Shadowrocketの使い方：Global RoutingのConfig・Proxy・Directの違い

この記事の要点

利用できる接続情報がある場合、普段はConfigを選び、現在の設定に基づいてリクエストごとのルートを決めます。Proxyは一時的に通信をプロキシ経由にして比較・切り分ける場合、Directは直接接続を確認する場合に使います。各モードの範囲や切り替え手順、トラブルの確認方法を解説し、「接続スイッチがオン」と「リクエストが実際にプロキシを使う」の違いを整理します。

モードの選び方：Configはルールに従い、ProxyとDirectは比較に使う

ShadowrocketのGlobal Routingは、処理対象となるリクエストのルーティング方法を決めます。サーバー一覧でも、接続サービスを提供する機能でもありません。モードを選ぶ前に、Homeに利用可能なサーバー情報があることを確認してください。情報がない状態でProxyに切り替えても、自動的に接続できるようにはなりません。

Config

Proxy

処理対象となる通常のリクエストを、Configの個別ルールで振り分けずにプロキシ経由にします。利用するサーバーが使用可能であることに加え、システムや設定による通信の除外も考慮してください。

おすすめの用途：プロキシ経路の一時確認や、ルールの影響の切り分け

Direct

処理対象となる通常のリクエストを直接接続し、選択したプロキシサーバーを経由しません。接続スイッチがオンのままの場合もあるため、Directは接続をオフにするモードではありません。

おすすめの用途：現在のネットワークで直接アクセスした場合の比較

ここでいう「一律」は、デバイス上のすべてのシステム通信を強制的に引き受けるという意味ではありません。実際の処理範囲は、システムのルーティング、設定内の除外項目、アプリの動作にも左右されます。DNSには独立した設定があるため、モード名だけから名前解決に使うサーバーや、すべてのDNSリクエストの経路を判断することはできません。

Global RoutingにSceneが表示される場合は、シーン別に設定するための別の入口として扱い、Configの別名と混同しないでください。この記事では、まず3つの明確なモードを基準に考えます。原因を調べるときは、モードをひとつに固定してから、Sceneの切り替えによる状態変化がないか確認してください。

切り替え手順：現在の状態を記録してから接続し直す

モードはHome → Global Routingから選択します。切り替える前に、現在のモード、選択中のサーバー、Configで使用中の設定ファイルを控えておきましょう。テスト後に元へ戻す項目を確認できます。設定ファイルはルールを決め、サーバー情報はプロキシ接続のパラメーターを決めます。両者は代用できません。

Homeでサーバーを確認します。選択中の情報が、利用者自身が保有し、使用権限のある接続情報であることを確認してください。一覧に表示されているだけでは、現在利用できるとは限りません。
Global Routingを開きます。ルールに沿って振り分ける普段の利用にはConfig、プロキシ経路の確認にはProxy、直接接続の確認にはDirectを選びます。
Homeに戻り、接続スイッチを確認します。モードを切り替えただけでは、接続の確立にはなりません。必要に応じて再接続し、新しいテストを明確な状態で行ってください。
リクエストを新しく送ります。テスト中のページを閉じて開き直すか、対象アプリの接続を再開してください。再生中のコンテンツや既存の長時間接続だけを見て判断しないでください。
テスト後は元に戻します。普段使うモードに戻し、選択中の設定とサーバーが想定どおりか確認してください。

接続スイッチをオフにしても自動でオンに戻る場合は、Settings → On Demandの条件を確認してください。On Demandは必要に応じた接続を管理し、Global Routingは接続後のルーティングを管理します。自動接続されたからといって、今回のテストに適したモードが自動で選ばれるわけではありません。

普段使いにConfigが適している理由：ルールを確認してからFINALを見る

Configの利点は、特定の種類のサイトが必ず同じ経路を通ると決めつけず、宛先ごとに処理を分けられることです。結果は現在の設定に全面的に依存します。通常、ルールは上から順に確認され、先に一致したルールのポリシーが適用されます。そのため、同じConfigでも設定を変えると結果が異なることがあります。

3種類

この記事で比較するモード：Config、Proxy、Direct

