· ルールと振り分け · 約10分

Shadowrocketのカスタムルール設定ガイド：マッチ順序、FINALのフォールバック、PROXY/DIRECT/REJECT

ルールは上から順に評価され、最初に一致した時点で処理が決まります。DOMAIN-SUFFIXやIP-CIDRの書き方と、3つのポリシーおよびFINALの使い方を解説します。

この記事の概要

この記事は、Shadowrocketで接続設定を済ませ、Configを編集するユーザー向けです。まずGlobal Routingを確認し、「個別の例外を先に、一般ルールを後に、FINALを末尾に」の順で整理します。ドメインとIPの例を使って、マッチ条件と処理ポリシーの違いを確認し、最後に新しい接続で動作を検証します。サブスクリプションは利用中のサービス提供元から入手し、接続サービスとアプリの購入はそれぞれ別に管理します。

まずGlobal Routingを確認

カスタムルールが評価されるかどうかは、Home → Global Routingで現在選択されている項目によって決まります。Configでは、現在有効な設定に従って接続が処理されます。ProxyとDirectは、全体の処理方法が異なります。Proxyのままルールの順序をテストしたり、Directで目的のサイトにアクセスできたことを、特定のDIRECTルールが適用された証拠と見なしたりしないでください。

Config

推奨

現在有効なConfigを使い、そこに記載されたルールに従って接続ポリシーを決定します。結果はPROXY、DIRECT、REJECTのいずれかで、未マッチの接続が必ず直接接続になるとは限りません。

用途：カスタムルールの作成、検証、日常的な使用。

Proxy

全体をプロキシ経由で処理します。この記事で扱う通常ルールの順序による振り分けテストには使いません。設定済みのプロキシ接続が利用できるか確認する際には役立ちます。

用途：プロキシ接続とルールの問題を一時的に切り分ける。

Direct

全体を直接接続で処理します。目的のサイトが開いても、現在の直接接続経路が利用できることを示すだけで、Config内の特定ルールが有効になった証拠にはなりません。

用途：ローカルネットワークでの直接接続の状態を比較する。

Global RoutingではSceneを使う場合もあります。Sceneは設定したシーン条件に基づいて動作します。問題を調べる際は、まず元の設定を記録し、一時的にConfigを明示的に選択してください。そうすることで、シーンの切り替えによる変化をルールの変更と取り違えずに済みます。Settings → On Demandでは接続を開始する条件を管理します。[Rule]内のマッチ順序は変更しません。テスト中は、ネットワークと接続条件をできるだけ一定に保ってください。

要点：テスト条件を固定する

まずGlobal RoutingがConfigになっていることと、対象の設定が有効であることを確認してから、ルールを1つ変更してください。そうしないと、設定テキストが正しくても、アクセス結果から変更が反映されたか判断できません。

ルールの構文と最初のマッチ

一般的なルールは「種類,マッチ条件,ポリシー」の形式で、区切りには半角カンマを使います。マッチ条件が不要なFINALは、通常2つのフィールドだけです。ルールキーワードとポリシーは英語表記のままにし、キーワードに日本語の句読点を加えないでください。以下は設定テキストの例であり、アプリ画面ではありません。また、すべてのネットワークに適用できる完全な設定を示すものではありません。

[Rule]
DOMAIN,login.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY
3フィールド
一般的なルール：種類、マッチ条件、ポリシー
2フィールド
FINAL：キーワードとフォールバックポリシー
最初のマッチ
テキストの記載順に評価され、自動的にルールの長さで並べ替えられることはありません

判定対象のドメインがlogin.example.comだとします。1つ目のDOMAINルールに一致したため、DIRECTが適用されます。次のDOMAIN-SUFFIXによってPROXYに変更されることはありません。この2行を入れ替えると、より広い範囲に一致するサフィックスルールが先に適用され、同じドメインにPROXYが使われます。「より具体的なルール」が例外になるのは、前に配置されている場合だけです。先にあるルールを自動的に上書きする優先順位はありません。

PROXY、DIRECT、REJECT

マッチ条件は「このルールの対象は何か」を示し、ポリシーは「一致した後にどう処理するか」を示します。DOMAIN-SUFFIX自体がプロキシを意味するわけではなく、IP-CIDR自体が直接接続を意味するわけでもありません。同じマッチ種類に異なるポリシーを指定できます。変更時は条件とポリシーを個別に確認し、行頭のキーワードだけで判断しないでください。

ポリシー処理内容確認ポイント
PROXYプロキシ経由で接続します。現在選択されているプロキシ、ポリシーの参照先、接続の利用可否を確認します。
DIRECT対象に直接接続します。ローカルネットワークから対象に到達できるか確認します。
REJECT一致した接続を拒否します。拒否対象に必要なドメインが含まれていないか確認します。

PROXYは接続サービスを作成せず、利用できない接続を自動的に復旧するものでもありません。設定でカスタムポリシーグループ名を使っている場合は、その定義と選択内容も確認してください。別の設定にあるグループ名を、ルール末尾にそのまま貼り付けないでください。この記事の例では、ルール順序を確認しやすいよう基本の3つのポリシーだけを使っています。既存のポリシーグループをすべて置き換えることを推奨するものではありません。

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

この例では、blocked.example.comは最初のルールで拒否され、login.example.comにはDIRECT、docs.example.comにはPROXYが適用されます。それ以外の未マッチの対象は、FINALによって直接接続されます。これらのドメインは構文の説明にのみ使用しており、アクセスを求めるものでも、接続サービスを提供するアドレスを示すものでもありません。

IP-CIDRとGEOIPの違い

