Shadowrocketのルール設定入門:DOMAIN・DOMAIN-SUFFIX・GEOIP・FINALを解説

DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORD、GEOIP、IP-CIDR、FINALの条件と評価順、PROXY・DIRECT・REJECTの使い分けを解説します。

この記事の概要

初回接続を済ませ、Configの編集を始める方向けの記事です。まずマッチ条件と実行ポリシーを区別し、6種類のルールを使って上から順に判定される仕組みを説明します。例は構文の解説用で、既存設定とそのまま置き換えられる完全な設定ではありません。プロキシ接続には、利用者自身が用意したサービス、サーバー、サブスクリプションが必要です。

1. Global Routingを確認してからConfigを編集する

Shadowrocketのルールで指定するのは、「接続がどの条件に一致するか」と「一致した場合にどのポリシーを適用するか」です。ルールでサーバーを作成したり、利用できないサーバーを使えるようにしたりすることはできません。編集を始める前に、Homeで利用可能なサーバーを選択し、基本的な接続テストを済ませてください。

Homeではサーバーと接続状態、Configでは設定ファイル、Settingsではアプリの設定を管理します。設定ルールに基づいて通信を振り分けるには、Home → Global RoutingでConfigを選択します。ファイルを編集しただけで、該当する設定を有効にしていない場合、ルールが機能しているとは判断できません。

モード主な動作この記事での確認方法
Config現在の設定にあるルールに基づいてポリシーを決定します。ルールのテストにはこのモードを使います。
Proxyこの記事のドメインルールに沿った振り分けではなく、プロキシ経由で通信します。プロキシ経路が利用できるかを比較する際に役立ちます。
Direct通信を直接接続で処理します。PROXYルールが適用されるかの確認には使えません。
Scene設定済みのSceneに基づいてルーティングを決定します。まずSceneの設定を確認してください。ルールファイル単体の動作確認にはConfigを使います。

On Demandは接続を開始または切断するタイミングを決める機能で、ドメインルールやIPルールの代わりにはなりません。接続が自動で再開する場合は、Settings → On Demandも確認してください。自動接続をDOMAINルールの適用と混同しないようにしましょう。

2. ルールの構成と評価順

基本的なルールの多くは、「種類、マッチする値、ポリシー」をカンマで区切って記述します。設定の[Rule]セクションに記述し、通常は上から順に評価されます。最初に一致したルールで接続のポリシーが決まり、後にある具体的なルールが自動的に優先されることはありません。

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

この例では、login.example.comは最初の行に一致し、DIRECTが適用されます。www.example.comは最初の行に一致せず、次に2行目に一致してPROXYが適用されます。どのルールにも一致しない接続はFINALで処理されます。2行目を1行目より上に移すと、ログイン用ドメインも先にサフィックスルールに一致します。

接続開始 宛先を確認 順に照合 ポリシー決定 外部へ接続
6種類
この記事で解説する基本的なルールタイプ
3種類
基本ポリシー:PROXY / DIRECT / REJECT
32ビット
IPv4アドレスの長さ。/32は単一アドレスを表します

これらの数値はこの記事で扱う基本事項を示すもので、Shadowrocketが6種類のルールしかサポートしないという意味ではありません。編集時は半角カンマを使い、1行に1つのルールを記述してください。リッチテキストから全角の句読点や見えない文字をコピーしないよう注意しましょう。

3. DOMAIN・DOMAIN-SUFFIX・DOMAIN-KEYWORD

ドメインルールは接続に関連付けられたホスト名に一致し、Webページのパスには一致しません。example.comのように指定し、プロトコル、ポート、パスを含むURL全体は記述しません。URL内に単語が含まれていても、パスにあるだけではDOMAIN-KEYWORDに一致しません。

ルールタイプ一致するもの一致しないもの
DOMAIN,example.com,DIRECTexample.comwww.example.com
DOMAIN-SUFFIX,example.com,PROXYexample.com、api.example.comnotexample.com
DOMAIN-KEYWORD,example,PROXYホスト名にexampleを含むドメインWebページのパスにだけexampleを含むリクエスト

DOMAIN:特定ホストへの例外設定

DOMAINは、特定のホストだけを変更したい場合に適しています。たとえば、login.example.comをDIRECTにし、ほかのサブドメインには引き続きプロキシを使う場合です。指定したホストの下位ドメインまで自動的に対象になるわけではありません。個別の例外ルールは、より広い範囲に一致するルールより前に記述してください。

