この記事は、Shadowrocketで手元の設定を使っており、ブロックルールを少し追加したい方を対象としています。まずルールの条件とREJECTポリシーを区別し、「設定をバックアップする」「対象を絞ったルールを追加する」「順序を確認する」「新しいリクエストで検証する」の手順で進めます。例には予約済みドメインと文書用アドレスを使い、構文を説明します。既存の設定とそのまま置き換えられるブロックリストではありません。
1. REJECTはポリシーであり、ドメインのマッチ条件ではない
ルールは通常、マッチタイプ、マッチ対象、処理ポリシーで構成されます。たとえば DOMAIN-SUFFIX,ads.example.com,REJECT の場合、DOMAIN-SUFFIX がマッチ方法を指定し、ads.example.com が照合するドメインサフィックス、REJECT が一致した場合の処理ポリシーです。REJECT だけでは、どのドメインを拒否するのか指定できません。
リクエストがShadowrocketの処理対象となり、現在の設定に基づいてルールが照合されると、REJECTに一致した接続は拒否されます。そのリクエストに本来適用される可能性があったDIRECTやプロキシ経由の処理には進みません。ウェブページの要素を削除したり、空白になった領域を再レイアウトしたりする機能ではありません。アプリ側では読み込みエラーやプレースホルダー、再試行の案内が表示される場合があります。
ルールの照合は接続処理中に行われますが、「REJECTに一致すればDNS問い合わせが一切発生しない」とは限りません。実際の挙動は、名前解決やキャッシュ、IPルールの照合に必要なアドレスの取得などに左右されます。REJECTの役割は一致した接続を拒否することであり、単独のDNSプライバシー設定ではありません。
2. よく使う書き方：ドメイン指定、サフィックス、IP範囲
まずはドメインを完全一致で指定し、サブドメイン全体も拒否すべきと確認できた場合に限ってDOMAIN-SUFFIXへ範囲を広げます。ルールのドメインに https://、パス、クエリパラメーター、末尾のスラッシュは付けません。以下の各行は構文の説明用です。同じ設定にすべて追加する必要はありません。
[Rule]
DOMAIN,ads.example.com,REJECT
DOMAIN-SUFFIX,metrics.example.com,REJECT
IP-CIDR,192.0.2.0/24,REJECT,no-resolve
IP-CIDR6,2001:db8::/32,REJECT,no-resolve| ルールタイプ | マッチ範囲 | 使用上の注意 |
|---|---|---|
DOMAIN | 指定したドメインと完全一致。 | 確認済みのホスト名を1つだけ拒否する場合に適しています。 |
DOMAIN-SUFFIX | 指定したドメインとそのサブドメイン。 | metrics.example.com は a.metrics.example.com にも一致しますが、othermetrics.example.com には一致しません。 |
IP-CIDR | IPv4アドレスの範囲。 | 共有アドレスには正常なサービスも同居する可能性があります。ドメインの名前解決で得たアドレスを、専用アドレスとみなさないでください。 |
IP-CIDR6 | IPv6アドレスの範囲。 | IPv4ルールだけでは、IPv6の宛先アドレスを対象にできません。 |
no-resolve は、このIPルールのためにドメイン名をIPアドレスへ積極的に名前解決するのを避ける指定です。すべてのDNS名前解決を無効にする意味ではなく、宛先がすでにIPアドレスのリクエストの照合も妨げません。例にある 192.0.2.0/24 と 2001:db8::/32 は文書用アドレスです。実在するサービスがブロックされることを期待しないでください。
判断の基本：マッチ範囲を絞ってからブロック範囲を広げる
不要なリクエストを送信するホスト名が1つだけ確認できた場合は、まずDOMAINルールを追加します。サブドメインごとの用途を確認してからDOMAIN-SUFFIXに切り替え、共有ネットワーク全体を先にブロックするのは避けてください。
3. ルールの順序：例外を先に、FINALを最後に
通常のルールリストでは、リクエストは上から順に照合され、最初に一致したルールで処理ポリシーが決まります。REJECTをリストの末尾に置いても、前にある許可ルールを上書きするわけではありません。同様に、先に広範囲なブロックルールに一致すると、後続の例外ルールで取り消すことはできません。
[Rule]
DOMAIN,assets.ads.example.com,DIRECT
DOMAIN-SUFFIX,ads.example.com,REJECT
IP-CIDR,192.0.2.0/24,REJECT,no-resolve
GEOIP,CN,DIRECT
FINAL,DIRECTこの例では、assets.ads.example.com は先に完全一致の例外ルールに一致し、video.ads.example.com は次のサフィックスブロックルールに一致します。GEOIPは宛先IPの地理的な割り当てに基づいて照合するもので、コンテンツの用途は判別しません。ブロックルールより前に置くと、条件に一致するリクエストが先にDIRECTになる場合があります。FINALは前のルールに一致しなかった場合のフォールバック項目なので、ルールリストの末尾に置きます。
完全一致の例外
- タイプ
DOMAIN- 対象
assets.ads.example.com- ポリシー
DIRECT- 配置
- 対象を含むサフィックスブロックルールより前に置きます。
DIRECTは直結を意味するだけです。実際の例外には、その通信に必要な利用可能なポリシーを指定してください。
サフィックスによるブロック
- タイプ
DOMAIN-SUFFIX- 対象
ads.example.com- ポリシー
REJECT- 配置
- 完全一致の例外の後、広範囲な許可ルールとFINALの前に置きます。
ここでのFINAL,DIRECTはフォールバックの説明用です。既存のルーティングポリシーを置き換えるものではありません。
ルールを統合する場合は、既存の [Rule] セクションに該当する行を挿入します。セクション全体を重ねて貼り付けたり、既存のプロキシポリシー、ルール参照、フォールバック設定をそのまま削除したりしないでください。外部ルールの参照がある場合は、参照位置を含めて全体の順序を確認します。追加した数行だけを見て判断しないでください。
4. Configで編集して動作を確認する
ルールは設定に保存されます。すでに利用しているノードのサブスクリプションは主に接続情報を提供するもので、更新してもルール編集の代わりにはなりません。作業前に現在利用できる設定を保存し、Configを開いて、編集中の設定と使用中の設定が同じものか確認してください。リモート設定の更新でローカルの変更が置き換わることがあるため、カスタムルールのコピーを保管します。
- 現在の状態を記録する。Home → Global Routingの現在の選択項目と、Configで有効になっている設定を記録し、元のファイルを保管して復元できるようにします。
- テストルールを1つだけ追加する。Configで対象設定の編集画面を開き、
[Rule]内に確認済みの対象を指定するDOMAINルールを追加します。先に一致する可能性のある広範囲なルールより前に置き、保存して設定を有効にします。 - ルールモードを使う。Home → Global RoutingでConfigを選択します。ProxyとDirectはグローバルな処理方法が異なるため、同じConfigルールの動作確認には使えません。Sceneを使っている場合は、シーンで実際に選ばれている設定とルーティング状態を先に確認してください。
- リクエストを新しく発生させる。接続が有効になっていることを確認し、対象のページを閉じてから開き直します。必要に応じて接続をいったん切って再接続し、新しい接続を開始してください。既存の長時間接続で画面を更新するだけでは、ルールの変更が反映されない場合があります。
- 記録を確認する。接続またはログの記録で、対象ドメイン、宛先アドレス、マッチしたルール、処理ポリシーを確認します。判断材料にするのは新しいリクエストがREJECTに一致した記録です。ページの一部が一時的に消えたことだけで判断しないでください。
5. ドメインブロックの限界と誤ブロックの原因
DOMAINとDOMAIN-SUFFIXが対象とするのはホスト名であり、ページ内の特定のコンテンツではありません。HTTPSリクエストでは、https://example.com/news と https://example.com/promo のように同じホスト上の異なるパスを、この2種類のドメインルールだけで区別できません。example.comを拒否すると、両方のパスに対応する接続に影響します。
- 正常なコンテンツとブロック対象が同じドメインを共有している。画像、ログイン、決済認証、アクセス解析で同じインフラが使われることがあります。ログインできない、画像が表示されないといった問題が起きたら、まず直近で追加したルールを戻し、ホスト名を1つずつ確認してください。
- リクエストの宛先がIPアドレスのみ。ルールエンジンが関連するドメイン名を取得できない場合、DOMAIN-SUFFIXだけではIPアドレスから所属ドメインを判別できません。一致しない原因をすべてルールの順序に求めないでください。
- コンテンツがキャッシュまたは既存の接続から読み込まれている。オフラインデータ、ローカルキャッシュ、再利用中の接続によって、変更後もページに変化がないように見えることがあります。以前のページを見るだけでなく、ルールを有効にした後の新しいリクエストを確認してください。
- ホスト名やネットワークアドレスが変わる。ドメインが代替ホストに切り替わったり、アドレスが変わったりすることがあります。一時的な名前解決結果に対してIP-CIDRルールを作ると、すぐに効かなくなる場合があるうえ、同じアドレスを共有する別のサイトまで誤ってブロックする可能性があります。
- 対象の設定を使ってリクエストが処理されていない。接続が有効でない、別の設定が選ばれている、Global Routingの状態が想定と異なるといった状況では、検証結果が正しくありません。ブロック範囲を広げる前に、処理経路を確認してください。
ドメインを拒否するためにHTTPS復号を有効にする必要は通常ありません。証明書を追加したり、無関係な設定を変更したりしても、「同じドメインが複数の種類のコンテンツを配信している」というマッチ範囲の問題は解決しません。個別に区別できないリソースについては機能上の限界を踏まえ、REJECTルール1つですべての該当コンテンツを削除できるとは考えないでください。
6. よくある質問：未一致、誤ブロック、更新による巻き戻り
REJECTを追加したのに、ページがまだ開くのはなぜ？
まず、対象がページ全体のホストなのか、ページ内のリソース用ホストなのかを確認します。Home → Global RoutingでConfigを選択しているか確認し、続いてConfigで有効なファイルを確認してください。新しいリクエストを発生させてログを確認し、別のホスト名が使われていた場合は、記録に基づいて完全一致ルールを追加します。同じ行を何度も追加しないでください。
ルールに一致したら、正常な画像まで表示されなくなりました。どうすればよいですか？
まずバックアップを復元するか、直近で追加したブロック行を削除して、画像が戻ることを確認します。その後、DOMAIN-SUFFIXを確認済みのDOMAINに絞り込みます。正常なコンテンツ用に独立したホストがある場合は、その完全一致の例外をブロックルールより前に置きます。画像と拒否対象が同じホストを共有している場合、ドメインルールだけでは分けられません。
既存のサブスクリプションを更新しても、ルールが変わらないのはなぜ？
まず更新したのがHomeのノードサブスクリプションか、Configのリモート設定かを確認します。前者はルールの更新ではありません。後者はローカルの編集内容を上書きする可能性があります。Configに戻って実際に使っているファイルの[Rule]の内容を確認し、自分で管理するルールと元の設定をそれぞれバックアップして、更新後に項目ごとに照合してください。
FINALをREJECTに変えれば、ルールを個別に追加しなくて済みますか？
FINAL,REJECTは、それ以前のルールに一致しなかったすべての接続を拒否するため、ドメイン1つをブロックするよりはるかに広い範囲に影響します。明確な許可リストを管理している場合を除き、対象を指定したルールの代わりに使わないでください。まず元のFINALポリシーに戻し、対象を絞ったDOMAINまたはDOMAIN-SUFFIXを追加します。
7. 保存前の最低限のチェックリスト
管理しやすいREJECT設定では、「どの対象を拒否するのか」「なぜこのマッチ方法を使うのか」「例外はどこか」「どうすれば元に戻せるか」の4点を説明できる必要があります。未確認のルールを一度に大量に読み込むより、1回の変更でマッチ条件を1つだけ変え、変更前後の記録を残すほうが問題の切り分けが容易です。
- ルールが実際に有効な設定の
[Rule]内にあり、ドメイン欄にプロトコルやパスが含まれていない。 - 完全一致の例外が対応するブロックルールより前にあり、ブロックルールが先に一致する可能性のある広範囲なルールより前にある。
- FINALは元のフォールバック用途のままにし、ブロックルールを追加したからといって不用意に変更しない。
- Home → Global RoutingでConfigを選択し、新しい接続記録で実際のマッチ結果を確認した。
- ログイン、画像、その他必要な機能を確認し、復元できる元の設定を保存した。