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

Shadowrocketのルール設定方法｜DOMAIN-SUFFIX・GEOIP・IP-CIDR・FINALの使い方

DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORD、GEOIP、IP-CIDR、FINALの対象と書式、上から順に判定されるルールの仕組み、PROXY・DIRECT・REJECTの意味を解説します。

この記事の要点

ルールは、まずマッチ対象を決め、次に通信先のポリシーを選び、最後に順序を確認します。Shadowrocketに自分で用意したサーバーを追加し、Configを編集する方向けに、ドメインルールとIPルールの違い、FINALを含む最小構成の書き方、接続ログで想定どおりにマッチしたかを確認する方法を解説します。例示するドメインと予約済みアドレスは構文の説明用で、接続先としては利用できません。

1. ルールが有効になる条件とマッチ順

ルールは設定ファイルの[Rule]セクションに記述します。この記事で扱う通常のルールは上から順に判定され、マッチすると、そのルールで指定したポリシーが適用されます。後ろにある「より具体的な」ルールまで判定が続くことはありません。そのため、例外ルールは範囲の広いルールより前に、FINALは末尾に置きます。

テストを始める前に、Home → Global RoutingでConfigを選び、Configで現在有効になっているファイルが編集したファイルか確認してください。ProxyやDirectを選んでいる場合、この記事のルールごとの判定結果ですべてのリクエストを説明することはできません。Sceneはシーンの選択に関わるため、最小構成のルールテストには適していません。

リクエスト先現在の設定順にマッチ判定適用ポリシー接続結果

ルールは通信の処理方法を決めるもので、サーバーの設定項目を補ったり、接続先への到達を保証したりするものではありません。PROXYにマッチしても、アドレス、ポート、認証情報が正しくなければ、自分のサーバーへの接続に失敗することがあります。テストでは「何にマッチしたか」と「接続に成功したか」を分けて記録してください。

6種類
この記事で解説するルール：DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORD、GEOIP、IP-CIDR、FINAL
3種類
この記事で使うポリシー：PROXY、DIRECT、REJECT
末尾に1行
最小構成の例では、FINALがそれまでにマッチしなかったリクエストを処理します

2. DOMAIN・DOMAIN-SUFFIX・DOMAIN-KEYWORD

ドメインルールの基本形式はルールタイプ,マッチ対象,ポリシーで、半角カンマで区切ります。マッチ対象に指定するのはホスト名で、完全なURLではありません。ドメイン欄にhttps://、パス、クエリパラメータ、:443を入力しないでください。同じホスト上の異なるページパスを、この3種類のルールで区別することはできません。

ルールマッチ範囲マッチしない例
DOMAIN,example.com,DIRECT完全一致するホスト名example.comのみwww.example.com
DOMAIN-SUFFIX,example.com,PROXYexample.comとそのサブドメイン（例：img.example.com）notexample.com
DOMAIN-KEYWORD,example,REJECTドメイン名にexampleという文字列を含む対象sample.test

DOMAIN-SUFFIXはドメインの階層に基づいてマッチします。「このドメインとすべてのサブドメイン」を指定する場合に適しています。*.example.comとは書かず、example.comをそのまま指定してください。DOMAIN-KEYWORDはより広い範囲にマッチするため、たとえばmyexample.testも対象になることがあります。関係のない接続までマッチしないか確認しましょう。

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

この単独の例では、account.example.comは1行目にマッチしてDIRECTになり、img.example.comは2行目にマッチしてPROXYになります。最初の2行を入れ替えると、アカウントのサブドメインが先にサフィックスルールにマッチし、後ろの完全一致ルールは適用されません。これは「ルールの順序」の問題であり、DOMAINの優先度がDOMAIN-SUFFIXより低いという意味ではありません。

要点：例外を先に、広い範囲を後に

同じドメイン体系で異なるポリシーを適用する場合は、個別のホストを指定するDOMAINをDOMAIN-SUFFIXより前に置きます。文字列でのマッチが必要な場合に限り、DOMAIN-KEYWORDを使ってください。

3. IP-CIDR・GEOIP・no-resolve

IP-CIDRは、接続先のIPv4アドレスが属するネットワーク範囲にマッチし、Webサイト名にはマッチしません。スラッシュの後ろの数字はプレフィックス長です。/32はIPv4アドレス1個、/24は256個のアドレスを含むネットワーク範囲を表します。ここでのアドレス数にはネットワークアドレスなども含まれ、利用可能なサーバー数と同じではありません。

IP-CIDR,192.0.2.8/32,DIRECT,no-resolve
IP-CIDR,198.51.100.0/24,REJECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

上記の192.0.2.8と198.51.100.0/24は、書式の説明に使う文書用予約アドレスです。no-resolveは、このIPルールのマッチ判定のために追加のドメイン名前解決を行わない指定です。マッチ判定時に利用できる宛先IPがすでにあれば、それに基づいて判定できます。すべてのDNSを無効にする設定でも、「ドメインとIPの両方に自動でマッチする」設定でもありません。

特定のWebサイトに指定したポリシーを適用したい場合は、明示的なドメインルールを使うと検証しやすくなります。既知のアドレスやネットワーク範囲を管理する場合は、IPルールを使います。地理データベース上の分類とサービスの実際の配置場所が異なることもあるため、GEOIPをWebサイトの識別手段として扱わないでください。

4. PROXY・DIRECT・REJECT・FINALの違い

