利用可能なサーバーと設定がある場合、通常はConfigを選びます。ルールの影響を切り分けるときは一時的にProxyへ切り替え、ローカルネットワークからの直接接続と比較するときはDirectを使います。3つのモードと接続スイッチ、Configファイル、サブスクリプション、On Demandの違いを説明し、条件を一度に1つだけ変えて確認する手順を紹介します。ルーティングの選択ミスをサーバー障害と取り違えないための内容です。
1. Config・Proxy・Directで制御する内容
ShadowrocketのGlobal Routingは、通信のルーティング方法を選択する機能です。サーバーのプロトコルでも、接続成功を示すものでもありません。モードを選んだ後は、Homeの接続状態、選択中のサーバー、実際のアクセス結果を確認してください。以下でいう「すべて」とは、Shadowrocketが処理する通信を指し、端末上のすべてのシステム通信が必ず同じ経路を通るという意味ではありません。
Config：現在の設定に沿って振り分け
推奨現在のConfigに設定されたルールとポリシーに基づいて通信先を決めます。DIRECTに一致したリクエストは直接接続し、プロキシポリシーに一致したリクエストは該当するポリシーで処理します。先行するルールに一致しない通信は、FINALなどのフォールバック設定で処理されます。初期状態ですべてが直接接続されるわけではありません。
用途：明確なルール設定があり、宛先ごとに通信を振り分けたい場合
Proxy：すべてプロキシ経由で接続
Configの宛先別ルールによる直接接続・プロキシ接続の選択を行わず、現在のプロキシ経路に統一します。選択中のサーバーが利用できない場合、Proxyに切り替えてもアドレス、認証情報、通信パラメータは修復されません。
用途：一時的に全通信をプロキシ経由にする場合や、振り分けルールが障害の原因か切り分ける場合
Direct：すべて直接接続
アプリが処理する通信を、プロキシサーバーを経由せず宛先へ直接接続します。リストにサーバーが残っていても、サーバーを選択していても、Directではそのサーバーを使用しません。
用途：ローカルネットワークから宛先にアクセスできるか確認し、直接接続の比較結果を取る場合
Global RoutingにSceneが表示される場合は、アプリ内のシーン設定を確認し、実際に適用されるルーティングを確かめてください。Sceneは「より強いプロキシ」モードではありません。この記事の比較テストではConfig、Proxy、Directを直接選び、シーン条件が結果に影響しないようにします。
2. Homeでモードを切り替える前に、3つの状態を個別に確認
Homeでのサーバー選択、Global Routing、接続スイッチはそれぞれ別の状態です。サーバーを選んだだけで接続が確立していなければ、通信がサーバー経由になったとは限りません。接続後もDirectのままでは、ウェブページにアクセスできるかどうかでプロキシサーバーの有効性を判断できません。切り替える前に現在の状態を記録してください。
- Homeを開き、テストに使うサーバーを確認します。この記事では、利用者自身がサービスプロバイダーと契約していることを前提とします。サーバーのパラメータとサブスクリプションリンクは、契約先のサービスプロバイダーから入手してください。
- HomeでGlobal Routingを開き、Config、Proxy、Directのいずれかを選択します。戻ったら、表示が切り替わったことを確認してください。
- Configを選んだ場合は、画面下部のConfigを開き、リストにファイルがあるかだけでなく、現在選択中の設定ファイルを確認します。
- Homeに戻り、接続が確立していることを確認してから、同じテストページを再度開きます。切り替えても結果が変わらない場合は、古いページを閉じるか既存の接続を終了してから再試行し、必要に応じて再接続してください。
- テスト後は元のモードに戻します。Proxyを一時的に選択したとき、普段の振り分けルールも経路選択に適用されていると思い込まないようにしてください。
3. Configのルールを読む：順序とFINALで結果が決まる
Configは、画面下部の設定管理メニューの名称であり、Global Routingの選択肢の1つでもあります。前者は設定ファイルを管理し、後者は現在の設定に沿ってルーティングを実行します。サーバーのサブスクリプションは「選択できるサーバー」を管理し、ルール設定は「どのリクエストをどの経路にするか」を決めるものです。両者を混同しないでください。
以下は構文を説明するためのルール例で、完全な設定ファイルではありません。example.comは例示用のドメインです。プロキシポリシー名は実際の設定と一致させてください。設定を変更する前に元のファイルを保存し、既存のポリシーグループや必要な設定を上書きしないようにします。
[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とそのサブドメインに一致 | PROXY |
IP-CIDR | 192.168.0.0/16のアドレス範囲に一致。no-resolveは、このルールのためにドメイン名を積極的に解決しないことを示します。 | DIRECT |
GEOIP | IP地理データベースを使ってCNに一致。結果はデータベースと取得した宛先IPの影響を受けます。 | DIRECT |
FINAL | 先行するルールに一致しなかったリクエストを処理 | PROXY |
ルールは上から順に照合され、最初に一致したルールで経路が決まります。この例ではexample.comのプロキシルールがGEOIPより前にあるため、宛先IPの地域だけで直接接続になるとは判断できません。FINALは末尾に置きます。フォールバックルールを前に置くと、後続の個別ルールが想定どおりに機能しません。
- 特定のドメインを直接接続するには、適切な位置にDIRECTを指定するルールを追加し、それより前に一致するルールがないか確認してください。
- ローカルネットワークへのアクセスを確認するときは、まず宛先がどのアドレス範囲に属するかを確認します。192.168.0.0/16は一例であり、すべてのローカルネットワークアドレスを網羅するものではありません。
- 変更後はGlobal RoutingをConfigにして、新しいリクエストを送信し、一致したルールとポリシーを確認します。ProxyまたはDirectのままでは、この振り分けルールの効果を検証できません。
4. 日常利用とトラブル切り分けでは、設定を使い分ける
日常利用では安定した設定動作が必要ですが、トラブルの切り分けでは変数をできるだけ減らします。この2つの作業を同時に進めないでください。サーバーの変更、サブスクリプションの更新、DNSの変更を一度に行うと、アクセスが回復しても何が原因だったのか分からなくなります。
操作方針：日常の設定を固定し、ルーティングだけを個別に比較
日常利用
- Global RoutingはConfigに設定し、現在の設定にあるルールとFINALの経路を確認します。
- 確認済みのサーバーとポリシーグループを使用し、名前だけで実際の接続先を推測しないでください。
- サブスクリプション更新後はサーバーが引き続き存在するか確認し、削除済みの項目に依存しないようにします。
一時的なトラブル切り分け
- 同じネットワーク、同じサーバー、同じテスト対象に固定します。
- Config、Proxy、Directの順に切り替え、新しいリクエストの結果を記録します。
- 各テストで変更する設定は1つだけにし、終了後は元の設定とモードに戻します。
結論：Proxyはルーティングを比較するための手段であり、あらゆる接続障害を直すスイッチではありません。Configが適切かどうかは、現在のルールが用途に合っているかで決まります。
プロトコルもGlobal Routingの代わりにはなりません。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuardはサーバーへの接続方式を示し、Config、Proxy、Directはリクエストのルーティング方法を決めます。ルーティングを切り替えるためにType、Port、認証情報をむやみに変更しないでください。各パラメータはサービスプロバイダーから案内された内容に合わせます。
5. テスト結果から問題の範囲を絞り込む
同じ対象に接続して比較し、接続タイムアウト、名前解決の失敗、ページのエラー表示など、具体的な失敗内容を記録します。「開けない」だけでは原因を特定できません。以下はテスト結果を読み取るための目安であり、特定の経路の利用可能性を保証するものではありません。
| 確認できた結果 | 優先して確認する項目 | 次の手順 |
|---|---|---|
| Proxyではアクセスできるが、Configではアクセスできない | ルールの一致状況、ポリシーグループの選択、DNSの違い | Configに戻り、該当リクエストに実際に一致したルールとポリシーを確認します。サーバーをすべて作り直す必要はありません。 |
| Directではアクセスできるが、Proxyではアクセスできない | 現在のプロキシ経路とサーバーのパラメータ | Address、Port、認証情報を確認します。プロトコルでTLSを使う場合は、関連するTLS項目も確認してください。 |
| ProxyとDirectの両方でアクセスできない | ローカルネットワーク、宛先サービスの状態、名前解決の結果 | アクセス可能と分かっている別の宛先でも比較し、ネットワークの認証が必要か確認します。 |
| 切り替えても、開いていたページの状態が変わらない | 接続の再利用、キャッシュ、接続状態 | リクエストを新たに送信し、必要に応じて再接続してからテストします。 |
- まずローカルネットワーク自体が利用できることを確認します。ウェブ認証が必要なネットワークでは、先に認証を完了してください。
- サーバーを固定し、一時的にProxyを選択して、同じ対象への新しいリクエストをテストします。
- Configに切り替えてテストします。この場合だけ失敗するなら、対象に一致するルールやポリシー、関連する名前解決設定を重点的に確認してください。
- 比較のためDirectを選択します。ただし、Directで成功してもプロキシサーバーが検証済みという意味ではありません。
- サーバーをさらに確認する必要がある場合は、自分のサービスプロバイダーに連絡し、発生した問題を伝えてください。モードとエラー情報を伝えれば十分です。認証情報を含むサブスクリプションリンク全体は公開しないでください。
6. サブスクリプション、On Demand、モード切り替えのよくある質問
Proxyを選べば、接続をオンにしなくても使えますか？
いいえ。Global Routingで選択するのはルーティング方法です。Homeに戻って接続状態を確認し、新しいリクエストを送信してください。Proxyを選択しただけでは、プロキシ経路が確立したことにはなりません。
サブスクリプションを更新したのに、Configで想定どおりに振り分けられないのはなぜですか？
サーバーリストを更新しても、ルールが書き換わるわけではありません。まずHomeで現在のサーバーを確認し、次にConfigで現在の設定、ルールの順序、ポリシーグループの参照先を確認してください。サブスクリプションリンクはサービスプロバイダーから入手します。更新後も参照先が有効か確認してください。
On Demandを有効にしていても、Configを選ぶ必要がありますか？
それぞれ個別に確認してください。Settings → On Demandではオンデマンド接続の条件を管理し、Global Routingでは接続後のルーティングを管理します。まずオンデマンドの条件を確認し、Homeに戻ってルーティングモードを確認してください。On Demandで振り分け設定を代用することはできません。
Directと接続スイッチをオフにする操作は、何が違いますか？
Directはアプリの接続中に選ぶルーティング方法です。接続スイッチをオフにすると、現在の接続が切断されます。完全に切断した状態のネットワーク動作を確認する場合は接続をオフにし、On Demandの条件によって再接続されないかも確認してください。
Shadowrocketを購入したのに、サーバーが表示されないのはなぜですか？
アプリの買い切り購入は、通信サービスの契約とは別です。Shadowrocketはクローズドソースの商用アプリで、入手先はApp Storeのみです。サブスクリプションは契約先のサービスプロバイダーから入手してください。アプリを購入しても、サーバーリストは自動的に作成されません。
最後に、あとから確認できる操作記録を残します。元のモード、変更後のモード、テストした対象、結果を記録してください。日常利用に戻す際は、Homeのサーバー、Global Routing、接続状態を改めて確認します。画面操作はチュートリアル、ルールキーワードの意味は用語集で確認できます。