Shadowrocketの接続タイムアウト・接続失敗の対処法｜遅延テスト・設定・システム時刻

この記事の概要

利用中のサービスの契約があり、Shadowrocketで接続タイムアウトや接続失敗が起きている方向けの記事です。ネットワーク、Connectivity Test、プロトコル設定、システム時刻、実際のリクエストの順に確認し、ポートへの到達不可、認証失敗、ルールの経路設定を切り分けます。一度に変更する条件は一つにし、後から確認できるよう結果を記録しましょう。

1. まず、どの段階で失敗しているか確認する

Homeで接続スイッチをオンにしても、接続先での認証が完了したとは限らず、Webリクエストが必ずその接続先を経由するとも限りません。システムはまずローカルのVPNトンネルを確立し、その後、個々のリクエストに応じて接続先への接続を開始する場合があります。そのため、「VPNの表示が出ている」「ノードに遅延時間が表示されている」「Webサイトにアクセスできる」は、それぞれ別の確認結果です。

始める前に、Wi-Fiとモバイル通信のどちらを使用しているか、選択中のノード、Global Routingの設定、失敗した時刻を記録してください。サブスクリプションを削除したり、すべての設定をリセットしたり、複数の項目を同時に変更したりするのは避けましょう。どの操作で結果が変わったのか判断しにくくなります。次の表は状況を見分けるための目安であり、特定の接続先を実測した結果ではありません。

確認できた症状	考えられること	次に行うこと
Shadowrocketを切断しても、通常のWebサイトが開けない	ローカルネットワークが正常にインターネットへ接続できていない可能性があります	Wi-Fiのログイン認証を完了するか、モバイル通信に切り替えて確認する
TCPテストに数値が表示されるが、実際のリクエストは失敗する	接続先ポートに到達できても、認証やTLSの成功までは確認できません	パスワード、UUID、SNI、通信方式の設定を確認する
テストはタイムアウトするが、Webサイトは正常に開ける	テスト方法やテスト先が、実際の通信と異なる可能性があります	テスト方法と、Webリクエストに適用されたルールを確認する
Wi-Fiでは失敗するが、モバイル通信では正常に動作する	現在のネットワーク経路に原因がある可能性が高いです	Wi-Fiの認証、DNS、ネットワークのアクセス制限を確認する
利用中のノードのうち1つだけ失敗し、ほかは使える	クライアント全体の問題と決めつけないでください	該当ノードの設定を確認し、契約中のサービス提供元に状態を問い合わせる

ポイント：再現可能な比較条件を一つ用意する

失敗するノードとテスト先を一つずつ選び、設定は変えずにWi-Fiとモバイル通信で1回ずつテストします。ネットワークを切り替えると結果が変わる場合は、まずネットワーク経路を確認しましょう。どちらでも失敗する場合は、次に設定を確認します。

2. 決まった手順で遅延と接続をテストする

遅延テストで分かるのは、特定のテスト条件における結果だけです。TCPテストは主にTCP接続の確立を確認するもので、ミリ秒の数値が表示されても、プロトコル認証や実際のリクエストの成功を保証するものではありません。UDPを使う接続では、TCPテストの結果だけで判断することは特に避けてください。異なるテスト方法で得た数値を、そのまま比較して順位づけしないようにしましょう。

ローカルネットワークを確認する

Homeで接続スイッチをオフにし、Safariで普段から直接アクセスできるWebサイトを開きます。Wi-FiでWebログインが必要な場合は、先に認証を完了してください。それでも接続できない場合は、ノードのパスワードを変更する前に、端末のネットワーク接続を確認します。
テストするノードを選ぶ

Homeに戻り、確認するノードを選択して、名前とプロトコルを記録します。リスト内のノードの遅延だけを見て、実際の接続時には別のノードを選んだままにしないよう注意してください。
接続テストを実行する

HomeでConnectivity Testを実行し、選択したテスト方法、結果、ネットワークの種類を記録します。同じ方法で3回繰り返し、最速の結果だけでなく、毎回の結果を残してください。
ルールの影響を切り分ける

一時的にHome → Global RoutingをProxyに切り替え、テスト対象のノードが選択されていることを確認します。次に接続スイッチをオンにして、同じWebサイトへリクエストします。テスト後は元のConfigまたはSceneに戻し、切り分け用の設定を常用しないようにしてください。
ネットワークを変えて再テストする

