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

この記事の概要

この記事では、Shadowrocketに登録済みの接続項目でタイムアウトやハンドシェイク失敗が起きる場合、また接続後に通信できない場合の確認手順を説明します。利用者自身がサービス提供元とサブスクリプションを用意していることが前提です。ネットワークの基本状態、テストの種類、サーバー設定、システム時刻、ルーティングを順に確認し、一度に変更する設定は一つだけにします。最後に同じ接続先で再テストしてください。以下のメニュー操作はiPhone / iPadの画面を基準にしています。ほかのプラットフォームでは、システムの許可設定やメニューの場所が異なる場合があります。

1. まずタイムアウトが発生する段階を切り分ける

Homeでテストがタイムアウトしても、サーバーがオフラインだとは限りません。通信には通常、システムトンネル、ルール判定、名前解決、プロキシ接続、接続先からの応答が関わります。どの段階でも所定の時間内に完了しなければ、待機後に失敗することがあります。「テストの失敗」なのか「実際のWebページの表示失敗」なのかを記録し、設定をすべて削除するのは避けてください。

ローカルネットワーク名前解決ポート接続プロトコルのハンドシェイク接続先からの応答

同じデバイスでShadowrocketの接続を一時停止し、普段直接接続できるWebサイトを開いてください。この状態でも接続できない場合は、Wi-Fiの認証、モバイルデータ通信の許可、またはネットワーク自体の問題を先に確認します。公衆Wi-FiのWeb認証が済んでいない場合、接続先を何度も変えても通常は解決しません。

すべての接続項目で失敗する：まず現在のネットワーク、システム時刻、サブスクリプションの有効性、共通する名前解決の問題を確認します。
一つの接続項目だけ失敗する：その項目のアドレス、ポート、プロトコルの設定を確認し、該当サービスの稼働状況をサービス提供元に問い合わせます。
テストに数値が表示されるのにWebサイトを開けない：Global Routing、実際に適用されたアクション、DNS、接続先のサイトを確認します。遅延の数値だけで通信全体が正常だとは判断できません。
アプリを前面に表示している間は使えるが、ネットワーク切り替え後に失敗する：Wi-Fiとモバイルデータ通信での違いを記録し、Settings → On Demandの自動接続条件が再テストに影響していないか確認します。

2. 条件をそろえて遅延とWebアクセスをテストする

テストの種類によって確認できる範囲は異なります。TCP接続テストで確認できるのは、通常、指定したアドレスとポートに接続できることまでです。認証情報の正しさ、TLSハンドシェイクの成功、Webページへのアクセス可否までは確認できません。HomeのConnectivity Testも、選択したテスト方式と接続先を踏まえて結果を判断してください。異なる方式で測定した数値をそのまま比較することはできません。

現在の状態を記録する

現在の接続項目名、テスト方式、Global Routingの状態、失敗時刻を記録し、Configに現在の設定のコピーを保存します。結果を撮影・転記する際は、認証情報とサブスクリプションURLを隠してください。
接続項目を固定する

Homeで登録済みの接続項目を一つ選び、テスト中に自動選択の設定で接続先が切り替わらないようにします。Wi-Fiとモバイルデータ通信のどちらを使っているかも記録してください。
テストを繰り返す

同じConnectivity Testを3回連続で実行し、成功・失敗と表示された所要時間をそれぞれ記録します。一度だけ成功しても、問題が解消したとは判断しないでください。
接続先にアクセスする

接続スイッチをオンにして、ブラウザーで同じHTTPSページを開きます。「テスト結果が表示されたこと」と「ページを実際に開けたこと」は分けて記録してください。
ネットワークを切り替える

接続項目と接続先は変えず、Wi-Fiとモバイルデータ通信を切り替えて、上記のテストを繰り返します。モバイルデータ通信では通信料が発生する場合があるため注意してください。

判断のポイント：ネットワークと接続項目のどちらに差があるか

同じ接続項目が特定のネットワークでのみ失敗する場合は、そのネットワークの名前解決や通信制限を確認します。異なるネットワークでも同じ接続項目だけ失敗する場合は、アドレス、ポート、プロトコル設定を確認してください。すべての設定を手当たり次第に変更する必要はありません。

3. アドレス・ポート・プロトコル設定を項目ごとに確認する

Homeで該当する接続項目の編集画面を開き、サービス提供元から案内された元の設定と一つずつ照合します。サーバーアドレス欄にはホスト名またはIPアドレスを入力し、Webページのパス、空白、プロトコルの接頭辞を含めないでください。ポートには指定された数値を入力します。たとえば指定ポートが443の場合、一般的な例で8443が使われているからといって置き換えてはいけません。ポート番号だけで使用プロトコルを判断することもできません。

