2026-08-04 · ルール · 約8分

Shadowrocketのルール構文入門：DOMAIN-SUFFIX・GEOIP・FINALなどのキーワードとマッチ対象

DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORD、GEOIP、IP-CIDR、FINALのマッチ対象と記述方法、ルールを上から順に判定する仕組みを解説します。

この記事の概要

この記事は、Shadowrocketで利用するサービス提供元の設定を用意済みで、ルールによる通信の振り分けを理解・調整したい方向けです。まずドメインと接続先IPの違いを把握し、「最初に一致したルールが適用される」「FINALは最後に置く」という順序を確認します。最後にConfig、Global Routing、接続ログで結果を検証します。例はルール構文の説明用であり、接続サービスは提供していません。アプリの買い切り購入に回線プランは含まれません。

1. ルールはマッチ条件とポリシーで構成される

ルールは接続に適用する出力ポリシーを決めるもので、利用可能なプロキシ接続を作成するものではありません。一般的な記述形式は「ルールキーワード,マッチ対象,ポリシー」で、各項目は半角カンマで区切ります。FINALにはマッチ対象がないため、キーワードとポリシーの2項目だけです。設定ファイルでは、通常これらの項目を[Rule]セクションに記述します。

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

ここでDIRECTは直接接続、PROXYはプロキシポリシー経由の通信、REJECTは接続の拒否を表します。名前付きポリシーグループを使う場合、ルール末尾には現在の設定に実在するグループ名も指定できます。他の設定にあるグループ名をそのまま使うと、ポリシーの参照先が無効になることがあります。例にあるexample.comは構文の説明用で、接続先ではありません。

接続開始 接続先を特定 順に照合 ポリシーを決定 接続

これらのルールを通常の振り分けに適用するには、Home → Global RoutingでConfigを選び、Configで現在使用中の設定を確認します。ProxyとDirectは全体のルーティング方式が異なるため、ドメイン単位で振り分ける同じ想定の検証には使えません。Sceneは、そのシーンの条件に沿って別途確認してください。ファイルを編集しただけでは、現在の接続にそのファイルが適用されたことにはなりません。

2. DOMAIN系はドメインにマッチし、URLのパスにはマッチしない

URLを分解してみましょう。https://api.example.com:443/accountの場合、ホスト名はapi.example.com、ポートは443、パスは/accountです。以下の3種類のルールでは、マッチ対象にドメインまたはドメインの一部を指定します。https://、ポート、パスは含めません。ウェブページのタイトルや本文を見て接続先を判定するルールではありません。

キーワード記述例マッチ範囲
DOMAINDOMAIN,api.example.com,PROXY完全一致するホスト名 api.example.com のみ
DOMAIN-SUFFIXDOMAIN-SUFFIX,example.com,PROXYexample.com本体とそのサブドメイン
DOMAIN-KEYWORDDOMAIN-KEYWORD,example,PROXYドメイン名にexampleを含む接続先

DOMAIN：特定のホストに例外を設定

DOMAIN,api.example.com,PROXYはwww.example.comにもv2.api.example.comにもマッチしません。ログイン用APIや特定のAPI、独立したホストだけに異なるポリシーを適用したい場合は、完全一致のドメイン指定で範囲を絞れます。ドメインは実際の接続ログをもとに確認してください。ブラウザーのアドレスバーだけで、すべてのリソースのホスト名を推測しないようにしましょう。

DOMAIN-SUFFIX：ドメイン本体とサブドメインに適用

DOMAIN-SUFFIX,example.com,PROXYはexample.com、www.example.com、a.b.example.comにマッチしますが、notexample.comやexample.com.other.testにはマッチしません。任意の文字列の末尾ではなく、ドメイン階層におけるサフィックスを指定します。通常はexample.comと記述し、*.example.comと書く必要はありません。

DOMAIN-KEYWORD：範囲が広いため誤マッチに注意

