Shadowrocketのルール構文入門：DOMAIN・DOMAIN-SUFFIX・GEOIP・FINALのマッチ範囲

この記事の要点

Shadowrocketのルールによる振り分けは、Global RoutingでConfigを選択していることが前提です。利用者自身が用意した接続情報を持ち、設定を編集する方向けに、ルールの項目、ドメインとIPのマッチ方法、順番に沿った判定の確認方法を解説します。例に使うドメインやアドレスは構文の説明用で、接続情報として利用できるものではありません。編集前に現在の設定を保存してください。

1. ルールの適用条件と判定順

まず結論として、ルールは設定内の上から順に確認され、該当したルールのポリシーが適用されます。後ろに「より具体的な」ルールがあっても、自動で選び直されることはありません。例外を先に、対象範囲の広いルールを後に置き、残りのリクエストはFINALで処理します。編集する前に、現在使用中の設定ファイルを確認してください。

Home → Global RoutingでConfigを選ぶと、現在の設定に基づいて振り分けられます。ProxyとDirectは全体に適用するルーティングモードのため、この記事のルール順を検証する用途には使えません。Sceneはシーンごとの設定に従うため、確認時にはシーンに対応するルーティングもチェックしてください。ルールファイル単体をテストするときはConfigを選び、ルーティングモードによる結果を構文の問題と取り違えないようにします。

リクエストを送信対象を特定順番に照合ポリシーを選択接続を確立

このフローはルール判定の仕組みを示したもので、すべてのリクエストで必ず最初にDNS問い合わせが行われるという意味ではありません。ドメインルールは判明している対象ドメインを、IPルールは対象アドレスを使います。ドメインを取得できるか、名前解決が必要か、設定のDNS項目がどうなっているかによって、照合に使える情報は変わります。PROXYにマッチしても、プロキシポリシーが選ばれたことを示すだけで、その後の接続成功を保証するものではありません。

2. ルール行の書式：キーワード・条件・ポリシー

一般的なルール行では、各項目を半角カンマで区切ります。DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORD、GEOIP、IP-CIDRにはマッチ条件とポリシーが必要です。FINALにはマッチ条件を付けず、ポリシーだけを指定します。ルールは設定の[Rule]セクションに記述し、[General]や[Host]には書かないでください。

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

上記の設定では、login.example.comを先行する例外とし、それ以外のexample.comの範囲にPROXYを適用しています。キーワードルールはより広い範囲を対象にする書式例です。実際の設定ですべての種類を同時に記述する必要はありません。PROXYとDIRECTはポリシーであり、プロトコル名ではありません。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuardなどのプロトコル接続情報は、既存の接続設定で確認し、ルール行のポリシー欄には入力しないでください。

DIRECT：対象のリクエストを直接接続するポリシーで処理します。実際の接続は、現在のネットワーク、接続先サービス、DNSの状態にも左右されます。
PROXY：リクエストをプロキシポリシーで処理します。テスト時には、そのポリシーに対応する既存の接続が利用可能か確認してください。
REJECT：マッチしたリクエストを拒否します。このルールが設定にある場合は、適用順の確認対象に含めてください。
カスタムポリシー：ポリシーグループ名を指定する場合は、設定内で実際に定義されている名前と一致させます。説明用の文字列を、存在するポリシー名として扱うことはできません。

条件にはルールに必要な情報だけを記述します。ドメインルールにはドメインを指定し、https://、パス、クエリパラメータ、:443は付けません。たとえばhttps://example.com/accountのドメイン条件はexample.comです。この6種類のルールでは、URLのパスを使って同じWebサイト内のページを区別できません。

3. DOMAIN・DOMAIN-SUFFIX・DOMAIN-KEYWORD

DOMAINは完全一致する1つのドメイン、DOMAIN-SUFFIXは指定したドメインとそのサブドメイン、DOMAIN-KEYWORDはドメインに指定文字列が含まれるかどうかを判定します。マッチ範囲はそれぞれ異なり、「exampleを含む」と一括りにはできません。特にDOMAIN-SUFFIXはドメインの境界を考慮しますが、DOMAIN-KEYWORDはサフィックス境界を判定しません。

ルール条件	マッチする例	マッチしない例
`DOMAIN,example.com`	`example.com`	`www.example.com`
`DOMAIN-SUFFIX,example.com`	`example.com`、`api.example.com`	`notexample.com`、`example.com.other.test`
`DOMAIN-KEYWORD,example`	`example.com`、`myexample.test`	`sample.test`

