2026年9月28日 · ルール応用 · 約8分

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

Shadowrocketのルールを実例で解説。DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORD、GEOIP、IP-CIDR、FINALのマッチ範囲と、上から順に判定される仕組みを紹介します。

この記事のポイント

Shadowrocketのルールは、接続先をどのように決めるのでしょうか？まずHome → Global RoutingでConfigを選択し、「マッチ条件・ポリシー・適用順序」の3つを確認します。自分で用意したサーバーやサブスクリプションがあり、設定を調整したい方に向けて、ドメインルールとIPルールの違い、範囲を限定した例外ルールの書き方、リクエストログで変更を確認する方法を解説します。

ルールが適用されるモードは？まずGlobal Routingを確認

ルールを正しく書けば、必ず適用されるのでしょうか？そうとは限りません。まずHome → Global Routingを確認してください。この記事ではConfigモードを扱います。接続は現在選択中の設定ファイルに基づいてルール判定されます。ProxyまたはDirectに切り替えている場合、個々のルール判定だけではすべての接続を説明できません。Sceneの場合は、選択中のシーンの設定を確認してください。

モード主な用途テスト前の確認事項
Config現在の設定ファイルにあるルールに従って接続を振り分けます。Configで選択中のファイルが、今回編集したファイルか確認します。
Proxy接続をプロキシ経由で処理します。選択中のサーバーと接続パラメータが有効か確認します。
Direct接続を直接処理します。現在のネットワークから接続先に直接アクセスできるか確認します。
Sceneシーンの設定に従って接続を処理します。使用中のシーンと、そのシーンに設定されている内容を確認します。

ルールでサーバー情報を補えますか？できません。ルールは接続ポリシーを選択するもので、接続先サーバーを作成したり、サービス提供元のパラメータを修正したりするものではありません。この記事は、利用可能な接続がすでにあることを前提としています。ノードやサブスクリプション、サービス提供元の情報を提供・販売・推奨するものではありません。変更前に元の設定を保存し、接続性の問題と振り分けの問題を混同しないようにしましょう。

ルールの1行を読むには？マッチ条件とポリシーに分けて確認

カンマの前後には何が書かれていますか？一般的なルールは「ルールキーワード、マッチ値、ポリシー」の順で記述します。次の1行目は、接続先ドメインが example.com と完全一致した場合に DIRECT を使う指定です。2行目の FINAL にはマッチ値がなく、フォールバックポリシーを指定します。

[Rule]
DOMAIN,example.com,DIRECT
FINAL,PROXY

DIRECTやPROXYはドメインですか？いいえ、ここではポリシーを表します。DIRECTは直接接続、PROXYはプロキシポリシーを意味します。実際の接続先は、現在選択しているサーバーも確認してください。自分の設定ファイルにあるポリシーグループ名を使う場合は、設定内で定義されている名前と一致させます。ルールの末尾に未定義の名前を書くだけでは使えません。

接続を受信接続先を確認順にマッチ判定ポリシーを選択接続を確立

これらのルール例を既存の設定ファイルにそのまま置き換えられますか？ルール例だけでは完全な設定ファイルとして使えません。[Rule]はルールセクションを示す見出しです。既存ファイルを編集する場合は、ほかの設定セクションを残したまま、既存のルールセクション内で項目を調整してください。この記事のexample.comとドキュメント用のIPアドレスは構文説明のための例であり、接続先サーバーのアドレスではありません。

DOMAINとDOMAIN-SUFFIXの違いは？マッチ範囲を比較

特定のホストだけに指定したポリシーを適用するには、DOMAINを使います。親ドメインとサブドメインをまとめて扱う場合は、DOMAIN-SUFFIXを使います。サフィックスの判定ではドメインのラベル境界が考慮されるため、指定した文字列を含むだけのドメインは対象になりません。

ルールマッチする接続先マッチしない接続先
DOMAIN,example.com,DIRECTexample.comapi.example.com
DOMAIN-SUFFIX,example.com,DIRECTexample.com、api.example.comnotexample.com
DOMAIN-KEYWORD,example,DIRECTexample.com、notexample.comsample.test

