REJECTは、ルールに一致した接続を拒否するためのポリシーであり、Webページの要素を除去する機能ではありません。Shadowrocketを使い、Configを変更する方に向けて、まずドメイン照合の仕組みを確認し、元に戻せるルールを1つ追加して、新しいリクエストで一致状況を検証する手順を解説します。ルールが適用されていない場合、キャッシュが残っている場合、特定のコンテンツだけを遮断できない場合を区別しましょう。
REJECTの役割：接続を拒否する。ページは編集しない
ルールは、照合条件と処理ポリシーで構成されます。DOMAIN-SUFFIX,example.com,REJECTは、ルール判定の対象ドメインがexample.comまたはそのサブドメインの場合に、REJECTで接続を拒否するという意味です。ページをダウンロードして一部を削除するわけではなく、ページ上の文字からコンテンツの種類を判定するものでもありません。
この流れには2つの前提があります。リクエストが実際にShadowrocketで処理されていること、そして現在のルーティングモードで対象のConfigルールが適用されることです。ルールをファイルに記述しただけでは、接続処理に使われているとは限りません。アプリに表示済みのキャッシュ内容を見ている場合、新しい通信が発生しないこともあります。
REJECT、DIRECT、PROXYはそれぞれ役割が異なります。DIRECTはプロキシを経由せずに接続し、PROXYはプロキシ経由で通信します。REJECTはその接続を拒否します。REJECTをDIRECTに変更しても別の遮断方法にはならず、接続を直接確立しようとする動作に変わります。
DOMAIN-SUFFIXの書き方：ドメインにプロトコルやパスは付けない
Configファイルの[Rule]セクションでは、ルールを1行ずつ記述し、フィールドを半角カンマで区切ります。以下は文法を示す単独の例であり、既存ファイルを置き換えるための完全な設定ではありません。既存ファイルに[Rule]がある場合は、そのセクションにルールを追加し、重複して作成しないでください。
[Rule]
DOMAIN,metrics.example.com,REJECT
DOMAIN-SUFFIX,ads.example.com,REJECT
FINAL,DIRECT単一ドメインの照合
- キーワード
- DOMAIN
- 照合値
- metrics.example.com
- 処理ポリシー
- REJECT
- 照合範囲
- 指定したドメインのみ。サブドメインは自動では含まれない
確認済みのホスト名だけを拒否する場合は、まず完全一致を選びます。
ドメインサフィックス照合
- キーワード
- DOMAIN-SUFFIX
- 照合値
- ads.example.com
- 処理ポリシー
- REJECT
- 照合範囲
- ads.example.comとその下位サブドメイン
範囲を広げる前に、サブドメインがログイン、画像、APIリクエストにも使われていないか確認してください。
DOMAIN-SUFFIX,example.com,REJECTはexample.comとa.example.comに一致しますが、文字列が似ているだけのnotexample.comには一致しません。任意の文字列検索ではなく、ドメイン階層に基づいて照合するため、*.example.comと書く必要もありません。
https://は付けないでください。照合値に指定するのはURL全体ではなくドメインです。/banner/image.pngのようなパスは付けないでください。パスはDOMAIN-SUFFIXの照合フィールドではありません。:443は付けないでください。ポート番号はこのドメインルールの構成要素ではありません。- 全角カンマは使わないでください。
，はルールの文法で必要な,とは異なります。
ルールの順序：最初に一致した条件で処理が決まる
この記事で扱う通常のルールは、Config内の上から順に判定され、最初に一致したルールのポリシーが適用されます。後続の拒否ルールが、すでに一致した許可ルールを上書きすることはありません。問題を調べる際は、対象ルールだけでなく、その前にあるルールも確認してください。ファイル内にREJECTがあるかどうかだけでは判断できません。
[Rule]
DOMAIN,account.example.com,DIRECT
DOMAIN-SUFFIX,example.com,REJECT
FINAL,DIRECTこの例では、まずaccount.example.comへの接続をDIRECTで許可し、その後にドメインサフィックスに一致するほかのリクエストを拒否します。サフィックス拒否ルールを先頭に移すと、アカウント用サブドメインも先にREJECTに一致し、後続の個別許可ルールは機能しません。実際に編集する際は、既存Configの出力ポリシーを維持してください。例のフォールバックがDIRECTだからといって、自分のFINALルールまでDIRECTに変更しないでください。
| ルールの種類 | 判定基準 | 確認ポイント |
|---|---|---|
| DOMAIN-SUFFIX | 対象ドメインおよびサブドメインのサフィックス | 前にあるドメイン許可ルールが先に一致していないか |
| IP-CIDR | 対象IPが指定されたネットワーク範囲に含まれるか | 同じIPアドレスで複数の異なるドメインが運用されている場合がある |
| GEOIP | 対象IPの地理的な分類 | 地理的な分類を、具体的なコンテンツの判別に代用できない |
| FINAL | 前のルールに一致しない場合のフォールバック | 通常の照合ルールの後に配置 |
ドメインルールとIPルールでは、照合に使う情報が異なります。ドメインを判定できない場合、サフィックスルールも一致するとは限りません。また、前に対象IPに一致する許可ルールがある場合は、そのルールが後続のドメインルールに与える影響も確認してください。リクエストの接続先IPが分かっただけでネットワーク範囲全体を拒否するのは避けましょう。同じIPを共有するほかのサービスにも影響する可能性があります。
Configで適用する：対象は一度に1つだけ変更
変更と検証は分けて行います。まず現在のConfigとルーティングモードを確認し、ルールを1つ追加してから新しいリクエストを確認してください。Global RoutingのConfigモードは、Configのルールに基づいて通信を振り分けます。ProxyモードやDirectモードでは、このConfigのREJECTルールが適用されるかを検証できません。Sceneモードでは、現在のシーンに実際に設定されている内容も確認してください。最初のテストでは、いったんConfigモードに切り替えるのがおすすめです。
判断のポイント：まずConfigを検証し、その後に遮断範囲を広げる
既知のドメイン1つでREJECTが一致することを確認してから、DOMAIN-SUFFIXに変更するか判断してください。Configの変更、出力先の切り替え、ルールの一括追加を同時に行うと、結果がどの変更によるものか特定しにくくなります。
- ファイルを確認。Config画面を開き、現在選択中のConfigを確認します。まずバックアップを保存してから、編集機能を開いてください。名前が同じでも、選択されていないファイルを編集しないようにしましょう。
- ルールを追加。
[Rule]セクションに、対象を明確にしたREJECTルールを1つ追加します。先に一致する可能性のある広範なルールより前に配置し、必要な個別許可ルールは残してください。 - 保存して適用。Homeに戻り、Global RoutingでConfigモードを選択して、接続スイッチがオンになっていることを確認します。必要に応じて接続を再確立し、その後のテストに保存済みConfigを使ってください。
- 新しいリクエストを発生させる。テスト中のページをいったん閉じてから対象に再アクセスし、リクエスト記録で対象ドメイン、一致したルール、処理ポリシーを確認します。すでに確立済みの長時間接続だけをテストの根拠にするのは適切ではありません。
- 元に戻して検証。追加したルールを削除して保存・再適用し、同じ対象に新しいリクエストを送ります。拒否した場合と取り消した場合で結果が変化すれば、変更との因果関係を判断しやすくなります。
Settings → On Demandは自動接続の動作を設定する項目であり、ドメインの遮断リストではありません。テスト中に接続を手動でオフにしても自動で再接続される場合は、まずOn Demandを確認してください。自動再接続を、ルールを取り消せない原因と誤認せずに済みます。Configがリモート更新で上書きされる場合は、編集内容を記録し、更新後もルールが残っているか確認してください。
遮断の限界：サフィックスだけでは同じドメイン内のコンテンツを区別できない
ドメイン単位の拒否は、対象ドメインへの接続全体が不要な場合に適しています。通常のコンテンツと遮断したいコンテンツが同じドメインから配信されている場合、DOMAIN-SUFFIXで照合される値は同じなので、一部のパスだけを許可することはできません。HTTPSリクエストに対して、このルールを暗号化されたページの内容を読み取って解析する機能として使うこともできません。
- 同一ドメインの異なるパス：
example.com/articleもexample.com/bannerも、ドメインルール上では同じexample.comです。このドメインを拒否すると、ページ全体が使えなくなる可能性があります。 - 異なる機能で同じリソースドメインを共有：画像、認証、アクセス解析が同じリソースの接続先を使うことがあります。遮断すると、コンテンツの一部だけでなく、画像の欠落、ログイン認証の失敗、ページの読み込みが終わらないといった問題が起きる可能性があります。
- ドメインの切り替えと予備の接続先：アプリによっては、接続に失敗すると別のドメインにリクエストを送ります。以前のドメインを拒否しても、すべての予備の接続先が対象になったとは限りません。
- キャッシュと既存の接続：キャッシュ済みの画像、オフラインデータ、確立済みの接続が確認を妨げることがあります。ページにコンテンツが表示されていても、それだけではルールが一致していない証拠になりません。
- ドメイン情報を取得できない：IPアドレスを直接使う接続や、アプリが独自に名前解決を処理する場合などは、ドメイン情報の取得に影響します。実際のリクエスト記録を確認し、ブラウザのアドレスバーだけから照合の経過を推測しないでください。
接続を拒否しても、ページに残った空白領域が消えるとは限りません。ページのレイアウトはアプリやWebサイト側で決まります。リソースの読み込みに失敗した後も、確保済みの領域が残ったり、エラーメッセージが表示されたりすることがあります。REJECTが扱うのは接続を続けるかどうかであり、レイアウトの修復ではありません。
よくある症状：一致記録を見て次の対応を決める
以下の確認手順は、すでに利用可能なConfigを持っていることを前提としています。サブスクリプションに関する問題の場合、リンクは利用中のサービス提供元から入手してください。クライアントの購入と通信プランは別のものです。REJECTルールの問題を解決するために、サブスクリプション全体とすべてのルーティング設定を同時に変更しないでください。
ルールを設定したのに、Webページがまだ開くのはなぜ？
まずHomeでGlobal RoutingがConfigモードになっているか確認し、次にConfig画面で現在選択中のファイルを確認します。対象ページを開き直し、新しいリクエストを確認してください。ページが別のリソースドメインを使っている場合や、キャッシュが表示されている場合もあるため、ページが表示されるかどうかだけでは判断できません。
記録にREJECTと表示されているのに、コンテンツが残るのはなぜ？
記録にあるドメインと、実際に読み込まれたコンテンツのリクエストを1つずつ照合します。アクセス解析用ドメインを拒否しても、コンテンツ用のリソースまで拒否されたとは限りません。テストページを閉じ、関連するキャッシュの影響を取り除いてから再度リクエストし、予備のドメインが使われていないか確認してください。失敗後の複数回の再試行を、拒否ポリシーが適用されていない証拠と誤解しないでください。
ルールを追加したら、ログインも画像も使えなくなった場合は？
まず今回追加したルールを取り消してConfigを再適用し、機能が復旧するか確認します。その後、DOMAIN-SUFFIXによるサフィックス照合をDOMAINの完全一致に絞り込みます。個別の許可ルールを残す必要がある場合は、広範な拒否ルールより前に配置してください。同じドメインが複数の機能を担っている場合は、遮断範囲を広げないでください。
Configの更新後、以前は有効だったルールが消えた場合は？
Config画面で更新後のファイルを確認し、バックアップと比較して、ローカルの変更が上書きされたのか、別のConfigに切り替わったのかを確認します。元の挿入位置にルールを1つ戻した後、新しいリクエストで再テストしてください。ルールセクションを重複して複数貼り付けないでください。
最終的な判断では、確認できる3つの事実を押さえます。どのConfigを使っているか、新しいリクエストがどのルールに一致したか、変更を取り消した後に症状が解消したか。これらを安定して再現できる場合にルールを残しましょう。対応関係を確認できない場合は、拒否ルールを追加し続けず、まずテスト対象を絞ってください。