Shadowrocketの接続中にインターネットへつながらないときの対処法

この記事の概要

この記事は、Shadowrocketをインストールし、自分で用意したサービス事業者の設定またはサブスクリプションがあり、接続スイッチをオンにできても通信できない場合を対象としています。接続をオフにした状態で基本のネットワークを確認してから、Homeのサーバー、Global Routing、DNS、ConfigのRuleを順にチェックします。一度に変更するのは1項目だけにし、同じ接続先で再テストしましょう。アプリを何度も再インストールするのではなく、基本ネットワーク、プロキシ接続、名前解決、ルーティング設定のどこに問題があるかを特定できます。

1. VPNの起動と接続先への到達を切り分ける

接続スイッチがオンになり、システムにVPNと表示されるのは、アプリの通信を処理する経路が確立されたことを示します。リモートサーバーの認証成功や、接続先Webサイトへの到達を保証するものではありません。サーバーアドレスの名前解決失敗、ポートへの接続不可、認証情報の不一致、Ruleによるリクエスト拒否は、いずれもスイッチをオンにした後に発生する可能性があります。

普段アクセスできる用途の異なるWebページを2つ選び、すべて開けないのか、特定のドメインだけ開けないのか、ページは表示されても一部のリソースが読み込めないのかを記録します。1つのサイトの障害だけでネットワーク全体が使えないと判断しないでください。また、原因を特定できなくなるため、サーバー、DNS、設定ファイルを同時に切り替えるのは避けましょう。

接続をオフにする

Homeに戻って接続スイッチをオフにし、ブラウザで選んだ2つの接続先にアクセスします。それでも失敗する場合は、まずWi-Fiのログイン、モバイルデータ通信の権限、または現在のネットワーク自体を確認してください。
自動接続を一時停止する

Settings → On Demandを開き、元の設定を記録してから自動接続を一時的にオフにします。手動で切断した後、システムが再接続するのを防げます。確認が終わったら元の設定に戻してください。
テスト条件を固定する

まずネットワークを1種類、使用するサーバーを1台に固定し、Home → Global Routingの現在の選択肢と、Configで実際に有効になっている設定ファイルを記録します。
接続後に再テストする

接続を再びオンにし、同じブラウザで同じ接続先にアクセスします。Wi-Fiとモバイルデータ通信を比較する場合は、ほかの設定を変更せず、ネットワークの切り替えだけを別のテストとして行ってください。

2. Homeのサーバーと接続エラーを確認する

Homeで、選択中の項目がテストするサーバーそのものか確認します。サブスクリプショングループの名前だけで判断しないでください。項目の編集画面を開き、自分が利用しているサービス事業者の情報と、アドレス、ポート、プロトコル、認証情報を照合します。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuardではパラメーターの構成が異なるため、別のプロトコルの項目をそのまま当てはめることはできません。

ポートはサーバー側の設定と一致させてください。TLSを使用するサービスでは、サービス事業者から提供されたServer Nameなどの項目も確認します。証明書の検証を無効にして誤設定を隠すのは避けてください。端末の日付と時刻が正しくないと証明書の検証に影響する場合があるため、まず正しい時刻に戻します。サブスクリプションの更新後に項目が変わることがあるので、現在選択中の設定を改めて確認し、古い項目名だけで有効性を判断しないでください。

HomeのConnectivity Testで手がかりを得ることはできますが、結果はテスト方法と接続先によって異なります。表示された遅延時間だけでWebページにアクセスできるとは判断できません。
TCP接続が確立しても実際のリクエストが失敗する場合は、認証情報とTLSパラメーターを確認します。ポートに接続できることと、アプリの通信を正常に転送できることは別の段階です。
特定のネットワークでHysteria2またはWireGuardだけが失敗する場合は、そのネットワークとサーバー側でUDPが到達可能か確認します。これらのプロトコルはTCPのテスト結果だけでは判断できません。
利用中のサブスクリプション内容が変更された場合は、元のサブスクリプションの更新機能で最新のパラメーターを取得してください。ポートやパスワードを推測で設定したり、サブスクリプションURL、キー、ログ全体を公開したりしないでください。

以下はネットワークログに記録されることがあるエラー文字列の例で、決まったポップアップのタイトルではありません。実際の文言はプロトコルや下位レイヤーのエラーによって異なります。該当する情報がログに記録されている場合に限り、対応する項目を確認してください。

エラー: connection refused

原因と対処:接続先ポートへの接続が拒否されています。サービスが待ち受けていないか、ネットワーク機器が接続を拒否している可能性があります。まずサーバーアドレスとポートを確認し、利用中のサービス事業者に稼働状況を問い合わせてください。先にドメインルールを変更する必要はありません。

