Shadowrocketのルール種類と使い方:DOMAIN・DOMAIN-SUFFIX・GEOIP・IP-CIDR・FINALのマッチ範囲

example.comを例に、DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORD、GEOIP、IP-CIDR、FINALのマッチ範囲を解説。ルールは上から順に評価され、最初に一致したものが適用されます。

この記事の概要

この記事は、Shadowrocketで接続を設定済みで、ルーティングルールを自分で調整したい方向けです。まず Home → Global Routing で Config を選び、現在の設定ファイルの [Rule] を確認します。ドメインルールは名前のマッチ範囲を、IPルールは接続先アドレスを判定し、FINALはどのルールにも一致しない通信を処理します。6種類のルールの違いと並べ方を把握し、個々のリクエストで結果を確認できます。プロキシ接続を使う場合は、利用可能な接続先をすでにお持ちであることが前提です。

1. ルールが適用される条件:Configと最初の一致

ルールの種類は「どの条件でマッチさせるか」を示し、行末のポリシーは「マッチ後にどう処理するか」を示します。両者は分けて考えましょう。DOMAIN,example.com,DIRECT は、ドメインが example.com と完全一致した場合に直接接続するルールです。このドメインを特定のプロキシリストに追加する指定ではありません。

この記事では Home → Global Routing → Config で行うルーティングを扱います。Proxy と Direct はそれぞれ全通信のプロキシ接続と直接接続に使うため、ここで説明するルールの優先順位を検証する用途には使えません。Scene はシーンごとにルーティングを選ぶ別の方式で、今回のテスト対象外です。Config では、実際に編集した設定ファイルを選択する必要があります。保存しただけで選択されていないファイルは、現在のルーティングに反映されません。

リクエストがトンネルに入る現在の設定を読み込む上から順に照合する最初の一致を適用する出力ポリシーを実行する

この記事の一般的なルール例では、条件に合うルールが最初に見つかった時点で、そのポリシーが適用されます。より「正確な」ルールを探して照合を続けることはありません。細かい条件が広い条件より自動的に優先されるわけではなく、優先順位は並び順で決まります。

6種類
この記事で扱うルールキーワードの種類。すべてを網羅するものではありません
1番目
最初に一致した一般ルールで今回のポリシーが決まる
32ビット
IPv4アドレスのビット数。/32は単一のアドレスを表す

2. DOMAIN・DOMAIN-SUFFIX・DOMAIN-KEYWORD

3種類ともドメインを照合対象とし、Webページのパスやクエリパラメーターは対象外です。https://example.com/docs?q=test にアクセスした場合、ドメインは example.com です。ページを絞り込むために /docs や ?q=test をDOMAINに指定することはできません。

ルールマッチするマッチしない
DOMAIN,example.com,PROXYexample.comwww.example.com
DOMAIN-SUFFIX,example.com,PROXYexample.com、api.example.comnotexample.com、example.com.test
DOMAIN-KEYWORD,example,PROXYexample.com、myexample.testsample.test

DOMAIN:完全一致するドメインを指定

api.example.com だけをプロキシ接続にし、ほかのサブドメインは現在のポリシーのままにしたい場合は、DOMAINを使います。ルール値にはドメインだけを記述し、プロトコル、ポート番号、ワイルドカードは付けません。HTTPSでよく使われる接続先ポート443はドメイン文字列に含まれないため、DOMAIN,example.com:443,PROXY はこの記事で紹介する書き方ではありません。

DOMAIN-SUFFIX:ルートドメインとサブドメインにマッチ

ドメイン階層全体を対象にする場合はDOMAIN-SUFFIXを使います。ドメインの階層境界を基準に照合するため、任意の文字列による末尾一致とは異なります。example.com は static.example.com にマッチしますが、notexample.com にはマッチしません。値には通常 example.com と記述し、*.example.com とは書きません。

DOMAIN-KEYWORD:ドメイン内の文字列でマッチ

DOMAIN-KEYWORDは、文字列がドメインのどこにあってもマッチする可能性があるため、サフィックスルールより対象範囲を制御しにくいルールです。名称の一部で分類する必要があり、誤マッチのリスクを許容できる場合に限って使いましょう。実際の対象が1つのルートドメインとそのサブドメインだけなら、DOMAIN-SUFFIXのほうが確認しやすくなります。

