Shadowrocketのリモートルール設定術｜RULE-SETと通信振り分けを徹底解説

リモートルールとは：RULE-SETで外部のルールを参照する

リモートルールは、ルールの内容を設定ファイルにすべて直接記述する代わりに、外部のルールファイルを参照して利用する方法です。Shadowrocketでは、通常、Configで使用する設定ファイルを選び、そのファイルの[Rule]セクションにRULE-SETを記述します。リモートのルールを参照する行も、最終的には設定ファイル内の他のルールと照合されます。

RULE-SETの基本形は、ルールの種類、ルールファイルのURL、適用するポリシーの順です。ポリシーにはPROXYやDIRECTのほか、設定内で定義されているポリシー名を指定できます。実際に選べるポリシーは現在の設定内容に従います。ファイルに存在しない名前を指定しても、期待した経路にはなりません。

[Rule]
RULE-SET,https://rules.example.invalid/sample.list,PROXY
DOMAIN-SUFFIX,example.invalid,DIRECT
FINAL,PROXY

この例では、最初の行がリモートルールを参照し、一致した通信にPROXYを適用します。URLのexample.invalidは説明用の予約ドメインであり、実際にルールを取得できる配布先ではありません。設定時には、利用するルールの配布元が案内する実際のURLと形式を使ってください。配布元が認証を必要とする場合や、ネットワークからアクセスできない場合は、ルールを取得できないことがあります。

リモートルールを記述しただけで、すべての通信に適用されるわけではありません。Homeで想定した設定が選ばれているか、Global RoutingがConfigになっているかも確認してください。Proxyはルールによる個別の振り分けではなく通信を一律にプロキシ経由にし、Directは直接接続します。ルールの動作確認では、まずConfigを基準にすると、ルールによる結果を切り分けやすくなります。

優先順位の考え方：例外を先に、広い対象を後に置く

[Rule]は上から順に照合されます。広い対象に一致するルールを先に置くと、その下にある個別の例外まで処理されないことがあります。リモートのRULE-SETも同じリストの一部として位置づけ、どの通信を先に処理したいかを考えて配置してください。末尾のFINALは、それ以前のルールに一致しなかった通信のためのフォールバックです。

[Rule]
DOMAIN,api.example.invalid,DIRECT
RULE-SET,https://rules.example.invalid/sample.list,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY

この例では、api.example.invalidへの通信を先にDIRECTへ振り分けます。その後、ルールセットに一致する通信にはPROXYが適用されます。さらにGEOIPに一致し、先行ルールでは処理されなかった通信はDIRECTとなり、どのルールにも一致しないものはFINALに進みます。記述した行が実際に評価される順序は、このように具体的な通信先を当てはめて確認してください。

ルールセットの対象に含まれるドメインを個別に除外したい場合は、その例外をルールセットより前に置く方法が基本です。反対に、個別ルールを後ろへ置けば上書きできると考えるのは避けてください。先に一致したルールが使われるためです。ルールセットの更新によって対象が変わる可能性もあるので、例外の目的をコメントなどで記録できる場合は、後から見直せる形にしておくと管理しやすくなります。

• 完全一致の例外：DOMAINで特定のホスト名を指定し、対象範囲の広いRULE-SETより前に置きます。
• ドメイン範囲の指定：DOMAIN-SUFFIXは対象となる範囲を確認してから使い、個別ホストの例外を先に置きます。
• IPアドレスの指定：IP-CIDRの対象とno-resolveの有無を確認し、ドメインルールとは別の条件として扱います。
• 最後の処理：FINALのポリシーを確認し、予期しない通信がどの経路へ進むかを明確にします。

ポリシー指定と設定ファイルを確認する

