Shadowrocketのカスタムルールは上から順に判定され、最初に一致したルールのポリシーが適用されます。具体的な例外は広い範囲のルールより前に置き、FINALは[Rule]セクションの最後に記述します。この記事では、iPhone、iPad、Mac、Windows、Android、Linuxでルールファイルを確認する際の考え方を解説します。画面操作は実際の端末表示に従ってください。基本的なルールの作成、PROXY / DIRECT / REJECTの使い分け、「現在の設定・接続状態・ルールの判定順・接続先」の順で原因を調べる方法を紹介します。
1. まずConfigの状態を確認してからルールの適用を判断する
接続スイッチがオンでも、カスタムルールが通信の振り分けに使われているとは限りません。iPhone / iPadを例に、まずConfigで編集する設定が選択されていることを確認し、Homeに戻ってGlobal Routingを確認します。この記事のルールを調べるときはConfigを使い、ProxyやDirectに切り替えて試した結果だけでルールの誤りと判断しないでください。
この記事では、利用可能なサービス設定をすでにお持ちであることを前提としています。ルールが決めるのはリクエストの処理方法であり、接続情報を作成したり、サーバーへの接続不能を解消したりするものではありません。当サイトではノードやサブスクリプションを提供・販売・推奨していません。変更前に現在の設定を複製しておき、設定を一度に置き換えて比較できなくなる事態を避けましょう。
| Global Routing | 確認時の意味 | 確認できる内容 |
|---|---|---|
| Config | 現在の設定にあるルールに従ってポリシーを決定 | ルールの順序、例外、FINAL |
| Proxy | 主にプロキシ経由で接続する状態。この記事のルールを1行ずつ検証する設定ではありません | 選択中のプロキシ接続が利用できるか |
| Direct | 主に直接接続する状態 | 現在のネットワークから直接接続できるか |
| Scene | 設定済みのシーンに応じて動作 | シーンの選択と切り替え。この記事の検証基準にはしません |
Settings → On Demandではオンデマンド接続の条件を管理しますが、[Rule]の順序は変わりません。ネットワークの切り替え後に接続状態が変わった場合は、まずOn Demandを確認してからルールを調べてください。「トンネルが接続されていない」状態と「ルールの判定ミス」は別の問題です。
2. ルールの構文：タイプ、照合値、ポリシーを指定する
多くのルールは「ルールタイプ,照合値,ポリシー」の形式で、項目を半角カンマで区切ります。キーワードと区切り文字には半角文字を使います。FINALには照合値がないため、FINAL,PROXYと記述します。以下は[Rule]セクションの学習用サンプルであり、サーバーやDNSなどを含む完全な設定ではありません。利用可能な既存設定に追加して確認してください。これだけで接続できるファイルではありません。
[Rule]
DOMAIN,blocked.example.com,REJECT
DOMAIN,local.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYexample.comとそのサブドメインは照合方法を説明するための例です。192.0.2.0/24はドキュメント用の例示アドレス帯で、利用可能なサービスのアドレスではありません。上記のルールは構文と順序を示すものであり、これらのアドレスで実際にサービスを利用できることを意味しません。検証にはアクセス権のある宛先を使い、用途に応じて直接接続するか拒否するかを判断してください。
- DOMAIN：ドメイン名に完全一致します。たとえば
local.example.comに一致し、名前が似ているだけの別のサブドメインには一致しません。 - DOMAIN-SUFFIX：指定したドメインとそのサブドメインに一致します。
example.comはapi.example.comにも一致しますが、この文字列を含むすべてのドメインに一致するわけではありません。 - IP-CIDR：IPv4アドレスの範囲に一致します。ここでの
/24はネットワークプレフィックス長であり、ポート番号ではありません。 - GEOIP：宛先IPの地域データベース上の所属情報に基づいて判定します。
CNは、ウェブページの言語、ドメインの末尾、ユーザーの所在地を基準にするものではありません。 - FINAL：前のルールに一致しなかったリクエストを処理します。ドメインやIPの条件は追加しません。
3. 上から順に判定：具体的な例外を広い範囲のルールより前に置く
ルールはすべての条件を照合してから、自動的に「最も具体的な」ものを選ぶ仕組みではありません。同じリクエストでは、上にあるルールから先に判定されます。一致してポリシーが決まると、通常は後続のルールで結果が上書きされません。そのため、完全一致のドメインルールがサフィックス指定より具体的でも、後ろに置けば自動的に優先されるわけではありません。
例外を先に置く：意図どおりに判定
- 1行目
DOMAIN,local.example.com,DIRECT- 2行目
DOMAIN-SUFFIX,example.com,PROXY- 最後の行
FINAL,PROXY
local.example.comには先にDIRECTが適用され、それ以外の該当サブドメインにはPROXYが適用されます。
範囲ルールを先に置く：例外が適用されない
- 1行目
DOMAIN-SUFFIX,example.com,PROXY- 2行目
DOMAIN,local.example.com,DIRECT- 最後の行
FINAL,PROXY
local.example.comは1行目に一致するため、後ろのDIRECTでは判定が変わりません。
要点：例外を先に、範囲ルールを次に、最後にデフォルト処理を置く
追加したルールが「効かない」ときは、まず上にあるルールのうち同じ宛先に一致するものを探します。必要な完全一致の例外をそのルールより前に移し、新しい接続で再確認しましょう。ポリシーを何度も切り替えるより、原因を特定しやすくなります。
- 目的を明確にします。たとえば、
local.example.comだけを直接接続し、それ以外のexample.comのサブドメインはプロキシ経由にします。 - まず完全一致のDOMAIN例外を置き、その後に範囲を指定するDOMAIN-SUFFIXを置きます。REJECTの例外がある場合も、意図した優先順位になるよう配置します。
- 既存設定から読み込まれたルールも含め、より上にあるルールが対象に一致していないか確認します。
- 保存後も該当の設定が選択されていることを確認し、新しい接続で検証します。以前のページですでに確立した接続だけを根拠に判断しないでください。
4. FINALを最後に置く理由と、デフォルト処理の選び方
FINALには追加の照合条件がありません。FINAL,PROXYを[Rule]の先頭に置くと、それより前に絞り込むルールがないため、後続のドメインやIPのルールでリクエストを処理できなくなります。途中に置いた場合も、その後ろにあるルールが適用されなくなります。保守しやすいようFINALは1行にまとめ、設定ファイル内の任意の位置ではなく[Rule]セクションの末尾に置いてください。
[Rule]
DOMAIN,local.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXYこの例では、まず明示されたドメインの条件を処理し、次に残りの宛先IPをGEOIPで判定し、最後まで一致しなかったリクエストをPROXYに渡します。FINALは接続に失敗したときの予備経路ではなく、「直前のプロキシ接続に失敗したら直接接続する」というフォールバック設定でもありません。PROXYが選ばれたリクエストは、末尾にFINAL,DIRECTがあっても、接続失敗だけを理由に自動で直接接続へ切り替わることはありません。
| デフォルト処理の書き方 | どのルールにも一致しないリクエストの処理 | 変更前に確認すること |
|---|---|---|
FINAL,PROXY | プロキシポリシーに渡す | プロキシの接続先が利用でき、未指定の宛先に想定した経路を使うこと |
FINAL,DIRECT | 宛先に直接接続する | ルールに記載していない宛先を現在のネットワークから直接接続してよいこと |
FINAL,REJECT | それ以外のリクエストを拒否する | 許可する宛先をすべて把握していること。通常の通信まで拒否されるおそれがあります |
ウェブページを一時的に表示するためだけに、デフォルト処理を何度も変更しないでください。未指定の宛先にどの経路を使うかを決めてから、必要な例外を追加します。FINALを明確なデフォルトポリシーとして設定しておけば、ルールが増えても通信の振り分け結果を説明しやすくなります。
5. PROXY、DIRECT、REJECTは接続プロトコルではない
この3つのキーワードは処理ポリシーを表すもので、プロトコル名ではありません。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuardは接続設定に関わるプロトコルです。PROXYと記述しても、現在の接続が自動的に特定のプロトコルへ切り替わるわけではありません。カスタムポリシーグループを使っている場合は、グループ名と実際に選択されている接続先も確認してください。定義されていないグループ名は有効なポリシーとして使えません。
| ポリシー | 動作 | よくある誤解 |
|---|---|---|
| PROXY | 一致したリクエストをプロキシ経由の接続先に渡します。選択中の接続や関連するポリシー設定を確認してください | 最速の接続先が自動選択されるわけではなく、サーバーに接続できる保証もありません |
| DIRECT | 現在のネットワークから宛先に直接接続します | VPN全体を停止する機能ではなく、ほかのリクエストもすべて直接接続されるわけではありません |
| REJECT | 一致したリクエストを拒否します | 接続を修復する機能でも、優先度を下げて再試行を待つ機能でもありません |
たとえばDOMAIN,blocked.example.com,REJECTは、そのドメイン名に完全一致するリクエストを拒否します。すべてのexample.comのサブドメインまで拒否するわけではありません。ドメイン全体を拒否する場合は、DOMAIN-SUFFIX,example.com,REJECTとします。影響範囲が広がるため、ログインやAPI、リソース用のドメインまで誤って拒否しないか確認してください。
6. IP-CIDR、GEOIP、DNS：ドメインへのリクエストをIPへのリクエストと混同しない
ドメインルールは通常、リクエストに含まれるドメイン名をもとに判定します。一方、IP-CIDRとGEOIPには宛先IPの情報が必要です。1つのドメインが複数のIPアドレスに対応することもあり、アドレスはネットワークや名前解決の結果、サービスの構成によって変わる場合があります。一度確認したIPを直接接続ルールに固定しても、次回のアクセスに適用されるとは限りません。また、そのドメイン全体に同じポリシーが適用されるとも限りません。
no-resolveは、そのIPルールの判定だけを目的とした名前解決を行わないようにするオプションです。「DNSを無効にする」という意味ではなく、すべてのドメインリクエストをこのIPルールで判定できるわけでもありません。判定に使える宛先IPがない場合、ネットワーク範囲との一致を無理に判定することはできません。
- 明確なドメイン条件：DOMAINまたはDOMAIN-SUFFIXを優先し、GEOIPより前に置きます。1回の名前解決結果に依存せず、意図したポリシーを適用できます。
- 明確なアドレス範囲：IP-CIDRを使い、CIDRプレフィックスを確認します。
192.0.2.0/24をポート番号付きの192.0.2.0:443に書き換えないでください。 - 地域判定：GEOIPはデータベース上の宛先IPの所属情報を参照します。サーバーの実際の設置場所と一致するとは限らないため、特にクラウドサービスやコンテンツ配信では確認が必要です。
- IPv6の宛先：IPv4のIP-CIDR範囲はIPv6には適用されません。デュアルスタック接続を調べる場合は、実際のアドレスの種類をそれぞれ確認してください。IPv4ルール1つだけで全通信を判断することはできません。
HTTPSの宛先ポートは443が一般的ですが、この記事のDOMAIN-SUFFIXルールにはポート条件がありません。ポートにかかわらずドメイン名で判定します。特定のAPIへの接続が失敗する場合は、対象ドメイン、実際のIPアドレス、宛先ポート、接続エラーをそれぞれ確認してください。アプリやサーバー側の拒否を、ルールに一致していないことと混同しないでください。
7. 保存後の検証：一度に変更するのは1項目
「ルールが正しく判定されたか」と「選択した接続先で接続できるか」は分けて確認します。前者ではリクエストに適用されたポリシーを、後者では接続の成否を確認します。PROXYに一致して接続に失敗しても、ルールの順序は正しい場合があります。反対に、ページが表示できても、想定したポリシーで接続されたとは限りません。
- 基準を残す：現在使える設定を複製し、変更前のGlobal Routing、選択中の接続、確認対象のドメインを記録します。
- 変更は1項目だけ：まず完全一致のDOMAINルールを1行追加するか、2行の順序だけを変更します。DNS、接続プロトコル、FINALを同時に変更しないでください。
- 選択状態を確認：Configに戻って使用中の設定を確認し、HomeでGlobal RoutingがConfigになっていることと、接続状態が正常であることを確認します。
- 新しい接続を開始：開いているページを閉じてからリクエストを再送します。必要に応じてアプリ内に残っている接続を終了してください。既存の接続は、確立時の経路を引き続き使うことがあります。
- 記録を確認：端末で確認できる接続記録やログで、宛先、一致したルール、ポリシーを確認します。記録にすべての項目が表示されない場合は、一時的な完全一致ルールと比較し、推測で結論を出さないでください。
- 復元して記録：変更後に問題が起きたら、まず複製した設定に戻します。変更の効果を確認できたら日常用の設定に反映し、ルールの目的を記録します。
DIRECTを追加したのに、なぜこのドメインはPROXYになるのですか？
まずGlobal RoutingがConfigか確認し、編集した設定が実際に選択中の設定と一致することを確認します。該当するDOMAIN行より上にあるDOMAIN-SUFFIXなどのルールを調べ、必要な例外を範囲ルールより前に移してください。保存後、新しい接続で再確認します。
FINALをDIRECTにしたのに、プロキシ接続の失敗後に直接接続されないのはなぜですか？
FINALが処理するのは、それより前のルールに一致しなかったリクエストだけです。PROXYに一致した後の接続エラーは処理しません。まず該当リクエストに一致したルールを確認し、次に現在のプロキシ接続先を調べます。もともと直接接続が必要な場合は、対象範囲を正確に指定したDIRECTルールを追加してください。接続失敗時のフォールバックに頼ることはできません。
サブスクリプションを更新すると、カスタムルールは上書きされますか？
まずHomeで行う接続サブスクリプションの更新と、Configで行うリモート設定の更新を区別してください。前者は主に接続情報を更新し、後者ではルールが再読み込みされる場合があります。編集前にローカルコピーを保存しましょう。リモート設定を継続的に更新する場合は、更新対象の範囲を確認し、一度限りの変更をリモートの内容だけに加えないでください。
On Demandを有効にしているのに、なぜルールが反映されないのですか？
Settings → On Demandで自動接続の条件を確認し、Homeに戻って実際の接続状態とGlobal Routingを確認してください。On Demandが決めるのは接続するタイミングです。接続状態を自動的にConfigとして扱う機能ではなく、ルールの順序を変更するものでもありません。
日常のメンテナンスでは、具体的な例外を先に、範囲ルールを中ほどに、FINALを最後に置きます。問題が起きたら、まず現在の設定と一致したルールの記録を確認し、次に接続先への到達性を調べてください。原因が特定できていない接続障害を、同じルールの重複追加で覆い隠さないようにしましょう。