エラー: i/o timeout

原因と対処:読み書きのいずれかの処理が制限時間内に完了しなかったことを示します。このエラーだけではDNSとサーバーのどちらに原因があるか分かりません。前後のログからタイムアウトした接続先を確認し、同じ設定を別のネットワークでもテストしてください。

エラー: no such host

原因と対処:問い合わせたホスト名を有効なアドレスに名前解決できませんでした。まずサーバーのドメインかWebサイトのドメインかを確認し、入力ミスと名前解決の経路を調べます。サーバードメインの名前解決失敗をRuleの問題と取り違えないようにしてください。

3. Global Routingでルーティングの問題を切り分ける

Home → Global Routingを開き、現在のProxy、Direct、Config、Sceneのいずれが選択されているか記録します。Proxyは通信をプロキシ経由で処理し、Directは直接接続します。Configは有効な設定に基づいて通信を振り分け、Sceneは選択中のシーン設定で動作します。切り分けには現在の動作モードの把握が欠かせません。ConfigのRuleだけを変更しても、別のモードを使い続けていると想定した結果にならないことがあります。

選択肢	このテストで確認すること	結果を見た後の対応
Direct	直接接続で通信できるかを比較する	失敗する場合は、接続をオフにしたときの結果と比較し、基本ネットワークと名前解決の設定を確認します。
Proxy	同じサーバーでプロキシ経由の通信をテストする	2つの接続先がどちらも失敗する場合は、Ruleの並べ替えを急がず、サーバー、認証、名前解決を優先して確認します。
Config	現在の設定による振り分けをテストする	Proxyでは接続でき、同じ接続先がConfigで失敗する場合は、適用されたルールと最終ポリシーを確認します。
Scene	シーンで実際に適用される設定を確認する	まず現在のシーンを確認します。問題を切り分ける間は、ProxyまたはConfigを明示的に選んで比較してください。

結論:まずプロキシ経由の通信を固定し、次にルールを確認する

同じネットワーク、同じサーバー、同じ接続先でProxyは成功し、Configは失敗する場合、次のテストではConfigの適用ルールと関連する名前解決設定だけを確認します。サーバーを同時に切り替えないでください。この比較で原因を絞り込めますが、リクエストの記録も確認して判断しましょう。

Global Routingの切り替えは診断のための操作であり、恒久的な解決策ではありません。テスト中に既存の長時間接続があると、切り替え後も古い接続が使われることがあります。切り替えた後はリクエストを新しく発行し、必要に応じて接続を一度オフにしてから再度オンにしてください。テスト終了後は元のモードに戻します。一時的にProxyを使っても、元のルーティング設定の問題が解決したとは限りません。

4. DNSの問題が発生した段階を見分ける

DNSを確認する際は、まず「どのドメインの名前解決に失敗したか」を特定します。サーバーアドレスがドメイン名の場合、プロキシ接続を確立する前にサーバーのIPアドレスを取得する必要があります。一方、Webサイトのドメインは、その後のリクエスト段階で名前解決されることがあります。どちらもタイムアウトとして表示される可能性がありますが、確認する順序は異なります。まずサーバーアドレスを名前解決できるようにしてから接続先ドメインを確認してください。まだ確立していないプロキシ接続で、前提となるすべての名前解決ができるとは限りません。

従来型DNSでよく使われるポート（UDPまたはTCP）

443

DoHがHTTPSで通常使用するポート

853

DoTで通常使用されるTLSポート

これらは名前解決方式でよく使われるポートであり、サーバーポートをこのいずれかに変更する指示ではありません。暗号化DNSを利用する場合も、DNSサーバーに到達できる必要があります。DNSの接続先がプロキシ確立後にしかアクセスできない一方、そのDNSでプロキシサーバーのドメインを解決しようとすると、依存関係が循環することがあります。DNSアドレスが正しくても、現在のネットワークからアクセスできるとは限りません。

Settings → DNSの現在の設定を記録し、Configで現在有効な設定に[General]のdns-server項目が含まれているか確認します。設定の参照元が複数ある場合は、実際に適用されているものを特定してください。無効なファイルだけを変更しないようにしましょう。
失敗したリクエストに接続先IPが記録されているか、名前解決エラーが発生しているか、サーバーへの接続前と接続先へのリクエスト中のどちらで失敗したかを確認します。IPが特定された後に接続がタイムアウトしているなら、Webページが開かないというだけでDNS障害と決めつけることはできません。
DNSを手動で設定したことがある場合は、元の値を保存してから、この項目だけを以前利用できていた設定に戻して比較します。サーバーとGlobal Routingは変えず、接続を確立し直して再テストしてください。
特定のWi-Fiでだけ名前解決に失敗する場合は、モバイルデータ通信に切り替え、ほかの条件を変えずに比較します。結果が異なればネットワーク環境が障害に関係していると分かりますが、どの機器が通信を妨げているかまでは特定できません。

