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

1. まず状況を記録し、テスト失敗とリクエスト失敗を切り分ける

Homeを開き、選択中のサーバーを確認してからConnectivity Testを実行します。テスト方式、表示結果、接続中のネットワークを記録してください。テスト方式を選べる場合は、TCPテストと実際のリクエストによる確認を分けて記録します。テスト結果が示すのは特定の方法で行った疎通確認であり、すべてのWebサイト、プロトコル、ネットワーク環境での接続状態ではありません。

TCPテストで確認できるのは、指定したアドレスとポートへのTCP接続です。ミリ秒単位の数値が表示されても、パスワードが正しいこと、TLS検証が成功すること、接続先のWebサイトにアクセスできることまでは確認できません。Hysteria2はUDPベースのQUICを使用し、WireGuardもUDPを使用します。TCPだけの疎通確認では、実際の通信を検証できません。

2. 複数の設定を同時に変えず、決まった順序で再テストする

まず、Shadowrocketの接続をオフにした状態で、iPhoneが現在のネットワークを利用できるか確認します。公共Wi-FiでWeb認証が必要な場合は、接続をオンにする前に認証を済ませてください。その後、以下の順に確認します。利用中のサブスクリプションやサーバー設定は、ご自身のサービス事業者から提供された情報を基準にしてください。

1. 変更前の状態を記録

   Homeで選択中のサーバー、Connectivity Testの結果、Global Routingの現在の設定を記録し、Wi-Fiかモバイル通信かも控えます。最初に設定をまとめて削除しないでください。

2. アドレスを確認

   Homeで対象サーバーの編集画面を開き、アドレスとポートを確認します。アドレス欄の前後に余分な空白が入っていないか確認してください。通常のサーバーアドレスにサブスクリプションURLを入力したり、独断でhttps://やパスを追加したりしないでください。

3. 設定項目を確認

   サービス事業者の情報を見ながら、Type、認証情報、TLS、通信方式の設定を一つずつ確認します。保存後に接続し直し、新しいWebリクエストを実行してください。以前の接続の結果を使って判断しないようにします。

4. ネットワークを切り替える

   設定を変えずにWi-Fiとモバイル通信を切り替えます。一方のネットワークだけでタイムアウトする場合は、その違いを記録してください。一時的に接続できたことを、パスワードが再確認された証拠とみなさないでください。

5. 時刻を確認

   iPhoneの「設定」→「一般」→「日付と時刻」を開き、「自動設定」と現在の日付、時刻、タイムゾーンを確認します。修正後に再接続し、同じHTTPSリクエストを再テストしてください。

3. アドレス、ポート、プロトコル設定を一つずつ確認する

Homeのサーバー編集画面を開き、まずプロトコルの種類がサービス事業者の指定と完全に一致していることを確認してから、各項目を照合します。ポートはサーバー側が指定する接続先です。ポートが443でも、HTTPSやTLSが利用できるとは限りません。よく使われるポートだからという理由で、元のポートを独断で変更しないでください。

TLSサーバー名と実際の接続先アドレスは異なる場合があります。接続先アドレスはリクエストの送信先を決め、サーバー名はTLSのネゴシエーションと証明書の識別に使われます。WebSocketではHostとPathもアプリケーション層のリクエストに関係します。それぞれ同じ値の場合もありますが、似ているからといって置き換えないでください。

• パスワードとUUID：コピー時に改行、引用符、末尾の空白が混入していないか確認します。認証情報の全文を公開の場に貼り付けないでください。
• Path：/connectはパスの形式を示す例にすぎません。実際の値はサーバー設定に従い、大文字・小文字や先頭のスラッシュも確認してください。
• アドレスとポート：ドメイン名を使う場合はDNSによる名前解決も必要です。IPアドレスへの変更は万能な解決策ではありません。特に、TLSサーバー名まで削除しないでください。
• サブスクリプションの更新：サービス事業者がサーバーアドレスや設定を変更する場合があります。独自に変更した内容を記録し、ご自身のサブスクリプションを更新した後、選択中の項目を再確認してください。古い設定を繰り返し使わないようにします。

4. エラーに応じて原因を絞り込み、すべての失敗を同じ方法で対処しない

接続失敗の前後に表示されたログを記録し、最初に現れたエラーと対象を確認します。以下はネットワークやTLSのログに表示されることがあるエラー例です。失敗のたびに同じ文言が表示されるとは限らず、ログの一行だけでサーバー側の障害と断定することもできません。

同じエラーが続いても、待ち時間を延ばすだけでは解決しません。まず、どの段階で失敗したかを確認します。サーバーのドメイン名を解決できない場合はアドレスとDNS、TLSネゴシエーションまで進んだ場合は時刻、サーバー名、証明書、認証に失敗した場合はプロトコル設定を確認してください。発生段階によって確認箇所は異なります。

5. 接続が確立している場合はGlobal RoutingとDNSを確認する

Home → Global Routingに戻り、現在の選択を記録します。Proxy、Direct、Config、Sceneはリクエストのルーティング方法に関係するもので、異なる接続プロトコルを指すものではありません。システムにVPN接続済みと表示されても、システムのトンネルが確立したことを示すだけです。すべてのリクエストが選択中のサーバーを経由して接続先に届いたとは限りません。

• Proxy：プロキシ経由の経路を比較するために使います。一時的に切り替えた後、リクエストを再試行してください。ローカルネットワーク上の機器へのアクセス方法が変わる場合があります。テスト後は元の設定に戻します。
• Direct：リクエストを直接接続します。このモードでWebページを開けても、サーバーの認証や転送が正常とは限りません。
• Config：現在選択中の設定に基づいてルールを適用します。Configで実際に有効なファイルを確認し、選択されていないファイルだけでなく、Ruleセクションも確認してください。
• Scene：設定済みのシーンに基づいてルーティング動作を決定します。トラブル対処では、シーンで実際に使われている設定も確認してください。固定のProxyやDirectとして扱うことはできません。

Configモードでは、Ruleセクションのルールが上から順に適用されます。先にあるDOMAIN-SUFFIX、IP-CIDR、GEOIPのルールがリクエストの経路を決める場合があります。FINALはそれ以前のルールに一致しないリクエストを処理するため、ルールの末尾に置きます。同じ接続先がProxyでは使えてConfigでは失敗する場合、すぐにパスワードを変えるのではなく、適用されたルールと対応するポリシーを確認してください。

6. 最後にシステム時刻を合わせ、確認内容を記録する

iPhoneの「設定」→「一般」→「日付と時刻」を開き、「自動設定」を確認します。日付、時刻、タイムゾーンに誤りがある場合は正しく設定し、端末の実際の時刻も確認してください。証明書の検証には時刻が使われます。タイムゾーンの表示を変えるだけでは、端末の時計は修正されません。VMessなど、時刻に関係する認証方式を使うプロトコルも、大きな時刻のずれによって影響を受ける場合があります。

時刻を正しく設定しても接続できない場合は、必要最小限の情報をまとめてサービス事業者に問い合わせます。発生時刻とタイムゾーン、ネットワークの種類、プロトコル、テスト方法、個人情報を伏せたエラーの一部、ネットワーク切り替え後の結果を記録してください。パスワード、秘密鍵、UUIDの全文、サブスクリプションURL全体は送らないでください。