ShadowrocketのGlobal Routingは接続のルーティング方法を決める機能で、サーバーを提供するものではありません。本記事では、利用可能なサーバーとサブスクリプションをすでにお持ちの方を対象に、Config・Proxy・Directの使い分け、切り替え手順、ルールの判定方法を解説します。また、一度に変更する設定を一つに絞るトラブルシューティング手順も紹介します。「サーバーに接続できない」場合と「ルールで誤った経路が選ばれている」場合を見分け、テスト後に通常の設定へ戻す方法がわかります。
Global Routingの3つのモード：普段はConfigを選択
まず結論です。利用可能なサーバーと設定ファイルがある場合、普段はConfigを使います。ルールによって特定のサイトが誤った経路に振り分けられている可能性があるときは、一時的にProxyへ切り替えます。現在のネットワークから接続先へ直接アクセスできるか確認するときは、一時的にDirectを選びます。これらのモードで変わるのは通信のルーティング方法であり、サーバーのアドレス、ポート、パスワード、プロトコル設定ではありません。
Config：現在の設定に従って振り分け
おすすめ現在有効な設定のルールに基づき、DIRECT、プロキシ、または定義済みの別のポリシーを選択します。先行するルールに一致しない通信はFINALなどのフォールバックルールで処理されるため、「一致しなければ直接接続」とは限りません。
適した用途：普段の利用。ドメインや宛先IPごとに通信を振り分けたい場合。
Proxy：すべてプロキシ経由にする
Shadowrocketが処理する一般的な通信をプロキシ経由に統一し、通常の振り分けルールを一時的に迂回して比較できます。サーバーが有効であること、プロキシプロトコルと転送設定が正しいことは別途必要です。
適した用途：プロキシが使えるか一時的にテストする場合や、Configでの振り分けとの差を調べる場合。
Direct：すべて直接接続にする
Shadowrocketが処理する一般的な通信を、プロキシサーバーを経由せず直接接続します。接続スイッチをオフにする機能ではなく、現在のネットワークからすべての接続先へ直接アクセスできることを保証するものでもありません。
適した用途：現在のネットワークで直接接続できるか比較し、プロキシ経由だけに問題があるか確認する場合。
ここでいう「すべて」はルーティングモードの概要を示す表現であり、デバイス上のすべてのパケットが必ず同じ経路を通るという意味ではありません。システムルーティング、除外設定、LANアクセス、DNSの処理設定によって実際の動作は変わることがあります。メニューにSceneが表示される場合、これはシーンごとに設定を適用するための項目です。本記事では自動切り替えによる影響を避けるため、シーンの条件を固定してConfig・Proxy・Directを比較します。
Home → Global Routing：切り替え前に確認する3項目
Global Routing、現在のサーバー、現在の設定は、それぞれ別の選択項目です。Global RoutingをConfigにしても、必要な設定がインポートまたは有効化されたことにはなりません。また、Homeでサーバーを選んでも、Config内のすべてのポリシーグループが自動的にその選択へ切り替わるわけではありません。複数のポリシーグループを含む設定では、問題が起きた通信に最終的にどのポリシーが適用され、そのグループでどのメンバーが選択されているかを確認してください。
- サーバーを確認：Homeを開き、すでにお持ちのサーバーがインポートされ、必要な項目が表示されていて、設定値が揃っていることを確認します。手動で追加する場合はAdd Serverを使い、プロトコルの種類とポートには既存の設定値を入力します。サブスクリプションの内容はSubscribeからインポート・更新します。
- 設定を確認：Configを開き、使用する設定ファイルが有効になっていることを確認します。変更する場合は、日常利用の設定にテスト用ルールを上書きしないよう、先に複製を保存してください。
- モードを選択：Home → Global Routingに戻り、Config・Proxy・Directのいずれかを選択します。その後Homeに戻り、選択内容が想定どおりか確認してください。
- テスト接続をやり直す：接続スイッチがオンであることを確認し、接続先のページを開き直します。切り替え前に確立した長時間接続は、以前の経路を使い続けることがあります。必要に応じて対象アプリを終了して再起動してください。接続をやり直すと進行中のセッションが切れるため、通話中やダウンロード中は避けましょう。
Configのルール判定：順序とFINALのフォールバック
Configではルールの内容と順序が重要です。一般的なルールリストでは上から順に判定され、最初に一致したルールのポリシーが適用されます。そのため、特定のドメインを対象とするルールは、広範囲な地域やネットワーク帯のルールより前に置くのが一般的です。設定ファイルにドメインが記載されているだけで適用されると決めつけず、より上に一致するルールがないかも確認してください。
以下はルールの順序を説明するための[Rule]の例で、既存ファイルをそのまま置き換えられる完全な設定ではありません。example.comは説明用のドメインです。使用前に、設定内のPROXYポリシーが利用可能か確認してください。既存の設定で独自のポリシーグループ名を使っている場合は、実際の名前と定義をそのまま維持します。
[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ポリシーで処理します。この文字列を含む任意のURLに一致するルールではありません。IP-CIDR,192.168.0.0/16,DIRECT,no-resolve：指定した宛先IPv4ネットワークに一致した通信を直接接続します。no-resolveは、このIPルールとの照合のためにドメイン名の名前解決を能動的に行わないという意味で、クライアント全体のDNSを無効にする設定ではありません。GEOIP,CN,DIRECT：宛先IPの地域データベース上の判定に基づいてDIRECTを選択します。ウェブページの言語やドメインの末尾で判定するものではありません。FINAL,PROXY：それ以前のルールに一致しなかった通信を処理します。既存ファイルがFINAL,DIRECTの場合はフォールバック先が異なります。変更前に普段の利用方法を確認してください。
ウェブサイトはページ、画像、ログイン、APIなど複数のドメインへ同時にリクエストすることがよくあります。トップページは開けてもログインできない場合は、メインドメインだけにルールを追加するのではなく、失敗したリクエストのドメインと適用ポリシーを確認してください。IPルールやGEOIPの判定は名前解決の結果にも左右されます。DNSの変更とルーティングルールの変更は分けてテストし、どの変更が結果に影響したか特定しましょう。
ProxyとDirectを比較：ルールの問題と接続の問題を切り分ける
比較時は同じネットワーク、同じ接続先、同じサーバーを使い、Global Routingだけを切り替えます。こうすれば結果を比較できます。一度のテストでサブスクリプションの更新、Wi-Fiの切り替え、DNSの変更、サーバーの変更を同時に行うと、アクセスできるようになっても原因を特定しにくくなります。以下は判断の目安であり、すべてのネットワークでの動作を保証したり、速度測定の結果を示したりするものではありません。
比較手順：接続先を固定してプロキシ経由と直接接続を確認
Proxyではアクセスできる
- 接続先とテスト結果を記録し、Configに戻して同じリクエストを試します。
- Configだけ失敗する場合は、一致したルールと実際のポリシーグループのメンバーを確認します。
- Configで別のサーバーに接続される場合は、同じサーバーに固定して比較します。
- 接続ログの接続先とポリシー情報を確認し、DIRECTルールが先に一致していないか調べます。
Directではアクセスできる
- 現在のネットワークから、その接続先へ直接アクセスできる経路があることを示します。
- Proxyで失敗する場合は、サーバーへの接続、認証設定、接続先側のアクセス制限を確認します。
- たとえば、既存の設定値でポートが443と指定されている場合は、よく使われる値に独自に変更せず、Add Serverのポート設定と照合してください。
- TLS、Server Name、転送設定も既存の設定値と一致しているか確認します。
結論：比較テストは問題の範囲を絞り込むためのものです。Proxyで成功しても設定全体が正しいとは限らず、Directで成功してもプロキシサーバーの故障とは限りません。テスト後はConfigに戻してください。
ProxyとDirectのどちらでも失敗する場合は、まずデバイスから既知の別のページにアクセスできるか確認し、その後、接続先サービス、DNS、ネットワーク制限を調べます。特定のアプリ機能だけ失敗する場合は、「ページは開くが、ログインを送信するとタイムアウトする」のように具体的な操作を記録してください。「ネットワークに接続できない」とだけ記録するより、該当するリクエストを特定しやすくなります。
Subscribe・プロトコル・On Demand：切り分ける設定項目を混同しない
サブスクリプションの更新で取得できるのは、すでにお持ちのサブスクリプションに含まれるサーバー情報です。現在の設定ファイルに適切な振り分けルールが含まれるとは限りません。逆に、Configのドメインルールを変更しても、サーバーのパスワード誤りは直りません。問題を調べる前に、「サーバー情報」「設定ルール」「接続を開始する条件」の3つに分けて確認してください。
| 確認する項目 | 場所・内容 | 確認すべき点 |
|---|---|---|
| サーバー情報 | Home / Add Server / Subscribe | アドレス、ポート、認証、転送設定が、お手元の情報と一致しているか確認します。サブスクリプションの更新後は、項目が引き続き有効か確認してください。 |
| ルーティングと設定 | Home → Global Routing；Config | モードが適切で、現在の設定が有効になっており、一致したルールが想定するポリシーを指定しているか確認します。 |
| オンデマンド接続 | Settings → On Demand | 現在の接続条件によって接続が再確立されるか、テスト中に自動動作で状態が変化していないか確認します。 |
Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuardはプロトコル名であり、Global Routingのモードではありません。Proxyを選んでもVLESSがTrojanに変わることはなく、不足している認証情報が補われることもありません。プロトコルの設定値は、お手元の情報に従って入力してください。TLSを使う接続では、証明書の検証、Server Name、転送関連の項目も確認します。通常の解決方法として証明書検証を無効にしないでください。
- テスト中に接続をオフにしても自動的にオンへ戻る場合は、Settings → On Demandを確認し、現在の条件を記録してください。必要に応じて関連する条件を一時的に無効にし、テスト後に元へ戻します。
- サブスクリプション更新後にサーバー名や項目が変わった場合は、ポリシーグループのメンバー参照を確認し、ルールがすでに存在しない選択先を参照しないようにしてください。
- 接続は確立しているのに接続先へアクセスできない場合は、まずルーティングを比較します。サブスクリプションの取得自体に失敗する場合は、サブスクリプションURLの有効性を個別に確認し、すべてのルールを書き直すことは避けてください。
Global Routingのよくある質問と復旧時の確認
Configを選んだのに、すべてのサイトがプロキシ経由に見えるのはなぜですか？
Configを開き、現在の設定ファイルのルールとFINALを確認してください。接続先が先行する直接接続ルールに一致せず、末尾がFINAL,PROXYであれば、プロキシ経由になるのはその設定の動作です。実際の接続ログも確認し、範囲の広いルールやポリシーグループの選択が想定と異なる結果を招いていないか調べてください。トップページを開けるかどうかだけで、すべてのリクエストの経路を判断しないでください。
Proxyなら使えるのに、Configに戻すとタイムアウトします。サブスクリプションを再インポートすべきですか？
まず再インポートはせず、同じサーバーに固定して2つのモードを比較し、Configで接続先に一致したルールとポリシーグループを確認してください。ルールが接続先をDIRECTや利用できないメンバーへ振り分けている場合は、該当ルールまたはメンバーを修正してから接続をやり直します。再インポートで項目が変わると、切り分ける要因が増えることがあります。
Directを選んでも接続中の表示が消えません。切り替えに失敗していますか？
必ずしもそうではありません。Directはルーティングの選択であり、クライアント接続を切断する設定ではありません。Home → Global Routingに戻り、Directが選択されていることを確認してください。接続を停止したい場合は、Homeの接続スイッチを操作し、Settings → On Demandの既存条件によって接続が再開されないかも確認します。
ルールを変更したのに、再生中の動画が以前の経路を使い続けています。どうすればよいですか？
まず再生を停止して関連ページを閉じ、もう一度開いて新しい接続で確認します。既存の接続は確立時の経路を使い続ける場合があります。必要に応じて、重要な作業を中断しないよう配慮したうえでクライアント接続を再確立してください。テストに成功したらGlobal RoutingをConfigに戻し、一時変更したOn Demandの条件も元に戻っていることを確認します。
最後に、テスト対象、ネットワークの種類、使用したサーバー、3つのモードでの結果、変更したルールを簡潔に記録しておきます。サブスクリプションのトークン、パスワード、認証情報を含むURL全体は記録しないでください。同様の問題が再発したとき、すべての設定を最初から変更せず、前回の確認結果をもとに調べられます。