IP-CIDRはIPv4アドレスが指定したネットワーク範囲に含まれるかを判定します。Webサイト名による分類ではありません。192.168.0.0/16は192.168.0.0から192.168.255.255までのアドレスを含みますが、10.0.0.0/8は含みません。ローカルデバイスを直接接続させる場合は、実際のアドレスとサブネットを確認してください。1つのネットワーク範囲が、ローカルネットワーク全体を表すわけではありません。

IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

「特定のドメインに常に指定したポリシーを適用したい」場合は、DOMAINまたはDOMAIN-SUFFIXで明示し、先に一致する可能性がある一般ルールより前に配置します。1つのドメインの振り分けを直すために、GEOIPルールをすべて削除しないでください。まず実際にどのルールに一致したかを確認し、変更する範囲を決めます。

FINALのフォールバックと安全な変更手順

FINALは通常、[Rule]の末尾に配置します。前のルールに一致しなかった接続だけがここに到達するため、FINALの後に通常のルールを追加しても、意図した結果にならないことがほとんどです。未分類の接続にどう対処するかに応じて、FINAL,PROXYまたはFINAL,DIRECTを選びます。どちらも明示的なポリシーであり、すべてのユーザーに共通する正解はありません。

  1. バックアップを保存する

    Configを開き、現在有効なファイルを確認して、まず復元可能なコピーを保存します。元のFINAL、ポリシーグループ名、ルールの順序を記録してください。リモート設定を上書きした際に、カスタム内容が失われるのを防げます。

  2. モードを固定する

    Home → Global RoutingでConfigを選択します。Configに戻り、編集対象と実際に有効なファイルが同じであることを確認してください。名前が似ている別のコピーを編集していないか確認します。

  3. 例外ルールを追加する

    対象ファイルの[Rule]セクションで、完全一致するDOMAINの例外を該当するDOMAIN-SUFFIXより前に配置します。追加する行はFINALより前に置き、半角カンマと既存のセクション区切りを維持してください。

  4. フォールバックを確認する

    [Rule]末尾のFINALが意図どおりか確認します。同じ目的でFINALを複数続けて追加したり、ドメインを含む3フィールドのルールとしてFINALを記述したりしないでください。

  5. 新しい接続で検証する

    設定を保存し、有効になっていることを確認してから、対象アプリで接続をやり直します。接続ログで宛先ドメインまたはIP、マッチしたルール、適用されたポリシーを確認してください。結果が想定と異なる場合は、まずバックアップを復元してから、項目ごとに変更します。

ルールの変更が影響するのは主に、その後の接続判定です。すでに確立した長時間接続では、以前の経路が引き続き使われる場合があります。テストでは古いセッションを終了し、必要に応じて中断しても問題のない作業で再接続してから、同じ対象を開いてください。ファイル転送や通話中にモードを何度も切り替えると、接続切断をルール構文の誤りと取り違えるおそれがあります。

ルールが反映されないときの確認ポイント

「この設定が使われているか」を最初に確認し、次に「どのルールが対象に一致したか」、最後に「ポリシー適用後に接続できるか」を調べます。Webページが開かないからといって、REJECTに一致したとは限りません。ページが開いても、関連するすべてのドメインに同じポリシーが使われているとは限りません。ログイン、画像、動画のリクエストで異なるドメインが使われることがあるため、実際の接続ごとに判定してください。

DIRECTを指定したのに、なぜPROXY経由になる？

まずHome → Global RoutingがConfigになっているか確認し、次にDIRECTの行より前にあるDOMAIN-SUFFIXなどのルールが同じ対象に一致していないか調べます。完全一致の例外を範囲の広いルールより前に移動し、保存後に接続をやり直してください。リスト内のプロキシ選択を何度も切り替えるだけでは解決しません。

ルールを末尾に追加しても変わらないのはなぜ？

現在のConfigの[Rule]を開き、FINALを探します。追加したルールがFINALの後にある場合は、FINALより前に移動してください。前にある範囲の広いルールが先に一致している場合は、相対的な位置も調整します。どの変更が結果に影響したか確認できるよう、一度に移動するルールは1つにしてください。

IP-CIDRにno-resolveを指定したのに、ドメインに一致しないのはなぜ？

判定時に利用可能な宛先IPがあるか確認してください。no-resolveは、このルールのためにドメインを積極的に名前解決するものではありません。特定のドメインに固定のポリシーを適用したい場合は、DOMAINまたはDOMAIN-SUFFIXを明示し、一般的なIPルールより前に配置してください。

REJECTを追加したらページ全体に問題が起きた。どう戻せばいい？

まずバックアップからその変更を復元するか、追加したREJECT行だけを削除してから、接続し直して確認してください。拒否されたドメインがログイン、スクリプト、リソースの配信にも使われていないか調べます。対象範囲を絞る必要がある場合は、広すぎるサフィックス指定ではなく、完全一致するDOMAINを使ってください。

更新後にルールが元に戻った場合、何を確認すればいい？

Configで現在有効なファイル、リモートの取得元、[Rule]の内容を確認し、更新によってローカルの変更が置き換えられたか調べます。保存しておいたコピーを復元してから、カスタムルールの管理方法を決めてください。接続サブスクリプションを繰り返し更新しても、設定ルールは復元されません。

確認が終わったら、結果を説明できる最小限のルールだけを残します。例外ルールにはそれぞれ明確な対象と用途を持たせ、FINALは未マッチの接続に対するフォールバックだけを担うようにしてください。画面上の用語については用語集を、接続経路が引き続き利用できない場合はトラブルシューティングを参照し、ネットワークとプロキシ接続を確認してください。むやみにルールを増やすのは避けましょう。

Shadowrocketをダウンロード