Shadowrocketのルール設定入門：DOMAIN・DOMAIN-SUFFIX・GEOIP・IP-CIDR・FINALの違い

この記事の要点

Shadowrocketのルールは、照合条件と処理ポリシーで構成されます。接続設定を用意済みで、Configからルールを編集する方に向けて、ドメインとIPの照合方法、ルールの優先順位、実際のリクエストで一致結果を確認する手順を解説します。例に使うドメインとアドレスは構文説明用であり、接続サービスではありません。

1. ルールが適用されるモードを確認する

HomeでGlobal Routingを確認します。この記事ではConfigを選び、現在の設定にあるルールに従って通信先を決める場合を説明します。Proxyは主にプロキシ経由、Directは主に直接接続で通信を処理します。この2つのモードでは、Webページを開けるかどうかだけでConfigのルールが適用されたか判断できません。Sceneは状況に応じて選択する機能です。シーンの条件と実際に使われているルーティング設定を別途確認してください。

ルールが決めるのは「この接続をどの経路で処理するか」であり、「プロキシサーバーに接続できるか」ではありません。PROXYに正しく一致しても、設定済みサーバーが利用できなければリクエストは失敗する可能性があります。DIRECTも直接接続を選ぶだけで、現在のネットワークから対象サイトに必ずアクセスできることを保証するものではありません。

リクエストがトンネルに入る宛先情報を読み取るルールを順に確認する一致したポリシーを適用する外向きの接続を確立する

ルールは、まず3つの部分に分けて考えると理解しやすくなります。2番目の項目は照合値、3番目はポリシーです。FINALには照合値がないため、項目は2つだけです。項目の区切りには半角カンマを使い、全角カンマに置き換えないでください。

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

DOMAIN：照合タイプ。宛先のドメイン名が完全に一致する場合に照合します。
api.example.com：照合値。プロトコル、ポート、URLのパスは含めません。
PROXY：プロキシポリシーで処理します。利用可能なプロキシ設定が必要です。
FINAL,DIRECT：それ以前のルールに一致しなかった場合、直接接続します。

2. DOMAIN・DOMAIN-SUFFIX・DOMAIN-KEYWORDの照合範囲

この3種類のキーワードはいずれもドメイン名を照合しますが、対象範囲が異なります。完全なURLからホスト名を取り出して確認しましょう。たとえば、https://api.example.com:8443/v1/statusのホスト名はapi.example.comです。8443はポート、/v1/statusはパスなので、DOMAINの照合値には含めません。

キーワード	ルール例	照合範囲
DOMAIN	`DOMAIN,api.example.com,PROXY`	api.example.comのみ。サブドメインは含みません。
DOMAIN-SUFFIX	`DOMAIN-SUFFIX,example.com,PROXY`	example.comとapi.example.comなどのサブドメインに一致します。
DOMAIN-KEYWORD	`DOMAIN-KEYWORD,example,PROXY`	ドメイン名にexampleという文字列を含む宛先に一致します。照合範囲はより広くなります。

ホスト名の完全一致・サブドメイン全体・キーワード

特定のAPIホストだけをプロキシ経由にする場合はDOMAINを使います。同じドメイン配下のメインサイト、画像用サイト、API用サイトも対象にする場合は、DOMAIN-SUFFIXのほうが管理しやすくなります。ドメイン階層に沿って照合するため、example.comはnotexample.comにもexample.com.other.testにも一致しません。

DOMAIN-KEYWORDは文字列が含まれるかどうかで判定します。exampleをキーワードにすると、異なる末尾のドメインに含まれる同じ文字列にも一致しますが、無関係なドメインまで対象になることがあります。サイトの運営元やブランド、ページの内容を判別する機能ではありません。正確なドメイン名で条件を指定できる場合は、ルールを短くするためだけに範囲の広いキーワードへ置き換える必要はありません。

3. IP-CIDRとGEOIPで宛先IPを照合する

IP-CIDRは宛先IPが指定したネットワーク範囲に含まれるかを判定します。GEOIPはIPの地理情報データベースに基づいて判定します。Webページの言語、ドメインの末尾、アカウントの地域とは別のものです。ドメイン名でアクセスする場合、IPを判定するために先に名前解決が必要になることがあります。IPアドレスへ直接アクセスする場合は、通常のドメインルールで照合できるホスト名がありません。

