Shadowrocket カスタムルールの設定：上から順に判定する仕組みと FINALの役割

1. Configを確認：ルール一覧が通信を振り分ける条件

カスタムルールは接続のオン・オフを切り替えるものではなく、接続に必要なサーバー情報を提供するものでもありません。作業前に、利用中のサービスプロバイダーからサブスクリプションまたは接続情報を入手し、接続自体が使えることを確認してください。本記事ではiPhone / iPadのHome、Config、Settingsの画面名を使って説明します。他のプラットフォームでは、対応するルーティングや設定画面で同じ項目を確認してください。

HomeでGlobal Routingを確認します。Configを使う場合、通信の振り分けを調べる際に基準となるのは、現在有効な設定ファイルのルールです。ProxyとDirectはグローバルルーティングのモードであり、個別ルール末尾のPROXY、DIRECTというポリシーとは別のものです。Sceneについても、現在のシーン設定を確認して判断してください。Configと同じ意味ではありません。

この流れは、設定に基づいて振り分けられるリクエストについて説明したものです。すべてのシステムリクエストが必ず同じ経路で処理されるという意味ではありません。確認する際は、明確な宛先ドメインと新しい接続を使ってください。ステータスバーにVPNマークが表示されているだけで、ルールが有効だと判断しないでください。

• Home：接続状態、選択中の接続、Global Routingの現在のモードを確認します。
• Config：実際に使用している設定ファイルを確認します。選択されていないファイルを編集しても、現在の通信振り分けには反映されません。
• Settings → On Demand：条件に応じた自動接続を設定します。DOMAIN-SUFFIXとFINALのどちらが先に照合されるかは決まりません。

2. ルールの構文：マッチ条件と実行ポリシーを分けて読む

一般的なルールは「タイプ、マッチ値、ポリシー」で構成され、各項目は半角カンマで区切ります。タイプは何を調べるか、マッチ値は対象範囲、ポリシーは一致した後の動作を示します。FINALにはマッチ値がないため、通常は2項目です。全角カンマを使ったり、ポリシー名の後ろに説明文を続けたりしないでください。

ドメインルールのマッチ値には、https://、パス、クエリパラメーター、ポート番号を含めません。たとえば、宛先URLがhttps://login.example.com:443/accountの場合、DOMAINの値はlogin.example.comです。IP-CIDRではURLではなく、アドレスとマスク長を指定します。GEOIPが判定するのはIPの分類であり、ウェブページの言語、ドメインの末尾、サービス運営者の所在地ではありません。

3. PROXY、DIRECT、REJECTで変わること

ポリシーはルールの末尾に指定します。一致したということは処理方法が選ばれたという意味で、宛先への接続が保証されるわけではありません。PROXYは選択した接続とリモートネットワークに依存し、DIRECTはローカルネットワークに依存します。REJECTは意図的に接続を拒否します。以下の2つの設定例はルールの仕組みを説明するもので、同時に読み込む完全な設定ではありません。

• PROXY：一致した接続をプロキシ経由で処理します。サーバーアドレスではなく、有効な接続を自動で作成するものでもありません。Homeで選択中の接続、または設定で指定されたポリシーの対象を確認してください。
• DIRECT：プロキシサーバーを経由せず、宛先に直接接続します。すべてのVPN処理を回避するという意味ではなく、現在のネットワークから必ずアクセスできるという保証でもありません。
• REJECT：一致した接続を拒否します。ルールが判定できる宛先情報に基づいて動作するもので、ウェブページのコンテンツフィルターではありません。同じHTTPS接続内の特定のページ要素だけを選んでブロックすることはできません。

同じドメインがログインと他のコンテンツの両方に使われている場合、広い範囲にREJECTを適用するとログインまでブロックすることがあります。まず実際に処理したい宛先を確認し、マッチ範囲を絞ってください。「ページの一部が表示されない」だけでルールが正しく動いていると判断せず、接続の失敗をすべてプロキシの問題と決めつけないようにしましょう。

4. マッチ順序：条件が具体的でも自動的に優先されない

ルール一覧は先頭から順に確認され、最初に一致したルールが今回のリクエストに適用されます。それ以降のルールは判定に使われません。DOMAINはDOMAIN-SUFFIXより対象が具体的ですが、その具体性によって行の順番が自動的に覆ることはありません。同様に、REJECTにも先行するDIRECTルールを飛び越える特別な優先順位はありません。

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

