Shadowrocketが接続済みなのにネットにつながらないときの対処法｜サーバー・モード・DNS・ルールを確認

この記事のポイント

Shadowrocketの接続スイッチをオンにしても、クライアントが接続処理を開始したことが分かるだけで、サーバーやDNS、Webサイトが利用可能とは限りません。利用中のサービスとサブスクリプションがあり、アプリを開けるもののWebページにアクセスできない場合を対象に、基本ネットワーク → サーバー → Global Routing → DNS → Ruleの順で確認します。一度に変更する項目は1つにし、同じURLで再テストして、原因を説明できる記録を残しましょう。

まず再テストの基準を記録する

確認を始める前に、現在のネットワーク、Homeで選択中のサーバー、Global Routingの設定値、Configで使用中の構成ファイルを記録します。変更前に構成をバックアップしてください。サブスクリプションの更新、サーバーの変更、DNSの変更を一度に行うと、復旧してもどの操作が有効だったのか判断できません。

以下ではiPhone / iPadのHome、Config、Settingsを操作例として説明します。他のプラットフォームでは該当する設定項目を確認し、モバイル端末のシステムVPN表示がすべての端末で共通だと考えないでください。テストには、普段アクセスできるものの現在問題が起きているWebサイトを使い、見覚えのないリンクは判断材料にしないでください。

オンデマンド接続を一時停止する

まずSettings → On Demandの現在の状態を記録し、確認中は自動接続を一時停止します。手動で接続をオフにした直後に再接続されるのを防げます。テスト後は元の設定に戻してください。
基本ネットワークを確認する

Homeの接続スイッチをオフにして、普段そのままアクセスできるWebページを開きます。それでも開けない場合は、Wi-Fiのログイン認証、ルーターの接続状態、モバイルデータ通信の許可を先に確認し、ルールの変更はまだ行いません。
テストするURLを固定する

直接アクセスできるURLと、問題が起きているURLを1つずつ選び、結果を記録します。毎回同じ完全なURLを再読み込みし、異なるWebサイトの状態を混同しないようにします。
接続し直す

他のVPN接続が同時に動作していないことを確認してから、Shadowrocketの接続スイッチをオンにします。設定を変更したらリクエストを新たに送信し、ブラウザーのキャッシュに残ったページを復旧の根拠にしないでください。

サーバーが実際に利用できるか確認する

Homeにサーバー項目が表示されていても、そのサーバーが現在も有効とは限りません。使う予定の項目が選択されていることを確認してから、Connectivity Testを実行します。結果はテスト方法と対象によって異なります。遅延が表示されても、そのテストが成功しただけで、すべてのドメイン、プロトコル、Webサイトにアクセスできるとは限りません。一度のタイムアウトだけで、サブスクリプション全体が無効だと判断することもできません。

項目の編集画面を開き、サービス提供元から案内されたパラメーターと照合します。アドレス、ポート、認証情報、暗号化方式、TLS関連の項目は、指定された組み合わせを保ってください。サーバーポートに共通の既定値はありません。Webでよく使われる443を、すべてのプロトコルのポートとして設定しないでください。サーバーアドレスにドメイン名を使う場合は、まずそのドメインを名前解決できることを確認します。

すべての項目がタイムアウトする：まずWi-Fiからモバイルデータ通信に切り替えて再テストします。一方のネットワークだけで失敗する場合は、そのネットワークのアクセス制限を確認し、サーバーパラメーターを一括変更しないでください。
1つの項目だけ失敗する：自分のサブスクリプションにある、利用できることが分かっている別の項目と比較します。失敗した項目の状態、利用枠、有効期限をサービス提供元に確認してください。
更新後も古いアドレスが表示される：Homeで自分のサブスクリプションを更新し、更新結果と項目の内容を確認します。更新に成功したことは、データの取得と解析ができたという意味であり、接続先のサーバーが利用できることを保証するものではありません。
更新自体に失敗する：元の構成を残したまま、自分のサブスクリプションURLが有効で、ネットワークに問題がないことを確認します。個人用のサブスクリプションURLを公開の掲示板などに投稿しないでください。URL内のtokenにアカウント権限が含まれている場合があります。

エラー詳細に以下の文字列が表示された場合は、それぞれの内容を手掛かりに原因を絞り込めます。プロトコルやシステムによって表示は異なるため、必ず同じ文言が表示されるとは限りません。

エラー：connection refused

原因と対処：接続がリモート側または中間機器によって明示的に拒否されています。ポートで待ち受けていない場合や、アクセス制御で拒否されている場合によく発生します。サーバーアドレスとポートを確認し、待ち受け状態をサービス提供元に問い合わせてください。ポート拒否をDNSの変更で解決しようとしないでください。

