· ルール · 約10分

Shadowrocketのルール設定入門：DOMAIN-SUFFIX・GEOIP・IP-CIDR・FINALのマッチ範囲

DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORD、GEOIP、IP-CIDR、FINALのマッチ対象と、ルールが上から順に評価される仕組みを解説します。

この記事の概要

Shadowrocketのルールは、まずマッチ対象を確認し、次に並び順、最後にマッチ後のポリシーを確認します。自分で用意したサービス設定やサブスクリプションを使い、Configを編集する方向けに、ドメインルールとIPルールの違い、最小限のルールの書き方、「ルールが反映されない」場合に接続ログから原因を特定する方法を解説します。当サイトではサーバーやサブスクリプションを提供・販売・推奨していません。

ルールの書式：タイプ・マッチ条件・ポリシー

一般的なルールは英語のカンマで区切り、DOMAIN-SUFFIX,example.com,DIRECTのように記述します。1番目の項目で判定対象、2番目でマッチ条件、3番目でマッチ後の接続処理を指定します。ルールはWebページのURLフィルターではありません。ドメイン欄にhttps://、パス、クエリパラメーター、ポートは記入しません。

[Rule]
DOMAIN,login.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,tracker,REJECT
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

これは構文を説明するための例であり、あらゆるネットワークに使える完全な設定ではありません。[Rule]はルールセクションです。既存の設定を編集する場合は、そのセクションを編集し、同じセクションを重複して追加しないでください。example.comと192.0.2.0/24は説明用の値であり、実際のサービスへの接続可否を確認するためのものではありません。

FINALにはマッチ条件がないため、FINAL,PROXYと記述します。FINAL,example.com,PROXYのように3項目にすることはできません。例にあるno-resolveはIPルールの追加パラメーターであり、4つ目のポリシーではありません。

DOMAIN系ルール：完全一致・サフィックス・部分一致

ドメインルールは、「このホスト名をどのポリシーで処理するか」を指定します。3種類の違いはマッチする範囲であり、優先順位ではありません。以下では同じドメインを例にします。「マッチ」は条件に合致することを示しますが、その行が実際に適用されるかどうかは、先にマッチするルールがあるかによって変わります。

ルール例マッチするマッチしない
DOMAIN,example.com,DIRECTexample.comwww.example.com
DOMAIN-SUFFIX,example.com,DIRECTexample.com、www.example.comnotexample.com、example.com.other.test
DOMAIN-KEYWORD,example,DIRECTexample.com、notexample.comドメインにexampleが含まれない宛先

DOMAIN-SUFFIXはドメインのラベル境界で判定します。「末尾の文字が同じならマッチする」という意味ではありません。通常はexample.comと記述し、*.を付ける必要はありません。api.example.comだけを対象にし、ほかのサブドメインには適用したくない場合は、DOMAINを使うと対象範囲を確認しやすくなります。

アプリはメインサイト、ログイン、画像、APIなど、複数のドメインに接続することがあります。メインサイトにルールを1つ追加しただけで、ほかのリクエストにもマッチすると判断することはできません。キーワードの範囲をむやみに広げず、接続ログで個別に確認してください。

GEOIPとIP-CIDR：IPアドレスの地域判定と範囲指定

GEOIP,CN,DIRECTは、使用する地理データベースに基づいて宛先IPの地域を判定します。Webページの言語、ドメインの末尾、ユーザーの所在地、サービス事業者の登録地による判定ではありません。ドメインが異なる地域のIPアドレスに解決されることもあるため、「中国語のサイトなら必ずCNにマッチする」という前提で原因を調べるのは適切ではありません。

IP-CIDRは、IPv4アドレスとプレフィックス長で範囲を指定します。たとえば192.0.2.0/24は192.0.2.0から192.0.2.255までを含み、192.0.2.8/32は1つのアドレスだけにマッチします。IPv6の範囲には対応するIP-CIDR6を使い、IPv6アドレスをIPv4の例に入力しないでください。

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

上の例では、単一アドレスの例外を広いアドレス範囲より前に置いています。宛先が192.0.2.8なら1行目にマッチするため、2行目で結果は変わりません。行を入れ替えると、範囲の広い/24が先にこのアドレスを処理します。

マッチ順：具体的な例外を先に、FINALを最後に

ルールは上から順に評価され、最初にマッチしたルールがその接続のポリシーを決めます。下にある「より具体的に見える」ルールで上書きされることはありません。DOMAINが自動的にDOMAIN-SUFFIXより先になるわけではなく、IP-CIDRも範囲が狭いだけで優先されるわけではありません。

接続を開始宛先情報を取得順にマッチ判定ポリシーを決定接続を実行 
DOMAIN,login.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT

この順序では、login.example.comはDIRECT、img.example.comはPROXYで処理され、先頭の2行に該当しない宛先にはFINALが適用されます。サフィックスルールを1行目に置くと、ログイン用ドメインも先にマッチし、完全一致の例外が機能しなくなります。

