· ルール · 約10分

Shadowrocket ルールタイプを解説：DOMAIN-SUFFIX、GEOIP、IP-CIDR とFINALの書き方

DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORD、GEOIP、IP-CIDR、FINALの対象と書式、上から順に判定されるルールの仕組みを解説します。

この記事の概要

ShadowrocketのRuleは「最も詳細なもの」が自動で優先されるのではなく、Configに記載された順に判定されます。接続設定が済んでいて、通信の振り分けを調整したい方向けに、Global RoutingをConfigに設定し、ドメインルールとIPルールを区別して、最後にFINALを置く手順を解説します。読み終えると、動作を説明・検証できるルールを作成し、「ルールに一致しない」場合と「一致後に接続に失敗する」場合を切り分けられます。

まずルールが適用される条件を確認

まずHomeでGlobal Routingを確認してから、Configを編集します。Configを使用すると、現在有効な設定ファイルに基づいて通信が振り分けられます。ProxyとDirectは全体の通信処理を切り替える設定で、カスタムRuleの動作確認には使えません。Sceneは設定済みの条件に応じて動作するため、特定のConfigを常に使う設定とは異なります。切り分け中はConfigに固定し、Sceneの切り替わりが判断に影響しないようにしてください。

6種類
この記事で扱うRuleのタイプ（全タイプではありません）
3種類
ドメイン照合：DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORD
4ステップ
Global Routing：Proxy / Direct / Config / Scene
  1. Homeで利用可能な接続設定があることを確認し、接続スイッチをオンにします。システムVPN設定を初めて作成する際は、画面の案内に従って許可してください。
  2. Configを開き、現在有効なファイルを確認します。編集前にコピーを保存し、リモートファイルの更新内容とローカルの変更が混ざらないようにしてください。
  3. Homeに戻り、Global RoutingをConfigに設定します。変更を保存したら、画面の案内に従って再読み込みするか、接続を再確立してください。
  4. テストするアプリの既存の接続を終了してから、新しいリクエストを送信します。確立済みの長時間接続は、ルールを1行変更してもすぐには経路が切り替わらないことがあります。

Homeでは接続とサービス項目を管理し、Configには設定ファイル、Settingsには全般設定があります。Settings → On Demandでは、条件に応じて接続を開始するタイミングを設定します。ドメインを特定のRuleに割り当てる機能ではありません。「切断しても自動で再接続する」場合は、FINALを何度も変更するのではなく、ここを確認してください。

ルールに一致してから、ポリシーを実行

一般的なルールは、タイプ、照合内容、ポリシーを半角カンマで区切って記述します。たとえば DOMAIN,api.example.com,DIRECT は、ドメインが api.example.com と完全一致した場合にDIRECTを実行するという意味です。FINALには照合内容の項目がないため、FINAL,PROXY のように記述します。3項目にしないでください。

新しいリクエストを送信 宛先の情報を取得 ルールを順番に照合 一致したポリシーを実行 送信接続を確立

リクエストが先にあるルールに一致すると、後続にある「より詳細な」ルールは判定されません。たとえば DOMAIN-SUFFIX,example.com,PROXY が先で、DOMAIN,api.example.com,DIRECT が後にある場合、後者はこのドメインの例外として機能しません。例外ルールを広い範囲に一致するルールより前に移動してください。

3種類のドメインルール

ドメインルールが対象にするのはホスト名で、URL全体ではありません。照合フィールドに https://、パスの /login、クエリパラメーター、ポートの :443 を入力しないでください。以下のexample.comは説明用の例で、設定が必要な実際のサービスを示すものではありません。

タイプと書式照合範囲間違えやすい点
DOMAIN,api.example.com,DIRECT api.example.comのみ一致 example.comやimg.api.example.comには一致しない
DOMAIN-SUFFIX,example.com,PROXY example.comとそのサブドメインに一致 notexample.comには一致しない（ドメインの境界が重要）
DOMAIN-KEYWORD,example,PROXY ホスト名にexampleを含むリクエストに一致 example.netとnotexample.comの両方に一致する可能性があり、範囲が広い

特定のAPIだけ出口を変えるならDOMAIN、同じ親ドメイン配下のリソース用ドメインも対象にするならDOMAIN-SUFFIXを使います。部分文字列での照合が明確に必要な場合に限り、DOMAIN-KEYWORDを使用してください。キーワードルールはサイトの所属関係を判別しません。短すぎる語句では無関係なドメインまで対象になり、問題の範囲も特定しにくくなります。

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

この例では、api.example.comは最初のルールに一致してDIRECT、img.example.comはサフィックスルールに一致します。いずれの条件にも一致しないリクエストには、最後のFINALのDIRECTが適用されます。最初の行をサフィックスルールの後に移すと、APIの例外が適用されなくなります。DNSや接続パラメーターを変更しなくても、順番を変えるだけで結果は変わります。

GEOIPとIP-CIDR

GEOIPは、宛先IPアドレスがローカルの地理データベースでどの地域に割り当てられているかを基準に照合します。GEOIP,CN,DIRECT は、CNに割り当てられた宛先IPにDIRECTを適用するという意味です。ウェブページの言語、ドメインの末尾、サービス事業者の登録地による判定ではありません。同じドメインが異なる地域のIPアドレスに解決される場合があるため、結果は名前解決の結果とデータベースの内容の両方に左右されます。

