この記事では、Shadowrocketに接続設定を追加したものの、Global Routingでどれを選べばよいか迷っている方に向けて解説します。まず、ルールに従って処理するConfig、すべての通信をプロキシ経由にするProxy、すべての通信を直接接続にするDirectの違いを確認し、決まった手順で新しいリクエストの経路を検証します。通常はConfigから使い始め、ProxyとDirectは経路の一時的な切り替えや原因の切り分けに利用します。サーバー設定やルールそのものの確認に代わるものではありません。
1. 接続スイッチ・Global Routing・現在の設定を区別する
Homeの接続スイッチはShadowrocketのVPN接続を確立するかどうかを決め、Global Routingは接続後のリクエストの経路を決めます。Configで選択した設定ファイルには、ルールなどの設定が含まれます。この3つには関係がありますが、互いに代用はできません。Global RoutingをProxyに変更しただけでは接続は開始されません。また、システムにVPNマークが表示されても、すべてのリクエストがプロキシサーバーを経由しているとは限りません。
ここでいう「すべてプロキシ経由」「すべて直接接続」とは、Shadowrocketの処理対象となる通信についての説明です。デバイス上のすべての通信を例外なく保証するものではありません。ルートの除外設定、ローカルネットワーク設定、DNS処理、既存の接続などが確認結果に影響する場合があります。切り替え後はステータスバーだけで判断せず、新しいリクエストを送信して確認してください。
2. Config・Proxy・Directの経路と使い分け
直接接続が必要なサービスとプロキシ経由が必要なサービスの両方を日常的に利用する場合は、Configを使うのが基本です。ただし、現在の設定ファイルにあるルールが用途に合っていることが前提です。Configは「一部のリクエストは自動で直接接続し、残りは自動でプロキシ経由にする」という固定テンプレートではありません。各ドメインの処理方法や最終的な振り分け先は、読み込まれているルールとポリシーによって決まります。
Config：現在の設定にあるルールで振り分け
おすすめリクエストはルールの順番に照合され、該当するルールでDIRECT、PROXY、または設定ファイル内の別のポリシーが選ばれます。どのルールにも該当しない場合は、FINALなどのフォールバック設定で経路が決まります。Configを選んだら、Configで想定したファイルが有効になっていることも確認してください。
向いている用途：明確なルールに基づいて、日常的に通信を振り分けたい場合。
Proxy：すべてプロキシ経由で接続
処理対象となる通常のリクエストは、すべてプロキシ経由になります。通常の振り分けルールごとにDIRECTやPROXYを選ぶ動作には依存しません。ただし、利用可能なプロキシサーバーが必要です。モードを切り替えても、誤ったアドレス、ポート、認証情報は修正されません。
向いている用途：プロキシが利用できるかを短時間で確認する場合や、失敗の原因がルールによる振り分けにあるかを切り分ける場合。
Direct：すべて直接接続
処理対象となる通常のリクエストは、プロキシサーバーを経由せずに送信されます。変わるのはリクエストの出口の選択であり、ShadowrocketのVPN接続が切断されるわけではありません。また、DNSなどの処理が接続をオフにした場合と完全に同じになるとは限りません。
向いている用途：現在のネットワークで直接接続できるか確認する場合、ローカルネットワーク上のリソースを試す場合、プロキシ経路の影響を一時的に切り分ける場合。
ProxyとDirectは「より速い」「より安定している」といった優劣ではなく、比較検証の条件として使うのが適切です。プロキシ経路が使えるかどうかはサーバーとネットワークによって異なり、直接接続できるかどうかは現在のネットワークから接続先に到達できるかによります。同じWebサイトの挙動が2つのモードで異なる場合は、トラブルシューティングの手がかりになりますが、設定全体の良し悪しを示す結論ではありません。
3. Configのルール照合：個別ルールからFINALまで
Configでは、通常のルールが設定ファイルの順に確認され、最初に一致したルールのポリシーがリクエストに適用されます。そのため、範囲の狭い例外ルールは、範囲の広いルールより前に置くのが一般的です。以下はルールの構文と順序を示す例であり、接続設定一式ではありません。予約済みアドレスと例示用ドメインは、利用できるサービスを示すものではありません。
[Rule]
DOMAIN-SUFFIX,intranet.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY| キーワード | 例での役割 | 確認ポイント |
|---|---|---|
DOMAIN-SUFFIX | 指定したドメインとそのサブドメインに一致します。 | intranet.example.com の例外ルールは、より広い範囲に一致する example.com のルールより前に置きます。 |
IP-CIDR | 接続先IPアドレスが属するネットワーク範囲に一致します。 | no-resolve は、このルールの照合のためにドメイン名の名前解決を積極的に行わないことを示します。すでに接続先IPアドレスがある場合は、引き続き照合に利用できます。 |
GEOIP | IPアドレスの地理的な割り当て情報に基づいて照合します。 | 判定はIPアドレスのデータに依存します。ドメインの用途やコンテンツの属性を判定するものではありません。 |
FINAL | それ以前のルールに一致しなかったリクエストを処理します。 | この例では PROXY を指定しているため、Configで残った通信がすべて直接接続になるとは限りません。 |
ドメインルールを照合するには、照合に使えるドメイン情報が必要です。接続先IPアドレスしかない場合、すべてのDOMAIN-SUFFIXルールに照合されるとは限りません。問題を調べる際は、設定ファイル内でドメイン名を検索するだけでなく、接続記録の接続先、適用されたルール、最終的なポリシーをあわせて確認してください。ルールがポリシーグループを参照している場合は、グループで現在選択されている出口も確認します。
4. モード切り替え後の確認手順
検証では変更する条件を1つに絞ります。ネットワーク、接続先、プロキシサーバーを固定し、Config、Proxy、Directの順にテストしてください。ブラウザーの古いタブでは既存の接続が使われ続けたり、キャッシュが表示されたりする場合があります。切り替え後に一度更新しただけでは、経路が変わった証拠にはなりません。古いリクエストを終了してアクセスし直し、該当時刻の新しい接続記録を確認してください。
- 開始時の状態を記録する。Homeで現在のサーバーと接続状態を確認し、Configで有効なファイルを確認します。アクセス権のある接続先を1つ選び、テスト時刻を記録して、別々のリクエストの結果を混同しないようにします。
- まずConfigをテストする。Home → Global Routing → Configを開き、新しいリクエストを送信します。接続記録で接続先、適用ルール、ポリシーを確認してください。DIRECTと表示された場合は、すぐにサーバーを変更するのではなく、現在のルールに沿った結果かを先に確認します。
- 次にProxyをテストする。Home → Global Routing → Proxyを開き、サーバーと接続先は変えずに、もう一度リクエストを送信します。この状態では成功しConfigでは失敗する場合、ルールの照合、ポリシーグループの選択、DNSの違いを重点的に確認してください。
- 最後にDirectをテストする。Home → Global Routing → Directを開き、同じ接続先にもう一度リクエストを送信します。Directでは成功しProxyでは失敗する場合、プロキシ接続の設定値、サーバーの状態、プロキシ経路での名前解決の問題を確認してください。
- テスト後は通常の設定に戻す。比較が終わったらConfigに戻し、ルールの結果をもう一度確認します。トラブルシューティングの記録には、繰り返し確認できた現象のみを残し、一度の成功やタイムアウトだけで結論を出さないでください。
一般的なWebページのHTTPSではTCP 443が使われ、HTTP/3ではUDP 443が使われる場合があります。これらは接続先サービスのポートであり、プロキシサーバーのポートを443に変更する必要があるという意味ではありません。ブラウザーは異なる通信方式にフォールバックする場合があるため、遅延テストに成功しても、両方の通信経路が正常とは限りません。サーバーのポート、プロトコル、認証情報は、既存の設定に基づいて確認してください。
2つの比較パターン：ルールとプロキシ経路のどちらを先に調べるか
Configでは失敗し、Proxyでは成功する
- Configで正しい設定ファイルが有効になっているか確認します。
- 同じ接続先への新しい記録を探し、適用ルールと最終ポリシーを確認します。
- 範囲の広いルールが先に一致していないか、FINALが想定どおりか確認します。
Proxyでは失敗し、Directでは成功する
- Homeで選択したサーバーがテスト前と同じか確認します。
- アドレス、ポート、認証情報、プロトコル関連の項目を確認します。
- 同じネットワークで再試行し、エラーの種類を記録します。DNSとルールを同時に変更しないでください。
比較結果は原因の範囲を絞るために使います。3つのモードすべてで失敗する場合は、ネットワークの到達性、DNS、接続先サービスの状態、接続記録をあらためて確認してください。
5. Global Routingでは変更されない設定
Global Routingが決めるのは「リクエストがどの経路を使うか」であり、接続パラメーターの作成や接続サービスの提供は行いません。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuardはプロトコル名で、Config・Proxy・Directとは異なる判断レイヤーに属します。プロトコル設定に誤りがある場合、モードを切り替えても不足している項目は補われません。
- サブスクリプションの追加と更新：サブスクリプションは利用中のサービス事業者から取得します。更新すると事業者が公開した接続情報を取得できますが、更新後に端末上のルールやGlobal Routingまで自動的に希望どおりになるとは限りません。
- On Demand：自動接続の条件はSettings → On Demandで確認します。ここで設定するのは接続を開始するタイミングであり、Configを選択する設定でも、すべてのリクエストをプロキシ経由にする保証でもありません。手動で切断してテストする際は、自動接続条件によって再接続されないかも確認してください。
- DNS：ドメイン名の名前解決は出口ポリシーと関係しますが、同じ設定ではありません。モードを変更しても名前解決に失敗する場合は、Global Routingを繰り返し切り替えるのではなく、DNS設定を個別に確認してください。
- アプリの購入：アプリの買い切り購入と回線プランは別のものです。ShadowrocketはAppleプラットフォーム向けのクローズドソースの商用アプリで、入手先はApp Storeのみです。価格、システム要件、購入の適用範囲はApp Storeの掲載内容をご確認ください。
初回接続時は、システムの案内に従ってVPN構成の追加を許可する必要があります。この許可はシステムの接続権限に関するもので、現在のプロキシに接続できることや、ルールの検証が済んでいることを示すものではありません。まず許可を完了して接続を確認し、前のセクションの手順で項目ごとにテストすると、権限、設定値、通信の振り分けの問題を切り分けられます。
6. 切り替え時によくある4つの質問
Configを選んだのに、特定のWebサイトが直接接続になるのはなぜですか？
まずConfigで有効な設定ファイルを確認し、そのWebサイトへの新しいリクエストに適用されたルールを調べてください。DOMAIN-SUFFIX、GEOIP、FINALがDIRECTを指定している場合や、ポリシーグループで直接接続が選択されている場合があります。Global RoutingにConfigと表示されているだけでは、そのWebサイトがプロキシ経由になるとは限りません。
Proxyに変更すると開けます。ルールに必ず誤りがあるということですか？
2つのモードで経路に違いがあることは分かりますが、特定の行の構文エラーとはまだ断定できません。同じサーバーとネットワークを使い、Configで適用されたルール、ポリシーグループの出口、名前解決の結果を比較してください。違いを特定してから、該当する設定を変更します。
DirectにしてもVPNマークが表示されます。切り替えに失敗していますか？
VPNマークはシステムのトンネルが確立したままであることを示しますが、通信がプロキシサーバーを経由していることを示すものではありません。Directはルーティングモードです。接続を切るにはHomeの接続スイッチをオフにします。切断後に自動で再接続される場合は、Settings → On Demandを確認してください。
切り替えても開いているWebページに変化がありません。どう確認すればよいですか？
まず古いページのリクエストを終了してからアクセスし直し、同じ時刻の新しい接続記録を確認してください。必要であれば一度切断して再接続し、長時間維持されている接続の影響を除外します。テスト中はGlobal Routingだけを変更し、サーバー、ルールファイル、DNSを同時に切り替えないでください。比較条件が保てなくなります。
日常の操作は、まず接続と設定を確認してConfigで使い始める、問題が起きたらProxyとDirectを比較して切り分ける、原因を見つけたらConfigに戻して新しいリクエストで該当ルールを確認する、という順序で進められます。ルールによる振り分けを保ちながら、トラブルシューティング用のモードを端末に戻し忘れることも防げます。