この記事は、Configで通信を振り分けていて、特定の接続先をブロックしたい方向けです。まずREJECTが適用される場面を確認し、完全なドメイン名、ドメインサフィックス、接続先IPを使ってルールを設定します。最後に接続記録を確認し、ルールの適用と誤ブロックの有無を検証します。例示のドメインは構文説明用です。実際の接続先は通信記録から特定してください。
REJECTの役割：該当する接続をブロック
REJECTはポリシーであり、単独で照合条件になるものではありません。ルールの前半で接続先が条件に合うかを判定し、末尾のREJECTで一致後の処理を指定します。たとえばDOMAIN,metrics.example.com,REJECTは、完全なドメイン名で照合し、一致した通信を拒否します。あらゆる解析サービスを自動で判別したり、ドメインの一覧を自動生成したりするわけではありません。
この流れは、通信がShadowrocketの処理対象となり、ルールによる振り分けが有効であることを前提としています。REJECTは接続先へ通信内容をすべて送ってから応答画面を隠すのではなく、接続の処理段階で以降の通信をブロックします。アプリ側では接続失敗、再試行、タイムアウトなどが表示されることがあります。表示はアプリの処理方法によって異なるため、画面のメッセージだけで適用されたルールを判断することはできません。
ルールは通常、上から順に照合され、最初に一致したルールのポリシーが適用されます。そのため、「REJECTを書いた」ことと「通信にREJECTが適用された」ことは別です。前段の広い許可ルールに一致すると、後ろにあるブロックルールはその通信を処理できません。確認時は接続先、ルールの順序、現在有効なConfigをあわせて確認してください。
Configを確認してから、範囲を絞ったルールを追加
HomeのGlobal RoutingでConfigを選び、Configで現在使用中の設定ファイルを確認します。ProxyやDirectではこの手順を代用できません。Sceneを使っている場合は、現在のシーンで実際に使われている設定ファイルとルーティング方法も確認してください。設定ファイルにREJECTが書かれているだけでは、適用中とは限りません。
- Configで現在の設定ファイルのコピーを保存し、既存のルール順と
FINALポリシーを記録しておくと、元に戻す際に役立ちます。 - 使用中の設定ファイルを開き、編集画面から
[Rule]セクションを探します。まずは完全なドメイン名を使ったルールを1つ追加し、すぐに複数のドメインへ範囲を広げないでください。 - より広いルールに先に一致する可能性がある場合は、そのルールより前に追加します。サービスに必要な個別の例外は残してください。
- 設定を保存し、引き続きその設定ファイルが使用中であることを確認します。対象アプリの既存の接続を終了し、同じ操作をもう一度行ってください。
- 今回の接続先と適用ポリシーを確認します。新しい通信に
REJECTが実際に適用されたことを確認して、初めてブロックの設定が正しいと判断できます。
設定ファイルがリモートから更新される場合は、後の更新でローカルの変更が上書きされないか確認してください。サブスクリプションやノードは利用中のサービスプロバイダーから取得します。サーバーのサブスクリプション更新とConfigのルール編集は別の操作です。サーバー一覧を更新しても、新しいルールが読み込まれたことにはなりません。
DOMAIN、DOMAIN-SUFFIX、IP-CIDRの書き方
接続先をカバーできる範囲で、最も絞り込んだ条件を選びます。完全なドメイン名は単一のホストに、ドメインサフィックスはその配下のドメインもまとめて処理する場合に適しています。IP範囲は対象のアドレス範囲が確認できている場合に使います。ドメイン欄にはhttps://、パス、クエリパラメーター、ポートを入力しないでください。
ドメイン名で照合
- 完全なドメイン名
DOMAIN,metrics.example.com,REJECT- ドメインサフィックス
DOMAIN-SUFFIX,metrics.example.com,REJECT- 照合範囲の違い
- 前者は指定したホストのみ、後者はその下位サブドメインも照合します。
サフィックスはドメイン階層に基づいて照合され、任意の文字列を含むかどうかで判定するものではありません。
接続先IPで照合
- 単一のIPv4アドレス
IP-CIDR,192.0.2.8/32,REJECT- IPv4アドレス範囲
IP-CIDR,192.0.2.0/24,REJECT- 使用例
- ここでは説明用のアドレスを使用しています。実際のブロック対象を示すものではありません。
実際の接続先アドレスを確認して範囲を決め、共有アドレスを単一サービス専用と誤認しないようにしてください。
DOMAIN-SUFFIX,metrics.example.com,REJECTは、metrics.example.comとimg.metrics.example.comに一致しますが、othermetrics.example.comには一致しません。*.metrics.example.comと書く必要もありません。このルールでは、ワイルドカードはサフィックスの指定方法として使いません。
IPルールとドメインルールは同じものではありません。1つのドメインが複数のアドレスに解決される場合があり、同じアドレスが複数のドメインで共有されることもあります。クライアントが別のアドレスやIPv6を使用する場合もあります。特定のIPv4アドレスを拒否しても、関連するドメインへの接続をすべてブロックできたとは限りません。GEOIPはIPアドレスの地域情報で照合するため範囲が広く、特定ドメインを正確にブロックする用途の代わりにはなりません。
ルールの順序：例外を先に、ブロックを後に、FINALは末尾に
以下は、例外を設けるルールの例です。指定したホストへの接続は許可し、同じサフィックスに属するほかのホストは拒否します。例にあるPROXYは、Configで利用できるポリシーまたはポリシーグループ名である必要があります。現在の設定で別の名前を使っている場合は、例のフォールバックをそのままコピーせず、既存のFINAL行を残してください。
[Rule]
DOMAIN,health.metrics.example.com,DIRECT
DOMAIN-SUFFIX,metrics.example.com,REJECT
FINAL,PROXY| 接続先 | 最初に一致するルール | 結果 |
|---|---|---|
health.metrics.example.com | 1行目のDOMAIN | DIRECTを適用 |
img.metrics.example.com | 2行目のDOMAIN-SUFFIX | REJECTを適用 |
www.example.com | 末尾のFINAL | 例のPROXYを適用 |
サフィックスによるブロックを1行目に置くと、ヘルスチェック用のホストも先にREJECTに一致し、後ろのDOMAIN例外では許可できません。反対に、ブロックより前にDOMAIN-SUFFIX,example.com,DIRECTを置くと、これらの接続先は先に許可されます。FINALは残りの通信を処理するためのルールです。ブロックルールより前に置くと、後ろのルールに照合される機会がなくなります。
判断のポイント：例外が必要なら、ルールの対象範囲を絞る
必要なホストに対する個別ルールを、範囲の広いブロックルールより前に移してから、もう一度確認してください。1件の誤ブロックに対してREJECTをすべて削除したり、範囲の広いDIRECTルールで順序の問題を覆い隠したりしないでください。
ブロックできる範囲と限界
REJECTは、接続先が明確で、ドメイン名やアドレスで区別できる通信のブロックに適しています。たとえば、不要と確認できた個別のリソースホストが対象です。判定対象は接続先であり、ページ内の視覚要素を1つずつ見分けたり、コンテンツの意味を解析したりするものではありません。
- 同じドメイン内のパスは区別できません：必要な通信と不要なリソースがどちらも
api.example.comから送られる場合、DOMAINルールは両方に適用されます。/metricsのパスだけを拒否することはできません。 - HTTPS通信が復号されるわけではありません：REJECTは暗号化された本文を読み取らず、ページ構造を自動で取得することもありません。リソースへの接続をブロックしても、ページレイアウトに確保された空白が消えるとは限りません。
- キャッシュで結果が分かりにくくなることがあります：アプリがキャッシュ済みの画像やコンテンツを表示する場合があります。表示されていても、直前の通信が成功したとは限りません。画面に変化があるかだけでなく、新しい接続記録も確認してください。
- 既存の接続も考慮が必要です：ルールの変更後も、すでに確立され再利用中の接続は、新しいルールで直ちに照合されるとは限りません。テストではアプリに接続を再確立させてください。
- 接続先が変わる場合があります：代替ドメインへの再試行、アドレスの切り替え、共有インフラなどによって、ブロック範囲が変わることがあります。広い共有ネットワークをそのままブロックするのではなく、実際の接続記録を確認してください。
DNSの名前解決失敗とREJECTの適用は区別してください。前者は接続先アドレスが判明する前に起こることがあり、後者は該当するルールとポリシーの記録で確認できます。ドメインに接続できないからといって、REJECTが原因とは限りません。また、ドメイン情報を照合に使えるかどうかは、実際のリクエストと名前解決の経路によって異なります。アドレス情報しかない場合は、接続記録とIP関連ルールを確認し、ドメイン条件が必ず使えると決めつけないでください。
ルールが適用されない・誤ってブロックされる場合の対処
検証では一度に1つの条件だけを変更し、同じアプリ、同じ操作、同じネットワーク環境で変更前後の新しい接続を比較します。以下の項目を、Configが使用中か、ルールが一致しているか、キャッシュで結果が分かりにくくなっていないかの順に確認してください。
ルールを保存したのに、接続先を開けるのはなぜ？
まずHome → Global RoutingがConfigになっているかを確認し、次にConfigで実際に使用中の設定ファイルを確認します。その後、新しい接続が前段のDIRECT、PROXY、またはほかの広いルールに先に一致していないかを確認してください。設定ファイルにREJECTの行があるかだけを見ても判断できません。
REJECTに一致しているのに、ページに以前の内容が表示されるのはなぜ？
対象アプリを終了してから開き直し、キャッシュ表示と新しいリクエストを切り分けます。ページが別のドメインからリソースを取得していないかを確認し、該当する接続も記録してください。キャッシュ済みの内容が画面に残っていても、REJECTに一致した通信が許可されたことにはなりません。
サフィックスルールを追加したら、ログインや画像の読み込みにも失敗する場合は？
まず追加したルールだけを無効にして再試行し、関連があるか確認します。次に失敗した接続記録から必要なホストを特定し、より範囲の狭いDOMAINルールに変更するか、サフィックスルールより前に個別の許可例外を追加してください。親ドメイン全体を許可しないでください。
Configを更新したら、以前のブロック設定が消えたのはなぜ？
保存しておいたコピーと現在の設定ファイルの[Rule]セクションを比較し、ローカルの変更がリモートの内容で上書きされていないか確認します。検証済みの最小限のルールを追加し直し、既存のFINALは残してください。サーバーのサブスクリプション更新を、ルールの復元操作と混同しないでください。
元に戻すときは、最後に追加したブロックルールを優先して取り消し、保存してから対象への接続を再確立してください。複数箇所を変更して順序を確認できない場合は、保存しておいた設定ファイルのコピーに戻します。対象、適用ルール、復元後の結果を記録しておくと、すべての設定を何度も切り替えるより原因を特定しやすくなります。