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

この記事の概要

Shadowrocketはルールを順番に判定し、最初に一致したルールのポリシーを適用します。設定済みの利用可能な構成があり、通信の振り分けを調整したい方向けの記事です。iPhone / iPadのHomeやConfig画面を例に説明しますが、ルールの考え方はMac、Windows、Android、Linux版にも共通します。編集画面はプラットフォームによって異なります。読み終えると、ドメインとIPの照合方法を区別し、基本的なRuleセクションを作成して、接続ログで一致結果を確認できるようになります。

1. Global RoutingがConfigになっているか確認する

ルールが構成に含まれていても、現在の接続がルールに従って振り分けられているとは限りません。HomeでGlobal Routingを確認し、現在の構成のRuleを適用する場合はConfigを選択します。Proxyは全体にプロキシポリシーを適用し、Directは全体を直接接続します。Sceneはシーンを選択する機能で、別のルールキーワードではありません。確認を始める際はConfigに固定し、Sceneの切り替えによる影響を避けましょう。

Configを開き、現在の構成をバックアップします。編集するのが別の同名ファイルではなく、選択中の構成ファイルであることも確認してください。
Homeに戻り、Global RoutingをConfigに設定して、既存のプロキシ接続が正常に使えることを確認します。
ルールを編集したら構成を保存します。必要に応じて接続を再確立し、新しいテストリクエストを送信してください。
接続ログで対象のドメインまたはIP、一致したルール、最終的なポリシーを確認します。ウェブページが開くかどうかだけで判断しないでください。

Settings → On Demandでは、接続を自動的に確立する条件を管理します。特定のドメインをPROXYとDIRECTのどちらに振り分けるかは決まりません。ルールのテスト中に接続を手動で切断する場合は、On Demandが再接続を実行しないか確認しましょう。設定を保存したことでスイッチが勝手に切り替わったと誤解するのを防げます。

アプリからリクエストトンネルに入る順に照合ポリシーを適用結果を記録

2. ルールの3要素：タイプ・照合値・ポリシー

基本的なルールの多くは、ルールタイプ、照合値、ポリシーの3項目を半角カンマで区切って記述します。たとえば DOMAIN,example.com,DIRECT は、接続先のドメインが example.com と完全に一致する場合に直接接続する指定です。FINALには照合値がないため、FINAL,PROXY と記述します。3項目の形式に合わせて空の項目を追加しないでください。

6種類

この記事で解説する基本ルールキーワード

3種類

基本ポリシー：PROXY / DIRECT / REJECT

最初に一致したルール

ルール名で自動的に並び替えられるわけではない

ポリシー	動作	適用時の注意
`PROXY`	プロキシポリシーで処理します。	利用可能なプロキシとその設定が必要です。ルール自体が接続サービスを作成するわけではありません。
`DIRECT`	接続先に直接接続します。	システムのトンネルを迂回するという意味ではなく、現在のネットワークから接続先に到達できる保証もありません。
`REJECT`	一致した接続を拒否します。	一致後にリクエストが失敗するのは想定どおりです。明確にブロックしたい接続先だけに使用してください。

ルールの末尾には、構成で定義済みのポリシーグループを指定することもできます。初めて設定する場合は、まず上記の基本ポリシーを使い、存在しないグループ名を入力しないでください。PROXYはポリシーの識別子で、Global RoutingのProxyは動作モードです。使う場所も役割も異なるため、相互に置き換えることはできません。

3. DOMAIN・DOMAIN-SUFFIX・DOMAIN-KEYWORDの違い

3種類ともドメインを対象としますが、照合範囲が異なります。DOMAINは完全なドメイン名に一致し、DOMAIN-SUFFIXは指定したドメインそのものとサブドメインに一致します。DOMAIN-KEYWORDはドメイン名に指定した文字列が含まれるかを調べます。ウェブページの本文は確認せず、URLのパスによって同じサイト内のページを区別することもありません。

ルール例	一致する例	一致しない例
`DOMAIN,example.com,DIRECT`	`example.com`	`www.example.com`
`DOMAIN-SUFFIX,example.com,DIRECT`	`example.com`、`img.example.com`	`notexample.com`
`DOMAIN-KEYWORD,example,PROXY`	`example.com`、`myexample.net`	`sample.net`

