Shadowrocketのルール設定入門｜DOMAIN-SUFFIX・GEOIP・IP-CIDR・FINALの照合順序

1. まずGlobal Routingを確認してから、ルールの照合を調べる

ルールファイルが存在していても、そのファイルに基づくルーティングが適用中とは限りません。Homeでは接続と選択中のアウトバウンド、Configでは設定ファイル、Settingsではアプリの設定を管理します。確認を始める前にHome → Global Routingの現在の選択内容を控え、Configで使用中のファイルを確認してください。「ファイルを取得した」ことと「ファイルを有効にした」ことは別の操作です。

Settings → On Demandでは、条件に応じて接続を開始する動作を管理します。ルール一覧の優先順位を切り替える設定ではありません。システム上でVPN接続中と表示されても、トンネルが接続状態であることを示すだけです。個々のリクエストがプロキシを経由したかどうかは、ルーティング方法、照合されたルール、最終的なポリシーをあわせて確認してください。

2. ルールの1行を読む：タイプ、照合対象、ポリシー

一般的なルールでは、半角カンマで項目を区切ります。たとえばDOMAIN-SUFFIX,example.com,DIRECTでは、1つ目が照合方法、2つ目が照合対象、3つ目が照合後の処理を指定します。設定ファイルの通常ルールは[Rule]セクションに記述します。ファイル末尾に1行を追加するだけで済ませず、正しいセクションにあるか確認してください。

[Rule]
DOMAIN,login.example.com,DIRECT
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
FINAL,DIRECT

これは構文を示す例であり、あらゆる用途に使える完全な設定ではありません。192.0.2.0/24は文書用の例示ネットワークです。すべてのルールをDIRECTにしているのは、未定義のプロキシポリシーを使わずに、まず照合の動作を確認するためです。既存の設定をこの例で置き換えないでください。

• DIRECTは直接接続を意味しますが、リクエストの成功を保証するものではありません。接続先に到達できない場合もあります。
• ルールでPROXYや独自のポリシー名を使う場合は、対応するポリシーまたはポリシーグループが現在の設定に存在し、利用可能であることを確認してください。名前は設定ファイルの記述と一致させます。任意の文字列がアウトバウンドとして使えるわけではありません。
• FINALにはドメインやネットワークの項目がないため、通常はFINAL,DIRECTのように記述します。3項目の形式にはしないでください。
• 区切りには半角の英語カンマを使います。ドメイン欄にhttps://、ポート、パス、クエリパラメーターは記述しません。

たとえば、ブラウザーでhttps://docs.example.com:443/helpにアクセスする場合、ドメインルールが照合するのはdocs.example.comです。443は接続ポート、/helpはURLのパスであり、どちらもDOMAIN-SUFFIXの照合値ではありません。プロトコルの接続パラメーターとルーティングルールは別の階層にあるため、ドメイン欄にプロトコル名を記述しないでください。

3. DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORDの違い

3つのキーワードはいずれもドメインを照合しますが、対象範囲が異なります。特定のホストだけを例外にする場合はDOMAIN、ドメインとそのサブドメイン全体を対象にする場合はDOMAIN-SUFFIXを検討します。DOMAIN-KEYWORDは対象が広いため、同じ文字列を含む別のドメインまで照合されないか確認してください。

DOMAIN-SUFFIXはドメイン階層の境界に基づいて照合し、任意の文字列の末尾とは照合しません。通常はexample.comと記述し、*.を付ける必要はありません。対象がapi.example.comだけなら、DOMAINを使うことで同じドメインの他のホストまで含めずに済みます。

4. IP-CIDR、GEOIP、DNSの関係

IP-CIDRは、接続先のIPアドレスが指定したネットワーク範囲に含まれるかを照合します。ドメインの文字列を照合するものではありません。192.0.2.0/24はIPv4ネットワーク、192.0.2.18/32は単一のIPv4アドレスを表します。プレフィックス長の数字はポートでも優先順位でもありません。数字が大きいほど通常はネットワーク範囲が狭くなりますが、ルール一覧の上位に自動で移動するわけではありません。

IP-CIDR,192.0.2.18/32,DIRECT,no-resolve
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,DIRECT

GEOIPは、接続先IPアドレスのデータベース上の割り当て情報を使います。たとえばGEOIP,CN,DIRECTは、データベースでCNに割り当てられたアドレスを対象にします。中国語のWebページや、末尾が.cnのドメインを照合するものではありません。コンテンツ配信の仕組み、IPアドレスの変化、データベースの情報により、サイト名からの推測と実際の結果が異なることがあります。

• リクエストにドメイン名が含まれる場合：IP系ルールの照合にアドレスの解決が必要なことがあり、その場合はDNSの結果が後続の判定に影響します。
• no-resolveを使う場合：照合のためにドメイン名を自動で名前解決しない指定です。DNSを全体的に無効にする設定ではありません。
• リクエストがIPアドレスの場合：ネットワーク範囲やアドレスの割り当てを直接確認できますが、元のドメイン名を必ず特定できるわけではありません。
• テスト中に接続先が変わる場合：同じドメイン名が複数のアドレスに解決されることがあり、IPv4とIPv6で実際の経路が異なる場合もあります。今回の接続先アドレスを確認してください。