[Rule]
IP-CIDR,192.168.50.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

192.168.50.0/24はIPv4のネットワーク範囲を表し、192.168.50.0から192.168.50.255までが対象です。「ポート24」という意味ではありません。
no-resolveは、このIPルールのためだけにドメインを積極的に名前解決しない指定です。すべてのDNSを無効にする設定でも、直接接続に切り替える設定でもありません。
GEOIP,CN,DIRECTは、データベース上で宛先IPがCNに分類された場合にDIRECTを適用する指定です。「中国語のWebサイトを直接接続する」という意味ではありません。
IPv6のネットワーク範囲には対応するIP-CIDR6を使用します。IPv6アドレスをIPv4のネットワーク範囲として入力しないでください。

上記のローカルネットワーク範囲は構文の例です。実際のルーターでは192.168.1.0/24など、異なるアドレス範囲が使われる場合があります。現在のネットワークに合わせて設定してください。特定の1台を対象にするために、必要以上に広いネットワーク範囲を追加すると、ほかのアドレスも同じポリシーの対象になります。

GEOIPの判定結果はデータベースと宛先IPに依存します。CDNを利用するWebサイトは、ネットワークによって異なるIPアドレスに名前解決されることがあります。DNSの変更後に判定結果が変わる場合もあります。そのため、「昨日はDIRECT、今日はPROXY」になっても、ルールファイルが壊れたとは限りません。ドメイン名、名前解決の結果、適用されたルールをあわせて確認してください。

4. ルールは上から順に判定し、FINALは末尾に置く

この記事で扱う一般的なルール一覧では、上から順に判定し、最初に一致したルールのポリシーが適用されます。「すべてのルールのうち、最も細かい条件が自動的に優先される」仕組みではありません。範囲の広いルールが先に一致すると、後続の詳細なルールは適用されません。

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

上の例では、api.example.comは最初にDOMAINへ一致し、PROXYが適用されます。www.example.comは1行目には一致しませんが、2行目に一致するためDIRECTになります。最初の2行を入れ替えると、APIホストも先にDOMAIN-SUFFIXに一致します。例外を先に、共通の範囲を後に記述するのはこのためです。

対象	最初に一致したルール	ポリシー
`api.example.com`	DOMAIN	PROXY
`www.example.com`	DOMAIN-SUFFIX	DIRECT
その他のドメイン。宛先IPはCNに分類	GEOIP	DIRECT
その他のドメイン。GEOIPにも一致しない	FINAL	PROXY

指定したドメインだけをプロキシ経由にする

「指定したサイトだけをプロキシ経由にし、それ以外は直接接続する」場合は、次の最小限の設定例から始められます。この例にGEOIPを含めていないのは、地域による追加判定が不要なためです。ルールの数が少なくても、必要な動作を正確に指定できていれば問題ありません。

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

5. Configを編集したら、新しい接続で確認する

作業を始める前に、利用中のサービスと有効な設定が必要です。ルール編集のためにクライアントを買い直したり、プロトコルを変更したりする必要はありません。Shadowsocks、VMess、VLESS、Trojanなどのプロトコルはプロキシ接続を担い、この節で扱うキーワードはリクエストをプロキシに送るかどうかを決めます。それぞれ異なる層の設定です。

現在の設定を残しておく

Configを開き、まず現在の設定のコピーを保存するか、バックアップをエクスポートしてください。使用中の設定を記録しておきます。リモート設定の更新でローカルの編集内容が上書きされる可能性があるため、唯一のコピーだけで何度も試さないでください。
ルール部分を編集する

Configで対象設定の編集画面を開き、[Rule]を探します。既存のルール部分を編集し、同じ名前のセクションが複数できるよう、例全体をファイル末尾に重ねて貼り付けないでください。
項目の順序を確認する

半角カンマを使用し、ドメインの項目からhttps://、ポート、パスを取り除きます。完全一致の例外を共通ルールより前に置き、FINALを末尾に配置します。ポリシー名のスペルも確認してください。
編集した設定を有効にする