ノード、テスト方法、テスト先を変えずに、利用可能な別のネットワークへ切り替えてテストを繰り返します。自動再接続を確認する場合は、先にSettings → On Demandでオンデマンド接続を一時停止し、テスト後に元の設定へ戻してください。

Proxyではリクエストが成功し、Configに戻すと失敗する場合は、プロトコル設定を変更し続けるのではなく、Configのルール、ポリシーの割り当て、DNSを優先して確認します。Global RoutingがDirectの場合、リクエストは直接接続されるため、プロキシノードが正常に動作している証拠にはなりません。Sceneを使用している場合は、現在のシーンで実際にどのルーティング設定が適用されているかを確認してください。

3. プロトコル設定と契約内容を一つずつ照合する

ノード名は識別用のラベルです。同じ名前でも、アドレス、ポート、認証情報が変更されている場合があります。Homeで対象ノードの編集画面を開き、契約中のサービス提供元から入手した最新情報と照合してください。すでにサブスクリプションを利用している場合は、まず更新してから確認します。Web上の記事を参考に、パスワード、UUID、通信パスを推測して入力しないでください。

項目	確認する内容	よくある誤解
Address / Port	アドレスにWebページのパスが含まれていないこと、ポートがサービス提供元の案内と一致していること	TLSを見て元のポートを443に変更すること。443はよく使われるポートですが、必須ではありません
Shadowsocks	暗号化方式、パスワード、サービス提供元が指定するプラグイン設定も確認する	パスワードが正しければ、ほかの項目もすべて正しいと思い込むこと
VMess / VLESS	UUID、TLSの有効・無効、通信方式を確認する。WebSocketを使う場合はHostとPathも確認する	WebSocketのHost、TLSのSNI、接続先アドレスは必ず同じだと思い込むこと
Trojan	パスワード、SNI、ポート、証明書の検証条件を確認する	サーバー名の誤りを直さず、証明書の検証を無効にして回避すること
Hysteria2	認証情報とTLS設定を確認し、現在のネットワークで必要なUDP通信が許可されていることを確認する	TCPテストが成功すれば、UDP経路も正常だと判断すること
WireGuard	鍵、Endpoint、トンネルアドレス、Allowed IPsを確認する	Endpointだけを確認し、トンネル内のアドレスやルーティング範囲を見落とすこと

SNIはTLSハンドシェイクでサーバー名を示すための情報です。証明書の検証では、名前、信頼チェーン、有効期限も確認する必要があります。接続先がIPアドレスだからといって、SNIにもそのIPアドレスを入力すべきとは限りません。サービス提供元から個別にドメイン名が指定されている場合は、その案内に従って入力してください。Allow Insecureを通常の解決策として使うのは避けましょう。

4. エラーメッセージから次の確認項目を絞り込む

「タイムアウト」は、制限時間内に特定の処理が完了しなかったことを示すもので、原因を直接示すものではありません。ログに次の英語の文言がある場合は、記載した観点で原因を絞り込めます。実際の表現は、プロトコル、基盤となる接続ライブラリ、失敗した段階によって異なる場合があります。前後の状況も含めて記録し、認証情報は隠してください。最後の単語だけを切り取らないようにしましょう。

エラー：i/o timeout

原因と対処：読み書きの処理が制限時間内に完了しなかった状態です。パケットロス、通信の遮断、接続先から応答がないといった原因が考えられます。まず同じノードを別のネットワークでテストし、次にアドレスとポートを確認してください。このエラーだけでパスワードの誤りと判断することはできません。

エラー：connection refused

原因と対処：接続先または中間の機器が接続を明示的に拒否しています。ポートでサービスが待ち受けていない場合や、拒否するポリシーが設定されている場合によく見られます。サブスクリプションに記載されたPortを確認し、そのポートのサービス状態を契約中のサービス提供元に問い合わせてください。適当なポートを一つずつ試すのは避けましょう。

エラー：TLS handshake timeout

原因と対処：TLSハンドシェイクが制限時間内に完了していません。ネットワーク経路、TLS設定、サーバーの応答などが原因として考えられます。まずSNI、TLSの有効・無効、ポートを確認し、次に別のネットワークでも比較してください。このエラーだけで証明書の有効期限切れとは判断できません。

エラー：certificate has expired or is not yet valid

原因と対処：証明書の有効期間の検証に失敗しています。端末時刻のずれや、サーバー側の証明書に問題がある可能性があります。まずiPhoneの時刻を正確に合わせて再試行してください。時刻が正しいのに失敗する場合は、契約中のサービス提供元に証明書の有効期間を確認してもらいましょう。

