Shadowrocketでタイムアウトが表示されても、接続先の障害とは限りません。利用中の接続情報がある方に向けて、ネットワーク到達性、プロトコル認証、TLS検証、システム時刻の問題を切り分け、ルーティングとサブスクリプションの更新も確認します。一度に変更する項目は一つに絞り、テスト方法・ネットワークの種類・エラー全文を記録すると、変更の効果を判断しやすくなります。
1. テスト条件をそろえ、テストと実際の接続を切り分ける
まずHomeで対象の項目にConnectivity Testを実行し、その後、実際にアクセスしてみます。遅延の数値が示すのは、そのテストで使われた経路と方法の結果です。プロトコル認証、TLSハンドシェイク、接続先サイトへのアクセスがすべて正常だとは判断できません。TCP接続が確立しても、その後の認証で失敗することがあります。また、あるテストがタイムアウトしても、すべての通信ができないとは限りません。
切り分け中は、サブスクリプションの更新、設定の切り替え、DNSの変更、ネットワークの変更を同時に行わないでください。復旧しても原因を特定できなくなります。使用中の設定を複製して保存し、対象項目の名前、プロトコルの種類、Global Routingのモードを記録します。パスワード、UUID、秘密鍵、サブスクリプションURLの全文は公開記録に含めないでください。
-
ネットワークを固定する
同じWi-Fiに接続したまま、通常のインターネット接続が使えることを確認します。Webページでのログインが必要なネットワークでは、先に認証を済ませてください。モバイル通信への切り替えは一旦控えます。
-
対象項目を固定する
Homeで自分の項目を一つ選び、Type、アドレス、Portを記録します。項目の切り替えや、複数項目の一括変更は行わないでください。
-
テスト結果を記録する
HomeでConnectivity Testを実行し、テスト方法、結果、時刻を記録します。繰り返しテストする場合も同じ方法を使い、異なる方法の数値を直接比較しないでください。
-
自動接続の条件を確認する
Settings → On Demandを開き、現在の条件を記録します。自動接続が手動での再現に影響する場合は、On Demandを一時的にオフにし、確認後に元の設定へ戻してください。
-
一度だけ再現する
Homeに戻って接続をオンにし、同じ接続先にアクセスします。スイッチがオンのままになるか、すぐにエラーが出るか、特定のサイトだけ失敗するかを確認してください。
2. 遅延とエラー全文から問題の箇所を絞り込む
遅延テストが繰り返しタイムアウトする場合は、まずアドレス、ポート、ネットワーク経路を確認します。テスト結果があるのに実際のアクセスがすぐ切断される場合は、プロトコル設定とTLSを重点的に確認してください。特定のサイトだけ失敗する場合は、まずリクエストに適用されたルールを確認し、すべての項目を作り直すのは避けましょう。以下はよくあるネットワークエラーの原文です。アプリに表示されるメッセージには、アドレスやポート、前後の情報が加わることがあります。
エラー: Connection timed out
原因：処理が制限時間内に完了しませんでした。ネットワーク経路、接続先からの応答、ハンドシェイクなどが考えられますが、このメッセージだけでは問題の発生箇所を特定できません。
対処：まずアドレスとPortを確認します。ほかの設定は変えずに、Wi-Fiとモバイル通信を一度切り替え、同じ方法でテストした結果を比較してください。
エラー: Connection refused
原因：接続要求が明示的に拒否されています。接続先のポートで待ち受けていない場合や、ネットワーク機器が接続を拒否している場合などに起こります。パスワードが間違っている直接の証拠ではありません。
対処：Portを契約先から提供された情報と照合します。一致している場合は、そのアドレスとポートが現在も使用中か、契約先に確認してください。
エラー: certificate has expired
原因：証明書の有効期間の検証に失敗しています。接続先の証明書が期限切れのほか、端末の日付が実際の日時から大きくずれている場合もあります。
対処：まずシステムの自動時刻設定を確認してください。時刻が正しいのにエラーが続く場合は、契約先に証明書の確認を依頼します。証明書検証を無効にして回避しないでください。
ネットワークを切り替えて復旧しても、問題がネットワーク経路に関係していたと分かるだけで、特定の通信事業者が原因とは断定できません。どちらのネットワークでも失敗する場合も、設定ミスは否定できません。「一方のネットワークだけ失敗」「両方で失敗」「特定の接続先だけ失敗」などに分けて記録し、次の確認に進みましょう。
- すべての項目で失敗する：端末の基本的なネット接続、ネットワーク認証、現在のルーティングモード、時刻を確認します。
- 一つの項目だけ失敗する：その項目のアドレス、ポート、認証情報、接続先の状態を優先して確認します。
- 特定の種類のアプリだけ失敗する：実際のリクエストがTCPとUDPのどちらを使うか、想定したルールが適用されているかを確認します。
3. Type、Port、プロトコル固有の設定を一つずつ確認する
Homeで対象項目の編集画面を開き、元の接続情報を基準に照合します。Typeは接続先と一致している必要があります。問題の切り分け目的でVMessをVLESSに変更するようなことはしないでください。アドレス欄には指定された形式のアドレスだけを入力し、共有テキスト全体やWebページのパス、余分な空白を混ぜないようにします。
Portには接続先で実際に待ち受けているポートを入力します。経験則で一律に置き換えられる値ではありません。たとえば、元の設定が8443なら、TLSを有効にしたからといって勝手に443へ変更しないでください。以下の数値はプロトコルとポートの関係を説明する例であり、接続可能なサービスを案内するものではありません。
| Type | 確認する項目 | よくある誤り |
|---|---|---|
| Shadowsocks | アドレス、Port、暗号化方式、パスワード。プラグインを使う場合は、その設定も確認します。 | パスワードだけを変更し、暗号化方式が接続先と一致していないことを見落とす。 |
| VMess / VLESS | UUID、通信方式、元の設定で指定されたTLS、Host、Pathなどの項目。 | UUIDさえ正しければ問題ないと思い、トランスポート層の設定を見落とす。 |
| Trojan | パスワード、TLS、Server Name、元の設定で指定された通信方式。 | パスワードを別の認証欄に入力する、または証明書に対応するドメイン名を入力し忘れる。 |
| Hysteria2 | 認証情報、TLS、Server Name、UDPの経路。 | TCPテストに成功したので、UDPの経路も使えると思い込む。 |
| WireGuard | ローカル秘密鍵、相手側の公開鍵、Endpoint、アドレス、ルーティング関連の設定。 | 鍵の役割を逆に入力する、またはEndpointだけ確認してルーティングを見落とす。 |
すべてのプロトコルで表中の項目を使うわけではありません。現在のTypeに表示され、元の接続情報で指定されている項目だけを確認してください。サブスクリプションから追加した項目にローカル変更を加えている場合は、更新前に変更内容を記録します。更新後に編集画面をもう一度開き、サブスクリプションの古い値で修正内容が上書きされていないか確認してください。
4. TLS、Server Name、システム時刻を確認する
TLSエラーが起きたら、まず項目の編集画面でTLS設定とServer Name（SNI）を確認します。接続先アドレスがIPアドレスでも、証明書はドメイン名に対して発行されていることがあります。その場合は、アドレス欄の値をそのまま使うのではなく、元の設定に従ってServer Nameを入力してください。証明書の検証に使う名前と、ネットワークリクエストのHostは、自由に入れ替えられる項目ではありません。
WebSocketを使う場合、PathとHostは接続先の指定に合わせる必要があります。Pathの大文字・小文字、先頭のスラッシュ、付加パラメーターがリクエストに影響することがあります。よく見かけるパスだからといって、独自に補わないでください。接続先から指定されていない項目も、推測で追加しないようにします。
- 項目の編集画面でTLS、Server Name、通信方式、Host、Pathを一つずつ照合します。変更を保存したら、同じ接続先で再テストしてください。
- iPhoneまたはiPadで「設定 → 一般 → 日付と時刻」を開き、「自動設定」と現在の日付、時刻、タイムゾーンが適切か確認してください。
- 「自動設定」を変更できない場合は、デバイス管理の制限やシステム設定の条件を確認します。エラーを回避するために、証明書の有効期間内の過去の日付へ手動で変更しないでください。
- 時刻を合わせたら、接続を確立し直します。端末の時刻が正しいのに証明書が期限切れ、または名前が一致しない場合は、エラー全文を記録し、契約先に証明書設定を確認してください。
5. ルーティング、DNS、サブスクリプション更新の問題を切り分ける
設定とTLSの確認後、Home → Global Routingを確認します。Proxy、Direct、Config、Sceneは、遅延テストの4種類の方法ではなく、通信の処理モードです。切り分けのためにProxyへ一時的に切り替え、選択したプロキシ経路を確認できます。テスト後は元のモードに戻し、一時的な切り替えを恒久的な解決策にしないでください。
- Proxy：プロキシ経路を確認する場合は、実際に選択されている項目やポリシーグループのメンバーを確認し、想定とテスト対象がずれていないか確かめます。
- Direct：直接接続の経路を確認します。このモードでアクセスできても、プロキシ項目が正しいとは限りません。
- Config：Configで現在使用中の設定を開き、リクエストが先にあるルールに一致していないか確認します。
- Scene：選択中のSceneの設定を確認します。ProxyやConfigと同じ結果になるとは限りません。
Configでは、DOMAIN-SUFFIX、IP-CIDR、GEOIPなどのルールごとに一致条件が異なり、FINALはそれ以前のルールに一致しない場合のフォールバックとして使われます。ルールは上から順に評価されます。対象ドメインが前のDIRECTまたはREJECTルールに一致している場合、後ろのFINALを変更しても、そのリクエストの判定は変わりません。まず実際のリクエスト記録を確認してからルールを変更してください。サイトが一つ開けないだけで設定全体を削除する必要はありません。
DNSの問題も個別に確認します。ドメイン名では接続できず、IPアドレスに変更すると結果が変わった場合、名前解決経路を調べる手掛かりにはなりますが、IPアドレスを恒久的な代替として使うことはできません。TLSでは元のServer Nameが必要な場合もあります。DNS、SNI、アドレスを同時に変更すると、差が生じた原因を切り分けられなくなります。
遅延テストに数値が出るのに、Webページが開かないのはなぜ？
Connectivity Testの方法を記録し、同じ接続先に同じ方法でアクセスします。Global Routingと適用されたルールを確認してください。テストに成功しても、特定の段階で到達できたことしか示しておらず、認証、TLS、接続先からの応答まで確認できたとは限りません。
既存の項目は使えるのに、サブスクリプションの更新がタイムアウトするのはなぜ？
サブスクリプションの更新でアクセスするのはサブスクリプションURLであり、既存項目のサービスポートではありません。Homeで自分のサブスクリプションを更新し、URLがまだ有効か確認してください。既存のプロキシ接続が使え、サブスクリプションURLへのアクセスにその経路が必要な場合は、Settings → SubscribeでUpdate via Proxyを確認してから、もう一度試してください。
Wi-Fiではタイムアウトするのに、モバイル通信では正常。パスワードを入れ直すべき？
まずパスワードは変更しないでください。同じ項目とテスト方法を使い、Wi-FiのWeb認証、ネットワーク制限、UDPの到達性を確認します。特定のネットワークでだけ失敗する場合は設定を保ったまま、ネットワーク経路の違いを調べてください。
手動で切断しても毎回また接続される。安定して再テストするには？
Settings → On Demandで自動接続の条件を確認します。条件を記録してからOn Demandを一時的にオフにし、Homeに戻って手動で再テストしてください。調査が終わったら必要な条件を戻し、自動接続によってテスト状態が変わらないようにします。
6. 解決しない場合は、必要最小限の情報を記録する
ここまで確認しても解決しない場合は、「接続できない」とだけ伝えるより、再現できる最小限の情報を契約先に共有すると、原因を特定しやすくなります。エラーがサブスクリプション更新、Connectivity Test、実際のアクセスのどこで起きたかを分けて記録し、最後に変更した項目も伝えてください。ログは該当時刻の前後に必要な部分だけを抜き出し、設定全体を公開しないでください。
- 利用環境：端末の種類、システムに表示されるバージョン、Wi-Fiまたはモバイル通信、自動時刻設定の状態。
- 対象：プロトコルのType、識別情報を伏せた項目名、使用中のPort。パスワード、UUID、秘密鍵、サブスクリプショントークンは含めないでください。
- 症状：エラー全文、発生時刻、テスト方法、ネットワーク切り替え前後の違い。
- ルーティング：Global Routingのモード、現在のConfigまたはScene、確認済みの適用ルール。
- 実施した操作：設定の確認結果、TLSとServer Nameが一致しているか、時刻を合わせた後に再接続したか。
復旧したら、元のOn Demand条件を有効に戻し、普段使っているGlobal Routingに戻して、同じ接続先で再テストしてください。有効だった変更は残し、診断のためだけに加えた一時設定は取り消します。証明書検証の無効化や、確認していないアドレスへの置き換えは残さないでください。