ShadowrocketのREJECTルール設定方法｜リクエスト遮断の仕組み・書き方・注意点

1. ルール判定におけるREJECTの役割

リクエストがShadowrocketのルール処理に入り、REJECTを指定したルールに一致すると、そのリクエストは拒否され、プロキシ経由や直接接続で対象にアクセスすることはありません。アプリ上では、リソースの読み込み失敗、接続エラー、再試行の繰り返しなどとして現れることがあります。表示内容はリクエスト元のアプリによって異なります。ページが真っ白になっただけでは、REJECTが適用されたとは判断できません。

通常、ルールは設定ファイルに記述された順に照合されます。適用対象のルールでポリシーが決まると、それ以降のルールでは今回のリクエストの結果は変わりません。そのため、「ルールを追加した」ことと「リクエストにそのルールが適用された」ことは別です。上位にある広範囲の許可ルール、実際に有効な設定ファイル、現在のルーティングモードが最終結果に影響します。

• DOMAIN：指定した完全一致のドメインに適用されます。まず対象を絞って確認する場合に適しています。
• DOMAIN-SUFFIX：指定したドメインとそのサブドメインに適用されます。単一の完全一致ドメインより広い範囲が対象です。
• IP-CIDR：IPv4アドレスまたはアドレス範囲に適用されます。Webページのパスや要素を指定するものではありません。
• FINAL：最後に適用するフォールバックルールです。既存の設定方針に沿ったポリシーを指定してください。

たとえば、同じドメイン上の本文、画像、アクセス解析へのリクエストが同じ接続先を共有することがあります。ドメインルールだけでは、こうした通信の用途を区別できません。ドメイン全体をREJECTにすると、ページの表示に必要なリソースまで遮断される可能性があります。

2. ConfigとGlobal Routingを確認する

作業前に現在の設定を複製しておきましょう。Config（設定）で現在選択されているファイルを確認し、そのファイルの編集画面からルール部分を確認します。編集画面の表示方法はアプリの現在の仕様に従ってください。有効になっていないファイルだけを変更し、Webページの表示だけでルールの正否を判断しないようにしましょう。

1. 現在選択中の設定、Global Routingの状態、対象アプリの通常時の動作を記録します。
2. Configで設定を複製してから、実際に有効なファイルのルール部分を変更します。
3. Homeに戻り、接続が有効であることを確認して、Global RoutingをConfigに設定します。
4. 変更を保存して読み込み済みであることを確認し、対象アプリから新しいリクエストを1回送信します。

Homeに表示される接続項目とConfig内のルールファイルは、設定上の階層が異なります。接続のサブスクリプションを更新しても、編集したルールが読み込まれるとは限りません。設定がリモートから更新される場合は、更新後もローカルの変更が残っているか確認してください。

3. DOMAIN-SUFFIXとIP-CIDRの正しい書き方

テキスト形式のルールでは、項目を半角カンマで区切ります。全角カンマは使用しません。以下は独立した構文例を4つ示したもので、まとめて置き換えられる完成済みの設定ではありません。ドメインには予約済みの例示用ドメインを使用しています。192.0.2.0/24は文書用の例示アドレス範囲であり、実際に遮断すべき対象を示すものではありません。

DOMAIN,metrics.example.com,REJECT
DOMAIN-SUFFIX,example.com,REJECT
IP-CIDR,192.0.2.18/32,REJECT,no-resolve
IP-CIDR,192.0.2.0/24,REJECT,no-resolve

DOMAIN-SUFFIX,example.com,REJECTは、example.comやimg.example.comなどのサブドメインに適用されます。文字列が含まれているだけの任意のドメインに一致するわけではありません。metrics.example.comだけを遮断したい場合は、まずDOMAINを使い、親ドメイン全体に対象を広げないようにしましょう。

4. ルールの順序・例外・FINALのフォールバック

特定のサブドメインを許可する場合は、例外ルールを広範囲の拒否ルールより前に配置します。以下は順序の例です。account.example.comは直接接続し、それ以外のexample.comへのリクエストは拒否し、最後に未一致のリクエストを直接接続します。ここでのDIRECTは明示的な例であり、すべてのユーザーにフォールバックを直接接続へ変更するよう推奨するものではありません。

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

