この記事の概要

利用可能なサーバーをすでにお持ちで、指定したサイトだけをPROXY経由にしたい方向けです。まずGlobal RoutingをConfigに設定し、現在有効な設定ファイルの[Rule]にドメインルールを追加します。最後にFINAL,DIRECTでその他のリクエストを処理します。以下では、マッチ結果やルールの順序、確認手順を説明します。例示するドメインは構文の説明用であり、サービスを推奨するものではありません。

1. まずGlobal RoutingをConfigに設定する

ShadowrocketはApp Storeで入手するAppleプラットフォーム向けの有料クライアントです。主にiPhoneとiPadで利用でき、開発元はShadow Launch Technology Limitedです。システム要件はApp Storeの掲載内容をご確認ください。この記事は、ご自身で利用中のサービスと接続情報をお持ちであることを前提とし、サービスの選び方は扱いません。クライアントの購入と接続サービスは別のものです。

ルールが正しくても、ルーティングの設定が意図と異なれば「指定したサイトはPROXY、その他はDIRECT」になりません。Home → Global Routingを開き、Configが選択されていることを確認してください。ここでのConfigは、設定ファイルのルールに従ってリクエストを処理するモードです。画面下部にあるファイル管理用のConfigページとは異なります。

Config

推奨

現在有効な設定ファイルのルールに従ってポリシーを選択します。この記事のドメインルールとFINAL,DIRECTは、このモードで機能します。

用途：指定したサイトだけをPROXY経由にし、その他のリクエストはDIRECTにする。

Proxy

対象の通信をすべてプロキシで処理し、この記事のような個別のルール分岐は行いません。一時的な切り替えで、問題がルール判定に起因するかを確認できますが、ルール分岐の検証にはなりません。

用途：選択中のサーバーから対象にアクセスできるか、短時間で確認する。

Direct

対象の通信をすべてDIRECTで接続します。設定にPROXYと記述されていても、プロキシ経由にはなりません。

用途：現在のネットワークでの直接接続と比較する。

Global RoutingのSceneは、シーンに応じて切り替える機能で、この記事で固定して使うConfigとは異なります。初回の確認ではモードを固定し、Sceneの切り替えによってルーティング結果が変わらないようにしてください。Settings → On Demandでは、条件に応じた接続の開始・切断を管理します。特定のドメインをPROXYに振り分ける機能ではありません。

2. 最小限のルール例：ドメインルールを先に、FINALを最後に

以下はルール部分のみで、設定全体を含む完全なファイルではありません。既存設定の[Rule]に追加してください。すでにこのセクションがある場合は、見出しを重複して追加しないでください。変更前に設定のコピーを保存し、特に既存のDNSやその他の設定をまとめて上書きしないようにしましょう。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-SUFFIX,example.net,PROXY
FINAL,DIRECT

1行目のドメインルールは、example.comとそのサブドメイン（www.example.com、static.example.comなど）にマッチします。2行目は別のドメイン群を処理します。どちらの条件にも一致しないリクエストは、FINAL,DIRECTに振り分けられます。実際に使う際は、例示のドメインを対象のドメインに置き換え、英語のカンマとポリシーキーワードはそのまま使用してください。

2件
2つのドメイン群を対象とするDOMAIN-SUFFIXルールの例。
1件
FINAL,DIRECTはルールの末尾に置き、一致しなかったリクエストを処理します。
3項目
ドメインルールは、ルールタイプ、マッチ対象、適用するポリシーの順に記述します。

3. DOMAIN-SUFFIXとDOMAIN-KEYWORDの使い分け

サイト単位で振り分ける場合は、マッチ範囲が明確なDOMAIN-SUFFIXを優先してください。ホスト名を完全一致で指定する場合はDOMAINを使えます。文字列を含むかどうかで判定したい場合に限り、DOMAIN-KEYWORDを使用します。キーワードはサイトの所属先を判定するものではなく、名前が似た無関係なドメインにもマッチすることがあります。

ドメインの範囲でマッチ

DOMAIN
www.example.com,PROXY
DOMAIN-SUFFIX
example.com,PROXY
FINAL
DIRECT

DOMAINは指定したホスト名だけにマッチし、DOMAIN-SUFFIXはルートドメインとそのサブドメインにマッチします。

文字列を含むかでマッチ

DOMAIN-KEYWORD
example,PROXY
マッチする
myexample.org
FINAL
DIRECT

キーワードの対象範囲は広くなります。上の例ではmyexample.orgにもexampleが含まれますが、example.comとは無関係です。

ルールのマッチ対象にはドメインまたはキーワードだけを記述し、完全なURLは入力しません。たとえばexample.comはドメインですが、example.com/accountにはパスが含まれるため、DOMAIN-SUFFIXには指定できません。また、ドメインルールでは「同じサイトのログインページだけPROXYにし、その他のページはDIRECTにする」といった指定もできません。

4. 上から順に判定：例外ルールは広いルールより前に

ルールは「具体的なものほど自動的に優先される」わけではありません。同じリクエストに対して先にマッチしたルールがポリシーを決め、後続ルールで上書きされることはありません。example.comへの大半のリクエストをPROXY経由にしつつ、status.example.comはDIRECTにしたい場合は、このホスト名の例外を先に記述します。

[Rule]
DOMAIN,status.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,example,PROXY
FINAL,DIRECT
判定対象のドメイン最初にマッチしたルール結果
status.example.comDOMAINによる完全一致の例外DIRECT
www.example.comDOMAIN-SUFFIXPROXY
myexample.orgDOMAIN-KEYWORDPROXY
example.orgDOMAIN-KEYWORDPROXY
example.netFINALDIRECT

