Shadowrocketのカスタムルール設定と優先順位｜上から順に判定する仕組みとFINALルール

この記事の要点

カスタムルールを使う前に、Global RoutingでConfigが選択されていることを確認し、「具体的な例外を先に、範囲の広い条件を後に、FINALを最後に」の順で並べます。自分で用意した接続情報があり、Shadowrocketの振り分けを調整したい方向けに、ルールの書式、編集手順、確認方法を紹介します。接続サービスの提供はありません。

まずConfigを確認し、ルールが適用されているか判断する

ルールの記述が正しくても、現在の接続でそのルールが使われているとは限りません。確認を始める前にHome → Global Routingで現在のモードを確認し、Configで選択中の設定ファイルを確かめてください。ここでは設定ファイルの[Rule]セクションにおける上から順の判定を扱います。サービス一覧の並び順や、遅延テストの結果順ではありません。

Config

Proxy

接続をプロキシ経由にし、この記事で扱う設定ルールに沿った個別の振り分けは行いません。一時的に切り替えてアクセスできても、振り分け経路を引き続き確認する必要があることを示すだけで、特定のルールの誤りを直接証明するものではありません。

用途：短時間、プロキシ経由の接続が使えるか確認する。

Direct

接続を直接接続として処理します。この状態で設定内のPROXYルールを変更しても、ルールの効果を検証する方法としては適切ではありません。

用途：現在のネットワークから直接接続できるか確認する。

Global Routingには、シーンごとに接続方法を設定するSceneもあります。Sceneが選択されている場合は、実際に適用されているシーンを確認してください。この記事の例を検証する際は、条件を絞るため一時的にConfigへ切り替え、検証後に元の設定へ戻せます。Settings → On Demandはオンデマンド接続を制御する機能で、接続先の振り分けルールの代わりにはなりません。

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

一般的なルールは「ルールタイプ、マッチ値、ポリシー」の順に記述し、各項目を半角カンマで区切ります。FINALはマッチ値を持たない例外で、FINAL,DIRECTまたはFINAL,PROXYと記述します。全角カンマを使ったり、ドメインのマッチ値にURLのパスやポート番号を含めたりしないでください。

ルールタイプ	書式例	マッチ範囲
`DOMAIN`	`DOMAIN,api.example.com,PROXY`	指定した完全一致のドメインだけにマッチします。
`DOMAIN-SUFFIX`	`DOMAIN-SUFFIX,example.com,DIRECT`	example.comとそのサブドメインにマッチします。notexample.comにはマッチしません。
`IP-CIDR`	`IP-CIDR,192.168.0.0/16,DIRECT,no-resolve`	指定したIPv4のネットワーク範囲にマッチします。この例では192.168.0.0から192.168.255.255までが対象です。
`GEOIP`	`GEOIP,CN,DIRECT`	接続先IPアドレスの地理データベース上の地域に基づいて判定します。Webページの言語やドメインの末尾では判定しません。
`FINAL`	`FINAL,PROXY`	前のルールにマッチしなかった場合に、ここで指定したポリシーを適用します。

たとえば接続先のドメインがapi.example.comの場合、DOMAINルールのマッチ値にはドメインだけを記述し、https://、/login、:443は付けません。同じドメインへのHTTPS接続でTCP 443が使われることは一般的ですが、DOMAIN-SUFFIXはポート番号を判定しません。ポートを区別する場合、ドメイン文字列を変えるだけでは対応できません。

3項目

DOMAIN-SUFFIX：タイプ、ドメインのサフィックス、ポリシー。

2項目

FINAL：タイプとフォールバックポリシー。マッチ値はありません。

256個のアドレス

IPv4の/24ネットワークには、256個のアドレスが含まれます。

no-resolveはIP系ルールで使えるオプションで、そのルールとの照合だけを目的としたドメイン解決を防ぎます。アプリ全体のDNSを無効にするものではありません。接続にドメイン名しかなく、照合に使える接続先IPアドレスがまだない場合、このオプションを付けたルールにはマッチしないことがあります。ドメイン単位で振り分けたい場合は、IPルールですべてをカバーしようとせず、ドメインルールを優先してください。

上から順に判定：具体的な例外を範囲の広いルールより前に置く