スキームは付けない：照合値には example.com と記述し、https://example.com とは書きません。
ページのパスは含めない：/login、クエリパラメーター、URLフラグメントは、これら3種類のルールの照合値ではありません。
ワイルドカードは不要：ドメイン全体とサブドメインを対象にする場合は DOMAIN-SUFFIX,example.com,DIRECT を使います。*. を付ける必要はありません。
短いキーワードは慎重に：DOMAIN-KEYWORD,ad,REJECT は、文字列「ad」を含む正常なドメインまで誤って拒否する可能性があります。広告ドメインだけを正確に指定するリストと同じものではありません。

api.example.com だけをプロキシ経由にし、同じドメインのほかの接続は直接接続したい場合は、完全一致のDOMAINを広範囲に一致するDOMAIN-SUFFIXより前に置きます。接続からドメイン情報を取得できる場合、このようにルールの順序で例外を指定できます。アプリがIPアドレスに直接アクセスする場合は、IPルールを確認してください。

4. GEOIPとIP-CIDR：照合対象は接続先IP

GEOIP,CN,DIRECT はIP地理データベース上の地域情報に基づいて接続先を判定します。ドメインの末尾やサービス提供元の本社所在地で判定するものではありません。ドメインへのリクエストがIP系ルールに到達すると、先にアドレスの解決が必要になる場合があります。判定結果はDNSの応答やデータベースの情報にも左右されるため、同じサービスでも接続先によって同じGEOIPルールに一致するとは限りません。

GEOIP,CN,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT
IP-CIDR,192.0.2.0/24,REJECT

IP-CIDRはネットワークアドレスとプレフィックス長で指定します。192.168.0.0/16 は 192.168.0.0 から 192.168.255.255 までのアドレスを対象とします。IPv4の /32 は単一のアドレスだけに一致します。上記の 192.0.2.0/24 はドキュメント用の例示ネットワークであり、実際のサービスアドレスではありません。実在するウェブサイトへの接続確認には使えません。

192.168.0.0/16 だけでは、すべてのプライベートIPv4アドレスを対象にできません。ほかのプライベートネットワークも必要な場合は、実際のネットワークに合わせて個別に設定してください。
IPv6のネットワークには対応する IP-CIDR6 タイプを使用します。IPv6アドレスをIPv4の例に入力して、同じように一致することを期待しないでください。
オプションの no-resolve は、このIPルールのためだけにドメイン解決が追加で行われるのを防ぎます。例：IP-CIDR,192.168.0.0/16,DIRECT,no-resolve。DNSを全体的に無効にする設定ではありません。
ドメインへのリクエストを解決後に特定のIP範囲へ一致させたい場合は、名前解決の動作を理解したうえで no-resolve を使うか判断してください。すべてのルールに付ける必須の接尾辞ではありません。

まとめ：対象ドメインが明確なら、まずドメインルールを使う

まずDOMAINまたはDOMAIN-SUFFIXで具体的な要件を指定し、GEOIPやIP-CIDRは地域やネットワーク範囲に応じたポリシーに使いましょう。アドレス解決の変化による判定のずれを抑えられ、接続ログから一致理由も確認しやすくなります。

5. FINALは最後に配置：個別の例外から既定ポリシーへ

Shadowrocketはルールを順番に確認し、最初に一致したルールのポリシーを適用します。後ろにあるルールのほうが「より具体的」でも、自動的にそちらへ切り替わることはありません。FINALはそれまでに一致しなかった接続を処理するため、Ruleセクションの最後に配置してください。先頭に置くと、後続の特定ドメイン向けルールが機能しなくなります。

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

これは学習用のRuleセクションで、プロキシ設定やDNSなどを含む完全な構成ではありません。既存の構成に [Rule] がある場合は、そのセクション内の項目を編集し、同じ名前のセクションを重複して追加しないでください。例のドメインは照合の仕組みを示すものです。使用する際は、実際に処理したい接続先に置き換えてください。

api.example.com にリクエストすると、1つ目のDOMAINルールに一致してPROXYが適用されます。以降のドメインサフィックスルールは確認されません。
img.example.com にリクエストすると、1つ目には一致せず、2つ目のDOMAIN-SUFFIXに一致してDIRECTが適用されます。
ドメインに blocked-demo が含まれ、先行する2つのルールに一致しない場合はREJECTに一致します。このルールのテストに別のドメインを使わないでください。
ほかの接続は指定したネットワーク範囲とGEOIPを順に確認します。どの条件にも一致しなかった場合に、FINALによってPROXYが適用されます。

