Shadowrocketのカスタムルールの優先順位｜上から順に評価する仕組みとFINALの設定方法

1. ルールの優先順位：重要なのは行の順序

設定に基づいて通信を振り分ける場合、[Rule]セクションは上から順に評価されます。ルールに一致すると、そのルールで指定されたポリシーが適用され、後続の「より詳細なルール」は評価されません。そのため、ルールの種類だけで行の順序に代わる共通の優先順位が決まるわけではありません。DOMAINをDOMAIN-SUFFIXの後に書いても、自動的に優先度が上がることはありません。

たとえば、api.example.comはDIRECTにし、example.comのほかのサブドメインはプロキシ経由にしたい場合は、個別ドメインの例外を先に記述します。以下のドメインは構文を説明するための例であり、サービスの提供先や利用可能性を示すものではありません。

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

• api.example.comへのリクエスト：1行目に一致し、DIRECTが適用されます。
• www.example.comへのリクエスト：1行目には一致せず、2行目に一致してPROXYが適用されます。
• 前のルールに一致しないその他のリクエスト：FINAL,DIRECTで処理されます。

最初の2つのルールを入れ替えると、api.example.comも広いドメインサフィックスの条件に一致し、先にPROXYが適用されます。「DIRECTと書いたのにプロキシ経由になる」場合は、末尾に同じルールを追加するのではなく、対象ルールより前に一致するルールがないか確認してください。

2. Global Routingを確認してからConfigを編集

設定ファイルにルールが書かれていても、現在の接続が必ずそのルールで振り分けられるとは限りません。Home → Global Routingを開いて現在のモードを確認し、Configで使用中のファイルを確認します。以下では、今回の検証に関係する3つのモードを比較します。Sceneはシーンごとの設定に使います。この記事のルールを調べる際は、シーン切り替えによる変数を減らすため、まずConfigを明示的に選択してください。

1. 設定をバックアップ

   Configを開き、まず現在のファイルを複製するか、バックアップをエクスポートして、元に戻せる状態にします。追加した数行だけを保存するのではなく、元のルール全体を残してください。

2. 編集画面を開く

   Configで対象の設定ファイルの編集画面を開き、[Rule]セクションを探します。編集対象が設定ファイルの本文であり、Homeのサーバー接続パラメータではないことを確認してください。

3. ルールを並べ替える

   個別ドメインの例外を、該当する広範なルールより前に置きます。続けてIP範囲とGEOIPの項目を確認し、末尾にFINALを残します。保存後、そのファイルが選択されていることを確かめてください。

4. モードを確認

   Home → Global Routing → Configに戻り、使用するサーバーが正しく選択されていることを確認してから接続を開始します。システムのVPN構成への許可が必要な場合は、画面の案内に従ってください。

5. 新しいリクエストを送信

   対象のページを閉じてから再度アクセスします。必要に応じて接続をやり直し、新しいルールを以前の接続で判断しないようにしてください。次の変更に進む前に、対象ドメイン、時刻、一致したルールを記録します。

3. DOMAIN-SUFFIX、IP-CIDR、GEOIPの並べ方

どの対象に一致するルールかと、何行目に記述するかは別の問題です。ドメインルールはホスト名、IPルールは宛先アドレスを確認し、GEOIPはIPアドレスのデータベース分類に基づいて判定します。ドメインのリクエストは複数のアドレスに解決されることがあり、同じドメインでもネットワーク環境によって異なるアドレスに解決されます。一度IPルールに一致したからといって、そのドメインに恒久的に当てはまる性質だと考えないでください。

DOMAIN-SUFFIXにはexample.comを記述します。https://を含む完全なURLや、example.com/pathではありません。パスはURLの別の部分です。ドメイン欄に貼り付けても、「このページだけをプロキシ経由にする」という指定にはなりません。また、Webサイトで一般的なHTTPSのポート443を使っているからといって、ルールにポート条件が自動的に追加されるわけではありません。

no-resolveは、このIPルールとの照合のために追加のドメイン名前解決を行わない指定です。設定全体のDNSを無効にするものでも、このネットワーク範囲に今後一致しなくなるという意味でもありません。判定に使える宛先IPがすでにある場合は、引き続きアドレス範囲で判定できます。ドメインしか分からず、このルールのための名前解決も行いたくない場合は、解決を省略するとリクエストが後続のルールに進む可能性があることを理解しておきましょう。

