2026-07-29 · ルール · 約8分

Shadowrocketのルール優先順位｜上から順に照合する仕組みとFINALの設定方法

Shadowrocketのルールは上から順に照合され、最初に一致したルールが適用されます。FINALの配置と、PROXY・DIRECT・REJECTの設定方法や使い分けを解説します。

この記事のポイント

Shadowrocketのルールは「条件が具体的なものほど自動的に優先される」わけではありません。現在有効なConfigを上から確認し、最初に一致したルールが適用されます。利用中のサービスと購読設定があり、通信の振り分けを変更したい方向けに、Global Routing、ルールの並べ方、3つのポリシー、FINALの使い方を解説します。設定例と確認手順も紹介します。

まずGlobal RoutingがConfigになっているか確認

カスタムルールを通信の振り分けに使うには、Home → Global Routing → Configを選びます。Configのルールだけを変更しても、Global RoutingがProxyまたはDirectのままでは、ルールが適用されるか確認できません。ルールは「どの経路を使うか」を決め、登録済みのサービス情報はその経路で接続できるかを左右します。それぞれ分けて確認してください。

Config

おすすめ

現在有効なConfigのルールに基づいてポリシーを選択します。直接接続、プロキシ接続、拒否のいずれになるかは、一致したルールによって決まり、地域で一律に決まるわけではありません。

用途：日常的なルール分岐、カスタムルールの動作確認。

Proxy

Shadowrocketが処理する通信を現在のプロキシ経路に送ります。Configのルールを一つずつ照合してポリシーを選ぶことはありません。

用途：登録済みのプロキシ経路で対象に接続できるか、一時的に確認する場合。

Direct

Shadowrocketが処理する通信を対象へ直接送ります。Configのプロキシ振り分け結果は使用しません。

用途：現在のネットワークから対象へ直接接続した場合の状態を比較する場合。

Global RoutingのSceneは、シーンごとに動作を設定する機能で、Configと同じ意味ではありません。問題の切り分けで変数を減らすため、この記事ではConfigを使用します。Settings → On Demandでは、オンデマンド接続を開始する条件を管理します。ルール一覧の優先順位を設定する機能ではありません。ルールの順序を調べる際は、接続状態と現在のネットワークを変えずに確認してください。

上から順に照合：個別の例外を広範囲のルールより前に配置

通常のルール一覧は先頭から照合され、一致したルールのポリシーが適用されると、後続のルールは確認されません。「より具体的な」ルールを探し続けることもありません。そのため、すでに対象を含むDOMAIN-SUFFIXより後ろに、個別のDOMAINルールを置いても適用されない場合があります。優先順位を決めるのは文字列の長さではなく、ルールの並び順です。

[Rule]
DOMAIN,metrics.example.com,REJECT
DOMAIN,login.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY

以下は構文の例です。example.comとそのサブドメインは照合方法を説明するためのもので、接続サービスや接続テスト用のアドレスではありません。1行目はmetrics.example.comのみ、2行目はlogin.example.comへの直接接続の例外、3行目はexample.comとそのサブドメインを対象にします。いずれにも一致しない通信はGEOIPを照合し、最後にFINALへ進みます。

リクエスト先のドメイン最初に一致するルールポリシー
metrics.example.com1行目のDOMAINREJECT
login.example.com2行目のDOMAINDIRECT
docs.example.com3行目のDOMAIN-SUFFIXPROXY

DOMAIN-SUFFIX,example.com,PROXYを先頭に移すと、表にある3つのドメインすべてが先にこのルールに一致し、後ろにある拒否や直接接続の例外は適用されません。明示的にブロックまたは許可する対象は前に置き、より広い範囲を対象とするサフィックス、IPアドレス範囲、地域ルールを続け、最後にフォールバックルールを配置します。

PROXY・DIRECT・REJECTとルールキーワードの違い

ルールは通常、「照合条件」と「処理ポリシー」で構成されます。たとえばDOMAIN-SUFFIX,example.com,PROXYでは、DOMAIN-SUFFIXがルールタイプ、example.comが照合対象、PROXYが一致後の処理方法です。プロトコル名とポリシーは別の概念です。既存の接続でShadowsocksやVLESSを使っていても、DOMAIN-SUFFIXの照合順序は変わりません。

3つのポリシー
この記事で扱うPROXY / DIRECT / REJECT
4つのキーワード
DOMAIN-SUFFIX / GEOIP / IP-CIDR / FINALを確認
FINALは1行
この記事の例では、ルール末尾にフォールバックを1行だけ設定

確認方法：条件と接続経路を分けて調べる

まず想定したルールに一致しているか確認し、次にそのポリシーが指定する経路を利用できるか確認します。「プロキシに接続できた」ことを「ルールが正しく適用された」証拠にしないでください。

ポリシー動作確認するポイント
PROXYプロキシ経路を使用します。現在選択しているプロキシを確認します。ポリシーグループを使っている場合は、グループ内の選択肢も確認してください。
DIRECT対象へ直接接続します。現在のネットワークから対象へ直接接続できるか確認します。
REJECT一致した通信を拒否します。対象を本当にブロックする必要があるか、必要な通信まで誤って遮断していないか確認します。

Configで任意の名前を付けたポリシーグループを定義している場合は、実際の設定でグループ名と選択内容を確認してください。不明な名前を組み込みポリシーとして扱わないようにします。REJECTは接続に失敗したときに自動で再試行するポリシーではありません。一致すると、失敗しても後続のPROXYを試すことはありません。

DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

