Shadowrocketの接続スイッチをオンにすると、端末上でVPN接続が確立したことは確認できますが、選択したサーバーやDNS、接続先のWebサイトにアクセスできるとは限りません。利用中のサービスとサブスクリプションがあり、接続はできるのにWebを正常に閲覧できない場合を対象に、4つの段階を順に確認します。変更は一度に1項目に絞り、同じ接続先へ新たにリクエストして結果を比べてください。
確認を始める前に：「接続済み」と「アクセス可能」を分けて考える
システムのVPNステータスは、端末の該当トラフィックがローカルのトンネルに送られていることを示します。リモートサーバーが接続を受け付けるか、ドメインを名前解決できるか、リクエストが最終的にどのポリシーで処理されるかは、その後の段階で確認します。スイッチを何度切り替えても、誤ったサーバーポートや設定済みのルールは修正されません。
まず、現在のConfigを複製して保存し、Homeで選択中のサーバー、Global Routingの現在値、問題が発生するのがWi-Fiかモバイル通信かを記録します。確認中は、普段使っていて正常にアクセスできることが分かっているHTTPSサイトを1つ決め、毎回同じ接続先を使って比較してください。
- Shadowrocketの接続を一時的にオフにし、現在のネットワークから、もともと直接接続できるサイトにアクセスできるか確認します。公衆Wi-Fiに認証ページがある場合は、先に認証を完了してください。
- スイッチが勝手にオンに戻る場合は、Settings → On Demandを確認します。現在の設定を記録したうえでOn Demandを一時的にオフにし、手動での比較に影響しないようにしてください。
- 接続を再びオンにし、同じ接続先へ新しいリクエストを送ります。既存の接続が再利用されて誤判定しないよう、テスト時は対象アプリを終了してから開き直してください。
ステップ1：選択中のサーバーが実際に使えるか確認する
Homeで現在選択されているサーバーを確認します。サブスクリプションのグループが表示されているだけでは不十分です。サブスクリプションのインポートに成功しても、設定データを読み込めたことを示すだけで、各サーバーがその時点で稼働中とは限りません。更新に成功しても、アカウントの利用枠やサービスの状態、接続先へのアクセスが正常であるとは限りません。
-
選択項目を確認する
Homeを開き、今回テストするサーバーが選択されていることを確認します。ポリシーグループを使っている場合は、グループ内で実際に選択されているメンバーも確認し、テスト対象と記録が一致しているか確かめてください。
-
パラメーターを確認する
対象サーバーの編集画面を開き、サービス提供元の情報とType、アドレス、Portを照合します。Portには提供元が指定した値を使用してください。接続先のWebサイトがHTTPSだからといって、すべて443に変更してはいけません。
-
接続をテストする
HomeのConnectivity Testで到達性の手掛かりを確認したうえで、実際に対象のWebページを開きます。テストの成功が確認できるのは、そのテスト方法と接続先に限られ、実際の利用時のリクエストを保証するものではありません。
-
条件をそろえて比較する
利用中のサーバーから別のものを1つ選び、ネットワーク、モード、接続先は変えずに比較します。特定のサーバーだけ失敗する場合は、Config全体を書き直すのではなく、そのサーバーのパラメーターとサービス状態を優先して確認してください。
プロトコルのパラメーターはサーバー側の設定と一致させる必要があります。たとえばTrojanのパスワードやTLSホスト名、VMessやVLESSのユーザー情報、通信方式、パスなどがハンドシェイクに影響することがあります。タイムアウトが一度発生しただけでプロトコルを安易に変更したり、ホスト名や証明書のエラーを隠すために証明書の検証を無効にしたりしないでください。
エラー：Connection timed out
原因と対処：接続ログにこのメッセージが表示された場合、該当の処理が制限時間内に完了しなかったことを示します。これだけでサーバーの停止かネットワーク経路の遮断かを判断することはできません。まずアドレスとPortを確認し、同じ設定のままWi-Fiとモバイル通信を切り替えて比較したうえで、利用中のサービス提供元にサーバーの状態を確認してください。
エラー：Connection refused
原因と対処：接続ログにこのメッセージが表示された場合、通常は接続先のポートで接続が明示的に拒否されたことを示します。まずログに記録された接続先がサーバーかWebサイトかを確認し、該当するポートとサービスの待ち受け状態を調べてください。何度再接続しても、誤ったポートは修正されません。
ステップ2：Global Routingでモードとサーバーの問題を切り分ける
Home → Global Routingを開き、最初に現在の値を記録します。Proxy、Direct、Config、Sceneはそれぞれ用途が異なります。Sceneは設定済みのシーン条件に応じてルーティングを決めるため、Sceneを選択しただけでは、リクエストがどの経路を通るかは判断できません。
| モード | 確認すること | 結果の見方 |
|---|---|---|
Proxy | プロキシ経由の接続を一時的に確認 | 接続先にアクセスできる場合、今回選択したプロキシ経路でリクエストを処理できています。次にConfigのルーティング結果を確認してください。 |
Direct | 直接接続の経路と比較 | 直接接続できる接続先にもアクセスできない場合は、サーバーだけでなくローカルネットワークとDNSも確認してください。 |
Config | 現在の設定ルールに従って処理 | このモードだけで失敗する場合は、現在のConfig、ルールの順序、ポリシーグループ、関連するDNS設定を重点的に確認してください。 |
Scene | シーン条件に従って処理 | 現在のネットワークで適用されているシーンとその設定を確認します。切り分けのため、まず明示的なProxyまたはConfigに切り替えて比較できます。 |
モードを切り替えたら、対象アプリの接続をいったん切り、新しく接続してテストします。既存の長時間接続には切り替え前の状態が残ることがあり、ページを一度再読み込みするだけではキャッシュが使われる場合もあります。Directで比較するときは、もともと直接接続できる接続先を選んでください。特定の接続先に直接つながらないことだけを根拠に、ローカルネットワーク全体が切断しているとは判断できません。
結論：Proxyで接続できるなら、まずサーバー設定は変更しない
同じサーバー、ネットワーク、接続先でProxyならアクセスでき、Configではできない場合、まずConfigに戻って実際に適用されたポリシーとDNS設定を確認してください。プロトコル、サーバーポート、ルールを同時に変更しないでください。
ステップ3：DNSの名前解決と、その後の接続をそれぞれ確認する
ドメインの名前解決は、接続先へのアクセスに先立って行われます。サーバーアドレス自体がドメイン名の場合は、サーバーアドレスの名前解決も必要です。そのためDNSの問題は、接続先のWebサイトに影響するだけでなく、プロキシ接続自体を確立できなくする場合もあります。ログを確認するときは、どのドメイン名の処理に失敗したのかをまず見分けてください。
Configを開き、現在使用中の設定ファイルを確認してから、DNS設定と元のテキストにある[General]を確認します。一般的な設定項目のdns-serverは、名前解決に使うサーバーを指定します。システムDNS、カスタムの従来型DNS、暗号化DNSでは接続経路が異なるため、アドレス文字列だけを比べて同じ結果になるとは判断できません。
[General]
dns-server = system上記はDNS設定の一部であり、設定ファイル全体ではありません。システムDNSを一時的な比較に使う場合は、バックアップした設定ファイルで既存のdns-server項目を編集してください。同じ項目を複数追加したり、既存のルールを上書きしたりしないでください。システムDNSは現在のネットワークに依存するため、あらゆる接続先に有効な解決策ではありません。
- 名前解決の結果を確認：直前に行った新しいリクエストについて、ログに名前解決の失敗が記録されているか、A／AAAAアドレスが取得できているかを確認します。アドレスが取得できても、名前解決の段階で結果が得られたことを示すだけで、そのアドレスに接続できるとは限りません。
- DNSサーバーへの経路を確認：従来型DNSではUDPまたはTCPの53番ポートが一般的です。DoHは通常HTTPSの443番ポートを使います。通常のWebページを開けても、特定のカスタムDNSサーバーに接続できるとは限りません。
- IPv4／IPv6の違いを確認：AAAAレコードが取得できても、現在のネットワークでIPv6経路が使えない場合、一部のリクエストがタイムアウトすることがあります。まずWi-Fiとモバイル通信で挙動を比較してから、関連する設定を調整してください。
- キャッシュの影響を除外：設定を保存して再接続し、対象アプリから新しい接続を確立します。設定変更後の結果をキャッシュ内の古いアドレスと取り違えないよう、変更前後の名前解決結果を記録してください。
ステップ4：現在のConfigと実際に適用されたルールを確認する
Home → Global RoutingがConfigに戻っていることを確認し、Configで現在使用中のファイルを確認します。設定ファイルのコピーを編集しても、そのコピーが現在の設定として使われるとは限りません。ルールは通常、上から順に判定され、先に一致したルールでリクエストのポリシーが決まります。ファイル内に接続先のドメイン名があるか探すだけでなく、実際に適用されたルールを確認してください。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECTこの例はルールの順序を示すものです。example.comとそのサブドメインはDOMAIN-SUFFIXに一致し、PROXYに渡されます。それ以外の一致しないリクエストはFINAL,DIRECTに従います。ここでのPROXYは、現在の設定で利用できるプロキシポリシーに対応している必要があります。カスタムのポリシーグループを使っている場合は、ルールの末尾に定義済みのグループ名を指定してください。この断片をConfig全体としてそのまま置き換えないでください。
- 対象ドメインの範囲を確認：
DOMAIN-SUFFIX,example.com,PROXYは、まったく異なるドメインのリソースには適用されません。ページ本体は開くのに画像の読み込みやログインに失敗する場合は、失敗したリソースの実際のホスト名を確認してください。 - 先に一致するルールを確認：対象より上に、リクエストを
DIRECTまたはREJECTへ送るルールがないか確認してください。ドメインルールをFINALの後ろに追加しても、期待したとおりには適用されません。 - IPルールを確認：
GEOIPとIP-CIDRはIPアドレスを判定するルールであり、ドメインのサフィックスルールとしては使えません。リクエストの名前解決結果と設定内の名前解決オプションを照らし合わせて適用状況を確認し、Webサイト名だけから判断しないでください。 - 適用先のポリシーを確認：ログでポリシーグループへの一致を確認した後は、グループ内で現在選択されているメンバーも調べます。グループ名が正しく一致していても、選択中のサーバーが使えるとは限りません。
Webページはメインサイト、静的リソース、認証用ドメインなどに同時に接続することがあります。メイン文書は表示されるのにページが読み込み中のままの場合は、失敗したリクエストと適用されたポリシーを記録してください。すべての通信をProxyに切り替えたままにするのは避けましょう。モードの一時的な切り替えは差異の特定に使い、最終的には実際に調整が必要なルールを修正してください。
よくある質問：次に確認する場所の見分け方
Connectivity Testの結果が出るのに、Webページを開けないのはなぜですか？
テスト結果が示すのは、テストに使われた方法と接続先についてだけです。同じWebページへ新しいリクエストを送り、接続先ドメインの名前解決、実際に適用されたポリシー、接続エラーをそれぞれ確認してください。特に、サーバーへの到達、プロトコルのハンドシェイク成功、接続先Webサイトへのアクセス成功を区別する必要があります。
Wi-Fiだけ接続できず、モバイル通信では正常な場合、まず何を変更すればよいですか？
サーバー、Global Routing、Configはそのままにして、ネットワークだけ切り替えて再テストしてください。Wi-Fiの認証を完了し、そのネットワークのDNSとIPv6の状態を確認します。同じサーバーが特定のネットワークでだけ失敗する場合は、サブスクリプションを再作成するのではなく、まずそのネットワークの接続経路を調べてください。
サブスクリプションを更新してもネットにつながりません。さらに更新を繰り返すべきですか？
まずHomeで、更新後に実際に選択されている項目を確認し、サービス提供元の案内とパラメーター、アカウントの状態を照合してください。更新で取得できるのは設定データです。停止中のサービスが復旧するわけではなく、ローカルのConfigに適さないルーティングルールが自動で修正されることもありません。
スイッチをオフにしてもまたオンになります。どうすれば比較できますか？
Settings → On Demandを開き、現在の設定を記録してからOn Demandを一時的にオフにし、手動で接続を切り替えてください。確認が終わったら元の設定に戻し、普段使うWi-Fiとモバイル通信の両方で自動接続の挙動を確認します。
最後に：再現できる記録を残し、普段の設定に戻す
確認が終わったら、必要なGlobal RoutingとOn Demandの設定に戻し、修正後のConfigが使用中であることを確認してください。一度アクセスできても、すべてのアプリが正常とは限りません。少なくとも、最初に失敗したWebページ、ページ内の重要なリソース、普段使う別のアプリからのリクエストを再テストしてください。
- 確認条件を記録：ネットワークの種類、選択中のサーバーに付けたローカルメモ、Global Routingの値、現在のConfig名、テスト時刻。
- 違いを記録：たとえば「同じ接続先がProxyでは成功し、Configではタイムアウト」のように記録すると、「つながらない」という曖昧な説明より原因を絞り込みやすくなります。
- エラーを記録：該当するリクエストの接続先ドメイン、適用されたポリシー、エラーの原文を残します。利用中のサービス提供元に問い合わせる際は、必要な情報だけを伝えてください。
- 機密情報を隠す：ログを外部に送る前に、サブスクリプションのトークン、パスワード、UUID、秘密鍵などの認証情報を削除してください。サブスクリプションのURL全体を公開しないでください。
Configの操作方法は使い方ガイドをご覧ください。各設定項目について詳しく知りたい場合は、設定の詳細を参照してください。クライアントの購入と、利用者が別途契約する接続サービスはそれぞれ別に管理されます。クライアントを買い切りで購入しても、接続サービスのプランが含まれるわけではありません。