ShadowrocketのREJECTルール設定方法｜ブロックの仕組み・照合順序・できることとできないこと

1. REJECTが適用される仕組み：対象を照合してからポリシーを実行

ルールでは、通信が照合条件に一致するか、そして一致した場合にどのポリシーを適用するかを定めます。たとえばDOMAIN-SUFFIX,example.com,REJECTでは、DOMAIN-SUFFIXが照合タイプ、example.comが照合値、REJECTがアクションです。一致した通信は拒否され、失敗しても次のルールには進みません。

この流れが適用されるのは、対象の通信がShadowrocketの処理対象になっている場合です。接続がオフ、通信がトンネルを迂回している、または現在のルーティングモードで該当ルールを使っていない場合、REJECTを編集しても通信先は変わりません。接続状態、ルーティングモード、Config、照合されたルールの順に確認し、最初からブロックルールをまとめて追加しないでください。

REJECTが制御するのは主にネットワーク通信です。ページにすでに表示された文字や画像のプレースホルダー、アプリ内のコンテンツを削除するものではありません。通信を拒否すると、リソースの読み込み失敗、画像の空白、アプリの再試行やエラー表示が起きる場合があります。具体的な表示はアプリのエラー処理によって異なるため、特定の変化がすべてのアプリで起こるとは限りません。

2. REJECTルールの構文：まずドメイン、IP範囲は慎重に

完全一致するホスト名だけを拒否する場合はDOMAIN、ドメインとそのサブドメインを対象にする場合はDOMAIN-SUFFIXを使います。照合値にはホスト名を入力し、https://、ポート、パス、クエリパラメーターは含めません。たとえばhttps://ads.example.com/bannerのホスト名を照合する場合は、URL全体ではなくads.example.comを指定します。

DOMAIN-SUFFIX,example.com,REJECTはexample.comとimg.example.comを対象にできますが、文字列を含む任意のドメインに一致するわけではありません。特定のリソース用ホストだけを拒否するなら、ルートドメイン全体に対象を広げないでください。同じルートドメイン配下でも、ログイン、画像、APIが別々のサブドメインを使うことがあります。

IP-CIDRはIPv4アドレスまたはネットワーク範囲に一致します。/32は単一のIPv4アドレス、/24は256個のアドレスを含む範囲です。共有インフラに広い範囲のREJECTを設定すると、無関係な複数のドメインにも影響する可能性があります。ドメインの接続先IPは変わることがあるため、一度調べたIPを長期間拒否しても、そのドメインを安定してブロックできるとは限りません。

3. ルールの照合順序：例外は先、FINALは最後

Configのルールで処理する場合、上から順に照合され、最初に一致したルールのポリシーが適用されます。後ろにある詳細なルールが、先に一致した広範なルールを自動で上書きすることはありません。よくあるミスは、ドメイン全体に適用するREJECTを先に書き、許可したいサブドメインを後ろに置くことです。この順序では例外ルールは適用されません。

[Rule]
DOMAIN,account.example.com,DIRECT
DOMAIN-SUFFIX,example.com,REJECT
IP-CIDR,192.0.2.8/32,REJECT,no-resolve
GEOIP,CN,DIRECT
FINAL,DIRECT

この順序の例では、account.example.comは1行目に一致するため、2行目は照合されません。img.example.comはサフィックスルールに一致して拒否されます。GEOIP,CN,DIRECTは宛先IPの地理情報データベースを使って照合し、Webページの言語を判定するものではありません。REJECTより前に置くと、条件に一致する通信が先に許可される場合があります。

FINALは最終ルールで、ドメインの照合値はありません。例を完結させるためにFINAL,DIRECTを使っていますが、使用中のConfigの最終ポリシーをDIRECTに変更すべきという意味ではありません。実際の編集では現在の最終ポリシーを維持し、検証済みの具体的なルールだけを適切な位置に挿入してください。同じConfigにFINALを重複して追加しないでください。

4. Configで編集・検証する：ルールは一つずつ追加

以下ではHome、Config、Settingsの画面構成に沿って確認箇所を説明します。編集画面の表示は、現在のアプリのバージョンや画面に従ってください。まず使用中のConfigを複製してから、選択中のConfigを編集します。ファイル名だけで使用中かどうかを判断したり、サブスクリプションの更新をルールの更新と取り違えたりしないでください。

