この記事は、Shadowrocketで設定を有効にしており、ブロックルールの追加やトラブルシューティングを行いたい方向けです。「マッチ条件」と「処理ポリシー」を分けて考え、最小限のルール例で照合順序を確認したうえで、同一ドメインへのリクエスト、暗号化された接続、キャッシュがブロック結果に与える影響を見ていきます。ドメインとアドレスはすべて説明用です。接続テストについては、利用者自身が契約しているサービスやサブスクリプションがあることを前提とします。
1. REJECTは処理ポリシーであり、コンテンツを識別するルールではない
Shadowrocketのルールには通常、マッチ条件と処理ポリシーが含まれます。たとえば DOMAIN-SUFFIX,example.com,REJECT では、最初の2項目が対象となる接続を決め、末尾の REJECT が一致した接続を拒否します。ページに特定の単語や画像、レイアウトがあるからといって、そのコンテンツを自動で識別して削除するものではありません。
設定に基づいて通信を振り分ける場合、処理の流れは次の5段階で考えられます。ここで示すのはルール処理の仕組みであり、クライアントがすべての接続から完全なドメイン情報を取得できることや、暗号化されたリクエストの本文を読み取れることを意味しません。
ルールは通常、上から順に確認され、最初に一致したルールのポリシーが適用されます。そのため、ファイルの末尾に置いた詳細なブロックルールが実行されないことがあります。接続がそれより前にある広範なルールに一致し、DIRECT などのポリシーが適用済みだからです。トラブルシューティングでは「何に一致したか」と「最終的に何が適用されたか」の両方を確認してください。ファイル内に REJECT があるかどうかだけを検索しても不十分です。
2. 最小限のルールでDOMAINとDOMAIN-SUFFIXを確認する
まず Config で現在の設定をバックアップし、テスト用のコピーを編集します。以下の例は [Rule] 内の照合関係だけを示すもので、既存の設定を置き換えられる完全な構成ではありません。使用するのは説明用に予約されたドメインで、実際のブロック対象ではありません。
[Rule]
DOMAIN,account.example.com,DIRECT
DOMAIN-SUFFIX,example.com,REJECT
FINAL,DIRECTこの順序では、account.example.com は先に完全一致の例外ルールに一致します。media.example.com とルートドメインの example.com はサフィックスルールで拒否され、それ以外のドメインへの接続には FINAL が適用されます。ここで DIRECT を使うのは仕組みを説明するためです。実際の利用時に、未一致の通信をすべて直接接続に変更すべきという意味ではありません。
完全一致の例外
- キーワード
- DOMAIN
- マッチ値
- account.example.com
- ポリシー
- DIRECT
- 配置場所
- 広範なサフィックスルールより前
このホスト名だけを許可します。下位ドメインは自動的には許可されません。
サフィックスによるブロック
- キーワード
- DOMAIN-SUFFIX
- マッチ値
- example.com
- ポリシー
- REJECT
- 対象範囲
- ルートドメインとそのサブドメイン
サフィックス欄に https://、パス、ポートは入力しません。アスタリスクも不要です。
保存後、コピーした設定が Config で現在の設定として選択されていることを確認し、Home → Global Routing で Config を選択します。Proxy や Direct は、設定ルールを有効にする操作と同じではありません。Scene を使う場合は、シーン適用後のルーティング動作も確認してください。変更後は新たにテスト接続を開始し、変更前から存在する接続を使い回さないようにします。
結論：まずホスト名を完全一致で確認し、範囲を広げる
まずDOMAINルールを1つ追加し、マッチ記録を確認します。対象と影響範囲を確認してから、DOMAIN-SUFFIXに変更するか判断してください。最初からプラットフォーム全体のルートドメインをブロックするのは避けましょう。
3. REJECTとREJECT-DROPの違いは拒否の方法
REJECT と REJECT-DROP は、どちらも接続を拒否するポリシーですが、拒否時の応答が異なります。通常、REJECT では接続が比較的早く失敗します。一方、REJECT-DROP は応答せずに破棄するため、接続元はタイムアウトまで待つ傾向があります。実際のエラー表示はTCPやUDP、アプリの再試行処理、現在の実装にも左右されるため、すべてのアプリでリクエストがすぐ停止するとは限りません。利用できるポリシー名は、現在のクライアントのルールエディターと対応状況を確認してください。
| ポリシー | 処理の傾向 | 確認したい動作 |
|---|---|---|
REJECT | 接続を拒否し、通常は比較的早く失敗を返す | アプリがすぐにエラーを表示するか、代替ドメインを直ちに試す場合があります |
REJECT-DROP | 応答せずに破棄し、接続元のタイムアウトを待つ | アプリの読み込み表示が長く続いたり、リクエストを繰り返したりする場合があります |
どちらのポリシーも、拒否した結果としてページ上のコンテンツが正しく非表示になるわけではありません。失敗を受け取ったアプリは、空白を残したり、エラーアイコンを表示したり、代替APIを利用したりすることがあります。また、REJECT-DROP のほうがドメインのマッチ範囲が広いわけではありません。接続がこのルールに一致していなければ、末尾のポリシーを置き換えてもマッチ範囲は広がりません。
- ルールが一致したか確認するには、読み込みアニメーションの長さで推測せず、まずリクエスト記録を確認します。
- 読み込み中の表示が続く場合は、ログイン、認証、初期化に必要なAPIが拒否されていないか、まず確認します。
- 拒否ポリシーを切り替えるときは、一度に変更する要素を1つにして、同じ操作をやり直し、動作の違いを記録します。
4. ドメインブロックの限界：同一ドメインのコンテンツ、HTTPS、共有アドレス
ブロック対象のリソースが独立したドメインを使っている場合、ドメインルールで範囲を分けやすい傾向があります。しかし、通常のコンテンツと対象リソースがどちらも api.example.com から配信され、パスだけが /content と /promotion に分かれている場合、DOMAIN と DOMAIN-SUFFIX では両者を区別できません。このホスト名を拒否すると、本文、ログイン、アカウント状態まで利用できなくなる可能性があります。
宛先ポートが 443 の一般的なHTTPS接続でも、ドメインルールはHTTPリクエストを復号する機能ではありません。URLのパス、クエリパラメーター、レスポンス本文は暗号化されているため、ドメインルールにパスを追加してコンテンツ単位で絞り込むことはできません。この記事のルール例もHTTPSの復号は扱いません。
| リクエストの種類 | ドメインルールで区別できるか | 適用上の注意 |
|---|---|---|
track.example.com と api.example.com | ホスト名ごとに分けてマッチできます | 前者が必須機能を担っていないか確認が必要です |
| 同じホスト名にある2つのHTTPSパス | DOMAINだけではパスを区別できません | 完全なURLをドメイン欄に入力しないでください |
| 複数のドメインが同じサービスアドレスを共有 | IPでブロックするとドメイン単位の粒度を保てません | ほかの正常なサービスにも影響する可能性があります |
| アプリがローカルキャッシュを読み込む | 新しい接続がなければルールで照合できません | ページが表示されていてもルールが無効とは限りません |
ドメインルールを IP-CIDR に変えても、同一ドメイン内のコンテンツが混在する問題は解決しません。たとえば IP-CIDR,192.0.2.10/32,REJECT は説明用のIPv4アドレスを拒否する設定であり、特定のWebサイトだけを拒否するものではありません。192.0.2.0/24 はさらに広い範囲を対象とします。実際のサービスでは複数のアドレスやIPv6が使われることもあります。アドレス範囲を安易に広げると誤ブロックが起きやすく、対象を完全にカバーできるとも限りません。
結論：同一ドメインに複数のコンテンツがある場合は、機能を維持してからブロックの要否を判断
必要な機能と対象リソースが同じホスト名を共有している場合は、まず広範な拒否ルールを解除して機能を復旧します。独立して確認できるリクエストドメインが見つかった場合に限り、範囲を絞ったルールを追加してください。コンテンツを判別する代わりに、アドレス全体をブロックするのは避けましょう。
5. ルールが効かないときは、記録をもとに順番に確認する
「コンテンツがまだ表示される」という事実だけでは、ルールが効いていないとは判断できません。アプリがリクエストを再送していない、別のホスト名に接続している、想定したルール経路を現在の接続が通っていない、といった可能性があります。変更前後の設定コピーを保存し、テスト時刻、操作内容、対象ホスト名、最終的に適用されたポリシーを記録すると、問題を再現しやすくなります。
- 現在の設定とルーティングを確認する。
Configを開いて有効なファイルを確認し、Home → Global Routing → Configも確認します。ファイルを保存しただけで有効化していなければ、現在の接続には反映されません。 - ネットワークリクエストを再実行する。保存後に接続を切って再接続し、必要に応じて対象アプリを終了してから開き直します。ページを更新するときは、キャッシュを読むだけでなく、新しいリクエストが発生しているか確認してください。
- リクエスト記録を確認する。クライアントの接続記録またはリクエスト記録からテスト時刻に該当する項目を探し、確認できるホスト名、宛先アドレス、マッチしたルール、最終ポリシーを照合します。REJECTの表示を見ただけでは不十分です。今回の対象リクエストに対応する記録かどうかを確認してください。
- ルールの順序と確認できる情報を調べる。より広範な許可ルールが先に一致していないか確認します。記録にIPアドレスしか表示されていない場合、DOMAIN-SUFFIXに使えるドメイン情報が得られているとは限りません。アプリが暗号化DNSで名前解決しているか、アドレスへ直接接続しているかも確認してください。
- 1項目ずつ比較する。追加したルールを一時的に無効にして、同じ操作を繰り返します。無効にしたとき機能が戻るなら、そのルールが問題に関係しています。拒否ルールをさらに追加するのではなく、マッチ範囲を絞ってください。
ルールの順序は、GEOIP、IP-CIDR、FINAL も合わせて確認します。これらはコンテンツ分類機能ではありません。GEOIP はアドレスの所属地域、IP-CIDR はアドレス範囲で照合し、FINAL はそれ以前のルールに一致しなかった接続を処理します。広範なルールが先に一致すると、後続の対象ドメインルールは実行されません。
6. よくある質問：誤ブロック、キャッシュ、設定の更新
ルールを追加したらログインできなくなりました。まずどのルールを削除すればよいですか？
今回追加したREJECTルールを一時的に無効にしてログインを再試行し、復旧するか確認します。次にログイン時のリクエスト記録を調べ、ルートドメインまで対象にするDOMAIN-SUFFIXを優先して確認してください。認証に必要なホスト名が分かった場合は、広範なルールより前に完全一致の例外を追加し、既存の正常な経路に合わせてポリシーを設定します。確認せずにプラットフォーム全体を許可するのは避けてください。
記録にはREJECTと表示されていますが、なぜページにはまだ表示されるのですか？
まず、その記録がページから今回発生したリクエストに対応するものか、バックグラウンドの別の接続ではないかを確認します。その後、ページを開き直して新しい接続が発生するか観察してください。キャッシュ済みの画像、ダウンロード済みのコンテンツ、アプリ内蔵素材は、接続を拒否しても自動で消えません。ルールにはページ上の表示領域を折りたたむ機能もありません。
アプリが別のドメインにリクエストするようになりました。新しいドメインをすべてブロックすべきですか？
見つかった順にまとめてルールへ追加するのは避けてください。各ホスト名がどの操作中に現れたかを照合し、対象の機能に関係するか判断してから、1つずつテストします。代替APIが正常なコンテンツも処理している場合があります。用途を確認できていないログイン、決済、同期のリクエストは、まず維持してください。
サブスクリプションを更新したら、カスタムのREJECTルールが消えました。なぜですか？
まず、Homeの接続項目に対するサブスクリプション更新と、Configの設定ファイル更新を区別してください。両者は別の操作です。現在有効なファイルが変わっていないか、リモート設定の更新で手動変更が上書きされていないかを確認します。テスト用のローカルコピーとカスタムルール一覧を保存し、更新のたびにファイル内容とルール順を照合してください。接続項目が残っているだけで、ルールも維持されたと判断しないでください。
ブロックが適切かどうかは、最終的に3つの条件で判断します。リクエストが現在のルール経路を通っているか、クライアントが照合に必要な情報を取得できているか、対象を必要な機能から切り分けられるかです。条件を満たす場合は、範囲を絞ったルールを使い、元に戻せる設定コピーを保管してください。切り分けられない場合は、より広いルールで問題を覆い隠すのではなく、ドメイン単位の処理に限界があることを踏まえてください。