Shadowrocket カスタムルールの書き方｜上から順に評価するルール、FINAL のフォールバック、PROXY / DIRECT / REJECT

1. ルールの優先順位：精度ではなく順序で決まる

Shadowrocket は設定内の順序に従ってルールを確認します。接続がいずれかのルールに一致すると、そのルールで指定されたポリシーが適用され、それ以降の「より具体的な」ルールは確認されません。ドメインルールが IP ルールより優先されるわけではなく、単一ドメインのルールが自動的にサフィックスルールより前に配置されるわけでもありません。例外が必要な場合は、ルールを作成する際に例外を前に置いてください。

login.example.com は DIRECT、example.com とそのほかのサブドメインは PROXY にしたい場合は、次の順に並べます。先頭の2行を入れ替えると、ログイン用ドメインへの接続は先に DOMAIN-SUFFIX に一致し、後ろにある DOMAIN ではすでに決まった判定を変更できません。

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

2. PROXY、DIRECT、REJECT：接続の処理方法を決める

ルールの前半は「何に一致するか」を指定し、最後のポリシーは「どう処理するか」を決めます。PROXY はプロキシ経由で処理する指定です。実際の接続先は、選択中のサーバーや設定内のポリシー構成によって異なります。DIRECT はプロキシを経由せず対象へ直接接続し、REJECT は一致した接続を拒否します。これらは Shadowsocks、VMess、VLESS、Trojan などのプロトコル名でも、接続品質の等級でもありません。

DIRECT でも接続が必ず成功するとは限りません。対象側でアクセスが拒否される場合や、ローカルネットワークに問題がある場合、DNS が誤ったアドレスを返す場合は、直接接続でも失敗します。同様に、PROXY に一致したことはルールがプロキシを選択したことを示すだけで、接続先サービスに必ずアクセスできるという意味ではありません。トラブル時は「ルールが経路を正しく選んだか」と「その経路が実際に利用できるか」を分けて確認してください。

3. Global Routing：Config でカスタムルールを確認

まず Home → Global Routing で現在のモードを確認し、ルールの効果を判断します。Config では現在の設定にあるルールに従って通信が振り分けられます。Proxy と Direct は経路を比較するために使えますが、特定のカスタムルールに一致したことの確認にはなりません。Scene はシーンの選択に関わります。最初のトラブルシューティングではシーン切り替えを同時に行わず、テスト条件が変わらないようにしてください。

比較が終わったら Config に戻してください。Settings → On Demand ではオンデマンド接続の条件を管理します。ルールの並べ替えは行わず、有効にしても FINAL より後ろにあるルールが再び適用されることはありません。テスト中はネットワークと接続の状態を一定に保ち、自動接続、ネットワークの切り替え、ルール編集を同時に行わないようにしてください。

4. よく使うルール構文：ドメイン、アドレス範囲、FINAL

一般的なルールでは、フィールドを半角カンマで区切ります。全角カンマは使いません。ドメインの照合フィールドにはドメイン名だけを指定し、https://、ポート番号、URL パスは含めません。たとえば https://api.example.com:443/v1 にアクセスする場合、DOMAIN に指定する対象は api.example.com で、URL 全体ではありません。443 はこの例の接続ポートであり、ドメイン名のフィールドには含まれません。

IP-CIDR の後ろに付ける no-resolve は、このルールとの照合のためにドメイン名の解決を能動的に行わないことを示します。そのため、「すべてのドメインを先に名前解決してから、このアドレス範囲と照合する」という意味ではありません。LAN 内の機器をテストする場合は、IP アドレスでの直接アクセスと機器のドメイン名を使ったアクセスを個別に確認し、DNS がパブリック IP とプライベート IP のどちらを返すかにも注意してください。

GEOIP は IP の帰属情報に基づくため、Web サイトの言語、ドメインのサフィックス、運営主体の所在地と同じ結果になるとは限りません。特定のサービスに固定の経路を使う必要がある場合は、GEOIP による間接的な判定に頼るより、明示的なドメインルールを指定して GEOIP より前に置くほうが確認しやすくなります。

• 文字の確認：キーワード、半角カンマ、ポリシーフィールドが正しく記載されていることを確認し、コピー時に全角記号が混入しないようにします。
• 範囲の確認：DOMAIN-SUFFIX,example.com は notexample.com には一致せず、URL 内の特定ディレクトリを示すものでもありません。
• アドレスの確認：192.168.0.0/16 はプライベートアドレス範囲の例であり、現在の LAN が必ずこの範囲を使うという意味ではありません。
• フォールバックの確認：通常は有効な FINAL を1件残し、有効なルールリストの最後に配置します。

