Shadowrocketでノードのテストがタイムアウトする、接続をオンにしてもWebページが開かない、サブスクリプションの更新がタイムアウトするなどの症状は、それぞれ原因となる段階が異なります。利用中のサービスとサブスクリプションがあることを前提に、テスト範囲、接続設定、システム時刻、ネットワーク環境を順に確認します。一度に変更する条件は一つに絞り、失敗時の記録を残してから同じ対象を再テストしてください。
1. ノード・Webページ・サブスクリプションのタイムアウトを切り分ける
タイムアウトは、操作が所定の時間内に完了しなかったことを示します。パスワードの誤りやサーバーの停止を直接意味するものではありません。Shadowrocketの接続がオンでも、システムトンネルが該当する状態にあることを示すだけで、リモート認証の成功や、すべてのWebサイトへのアクセスを保証するものではありません。まず、どの段階で失敗したかを特定し、関係のない設定を何度も変更しないようにしましょう。
上記は確認範囲を切り分けるための流れであり、すべてのプロトコルが内部で同じ順序で処理されるという意味ではありません。たとえば、TLS関連の情報がハンドシェイクに影響する場合があり、ルールがドメイン名をもとに先に判定することもあります。実際の原因はテスト対象とリクエスト記録を照らし合わせて確認し、赤い結果だけから特定の段階に原因を決めつけないでください。
- 特定のノードだけテストに失敗する場合：そのノードのアドレス、ポート、プロトコル設定と、現在のネットワークからサーバーへの到達性を確認します。
- ノードの遅延は表示されるのにWebページが開かない場合：認証、DNS、Global Routing、接続先サイトを続けて確認します。ポートに接続できても、プロキシリクエスト全体の成功を意味するわけではありません。
- サブスクリプションの更新だけ失敗する場合：サブスクリプションURL、アクセス経路、サービス提供元の状況を確認します。それだけを根拠に、既存ノードがすべて無効になったと判断しないでください。
- すべてのノードが同時に失敗する場合：まずローカルネットワーク、システム時刻、共通する設定の入手元を確認し、その後、サーバーの状態を個別に確認します。
2. テスト条件をそろえて遅延結果を確認する
HomeでConnectivity Testを実行する前に、選択中のノード、接続中のネットワーク、テスト方式を記録します。テスト方式によって、接続の確立だけを調べる場合と、テストURLへのリクエストまで行う場合があります。後者の結果にはDNS、TLS、テスト先の応答も影響します。そのため、方式の異なるテスト結果を単純に比較することはできず、単発の数値も帯域幅を示すものではありません。
-
現在の状態を記録
Homeで選択中のノードを確認し、Global Routingの現在の選択肢、Wi-Fiまたはモバイル通信、失敗した時刻を記録します。記録にパスワードやサブスクリプションURL全体を含めないでください。
-
テストを繰り返す
HomeでConnectivity Testを使い、同じ方式で3回続けてテストして、毎回の結果を記録します。URLテストを使う場合は、テスト先も変えないでください。
-
ネットワークを切り替える
モバイル通信を使えることを確認したうえで、Wi-Fiからモバイル通信に切り替え、同じノードを3回テストします。このとき、ポート、DNS、プロトコルを同時に変更しないでください。
-
リクエストを確認
ノードを選択して接続をオンにし、正常に表示できると確認済みのHTTPSページを開きます。ページの表示結果とテスト結果は分けて記録し、サーバーへの到達と実際のリクエスト成功を区別します。
| 記録例 | 判断できること | 次に行うこと |
|---|---|---|
| 同じ方式で180 ms、210 ms、タイムアウト | 結果にばらつきがあり、最小値だけでは安定性を判断できない | 設定を変えずにネットワークを切り替えて再テスト |
| 接続テストは成功、URLテストはタイムアウト | 接続の確立とリクエスト全体の結果が一致していない | 認証、テスト先、DNSを確認 |
| Wi-Fiでは3回ともタイムアウト、モバイル通信では3回とも成功 | ネットワーク経路に関連する問題の可能性が高い | Wi-Fiのログイン状態とネットワーク制限を確認 |
表中の数値は記録方法の例であり、本サイトで測定した結果でも、特定の回線の性能を示すものでもありません。テスト先自体に接続できなければ、URLテストも失敗します。ノードの問題と決めつけず、正常にアクセスできると確認済みの別のテスト先でも照合してください。
ポイント：テスト方式を固定してから設定を変更する
「同じノード・同じ接続先・2種類のネットワーク」の比較記録を残します。条件を一つだけ変えたときに結果が安定して変化する場合に限り、その条件を中心に次の確認を進めてください。
3. アドレス・ポート・認証情報・通信設定を確認する
Homeから該当ノードの編集画面を開き、サービス提供元から受け取った元の設定と項目ごとに照合します。表示名をサーバーアドレスと取り違えたり、プロトコル名が同じだからといって別のノードの設定を流用したりしないでください。ポート443はポート番号の一つにすぎず、TLSが有効であることを自動的に意味するものではありません。実際のポートとTLSの状態は、いずれもサーバー側の設定に従います。
| 確認項目 | 具体的な確認内容 | よくある影響 |
|---|---|---|
| アドレスとポート | サーバーアドレスにURLのパスを含めないでください。ポートにはサーバー側で指定された整数（443、8443など）を使い、独自に変更しないでください。 | 名前解決の失敗、接続拒否、応答待ちのタイムアウト |
| Shadowsocks | 暗号化方式、パスワード、設定で実際に使われているプラグインのパラメータを確認 | 下位層の接続は確立しても、プロキシリクエストを正常に完了できない |
| VMess / VLESS | UUID、該当プロトコルのオプション、伝送方式を確認し、元の設定で必要な項目だけを入力 | 認証または伝送層の設定不一致 |
| Trojan | パスワード、TLS、サーバー側で指定されたServer Nameを確認 | 認証失敗またはTLSハンドシェイク失敗 |
| WebSocket伝送 | PathとHostを確認します。Path先頭のスラッシュと大文字・小文字は、元の設定どおりに保ってください。 | リクエストはサーバーに届いても、正しいプロキシの入口に到達できない |
| Hysteria2 / WireGuard | UDPの到達性と、認証情報や鍵、Peerなどのプロトコル項目を確認 | 現在のネットワークでUDPが制限されている場合、ほかのTCPリクエストが正常でも、この接続が使えるとは限りません。 |
パスワード、UUID、鍵をコピーするときは、前後の空白や改行が入っていないか確認します。TLSのServer Nameはハンドシェイクと証明書の本人確認に使われ、WebSocketのHostは対応するリクエストのルーティングに使われます。「どちらもドメイン名だから」と置き換えることはできません。接続先アドレスがIPアドレスでも、サービス提供元が指定したServer Nameを残す必要がある場合があります。
4. エラー内容とシステム時刻・TLSを確認する
エラーの文言は、利用端末に実際に記録された内容を確認してください。プロトコルや下位の実装によって表現が異なる場合があります。サービス提供元に問い合わせる際は、「タイムアウト」とだけ伝えるより、エラー全文と発生時刻を残したほうが原因を特定しやすくなります。以下はよくある下位層のエラー例で、失敗するたびに必ず表示されるものではありません。
エラー：i/o timeout
原因と対処：読み書きの待ち時間が上限を超えています。この文言だけでは原因を特定できません。まず接続時とリクエスト時のどちらで発生したかを記録し、同じノードでネットワークを切り替えて到達性を確認してください。
エラー：connection refused
原因と対処：接続先ホスト、または経路上の機器によって接続が明示的に拒否されています。まずポートを確認し、そのポートでサーバーが待ち受けているか、アクセス制御が適用されているかをサービス提供元に確認してください。
エラー：TLS handshake timeout
原因と対処：TLSハンドシェイクが制限時間内に完了していません。ポート、TLS設定、Server Nameを確認し、ネットワークを切り替えてハンドシェイク通信の遮断や経路の応答遅延を切り分けてください。
エラー：certificate has expired or is not yet valid
原因と対処：現在時刻が証明書の有効期間外です。まず端末の日付と時刻を合わせます。それでも失敗する場合は、サーバー証明書の期限切れや有効化前の状態をサービス提供元に確認してください。
iPhoneまたはiPadの「設定 → 一般 → 日付と時刻」で「自動設定」を確認し、表示される日付と時刻が正しいことを確かめてから再接続してください。VMessの認証も時刻の同期に依存します。端末の時刻が大きくずれている場合は、UUIDを何度も変更するのではなく、まず時刻を合わせます。TLSのタイムアウトと証明書の有効期間に関するエラーは別の現象であり、すべてのハンドシェイク失敗を時刻の問題と決めつけないでください。
5. 接続済みでもWebページが開かない場合：ルーティングとDNSを確認
ノードのテストは正常なのに実際のWebページだけ開かない場合は、Homeに戻ってGlobal Routingを確認します。Proxy、Direct、Config、Sceneはそれぞれルーティングの状態が異なります。Directはプロキシ経由で接続せず、Configは現在の設定にあるルールに従い、Sceneは選択中のシーンに応じて確認が必要です。比較のため一時的にProxyを使うことはできますが、テスト後は元の選択肢に戻してください。一時的な切り替えは、ルールの修復を意味しません。
- まず適用されるルールを確認：Configで現在の設定を確認します。
DOMAIN-SUFFIXはドメインのサフィックス、GEOIPとIP-CIDRはIPの条件を処理し、FINALは最終的なフォールバックを担います。ルールの順序によって、接続先の選択が変わることがあります。 - ルールによる拒否とネットワークのタイムアウトを区別：接続先が
REJECTに一致する場合、リクエストはルールによって拒否されています。ノードのパスワードを変更しても解決しません。まず対象ドメインにルールが誤って適用されていないか確認してください。 - DNSの対象を切り分ける：接続先アドレスがドメイン名の場合、まずサーバーアドレスを名前解決する必要があります。Webページの接続先ドメインの名前解決は、これとは別の段階です。どちらのドメインで失敗したのかを記録し、設定内のDNSとリゾルバーへの到達性を確認してください。
- IPアドレスでHTTPSに接続した結果だけで判断しない：IPアドレスへ直接アクセスすると、正しいドメイン情報が不足し、証明書やサイトのルーティングが一致しない場合があります。その結果だけを根拠にDNSが正常または異常だと判断しないでください。
大きなページ、動画、大容量の転送だけが止まり、短いリクエストは完了する場合は、経路MTUなどの問題も検討します。WireGuardでは、まず既存の設定に記載されたMTUを使用してください。変更が必要な場合は元の値を記録し、サービス提供元に確認してから個別に再テストします。DNS、ルーティング、MTUを同時に変更しないでください。
6. ネットワーク環境・On Demand・サブスクリプション更新の影響を切り分ける
公衆Wi-Fiでは、先にWebページでのログイン認証が必要な場合があります。まずShadowrocketの接続をオフにし、ネットワーク自体で通常のアクセスができるか確認してください。基本のネットワーク接続が確立していない状態では、プロトコルを変更しても解決しません。モバイル通信では、システムでShadowrocketのモバイルデータ通信が許可されていることを確認し、ほかのVPN設定やデバイス管理ポリシーが接続に影響していないかも確認してください。
Settings → On Demandで、自動接続の条件が有効になっているか確認します。確認中に接続が自動で再確立される場合は、On Demandを一時的にオフにし、接続スイッチを手動で操作してください。再テスト後は、記録した元の設定に戻します。On Demandはシステムが接続を開始する条件を管理する機能で、サーバーアドレス、ポート、認証情報を修復するものではありません。
Wi-Fiではタイムアウトするのに、モバイル通信では正常なのはなぜ？
同じノードとテスト先を使い、まずWi-Fiのログイン認証を完了してから再テストしてください。Wi-Fiだけで引き続き失敗する場合は、ネットワークの種類と使用プロトコルを記録し、ポートやUDPなどの通信制限についてネットワーク管理者またはサービス提供元に確認します。最初からすべての設定をリセットしないでください。
サブスクリプションの更新がタイムアウトしたら、既存ノードをすべて削除するべき？
まず既存の設定を残します。Homeで利用中のサブスクリプションを更新し、URLが有効か、サービス提供元がURLやアクセス条件を変更していないかを確認してください。更新リクエストの失敗は、読み込み済みのノードが同時に無効になったことを意味しません。設定を削除すると、比較に必要な条件が失われます。
ノードに遅延が表示されるのに、接続後もWebページが開かないのはなぜ？
まずテスト方式を確認します。次にHomeでGlobal Routingを一時的にProxyに切り替え、同じHTTPSページを再テストしてください。それでも失敗する場合は、認証、TLS、DNSを確認します。表示できるようになった場合は、Configで元のルールの適用状況を確認し、最後に元のルーティング状態へ戻してください。
何度も再インストールすればタイムアウトは解決する？
再インストールしても、サーバー側のポート、サブスクリプションの状態、ネットワーク制限は変わりません。まず設定を照合し、2種類のネットワークでテストしてください。自分の設定をバックアップし、アプリ内のローカル状態に問題があると確認できた場合に限り、切り分け結果に沿って対処します。元の記録を失わないようにしてください。
7. 解決しない場合は必要最小限の情報をまとめる
ここまで確認しても原因が分からない場合は、設定を手当たり次第に変更するのではなく、再現できる条件を絞り込みます。サービス提供元に問い合わせる際は、使用プロトコル、テスト方式、失敗した段階を伝えてください。学校や職場の管理対象ネットワークに関する制限は、該当するネットワーク管理者に確認します。
- 発生日時とタイムゾーン、端末の機種、実際に使用しているOSとアプリの情報。
- Wi-Fiとモバイル通信での比較結果。それぞれのネットワークで、同じ方式によるテストを3回行った記録。
- 失敗するのが特定のノードだけかどうか、および接続テスト、URLテスト、実際のWebページへのリクエストそれぞれの結果。
- 個人情報を伏せたプロトコルの種類、ポート、TLSの状態、エラー全文。パスワード、秘密鍵、UUID、サブスクリプションURL全体は公開しないでください。
- 変更した項目と元に戻したかどうか。特にGlobal Routing、On Demand、DNS、MTUの設定。