この記事で扱う基本的なルールでは、接続は上から順に照合され、最初にマッチしたルールのポリシーが適用されます。条件が「より具体的」だからといって自動的に優先されることはなく、複数のルールにマッチしてもポリシーは統合されません。よくあるのは、先にドメイン全体を対象とするサフィックスルールがあり、後に書いた個別のサブドメインの例外が適用されないケースです。

[Rule]
DOMAIN,api.example.com,PROXY
DOMAIN,blocked.example.com,REJECT
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
FINAL,PROXY

これは順序を説明するための[Rule]の例であり、接続に必要な設定をすべて含む完全な設定ファイルではありません。ドメインは説明用の例です。接続パラメータには、すでに利用している情報を使ってください。既存のファイルに[Rule]セクションがある場合は、そのセクション内を編集し、同じセクションを重複して追加しないでください。

api.example.comは最初のルールにマッチしてPROXYが適用されます。後続のドメインサフィックス条件にも該当しますが、DIRECTに切り替わることはありません。
blocked.example.comは2番目のルールにマッチしてREJECTが適用されます。このルールをDOMAIN-SUFFIXの後ろに移すと、例外として機能しなくなります。
www.example.comは最初の2つのルールにマッチせず、3番目のルールにマッチしてDIRECTが適用されます。
接続先が192.168.1.20の場合は4番目のルールにマッチします。前の条件にマッチしなかった接続だけがFINALに進みます。

ポイント：ルールを追加する前に例外の順序を見直す

サブドメインが意図したとおりに振り分けられない場合は、まず上位にドメイン全体を対象とするルールがないか確認してください。重複するルールを追加するより、具体的な例外を範囲の広い条件より前に移す方が効果的です。

同じ考え方はIPネットワークにも当てはまります。特定のIPアドレスだけに異なるポリシーを適用する場合は、そのアドレスを指定する/32ルールを、対象を含む/24や/16ルールより前に置きます。GEOIPのような広い条件は、個別に処理したい接続を先に振り分けてしまわないよう、具体的なドメインやネットワークの後に置くのが一般的です。

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

ルールタイプは「何にマッチするか」、ポリシーは「マッチした接続をどう処理するか」を示します。PROXYはプロキシ経由、DIRECTは直接接続、REJECTは接続拒否を意味します。PROXYでリクエストを処理できるかどうかは、選択中のプロキシとその接続状態にも左右されます。ルールにマッチしても、接続先に必ずアクセスできるとは限りません。

PROXY: マッチした接続をプロキシ経由にします。検証時はHomeで現在選択されているサービスと、その接続状態も確認してください。
DIRECT: 現在のネットワークから接続先へ直接接続します。「自動的に最速の経路を選ぶ」という意味ではなく、現在のネットワークからアクセスできることを保証するものでもありません。
REJECT: マッチした接続を拒否します。対象範囲の広いドメインサフィックスやネットワークのルールに設定すると、関連するページやリソースにも影響することがあります。
FINAL: 前のルールにマッチしなかった接続に適用する最後のルールです。プロキシサービスの一種ではなく、残りの接続を指定したポリシーに振り分けます。

FINAL,DIRECTは「明示した接続先だけをプロキシ経由にし、それ以外は直接接続する」設計に適しています。FINAL,PROXYは「明示した接続先を直接接続または拒否し、それ以外はプロキシ経由にする」設計に適しています。どちらが適切かは利用目的によって異なります。特定のWebサイトに一時的にアクセスできないからといって、FINALのポリシーを何度も切り替えないでください。

また、Webページは複数のドメインに同時に接続することがあります。メインページ、画像、ログイン用API、メディアは、それぞれ異なるルールにマッチする場合があります。メインドメインにDIRECTを指定しても、ページ上のすべての接続がDIRECTになるわけではありません。実際のリクエスト先ドメインを確認して必要な例外を追加し、把握できない接続をすべてREJECTにしないようにしてください。

編集と検証：一度に変更する条件は1つだけ

編集前に現在の設定ファイルのコピーを保存し、Home → Global Routingで選択中のモードを記録してください。Configではサブスクリプション設定、リモート設定、ローカルコピーを区別します。サービス一覧の更新とルールの更新は別の操作です。また、リモート設定の更新によって、元のファイルに直接加えた変更が上書きされることがあります。長期間使う個別の変更は、自分で管理できる設定ファイルのコピーに加え、更新のたびに内容を確認してください。

モードを確認する

