この記事では、Shadowrocketで既存サーバーがタイムアウトする、または接続できない場合の確認手順を説明します。利用者自身がサービス提供元とサブスクリプションを用意していることが前提です。「基本ネットワーク、テストの意味、プロトコル設定、TLSと時刻、DNS、ルーティングとログ」の順に確認し、変更は一度に1項目だけにします。これにより、端末側・設定・サーバー側の問題を切り分けられます。テスト結果は回線品質を保証するものではなく、接続をオンにしただけで宛先への通信が成功したとは限りません。
1. テスト条件を固定し、基本ネットワークを確認する
接続失敗はリクエストが完了しなかったことを示す結果であり、特定の障害名ではありません。デフォルト設定、テスト方法、接続タイムアウト時間は、現在のアプリ表示を確認してください。調査前に元の値を記録し、サーバー・DNS・Global Routingを同時に変更しないようにします。変更後に通信が復旧しても、どの変更が有効だったか分からなくなるためです。
まず、端末自体がインターネットに接続できるか確認します。Homeの接続スイッチをオフにし、通常そのまま開けるページにアクセスしてください。それでも失敗する場合は、Wi-Fiのログイン認証を完了するか、モバイルデータ通信の権限を確認してから、Shadowrocketの確認に進みます。VPNのステータスアイコンはシステムトンネルが確立したことを示すだけで、接続先サーバーが通信を受け付けた証拠にはなりません。
-
元の設定を記録する
Homeで選択中のサーバーとGlobal Routingの値を記録し、Configで使用中の構成ファイルを確認します。障害が発生した時刻とネットワークの種類も記録してください。パスワードやサブスクリプションの認証情報は平文で記録しないでください。
-
直接接続を確認する
Homeの接続スイッチをオフにし、ブラウザーで基本ネットワークを確認します。公衆Wi-Fiにログインページが表示される場合は、先にネットワーク認証を完了してください。認証が済んでいない状態をサーバーのタイムアウトと誤認しないようにします。
-
自動接続を一時停止する
Settings → On Demandを開き、現在の設定を記録してから、オンデマンド接続を一時的に無効にします。手動で接続をオフにした後、システムが自動的に再接続するのを防げます。確認が終わったら元の設定に戻してください。
-
条件を一つに絞って再テストする
Homeに戻り、既存サーバーを1つだけ選択して接続をオンにし、同じ宛先にアクセスします。その後、サーバーと構成を変えずにWi-Fiとモバイルデータ通信を切り替えて再テストします。
2. 遅延テストと実際のリクエストの違い
遅延テストで測定するのは、特定の方法でプローブした際の所要時間であり、アプリによるアクセス全体の結果ではありません。Home → Connectivity Testのテスト方式や関連オプションは、現在のアプリ表示を確認してください。まず使用中のプローブ方式を確認してから数値を判断します。TCP接続の確立だけを調べる場合、プロキシ認証、TLSハンドシェイク、Webサイトの応答、UDP通信は検証されません。
テストがタイムアウトした場合は、プローブ先も確認します。特定のテスト用アドレスへのアクセスに依存していると、そのアドレスが一時的に利用できないだけで、複数のサーバーが同時に失敗と表示されることがあります。実際のアクセスは正常でプローブだけ失敗する場合は、テスト先と方式を先に確認し、既存の構成をすぐに削除しないでください。
- TCPプローブは成功するのにWebページが開かない：遅延の数値だけで判断せず、認証、TLS、トランスポート設定、実際に適用されるルールを優先して確認します。
- 1台のサーバーだけ失敗し、ほかは正常：そのサーバーのアドレス、ポート、サーバー側の状態を優先して確認します。すべての設定を先にリセットしないでください。
- 同じ構成が特定のネットワークだけで失敗する：そのネットワークのDNS、ポート、UDPの到達性を確認し、ネットワークを切り替えた際の違いを記録します。
- 複数のサーバーと直接接続の両方が失敗する：まず端末の基本ネットワークを確認します。サブスクリプションを何度も更新しても、この段階の問題は通常解決しません。
3. アドレス・ポート・プロトコル設定を確認する
サーバー設定はクライアントとサーバー間の取り決めであり、すべてのプロトコルに共通する正解はありません。Homeで該当サーバーの編集画面を開き、サービス提供元から受け取った元の設定と項目ごとに照合します。アドレス、ポート、認証情報は元の値を保ち、経験則だけでポートを一律443に変更しないでください。アドレス欄にURLのパスや余分な空白を入れないようにします。
| プロトコル | 優先して確認する項目 | 誤解しやすい点 |
|---|---|---|
| Shadowsocks | アドレス、ポート、パスワード、暗号化方式、元の設定で指定されている追加パラメーター | ポートに接続できても、パスワードや暗号化方式が異なれば、実際のプロキシ通信は失敗します。 |
| VMess | UUID、暗号化設定、トランスポート方式、および該当するTLS・トランスポート設定 | UUIDが正しくても、WebSocketのパスやHostが正しいとは限りません。システム時刻も確認してください。 |
| VLESS | UUID、トランスポート方式、元の設定で使用しているTLS、REALITY、Flowの各パラメーター | 別のサーバーのセキュリティ設定を、現在の構成にそのまま適用しないでください。 |
| Trojan | パスワード、TLS、Server Name、証明書の検証 | アドレスに接続できても、証明書名や認証情報が一致しなければ、リクエストは完了しません。 |
| Hysteria2 | 認証、TLS、ポート、UDPの到達性 | QUICをベースとしているため、TCPポートのプローブに成功しても、通信経路が利用可能とは判断できません。 |
| WireGuard | 鍵、Peer、Endpoint、Allowed IPs、トンネルアドレス | UDP通信とハンドシェイクを確認する必要があります。TCPプローブだけでは判断できません。 |
サブスクリプションの更新は、サービス提供元が公開した設定を同期するためのもので、すべての接続エラーを修復するものではありません。サブスクリプションが有効であることを確認してから、Homeで該当するサブスクリプションを更新し、更新後も以前の無効な項目を選択していないか確認します。サブスクリプションから生成された項目を手動で変更する場合は、後の更新で上書きされることがあるため、事前に記録してください。同じサブスクリプションを何度も追加しても、問題の切り分けにはなりません。
4. TLS・Server Name・システム時刻を確認する
TLS検証では、サーバー証明書と接続先の識別情報を確認します。証明書名、有効期間、信頼チェーンが関係します。Server Nameは通常、TLSのサーバー名表示や名前の検証に使われます。具体的な値は既存の構成に従ってください。WebSocketのHostとは別の項目であり、自由に置き換えられるものではありません。証明書検証は有効にしたままにし、検証のスキップを通常の対処法にしないでください。
システム時刻は証明書の有効期間の判定に影響し、一部のプロトコル認証にも影響する場合があります。iPhoneまたはiPadでは、システムの「設定 → 一般 → 日付と時刻」で自動設定と実際の時刻を確認します。端末が管理ポリシーの対象の場合は、管理上の要件も確認してください。時刻を修正したら接続を再確立します。プロトコルやDNSを同時に変更する必要はありません。
端末の時刻が正しいのに、証明書の期限切れや名前の不一致が続く場合は、サービス提供元に証明書とServer Nameを確認してください。ドメイン名をIPアドレスに変更しても、証明書の問題が自動的に解決するわけではありません。IPアドレスに接続する場合も、元の設定で指定されたServer Nameを維持する必要があることがあります。
- システムの日付、時刻、タイムゾーンを確認し、手動設定による大きなずれがないか調べます。
- サーバーの編集画面で、TLSとServer Nameが元の構成に一致しているか確認します。別の項目の値を流用しないでください。
- WebSocketを使用している場合は、Hostとパスを個別に確認します。パスの大文字・小文字と先頭のスラッシュをサーバー側の設定に合わせてください。
- 接続し直して今回のエラーを確認し、TLSエラーが認証エラーや宛先リクエストのエラーに変わったかを判断します。
5. DNSとGlobal Routingを分けて確認する
DNSはドメイン名をアドレスに変換するため、プロキシサーバーのアドレス解決と接続先Webサイトの名前解決の両方に影響することがあります。デフォルトのDNS動作は、現在のConfigとアプリ設定によって異なります。まず元の構成を維持し、ログに名前解決エラーが記録されている場合にDNSを確認してください。複数のDNSアドレスをむやみに追加すると確認項目が増えるだけで、タイムアウトの原因が解消したとは判断できません。
Global Routingはリクエストのルーティング方法を決定します。Proxyは選択中のプロキシ経路を一時的に確認する際に使えます。Directは直接接続、Configは現在の構成ルールに従った処理、Sceneは設定済みのシーンに従った処理です。現在の値はHomeで確認してください。Proxyに一時的に切り替えてアクセスが復旧した場合、Configのポリシーやルールを確認する手掛かりになります。ただし、すべてのDNSやプロトコル設定が正しいと証明されたわけではありません。
- サーバーのドメイン名を解決できない：まず直接接続で基本ネットワークを確認し、現在のDNS設定とログの名前解決エラーを調べます。そのうえで、サーバーアドレスが有効かサービス提供元に確認してください。
- 一部のWebサイトだけ開けない：Home → Global Routingの現在値を確認し、Configで使用中のファイルに設定されたマッチルールとポリシーの割り当てを調べます。
- Configでは失敗し、Proxyでは正常：まずルールの順序を確認します。
DOMAIN-SUFFIX、IP-CIDR、GEOIPでは一致する対象が異なります。FINALは最終ポリシーとしてルールの末尾に配置します。 - Sceneの切り替え後に失敗する：該当するSceneの条件と実際に使用されるポリシーを確認します。Homeに表示されたサーバー名だけを確認して終わらせないでください。
問題の切り分けが終わったら、Global Routingを元の値に戻し、実際の宛先で再テストしてください。一時的なProxyへの切り替えは比較条件として使うものであり、Config内のDIRECT、PROXY、REJECTポリシーの確認に代わるものではありません。ルールによってリクエストが明示的に拒否されている場合、サーバーを変更しても拒否結果は変わりません。
6. ログのエラーから原因を絞り込む
ログを使うと、通信処理のどの段階で失敗したかを確認できます。Settings → Logで関連記録を確認してください。記録のオン・オフや詳細度は現在のアプリ表示に従い、再現に必要な記録だけを有効にすることをおすすめします。まず時刻を記録してからリクエストを1回実行し、古い記録を今回の結果と取り違えないようにします。以下はネットワーク処理で返されることがあるエラー原文の一部です。固定のポップアップ文言ではなく、実際の前後の文字列はログで確認してください。
エラー: i/o timeout
原因と対処：接続または読み書きが制限時間内に完了していません。この文言だけでは、パケットロス、通信の遮断、サーバーの無応答を区別できません。まずログ上の処理段階に応じてアドレスとポートを確認し、同じ構成のままネットワークを切り替えて再テストします。
エラー: connection refused
原因と対処：接続先または途中の機器から明示的に拒否されています。ポートで待ち受けていないか、拒否ルールが設定されている可能性があります。ポートとプロトコルを確認し、該当サービスが稼働中かサービス提供元に問い合わせてください。
エラー: no such host
原因と対処：ドメイン名を有効なアドレスに解決できていません。アドレスの入力ミスや名前解決経路の問題が考えられます。まずサーバーアドレスを確認し、現在のDNS設定とネットワーク上での名前解決状況を調べてください。
エラー: certificate has expired or is not yet valid
原因と対処：証明書の有効期間と現在時刻が一致していません。まずシステムの自動時刻設定を確認します。時刻が正しいのに失敗する場合は、サービス提供元に証明書を確認してください。検証を無効にして回避しないでください。
「名前解決エラー」から「認証エラー」に変わった場合、リクエストが異なる段階まで進んだことを示しており、問題が悪化したとは限りません。各回で変更した項目と新しいエラー段階を記録してください。長時間のアイドル状態の後だけ接続に失敗する場合は、バックグラウンドとフォアグラウンドの切り替え、ネットワークの切り替え、再接続後の状況も記録します。タイムアウト値を一律に延長するのではなく、On Demandなどの自動接続設定を確認してください。
7. 再テスト結果と問い合わせ時の情報
有効な再テストでは、同じ宛先、同じ構成、明確なネットワーク条件で繰り返し確認します。少なくとも障害時と比較用の記録を1つずつ残し、接続のオン・オフ、Global Routingの値、エラーが発生した段階を明記してください。1回の遅延測定だけで長期的な利用可否を判断せず、未加工の構成全体をそのまま他人に送らないでください。
遅延の数値が表示されるのに、Webページが開かないのはなぜですか？
まずHome → Connectivity Testで使用中のプローブ方式を確認してから、同じ宛先に実際にアクセスしてください。TCPプローブだけに成功した場合は、プロトコル認証、TLS、Configのポリシーを引き続き確認します。数値が表示されても、リクエスト全体の成功を意味するわけではありません。
Wi-Fiではタイムアウトするのにモバイル通信では正常です。パスワードを変更すべきですか？
パスワードとプロトコル設定は変えず、2種類のネットワークでの結果を記録してください。Wi-Fiのログイン状態、DNS、UDPの到達性を確認します。特にHysteria2やWireGuardを使用している場合は、ネットワーク管理者にUDP通信の制限を確認してください。
サブスクリプションを更新しても接続できません。次に何をすればよいですか？
Homeで更新後の有効な項目が選択されていることを確認し、アドレス、ポート、プロトコルを照合します。特定の項目だけ失敗が続く場合は、発生時刻、ネットワークの種類、個人情報を伏せたエラー内容をサービス提供元に伝えて確認してください。同じサブスクリプションを何度も追加しないでください。
問い合わせ時に隠すべき情報は何ですか？
プロトコル名、ネットワークの種類、エラー原文、再現手順は残します。パスワード、UUID、鍵、サブスクリプションの完全なURLと、そのURLに含まれるtokenは隠してください。ログを送る前に、サーバーアドレスやアクセス先ドメインなどに個人情報が含まれていないかも確認します。
- 端末側の確認済み：直接接続は正常で、システム時刻も正しく、Wi-Fiとモバイル通信の比較テストを実施済みです。
- 構成の確認済み：アドレス、ポート、認証、TLS、トランスポート設定を既存のサービス設定と照合し、別の項目の値を流用していません。
- 再現できる情報あり：具体的な時刻、エラーが発生した段階、使用したルーティング方法、個人情報を伏せたログを提示し、「接続できない」だけの説明にしません。
- 設定を復元済み：確認後、On Demand、Global Routing、一時的なログ設定を元に戻し、通常のアクセスを再確認します。