DOMAIN-KEYWORD,example,PROXYはexample.comとmyexample.testの両方にマッチする可能性があります。文字列を含む範囲を対象にする必要がある場合に使います。特定のドメイン群だけが対象なら、DOMAIN-SUFFIXを優先してください。短すぎるキーワードは影響範囲を広げ、問題発生時の原因特定も難しくします。

3. GEOIPとIP-CIDRは接続先IPにマッチする

ドメインルールは名前を判定し、IPルールは接続先アドレスを判定します。ドメインがどのIPに解決されるかは、DNSの応答、ネットワーク環境、コンテンツ配信の構成によって変わります。そのため、「ドメインが特定の組織に属すること」と「接続先IPがデータベース上で特定の地域に割り当てられていること」は異なる条件であり、相互に置き換えることはできません。

GEOIP,CN,DIRECT
IP-CIDR,192.168.50.0/24,DIRECT
IP-CIDR,203.0.113.7/32,PROXY

リクエストが最初にドメイン名で指定されていた場合、IP系ルールの判定にドメイン解決が関係することがあります。一部のIP系ルールにはno-resolveを追加でき、このルールのためだけにドメイン解決を行わないよう指定します。これはDNSを無効にする設定ではなく、すべてのドメインリクエストがそのIPルールにマッチすることを保証するものでもありません。初めて設定する場合は、DNSとマッチの仕組みを把握するまで、このパラメーターを追加しないことをおすすめします。

4. 最初にマッチしたルールを適用し、FINALで残りを処理

ルールは通常、上から順に確認され、条件を満たした最初のルールでポリシーが決まります。「より正確な」ルールを探して下へ進むことはありません。DOMAINがDOMAIN-SUFFIXより自動的に優先されるわけではありません。範囲の広いルールが上にあると、それ以降の具体的な例外ルールは適用されません。

[Rule]
DOMAIN,login.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,DIRECT
接続先の条件最初にマッチする項目結果
login.example.comDOMAINDIRECT
img.example.comDOMAIN-SUFFIXPROXY
その他のドメインで、接続先IPがCNに分類される場合GEOIPDIRECT
それ以前の条件にマッチしないFINALDIRECT

FINAL,DIRECTは、他のルールにマッチしない接続を直接通信にします。FINAL,PROXYは、残りの接続をプロキシポリシーに振り分けます。どちらが優れているかではなく、既定の動作の違いです。指定したサイトだけをプロキシ経由にしたい場合は、前者が想定に合います。FINALを先頭に置くと、後続のルールはマッチする機会を失います。

5. Configでルールを編集して確認する

以下の手順は、利用可能なサービス提供元の設定をすでにお持ちであることを前提とします。ルールはポリシーの選択方法を決めますが、プロキシ接続の成否はサービスの接続パラメーターやネットワーク環境にも左右されます。変更前に元の設定を複製してください。リモート更新で上書きされる設定を使う場合は、ローカルでの変更内容が保存される場所と、次回更新時の動作をあらかじめ確認します。

  1. 現在の設定を確認

    Configを開き、現在選択されている設定ファイルを確認します。そのファイルの編集画面から[Rule]セクションを確認してください。まだ有効になっていない複製ファイルは編集しないようにします。

  2. 具体的なルールを追加

    まずDOMAIN,api.example.com,PROXYの形式でルールを追加し、必要に応じてDOMAIN-SUFFIXへ範囲を広げます。半角カンマを使い、指定したポリシー名が実際に利用できることを確認してください。

  3. Configを選択

    Home → Global Routing → Configに戻り、接続スイッチがオンになっていることを確認します。検証中はProxyやDirectに切り替えないでください。切り替えると検証条件が変わります。

  4. 新しい接続を開始

    保存後に再接続し、テストするページを開き直すか、テスト用アプリを再起動して新しいリクエストを発生させます。ルールを編集しても、確立済みの長時間接続がすぐに別の経路へ切り替わるとは限りません。

  5. 接続ログを確認

    接続ログで接続先ドメイン、接続先IP、選択されたポリシーを確認します。マッチしたルールがログに表示される場合は、それも確認してください。実際の結果を、最初にマッチするルールについての想定と1つずつ照らし合わせます。