特定のWebサイトを開いたときだけエラーが出る場合は、「プロキシサーバーへの接続」と「プロキシサーバーからWebサイトへの接続」を区別してください。同じTLSエラーでも、発生した接続段階が異なる場合があります。エラーに記載された接続先ホスト、ポート、発生時刻を照合し、Webサイト側の証明書の問題をノード自体の問題と取り違えないようにしましょう。

5. iPhoneのシステム時刻と自動再接続を確認する

TLS証明書には有効期間があり、一部のプロトコル認証も時刻に関係します。端末の時計が大きくずれていると、ネットワークやパスワードに問題がなくても接続に失敗することがあります。表示するタイムゾーンを変更しても、実際の時計が正確になるとは限りません。システムの日付と時刻を正しく設定してから、新しい接続を確立してください。

iPhoneの「設定 → 一般 → 日付と時刻」を開き、「自動設定」を確認します。現在の日付、時刻、タイムゾーンが正しいことを確かめてください。デバイス管理などの制限で変更できない場合は、まず制限の原因を確認しましょう。
Shadowrocket → Homeに戻り、接続をオフにしてから再度オンにします。その後、同じノードとテスト先で確認してください。時刻を変更したあと、前回のテストで残った数値だけを確認して終わらせないようにしましょう。
接続をオフにしてすぐ自動的に再接続する場合は、Settings → On Demandを確認してください。手動テストの結果を明確にするには、一時的に無効にし、終了後に普段の設定へ戻します。
特定のノードだけ証明書の有効期間エラーが続き、ほかの利用中のノードは正常な場合は、失敗した時刻とエラーの一部を記録し、契約中のサービス提供元にサーバー時刻と証明書チェーンを確認してもらいましょう。

On Demandは、条件を満たしたときに接続を開始する機能です。接続先のパスワード、期限切れの証明書、到達できないポートを修復するものではありません。トラブルの切り分け中に一時的にオフにするのは、接続状態が自動で変わることによる影響を減らすためです。普段から無効にしておく必要があるという意味ではありません。

6. よくある質問と問い合わせ用の記録

遅延の数値が出るのに、なぜWebサイトを開けないのですか？

まずConnectivity Testの方法を確認し、次にHome → Global Routingで一時的にProxyを選び、テスト対象のノードから同じサイトへアクセスします。TCP接続を確立できても、プロトコル認証、TLS、接続先へのアクセスに失敗する場合があります。Proxyでは正常でConfigでは失敗する場合は、ルールとポリシーを確認してください。

すべてのノードがタイムアウトします。アプリを買い直す必要がありますか？

まず接続をオフにして通常のWebサイトが開くか確認し、Wi-Fiとモバイル通信を切り替えて再テストしてください。アプリの購入状態だけでは、接続先サービスの状態は判断できません。アプリの買い切りと、接続サービスの契約は別のものです。利用中のサブスクリプションが有効かどうかは、契約中のサービス提供元に確認してください。

サブスクリプションの更新に成功したのに、以前のノードで接続できないのはなぜですか？

Homeで更新後の項目を確認し、テストするノードが選択されていることを確かめます。現在のAddress、Port、認証設定が最新の案内と一致しているか確認してください。サブスクリプションのリソースにアクセスできることと、ノードのサービスが使えることは別です。設定の確認をせず、削除と再追加を繰り返すのは避けましょう。

契約中のサービス提供元に問い合わせるとき、何を伝えればよいですか？

失敗した時刻とタイムゾーン、Wi-Fiまたはモバイル通信の別、プロトコルの種類、テスト方法、3回連続の結果、機密情報を隠したエラーの一部を伝えてください。別のネットワークで使えるかどうかも記載します。サブスクリプションリンク全体、パスワード、UUID、秘密鍵は送らないでください。

確認が終わったら、Global RoutingとOn Demandを元の設定に戻し、普段使うWebサイトにアクセスできるか再確認してください。「接続中」と表示されたスクリーンショットより、条件を一つずつ変えて安定して再現できる比較結果のほうが、原因の特定に役立ちます。端末時刻、設定、ローカルネットワークを確認しても、同じノードが異なるネットワークで接続できない場合は、記録を契約中のサービス提供元に伝え、サーバー側の状態を確認してもらいましょう。