Shadowrocketのカスタムルール設定｜マッチ順序・FINALのフォールバック・PROXY/DIRECT/REJECT

この記事の概要

この記事は、Shadowrocketに自分で用意した接続情報を追加済みで、ルールによる振り分けを変更したい方向けです。まずHome → Global RoutingでConfigを選び、現在有効な設定ファイルの[Rule]セクションを編集します。個別の例外、範囲ルール、FINALの順に整理すれば、接続記録からルール順序の誤り、ポリシーの選択ミス、接続自体の問題を切り分けられます。設定を何度も入れ替えて試す必要はありません。

1. まずGlobal Routingを確認：ルールが判定に使われる条件

ルールを書き加えても、それだけで接続処理に反映されるわけではありません。Shadowrocketでは、Homeで接続と全体のルーティング方式を管理し、Configで設定ファイルを管理します。Settingsではアプリの設定を変更できます。ここで解説するカスタムルールを確認するには、まずHome → Global RoutingでConfigを選び、Configで選択中のファイルが編集したファイルと同じか確認してください。

Config

Proxy

全体のルーティング先をプロキシにします。この記事で扱うルールに従った振り分けは行われません。接続結果を比較するために一時的に使うことはできますが、特定のDOMAIN-SUFFIXルールが一致するかの確認には使えません。

用途：プロキシ接続が利用できるかの比較確認

Direct

全体のルーティング先を直接接続にします。設定にPROXYルールがあっても、この状態で設定どおりに振り分けられるとは限りません。

用途：直接接続の結果を比較確認

Global RoutingのSceneは、状況に応じて選択するための機能です。個々のルールに設定するポリシーとは別のものです。問題を調べる際はConfigに固定すると、Sceneの切り替えによる変数を減らせます。Settings → On Demandは条件に応じて接続を開始する設定であり、特定のドメインがPROXYとDIRECTのどちらに一致するかは決めません。接続を自動で開始することと、接続後に通信を振り分けることは別の処理です。

2. 上から順に評価：個別の例外を範囲ルールより先に置く

ルール一覧は「より詳細なルールが自動的に優先される」仕組みではなく、順番に沿って判定するリストです。Shadowrocketは上から確認し、最初に条件を満たしたルールのポリシーを適用します。そのリクエストについて、後続のルールが結果を補ったり上書きしたりすることはありません。下の方に詳細なルールを追加しても、上のルールがすでに一致していれば、その結果は変わりません。

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

このルールでは、account.example.comは最初のDOMAINに一致するためDIRECTになります。media.example.comは1行目には一致せず、次のDOMAIN-SUFFIXに一致してPROXYになります。先頭2つのルールを入れ替えると、範囲の広いサフィックスルールが先に一致し、accountの例外を上書きします。example.comは構文を説明するための例であり、利用可能なプロキシサービスを示すものではありません。

1件

最初に一致したルールが今回のポリシーを決定

3種類

この記事で扱うポリシー：PROXY / DIRECT / REJECT

末尾

FINALは個別の条件ルールの後に配置

ルールを整理する際は、「必ず拒否する個別の対象、DIRECTにする個別の例外、広いドメイン範囲、アドレス範囲、フォールバック」の順で確認できます。ただし、これは固定のテンプレートではありません。特定のドメインを優先して直接接続する必要がある場合は、それを含むルールより前に例外を置いてください。重要なのはキーワード名の順ではなく、ルール同士の適用範囲です。

3. DOMAIN-SUFFIX、IP-CIDR、GEOIPの書き方

ドメインルールはリクエストのホスト名を、アドレスルールは接続先IPを判定します。同じサービスを指すことがあっても、照合する対象は異なります。IP-CIDRにドメインを入力したり、プロトコルやパス、クエリを含む完全なURLをDOMAIN-SUFFIXに入力したりしないでください。

キーワード	構文例	対象範囲と注意点
`DOMAIN`	`DOMAIN,account.example.com,DIRECT`	ドメイン全体に一致します。ほかのサブドメインは自動的に含まれません。
`DOMAIN-SUFFIX`	`DOMAIN-SUFFIX,example.com,PROXY`	example.comとそのサブドメインに一致します。ワイルドカードのアスタリスクは不要です。
`IP-CIDR`	`IP-CIDR,192.168.0.0/16,DIRECT,no-resolve`	IPv4のアドレス範囲に一致します。マスク長も範囲を指定する要素です。
`GEOIP`	`GEOIP,CN,DIRECT`	接続先IPを地理情報データベースで分類します。ウェブページの言語やドメインの末尾で分類するものではありません。
`FINAL`	`FINAL,PROXY`	照合対象は指定しません。それ以前のルールに一致しなかったリクエストを受け取ります。

