ShadowrocketのREJECTルールの使い方：通信を拒否する仕組みと適用範囲

REJECTの役割：通信を拒否する。ページの内容を消す機能ではない

Shadowrocketのルールは、マッチ条件と処理ポリシーで構成されます。条件は「どの通信に一致するか」、ポリシーは「一致した通信をどう処理するか」を指定します。たとえばDOMAIN,blocked.example.com,REJECTは、ルール判定で得られた接続先ドメインが指定した名前と一致した場合、その通信をREJECTで拒否し、後続のルールによる出力先の選択に進まないことを示します。

この流れが成立するのは、対象の通信がShadowrocketの処理対象に入り、現在のルーティング設定で該当ルールが使われている場合です。端末上のすべての通信が必ず対象になるわけではなく、Webページ上の不要な要素がすべて消えるわけでもありません。アプリによっては読み込み中の表示が残ったり、エラーが表示されたり、リクエストを再試行したりします。

• PROXY：一致した通信を対応するプロキシ経由で処理します。実際の接続先は、選択中の設定や構成によって異なります。
• DIRECT：一致した通信を接続先へ直接接続します。リクエストを拒否する設定ではありません。
• REJECT：一致した通信を拒否します。直接接続に切り替える設定ではありません。

そのため、ルールが機能しているかは、通信がルールに一致して拒否されたかで判断します。ページに空白が残ったかどうかだけでは判断できません。空白や読み込み中の表示、エラーメッセージは、リソース取得に失敗した際のページ側の挙動である可能性があります。REJECTがページのレイアウトを自動調整した証拠ではありません。

まずGlobal Routingを確認し、次にルールの順序を確認

HomeでGlobal Routingを確認します。現在の設定のルールを検証する場合は、まずConfigを選び、Configで編集した設定が有効になっていることを確認してください。ProxyとDirectは全体の処理モードです。この状態での結果だけを見て、現在の設定にあるREJECTの正しさを判断することはできません。Sceneを使っている場合は、シーンで実際に使用されている設定とルーティングも確認します。

ルールは上から順に判定され、一致すると対応するポリシーが適用されます。「より具体的な」ルールを探して後続のルールへ進むことはありません。そのため、例外となる完全一致ルールは範囲の広いルールより前に置き、FINALは最後に配置します。以下は構文だけを示す独立した例です。記載したドメインはすべて説明用です。既存設定全体の出力ポリシーを、この例に合わせて変更しないでください。

[Rule]
DOMAIN,allowed.example.com,DIRECT
DOMAIN-SUFFIX,example.com,REJECT
GEOIP,CN,DIRECT
FINAL,PROXY

この順序なら、allowed.example.comは1行目に一致するため、2行目では拒否されません。一方、blocked.example.comは2行目に一致します。1行目を2行目より後ろに置くと、完全一致の例外は機能しません。GEOIPは接続先IPアドレスの地域情報をもとに判定するもので、ページの言語やWebサイト運営者の所在地を示すものではありません。

DOMAIN、DOMAIN-SUFFIX、IP-CIDRの使い分け

問題のドメインが1つだけ特定できている場合は、範囲を最小限に抑えられるDOMAINでテストするのが基本です。サブドメインを含む一連のドメインすべてを拒否する必要があると確認できてから、DOMAIN-SUFFIXを検討してください。これは指定したドメインとそのサブドメインに一致するルールで、名前の一部にたまたま同じ文字列が含まれるドメインだけに一致するわけではありません。メインサイトのドメインを指定すると、ログイン、画像、APIの通信まで影響することがあります。

ドメインルールの判定には、ルールが参照できる接続先ドメインの情報が必要です。アプリがIPアドレスへ直接接続する場合や、ドメインとの対応が不完全な場合、実際のリクエスト先が変わった場合などは、既存のドメインルールに一致しないことがあります。まず通信記録で実際の接続先を確認し、「ドメインをブロックできなかった」という理由だけで広いIP範囲を拒否しないでください。

• /32はIPv4の単一アドレスを指します。/24はアドレス範囲を表し、影響する範囲が大きく異なります。
• 共有IPアドレスやCDNのアドレスでは、複数のサイトが同じアドレスを利用している場合があります。IPを拒否すると、ほかの正常な通信にも影響するおそれがあります。
• ドメインの名前解決結果は変わることがあります。その時点で確認したIPアドレスを1つだけブロックしても、そのドメインへの通信を継続的に遮断できるとは限りません。
• DOMAINのドメイン欄にhttps://、Webページのパス、クエリパラメータを記入しないでください。

