Shadowrocketのルール設定方法：優先順位、FINALのフォールバック、PROXY/DIRECT/REJECTの使い分け

1. まずGlobal Routingを確認してからルールをチェック

設定ファイルにルールを書いても、現在のリクエストが必ずそのファイルに従って振り分けられるとは限りません。Homeでは接続やサービス項目を管理し、Configでは設定ファイルを管理し、Settingsではアプリの設定を行います。トラブル時は、接続に使われている設定を確認してから、Home → Global Routingを確認してください。この記事のルール解説はConfigを選択していることが前提です。ProxyまたはDirectで一時的に振り分けを上書きしている場合には当てはまりません。

Global RoutingのSceneではシーンを選択するため、現在そのシーンで使われている設定を確認してください。Sceneは[Rule]内に記述するルールキーワードではありません。初回のルール検証では、条件を減らすため明示的にConfigへ切り替えます。Settings → On Demandは条件に応じて接続を開始する動作を制御するもので、ルールの順序は変更しません。

2. ルールの構文：条件を先に、ポリシーを後に記述

設定ファイルでは、ルールを[Rule]セクションに記述します。一般的なルールは「タイプ,マッチ値,ポリシー」の形式で、半角のカンマで区切ります。以下の3行は、完全一致のドメイン、ドメインサフィックス、最終ポリシーの例です。ドメインは構文説明用のため、実際の用途にそのまま流用しないでください。

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

PROXYはサーバーアドレスでもプロトコル名でもありません。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuardは接続プロトコルです。ルールはリクエストに適用するポリシーを決め、サービス項目には実際の接続パラメーターを設定します。プロトコル名、サブスクリプションのURL、サーバーのポートをルールのポリシー欄に記述しないでください。カスタムポリシーグループを使う場合は、その名前が設定内の定義と一致している必要があります。

3. ルールの優先順位：上のルールに一致すると、下は評価されない

ルールは上から順に評価され、一致した時点で対応するポリシーが適用されます。「より具体的なルールが自動的に優先される」わけでも、すべての一致結果を組み合わせるわけでもありません。上の例では、api.example.comは先にDOMAINに一致するためPROXYが適用されます。img.example.comは1行目に一致せず、次にDOMAIN-SUFFIXに一致するためDIRECTが適用されます。

1. 個別の例外を先に配置します。完全一致で個別に処理するドメインは、広いサフィックス条件より前に置きます。たとえば、DOMAIN,api.example.com,PROXYをDOMAIN-SUFFIX,example.com,DIRECTより先に記述します。
2. 次に範囲指定のルールを配置します。DOMAIN-SUFFIXは指定したドメイン自体とそのサブドメインに一致します。example.comはexample.comとa.example.comに一致しますが、この文字列を含むすべてのドメインに一致するわけではありません。
3. REJECTルールの配置には注意します。先にDOMAIN-SUFFIX,example.com,REJECTを記述すると、後にあるapi.example.comの許可ルールは評価されません。
4. FINALは最後に配置します。それより前の条件に一致しなかったリクエストに、最後のポリシーを適用します。FINALの後に記述したルールは、通常の後続マッチングには使えません。

最初の2行を入れ替えると、結果が変わります。以下の例では、api.example.comが先頭のルールに一致して直接接続されます。2行目の方が具体的でも、すでに決まった結果は上書きされません。

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

4. FINALのフォールバックとIPルールの組み合わせ

FINALにドメインやネットワークの値は指定しません。正しい形式はFINAL,ポリシーで、例はFINAL,PROXYまたはFINAL,DIRECTです。接続失敗時に再試行する仕組みではありません。PROXYルールに一致して接続に失敗しても、FINALまで下に進んでDIRECTに切り替わることはありません。フォールバックが対象とするのは「どの条件にも一致しない」場合であり、「接続に失敗した」場合ではありません。

no-resolveは、このIPルールへの一致判定のために追加のドメイン解決を行わないようにします。アプリ全体のDNSを無効にするものではなく、ドメインを自動的にIPへ変換するものでもありません。リクエストに利用可能な宛先IPが含まれていれば、そのIPで判定できます。ドメインしかなく、利用可能なIPもまだない場合、このルールに必ず一致するとは限りません。

GEOIPの判定結果は宛先IPとローカルデータベースに左右されます。同じドメインでも解決先が異なれば、一致する地域条件が変わることがあります。固定ポリシーを適用したい特定のドメインには、まずDOMAINまたはDOMAIN-SUFFIXの明示的な例外を設定し、その後にGEOIPなど範囲の広い条件を配置します。「名前解決に成功した」「ルールに一致した」「接続に成功した」は、それぞれ別の状態です。

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

上の断片はルールの並べ方の一例であり、完全な設定でも、すべてのネットワークに推奨される一覧でもありません。使用前に、ローカルネットワークの範囲、宛先ドメイン、最終ポリシーが用途に合っているか確認してください。宛先がIPv6を使う場合、IPv4のIP-CIDRルールだけでは対応するIPv6アドレスをカバーできません。関連ルールとネットワーク条件を別途確認してください。

5. 保存後に一致結果を確認する

検証する単位は、すでに開いているページではなく、新しく開始した接続です。ブラウザーが既存の接続を再利用したり、ページがキャッシュを表示したりすることがあります。ページが開けるかだけでは、変更したルールが適用されたか判断できません。変更前に元の設定を保存し、テストでは一度に変更する条件やポリシーを1つにしてください。

1. 設定を確認

   Configを開き、現在選択されているファイルを確認します。そのファイルの[Rule]セクションを編集して保存してください。有効になっていない別のコピーだけを変更しないようにします。

2. モードを固定

   Home → Global Routing → Configに戻り、Proxy、Direct、または未確認のSceneではなく、Configが選択されていることを確認します。

3. 接続を再作成

   設定を反映してから宛先へ新しいリクエストを送ります。必要に応じて切断し、再接続してください。テストページの古い接続を閉じ、接続の再利用を新しいルールの不適用と誤認しないようにします。

4. ログを確認

   リクエストログで、実際の宛先ドメインまたはIP、一致したルール、適用されたポリシーを確認します。ページで複数のドメインが使われている場合は、メインのページ、ログインAPI、リソースのリクエストを分けて確認してください。

5. テスト用の変更を戻す

   元のルール、変更内容、結果を記録し、一時的に追加したREJECTルールや例外ルールを元に戻します。通常アクセスが必要なドメインに、テスト用のREJECTを残さないでください。

たとえば、利用許可のあるテスト用ドメインにREJECTを設定すると、新しいリクエストは拒否されるはずです。ただし、ページに表示される古い文章はキャッシュ由来の場合があり、別ドメインから読み込まれた画像が表示され続けることもあります。これは検証方法の説明であり、本サイトでの実測データではありません。ページ全体がすぐ真っ白になるかではなく、該当リクエストのログを基準に判断してください。

6. ルールによる振り分けでよくある質問

設定を整理するときは、まず少数のルールでテスト結果を説明できる状態にしてから、対象範囲を段階的に広げます。ルールを追加するたびに、何に一致するか、それより前に一致する条件があるか、一致後にどのポリシーを使うかを確認してください。この3点が明確なら、FINALは最後に置く明示的な選択肢となり、前のルールの誤りを隠すための継ぎ当てにはなりません。