IP-CIDRは宛先IPが属するアドレス範囲で照合します。192.0.2.0/24はドキュメント用のアドレス範囲です。no-resolveは、このIPルールのためだけに追加のドメイン解決を行わない指定であり、すべてのDNSを無効にするものではありません。宛先IPがすでに分かっている場合は、その情報が照合に使われることがあります。GEOIP,CN,DIRECTはIPの位置情報データベースに基づいて判定します。ドメインの末尾や運営主体では判断しないため、直接接続したいサイトすべてに適用されるとは限りません。

FINALのフォールバック：前のルールに一致しなかった通信だけを処理

FINALにドメインやアドレスのパラメーターは不要です。一般的な記述方法はFINAL,PROXYまたはFINAL,DIRECTです。条件を問わないフォールバックのため、通常はルール一覧の末尾に置きます。前に置くと、後続のルールが残りの通信を処理できません。FINALを2行記述しても、1行目が失敗したときに2行目を試す仕組みにはなりません。

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

FINALが処理するのは「前のルールに一つも一致しなかった場合」であり、「前のルールに一致した後、接続に失敗した場合」ではありません。DIRECTルールに一致した通信は、直接接続がタイムアウトしても、末尾のFINAL,PROXYに自動で引き継がれません。その場合は、先に照合条件が広すぎないか確認し、ルールの順序を変えるかポリシーを変更してください。

変更と確認：一度に変更するルールは1つだけ

作業を始める前に現在のConfigのコピーを保存し、使用中のConfig名を記録してください。Homeの購読は登録済みのサービス情報を管理し、Configのルールは通信を振り分けます。Subscribeを更新しても、ルールが変更されるわけではありません。リモートConfigの更新で編集内容が置き換わることもあるため、「既存の購読情報の更新」と「ルールConfigの更新」を区別し、操作後に有効なファイルを確認してください。

  1. ルーティング設定を確認

    Home → Global Routing → Configを開きます。登録済みの接続が利用できる状態を保ち、現在選択しているプロキシまたはポリシーグループを記録してください。テスト中に接続経路を同時に変更しないようにします。

  2. 現在のConfigをバックアップ

    Configを開き、現在使用中のConfigを確認します。先にコピーを保存してから、そのConfigの編集画面を開いてください。テキストで編集する場合は、[Rule]セクションを探します。

  3. 個別のルールを追加

    確認したいDOMAINまたはDOMAIN-SUFFIXを、対象を含む広範囲のルールより前に配置します。末尾にFINALを1行だけ残し、保存後に変更したConfigが使われていることを確認してください。

  4. テスト用リクエストを再実行

    対象アプリで進行中の古いリクエストを停止してから、もう一度アクセスします。必要に応じてConfigの保存後にShadowrocketを再接続してください。変更前に確立した長時間接続を、新しいルールのテスト結果と取り違えないようにします。

  5. ルールの一致結果を確認

    リクエスト記録に表示される宛先ドメイン、宛先IP、ポリシーを確認します。一度に変更する項目は1つにして、変更前後の結果を記録してください。想定したルールに一致しない場合は、プロトコルをすぐに変えず、まず順序を確認します。

Webページは通常、メインページ、ログイン、画像、APIなど複数のドメインへリクエストを送ります。メインページがPROXYに一致しても、すべてのリソースが同じルールに一致するとは限りません。「トップページは開くがログインできない」場合は、ブラウザーのアドレス欄にあるドメインだけに例外を追加するのではなく、失敗したリクエストの実際のドメインを確認してください。

ルールが適用されたかどうかは、新しいリクエストの照合結果とポリシーで判断します。遅延テストで分かるのは特定のテスト経路の応答状況であり、Webページのリクエストが指定したルールに一致したことの証明にはなりません。

よくある質問：ルールが効かないときの確認方法

DIRECTを設定したのに、なぜプロキシ経由になる？

まずHome → Global RoutingでConfigが選択されていることを確認します。次に、DIRECTルールより前に、同じドメインを含むDOMAIN-SUFFIXなどの広範囲なルールがないか調べてください。個別の例外を対象範囲の広いルールより前に移し、保存後にリクエストを再実行します。

FINALを変更しても、対象に接続できないのはなぜ？

まず、リクエストが実際にFINALまで到達しているか確認してください。先行するREJECTまたはDIRECTに一致している場合、FINALを変更しても影響しません。FINAL,PROXYに一致していることを確認できたら、使用中のプロキシ経路、対象サービス、DNSの名前解決結果を調べます。

ルールにドメインを設定しても、IPアドレスへのアクセスが一致しないのはなぜ？

DOMAINとDOMAIN-SUFFIXは、利用可能なドメイン情報に基づいて照合します。IPアドレスへの直接アクセスは、同じドメインへのアクセスとは異なります。IPアドレスで照合する必要がある場合は、適切な範囲のIP-CIDRを追加してください。1つの対象を解決するために、範囲が広すぎるアドレスを追加しないようにします。

更新後、追加したルールが消えたのはなぜ？

Configで現在のファイルと内容を確認し、別のConfigに切り替わっていないか、リモートConfigが更新されていないか調べてください。バックアップと[Rule]セクションを照合し、必要な例外を戻してFINALの位置を確認します。Homeにある既存の購読情報を更新したことは、ルールが保存された証拠にはなりません。

最後に、内容を説明できる最小限のルール一覧を残します。個別の例外を先頭に、範囲ルールを中ほどに、FINALを末尾に配置してください。問題が起きたら、まずGlobal Routingと現在のConfigを確認し、該当するリクエストを追います。ルールの順序、接続経路の到達性、DNSの問題を切り分けられるため、ルールを重複して追加し続けて原因の特定が難しくなるのを防げます。

App Storeの正規アプリを確認