Shadowrocketを普段使う場合は、選択中の設定を確認したうえでConfigを使うのが基本です。Proxyはプロキシ経路の一時確認に、Directはローカルネットワークとの比較に使います。サーバーまたはサブスクリプションをすでに利用している方向けに、3つのモードでリクエストの経路がどう変わるか、複数の設定を同時に変更せず問題を切り分ける方法を説明します。ここでいう「すべて」とは、Shadowrocketの処理対象となる通信を指し、デバイス上の全通信が必ず対象になるという意味ではありません。
1. まずモードを選ぶ：Config・Proxy・Directの処理範囲
Home → Global Routingでモードを選びます。この設定で決まるのはリクエストに適用するルーティングの仕組みであり、サーバーの選択や接続の開始ではありません。対象の通信がShadowrocketの処理範囲に入った場合にのみ、選択したモードが反映されます。接続がオフの状態でここだけ切り替えても、プロキシ接続は確立されません。
Config：設定ファイルのルールに従って振り分ける
おすすめ現在の設定ファイルにあるルールを参照し、リクエストに応じてPROXY、DIRECT、REJECT、または設定ファイルで定義されたポリシーグループを使います。先行ルールに一致しなかったリクエストの処理は、FINALなどのフォールバック設定によって異なり、必ず直接接続になるわけではありません。
適した用途：信頼できる設定を確認済みで、普段から宛先ごとに通信を振り分けたい場合。
Proxy：すべてプロキシ経由にする
処理対象の通信を一律にプロキシ経由にし、通常の振り分けルールごとに経路を決めることはありません。利用可能なサーバーが必要です。モードを切り替えても、プロトコル、DNS、接続先サービス自体の問題は解消されません。
適した用途：一時的にプロキシ経由で接続する場合や、Configと比較してルールやポリシーの選択を切り分ける場合。
Direct：すべて直接接続にする
処理対象の通信を選択中のプロキシサーバー経由にせず、直接接続します。VPNの状態が接続中と表示されることはあるため、ステータスバーの表示だけでは個々のリクエストがプロキシ経由かどうかを判断できません。
適した用途：ローカルネットワークから接続先へ直接アクセスできるか確認し、比較用の結果を取る場合。
Global RoutingにはSceneが表示される場合もあります。これは設定済みのシーン条件に応じて対応する動作を適用する機能で、固定された4つ目の通信経路と考えるべきではありません。シーン条件を確認していない場合は、まずこの記事で扱う明確な3つのモードでテストし、その後にシーン設定を個別に確認してください。
2. 3つの設定箇所を区別する：ルーティングモード・設定ファイル・接続スイッチ
「サブスクリプションを追加済み」というだけでは、サーバー情報があることを示すにすぎず、ルール設定が正しいとは限りません。サーバーのサブスクリプションには主に接続パラメータが含まれ、設定ファイルにはルールなどの設定が含まれる場合があります。それぞれ別に更新されることがあり、名前が似ていても同じ内容が使用中とは限りません。
- まずHomeを確認：選択中のサーバーが利用するサーバーと一致し、接続情報がそろっていることを確認します。Global Routingを切り替えても、サーバーアドレス、ポート、認証情報は修正されません。
- 次にConfigを確認：現在選択されている設定ファイルを確認します。ファイルを保存または読み込んだだけで有効になったとは限りません。リストに戻り、選択状態を確認してください。
- 最後に接続スイッチを確認：接続が確立してから、新しいリクエストを送ります。すでに確立されている長時間接続では、切り替えたばかりのモードを判断できません。
利用中のサブスクリプションが更新された場合は、まずサーバーリストに以前選択していた項目が残っているかを確認し、実際の接続先も確認してください。サブスクリプションの更新とGlobal Routingの切り替えは別の操作です。同じモードでも、選択中のサーバーが変われば結果も異なる場合があります。
3. Configで経路が決まる仕組み：ルールの評価順とFINALのフォールバック
Configで重要なのは「一部はプロキシ、残りは直接接続」という大まかな説明ではなく、実際のルール内容です。通常の振り分けルールは順番に評価され、先に一致したルールによって、後続のルールが適用されるかどうかが変わります。以下は構文を読むための例です。ドメイン名は説明用で、接続テスト用のアドレスではありません。また、設定ファイル全体をこの例に置き換えないでください。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYDOMAIN-SUFFIX,example.com,PROXY：ドメインの末尾がexample.comまたはそのサブドメインに一致すると、PROXYを使用します。先行ルールに一致している場合、この行では経路が決まりません。IP-CIDR,192.168.0.0/16,DIRECT,no-resolve：このプライベートIPv4アドレス範囲に一致する通信でDIRECTを使用します。no-resolveは、このルールへの一致判定のためにドメイン名を積極的に名前解決しないことを示します。GEOIP,CN,DIRECT：IPアドレスの地理的な割り当てに基づいて判定し、DIRECTを使用します。Webページの言語やドメイン名の文字列で判定するものではありません。FINAL,PROXY：先行するルールに一致しなかった場合、PROXYを使用します。FINAL,DIRECTと記述した場合は、フォールバック先が異なります。
そのため、Configにすれば自動的にプロキシ経由の通信が減るわけでも、特定のWebサイトが必ず直接接続になるわけでもありません。設定内のPROXYは、選択中のサーバーやポリシーグループにも関係する場合があるため、ポリシーの参照先も確認してください。構文の詳細はルールリファレンスをご覧ください。1つの接続先を直すために、すべてのルールを削除しないでください。
4. 利用場面に応じて選ぶ：普段の振り分けと一時的な切り分け
普段の利用では設定の動作を把握しやすい状態に保ち、問題の切り分けでは変数を減らします。サブスクリプションの更新、サーバーの変更、ネットワークの切り替え、ルールの変更を同時に行うと、アクセスが回復しても、どの操作が影響したのか判断できません。以下の2つの方法では、同じ接続先、同じデバイス、同じネットワークを比較の基準にします。
使い分け：普段はConfig、切り分け時のみ一時的に切り替える
普段の利用
- Configで現在の設定ファイルを確認し、Home → Global RoutingをConfigに設定します。
- 直接接続される想定の接続先と、プロキシ経由になる想定の接続先を、それぞれ確認します。
- 接続先に問題が起きたら、設定ファイル全体をすぐに置き換えず、ドメイン名と時刻を記録します。
一時的な切り分け
- サーバーとネットワークは変えず、ConfigからProxyに切り替えて新しいリクエストを送ります。
- ローカルネットワークと比較する必要がある場合はDirectに切り替え、同じ接続先に再アクセスします。
- 各モードと結果を記録し、テスト後にConfigへ戻して、適用されているポリシーを確認します。
一度に変更するのは1つの要素だけにしてください。特定のモードでWebページが開けても、それだけでは原因を特定できず、切り分けの手がかりにとどまります。
自動再接続も別に確認してください。Settings → On Demandではオンデマンド接続の条件を管理します。ドメインごとにPROXYかDIRECTかを指定する設定ではありません。接続が自動的に再確立される場合は、スイッチの動作を判断する前にOn Demandを確認してください。「自動接続」と「自動振り分け」は別の機能です。
5. 接続できない場合は、再現可能な手順で切り分ける
まずローカルネットワークが利用できることを確認し、次にサーバー、最後にルールを確認します。Connectivity Testは接続確認ツールです。結果はアプリ内で選択したテスト方法とあわせて判断してください。テストに成功しても、すべてのWebサイト、ルール、プロトコルで通信が確認できたとは限りません。
- 現在の状態を記録：ネットワーク、接続先のドメイン名、選択中のサーバー、Global Routingのモード、接続が確立しているかを記録します。パスワードやサブスクリプションURL全体などの機密情報は記録・共有しないでください。
- ローカルネットワークを確認：Directで、普段直接接続できる接続先にアクセスします。それでも失敗する場合は、ルールを変更する前にWi-Fiへの接続、モバイルネットワーク、接続先自体を確認してください。
- プロキシ経路を確認：同じサーバーを選んだままProxyで新しいリクエストを送り、HomeでConnectivity Testを実行します。失敗した場合は、アドレス、実際のポート、認証情報など、利用中の接続パラメータを確認してください。
- Configと比較：Proxyでは成功しConfigでは失敗する場合は、ルールの順序、一致したポリシーグループ、FINAL、名前解決に関する設定を優先して確認します。これは切り分けの手がかりであり、サーバーやDNSに問題がないと証明されたわけではありません。
- 再テストして元に戻す：設定を1か所変更したら、同じ接続先に再度リクエストを送ります。必要に応じて一度切断してから再接続し、既存の接続による影響を除外します。結果を記録したら普段のモードに戻し、一時的な診断設定をそのまま残さないようにしてください。
たとえば、同じ接続先にProxyではアクセスでき、Directではタイムアウトし、Configでもタイムアウトする場合、ConfigでDIRECTに振り分けられていないか、別のポリシーが選ばれていないかを重点的に確認します。これは再現可能な判断方法の例であり、あらかじめ検証された結果ではありません。デバイス上の実際のリクエスト記録と結果を確認してください。
サーバーがShadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuardのいずれを使っていても、3つのモードの基本的な役割は変わりません。プロトコルのパラメータは対応する接続を確立できるかどうかに影響し、Global Routingは適用する経路を決めます。ポートには利用中のサービス設定に記載された実際の値を使用してください。すべてのプロトコルに共通するポートはありません。
6. Global Routingに関するよくある質問
Proxyに切り替えれば、すべてのWebサイトにアクセスできますか？
いいえ。まずHomeでサーバーが選択されていることを確認し、接続を開始してConnectivity Testを実行してください。Proxyは通信経路をプロキシに統一するだけです。サーバーに到達できない、認証に失敗する、接続先から拒否される、名前解決に問題がある場合は、それぞれ個別に対処する必要があります。
Directを選んだのに、ステータスバーにVPNの表示が残るのはなぜですか？
Directはリクエストの経路を示すもので、VPNセッションを終了する設定ではありません。Homeで接続スイッチを確認してください。セッションを終了する場合は接続をオフにし、Settings → On Demandで自動接続の条件が設定されているかも確認します。
Configでローカルデバイスに接続できない場合、どこを変更すればよいですか？
まず接続先の実際のアドレスを記録し、現在の設定にそのネットワーク範囲を対象とするIP-CIDRルールがあるか、また先行ルールに一致していないかを確認します。前述の192.168.0.0/16は特定のアドレス範囲のみを対象とし、すべてのローカルネットワークを表すものではありません。実際のネットワーク範囲を確認し、そのままコピーしないでください。
ルールを変更したのに、同じWebページの表示が変わらないのはなぜですか？
まず変更したのが現在選択中の設定ファイルか確認し、接続を再確立して新しいリクエストを送ってください。ブラウザーのキャッシュや既存の長時間接続により、見た目が変わらないことがあります。同じ接続先で再テストし、ページの表示だけでなく、リクエストに実際に適用されたポリシーも確認してください。
利用中のサブスクリプションを更新した後、ConfigをProxyに変更する必要はありますか？
必ず変更する必要はありません。更新後にサーバーリストと選択中のサーバーを確認し、Connectivity Testで接続を確認してください。普段使うルールはConfigのまま利用できます。プロキシ経路とルールの問題を切り分けたい場合に限り、比較のため一時的にProxyへ切り替えてください。
最終的な選び方は3つです。振り分けが必要で、設定も確認済みならConfig。一時的にプロキシ経路を確認するならProxy。ローカルネットワークと比較するならDirectを選びます。初回接続の手順ははじめに、モードの設定方法はルーティングモードをご覧ください。