ShadowrocketのREJECTルールの仕組み｜ルールで遮断できる通信とその限界

REJECTが適用される仕組み

Shadowrocketは、設定内のルールに基づいて通信を処理します。REJECTは、ルールに一致したリクエストを拒否する指定です。DIRECTやPROXYと同じくルールの末尾に指定する処理方針ですが、処理結果は異なります。ルールは対象を選び、処理方針はその対象をどう扱うかを決めます。この2つを混同しないようにしましょう。

この流れは、Shadowrocketの処理対象となり、最終的にREJECTに一致したリクエストについて説明しています。アプリのスイッチをオンにしただけでは、必ず設定ルールに従って通信が振り分けられるとは限りません。まずHomeでGlobal Routingを確認してください。現在の設定にある拒否ルールを検証する場合はConfigを選び、編集した設定が選択されていることも確認します。

• Global Routing → Config：現在の設定ルールに従ってリクエストを処理します。この記事のルール検証では、この設定が前提です。
• Global Routing → Proxy：すべての通信をプロキシ経由にする設定です。これだけでは、設定内の特定のREJECTルールが有効かどうかを検証できません。
• Global Routing → Direct：すべての通信を直接接続する設定です。この状態でも、設定ルールが適用された証拠にはなりません。
• Settings → On Demand：条件に応じて自動接続する動作を管理します。REJECTするドメインを定義する機能ではありません。

Global RoutingでSceneを使用している場合も、スイッチの状態だけでルールの適用経路を推測せず、現在のSceneの設定を確認してください。トラブルシューティング中はConfigに条件を固定すると、自動切り替えや異なる接続モードによる影響を減らせます。

ルールがリクエストを判定する仕組み

基本的なルールは、照合タイプ、照合する内容、処理方針で構成されます。たとえばDOMAIN-SUFFIX,example.com,REJECTの場合、照合タイプはDOMAIN-SUFFIX、対象はドメイン末尾のexample.com、処理方針はREJECTです。example.comは説明用に予約されたドメインであり、実際に遮断すべきサービスを示すものではありません。

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

この例はルールの順序を説明するもので、設定全体を置き換えるためのものではありません。設定ルールは上から順に照合されます。login.example.comと判定できるリクエストには、先にある個別ルールが適用されます。example.comで終わるその他のドメインは拒否され、それ以前のルールに一致しないリクエストはFINALで処理されます。DIRECTは例外ルールの例です。実際の環境では、そのサービスで本来使える処理方針を維持してください。

ドメインルールは照合可能なドメイン情報を必要とし、IPアドレスルールは接続先のアドレスに基づいて判定します。名前解決の処理、DNSキャッシュ、アプリがIPアドレスを直接使うかどうかによって、確認できる情報は変わることがあります。ブラウザーのアドレスバーだけを見て、関連するすべての接続に同じドメイン情報が使われていると判断しないでください。

遮断できる対象

REJECTが処理するのはリクエストであり、画面上の特定の部分ではありません。ページはメイン文書、画像、フォント、アクセス解析用のAPI、ログイン用のAPIなどに同時にリクエストすることがあります。そのうち特定のドメインを正しく照合できれば、その接続先へのリクエストを拒否できます。それ以外のページ表示に影響するかどうかは、その接続先にページが依存しているかによります。

HTTPSでは通常TCP 443、HTTP/3では通常UDP 443が使われますが、ポート番号だけではリクエストの用途を特定できません。同じドメイン上の通常のAPIと別のリソースが、どちらも443を使うことがあります。DOMAIN-SUFFIXにはポートによる絞り込み条件がないため、接続先のポートが変わっても、別の用途を判別する仕組みにはなりません。

誤判定が起きる理由

よくある誤判定は、構文の間違いではなく、照合範囲が想定より広いことが原因です。DOMAIN-SUFFIX,example.com,REJECTを設定に追加すると、login.example.com、static.example.com、api.example.comも対象になります。ログイン画面は開くのに送信できない、本文は表示されるのに画像が読み込まれないといった問題は、機能ごとに異なるサブドメインを使っているために起こることがあります。

