Shadowrocketの接続スイッチをオンにすると、端末上で接続処理が始まります。ただし、それだけでサーバーや名前解決、振り分けルールが正常だとは判断できません。自分で用意したサービスとサブスクリプションを利用していて、接続後もウェブページが開かない場合は、サーバー → Global Routing → DNS → ルールの順に原因を絞り込みましょう。同じ接続先で再テストし、複数の設定を同時に変えて原因が分からなくなるのを防ぎます。
まずテスト条件をそろえ、端末のネットワークとプロキシの問題を切り分ける
システムにVPN接続中と表示されても、リモートサーバーの認証完了やウェブサイトへのアクセス成功を意味するわけではありません。Shadowrocketは端末上にネットワークトンネルを作成してから、リクエストに応じてサーバーへ接続します。そのため、サーバーに到達できない場合でも接続スイッチがオンのままになることがあります。スイッチを何度も切り替えるのではなく、実際のリクエストを確認してください。
普段は直接アクセスできるウェブページを1つ、現在開けない接続先を1つ選びます。どちらもブラウザーから新しいリクエストを送信し、失敗した時刻、使用中のネットワーク、選択中のサーバーを記録してください。すでに開いているタブやアプリのトップ画面だけで判断しないでください。キャッシュによって、ネットワークが切れていても古い内容が表示されることがあります。以下は主にiPhone / iPadの画面表記に沿って説明します。他のプラットフォームでは同名の設定を確認してください。
-
ネットワークの基本状態を確認
Homeで接続をオフにしてから、普段は直接アクセスできるウェブページを開きます。それでも失敗する場合は、まずWi-Fiのログイン認証を完了し、モバイルデータ通信の許可やルーターの接続状態を確認してください。ネットワーク自体が切れている場合、振り分けルールを変更しても解決しません。
-
テスト対象を固定
同じ接続先のドメイン名、使用中のWi-Fiまたはモバイルネットワーク、Homeで選択したサーバーを記録します。その後は一度に1項目だけ変更し、同じ接続先へ再度リクエストしてください。別のウェブサイトでの結果を比較対象にしないようにします。
-
自動接続を一時停止
Settings → On Demandを開き、現在の状態を記録してから自動接続を一時的にオフにします。手動で切断した際にシステムがすぐ再接続するのを防げます。テスト後は元の設定に戻してください。
-
元の設定を記録
変更前にGlobal Routing、現在のConfig、カスタムDNSを記録します。ルールを編集する場合は、診断用の一時設定が普段の設定として残らないよう、先にConfigのコピーを保存してください。
1つ目：サーバーに接続し、実際のリクエストを完了できるか
Homeで選択中の項目を確認し、サブスクリプションのグループ名だけで判断しないでください。Connectivity Testを実行したら、遅延値が表示されたのかタイムアウトしたのかを確認し、続いてブラウザーから実際のリクエストを試します。テスト方法や接続先によって結果は異なります。遅延値が出ても、接続の一部が成功したことしか確認できず、アカウント認証、TLSハンドシェイク、接続先へのアクセスまで成功したとは限りません。
自分で用意したサブスクリプションを利用している場合は、更新後にサーバーアドレス、ポート、選択中の項目を再確認してください。古い項目が一覧に残っていても、現在有効とは限りません。手動で追加した項目は、プロトコルと認証情報を個別に確認します。たとえば、TrojanのパスワードとTLS設定、VLESSのUUID、Shadowsocksの暗号方式とパスワードは、それぞれ別のものです。ポートは自分の設定に従ってください。TLSを使用しているからといって、すべて443に変更してはいけません。
- すべての項目がタイムアウトする場合：まずWi-Fiとモバイルネットワークで結果を比較します。特定のネットワークだけで失敗するなら、そのネットワークの接続制限、認証状態、UDPの利用可否を優先して確認してください。
- 特定の項目だけ失敗する場合：サーバーアドレス、ポート、認証情報、サービスの稼働状況を自分のサービス提供元に確認します。クライアント全体をリセットする必要はありません。
- 遅延は正常なのにウェブページが開かない場合：実際のリクエストで発生したエラーを確認します。TCP接続が成功しても、TLSや認証で失敗することがあります。また、テスト先とウェブページで到達性が異なる場合もあります。
- Hysteria2で失敗する場合：Hysteria2はQUICをベースとしており、UDP通信を使用します。一般的なTCPテストが成功しても、対象のUDP経路が使えるとは限りません。WireGuardでもUDP通信の条件を確認してください。
エラー：connection timed out
原因：制限時間内に必要な応答がありませんでした。サーバーへの到達不能、経路上のパケットロス、ネットワークによるフィルタリングなどが考えられます。タイムアウトだけでパスワードの誤りとは判断できません。
対処法：まずサーバーアドレスとポートを確認し、同じ項目のままネットワークを切り替えて再テストします。その項目だけタイムアウトが続く場合は、サーバーの稼働状況を自分のサービス提供元に確認してください。
エラー：connection refused
原因：接続先のポートが接続を受け付けていません。ポートの設定ミス、サービスが待ち受けていない、中継機器による拒否などが考えられます。
対処法：現在の設定に基づいてポートとプロトコルを確認してください。ポートが明示的に拒否されている場合、DNSを変更しても解決しません。
ここで紹介したのは、ネットワークログに記録されることがあるエラーの原文です。失敗のたびに必ず表示される固定のポップアップではありません。エラーを記録するときは、発生時刻と接続先も一緒に残してください。診断情報を共有する前に、サブスクリプションのtoken、パスワード、UUIDなどの認証情報を隠してください。
2つ目：Global Routingのモードがテスト目的に合っているか
Home → Global Routingを開き、現在のモードを確認します。モードによってリクエストの処理経路が決まり、接続スイッチの状態とは別に設定されています。まずモードを確認してから、ルールに問題があるかを判断してください。Directになっている場合、接続スイッチがオンでも通常のリクエストが現在のプロキシサーバー経由で転送されることはありません。
| モード | 処理内容 | 確認方法 |
|---|---|---|
| Config | 現在のConfigに設定されたルールに従って処理方法を選択します。 | 普段の通信振り分けが正しいか確認するには、現在使用中のConfigも確認してください。 |
| Proxy | 通常の通信を現在のプロキシ経路で処理します。 | 一時的にConfigと比較し、通常の振り分けルールが判断に与える影響を減らします。 |
| Direct | 直接接続の経路を使用します。 | プロキシ経路との比較に使用します。これだけでは、リモートのプロキシサーバーが使えることは証明できません。 |
| Scene | Configに設定されたシーン条件に応じて、実際の処理方法を決定します。 | 現在のネットワークでどのSceneが適用されたかを確認してください。「Scene」という名前だけで接続経路を判断しないようにします。 |
最初に現在のモードを記録し、一時的にProxyへ切り替えます。同じサーバーで同じ接続先にアクセスした後、Configに戻して再テストしてください。Proxyではアクセスでき、Configではできない場合は、Config内のルールとポリシーの選択を優先して確認します。両方で失敗する場合は、ルールだけが原因とは限りません。Proxyとの比較でも、すべてのネットワーク設定を完全に切り分けられるわけではなく、DNS、サーバー設定、ネットワーク経路が複合的に影響することがあります。
まとめ：モードを比較して原因を絞り込む
同じネットワーク、サーバー、接続先でProxyは成功し、Configは失敗する場合は、成功したサーバー設定を維持してConfigの適用ルールとポリシーの振り分け先を確認します。プロトコルとDNSを同時に変更しないでください。
3つ目：DNSエラーは名前解決のどの段階で起きているか
通常、ウェブページへのリクエストでは、まずドメイン名をIPアドレスに変換してから接続します。DNSがタイムアウトすると接続先を取得できません。一方で、プロキシサーバーのホスト名も事前に名前解決が必要な場合があります。失敗しているのがプロキシサーバーのホスト名なのか、ウェブサイトのドメイン名なのかを区別してください。以降の確認手順が異なります。
Settings → DNSを開いて現在の設定を確認し、ConfigにDNSへ影響する設定が含まれていないかも確認してください。画面上の項目を1つ変更しただけで、すべてのリクエストがそのDNSサーバーを使うとは限りません。アプリ独自の暗号化DNS、既存のキャッシュ、異なる名前解決経路によって、実際の結果が想定と異なる場合があります。
- エラーの対象を確認します。ログで名前解決に失敗したホスト名を記録してください。サーバーのホスト名が解決できない場合は、まずその問題を解消します。接続先のウェブサイトを切り替えても、サーバーが正常かどうかは確認できません。
- 最近の変更を元に戻します。DNSを手動で設定してから問題が起きた場合は、元の値を記録して変更を戻し、再テストしてください。判断材料を増やさないため、出所が分からないDNSアドレスを一度に複数追加しないでください。
- DNSサーバーへの到達性を確認します。従来型DNSでは53番ポートが一般的です。暗号化DNSの場合は、対応するサーバーへの接続と証明書の検証も正常に行える必要があります。暗号化されていても、接続できるとは限りません。
- 新しいリクエストを送ります。設定を保存したら、いったん切断して再接続し、接続先のページを閉じてから開き直します。キャッシュの影響が疑われる場合は、関連するアプリを再起動してテストしてください。以前のページ表示を、新しい名前解決の結果とみなさないようにします。
- アドレスファミリーを切り分けます。特定のネットワークだけで失敗する場合は、IPv6経路が関係していないか確認してください。一時的な比較で原因を絞り込めますが、変更内容を記録し、IPv6を無効にすることを万能の対処法と考えないでください。
エラー：No such host is known
原因：Windowsで発生することがあるホスト名の名前解決エラーです。現在の名前解決で利用可能な結果が得られなかったことを示しますが、リモートのポートが開いているかどうかは判断できません。
対処法：まずホスト名の入力ミスがないか確認し、使用中のネットワークとDNS設定を確認してください。自分のサーバーのドメイン名であれば、ドメインが現在有効かどうかをサービス提供元に確認します。
4つ目：ルールがREJECTまたはDIRECTに一致していないか
Home → Global Routing → Configに戻り、Configを開いて実際に有効な設定を確認します。通常のルールは上から順に確認され、最初に一致したルールが後続の処理を決定します。前のルールに一致しなかった場合にのみFINALへ進みます。サブスクリプションのサーバー更新とルール設定の更新は別の操作です。サーバー一覧を更新しても、現在のルールが更新されたとは限りません。
以下はルールの構造を示す例です。example.comとドキュメント用のIPアドレス帯を使用しており、そのまま使える設定ではありません。ここでのPROXYはプロキシポリシーを表します。実際の設定では、対応するポリシー名と接続先が存在することを確認してください。
[Rule]
DOMAIN-SUFFIX,example.com,REJECT
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY- DOMAIN-SUFFIX：1行目はexample.comとそのサブドメインに一致し、REJECTへ振り分けます。後続のFINALが、先に一致した拒否ルールを上書きすることはありません。
- IP-CIDR：接続先のIPアドレス帯に基づいて一致します。例のno-resolveは、このルールへの一致判定のためにドメイン名を積極的に名前解決しないことを示します。すべてのDNSリクエストを停止するという意味ではありません。
- GEOIP：接続先IPアドレスの地理情報に基づいて一致します。ウェブサイトの表示言語やドメイン末尾で判定するものではなく、データベースや実際の名前解決結果によって判定が異なることもあります。
- FINAL：前のルールに一致しなかった通信を処理します。実際のConfigがFINAL,DIRECTなら、一致しなかった接続先は直接接続され、Homeで選択したサーバーが自動的に使われるわけではありません。
一部のウェブサイトだけ開けない場合は、そのリクエストのドメイン名、一致したルール、最終的なポリシーを確認してください。ウェブページはメインのドメインに加え、ログイン、スクリプト、画像などのドメインにもアクセスすることがあります。トップページが表示されてもログインできない場合、必要なドメインの一つだけが拒否されている可能性があります。失敗したリクエストに対応するルールを修正し、1つのリソースのためにフィルタールール全体を削除しないでください。
DIRECTはエラーを意味するのではなく、直接接続を示します。現在のネットワークから接続先へ直接アクセスできない場合に、DIRECTに一致するとアクセス失敗につながります。同様に、ルールがプロキシポリシーを選んでいても、そのポリシーが実際に指しているサーバーが使えるかを確認してください。PROXYと表示されたことだけで調査を終えないようにします。
まとめ：実際に一致したルールを修正
ログで接続先がREJECTになっている場合は、該当ルールと順序を確認します。DIRECTの後にタイムアウトする場合は、本来プロキシを使う接続先かどうかを確認してください。プロキシ経由でも接続に失敗する場合は、サーバーとDNSの確認に戻り、関係のないルールを繰り返し変更しないでください。
よくある質問と設定の復元
4項目の確認が終わったら、診断用に一時変更した設定を根拠のある状態に戻してください。特にProxy、On Demand、一時的なDNS設定は、テストに成功したからといって元の利用目的を忘れないようにします。以下の質問を参考に、自動再接続、ルールのフォールバック、ネットワークによる違いを確認してください。
接続スイッチをオフにしても、なぜ自動でオンに戻るのですか？
まずSettings → On Demandが有効か確認します。元の状態を記録して一時的にオフにし、手動で切断して再テストしてください。端末にほかの自動接続管理設定がないかも確認します。確認が終わったら、元の利用条件に合わせて設定を戻してください。
遅延はとても低いのに、ウェブページの読み込みが終わらないのはなぜですか？
遅延テストだけでは、リクエスト全体の成功を確認できません。サーバーを固定し、ウェブページのリクエストで名前解決が完了したか、TLSまたは認証の段階で失敗したかを確認してから、ProxyとConfigを比較してください。遅延の数値だけを見て、サーバーを何度も切り替えないようにします。
Proxyに切り替えたら直りました。このまま使い続けてよいですか？
Configの振り分け経路を優先して確認する必要があるということです。すべてのリクエストを長期的にプロキシ経由にするのが適切とは限りません。Configに戻し、失敗した接続先に一致したルール、FINALの処理先、ポリシーで実際に選択されたサーバーを確認してください。
Wi-Fiでは失敗し、モバイルネットワークでは使えます。まず何を確認すればよいですか？
サーバー設定はそのままにし、まずWi-Fiのログイン認証が済んでいるか確認します。そのうえで、そのネットワークのDNS、外部接続の制限、UDPの利用条件を確認してください。同じ設定でネットワークを切り替えたら成功したという結果は、ネットワーク間の違いを特定する手がかりです。アプリを再インストールする必要があるという意味ではありません。
- 必要なGlobal Routingモードに戻し、現在のConfigが想定どおりか確認します。
- On Demandを元の状態に戻し、ネットワーク切り替え後に実際にどの経路で通信しているか確認します。
- 変更内容を記録しておきます。症状、変更した項目、変更前後の結果を残せば、次回同じ確認を繰り返さずに済みます。
- 自分のサービス提供元に問い合わせる場合は、エラーの発生時刻、プロトコル、ネットワークの種類、認証情報を伏せたログだけを伝えてください。サブスクリプションのリンクや認証情報をそのまま公開しないでください。