5. おすすめの並べ方：具体的な例外を先に、FINAL を最後に

次は、順序を理解するためのルール例です。特定のログイン用ドメインを直接接続にし、明示したドメインを拒否した後、ドメインサフィックス全体を処理します。続いてプライベートアドレス範囲と地域ルールを処理し、最後に FINAL に渡します。これは並べ方の例であり、すべてのネットワークにそのまま適用できる共通設定ではありません。実際の対象に合わせて不要なルールを削除してください。

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

この順序は「具体的な例外を優先する」考え方を示していますが、ドメインルールを常にアドレス範囲より先に置くべきという意味ではありません。すべての LAN 内の対象を直接接続にする場合は、名前解決で LAN 内のアドレスになった対象がドメインルールによって PROXY に送られる可能性も確認し、DNS の動作に合わせて調整してください。ルールの順序は実際の目的に合わせるもので、ひとつのテンプレートを固定の優先順位として扱わないでください。

1. login.example.com にアクセス：最初の DOMAIN に一致して DIRECT が適用されるため、後続のサフィックスルールは評価されません。
2. blocked.example.com にアクセス：2番目のルールに一致して REJECT が適用されます。このルールをサフィックスルールより下に移すと、結果が変わります。
3. api.example.com にアクセス：最初の2件には一致せず、その後 DOMAIN-SUFFIX に一致して PROXY が適用されます。
4. 192.168.1.1 に直接アクセス：前のドメインルールに一致しない場合、該当するプライベートアドレス範囲のルールに一致し、直接接続されます。
5. その他の対象にアクセス：GEOIP を確認し、そこにも一致しない場合は FINAL に進みます。

FINAL,PROXY と FINAL,DIRECT は、どちらも有効なフォールバック設定です。違いは、未知の対象がデフォルトでどの経路を使うかです。FINAL は接続失敗後の再試行機能ではありません。前のルールで PROXY に一致してプロキシ接続に失敗しても、そのルールを飛ばして FINAL が実行されることはありません。失敗時の経路を変えるには、該当するルールを変更するか、選択中の接続を修正してください。

6. 編集と確認：一度に変更する条件は1つだけ

以下の手順では iPhone / iPad の画面上の用語を使用します。ルールは Config で有効になっている設定ファイルに含まれます。Home のサーバーリストが変わっても、ルールファイルが更新されたとは限りません。編集前に元の設定を保存し、特に自分で編集したローカルファイルと、リモート更新で上書きされるファイルを区別してください。

1. モードを確認

   Home → Global Routing を開き、Config を選択します。現在選択中のサーバーを記録し、テスト中は接続先を同時に変更しないでください。

2. ファイルを確認

   Config を開き、現在有効な設定ファイルを確認します。元の内容を保存してから編集してください。有効になっていない別のファイルを編集しても、現在の接続の振り分けは変わりません。

3. 順序を調整

   設定内のルールから [Rule] を探し、具体的な例外を対象範囲をカバーするルールより前に置き、FINAL が最後にあることを確認します。ルール行だけをコピーする場合、既存の [Rule] に区間見出しを重複して挿入しないでください。

4. 保存して再接続

   保存後、変更した設定が有効になっていることを確認し、必要に応じて再接続します。編集前に開いたテストページを閉じるか、既存の接続を終了してから新しいリクエストを送信し、編集前に確立した接続が再利用されないようにしてください。

5. 結果を確認

   接続履歴またはログで、対象ドメイン、対象 IP、実際に適用されたポリシーを確認します。テスト対象、一致したルール、アクセス時の状況を記録してから、次の変更を判断してください。

3種類の対象で最小限のテストセットを作成できます。DIRECT になる対象、PROXY になる対象、個別ルールがなく FINAL に進む対象をそれぞれ1つずつ用意します。REJECT を使う場合は、明示的にブロックする対象を1つ追加します。Web ページが開くかどうかだけでルールの正しさを判断しないでください。DIRECT と PROXY のどちらでも接続に成功する場合があり、ページがキャッシュを再利用していることもあります。

7. ルールが適用されないとき：症状から原因を確認

ルールの問題は、ルール不足ではなくテスト条件が一定でないことが原因の場合があります。まず、繰り返しテストできる対象を1つ決め、以下の症状に沿って確認してください。より詳しいネットワークのトラブルシューティングはトラブル対処をご覧ください。

最後に、Config を使っていること、正しいファイルが有効になっていること、例外が範囲指定ルールより前にあることの3点を確認します。すべて確認したら、新しい接続で最終的なポリシーを調べてください。ルールが決めるのは接続の処理経路です。利用中のサービスが使えるかどうかの確認に代わるものではなく、無効になった接続設定を自動で修復することもありません。