Shadowrocketの接続スイッチをオンにすると、システムのトンネルは有効になります。ただし、サーバーや名前解決、接続先のWebサイトがすべて利用可能になったことを示すわけではありません。利用中のサービスやサブスクリプションがあることを前提に、サーバー、Global Routing、DNS、ルールの順で原因を絞り込みます。変更は一度に一つだけ行い、同じ接続先で再テストしたら、最後に元の振り分け設定へ戻してください。
確認を始める前に：トンネル・サーバー・Webリクエストを切り分ける
最初からアプリを削除したり、設定をすべて作り直したりする必要はありません。VPNの表示、サーバーの遅延、Webページの読み込みは、それぞれ異なる段階を示します。システムがVPN設定を受け入れても、リモートサーバーとのプロトコル認証が完了したとは限りません。遅延テストに応答があっても、Webページで使われるドメイン、ポート、ルールの経路が正しいとは限りません。まず症状を確認し、どの設定を調べるか判断しましょう。
この流れは確認箇所を特定するためのもので、すべての接続でルール判定前にDNS解決が必要という意味ではありません。ドメインルールはホスト名で直接判定できる一方、IPルールでは名前解決の結果が関係する場合があります。ここではiPhone / iPadの画面を例に説明します。作業前に、Homeで選択中のサーバー、Global Routingの値、Configで使用中の設定ファイルを控えておきましょう。
- 接続スイッチをオフにし、通常は現在のネットワークから直接アクセスできるWebサイトを開いてみます。それでも開けない場合は、Wi-Fiのログイン、モバイルデータ通信の許可、基本的なネットワーク障害を先に確認してください。
- 実際にプロキシ経由でアクセスしたい接続先を一つ選び、毎回同じアドレスでテストします。異なるWebサイトの結果を、変更前後の比較に使わないでください。
- 現在の設定のコピーを残してください。スクリーンショットやメモは自分で見返すために使えますが、他の人に相談するときはサブスクリプションURL、認証情報、鍵を隠してください。
ステップ1：選択中のサーバーが実際に使えるか確認する
Homeを開き、選択中の丸印がテストしたいサーバーに付いていることを確認します。サブスクリプションのグループを展開しただけでは、サーバーが選択されたことにならない場合があります。接続スイッチをオンにしてConnectivity Testを実行し、テストが完了したか、どのようなメッセージが表示されたかを記録してください。このテストで分かるのは、そのときのテスト対象への接続状況だけです。すべてのWebサイトを確認できるわけではなく、DNSやルールが正しいことを単独で証明するものでもありません。
-
選択中の項目を確認する
Homeで丸印の位置とサーバー名を確認します。設定でポリシーグループを使用している場合は、グループ内で実際に選択されている項目も確認してください。Homeの既定の選択が、設定ファイルに指定された固定ポリシーに適用されるとは限りません。
-
接続テストを実行する
HomeでConnectivity Testを実行した後、同じテスト用アドレスにアクセスします。テストとWebページの結果をそれぞれ記録し、遅延の数値だけをWebページにアクセスできた証拠とみなさないようにしましょう。
-
接続設定の項目を確認する
対象サーバーの編集画面を開き、Type、アドレス、ポート、認証情報を元の設定と照合します。TrojanやVLESSなどでは、TLSや転送方式のパラメーターも元の設定に合わせて確認してください。サーバー名だけでTypeを判断することはできません。
-
既存のサブスクリプションを更新する
Homeで対象のサブスクリプションを更新し、更新が成功したことを確認してから項目を選択してテストします。更新に失敗した場合は現在の設定を残し、利用中のサービス提供元にサブスクリプションが有効か確認してください。何度も削除して追加し直すのは避けましょう。
ポートには、利用中の設定に記載された値を入力してください。すべてを443に変更してはいけません。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuardでは認証や転送の項目が異なります。Typeを変更しても設定内容は自動変換されません。サーバー側がUDPを必要とし、現在のネットワークでUDPが制限されている場合、ポートを一つ変更しただけで解決したとは判断できません。
ログのキーワード：connection refused
原因と対処：通常は接続先または中間の機器に接続を明示的に拒否されたことを示します。ポートで待ち受けていない、またはアクセスが拒否されている可能性があります。まずサーバーのアドレスとポートを確認し、該当サービスの稼働状況を利用中のサービス提供元に問い合わせてください。
ログのキーワード：i/o timeout
原因と対処：I/O処理が制限時間内に完了しなかったことを示します。これだけでアカウントが無効だとは判断できません。ログに記録された接続先を確認し、タイムアウトがサーバー側か接続先のWebサイト側かを切り分け、別のネットワークでも再テストしてください。
上記はネットワークログに表示される場合がある原文のキーワードです。すべての障害でこれらのメッセージが出るわけではありません。実際に端末に記録された内容を確認し、記事の例をもとに診断結果を書き足さないでください。
ステップ2：Global Routingで振り分けの問題を切り分ける
Home → Global Routingを開き、まず現在の値を確認してから一時的に比較します。Proxy、Direct、Config、Sceneはサーバー名ではなく、通信経路の選択方法を決めるモードです。Direct自体が問題というわけではありません。直接接続できる接続先なら正常に使えるはずです。プロキシが必要な接続先でDirectのままなら、アクセス要件と合っていない可能性があります。
- Proxy：プロキシ経由の通信を一時的に確認するときに使います。同じ接続先がProxyでは開き、Configでは失敗する場合、サーバーの認証情報をすぐに変更するのではなく、ルールとポリシーの選択を優先して確認してください。
- Direct：直接接続する経路との比較に使います。トンネルをオフにするとアクセスできるのに、オンにしてDirectにしても失敗する場合は、トンネル内のDNS、ネットワーク設定、接続記録をさらに確認してください。
- Config：現在の設定に従って通信を振り分けます。Configで有効になっているファイルがどれかも確認してください。Global Routingの項目だけを確認しても不十分です。
- Scene：設定済みのシーン条件と、対応する動作に従います。切り分けの際は現在のシーンを記録し、一時的にProxyまたはConfigへ切り替えて比較してください。条件の変化が判断に影響するのを防げます。
ステップ3：DNSの名前解決失敗と接続失敗を切り分ける
DNSはドメイン名を接続可能なアドレスに変換します。接続記録で接続先のアドレスを取得する前にエラーが出た場合は、まず名前解決を確認してください。アドレス取得後に接続がタイムアウトする場合は、接続先への到達性、サーバーの外向き通信、ルールを続けて確認します。ブラウザーの「ページを開けません」という表示だけでは、どちらの問題か判断できません。
ログのキーワード：no such host
原因と対処：通常はドメイン名の名前解決で利用可能な結果が得られなかったことを示します。アドレスの入力ミスが原因の場合もあります。エラーに記録されたドメインが、サーバー、DNSサービス、接続先Webサイトのどれに該当するか確認し、対応するアドレスと名前解決の経路を調べてください。
- 接続に失敗したら、すぐに接続記録またはログを開き、同じ時間帯に記録された同じドメインの項目を探します。別のアプリがバックグラウンドで送信したリクエストを、現在のテストの結果として扱わないでください。
- SettingsでDNS関連の設定を確認すると同時に、Configで使用中の設定に
[General]内のdns-serverや、[Host]の静的マッピングが含まれていないか確認してください。設定ファイルに指定された値が、問題の原因を特定する手がかりになる場合があります。 - カスタムDNSを追加したばかりの場合は、元の値を記録してから、変更前に使えていた設定に戻します。DNS、サーバー、ルーティングモードを同時に変更すると、どの変更が影響したのか判断できません。
- 暗号化DNSを使用している場合は、DNSサービスのドメイン、ネットワーク経路、TLS接続も確立できることを確認してください。暗号化DNSを使っているからといって、DNSサービスに必ず到達できるわけではありません。
「WebサイトのIPアドレスを直接入力すると開く」ことを、汎用的なDNSテストとみなさないでください。HTTPSの証明書検証やSNIにはドメイン名が必要です。また、多くのWebサイトは共有アドレスやCDNを利用しています。IPアドレスでアクセスできなくても、そのIPに接続できないとは限りません。ドメイン名を迂回して結論を出すのではなく、ログに記録された名前解決の結果と接続段階を確認してください。
ステップ4：ルールの順序・一致結果・通信経路を確認する
サーバーとDNSを確認したら、Configで現在有効なファイルの[Rule]を開きます。ルールは通常、上から順に照合されます。上位の広い条件が、その下にある具体的なルールより先に一致する場合があります。失敗したリクエストの接続記録を確認し、接続先のドメインまたはIP、一致したルール、実際に選択されたポリシーを照合してください。ルールファイルに「そのドメインが記載されている」ことを確認するだけでは不十分です。
[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,example.com,PROXY：指定したドメインとそのサブドメインに一致します。Webページが複数のリソース用ドメインを使っている場合、メインのドメインを追加しただけでは、すべてのリソースが同じ経路を通るとは限りません。IP-CIDR,192.168.0.0/16,DIRECT,no-resolve：例示されたプライベートアドレス範囲に一致します。no-resolveは、このIPルールのために追加のドメイン解決を行わないという意味で、すべてのDNSを無効にする設定ではありません。GEOIP,CN,DIRECT：IPの地理情報データベースの結果に基づいて判定します。Webページの言語やドメインの末尾で判断するものではありません。名前解決の結果とデータベースの内容が、一致するかどうかに影響します。FINAL,PROXY：それ以前のルールに一致しなかった接続を処理します。実際の設定がFINAL,DIRECTの場合、個別ルールに一致しない接続先は直接接続になる可能性があります。一律に特定の値へ変更するのではなく、元の振り分け方針に照らして判断してください。
改善しない場合：症状ごとに原因を絞り込む
4つの確認を終えても接続できない場合は、「基本ネットワークの状態、現在のサーバー、Global Routingの値、失敗したドメイン、ログのキーワード」の5項目を整理します。共有する前に機密情報を削除してください。特定のネットワークでだけ失敗する場合は、まずネットワーク環境を比較します。どのネットワークでも失敗し、設定項目も一致している場合は、利用中のサービス提供元にサービスの状態を確認してください。
遅延の数値が表示されるのに、Webページを開けないのはなぜですか？
遅延テストとWebリクエストでは、接続先や経路が異なる場合があります。まずConnectivity Testを実行し、同じWebページをProxyとConfigで比較してください。Configでだけ失敗する場合は、そのページへのリクエストに適用されるルールと実際の通信経路を確認します。
Wi-Fiではつながらず、モバイルデータ通信では使える場合、まず何を確認すればよいですか？
サーバー、設定、接続先のアドレスは変えず、ネットワークだけ切り替えて再テストします。まずWi-FiでWebログインが必要かを確認し、その後、必要な通信方式が制限されていないか調べてください。DNSとプロトコルを同時に変更すると比較できなくなるため、避けましょう。
手動で切断しても自動で再接続される場合は、どうすればよいですか？
Settings → On Demandを開き、現在のオンデマンド接続設定を記録します。切り分け中は一時的にオフにしてからテストしてください。On Demandは接続を自動で確立する条件を制御する機能です。無効なサーバー認証や誤ったルールを修復するものではありません。確認後は、元の用途に合わせて設定を戻してください。
サブスクリプションを更新しても接続できません。再インストールが必要ですか？
まずサブスクリプションの更新が成功したことと、Homeで更新後の項目が選択されていることを確認します。次にConfigで固定サーバーやポリシーグループが古い項目を参照していないか調べてください。サーバーのサブスクリプション更新とルール設定の更新は別の操作です。再インストールを最初に試す必要はありません。