DOMAIN-SUFFIX:ルートドメインとサブドメイン

DOMAIN-SUFFIXは、ドメインの境界に基づいて複数のホストをまとめて管理する場合に適しています。example.comと記述すればよく、*.を付ける必要はありません。ルートドメインとサブドメインの両方に一致しますが、notexample.comは同じサフィックスとして扱われません。

DOMAIN-KEYWORD:ホスト名に含まれる文字列

DOMAIN-KEYWORDはマッチ範囲が広く、想定外のドメインまで対象になることがあります。文字列の一部で照合する必要がある場合を除き、DOMAINまたはDOMAIN-SUFFIXを優先してください。キーワードルールを前に置くと、後にある具体的なルールより先に一致します。

4. GEOIPとIP-CIDR:宛先IPアドレスで判定

IPルールはURLの文字列ではなく、宛先アドレスを使って判定します。ドメインに接続する場合、IPとの照合に先立ってDNSの名前解決が必要になることがあります。名前解決の結果やアドレスデータベースの違い、CDNの振り分けによって、実際の一致状況は変わることがあります。

IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR,192.0.2.0/24,REJECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

GEOIP,CN,DIRECTは、使用するアドレスデータベースで宛先IPがCNに属すると判定された場合、DIRECTを適用するという意味です。Webサイトの言語や運営者の所在地を判定するものではありません。中国語のサイトでも別の地域のアドレスを使う場合があり、1つのドメインから複数のアドレスが返されることもあります。

宛先がIPv6で通信している場合、IPv4のIP-CIDRルールだけではその接続をカバーできません。対応するIPv6ルールとネットワーク設定も確認してください。IPv4の例が正しくても、すべてのアドレスファミリーに対応できているとは限りません。

5. PROXY・DIRECT・REJECTとFINALの使い分け

マッチタイプとポリシーは別の要素です。DOMAIN-SUFFIXは「どのドメインに一致させるか」を決め、PROXYは「一致した接続をどう処理するか」を決めます。ルールの最後の項目をDIRECTからPROXYに変更すると、外部への接続方法が変わりますが、ドメインのマッチ範囲は変わりません。

ポリシー動作確認するポイント
PROXYプロキシ経由で外部に接続します。選択中のサーバー、または関連するポリシーが利用可能か確認してください。
DIRECT宛先に直接接続します。現在のネットワークから宛先に直接アクセスできるか確認してください。
REJECT条件に一致した接続を拒否します。拒否する範囲に必要なAPIが含まれていないか確認してください。

FINALは、ほかのルールに一致しない接続を処理するためのルールです。独自のドメインやIPのマッチ値はなく、FINAL,ポリシーと記述します。ルールセクションの末尾に置いてください。FINALを途中に置くと、それより後のルールが未一致の接続を処理できなくなります。

[Rule]
DOMAIN,ads.example.com,REJECT
DOMAIN,login.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

この例では、まず明確な例外を処理し、次に広い範囲を対象にし、最後に残りを処理します。ads.example.comは拒否され、login.example.comは直接接続されます。残りのexample.comのドメインはプロキシ経由になります。CNのアドレスに名前解決された場合でも、先にあるドメインルールでポリシーが決まるため、GEOIPには進みません。

6. Configで保存・有効化・動作確認

編集前に、現在利用できている設定のコピーを保存してください。サーバーのサブスクリプション更新とルールファイルの更新は別の操作です。Homeでサーバーリストの更新に成功しても、Configのルールが更新されたとは限りません。リモート管理の設定は、更新時にローカルの変更が上書きされる場合もあるため、編集前にファイルの提供元を確認してください。

  1. 基準状態を確認する。Homeでサーバーを選択し、接続スイッチをオンにしてConnectivity Testを実行します。テストに成功しても、確認した経路が利用できることを示すだけで、すべてのWebサイトにアクセスできるとは限りません。
  2. 現在の設定ファイルを確認する。Configを開き、現在有効なファイルを確認します。そのファイルの編集画面から[Rule]セクションを確認し、ほかの設定セクションは残してください。この記事の例をファイル全体に置き換えてはいけません。
  3. 変更する項目は1つにする。必要なDOMAINまたはDOMAIN-SUFFIXルールを1つ追加し、関連する広範囲のルールとFINALより前に配置して保存します。
  4. ルールが有効になる条件を確認する。変更した設定を有効にし、Home → Global RoutingでConfigを選択します。必要に応じて接続を再確立してください。
  5. リクエストを再実行する。開いているページを閉じるか、関連アプリの接続を終了してからテストします。既存の長時間接続は確立時の接続先を使い続ける場合があり、新しいルールの結果を反映しているとは限りません。
  6. 実際の状況を記録する。接続履歴やログを確認し、対象ホスト名、宛先IP、適用されたポリシーを照合します。改善しない場合は、直前に使えていた設定に戻してから、DNSまたは外部への接続経路を確認してください。

