Shadowrocketのカスタムルール優先順位｜上から順に判定する仕組みとFINALの使い方

まずGlobal RoutingをConfigに設定

ルールを編集する前に、「接続するか」と「通信をどう振り分けるか」を分けて確認します。Homeの接続スイッチは接続の有効化を担い、Global Routingはリクエストの処理方法を決めます。設定ファイル内のルールを検証するには、Global RoutingをConfigにしてからConfigで使用中の設定ファイルを確認してください。有効になっていないファイルを編集しても、現在の振り分け結果は変わりません。

Global RoutingのProxyは通信全体をプロキシ経由にし、Directは全体を直接接続にします。どちらを選んでも、設定ファイル内の特定のルールに一致した証拠にはなりません。Sceneは状況に応じて設定を適用する機能であり、Configの固定状態として扱わないでください。個別ルールを調べる際は、まずConfigを選び、Sceneの切り替えによる影響を抑えます。

上から順に判定。「より具体的」なルールが自動で優先されるわけではない

ルールの並びは、順序のある条件判定リストと考えられます。リクエストが振り分け処理に入ると、条件を上から確認し、一致した時点でそのルールのポリシーを適用します。その後にある「より適切そうな」ルールは調べません。そのため、個別の例外は通常、汎用ルールより前に置きます。条件の細かさをアプリが自動で比較することには頼れません。

以下は、よくあるルール順序の問題です。DOMAIN-SUFFIX,example.com,PROXYは、example.com自体とそのサブドメインに適用されます。宛先がapi.example.comの場合、1行目で一致するため、後ろにある完全一致のドメインルールは判定されません。

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

このサブドメインだけをDIRECTにし、同じサフィックスのほかのドメインにはPROXYを使う場合は、例外を前に置きます。ここに記載したドメインは構文の説明用であり、接続サービスや疎通確認には使えません。

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

拒否ルールの例外も同じです。特定のサブドメインだけを拒否し、同じサフィックスのほかのリクエストは引き続きプロキシ経由にするなら、完全一致のREJECTルールを広範囲のサフィックスルールより前に置きます。「拒否のほうが強いから優先される」と考えないでください。

DOMAIN-SUFFIX・IP-CIDR・GEOIPの並べ方

これらのキーワードは異なる条件を表すもので、固定の優先順位を示すものではありません。DOMAIN-SUFFIXはドメインのサフィックス、IP-CIDRは宛先IPが指定範囲内かどうか、GEOIPはIPの地域情報に基づいて地域コードを判定します。具体的な例外を先にし、その後に対象範囲の広いアドレスや地域のルールを置きます。

IPルールの判定には、対象となるIPアドレスが必要です。リクエストの宛先が最初はドメイン名だけの場合、名前解決の過程によってIP-CIDRやGEOIPに一致するかどうかが変わることがあります。例のno-resolveは、このルールのためだけにドメイン名の名前解決を開始しない指定です。アプリ全体のDNSを無効にする指定でも、すべてのドメインリクエストがそのIP範囲に直接一致するという意味でもありません。

• ドメインに個別の例外がある：DOMAINまたはDOMAIN-SUFFIXを先に置き、対象リクエストのポリシーを広範囲のIP条件より前に確定します。
• ローカルネットワークに明確な範囲がある：実際のネットワークに合わせてIP-CIDRを記述します。192.168.0.0/16はプライベートアドレス範囲の一つであり、すべてのローカルネットワークを表すものではありません。
• 地域ごとに基本ポリシーを設定する：GEOIPは個別の例外より後に置きます。地域データベースが示すのはIPアドレスの帰属地域であり、ウェブサイトの使用言語やドメインのサフィックスではありません。
• どの条件にも一致しない：ルールの末尾にあるFINALで処理し、前方に無条件ルールを挿入しないでください。

GEOIPの判定結果はアプリが使用するIP地域情報に依存し、ウェブサイト運営者の所在地と一致するとは限りません。CDNを利用するサイトでは、時間帯によって異なるIPアドレスに名前解決されることもあります。特定のドメインに常に同じポリシーを適用する必要がある場合は、個別のルールを設定してください。GEOIPだけで通信経路を推測するのは避けましょう。

PROXY・DIRECT・REJECTは動作を示すもので、優先順位ではない