まず対象が明確な例外を少数記述し、次に範囲の広いドメインやアドレスを置き、最後に意図を説明できるFINALを残す方法がおすすめです。これは管理しやすい並べ方の一例であり、すべての設定でルールタイプごとに機械的に分類する必要はありません。

Configでルールを編集・検証する

テストの前に元の設定を保存し、現在有効な設定と編集対象のファイルが同じであることを確認してください。サブスクリプション内のサーバー項目の更新と、Config内のルールファイルの編集は別の作業です。Homeで既存のサブスクリプションを更新しても、現在有効なルールを確認したことにはなりません。

  1. 元の設定を保存

    Configを開き、復元できる設定のコピーを保存してから、対象設定の編集画面を開きます。[Rule]を探し、編集対象がルールセクションであることを確認してください。

  2. ルールを1つ追加

    まず範囲が明確なDOMAINルールを1つ追加し、そのルールを上書きする可能性のあるサフィックスルールやキーワードルールより前に置きます。変更する条件は一度に1つだけにし、保存してください。

  3. ルール設定を有効化

    Configで保存したばかりの設定が選択されていることを確認し、Home → Global Routing → Configに進みます。ProxyとDirectは全体の接続方式であり、ここで個別のルールによる振り分けを検証する用途には使えません。

  4. 新しい接続を開始

    対象ページを開き直すか、アプリからリクエストを再送し、接続ログで宛先、マッチしたルール、ポリシーを確認します。既存の長時間接続が再利用される場合があるため、変更前から開いているページだけで判断しないでください。

  5. マッチ結果を確認

    ログで別のルールにマッチしていた場合は、まずそのルールの位置を確認します。想定したルールにマッチしているのに接続できない場合は、接続先への通信を調べてください。ほかの条件を追加するのは、検証が終わってからにします。

Global RoutingのSceneは、シーン設定も含めて現在適用されているポリシーを確認してください。最初の検証ではConfigに明示的に切り替えると、確認対象を絞れます。Settings → On Demandは、条件に応じてVPN接続を開始する動作を設定する項目です。DOMAIN-SUFFIXのマッチ範囲は変わらず、有効な設定の選択に代わるものでもありません。

検証では、ページが表示されるかどうかだけで判断せず、新しい接続のログを確認してください。キャッシュによって失敗が成功のように見えることがあり、バックエンドAPIへの接続に失敗しても、メインページだけは表示されてログインできない場合があります。

ルールが反映されない場合と接続失敗は分けて調べる

「どのルールにマッチしたか」と「マッチ後に接続できたか」は別の問題です。以下はネットワーク接続で表示されることがあるエラーの原文例で、ルール構文のエラーではありません。まずマッチしたルールとポリシーを確認してから、接続エラーを調べてください。

エラー：Connection refused

原因と対処：接続先のエンドポイントがリクエストを拒否しています。アドレス、ポート、待ち受けサービスが一致しない場合などに発生します。まず接続ログで実際の接続先を確認し、自分の設定でポートとサービスの状態を確認してください。DOMAIN-SUFFIXを変更しても、ポートの問題は解決しません。

エラー：Operation timed out

原因と対処：制限時間内に処理が完了しませんでした。ネットワーク経路、宛先、プロキシ接続などが関係している可能性があります。まずマッチしたポリシーを確認し、宛先への接続と既存のプロキシ接続をそれぞれ調べてください。このエラーだけでGEOIPデータやルールの順序に問題があるとは判断できません。

DOMAINを設定したのに、サブドメインに適用されないのはなぜですか？

DOMAINは、指定したドメイン名そのものにだけマッチします。親ドメインとサブドメインの両方を対象にするには、DOMAIN-SUFFIX,example.com,DIRECTを使用し、上のルールが先にマッチしていないことを確認してください。

FINALを先頭に置くとどうなりますか？

その行まで到達したリクエストはFINALで処理されるため、後続のルールが想定どおりに機能しなくなります。フォールバックの行をルールセクションの最後に移動し、新しい接続でマッチログを確認してください。

no-resolve付きのIP-CIDRがマッチしないのはなぜですか？

まず今回のリクエストに利用可能な宛先IPがあるかを確認し、次にそのアドレスがプレフィックスの範囲内かを調べてください。ドメイン名しかなく、利用できるIPがない場合、このルールはマッチのために名前解決を行いません。マッチしないからといって、すぐにプレフィックスの構文エラーと判断しないでください。

REJECTにマッチしたのに、ページに同じ種類のコンテンツが表示されるのはなぜですか？

REJECTが拒否するのはマッチした接続であり、ページ内のコンテンツを分類するわけではありません。別のドメインから読み込まれていないか、ローカルキャッシュに残っていないかを確認してください。同じドメインが必要なAPIも提供している場合、拒否範囲を広げると正常な機能に影響する可能性があります。

最後に、次の順で確認してください。有効なConfig、Global Routingのモード、リクエストの宛先、最初にマッチしたルール、最終ポリシー、実際の接続結果。キーワードについてはルールキーワード用語集を、名前解決の動作についてはDNS設定の説明を参照し、名前解決の問題とルールの範囲を混同しないようにしてください。

App Storeで正規版を確認