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

Shadowrocketのルール構文入門：DOMAIN-SUFFIX・GEOIP・IP-CIDR・FINALのマッチング

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

この記事の概要

Shadowrocketのルールは、接続に適用するポリシーを決めるもので、利用可能なサーバーを提供するものではありません。サーバーのインポートを済ませ、Configで通信を振り分けたい方に向けて、Global Routingと構成ファイルの違い、6つのルールキーワード、最小限の例を使ったマッチ順序・DNSの条件・実際の接続先を解説します。ドメイン名とアドレスの例は構文の説明用であり、利用可能な接続先ではありません。

1. まずConfigを選択し、ルールの適用を確認する

Shadowrocketのルールは、接続を開始すれば必ず1行ずつ適用されるわけではありません。まずHomeでGlobal Routingを確認します。現在の構成ファイル内のルールを使うにはConfigを選択してください。続いてConfigで、編集した構成ファイルが実際に有効になっているか、同じ名前の別ファイルが選ばれていないかを確認します。

選択肢用途ルール確認時の注意点
Config現在の構成に従って振り分けこの記事のルール例を検証する際の前提です。
Proxyすべての通信をプロキシ経由で接続この状態では、特定のルールがDIRECTを選択したか検証できません。
Directすべての通信を直接接続この状態では、PROXYルールが正しく動作するか判断できません。
Sceneシーンに応じて設定を適用シーンが切り替わっていないか先に確認し、ルールが効かない状態と混同しないようにします。

Homeではサーバーの選択と接続、Configでは構成ファイルの管理、Settingsではアプリの設定を行います。Settings → On Demandは条件に応じた接続の動作に影響しますが、DOMAIN-SUFFIXのポリシーを自動で別のものに変える機能ではありません。トラブルシューティングでは「接続が確立するか」と「確立後にどのルールが適用されるか」を分けて確認し、異なる種類の設定を同時に変更しないでください。

2. ルールは上から順に判定され、最初の一致でポリシーが決まる

一般的なルール行は英語のカンマで区切り、「ルールタイプ、マッチ対象、ポリシー」の順に記述します。マッチ対象を持たないFINALは「FINAL、ポリシー」の形式です。ルールは記載順に判定され、一致した時点でそのポリシーが適用されます。後続のより具体的に見えるルールまで判定されることはありません。そのため、「具体的な例外を先に、広い範囲のルールを後に、FINALを最後に」という順序が重要です。

接続情報上から順に判定最初の一致ポリシーを選択接続先へ送信 
DOMAIN,api.example.com,PROXY
DOMAIN-SUFFIX,example.com,DIRECT
FINAL,PROXY

この3行の場合、api.example.comは1行目に一致してPROXYが選ばれます。www.example.comは1行目には一致しませんが、2行目に一致するためDIRECTが選ばれます。2行目を1行目より前に移すと、api.example.comも先にサフィックスルールに一致し、元の個別例外が適用されません。順序を誤っても必ず構文エラーになるとは限りませんが、判定結果は変わります。

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

ドメインルールがマッチするのは、接続で利用できるドメイン情報であり、ウェブページの完全なURLではありません。マッチ対象にはプロトコル、ポート、パス、クエリパラメーターを含めないでください。たとえば/accountというパスのページにアクセスする場合も、DOMAINが判定するのはホスト名だけです。同じホスト上の2つのページを区別することはできません。

キーワードと例マッチする対象マッチしない対象・注意点
DOMAIN,example.com,DIRECTexample.comwww.example.comは含まれません。
DOMAIN-SUFFIX,example.com,PROXYexample.com、www.example.com、a.b.example.comnotexample.comは含まれません。サフィックス判定ではドメインラベルの境界が考慮されます。
DOMAIN-KEYWORD,metrics,REJECTドメイン名にmetricsを含む接続マッチ範囲が広く、metricsという名前のサブドメインだけに限定されません。

api.example.comだけをプロキシ経由にする場合は、apiをDOMAIN-KEYWORDに指定するのではなく、DOMAINを使ってください。後者では無関係なドメインまで対象になる可能性があります。1つのドメインとそのすべてのサブドメインを対象にする場合は、DOMAIN-SUFFIXを選びます。ここで説明したサフィックス構文の代わりに、ワイルドカードの*.example.comを使わないでください。

4. IP-CIDR・GEOIPとDNSの関係

IP-CIDRはアドレスのネットワーク範囲で、GEOIPはIPの地理情報データベース上の所属情報でマッチします。判定対象はいずれもアドレス情報であり、ウェブページの言語、アカウントの地域、ドメイン末尾の国・地域コードではありません。ドメインに特定の国・地域コードが使われていても、それだけでGEOIPのどの地域コードに一致するかは判断できません。

IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

192.0.2.0/24は文書用のサンプルネットワークです。/24は先頭24ビットがネットワークプレフィックスであることを示し、192.0.2.0から192.0.2.255までが範囲に含まれます。これは利用可能なサーバーアドレスではありません。IP-CIDRはアドレス範囲全体にマッチするため、192.0.2.0という文字列だけを判定するものではありません。IPv6のネットワークには対応するIP-CIDR6ルールタイプを使用し、IPv4の例にIPv6アドレスを無理に記述しないでください。

ドメインルールに一致せず、後続のIPルールにアドレス情報が必要な場合は、DNSの状態が判定に影響することがあります。GEOIPの結果も実際の接続先アドレスとデータベースの内容によって異なり、特定のウェブサイトの全リソースが対象になるとは限りません。確認時は「アプリが開かない」だけでなく、対象ドメイン、実際のアドレス、適用されたポリシーを記録してください。

5. 最小限のルールセットでFINALとポリシーの結果を確認する

