ShadowrocketのREJECTとは？ルールでブロックできる範囲とできない範囲

REJECTが拒否するのは接続であり、ページ内の特定要素ではありません

アプリがネットワークにアクセスすると、Shadowrocketは処理対象となる接続にルールを照合します。REJECTに一致すると、そのリクエストについてDIRECTやPROXYを使った通常の宛先向け接続は確立されません。ここでいう「接続確立前」とは宛先への出方向の接続段階を指します。アプリがリクエストを送信する前という意味でも、照合前にDNSクエリが必ず発生しないという意味でもありません。

アプリ上の表示は、アプリ独自のエラー処理によって異なります。画像の読み込みに失敗したり、独立した計測リクエストが終了したりするほか、再試行やタイムアウトが表示されることもあります。REJECTは正常なページを代わりに生成せず、ページ内の空白領域を自動で折りたたむこともありません。そのため、「リクエストは拒否されたが、ページの見た目は変わらない」という状況は起こり得ます。

• DIRECT：宛先に直接接続します。リクエストのネットワークアクセスは許可されます。
• PROXY：選択したプロキシポリシー経由で通信します。リクエストを遮断する設定ではありません。
• REJECT：一致したリクエストを拒否します。コンテンツの置き換えやページのレイアウト調整は行いません。

これらのポリシーは、使用するプロキシプロトコルとは別の階層です。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuardは、プロキシの通信方式やトンネル方式を表します。プロキシプロトコルを変更しても、REJECTでHTTPSページ内のコンテンツを識別できるようにはなりません。

ドメインルールとIPルールで判定できること

照合時に宛先ドメインを取得できる場合は、DOMAINまたはDOMAIN-SUFFIXを使用できます。前者は完全一致するホスト名、後者は指定したドメインとそのサブドメインに一致します。独立したリクエスト先だけを拒否したい場合は、最初からドメイン全体に範囲を広げず、完全なホスト名を指定してください。

/32は単一のIPv4アドレスを表し、曖昧な範囲を意味しません。no-resolveは、このIPルールのためだけに追加のドメイン解決を行わないようにする設定です。「すべてのリクエストでDNSを使わなくなる」という意味ではありません。アプリがIPアドレスに直接アクセスし、利用可能なドメイン関連情報もない場合、ドメインルールだけでは一致しないことがあります。

IPルールにも限界があります。複数のドメインが同じCDNアドレスを共有する場合があり、同じドメインでも地域、ネットワーク、時間によって異なるIPアドレスが返ることがあります。ある時点で解決されたIPをすべて拒否すると、新しいアドレスを見逃す一方で、同じアドレスを共有する別のサービスに影響するおそれがあります。GEOIPもアドレスの位置情報データベースに基づく判定であり、Webサイトの実際のコンテンツや運営主体を識別するものではありません。

ルールは記載順に照合され、REJECTに特別な優先権はありません

Configによるルーティングでは、ルールを上から順に確認し、最初に一致したルールのポリシーを適用します。拒否を意味するREJECTだからといって、前にあるDIRECTやPROXYを自動的に上書きするわけではありません。具体的な例外は範囲の広いルールより前に置き、FINALはルール群の最後に配置して、それまで一致しなかった接続を処理します。

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

この例は順序の説明用です。login.example.comは先にDIRECTに一致し、metrics.example.comは先にREJECTに一致します。それ以外のexample.comに属するリクエストは、その後PROXYに一致します。DOMAIN-SUFFIXを先頭に移すと、前の2つのホスト名も先にそのルールで処理され、後続の個別ルールが機能しなくなります。

Configの適用を確認し、範囲を絞ってテストする

ルールファイルがConfigにあっても、現在のリクエストがそのファイルで処理されるとは限りません。まずHomeでGlobal Routingを確認してください。ProxyとDirectは全体の通信経路を決める設定です。ルールをテストするときは、Configを明示的に選択します。Sceneは状況に応じたルーティング設定です。Sceneと表示されているだけで、現在のConfigにあるルールが適用されるとは判断できません。