5. ConfigでRuleの適用順を確認する

プロキシ経由では通信できるのにConfigで特定の接続先だけ失敗する場合は、Configで実際に有効なファイルを開き、[Rule]を確認します。ルールは上から順に評価され、最初に一致したルールのポリシーが適用されます。通常、個別のドメインルールは広範囲に適用されるルールより前に置き、FINALは末尾に配置します。編集する前に元ファイルのコピーを保存し、変更後もそのファイルが適用されていることを確認してください。

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

上の例は構文と順序を示すもので、現在の設定をそのまま置き換えるためのものではありません。example.comは例示用ドメインです。DOMAIN-SUFFIXはそのドメインとサブドメインに一致し、IP-CIDRはIPアドレス範囲に一致します。GEOIPはIPアドレスの地域情報に基づき、FINALはそれ以前のルールに一致しなかったリクエストを処理します。no-resolveは、そのIPルールとの照合のために能動的なドメイン名解決を行わない設定です。すべてのDNSを無効にするという意味ではありません。

確認する順序:接続先が先行するDIRECTルールに一致している場合、末尾のFINALでPROXYに変更されることはありません。例外ルールを追加する場合は、適用を上書きしているルールより前に配置してください。
ポリシーの確認:ルールが独自のポリシー名を指定している場合は、対応するポリシーが存在し、最終的に選択されているサーバーが利用可能か確認します。グループ名が正しく見えても、グループ内で選択された項目が使えるとは限りません。
拒否ルールの確認:REJECTに一致したリクエストは拒否されます。Webページ本体は表示されるのに必要なリソースだけ読み込めない場合は、アドレス欄のドメインだけでなく、そのリソースのドメインとポリシーも確認してください。
IPルールの確認:GEOIPとIP-CIDRは、リクエストで利用できるIP情報に依存します。ドメインの名前解決結果が変わると適用されるルールも変わるため、一度の確認結果を固定のものと考えないでください。

適用されたルールを特定したら、失敗した接続先に関係する最小限の範囲だけを変更し、同じテストを繰り返します。1つのWebページを表示するためにすべてのルールを削除しないでください。一時的にアクセスできても、元の問題を判断する根拠が失われる可能性があります。各ルール項目の詳しい説明は設定項目マニュアルを参照してください。

6. よくある症状と復旧手順

遅延時間が表示されてもWebページが開かないのはなぜですか？

遅延テストで確認できるのは特定のテストへの応答であり、認証、TLS、DNS、接続先へのリクエストすべてを確認するものではありません。同じサーバーのままHome → Global RoutingでProxyに切り替えて元の接続先にアクセスし、リクエストのエラーからハンドシェイクと接続先への接続のどちらに失敗したかを判断してください。

Wi-Fiでは使えるのにモバイルデータ通信では使えません。まず何を確認すればよいですか？

まず接続をオフにし、モバイルネットワーク単体でアクセスできるか確認します。次に、システム設定でShadowrocketのモバイルデータ通信が許可されているか確認してください。その後、同じサーバーとモードで再テストします。UDPに依存する設定だけが失敗する場合は、そのネットワークでの接続条件を利用中のサービス事業者に確認し、プロトコル項目をむやみに変更しないでください。

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

まずProxyとConfigでその接続先の結果を比較し、読み込みに失敗したリソースのドメイン、適用ルール、最終ポリシーを確認します。どちらのモードでも失敗し、ほかのWebサイトは正常に開ける場合は、接続先サービスの状態、リモート側から接続先までの経路、そのWebサイト独自のアクセス条件も考慮してください。

スイッチをオフにしても自動的に再接続されます。どう確認すればよいですか？

Settings → On Demandで自動接続を一時的にオフにし、接続を切った状態で基本のテストを行います。確認後は元の設定に戻してください。自動接続の動作をスイッチの故障と誤認しないようにしましょう。また、この現象への対処として、すぐにシステムのVPN設定を削除する必要はありません。

最後に、Global Routing、DNS、On Demandで一時的に変更した設定を元に戻し、比較テストで有効性を確認できた修正だけを残します。それでも解決しない場合は、発生日時、ネットワークの種類、プロトコル、個人情報を伏せたエラー原文、Direct・Proxy・Configの3通りのテスト結果を利用中のサービス事業者に伝えてください。パスワード、UUID、キー、サブスクリプショントークンは伏せてください。「スイッチはオン」という情報より、これらの情報のほうが接続のどの段階で問題が起きているかを特定する助けになります。