REJECTだけで拒否できるものと、できないもの

不要なリソースが独立したドメインから配信され、そのドメインが必要な機能を担っていない場合は、ドメイン単位の拒否で範囲を限定しやすくなります。一方、同じドメインが本文、ログイン認証、ほかのリソースをまとめて配信している場合、ドメインルールだけではURLのパスごとに用途を区別できません。HTTPS接続の具体的なページ内容も、DOMAINルールを追加しただけで自動的に判定対象になるわけではありません。

ページ上に領域が残る場合、コンテンツがメインのドキュメントに含まれているか、アプリのローカルキャッシュが表示されている可能性があります。リクエストを拒否した後も、固定の高さを持つコンテナが画面に残ることがあります。こうした見た目の残りを消すために、メインサイトや静的リソースのドメインまで対象にしないでください。ルールが制御するのは通信の処理先であり、ページ要素の非表示ではありません。

ルールの追加から検証まで：一度にテストするのは1件

変更前にConfigで元に戻せる設定を保存し、元のGlobal Routing、選択中の出力先、テスト対象のページを記録しておきます。設定がリモート管理や更新元から提供されている場合は、後の更新でローカルの変更が上書きされないかも確認してください。利用中のサービスやサブスクリプションの内容はそれぞれの提供元が管理するものです。この記事では、ローカルルールのテスト方法のみを説明します。

1. 変更前の状態を記録。REJECTを追加せずに対象ページを開き、ログイン、画像、APIが正常に動作するか記録します。すでに発生している不具合を、新しいルールの影響と混同しないようにしてください。
2. 設定を編集。Configで現在使用中の設定を開き、ルール欄にDOMAINの完全一致ルールを1件追加します。先に一致する可能性のある範囲の広いルールより前に配置してください。
3. 設定が有効か確認。変更を保存して、現在選択中の設定を確認します。次にHomeに戻り、Global Routing → Configになっていることを確認してください。保存しただけで有効化していない別の設定を使わないようにします。
4. 接続を作り直す。必要に応じてHomeの接続スイッチをいったんオフにしてからオンにし、対象アプリからリクエストを再送します。この操作では現在の接続が一時的に切断されるため、実行中の作業がないときに行ってください。
5. 記録を確認。アプリ内で利用できる接続記録やリクエスト記録を開き、同じ時刻の接続先ドメインと適用されたポリシーを探します。詳細に一致したルールが表示される場合は、あわせて記録してください。対象のリクエスト記録がなければ、すぐに原因を断定しないでください。
6. 機能を再テスト。ページ表示、ログイン、検索、画像の読み込みなど、関連する機能を確認します。対象の通信が拒否され、必要な機能も正常に動作する場合に限り、ルールを残してください。

応答が速くなったことだけを根拠にしたり、1回のタイムアウトをルールへの一致とみなしたりしないでください。同じページのリソースでも、キャッシュ、ログイン状態、サーバーからの応答によって状況は変わります。対象のリクエスト、実際に適用されたポリシー、ルールを取り消した後の比較結果をあわせて確認することが大切です。

ページに不具合が出たら、最小限の範囲で元に戻す

誤ブロックは、ログイン認証用ドメイン、画像配信、共有API、アプリ起動に必要な設定リクエストでよく起こります。ボタンが反応しない、読み込みが終わらない、ログイン画面が繰り返し表示されるといった症状の原因は、バックグラウンドで必要な通信が拒否されていることかもしれません。原因を確認するには、「修正ルール」を追加し続けるより、直近で追加したルールを取り消すほうが確実です。

ルールを取り消しても問題が続く場合は、変更前に保存した設定全体を復元し、現在有効な設定ファイル、接続状態、対象サービス自体の動作状況を確認してください。特定のルールがある場合にだけ問題を再現できるなら、そのルールの対象範囲をさらに絞ります。例外が必要な場合は、完全一致ルールを範囲の広いREJECTより前に置き、その接続先に本来必要なDIRECTまたはPROXYを指定してください。常にDIRECTに変更するのは避けてください。

• 記録を残す：追加したルール、再現手順、接続先ドメイン、適用されたポリシー、元に戻した後の結果を書き留め、次回に対象範囲を広げすぎないようにします。
• 一度に多くの設定を変更しない：ルールの順序、DNS、出力先を同時に変更すると、不具合の原因を特定しにくくなります。
• プライバシーを保護：調査用の情報を共有する前に、アカウント情報、サブスクリプションURL内のトークン、その他の認証情報を隠してください。