Shadowrocketでは、「指定したドメインにはPROXY、それ以外のリクエストにはDIRECT」を設定して、サイトごとに通信を振り分けられます。自分のサブスクリプションを登録済みで接続できるものの、すべてのサイトをプロキシ経由にしたくない方に向けた手順です。ポイントは、Global Routing → Configを選び、対象ドメインのルールを先に置き、最後をFINAL,DIRECTにすることです。動作確認では、マッチしたルール、最終的なポリシー、Webページが利用する関連ドメインも確認します。
1. Configモードと接続状態を確認する
ルールで決まるのはリクエストに適用するポリシーであり、プロキシ接続そのものを作成するわけではありません。始める前にHomeで利用中のサブスクリプションが登録済みで、選択したサーバーに接続できることを確認してください。この記事ではノードやサブスクリプションの提供・販売・推奨は行いません。例はローカルのルール構成のみを示すもので、接続可能なサービスのアドレスは含みません。
Home → Global RoutingでConfigを選ぶと、現在の構成に設定されたルールに従って通信が振り分けられます。Proxyは全体をプロキシ経由にするモード、Directは全体を直接接続するモードで、どちらもこの記事のドメイン別振り分けの確認には適しません。Sceneはシーンを選択する機能です。シーンの切り替えが確認に影響しないよう、今回の基本的なテストでは使用しません。
- Home：選択中のサーバーと接続スイッチを確認し、Global RoutingでConfigを選択します。
- Config：編集する構成が現在有効になっていることを確認します。同じ名前のファイルが保存されているだけでは不十分です。
- Settings → On Demand：現在の設定を確認します。On Demandは接続を自動的に開始する条件に関する設定で、特定のドメインをPROXYに指定する機能ではありません。
アプリの購入と回線の利用は別です。アプリの買い切り購入は、回線プランの購入を意味しません。ShadowrocketはAppleプラットフォーム向けのクローズドソースの商用アプリで、入手先はApp Storeのみです。iPhone、iPadなどの対応デバイスに必要なシステム要件は、App Storeのページでご確認ください。
2. 基本ルール：対象ドメインを先に、FINAL,DIRECTを最後に
以下のコードは構成ファイルの[Rule]セクションに記述するもので、完全な構成ファイルではありません。example.comとexample.netは例示用のドメインです。実際に振り分けたいドメインに置き換えてください。このコード全体をサブスクリプションのURL欄に貼り付けたり、DNSやポリシーグループなどの設定を含む構成ファイル全体に上書きしたりしないでください。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-SUFFIX,example.net,PROXY
FINAL,DIRECTDOMAIN-SUFFIX,example.com,PROXYは、example.com自体とそのサブドメイン（www.example.com、api.example.comなど）にマッチします。入力するのはドメイン名のみです。https://、ポート、パス、クエリパラメータは含めません。文字列が似ているだけのnotexample.comにはマッチしません。
FINAL,DIRECTは、それより前のルールにマッチしなかった場合にDIRECTを適用します。ルールは上から順に評価され、最初にマッチしたルールでポリシーが決まるため、FINALは末尾に置きます。前に広範囲のPROXYルールが残っていると、そのリクエストはFINALに到達しません。最後の行だけを変更しても、「それ以外はすべて直接接続」になるとは限りません。
構成ファイル全体をバックアップするConfigで元の構成ファイルを複製してから、作業用のコピーを編集します。既存の構成に複数のルールセクション、ルールセットの参照、複雑なポリシーが含まれている場合は、順序と用途を先に確認してください。例の3行を作るために、必要な設定まで削除しないでください。
3. DOMAIN-SUFFIXとDOMAIN-KEYWORDの使い分け
対象サイトのメインドメインが分かっている場合は、DOMAIN-SUFFIXを優先します。DOMAIN-KEYWORDはドメイン文字列の一部に対するキーワードマッチで、通常は対象範囲が広く、「サイト名を判別する」機能ではありません。たとえばキーワードにexampleを指定すると、同じ文字列を含む別の事業者のドメインまでPROXYに振り分けられる可能性があります。
| ルール | マッチする範囲 | 用途 |
|---|---|---|
DOMAIN,api.example.com,PROXY | 指定した完全一致ドメインのみ | 特定のインターフェースドメインだけを変更 |
DOMAIN-SUFFIX,example.com,PROXY | メインドメインとそのサブドメイン | 同じドメイン体系全体を振り分け |
DOMAIN-KEYWORD,example,PROXY | ドメインに指定の文字列を含む | 対象範囲を確認済みのキーワードルール |
キーワードルールが必要な場合は、FINALの前に次の1行を追加します。範囲を確認していないキーワードを多数設定すると、通常のサイトまでPROXYにマッチするおそれがあります。どのルールで範囲が広がったのか特定しにくくなるため、追加は慎重に行ってください。
DOMAIN-KEYWORD,example,PROXYルールでは、同じドメイン内のページを完全なWebページのパスで区別できません。https://example.com/newsとhttps://example.com/accountへのアクセスでは、DOMAIN-SUFFIXから見た対象ドメインは同じです。このルールにパス付きのURLを入力して、片方のページだけをプロキシ経由にすることはできません。
4. Configでルールを適用する5つの手順
作業中は変更する要素をできるだけ絞ります。同じデバイス、同じネットワーク、同じ選択中のサーバーを保ち、一度に変更するルールは1組だけにします。サブスクリプションのサーバー一覧の更新と、ローカルのルールファイルの編集は別の操作です。サブスクリプションを更新しても、編集したConfigが有効になるわけではありません。
-
構成をバックアップする
Configを開き、使用中の構成を見つけて複製を保存します。元々選択されていたファイルを控えておき、問題が起きた際に元の構成へ戻せるようにしてください。
-
ルールを編集する
作業用コピーの編集画面を開き、[Rule]セクションを探します。対象のDOMAIN-SUFFIXルールは、マッチ範囲が重なる広範囲のルールより前に置きます。一部だけを直接接続する例外が必要な場合は、より具体的なDOMAIN,DIRECTルールを前に置いてください。
-
末尾を確認する
最後のルールがFINAL,DIRECTになっていることを確認し、その前に全リクエストを対象とするルールや範囲が広すぎるPROXYルールが残っていないかチェックします。保存後、Configで作業用コピーを有効にしてください。
-
モードを選択する
Home → Global Routing → Configに戻り、選択中のサーバーが利用可能であることを確認してから接続を開始します。ルールの動作確認をProxyやDirectモードで行わないでください。
-
もう一度動作を確認する
開いているWebページの接続を閉じてからアクセスし直します。必要に応じてShadowrocketの接続も再確立してください。接続ログで対象ドメイン、マッチしたルール、最終的なポリシーを確認し、ルールに含めていないサイトもテストします。
5. 振り分けを確認する：ページの表示だけでなくリクエストを見る
1つのページから複数のドメインへリクエストが送られることがあります。ページ本体、画像、スクリプト、ログインAPI、メディアは、同じメインドメインを使うとは限りません。メインページがPROXYにマッチしても、関連するすべてのリクエストが同じルールにマッチするわけではありません。ページは開くのに画像が表示されない場合は、失敗したリソースの実際のドメインを確認してください。Global RoutingをProxyに切り替えて、そのまま使い続けるのは避けましょう。
この流れから分かることは2つあります。VPNの表示が出ているのは、システムのトンネルが動作していることを示すだけで、すべてのリクエストがプロキシサーバーを経由する証拠にはなりません。DIRECTのリクエストも、いったんトンネルに入り、Shadowrocketがルールに従って接続先へ直接接続することがあります。「接続スイッチがオン」を「すべてのサイトがプロキシ経由」の根拠にしないでください。
- 対象サイトのテスト：ルールに追加したドメインにアクセスし、該当するDOMAIN-SUFFIXにマッチしているか、最終ポリシーがPROXYかを確認します。
- 比較用サイトのテスト：他のルールにマッチしないドメインにアクセスし、FINALに到達して最終ポリシーがDIRECTになっているかを確認します。
- 関連リソースのテスト：ページの一部が表示されない場合は、失敗したリクエストのドメインを記録します。必要性を確認してから1つずつ追加し、範囲の広すぎるキーワードで一括指定しないでください。
- 接続の再利用を確認：ルールを変更しても古い接続が使われる場合があります。新しいルールの結果と誤認しないよう、ページやアプリの既存の接続を閉じてから再テストしてください。
ドメインルールの適用には、リクエストからドメイン情報を取得できることも必要です。アプリがIPアドレスに直接接続する場合、アドレスをキャッシュしている場合、特殊な名前解決を使う場合は、DOMAIN-SUFFIXに必ずマッチするとは限りません。IPアドレスで振り分ける場合は、IP-CIDRのネットワーク範囲とルールの順序を別途確認します。GEOIPはIPアドレスの地理的位置による判定で、サイト運営者の所在地を示すものではありません。
6. サイトが開かないとき：名前解決・接続・ルールの問題を切り分ける
以下はブラウザーに表示される可能性のあるネットワークエラーの例で、Shadowrocket固有のダイアログではありません。ブラウザーによって表示は異なります。まずどの段階で失敗したかを確認してから、ルールを変更してください。タイムアウトが必ずルールの誤りとは限らず、名前解決の失敗が必ずサーバーの利用不能を意味するわけでもありません。
ERR_NAME_NOT_RESOLVED
原因：ブラウザーが対象ドメインの名前解決を完了できませんでした。ドメインの入力ミスや現在のDNS経路が原因の可能性があります。
対処：まずドメイン名を確認し、Configの既存DNS設定と接続ログを調べてください。名前解決の問題を切り分ける代わりに、DOMAIN-SUFFIXを追加しないでください。
ERR_CONNECTION_TIMED_OUT
原因：待機時間内に接続が完了しませんでした。直接接続の経路、選択中のサーバー、接続先サイトなどが原因の可能性があります。
対処：まずリクエストに実際に適用されたポリシーを確認し、該当する接続経路をそれぞれ調べてください。すでにPROXYにマッチしている場合は、Homeで選択中のサーバーに接続できるかを優先して確認します。
すべてのサイトがPROXYになる場合は、まずGlobal RoutingがProxyになっていないか確認し、次に対象ルールより前に広範囲のマッチルールがないか調べてください。すべてのサイトが直接接続される場合は、現在のモードがConfigであること、作業用コピーが有効であることを確認します。また、ドメインをプロトコルやパス付きのURLで入力していないかもチェックしてください。
ルール名とポリシーの適用先をそれぞれ確認するPROXYはプロキシポリシーの選択を示すもので、プロトコル名ではありません。元の構成でカスタムポリシーグループを使っている場合は、ルール末尾で参照している名前が存在することと、グループ内で選択中の接続先を確認してください。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuardなどの接続プロトコルの設定は、DOMAIN-SUFFIXの行では変更されません。
7. 特定サイトの振り分けに関するよくある質問
サブドメイン1つだけをプロキシ経由にするには？
[Rule]にDOMAIN,api.example.com,PROXYを追加し、末尾のFINAL,DIRECTはそのまま残します。このドメインを対象にするDIRECTルールが前にある場合は、この具体的なルールをその前に移動してください。メインドメイン全体を対象にするDOMAIN-SUFFIXを追加する必要はありません。
サイト全体をプロキシ経由にして、特定のAPIだけ直接接続するには？
まずDOMAIN,api.example.com,DIRECTを記述し、その次の行にDOMAIN-SUFFIX,example.com,PROXYを記述します。より具体的な例外を先に置き、範囲の広いドメインルールを後に置きます。最後はFINAL,DIRECTにします。
サブスクリプションを更新した後、ルールも書き直す必要がありますか？
まず更新対象がHomeのサーバーサブスクリプションか、Configのリモート構成かを確認します。前者では通常サーバー一覧が更新され、後者では構成内容が変更される場合があります。リモート構成を更新する前にローカルコピーを保存し、更新後に[Rule]、有効なファイル、ポリシーグループ名を確認してください。手動での変更が必ず保持されるとは限りません。
FINAL,DIRECTで、それ以外のリクエストはすべて直接接続されますか？
FINAL,DIRECTが処理するのは、現在のルール処理に入り、それ以前のルールにマッチしなかったリクエストだけです。まずHome → Global RoutingでConfigを選択し、それより前にあるすべてのルールと参照先を確認してください。これはデバイス上のあらゆる通信を個別に保証するものではなく、DNSクエリの経路を指定するものでもありません。
各ルールの用途を説明できる構成を最終版として保存しましょう。対象ドメインの一覧を前に置き、必要な具体的例外はさらに前に、FINAL,DIRECTは末尾に置きます。ドメインを追加するたびに対象サイトと直接接続の比較用サイトをテストすると、グローバルモードを何度も切り替えるより、振り分けが実際に適用されたか確認しやすくなります。