2026年10月14日 · ルールと設定 · 約10分

Shadowrocketのルール設定入門｜DOMAIN-SUFFIX・DOMAIN-KEYWORD・GEOIP・IP-CIDR・FINALのマッチ範囲

DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORD、GEOIP、IP-CIDR、FINALのマッチ対象を、ルール例やよくある記述ミスとあわせて解説します。

この記事の概要

Shadowrocketのルールは、まず「何にマッチさせるか」を決め、次に「どのポリシーを適用するか」を指定します。利用可能な設定があり、ルーティングの対象範囲を調整したい方に向けて、ドメインルールとIPルールの違い、例外を上から順に並べる方法、接続ログで結果を確認する手順を説明します。例はルールの構文のみを示すもので、接続サービスは提供しません。プロキシ接続を利用する場合は、すでにお持ちのサービスとサブスクリプションを使用することを前提としています。

1. ルールの基本形式：タイプ、マッチ値、ポリシー

一般的なルールは、ルールタイプ、マッチ値、ポリシーの3項目で構成され、半角カンマで区切ります。設定ファイルの[Rule]セクションに記述します。FINALはマッチ値が不要なため、項目は2つだけです。ルールを追加する前に構文を確認すると、問題の箇所を特定しやすくなります。

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

DIRECTは直接接続、PROXYはプロキシポリシーの適用、REJECTはマッチした接続の拒否を表します。ポリシー欄には、設定内に実在するポリシー名も指定できますが、名前は完全に一致させてください。ここでは、未定義の名前が例に混ざらないよう、組み込みのポリシー名を使用します。

リクエスト開始 宛先を確認 順番にマッチ ポリシーを決定 接続を確立

2. DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORDのマッチ対象

この3種類のルールが確認するのはドメインであり、WebページのURL全体ではありません。https://やポート番号、パスを含めず、example.comのように指定します。ページ本体、画像、APIがそれぞれ異なるドメインにアクセスする場合があります。同じページに表示されていても、1つのドメインルールですべての接続が対象になるわけではありません。

ルールマッチ範囲マッチしない例
DOMAIN,example.com,DIRECTexample.comのみマッチwww.example.com
DOMAIN-SUFFIX,example.com,DIRECTexample.comとそのサブドメインにマッチ（例：a.b.example.com）notexample.com
DOMAIN-KEYWORD,example,DIRECTドメインにexampleを含むリクエストにマッチドメインがsample.testで、URLパスにだけexampleを含むリクエスト

DOMAIN-SUFFIXはドメインの階層境界に基づいてマッチし、任意の文字列の末尾を照合するものではありません。通常はexample.comと記述し、*.example.comとは書きません。api.example.comだけを個別に扱う場合は、DOMAINを使うと対象を明確にでき、配下の別のサブドメインまでマッチすることもありません。

DOMAIN-KEYWORDはより広い範囲にマッチします。exampleを指定すると、対象サイトだけでなく、同じ文字列を含む別のドメインにもマッチする可能性があります。正規表現ではないため、正規表現の記号をマッチ構文として使わないでください。特定のドメインとそのサブドメインだけを扱う場合は、要件に合ったサフィックスルールを使うのがおすすめです。

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

この例では、api.example.comは1行目に、ほかのexample.comのサブドメインは2行目にマッチします。3行目は、まだマッチしていないリクエストのドメインにtelemetryが含まれるかを確認します。先にマッチした2行のポリシーが後から上書きされることはありません。

3. IP-CIDRとGEOIP：URLの文字列ではなく宛先IPを確認

IP-CIDRはIPv4のネットワーク範囲にマッチします。スラッシュの後の数字はネットワークプレフィックス長で、ポート番号ではありません。192.168.1.0/24は192.168.1.0から192.168.1.255までの範囲を表し、/32はIPv4アドレス1つだけを表します。IPv6のネットワーク範囲には、対応するIP-CIDR6タイプを使います。

