Shadowrocketでタイムアウトと表示されても、すべての通信が失敗しているとは限りません。遅延が表示されても、プロトコル認証やWebサイトへのアクセスが成功したとは限りません。自分で用意したサーバーやサブスクリプションを利用中に接続できなくなった場合は、まずネットワークの状態、サーバーテスト、実際の通信を切り分けます。次にプロトコル設定、TLS、システム時刻を確認し、同じ接続先で再テストしましょう。一度に変更する項目は一つにします。
1. 遅延テスト・VPNの状態・実際の通信を切り分ける
現在のサーバーと設定はそのままにし、ポート・DNS・ルールを同時に変更しないでください。Homeに表示されるサーバーの遅延、システムのVPN接続状態、Connectivity Test、ブラウザでの実際のアクセス結果は、それぞれ異なる段階を示します。システムにVPN接続済みと表示されても、端末側のトンネルが確立したことを示すだけです。リモートサーバーの認証完了や、接続先Webサイトへの到達を保証するものではありません。
前から順に確認すると、原因を誤って判断しにくくなります。たとえば、サーバーのポートにTCP接続できても、その後のハンドシェイクでパスワードが間違っていると失敗します。テスト先の一つから応答がないだけで、すべてのWebサイトが利用できないとは判断できません。テスト方法によって確認できる段階は異なるため、結果とあわせてテスト方法と接続先も記録してください。
| 確認箇所 | わかること | 次に確認する項目 |
|---|---|---|
| Homeのサーバー遅延 | 現在のテスト方法での応答状況 | プロトコル設定と実際の通信が成功するか |
| システムのVPN接続状態 | 端末側のトンネルの状態 | デフォルトサーバーとGlobal Routing |
| Connectivity Test | テスト先にその時点の条件で到達できるか | ほかの接続先とアプリでの実際のアクセス |
| ブラウザでのアクセス結果 | その接続先へのエンドツーエンドの通信結果 | 特定のドメインやアプリだけで失敗するか |
2. 複数の設定を同時に変えず、手順に沿ってタイムアウトを再現する
まず基本ネットワークが使えることを確認してから、Shadowrocketの接続を調べます。確認中にSettings → On Demandが有効だと、手動で切断しても再接続が始まる場合があります。基準となるテストを終えるまでOn Demandを一時的に無効にし、終了後に元の設定へ戻してください。テストには、正常にアクセスできるとわかっている接続先を使い、見知らぬアドレスを次々と試すのは避けましょう。
-
基本ネットワークを確認する
Shadowrocketを切断し、ブラウザでアクセスできるとわかっているWebページを開きます。Wi-Fiのログイン認証が必要な場合は、先に認証を済ませてください。基本ネットワーク自体が使えない場合は、まずネットワークへの接続を解決します。
-
デフォルトの選択項目を確認する
Homeに戻り、テストするサーバーを選択して、選択中のマークがその項目に付いていることを確認します。編集画面を開いただけではデフォルト項目は切り替わりません。現在のGlobal Routingの選択内容も記録してください。
-
遅延を記録する
Homeでサーバーの遅延テストを実行し、成功またはタイムアウトの結果と、選択したテスト方法を記録します。3回連続でテストして安定性を確認してください。一度応答があっただけでは、継続して利用できるとは限りません。
-
実際の接続を確認する
接続スイッチをオンにし、システムの案内に従ってVPN構成を許可します。次にHomeでConnectivity Testを実行します。その後、同じ既知の接続先にアクセスし、テスト結果とWebページの表示結果をそれぞれ記録してください。
-
接続ネットワークを切り替える
可能であれば、サーバー・設定・接続先を変えずにWi-Fiからモバイル通信へ切り替えて再テストします。接続ネットワークによって結果が変わる場合は、ネットワークの制限、名前解決、使用する通信方式で到達できるかを優先して確認してください。
3. アドレス・ポート・認証・通信方式の設定を一つずつ確認する
基本ネットワークに問題がないのに特定のサーバーで接続が続けて失敗する場合は、Homeでそのサーバーの編集画面を開き、自分のサービス提供元またはサーバー側の元の設定と照合します。まずTypeが一致しているか、次にアドレスとポート、最後に認証・通信方式・TLSを確認してください。表示名は識別用のラベルであり、プロトコル認証には使われません。表示名が同じでも内部の設定が同じとは限りません。
| 確認項目 | 具体的な確認内容 | 間違えやすい点 |
|---|---|---|
| アドレスとポート | アドレスに余分な空白がないこと、ポートがサーバーの待受ポートと一致すること | ポート443でも、TLSが使われているとは限らず、サービスが利用可能とも限りません |
| Shadowsocks | 暗号化方式、パスワード、サーバーが要求するプラグイン設定を確認する | 試しに別の暗号化方式へ変更しても、元の設定の代わりにはなりません |
| VMess / VLESS | UUID、通信方式、サーバーが要求するその他の項目を確認する | UUIDが同じでも、異なるプロトコルを相互に置き換えられるわけではありません |
| Trojan | パスワードとTLS関連の設定を確認する | アドレスに接続できても、パスワード認証や証明書の検証が成功したとは限りません |
| Hysteria2 | 認証・TLS・サーバー指定の設定を確認し、UDPで到達できるかも調べる | 通常のTCPポートテストでは、接続経路全体を検証できません |
| WireGuard | 鍵、ピア、Endpoint、アドレスなどの設定を確認する | TLS証明書は使わないため、TLSのトラブルシューティング手順は適用できません |
元の設定でWebSocketを使っている場合は、PathとHostも確認します。たとえば、サーバー側の設定が/wsを要求しているなら、クライアント側を勝手に/へ変更しないでください。ここでのパスは各項目を一字一句合わせる必要があることを示す例であり、そのまま使えるサーバー設定値ではありません。別の通信方式を使う場合も、元の設定に従って該当項目を確認し、WebSocket用の項目を流用しないでください。
- ポートはサーバー設定の一部です。443がよく使われるからといって、元のポート8443を443に変更してはいけません。
- パスワード、UUID、鍵をコピーしたときに途中で切れていないか、改行が含まれていないか確認します。これらの情報を公開の掲示板などに投稿しないでください。
- サブスクリプションを使っている場合は、更新が成功したことを確認してから、現在選択中の項目が想定したサーバーかを確認してください。リストの更新と接続の成功は別です。
- サブスクリプション管理の項目は、次回更新時に手動編集が上書きされることがあります。比較テストを行う場合は元の設定を保存し、一時的な変更を恒久的な解決策と考えないでください。
4. エラーの原文を確認し、発生した段階を特定する
以下はネットワーク接続でよく見られるエラーの一部です。すべての画面に同じ文言が表示されるとは限りません。実際のエラー詳細や接続ログに該当する原文がある場合に限り、その内容に沿って調べてください。「タイムアウト」と表示されただけで認証に失敗したとは判断できません。エラーを記録するときは、サブスクリプションの更新、サーバーテスト、Webページへのリクエストのどの段階で起きたかも記録します。
エラー：i/o timeout
原因：処理が制限時間内に完了しなかったことを示します。この文言だけでは、名前解決・接続・その後のデータ受信のどこでタイムアウトしたかは特定できません。
対処法：前後のログで接続先と処理段階を確認します。同じアドレスとポートで再テストし、別の接続ネットワークでも比較してください。すべての設定を一度に変更しないでください。
エラー：connection refused
原因：接続が明示的に拒否されています。接続先のポートで待ち受けていない場合や、ネットワーク機器が接続を拒否した場合によく発生します。
対処法：まずポートとプロトコルを確認し、自分のサービス提供元に該当サービスが稼働しているか問い合わせてください。ポート拒否の場合、パスワードを繰り返し変更しても通常は解決しません。
エラー：certificate has expired or is not yet valid
原因：証明書の有効期間と検証時刻が一致していません。証明書の期限切れのほか、端末の時刻が正しくない場合にも発生します。
対処法：まずシステムの日付と時刻を確認してから、再接続してください。時刻が正しいのにエラーが続く場合は、自分のサービス提供元に証明書の有効期間を確認します。
問題の調査を依頼するときは、「使えない」とだけ伝えるより、エラーの原文を残すほうが役立ちます。接続ネットワークの種類、テストした時刻、プロトコルの種類、エラーが起きた段階、試した変更項目を一つずつ伝えてください。サブスクリプションの完全なURL、パスワード、UUID、秘密鍵は公開の診断情報に含めないでください。
5. TLSとシステム時刻を確認し、証明書の検証を回避しない
TLSを利用するには、サーバー設定、証明書の識別情報、端末の時刻など、複数の条件が一致する必要があります。サーバーアドレス、TLSのServer Name（SNI）、WebSocketのHostは用途の異なる項目です。同じ値の場合もありますが、必ず一致すると決めつけてはいけません。IPアドレスで接続している場合でも、サーバーが要求するServer NameをIPアドレスに変更してはいけません。
- Homeでサーバーの編集画面を開き、サーバー側の設定に従ってTLSが有効か、Server Nameが正しいかを確認します。この確認は、使用中のプロトコルと通信方式でTLSを使う場合に行ってください。
- iPhoneまたはiPadのシステム設定で「設定 → 一般 → 日付と時刻」を開き、「自動設定」を確認します。現在の日付、タイムゾーン、時刻も確認してください。ここで確認するのはシステム設定であり、ShadowrocketのSettingsではありません。
- 「自動設定」を利用できない場合は、端末管理やシステム上の制限を確認し、時刻を正確にしてから再テストしてください。証明書の期限切れを隠すために、システムの日付を過去に戻してはいけません。
- 時刻が正しいのに証明書エラーが続く場合は、自分のサービス提供元に証明書の有効期限、ドメインとの一致、証明書チェーンの完全性を確認してください。通常の修復方法として証明書の検証を無効にしないでください。
6. 遅延は正常なのに接続できない場合：Global Routingとルールを確認する
遅延テストが正常でも実際のリクエストが失敗する場合は、通信が想定した経路を通っているか確認してください。Home → Global RoutingのProxy、Direct、Config、Sceneは、それぞれ異なるルーティング方法です。Proxyはプロキシ経由、Directは直接接続、Configは現在の設定に基づく振り分け、Sceneは選択中のシーン設定に従って動作します。選択肢で変わるのは通信経路であり、誤ったプロトコル認証情報が修正されるわけではありません。
- Configを使う場合は、Configで現在選択している設定を確認してから、該当するルールと出力先ポリシーを確認してください。サーバー一覧の遅延だけで振り分け結果を判断しないでください。
DOMAIN-SUFFIXはドメインのサフィックスで一致判定し、IP-CIDRはIPアドレスの範囲で一致判定します。GEOIPはIPアドレスの地理的分類を使用します。ドメインルールとIPルールでは、判定条件が異なります。FINALは、それ以前のルールに一致しなかった場合の最終ルールです。ルールの順序と最終ポリシーを確認し、接続先が意図せずDirectなど想定外の経路に流れないようにしてください。- 同じ接続先を一時的にProxyで比較テストした後は、元のルーティング方法に戻してください。Configでだけ失敗する場合は、すでに正常と確認できたパスワードを変更し続けるのではなく、ルールと名前解決を確認します。
名前解決も実際の通信の一部です。サーバーアドレスのドメインを名前解決できない場合と、サーバーへの接続後に接続先ドメインを名前解決できない場合は、異なる段階の問題です。DNS関連の設定を一度にすべて変更しないでください。まず、どのドメインで、どの経路を通るときに失敗するかを特定し、一つずつ変更して結果を比較します。
7. よくある質問とトラブルシューティングの完了条件
遅延の数値が表示されても接続できないのはなぜですか？
遅延の数値が示すのは、選択したテスト方法で確認できた範囲だけです。Homeに戻ってデフォルトサーバーを確認し、接続後にConnectivity Testを実行してから、認証と通信方式の設定を点検してください。ポートから応答があるだけで、プロトコルのハンドシェイク全体が成功したとは判断できません。
Wi-Fiではタイムアウトするのに、モバイル通信では正常な場合はどうすればよいですか？
サーバーと接続先は変えず、まずWi-Fiのログイン認証を済ませてから、そのネットワークでの名前解決、ポート、UDPへの到達性を確認します。すぐにプロトコルの変更を求めるのではなく、「同じ設定で接続ネットワークを変えた場合」の比較結果を自分のサービス提供元に伝えてください。
サブスクリプションを更新できるのに、サーバーへ接続できないのはなぜですか？
サブスクリプションの更新成功が示すのは、リストを取得できたことだけです。リスト内のすべてのサーバーで認証が完了するとは限りません。更新後にHomeでデフォルト項目を確認し、そのサーバーを個別にテストしてください。サービスの状態と認証情報が有効か、自分のサービス提供元に確認します。
VPNは接続済みなのに、特定のWebサイトだけ開けない場合は？
まず、アクセスできるとわかっている別の接続先と比較し、次にHome → Global RoutingとConfigで該当するルールを確認します。ほかの接続先に問題がなければ、そのドメインの名前解決、ルール、接続先からの応答を調べてください。すぐに設定全体を作り直す必要はありません。
トラブルシューティングの完了には、想定したサーバーが選択されていること、プロトコル設定が元の設定と一致していること、システム時刻が正しいこと、接続先への通信が想定した経路を通ること、同じ条件での再テストが複数回安定することを確認します。変更前後の記録を残し、一時的に無効にしたOn Demandと変更したGlobal Routingは元に戻してください。問題が続く場合は、最小限の再現手順をまとめて自分のサービス提供元に確認を依頼します。