2026年9月30日 · ルール · 約10分

Shadowrocketのカスタムルール設定｜上から順に判定・FINALのフォールバック・PROXY / DIRECT / REJECT

ルールは上から順に評価され、最初に一致した時点で判定が終了します。DOMAIN-SUFFIXやIP-CIDRの書き方、FINALの役割、PROXY・DIRECT・REJECTの使い分けを解説します。

この記事の概要

カスタムルールを適用するには、正しい設定を有効にし、Global RoutingをConfigに設定する必要があります。既存のサーバー情報を読み込み、通信の振り分けを調整する方に向けて、まずルーティングモードとルールの動作を整理します。「具体的な例外を先に、広い条件を後に、最後にFINAL」の順でルールを記述し、新しい接続で結果を確認しましょう。例のドメインは構文の説明用であり、接続先ではありません。

1. Global Routingを確認してルールの適用状態を見分ける

Shadowrocketのサーバー選択、設定ファイル、Global Routingはそれぞれ別の設定です。Homeでサーバーを選んでも、通信が必ずプロキシ経由になるとは限りません。Configにルールが保存されていても、現在のルーティングモードでそのルールが使われているとは限りません。確認するときは、まずHome → Global Routingを開き、現在の選択内容を確認してください。

この記事のルールに従って通信を振り分けるには、Config（設定に基づくルーティング）を選びます。Proxy（プロキシ）とDirect（直接接続）は比較確認に使うモードであり、その接続結果から個別の設定ルールが一致したかどうかを判断することはできません。Scene（シーン）はシーンごとのルーティングに使います。Sceneを使用中の場合は、現在のシーン設定も確認してください。この記事のConfigでのテスト条件と同じだと決めつけないようにしましょう。

Config：設定に基づく振り分け

推奨

現在有効な設定に基づいて、リクエストに適用するルールを決定します。この記事のルール順序とFINALの例は、すべてこのモードを前提としています。

用途：日常的な振り分け、カスタムルールの検証

Proxy：全通信をプロキシ経由にする

クライアントが処理する接続をプロキシ経由にします。既存のサーバーで対象の接続を確立できるか確認するためのモードで、ルール一覧の順序を検証するものではありません。

用途：一時的な比較、プロキシ接続とルールの問題の切り分け

Direct：全通信を直接接続する

クライアントが処理する接続を、対象へ直接つなぎます。この状態でWebページが開いても、設定内のPROXYルールが適用されたことにはなりません。

用途：ローカルネットワークから直接接続できるかの確認

2. ルールは上から順に評価され、「より具体的」でも自動で優先されない

ルール一覧は順序に沿って判定する仕組みで、条件の細かさを自動比較するものではありません。リクエストが上位のルールに一致すると、それより後にある通常のルールで再判定されることはありません。「完全なドメイン名のほうがサフィックスより具体的」という考え方は、ルールを並べる際の指針です。アプリが優先順位を自動調整するという意味ではありません。

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

この例では、api.example.com宛てのリクエストは1行目に一致し、DIRECTになります。www.example.comは1行目には一致しませんが、2行目に一致するためPROXYになります。どちらの条件にも一致しないリクエストはFINALで処理されます。ここでの[Rule]はテキスト設定におけるルールセクションの見出しです。各ルールの前に繰り返し追加するものではありません。

最初に一致したルール
ルール一覧の順序で適用先を決定。具体的なルールが自動で上位になることはありません
3種類のポリシー
この記事の例ではPROXY / DIRECT / REJECTを使用
末尾に1つ
この記事の例では、最後にFINALを1つだけ設定

3. DOMAIN-SUFFIX・IP-CIDR・GEOIPのマッチ対象

一般的な条件ルールは「ルールタイプ,マッチ対象,ポリシー」の形式で記述し、区切りには半角カンマを使います。ドメイン欄にはホスト名だけを指定し、https://やパス、クエリパラメーターは含めません。たとえばアクセス先の/accountはDOMAIN-SUFFIXの対象ではありません。また、この種のルールはWebページのコンテンツをフィルタリングするものではありません。