RULE-SETの末尾に書くポリシーは、そのセットに一致した通信の送信先を決めます。PROXYと書けばプロキシ経由、DIRECTと書けば直接接続です。設定にポリシーグループが定義されている場合は、その名前を指定できることがありますが、名前の表記や定義状況は使用中の設定に合わせる必要があります。ルール側の名前だけを変更しても、対応するポリシーが存在しなければ意図した動作になりません。

構文を変更するときは、一度に複数の要素を動かさないでください。まずRULE-SETのURLとポリシーを確認し、その後、配置順や例外ルールを調整します。変更前の内容を控えておけば、通信結果が悪化した場合に元へ戻せます。ルールファイルの更新方法や取得タイミングは、利用している配布元と設定の運用方法に沿って確認してください。取得が成功したか不明な状態で、ルールの内容が更新済みだと決めつけないことが重要です。

また、接続の確立と通信の振り分けは別の確認項目です。Shadowrocketが接続中でも、選択中のルーティングモードや一致したルールによって、特定のリクエストがDIRECTになることがあります。VPNの表示だけを見て、すべての通信がプロキシ経由だと判断しないでください。

設定の適用とテスト：変更を一項目ずつ検証する

ルールセットの動作を確かめるには、設定ファイルを読み込んだかだけでなく、実際に使用するファイルとして選択されているかを確認します。Configで現在のファイルを開き、[Rule]にRULE-SETがあることを確認してください。そのうえでHomeに戻り、接続先とGlobal Routingを確認します。ルールに基づく振り分けを試す場合、Global RoutingはConfigを選びます。

1. 対象を特定

   Configで現在選択中の設定ファイルを確認します。複数の設定がある場合は、編集したものと使用中のものが同じかを見比べます。

2. 構文を点検

   [Rule]内のRULE-SET行を確認し、半角カンマ、URL、ポリシー名に誤りがないか見ます。ルールファイルの形式は配布元の説明と照合してください。

3. 経路を選択

   Homeで利用可能な自分の接続設定を選び、Global RoutingをConfigにします。接続できることと、対象リクエストが想定したルールに一致することを別々に確認します。

4. 新規通信で試す

   対象アプリでページを再読み込みするなど、新しいリクエストを発生させます。既存の通信が継続している場合は、テスト結果が変更前の接続を反映することがあります。

5. 結果を記録

   テスト先、選択中の設定ファイル、Global Routing、適用したルールとポリシーを記録します。変更は一つずつ行い、前後の結果を比較します。

ルールセットの取得に成功しているか、対象の通信がそのルールセットに一致しているかは、別々に考えます。たとえばURLにアクセスできない問題と、アクセスできるが経路が想定と違う問題では、調べる箇所が異なります。先にルール配布元への到達性と設定内容を確認し、その後に対象ホスト、ルールの位置、ポリシーを調べると、原因を絞り込みやすくなります。

ルールが効かない場合：取得・照合・経路を切り分ける

ルールが反映されないと感じたら、まず「どの通信が、どの設定ファイルを使い、どのポリシーに一致する想定か」を一文で整理します。たとえば「選択中のConfigで、対象ホストがRULE-SETに一致し、PROXYになる想定」と記録します。対象ホストを曖昧にしたままでは、サブドメインやアプリ内の別の接続先をテストしている可能性を見落とします。

URLの記述を確認するときは、余分な空白や全角記号が混じっていないかも見てください。HTTPSのURLであれば、ネットワーク側の制限や配布元側の応答も取得可否に影響することがあります。接続先に到達できない問題が続く場合は、利用している配布元の案内を確認してください。ここで確認するのは、利用中のルールファイルが取得できるかどうかであり、特定のルール配布元や接続サービスを推奨するものではありません。

設定を戻す必要がある場合は、記録した変更前の内容に戻し、同じテスト先と同じGlobal Routingで再試験します。試行ごとに複数のルールや接続条件を同時に変えると、改善または悪化の原因が分からなくなります。RULE-SETの位置、ポリシー、対象の例外を一項目ずつ調整し、結果が再現するかを確認してください。