特定のホスト名だけを指定する場合はDOMAIN、親ドメインと複数階層のサブドメインを対象にする場合はDOMAIN-SUFFIXを使います。DOMAIN-KEYWORDは文字列による広いマッチが必要な場合に適していますが、関係のないドメインまで含むことがあるため、行数を減らす目的だけでサフィックスルールの代わりに使うのは避けましょう。DOMAIN-SUFFIXの条件に*.example.comと書く必要はなく、example.comと記述します。

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

この例では、api.example.comは先にDOMAINにマッチするためDIRECT、www.example.comは2行目にマッチするためPROXYになります。最初の2行を入れ替えると、先にサフィックスルールがapi.example.comを処理するため、完全一致ルールを例外として適用できません。Webページでは画像、ログイン、APIなど別のドメインへのリクエストが発生することもあります。アドレスバーのドメインだけでページ全体の通信を判断せず、それぞれのリクエストを確認してください。

4. GEOIPとIP-CIDR：宛先IPによるマッチ

GEOIPは、アプリが使用する地理情報データベース上での宛先IPの地域判定に基づいてマッチします。例：GEOIP,CN,DIRECT。ここでのCNは国コードであり、ドメイン末尾やコンテンツの対象地域を表すものではありません。データベースによる判定は物理的な位置をリアルタイムに証明するものでもないため、ページが日本語で表示されることだけを理由にCNへマッチすると考えないでください。

IP-CIDRは、宛先のIPv4アドレスが指定したネットワーク範囲に含まれるかを判定します。192.168.0.0/16は192.168.0.0から192.168.255.255までの範囲を表し、/32は単一のIPv4アドレスを表します。以下のアドレスは構文の説明用であり、サーバーアドレスとして推奨するものではありません。

IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR,203.0.113.7/32,PROXY,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

IPアドレスが判明している場合：リクエストの宛先がすでにIPアドレスなら、ドメインルールとしてではなく、ネットワーク範囲やデータベース上の地域を直接判定できます。
ドメイン宛ての場合：IPルールの判定には名前解決が必要な場合があり、DNSの結果がマッチに影響します。ドメインが先行するドメインルールにマッチした場合、後続のIPルールで結果が変わることはありません。
no-resolve：このIPルールのためにドメインを積極的に名前解決しない指定です。すべてのDNSを無効にするものでも、すでに利用可能な宛先IPを無視するものでもありません。
アドレスファミリー：IP-CIDRはIPv4用です。IPv6のネットワーク範囲にはIP-CIDR6を使います。IPv4の範囲だけを書いても、宛先のIPv6アドレスは対象になりません。

例の最終行はFINAL,PROXYで、FINAL,DIRECTとは目的が異なります。マッチしなかったリクエストをプロキシ経由にする設定です。どちらのフォールバックを使うかは、実現したい振り分け方に応じて選びます。実際に検証する際は、リクエストのドメイン、宛先アドレス、最終ポリシーを記録し、DNSが別のアドレスを返した現象をCIDRの記述ミスと混同しないようにしてください。

5. FINALによるフォールバックと設定の確認手順

FINALは、それまでのルールにマッチしなかったリクエストを処理するため、ルール末尾に置きます。「優先度が最も低いデフォルトルール」として自動適用される設定ではなく、順番に並ぶルールの1つです。前方に置くと、後続ルールがリクエストを処理する機会はありません。指定したドメインだけをプロキシ経由にする場合はドメインルールとFINAL,DIRECTを、その他のリクエストもプロキシ経由にする場合はFINAL,PROXYを使えます。

元の設定を保存

Configを開き、現在有効なファイルを確認してから、変更前のコピーを保存します。既存の例外ルールをテスト用ルールだけで置き換えて失わないよう、元の[Rule]の順番を記録してください。
テスト用ルールを記述

この設定の編集画面を開き、[Rule]に必要なルールを追加します。DOMAINの例外をDOMAIN-SUFFIXより前に置き、最後に目的に合ったFINALを記述して保存します。
ルーティングを確認

Home → Global Routing → Configに戻り、Configで選択中のファイルを確認します。Homeでは、プロキシポリシーに自分が用意した接続可能なサーバーが設定されていることを確認してください。
新しいリクエストを送信