検証では一度に変更する条件を1つにします。まず完全一致のドメインルールがマッチすることを確かめてから、サフィックスに変更するか、IP範囲を追加してください。ウェブページが開けることだけでは、想定したポリシーで通信した証明にはなりません。キャッシュ、ローカル接続、ページ内の別ドメインが判断に影響することがあります。

6. ルールの未マッチと接続失敗を切り分ける

トラブルシューティングは、まず接続で選ばれたルールを特定し、次にそのポリシーによる通信が成功したかを確認する2段階で進めます。以下はDNSやネットワークの診断でよく見られるエラーテキストです。すべての画面で同じ表記になるとは限りません。実際のログに該当する情報がある場合に、その内容に応じて確認してください。

エラー：NXDOMAIN

原因と対処：DNS検索でドメインが存在しないという応答が返されています。リクエスト先ドメインのスペルと、現在のDNS応答を確認してください。GEOIPや接続先IPが必要なルールを検証する前に、まず名前解決を解決します。FINALを変更しても、存在しないドメインに有効なアドレスが割り当てられることはありません。

エラー：Connection refused

原因と対処：接続先から接続が拒否されています。ポートで待ち受けていないか、サービス側のポリシーで拒否されている可能性があります。まずログのポリシーと接続先アドレスを確認し、利用中のサービス提供元にサーバーアドレス、ポート、プロトコルの設定を問い合わせてください。このエラーだけでDOMAIN-SUFFIXの記述ミスと判断することはできません。

エラーがなく、ログに想定外のポリシーが表示される場合は、まず次の4点を確認します。実際のホスト名が異なっていないか、前に範囲の広いルールがないか、選択中の設定が正しいか、Global RoutingがConfigになっているか。タイムアウトを解消しようとして広範囲のルールを一度に追加すると、結果を比較する手がかりが失われます。

7. ルールに関するよくある質問

DOMAIN-SUFFIXを設定しても、ログインページが正しく表示されないのはなぜですか？

ログインをやり直し、接続ログを確認してください。ログイン時に別のドメインへリダイレクトされる場合や、先にあるルールが具体的なルールを上書きしている場合があります。まずログに表示された実際のホスト名にDOMAINを設定してテストし、その後、サフィックスの範囲を広げるか判断します。

GEOIP,CN,DIRECTですべてのドメインルールを置き換えられますか？

いいえ。接続先IPのデータベース上の割り当てを判定するルールであり、ウェブサイトの内容や用途は判定しません。特定のドメインに基づいてポリシーを選びたい場合は、対応するDOMAINまたはDOMAIN-SUFFIXルールをGEOIPより前に置いてください。

サブスクリプションを更新しても、ルールが変わらないように見えるのはなぜですか？

接続情報のサブスクリプションと、Configにあるルールファイルは別のものです。まずConfigで現在のファイルの[Rule]の内容を確認してください。Homeの接続先リストの更新が成功したことを、ルールも更新された根拠にしないようにしましょう。

On Demandを有効にすると、ルールは自動で修正されますか？

いいえ。Settings → On Demandは、条件に応じて接続を開始する機能であり、ルールの並べ替えやドメイン範囲の選択は行いません。ルールを確認するには、引き続きConfigの内容とHome → Global Routingで選択中の方式を確認してください。

FINALをPROXYに変更すれば、プロキシが正常か確認できますか？

いいえ。FINALは、他のルールにマッチしなかったリクエストに適用するポリシーを指定するだけです。接続が実際にPROXYを使っていることを確認してから、利用中のサービス提供元の設定と通信結果を確認してください。テスト後は、普段の利用目的に合ったフォールバックポリシーに戻します。

App Storeでダウンロード