4種類

以下の例で使うルール：DOMAIN-SUFFIX、IP-CIDR、GEOIP、FINAL

1つ

例の末尾にあるFINALのフォールバックルール

以下はルールの順序を説明するための抜粋であり、完全な設定ファイルでも、そのまま利用できる接続情報でもありません。ドメイン名は説明用です。実際に編集する際は、Configで元のファイルを複製してから対象の設定を変更してください。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,DIRECT

DOMAIN-SUFFIX,example.com,PROXY：example.comとそのサブドメインにPROXYを適用します。他のドメインにもプロキシが適用されるという意味ではありません。
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve：該当するIPv4アドレス範囲に一致します。no-resolveは、このIPルールに一致させるためのドメイン解決を積極的に行わないことを示します。
GEOIP,CN,DIRECT：アプリが使用するGEOIPデータに基づいて宛先IPを判定します。ページの言語やサイト名で判定するものではありません。
FINAL,DIRECT：それまでのルールに一致しない場合は直接接続します。末尾をFINAL,PROXYに変更すると、一致しなかったリクエストのデフォルト経路も変わります。

REJECTは通信を拒否するポリシーであり、利用できないサーバーを選ぶこととは異なります。現在の設定に対象と一致するREJECTルールがあれば、サーバーのテストが正常でも、Configではリクエストが拒否されることがあります。ルール内のカスタムポリシーグループを使っている場合は、グループ内の選択内容も確認してください。ルールに記載されたグループ名だけでは判断できません。

切り分け：Proxyでは接続できるのにConfigではできない場合、対象に一致するルールを確認

サーバーとネットワークは変えず、対象ドメインに先に一致するルール、対応するポリシーグループ、FINALを確認してください。プロトコルの設定をすぐに入力し直す必要はありません。この比較で確認範囲を絞れますが、原因の特定にはDNSと接続ログも確認してください。

ProxyとDirectの使い方：条件を固定して比較する

Proxyは個別ルールによる振り分けを一時的に避けたい場合、Directは現在のネットワークで直接接続したときの基準を確認する場合に便利です。どちらも診断用の手段であり、速度を保証するものではありません。Proxyに切り替えて遅くなった場合は、プロキシ経路やサーバー負荷が変わった可能性があります。Directで接続できない場合も、現在のネットワークから対象に直接アクセスできない可能性があり、それだけでアプリの設定が壊れているとは判断できません。

比較の条件：同じ宛先、同じネットワーク、同じサーバー

プロキシ経路を確認：Proxy

現在のWi-Fiまたはモバイル通信を記録し、テスト中は意図的に切り替えないでください。
選択中のサーバーを変えずにProxyを選び、テスト用の接続を再確立します。
同じ宛先にアクセスし、成功、タイムアウト、接続中断などの具体的な結果を記録します。
Configに戻って再試行し、モードによる差が繰り返し現れるか確認します。

直接接続を確認：Direct

Directを選び、同じ宛先に新しいリクエストを送ります。
ページにキャッシュが表示されるかだけでなく、接続を確立できるかを記録します。
接続を完全に無効にした状態を確認する場合は、別途、接続スイッチをオフにしてテストします。
テスト後はConfigに戻し、一時的な設定を普段の状態として残さないようにします。

一度に変更するのはモードだけにしてください。ネットワークやサーバーを変えたり、DNSを変更したりすると、比較結果から原因を特定しにくくなります。

結果を判断するときは、以下の順に確認範囲を絞れます。ここに挙げるのはトラブルシューティングの観点であり、本記事で実測済みのデータを示すものではありません。実際の記録は、そのときのデバイスでの結果を基準にしてください。

確認した結果	優先して確認する項目	次に行うこと
Proxyは正常、Configは異常	ルールの一致、ポリシーグループ、FINAL、DNSの違い	Configに戻って対象のルールを確認し、DIRECTやREJECTに一致していないか確認する
Directは正常、Proxyは異常	選択中のサーバー、認証情報、通信パラメーター	利用者自身が保有する接続情報を確認し、アドレス、ポート、プロトコル、TLSの設定を照合する
3つのモードすべてで異常	基本ネットワーク、接続先の状態、DNS、システム時刻	まず他の宛先にアクセスできるか確認してから、項目ごとに原因を調べます。設定をまとめて変更しないでください。
切り替え後もすぐに結果が変わらない	キャッシュ、接続の再利用、テストリクエストが新規かどうか	接続を再確立し、同じ操作でもう一度テストする