そのため、「ドメイン名から特定の地域だと思える」ことと「GEOIPに一致する」ことを同一視できません。まず実際の接続先を確認し、その後で名前解決の結果とデータベース上の判定を確認してください。判定に使えるアドレスが得られていない場合、no-resolve付きのIP系ルールには一致せず、後続のルールが引き続き確認されることがあります。

5. 上から順に照合：個別の例外を先に、FINALを最後に

通常のルールは設定ファイルの記述順に照合され、一致した時点で対応するポリシーが適用されます。より「細かい」ルールを探すために後続のルールへ進むことはありません。DOMAINがDOMAIN-SUFFIXより自動的に優先されるわけでも、単一アドレスのルールが広いネットワーク範囲のルールより自動的に優先されるわけでもありません。例外を優先するには、対象範囲の広いルールより前に記述してください。

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

この例は、現在の設定に利用可能なPROXYポリシーがあることを前提としています。login.example.comにアクセスすると、最初のルールに一致して直接接続します。img.example.comでは最初のルールに一致せず、2つ目のルールに一致してPROXYに渡されます。2つ目のルールを1つ目より前に移動すると、ログイン用ドメインも先にサフィックスルールに一致し、後ろにある個別の例外が機能しなくなります。

1. まず、ログイン用の単一ドメインなど、明確なホスト単位の例外を記述します。
2. 次に、ドメインサフィックス、キーワード、その他必要なルールを記述し、対象範囲が重複しないか確認します。
3. IPアドレス系のルールを配置する際は、照合のための名前解決を許可するか、後続のルールを覆わないか確認します。
4. 最後にFINALを置き、先行するルールに一致しない場合の最終処理として使います。

FINALは、接続に失敗したときの予備経路ではありません。あるルールに一致してPROXYが適用された後、接続がタイムアウトしてもFINALに進むことはありません。接続失敗後の切り替え動作は、使用するポリシーグループとその設定によって決まります。FINALの後ろに別のルールを追加しても実現できません。

6. バックアップから検証まで：ルールを1つずつ変更する

以下の手順は、自分の接続設定をすでに持っていることを前提としています。変更前に元のファイルを保存し、まず対象が明確なドメインルールを1つ検証してから、複数のルールを整理してください。リモート設定の更新によってローカルの変更が上書きされる場合があります。自分で編集したコピーと、後で再取得するファイルを区別してください。

1. 元の設定を保存する

   Configを開き、現在使用中の設定ファイルを確認して、復元できるコピーを保存します。変更前のGlobal Routingの選択内容と対象ルールの順序も記録し、ルールセクション全体を先に削除しないでください。

2. ルールセクションを編集する

   Configで編集するファイルを開き、[Rule]を探して、自分でテストするドメインを対象にしたDOMAINルールを1つ追加します。保存後、変更したファイルが現在有効になっていることを確認してください。編集画面の表示方法はアプリ内の案内に従ってください。

3. ルーティングを確認する

   Home → Global Routing → Configに戻ります。接続が有効で、参照先のプロキシポリシーに利用可能なアウトバウンドがあることを確認してください。Sceneを使っている場合は、設定内容を控え、Sceneの切り替えをルールの変更と誤認しないようにします。

4. 新しいリクエストを送る

   対象のアプリから新しい接続を開始し、接続ログで接続先ドメイン、アドレス、一致したルール、ポリシーを確認します。既存の長時間接続は以前の経路を使い続けることがあります。ファイルを保存しただけでは、既存の接続がすぐに再確立されるとは限りません。

5. 結果を照合して元に戻す

   実際の結果を予想と項目ごとに照らし合わせ、まずルールの照合結果、次に接続の成否を確認します。テスト後は一時的なルールを削除するか元のファイルに戻し、Global Routingも元の選択内容に戻してください。

Homeの遅延テストだけを、ルールが正しい証拠にしないでください。遅延テストでは選択中のアウトバウンドからテスト先に接続しますが、ブラウザーのリクエストでは別のドメイン、異なるアドレスやポートが使われることがあります。「接続先ドメイン、接続先ポート、一致したルール、最終ポリシー、エラーの内容」の5項目を記録すると、すべての設定を何度も切り替えるより問題を再現しやすくなります。

7. 接続エラーとルールの誤りを分けて調べる

以下はネットワーク診断でよく見かける英語のエラーメッセージです。実際の画面では、より詳しい情報が表示される場合があります。毎回同じ表現になるとは限りません。まずリクエストがどのルールに一致したかを確認し、そのルールで選ばれた経路に沿って調べてください。タイムアウトが発生したからといって、すべてのリクエストを同じポリシーに変更しないでください。

ファイルを正常に保存または読み込めない場合は、セクション名、半角カンマ、ポリシー名、項目数を確認します。ファイルは使えるもののルールの照合先が違う場合は、記述順と対象範囲を確認してください。ルールに正しく一致しているのにアクセスできない場合は、接続経路を調べます。この3つでは対処の方向が異なります。