REJECTは、ルールに一致した接続を拒否するポリシーであり、ページ要素を選択する機能ではありません。Shadowrocketを利用中で、特定ドメインへの接続を制限したい方に向けて、DOMAINとDOMAIN-SUFFIXの書き方、Global Routingの選択、ルールの優先順位、誤ってブロックした場合の確認方法を説明します。利用中のサービスと有効な設定があることを前提に、まず設定をバックアップし、ルールを1つだけ追加して検証してください。提供元が不明な大規模リストをそのまま読み込むのは避けましょう。
REJECTが適用される仕組み
ルールは、照合条件と一致した場合のポリシーで構成されます。たとえば、DOMAIN,ads.example.com,REJECTでは、DOMAINが完全なドメイン名との照合、ads.example.comが照合対象、REJECTが拒否処理を指定します。DIRECTとの違いは、DIRECTが宛先への直接接続を試みるのに対し、REJECTは一致した接続を通常の直接接続やプロキシ経由で宛先に届けないことです。
上記の流れは、Shadowrocketが捕捉し、ルール判定の対象となったリクエストについて説明しています。ドメインルールに一致するかどうかは、接続に照合可能なドメイン情報があるかにも左右されます。接続記録に宛先IPしかなく、関連付けられたドメインがない場合、ブラウザーのアドレスバーに表示された名前だけを根拠にDOMAINルールが必ず一致すると判断することはできません。
REJECTはDNSの書き換えでも、ウェブページの編集でもありません。HTTPSレスポンス内のページ構造を自動で読み取ることはなく、ボタンの文字や画像の位置を基準にコンテンツを削除する機能もありません。ブラウザーでは、リソースの読み込み失敗や画像の欠落、リクエストエラーとして表示される場合があります。実際の表示はサイト側のエラー処理によって異なるため、特定の画面表示をREJECTの決まった効果と考えないでください。
ドメインルールの基本形
設定ファイルのルールは通常、[Rule]セクションに記述します。以下のドメインは説明用の例であり、実際に使えるブロックリストではありません。設定する際は、自分の接続記録で対象の名前を確認し、目的の範囲に合うルールだけを追加してください。ドメイン名にadsやtrackが含まれているだけで、安全にブロックできると判断してはいけません。
[Rule]
DOMAIN,ads.example.com,REJECT
DOMAIN-SUFFIX,metrics.example.net,REJECT
FINAL,DIRECT1行目はads.example.comだけに適用され、img.ads.example.comには適用されません。2行目はmetrics.example.net自体と、event.metrics.example.netのようなサブドメインに適用されますが、notmetrics.example.netのように文字列の一部が一致するだけのドメインには適用されません。ドメイン欄にプロトコル、パス、クエリパラメーター、ポート番号は入力しません。
範囲を限定
- キーワード
DOMAIN- 照合する値
ads.example.com- ポリシー
REJECT- 適用条件
- 単一ホストの用途を確認できている場合に、まず範囲を絞って検証します。
同じサービス内のほかのホストへの影響を抑えるため、まず完全なドメイン名を指定します。
サフィックスの範囲
- キーワード
DOMAIN-SUFFIX- 照合する値
metrics.example.net- ポリシー
REJECT- 適用条件
- 対象ドメインとその配下のホストをまとめて拒否してよいと確認できている場合。
サフィックスで範囲を広げる前に、その配下にログイン、画像、APIなどのサービスがないか確認します。
例のFINAL,DIRECTは、最小限のルールセクション全体を示すためのもので、前のルールに一致しなかった場合にDIRECTへ進むことを意味します。既存の設定では、別の最終ポリシーが使われている場合があります。REJECTを追加するために既存のFINALを置き換えたり、例全体を既存のFINALの後ろに追加したりしないでください。通常、変更するのは対象を拒否するルールだけです。既存のルーティング構成は維持してください。
- 正しい例：
DOMAIN,ads.example.com,REJECT。 - ドメインを
https://ads.example.com/bannerのように記述しないでください。DOMAINはURLのパスには一致しません。 - HTTPSで一般的なポート
443やHTTPで一般的なポート80を使うからといって、ドメイン欄に:443や:80を入力する必要はありません。 - ドメイン全体を拒否する必要がない限り、単一ホストのルールの代わりに、親ドメイン
example.comを対象とするサフィックスルールを使わないでください。
Configを有効にしてルールの優先順位を確認
ルールを記述しただけでは、現在の接続に適用されるとは限りません。まずConfigで、編集中の設定が現在使用中のものか確認して保存します。次にHome → Global Routingに戻り、Configを選択してください。ProxyとDirectはグローバルなルーティング設定であり、設定ファイル内の個別ルールを検証する際には使いません。Sceneではシーン設定に応じて実際のルーティングが決まるため、トラブル対処時は現在の選択内容を確認し、SceneをConfigと同じものとして扱わないでください。
- バックアップ：Configで元の設定のコピーを保存し、既存のFINALと対象ドメイン付近のルールを記録します。
- 追加：確認済みのDOMAIN拒否ルールを、先に一致する可能性のある広範なルールより前、かつFINALより前に配置します。
- 選択：Homeに戻り、Global RoutingをConfigに設定して、接続が有効になっていることを確認します。
- 再試行：対象のページやアプリを終了してから、もう一度アクセスします。必要に応じて再接続し、新しい接続でテストしてください。
- 確認：今回のリクエストの宛先、一致したルール、最終ポリシーを確認します。新しい記録がない場合は、すぐにルールが無効だと判断しないでください。
ルールは上から順に評価され、最初に一致したルールのポリシーが適用されます。たとえば、先にDOMAIN-SUFFIX,example.com,DIRECTを書き、その後にDOMAIN,ads.example.com,REJECTを書くと、対象が先の親ドメインルールに一致するため、後者が実行されない場合があります。GEOIPはIPアドレスの地域情報、IP-CIDRはアドレス範囲を基準に照合します。ページの分類に使うものではなく、配置順も含めて確認する必要があります。
[Rule]
DOMAIN,ads.example.com,REJECT
DOMAIN-SUFFIX,example.com,DIRECT
FINAL,DIRECTこの順序は「指定したホストを先に拒否し、同じドメイン範囲の残りは許可し、最後にフォールバックする」構成です。既存の設定にルールセットやポリシーグループがある場合は、それらが先に対象を処理していないかも確認してください。REJECTの記述を1つ見つけただけで調査を終えず、現在の設定、ルーティングの状態、実際の一致記録が整合していることを確認します。
適用範囲とページに残るコンテンツ
単独でブロックしやすいのは、用途が確認でき、主要な機能から比較的独立したリクエスト先のドメインです。ドメイン名が計測サービスのように見えるだけでは、アプリの機能に影響しないとは限りません。セッションの初期化、機能の切り替え、リソース署名などを兼ねるAPIもあり、拒否すると計測が止まるだけでなく、アプリが次の画面に進めなくなることがあります。
| リクエストの状況 | REJECTでできること | 注意点 |
|---|---|---|
| 独立したリソースホスト | そのホストへの接続を拒否する | 必要なリソースの配信元ではないことを確認してください。 |
| 同じドメインの異なるパス | ドメインルールは、そのホストへの関連する接続全体に影響します | /bannerだけを拒否し、同じホストの/loginを残すことはできません。 |
| 本文に埋め込まれたコンテンツ | 1つのレスポンス内の一部分を、独立したドメインルールで取り除くことはできません | レスポンスに含まれる画像データやテキストは自動的に削除されません。 |
| ローカルキャッシュのリソース | 以後のリクエストのうち、ルールに一致するものだけに影響します | キャッシュから読み込まれる場合、対象への新しい接続が発生しないことがあります。 |
| 共有CDNのIPアドレス | IPルールはそのアドレスへの接続に影響します | 同じIPで複数の無関係なドメインがホストされている場合があり、誤ってブロックする範囲が広がります。 |
判断のポイント：まずホスト単位に絞り、必要な場合のみ範囲を広げる
同じサフィックス配下のホストをすべて拒否してよいと確認できた場合に限り、DOMAINをDOMAIN-SUFFIXに変更してください。対象コンテンツがログインや本文と同じホストを使っている場合は、ページ全体を消すためにドメイン範囲を広げるのではなく、範囲の拡大を止めましょう。
HTTPSで暗号化されたコンテンツは、REJECTを設定しても部分ごとに選別できる平文にはなりません。この記事のドメインルールを使うために、HTTPS Decryptionを有効にしたり、復号証明書をインストールしたりする必要はありません。ページ内の特定要素を削除したい場合はコンテンツ層の処理が必要です。接続層のルールが機能したかどうかで代用して判断することはできません。
新しい接続で検証し、元に戻せる状態を保つ
検証では、説明用のドメインを開いて特定の結果を期待するのではなく、実際に確認できているリクエストを対象にします。まずルールを追加する前の状態を記録し、ルールを1つ追加して新しいリクエストを発生させ、一致状況を確認してください。1回の検証で変更する条件を1つに絞れば、ルールの順序、キャッシュ、接続の再利用、対象側の変化を切り分けやすくなります。
- 基準を記録：元の設定で対象の操作を1回行い、時刻とドメインに加え、ログイン、画像、再生など必要な機能が正常か記録します。
- 1ルールで検証：完全なドメインを指定するDOMAINルールを1つ追加し、保存して現在の設定を確認します。サービス、プロトコル、DNSの設定を同時に変更しないでください。
- 新しいリクエストを発生：対象のアプリやページを開き直します。更新してもキャッシュが使われる場合があり、既存の長時間接続ではルールの判定がすぐにやり直されないこともあります。
- 記録を確認：新しい接続記録に、想定した宛先とREJECTが表示されているか確認します。別のホストが記録されている場合は、推測したドメインをまとめて追加せず、リクエストの経路を確認してください。
- 元に戻して検証：追加したルールを削除するかコメントアウトして、同じ操作を再試行します。ルールの追加と取り消しに応じて不具合が再現・解消する場合に限り、そのルールを主な原因候補と考えます。
- 記録を残す：効果を確認できたら、ブロックする理由と影響範囲を記録します。設定が更新された後も、ローカルで変更したルールが現在使用中のファイルに残っているか再確認してください。
購入先や設定の入手元が混同されている場合は、アプリと接続サービスを分けて考えてください。Shadowrocketはクローズドソースの有料アプリです。アプリの買い切り購入と通信サービスのプランは別です。この記事ではノードやサブスクリプションの提供、販売、推奨はしていません。既存のサブスクリプションを更新しても、ローカルのREJECTルールが保持されるとは限らないため、サービス情報と設定ファイルの更新結果をそれぞれ確認してください。
よくある質問と設定の復元
REJECTを設定したのに、ページに元の画像が表示されるのはなぜですか？
まず新しい接続が発生したか確認してください。ページがローカルキャッシュを使っている場合や、別のホストから同じリソースを読み込んでいる場合があります。ページを開き直して対象リクエストの記録を確認しましょう。対象がREJECTに一致しているのに画像が表示される場合は、レスポンスに埋め込まれたコンテンツかどうかを確認し、サフィックスの範囲を広げないでください。
接続スイッチはオンなのに、ルールがまったく反映されないのはなぜですか？
Home → Global RoutingがConfigになっているか、Configで現在使用中のファイルに新しいルールが含まれているか、FINALや先に一致するほかのルールより前に配置されているかを順に確認します。その後、新しい接続を発生させてください。ファイルを保存しただけで、別の設定を使い続けている場合、新しいルールは適用されません。
ブロック後にログインできなくなりました。設定全体を削除する必要がありますか？
まず直近に追加したルールだけを取り消し、ほかの設定は変えずに再接続してログインを試してください。正常に戻った場合は、サフィックスルールを確認済みの単一ホストに絞るか、そのドメインへのアクセスを許可します。認証、リスク管理、APIで共有されるドメインは、名前だけを根拠に拒否しないでください。
プロトコルを変更すると、REJECTでより確実にブロックできますか？
プロトコルを変更しても、ページのコンテンツを選別できるようにはなりません。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuardは接続や通信方式に関するものです。REJECTの適用範囲は照合条件、ルールの優先順位、現在のルーティングによって決まります。まずルールを見直し、ブロック範囲を広げる手段としてプロトコルを変更しないでください。
最終的には、内容を説明でき、検証や取り消しが可能なルールだけを残してください。機能に問題が起きたら、まず直近の変更を取り消し、一致記録を確認します。対象を独立したホスト単位で切り分けられない場合は、接続層ルールの限界を受け入れるほうが、拒否範囲を広げ続けるより通常のアクセスを保ちやすくなります。