• 業務上必要な個別例外を先に記述し、その後に該当するドメインサフィックスを置きます。広範なルールが例外に先に一致するのを防げます。
• 宛先アドレスによる振り分けが必要な場合に限り、IPネットワーク範囲を追加します。/32は単一のIPv4アドレス、/24は256個のアドレスを対象にします。
• 対象範囲の広いGEOIPは、個別例外の後に置くのが一般的です。ただし、これは保守しやすい並べ方であり、クライアントがルールの種類に強制する優先順位ではありません。
• 接続先にIPアドレスを直接指定し、利用できるドメイン情報がない場合、DOMAIN-SUFFIXだけで一致させることはできません。

4. PROXY、DIRECT、REJECT、FINALの設定例

ルール末尾のポリシーによって、一致した後の動作が決まります。PROXYはプロキシ経由で処理し、DIRECTは宛先に直接接続し、REJECTはリクエストを拒否します。これらはサーバーのプロトコルとは別の設定です。既存サーバーのプロトコルをShadowsocksからTrojanに変更しても、ルールを上から順に評価する基本的な仕組みは変わりません。

以下は解説用の[Rule]セクションであり、既存の設定すべてを置き換えられる完全な設定ファイルではありません。利用可能なサーバーをすでにお持ちであることを前提としています。例示ドメインはサービスを提供しません。実際の設定に統合する前に、使用中のポリシー名、ほかのルール、必要なネットワーク範囲を確認してください。

[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

• api.example.comはexample.comの一部ですが、先に1行目の例外に一致するため、直接接続されます。
• blocked.example.comはサフィックスルールより前にREJECTに一致します。アクセスできないのは、このポリシーで想定される動作です。
• 192.168.0.0/16が対象とするのは、このプライベートアドレス範囲だけです。すべてのローカルネットワークを意味するわけではありません。ほかの範囲は必要に応じて個別に判断してください。
• GEOIP,CN,DIRECTは宛先IPのデータベース分類に依存します。中国語のWebサイトすべてに一致するとは限らず、同じドメインが毎回同じ分類になるとも限りません。
• FINAL,PROXYが処理するのは、それまでのルールに一致しなかったリクエストだけです。すでにDIRECTに一致したリクエストをプロキシに切り替えることはありません。

FINALをルールの途中に置くと、それ以降の未分類リクエストがそこで処理され、後続の項目が意図どおりに機能しなくなります。設定を管理するときは、明確なフォールバックを末尾に1つだけ残してください。既存設定に2つ目のFINALが残っていると、内容を誤解する原因になります。

5. 一度に一項目ずつ試してルールが効かない原因を特定

確認は「現在のファイル → 現在のモード → リクエスト先 → 実際に一致したルール → 接続結果」の順に行います。Webページが開けても分かるのはリクエストが成功したことだけで、どの経路を通ったかまでは判断できません。ページが開けない原因も、REJECT、接続先サービスの障害、プロキシ接続の問題などが考えられます。ルールの一致判定と接続の成否は分けて記録してください。

1. 基準状態を記録：同じネットワーク、同じ既存サーバー、同じ接続先を使い、変更前の状態を記録します。サーバーとルールを同時に変更しないでください。
2. 変更は1行だけ：たとえばDOMAINとDOMAIN-SUFFIXの順序だけを入れ替えます。保存してその設定が選択されていることを確かめた後、リクエストを再送します。
3. リクエスト情報を確認：アプリの接続記録やログで、今回の宛先ホスト、宛先IP、確認できるポリシー情報を探します。IPしか表示されない場合は、ドメイン情報が取得できているかを先に確認してください。
4. ページ全体の構成を確認：ページ本文、画像、ログイン用APIはそれぞれ異なるドメインを使う場合があります。メインサイトにルールを1つ追加しただけでは、ページが必要とする通信すべてをカバーできないことがあります。
5. 変更前と比較：直前の変更を元に戻し、再度アクセスします。変更を繰り返しても結果が変わらない場合は、キャッシュ、以前の接続、接続先サービスの状態を引き続き確認してください。

サブスクリプションの更新と設定ファイルの編集も、分けて考える必要があります。Homeで既存のサーバーサブスクリプションを更新する操作は、主にサーバー項目を更新します。Configでリモート設定を更新すると、設定ファイルの本文が置き換わることがあります。どちらも「ルールの更新」と捉えてはいけません。リモート設定を変更する前にローカルコピーを保存し、更新後に例外ルールとFINALが残っているか確認してください。

6. ルールの順序とFINALに関するよくある質問