実際に使用する際は、既存の設定に必要なポリシーを維持してください。この例外にプロキシ接続が必要な場合、DIRECTをそのままコピーせず、設定内にすでにある適切なポリシーを使用します。また、2つ目の[Rule]セクションをファイル末尾にそのまま追加しないでください。既存のルールセクションを編集し、最終的な順序を確認しましょう。

• 拒否ルールをFINALの後に置く：先にフォールバックルールでリクエストが処理されるため、後続の拒否ルールは期待どおりに適用されません。
• 広範囲の許可ルールが先にある：対象が先に別のDOMAIN-SUFFIX、IP-CIDR、GEOIPルールに一致すると、後続のREJECTは適用されません。
• 例外を拒否ルールの後に置く：対象がすでに拒否されているため、後置きの許可例外では元に戻せません。
• FINALをREJECTに設定する：未一致のリクエストがすべて拒否されます。これはデフォルト拒否の設定であり、特定の対象だけを遮断する一般的な方法ではありません。

GEOIPはIPアドレスの地域情報を使って照合するもので、「特定のWebサイトを遮断すべきか」という用途を分類するものではありません。1つのドメインへの対応としてGEOIPの広範囲なポリシーを変更すると、不要な影響が生じることがあります。対象に直接関係するルールを優先して移動するか、範囲を絞ってください。

5. ルールによる遮断で対応できないケース

REJECTは接続先をもとに判断し、ページのレイアウトは解析しません。HTTPSリクエストのパス、パラメーター、本文をDOMAIN-SUFFIXの照合値として直接指定することもできません。同じドメイン内に複数のコンテンツがある場合、キャッシュ済みのコンテンツ、共有インフラを使う場合は、まず影響範囲を把握してから拒否ポリシーを使うか判断してください。

接続がすでに確立されている場合、新しいルールが後続のページ動作にすぐ反映されるとは限りません。ルールのテストでは、変更後に作成された新しい接続を対象にします。対象ページを閉じて開き直し、必要であれば対象アプリを終了して再試行してください。接続の再利用にも注意し、既存接続での通信を新しいルールの不具合と誤認しないようにしましょう。

6. 接続ログでルールの未適用・誤遮断を確認する

確認作業では、一度に変更する項目は1つにします。まず問題のリクエストを再現し、アプリ内の接続ログとLog（ログ）を確認してください。関連する画面や表示項目はアプリの現在の仕様によって異なります。対象のドメインまたはIP、発生時刻、最終ポリシー、確認できる一致ルールを記録します。ログを共有する前に、サブスクリプションURL、トークン、その他のアカウント情報を隠してください。

1. リクエストが処理対象に入っているか確認：Homeの接続状態とGlobal Routingを確認します。ログに新しいリクエストがない場合は、接続状態、キャッシュ、対象のアクセスが実際に発生しているかを確認してください。
2. 対象を確認：画面に表示されたサイト名が、失敗したリソースのドメインとは限りません。該当時刻の接続ログを手がかりに、実際のホスト名とアドレスを確認してください。
3. 有効なファイルを確認：Configに戻り、現在の設定ファイルを編集したこと、保存・読み込み後もルールが残っていることを確認します。
4. 順序を確認：上から順に、先に一致する可能性のある許可ルールとFINALの位置を確認します。
5. 今回の変更を取り消す：追加したREJECTだけを削除し、同じ操作を再現します。機能が回復した場合は今回のルールを重点的に確認しますが、具体的な依存関係はログと照らし合わせて判断してください。
6. 範囲を絞って再テスト：サフィックスルールを単一ドメインに、アドレス範囲を単一アドレスに変更します。ログイン、画像、検索、再生など、影響を受けた機能をそれぞれテストしてください。

確認が終わったら、変更は必要最小限にとどめ、用途も記録しておきましょう。一時的な確認に使ったグローバルモード、アドレス範囲全体の拒否、広範囲のサフィックスルールを長期設定として残さないでください。次に同じ問題が起きたとき、出所のわからない大きなリストを管理するより、理由が明確な1つのルールを正確に戻すほうが問題を特定しやすくなります。