Shadowrocketの接続タイムアウト・接続失敗の対処法｜遅延テスト、プロトコル設定、システム時刻の確認順

1. まず問題の範囲を確認し、状況を記録する

まず、サブスクリプションの更新失敗、ノードのテスト失敗、接続後に特定のWebページが開かない、の3つを区別します。それぞれ異なる段階で起きている可能性があります。サブスクリプションの更新では設定データを取得し、ノードテストでは選択した方法でテストを実行します。Webページへのアクセスには、ルーティング、DNS、プロトコルのハンドシェイク、接続先のWebサイトも関わります。「タイムアウト」という表示だけで、これらを同じ問題として扱わないでください。

開始前にHomeで、選択中のノード名、Global Routingの設定、エラーが出た操作を記録します。Configの既存設定は残し、ルールを先に消さないでください。Settings → On Demandが有効な場合は、その状態も記録します。手動で切断して比較する際は、既存の条件によって接続が再び開始されないことを確認してください。

1. ネットワークの基本状態を確認：一時的に接続を切り、現在のWi-Fiまたはモバイル通信で、普段直接アクセスできるページが開くか確認します。Wi-FiでWeb認証が必要な場合は、先に認証を完了してください。
2. テスト対象を固定：自分が利用しているノードを1つ選び、以降の確認とテストは同じノードで行います。設定の異なるノードの結果を混同しないようにしましょう。
3. 結果をそのまま記録：テストがタイムアウトしたのか、接続スイッチがオンの状態を維持できないのか、特定のアプリのリクエストだけが失敗するのかを記録し、エラー全文も保存します。
4. 変更は一度に1項目：変更後は同じ操作で再テストします。改善しなければ変更を元に戻してから、次の項目を確認してください。

2. 遅延テストの見方：数値が出ても接続できるとは限らない

結果を判断する前に、テスト方法を確認してください。TCPハンドシェイクで確認できるのは、主にアドレスとポートへの到達性です。プロキシプロトコルの認証全体を検証するものではありません。ノード経由のHTTPリクエストテストでは、テスト先自体を含む、より多くの要素が関係します。2つの方法で得られる時間の意味は異なるため、単純に比較したり、数値を通信速度とみなしたりしないでください。

Homeで同じノードに対して現在のテストを繰り返し、結果が安定しているか記録します。アプリで別のテスト方法を選択している場合は、その方法も記録してください。以下の3回という回数は、トラブル調査のための目安であり、アプリで定められた回数ではありません。継続的な失敗と一時的な揺らぎを区別するためのものです。

同じ設定でWi-Fiでは失敗し、モバイル通信では成功する場合、まずネットワーク経路やそのネットワークの制限が違いとして考えられますが、具体的な原因を特定できたとは限りません。どちらのネットワークでも失敗しても、サーバー停止と即断しないでください。アドレスの誤り、認証情報の期限切れ、DNSの名前解決エラー、プロトコルの不一致をそれぞれ確認する必要があります。

3. アドレス、ポート、プロトコル設定を照合し、推測で値を置き換えない

Homeから現在のノードの編集画面を開き、利用中のサービスが提供した元の設定と項目ごとに照合します。まずタイプが一致しているか、次にアドレスとポート、最後に認証、TLS、トランスポート関連の項目を確認します。サブスクリプションの読み込みに成功したことは、クライアントがデータを取得して解析できたことを示すだけで、すべてのノードで接続できることを意味しません。

ドメイン名を使う場合は、名前解決で取得したアドレスが正しいかも確認してください。名前解決を回避するためにドメイン名を安易にIPアドレスへ置き換えないでください。サーバー側で選ばれる接続先が変わり、TLSのホスト名検証にも影響する可能性があります。WebSocketを使う設定では、パス、Host、TLSのSNIはそれぞれ役割が異なります。どれもドメイン名のように見えるからといって、相互に置き換えないでください。

• パスワード、UUID、鍵をコピーする際は、前後の空白、改行、文字列の欠落がないか確認してください。スクリーンショットから文字を推測して入力しないでください。
• 利用中のサービスから設定変更の連絡があった場合は、既存の設定を残したうえで、該当するサブスクリプションを更新します。更新後、実際に選択されているノードを再確認してください。
• サブスクリプションの更新に失敗した場合は、リンクが有効で、現在のネットワークからアクセスできるかを先に確認します。唯一の利用可能な設定を先に削除しないでください。
• TLSエラーを隠すために証明書の検証を無効にしないでください。まずシステム時刻、SNI、証明書の状態を確認します。

4. iPhoneのシステム時刻を確認してからTLSエラーを調べる