DOMAIN-KEYWORDを使わないのはなぜですか？ドメイン内のキーワードで判定するため、ドメインサフィックスより範囲が広く、名前が似ているだけで同じドメイン体系に属さない接続先まで対象になることがあります。完全なドメイン名がわかっている場合は、DOMAINまたはDOMAIN-SUFFIXを優先してください。文字列の包含関係で判定する必要がある場合に限り、キーワードルールを検討しましょう。

GEOIPとIP-CIDRは何にマッチする？地域データとIPアドレス範囲の違い

GEOIP,CN,DIRECTは、ウェブサイトの表示言語から地域を判定できますか？できません。GeoIPデータ上の接続先IPの地域情報に基づいて判定し、ページの文言、ドメインサフィックス、端末の所在地は参照しません。データ上の地域情報が、サービスの実際の設置場所の認識と異なる場合もあります。リクエストに使われた接続先IPと、アプリでのマッチ結果を確認してください。

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

/24はポート番号ですか？いいえ、IPv4のプレフィックス長です。198.51.100.0/24は198.51.100.0から198.51.100.255までを対象とし、198.51.100.23/32は1つのIPv4アドレスだけにマッチします。ここではドキュメント用のアドレス範囲を使っています。実際の設定には、対象とするIPアドレス範囲を明確に指定してください。

no-resolveを付けると、一部のドメインリクエストがマッチしないのはなぜですか？判定時に利用できる接続先IPがなく、ルールがドメイン解決を行わない場合、後続のルールに判定が進むことがあります。特定のドメインを安定して振り分けるには、ドメインルールを優先してください。IPルールをマッチさせるためだけに、DNS設定全体をむやみに変更しないでください。

複数のルールにマッチした場合はどれが使われる？先にマッチしたルールが優先

より細かいルールが自動的に優先されますか？いいえ。この記事で扱う一般的なルールは上から順に判定され、最初にマッチしたルールのポリシーが適用されます。特定ホスト向けの例外を広範囲のルールより前に配置すると、意図した結果になります。

[Rule]
DOMAIN,api.example.com,PROXY
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,198.51.100.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY
  1. api.example.comは1行目に先にマッチしてPROXYを使うため、2行目のDIRECTには切り替わりません。
  2. www.example.comは1行目にはマッチしませんが、2行目にマッチするためDIRECTを使います。
  3. 接続先が198.51.100.23で、それより前のドメインルールにマッチしていない場合、例示したIPアドレス範囲のルールにマッチします。
  4. それまでのルールにマッチしなければ、続けてGEOIPを判定します。それにもマッチしない接続にはFINALが適用されます。

FINALを1行目に書けますか？構文上は書けますが、先頭に置くとそこでフォールバックが適用され、後続の一般ルールが判定されません。通常はルールセクションの末尾に置いてください。これは「接続に失敗したら別のルールを試す」という再試行設定ではありません。ルールにマッチした後で接続に失敗しても、次の行のポリシーに自動で切り替わることはありません。

変更が反映されたか確認するには？接続先を1つずつテスト

保存後にウェブページが開けば、ルールが正しいと判断できますか？いいえ。直接接続とプロキシ接続のどちらでもページが開く場合があります。現在の設定ファイル、Global Routing、リクエストの接続先、最終的なポリシーを確認してください。ページが読み込めるかどうかだけでは判断できません。既知の接続先を1つ選んで繰り返しテストすると、複数の変更による影響を抑えられます。

  1. 元の設定を保存

    Configを開き、現在選択しているファイルを記録して、復元できるコピーを保存します。リモート設定のファイルを使っている場合は、更新によってローカルの変更が上書きされるか、あらかじめ確認してください。

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

    Configで対象の設定ファイルを開いて編集し、[Rule]を探します。まず明確なDOMAINルールを1つ追加し、広範囲のルールとFINALより前に配置してください。

  3. モードを確認

    保存して対象の設定ファイルが選択されていることを確認し、Home → Global Routing → Configに戻ります。現在のサーバーが、すでに利用可能な自分の接続先であることを確認してください。

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

    テスト対象のページを開き直し、アプリのリクエストログで同じ時刻の接続先を探します。必要に応じて、重要な作業を中断しない範囲で再接続し、既存の長時間接続が再利用されないようにしてください。

  5. ルールのマッチ結果を確認

    ログに表示された接続先のドメインまたはIP、マッチしたルール、実際のポリシーを確認します。表示される項目はアプリ内の表示に従ってください。結果が想定と異なる場合は、まずそのルールより上にあるマッチ候補を確認し、次に選択中のファイルが正しいか確認します。

