Shadowrocketが接続中なのにインターネットに繋がらないときの対処法：サーバー・Global Routing・DNS・ルールの確認

この記事の要点

Shadowrocketの接続をオンにしても、起動したのはシステムのトンネル機能であり、サーバーや名前解決、接続先のWebサイトまで利用できるとは限りません。この記事では、利用中のサービスとサブスクリプション情報をお持ちの方を対象に、まずローカルネットワークの状態を確認し、次にサーバー、Global Routingによる条件比較、DNS、ルールの適用状況を順に調べます。各回で変更する項目は一つだけにし、同じ接続先で結果を記録すると、設定変更をネットワーク復旧と誤認しにくくなります。

1. まず障害の範囲を確認する。再インストールは後回し

「すべての通信が失敗する」「一部のドメインだけ失敗する」「ネットワークを切り替えると失敗する」をまず区別します。現象によって確認すべき点が異なります。システムにVPNと表示されても、接続先のプロキシとのハンドシェイクが完了したとは限りません。Homeにテスト遅延が表示されても、実際のWebリクエストの成否を示すものではありません。

調査中は現在のConfigとサーバー情報を残し、アプリをすぐに削除しないでください。削除後に再読み込みすると、設定やキャッシュ、選択状態が同時に変わり、原因を特定する手がかりを失うおそれがあります。オンデマンド接続を有効にしている場合は、Settings → On Demandで一時停止してから、手動で接続のオン・オフを試します。テスト後は元の設定に戻してください。

ネットワークの基準状態を確認する

Homeで接続をオフにし、通常は直接アクセスできるHTTPSページを開きます。それでも表示できない場合は、Wi‑Fiのログイン認証、モバイルデータ通信の権限、ルーターへの接続を先に確認してください。ローカルネットワークの切断をルールの問題と決めつけないようにします。
テストする接続先を固定する

直接接続する接続先と、利用中のプロキシ経由でアクセスする接続先を一つずつ選び、毎回同じドメイン、同じページを使います。ページ全体が読み込まれた場合を成功とします。以前表示したページが画面に残っていても、新しいリクエストが成功したとは限りません。
現在の状態を記録する

Homeで選択中のサーバーとGlobal Routingのモードを記録し、Configで現在有効な設定を確認します。Wi‑Fiとモバイルデータ通信のどちらを使っているかも記録し、比較中は条件を同時に変えないでください。
リクエストを再実行する

接続をオンにしたら、テストページを開き直し、新たに記録されたリクエストを確認します。接続先ドメイン、時刻、適用されたポリシー、エラー情報を記録してください。数分前の古い記録を今回の結果と取り違えないようにします。

2. サーバーを確認する：トンネルが起動しても接続先に到達できるとは限らない

Homeで実際に選択されているサーバーを確認します。サブスクリプション一覧にサーバーが表示されているだけでは不十分です。アドレス、ポート、プロトコル、認証情報が、利用中のサービスから提供された情報と一致しているか確認してください。サーバーにドメイン名を使う場合、プロキシ接続の確立前にその名前を解決する必要があります。そのため、サーバーのドメイン名を解決できない場合も接続不能として現れます。

ポート番号だけではプロトコルは判断できません。たとえばサーバー側がTCP 443を使っていても、どのプロトコルでもそのポートに接続できるわけではありません。Trojanの認証情報とTLS設定、VMessやVLESSのトランスポート設定、Shadowsocksの暗号化方式は、サーバー側と一致させる必要があります。試行錯誤のためにTypeだけを変更し、互換性のないほかの項目を残さないでください。