3. GEOIPとIP-CIDR:接続先IPを照合

ドメインルールは名前を照合し、GEOIPとIP-CIDRはアドレスを照合します。GEOIPはローカルのIP位置情報データベースに基づいて分類します。たとえば GEOIP,CN,DIRECT は、データベースでCNに分類される接続先IPを直接接続にする指定です。Webページの言語やドメインの登録地を確認するものではなく、サーバーの物理的な所在地を特定できるとは限りません。

[Rule]
DOMAIN,api.example.com,PROXY
IP-CIDR,192.168.50.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

IP-CIDRはネットワークプレフィックスでIPv4アドレス範囲を指定します。192.168.50.0/24 は 192.168.50.0 から 192.168.50.255 までを対象にします。1台のデバイスだけを対象にする場合は、192.168.50.10/32 を使えます。例に示したLANアドレスはリモートサービスのアドレスではありません。実際のネットワークに合わせて変更してください。

同じドメインが複数のIPアドレスに解決されることがあり、アドレスはネットワーク環境によって変わる場合もあります。「このWebサイトを常に特定のポリシーで接続したい」場合は、まずドメインルールを検討しましょう。接続先のネットワーク範囲やIPの分類に基づく必要が明確な場合に、IPルールを使います。

4. FINALとルールの順序:例外を先に、一般ルールを後に、最後に既定ルール

FINALにはドメインやネットワーク範囲を指定せず、それ以前のどのルールにも一致しない通信を処理します。FINAL,DIRECT は残りのリクエストを直接接続し、FINAL,PROXY は残りのリクエストをプロキシ接続にします。どちらが適切かは設定の目的によって異なり、常に正しいといえる一方はありません。

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

このルール設定では「API用ドメインだけをプロキシ接続にし、同じサイトのほかのドメインは直接接続」にします。api.example.com へのリクエストは先にDOMAINにマッチします。www.example.com は最初のルールには一致しませんが、DOMAIN-SUFFIXにマッチします。example.net はFINALに進みます。

並び順api.example.comへのリクエスト理由
DOMAINが先PROXY例外の完全一致が先に適用される
DOMAIN-SUFFIXが先DIRECT広いルールが先に適用され、APIドメインも対象になる
FINALが先頭DIRECT既定ルールが先にリクエストを処理し、後続の一般ルールは適用されない

DOMAIN-KEYWORD,example,PROXY を追加する場合は、本来直接接続したいドメインに先回りしてマッチしないかも確認してください。ルールを確認するときは、対象ドメインが記述されているかだけでなく、ファイルの先頭から順に、先にマッチする可能性のある条件がないかも調べましょう。

5. Configでルールを編集して確認する

以下の例は[Rule]セクションのみを示したもので、既存の設定ファイルを置き換えてそのまま使える完全なファイルではありません。PROXYには、現在利用しているプロキシの選択先を指定します。設定ファイルで独自のポリシーグループ名を参照している場合は、対応するグループが存在することも確認してください。アプリの買い切り購入に回線プランは含まれません。アプリを購入しても、プロキシ接続に必要な情報が自動で設定されるわけではありません。

  1. 現在の設定を残す:Configを開き、現在のファイルを複製するかバックアップとして書き出します。選択中の設定ファイルも記録しておきましょう。
  2. 対象ファイルを編集する:変更する設定ファイルを開いて編集し、既存の [Rule] セクションを探します。明確なDOMAINのテストルールを、それに先回りする可能性のあるルールより前に置き、同じセクションを重複して追加しないでください。
  3. 保存して選択する:Configで変更後のファイルが選択されていることを確認し、Home → Global Routing → Configに戻ります。
  4. 接続を準備する:Homeで、すでに利用可能な接続先が選択されていることを確認します。対象ポリシーがPROXYの場合は、先にConnectivity Testを実行できます。ただし、テストに成功してもWebサイトのすべてのリソースにアクセスできるとは限りません。
  5. 新しいリクエストを作成する:開いているWebページを閉じ、対象ページを開き直します。必要に応じて、接続が一時的に切れることを確認したうえで再接続してください。確立済みの長時間接続は、変更後のルールを検証するのに適していません。
  6. 記録を確認する:今回のリクエストに対応する接続記録を開き、接続先ドメイン、接続先IP、マッチしたルール、実際に適用されたポリシーを確認します。一度に変更するのは1項目だけにし、新しいリクエストを発生させて結果を比較してください。

