2026年8月21日 · ルールと振り分け · 約8分

Shadowrocketのルール設定方法｜DOMAIN・DOMAIN-SUFFIX・GEOIP・IP-CIDR・FINALのマッチング入門

6種類のルールキーワードの対象と範囲、上から順に評価して最初の一致で処理を決める仕組み、FINALを最後に置く理由を解説します。

この記事の概要

Shadowrocketのルールは、リクエストが条件に一致するかを判定してから、適用するポリシーを決めます。自分のサービス情報を用意し、Configを編集するユーザー向けに、まず6種類のキーワードを確認し、「具体的な例外を先に、広い条件を後に、FINALを最後に」並べる方法と、新しい接続で結果を確認する手順を説明します。例は構文とマッチング範囲の解説に限り、サービス情報は提供しません。

1. ルールの書式：マッチタイプ・対象・ポリシー

一般的なルールは設定ファイルの[Rule]セクションに記述します。FINALなどの特殊な形式を除き、通常は「キーワード、マッチ対象、ポリシー」の3項目を英語のカンマで区切って1行に記述します。ドメインの対象にはホスト名のみを指定し、プロトコルの接頭辞、Webページのパス、ポート番号は含めません。

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

DIRECTは直接接続、PROXYはプロキシポリシーに渡すこと、REJECTは一致したリクエストを拒否することを表します。ルールが決めるのは処理の方向だけで、サーバーを作成したり、認証情報を補ったりするものではありません。PROXYを使う前に、Homeで自分が登録済みのサーバーとその接続状況を確認してください。カスタムのポリシーグループを使う場合は、ルール末尾の名前を設定内の定義と一致させます。

6種類
この記事で解説するルールキーワード。対応する種類すべてではありません
3項目
一般的な形式：キーワード、マッチ対象、ポリシー
2項目
フォールバック形式：FINAL、ポリシー

要点：まずマッチ対象を正しく指定する

ホスト名を1つだけ対象にするならDOMAINを使います。ドメイン全体とサブドメインを対象にする必要がある場合に限り、DOMAIN-SUFFIXに範囲を広げましょう。最初から範囲の広いキーワードマッチを使うのは避けてください。

2. DOMAIN・DOMAIN-SUFFIX・DOMAIN-KEYWORDの違い

この3種類のルールはいずれもドメインを対象としますが、マッチする範囲が異なります。DOMAINは完全なホスト名に一致し、DOMAIN-SUFFIXは指定したドメイン自体とそのサブドメインに一致します。DOMAIN-KEYWORDはドメイン名に指定した文字列が含まれるかを確認します。Webアドレスのフィルターではないため、/video/のようなパスで同じホスト上のページを区別することはできません。

ルール例一致する一致しない／注意点
DOMAIN,example.com,PROXYexample.comwww.example.comは含まれない
DOMAIN-SUFFIX,example.com,PROXYexample.com、www.example.com、a.b.example.comnotexample.comには一致しない
DOMAIN-KEYWORD,example,PROXYexample.com、myexample.net対象サイトと関係のないドメインまで一致する可能性がある

たとえばログイン用のエンドポイントだけを直接接続し、同じドメインのほかのリクエストをプロキシ経由にする場合は、DOMAIN,account.example.com,DIRECTをDOMAIN-SUFFIX,example.com,PROXYより前に置きます。ここで優先されるのはルールの順序であり、「完全なドメイン名のほうが自動的に優先される」わけではありません。

3. GEOIPとIP-CIDR：宛先IPの地域とアドレス範囲で判定

GEOIPは、地理情報データベース上での宛先IPの所属地域に基づいてマッチします。たとえばGEOIP,CN,DIRECTは、データベースでCNに属すると判定された宛先をDIRECTに渡す設定です。Webページの言語、ドメインの末尾、サーバー運営者の所在地を判定するものではありません。また、データベースの情報は実際の物理的な所在地をリアルタイムに示すものではありません。

IP-CIDRはIPv4アドレスの範囲に一致します。192.168.1.0/24は192.168.1.0から192.168.1.255までを対象とし、ルールの範囲を示す例として使えます。実際のローカルネットワークでデバイスに割り当てられるアドレスは、ネットワーク設定にも左右されます。IPv6の範囲にはIP-CIDR6を使い、IPv6アドレスをIPv4の例に記述しないでください。

[Rule]
IP-CIDR,192.168.1.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

ドメインルールとIPルールを併用する場合は、明確なドメインの例外を先に置き、その後に広い範囲のIP地域判定ルールを配置します。これにより、名前解決されたアドレスの地域判定によって、意図せず別のポリシーが先に適用されるのを防げます。同じドメインでもDNSが返すアドレスは変わることがあるため、GEOIPの判定結果も宛先アドレスに応じて変わる場合があります。

4. 上から順に評価し、最初の一致で終了：FINALを最後に置く理由

通常のルールリストでは、リクエストは記載順に照合され、最初に一致したルールのポリシーが適用されます。その後にある「より具体的な」ルールを探すことはありません。FINALにはドメインやアドレスの条件がなく、それまでに一致しなかったリクエストを受け取るため、必ずルールリストの最後に置きます。