まず現在の項目をテスト：HomeでConnectivity Testを実行し、その後に実際のWebページを開いて確認します。テストに失敗した場合は、引き続き原因を調べます。成功しても、その時点でテストに使われた経路が利用できたことを示すだけです。
次に同じネットワークで比較：一覧にほかの有効な項目がある場合は、Global RoutingとConfigを変えず、サーバーだけ切り替えます。一つの項目だけ失敗する場合は、その項目のパラメーター、有効状態、接続先のサービスを優先して確認してください。
最後にネットワークを切り替える：サーバーはそのままにして、Wi‑Fiからモバイルデータ通信に切り替えて再テストします。片方のネットワークでのみ失敗する場合は、そのネットワークの認証状態や通信制限、使用中のトランスポートが到達可能かを確認してください。
利用中のサブスクリプションを確認：サービスのパラメーターが変更された場合は、自分が利用しているサブスクリプションを更新してから、対象の項目を選び直します。更新に成功したことが示すのは設定内容を取得できたという点だけで、サーバーがすべて現在も利用可能とは限りません。

エラー：`connection refused`

原因：接続先または中間の機器が接続を明示的に拒否しています。アドレス、ポート、サーバーの待ち受け状態を確認してください。

対処：利用中のサービスから提供された情報とポートを照合します。情報が一致している場合は、発生時刻、ネットワークの種類、エラー内容を利用中のサービス提供元に伝えて確認を依頼してください。DNSを次々に変更しても解決にはつながりません。

エラー：`i/o timeout`

原因：ネットワーク上の処理が制限時間内に完了しませんでした。このメッセージだけでは、サーバー、通信経路、接続先のどこに問題があるか判断できません。

対処：同じ記録の前後にある接続先と処理段階を確認します。そのうえで「同じネットワークでサーバーを変更」「同じサーバーでネットワークを変更」と比較し、失敗箇所を絞り込みます。

ここに挙げたのはネットワークログに表示される可能性がある低レベルのエラー原文で、固定の画面表示文言ではありません。プロトコルによって前後の情報は異なるため、問い合わせ時は前後のログも残し、パスワード、認証情報、サブスクリプショントークンは必ず伏せてください。

3. Global Routing：ProxyとConfigを使って出口とルールを切り分ける

Home → Global Routingで現在のモードを確認します。Proxy、Direct、Config、Sceneはそれぞれ通信の処理方法を示すもので、サーバーの稼働状況を示すものではありません。調査前に元の設定を記録し、短時間の比較が終わったら元に戻します。モードを切り替えると、ほかのアプリで進行中の通信に影響する可能性があります。

モード	処理内容	今回の確認での用途
Proxy	通信をプロキシ経由で処理し、Configの通常の振り分けルールに従って直接接続を選ぶことはありません。	サーバーを固定し、プロキシの出口から実際のリクエストを完了できるか確認します。
Direct	直接接続する経路を使います。	ローカルネットワークと接続先への直接接続が可能か確認します。プロキシサーバーの検証には使えません。
Config	現在有効な設定とルールに基づいて処理方法を決定します。	Proxyと比較して、ルール、ポリシー、設定内のDNSに違いがないか特定します。
Scene	設定済みのシーン条件に基づいて、対応するルーティング方法を適用します。	まず実際に適用されているシーンを確認します。最初の切り分けでは、条件の変動を減らすため、明示的なモードに切り替えてください。

同じサーバーと接続先でProxyなら成功し、Configでは失敗する場合は、現在の設定と適用されたポリシーを優先して確認します。ただし、すぐに「ルールの記述ミス」とは断定できません。設定内の名前解決、実際に選択されたポリシーグループ、拒否ルールなども差の原因になり得ます。どちらのモードでも失敗する場合は、ルールを追加し続けるのではなく、サーバーへの到達性とDNSを先に確認してください。

まとめ：再現できるモード間の違いを記録する

「Proxyでは成功、Configでは失敗」となる場合は、その比較結果を残し、失敗したリクエストに実際に適用されたルールと送信先を確認します。まず違いの箇所を特定してから設定を変更してください。サーバーとDNSを同時に切り替えないようにします。

4. DNSを確認する：サーバーのドメイン名と接続先のドメイン名を分けて確認