この順序では、login.example.comへのアクセスは最初の行に一致します。example.comのサブドメインだからです。2行目のほうが具体的でも、適用される機会はありません。ログイン用ドメインをPROXY、その他のサブドメインをDIRECTにするには、先頭2行を入れ替えます。

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

「具体的な条件を先に置く」のはルール整理に役立つ方法ですが、実際の原則は最初に一致したルールが優先されることです。たとえば、特定のIPにPROXYを適用する必要がある場合、そのIPをカバーする可能性のあるGEOIPの直接接続ルールより前に置きます。ドメインルールが必ずアドレスルールより優先される、あるいは特定のポリシーが他より強いと考えないでください。

5. FINALを最後に置く理由

FINALは特定のドメインやアドレスを照合せず、それまでのルールに一致しなかったリクエストを処理します。リストの途中に置くと、その位置で残りのルール判定が終わります。下に構文として正しいDOMAIN、IP-CIDR、GEOIPがあっても、FINALが処理したリクエストには適用されません。

[Rule]
DOMAIN,login.example.com,PROXY
DOMAIN-SUFFIX,ads.example.com,REJECT
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.168.50.0/24,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY

これはルールの順序を理解するための最小限の例であり、すべてのネットワークに適した既定の設定ではありません。example.comとそのサブドメインは説明用です。ローカルネットワークの範囲も、実際に必要な範囲に置き換えてください。既存の設定に[Rule]がある場合は、同じ名前のセクションを貼り付け直さず、そのセクション内でルールを整理します。

1. login.example.comは1行目のPROXYに一致し、後続のドメインサフィックスルールには進みません。
2. ads.example.comは2行目のREJECTに一致します。サブドメインもこのサフィックスの範囲に含まれます。
3. www.example.comは3行目のDIRECTに一致します。ただし、リクエストから照合可能な宛先ドメインを取得できることが前提です。
4. 宛先アドレス192.168.50.10は例示した/24ネットワークに含まれます。それまでのルールに一致しなければ、4行目で処理されます。
5. 残りのリクエストはGEOIPの判定に進み、そこにも一致しない場合にFINALで指定したPROXYが適用されます。

IP系のルールはドメイン解決を伴う場合があり、判定結果は実際の宛先IP、DNSの応答、GeoIPデータにも左右されます。IPアドレスを直接指定した接続では、DOMAINの照合に使えるドメイン情報がないことがあります。そのため、ドメイン名でのアクセスとIPアドレスへの直接アクセスを、まったく同じテストとして扱わないでください。

6. 保存と確認：設定が反映されていない場合と接続できない場合を切り分ける

編集前に、現在使えている設定のコピーを保存してください。確認時は、宛先または順序を一度に1つだけ変更し、変更前後の結果を記録します。DNS、ルーティングモード、ルール一覧を同時に変更すると、どの変更が影響したのか判断できなくなります。

1. 編集中のファイルを確認：Configを開き、現在使用中の設定を確認してから編集画面に進みます。リモート設定とローカルコピーは区別してください。
2. ルールセクションを確認：[Rule]内を編集し、半角カンマを使います。ポリシー名のスペルを確認し、FINALを末尾に移動してください。
3. 保存して適用：編集後に保存し、その設定が引き続き使用中であることを確認します。Homeに戻り、Global RoutingがConfigになっていることを確認してください。
4. 新しい接続を確立：保存後に再接続し、テストするページやアプリを開き直してください。既存の長時間接続を新しいルールの結果と混同しないためです。
5. 記録を確認：リクエストまたは接続の記録からテスト対象を探し、確認できる一致ルール、ポリシー、宛先アドレス情報を確認します。まず想定したルールに一致しているかを確認してから、接続エラーを調べてください。
6. 問題の範囲を絞る：PROXYに一致した後もタイムアウトする場合は、選択中の接続とサービスプロバイダーの状態を確認します。REJECTに一致して失敗した場合は、そのポリシーによる想定どおりの動作です。

サブスクリプションの更新と設定ファイルの更新も区別してください。接続用サブスクリプションの更新は通常、サービスプロバイダーが提供する接続情報を更新するもので、現在の[Rule]が書き換わったことを意味しません。リモート設定を更新すると、ファイルの内容が置き換わる場合があります。長期的に維持するカスタムルールをどの設定ファイルに置くか明確にし、更新後にも内容を確認してください。

7. ルールが反映されないときによくある質問