利用中のサービスやサブスクリプションがあり、Shadowrocketで接続タイムアウトが起きる、または接続後にアクセスできない場合の確認手順です。まず、テストの失敗、プロトコルのハンドシェイク失敗、想定したルートを通らない状態を切り分け、既存の接続情報とデバイスの時刻を確認します。一度に変更する条件は一つに絞り、結果を記録して、問題がローカルネットワーク、接続先、アプリの設定のどこにあるか判断しましょう。
1. 接続スイッチ、ノードテスト、Webサイトへのアクセスを切り分ける
Shadowrocketで接続スイッチをオンにすると、システムのVPNトンネルが確立します。ただし、接続先で認証が通ったことや、すべてのWebサイトにアクセスできることを示すわけではありません。ノードの横に遅延時間が表示されても、そのテストが特定の条件下で完了したという意味に限られます。すべての接続先や通信方式が正常とは限りません。
Homeで現在選択中のノード、Global Routingの状態、使用中のネットワークを記録します。切り分け中はSettings → On Demandを開き、On Demandを一時的にオフにしてください。ネットワーク切り替え時に自動接続が動作し、テスト条件が変わるのを防げます。テスト後は元の設定に戻します。ノードの変更、設定の更新、DNSの変更を同時に行うと、アクセスが回復しても原因を特定できません。
- ローカルネットワークを確認：接続スイッチを一時的にオフにし、現在のWi-Fiまたはモバイルデータ通信でインターネットに接続できるか確認します。公衆Wi-Fiにログイン画面が表示される場合は、先に認証を済ませてください。
- テスト条件を記録：ネットワークの種類、ノード名、テスト方式、成功またはタイムアウトの結果、エラーの原文を記録します。記録を共有する前に、サーバーアドレス、アカウント情報、認証情報を伏せてください。
- 影響範囲を確認：既存の全ノードで失敗するのか、特定のノードだけか、特定のWebサイトだけ開けないのかを確認します。状況によって確認すべき点が異なります。
2. まず遅延テストを行い、結果から分かる範囲を見極める
HomeのConnectivity Testで既存のノードをテストし、テスト方式も記録します。方式によって確認できる段階は異なります。TCP接続が成功しても、指定した接続先がTCP接続を受け付けたことしか分かりません。プロキシ経由でテスト用アドレスにリクエストする場合は、認証、プロキシからの外向き通信、DNS、テスト先の状態も関係します。この2つの結果を同じ指標として扱わないでください。
-
条件をそろえる
Homeで既存のノードを1つ選び、同じネットワークとテスト方式のまま3回続けてテストします。各回の結果を記録し、最小遅延だけで安定性を判断しないでください。
-
モードを確認
Home → Global Routingを確認します。プロキシ経由の経路を調べる場合は、一時的にProxyを選び、正しいノードが選択されていることを確認します。元のConfig、Direct、Sceneの状態を記録し、テスト後に戻してください。
-
アクセスを確認
接続スイッチをオンにし、普段利用していて状態を確認できるHTTPSページを2つ開きます。テスト用アドレスだけに頼らないでください。テスト先だけに問題があり、タイムアウトすることもあります。
-
ネットワークを切り替える
ノードと設定は変えず、Wi-Fiとモバイルデータ通信を切り替えて同じテストを繰り返します。モバイルデータ通信の利用許可と、現在のネットワークで必要な通信方式が使えるかも確認してください。
| 結果 | 分かること | 次の確認 |
|---|---|---|
| 同じノードが3回ともタイムアウト | 現在のテスト条件では制限時間内に完了していません。認証情報の誤りとはまだ断定できません。 | ネットワークを切り替えて再テストし、アドレス、ポート、通信方式を確認する |
| TCPテストは成功するが、プロキシ経由のリクエストは失敗 | 接続先には到達できても、認証、TLS、その後のリクエストで失敗する可能性があります。 | プロトコル設定とエラー記録を一つずつ確認する |
| Wi-Fiでは失敗し、モバイルデータ通信では成功 | ネットワーク経路、名前解決、ネットワーク制限に関係している可能性が高い状態です。 | Wi-Fiの認証、DNS、UDPが利用できるか確認する |
| Proxyではアクセスできるが、Configではアクセスできない | ルール、ポリシーの選択、DNS経路を優先して確認する | Configで現在有効な設定と一致したルールを確認する |
まとめ：比較結果で原因の範囲を絞る
同じノードが一方のネットワークでのみ失敗する場合は、プロトコル設定を変えずに、そのネットワーク経路を確認します。両方のネットワークで失敗する場合は、アドレス、ポート、ハンドシェイク設定を確認しましょう。正しい設定を何度も変更するのを避けられます。
3. アドレス、ポート、認証、通信方式の順に確認する
Homeで対象ノードの編集画面を開き、手元にある元の接続情報と項目ごとに照合します。サーバーアドレスにプロトコルの接頭辞、パス、末尾の空白が含まれていないか確認してください。Portは接続先で実際に待ち受けているポートと一致する必要があります。たとえば、接続情報が443の場合、接続に失敗したからといって自己判断で8443に変更しないでください。ポート番号が同じでも、TCPとUDPの両方が使えるとは限りません。
サブスクリプションの更新とノードへの接続は、別々のリクエスト経路です。サブスクリプションの更新に成功した場合、設定情報を取得できたことしか分かりません。ノードが使えても、サブスクリプションのURLにアクセスできるとは限りません。利用中のサービスから接続設定の変更が通知された場合は、まず既存のサブスクリプションを更新し、選択中の項目を確認してください。古いアドレスでテストを続けないようにしましょう。手動編集の前に元の値を記録してください。次回のサブスクリプション更新で編集内容が置き換わることがあります。
| プロトコル | 優先して確認する項目 | よくある誤解 |
|---|---|---|
| Shadowsocks | アドレス、ポート、暗号化方式、パスワード、元の接続情報で指定されたプラグイン設定 | ポートに接続できても、暗号化方式とパスワードが一致しているとは限らない |
| VMess | UUID、暗号化設定、通信方式、TLS、デバイスの時刻 | UUIDだけを確認し、通信方式や時刻のずれを見落とす |
| VLESS | UUID、通信方式、TLS、元の接続情報で指定されたflowなどの設定 | 同じアドレスに使われている別の通信方式の設定を、そのまま流用する |
| Trojan | パスワード、TLS、サーバー名、ポート | 接続先アドレスとTLSのサーバー名が必ず同じだと思い込む |
| Hysteria2 | 認証情報、TLS、UDP経路、元の接続情報にある難読化設定 | TCPテストの結果だけで、QUICベースの接続も正常だと判断する |
| WireGuard | ローカル秘密鍵、ピアの公開鍵、Endpoint、トンネルアドレス、Allowed IPs | 接続スイッチの状態だけを見て、有効なハンドシェイクや通信量を確認しない |
TLSを有効にした接続では、サーバー名も確認してください。WebSocketを使う接続では、HostとPathも照合します。Pathの大文字・小文字やスラッシュはルーティングに影響することがあるため、慣例で書き換えないでください。プロトコルごとの設定項目は互換性がありません。各項目を入力するかどうかは、手元にある元の接続情報を基準に判断し、エラーを消すために証明書の検証を無効にしないでください。
4. エラーから失敗した段階を特定する
「接続できない」という情報だけより、エラー記録のほうが原因を特定する手がかりになります。以下は、通信の低いレイヤーで表示されることがある代表的な英語のエラーです。実際の表示にはアドレスやプロトコルの接頭辞、詳しい状況が含まれる場合があります。エラーの直前・直後にどの処理が行われたかも記録し、キーワードだけで接続先の状態を判断しないでください。
エラー：i/o timeout
原因：接続、読み取り、ハンドシェイクなどの処理が制限時間内に完了しなかった状態です。パスワードの誤りを直接示すものではありません。
対処：同じノードでネットワークを切り替えて再テストし、アドレス、ポート、TCPまたはUDPの通信条件を確認してください。
エラー：connection refused
原因：接続リクエストが拒否されました。接続先のポートでサービスが待ち受けていないか、途中の機器が接続を拒否している可能性があります。
対処：元の接続情報に記載されたポートが変更されていないか確認します。同じエラーが再現する場合は、時刻と個人情報を伏せたエラー記録を利用中のサービスに送り、接続先の状態を確認してください。
エラー：no such host
原因：ドメイン名の名前解決で有効な結果を得られませんでした。アドレスの入力ミス、名前解決サービス、ドメイン自体に問題がある可能性があります。
対処：まずノードアドレスの入力ミスや余分な空白を確認し、ネットワークを切り替えて名前解決の結果を比較します。TLSのサーバー名をむやみに変更しないでください。
エラー：x509: certificate has expired or is not yet valid
原因：証明書の有効期間と検証に使われる現在時刻が一致していません。デバイスの時刻が誤っている場合と、接続先の証明書が実際に期限切れになっている場合があります。
対処：まずシステム時刻を正しく設定してください。時刻が正しいのに同じエラーが続く場合は、検証を無効にせず、利用中のサービスに証明書の確認を依頼します。
5. システム時刻とタイムゾーンを確認し、認証や証明書の誤判定を防ぐ
デバイスの時刻はTLS証明書の有効期間の確認に使われ、VMessなどの時刻に関係する認証にも影響します。ステータスバーの時刻だけでなく、日付、年、実際の時刻が正しいか確認してください。タイムゾーンは主に現地での時刻表示に影響します。タイムゾーンの表示が異なるだけで、デバイスの実時刻が誤っているとは限りません。
- iPhoneまたはiPadで「設定」→「一般」→「日付と時刻」を開き、「自動設定」を確認します。利用できる場合はオンにし、システムの同期を待ちます。
- 表示されている日付、年、タイムゾーンを確認し、現在のネットワークが使えることを確かめます。証明書エラーを回避するために日付を手動で変更しないでください。
- Shadowrocketに戻り、接続スイッチをオフにしてから再接続します。他の設定は変えず、同じノードでConnectivity Testを実行してください。
- 自動設定を変更できない場合は、デバイス管理による制限を確認します。時刻が正しいのに証明書エラーが続く場合は、エラーを記録して利用中のサービスに連絡し、接続先の証明書を確認してください。
6. テスト成功後にWebページを開けない場合はGlobal RoutingとConfigを確認
Global RoutingのDirectはリクエストを直接接続で処理し、Proxyはプロキシ経由で処理します。Configは現在の設定ルールに従い、Sceneは設定したシーンに応じて処理します。ノード自体のテストと、実際のアプリからのリクエストでは、同じ経路が選ばれるとは限りません。「遅延は正常なのにWebページが開けない」場合は、すぐにノードを作り直すのではなく、ルーティングと接続先を確認してください。
- まずモードを比較：一時的にProxyを選び、同じWebページにアクセスしてから元のモードに戻します。Configでのみ失敗する場合は、Configで現在有効な設定を確認してください。有効になっていないファイルだけを確認しても原因は分かりません。
- 次にルールの順序を確認：ルールは通常、上から順に照合されます。
DOMAIN-SUFFIXはドメインのサフィックス、IP-CIDRはIPアドレスの範囲、GEOIPはIPアドレスの地域データベースに基づいて照合します。FINALは、それまでに一致しなかったリクエストを処理します。 - DNSの手がかりを確認：接続先への接続は正常でもドメインへのリクエストが失敗する場合は、現在の設定にあるDNS設定とエラー記録を確認します。HTTPSページをドメイン名の代わりにIPアドレスで開いて簡単に判断しないでください。証明書や仮想ホストが元のドメイン名を必要とする場合があります。
- 特定の接続先だけの問題かを確認：ほかのよく使うページは開けるのに、特定の接続先だけ失敗する場合は、その接続先と時刻を記録します。接続先自体、名前解決、該当するルールのどこに問題があるかを確認してください。
たとえば設定の末尾がFINAL,DIRECTの場合、前のルールでプロキシのポリシーに一致しなかったリクエストはDirectで処理されます。これは設定の動作であり、ノードのタイムアウトを示すものではありません。変更前に現在の設定をバックアップし、接続先に適用すべきポリシーを確認してから、該当するルールを調整してください。ルール全体を消去する方法を、通常のトラブルシューティングにしないでください。
7. よくある質問と記録の共有
遅延時間が表示されるのに、接続後もページを開けないのはなぜですか？
まずConnectivity Testの方式を確認し、Home → Global Routingで一時的にProxyを選択して、同じWebページをテストします。接続先に到達できても、認証、DNS、ルール、接続先へのアクセスがすべて成功したとは限りません。
すべてのノードがタイムアウトします。1つずつ追加し直すべきですか？
まず接続をオフにして、ローカルネットワークが正常か確認します。次に既存のノードを1つ選び、設定を変えずにWi-Fiとモバイルデータ通信を切り替えて再テストしてください。すべてのノードを追加し直すより、共通するネットワーク経路、名前解決、時刻の問題を先に確認するほうが有効です。
Hysteria2だけ失敗するのに、TCPテストは成功するのはなぜですか？
Hysteria2はQUICをベースとしており、UDPを使用します。まず元の接続情報にあるポートと認証情報を確認し、ネットワークを切り替えてテストしてください。TCPポートのテストでは、UDPやプロトコル全体のハンドシェイクを検証できません。
サブスクリプションの更新に成功したのに、古いノードが使えないのはなぜですか？
更新に成功したことから分かるのは、サブスクリプションの内容を取得できたことだけです。Homeに戻り、現在選択中の項目が古いままではないか確認し、最新の接続情報にあるアドレス、ポート、プロトコルと照合してください。サブスクリプションの取得成功を、ノードの正常性確認と混同しないでください。
利用中のサービスにどのような情報を伝えればよいですか？
失敗した時刻とタイムゾーン、Wi-Fiまたはモバイルデータ通信の別、プロトコル、テスト方式、3回分のテスト結果、個人情報を伏せたエラーを伝えてください。サブスクリプションURL全体、パスワード、UUID、秘密鍵、認証情報を含むスクリーンショットは送らないでください。
トラブルシューティングが終わったら、Global RoutingとOn Demandを元の設定に戻し、普段使うアプリで動作を確認します。「変更前の条件」「変更した項目」「変更後の結果」の3点を記録してください。同じ現象が起きた際に、すべての設定を変更し直すことなく、効果を確認できた手順を再利用できます。