ShadowrocketのREJECTルールとは？ドメイン拒否の仕組みと限界

REJECTの位置づけ：ルールが対象を決め、ポリシーが処理方法を決める

ルールは通常、ルールタイプ、マッチする値、処理ポリシーで構成されます。たとえばDOMAIN-SUFFIX,example.com,REJECTの場合、DOMAIN-SUFFIXはドメインの末尾で照合するルールタイプ、example.comは照合対象、REJECTは一致した接続を拒否するポリシーです。REJECTをドメイン一覧と考えたり、Configにこの語があるだけで対象の接続が必ず拒否されると判断したりしないでください。

通常のルール設定では、ルールを上から順に確認し、一致した時点で対応するポリシーを適用します。そのため、先にある広範囲の許可ルールが、後続の拒否ルールより先に一致することがあります。FINALはそれ以前のルールに一致しなかった場合のフォールバックとして、ルール一覧の最後に置きます。追加の照合を行うルールではなく、先行ルールに一致した接続の結果を後から上書きするものでもありません。

• DIRECT：一致した接続を直接接続で処理します。
• REJECT：一致した接続を拒否します。アプリ側には失敗、再試行、タイムアウト待ちなどと表示されることがあります。表示はアプリの仕様によって異なります。
• プロキシポリシーまたはポリシーグループ：一致した接続にConfig内の対応するアウトバウンドを使用します。ポリシー名は現在のConfigで有効なものを指定してください。定義されていない名前は使用できません。

ルールが判定に使われるかどうかは、現在の動作モードにも左右されます。Home → Global Routingで選択中のモードを確認してください。この記事ではConfigを使用していることを前提に説明します。ProxyやDirectは、Configのルールが一致するかを検証する条件として同等ではありません。Sceneを使用している場合は、そのSceneで実際に適用されているルール設定を確認してください。

DOMAIN-SUFFIXの対象範囲：ドメイン全体であり、URLのパスではない

DOMAIN-SUFFIX,example.com,REJECTは、example.comやimg.example.comなどのサブドメインに一致します。文字列が似ているだけのnotexample.comには一致しません。特定のホスト名だけを対象にしたい場合は、DOMAINで完全一致させる方法を検討してください。同じドメイン末尾を使う別のサービスまで拒否するのを防げます。

以下は「完全一致の例外を先に、ドメイン末尾の拒否を後に、フォールバックを最後に」配置する例です。ここで使うドメインは構文説明用で、実際のサービスをブロックするものでも、そのまま置き換えて使えるConfigでもありません。既存のConfigに適用する前に、直接接続の例外が実際の用途に合っているか確認してください。

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

ここではkeep.example.comが先に完全一致の直接接続ルールに一致します。それ以外のexample.com配下の対象は、後続の拒否ルールに一致します。2つのルールを逆順にすると、例外が先のドメイン末尾ルールに含まれてしまいます。1つのページの問題を解決するために、共有ドメイン全体を拒否しないでください。まず、対象だと確認できた範囲に絞りましょう。

検証を始める：動作モードと使用中のConfigを固定する

トラブル対処では、一度に変更する条件は1つにします。まず現在のConfigを複製して保存し、テスト前後のルール順を記録してください。編集したファイルが現在使用中のConfigかどうかも確認します。Config一覧にある別のファイルだけを編集し、切り替えずにテストしても、ルールの構文に問題があるとは判断できません。

1. 用途を確認できるドメインを1つ選び、対象範囲を広げずに完全一致ルールからテストします。
2. 先に一致する可能性のある広範囲のルールより前にテストルールを置き、Configを保存して現在使用中であることを確認します。
3. 既存のリクエストを終了し、対象のページを開き直すか機能を再実行して、新しい接続を発生させます。
4. 接続記録でテスト時刻、接続先情報、一致したポリシーを確認します。必要に応じてConfigを保持したままVPNに再接続してから、もう一度テストしてください。
5. テストルールを削除し、同じ操作を繰り返して新しい接続結果を比較します。影響がそのルールによるものか確認してください。

On Demandは自動接続の条件を管理する機能であり、ドメイン拒否ルールの優先順位を設定するものではありません。テスト中にVPNが自動接続または切断される場合は、Settings → On Demandで関連する条件を確認し、トンネルの状態変化をREJECTの不安定な動作と取り違えないようにしてください。

同一ドメイン内のコンテンツに対する制限：接続は拒否できても、ページの一部だけを削除することはできない

