Shadowrocketでタイムアウトが発生しても、ノードが必ず使えなくなったとは限りません。この記事ではiPhone / iPad、Mac、Windows、Android、Linuxを対象に、「ローカルネットワーク → テスト範囲 → プロトコル設定 → システム時刻 → ルールとDNS」の順で原因を調べます。画面操作はiPhone / iPadのHome、Config、Settingsを基準に説明します。他のプラットフォームでは対応する設定項目を確認してください。利用者が自身のサービス提供元と契約していることを前提とし、サブスクリプションのURLはサービス提供元から取得してください。
1. ノードのタイムアウトとローカルネットワークの問題を切り分ける
まずShadowrocketの接続をオフにし、ブラウザで普段直接アクセスできるページを開きます。ローカルネットワーク自体が使えない場合、遅延テストの結果からリモートサービスの状態を判断することはできません。公衆Wi-Fiでは、先にログインが必要な場合もあります。Wi-Fiアイコンが表示されていても、インターネットに完全にアクセスできるとは限りません。
テストでは一度に変更する条件を一つに絞ります。まず同じネットワーク、同じノード、同じ接続先で確認し、その後Wi-Fiとモバイル通信を切り替えます。サブスクリプションの更新、プロトコルの変更、設定の差し替えを同時に行わないでください。復旧しても、どの変更が効いたのか判断できなくなります。
-
ローカルネットワークを確認する
Homeで接続をオフにし、ブラウザから直接アクセスできることが分かっているページを開きます。ログインが必要なWi-Fiでは、先に認証を完了してください。
-
失敗する範囲を記録する
Homeでテストするノードを選び、失敗が単一ノード、同じグループ内の複数ノード、または全ノードのどれに当たるかを記録します。使用中のネットワークがWi-Fiかモバイル通信かも控えてください。
-
実際の接続を確認する
接続をオンにしたら、HomeでConnectivity Testを実行し、ブラウザから同じ接続先にアクセスします。テスト結果とページの読み込み状況を記録し、接続スイッチの状態だけで判断しないでください。
-
ネットワークを切り替えて再テストする
ノードと設定はそのままにして、利用できる別のネットワークに切り替えて再テストします。特定のネットワークだけで失敗する場合は、そのネットワークのDNS、アクセス制限、UDPの到達性を優先して確認してください。
2. 遅延テストに数値が出てもWebページを開けないのはなぜ？
遅延の数値は、どの方法でテストしたかを踏まえて判断する必要があります。TCP接続テストで確認できるのは、指定したアドレスとポートへの接続処理の一部です。パスワードが正しいことや、プロキシ経由で目的のWebサイトにアクセスできることまでは証明できません。実際のリクエストを使うテストはより多くの処理を確認できますが、その時点でのテスト先の結果を示すにすぎず、すべてのWebサイトで利用できる保証にはなりません。
| 確認できた現象 | まず考えられる原因 | 次に行うこと |
|---|---|---|
| 一つのノードだけタイムアウトし、他のノードは正常 | その接続先または設定値に問題がある可能性が高い | そのノードのアドレス、ポート、サービス状態を確認し、設定全体はリセットしない |
| Wi-Fiでは全ノードが失敗するが、モバイル通信では正常 | ローカルネットワークの通信経路に違いがある | Wi-Fiのログイン状態、DNS、UDPの通信可否を確認する |
| ポートテストでは遅延が出るが、実際のリクエストは失敗する | 接続後の認証、TLS、または接続先へのアクセスで失敗している | 失敗したリクエストのログを確認し、認証情報、SNI、システム時刻をチェックする |
| Webページは開けるが、一部のテストだけ失敗する | テスト先またはテスト方法が現在の通信経路に合っていない可能性がある | テストの種類を記録し、実際に使うリクエストでも確認する |
| 特定のWebサイトだけ開けない | 接続先サイト、ルール、または名前解決の問題 | Global RoutingのProxyとConfigを比較し、そのドメインに適用されるルールを確認する |
ポイント：再現できる比較条件を残す
同じノードがネットワークを変えると使える場合は、まず元のネットワークを調べます。同じネットワークで一つのノードだけ失敗する場合は、そのノードを確認します。このように範囲を絞ると、アプリを何度も再インストールするより原因を見つけやすくなります。
Hysteria2などUDPを使う通信では、一度のTCPポートテストだけでプロトコルが使えるかどうかを判断できません。逆に、TCPテストが成功してもUDP通信が可能とは限りません。テスト方法と実際のプロトコルを分けて記録し、結果を混同しないようにしてください。
3. プロトコルごとにアドレス、ポート、認証設定を確認する
Homeで対象ノードの編集画面を開き、各項目をサービス提供元から案内された情報と照合します。サブスクリプションから読み込んだノードも、サーバー側の変更で古くなっていることがあります。まず更新が成功したか確認してから、設定値を調べてください。慣例だけを根拠にポートを一律443へ変更したり、エラーを消すために証明書の検証を無効にしたりしないでください。
- Shadowsocks：アドレス、ポート、Password、暗号化方式を確認します。パスワードが正しくても暗号化方式が異なれば通信できません。サービス提供元から追加のプラグイン設定を指定されている場合は、その内容も一致させてください。
- VMess：UUID、サーバー側で指定された認証設定、転送方式を確認します。WebSocketを使う場合は、Host、Path、TLSの設定も確認してください。UUIDだけをコピーしても不十分です。
- VLESS：UUID、転送方式、サービス提供元から明示されたTLS、REALITY、またはFlowの設定を確認します。異なるセキュリティ方式の設定項目を混在させないでください。
- Trojan：Password、ポート、TLSの設定を確認します。SNIにはサービス提供元が指定したホスト名を入力し、プロトコルの接頭辞、ポート、パスは含めません。接続先アドレスとSNIは異なる場合がありますが、任意に置き換えないでください。
- Hysteria2：認証情報、TLS、サービス提供元が指定する難読化設定を確認し、現在のネットワークで必要なUDP通信が許可されているかも確認します。TCPで接続できても十分な条件ではありません。
- WireGuard：ローカル秘密鍵、ピアの公開鍵、Endpoint、トンネルアドレスなどの設定を確認します。TLSのSNIフィールドは使用しないため、Trojanの確認項目を当てはめないでください。
TLSのSNIとWebSocketのHostは別の概念です。前者はTLSハンドシェイクで接続先のサービスを識別するために使われ、後者はHTTPリクエストのフィールドです。値が同じ場合もありますが、それぞれサービス提供元の案内を確認してください。ノード名はローカルで表示するラベルにすぎず、名前を変えても認証や接続の問題は解決しません。
4. エラーメッセージから失敗した段階を特定する
失敗時のログまたはシステムのエラー詳細を確認し、エラーメッセージの原文と発生時刻を記録してください。以下はネットワーク層やTLS層でよく見られるエラーです。具体的な接頭辞はプラットフォームや接続段階によって異なります。画面にTimeoutとだけ表示される場合は、前述のネットワーク比較テストとあわせて判断してください。
エラー：connection timed out
原因と対処：待機時間内に期待した応答を受信できなかった状態です。アドレス、ポート、ネットワーク経路、リモート側の状態などが原因として考えられます。同じノードを別のネットワークで再テストし、その後サービス提供元に接続先が引き続き有効か確認してください。
エラー：connection refused
原因と対処：接続先または中継機器が接続要求を明示的に拒否しています。ポートとプロトコルを確認してください。待機時間を延ばすだけでは解決しません。ポートが正しい場合は、サービス提供元に待ち受けサービスの状態を確認してもらってください。
エラー：certificate has expired or is not yet valid
原因と対処：端末の時刻が正しくないか、サーバー証明書の有効期限が切れている可能性があります。まずシステム時刻を修正して再試行してください。それでも失敗する場合はサービス提供元に証明書を確認してもらいます。検証を回避する方法を恒常的な対処にしないでください。
エラー：no such host
原因と対処：ホスト名を解決できないか、有効なレコードを取得できていません。アドレスの入力ミスがないか、ローカルネットワークが使えるかを確認し、解決に失敗しているのがノードのドメイン名か接続先サイトのドメイン名かを切り分けます。
ログに表示されたEOFだけを見て「パスワードが間違っている」と判断しないでください。EOFは接続が終了したことを示すだけで、認証情報の不一致、転送設定の誤り、リモート側による接続の早期切断など、さまざまな原因で発生します。前後にあるTLS、名前解決、接続の情報も確認してから、変更する項目を決めてください。
5. システム時刻と自動設定を確認する
システム時刻のずれは、証明書の有効期間の判定に影響するほか、一部の認証処理にも影響する可能性があります。確認するのは画面に表示されたタイムゾーンだけでなく、端末の現在時刻が正確かどうかです。タイムゾーンを手動で変更しても時刻の同期にはなりません。自動設定を有効にした後、日付、年、時刻が正しく戻ったか確認してください。
- iPhone / iPad：システムの「設定 → 一般 → 日付と時刻」を開き、「自動設定」をオンにします。変更できない場合は、デバイス管理やシステム制限を確認してから、Shadowrocketで接続し直してください。
- Mac：「システム設定 → 一般 → 日付と時刻」を開き、日時の自動設定を有効にして、現在時刻が正確か確認します。
- Windows：「設定 → 時刻と言語 → 日付と時刻」を開き、時刻の自動設定を有効にして、システムの「今すぐ同期」操作を実行します。
- Android：システム設定で「日付と時刻」を検索し、時刻の自動設定を有効にします。メニュー名は端末によって異なります。タイムゾーンの自動設定も確認してください。
- Linux：システムの日付と時刻の設定で、ネットワーク時刻同期を有効にします。グラフィカルな設定画面がない場合は、デバイス管理者に時刻同期サービスの状態を確認してもらってください。
6. 接続済みの場合はGlobal Routing、DNS、On Demandを確認する
ノードは使えるのにWebページを開けない場合は、Home → Global Routingを確認します。Proxyはプロキシ対象の通信を選択中のプロキシに転送し、Directは直接接続します。Configは現在の設定ルールに基づいて通信を振り分けます。Sceneは選択中のシーン設定に従って処理するため、シーンの内容も確認してください。原因を調べる間だけProxyとConfigを切り替えて比較し、終わったら元の設定に戻します。
- Proxyは正常、Configは失敗：Configを開き、現在有効な設定とルールの適用順を確認します。DOMAIN-SUFFIXはドメインのサフィックスに一致し、GEOIPとIP-CIDRはIP条件に基づいて一致します。FINALは、それ以前のルールに一致しなかった接続に適用されます。
- ProxyとConfigの両方で失敗：接続先、プロトコル、DNSの確認に戻り、FINALだけを変更しないでください。ノードのドメイン名を解決できないと接続を開始できません。接続先サイトのドメイン名の解決に失敗する場合は、トンネル確立後に問題が発生している可能性があります。
- 接続をオフにしても自動で再接続する：Settings → On Demandと、設定済みの条件を確認します。調査中は自動起動を一時的にオフにし、自動再接続を手動操作の失敗と誤認しないようにしてください。確認後は必要な設定に戻します。
- スリープ復帰後やネットワーク切り替え後に失敗する：復帰前後のネットワーク種別を記録し、いったん手動で切断してから再接続します。特定の条件でのみ問題が発生する場合は、その条件に対応するOn Demand設定を確認してください。
ルールは上から順に評価され、先に一致したルールが後続の処理に影響します。設定ファイルに対象ドメインのルールが「あるか」だけでなく、それより前のルールが先に一致していないかも確認してください。特定のWebサイトだけ開けない場合は、対象ドメインと実際に適用されたポリシーを記録すると、Config全体を差し替えるより原因を特定しやすくなります。
7. よくある質問と問い合わせ前に記録する情報
サブスクリプションの更新もタイムアウトします。すべてのノードが使えなくなったのでしょうか？
いいえ。サブスクリプションのダウンロードとノードへの接続は、別のリクエスト経路を使います。まず既存のノードが使えるか確認し、次にサブスクリプションURLが有効か、期限切れやアクセス制限がないかを確認してください。URLはサービス提供元から取得します。更新が成功したら、ノードの設定値に変更があったか比較してください。
遅延は小さいのに、動画がずっとバッファリングするのはなぜですか？
遅延が示すのは一度のテストに対する応答時間であり、継続的な転送速度ではありません。同じ接続先で別の既存ノードや他のネットワークと比較してください。そのWebサイトだけで発生していないかも確認し、遅延が最小のノードだけを基準に選ばないようにしてください。
証明書の検証をオフにすると接続できます。これで直ったと考えてよいですか？
それだけで問題が解決したとは判断できません。証明書の検証を元に戻し、システム時刻、SNI、サーバー証明書を確認してください。サービス提供元から特別な信頼設定を指定されている場合は、証明書の入手元と正しい設定方法を確認し、エラーを長期間無視しないでください。
サブスクリプションURLとログをすべてそのまま共有してよいですか？
サブスクリプションURL、パスワード、UUID、秘密鍵を公開しないでください。サービス提供元に問い合わせる際は、発生時刻、プラットフォーム、ネットワーク種別、プロトコル、エラーメッセージの原文、必要な範囲で個人情報を伏せたログを伝えます。スクリーンショットを共有する前に認証情報を隠してください。
最終的に、発生時刻とタイムゾーン、デバイスのプラットフォーム、Wi-Fiかモバイル通信か、単一ノードか全ノードか、現在のGlobal Routing設定、エラーメッセージの原文、別のネットワークで試した結果を簡潔に記録してください。リセットや再インストールを行う場合は、先に既存の設定をバックアップします。再インストールしても、サーバーの停止、認証情報の誤り、証明書の失効は解決できません。