利用可能な設定があり、ブロックルールを調整したいShadowrocketユーザー向けの記事です。まずHomeでGlobal Routingを確認し、Configで現在の設定の[Rule]をチェックします。DOMAINでホスト名を指定し、DOMAIN-SUFFIXでサブドメインを含めて指定します。例外ルールはブロックルールより前に置き、リクエスト記録で動作を確認してください。記載のドメインとアドレスは構文の説明用であり、利用可能なサービスを示すものではありません。
まずHomeとConfigを確認：REJECTが適用される場所
HomeでGlobal Routingを確認し、この記事のルールを検証する際はConfigを選択します。次にConfigで現在使用中の設定ファイルを確認し、編集画面で[Rule]セクションをチェックしてください。ルールをファイルに記述しただけで、そのファイルを有効にしていなければ、現在の接続処理には反映されません。また、Homeの接続スイッチがオフの状態では、閲覧結果からルールの有効性を判断できません。
REJECTは、ルールに一致したときに適用されるポリシーです。ルールの種類でもサーバー名でもありません。まずリクエストが条件に一致するかを判定し、一致した場合に拒否します。プロキシサーバーにリクエストを送ってから拒否するわけではなく、端末に保存済みのウェブページを削除するものでもありません。
確認する場所
- Home
- 接続スイッチがオンになっていることを確認
- Global Routing
- Configを選択
- Config
- 変更した設定が有効になっていることを確認
- [Rule]
- ルールの順序と最終ポリシーを確認
まず設定がリクエスト処理に適用されていることを確認してから、ルール自体の正しさを判断します。
Global Routingのモード
- Config
- 現在の設定ファイルのルールに従って振り分け
- Proxy
- グローバルプロキシ。この記事のルール振り分けの検証には使用しません
- Direct
- グローバル直結。この記事のルール振り分けの検証には使用しません
- Scene
- シーンごとの設定に従って動作するため、現在のシーンを別途確認してください
検証中はConfigに固定し、シーンの切り替わりが確認に影響しないようにします。
Settings → On Demandでは、条件に応じて接続を開始・切断する動作を設定します。[Rule]内のドメイン照合を置き換えるものではありません。テスト中に接続状態が頻繁に変わる場合は、まずOn Demandの条件を確認してください。接続が維持されない問題に対処するため、REJECTルールを追加し続けるのは避けましょう。
照合順序を理解する：先に一致したルールで処理が決まる
通常のルール振り分けでは、ルールを上から順に確認します。リクエストがいずれかのルールに一致すると、そのルールで指定されたポリシーが適用され、それより下のルールは確認されません。そのため、特定の宛先を許可するルールは、通常、範囲の広いブロックルールより上に配置します。FINALは、それまでのルールに一致しなかったリクエストを処理します。
[Rule]
# このホスト名への直結を先に許可
DOMAIN,help.example.com,DIRECT
# 次にexample.comとそのサブドメインを拒否
DOMAIN-SUFFIX,example.com,REJECT
# この例の残りのリクエストは直結（構文説明用）
FINAL,DIRECTこの3つのルールでは、help.example.comは最初のルールに一致し、DIRECTが適用されます。media.example.comは2番目のルールに一致し、REJECTが適用されます。一致しなかったドメインはFINALで処理されます。2番目のルールを1番目より上に移動すると、ヘルプページもexample.comのサブドメインであるため拒否されます。
ルールの範囲を選ぶ：DOMAINとDOMAIN-SUFFIXの使い方
特定のホスト名だけをブロックする場合は、DOMAINを使います。ドメインとすべてのサブドメインを対象にする場合は、DOMAIN-SUFFIXを使います。どちらも対象欄にはドメイン名だけを記述し、プロトコル、ポート、パス、クエリパラメーターは含めません。たとえば、https://ads.example.com/banner全体をドメイン欄に指定することはできません。
| ルール例 | 対象範囲 | 使用前の確認事項 |
|---|---|---|
DOMAIN,ads.example.com,REJECT | ads.example.comに完全一致 | リクエスト記録のホスト名が完全に一致することを確認 |
DOMAIN-SUFFIX,example.com,REJECT | example.comとそのサブドメインに一致 | ログイン、画像、APIが同じドメインサフィックスを使っているか確認 |
IP-CIDR,192.0.2.7/32,REJECT,no-resolve | 単一のIPv4アドレスに一致 | ここに記載したのは文書用の例示アドレスであり、実際のブロック対象ではありません |
IP-CIDRはIPアドレスの範囲に基づいて照合し、GEOIPはIPアドレスの地理的な帰属に基づいて照合します。どちらもドメインサフィックスによる照合とは異なります。例のno-resolveは、このIPルールのために追加のドメイン解決を行わないことを示します。リクエストにドメイン名しかない場合、このアドレスルールに必ず一致するという意味ではありません。複数のサイトが共有するアドレスにREJECTを適用すると、同じアドレス上の別サイトにも影響する可能性があります。
まず特定のホスト名に一致させ、必要に応じて対象を広げる
リクエスト記録で確認した単一のホスト名を使って、まずDOMAINルールを作成します。ほかのサブドメインも拒否する必要があると確認できた場合に限り、DOMAIN-SUFFIXに変更してください。一度にサービスのドメイン全体をブロックする事態を避けられます。
適用範囲を把握する：REJECTではウェブページの要素を選別できない
REJECTは、ページから個別にリクエストされるドメインなど、ネットワーク上で個別に識別できる対象の拒否に適しています。ウェブページの要素を選別する機能ではありません。本文、画像、ブロックしたいコンテンツが同じホスト名を使っている場合、単純なドメインルールでは特定のパスだけを区別できません。そのドメインを拒否すると、本文のAPI、ログイン認証、静的リソースの読み込みまで失敗する可能性があります。
- 同じドメインの異なるパス：
example.com/newsとexample.com/bannerをDOMAINルールで個別に処理することはできません。パスはこのルールの照合対象ではありません。 - コンテンツがキャッシュ済み：REJECTに一致しても、以前にキャッシュされた画像やテキストがページに表示される場合があります。古いページから表示が消えたかではなく、新しいリクエストの処理記録を確認してください。
- 対象ドメインの変更：ページが別のホスト名からコンテンツを再取得する場合があります。実際に発生した新しいリクエストを確認し、名前が似ているという理由だけでサフィックスの対象を広げないでください。
- 対象IPのみが記録されている：照合時に利用できるドメイン情報がない場合、DOMAIN-SUFFIXに一致すると決めつけることはできません。まず記録にある対象の種類を確認してください。
- 共有インフラ：1つのIPアドレスで複数のドメインが運用されている場合があります。IP-CIDRに変更しても、自動的に精度が上がるわけではありません。広いアドレス範囲をブロックする場合は、特に慎重に設定してください。
HTTPSが暗号化されていても、すべてのドメインルールが機能しなくなるわけではありません。一方、REJECT自体が通信を復号してウェブページの本文を検査することもありません。ネットワーク上の対象をブロックするために、先にHTTPS復号を有効にしたり証明書をインストールしたりする必要はありません。この記事のルール検証にそうした操作は不要です。また、ウェブページに空白が残っていても、ルールが失敗したとは限りません。リクエストが拒否されても、ページのレイアウトから該当領域が自動的に削除されるとは限りません。
動作確認と元に戻す方法：実際のリクエストから誤遮断を特定
Configで変更を保存したら、その設定が有効になっていることを再確認してください。Homeに戻り、Global RoutingがConfigになっていることを確認します。必要に応じて接続し直してから、対象ページを再度開き、新しいリクエストを発生させます。アプリ内のリクエスト記録で対象のドメインまたはIP、適用されたポリシー、確認可能なルール情報を確認してください。記録の表示場所や項目は、現在の画面に従ってください。
- 変更前の設定を保存：変更前に元に戻せるコピーを保存し、追加するルールの位置も記録しておきます。ルールを追加し続けるのではなく、いつでも取り消せる状態にしてください。
- 一度に変更するのは1項目：まず特定の対象に絞ったルールを1つ追加し、保存して動作を確認します。Global Routing、DNS、複数のIPルールを同時に変更すると、何が原因で変化したのか判断しにくくなります。
- 新しいリクエストが発生しているか確認：記録に対象のリクエストがない場合は、ページを再読み込みするか、関連する機能を開き直してください。キャッシュや既存の接続を、新しいルールの結果と誤認しないようにします。
- 実際に適用されたポリシーを確認：記録がDIRECTまたは別のポリシーを示している場合は、より上にあるルールに一致していないか確認します。REJECTと記録されているのにページにコンテンツが表示される場合は、キャッシュや別のリクエスト先ドメインを確認してください。
- 必要最小限の範囲に戻す：まず直近に追加したルールを取り消します。サフィックスによるブロックを残す必要があると確認できた場合は、その上に特定ドメインの例外を配置し、元の設定で必要な許可ポリシーを使ってください。
許可する場合でも、必ずDIRECTを使うわけではありません。DIRECTは直結を意味します。元の設定でプロキシを経由するサービスには、もともと設定されていたポリシーを戻してください。前述のDIRECTは例外ルールの順序を示すためのもので、すべてのサービスにそのまま適用できる設定ではありません。戻すポリシー名がポリシーグループを参照している場合は、その名前が現在の設定に存在することも確認してください。
REJECTを設定したのに、なぜ開ける？
まずHomeでGlobal RoutingがConfigになっていることを確認し、次にConfigで有効なファイルを確認してください。リクエストを再発生させて実際のホスト名を確認します。上位の許可ルールに一致している場合は、同じREJECTを繰り返し追加するのではなく、ルールの順序を調整してください。
ルールを追加したら、ログインボタンが回り続ける場合は？
直近に追加したルールを取り消し、ログイン操作をやり直して、リクエスト記録にある認証またはAPIのドメインを確認してください。範囲の広いDOMAIN-SUFFIXが誤って一致している場合は、DOMAINで対象を絞るか、その前に必要な特定ドメインの例外を追加します。
Connectivity Testが正常なら、ブロック成功の証明になる？
なりません。HomeのConnectivity Testは接続先への到達性を確認するもので、特定のドメインにREJECTが適用されたことを示すものではありません。対象の機能からリクエストを発生させ、そのリクエストの処理記録を確認してください。
サブスクリプションを更新すると、手動で追加したルールは残る？
まずHomeでのサーバーサブスクリプション更新と、Configでの設定ファイル更新を区別してください。サーバー一覧の更新は[Rule]の編集とは異なります。一方、リモート設定を再取得すると、ローカルの変更が置き換わる場合があります。操作前にコピーを保存し、更新後に現在のファイルとルールの位置を確認してください。サブスクリプションリンクは、利用中のサービス提供元から取得してください。
最終確認では、対象への新しいリクエストに想定どおりREJECTが適用され、維持する必要のあるログイン、画像、APIには正しいポリシーが適用されることの両方を確認します。「ページが開かなくなった」だけでは、ルールが正確とは言えません。再現可能な対象、明確な照合範囲、元に戻せる設定が、その後のメンテナンスの基準になります。