IP-CIDRはIPv4のアドレス範囲を直接照合します。192.168.0.0/16 は192.168.0.0から192.168.255.255までを対象とし、10.20.30.40/32 は1つのIPv4アドレスを表します。マスクが示すのはアドレス範囲であり、ポート範囲やホスト数ではありません。

IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR,10.20.30.40/32,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

「そのウェブサイトは特定の地域のものだから」といった理由だけで、GEOIPが必ず一致すると判断しないでください。コンテンツ配信ネットワークは、同じドメインに複数の宛先IPを返すことがあり、アプリがキャッシュ済みのアドレスを使う場合もあります。新しいリクエストの宛先アドレスを確認してから、地理ルールが想定どおりか判断してください。

FINALとルール全体の順序

FINALは、それより前のルールに一致しなかった場合に使うフォールバックであり、接続失敗後の再試行を切り替える設定ではありません。先行ルールがPROXYを選び、送信接続がタイムアウトしても、そのルールを自動で飛ばしてFINALのDIRECTに切り替わることはありません。末尾にルールを追加するのではなく、選択された送信先またはルールの選択を見直してください。

[Rule]
DOMAIN,api.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,media-sample,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY
  1. 具体的な例外を先に配置。単一ドメインのAPIルールを、同じサイトを対象にするサフィックスルールより前に置くと、例外が適用されます。
  2. 次にドメインの範囲を設定。既知のサイトの出口を先に決め、その後でIP範囲を処理すると、地理的な割り当ての変化が特定サイトに与える影響を抑えられます。
  3. アドレスルールを配置。ローカルネットワークの範囲とGEOIPの間にも順序があります。ルールの範囲が重なる場合は、優先したい条件を前に置いてください。
  4. 最後にフォールバックを配置。FINALは末尾に置きます。分類されていないリクエストにDIRECTとPROXYのどちらを適用するかは、他の設定をまねるのではなく、希望する処理に応じて決めてください。

症状から通信振り分けの問題を特定

変更は一度に1項目だけにし、同じ宛先に新しいリクエストを送って確認します。利用できる接続履歴やログを確認し、宛先ドメイン、実際のIPアドレス、一致したルール、最終的なポリシーを記録してください。ログに一部しか表示されない場合は、その情報をもとに原因を絞り込みます。「ページが開かない」ことだけで、ルールの記述ミスと決めつけないでください。

エラー：Connection timed out

原因と対処：制限時間内に接続が完了しなかった状態です。宛先、経路、送信サービスが関係している可能性があります。まず一致したポリシーを確認し、HomeのConnectivity Testで現在の接続をテストしたうえで、同じ宛先への別のリクエストと比較してください。タイムアウトだけでは、DOMAIN-SUFFIXの書式が誤っているとは判断できません。

エラー：Connection refused

原因と対処：通常は宛先側または中間機器が接続を明示的に拒否したことを示します。リクエストの宛先ポートと、利用者が設定済みのサービスのポートを確認してください。たとえばサービスが443番ポートだけで待ち受けているのに8443番へ接続している場合は、FINALのフォールバックを変更するのではなく、接続パラメーターを修正します。

上記はネットワークエラーを英語で表したものです。ログの取得元によって具体的な表示は異なります。エラーはないものの出口が想定と違う場合は、まずProxyまたはDirectのままになっていないか確認します。次に編集したファイルが有効なConfigかを確認し、最初のRuleから順に、先に一致している条件を探してください。

「ルールを追加したのに、出口が変わらないのはなぜ？」

まずHomeでGlobal RoutingをConfigに固定し、Configで有効なファイルを確認します。単一ドメインの例外を、より広いサフィックスまたはキーワードルールより前に移動します。保存後は既存の接続を終了して、同じドメインへ再度リクエストしてください。古い接続を再利用しているページを更新するだけでは確認になりません。

「GEOIPにCNを指定したのに、この中国語サイトがDIRECTにならないのはなぜ？」

ページの言語ではなく、そのリクエストが実際に接続したIPアドレスを確認してください。先行するドメインルールにすでに一致している場合、後続のGEOIPは判定されません。GEOIPまで到達している場合は、そのIPのデータベース上の割り当てと、名前解決の結果が変わっていないかを確認してください。

「サブスクリプションを更新すると、カスタムルールも更新されますか？」

サービスのサブスクリプションとConfigは別のものです。Homeで既存のサービスのサブスクリプションを更新すると、主に接続項目が更新されます。リモート設定を更新するには、Configで対象ファイルを操作してください。サブスクリプションの更新に成功しても、ローカルのRuleが保存済みまたは有効とは限りません。

「プロトコルを変更したら、DOMAIN-SUFFIXも書き直す必要がありますか？」

プロトコルの変更だけを理由に、Ruleを自動的に書き直す必要はありません。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuardは接続プロトコルの層に属し、ドメインルールはポリシーを選択します。まず従来のポリシーが有効な接続項目を参照しているか確認し、その後、利用するサービスのパラメーターに従ってプロトコル接続を確認してください。

保存前に項目ごとに確認

適切な通信振り分け設定には、次の3点を説明できる必要があります。このルールは何に一致するか、なぜこの位置に置くのか、一致後にどのポリシーを使うのか。説明できないキーワードを一度に大量に追加するより、まず少数の明確なルールを設定し、段階的に増やすほうが問題を特定しやすくなります。当サイトではクライアントの設定方法を解説します。ノードやサブスクリプションサービスの提供、販売、推奨は行いません。

Shadowrocketを無料でダウンロード