サービス提供元から入手した設定を読み込み済みで、Shadowrocketでタイムアウトが発生している場合の確認手順です。テストの失敗と実際のリクエストの失敗を切り分け、ネットワークの比較、プロトコル設定、システム時刻を順に確認します。一度に変更する項目は一つだけにし、元の設定を記録しておきましょう。確認後は、ルーティングとOn Demandの設定を元に戻してください。
1. 遅延テストのタイムアウトとリクエストの失敗を切り分ける
Shadowrocketの遅延テストの数値は、選択したテスト方法での結果を示すもので、接続全体の正常性を保証するものではありません。TCPハンドシェイクに成功しても、プロキシ認証、TLSハンドシェイク、接続先へのアクセスが成功するとは限りません。別の方式によるテストがタイムアウトしても、実際のリクエストがすべて失敗するとは限りません。数値だけでなく、テスト方法も記録しておきましょう。
確認を始める前に接続スイッチをオフにし、現在のWi-Fiまたはモバイル通信で通常のWebページを開けることを確認してください。Wi-Fiで認証ページへのログインが必要な場合は、先に認証を完了させます。基本のネットワークが使えない状態でサーバー設定を繰り返し編集しても、問題は解決しません。
- 一部のノードだけタイムアウトする場合：同じネットワークで他の登録済みサーバーが使えるなら、該当項目のアドレス、ポート、サービスの稼働状況を優先して確認します。
- すべてタイムアウトする場合：基本のネットワーク、DNS、テスト方法、サブスクリプションの状態を先に確認します。すぐに各項目の設定を入力し直す必要はありません。
- 遅延テストは正常でもWebページを開けない場合：認証、TLS、Global Routing、および接続先のリクエストに適用されるルールを確認します。
- 特定のWebサイトだけ開けない場合：接続先のドメインとエラーを記録し、そのサイトの問題をプロキシ接続全体の障害と混同しないようにします。
2. 再現可能な接続テストを行う
HomeでSERVERリストのデフォルトサーバーを確認します。グループを開いた、または項目が表示されたというだけで、実際の接続先だと判断しないでください。テスト中はサーバー、ネットワーク、ルーティングモードを同時に切り替えないようにします。そうすると、どの変更が結果に影響したのか判断できなくなります。
-
現在の状態を記録する
Homeでデフォルトサーバー、現在のGlobal Routingの値、接続スイッチの状態を記録します。Settings → On Demandでオンデマンド接続が有効か確認してください。自動再接続が行われる場合は、現在の設定を記録してから一時的にオフにします。
-
遅延テストを実行する
Home → Connectivity Testを使い、テスト方法と結果を記録します。同じ項目を2～3回テストして、継続的なタイムアウトか一時的な失敗かを見分けましょう。一度の結果だけで設定を削除しないでください。
-
実際のリクエストを確認する
デフォルトサーバーを選び、接続スイッチをオンにします。必要に応じてGlobal Routingを一時的にProxyに設定し、Configのルールによる影響を抑えたうえで、接続できることが分かっているHTTPSページを開きます。
-
基本のネットワークを切り替える
サーバーとルーティングモードはそのままにし、Wi-Fiとモバイル通信だけを切り替えます。切り替え後、ネットワークが安定してから再接続し、同じページにアクセスしてください。
-
比較結果を記録する
ネットワークの種類、テスト結果、実際のアクセス結果、エラーの原文をそれぞれ記録します。テスト後はGlobal RoutingとOn Demandを元の状態に戻し、一時的な設定が普段の利用に影響しないようにしてください。
Proxyはプロキシ経由の通信を確認するために使います。Directではリクエストが直接接続されるため、サーバーが使えることの確認にはなりません。Configでは現在の設定に従ってリクエストが処理されます。Sceneを使用中の場合は、該当するシーンが有効になる条件も確認してください。一時的なモード切り替えは原因の特定に使うもので、恒久的な解決策ではありません。
3. プロトコル設定を一つずつ確認する
Homeから該当サーバーの編集画面を開き、サービス提供元から入手した元の情報と項目ごとに照合します。まずType、アドレス、ポートを確認し、その後に認証と通信オプションを確認してください。ドメイン、SNI、Hostは別々の項目です。また、一般的な例で443が使われていても、自分のポートを443に変更しないでください。
| Type | 優先して確認する項目 | 間違えやすい条件 |
|---|---|---|
| Shadowsocks | アドレス、ポート、暗号化方式、パスワード | 暗号化方式はサーバー側の設定と一致させます。プラグインの設定はサーバー側で指定されている場合のみ行ってください。 |
| VMess | UUID、通信方式、サーバー側で必要な認証オプション | WebSocketを使用する場合は、PathとHostも確認します。TLSの設定はサーバー側と一致させてください。 |
| VLESS | UUID、通信方式、Flow（該当する場合） | 別の設定項目のTLSや通信パラメーターを、そのまま流用しないでください。 |
| Trojan | パスワード、ポート、TLS、サーバー名 | アドレスに到達できても、パスワードや証明書名が一致しないと接続できないことがあります。 |
| Hysteria2 | 認証情報、TLS、難読化設定（該当する場合） | UDP経路に依存します。TCPポートのテストだけでは、全機能が使えるか確認できません。 |
| WireGuard | 鍵、Endpoint、インターフェースアドレス、Allowed IPs | UDPを使用します。鍵の不一致やルーティング範囲の誤りがあると、データを転送できません。 |
判断のポイント：複数のネットワークで再現するか確認してから設定を変更する
同じ設定で一方のネットワークだけ失敗する場合は、そのネットワークでのポートとUDPの到達性をサービス提供元に確認してください。両方のネットワークで失敗する場合は、サービスの稼働状況とプロトコル設定をまとめて確認します。ポート、パスワード、TLS設定を同時に変更しないでください。
サブスクリプションでサーバーを管理している場合、読み込み済みの項目を手動で変更しても、次回の更新でサービス提供元の設定に上書きされることがあります。機密情報を伏せて変更前の内容を記録し、該当するサブスクリプションを更新して、更新が成功したことと項目に意図した変更が反映されたことを確認してください。サブスクリプションを取得できても、登録されているすべてのサーバーが使えるとは限りません。取得に失敗しても、保存済みのサーバーがすぐ使えなくなるわけではありません。
4. エラーの原文から失敗した段階を特定する
エラーログは異なるネットワーク層から出力され、接続方式によって文言も変わることがあります。以下はよく見られるエラーの例です。実際に表示された場合に限り、判断材料として使ってください。エラー全文と発生時刻を記録し、すべての失敗を「タイムアウト」とまとめないようにします。
エラー：i/o timeout
原因と対処：ある処理段階で、制限時間内に応答を受信できなかったことを示します。この文言だけでは認証とネットワークのどちらが原因か分かりません。前後のログから失敗した段階を確認し、同じ設定のまま基本のネットワークを切り替えて検証してください。
エラー：connection refused
原因と対処：接続先のホストまたは中継機器によって接続が拒否されています。ポートでサービスが待ち受けていない、またはアクセスが拒否されている場合によく発生します。まずポートを確認し、サービス提供元に待ち受けサービスとアクセス制限を確認してもらいましょう。
エラー：no such host
原因と対処：必要なドメイン名を解決できていません。アドレスの入力ミスやDNSの経路に問題がある可能性があります。元のサーバードメインと照合し、現在のネットワークでの名前解決を確認してください。出所の分からないIPアドレスに安易に置き換えないでください。
エラー：certificate has expired or is not yet valid
原因と対処：証明書の有効期間と現在の検証時刻が一致していません。端末の時計またはサーバー証明書に問題がある可能性があります。まず端末の時刻を正しく設定し、再現する場合はサービス提供元に証明書の有効期間を確認してもらいましょう。
TLS証明書の名前の誤りと、有効期間の誤りは別の問題です。前者はサーバー名、SNI、証明書の対象ドメインを確認します。後者は時刻と証明書の更新状況を確認してください。エラーを隠すために証明書の検証を無効にしないでください。本人性の確認が失われるうえ、サーバー側の設定問題も解決しません。
5. iPhoneのシステム時刻を確認する
TLSでは証明書の有効期間が確認され、VMessの認証にも時刻が関係します。端末の日付や時刻が実際とずれていると、アドレス、ポート、パスワードが正しくても接続できないことがあります。画面に表示されるタイムゾーンの違いだけでシステム時刻の誤りとは限らないため、日付と実際の時刻も確認してください。
- iPhoneの「設定」→「一般」→「日付と時刻」を開き、「自動設定」を確認します。ここで確認するのはシステム設定であり、ShadowrocketのSettingsではありません。
- ネットワークに接続できる状態で「自動設定」をオンにし、年、日付、時刻が正しいことを確認します。管理ポリシーによってスイッチを変更できない場合は、端末の管理担当者に相談してください。
- Shadowrocketに戻り、接続スイッチをオフにしてから、同じサーバーに再接続します。サブスクリプションの更新や設定変更は同時に行わず、同じページにアクセスして再確認してください。
- 時刻が正しいにもかかわらず証明書の期限切れが表示される場合は、エラー内容をサービス提供元に伝え、サーバー証明書を確認してもらいましょう。タイムゾーンを繰り返し変更しても、証明書の有効期間は延びません。
6. 遅延が解消したら実際のルーティングを確認する
Proxyではアクセスできるのに、Configに戻すと失敗する場合は、Configで現在有効な設定とリクエストに適用されるルールを確認します。ルールは順番に評価され、条件の位置やFINALのポリシーによって送信先が変わります。「ルールによってDirectで接続された」ことを、デフォルトサーバーに接続できないことと混同しないでください。
DOMAIN-SUFFIXはドメインのサフィックスに一致します。接続先のドメインに意図したポリシーが適用されているか確認してください。GEOIPはIPアドレスの地理的な位置に基づいて一致します。ドメインのサフィックスを照合するルールではありません。IP-CIDRはIPアドレスの範囲に一致します。ネットワーク範囲が広すぎないか確認してください。FINALは前のルールに一致しなかったリクエストを処理します。最終的なポリシーが意図した内容か確認してください。
Configのルールを変更する前にバックアップを取り、既存のポリシー名を残してください。特定の接続先だけが失敗する場合は、そのリクエストの記録をもとに、ドメイン解決と実際の送信先を確認します。一つの接続先のためにConfig全体を消去しないでください。接続をオフにしても再びオンになる場合は、Settings → On Demandでオンデマンド接続の条件を確認し、自動再接続をスイッチの故障と取り違えないようにします。
7. サービス提供元に確認を依頼するための情報をまとめる
ここまで確認しても解決しない場合は、「使えない」とだけ伝えるのではなく、問題を再現できる記録を提出してください。パスワード、UUID、秘密鍵、サブスクリプションURL全体を公開する必要はありません。これらの情報があると、サービスへのアクセスに使われるおそれがあります。スクリーンショットやログを送る前に、機密情報が含まれていないか確認してください。
- 発生日時：サーバー側のログと照合できるよう、日付、時刻、タイムゾーンを記録します。
- 接続条件：Wi-Fiまたはモバイル通信の別、プロトコルのType、ポート、機密情報を伏せたサーバー識別情報を記載します。
- 比較結果：2種類のネットワークそれぞれについて、テスト方法、タイムアウトの有無、実際にページへアクセスできたかを記載します。
- エラーの記録：エラーの原文と前後の関連情報を提示し、システム時刻を確認済みであることを記載します。
- 変更した内容：サブスクリプションの更新、設定項目の確認、ルーティングの切り替え結果を列挙し、現在の設定を元に戻したかどうかも記載します。
Shadowrocketはクローズドソースの商用アプリで、Appleプラットフォーム向けにApp Storeで提供されています。主にiPhone / iPadで利用でき、システム要件はApp Storeの掲載内容をご確認ください。アプリの買い切り購入に通信サービスは含まれません。利用中のサブスクリプションはサービス提供元から入手してください。通信サービスの稼働状況、認証情報の有効性、サーバー証明書に関する問題は、該当するサービス提供元にご確認ください。この種の問題の確認に、アプリを再購入する必要はありません。