ルール末尾のポリシーは、「マッチした後にどう処理するか」を指定します。PROXYはプロキシ経由で通信する指定ですが、実際に使うサーバーは現在の選択内容や関連設定によって異なります。DIRECTは接続先に直接接続し、REJECTはリクエストを拒否します。これらはプロトコルではなく、サーバーのType、アドレス、ポートの代わりには使えません。

記述例意味確認ポイント
DOMAIN,example.com,PROXYこのホストへの通信をプロキシ経由にするルールにマッチした後、実際に使われるサーバーを確認する
DOMAIN,example.com,DIRECTこのホストへ直接接続する現在のネットワークから接続先へ直接アクセスできるか
DOMAIN,example.com,REJECTこのホストへのリクエストを拒否する拒否が本来の意図に合っているか
FINAL,PROXYそれまでにマッチしなかったリクエストにPROXYを適用するフォールバックのポリシーが想定どおりか

FINALには「マッチ対象」フィールドがなく、形式はFINAL,ポリシーです。FINAL,example.com,PROXYのようには書きません。途中に置くと、それ以降のリクエストを先に処理するため、後続の通常ルールが想定どおりに機能しなくなります。フォールバックにDIRECTとPROXYのどちらを使うかは利用目的によって異なり、すべての設定に共通する正解はありません。

5. Configに最小構成を保存して検証する

まず元の設定を複製し、ローカルのテスト用ファイルを編集してください。以下のルール部分を、設定ファイル全体にそのまま上書きしないでください。ここに示すのは[Rule]セクションのみです。元のファイルに同セクションがある場合は、その中を編集してください。[Rule]セクションを複数作ると、設定の把握が難しくなります。

  1. 元の設定を複製する

    Configを開き、現在有効なファイルを確認します。内容をバックアップしてから、ローカルのテスト用設定を別に用意してください。テスト後に元へ戻せるよう、変更前のGlobal Routingの選択内容も記録しておきます。

  2. ルールを編集する

    Configからテストファイルの編集画面を開き、[Rule]を探して、下の最小構成例を入力します。カンマの位置、フィールド数、FINALの位置を確認してから保存してください。

  3. 設定を有効にする

    Configで保存したテストファイルを選び、次にHome → Global Routing → Configを選択します。Homeで選択されているのが、自分で用意し、接続情報も正しく設定したサーバーであることを確認してください。

  4. 新しいリクエストを送る

    接続先へのリクエストを新たに開始し、アプリの接続ログで接続先、マッチしたルール、適用されたポリシーを確認します。すでに確立している長時間接続では、変更したルールを検証できないことがあります。必要に応じて接続先のアプリを終了し、再度開いてください。

  5. ルールを1つずつ追加する

    最小構成が想定どおりに動作することを確認したら、ルールを1つ追加するごとに検証を繰り返します。結果が変わった場合は、DNS、サーバー、複数のルールを同時に変更せず、直前に追加したルールをいったん戻してください。

[Rule]
DOMAIN,account.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.8/32,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

この例では、アカウントのサブドメインに先にDIRECTを適用し、それ以外のexample.comのサブドメインにはPROXYを適用します。その後、IPルールとGEOIPを確認し、最後にFINALで残りを処理します。例示ドメインはマッチの仕組みを確認するためのものです。実際に接続テストを行う際は、自分がアクセスでき、ホスト名が明確な接続先に置き換えてください。

6. ルールが反映されない場合とtimeoutの確認手順

「ページが開けない」ことだけでは、ルールの構文エラーとは判断できません。まず現在のファイルとGlobal Routingを確認し、次に実際の接続先とマッチしたルールを見て、最後に接続先への通信を確認します。接続に失敗したからといって、すべてのルールをすぐにPROXYへ変更しないでください。マッチの問題と接続の問題を切り分けられなくなります。

エラー：timeout

原因：接続テストまたはリクエストが所定の時間内に完了しなかった状態です。この結果だけでは、原因がルール、接続先のネットワーク、使用中のサーバーのどれかは判断できません。

対処：まず、このリクエストに実際に適用されたポリシーを確認します。PROXY の場合は、Home → Connectivity Test で現在のサーバーをテストし、自分の接続先アドレス、ポート、認証情報も確認してください。

症状最初に確認する項目対処方法
すべてのリクエストが同じ方法で通信されるHome → Global RoutingがConfigになっているかConfigに戻し、現在有効なファイルを確認する
完全一致のドメインルールにマッチしない前にサフィックスルールやキーワードルールがないか優先したい完全一致ルールを前に移動する
後半のルールが適用されないFINALが途中に置かれていないかFINALを通常のルールの後ろに移動する
メインページは表示できるが、画像やAPIへの接続に失敗する失敗したリクエストが別のホスト名宛てではないかアドレスバーだけで判断せず、実際の接続先に応じてルールを追加する
IPルールが想定どおりにマッチしない実際の接続先アドレス、ネットワーク範囲、no-resolveマッチ判定時に使えるアドレス情報を確認し、ドメインの所属先とIPアドレスの所属先を同一視しない

最後にルールの記述自体を確認します。半角カンマを使い、DOMAIN-SUFFIXなどのキーワードは原文のまま残し、説明文をルール行に貼り付けないでください。DOMAINなどの3フィールド形式のルールとFINALでは、フィールド数が異なります。名前付きポリシーを追加した場合は、参照先の名前が現在の設定に存在することも確認してください。元の設定に戻して正常に動作する場合は、変更箇所を絞る手がかりになります。具体的な原因は、変更を1つずつ戻して特定してください。

App Storeの正規品を確認デベロッパ名とアプリIDを確認