[Rule]
DOMAIN,account.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.1.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,DIRECT
  1. account.example.comにアクセス：1行目に一致してDIRECTが適用され、後続のサフィックスルールは評価されません。
  2. images.example.comにアクセス：1行目には一致せず、2行目に一致してPROXYが適用されます。
  3. 宛先アドレス192.168.1.20にアクセス：ローカルネットワークのアドレス範囲に一致し、DIRECTが適用されます。
  4. その他のリクエスト：まずGEOIPで判定し、それにも一致しない場合は最後にFINALで指定したDIRECTが適用されます。

サフィックスルールを完全なドメイン名の例外より前に置くと、account.example.comにも先にPROXYが適用されます。FINAL,DIRECTを先頭に置けば、通常のリクエストを後続のルールで処理できません。「指定したWebサイトだけをプロキシ経由にする」には、ドメインルールで対象を列挙し、最後にFINAL,DIRECTを置きます。それ以外のリクエストもプロキシ経由にする場合は、明示的にFINAL,PROXYへ変更してください。2つの設定では影響範囲が異なります。

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

ファイルにルールを書いただけでは、その設定が有効になったとは限りません。現在選択中の設定ファイルと、HomeのGlobal Routingを両方確認してください。設定ファイルのルールを使う場合はConfigを選びます。ProxyとDirectでは、この記事のルールリストを項目ごとに検証できません。Sceneはシーンの選択に関わるため、基本的なルールを個別にテストする用途には適しません。

  1. 元の設定を残す

    Configを開き、まず現在のファイルのコピーを保存するか、元のテキストを控えてください。編集対象が現在使用中のファイルであり、同じ名前の別ファイルではないことを確認します。

  2. ルールセクションを編集する

    Configで対象ファイルを選び、Edit Plain Textを開いて[Rule]を探します。具体的な例外を先に置き、必要なFINALのフォールバックは最後に1つだけ残してください。ファイル内のほかの必要な設定セクションも保持します。

  3. 保存して選択する

    変更を保存してConfigに戻り、編集したファイルが選択されていることを確認します。リモート設定を再度更新するとローカルの変更が上書きされることがあるため、テスト前に自分で追加したルールのテキストを保存しておいてください。

  4. モードを確認する

    Home → Global Routing → Configに戻り、自分のプロキシサーバーも確認します。サブスクリプションの更新は登録済みのサービス情報を更新するもので、ローカルルールを自動で作成・有効化するものではありません。

  5. 新しい接続で確認する

    保存後に接続を確立し直してから、対象へのリクエストを送信します。接続ログで対象ホスト、宛先IP、実際に適用されたポリシーを確認してください。ページが開くかどうかだけで、ルールに一致したと判断しないでください。

確認時は、一度に変更する条件を1つに絞ります。たとえば、まず完全なドメイン名を1つDIRECTにし、結果を確認してからDOMAIN-SUFFIXに範囲を広げます。ブラウザーのキャッシュ、既存の長時間接続、Webサイトが利用する別のリソースドメインが、確認結果に影響することがあります。再リクエストで実際にネットワーク接続が発生していることを確認してください。キャッシュされたページだけでは、新しいルールが使われた証拠になりません。

6. ルールが適用されない場合とネットワークエラーを切り分ける

「Webページが開かない」という症状だけで、ルール構文の誤りとは判断できません。まずリクエストに実際に適用されたポリシーを確認し、その後DNSと接続の状態を調べます。以下はAppleのネットワーク層で返されることがある英語のエラー文です。アプリやシステムではローカライズされた文言で表示される場合があり、Shadowrocketに毎回まったく同じ表示が出るとは限りません。

エラー：The request timed out.

原因と対処：制限時間内にリクエストが完了しませんでした。宛先に到達できない、または選択したサーバーに接続できない可能性があります。まず接続ログでDIRECTかPROXYかを確認し、それぞれの接続経路を調べてください。すぐにルールの範囲を広げるのは避けましょう。

エラー：A server with the specified hostname could not be found.

原因と対処：対象のホスト名を名前解決できませんでした。ドメイン名の入力と、現在の設定でのDNSを確認してください。名前解決が復旧したら、GEOIPやIP-CIDRの判定に必要な宛先アドレスが得られているかを確認します。

確認された現象まず確認する項目次に行うこと
すべてのリクエストが同じポリシーになるGlobal RoutingがConfigになっているか、FINALを先頭に置いていないかモードまたは順序を修正して、新しい接続を確立する
メインサイトは想定どおりだが、画像は異なる画像のリクエストで別のホスト名が使われていないか接続ログを見て実際のリソースドメインを追加し、安易なキーワード指定は避ける
完全なドメイン名の例外に一致しない前に、より広いDOMAIN-SUFFIXまたはDOMAIN-KEYWORDがないか具体的な例外を広い範囲のルールより前に移動する
IPルールがドメイン宛てのリクエストに一致しない宛先IPを利用できるか、no-resolveを使っているかDNSの名前解決の問題と、ルール条件に一致しない問題を切り分ける

要点：新しいリクエストで3項目を確認する

変更するたびに「対象ホスト、実際に適用されたポリシー、該当ルールの順序」を記録してください。リクエストが想定したポリシーに進んだことを確認してから、その経路の接続問題を調べます。接続できない問題とルールに一致しない問題を混同しないでください。

App Storeで正規品を確認