プロトコルまたはレイヤー	確認する項目	見落としやすい違い
Shadowsocks	アドレス、ポート、Password、暗号化方式	暗号化方式はサーバー側の設定と一致させる必要があります。パスワードが正しくても、方式が異なれば接続できません。
VMess / VLESS	UUID、トランスポート方式、TLS、サーバー指定の追加パラメーター	UUIDだけをコピーしても不十分です。WebSocketのパスやHostなどの項目も元の設定どおりに入力してください。
Trojan	Password、TLS、Server Name	接続先アドレスと証明書に対応する名前が異なる場合があります。サーバー側で指定された名前をそのまま使用してください。
Hysteria2	認証情報、TLS、サーバー指定のポートと追加設定	UDP通信を使用するため、TCPポートの確認結果だけでは実際のプロトコルで通信できるか判断できません。
WireGuard	鍵、Peerの公開鍵、Endpoint、トンネルアドレス、ルーティング範囲	ハンドシェイクとデータの送受信を確認してください。パスワード方式のプロキシと同じ項目で切り分けることはできません。

TLSを使用する接続では、サーバーアドレス、Server Name、HTTP Hostを区別してください。それぞれ異なるレイヤーの設定で、いずれもドメイン名のように見えるからといって相互に置き換えることはできません。WebSocketのパスは大文字と小文字を区別する場合があります。先頭のスラッシュが抜けていたり、余分な空白が入っていたりしても接続に失敗することがあります。

4. エラーメッセージから原因を絞り込み、システム時刻を確認する

ログに記録されたエラーは、「接続できない」という状況説明より原因の特定に役立ちます。以下は表示される可能性がある低レベルのエラー例です。大文字・小文字、接頭辞、具体的な文言はプラットフォームや接続段階によって異なる場合があるため、デバイスに記録された内容を確認してください。障害発生時のメッセージをそのまま保存し、すべてのエラーを「接続先のタイムアウト」とひとまとめにしないでください。

エラー：i/o timeout

原因と対処：ネットワークの読み書きが制限時間内に完了しなかった状態です。このメッセージだけでは停止した箇所を特定できません。前後のログから、名前解決・接続・応答の読み取りのどこで失敗したかを確認し、同じ接続項目でネットワークを切り替えて再テストしてください。

エラー：connection refused

原因と対処：接続要求が明示的に拒否されています。ポートで待ち受けていない場合や、デバイス側から拒否された場合によく起こります。まずアドレスとポートを照合し、そのポートでサービスが稼働しているかサービス提供元に確認してください。

エラー：TLS handshake timeout

原因と対処：TLSハンドシェイクが時間内に完了していません。通信が遮断されている、またはサーバーが応答していない可能性があります。TLSの設定、Server Name、ポートを確認し、別のネットワークでも試して経路の問題かどうかを調べてください。

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

原因と対処：証明書の有効期間とシステム時刻が一致していません。まずデバイスの時刻を正しく設定し、それでも失敗する場合は、サーバーの管理者に証明書の有効期間を確認してもらってください。

iPhone / iPadでは、「設定」→「一般」→「日付と時刻」で「自動設定」を確認し、日付・タイムゾーン・現在時刻が正しいことを確かめます。Windows、Mac、Android、Linuxでは、それぞれのシステムの日付と時刻の設定から同期してください。修正後に接続を再確立し、同じエラーが引き続き表示されるか確認します。

システム時刻のずれは、TLS証明書の有効期間の確認だけでなく、時刻の範囲に依存するプロトコル認証にも影響する場合があります。
システム時刻が正しくても、証明書に問題がないとは限りません。期限切れ、名前の不一致、証明書チェーンの問題はそれぞれ個別に確認が必要です。
特定のWebサイトだけで証明書エラーが起きる場合は、プロキシのハンドシェイク失敗なのか、接続先サイト自体の証明書エラーなのかを切り分けてください。

5. 接続後にルーティング・DNS・サブスクリプションの状態を確認する

接続スイッチがオンなのは、システムトンネルが動作していることを示すだけで、すべてのリクエストが選択中のプロキシを経由するとは限りません。Home → Global Routingで現在のモードを確認します。Proxyは全通信をプロキシ経由にし、Directは直接接続、Configは現在の設定に従って通信を振り分け、Sceneはシーン設定に従って動作します。原因の切り分け中は一時的にProxyを選び、同じ接続先で再テストできます。テスト後は元のモードに戻してください。