キーワード記述例マッチする対象
DOMAINDOMAIN,api.example.com,DIRECTホスト名全体に一致します。下位のサブドメインは対象外です。
DOMAIN-SUFFIXDOMAIN-SUFFIX,example.com,PROXYexample.comそのものと、そのサブドメインに一致します。この文字列を含む任意のドメインに一致するわけではありません。
IP-CIDRIP-CIDR,192.168.0.0/16,DIRECT,no-resolveIPv4アドレスの範囲で判定します。この例では192.168.0.0から192.168.255.255までが対象です。
GEOIPGEOIP,CN,DIRECT接続先IPの地理情報データベースに基づいて判定します。Webページの言語やドメインの末尾では判定しません。
FINALFINAL,PROXYマッチ対象を指定せず、前のルールに一致しなかったリクエストを受け取ります。

no-resolveは追加オプションであり、ポリシー名ではありません。IPルールに指定すると、そのルールの判定のためにドメイン名を積極的にIPアドレスへ変換しません。リクエスト自体がIPアドレス宛ての場合は、引き続きアドレス範囲を判定できます。そのため、このオプション付きのIPルールがドメイン名のリクエストに一致しなくても、アドレス範囲の記述ミスとは限りません。

4. PROXY・DIRECT・REJECTとFINALの組み合わせ

PROXYは一致したリクエストをプロキシ経由にし、DIRECTは接続先に直接接続し、REJECTは一致したリクエストを拒否します。ルールにPROXYを記述しても、サーバーが作成されたり接続情報が提供されたりすることはありません。利用するには、あらかじめ自身のサーバーまたはサブスクリプションを読み込み、該当するプロキシ経路が使えることを確認してください。当サイトではノード、サブスクリプション、サービスプロバイダーを提供・販売・推奨していません。

FINALは他のルールに一致しなかったリクエストを処理するもので、「すべての通信にこのポリシーを強制する」という意味ではありません。前のルールに一致しなかった場合にのみ適用されます。一致しなかったリクエストをプロキシ経由にするにはFINAL,PROXY、直接接続するにはFINAL,DIRECTと記述します。どちらを選ぶかは振り分け方針の違いであり、あらゆるネットワークに通用する正解はありません。

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

この設定例では、指定したAPIへの直接接続、特定のサブドメイン範囲の拒否、その他の例示ドメインへのプロキシ接続、未一致リクエストの直接接続という4種類の結果を示します。blocked.example.comのREJECTは、example.com全体に適用するプロキシルールより前に置く必要があります。後ろにあると、先にサフィックスルールに一致してしまいます。これは説明用の最小限のルール例であり、あらゆる用途を網羅する完全な設定ではありません。

末尾にFINALを2つ記述できないのはなぜ？
先にあるFINALが残りのリクエストを処理するため、後のFINALで再選択することはできません。プロキシ接続に失敗しても、次のFINALが試されるわけではありません。障害への対処が必要な場合は、重複したフォールバックを追加するのではなく、プロキシやポリシーグループの設定を確認してください。

5. Configでルールを編集し、新しい接続で検証する