[Rule]
IP-CIDR,192.168.1.0/24,DIRECT,no-resolve
IP-CIDR,192.0.2.8/32,DIRECT,no-resolve
IP-CIDR6,2001:db8::/32,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

192.0.2.8と2001:db8::/32は文書用の例示アドレスであり、接続先として利用できるサービスではありません。192.168.1.20:8080にアクセスする場合、ネットワークルールが確認するのは192.168.1.20で、ポート8080だけをマッチさせるわけではありません。CIDRのマッチ値にポート番号を含めると、異なる条件が混同されます。

項目・タイプ意味確認ポイント
IP-CIDR宛先IPv4が指定したネットワーク範囲に含まれるかネットワークアドレスとプレフィックス長を指定し、URLは入力しない
GEOIP,CN使用する地理データベースで、宛先IPがCNに分類されるかドメインのサフィックス、Webページの言語、端末の位置では判定しない
no-resolveこのIPルールを確認するために、ドメインの名前解決を自動的に行わないすべてのDNSを無効にするわけではなく、ドメインのリクエストが必ずマッチするという意味でもない

ドメインリクエストをIPタイプのルールで判定するには、判定可能な宛先IPが必要です。ルールのマッチ時に名前解決が行われるかどうかは、ルールオプションとリクエストの状況によって異なります。no-resolveを付けた場合、その時点で利用できる宛先IPがなければ、このネットワークルールをドメイン全体に適用することはできません。特定のドメインに確実に適用したい場合は、明示的なドメインルールを追加すると確認しやすくなります。

GEOIPの判定結果は、使用するIP地理データベースに依存します。1つのドメインが複数のアドレスに解決される場合があり、アドレスの地域判定も変わることがあります。そのため、DOMAIN-SUFFIXとは用途が異なります。特定のドメインに常に指定のポリシーを適用するには、汎用的なGEOIPルールより前にドメインの例外を置いてください。

4. 上から順にマッチ：FINALを最後に置く理由

通常のルールは記述順に確認され、最初にマッチしたルールのポリシーが適用されます。「より具体的なルールが自動的に優先される」という並べ替えの仕組みはありません。個別の例外を先に置き、範囲の広いルールをその後に配置し、これまでにマッチしなかったリクエストを処理するFINALは末尾に置きます。

[Rule]
DOMAIN,api.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.1.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

サフィックスルールを1行目に移すと、api.example.comが先にマッチし、その下にあるドメイン単位の例外が機能しなくなります。同様に、FINAL,DIRECTを先頭に置くと、後続のルールが通常どおりマッチ判定されません。順序を変更したら、新しい接続で結果を確かめてください。すでに確立された接続のページを再読み込みするだけでは不十分です。

5. Configの変更後に行う4つの確認

問題を調べるときは、一度に変更する条件を1つに絞ります。まず、現在使用している設定を編集したか確認し、次にHomeのルーティングモードを確認してから、新しい接続の宛先とポリシーを調べます。画面上部の接続スイッチがオンになっているだけでは、指定したルールにマッチしたとは判断できません。

  1. 元の設定を保存する

    Configを開いて現在使用中のファイルを確認し、先にコピーを保存します。そのファイルのテキスト編集画面を開き、[Rule]セクション内を編集してください。[Host]など、ほかのセクションにルールを追加しないでください。

  2. 個別ルールを追加する

    必要なDOMAINの例外を、対応するDOMAIN-SUFFIXより前に置き、ファイル末尾のFINALは残します。保存後、Configで変更後のファイルが選択されていることを確認してください。

  3. Configを選択する

    Home → Global Routing → Configに戻り、接続状態を確認します。PROXYを使用する場合は、Home → Connectivity Testで既存サービスへの接続状況を確認してください。ただし、テスト結果だけではルールにマッチした証明にはなりません。

  4. 新しい接続を確認する

    対象へのリクエストを再度実行し、アプリ内の接続ログで実際のドメイン、宛先IP、適用されたポリシーを確認します。ページが複数のドメインにアクセスする場合は、それぞれを個別に確認してください。画像のリクエスト結果をページ本体のリクエスト結果と混同しないようにします。

