Shadowrocketのルール構文入門：DOMAIN-SUFFIX・GEOIP・IP-CIDR・FINALのマッチ方法

この記事の概要

この記事は、Shadowrocketに自分で用意した設定を読み込み、ルールによる振り分けを調整する方を対象としています。まずGlobal RoutingがConfigになっていることを確認し、ドメイン条件とIP条件を区別します。そのうえで「個別の例外を先に、広い範囲の条件を後に、最後にFINAL」の順にルールを並べます。以下の例は構文の説明用で、接続に使える情報は含みません。テスト時は、自分がアクセスする権限のある宛先に置き換えてください。

ルールが適用される条件を確認する

ルールは接続に適用するポリシーを決めるもので、サーバーを作成したり、サーバー自体の利用可否を決めたりするものではありません。Homeではサーバーの選択と接続管理、Configでは設定ファイルの管理、Settingsではアプリの設定を行います。ファイルを編集した後は、それが現在選択されている設定かどうかも確認してください。有効化されていないファイルを保存しても、使用中のルールは変わりません。

Home → Global RoutingでConfigを選ぶと、現在の設定に基づいてこの記事で扱う振り分けが行われます。Proxyはすべての接続にプロキシを使う設定、Directはすべて直接接続する設定です。Sceneは設定済みのシーン条件とあわせて確認してください。メニューにSceneが表示されているだけでは、特定のルールが適用されているとは限りません。切り分けの際は、まずConfigに固定してシーン切り替えによる変動を減らします。

6種類

この記事で扱うルール：DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORD、GEOIP、IP-CIDR、FINAL

3項目

通常の条件ルールは、タイプ・マッチ値・ポリシーで構成されます

1行

最小構成の例では、前のルールに一致しなかった接続を1行のFINALで処理します

要点：最初に有効な設定を固定する

テスト前に、現在の設定名とGlobal Routingの選択内容を記録してください。この2点が不明なままルールを追加すると、変化がファイルの切り替えによるものか、マッチ条件によるものか判断できません。

ルールの書式とポリシー名

設定テキストの[Rule]セクションでは、通常の条件ルールは3項目を半角カンマで区切って記述します。項目はルールタイプ、マッチ値、ポリシーです。ウェブページのURL全体をドメイン欄に入力しないでください。ドメイン条件にはhttps://、パス、クエリパラメーター、ポートは含めません。以下の2行は、それぞれ「指定したドメインに直接接続」「それ以外の接続にはプロキシを使用」を表します。

[Rule]
DOMAIN,example.com,DIRECT
FINAL,PROXY

項目またはポリシー	意味	確認ポイント
`DOMAIN`	完全なドメイン名でマッチするルールタイプです。	プロトコルの種類でもサーバー名でもありません。
`example.com`	そのルールで照合する値です。	パスを含むURL形式では記述できません。
`DIRECT`	宛先に直接接続します。	接続の可否は、現在のネットワーク、DNS、宛先への到達性にも左右されます。
`PROXY`	プロキシを使用するポリシーです。	Homeで現在選択されているデフォルトサーバーを確認してください。
`REJECT`	一致した接続を拒否します。	ルールに一致した後のアクセス失敗は、想定どおりの結果である場合があります。

既存の設定でカスタムポリシーグループ名を使っている場合、ルールの末尾には設定内に実在する名前を指定してください。初めて試すときはDIRECTとPROXYを使い、ポリシーグループの追加、DNSの変更、ルールの並べ替えを同時に行わないでください。この記事の例は一部分です。既存の設定に[Rule]がある場合は、同じセクションを何度も追加せず、元のセクションを編集してください。

3種類のドメイン条件の違い

DOMAINは単一ホストの例外、DOMAIN-SUFFIXはドメインとそのサブドメイン、DOMAIN-KEYWORDはドメインに指定した文字列が含まれるかどうかの判定に使います。いずれも照合するのはドメイン情報です。ページタイトルやページ内容、URLのパスは対象になりません。

ルールの例	一致するもの	一致しないもの
`DOMAIN,example.com,DIRECT`	`example.com`	`api.example.com`
`DOMAIN-SUFFIX,example.com,DIRECT`	`example.com`、`api.example.com`	`notexample.com`、`example.com.test`
`DOMAIN-KEYWORD,example,DIRECT`	`api.example.com`、`notexample.com`	`example.org`以外で、その文字列を含まないドメイン（例：`sample.test`）