1回のアクセスで、プロキシサーバーのアドレスと接続先Webサイトのドメイン名という2種類の名前解決が必要になることがあります。前者に失敗すると、プロキシ接続はまだ確立されません。後者に失敗すると、サーバーには到達できても接続先へのリクエストを続けられない場合があります。名前解決がローカルとリモートのどちらで行われるかは、プロトコルと設定によって異なります。ページの読み込みが続くだけでは判断できません。

接続先のドメイン名名前解決の結果ルール判定送信先への接続接続先からの応答

この流れは確認箇所を理解するためのもので、すべてのプロトコルで同じ段階にて名前解決されることを示すものではありません。Configで現在の設定の編集画面を開き、[General]内のdns-serverなどの名前解決設定を確認します。また、リクエスト記録に名前解決の失敗、空の結果、異常なアドレスがないか確認してください。カスタムDNSサービスを使う設定の場合は、そのDNSサービスへの接続に必要なネットワーク経路も調べます。

変更する設定元は一つだけ：まず設定のコピーを保存し、現在のカスタムDNS設定を一時的に、利用できることが確認済みのシステムDNSに戻します。再接続して同じドメインを試し、Config全体を同時に置き換えないようにしてください。
アドレスの種類を分けて確認：記録にAとAAAAの結果がある場合は、最終的に接続されたIPv4またはIPv6アドレスをそれぞれ確認します。AAAAレコードを受信しても、現在のネットワークからIPv6で通信できるとは限りません。
ポートを正しく理解する：従来のDNSは通常UDPまたはTCP 53を使用し、DoHはHTTPSを使うため、一般にTCP 443が関係します。ポートに到達できてもDNSリクエストが成功するとは限りません。実際の応答を確認してください。
IPアドレスに置き換えて検証しない：HTTPSサイトでは、証明書の検証や仮想ホストの選択にドメイン名が必要な場合があります。アドレス欄をIPアドレスに変えて失敗しても、それだけでDNSの問題とは判断できません。

5. ルールを確認する：ルールの有無だけでなく、最初に適用されたルールを見る

Configで実際に有効な設定を確認してから、失敗したドメインのリクエスト記録を調べます。適用されたルール、最終的なポリシー、実際に使われたサーバーを記録してください。ルールは順番に評価されます。先に一致したリクエストが、後ろにより意図に近いルールがあるというだけで自動的に別の経路へ変わることはありません。

以下は順序と構文を説明するための例で、既存の設定をそのまま置き換える汎用的な設定ではありません。example.comは例示用のドメイン名、192.168.0.0/16はプライベートアドレス範囲です。PROXYとDIRECTはルールのポリシーキーワードであり、Global Routingメニューの表示文言とは区別してください。

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

DOMAIN-SUFFIX：この例ではexample.comとそのサブドメインに一致します。実際のページではログイン、画像、API用の別ドメインにもアクセスする場合があります。メインページのリクエストが一致しても、依存するすべてのリクエストが一致するとは限りません。
IP-CIDR：接続先のIPアドレス範囲に基づいて一致します。例のno-resolveは、このIPルールに一致した通信のために追加のドメイン名解決を行わないことを示します。設定全体のDNSを無効にするものではありません。
GEOIP：たとえばGEOIP,CN,DIRECTは、アドレスの地域情報に基づいて判定します。結果はアドレスと使用するデータベースによって変わるため、ドメインのサフィックスルールとして使うことはできません。
FINAL：前のルールに一致しなかった場合に適用される最終処理です。この例ではFINAL,DIRECTを使っているため、最初の2つのルールに一致しないリクエストは直接接続されます。接続先にプロキシが必要な場合、このフォールバックは意図と異なる可能性があります。

ルールの適用結果が意図と異なる場合は、まず想定したConfigが有効か確認し、次にルールの順序、ドメイン名のつづり、参照先のポリシーを確認してください。ポリシーグループが適用されている場合は、グループ内で実際に選択されているサーバーも調べます。PROXYと表示されているだけで、想定した出口を通っていると決めつけないでください。

