ShadowrocketのREJECTルール解説｜通信をブロックできる範囲と限界

1. ルールチェーンにおけるREJECTの位置

設定に基づいて通信を振り分ける場合、Shadowrocketは接続から利用できる情報を使ってルールを照合します。照合条件と実行ポリシーは別の要素です。DOMAIN、DOMAIN-SUFFIX、IP-CIDRなどで「一致するか」を判定し、末尾のREJECTで「一致した後に拒否するか」を決めます。REJECTはプロトコルではなく、実行時に別のプロキシ経路を選ぶ必要もありません。

ここではREJECTに一致した場合の流れを説明しています。DIRECTに一致すれば直接接続し、有効なプロキシポリシーに一致すれば該当する出力先に接続します。ルールは上から順に確認され、一致した時点で対応するポリシーが適用されます。後続のルールから「より適切な」結果を探すことはありません。トラブル時は、REJECTが書かれているかだけでなく、その前のルールが先にリクエストを処理していないかも確認してください。

• まずルーティングモードを確認：HomeでGlobal Routing → Configを確認し、現在の設定のルールがテストに使われる状態にします。ProxyまたはDirectの全体テスト結果から、Configのルールが正しいかどうかを判断しないでください。
• 次に設定を確認：Configで現在有効な設定ファイルを確認します。無効な別ファイルを編集しても、使用中のルールは変わりません。
• 最後に新しいリクエストで確認：すでに確立した接続は再利用されることがあります。変更後は接続を新しく確立してから対象ページを再度開くと、ページを更新するだけの場合より判断しやすくなります。

2. 正確なドメインからルールを書く

まずDOMAINでホスト名を1つ指定し、必要に応じてDOMAIN-SUFFIXへ範囲を広げます。たとえばmetrics.example.comだけを拒否する場合、完全一致のルールではwww.example.comは拒否されません。一方、DOMAIN-SUFFIX,example.com,REJECTはルートドメインとサブドメインを対象とするため、ログイン、画像、APIまで遮断する可能性があります。以下のドメインは構文の説明用であり、実際にブロックすべき対象を示すものではありません。

[Rule]
DOMAIN,metrics.example.com,REJECT
DOMAIN-SUFFIX,blocked.example.org,REJECT
FINAL,DIRECT

これはルールの構成例であり、既存ファイルと置き換えて使える完全な設定ではありません。必要なルールを既存の[Rule]セクションに追加し、同じセクションを重複して作らないでください。元の設定に必要なルールやフォールバックポリシーも残します。例のFINAL,DIRECTは末尾の位置を示すだけであり、すべてのユーザーが自分のFINALをDIRECTに変更すべきという意味ではありません。

完全なURLをDOMAIN条件に記入しないでください。ページURLの/banner/imageはパスであり、ドメインの一部ではありません。:443はポートであり、ホスト名には含まれません。こうしたドメインルールでは、同じホストがHTTPSの443番ポートとHTTPの80番ポートの両方でサービスを提供していても、DOMAIN条件だけで一方のポートに限定することはできません。

3. ルールを書いたのにブロックされない場合は順序を確認

ルールは「より具体的なものを優先」という基準で自動的に並べ替えられません。たとえば設定にDOMAIN-SUFFIX,example.com,DIRECTが先にあり、その後にDOMAIN,metrics.example.com,REJECTがある場合、このサブドメインへのアクセスは先にあるDIRECTに一致します。後ろのルールは条件がより限定的でも、実行されません。

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

上の例では、明確な拒否対象を広範囲の直接接続ルールより前に置いています。特定のサブドメインを許可する場合は、そのサブドメインの許可ルールを該当するサフィックス拒否ルールより前に置きます。互いに範囲が重なるルールを複数追加し、ページの見た目だけで判断しないでください。対象の接続が一致したルールと最終的なポリシーを確認します。