DOMAIN-SUFFIXを使う場合はexample.comと記述し、*.を付ける必要はありません。ドメイン境界を考慮してサフィックスを判定するため、単純な文字列の末尾比較とは異なります。一方、DOMAIN-KEYWORD,example,DIRECTはマッチ範囲が大幅に広く、対象サイトと関係のないドメインにも一致する可能性があります。特定のサイト群だけを対象にする場合は、明確なサフィックス条件を優先してください。

同じドメイン内の/newsと/accountは、上記3種類の条件では分けられません。
example.com:443にアクセスする場合も、ドメイン欄にはexample.comと記述し、:443は付けません。
IPアドレスを直接指定してアクセスする場合、ドメインルールが必ず一致するとは限りません。照合に使えるドメイン情報がリクエストに含まれているか確認してください。

GEOIPとIP-CIDRのマッチ対象

GEOIPは、地理情報データベース上での宛先IPの所属地域に基づいて判定します。たとえばGEOIP,CN,DIRECTは、データベースでCNと判定された宛先IPにDIRECTを適用します。ドメインのサフィックス、ウェブページの言語、企業の登記地を基準にするものではありません。また、特定のドメインのすべての名前解決結果が同じ地域に属するとは限りません。

IP-CIDRはIPv4アドレスの範囲を直接指定します。スラッシュの後ろはプレフィックス長です。/32は単一のIPv4アドレス、/24は256個のアドレスを表します。以下では、構文の説明用に用意されたアドレス範囲を使います。これらは利用可能なサービスのアドレスではありません。

IP-CIDR,192.0.2.7/32,DIRECT
IP-CIDR,198.51.100.0/24,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY

192.0.2.7/32が対象とするのは192.0.2.7のみで、192.0.2.8は含みません。
198.51.100.0/24のアドレス範囲は、198.51.100.0から198.51.100.255までです。
IPv6の範囲には対応するIP-CIDR6タイプを使用します。IPv6アドレスをIPv4用のIP-CIDRの例にそのまま当てはめることはできません。
ドメインのリクエストでIP条件を判定する前に名前解決が必要かどうかは、設定の名前解決動作によって異なります。名前解決の失敗とルールに一致しないことは、別の問題です。

一部のIP条件にはno-resolveを付けられます。例：IP-CIDR,192.0.2.0/24,DIRECT,no-resolve。この指定は、そのルールの評価だけを目的としたドメインの名前解決を避けるもので、DNSを全体的に無効にするものではありません。その時点で利用できる宛先IPがなければ、ドメインを名前解決してルールに一致させることはできません。切り分けでは、関連する設定をそのまま維持し、一括で追加・削除しないでください。

上から順に判定し、FINALは最後に置く

この記事で扱う通常のルールは上から順に判定され、一致するとその行のポリシーが適用されます。後に「より具体的な」条件があっても、自動的にそちらへ切り替わることはありません。つまり、タイプ名そのものに優先順位はありません。DOMAINが、その前にあるDOMAIN-SUFFIXより自動的に優先されるわけではありません。

[Rule]
DOMAIN,api.example.com,PROXY
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

api.example.comへのリクエストは1行目に一致し、PROXYが適用されます。
www.example.comへのリクエストは1行目には一致せず、2行目に一致してDIRECTが適用されます。
宛先IPが192.0.2.8で、それ以前のドメインルールに一致しなければ、例のアドレス範囲ルールに一致します。
それ以外の接続は引き続きGEOIPを判定し、どのルールにも一致しなければFINAL,PROXYで処理します。

最初の2行を入れ替えると、api.example.comは先にサフィックスルールに一致し、例外として個別に扱うつもりだったドメインが対象外になります。同様に、無条件のフォールバックであるFINALはルールの末尾に置いてください。その後に普通のルールを置いても、確定済みの結果は変わりません。順序の誤りを直すためにFINALを追加するのは避けてください。

要点：例外を先に、範囲の広い条件を後に

特定のサブドメインに別のポリシーを適用する場合は、そのDOMAIN条件を関連するDOMAIN-SUFFIXより前に置きます。保存後は、そのサブドメインと別の一般的なサブドメインをそれぞれテストし、別々のルールが適用されることを確認してください。