まず現在の設定をバックアップし、結果をはっきり確認できるルールを編集します。以下の手順はモバイル版のHome / Config画面を基準にしています。編集画面への入り方はプラットフォームによって異なる場合がありますが、「どのファイルを編集しているか」「どのファイルが有効か」「Global Routingのモードは何か」を確認する点は共通です。サーバーのサブスクリプション更新とルールファイルの編集は、別の操作として扱ってください。

  1. 設定をバックアップ

    Configを開いて、現在有効な設定ファイルを確認し、編集前にコピーを保存するかバックアップをエクスポートします。リモート設定を再ダウンロードすると、ローカルでの変更が上書きされる場合があります。テスト前に復元できる状態にしておきましょう。

  2. ルールを編集

    Configで対象ファイルの編集画面を開き、プレーンテキストで編集する場合は[Rule]を探します。具体的な例外を広い条件のルールより前に置き、一覧の末尾にあるFINALを確認してください。既存のルールセクション内に見出しを重複して貼り付けないようにします。

  3. モードを確認

    保存後、対象の設定が有効になっていることを確認し、Home → Global Routing → Configに戻ります。Homeで使用可能なサーバーが選択されていることも確認してから、接続を開始してください。

  4. 接続し直す

    テスト中のページやアプリの接続を終了し、テストする権限のある接続先へ再度アクセスします。既存の長時間接続では以前の経路が引き続き使われることがあります。接続を再利用しているページを更新しただけで、変更が反映されていないと判断しないでください。

  5. 接続記録を確認

    接続記録を開き、接続先のホスト名またはIPアドレスで新しいリクエストを探して、実際に適用されたポリシーと確認可能なルール情報を照合します。順序は一度に1か所だけ変更し、変更前後の結果を記録してください。複数の条件を同時に変えるのは避けましょう。

たとえば、自分が管理するテスト用ドメインに完全一致するREJECTルールを一時的に追加し、関連するサフィックスルールより上に置きます。新しい接続が拒否されたら、DIRECTに戻して直接接続できるか確認します。接続記録を根拠に判断してください。Webページのキャッシュによって拒否後も古い内容が表示されたり、ページ内の外部リソースがまったく別のドメインを使っていたりする場合があります。

6. カスタムルールのよくある質問と確認手順

ルールを保存したのに、なぜプロキシ経由になる？

まずHome → Global RoutingがProxyのままになっていないか確認し、次にConfigで編集したファイルが現在有効なファイルと同じか確認してください。問題がなければ、ルール一覧の上から、先に一致するサフィックスルール、アドレス範囲ルール、その他の条件がないか探します。新しく追加した行だけを確認しても十分ではありません。

FINALをDIRECTに変更したのに、一部のサイトがPROXY経由になるのはなぜ？

FINALが処理するのは、他のルールに一致しなかったリクエストだけです。接続先が前のDOMAINまたはDOMAIN-SUFFIXルールに一致していないか確認してください。特定のドメインだけを直接接続する場合は、完全なドメイン名のDIRECT例外ルールを、関連する広い条件のルールより前に置きます。変更後は新しい接続で確認してください。

REJECTを設定したのに、ページの一部が表示されるのはなぜ？

まずキャッシュと既存の接続を除外し、実際にリクエストを送信しているホスト名を確認します。1つのページでメインサイト、画像、API、静的リソースにそれぞれ別のドメインを使うことがあります。1つのドメインを拒否しても、関連するすべてのドメインが自動的に対象になるわけではありません。接続記録を見ながら必要なルールを追加し、広いアドレス範囲をまとめて拒否するのは避けてください。

サブスクリプションを更新したら、結果が変わったのはなぜ？

更新された対象を切り分けてください。サーバーのサブスクリプションを更新すると、サーバー項目や現在の選択が変わることがあります。リモート設定を更新すると、ルールの内容が変わることがあります。Homeで選択中のサーバーを確認し、Configで有効なファイルとルールの順序を確認してください。まずバックアップと比較して変更点を確認し、すべての問題をFINALのせいにしないようにしましょう。

ルールがPROXYに一致したのに接続できない場合は？

ルールへの一致で確認できるのはルートの選択までで、接続先への接続成功を保証するものではありません。既存のサーバー設定、現在のネットワーク、接続先サービスの状態を確認し、一時的にGlobal Routing → Proxyにして同じ接続先を比較テストしてください。どちらのモードでも失敗する場合は、ルールを重複して追加するのではなく、まず接続経路を確認します。

最後に、決まった順序で見直しましょう。まずルーティングモード、次に有効な設定、続いて最初に一致するルール、最後にプロキシまたは接続先への接続状態を確認します。これにより、「ルールが使われていない」「ルールの順序が違う」「ポリシーは正しいが接続に失敗している」の3種類に切り分けられ、同じFINALを何度も変更せずに済みます。

Shadowrocketをダウンロード