本記事は、ご自身でサービス事業者、サーバー情報、またはサブスクリプションを用意している方向けです。テストのタイムアウトと実際のリクエスト失敗を切り分け、ネットワーク、プロトコル設定、システム時刻、ルーティング設定の順に確認します。一度に変更するのは1項目だけにし、元の値を控えておきましょう。Shadowrocketの接続スイッチの状態、テスト結果、Webページにアクセスできるかどうかは、それぞれ個別に確認してください。
1. まず遅延テストを行い、失敗箇所を切り分ける
timeoutは、処理が待ち時間内に完了しなかったことを示します。パスワードの誤り、サーバーの停止、アプリの異常を直接示すものではありません。HomeのConnectivity Testから診断できますが、テスト方法によって確認される範囲は異なります。使用したテスト方法を記録し、同じ項目を同じ方法で比較してください。異なるテスト方法の数値を混同しないようにしましょう。
ポートへの接続に成功しても、プロキシ認証が完了したとは限らず、接続先のWebページから内容が返るとも限りません。逆に、あるテストに失敗したからといって、実際のリクエストがすべて失敗するとは限りません。まず接続スイッチをオフにし、現在のWi-Fiまたはモバイル通信で通常どおりアクセスできることを確認します。次に既存の項目を選んでテストし、最後に接続をオンにして、普段利用できるWebページにアクセスします。
-
現在の状態を記録
Homeで選択中の項目、Global Routingの現在の選択肢、Connectivity Testのテスト方法、エラー表示を記録します。サーバーログと照合できるよう、テストした時刻も控えてください。
-
ネットワーク接続を確認
Homeの接続スイッチをオフにし、ローカルネットワークで先にログイン認証が必要か確認します。インターネット接続が復旧するまでは、サーバーのプロトコル設定を変更しないでください。
-
テストを繰り返す
同じ項目、同じテスト方法で3回続けてテストします。成功、timeout、その他のエラーをそれぞれ記録し、失敗が続くのか、断続的に発生するのかを確認してください。
-
ネットワークを切り替える
可能であれば、Wi-Fiとモバイル通信のそれぞれで再テストします。ネットワークだけを切り替え、項目、プロトコル、Global Routingは同時に変更しないでください。
-
リクエストを確認
Homeの接続スイッチをオンにして、同じ接続先のページを開きます。「テストは失敗したがページは表示できる」場合と「テストもページ表示も失敗する」場合を分けて記録してから、設定の確認に進みます。
2. サーバーアドレス、ポート、プロトコル設定を確認
Homeから該当項目の編集画面を開き、まずTypeが手元の元の設定と一致していることを確認してから、アドレス、ポート、認証情報を確認します。接続できないからといって、VLESSをVMessに変更したり、Hysteria2をTrojanに変更したりしないでください。クライアントとサーバーで同じプロトコルを使用する必要があります。
| 確認項目 | 確認する内容 | 間違えやすいポイント |
|---|---|---|
| アドレスとポート | ドメインの綴り、IPアドレス、ポート番号 | ポート443はあくまで一例です。これだけでプロトコル、TLS、認証の設定が正しいとは限りません。 |
| Shadowsocks | サーバー指定の暗号化方式とパスワード | パスワードだけでなく、暗号化方式も一致している必要があります。 |
| VMess / VLESS | UUID、転送方式、および設定で指定されたTLS、Host、Pathなどの項目 | UUIDが正しくても、転送経路やハンドシェイクの設定が誤っていれば接続できません。 |
| Trojan | パスワード、TLS設定、サーバー名 | 接続先アドレスと証明書で検証される名前は異なる場合があります。元の設定を確認してください。 |
| Hysteria2 | 認証情報、TLSパラメータ、UDP経路に到達できるか | TCPポートの確認だけでは、UDPを使うプロトコルの検証にはなりません。 |
| WireGuard | 鍵、Endpoint、ポート、アドレス、ルーティング設定 | TCPハンドシェイクの結果から、WireGuardのUDPトンネルの状態を判断しないでください。 |
項目をコピーするときは、先頭や末尾の空白、文字の抜け、全角記号に注意してください。元の設定でポートが8443と指定されている場合、「直す」つもりで443に変更してはいけません。新しいポートで同じサービスがサーバー側に用意されていなければ、設定の不一致が増えるだけです。TLS関連のエラーを証明書検証の無効化で回避せず、名前、時刻、証明書の設定を確認してください。
まとめ:失敗したレイヤーに応じて次の確認を行う
特定の項目だけ失敗し続ける場合は、その項目の元の設定を優先して確認します。同じ項目群が特定のネットワークだけで失敗する場合は、まずそのネットワークの接続条件を確認してください。どちらの場合も、ルールをむやみに書き換えないでください。
3. エラー表示に応じて確認箇所を絞る
テスト一覧には簡略化された状態だけが表示される場合があります。詳細なエラーは接続ログやご自身のサーバーログに記録されることもあります。以下はネットワーク診断でよく見られるエラー表記ですが、Shadowrocketの同じ場所に毎回表示されるとは限りません。実際に表示された文言を省略せず記録し、すべての失敗を「ノードのタイムアウト」とひとまとめにしないでください。
エラー:timeout
原因と対処:今回の処理が待ち時間を超過しています。この表示だけでは失敗箇所を特定できません。同じ項目を再テストし、別のローカルネットワークでの結果と比較してから、アドレス、ポート、プロトコルの要件を確認してください。
エラー:connection refused
原因と対処:接続先のポートから明示的に拒否されたことを示す場合が多く、サービスが待ち受けていない、またはアクセスが拒否されている可能性があります。ポートが元の設定と一致しているか確認し、ご自身のサービス事業者またはサーバー管理者に稼働状況を確認してください。
エラー:no such host
原因と対処:接続先の名前を解決できていません。サーバードメインの綴りとローカルネットワークの接続状況を確認してください。ご自身で管理するドメインの場合は、該当するDNSレコードが存在するかも確認します。
エラー:TLS handshake timeout
原因と対処:TLSハンドシェイクが制限時間内に完了していません。TLS設定がサーバーの要件を満たしているか、サーバー名が正しいかを確認し、ネットワーク経路も比較してください。すぐにパスワードの問題と決めつけないでください。
ご自身のサービス事業者に問い合わせる際は、発生時刻とタイムゾーン、ネットワークの種類、プロトコル、テスト方法、エラーの原文、継続的な障害か断続的な障害かを伝えれば十分です。パスワード、UUID、秘密鍵、サブスクリプションURL全体は機密情報のため、公開スクリーンショットや公開ログに含めないでください。
4. システムの日付、タイムゾーン、自動接続を確認
システム時刻のずれは、証明書の有効期間の判定や一部プロトコルの認証に影響することがありますが、すべてのtimeoutの共通原因ではありません。iPhoneまたはiPadのシステム設定で、Settings → General → Date & Timeを開き、Set Automaticallyを確認してください。管理対象のデバイスでは該当項目が制限される場合があるため、デバイス管理のルールに従ってください。
- まず日付と時刻を確認:年、月日、時、分に大きなずれがないか確認してください。ステータスバーの時刻を見るだけでは十分ではありません。
- 次にタイムゾーンを確認:タイムゾーンはローカル表示やログとの照合に影響します。表示されるタイムゾーンが異なるだけで、デバイスの絶対時刻が誤っているとは限りません。ログを報告する際はタイムゾーンも記載してください。
- 時刻を修正した後に再接続:時刻を直したら、Homeの接続スイッチを一度オフにしてからオンにし、同じ方法で再テストします。修正前の結果を使って判断しないようにしてください。
- 自動接続の影響を切り分ける:手動で切断した後に再接続が試みられる場合は、ShadowrocketのSettings → On Demandで現在の設定を確認し、元の状態を記録してください。必要であれば、手動テストの間だけ一時的に無効にします。
5. 最後にGlobal Routingとルールの適用先を確認
接続テストに成功してもページを開けない場合は、Home → Global Routingを確認します。Proxy、Direct、Config、Sceneはそれぞれ異なるルーティング方式であり、異なるプロトコルではありません。Proxyはプロキシ可能な通信を全体的にプロキシ経由で処理し、Directは直接接続します。Configは選択中の設定にある振り分けルールを使用します。Sceneでは現在のシーンと関連設定を確認してください。Configの別名ではありません。
ルールの影響を切り分けるには、まず元の選択肢を記録し、一時的にProxyへ切り替えて、同じサーバーと接続先で試します。確認後は元の方式に戻してください。Proxyでは使えてConfigでは使えない場合は、Configで使用中の設定、ルールの順序、ポリシーの振り分け先を優先して確認します。これで調査範囲を絞れますが、DNSや接続先の問題がすべて解消したことを意味するわけではありません。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY
上記はルールのマッチ方法を説明する例であり、設定全体を置き換えるためのものではありません。DOMAIN-SUFFIXは指定したドメインとそのサブドメインに一致します。IP-CIDRは接続先のIPアドレス範囲に一致します。例の192.0.2.0/24はドキュメント用のアドレス範囲です。no-resolveは、このIPルールの照合時にドメインを積極的に名前解決しないことを示します。GEOIPはIPアドレスの地理的な割り当てに基づいて一致し、FINALはそれ以前のルールに一致しなかったリクエストを処理します。
- ルールは上から順に評価され、最初に一致したルールのポリシーが適用されます。優先して処理する項目は上位に配置してください。
DIRECT、PROXY、REJECTは、それぞれ直接接続、プロキシ、拒否を表します。接続先がREJECTに一致している場合は、サーバーのタイムアウトとして調べる必要はありません。- カスタムポリシーグループを使っている場合は、ルールが参照する名前と、グループ内の選択項目を確認してください。テストに成功したサーバーが、そのルールで実際に使われる送信先とは限りません。
- 一部のドメインだけが失敗する場合は、その接続先に適用されたルールとポリシーを記録してください。FINALをむやみに移動して、ほかのリクエストに影響を与えないようにしましょう。
6. サブスクリプション更新と接続失敗に関するよくある質問
サブスクリプションの更新がタイムアウトしました。保存済みの項目はすべて使えなくなっていますか?
必ずしもそうとは限りません。サブスクリプションの更新は設定データを取得する処理で、保存済み項目の接続テストとは別のリクエスト経路です。まずHomeに保存されている項目をテストし、次にご自身のサブスクリプションが有効か確認してください。既存のプロキシ経由で更新する場合は、接続が使えることを先に確認してから、Settings → Subscribe → Update via Proxyを確認します。すべての項目が使えない状態では、この設定を有効にしても接続は復旧しません。
遅延の数値が表示されるのに、Webページを開けないのはなぜですか?
まずConnectivity Testで使用したテスト方法を確認してください。ポートに到達できても、認証、TLS、接続先の名前解決、接続先からの応答がすべて成功したとは限りません。プロトコル設定を順に確認し、同じ接続先をProxyとConfigで試した結果を比較してください。1つのミリ秒表示だけで通信経路全体を判断しないようにしましょう。
Wi-Fiだけタイムアウトし、モバイル通信では正常です。パスワードを変更すべきですか?
パスワードやほかの項目は変えず、まず同じ項目で結果を繰り返し比較してください。Wi-Fiでログイン認証が必要か、使用するポートやUDPがネットワークで制限されていないかを確認します。ネットワークによる違いを管理者に伝えてください。むやみにパスワードを変更すると、正常に使えていた設定まで壊すおそれがあります。
サブスクリプション更新後にタイムアウトする場合、すぐに削除して追加し直すべきですか?
まず更新前後のアドレス、ポート、Type、転送設定を比較し、選択中の項目が変わっていないか確認してください。元の情報を保存してから、ご自身のサービス事業者に変更内容を確認します。すぐに削除すると比較に必要な情報が失われ、サーバー側が応答していない問題も解決できません。
まとめ:再現可能な最小限の記録を残す
確認後は、「同じ項目、同じテスト方法、2種類のネットワーク、1つの接続先、一度に変更するのは1項目だけ」という条件で結果を記録してください。次に必要なのがローカル設定の修正、ネットワーク条件の確認、ご自身のサービス事業者へのサーバー側の調査依頼のどれかを判断しやすくなります。