ShadowrocketのREJECTルール設定|ドメイン単位で通信を遮断する仕組みと限界

ShadowrocketのREJECTルールの仕組みやDOMAIN-SUFFIXとの使い方、遮断できない通信、誤遮断によるページ表示の不具合を解説します。

この記事の概要

この記事は、Shadowrocketで自分の設定を使用しており、ドメインを指定して特定の接続を拒否したい方向けです。まずマッチ条件とREJECTポリシーの違いを確認し、例示用ドメインを使ってルールの順序、例外、確認方法を説明します。最後に、遮断されない場合やページに不具合が起きた場合の確認ポイントを紹介します。例には利用可能なサービス情報は含まれず、設定全体を置き換えるものでもありません。

1. REJECTはポリシーであり、対象を識別する条件ではない

ルールでは通常、まず「何にマッチするか」を指定し、次に「マッチした通信をどう処理するか」を定めます。DOMAIN-SUFFIXはドメインのサフィックスにマッチする条件、REJECTは接続を拒否するポリシーです。この2つを組み合わせると、対象ドメインにマッチした接続をプロキシや直接接続で確立しないようにします。ページを解析して特定の要素を削除する機能ではありません。

通信がトンネルに入る 接続先情報を識別 ルールを順に照合 ポリシーを適用

この記事のルールを検証するときは、Home → Global Routing → Configで設定によるルーティングを選び、編集した設定が現在有効になっていることを確認してください。Proxy、Direct、Sceneのルーティング動作は、ここでのConfigによるテスト条件と同じではありません。接続スイッチがオンでも、指定したルールファイルが判定に使われているとは限りません。

Settings → On Demandでは、条件に応じてVPNを接続・切断する動作を設定します。特定のドメインをREJECTにする機能ではありません。確認の際は「トンネルが接続されているか」「設定が有効か」「リクエストがどのルールにマッチしたか」を分けて確認し、自動接続の設定をドメイン遮断のスイッチと混同しないでください。

3項目
DOMAIN-SUFFIXの例:キーワード、ドメイン、ポリシー
2項目
FINALの例:キーワードと最終処理ポリシー
1ルール
通常の順次照合では、最初にマッチしたルールのポリシーが適用されます

2. DOMAINとDOMAIN-SUFFIXの正しい書き方

以下の例では、構文の説明に予約済みの例示用ドメインを使います。ルールは設定の[Rule]セクションに記述します。すでにセクションがある場合は、その中を編集してください。ルールを追加するためにセクションを重複して作成する必要はありません。ドメイン欄にはプロトコル、パス、ポート、クエリパラメーターを含めず、区切りには半角カンマを使います。

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

この最小例では、account.example.comは先に完全一致の例外ルールにマッチし、DIRECTになります。example.comとimg.example.comはサフィックスルールにマッチし、REJECTになります。notexample.comは該当ドメインのサフィックスではないため、末尾の文字列が似ているだけではマッチしません。最後の行は最終処理の位置を示す例であり、既存のFINALポリシーをDIRECTに変更する指示ではありません。

完全一致のドメインルール

キーワード
DOMAIN
対象
metrics.example.com
ポリシー
REJECT
ルール全体
DOMAIN,metrics.example.com,REJECT

このドメインだけにマッチし、サブドメインは自動的に対象になりません。

ドメインサフィックスルール

キーワード
DOMAIN-SUFFIX
対象
metrics.example.com
ポリシー
REJECT
ルール全体
DOMAIN-SUFFIX,metrics.example.com,REJECT

該当ドメインとそのサブドメインにマッチします。同じ階層の別ドメインは対象外です。

metrics.example.comだけを拒否したい場合、example.com全体に対象を広げるべきではありません。同じドメイン配下でログイン、画像、決済コールバック、計測用リクエストを処理している場合があります。サフィックスの範囲を広げるほど、誤遮断の影響も大きくなります。まずDOMAINで対象を確認し、実際のリクエストに応じてDOMAIN-SUFFIXが必要か判断してください。

3. ルールの順序:具体的な例外を先に、FINALを最後に

通常の順次照合では、最初にマッチしたルールで処理方法が決まります。後から出てくる、より具体的なルールが先行する広い範囲のルールを自動的に上書きすることはありません。したがって、REJECTの行がファイルに存在するだけでは有効になりません。その行に到達する前に、別の条件でリクエストが処理されていないかも確認してください。

位置または条件想定される判定確認・対応
サフィックスルールより前に完全一致のDOMAIN例外がある指定したホストには先に例外ポリシーが適用される例外が本当に必要か、維持するホストだけに範囲を絞れているか確認する
完全一致ルールより前に広いDOMAIN-SUFFIXがある後続の完全一致ルールでは、すでにマッチしたリクエストを処理できないルールの順序を調整する。同じルールを重ねて追加するだけでは解決しない
先行するIP-CIDRまたはGEOIPルールにマッチしているリクエストが先にIP条件で処理されている可能性があるログを確認し、実際の接続先情報とマッチした項目を照合する
追加したルールより前にFINALがあるリクエストが最終処理されており、後続ルールが想定どおり機能しない判定に使うルールをFINALより前に配置する

要点:最初にマッチしたルールを確認してから、遮断範囲を調整する

リクエストログで先行するDIRECTまたはPROXYルールへのマッチが確認できた場合は、まず順序を見直してください。サフィックスルールを追加しても、すでに完了した判定は変わりません。