接続を再確立してからテスト対象にアクセスし、変更前に確立した長時間接続を使い続けないようにします。アプリのリクエスト記録で対象と実際のポリシーを確認してください。キャッシュ済みのWebページでは、新ルールの適用を確認できません。
フォールバックを確認

ドメインリストにない対象にもアクセスし、FINALで指定したポリシーが適用されるか確認します。結果が異なる場合は、先行ルール、対象IP、現在の設定の順に確認し、すぐに対象範囲の広いキーワードルールを追加しないでください。

第3節の3行の例では、api.example.comにDIRECT、www.example.comにPROXY、その他の未マッチ対象にDIRECTが適用される想定です。これはルールから導かれる結果であり、例示したドメインへの実通信テストの報告ではありません。自分の設定に使う実際のドメインに置き換えたうえで、リクエスト記録から確認してください。単独のレイテンシテストで確認できるのは接続性であり、特定のWebページがどのルールにマッチしたかは分かりません。

6. ルール未適用と接続エラーを切り分ける

まず問題を2種類に分けます。リクエストに誤ったポリシーが適用された場合は、ルーティングモード、設定の選択、ルール条件や順番を確認します。想定どおりのポリシーが適用されているのに接続できない場合は、接続先サービスと既存サーバーの接続情報を確認します。ルールが決めるのはリクエストの処理方法であり、サーバーのポート誤りや到達不能を解消するものではありません。

エラー：Connection refused

原因と対処：接続先で拒否されたときに返されることがあるエラーで、通常は対象ポートで待ち受けていないか、明示的に接続を拒否しています。まずリクエストに実際に適用されたポリシーを確認してください。PROXYの場合は、利用中のサービス情報でサーバーアドレスとPortを確認します。情報に443と明記されている場合は、一般的なポート番号を推測して入力せず、443を設定してください。

エラー：Operation timed out

原因と対処：処理が待機時間内に完了しなかった場合に返されることがあるエラーで、ルール構文の誤りとは限りません。まずHomeで既存の接続をテストし、次にリクエストの対象とポリシーを確認します。現在のネットワーク、接続先への到達性、サーバーの稼働状況をそれぞれ確認してください。アプリの記録に表示される詳細な文言は、エラーの発生元によって異なる場合があります。

DOMAIN-SUFFIXを書いたのに、なぜDIRECTになる？

まずHome → Global RoutingでConfigを選び、Configで有効になっているのが保存したばかりのファイルか確認します。次に[Rule]の先頭から、先にマッチするDIRECTやFINALがないかを確認してください。条件にはドメインだけを記述し、プロトコル、パス、ポートは含めません。

特定のサブドメインだけをDIRECTにして、ほかに影響させない方法は？

DOMAIN,api.example.com,DIRECTをDOMAIN-SUFFIX,example.com,PROXYより前に記述します。保存後に新しいリクエストを送り、api.example.comと別のサブドメインそれぞれのポリシーを確認してください。片方だけのテストでは不十分です。

Webページは開くのに、一部の画像が読み込まれないのはなぜ？

ページのアドレスだけでなく、失敗したリクエストの実際のドメインを確認します。画像が別のドメインから配信されている場合もあれば、PROXYにマッチした後の接続に失敗している場合もあります。リクエスト記録を確認してからDOMAINやDOMAIN-SUFFIXを追加するか判断し、関係のない対象まで含みやすいDOMAIN-KEYWORDでまとめて指定するのは避けてください。

サブスクリプションを更新すると、自分で書いたルールも変わる？

まずHomeの接続情報のサブスクリプションと、Configのルールファイル更新を区別します。既存の接続サブスクリプションを更新しても、現在の[Rule]が編集されるとは限りません。現在の設定ファイル自体がリモート更新される場合は、更新後にファイルの内容を再確認し、カスタマイズした内容は管理できるコピーに保存してください。

トラブルシューティングでは、一度に変更する条件を1つに絞り、変更前後のルール行とリクエスト結果を記録してください。「現在の設定、Global Routing、マッチ順、ドメインまたはIP、接続情報」の順に確認すると、振り分けの判定とネットワーク接続の問題を切り分けられます。設定画面の詳しい手順は、サイト内の使い方ガイドをご覧ください。プロトコル情報の確認場所については、プロトコルリファレンスをご覧ください。