Shadowrocket の接続スイッチをオンにすると確認できるのは、端末側の接続状態だけです。リモートサーバーや名前解決、接続先のWebサイトが利用できるとは限りません。自身のサービス情報とサブスクリプションをすでにお持ちで、Webページが開かない場合に役立つ内容です。まず通常のネットワーク接続を確認し、サーバー、モード、DNS、ルールの順に原因を絞り込みます。一度に変更する設定は一つだけにし、最後に普段の設定へ戻してください。
1. 通常のネットワークとプロキシ経路の問題を切り分ける
すぐにサブスクリプションを削除したり、すべての設定をリセットしたりしないでください。まず Home で選択中のサーバーと Global Routing のモードを、Config で使用中の設定ファイルを記録します。同じ「Webページが開かない」状態でも原因はさまざまです。現状を残しておけば、どの変更が効果をもたらしたか確認できます。
システムに接続済みと表示されても、通常わかるのはローカルのVPNトンネルが開始したことまでです。リモートサーバーが接続を受け付けるか、認証情報が有効か、DNSが応答するかは個別に確認する必要があります。普段アクセスでき、ログイン不要のWebページを使ってテストし、日時とエラーの内容を記録してください。
-
現在の状態を記録
Home で選択中のサーバーと Global Routing、Config で使用中の設定を記録します。元の設定を保存してから変更し、最初からあった問題と変更後の影響を混同しないようにします。
-
接続を切る
Home の接続スイッチをオフにします。接続が自動で再開する場合は Settings → On Demand を確認し、条件を一時的に無効にしてから、接続が確実に切れたことを確認します。
-
直接接続を確認
Safari で、直接接続できることがわかっているWebページを開きます。それでも開けない場合は、ルールを変更する前に、現在のWi-Fiでのログイン認証、モバイルデータ通信の許可、通常のネットワーク接続を確認してください。
-
接続を戻してテスト
接続を再びオンにし、同じWebページで再テストします。テスト中はネットワーク、サーバー、接続先を変えず、1回につき設定を一つだけ変更してください。
-
別のネットワークでも確認
可能であればWi-Fiとモバイルデータ通信を切り替え、同じ接続先をテストします。片方のネットワークだけで失敗する場合は、そのネットワークの名前解決、ポート、通信制限を優先して確認してください。
2. サーバーのアドレス・ポート・プロトコル設定を確認
Home で実際に選択されているサーバーを確認します。サブスクリプションのグループ名だけを見て判断しないでください。そのサーバーの編集画面を開き、手元にあるサービス情報と Address、Port、Type、認証項目を一つずつ照合します。サブスクリプションの更新に成功したことが示すのは、内容を取得して解析できたことだけです。サーバーごとの通信が現在可能かどうかは別途確認してください。
Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuard の設定項目は相互に置き換えられません。サーバーで使われているプロトコルに合わせて項目を確認してください。TLSを使う場合はサーバー名と証明書の要件も、トランスポート層の設定がある場合はパスやホスト名なども確認します。Type を手当たり次第に変更して「修復」しようとしないでください。
- アドレスとポート：Port はリモート側の待ち受けポートと一致している必要があります。サービスによっては 443 を使いますが、すべてのサーバーのポートを 443 に変更してよいわけではありません。
- 認証情報：パスワード、UUID、キーが現在有効な設定のものか確認します。コピーした値に空白や改行が混入していないかも確認してください。
- 時刻と証明書：端末の時刻が大幅にずれていると、TLSの検証に影響することがあります。まず時刻を正確に合わせ、証明書エラーが出る場合は名前とサーバー側の設定を確認してください。検証をそのまま無効にするのは避けてください。
- テスト結果の見方：Home で Connectivity Test を実行し、どの方式でテストされたか確認してください。TCP接続が成功しても、プロトコル認証の成功を意味するわけではありません。一度の遅延測定だけでWebページが利用できるとも判断できません。
接続ログに次のようなメッセージがある場合は、発生した段階に応じて原因を調べます。プロトコルやエラーの発生元によって、接頭辞や追加情報が付くことがあります。一つの単語だけで判断せず、ログ全体を保存してください。
エラー：connection refused
原因：接続先または途中の機器が接続を拒否しています。ポートの不一致や、サービスが待ち受けていない場合によく発生します。
対処：Address と Port を確認し、自身のサービス提供元に該当ポートが現在待ち受けているか問い合わせてください。
エラー：i/o timeout
原因：ネットワーク上の読み書きが所定の時間内に完了しませんでした。このエラーだけでは、通信の破棄、サーバーの無応答、その後のハンドシェイク停止のどれかを特定できません。
対処：タイムアウトした接続先と段階を記録します。設定を変えずに別のネットワークで再テストし、同じサブスクリプションにある、すでに利用している別のサーバーとも比較してください。
エラー：no such host
原因：今回の名前解決で有効なホストアドレスを取得できませんでした。サーバーのドメイン名の入力ミスか、名前解決経路の異常が考えられます。
対処：まずエラーに表示されたドメイン名を確認してください。サーバーアドレスの名前解決に失敗している場合は、先にそのアドレスを解決できるようにしてからWebサイトのドメインをテストします。
3. Global Routing で問題の範囲を絞る
Home → Global Routing を開き、現在のモードを確認します。Direct、Proxy、Config、Scene はそれぞれ異なる処理方法であり、接続成功度を示す4段階ではありません。テスト前に元のモードを記録し、一時的に切り替えたら、テスト後に元へ戻してください。
| モード | 主な動作 | トラブル対処での用途 |
|---|---|---|
Direct | 直接接続で処理 | 通常の直接接続経路を確認できます。プロキシサーバーの利用可否を検証する用途ではありません。 |
Proxy | プロキシ経由で処理 | 現在のプロキシ経路を一時的に確認し、設定ファイルのルールによる振り分けの影響を減らします。 |
Config | 現在の設定ファイルのルールに従って処理 | ルールの順序、ポリシー名、最後のフォールバックを確認するのに適しています。 |
Scene | 設定済みのシーン条件に従って処理 | 現在のネットワークでどのシーンが適用され、そのシーンでどの設定が使われているか確認します。 |
同じサーバーとURLを使って比較します。Proxy では開けて Config では開けない場合は、ルールやポリシーを優先して確認してください。ただし、モードを切り替えるとリクエスト経路や名前解決の動作も変わることがあります。Proxy でも失敗する場合は、サーバー設定とDNSに戻って確認します。ドメインルールを追加して何度も試すだけでは解決しません。
結論：経路を固定してからルールを変更
同じ接続先が固定したプロキシ経路では利用でき、Config では安定して失敗する場合に限り、振り分けルールを優先して調べます。どちらのモードでも失敗する場合は、ルールを変更せず、両方で共通して使われるサーバーと名前解決経路を確認してください。
4. DNSを確認：どのドメインの名前解決に失敗したかを特定
DNSの問題には少なくとも2つの段階があります。リモートサーバーへの接続時にはサーバーのドメイン名を、Webページへのアクセス時にはWebサイトのドメイン名を解決します。前者に失敗するとプロキシ経路を確立できず、後者に失敗すると接続済みでもWebページが長時間読み込み中になることがあります。DNSサーバーを何度も変更するより、エラーに表示されたドメイン名を確認するほうが効果的です。
Settings → DNS でアプリ側の名前解決設定を確認するとともに、現在の Config ファイルにDNS関連の設定が含まれていないか確認します。現在の値と設定元を記録してください。Settings だけを変更しても、使用中の設定ファイルに別の名前解決要件が残っている場合があります。どの設定が実際に適用されるかは、リクエスト記録と合わせて確認してください。
- まず入力形式を確認：IPアドレスと暗号化DNSのURLは、入力形式が異なります。設定項目が対応する形式で入力してください。プロトコルの接頭辞だけを削除して使い続けないでください。
- 次に到達性を確認：暗号化DNSを使う場合も、ネットワークから接続できる必要があります。ドメイン名を使う名前解決エンドポイントは、そのエンドポイント自体を先に名前解決する必要がある場合もあります。暗号化方式に変えるだけでネットワークの問題が自動的に解決するわけではありません。
- IPv4とIPv6の結果を確認：ドメインから A と AAAA の両方のレコードが返されても、IPv4とIPv6で実際の到達性が異なることがあります。失敗が一方のアドレスファミリーに集中している場合は、ドメイン全体が使えないと判断せず、該当する経路を確認してください。
- 誤ったテストを避ける：HTTPSサイトのドメインをIPアドレスに置き換え、証明書エラーからDNSの問題を判断しないでください。HTTPSには証明書名、SNI、バーチャルホストも関係します。IPアドレスでアクセスできないことだけでは、名前解決に問題があるとは証明できません。
5. ルールの順序、ポリシー、FINAL を確認
Config で選択中の設定ファイルを確認し、その中のルールを調べます。ルールは通常、上から順に照合され、先に一致したルールによって後続のルールがリクエストを処理できるかが決まります。ファイルの末尾にドメインルールを追加しても、前のルールですでに処理された通信には影響しない場合があります。
以下の例は構文を確認するためのもので、現在の設定を置き換える汎用的な推奨設定ではありません。example.com は例示用ドメイン、192.0.2.0/24 はドキュメント用の例示ネットワークです。実際のトラブル対処では、失敗したドメイン、リクエスト記録、自身のポリシーを基に確認してください。
[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.0.2.0/24,PROXY,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYDOMAIN-SUFFIX：指定したドメインの末尾とそのサブドメインに一致します。プロトコル部分、パス、スペルに誤りがないか確認してください。ルールに記述するドメインは、Webページの完全なURLではありません。IP-CIDR：接続先のIPアドレス範囲で照合します。例のno-resolveは、このIPアドレスルールへの照合のためだけにドメイン名の名前解決を開始しない指定です。すべてのDNSを無効にするものではありません。GEOIP：IPアドレスの地理情報データベースの結果で照合します。Webサイトの表示言語やドメインの末尾で判断するものではありません。データベース上の分類と実際のサービスの帰属先が一致しない場合もあります。FINAL：それ以前のルールに一致しなかったリクエストに適用するフォールバックポリシーです。ルールの末尾に配置します。Direct、Proxy、その他の有効なポリシーのどれを指定するかによって、未一致の通信経路が決まります。
設定でカスタムポリシーグループを参照している場合は、グループ内で現在選択されている項目も確認してください。ルールがグループ名に一致しても、そのグループが必ずプロキシを使うとは限りません。グループ内で直接接続、または現在利用できないサーバーが選択されている場合があります。リクエスト記録を使い、「接続先ドメイン → 一致したルール → ポリシーグループ → 実際の出口」の順に確認するほうが、ルールの記述だけを見るより確実です。
6. よくある質問とトラブル対処の仕上げ
遅延が表示されるのに、Webページが開かないのはなぜ？
まず Connectivity Test のテスト方式を確認してください。TCP接続の確立やテスト先からの応答で確認できるのは、通信経路の一部だけです。実際に失敗したWebサイトで再テストし、認証、DNS、ルールの適用状況を確認してください。遅延の数値だけで、すべてのWebサイトが使えると判断することはできません。
Webサイトが1つだけ開かない場合、サブスクリプションを再読み込みすべき？
まず同じサーバーでほかのWebページを開き、次にそのサイトで失敗したリクエストのドメインとポリシーを確認してください。Proxy では使えて Config では失敗する場合は、そのドメインのルールと関連リソースを優先して確認します。サブスクリプションを再読み込みしても、設定ファイル内のドメイン振り分けの誤りは通常修正されません。
接続を切っても自動で再接続する場合、直接接続テストはどうすればよい？
Settings → On Demand で該当する接続条件を一時的に無効にします。その後 Home に戻って接続をオフにし、状態を確認してください。比較テストが終わったら元の設定に戻します。On Demand による再接続を、手動で切り替えた設定が反映されなかったと誤解しないようにしてください。
サブスクリプションを更新したのに、元のサーバーが使えないのはなぜ？
更新によって一覧の内容が最新になるだけです。Home に戻り、実際に選択中の項目を確認して、そのアドレス、ポート、認証情報に変更がないか確認してください。一覧の内容が自身の有効なサービス情報と異なる場合は、すでに利用しているサービスの提供元に確認します。同じリンクを何度も読み込んで重複項目を作らないでください。
接続が回復したら、テストのためだけに変更した設定を元に戻します。普段使う Global Routing に戻し、Config で正しいファイルが選択されていることを確認し、必要な On Demand 条件も復元してください。その後、直接接続するWebページ、プロキシ経由で使うWebページ、以前失敗した具体的な機能を再テストします。ホームページだけ確認して、ログインや画像のリクエストを見落とさないようにしてください。
- 必要最小限の記録を残す：発生日時、ネットワークの種類、サーバーのプロトコル、Global Routing モード、失敗したドメイン、エラー全文。
- 効果のあった変更を記録：「同じサーバーで Proxy は成功、Config は失敗」のように記録し、「再接続したら直った」とだけ書かないでください。
- 機密情報を削除：記録を共有する前に、サブスクリプションの完全なURL、token、パスワード、UUID、キーを削除してください。原因を特定するためのエラー発生段階やルール情報は残します。