保存後、編集した設定を選択してHome → Global Routing → Configに戻ります。Homeで利用可能なサーバーが選択されていることも確認し、接続の問題とルールの問題を混同しないようにしてください。
新しいリクエストを発生させる

接続を確立し直してテスト対象にアクセスし、Dataで新しいリクエストの宛先、ポリシー、一致したルールを確認します。既存の接続では以前の経路が使われ続けることがあります。接続を再利用しているページを更新するだけで判断しないでください。

1回の検証で変更する条件は1つにします。まず完全一致のDOMAINを確認し、次にDOMAIN-SUFFIXへ範囲を広げ、最後にIPの判定を追加します。予想したポリシーと実際のポリシーを記録すると、数十件のルールを一度に追加するより原因を特定しやすくなります。例に使うドメインは構文の説明用です。実際の検証では、本当にアクセスする必要のある宛先を使ってください。

6. 「ルールに一致するか」と「接続できるか」を分けて確認する

トラブルシューティングでは、まずDataで新しいリクエストに想定したポリシーが適用されているかを確認し、次に宛先へ接続できるか調べます。ポリシーが想定と異なる場合は、現在のConfig、Global Routing、先行するルールを確認してください。ポリシーは正しいのにタイムアウトする場合は、プロキシへの接続、DNS、宛先サーバーを確認します。すぐに範囲の広いキーワードへ変更しないでください。

以下はAppleのネットワークエラーで使われる標準的な識別子です。システムやアプリの詳細なエラー情報に表示されることがあります。リクエストの入口によって表示内容は異なります。接続に失敗したことを示すもので、Shadowrocketのルール構文エラーではありません。また、エラーコードだけでDIRECTとPROXYのどちらを使うべきか判断することもできません。

NSURLErrorDomain Code=-1001

原因：応答を待つ時間が上限を超えています。プロキシへの接続中、または宛先からの応答待ちで発生することがあります。

対処法：まずDataで適用されたポリシーを確認し、現在のサーバーと同じ宛先への接続をそれぞれ確認してください。ルールの順序を変えるだけでタイムアウトの原因を覆い隠さないようにします。

NSURLErrorDomain Code=-1003

原因：指定されたホストが見つかりません。ドメイン名のスペルとDNSの名前解決条件を確認してください。

対処法：リクエスト先のホスト名が正しいことを確認し、現在のDNS設定を調べてください。ドメインにPROXYルールを追加しても、名前解決の問題は解消されません。

DOMAIN-SUFFIXを設定したのに、なぜ直接接続される？

Home → Global Routingを開き、Configが選択されていることを確認します。次にConfigで選択中のファイルを確認してください。どちらも正しい場合は、そのルールより前にDOMAIN、別のサフィックスルール、またはFINALが一致していないか確認し、Dataで実際のリクエストのホスト名を調べます。

サイトは開くのに、画像が読み込まれないのはなぜ？

Webページと画像は、異なるドメインから読み込まれることがあります。ページを再読み込みし、Dataで読み込みに失敗したリソースのホスト名を確認して、用途に応じたルールを追加してください。ページのURLだけから、すべてのリソースが同じDOMAIN-SUFFIXを使っていると判断しないでください。

IP-CIDRにno-resolveを追加したら、一致しなくなったのはなぜ？

リクエストがドメイン名で行われ、その時点で照合可能な宛先IPがない場合、このルールはネットワーク範囲を判定するために積極的な名前解決を行いません。ドメイン名での振り分けが必要なら、ドメインルールを指定してください。解決後のIPで判定する必要がある場合は、no-resolveを残すか改めて検討します。

ルールを編集して再接続したら、元の内容に戻ったのはなぜ？

まず、現在有効なファイルを編集したか確認し、リモート設定が更新されていないか調べます。接続のサブスクリプションとルール設定は同じ内容ではありません。ローカルで編集したコピーを残し、更新後にルールの差分を確認してください。Settings → On Demandはオンデマンド接続を制御する設定で、ルールの保存や復元には関係ありません。

最後に、次の4点を確認します。Global RoutingがConfigになっていること、現在の設定に編集内容が含まれていること、最初に一致したルールが想定どおりであること、選択された経路で接続を確立できること。この順序で確認すると、構文、優先順位、DNS、接続経路のどれが影響しているかを切り分けられます。