変更と検証は5つの手順で進める

以下の手順は、自分で用意したサーバーまたはサブスクリプションを持ち、基本的な接続ができることを前提としています。ルールファイルとHomeのサーバー一覧は用途が異なります。サーバー情報を更新しても、編集中のルールファイルが切り替わるわけではありません。同様に、振り分け設定を変更しても、無効な接続情報は修復されません。

設定をバックアップする

Configを開き、まず現在の設定のコピーを保存して、使用中のファイル名を記録します。リモート設定の場合は、今後の更新でローカルの変更が上書きされるかどうかも確認してください。
接続モードを確認する

Home → Global RoutingでConfigを選び、Configで選択されているファイルがテスト対象であることを確認します。あわせてHomeで選択されているデフォルトサーバーも確認してください。
変更は1項目だけにする

Configで対象の設定を編集する画面を開き、テキスト編集に進んで[Rule]を探します。既知の宛先に対するDOMAINルールを1つだけ追加するか、順序を1か所だけ変更して保存してください。
接続を再確立する

保存後、VPN接続を再確立し、テストするアプリから新しいリクエストを送信します。既存の長時間接続は以前の経路を使い続ける場合があります。同じページを何度も再読み込みしても、新しい接続が作られるとは限りません。
結果を照合する

接続ログで確認できる宛先、ポリシー、エラー情報をもとに実際の結果を確認します。Connectivity Testは基本的な接続性の確認に役立ちますが、特定のウェブサイトがどのルールに一致したかを単独で証明するものではありません。

ルールに一致しているのにアクセスできない場合

ルールに一致したことが示すのは、接続経路が選択されたという点だけです。その経路で宛先に正常に到達できるとは限りません。まず「ポリシーの選択が正しいか」を確認し、次に「選択した経路が利用できるか」を確認してください。以下は接続診断で表示されることがあるシステムエラーの原文です。ルールパーサー固有のエラーではなく、表示箇所や詳細は接続の種類によって異なる場合があります。

エラー：Connection refused

原因：宛先または中間の機器が接続を明示的に拒否しています。サービスが待ち受けていない場合や、ポートの入力ミスなどが考えられます。このエラーだけでDOMAINの構文に誤りがあるとは判断できません。

対処：まずログに記録された実際の接続先を確認します。PROXY経由の場合は、自分で用意したサーバーのアドレスとポートを確認してください。DIRECTの場合は、宛先サービスがそのポートへのアクセスを許可しているか確認します。

エラー：Operation timed out

原因：制限時間内に接続が完了しませんでした。サーバーに到達できない、宛先が応答しない、ネットワークでデータが破棄されたなどの可能性があります。タイムアウトだけでは、どのルールが原因か判断できません。

対処：まず最終的に適用されたポリシーを確認し、同じネットワークで基本的な接続性をテストします。設定を変えずに項目ごとに確認し、DNS、サーバー、ルール順序を同時に切り替えないでください。

エラーはないが、適用されるポリシーが想定と違う

すべてのリクエストが同じ経路になる：Home → Global Routingに戻り、ProxyまたはDirectになっていないか確認し、使用中の設定も確認してください。
単一ドメインの例外が機能しない：そのルールより前に、より広い範囲のDOMAIN-SUFFIX、DOMAIN-KEYWORD、またはFINALが一致していないか確認してください。
IPルールに一致しない：実際の宛先がIPv6かどうか、名前解決結果が変わっていないか、ルールにno-resolveが指定されているかを確認してください。
1つのページに複数のポリシーが適用される：ページはメインサイト、画像、APIなど複数のドメインに同時接続している場合があります。ページ全体を1つの接続と見なさず、リクエストごとに確認してください。
保存後も状況が変わらない：変更したファイルが選択されていることを確認し、テスト接続を再確立してください。古い接続の結果を新しいルールの検証結果と見なさないでください。

テストが終わったら、一時的なルールを削除するか、必要な範囲が明確な条件に変更してからバックアップを保存します。後から確認できる最小限の記録には、対象ドメイン、実際の宛先IP、想定したポリシー、実際のポリシー、エラーの原文を含めてください。これらの情報があれば、マッチ範囲、ルールの順序、ネットワーク接続性のどこに問題があるかを切り分けられます。