既定で直接接続したい場合は、最後のルールを FINAL,DIRECT に変更できます。ただし、影響するのはテスト中のサイトだけではなく、すべての未一致接続です。変更前に、プロキシ経由にする必要があるドメインを洗い出し、FINALより前に配置してください。

6. ルールが機能しないとき：照合ミスと接続エラーを切り分ける

ウェブページが開けなくても、ルールの記述ミスとは限りません。まず接続ログで、接続先が想定どおりか、どのルールに一致したか、最終的にどのポリシーが使われたかを確認します。一致したルールやポリシーが想定と異なる場合は、構成の選択、ルールの範囲、順序を優先して確認してください。正しく一致しているのに接続できない場合は、ネットワークと設定済みのプロキシパラメーターを調べます。

Connection timed out

原因：接続が制限時間内に完了していません。直接接続先またはプロキシの出力先で発生する可能性があり、ルール構文の誤りだけを示すメッセージではありません。

対処：ログでDIRECTまたはPROXYのどちらが使われたかを確認し、現在のネットワークから接続先または設定済みのプロキシをテストします。問題を隠すためだけにFINALの位置を変えないでください。

Connection refused

原因：接続先から接続を拒否されました。指定アドレスのポートでサービスが待ち受けていない場合や、接続先が接続を明示的に拒否した場合によく発生します。

対処：ログに記録された接続先アドレスとポートを確認してください。PROXY経由の接続に失敗する場合は、設定済みのプロキシのアドレス、ポート、サービス状態も確認します。

HTTPSでよく使われる接続先ポートは 443 ですが、DOMAINルールは「443番ポートだけに一致する」ルールではありません。プロキシサーバーのポートにも、単純に443を設定しないでください。利用中のサービスの実際の設定値を確認します。PROXYに正しく一致しても接続できない場合は、ドメインキーワードを変更するのではなく、使用しているプロトコルの設定を確認してください。

いつもFINALに一致する：照合値にスキームやパスが誤って含まれていないか、接続ログにドメイン情報が記録されているかを確認してください。
例外ルールが反映されない：上に範囲の広いDOMAIN-SUFFIXやDOMAIN-KEYWORD、または先に配置されたFINALがないか確認してください。
変更後も以前の結果になる：現在の構成を保存したか確認してから、新しい接続を作成してください。ブラウザーで再利用されている接続は、以前の経路を引き続き使う場合があります。
しばらくすると元に戻る：構成がリモート更新によって置き換わっていないか確認してください。サブスクリプションのプロキシリストとConfig内のルール設定は別の内容です。プロキシリストを更新すればルールも更新されると決めつけないでください。

7. よくある質問：ドメイン・プロトコル・サブスクリプションの違い

DOMAINを設定したのに、サブドメインに適用されないのはなぜですか？

DOMAINは完全一致するドメイン名だけを対象にします。ルートドメインとすべてのサブドメインを対象にするには、DOMAIN-SUFFIXに変更してください。特定のサブドメインだけ例外にする場合は、そのDOMAINルールをサフィックスルールより前に置きます。

GEOIP,CN,DIRECTで中国語のサイトがすべて直接接続にならないのはなぜですか？

GEOIPが判定するのはIPアドレスの地域で、ページの言語ではありません。接続先の解決結果と一致ログを確認してください。特定のサイトを直接接続したい場合は、実際のドメインをDOMAIN-SUFFIXで指定し、GEOIPより前に配置します。

FINALをPROXYに変えれば、プロトコル設定の問題を解決できますか？

いいえ。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuardはプロキシプロトコルであり、ルールタイプではありません。FINALは未一致の接続に適用するポリシーを決めるだけです。パスワードや認証情報、TLS、トランスポートの設定は修正しません。

自分のサブスクリプションを更新すると、手動で追加したルールは保持されますか？

まず更新したものがHomeのプロキシサブスクリプションか、Configのリモート構成かを確認してください。リモート構成の更新ではファイルの内容が置き換わることがあります。編集前にConfigでバックアップし、更新後にRuleセクションを確認してください。すべての更新方法で同じマージ処理が行われるとは限りません。

日常のメンテナンスは「バックアップ、ルールを1つ変更、新しいリクエストを送信、一致結果を確認」の順で進めましょう。DNS、Global Routing、複数のルールを同時に変更するより、変数を1つずつ調整するほうが原因を特定しやすくなります。この記事は、利用者がすでに自身のサービスとサブスクリプションを用意していることを前提としています。当サイトでは接続先やサブスクリプションの提供・販売・推奨はしていません。クライアントの入手と接続サービスは別のものです。