1. 設定のコピーを保存します。Configで現在使用中の設定を確認し、編集前に復元用のコピーを保存してください。内容を把握していないルール一式を、そのまま上書きしないでください。
2. ホスト名を指定したルールを1つだけ追加します。リクエストログに実際に表示されたホスト名を使い、DOMAIN,ホスト名,REJECTの形式で記述します。ここでの「ホスト名」は入力欄の説明であり、そのまま貼り付けて使えるルールではありません。
3. 設定の適用状態を確認します。変更を保存し、編集した設定が選択されていることを確認します。HomeでGlobal RoutingをConfigに設定し、接続スイッチがオンになっていることも確認してください。
4. 新しいリクエストを発生させます。対象ページを閉じてから再度開きます。必要に応じて対象アプリを終了して起動し直してください。読み込み済みの画像や古いタブだけを見て判断しないでください。
5. ログを確認します。リクエストログで対象のホスト名またはIPを探し、実際に一致したルールとポリシーを確認してください。新しいリクエストにREJECTと表示されて初めて、テストで拒否処理が行われたと確認できます。
6. ルールを戻して比較します。追加したルールを一時的に削除し、同じ手順でリクエストを発生させます。削除前後の接続結果や機能の変化を比べ、影響がそのルールによるものか確認してください。

Settings → On Demandは、条件に応じた自動接続を制御する設定であり、REJECTのオン・オフではありません。テスト中にトンネルが切断されると、その後のリクエストが同じ処理経路を通らない可能性があります。「ルールが効かない」と判断する前に接続状態を確認してください。また、ルールを変更しても既存のセッションがすべて切断されるわけではありません。テストでは新しい接続を発生させる必要があります。

HTTPS、キャッシュ、同一ドメイン上のコンテンツによる制限

ドメインルールとIPルールが処理するのは接続先です。たとえば通常のコンテンツがhttps://example.com/articleにあり、別のコンテンツがhttps://example.com/promoにあっても、ホスト名は同じです。DOMAINやDOMAIN-SUFFIXだけでは2つのパスを区別できません。このホスト名を拒否すると、通常の記事も同時にブロックされる可能性があります。

ポート番号から分かるのは、通信の用途に関する手がかりだけです。通常のWebページもその他のHTTPSリクエストも443を使う場合があるため、ポート全体を拒否して細かく選別することはできません。宛先ドメインを取得できても、暗号化された接続内のURLパス、リクエスト本文、応答内容を読み取れるとは限りません。REJECT自体に復号機能はありません。

• コンテンツがキャッシュ済み：アプリがディスクやメモリ上のデータを直接表示しており、新たに拒否できるネットワークリクエストがありません。ページを開き直してもキャッシュが使われることがあります。
• コンテンツがメインの応答に含まれる：通常の本文と別のコンテンツが同じリクエストで返される場合、接続単位の拒否では一方だけを残せません。
• ページの構造は残る：リモート画像のリクエストが失敗しても、Webページにあらかじめ用意されたコンテナ、見出し、ボタンなどは表示されることがあります。
• リクエスト先が切り替わる：失敗後、アプリが別のドメインにアクセスすることがあります。元のルールが対象にするのは一致した接続先だけで、新しい接続先の用途を自動で判定することはありません。
• リクエストが処理経路に入っていない：接続がオフの場合や除外された経路がある場合、ルールを追加しても解決しません。まず通信が現在の設定を経由しているか確認してください。

URL Rewriteは別種のリクエスト書き換え機能であり、その機能をREJECTのものとして扱ってはいけません。接続ルールだけで特定のコンテンツを切り分けられない場合は、必要な機能を維持して対象範囲を絞ってください。ページ要素を消そうとしてネットワーク範囲を際限なく広げるのは避けましょう。

よくある症状と復旧手順

この記事では、ユーザーが自身のサービス提供元とサブスクリプションを利用していることを前提としています。接続情報は利用中のサービス提供元から取得してください。サービス提供元が案内する接続パラメータは接続設定に関するもので、REJECTは現在の設定における照合と拒否を処理します。両者は代替できません。検証後は、用途が分からないルールを増やし続けるより、範囲が明確で説明でき、元に戻せるルールを保つほうが管理しやすくなります。