この記事では example.com を使って構文上の範囲を説明しています。表はルールの動作を論理的に示したもので、実際のネットワーク速度を測定した結果ではありません。実際にテストする場合は、アクセス権があり、普段利用しているドメインに置き換えてください。ページの表示速度だけでルーティングを判断しないでください。ネットワーク遅延から、どのルールにマッチしたかは分かりません。

6. 接続できないとき:DNS・接続・ルールを切り分ける

Webページのエラーが、ルールの構文エラーを意味するとは限りません。まず、リクエストが想定したポリシーにマッチしたかを確認し、次にそのポリシーに対応する名前解決と接続経路を調べます。以下の2つはDNS応答で使われる標準エラー識別子で、Shadowrocketに固定表示されるメッセージではありません。実際の診断結果に表示された場合に、それぞれに応じて対応してください。

DNS応答:NXDOMAIN

原因:リゾルバーが、問い合わせたドメインは存在しないと応答しています。名前の入力ミスか、ドメイン自体が利用できない可能性があります。

対処法:リクエスト先のホスト名とDNSレコードを確認してから、リゾルバーの応答を調べます。DOMAINをDOMAIN-SUFFIXに変更するだけでは、マッチ範囲が広がるだけで、存在しないDNSレコードは作られません。

DNS応答:SERVFAIL

原因:リゾルバーが問い合わせを完了できませんでした。上流の名前解決や検証に問題がある可能性があります。このエラーだけでドメインが存在しないとは判断できません。

対処法:現在のDNS設定と上流への接続を確認し、同じドメインで応答を再確認します。ドメインのIPアドレスが取得できたら、GEOIPまたはIP-CIDRのマッチ結果を検証してください。

IPアドレスが解決できても接続がタイムアウトする場合は、DIRECTとPROXYの接続経路を切り分けてください。DIRECTにマッチした場合は、現在のネットワークから接続先に到達できるかを確認します。PROXYにマッチした場合は、まず選択中のプロキシに接続できることを確認し、次にプロキシから接続先までの経路を調べます。FINALを何度も切り替える方法は、条件をそろえた比較には使えますが、原因の特定にはなりません。

7. ルールの書き方でよくある質問

DOMAINを設定したのに、サブドメインが同じプロキシ接続にならないのはなぜ?

DOMAINは完全一致するドメインだけにマッチします。ルートドメインとすべてのサブドメインに同じポリシーを適用するには、ルールを DOMAIN-SUFFIX,example.com,PROXY に変更し、それより前にマッチするルールがないか確認してください。

ルールにPROXYと書いてあるのに、記録では直接接続になっています。最初に何を確認すればよいですか?

まずHome → Global RoutingがConfigになっているかを確認し、次にConfigで現在どのファイルが選択されているかを確かめます。その後、[Rule]セクションの先頭から、DOMAIN-SUFFIX、IPルール、FINALが先にマッチしていないか確認してください。

GEOIP,CN,DIRECTを設定すれば、中国語のWebサイトはすべて直接接続になりますか?

いいえ。GEOIPは接続先IPをデータベースに基づいて分類するもので、ページ内の言語は判定しません。特定のドメインを直接接続にする必要があると分かっている場合は、GEOIPより前にDOMAINまたはDOMAIN-SUFFIXを追加し、新しい接続で確認してください。

一部のWebサイトだけをプロキシ接続にしたい場合、FINALはどう設定すればよいですか?

対象ドメインのポリシーをPROXYにし、必要な例外をその前に並べて、最後に FINAL,DIRECT を設定します。テストでは対象ドメインと対象外のドメインの両方を確認し、前者がドメインルールにマッチし、後者が直接接続の既定ルールに進むことを確かめてください。

Settings → On Demandでルールのマッチ範囲は変わりますか?

On Demandは条件に応じた接続の確立を管理する機能で、DOMAINをサフィックス一致に変えるものではありません。まずトンネルが接続済みであることを確認し、Configでルールを調べてください。「接続しているか」と「接続後にどうルーティングするか」を同じ設定として扱わないようにしましょう。

App Storeの正規アプリページ購入前にデベロッパ名とアプリIDを確認