混同しないために：プロトコル、サブスクリプション、On Demandはそれぞれ別の役割

Global Routingは「今回のリクエストがどの経路を使うか」を決め、プロトコルのパラメーターは「プロキシ接続をどう確立するか」を決めます。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuardはそれぞれパラメーターの構成が異なります。モードを変えても、誤って入力した認証情報は修正されず、あるプロトコルが別のプロトコルに変わることもありません。

アドレスとポート：利用者自身が保有する接続情報に従って入力してください。ポートが443であっても、それだけで特定のプロトコルだとは判断できません。また、他のポートを一律に443へ変更する根拠にもなりません。
サブスクリプションの読み込みと更新：利用者自身が保有するサーバー情報を取得または更新するために使います。更新が成功したことは、情報の取得処理が完了したことを示すだけです。一覧内のすべての項目が利用できることや、現在のConfigのルールが想定どおりであることを保証しません。
Config：使用中の設定ファイル、ルールの順序、ポリシーの割り当てを確認します。サーバー情報を読み込んでも、振り分けルールの設定が完了するわけではありません。
Settings → On Demand：自動接続の条件を確認します。Home → Global Routingの選択内容とは、分けて確認してください。

Wi-Fiやモバイル通信に切り替えた後は、現在のモードが想定どおりか確認してからテストしてください。Sceneなどの自動化設定を使っている場合は、その実際の動作も確認します。環境の変化による設定の切り替わりを、同じルールがランダムに動作したと誤解しないようにしてください。

よくある質問：接続スイッチがオンなのに、想定した経路にならない

接続をオンにしたのに、リクエストが直接接続されるのはなぜですか？

まずHome → Global Routingを開き、Directが選択されていないか確認します。Configが選択されている場合は、Configで対象に一致するルールとFINALを確認してください。接続スイッチがオンなのは接続状態を示すだけで、すべてのリクエストがPROXYを使うことを意味しません。

Configを選べば、振り分けは自動で設定されますか？

いいえ。まず使用中の設定ファイルを確認し、ルールとポリシーを照合してください。設定末尾がFINAL,DIRECTの場合、他のルールに一致しないリクエストは直接接続します。Config自体に、すべての人に適した振り分け設定が含まれているわけではありません。

一時的にProxyを選んだ後、そのまま使い続けてもよいですか？

明確な目的があれば、そのまま使うこともできます。ただし、Configのようにリクエストごとに個別ルールで振り分ける動作は続きません。一部の宛先にDIRECTを使っていた場合は、テスト後にHome → Global Routing → Configへ戻し、新しいリクエストで確認してください。

Directと接続スイッチをオフにすることは、同じ意味ですか？

異なります。Directではアプリの接続状態と関連する処理環境が維持されますが、接続スイッチをオフにした状態は別です。アプリの接続環境が原因かどうかを確認するには、それぞれを個別にテストしてください。その際はSettings → On Demandも確認し、条件によってスイッチが再度オンにならないようにします。

サブスクリプションを更新しても接続できません。すぐにProxyへ切り替えるべきですか？

まずHomeで、更新後に実際に選択されている項目を確認し、利用者自身が保有する接続情報とテスト結果を照合してください。Proxyは一時的な比較に使えますが、プロキシ接続自体に失敗している場合、モードを変えてもアドレス、ポート、認証情報の誤りは解決しません。

普段使うモードは、次の手順で選ぶと整理しやすくなります。現在の設定が正しいことを確認してからConfigを使い、問題が起きたらネットワークとサーバーを固定してProxyとDirectで短時間の比較を行い、最後に元の状態へ戻します。テストごとにモード、宛先、結果を記録すると、複数の設定を同時に何度も変えるより原因を見つけやすくなります。