利用中のサービスやサブスクリプションがあり、Global Routingの選び方が分からない場合は、まず「接続が有効か」と「リクエストがどう振り分けられるか」を分けて考えましょう。Config・Proxy・Directの比較、ルール例、条件を固定したテストを通じて、Configを通常利用する際の前提や、Proxy・Directで問題を切り分ける方法を解説します。Scene、On Demand、サブスクリプションの更新がそれぞれ担う役割も整理します。
1. 接続状態を確認してからGlobal Routingを選ぶ
ShadowrocketはAppleプラットフォーム向けの有料クライアントで、入手先はApp Storeのみです。App Storeの商品ページに記載されたアプリIDは932747118、開発者はShadow Launch Technology Limitedです。アプリは買い切りで、システム要件はApp Storeのページをご確認ください。アプリの購入に接続サービスは含まれません。以降は、利用者がすでにサービス提供元とサブスクリプションを用意していることを前提に説明します。
Global Routingは、Shadowrocketが処理するリクエストのルーティング方法を決める設定です。接続のオン・オフやサーバーの選択とは異なります。接続を有効にせずProxyに切り替えても、プロキシが機能しているかは判断できません。また、システムにVPNの表示があっても、特定のWebサイトが最終的にプロキシ経由か直接接続かは分かりません。
- Homeで利用可能なサーバー項目があることと、現在の選択を確認します。ポリシーグループを使っている場合は、グループ内の選択も確認してください。
- Configで現在有効な設定ファイルを確認します。ファイルをインポートしただけでは、そのファイルが選択されて使われているとは限りません。
- Home → Global Routingに戻り、Config、Proxy、Directのいずれかを選んでから、接続を有効にするか、接続状態を確認します。
- 新しいWebリクエストを発行し、リクエストログで接続先と適用されたポリシーを確認します。既存の接続では以前の経路が再利用されることがあるため、古いページだけを見て判断しないでください。
2. Config・Proxy・Directの違いと選び方
3つのモードが変更するのはルーティングの判断方法です。サーバー設定が自動で補われたり、期限切れのサブスクリプションが修復されたりするわけではありません。通常利用でConfigを選ぶには、現在の設定ファイルにあるルールとポリシーの適用先が正しいことが前提です。設定内容が分からない場合は、Config自体を動作の保証と考えず、まずルールを確認してください。
Config：現在の設定に基づいて判定
推奨ルールの順序に従ってポリシーを決定します。ルールに一致すると、DIRECT、PROXY、REJECT、または設定ファイルで定義されたポリシーグループが適用されます。前のルールに一致しなかった場合は、通常FINALが処理します。「それ以外はすべて直接接続」と決まっているわけではありません。
適した用途：ルールを確認済みで、接続先ごとに経路を分けたい日常利用。
Proxy：すべてプロキシ経由にする
処理対象の通常のリクエストを一律にプロキシ経由にします。ルールごとに直接接続かプロキシかを判定する必要はありません。ただし、サーバーが利用できない、認証に誤りがある、プロトコル設定が一致しないといった場合は、Proxyに切り替えても接続できません。
適した用途：一時的にプロキシ経路を検証し、問題がルールによる振り分けに関係するかを確認する場合。
Direct：すべて直接接続にする
処理対象のリクエストをリモートプロキシ経由にせず、直接接続します。「すべてのネットワーク処理を停止する」設定ではなく、接続をオフにしたときのシステム本来のネットワーク環境とも異なります。
適した用途：一時的に直接接続できるかを検証し、プロキシ経路が問題の原因か比較する場合。
「レイテンシが低い」という理由だけでモードを選ばないでください。特定のテスト先のレイテンシが示すのは、そのテスト条件における結果だけです。Webページは複数のドメインにリクエストを送ることがあり、それぞれDNS、TCP、TLS、コンテンツの読み込みが関係します。Configで一部を直接接続し、一部をプロキシ経由にした結果と、Proxyですべてをプロキシ経由にした結果を、1つの数値だけで比較するのは適切ではありません。
3. Configのルール判定：順序・ポリシー・FINAL
Configではルールを上から順に確認することが重要です。通常の順序判定では、最初に一致したルールがリクエストに適用するポリシーを決めます。広い範囲を対象にするルールを先に置くと、後ろの具体的なルールが適用されないことがあります。つまり、ルールを記述しただけで、そのリクエストに必ず適用されるわけではありません。
以下は説明用の[Rule]部分のみで、完全な設定ファイルではありません。サーバー情報も含みません。example.comは例示用のドメインです。PROXYはプロキシポリシー、DIRECTは直接接続ポリシーを表します。編集前に現在の設定をバックアップし、ポリシー名と参照先が有効であることを確認してください。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY| ルールキーワード | 対象 | 確認ポイント |
|---|---|---|
DOMAIN-SUFFIX | ドメイン本体とそのサブドメイン | example.comはwww.example.comに一致しますが、この文字列を含むすべてのドメインに一致するわけではありません。 |
IP-CIDR | 宛先IPv4アドレスの範囲 | 192.168.0.0/16はプライベートアドレスの範囲です。no-resolveは、このルールのために追加のドメイン名前解決を行わないことを示します。 |
GEOIP | IPアドレスの地域判定 | 結果は使用するデータベースと宛先IPアドレスによって異なります。ドメインの末尾だけでは判断できません。 |
FINAL | それ以前のルールに一致しなかったリクエスト | この例ではPROXYを指定しています。DIRECTに変更すると、一致しなかったリクエストの出口経路も変わります。 |
Proxyなら開けるページがConfigでは失敗する場合は、まず、そのリクエストにDIRECT、REJECT、または利用できない別のポリシーグループが適用されていないか確認してください。すぐに対象範囲の広いルールを追加するのは避けましょう。実際に失敗したドメインを特定し、その前にあるルールとFINALを確認してください。1つのリクエストを直すために、関係のない多数のリクエストの経路まで変えてしまうおそれがあります。
4. 同じ接続先で切り分ける：一度に変更する条件は1つ
切り分け中は、同じWi-Fiまたはモバイル通信、同じサーバー、同じ接続先を使います。テスト前に元のモードと設定ファイル名を記録し、テスト後に元へ戻してください。サブスクリプションの更新、サーバーの切り替え、DNSの変更、モードの切り替えを同時に行うと、アクセスが回復してもどの操作が有効だったのか分かりません。
2つの比較：ルール経由と直接接続
ConfigとProxyを比較する
- まずConfigで新しいリクエストを発行し、実際に適用されたポリシーを記録します。
- サーバーは変えず、Global RoutingだけをProxyに変更します。
- リクエストを新たに発行します。Proxyだけが成功する場合は、ルールの順序とポリシーグループの選択を優先して確認してください。
ProxyとDirectを比較する
- 現在のネットワークから直接接続できる接続先を、基準として選びます。
- ProxyとDirectをそれぞれ使って新しいリクエストを発行し、成功またはタイムアウトを記録します。
- Directでは成功しProxyでは失敗する場合は、サーバーへの接続、認証、転送方式、DNSの経路を確認してください。
モードの比較は問題の範囲を絞り込むためのものです。一度成功しただけで原因を特定したと判断せず、テスト後は元の設定に戻して再確認してください。
Directで失敗しても、プロキシサーバーの故障とは限りません。そのリクエストはリモートプロキシを使っていないためです。反対にProxyで失敗しても、ルールに誤りがあるとは限りません。この比較では通常の振り分けルールが判断要因にならないためです。どちらのモードでも失敗する場合は、まずローカルネットワーク、接続先サービスの状態、名前解決を確認し、その後に個別の接続パラメーターを確認してください。
- ページの一部だけが読み込まれる：アドレスバーのメインドメインだけでなく、読み込みに失敗したリソースのドメインを確認してください。画像、ログイン、API通信には別々のポリシーが適用されることがあります。
- 切り替えても変化がないように見える：開いているページを閉じ、新しい接続を開始してください。必要であれば、短時間の通信中断が許容される状況でShadowrocketを再接続し、古いセッションの影響を避けます。
- Webページは使えるが、ほかの機能は失敗する：TCPやUDPなど、それぞれに必要な転送方式を確認してください。Webページが表示できたからといって、すべてのリクエストが成功するとは限りません。
5. Scene、On Demand、サブスクリプションの更新は別の機能
Global RoutingにはSceneもあります。設定済みのシーン条件に応じてルーティングを切り替えるため、ネットワーク環境に合わせて経路を変更したい場合に使えます。別のプロキシプロトコルではありません。まずConfig、Proxy、Directで条件を固定してテストし、その後でSceneを検討してください。こうすれば、シーンの切り替えによって切り分け条件が予期せず変わるのを防げます。
Settings → On Demandは、接続をオンデマンドで確立する条件を管理します。一方、Global Routingが扱うのは、接続中のルーティング判断です。モードを手動で比較するときは、既存の条件によって接続状態が変わらないよう、先にOn Demandを確認してください。切り分けが終わったら、必要な設定を元に戻します。
サブスクリプションの更新はサーバー項目を更新する機能です。Proxyに切り替えても自動で更新されず、現在のConfigルールが更新された証明にもなりません。サブスクリプションの取得結果が空、または更新に失敗した場合は、リンクが正しいか、登録済みのサブスクリプションが有効か、更新時のネットワークに問題がないかを個別に確認してください。サブスクリプションの問題を調べるために、Global Routingを何度も切り替えないでください。
- 登録済みのサブスクリプションの状態を確認し、アプリ内の更新操作でサーバー一覧を更新します。
- 更新後にHomeへ戻り、以前選択していた項目が残っていることと、現在の選択が意図どおりであることを確認します。
- 次にConfigで、有効なファイルとポリシーの参照先を確認します。サーバー一覧の更新とルールファイルの更新は、別々に確認する必要があります。
- 最後に通常利用のモードへ戻し、直接接続する想定の接続先と、プロキシ経由にする想定の接続先を1つずつ確認します。
6. よくある質問：モード切り替え後の確認方法
Configを選べば、日本国内は直接接続で、それ以外はすべてプロキシ経由になりますか？
必ずしもそうではありません。Configで現在有効なファイルのルール、特にGEOIPとFINALを確認してください。「日本国内は直接接続」とするには、それに対応したルールとデータが必要です。FINALがDIRECTなら、ほかのルールに一致しなかったリクエストも直接接続されます。Configという名前だけで結果を判断することはできません。
Proxyでは開けるのにConfigでは開けません。Proxyを使い続ければよいですか？
必要な確認を行う間、一時的にProxyを使うことはできます。ただし、リクエストログでConfig使用時に失敗したリクエストへ適用されたポリシーを特定し、Configに戻して該当ルールまたはポリシーグループを確認してください。修正後はConfigに戻し、新しいリクエストで結果を確かめます。1つのドメインのために、すべてのリクエストの経路を長期間変更しないでください。
DirectはHomeの接続スイッチをオフにするのと同じですか？
同じではありません。Directは接続中に使う直接接続ポリシーで、Shadowrocketが引き続きリクエストを処理する場合があります。接続をオフにすると、この処理経路は使われません。システム本来のネットワーク環境を確認する場合は、Settings → On Demandの状態を先に記録し、オンデマンド接続によってテスト条件が変わらないようにしてください。
Proxyに切り替えてもタイムアウトします。ポートを変更すべきですか？
まず、利用中のサービス提供元から案内されたサーバーアドレス、ポート、認証情報、プロトコル設定を確認してください。Webサイトで一般的なHTTPSポート443を、プロキシサーバーも必ず使うとは限りません。設定を変えずに接続状態を確認し、明確な相違が見つかった場合にのみ修正してください。ポートを次々に試して原因を探る方法は避けてください。
Sceneに切り替えた後、結果が安定しません。どう確認すればよいですか？
まず現在のネットワークとシーンの条件を記録し、Config、Proxy、Directのいずれかに一時的に固定して、同じ接続先を再テストします。固定したモードで正常なら、Sceneの条件と関連設定を確認してください。Wi-Fiとモバイル通信の切り替えで異なるSceneが適用される場合は、それぞれの結果を別々に記録し、同じテストとしてまとめないでください。
日常利用では、接続が有効か、現在の設定が正しいか、実際にどのポリシーが適用されたかを確認し、接続先が想定どおり動作するか検証します。Global Routingはルーティングの判断方法を選び、サーバー設定はリモート接続を確立し、サブスクリプションは項目の取得元を管理します。それぞれを分けて確認するほうが、複数の設定を続けて変更するより再現性のある結論を得やすくなります。