この記事は、Shadowrocketに自分のサブスクリプションを追加済みで、Global Routingの選択に迷っている方向けです。「接続中かどうか」「どのサーバーを使うか」「通信をどう振り分けるか」を分けて確認し、同じ接続先でConfig・Proxy・Directの動作を比較します。普段はルールを確認したConfigを選び、一時的な全通信のProxy化やルールの切り分けにはProxy、直接接続の確認にはDirectを使います。切り替え後は新しいリクエストで動作を確認し、調査が終わったら元の設定に戻しましょう。
1. 接続のオン／オフ、サーバー、Global Routingを区別する
Global Routingは、Shadowrocketが処理する通信のルーティング方法を決める設定です。サーバーを提供する機能でも、接続のオン／オフでもありません。Homeでサーバーを選んでも、すべてのリクエストがそのサーバーを経由するとは限りません。Configを選んだ場合、各リクエストの経路は現在の設定ファイルにあるルールとポリシーによって決まります。
まずHomeでGlobal Routingを開き、現在の選択項目を確認します。次にConfigで、使用中の設定ファイルを確認してください。Settingsの機能設定は別の項目です。たとえばSettings → On Demandでは条件に応じた接続動作を管理しますが、ドメインごとにDIRECTやPROXYを指定する設定ではありません。
画面によってはSceneも表示されます。Sceneはシーンごとにルーティングの選択を整理する機能で、固定の通信出口がもう1つ増えるという意味ではありません。Sceneを使用している場合は、現在のシーンで実際に適用されている設定も確認してください。ここでは、シーン切り替えによる変数を避けるため、手動で選択する3つのモードを基準に説明します。
2. Config・Proxy・Directの通信経路
Config：現在の設定ファイルに従って処理
推奨リクエストは現在の設定ファイルにあるルールとポリシーに従って処理されます。DIRECTに一致すれば直接接続、PROXYに一致すればプロキシ経由、REJECTに一致すれば拒否されます。前のルールに一致しない場合、通常はFINALで経路が決まります。Configは「一部のドメインだけプロキシを使う」という意味ではありません。
用途：ルールとFINALを確認したうえで、日常的に通信を振り分ける場合。
Proxy：すべての通信をプロキシ経由にする
クライアントが処理する通信は、Configのルールで個別に出口を選ぶのではなく、一律にプロキシ経由になります。実際にアクセスできるかどうかは、使用するサーバー、プロトコル設定、DNS、接続先のサービスにも左右されます。
用途：一時的にすべてをプロキシ経由にする場合や、Configのルールとポリシーを比較して調査する場合。
Direct：すべて直接接続にする
クライアントが処理する通信は直接接続され、選択中のプロキシサーバーを経由しません。ただし、クライアントの接続状態が維持されたり、DNSなどが処理されたりすることはあります。Directは接続を完全にオフにする設定ではありません。
用途：現在のネットワークから接続先に直接アクセスできるか確認する場合や、一時的にプロキシ経由を避ける場合。
ここでいう「すべて」は、クライアントが実際に処理する通信の範囲に限られ、デバイス上のあらゆる通信を保証するものではありません。システムの動作、除外設定、既存の接続によって、観察結果が変わることがあります。Proxyを選んでも、すべてのDNSリクエストが同じプロキシ経由になるとは限りません。
3. 4つのルールで理解する、Configが固定の出口ではない理由
以下はルールを読むための例です。設定ファイルの[Rule]セクションにあるものとして確認してください。example.comは説明用のドメインです。普段のアクセス用ルールとして追加する必要はありません。テストのために、使用中の設定ファイル全体を上書きしないでください。
[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYDOMAIN-SUFFIX,example.com,DIRECT：example.comとそのサブドメインに一致し、DIRECTを使用します。notexample.comには一致しません。IP-CIDR,192.168.0.0/16,DIRECT,no-resolve：このアドレス範囲に一致する通信にDIRECTを使用します。no-resolveは、このルールへの一致判定のためにドメイン名の名前解決を行わないことを示します。GEOIP,CN,DIRECT：クライアントが使用するGeoIPデータに基づき、接続先IPがCNに属するかを判定します。Webページの言語、ドメインの末尾、ユーザーの所在地で判定するものではありません。FINAL,PROXY：前のルールに一致しない場合、PROXYを使用します。FINAL,DIRECTに変更すると、最後に適用される経路も変わります。
ルールは上から順に照合され、最初に一致したルールのポリシーが適用されます。テスト用ドメインが先にDIRECTに一致した場合、後ろにPROXYのルールがあってもプロキシ経由にはなりません。また、ポリシーが設定ファイル内のポリシーグループを指している場合は、グループで現在選択されている項目も確認してください。ルールの最後のフィールドだけでは判断できません。
4. 日常の振り分けと一時的なトラブルシューティングの設定方法
日常的にConfigを使うには、設定ファイルの入手元、ルールの適用範囲、FINALの動作を把握しておく必要があります。設定内容を確認していない場合、「推奨」という説明だけで現在のネットワークに適しているとは判断できません。サブスクリプションには通常サーバー情報が含まれ、設定ファイルにはルールやその他のパラメーターを含められます。両者は同じものではありません。
2つの手順：安定した日常利用と、変数を1つに絞った切り分け
日常利用：Config
- Configで使用中のファイルを確認し、DIRECT・PROXY・FINALをチェックします。
- Homeで利用可能なサーバーを確認し、Global Routing → Configを選択します。
- 直接接続される想定の接続先と、プロキシ経由の想定の接続先をそれぞれ確認します。
- 自動接続が必要な場合は、別途Settings → On Demandを確認します。
一時的にProxy / Directへ切り替える
- 元のルーティングモード、設定ファイル、選択中のサーバーを記録します。
- ネットワークとテスト対象を固定し、Global Routingだけを切り替えます。
- 以前のリクエストを終了してから対象に再アクセスし、新しい接続の結果を確認します。
- 結果を記録してConfigに戻し、普段使うサービスで動作を再確認します。
一度に変更する変数は1つだけにします。ルーティングの切り替え、サブスクリプションの更新、サーバーの変更、DNSの変更をまとめて行わないでください。
モードを切り替えても、既存の長時間接続がすぐに再確立されるとは限りません。音楽再生、メッセージアプリ、ブラウザーで再利用されている接続などは、そのまま継続することがあります。対象の通信を停止してから、接続先を開き直してください。クライアントを切断して再接続する場合は、維持が必要なセッションがないことを先に確認します。
5. 現象から原因を探る：Proxyでは使えるのにConfigでは使えない
この現象はルーティングの違いを調べる手がかりになりますが、「特定のルールが必ず間違っている」とは限りません。経路によって出口、名前解決の結果、接続先のアドレスが異なる場合があります。以下の順に確認すると、原因を絞り込み、サーバーの問題をルールの問題と取り違えにくくなります。
- 条件を固定する。接続先ドメイン、現在のWi-Fiまたはモバイル回線、選択中のサーバー、接続状態を記録します。同じ接続先に新しいリクエストを送り、ConfigとProxyそれぞれの結果を記録してください。レイテンシーテストの数値をWebページへのアクセス結果と混同しないでください。
- Configで実際に一致したルールを確認する。クライアントで利用できるリクエストや接続のログを確認し、接続先ドメイン、接続先IP、適用ルール、ポリシーを照合します。DIRECTやREJECTに一致していないか、別のサーバーを指すポリシーグループが選ばれていないかを確認してください。
- フォールバックを確認する。前のルールに一致しない場合に適用されるFINALのポリシーを確認します。プロキシを想定していたのに実際はDIRECTになった場合、設定の意図なのかルール漏れなのかを先に確認し、すぐにすべてのルールを変更しないでください。
- ドメインとIPの違いを確認する。接続先が別のドメインにリダイレクトされたり、複数のリソース用ドメインを読み込んだりする場合があります。トップページのドメインにだけルールを設定しても、ログイン用API、画像、メディアの通信まで対象になるとは限りません。
- 変更は必要最小限にする。まず現在の設定ファイルをバックアップし、対象に関係するルールやポリシーだけを変更して、新しい接続で確認します。原因を特定したら、不要な一時設定を元に戻してください。
ProxyとConfigではアクセスできず、Directならアクセスできる場合は、ルールを書き直す前にプロキシ経路と選択中のサーバーを確認してください。3つのモードすべてで失敗する場合は、現在のネットワーク、接続先の稼働状況、DNSなど共通する条件を調べます。DirectでもクライアントのDNS設定が使われることがあります。システムネットワークの基準状態と比較する場合は、重要なセッションがないことを確認してからクライアントを切断し、別途テストしてください。
6. Global Routingに関するよくある質問
Proxyを選んでも、特定のアプリが開かないのはなぜですか？
まずHomeで選択中のサーバーと接続状態を確認し、同じ接続先に新しいリクエストを送ってテストしてください。プロキシ経路が使えても、接続先サービスがその出口からのアクセスを許可するとは限りません。DNS、接続先の制限、プロトコル設定も確認してください。具体的な失敗リクエストを調べずに、モードを何度も切り替えて済ませないようにしましょう。
Directを選んだのに、接続中の表示が消えないのはなぜですか？
Directで変更されるのは通信経路であり、クライアントの終了ではありません。接続を停止するにはHomeの接続スイッチを操作してください。その後、自動で再接続される場合はSettings → On Demandで起動条件を確認します。システム上の接続表示だけを見て、リクエストがプロキシサーバーを経由したかどうかを判断しないでください。
サブスクリプションを更新すると、自分に合ったConfigのルールが自動で設定されますか？
そのようには判断できません。サーバー情報のサブスクリプション更新と、設定ファイルのルール管理は分けて確認してください。更新後はHomeでサーバー情報を確認し、Configで使用中のファイルとルールを確認します。サブスクリプションURLはサービス提供元から取得してください。認証情報を含むURLを公開の記録に貼り付けないでください。
Configを確認せずに、Proxyをずっと使ってもよいですか？
用途に応じて選べますが、すべてをプロキシ経由にすると、本来は直接接続できるリクエストの経路も変わり、LAN内のリソース、アクセス速度、接続先サービスの判定に影響することがあります。通信を振り分ける場合はConfigに戻し、必要なDIRECTルールを明確に設定してください。Proxyを設定ミスの隠蔽に長期間使わないようにしましょう。
iPadに移行した後も、ルーティング設定を確認する必要がありますか？
必要です。新しいデバイスでHome → Global Routing、Configの使用中のファイル、Settings → On Demandをそれぞれ確認してください。設定ファイルを移行した場合でも、現在のネットワークで実際の動作を検証しましょう。デバイスによってネットワーク環境や接続条件は異なることがあります。
操作の目的は、次のように確認できます。日常的にルールで振り分けるならConfig、一時的に全通信をプロキシ経由にするかルールを比較するならProxy、直接接続を確認するならDirectを選びます。判断の基準はモード名だけではなく、「新しいリクエストがどのルールに一致し、最終的にどの経路を通るか」です。