エラー：i/o timeout

原因と対処：処理が制限時間内に完了しませんでした。ネットワーク経路、接続先からの応答、名前解決の待ち時間などが原因として考えられます。まずログからどの段階でタイムアウトしたか確認し、別のネットワーク、または利用できることが分かっている別の項目で比較します。このメッセージだけでパスワードの誤りと判断することはできません。

エラー：no such host

原因と対処：ドメイン名を有効なアドレスに解決できませんでした。エラーに表示されたドメインがサーバーのものか、アクセス先Webサイトのものかを確認し、スペル、DNS設定、ドメインの有効性を調べてください。

モードを切り替えてルールの問題を切り分ける

Home → Global Routingを開き、まず現在の値を確認してから、短時間だけ設定を切り替えて比較します。Proxy、Direct、Config、Sceneは接続品質の段階ではなく、後ろの項目ほど安定するという意味でもありません。接続スイッチがオンだからといって、リクエストが必ずプロキシサーバーを経由するとは限りません。

設定値	意味	確認方法
`Proxy`	通常の設定ルールによる振り分けを行わず、プロキシ経由でリクエストを処理します。	選択中のサーバーで目的のWebサイトにアクセスできるか確認します。DNS、プロトコル、システムのルーティングなども影響します。
`Direct`	直接接続でリクエストを処理します。	現在のネットワークから直接アクセスできるかを比較します。接続スイッチをオンにしても、自動的にプロキシ経由にはなりません。
`Config`	現在の構成に設定されているルールに従って、リクエストの処理方法を決めます。	Proxyでは正常でConfigでは失敗する場合は、まずルールのマッチ結果と選択中のポリシーを確認します。
`Scene`	設定済みのシーン条件に応じて動作を選択します。	現在適用されているシーンとその設定を確認します。変数を減らすため、ProxyまたはConfigに一時的に切り替えて比較できます。

判断のポイント：成功する経路を維持する

同じネットワーク、同じサーバー、同じURLでProxyなら開けてConfigでは開けない場合は、サーバーパラメーターを変更せず、現在の構成で適用されるルールとポリシーグループを確認します。アプリの再インストールやサブスクリプション全体の再読み込みを先に行わないでください。

ProxyとConfigの両方で失敗する場合も、ルールが原因とは限りません。まずサーバーのテストに戻り、その後DNSを確認します。比較が終わったら必要なGlobal Routingの設定に戻し、一時的なテストモードを正式な解決策として使わないでください。

名前解決と接続の問題を見分ける

DNSはドメイン名をアドレスに変換しますが、その後の接続はサーバー、TLS、アクセス先Webサイトで失敗することがあります。ブラウザーの読み込みが続くだけではDNSの問題とは断定できません。また、DNSがアドレスを返しても、そのアドレスのサービスに接続できるとは限りません。リクエスト記録のドメイン、名前解決の結果、エラーが発生した段階をあわせて確認してください。

従来のDNSでよく使われるポート。UDPまたはTCPを使用

443

HTTPSでよく使われるポート。すべてのプロキシサーバーのポートではありません

2種類のドメイン

サーバーのドメインとアクセス先Webサイトのドメインをそれぞれ確認

Configで現在使用中の構成を見つけて編集内容を開き、[General]のdns-serverを確認します。カスタムDNSが設定されている場合は、変更前の値をバックアップしてから、1項目ずつ比較してください。以下はシステムDNSを使う設定例です。構成ファイル全体をこの2行に置き換える必要はありません。

[General]
dns-server = system

まずシステムDNSでテスト：変更を保存して再接続し、同じ問題のあるWebサイトにアクセスします。復旧した場合は、元のカスタムDNSへの接続性とアクセス経路を確認してください。カスタムDNS全般に問題があると決めつけないでください。
名前解決の前提条件に注意：サーバーアドレスがドメイン名の場合、プロキシ接続の前に名前解決が必要になることがあります。この段階で失敗している場合、アクセス先Webサイトのルールを切り替えるだけではサーバーに接続できません。
キャッシュの影響を除外：リクエストを再送信し、必要に応じて再接続するか、関連するアプリを再起動します。DNSを何度も切り替えて、たった一度の成功から原因を推測しないでください。
HTTPSのドメインをIPアドレスに置き換えない：証明書の名前やSNIが一致せず、新たなエラーが発生する可能性があります。一般的なDNS確認方法として使うことはできません。

ルールの順序とFINALを確認する