GEOIPとIP-CIDRは宛先IPに基づく照合条件です。確認済みの正確なドメイン条件の代わりに使わないでください。複数のウェブサイトが同じIPを共有している場合があり、アドレス範囲を拒否すると、より広い範囲に影響することがあります。ドメインルールが一致するかどうかは、その接続で利用可能なドメイン情報があるかにも左右されます。IPしか分からない接続が、必ずいずれかのDOMAINルールに一致するとは限りません。

4. 同じドメインのコンテンツ、キャッシュ、ページの余白に関する限界

REJECTは一致した接続を拒否できますが、ウェブページの領域が本文、広告枠、プレーヤーのどれかを判別することはできません。たとえば同じwww.example.comから記事用APIと広告用APIが返される場合、DOMAINやDOMAIN-SUFFIXでは一方のパスだけを拒否できません。そのドメインを拒否すると、通常のコンテンツも影響を受けます。「同じドメインのコンテンツはブロックできない」とは、こうしたドメインルールだけではコンテンツを選別できないという意味です。

HTTPSではパスとレスポンス本文が暗号化されており、通常のドメインルールはこれらの内容を判定に使いません。DOMAIN-SUFFIXの項目を増やしても、ページ要素を識別できるようにはなりません。ブラウザがリソースをメモリやローカルキャッシュに保存している場合、新しいリクエストが拒否されても、元の画像が表示されることがあります。

5. 1項目ずつ検証し、元に戻せる状態を保つ

テスト前に、現在使用できている設定のコピーを保存し、追加するルールと元の順序を記録します。ネットワークの変更、プロキシの切り替え、サブスクリプションの更新、複数の拒否ルールの追加を同時に行わないでください。ページの動作が変わっても、原因を特定できなくなります。以下は、接続が正常な状態で、1つの拒否対象を検証する手順です。

1. 基準となる状態を記録：ネットワークと設定を同じ状態に保ち、対象ページを開きます。ログイン、画像の読み込み、動画再生など、具体的な動作を記録してください。
2. 対象を特定：接続ログで関連するリクエストを探し、対象のホスト名、一致したルール、実行ポリシーを確認します。1つのページが複数のドメインにアクセスすることがあります。ドメイン名から統計サービスのように見えるだけで、ブロック可能と判断しないでください。
3. 変更は1ルールだけ：Configで現在有効な設定の[Rule]セクションに、完全一致のDOMAINルールを1つ追加します。範囲の広いルールやFINALに先行する位置に置き、保存後に設定が反映されていることを確認してください。
4. 接続を再確立：再接続して対象ページをもう一度開きます。必要に応じて以前のタブを閉じ、新しいセッションでテストしてください。REJECTに一致したか、ログイン、画像、動画などの機能に影響したかをそれぞれ記録します。
5. ルールを取り消して比較：追加したルールを一時的に削除し、接続を再確立してテストします。ルールの追加後に問題が発生し、削除後に解消した場合は、そのルールによる誤判定をまず疑ってください。
6. 必要最小限の範囲に保つ：効果が確認でき、必要な機能への影響がなければ、そのルールを残します。さらにサブドメインを対象にする場合も段階的に広げ、共有ドメインやアドレス範囲全体を一度に拒否しないでください。

サブスクリプション内のサーバー情報と、現在のConfigにある振り分けルールは別の内容です。更新後に動作が変わった場合は、選択中の接続先と現在の設定をそれぞれ確認してください。更新によってローカルルールが上書きまたは保持されたと決めつけないでください。リモートURLから設定ファイルを更新した場合も、ローカルの変更が残っているか確認します。元に戻すためのコピーは復元に使い、差分を確認せずに繰り返し上書きしないでください。

6. よくある症状と確認の順序

ルールを残す基準は、対象への新しい接続が実際にREJECTに一致すること、必要な機能を引き続き利用できること、ルールを取り消して元の動作に戻せることです。REJECTは対象範囲を明確にした通信拒否に適しています。ページ単位のコンテンツ整理、レスポンス内容の選別、レイアウトの調整は、これらのドメインルールで保証できる結果ではありません。基本操作は使い方ガイド、ルール関連の用語は用語集をご覧ください。