本文、画像、ログインAPI、処理対象のコンテンツがすべて同じホスト名から配信されている場合、ドメインルールでリクエストの用途を区別することはできません。HTTPSリクエストのパス、レスポンス本文、ページ内の要素もDOMAIN-SUFFIXの照合対象ではありません。そのドメインを拒否すると、ログイン、認証コード、画像の読み込み、動画の再生などにも影響する可能性があります。

HTTP/3は通常UDP 443を使用し、一般的なHTTPS接続ではTCP 443が使われることもあります。ポート443という情報だけでは、接続が本文、アクセス解析、動画のどれに使われるかは判断できません。そのため、拒否ルールが特定のコンテンツだけに影響すると保証することもできません。また、接続を拒否した後にアプリが別のドメインや代替API、既存のキャッシュを使い、元のコンテンツが表示され続けることもあります。

• ページに空白ができる：リソースへの接続に失敗した可能性があります。REJECTはページを再レイアウトする機能ではありません。
• コンテンツが表示され続ける：ローカルキャッシュ、既存の長時間接続、代替ドメインを確認してください。ルールに一致していないとすぐに判断することはできません。
• ページ全体が開かない：メインサイト、認証API、共有リソースのドメインを誤って拒否していないか確認してください。

暗号化DNSとIPルール：照合時にどの接続先情報が取得できるかが重要

ドメインルールで照合するには、照合時に利用可能なドメイン情報が必要です。DNSの解決方法、キャッシュ、アプリがIPアドレスへ直接接続するかどうか、ConfigでのDNS処理方法によって、接続記録に表示される情報は異なります。「暗号化DNSを使うと、すべてのドメインルールが無効になる」とは限らず、すべてのIP接続から元のドメインを確実に特定できるとも限りません。

DoHを使うアプリは、HTTPSでDNSの解決先と通信する場合があります。このリクエストから、その後に問い合わせるすべてのドメインが直接わかるわけではありません。後続の通信でIPアドレスしか確認できず、ドメインとの関連付けに使える情報もない場合、ドメインルールに一致しないことがあります。一方、Shadowrocketで利用可能なドメインとの対応情報などを取得できていれば、ドメインに基づいて処理できる場合もあります。対象の接続記録で確認してください。

IP-CIDRはIPアドレスまたはネットワーク範囲に一致し、GEOIPはIPの地理情報データベースに基づいて分類します。どちらもページのコンテンツを分類するルールではありません。構文例のIP-CIDR,192.0.2.1/32,REJECT,no-resolveでは、文書用に予約されたIPアドレスを使用しています。/32は単一のIPv4アドレスを表し、no-resolveはこのIPルールのためにドメイン解決を明示的に開始しない指定です。欠落したドメイン情報をすべて補う設定ではなく、この例を実際のブロックにそのまま使うこともできません。

トラブル対処の結論：新しい接続の一致記録を基準にする

REJECTルールが有効か判断するには、「Configが有効になっているか」「対象に一致したか」「結果が想定どおりか」を分けて確認してください。ページにコンテンツが表示され続けているだけでは、拒否されなかったとは限りません。接続に失敗しただけでも、REJECTが原因とは断定できません。接続先、時刻、一致したルール、アプリの挙動を関連付けて確認します。

1. REJECTに一致しない：Home → Global RoutingがConfigになっているか確認し、使用中のConfig、ルールの位置、ドメインの境界、利用可能な接続先情報を確認します。
2. 一致したのにコンテンツが表示される：リクエストを再実行し、キャッシュ、既存の接続、代替ドメインを確認して、コンテンツを実際に配信している接続を記録します。
3. 一致した結果、機能に問題が出る：そのルールを削除し、より狭い範囲で検証します。複数の機能が同じドメインを使っている場合、ドメイン末尾のルールでページ内のコンテンツを切り分けようとしないでください。
4. 長期的にルールを使う場合：対象の用途、ルールを追加した理由、元に戻す方法を記録してください。Configを更新した後は、ルールが残っているか、順序が変わっていないかを再確認します。

既存のサブスクリプションは通常、接続情報を更新するためのものです。Configに含まれるルール設定は、別途確認が必要です。サブスクリプションを更新しても、拒否ルールが更新されたとは限りません。また、Configファイルの更新でローカルの変更が変わることもあります。すでに利用しているサービスとサブスクリプションがある場合は、トラブル対処時に接続情報とルールファイルの状態をそれぞれ確認してください。REJECTのテストのために接続サービスを変更する必要はありません。