192.168.0.0/16は192.168.0.0から192.168.255.255までのアドレス範囲を表し、1台のデバイスを指すものではありません。特定のIPv4デバイスだけに一致させるには、そのアドレスに対応する/32ルールを使用できます。LAN内の宛先に一致する通信をプロキシに渡さず直接接続できますが、実際に到達できるかどうかは現在のネットワーク、システムの権限、接続先サービスに左右されます。

GEOIPの判定結果は、実際の接続先アドレスとデータベースの内容によって変わります。.comで終わるドメインでも異なる地域のアドレスに解決されることがあり、同じドメインでもネットワークによって異なるコンテンツ配信先が使われる場合があります。特定のドメインに常に同じポリシーを適用したい場合は、明確なドメインルールを優先し、GEOIPの結果を推測で代用しないでください。

4. PROXY、DIRECT、REJECTとFINALの関係

キーワードは「何に一致させるか」を、ポリシー欄は「一致後にどう処理するか」を指定します。たとえばDOMAIN-SUFFIX,example.com,PROXYでは、最初の2項目で照合範囲を定め、最後の項目で処理方法を決めます。FINALは特殊なフォールバックルールであり、4つ目の接続ポリシーではありません。

PROXY：プロキシ経由で処理します。利用には、ユーザー自身が用意した有効な接続情報と、利用可能なプロキシの選択が必要です。ルール自体がサービスを作り出すことはありません。
DIRECT：接続先へ直接接続します。「まず直接接続し、失敗したら自動的にプロキシへ切り替える」という意味ではありません。接続に失敗しても、次のルールの評価は行われません。
REJECT：一致したリクエストを拒否します。明確にブロックしたい接続先に使います。ログイン、認証、リソースのドメインに誤って適用すると、ページの機能が正常に動作しない場合があります。
FINAL：ほかのルールに一致しなかったリクエストにポリシーを指定します。例：FINAL,DIRECT、FINAL,PROXY。

FINALはルール一覧の末尾に置きます。ドメインやアドレスの条件がなく、ここまで到達した残りのリクエストを受け取るためです。先頭に置くと、その後の個別ルールが一致する機会を失います。通常は明確なFINALを1つだけ残し、複数のFINALを重ねてフェイルオーバーを実現しようとしないでください。

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

上の例は、特定のホストを拒否し、ログイン用の例外を残し、残りのexample.com宛てリクエストをプロキシに渡し、その後LANとGEOIPの条件を処理して、最後に残りをPROXYにするという学習用の判断例です。あらゆるネットワークに適用できる汎用設定ではありません。リストにない接続先を直接接続したい場合は、最後の行をFINAL,DIRECTに変更してください。その場合、プロキシルールに含まれない接続先も直接接続されます。

5. 現在のConfigを編集：バックアップ、保存、再確認

作業を始める前に、自分で用意したサービスと接続情報があり、選択した接続が利用できることを確認してください。クライアントの買い切り料金と接続サービスの料金は別です。このサイトでは接続先やサブスクリプションを提供、販売、推奨していません。ルールの変更で変わるのは既存の接続先を選ぶ方法であり、認証情報の期限切れやサーバーに到達できないといった基本的な問題は解決しません。

現在の設定をバックアップ

Configを開いて選択中の設定ファイルを確認し、まず複製を保存するかバックアップをエクスポートします。元の[Rule]の内容とFINALのポリシーを記録しておけば、編集に失敗した場合もルールを一から整理し直さずに済みます。
ルーティング方式を固定

Home → Global Routing → Configを開きます。現在選択されているプロキシを記録してください。テスト中はSettings → On Demandの変更やネットワークの切り替えを同時に行わないでください。
ルールを編集

Configに戻り、現在の設定ファイルの編集画面を開いて[Rule]を探します。個別の例外は、それを含む範囲ルールより前に配置してください。既存のセクションを編集し、[Rule]セクションを重複して追加しないでください。
保存して選択

変更を保存し、Configで引き続きこのファイルが選択されていることを確認します。複製を編集した場合は、先にその複製へ切り替えてからHomeに戻り、接続状態を確認してください。反映されていないファイルだけを変更していないか確認するためです。
新しいリクエストを送信

テスト接続を新たに確立し、個別の例外、範囲ルール、フォールバック先をそれぞれ確認します。必要に応じて作業を保存してから接続を切り、再接続してください。以前の接続が再利用されることによる判定への影響を減らせます。