まとめ：誤った振り分けを確認できた場合だけ修正する

失敗したリクエストの記録から、接続先が誤って直接接続されていることが明確な場合は、設定のコピーに対象範囲を絞ったドメインルールを追加し、先に一致する広範なルールより前に配置します。ページと依存するリクエストを確認してから、変更を残すか判断してください。

6. よくある質問：一部だけ使える場合、自動再接続、サブスクリプションの更新

遅延の数値が表示されるのに、Webページが開かないのはなぜですか？

遅延の数値は特定のテスト結果であり、すべての接続先、DNS経路、Webページが依存するリクエストの結果を示すものではありません。同じサーバーを使い、Proxyで実際の接続先にアクセスしてから、名前解決、接続、応答のどの段階で失敗したかを確認してください。

一つのWebサイトだけ開けない場合、設定全体を変更する必要はありますか？

まず、そのWebサイトのメインドメインとAPIドメインのリクエスト記録を確認します。ほかの接続先は正常なら、対象ドメインのルール、名前解決の結果、接続先からの応答を優先して調べてください。HTTP 403や429などの応答は、何らかのHTTPサービスまでリクエストが届いたことを示します。応答元とアクセス条件を確認し、すぐに再インストールしないでください。

接続をオフにしても自動的にオンに戻る場合、どう比較すればよいですか？

Settings → On Demandを開き、オンデマンド接続を一時的にオフにしてから、手動で切断してテストします。デバイスに管理ポリシーが適用されている場合は、その接続要件も確認してください。今回の調査が終わったら元の設定に戻し、テスト用の状態を長期間残さないようにします。

サブスクリプションの更新失敗とWebページが開かない問題は同じですか？

いいえ。サブスクリプションの更新では設定のアドレスにアクセスし、Webページの表示では接続先サイトにアクセスするため、通信経路が異なる場合があります。まず自分のサブスクリプションURLが完全で、現在も有効か確認します。次に、そのアドレスの名前解決と接続経路を確認してください。更新後はHomeで選択中のサーバーも改めて確認します。

モバイルデータ通信に切り替えると直る場合、Wi‑Fiの問題と判断できますか？

ネットワーク環境が障害に関係していることは分かりますが、条件をそろえて確認する必要があります。サーバー、Config、接続先を変えずに、Wi‑Fiの認証が完了しているか、直接接続できるか、現在のトランスポートがそのネットワークで許可されているかを確認してください。プロトコル、サーバー、DNS設定を一度に変更しないでください。

7. 設定を元に戻し、再現できる記録をまとめる

原因を特定したらGlobal RoutingとOn Demandを元の設定に戻し、検証済みで必要な変更だけを残します。一度成功しても問題が完全に解消したとは限りません。最初に失敗したネットワークでリクエストを再実行し、接続をオフにしてから再びオンにしても同じ結果になることを確認してください。

環境：デバイスの種類、ネットワークの種類、発生時刻、接続をオフにしたときに直接接続できるか。
比較結果：同じ接続先でProxyとConfigを使った場合の結果、ネットワークまたは利用中のサーバーを切り替えたときの変化。
確認情報：失敗したリクエストのドメイン名、適用されたポリシー、エラー原文と前後の記録。テスト対象がWebページかConnectivity Testかも記載します。
プライバシー：記録を送る前に、サブスクリプションの完全なURL、トークン、パスワード、その他の認証情報を削除し、原因の特定に必要な情報だけを残します。

この記録によって、「接続をオンにしても使えない」という状況を、サーバーに接続できない、名前解決できない、ルールが誤った送信先を選ぶ、接続先からエラーが返る、という具体的な問題に切り分けられます。何度もリセットするより、順番に検証するほうが証拠を残しやすく、利用中のサービス提供元も接続先の状態を確認しやすくなります。