2026-06-28 · ルールと振り分け · 約9分

Shadowrocket のルールの書き方:DOMAIN・GEOIP・IP-CIDR・FINAL は何にマッチするか

Shadowrocket のルールリストは、1 行につき 1 件を「タイプ,値,ポリシー」の 3 要素で書くプレーンテキストです。照合は上から順に行われ、最初にマッチした行で確定します。本記事では DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORD、GEOIP、IP-CIDR、FINAL がそれぞれ何にマッチするのかを 1 つずつ分解し、そのまま使える記述例と切り分けの順序を示します。

この記事の要点

ルールリストはプレーンテキストで、1 行につき 1 件、「タイプ,値,ポリシー」の書式で書きます。本記事ではドメイン系(DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORD)、IP 系(GEOIP、IP-CIDR)、フォールバック(FINAL)について、マッチ対象と判定順を 1 つずつ整理し、Config → Rules にそのまま使える例を挙げます。すでにサブスクリプションを読み込み済みで、通信を自分の意図どおりに振り分けたいユーザー向けの内容です。読み終えるころには、互いに衝突しないルールリストを自分で書けるようになります。

1 つのルールを成す 3 つの要素

Shadowrocket のルールリストは設定ファイルに保存されるプレーンテキストで、1 行につき 1 件です。各行は半角カンマで 3 つに区切られます。タイプ(TYPE)、値(VALUE)、ポリシー(POLICY)です。タイプは「何と比べるか」、値は「何を比べるか」、ポリシーは「マッチした後どうするか」を決めます。

ポリシーは 3 種類だけです。PROXY は現在選択中のサーバー経由、DIRECT は直接接続、REJECT はその接続の破棄を意味します。# で始まる行はコメントとして扱われ、解析時にはスキップされます。空行も同様に無視されます。ルールを書くときのカンマは必ず半角で入力してください。全角カンマが混ざるとその行全体が無効になります。

# 各行の書式:タイプ / 値 / ポリシー
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,analytics,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
FINAL,DIRECT

3 つのうち最も間違えやすいのが値です。ドメイン系ルールの値はホスト名、IP 系ルールの値は CIDR 表記のネットワークか 2 文字の国・地域コード、ポート系ルールの値は数字です。書式が正しくない行はエラーを出さず、黙ってスキップされます。「ルールを書いたのに反応しない」ときは、まずその行のカンマと値の書式に戻って確認し、それから他の要因を疑ってください。

ドメイン系:DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORD

ドメイン系ルールが照合するのはリクエストのホスト名です。HTTPS のホスト名は通常 TLS ハンドシェイクの SNI から、HTTP の場合は Host ヘッダーから取れます。どちらも接続が確立した時点で揃っている情報なので、DNS 解決の完了を待たずに判定でき、ドメインルールは最も速く、解決結果の変動にも影響されにくくなります。よく使う 3 つの書式は、次の順に粒度が広がります。

タイプマッチ対象記述例マッチ範囲
DOMAIN完全一致するホスト名。1 文字でも違えばマッチしないDOMAIN,api.example.com,PROXYapi.example.com のみマッチ。www.api.example.com はマッチしない
DOMAIN-SUFFIXドメインの末尾。自身とすべてのサブドメインを含むDOMAIN-SUFFIX,example.com,PROXYexample.com、a.example.com、a.b.example.com のいずれもマッチ
DOMAIN-KEYWORDホスト名の任意の位置に現れるキーワードDOMAIN-KEYWORD,analytics,DIRECTanalytics.example.com、cdn-analytics.example.net のいずれもマッチ
DOMAIN-SET外部のドメインリストファイル。1 行につき 1 ドメインDOMAIN-SET,example-domains.txt,DIRECTリストに書かれたドメインはその行のポリシーで処理される

粒度が広いほど誤爆の可能性も上がります。DOMAIN-KEYWORD,analytics,DIRECT はホスト名のどこかに analytics を含むリクエストすべてにマッチし、直結したくないサイトまで巻き込みます。DOMAIN-SUFFIX,example.com,PROXY の場合も mail.example.com や static.example.com が一緒にプロキシへ送られます。広いルールを書く前に、その末尾配下に個別扱いすべきサブドメインが本当にないか確認してください。

書式を選ぶときは、次の順で判断します。

DOMAIN,www.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,adservice,REJECT
DOMAIN-SET,example-domains.txt,DIRECT

IP 系:GEOIP と IP-CIDR は解決後のアドレスを比較する

IP 系ルールはドメインを見ず、接続先の IP アドレスだけを比較します。IP を得るにはシステムがまず DNS 解決を行う必要があるため、IP ルールはドメインルールより一歩遅れて効きます。しかも「ドメイン」という軸が失われるので、同じドメインでも解決先のアドレスが変わればマッチ結果も変わることがあります。

GEOIP は 2 文字の国・地域コードでアドレスの帰属をまとめて判定します。GEOIP,CN,DIRECT の意味は「接続先が中国の IP なら直結」です。IP-CIDR は具体的なネットワークを指定するもので、LAN を直結させる定番の書き方は IP-CIDR,192.168.0.0/16,DIRECT と IP-CIDR,10.0.0.0/8,DIRECT です。IPv6 の接続先には IP-CIDR6 を使います。ポートによる判定は DST-PORT と SRC-PORT が担い、たとえば DST-PORT,443,PROXY は宛先ポートが 443 の接続をプロキシ経由にします。

GEOIP,CN,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
IP-CIDR6,fc00::/7,DIRECT,no-resolve
DST-PORT,443,PROXY

LAN のネットワークに対するルールには、通常 no-resolve を付けておきます。これはこのルールの照合時に、IP を得るための DNS 解決を起こさないようにする指定です。これがないと、本来そのままマッチできるはずのリクエストがまず 1 回解決を強いられ、判定が遅くなるだけでなく、解決に失敗するとマッチし損ねることがあります。