ログに想定したドメインが表示されない場合は、ルールの範囲をすぐに広げず、リダイレクト、APIのドメイン、IPアドレスへの直接アクセスを確認します。リクエストが既存の接続を引き続き使用している場合は、対象のページやアプリを閉じてから再度リクエストしてください。必要に応じてShadowrocketの接続を再確立します。再現可能な新しいリクエストで確認すると、「ルールにマッチしていない」のか「既存の接続がまだ更新されていない」のかを切り分けられます。

6. よくある記述ミスとルール以外のエラー

構文エラー、マッチ範囲の誤り、サービスの利用不可は、それぞれ別の問題です。ルールはポリシーを決めるもので、サブスクリプションURLやプロキシ接続のパラメータを修正するものではありません。まずテキストから確認できる問題を調べ、その後、ルールとは関係のない取得エラーに対処します。

誤った記述・状態問題点修正方法
DOMAIN,https://example.com/a,DIRECTURL全体をドメインとして指定しているDOMAIN,example.com,DIRECTに変更します。パスは判定対象になりません。
DOMAIN-SUFFIX,*.example.com,DIRECTサフィックスのマッチ値にワイルドカードを含めているDOMAIN-SUFFIX,example.com,DIRECTに変更します。
IP-CIDR,192.168.1.20:8080,DIRECTポート番号が含まれており、CIDRプレフィックスもない単一アドレスは192.168.1.20/32と記述します。このルールではポートを指定しません。
FINAL,example.com,PROXYFINALにマッチ値を余分に指定しているFINAL,PROXYに変更し、ルールの末尾に置きます。
全角カンマで項目を区切っている項目の区切り文字が正しくない半角カンマに置き換え、ルールが[Rule]内にあることを確認します。

エラー：Failed to load subscription

原因と対処：これはサブスクリプションの読み込み失敗を示すメッセージです。URLの無効化やアクセス失敗などが原因として考えられ、特定のDOMAIN-SUFFIXルールの構文エラーを示すものではありません。まず契約中のサービス提供元にサブスクリプションURLが有効か確認し、Homeから更新してください。ルールの確認は、項目が利用可能で設定が有効になってから別途行います。

リモートで管理されている設定を編集した場合、次回の更新でローカルの変更が上書きされることがあります。ファイルの取得元と更新方法を確認し、ローカルのコピーを残しておきましょう。確認したルールが更新内容で置き換わるのを防げます。サブスクリプション項目の更新と[Rule]セクションの編集は別の操作です。ルールの確認の代わりにサブスクリプションを繰り返し更新しないでください。

7. ルールのマッチに関するよくある質問

DOMAINを設定したのに、サブドメインに適用されないのはなぜですか？

DOMAINはドメイン名全体にのみマッチします。example.comとそのサブドメインを対象にするには、DOMAIN-SUFFIX,example.com,DIRECTを使います。特定のサブドメインだけ例外にする場合は、対応するDOMAINルールを先に置いてください。

GEOIP,CNを使えば、中国語のWebサイトはすべて直接接続されますか？

Webページの言語では判定できません。GEOIPはIP地理データベース上の地域情報を確認します。まず接続ログで実際の宛先IPを調べ、特定のドメインを明示的に扱いたい場合は、GEOIPより前にドメインルールを追加してください。

ルールの記述が正しいのに、すべて同じポリシーになるのはなぜですか？

まずHome → Global RoutingがConfigになっているかを確認し、次にConfigで有効なファイルを確認します。その後、より広い範囲にマッチするDOMAIN-KEYWORDや、早い位置にあるFINALがないかを調べ、最後に新しい接続のログを確認してください。

no-resolveを使うと、すべてのドメインが名前解決されなくなりますか？

いいえ。これは対応するIPルールの判定のために行われる名前解決を制限するオプションです。特定のドメインを直接接続したい場合は、明示的なDOMAINまたはDOMAIN-SUFFIXを使ってください。ドメインのマッチ指定の代わりにno-resolveを使うことはできません。

App Storeでダウンロード