この表は上記のルールから導かれる想定結果であり、通信速度の測定記録ではありません。また、キーワードのマッチ範囲が想定より広くなりやすいことも示しています。example.orgにもexampleが含まれるためです。example.comのドメイン群だけが対象なら、DOMAIN-KEYWORDを削除してください。ルールタイプを見せるためだけに残す必要はありません。

5. Configで保存・有効化して動作を確認する

ファイルを編集しただけでは、現在の接続にそのファイルが適用されたとは限りません。以下の手順で、一度に変更するルールは1組にし、まず単純なドメインルールを確認してから例外やキーワードを追加してください。サブスクリプションを更新しても、ローカルのConfigルールが保存・有効化されるわけではありません。サーバー一覧と設定ファイルは、それぞれ確認が必要です。

  1. 元のファイルをバックアップ

    Configを開いて現在使用中の設定を探し、先にコピーを保存します。以降の編集対象がローカルで管理できるファイルであることを確認し、リモート設定の更新で変更が上書きされないようにしてください。

  2. ルール部分を編集

    Configで対象ファイルの編集画面を開き、[Rule]を探します。ドメインルールを追加し、例外を先に置いて、FINAL,DIRECTを末尾に残してから保存します。

  3. 対象の設定を有効化

    Configのファイル一覧に戻り、保存したファイルが現在選択されていることを確認します。Home → Global Routingに戻り、ProxyやDirectではなくConfigを選択してください。

  4. サーバーを確認

    Homeで現在選択中のサーバーを確認し、接続します。以前から接続が続いている場合は、古い接続の影響を避けるため、接続を確立し直してからテストしてください。

  5. 新しいリクエストを確認

    マッチするドメインとマッチしないドメインにそれぞれアクセスします。リクエストログで対象ホスト、マッチしたルール、接続ポリシーを確認してください。想定される結果は、それぞれPROXYとDIRECTです。

確認時に「Webページが表示されるか」だけを見ないでください。同じページはDIRECTでもPROXYでも正常に表示される場合があり、サーバーの遅延値からページがどのルールで処理されたかは判断できません。新しいリクエストのマッチ情報を確認しましょう。リクエストが既存の接続を再利用している場合は、該当ページを閉じて再アクセスしてください。必要に応じてアプリの接続を確立し直してから確認します。

6. GEOIP、IP-CIDR、DNS：確認が必要なケース

「指定したサイトだけをPROXYにする」最小構成では、通常GEOIPを追加する必要はありません。GEOIP,CN,DIRECTは接続先IPの地域情報で判定するルールであり、「中国語のサイトはDIRECT」という意味ではありません。また、特定のドメインが提供するすべてのサービスが同じ地域にあることを示すものでもありません。広範囲なIPルールをドメインルールより前に置くと、先にリクエストのポリシーが決まることがあります。

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

この追加例では、接続先が192.168.0.0/16のリクエストをDIRECTにします。no-resolveは、このIPルールにマッチさせるためにドメインを積極的に名前解決しないという意味で、DNSを全体的に無効にするものではありません。この例にはすでにFINAL,DIRECTがあるため、IP-CIDRは最終的なポリシーに対して通常は冗長です。ここではIPルールの構文と適用範囲を示すために記載しています。

7. よくある設定ミスと元に戻す方法

「有効化されているか → マッチしているか → ポリシーが利用可能か」の順に確認します。DNS、サーバー、ルール、On Demandを同時に変更すると比較の条件が崩れます。まず原因を追いやすい最小の3行ルールに戻し、条件を一つずつ追加するほうが、ルールを重ね続けるより問題を特定しやすくなります。

症状まず確認する項目対処方法
新しいリクエストがすべてPROXYになるGlobal RoutingがProxyになっていないか、前方に広範囲なプロキシルールがないかConfigに切り替え、[Rule]全体の先行ルールと末尾のFINALを確認します。
対象ドメインがDIRECTのまま現在の設定、ルールの位置、実際のリクエストドメイン有効なファイルを確認し、先にマッチする可能性のあるルールより前に対象ルールを置きます。
保存後にルールを正常に読み込めないカンマ、項目数、セクション見出し英語のカンマを使います。ドメインルールは3項目、FINALは2項目です。
PROXYにマッチするが接続できない選択中のサーバーと接続情報まずプロキシ接続が利用可能か確認します。ルールにマッチしても、接続先への接続成功を意味するわけではありません。
後から変更が消えていることに気づくリモート更新で上書きされる設定を編集していなかったかローカルのバックアップから復元し、独立したローカル設定でカスタムルールを管理します。
FINAL,DIRECTを設定するとプロキシ接続が切れますか？

いいえ。マッチしなかったリクエストをDIRECTにする設定であり、アプリの接続を切断するものではありません。接続を確立するかどうかと、リクエストをどう振り分けるかは別の仕組みです。前者の条件に応じた処理はOn Demand、後者のポリシー選択はルールが担います。

ShadowsocksとVLESSでドメインルールを別々に書く必要がありますか？

必要ありません。ドメインルールはマッチ条件と適用するポリシーを記述するもので、サーバーのプロトコルごとに同じルールを重複して書く必要はありません。実際に使う接続プロトコルは、選択したサーバーの設定で決まります。サーバーを切り替えた後も接続できることを確認し、同じルールの結果を検証してください。

今回のルール変更を取り消すには？

Configで変更前に保存した設定のコピーを選び直し、Home → Global Routingが意図したモードのままであることを確認してから接続し直します。FINALだけを削除しないでください。明示的なフォールバックがなくなると、その後の結果を確認しにくくなります。