ルールは通常、キーワード、照合値、ポリシーで構成されます。たとえばDOMAIN-SUFFIX,example.com,PROXYでは、前の2項目が「何に一致させるか」、最後の項目が「一致したときにどう処理するか」を示します。FINALは特別なフォールバック形式のため、ドメインやネットワーク範囲を指定せず、FINAL,PROXYのように記述します。

PROXYに一致したことが示すのは、ルールがプロキシ経由の処理を選んだことだけです。宛先への接続が保証されるわけではありません。サーバーの停止、接続先サービスの障害、名前解決の失敗でもアクセスできないことがあります。DIRECTに一致しても、すべてのルール判定を回避するわけではありません。ルール判定後に直接接続する動作です。

設定でカスタムのポリシーグループ名を使う場合、ルールの末尾には既存の名称を正確に指定してください。任意の説明文をポリシーとして入力したり、ルールにPROXYと書かれているだけで現在の接続先が正しいと判断したりしないでください。Homeでの選択状態と、設定内のポリシーグループの状態も確認します。

FINALを末尾に置く理由と、PROXY・DIRECTの選び方

FINALは特定のドメイン、ネットワーク範囲、地域を限定せず、その位置まで一致しなかったリクエストを処理します。ルールの先頭付近に置くと、後続ルールが判定されなくなります。そのため設定を管理する際は、問題が起きるたびにFINALを追加するのではなく、ルール末尾のフォールバックを確認してください。

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

これはルールの順序を確認するための例であり、完全な設定ファイルではありません。既存設定の必要なセクションは残し、実際の用途に合わせてルールを統合してください。この数行でファイル全体を置き換えないでください。例では最初のサブドメインにDIRECT、2つ目にREJECTを適用し、同じサフィックスのほかのドメインにはPROXYを使います。それ以外のリクエストは、アドレス、地域、最後のフォールバックの順に判定します。

1. FINAL,PROXYを選ぶ：個別の例外に一致しないリクエストもプロキシ経由にします。未分類のリクエストをまとめてプロキシ経由にしたい場合に適しています。
2. FINAL,DIRECTを選ぶ：明示的に指定したリクエストだけをプロキシ経由にし、それ以外は直接接続します。ルールに記載されていない宛先には直接接続できない場合があることを考慮してください。
3. 変更前にバックアップ：現在使える設定を保存し、変更前のFINALポリシーを記録します。影響範囲が広がった場合は、例外を追加し続けるのではなく、元のファイルに戻せます。

変更後の検証方法：キャッシュを新しい結果と取り違えないために

ルール変更後は「保存・反映・新しい接続・記録の確認」までを一連の手順として行います。ブラウザーやアプリは確立済みの接続を再利用することがあり、ページを開き直しただけでは同じルール判定が再度行われるとは限りません。検証時は、既存接続の継続と新しいリクエストの結果を区別してください。

1. 現在のファイルをバックアップ：Configで使用中の設定を確認し、変更前のコピーを保存します。今回変更する対象のドメインまたはネットワーク範囲も記録してください。
2. 変更する条件は一つだけ：たとえばDOMAINの例外をDOMAIN-SUFFIXより前に移動するだけにして、DNS、サーバー、FINALは同時に変更しないでください。
3. 保存して反映を確認：編集後、対象のファイルが引き続き使用中であることを確認します。Homeに戻り、Global RoutingがConfigで、接続状態が正常であることを確かめてください。
4. 新しい接続を開始：対象のページまたはアプリの既存接続を閉じてから再試行します。必要に応じて、短時間の切断が問題ないことを確認したうえで再接続し、宛先にアクセスしてください。
5. 接続記録を確認：Dataで利用可能な接続記録やログを開き、宛先ドメイン、宛先IP、ポリシーを確認します。記録にルール情報が表示される場合は、一致したルールも確認してください。

たとえば、api.example.comがDIRECTに一致する想定なのに、記録では同じサフィックスのルールによってPROXYになっている場合は、まずルールの順序とファイルが反映されているかを確認します。記録にDIRECTと表示されているのにアクセスできない場合は、直接接続できるかを調べてください。同じルールを上に複製し続けても解決しません。

利用中のサーバーサブスクリプションの更新と設定ファイルの更新も区別してください。サーバー一覧が変わっても、Config内のルールが変わるとは限りません。一方、リモート設定の更新によってローカルでの編集内容が置き換わることがあります。編集対象を確認してから変更し、更新後はルールの順序とFINALを再確認してください。これにより、ルールの判定問題なのか、更新で内容が置き換わったのかを判断できます。

ルール優先順位に関するよくある質問