Home → Global Routing → Configに進み、今回の検証で設定ルールを使うようにします。現在選択されているプロキシも記録し、テスト中は変更しないでください。
設定ファイルを開く

Configを開き、現在選択中の設定ファイルを確認します。先にコピーを保存してから編集画面を開き、テキストエディタを使う場合は[Rule]を探して、既存のFINALの位置を確認してください。
例外ルールを追加する

テストするDOMAINまたはDOMAIN-SUFFIXを、関連する範囲の広いルールより前、かつFINALより上に配置します。一度に追加または変更するのは1つだけにし、DNSや接続パラメータを同時に変更しないでください。
新しい接続で試す

保存後も同じ設定ファイルが選択されていることを確認し、Homeに戻って接続し直します。対象のページを閉じてから開き直し、新しい接続でリクエストを発生させてください。既存の接続が維持されている状態だけで判断しないようにします。
結果を確認する

アプリ内の接続ログで、実際のリクエストドメイン、接続先アドレス、適用されたポリシーを確認します。想定と異なる場合は、マッチした可能性のある直前のルールを探してから、マッチ値を変更するか判断してください。

「接続先・想定・実際の結果・変更内容」の4項目を記録しておくと、テスト結果を整理できます。たとえば、自分が使うAPIのドメインが接続先で、想定はPROXY、実際はDIRECTだったため、このテストでは該当するDOMAINルールをDOMAIN-SUFFIXより前に移動した、と記録します。これにより、「ルールにマッチしなかった」ケースと「ルールにはマッチしたが接続できなかった」ケースを区別でき、検証後に一時設定を戻す際にも役立ちます。

意図しないルールにマッチする：実際のポリシーが想定と異なる場合は、まずGlobal Routing、選択中の設定ファイル、ルールの順序を確認します。
正しいルールにマッチするが接続できない：PROXYが適用されているのにタイムアウトする場合は、使用中のサービスの状態やプロトコルパラメータを確認します。すぐにルール全体を書き直す必要はありません。
一部のリソースだけ失敗する：メインページは表示できるのに画像やログインに失敗する場合は、アドレスバーのドメインだけでなく、読み込めないリソース自体のドメインを確認してください。

よくある質問：ルールが適用されないときに確認すること

ルールを設定したのに、なぜすべてプロキシ経由になるのですか？

まずHome → Global Routingを開き、ProxyではなくConfigが選択されていることを確認します。次にConfigで選択中のファイルを確認してください。Configが選択されている場合は、前方に範囲の広いPROXYルールがないか、FINALがカスタムルールより前に置かれていないかを確認します。

DOMAIN-SUFFIXにワイルドカードは必要ですか？

example.comとそのサブドメインにマッチさせるには、DOMAIN-SUFFIX,example.com,DIRECTと記述します。*.example.comやプロトコルのプレフィックスは不要です。完全一致する特定のドメインだけを対象にする場合は、DOMAINを使います。

IP-CIDRにno-resolveを付けたらマッチしなくなったのはなぜですか？

まず接続ログに、照合できる接続先IPアドレスがあるか確認してください。no-resolveは、このルールのためにドメインを自動で解決しません。ドメイン単位で振り分ける必要がある場合は、IPルールでアドレス情報を補えると考えず、ドメインルールを追加してください。

更新後にカスタムルールが消えた場合はどうすればよいですか？

まずConfigで、現在の設定ファイルがリモートの内容に置き換わっていないか、別のファイルに切り替わっていないかを確認し、保存したコピーと照合して復元します。Homeでのサービスサブスクリプションの更新と、Configでの設定ファイルの更新は別の操作です。確認時はそれぞれ分けて記録してください。

個別に確認せず、FINAL,REJECTを使えますか？

許可リスト方式を明確に採用し、必要な接続先をすべて管理できる場合に限り、この設計を検討してください。前のルールで処理されなかった接続はすべて拒否されます。通常のトラブルシューティングでは既存のフォールバックポリシーを維持し、具体的なDOMAINの例外で検証してください。一度に多くのリソースを遮断する事態を避けられます。

検証が終わったら、一時的に変更したモードを元に戻し、テスト用ルールを削除して、FINALが最後にあることを確認します。ルール管理で重要なのは項目数ではありません。それぞれの例外に明確な対象があり、更新ごとの差分を確認でき、接続の失敗をマッチの問題と接続の問題に分けて判断できることです。