Shadowrocketの遅延表示、VPNの接続状態、Webページが開くかどうかは、それぞれ異なる状況を示します。利用中のサービスと設定があり、timeoutや接続失敗が発生している場合は、まず設定を残してテストを繰り返し、プロトコル・ポート・ルーティングを確認します。その後、システム時刻やネットワークによる違いを調べ、すべての原因を接続先に結びつけないようにしましょう。
1. テストのタイムアウト・トンネル接続・Webページの読み込み失敗を切り分ける
まず、どの段階で失敗しているかを確認し、その段階に応じた設定を見直します。Homeで項目がtimeoutと表示されても、そのテストが制限時間内に完了しなかったことを示すだけです。システムにVPNの表示が出ても、接続先での認証が完了したことや、すべてのWebサイトにアクセスできることを意味するわけではありません。テスト方法、選択中の項目、Global Routingの設定、アクセス先をあわせて記録してください。
この流れは、確認する段階を切り分けるためのものです。すべての通信が必ず同じ順序で処理されるという意味ではありません。ドメイン名の解決は端末側または接続先側で行われる場合があり、ルールもドメイン名、IPアドレスなどの条件に基づいて通信経路を選択します。遅延テストの結果ひとつだけでは、これらすべてを判断できません。
- テストだけがタイムアウトする場合：同じ条件でテストを繰り返し、その後に実際の通信を試します。すぐに設定を削除しないでください。
- 接続スイッチをオンのまま維持できない場合：システムのVPN許可、ほかのVPN接続、On Demandを確認してから、接続先の設定を見直します。
- 接続はオンになるが、すべての接続先にアクセスできない場合：選択中の項目、Global Routing、認証、DNSを確認します。
- 特定のドメインだけ接続できない場合：そのドメインに適用されるルール、名前解決の結果、接続先の状態を優先して確認します。
2. Homeで遅延テストを繰り返し、比較条件をそろえる
Homeで、既存の設定のうちどの項目をテストしているか確認し、名前とプロトコルを記録します。同じネットワークで同じ項目を、約10秒間隔で3回続けてテストしてください。テストの場所や方法は、現在のアプリ画面に表示される内容に従います。TCPテストを使った場合、主にTCP接続の確立状況がわかりますが、UDPを使うプロトコルの通信が正常だとは判断できません。
- Wi-Fiの接続と認証が完了していること、またはモバイルデータ通信が利用できることを確認します。Shadowrocketの接続を一時的にオフにして、ブラウザから普段直接アクセスできるページを開き、通常のネットワーク接続を確認します。
- Homeに戻り、同じ項目を同じ方法でテストして、3回分の結果を記録します。テストのたびにポート、DNS、ルーティング設定を同時に変更しないでください。
- その項目を選んで接続をオンにし、決めた接続先にアクセスします。すぐにエラーが出るのか、長時間読み込みが続くのか、ページの一部だけ読み込めないのかを記録してください。
- ほかに利用できる項目がある場合は、同じネットワーク、同じ接続先で比較できます。異なるテスト方法で得た数値をそのまま並べて比較しないでください。
| 記録例 | 判断できること | 次の手順 |
|---|---|---|
| 3回ともtimeout | テストが継続して失敗しているが、原因はまだ特定できていない | アドレス、ポート、ネットワークからの到達性を確認する |
| 120 ms、timeout、135 ms | 結果が不安定。数値は記録例です | 別のネットワーク接続に切り替えて、同じテストを繰り返す |
| TCPテストは成功するが、Webページを開けない | ポートへの接続が確立しても、認証に成功したとは限らない | プロトコル設定、TLS、ルーティングを確認する |
| Webページは表示できるが、特定のテストがタイムアウトする | テストの経路と実際の通信状況が一致していない | テスト方法を確認し、その結果だけを根拠に設定を書き換えない |
結論：条件をそろえてから、問題の範囲を切り分ける
同じ項目がWi-Fiでは失敗し、モバイルネットワークでは成功する場合は、まずWi-Fiの経路や接続制限を確認します。パスワードの再入力とDNSの変更を同時に行うと、どの変更が結果に影響したのか判断できません。
3. プロトコル、サーバーアドレス、ポートをひとつずつ確認する
Homeから既存項目の編集画面を開き、手元に保存した元の設定と各項目を照合します。表示名はメモにすぎず、サーバーアドレスやプロトコルが正しいことの証明にはなりません。ポートは接続先で待ち受けているポートと一致させます。元の設定が443なら443のままにし、別の設定で8443が使われていても、その値を流用しないでください。443だからといって、その項目が必ずTLSを使うとは限りません。
| プロトコル | 優先して確認する項目 | 間違えやすい点 |
|---|---|---|
| Shadowsocks | サーバーアドレス、ポート、暗号化方式、パスワード | 暗号化方式も接続先と一致させる必要があります。パスワードだけを確認しても不十分です。 |
| VMess / VLESS | UUID、通信方式、元の設定で指定されているTLSパラメータ | WebSocketのHostとPathは、サーバーアドレスと同じものではありません。 |
| Trojan | パスワード、ポート、TLS Server Name | IPアドレスに変更しても、証明書で必要となるドメイン情報は正しく設定する必要があります。 |
| Hysteria2 | 認証情報、TLSパラメータ、UDPの通信経路 | TCPポートのテストでは、UDPの通信経路を検証できません。 |
| WireGuard | PrivateKey、接続先のPublicKey、Endpoint、アドレス、AllowedIPs | 鍵の役割、UDPの到達性、ルーティングの範囲をそれぞれ確認します。 |
ドメイン名、TLS Server Name、WebSocket Hostは同じ場合もあれば、元の設定で異なる値が指定されている場合もあります。「統一」するためにすべて置き換えないでください。Pathのスラッシュやクエリ文字列も含め、元の内容をそのまま保持します。設定をコピーする際は、先頭や末尾の空白、改行、途中で切れた認証情報に注意してください。秘密鍵、パスワード、完全なサブスクリプションURLを公開記録に貼り付けないでください。
4. エラーの原文から原因を探り、timeoutだけに注目しない
アプリに表示される接続記録やログから、今回のリクエストに対応するエラーの原文と発生時刻を残します。以下はネットワーク接続でよく見られるエラーの例です。実際の表現はプロトコル、下位レイヤーのエラー、アプリ画面によって異なる場合があります。該当する表示がない場合は、その種類の障害が発生したと決めつけないでください。
エラー：timeout
原因と対処：処理が制限時間内に完了していません。名前解決、接続、ハンドシェイクなどが関係している可能性があります。まずログのどの段階で発生したかを確認し、同じ設定のままネットワークを切り替えて再テストしてください。
エラー：connection refused
原因と対処：接続先または途中の機器が接続を明示的に拒否しています。アドレスとポートを確認し、利用中のサービス提供元に、該当サービスが待ち受け中か問い合わせてください。
エラー：no such host
原因と対処：ドメイン名を有効なアドレスに解決できていません。ドメイン名の入力、現在のDNS、基本的なネットワーク接続を確認し、そのドメインが引き続き有効かも確かめてください。
エラー：certificate has expired or is not yet valid
原因と対処：証明書の有効期間と現在時刻が一致していません。まずシステムの日付と時刻を正確に設定します。時刻が正しいのにエラーが続く場合は、接続先の証明書の有効期間を確認してください。
同じログの中で、接続の再試行が記録されたあと、最後にtimeoutとしてまとめられる場合があります。最後の1行だけでなく、前後のエラーも残してください。サブスクリプションの更新に失敗しても、保存済みの項目で接続できる場合は、それぞれ別の問題として記録します。サブスクリプションの取得失敗は、既存の接続先が使えなくなったことを意味しません。
5. Global Routing、Config、DNSを確認する
HomeのGlobal Routingで、現在のルーティング方法を確認できます。Proxy、Direct、Config、Sceneは同じスイッチではありません。Directは直接接続、Configは現在の設定ルールに基づく経路選択です。Sceneを使用している場合は、シーン内の設定も確認してください。トラブル対処を始める前に現在の値を記録し、必要に応じて一時的にProxyを選んで決めた接続先と比較します。テスト後は元の設定に戻してください。
- Homeで現在選択されている項目と、Global Routingの元の設定を記録します。テスト中にDirectが選択されたままになっていないか確認してください。
- Configを使用している場合は、Configで現在有効な設定ファイルを確認します。対象のドメイン名またはIPアドレスに適用されるルールと、対応するポリシーが有効かを調べてください。
- Sceneを使用している場合は、シーンで実際に使われているルーティングとポリシーを確認します。シーン名だけで通信経路を判断しないでください。
- 「接続先サーバーのドメイン名を解決できない」場合と、「アクセス先Webサイトのドメイン名を解決できない」場合を区別します。前者はプロキシ接続の確立前に失敗する可能性があります。後者は、設定内のDNSと実際の接続記録をあわせて確認してください。
以下はルール構文の例であり、既存の設定を置き換えるための修復用ファイルではありません。ルールは通常、上から順に照合されます。先に一致したルールがあると、それ以降のルールは今回の選択に使われない場合があります。DOMAIN-SUFFIXはドメインのサフィックス、IP-CIDRとGEOIPはIPアドレスに関する条件に使います。FINALは、それ以前のルールに一致しなかった場合のフォールバックです。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYno-resolveは、このIPルールの照合時にドメイン名の解決を積極的に行わないことを示します。設定全体のDNSを無効にする意味ではありません。決めた接続先がProxyでは利用でき、Configに戻すと失敗する場合は、接続先のパスワードを再変更するのではなく、ルールとポリシーを優先して確認してください。ひとつのドメインを直すために、すべてのルールを削除しないでください。
6. 最後にシステム時刻、ネットワーク経路、On Demandを確認する
時刻が正しくないと、証明書の有効期間の判定や、時刻確認を伴う認証に影響する場合があります。iPhoneまたはiPadのシステム設定で「一般」→「日付と時刻」を開き、「自動設定」と実際の日付、時刻、タイムゾーンを確認してください。重要なのはシステム時刻が正確であることです。タイムゾーンの表示が異なるだけで、必ずしも障害になるわけではありません。端末管理の制限で設定を変更できない場合は、その端末の管理要件に従ってください。
- Wi-Fiとモバイルネットワークの比較：同じ項目、接続先、ルーティング設定で、それぞれ1回ずつテストします。片方のネットワークだけで失敗する場合は、そのネットワークのDNS、アクセス制限、UDPの到達性を優先して確認してください。
- ネットワークの認証：ホテル、学校、公共のWi-Fiでは、先にWebページでの認証が必要な場合があります。基本的なネットワーク接続が許可されていない状態では、プロトコル設定を変更しても接続できないことがあります。
- On Demand：Settings → On Demandで、オンデマンド接続の条件を確認します。手動で切断してもすぐ再接続する場合や、ネットワークを切り替えたときに状態が自動で変わる場合は、該当する条件を一時的に無効にし、手動テスト後に元へ戻してください。
- システムのVPN状態：ほかのVPN接続が通信を引き受けていないか確認してください。用途がわからないまま、端末管理の設定を削除しないでください。まず、実際に有効になっている接続を確認します。
- サブスクリプションの更新：利用できる既存の項目と設定のバックアップを残してください。元のサブスクリプション内容が変更されたと確認できた場合に限り更新し、接続のトラブル対処と設定の置き換えを一度に行わないようにします。
結論：設定全体ではなく、最小限の再現情報を共有する
復旧しない場合は、発生時刻、接続ネットワーク、プロトコル、ポート、3回分のテスト結果、個人情報を伏せたエラー部分を、利用中のサービス提供元に伝えてください。パスワード、PrivateKey、完全なUUID、サブスクリプショントークンを公開画像に含めないでください。
7. よくある質問と復旧後の確認
遅延に数値が表示されるのに、Webページが開かないのはなぜ？
まずテスト方法を確認します。TCPテストの成功が示すのは、そのテストでポート接続が確立したことだけです。Homeに戻って選択中の項目とGlobal Routingを確認し、実際のリクエストが認証、TLS、DNS、ルールのどの段階で失敗しているか調べてください。
Wi-Fiだけタイムアウトし、モバイルネットワークでは正常です。再インストールが必要？
まず再インストールはせず、同じ設定で違いが再現することを確認し、Wi-Fiの認証、DNS、ネットワーク制限を調べてください。再インストールしても、接続ネットワークによるポートやUDP経路の制限は直接解消できません。
サブスクリプションの更新後に接続できなくなりました。元の項目をすべて削除してもいい？
まず元の設定を残し、更新前後のアドレス、ポート、プロトコル設定を照合してください。リストが空、または項目が欠けている場合は、先にサブスクリプションの取得問題を解決します。バックアップがない状態で元の項目を削除すると、比較に使える記録が失われます。
復旧後に、どの設定を変更すればいい？
トラブル対処を始める前のGlobal RoutingとOn Demandの設定に戻し、普段アクセスする接続先でもう一度テストします。実際に有効だった修正は残し、一時的な比較用の設定は元に戻してください。今回の障害につながった項目やネットワーク条件も記録します。
トラブルの切り分けは「ある項目を変更すると、再現性のある結果の変化が起きる」ことを確認して完了です。スイッチが点灯しただけでは、解決したとはいえません。2種類のネットワークで基本的な通信ができるのに、すべての既存項目が失敗する場合は、共通する設定、システム時刻、接続先の状態をまとめて確認します。特定の接続先だけ失敗する場合は、その接続先の名前解決とルールまで原因を絞り込んでください。