Proxyでは接続できるがConfigでは失敗する：Config内のルールの順序と、実際に適用されたルールを確認します。DOMAIN-SUFFIXはドメインのサフィックス、IP-CIDRはアドレス範囲、GEOIPはIPアドレスの地域情報に基づいて照合し、FINALはそれ以前のルールに一致しなかった通信を処理します。
DIRECTに一致する：そのリクエストは想定どおりにプロキシを経由していません。接続項目のパスワードを変更するのではなく、それより前に一致したルールがないか確認してください。
REJECTに一致する：ルールによってリクエストが拒否されています。ルールの目的と適用範囲を先に確認し、サーバーが応答していない状態と混同しないでください。
ログに名前解決の失敗が記録される：設定内のDNS、サーバーのドメイン名の入力、現在のネットワークから名前解決できるかを確認してください。TLSの名前確認に影響したり、誤ったアドレスに接続したりするおそれがあるため、サーバーのドメイン名を安易にIPアドレスへ置き換えないでください。

サブスクリプションの更新は、接続とは別のリクエスト経路を使います。更新の成功は、今回のサブスクリプション内容をダウンロードして解析できたことを示すだけで、すべての接続項目が使用できることを保証しません。登録済みの接続項目が使えても、サブスクリプションURLが有効とは限りません。サービス提供元が設定を変更した場合は、Homeで該当するサブスクリプションを更新し、接続項目が実際に変わったか確認してください。

判断のポイント：更新失敗と接続失敗を分けて記録する

「サブスクリプションの更新結果」「選択中の接続項目」「Global Routingのモード」「実際のアクセス結果」の4項目を記録します。更新経路だけに問題があり、使用可能なプロキシがある場合に限り、Settings → SubscribeでUpdate via Proxyを確認してください。接続できないプロキシは、更新リクエストの経路として使えません。

自動接続の影響を避けるため、再テストの前にSettings → On Demandの現在の状態を記録し、必要に応じて一時的に無効にしてから手動で接続してください。テスト後は元の設定に戻します。トラブル対処のため一時的に変更したモードを、そのまま普段の設定として使い続けないでください。

6. よくある質問とトラブル情報の伝え方

遅延が数十ミリ秒なのに、Webページを開けないのはなぜですか？

まず、どの種類のテスト結果が表示されているか確認してください。TCP接続が速くても、プロトコル認証や接続先へのアクセスが成功するとは限りません。Homeで選択中の接続項目とGlobal Routingを確認してから、同じHTTPSページにアクセスします。失敗時のログを確認し、ハンドシェイクのエラーかルールによる振り分けの問題かを切り分けてください。

Wi-Fiではタイムアウトしますが、モバイルデータ通信なら使えます。再インポートが必要ですか？

サブスクリプションはすぐに削除しないでください。同じ接続項目とプロトコル設定のまま、Wi-Fiの認証が完了しているか、名前解決ができるかを確認します。Hysteria2またはWireGuardを使用している場合は、ネットワークによるUDP制限も確認してください。Wi-Fiとモバイルデータ通信の差については、サービス提供元またはネットワーク管理者に問い合わせます。

サブスクリプションを更新しても、一つの接続項目がタイムアウトします。どうすればよいですか？

該当する接続項目の設定が実際に更新されたことを確認し、元の設定とアドレス・ポート・認証項目を照合してください。同じネットワークでほかの接続項目が使える場合は、該当項目の情報を個人情報が分からない形で伝え、失敗時刻とエラーメッセージを添えてサービス提供元に該当サービスの確認を依頼してください。

設定全体を誰かに送って確認してもらう必要がありますか？

通常は、利用しているシステムのプラットフォーム、プロトコル、ネットワークの種類、Global Routingの状態、テスト方式、個人情報を伏せたエラーメッセージを伝えれば十分です。サブスクリプションの完全なURL、Password、UUID、秘密鍵、認証情報を含むQRコードは公開しないでください。ログを共有する前に、ドメイン名や個人情報が含まれていないか確認します。

一通り確認したら、元のネットワーク、接続項目、接続先に戻して再テストし、トラブル対処のために一時変更した設定も元に戻してください。原因を特定できない場合は、「どのネットワークで、どの接続項目（個人情報は伏せる）を選び、どのモードで、どのエラーメッセージが表示されたか」を手順として記録します。タイムアウト画面のスクリーンショットだけを送るより、状況を確認しやすくなります。