iPhoneの日付、時刻、タイムゾーンが大きくずれていると、証明書の有効期間の判定や、時刻検証が必要な認証に影響することがあります。証明書には有効開始日時と有効期限があります。デバイスの時計が大きくずれている場合、アドレスやパスワードが正しくても、ハンドシェイクで失敗する可能性があります。すべてのタイムアウトに共通する原因ではありませんが、確認しやすく、先に調べておきたい項目です。

1. iPhoneの「設定」→「一般」→「日付と時刻」を開き、「自動設定」がオンになっているか確認します。
2. 表示されている日付、現地時刻、タイムゾーンが適切か確認してください。スイッチを変更できない場合は、デバイス管理や機能制限を確認し、管理設定をむやみに削除しないでください。
3. Shadowrocketに戻り、接続を切ってから同じノードに再接続し、同じテストを実行します。
4. TLS関連のエラーが続く場合は、エラー全文と発生時刻を利用中のサービスに伝え、サーバー証明書、証明書チェーン、ドメイン設定を確認してもらってください。

システム時刻が正しいことは確認項目の1つにすぎず、証明書の期限切れ、証明書名の不一致、サーバー設定の異常を自動的に解決するものではありません。以下に、よくあるネットワークエラーの文面から考えられる確認箇所を示します。該当する文面が実際のログにある場合のみ、その項目を参考にしてください。具体的な表現は、システムや失敗した段階によって異なることがあります。

5. 接続後も開けない場合：Global Routingとルールの適用先を確認

接続スイッチがオンでも、すべてのリクエストが現在のノードを経由するとは限りません。Home → Global Routingで全体のルーティング方式を設定します。Proxyはプロキシ経由、Directは直接接続、Configは現在の設定に基づく処理、Sceneは設定済みのシーンに応じたルーティング方式を選択します。調査では現在の設定を記録し、ノード名だけを確認して終わらせないでください。

ルールの影響を切り分ける必要がある場合は、テスト範囲を確認したうえで、一時的にProxyを選び、同じ接続先へリクエストを送信してから元の設定に戻します。この操作中は他のリクエストのルーティングも変わるため、影響を理解したうえで実施してください。Proxyでは成功しConfigでは失敗する場合は、Configで有効になっている設定と、リクエストに実際に適用されたポリシーを確認します。パスワードを変更し続ける必要はありません。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
IP-CIDR,192.0.2.0/24,DIRECT
FINAL,PROXY

ここではマッチング順序のみを説明します。完全な設定ではありません。DOMAIN-SUFFIXはドメインのサフィックス、GEOIPはIPアドレスの地理的な所属、IP-CIDRはアドレス範囲に基づいて照合します。FINALは、それまでのルールに一致しなかったリクエストを処理します。ルールは上から順に判定されます。例にある192.0.2.0/24はドキュメント用のアドレス範囲であり、実際の通信ルートを変更する根拠にはなりません。使用時は、ポリシー名が自分の設定内で有効かどうかも確認してください。

• 特定のドメインだけ失敗する：そのリクエストのドメイン名、名前解決の結果、適用されたポリシーを照合し、接続先Webサイト自体の問題も切り分けます。
• ノード経由のリクエストがすべて失敗する：プロトコル設定とハンドシェイクの確認に戻り、ルールの変更範囲をむやみに広げないでください。
• Webページは開けるが特定のサービスだけ失敗する：そのサービスがUDP、追加のドメイン名、別のポートに依存していないか確認してください。通常のWebページのテストだけでは、すべての通信条件を確認できません。

6. よくある質問とトラブル記録のまとめ方

問題を問い合わせる際は、単に「使えない」と伝えるより、失敗した段階を特定できる情報を提供すると効果的です。以下の順に記録をまとめてください。ノード名は必要に応じて匿名化できます。認証情報はトラブル調査のために公開する情報ではありません。

• 環境：デバイスの種類、システム情報、Wi-Fiまたはモバイル通信、問題が発生し始めた現地時刻とタイムゾーン。
• テスト：テスト方法、同じノードでの3回分の結果、ネットワークを切り替えた際の変化。
• 設定：プロトコルの種類、ポート、現在のGlobal Routing設定、On Demandの有効・無効。
• 症状：エラー全文、失敗した手順、すべてのリクエストが失敗するのか、特定の接続先だけなのか。
• プライバシー：サブスクリプションリンク内のtoken、パスワード、UUID、秘密鍵などの認証情報を隠し、設定全体を公開しないでください。

この順序で確認すれば、問題をネットワークの基本状態、サーバーへの到達性、プロトコルのハンドシェイク、デバイスの時刻、リクエストのルーティングのいずれかに絞り込めます。問題がある段階を特定してから対応する設定を変更し、再テストに成功したら一時的な変更を元に戻してください。診断用のルーティング設定を普段の設定として残さないようにしましょう。