Shadowrocketでタイムアウトが表示されても、すべての接続設定に問題があるとは限りません。利用中のサービス事業者やサブスクリプションがあることを前提に、基本ネットワーク、遅延テスト、プロトコル設定、システム時刻、DNS、ルーティングの順に原因を確認します。一度に変更する項目は一つに絞り、同じ接続先で再テストしてください。再現できる症状とエラー記録も残しておきましょう。
1. テストのタイムアウトと実際の接続失敗を区別する
まず、遅延テストは診断の手がかりであり、接続成功を証明するものではありません。TCPテストで確認できるのは、指定したアドレスとポートへのTCP接続が確立するかどうかです。パスワードやUUID、後続のTLSハンドシェイクが正しいかまでは確認できません。Proxy経由でテストURLにアクセスする場合は、プロトコルのネゴシエーション、接続先ドメインの名前解決、接続先サイトからの応答も関係します。テストごとに測定範囲が異なるため、結果をそのまま比較することはできません。
システムにVPN接続済みと表示されても、システムのトンネルが確立したことを示すだけです。接続先のサービス、DNS、各ルールの動作が正常だとは限りません。「テスト失敗」「接続スイッチがオン」「実際にWebページを開けるか」を分けて記録してください。UDPを使うプロトコルでは、1回のTCPポートテストだけで接続可否を判断することは特にできません。
- テストだけがタイムアウトする場合：テスト方法と接続先を記録してから、実際にアクセスできることが分かっているHTTPSページを開いて確認します。すぐにノードを削除する必要はありません。
- 数値が表示されるのにアクセスできない場合：認証、TLS、DNS、ルールを引き続き確認してください。遅延値だけを見て設定の照合を省略しないでください。
- 特定のWebサイトだけ開けない場合：サイト側の状態、適用されるポリシー、ドメインの名前解決を優先して確認します。接続全体に問題があると決めつけないでください。
2. 再現可能な確認条件を整える
現在選択中のノード、Global Routingの設定、Config名を記録し、確認後に元の状態へ戻せるようにします。以下の手順では同じノードと接続先を使います。Wi-Fiとモバイル通信を切り替えるときも、プロトコルやDNSを同時に変更しないでください。モバイル通信でのテストではデータ通信量が発生するため、契約内容に応じて実施してください。
-
基本ネットワークを確認する
Settings → On Demandの現在の設定を記録します。確認中は自動接続を一時的にオフにし、Homeの接続スイッチもオフにしてください。アクセスできることが分かっているWebサイトを開きます。ログイン認証ページが表示される公共Wi-Fiでは、先に認証を完了してください。
-
テスト対象を固定する
Homeに戻り、確認するノードを選択して、遅延テストの方法と接続先を記録します。同じ条件で3回続けてテストし、成功・タイムアウト・具体的なエラーをそれぞれ記録してください。この3回は症状を再現するためのもので、長期的な稼働率を推定するものではありません。
-
ネットワーク環境を比較する
可能であれば、同じノードを使ってWi-Fiとモバイル通信の両方で再テストします。一方のネットワークだけで失敗する場合は、該当ネットワークの認証、DNS、通信制限を先に確認してください。ノードの設定を一度にすべて入力し直すのは避けましょう。
-
実際のリクエストを確認する
接続をオンにし、Home → Global Routingで一時的にProxyを選択して、同じHTTPSの接続先にアクセスします。これによりConfigのルーティングによる影響を抑えられます。テスト後は元の設定に戻し、診断用の設定をそのまま使い続けないようにしてください。
3. アドレス・ポート・プロトコル設定を一つずつ確認する
Homeで該当ノードの編集画面を開き、利用中のサービス事業者から提供された元の設定と項目ごとに照合します。ノード名だけでプロトコルを判断しないでください。名前は古い情報のままでも、実際の設定項目が変更されていることがあります。アドレス欄には指定されたホスト名またはIPアドレスを入力します。共有リンク全体、サブスクリプションURL、パス付きのURLをサーバーアドレスとして入力しないでください。
| 確認項目 | 照合する内容 | よくある誤認 |
|---|---|---|
| Address / Port | サーバーアドレスとポートを一字ずつ照合します。ポート番号の範囲は1～65535で、実際の値は元の設定で指定されています。 | すべてのノードのポートを443と決めつけ、元の設定では8443なのに443へ変更してしまう。 |
| Shadowsocks | 暗号化方式とパスワードを照合します。プラグインや追加の通信設定がある場合は、それらもサーバー側の設定と一致させます。 | ポートに接続できればパスワードも正しいと思い込む、または暗号化方式を独自に変更する。 |
| VMess / VLESS | UUID、転送方式、TLSに加え、選択した転送方式で使うHost、Path、Service Nameを確認します。 | UUIDだけを確認し、WebSocketのパスやgRPCのサービス名を見落とす。 |
| Trojan | パスワード、サーバーアドレス、ポート、TLS、SNIを確認します。追加の通信設定は元の設定どおりに入力してください。 | アドレスをIPに変更した際にSNIも空欄にし、証明書のホスト名が一致しなくなる。 |
| Hysteria2 | 認証情報、TLS、サーバー側で指定された難読化設定を確認し、ネットワークが必要なUDP通信を許可しているかも確認します。 | TCPテストに失敗しただけで、QUICベースの接続も使えないと判断する。 |
| WireGuard | ローカルのPrivateKey、対向側のPublicKey、Endpoint、Address、ルーティング範囲を確認します。 | 2種類の鍵を取り違える、またはTLS関連のエラーがないことをWireGuardのハンドシェイク完了と誤認する。 |
ノードがサブスクリプション由来の場合は、まず直近の更新が成功したか確認し、更新後の設定項目を照合します。サブスクリプションの更新とノードへの接続は別のリクエストです。更新に成功しても、設定内のすべてのノードに接続できるとは限りません。手動で変更する前に必要な情報を保存してください。次回のサブスクリプション更新で、ローカルの変更が上書きされる場合があります。
ポイント：ポートに接続できたらハンドシェイクを確認
TCPテストで結果が返ってもProxy経由のリクエストに失敗する場合は、ポートを繰り返し変更するのではなく、認証、TLS、転送設定を確認してください。UDPプロトコルの場合は、実際のプロトコルを使ったリクエストで判断します。
4. エラーが発生した段階から原因を絞り込む
アプリ内の接続記録を確認するときは、エラーの前後の状況を残してください。特に、エラーがサーバーアドレス、DNS検索、接続先サイトのどれに関係しているかを確認します。以下はネットワークエラーに現れることがある原文の一部です。大文字・小文字や正確な表現はエラーの発生元によって異なります。これらの英文がShadowrocketで必ず表示される固定メッセージだと考えないでください。
エラー：i/o timeout
原因と対処：ネットワークの読み込みまたは書き込みが、制限時間内に完了しなかった状態です。この表示だけでは、ポート、ハンドシェイク、接続先からの応答のどこに問題があるかは判断できません。まずエラーの前後に記録された接続先を確認し、基本ネットワーク、ポート、プロトコル設定の順に調べてください。
エラー：connection refused
原因と対処：接続が拒否されたことを示します。接続先のポートで待ち受けていないか、中継機器によって拒否されている可能性があります。アドレスとポートを確認したうえで、利用中のサービス事業者に接続先が現在も稼働しているか問い合わせてください。手当たり次第にポートを変更して確認するのは避けましょう。
エラー：no such host
原因と対処：対象のホスト名を名前解決できません。アドレスの入力ミス、DNSレコードの未登録、現在の名前解決経路の異常などが考えられます。エラーに出ているドメインがノード側か接続先サイト側かを確認し、ドメイン名とDNS設定を照合してください。
エラー：certificate has expired or is not yet valid
原因と対処：証明書の有効期間を確認できませんでした。端末の時刻またはサーバー証明書に問題がある可能性があります。まずiPhoneの時刻を正確に設定してください。時刻が正しくても解決しない場合は、利用中のサービス事業者にサーバー証明書の状態を確認します。
証明書エラーを解消するために、証明書の検証をオフにしないでください。アドレス、SNI、証明書に記載されたドメイン名は一致している必要があります。設定でエラーを回避できたとしても、名前や証明書そのものの問題は解決しません。
5. iPhoneのシステム時刻とTLSを確認する
iPhoneの「設定 → 一般 → 日付と時刻」で「自動設定」を確認します。デバイス管理ポリシーにより変更できない場合は、端末の実際の時刻が正確かどうかを確認してください。証明書の有効期間は通常、絶対時刻で判定されます。表示されるタイムゾーンが異なるだけで、システム時刻が間違っているとは限りません。
- 時刻が大きくずれている場合：正確な時刻に戻した後、Shadowrocketの接続を切断して再接続し、同じ接続先をテストしてください。
- 時刻が正しいのに証明書エラーが出る場合：ノードの編集画面に戻り、TLSとSNIを確認します。サーバーのIPアドレスを証明書のドメイン名として指定していないか、特に注意してください。
- 特定の接続先だけ失敗する場合：エラーがProxyサーバーとのハンドシェイクではなく、接続先サイトの証明書に関するものか確認してください。両者を混同しないようにしましょう。
- 最近設定が変更された場合：利用中のサービス事業者が提供する最新の設定と照合し、接続先ドメインや証明書関連の要件に変更がないか確認します。
一部の認証方式も、適切なシステム時刻を必要とします。時刻の調整は確認項目の一つとして扱い、接続に失敗するたびに繰り返す万能な対処法とは考えないでください。調整後もエラーが変わらない場合は、次の段階を確認します。同じ項目を何度も操作するのは避けましょう。
6. 最後にDNSとConfigのルーティングを確認する
プロトコル設定と時刻を確認したら、「ノードのドメインを名前解決できない」場合と「接続確立後に接続先ドメインを名前解決できない」場合を切り分けます。前者では接続先サーバーとの接続を確立できず、後者では接続スイッチが正常でも一部のWebサイトが開けないことがあります。IPアドレスを直接開くだけではHTTPSを十分に検証できません。証明書の名前やWebサイトの仮想ホストがドメイン名に依存する場合があるためです。
Configを使用している場合は、Configで現在選択中の設定を確認し、編集内容の[General]とdns-serverの設定を確認します。有効になっていない別のConfigを編集しても、その変更は反映されません。複数の不明なDNSアドレスを一度に追加するのも避けてください。元の値を保存し、項目を一つだけ変更してから同じドメインで再テストします。
- ルールの順序を確認：
DOMAIN-SUFFIXはドメインのサフィックス、IP-CIDRはIPアドレス範囲、GEOIPはIPアドレスの地理的な位置に基づいて判定します。これらを同じ条件として扱わないでください。 - 最終ポリシーを確認：
FINALは、それ以前のルールに一致しなかった場合に適用されるフォールバックです。適用されるポリシーが想定と異なると、接続先の経路が変わることがあります。 - 設定を比較：同じノードがProxyでは使えてConfigでは失敗する場合、認証項目を再入力する前に、ルール、ポリシーの参照先、Config内のDNSを確認してください。
- 元の状態に戻す：比較テストが終わるたびに、Global RoutingとOn Demandを元の設定に戻し、最終的に残した変更を記録してください。
7. よくある質問と確認結果のまとめ
遅延の数値が表示されるのに、Webページを開けないのはなぜですか？
まずテスト方法を確認してください。TCP接続が成功しても、認証やTLSが成功したとは限りません。Home → Global Routingで一時的にProxyを選び、同じHTTPSの接続先にアクセスしてから、ハンドシェイクのエラーを確認します。Proxyでは使えてConfigでは使えない場合は、現在のConfigでルールとDNSを確認してください。
サブスクリプションの更新に成功したのに、ノードがタイムアウトするのはなぜですか？
サブスクリプションの内容を取得する通信と、接続先サーバーに接続する通信は別です。ノードの編集画面を開き、アドレス、ポート、プロトコル設定を照合してから、同じテスト方法で現在のネットワーク上で再テストしてください。「更新成功」は、すべてのノードに接続できる証明ではありません。
Wi-Fiでは接続できず、モバイル通信では使える場合、ノードを追加し直す必要がありますか？
まず削除しないでください。ノード設定は変更せず、Wi-Fiのログイン認証とDNSを確認します。Hysteria2またはWireGuardを使用している場合は、そのネットワークでUDP通信が許可されているかも確認してください。ネットワーク管理者や利用中のサービス事業者には、比較結果を伝えると、何度も追加し直すより原因を特定しやすくなります。
利用中のサービス事業者に問い合わせるとき、何を伝えればよいですか？
障害が発生した日時とタイムゾーン、ネットワークの種類、プロトコルの種類、テスト方法、エラーの全文、ProxyとConfigでの比較結果を伝えてください。パスワード、UUID、PrivateKey、サブスクリプションのtokenは隠します。確認していない設定全体やスクリーンショットをそのまま送らないでください。
確認が終わったら、「変更前の症状」「変更した項目（一つだけ）」「変更後の結果」を記録してください。それでも解決しない場合は、最後に再現できたテスト条件も残します。次回は手当たり次第に設定を変えず、問題が起きた段階から確認を続けられます。