Global RoutingがConfigの場合は、Configを開いて実際に有効になっているファイルを確認します。選択されていないコピーだけを編集しないでください。ルールは通常、上から順に照合されるため、前方の広い条件に後方の詳細なルールより先に一致することがあります。末尾のFINALは、ほかのルールに一致しなかったリクエストに適用する既定のポリシーです。

以下はマッチ順序を理解するための最小限の例です。example.comは例示用ドメインであり、実際に問題が起きているWebサイトの代わりには使えません。テストに使う前にバックアップしてください。この例は日常的なアクセス要件をすべて網羅しておらず、サーバーやDNSの問題を自動で解決するものでもありません。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,DIRECT

ルールキーワード	例の意味	見落としやすい確認項目
`DOMAIN-SUFFIX`	指定したドメインとそのサブドメインに一致します。	プロトコル、パス、ポートを付けずにドメイン名を入力します。Webサイトへのアクセスで実際に使われる別のドメインも確認してください。
`IP-CIDR`	IPv4のネットワーク範囲に一致します。例はプライベートアドレスの範囲です。	`no-resolve`は、このIPルールの照合時にドメイン名の解決を積極的に行わないという意味です。DNSを全体的に無効にする設定ではありません。
`GEOIP`	IPの位置情報データベースに基づいて照合します。	分類結果は名前解決の結果やデータベースに左右されることがあり、ドメインの所在地と同じとは限りません。
`FINAL`	それまでのルールに一致しなかったリクエストにポリシーを指定します。	ルール一覧の末尾に置きます。例はDIRECTで、前のルールに一致しないリクエストは直接接続されます。

一部のWebサイトだけ開けない場合は、リクエスト記録で一致したルールと最終ポリシーを確認します。プロキシ経由にしたいWebサイトがFINAL,DIRECTに一致している場合は、まずそのドメインの振り分けルールを修正してください。カスタムポリシーグループに一致している場合は、そのグループで現在選択されているサーバーが有効かどうかも確認します。ルールが正しく一致していても、ポリシーグループの接続先が使えるとは限りません。

特定のドメインに対するルールは、関連する広い条件より前に置き、先に別のルールに一致しないようにします。
カスタムポリシー名が存在し、表記が一致しているか確認します。コメント内の名前を有効なポリシーと誤認しないでください。
変更を保存し、そのファイルが引き続き有効になっていることを確認してから、リクエストを再送信し、マッチ結果が想定どおり変わったか確認します。

症状に合わせて再テストする

原因を絞り込んだら、On Demandなどの日常設定を元に戻して、もう一度テストします。特にWi-Fiからモバイルデータ通信に切り替えた後は、シーン条件や自動接続によって、直前の確認結果が変わっていないか確かめてください。以下の質問を参考に、設定を維持するか、次に何を確認するか判断できます。

遅延時間は表示されるのに、Webページが開かないのはなぜ？

遅延テストとWebページへのアクセスでは、対象や処理手順が異なる場合があります。同じサーバーを使い、Home → Global Routingで一時的にProxyへ切り替えて問題のあるURLをテストします。その後DNSとエラーが発生した段階を確認し、遅延時間だけでアクセス成功と判断しないでください。

特定のWebサイトだけ開けない場合、再インストールが必要？

まず再インストールは不要です。Configで、そのWebサイトのリクエストに実際に適用されたルールとポリシーを確認します。Proxyでもそのサイトだけ開けない場合は、Webサイト自体の状態、証明書の有効期間、アクセス制限のメッセージを確認してください。

Wi-Fiでは使えないのにモバイルデータ通信なら使える場合、どこを変更する？

サーバーと構成を変えずに、2つのネットワークで同じURLを再テストします。まずWi-Fiのログイン認証を済ませ、そのネットワークのDNSとアクセス制限を確認してください。次にSettings → On DemandとSceneのネットワーク条件を確認し、サブスクリプションのパラメーターを一括変更しないでください。

サブスクリプションを更新しても接続できない場合、次は何をする？

Homeで新しい項目が選択されていることを確認し、サービスの有効期限、利用枠、アドレスを確認します。ほかの項目は使える場合、発生時刻、ネットワークの種類、個人情報を伏せたエラー内容をサービス提供元に伝えてください。サブスクリプションURL全体や認証情報は公開しないでください。

さらに原因を特定するには、「ネットワークの種類、Global Routingの設定値、サーバーテストの結果、DNSの比較結果、一致したルール、最終ポリシー、エラーの原文」の7項目を記録します。共有する前に、サブスクリプションtoken、パスワード、UUIDなどの認証情報を削除してください。設定キーワードの意味は設定項目で確認できます。原因が分からないまま、見覚えのない構成ファイル全体を貼り付けて解決しようとしないでください。