GEOIPはIPアドレスの地域情報、IP-CIDRはアドレスの範囲をもとにマッチします。どちらもドメインの種類を識別するものではありません。ドメインルールの問題を解決するために共有IPの範囲全体を遮断すると、同じインフラを利用する別のサイトにも影響する可能性があります。明確なIP単位の要件がない限り、IP範囲を広げて対応するのではなく、ドメインとルールの順序を確認してください。

4. ルールの追加と結果確認:番号付き手順

ページの変化とルールの関係を確認するには、一度に変更する条件を1つに絞ります。以下は、自分の設定をすでに使用していることを前提とした手順です。プロキシ接続が必要な場合は、引き続きご自身のサービス設定を利用してください。この記事ではサービスの入手方法や推奨は扱いません。

  1. 元に戻せるコピーを保存する。Configで現在使用中の設定を確認し、先に複製を保存するか元の内容を記録します。特に、既存のポリシー名、DNS設定、FINALは残してください。この記事の最小例を、すぐに使える完全な設定として読み込まないでください。
  2. 実際の接続先を確認する。接続ログまたはリクエストログで、問題のあるリクエストのドメインを確認します。ページのタイトルから推測せず、ホスト名を記録してください。ページのURLと、画像やAPIが実際にリクエストするホストは異なる場合があります。
  3. 最小限のルールを追加する。現在の設定の[Rule]セクションに、DOMAIN,metrics.example.com,REJECTの形式で1行追加し、例示用ドメインを確認済みの接続先に置き換えます。関連する広範囲のルールとFINALより前に配置してください。
  4. テスト時の状態を確認する。設定を保存し、Homeで現在の設定とGlobal Routing → Configを確認してから、接続状態を確認します。接続が不安定な場合は、先に基本的な接続の問題を解決してからルールをテストしてください。
  5. リクエストを再実行する。ページを再読み込みするか、対象アプリを終了してから開き直し、新しい接続を発生させます。対応するログで接続先、マッチしたルール、ポリシーを確認してください。ページの一部が消えたかどうかだけで判断しないでください。
  6. 変更を1つずつ戻して確認する。追加したルールだけを削除して保存し、同じ操作をもう一度行います。機能が復旧するか比較してください。変化がなければ、ほかのリクエストも確認します。ルール一式を一度に削除しないでください。

HTTPSを使うサイトで一般的なポートは443ですが、DOMAIN,metrics.example.com,REJECTは443に限定する条件ではありません。このルールが指定するのはドメインであり、URL、リクエストメソッド、ポートではありません。:443を含む完全なURLをドメイン欄に入力しないでください。

5. 対象外となるリクエストとページ内容

ドメインルールが対象にするのは、マッチ可能な接続先です。ページの内容を分類する機能ではありません。同じドメインから本文、画像、おすすめ情報、ログイン用APIが返されることがあり、1つの接続で複数のリクエストが処理される場合もあります。DOMAIN-SUFFIXだけでは、そのうちどの内容を残すべきか判断できません。

DNSの名前解決ログと、最終的な接続処理のログは同じものではありません。ドメインの名前解決後に、接続がREJECTされることがあります。反対に、名前解決に失敗し、接続が想定したルールの検証段階まで進まないこともあります。判定の際は、名前解決、ルール照合、接続結果を分けて記録してください。

6. ページの不具合や遮断されない場合のよくある質問

誤遮断では、ログイン画面が繰り返し表示される、画像が空白になる、ボタンの読み込みが終わらない、認証を完了できないといった症状が起こることがあります。これらは、依存するリクエストが失敗している可能性を示すものであり、そのリクエストを許可すべきだと証明するものではありません。追加したルールと実際のマッチ状況を照合し、対象範囲を少しずつ絞ってください。

REJECTを追加したのに、ページが普通に開くのはなぜですか?

まず、対象ドメインへのリクエストが実際に発生しているかを確認し、Home → Global Routing → Configと現在の設定を照合してください。ページの本文が正常に表示されても、ルールが機能していないとは限りません。対象のリクエストが追加リソースの場合もあります。新しい接続に適用されたポリシーを確認してください。

計測用ドメインを遮断したら、ログインもできなくなったのはなぜですか?

主ドメイン全体にDOMAIN-SUFFIXを適用していないか確認してください。追加したルールをいったん削除して再ログインし、機能が戻る場合は、確認済みの完全一致DOMAINに変更します。ログイン用ホストを許可する必要がある場合は、明示的な例外をより前に設定し、通常のアクセス経路には既存設定のポリシーを使ってください。

ログにREJECTと表示されるのに、DNSリクエストも見えるのはなぜですか?

名前解決と接続は別の段階です。名前解決のログがあっても、アプリが接続先に正常にアクセスできたとは限りません。対応する接続が拒否されているかを確認してください。DNSログを消すためだけに、ドメインやIPの遮断範囲を広げないでください。

設定を更新したら、自分で追加したルールが消えたのはなぜですか?

更新した対象がノードのサブスクリプションか、設定ファイル全体かを確認してください。両者は別のものです。リモート設定の更新で、ローカルで編集した内容が置き換わる場合があります。更新前後のコピーを比較し、現在有効なファイルを確認してから、検証済みで必要なルールを復元してください。

ルールを1つ削除しても不具合が続く場合は、ネットワーク、DNS、サーバーからの応答も確認してください。すべての問題をREJECTのせいにしないでください。基本的な接続確認はトラブル対処ガイドを参照してください。ConfigとHomeの役割がわからない場合は、まず入門ガイドで設定を有効にする手順を確認してください。

App Storeで正規品を確認 →