サブスクリプションの読み込みとConfigの管理は別の操作です。既存サーバーのサブスクリプション更新では主に接続項目が更新されますが、リモート設定の更新ではルール内容が置き換わる場合があります。ローカルの変更が消えた場合は、どちらを更新したのか確認してください。長期的に管理するカスタムルールは、管理できるローカル設定の複製に保存し、リモート設定を更新するたびに差分を確認してください。

6. 一致結果を検証：まずルール、次にウェブページ

ページが開くかどうかで分かるのは、そのアクセスの結果だけです。ルールが正しいことの証明にはなりません。1つのページでも複数のドメインに接続することがあり、メインページは直接接続でも、画像や認証用API、メディアなどは別のポリシーで処理される場合があります。問題を調べる際は、ページタイトルや読み込み速度だけで判断せず、接続記録から対象ホスト、適用されたルール、最終的なポリシーを確認してください。

確認対象	上記の例で想定される結果	想定どおりでない場合に確認する点
`account.example.com`	DOMAINに一致し、DIRECTを使用	個別ルールがDOMAIN-SUFFIXより前にあるか
`media.example.com`	DOMAIN-SUFFIXに一致し、PROXYを使用	編集後のConfigが選択されているか、先に一致するルールがないか
`192.168.1.20`	LANのIP-CIDRに一致し、DIRECTを使用	ネットマスク、ルールの順序、実際の接続先IP
前のルールに一致しなかった接続先	FINALに一致し、PROXYを使用	FINALのポリシー、それ以前に別のルールへ一致していないか

表のドメインは動作を考えるための例であり、実際にアクセスできるテストサービスではありません。実際に検証する際は、自分がアクセスできる接続先に置き換え、同じ適用範囲を基準に想定結果を立ててください。変更する要素は毎回1つに絞ります。まず順序を調整してから確認してください。DNS、プロキシプロトコル、FINAL、ネットワーク環境を同時に変更すると、どの変更が結果に影響したか特定しにくくなります。

7. よくある質問：ルールがあるのに想定どおりに動作しない

DIRECTを追加したのに、なぜPROXYになる？

まずHome → Global RoutingがConfigになっているか確認し、次にConfigで編集したファイルが選択されているか確認してください。その後、[Rule]の先頭から最初に一致するルールを探します。DOMAIN-SUFFIXが個別のDOMAINより前にある場合は、例外を上に移動して保存し、接続をやり直して確認してください。

FINAL,PROXYはプロキシ接続に失敗すると自動的に直接接続する？

いいえ。FINALは前のルールに一致しなかったリクエストを受け取り、PROXYは処理する方向を指定します。プロキシ接続に失敗しても、ルールエンジンがDIRECTに切り替えて再判定することはありません。選択した接続が利用可能か確認するか、自分の利用目的に合わせてポリシーを明示的に変更してください。

REJECTを設定したのに、ページに古い内容が表示されるのはなぜ？

すでに表示されているページのキャッシュは、新しいリクエストが発生したことを意味しません。まず対象ホスト名がルールと完全に一致するか確認し、ページを再読み込みして新しい接続記録を確認してください。ページが別のドメインを使っている可能性もあります。古いページが表示されたままというだけで、REJECTが機能していないと判断しないでください。

IP-CIDRに設定したら、ドメインでアクセスしても一致しないのはなぜ？

まず実際の接続先IPが指定した範囲に含まれるか確認してください。no-resolveが付いている場合、このルールのためだけにドメイン名を積極的に解決することはありません。特定のドメインに適用するポリシーを固定したい場合は、DOMAINまたはDOMAIN-SUFFIXを追加し、そのドメインを含む可能性のあるルールより前に置いてください。

昨日は有効だったルールが、更新後に変わったのはなぜ？

Configで選択中のファイル、リモート設定を更新した後の[Rule]の内容、Home → Global Routingの設定を確認してください。ルールに変更がなければ、接続先ドメイン、名前解決されたアドレス、接続記録を確認します。GEOIPやIP-CIDRを使う場合は、アドレスの変化だけでも一致結果が変わることがあります。

最終的には、内容を説明できるルール一覧を保ちましょう。個別の例外にはそれぞれ明確な目的があり、範囲ルールの適用範囲が分かりやすく、FINALが残りの通信の行き先を明確に示している状態が理想です。ルールの数を増やしても精度が上がるとは限りません。対象リクエストから一覧を1行ずつたどって一致箇所を特定できれば、その後の管理や問題の切り分けが容易になります。プロトコルパラメータの詳しい説明は技術リファレンス、接続や設定の問題はトラブルシューティングをご覧ください。