結論:ドメインルールは IP ルールより前に書く

GEOIP と IP-CIDR は接続先 IP を先に取得する必要があります。これらがドメインルールより前に並んでいると、DOMAIN-SUFFIX で正確にマッチできるはずのリクエストがまず解決を強いられ、そのときどのアドレスに解決されたかで結果が変わります。ドメイン系を前、IP 系を後に置いて初めて順序が安定します。

判定順:上から下へ、最初にマッチした行で確定

Shadowrocket はルールリストの 1 行目から順に照合し、どこかの行がマッチするとその行のポリシーを直ちに実行し、以降のルールは判定に使われません。この仕組みが並べ方の原則を決めます。具体的で優先したいルールほど上に、広いルールほど下に書きます。

FINAL はポリシーだけを書き、マッチさせる値を持たないフォールバック用のルールで、ここまででマッチしなかったすべてのリクエストを受け止めます。FINAL,DIRECT なら未マッチの通信を直結、FINAL,PROXY なら未マッチの通信をプロキシ経由にします。必ずリストの最終行に置いてください。FINAL より後ろに書いたルールは実行されません。

# 1. LAN と予約アドレスは先に直結
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
# 2. 明確にブロックしたいドメイン
DOMAIN-SUFFIX,ads.example.com,REJECT
# 3. 明確にプロキシ経由にしたいドメイン
DOMAIN-SUFFIX,example.com,PROXY
# 4. 中国本土のアドレスは直結
GEOIP,CN,DIRECT
# 5. フォールバック
FINAL,PROXY

並べ替えるときは、次の 5 層を上から下へ配置します。

ルールを効かせる:Global Routing と設定ファイル

ルールリストが判定に使われるのは、Global Routing が Config のときだけです。切り替えは Settings → Global Routing で行います。よく使う 3 つの選択肢の違いは次のとおりです。

Config(設定)

おすすめ

設定ファイル内のルールリストを 1 行ずつ照合し、PROXY にマッチすればプロキシ経由、DIRECT なら直結、REJECT なら破棄します。

向いている用途:日常のメイン設定。ルールを実際に効かせたいとき

Proxy(プロキシ)

ルールリストを無視し、すべての接続を現在選択中のサーバー経由にします。

向いている用途:一時的な全量プロキシ、ルールの切り分け

Direct(直結)

ルールリストもサーバーも無視し、すべての接続をそのまま送信します。

向いている用途:ある現象がプロキシ由来かどうかを確かめたいとき

もう 1 つの前提は「正しいファイルを編集しているか」です。Config タブには複数の設定が並ぶことがあり、実際に使われるのは現在選択中(チェック付き)の 1 つだけです。編集の入口は Config → 使用中の設定ファイルを選択 → Rules です。リストは行単位で表示され、右上の「+」で行を追加でき、任意の行をタップするとタイプ・値・ポリシーを変更できます。全体の流れは次のとおりです。

  1. モードを確認

    Settings → Global Routing で Config を選択。そうしないとルールリストは判定に使われません。

  2. Config を開く

    下部タブで Config に切り替え、チェックが付いているのが使用中の設定ファイルであることを確認します。

  3. Rules を開く

    設定ファイルを開き、Rules の行を探します。そこにルールリストの全体が入っています。

  4. 行を追加

    右上の「+」でルールを追加し、「タイプ,値,ポリシー」の 3 要素で入力します。カンマは半角で。

  5. 順序を調整

    具体的なルールを広いルールより前へ移し、FINAL は最終行に保ちます。

  6. 保存して再接続

    保存したら Home に戻り、一度切断してから再接続し、新しいルールリストを反映させます。

結論:まずモード、次にルール

ルールが効かないときは、まず Global Routing が Config のままかどうか、選択中なのが自分が編集した設定ファイルかどうかを確認し、そのうえでルールの順序と書式を点検します。順番を逆にして調べると、書式の見直しで無駄に時間を溶かすことになります。

よくある 4 つの疑問

以下はルール関連のフィードバックで最も多い 4 つの場面です。切り分けは「モード → 設定ファイル → ルールの順序 → ルールの書式」の順に 1 層ずつ下ろしていきます。

DOMAIN-SUFFIX,example.com,PROXY を追加したのに、このドメインが直結のまま

まず、リスト内により前のルールが先にマッチしていないか確認します。たとえばドメインルールより上にある GEOIP,CN,DIRECT や、広い DOMAIN-KEYWORD です。次に Global Routing が Config のままで、選択中なのが編集した設定ファイルであることを確認し、最後に一度切断して再接続します。

GEOIP,CN,DIRECT を書いても中国本土のサイトが直結されない

GEOIP がマッチするのは解決後の IP で、ドメインではありません。ドメインルールより前に書かれている場合や、接続先が解決したアドレスが CN の範囲に入っていない場合はマッチしません。ドメインルールの後、FINAL の前へ移して、もう一度再接続して観察してください。

IP-CIDR ルールが書いたドメインにマッチしない

IP-CIDR は IP アドレスだけを比較し、ドメインは認識しません。ドメインで振り分けたいなら DOMAIN-SUFFIX を使い、ネットワーク単位で振り分けたいなら、接続先が解決したアドレスが指定した CIDR に本当に入っているかを確認します。LAN のネットワークを書くときは no-resolve を忘れずに。

REJECT を書いたのに一部のリクエストが送信されてしまう

ルールは上から下へ照合され、最初にマッチした行で確定します。REJECT より上に、同じ接続先へマッチする PROXY や DIRECT があると、リクエストはこの行まで到達しません。REJECT を該当するドメインルールより前へ移して試してください。

App Store 正規版の確認