テストでは、ポートとルールのマッチ範囲も区別してください。HTTPSでは宛先ポート443がよく使われますが、DOMAIN,example.com,DIRECT自体に「443だけに一致する」という制限はありません。Webページは表示できても、別のポートを使うサービスに接続できない場合は、ドメインルールの不具合と判断する前に、サービスの待ち受け状態とネットワークの到達性を確認してください。

7. 接続に失敗したら、エラーとルールの適用を切り分ける

エラーの原文は接続処理のどこかで失敗したことを示すもので、特定のルールの記述ミスを直接証明するものではありません。以下はネットワーク診断で表示されることのあるエラーで、Shadowrocket独自のルール構文エラーではありません。接続先と実際に使われた接続経路を確認して原因を判断してください。

エラー:Connection refused

原因:接続先または途中の機器によって接続が拒否されています。ポートでサービスが待ち受けていない可能性があります。

対処法:まず失敗した接続先がプロキシサーバーかWebサイトかを確認し、該当するアドレスとポートを照合します。ルールが適用されていることを確認したら、その接続先サービスの状態を調べてください。

エラー:Operation timed out

原因:制限時間内に接続が完了しませんでした。ネットワーク経路、フィルタリング、接続先への到達性などが関係している可能性があります。

対処法:まずHomeでConnectivity Testを実行し、次にDIRECTとPROXYの経路をそれぞれ確認します。DNSとサーバーを同時に変更せず、対象ルールを一度に1つだけ調整してください。

REJECTが適用された場合、接続が拒否されるのは想定どおりの動作です。必要なリソースまで拒否される場合は、拒否ルールの範囲を狭めるか、明示的に許可する例外ルールをその前に置いてください。再試行を繰り返しても、適用済みのREJECTルールが自動的にPROXYへ変わることはありません。

8. ルール設定に関するよくある質問

DOMAINルールを追加したのに、サブドメインに変化がないのはなぜですか?

DOMAINは指定したホスト名だけに一致します。ルートドメインとそのサブドメインを対象にするには、DOMAIN-SUFFIXを使い、そのルールがほかの一致するルールより前にあるか確認してください。特定のサブドメインだけに例外を設ける場合は、そのホスト用のDOMAINルールを追加します。

ルールを最後の行に書いたのに、適用されないのはなぜですか?

まず、そのルールがFINALより後にないか確認してください。具体的なルールをFINALより前に移し、さらに前にあるDOMAIN-SUFFIXまたはDOMAIN-KEYWORDがすでに一致していないか確認します。ルールは後ろにあるものほど優先される仕組みではありません。

GEOIPにCNと書いたのに、このサイトがPROXYになるのはなぜですか?

まず、前にあるドメインルールでPROXYが選択されていないか確認し、次に実際の名前解決結果とアドレスデータベース上の地域を確認してください。GEOIPはWebサイトの言語では判定しません。特定のドメインの接続先を固定したい場合は、前のほうに明示的なDOMAINルールを追加して検証できます。

サブスクリプションの更新に成功したのに、ルールが古いままなのはなぜですか?

サーバーのサブスクリプションとConfigファイルを別々に確認してください。まずConfigで有効なファイルとルールの内容を確認してから、対応するリモート設定を更新する必要があるか判断します。更新前にローカルの変更を保存し、サブスクリプションの更新をルール更新と混同しないようにしてください。

ブラウザーでは表示できるのに、アプリ内の画像が開けない場合はどうすればよいですか?

画像リクエストの実際のホスト名を確認し、サイトのトップページだけで判断しないでください。リクエストを再実行して接続履歴を確認し、別のリソースドメイン、異なる宛先IP、REJECTされたAPIがないか調べます。対象が特定できたら、必要最小限の範囲で例外ルールを追加してください。

ShadowrocketをApp Storeで入手