1. ルートドメインの範囲が広すぎる：ads.example.comだけを拒否するつもりでexample.comを指定すると、アカウント機能、画像、APIにも影響します。
2. 共有アドレスをまとめて拒否：複数のドメインが同じホスティング先や配信先のアドレスを使う場合があります。一度確認したIPアドレスをIP-CIDRの範囲に広げると、無関係なサービスまで拒否するおそれがあります。
3. 必要な機能を追加リソースと誤認：CAPTCHA、アカウント認証、決済画面への遷移、メディアの認証などが別のドメインに依存している場合があります。ページ自体は表示されても、重要な操作を完了できなくなることがあります。
4. 例外ルールの順序が不適切：広い拒否ルールの後ろに個別の許可ルールを置いても、先に一致したルールで処理方針が決まるため、後の例外では修正できません。
5. 編集した設定と適用中の設定が異なる：Config内のファイルを変更しても、実際には別の設定が選択されていて、調査の方向がずれてしまうことがあります。

「ときどき使える」場合も、REJECTがランダムに効かなくなるとすぐに判断しないでください。既存の接続が再利用されていたり、キャッシュが読み込まれていたり、別のサービスドメインに切り替わっていたりする可能性があります。同じ操作を条件を変えずにやり直し、そのときの記録で接続先を確認します。ページやアカウントの状態が異なる2回の結果を、そのまま比較しないでください。

一度に変更する条件を1つにする

拒否ルールを検証する前に、元に戻せる設定を保存し、対象を1つだけ変更します。処理方針の切り替え、DNSの調整、サブスクリプションの更新、複数ルールの追加を同時に行うと、機能が復旧しても原因を特定できません。以下の手順では、現在のサービスを変更せず、ローカルのルールと実際のリクエストだけを確認します。

1. 変更前の状態を記録：「ログイン画面を開いてフォームを送信する」など、失敗する操作と発生時刻を書き留めます。変更前に正常に動作していたかも確認します。
2. 接続モードを固定：Home → Global RoutingでConfigを選択し、Configで現在の設定を確認します。テスト中に接続モードが自動で変わる場合は、Settings → On Demandの条件も確認してください。
3. 同じ操作を再現：同じ操作をもう一度実行し、アプリ内で利用できる接続記録やログから、その時刻の接続先ドメイン、IP、該当ルール、処理方針を探します。記録に表示される項目だけを書き留め、情報を推測で補わないでください。
4. ルールの範囲を狭める：広範囲のDOMAIN-SUFFIXに一致している場合は、テスト用のコピーからそのルールを外し、実際の接続先に応じてDOMAINに変更します。それ以外のルールと元のフォールバック方針は維持してください。
5. 適用して再テスト：設定を保存し、変更が適用されたことを確認します。必要に応じて、ネットワーク処理を中断できるタイミングで再接続し、既存の接続が再利用されないようにして同じ操作を試します。
6. ルールを戻して比較：そのルールを外すと復旧し、再び追加すると失敗することを確認できれば、原因をそのルールに絞り込む有力な根拠になります。比較できない場合は、許可範囲を次々と広げず、ほかのルールや接続先を調べてください。

ログに接続失敗が記録されていても、REJECTに一致した証拠とは限りません。DNSの名前解決失敗、接続タイムアウト、接続先からのエラーも「開けない」原因になります。まず処理方針と一致したルールの項目を確認してください。記録だけでは情報が足りない場合、原因は未確認として扱います。調査内容を共有する前に、サブスクリプションURLの認証情報、アカウント情報、不要なアクセス記録を隠してください。

よくある質問と対処方法

日常のメンテナンスでは、拒否した接続先の完全な名前、ルールを追加した理由、取り消す方法の3点を記録しておくと便利です。通常の機能に問題が出たら、まず最近の変更を確認し、条件を1つずつ変えて再テストしてください。ルールの数は効果を示す指標ではありません。対象範囲が明確で、照合結果を説明でき、すぐに元へ戻せることが長期的な管理につながります。