ルールを変更すると、すでに確立されているすべての接続も変わりますか？そうとは限りません。ブラウザーの接続再利用、ページキャッシュ、アプリの長時間接続により、テストが古い接続を使い続けることがあります。新しく作成された接続のログを確認してください。テスト後は必要な設定を元に戻し、トラブルシューティングのために一時的に選択したモードをそのまま使い続けないようにしましょう。

正しいルールにマッチしているのに接続できない？マッチ判定と接続エラーを切り分け

リクエストログに正しいポリシーが表示されているなら、ルールの変更は一度止めて、接続先への通信を確認してください。以下はネットワークエラーでよく見られる英語のメッセージです。表示される前後の文言や場所は異なることがあります。これらは接続処理中の問題を示すものであり、ドメインルールの記述ミスを単独で証明するものではありません。

エラー：Connection refused

原因と対処：接続先に拒否されています。アドレスやポートの誤り、サービスが待ち受けていないことなどがよくある原因です。まずリクエストログで拒否されたのがプロキシサーバーへの接続か、接続先への通信かを確認します。次にHomeでサーバーアドレスとPortを確認し、サービス提供元から案内されたパラメータと照合してください。サーバーポートを、ウェブサイトでよく使われる443に安易に変更しないでください。

エラー：Operation timed out

原因と対処：接続または関連する処理が制限時間内に完了しませんでした。まずHomeのConnectivity Testで、現在利用しているサーバーを確認してください。次にネットワーク、DNS、リクエストに適用されたポリシーを確認します。ログから誤ったルールにマッチしたと確認できた場合に限り、該当ルールを調整してください。

トラブルの範囲を広げないためには？「サーバーの利用可否、現在のモード、接続先の名前解決、ルールのマッチ結果」の順で確認し、一度に変更する項目は1つにします。DNSの変更、ルール全体の並べ替え、サーバーの変更を同時に行うと、接続が戻っても、どの変更が有効だったのか判断しにくくなります。

よくある質問：ルール更新・DNS・FINALの確認方法

サブスクリプションを更新すると、手書きのルールも変わりますか？

まずHomeにあるサーバーのサブスクリプションと、Configにあるリモート設定ファイルを区別してください。サーバーのサブスクリプション更新では、主に接続項目が更新されます。リモート設定の更新では、設定内容が置き換わる場合があります。変更前にConfigでファイルの取得元を確認し、更新後は[Rule]と選択状態をあらためて確認してください。両者の更新が同じ働きをすると考えないようにしましょう。

同じウェブサイトで複数のドメインに接続するのはなぜですか？

ページはメインサイト、ログインAPI、リソース用ドメインにそれぞれリクエストを送ることがあります。1つのDOMAINルールが対象にするのは指定したホストだけです。まずリクエストログで実際に失敗した接続先を確認してから、必要なルールを追加してください。画像が1枚読み込めないからといって、範囲の広いDOMAIN-KEYWORDをすぐに追加しないでください。

FINAL,PROXYなら、すべてのリクエストがプロキシ経由になりますか？

いいえ。この行に到達した、前のルールにマッチしていない接続だけが対象です。前の行にDOMAIN-SUFFIX,example.com,DIRECTがあれば、該当ドメインには先にDIRECTが適用されます。実際の接続先を判断するには、ルールセクションの先頭から順番に確認してください。

IP-CIDRにマッチしない場合、ドメインルールを削除すべきですか？

まず、より上にあるドメインルールにマッチしていないか確認します。次に、接続先でIPv4とIPv6のどちらが使われているか、またno-resolveによってその行で名前解決が行われない設定になっていないかを確認してください。IPアドレス範囲のルールを優先させる必要があると確認できた場合にのみ、順序を調整します。1回のテストのためにドメインルールをすべて削除しないでください。

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