自分で利用しているサービスとサブスクリプションがあり、Shadowrocketでタイムアウトや接続失敗が起きた場合に役立つ手順です。まず、端末のネットワーク接続、テスト結果、実際のプロキシ通信を切り分けます。次に、アドレス、ポート、認証情報、TLS、システム時刻を順に確認し、最後にルールとネットワークを比較して原因の範囲を絞り、後から確認できる記録を残します。
1. テストのタイムアウトと実際の接続失敗を区別する
遅延テストで数値が表示されても、そのテストで確認できた通信経路が応答したことを示すだけです。すべてのWebサイト、認証処理、通信方式が利用できるとは限りません。反対に、一度タイムアウトしただけでサーバーの停止を断定することもできません。テスト方法、接続先、ネットワーク状態、サーバー側の制限などが結果に影響します。
Shadowrocketの接続スイッチがオンになっていることは、システムのVPNトンネルが確立済み、または確立中であることを示します。リモートサーバーの認証が完了したという意味ではありません。切り分けでは「スイッチをオンの状態に保てるか」「テストに応答があるか」「実際のリクエストが成功するか」をそれぞれ記録し、まとめて「接続できない」と判断しないでください。
- ネットワーク自体に問題がある：Shadowrocketをオフにしても、直接アクセスできることが分かっているWebページを開けない場合は、Wi-Fi、モバイルデータ通信、ネットワークのログインページを先に確認します。
- テストに失敗する：Homeでテストがタイムアウトしても、実際のアクセスをまだ確認していないなら、判断できるのはテスト段階までです。
- プロキシ経由のリクエストに失敗する：通常のネットワーク接続は正常で、サーバーを選択しても実際のリクエストが失敗する場合は、設定項目とログを確認します。
- 特定の接続先だけ失敗する：ほかの接続先は正常で、特定のドメインだけ問題が起きる場合は、その接続先、DNS、ルーティングルールを優先して確認します。
2. テスト条件をそろえて遅延結果を比較する
最初の確認では設定を変更しないでください。すでに利用している同じサーバー設定を選び、同じテスト方法で、近い時間帯に数回テストします。テスト方法を記録せず数値だけ比べると、意味の異なる結果を同じ基準で判断してしまうおそれがあります。
-
端末のネットワーク接続を確認する
Homeの接続スイッチをオフにし、Safariで直接アクセスできることが分かっているWebページを開きます。公衆Wi-Fiにログインページが表示される場合は、ログインを済ませてからShadowrocketに戻ります。
-
同じ設定を選ぶ
Homeに戻り、確認するサーバーを選択します。現在のWi-Fiまたはモバイルデータ通信の環境を記録し、名前が似た別の設定をテストしていないか確認します。
-
遅延テストを繰り返す
HomeでConnectivity Testを実行し、現在のテスト方法を確認します。同じ条件で3回テストし、応答したかタイムアウトしたかをそれぞれ記録してください。間隔を空けて再テストし、短時間に連続してタップする方法は避けます。
-
実際のリクエストを確認する
接続をオンにし、同じWebページで実際にアクセスできるか確認します。テスト結果とページの表示結果を別々に記録してください。結果が一致しない場合は、その差を記録し、すぐに設定を削除しないでください。
-
ネットワークを切り替えて再テストする
端末と通信プランで利用できる場合は、Wi-Fiとモバイルデータ通信を切り替え、前のテストを繰り返します。比較条件を保つため、ネットワーク以外の設定項目は変更しないでください。
判断の目安：ネットワークを変えると症状も変わるか
同じ設定が特定のネットワークだけで失敗する場合は、そのネットワークのDNS、ログイン状態、通信制限を先に確認します。どちらのネットワークでも失敗する場合は、サーバー設定とサービスの状態を重点的に確認します。いずれの場合も、遅延の数値だけで原因を特定することはできません。
3. アドレス、ポート、認証、通信方式の順に確認する
Homeで該当する設定の編集画面を開き、サービス提供元から受け取った情報と照合します。まずTypeを確認し、その後ほかの項目を確認してください。プロトコルによって必要な設定は異なります。サーバーアドレスとパスワードだけを別のTypeにそのまま移してはいけません。編集前に元に戻せるコピーを保存し、特に利用中の設定を上書きしないよう注意してください。
| 確認項目 | 確認内容 | よくある誤解 |
|---|---|---|
| アドレスとポート | サーバーアドレスがすべて入力されているか、ポートが受け取った情報と一致しているかを確認します。ポート番号は1～65535の範囲です。 | 443を万能な値として扱う。ポートが443でも、すべてのプロトコルで使えるとは限らず、TLSを使用するとも限りません。 |
| Shadowsocks | 暗号化方式とパスワードを確認します。サーバー側でプラグインを使用している場合は、プラグインと関連設定も確認してください。 | アドレスとポートが正しければ、暗号化方式の不一致は問題にならないと思い込む。 |
| VMess / VLESS | UUID、通信方式、この設定で実際に有効になっているセキュリティ項目を確認します。VLESSでflowを使用する場合は、サーバー側の設定とも一致させてください。 | どちらのプロトコルもUUIDを使うため、Typeを入れ替えてもよいと思い込む。 |
| Trojan | パスワード、TLS設定、Server Name、設定されている通信方式を確認します。 | パスワードだけを更新し、サーバー側で変更されたドメイン名や通信設定を見落とす。 |
| Hysteria2 | 認証、TLS、ポート、設定されている可能性のある難読化パラメータを確認します。また、現在のネットワークで該当するUDP通信が許可されているか確認してください。 | TCPポートを一度テストしただけで、UDPの通信経路も正常だと判断する。 |
| WireGuard | 鍵の対応関係、Endpoint、トンネルアドレス、AllowedIPsなどの設定を確認します。 | 鍵、ルーティング、ハンドシェイクの問題をすべてパスワードの誤りとして扱う。 |
| WS / gRPC | 該当する設定でその通信方式を使っている場合に限り、WSのPathとHost、またはgRPCのService Nameを確認します。 | Path、Host、Server Nameを同じ項目として扱う。 |
Server Nameは通常、TLSハンドシェイクで使われる名前と証明書の検証に関係します。WSのHostはHTTPリクエストの情報、Pathはリクエストパスです。似た文字列が使われていても、3つを独断でまとめないでください。パスの大文字・小文字、先頭のスラッシュ、UUIDに余分な空白がないかも、受け取った情報と一文字ずつ照合します。
4. システム時刻とTLSを確認し、証明書検証を無効にしない
証明書には有効期間があります。端末の日付が大きくずれていると、ネットワークやパスワードに問題がなくてもTLSの段階で失敗することがあります。一部のプロトコルでは認証にも時刻が関係します。時刻の確認は設定項目の確認後に行いますが、あらゆる方法を試して失敗するまで後回しにする必要はありません。
- iPhoneまたはiPadでシステムのSettings → General → Date & Timeを開き、Set Automaticallyを確認して、表示される日付と時刻が正しいか確かめます。
- デバイス管理などの制限によって自動設定できない場合は、先にその制限に対処してください。期限切れの証明書を回避するために、日付を過去に変更してはいけません。
- 時刻を修正したら、接続をいったん切って再接続し、同じ設定と接続先で再テストします。古いページのキャッシュだけを見て判断しないでください。
- 時刻が正しいのに証明書エラーが続く場合は、サーバーアドレス、Server Name、証明書に含まれるドメインを確認し、有効期間と証明書チェーンについて自分のサービス提供元に問い合わせます。
証明書検証の無効化を通常の修復方法にしないでください。セキュリティ上の境界が変わり、誤ったサーバーへの接続やドメイン設定の誤りなどを見過ごすおそれがあります。端末の時刻が正しいことと証明書が正しいことは別の条件として、それぞれ確認してください。
5. ログの原文から失敗した段階を特定する
失敗したら接続ログを開き、エラーが発生した時刻、接続先アドレス、関連する行を記録します。以下はネットワークやTLSのログに表示されることがある原文の例です。実際の表示には前後の情報が含まれる場合があり、すべてのプロトコルで同じメッセージが使われるわけではありません。エラーは発生段階の特定に役立ちますが、それだけで具体的な原因や責任元を断定することはできません。
エラー：i/o timeout
原因：読み書きの処理が制限時間内に完了していません。ネットワークのパケットロス、接続先からの応答なし、中継経路の制限などが考えられます。
対処：前後のログから接続先アドレスを確認し、同じ設定のままネットワークを切り替えて再テストします。ポートと接続先サービスの状態も確認してください。
エラー：connection refused
原因：接続要求が明示的に拒否されています。接続先のポートで待ち受けていない場合によく起こりますが、中継機器から拒否応答が返ることもあります。
対処：まずサーバーアドレスとポートを確認します。発生時刻とエラーを自分のサービス提供元に伝えて待ち受け状態を確認し、ポートを手当たり次第に試すのは避けてください。
エラー：x509: certificate has expired or is not yet valid
原因：証明書の有効期間と現在時刻が一致していません。端末の時刻が誤っている場合も、接続先の証明書自体に問題がある場合もあります。
対処：まずシステムのDate & Timeを確認し、次に接続先の証明書の有効期間を確認します。証明書検証は有効のままにしてください。
エラー：EOF
原因：データストリームが途中で終了しています。プロトコルの不一致、認証失敗、接続先による切断など、発生する段階はさまざまです。
対処：それ以前のハンドシェイク情報と照らし合わせ、Type、認証、通信設定を確認してください。この1行だけでパスワードの誤りと決めつけないでください。
6. 接続確立後にルーティングとOn Demandを確認する
テストに応答があるのにWebページが開かない場合は、リクエストが選択したサーバーを実際に経由しているか確認します。Home → Global RoutingのProxy、Direct、Config、Sceneはそれぞれ異なるルーティング方法を示し、接続品質の段階ではありません。Directで直接アクセスに成功しても、プロキシサーバーの動作確認にはなりません。Configでは、現在有効な設定とあわせて判断してください。
- 一時的に比較する：リクエストを確認するため、一時的にProxyを選んでルールによる振り分けの影響を除外できます。テスト後はGlobal Routingを元の設定に戻してください。変更前の設定も記録し、長時間そのまま使わないようにします。
- 設定を確認する：Configを使用している場合は、Configを開いて現在有効なファイルを確認し、ルールの順序とポリシー名をチェックします。Sceneでは、名前だけで判断せず、実際に適用されているシーン設定を確認してください。
- ルールを確認する：
DOMAIN-SUFFIXはドメインとそのサブドメインに一致し、IP-CIDRはIPアドレス範囲で照合します。GEOIPはIPの地理情報で照合し、FINALは前のルールに一致しなかった場合のフォールバックです。ドメインの名前解決やルールの順序によって、最終的なポリシーが変わることがあります。 - 自動接続を除外する：Settings → On Demandを開き、オンデマンド接続の設定を確認します。手動で再テストする場合は、On Demandを一時的に無効にして接続を手動で操作できます。テスト後は元の設定に戻してください。
On Demandは条件に応じて接続を開始する機能であり、誤ったパスワード、無効な証明書、待ち受けていないポートを修復するものではありません。手動で切断しても自動で再接続する場合は、システムのVPN設定を何度も削除するのではなく、まず接続条件を確認してください。システムのVPN認証とリモートサーバーのタイムアウトは、別々の段階で起きる問題です。
7. よくある質問と切り分け記録のまとめ方
遅延が小さいのに、Webページが開かないのはなぜですか？
まず、現在のテスト方法でどの段階まで確認できるかを把握し、Homeで選択中の設定とGlobal Routingを確認します。Proxyを一時的に使って比較し、失敗したリクエストのログも確認してください。特定のドメインだけ失敗する場合は、遅延順に並べ替えるだけでなく、DNS、ルール、接続先サイトの状態を確認します。
Wi-Fiではタイムアウトするのにモバイルデータ通信では正常です。プロトコルを変更すべきですか？
設定は変えず、Wi-Fiのログインが完了していることを確認し、同じ接続先で再テストします。差が続く場合は、プロトコルで使用している通信方式を記録し、ネットワーク管理者または自分のサービス提供元に制限を確認してください。特にUDPに関する問題は、TCPで接続できることだけを根拠にネットワークの影響を否定できません。
サブスクリプション更新後にすべてタイムアウトします。更新に失敗したのでしょうか？
まず、更新自体の失敗と、更新後の接続失敗を区別します。Homeで新しい設定が追加されたか、正しい設定を選択しているかを確認し、サービス提供元の情報とType、アドレス、ポートを照合してください。サブスクリプションを取得できても、含まれるすべてのリモートサービスが利用できるとは限りません。プロトコル設定の確認代わりに、更新を何度も繰り返すのも避けてください。
設定ファイル全体やサブスクリプションURLを他人に送る必要はありますか？
必要ありません。エラーの原文、発生時刻とタイムゾーン、使用中のネットワーク、プロトコルの種類、テスト方法、比較結果をまとめてください。パスワード、UUID、秘密鍵、サブスクリプションのtokenは必ず伏せます。サーバー側での確認が必要な場合は、自分のサービス提供元が用意する非公開のサポート窓口を利用してください。
まとめ：一度に変更する条件は1つだけ
再テストのたびに、ネットワーク、設定値、時刻、ルーティングのいずれか1項目だけを変更し、結果を記録してください。「どの手順で失敗したか」「どのネットワークで再現したか」「どんなエラーが出たか」を自分のサービス提供元に伝えると、「サーバーが使えない」とだけ伝えるより原因を特定しやすくなります。
切り分けが終わったら、一時的に変更したGlobal RoutingとOn Demandの設定を元に戻し、動作を確認した設定を保存してください。ShadowrocketはAppleプラットフォーム向けのクローズドソースの商用アプリです。アプリの買い切り購入と通信サービスの契約は別のものです。アプリの入手とリモートサービスのトラブル対応も別の問題であり、アプリを再購入してもリモート側の設定は修復されません。