1. 使用モードを確認する。Homeで接続状態とGlobal Routingを確認します。Configのルールを検証する場合はConfigを選択してください。ProxyやDirectは、この記事のルール照合を検証するモードではありません。Sceneを使っている場合は、現在のSceneで実際に適用されるルーティング設定も確認します。
2. 対象のConfigを確認する。Configを開き、選択中のファイルを確認して複製を保存したうえで、[Rule]セクションを探します。すでにセクションがある場合はその中を編集し、ファイル末尾に同じ構造を重ねて追加しないでください。
3. 最小限のルールを追加する。まず拒否対象となることが確かなホスト名を一つ選び、DOMAINルールを関連する広範なルールより前に置きます。ほかの既存ポリシーは変更しないでください。
4. 保存して適用する。保存後も同じファイルが選択中のConfigであることを確認し、画面の案内に従って適用します。接続し直す必要がある場合は、進行中のほかのネットワーク通信への影響に注意してください。
5. 通信を再度発生させる。対象のページやアプリを閉じて開き直し、新しい接続をできるだけ確立します。対象ドメイン、一致したルール、ポリシーを記録してください。ログに十分な情報がない場合、ページが空白になっただけでREJECTに一致したと判断しないでください。
6. 一つの変更だけを戻して比較する。追加したルールを削除し、保存して同じ操作を再テストします。変更前後を比べてから、ルールを残すか、対象を絞るか、調査を続けるか決めてください。

既存の接続、ブラウザーキャッシュ、アプリ内キャッシュによって、ルール変更後の表示が想定と異なる場合があります。設定を続けて変更するのではなく、まず対象への通信を新しく発生させてください。記録では「新しい通信が拒否された」「新しい通信が発生していない」「通信は成功したが表示が変わらない」を区別します。それぞれ次に行う確認が異なります。

5. ブロックの限界：同一ドメインのコンテンツ、キャッシュ、共有IP

ドメインルールで振り分けられるのは、照合可能な接続先情報に限られます。正常なAPIとブロック対象のコンテンツが同じホスト名を使い、URLパスだけが異なる場合、DOMAINとDOMAIN-SUFFIXで両者を区別することはできません。そのホスト名をREJECTにすると、正常なAPIも一緒に拒否される可能性があります。

• HTTPSのパスはドメイン条件になりません。https://api.example.net/feedとhttps://api.example.net/bannerは同じホスト名を使っています。DOMAIN-SUFFIXの後ろに/bannerを追加してもパスでフィルタリングできません。443ポートでもこの二つの通信は区別できません。
• ローカルのコンテンツにはブロック対象の通信がありません。すでにダウンロード済みのリソース、オフラインページ、アプリに含まれるコンテンツは、ネットワークルールを追加してもすぐには消えません。
• 共有IPだけでは特定のサイトを正確に指定できません。一つのIPアドレスが複数のドメインで共有されている場合があります。識別可能なドメインルールを優先して検証し、特定のリソースを対象にするためにIP範囲全体を拒否しないでください。
• 接続情報が常にすべて得られるとは限りません。IPアドレスを直接指定する通信は、ドメインルールだけでは照合できません。ドメイン情報を利用できるかどうかは、実際の名前解決や接続経路にも左右されるため、接続ログとあわせて確認してください。
• サーバー側のリソース配置は変わることがあります。接続先のドメイン、アドレス、リクエスト方法が変更される可能性があります。以前のルールに一致しなくなった場合は、対象の通信先を再確認し、むやみにルートドメイン全体へ対象を広げないでください。

REJECTは明確な接続先への通信を拒否できますが、すべての広告コンテンツを除去したり、ブロック後もページレイアウトを維持したりするものではありません。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuardなどのプロトコルに切り替えても、DOMAIN-SUFFIXがWebページの内容を読み取って選別できるようにはなりません。通信に使うプロトコルとルール照合は、それぞれ異なる役割を担います。

6. よくある質問：反映されない・誤ブロック・更新後の変化

継続して管理する場合は、変更ごとに対象ホスト、追加理由、元に戻す方法を記録してください。誤ブロックが起きたら、まず通信できる状態に戻してから対象のリクエストを調べます。DNS、通信プロトコル、ルール一式を同時に変更すると、どの変更が結果に影響したのか判断しにくくなります。さらに確認が必要な場合は、トラブルシューティングガイドで現在のConfigと接続ログを確認してください。

この記事は、利用者が自身でサービス事業者やサブスクリプションを用意していることを前提に、ローカルルールの管理方法だけを説明しています。当サイトでは接続先、サブスクリプション、接続サービスの提供・販売・推奨は行っていません。アプリの買い切りと通信サービスの料金は別です。REJECTを追加しても、新しい接続設定は作成されません。