以下はルールの読み方や動作を試すための一通りの例であり、あらゆるネットワーク向けの設定推奨ではありません。変更前に現在の構成とサーバー設定を残し、コピー上でルールを調整してください。[Rule]だけの断片を、接続に必要なパラメーターをすべて含む新しい構成ファイルとして扱わないでください。

[Rule]
DOMAIN,blocked.example.com,REJECT
DOMAIN,api.example.com,PROXY
DOMAIN-SUFFIX,example.com,DIRECT
DOMAIN-KEYWORD,metrics,REJECT
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

metrics.example.comも拒否する場合は、サフィックスルールより前に、個別のDOMAIN例外を追加できます。キーワードルール全体を前に移動すると、metricsを含むすべてのドメインが先に拒否される可能性があります。変更前に対象範囲を明確にし、「個別の例外を追加する」か「範囲の広いルールを移動する」かを選んでください。1つのドメインを修正するために、影響範囲を広げないようにしましょう。

6. 現在の構成を編集して動作を確認する

  1. 元の構成を残す

    Configを開き、まず現在使える構成のコピーを保存してから、変更するファイルの編集画面を開きます。元に戻せるよう、ファイル名と元のGlobal Routingの設定を記録してください。

  2. ルール部分を確認する

    構成ファイル内で[Rule]を探し、英語のカンマで区切って1行ずつ編集します。個別の例外は該当する範囲の広いルールより前に置き、FINALは最後に配置してください。順序を整理する代わりに、[Rule]のセクションを複数貼り付けないでください。

  3. 構成を有効にしてモードを選ぶ

    保存後、Configでこのファイルが選択されていることを確認します。Home → Global Routing → Configに戻り、Configを選択してください。ファイルを保存しただけでは、変更を検証できません。

  4. 接続先を確認する

    Homeで既存のサーバーを選択し、Connectivity Testを実行して、プロキシ経由で接続できる状態か先に確認します。サーバーとサブスクリプションの情報は利用中のサービス提供元から取得してください。ルールの記述だけでは、これらのパラメーターを補えません。

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

    対象へのリクエストを新たに開始し、アプリの接続記録で接続先、マッチしたルール、出力ポリシーを確認します。一度に変更するのは1項目だけにしてください。古い接続が再利用される場合は、必要に応じて古いリクエストを停止してから再接続し、テストしてください。

Connectivity Testで確認できるのは接続の可否であり、特定のウェブサイトに指定したルールが適用された証明にはなりません。ルールの検証には、個々のリクエストの記録を使ってください。また、サーバーのサブスクリプションとルールの構成は別々に確認します。Homeのサーバーリストを更新しても、現在のConfig内のルールが更新されるわけではありません。リモート構成を再更新した後は、ローカルでの変更が保持されているかも確認してください。

7. ルールの誤りと接続先の問題を切り分ける

ルールがPROXYに一致していても、ウェブページが開かないからといって、構文エラーとは限りません。以下は接続ログによく表示されるネットワークエラーの一部です。エラー全文にアドレス、ポート、低レベルの詳細が含まれる場合は、接続先への接続段階とプロキシサーバーへの接続段階のどちらで発生したかをまず確認してください。

エラー：connection refused

原因と対処：接続先のエンドポイントが接続を拒否しています。対象ポートで待ち受けていない場合や、明示的に拒否された場合によく発生します。まず接続記録で失敗したエンドポイントを確認し、該当するサーバーまたは接続先サービスのアドレスとポートを調べてください。FINALの位置を変更するだけでは解決できません。

エラー：i/o timeout

原因と対処：制限時間内にネットワーク処理が完了しませんでした。まずHomeのConnectivity Testで選択中のサーバーを確認し、次に対象リクエストがDIRECTとPROXYのどちらを通ったかを確認して、それぞれ直接接続経路またはプロキシ経路を調べてください。

たとえばサービス提供元からサーバーポートとして443が指定されている場合、サーバー設定のポートが実際に443になっているか確認してください。ルールの例に443が出てくるという理由だけで、元のポートを置き換えないでください。DOMAIN-SUFFIX自体にポートの指定はなく、サーバーの待ち受けポートとドメインのマッチ条件は別の層に属します。

8. ルール設定についてよくある質問

DOMAINを設定したのに、別のポリシーが適用されるのはなぜですか？

まずHome → Global RoutingでConfigが選ばれているか確認し、次にConfigで有効なファイルを確認してください。その後、対象ルールより前にあるルールを上から確認します。特に先行するDOMAIN-SUFFIX、DOMAIN-KEYWORD、FINALに注意してください。前のルールに一致した接続は、それ以降のルールでは判定されません。

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

できません。GEOIPは接続先IPのデータベース上の所属情報で判定するため、同じサービスでも異なる地域のリソースが使われることがあります。特定のドメインに適用するポリシーを固定するには、明示的なDOMAINまたはDOMAIN-SUFFIXをGEOIPより前に置き、接続記録で結果を確認してください。

サブスクリプションを更新したのに、ルールが古いままなのはなぜですか？

まず更新した対象を確認してください。Homeのサーバーサブスクリプションの更新は、主にサーバー項目に反映されます。ルールは現在のConfigから読み込まれます。Configで実際の内容と有効状態を確認し、サーバー名が変わったことだけをルール更新の根拠にしないでください。

FINALをDIRECTに変えれば接続を直せますか？

変更されるのは、先行ルールに一致しなかった接続のデフォルトの出力先だけです。サーバーパラメーターやDNSの問題は解決できません。まず対象が実際にFINALに一致しているか確認してください。特定のドメインだけに例外が必要なら、すべての未一致接続の動作を変えるのではなく、範囲を明確にしたルールを追加してください。

App Storeで正規版を入手デベロッパー名とアプリIDを確認