ShadowrocketのREJECTは、リクエストに適用する処理方針であり、Webページ内の要素を除去する機能ではありません。利用可能な設定があり、端末内にブロックルールを追加したい方向けに、まずマッチ条件と処理方針を確認し、Configモードでルールの順序を点検する方法を説明します。最後に、ルールを1つずつ有効・無効にして誤判定の有無を確認します。例示には説明用のドメインと文書用IPアドレスを使用しています。実際のリクエストに合わせて置き換えてください。そのまま使えるブロックリストではありません。
REJECTとは：一致したリクエストを拒否
REJECTは、一致したリクエストを拒否する処理であり、接続先のプロキシサーバーを選ぶものではありません。ルールは、前半でマッチ条件を指定し、末尾で処理方針を指定します。たとえば DOMAIN,ads.example.com,REJECT の場合、DOMAIN はルールタイプ、ads.example.com はマッチする値、REJECT は一致後の処理です。REJECTをサーバーアドレスやポートの欄に入力しないでください。
ルールが処理できるのは、該当する振り分け処理に入った通信だけです。Home → Global RoutingでConfigを選ぶと、現在の設定に対する通常のテストができます。ProxyとDirectは全体に適用する処理方針であり、設定内のREJECTを検証する条件と同じではありません。Sceneは選択中のシーンの設定に応じて判断してください。リクエストがShadowrocketの処理経路を通らない場合、設定内のREJECTを変更しても影響しません。
DIRECT：リクエストを直接接続します。接続を拒否する意味ではありません。PROXY：リクエストを対応するプロキシ方針に渡します。利用できるかどうかは、現在の設定とサーバーにも左右されます。REJECT：リクエストを拒否します。この拒否ルール用にプロキシの接続先を用意する必要はありません。
ルールの書き方：完全一致から始める
まずDOMAINで完全一致させ、必要に応じてDOMAIN-SUFFIXまたはDOMAIN-KEYWORDに範囲を広げます。以下は設定ファイルの [Rule] セクションに記述する例です。3つのルールでマッチ範囲を比較できます。実際に調べるときは必要なルールだけを有効にし、範囲が重なってどのルールが作用したのか分からなくなるのを避けてください。
[Rule]
DOMAIN,ads.example.com,REJECT
DOMAIN-SUFFIX,tracker.example.net,REJECT
DOMAIN-KEYWORD,telemetry,REJECT
FINAL,DIRECTドメイン条件とマッチ範囲
- DOMAIN
- ads.example.com,REJECT：この完全なドメイン名だけに一致します。
- DOMAIN-SUFFIX
- tracker.example.net,REJECT：このドメイン名とサブドメインに一致します。
- DOMAIN-KEYWORD
- telemetry,REJECT：ドメイン名にこのキーワードを含むリクエストに一致します。
ドメイン条件には https://、ページのパス、クエリパラメーターを含めません。
アドレス条件とフォールバック
- IP-CIDR
- 192.0.2.7/32,REJECT：単一のIPv4アドレスに一致します。
- GEOIP
- CN,DIRECT：IPジオロケーションデータベースの地域情報に基づいて一致します。
- FINAL
- DIRECT：それ以前のルールに一致しなかったリクエストを処理します。
アドレスルールは利用可能な宛先IP情報に依存するため、ドメインを指定するルールの代わりにはなりません。
ドメインルールが照合するのはホスト名であり、URL全体ではありません。宛先が https://ads.example.com/banner?id=1 の場合、ドメインルールの照合対象は ads.example.com であり、/banner や id=1 ではありません。URL全体をDOMAIN-SUFFIXに記述しても、「このページだけをブロックする」ことはできません。
例のFINAL,DIRECTは、ルールを締めくくる形を示すためのものです。一致しなかった通信を直接接続するため、既存のFINAL方針を置き換える目的では使わないでください。例を既存の設定に追加する場合は、必要な拒否ルールだけを加え、元のフォールバック方法と有効な方針名を維持してください。
マッチ順序の決め方：例外を先に、広い条件を後に
通常のルールは上から順に判定され、最初に一致したルールの方針が適用されます。同じドメインが完全一致条件とサフィックス条件の両方に該当しても、「より具体的に見える」ルールが自動的に選ばれるわけではありません。許可する例外は広範囲の拒否ルールより前に置き、FINALは通常のルールの最後に配置してください。
[Rule]
DOMAIN,login.example.com,DIRECT
DOMAIN-SUFFIX,example.com,REJECT
FINAL,DIRECTlogin.example.comにアクセス：最初のルールに一致してDIRECTが適用されるため、後続のサフィックス拒否ルールには一致しません。ads.example.comにアクセス：最初のルールには一致しませんが、2つ目に一致するためREJECTが適用されます。example.comにアクセス：ドメイン自体も2つ目のルールの対象範囲に含まれるため、同様に拒否されます。example.orgにアクセス：最初の2つのルールには一致せず、最後にFINAL,DIRECTで処理されます。
まとめ：例外を先に移動し、その後ブロック範囲を広げる
ログイン用のドメインを許可する場合は、その許可ルールをサフィックス拒否ルールより上に置いてから、ログインと対象機能の両方をテストしてください。2つのルールの順序を逆にすると、完全一致の例外が設定に残っていても、リクエストが先に広範囲のルールに一致するため機能しません。
「ルールを追加したのに効かない」ときは、まず前にあるルールとの一致を確認してください。たとえば上に DOMAIN-SUFFIX,example.com,DIRECT があり、その下に DOMAIN,ads.example.com,REJECT を追加しても、このリクエストは先に直接接続されます。同じREJECTルールを繰り返し追加するのではなく、順序を変更するか、上の条件を狭めてください。
追加と検証の方法：ルールは一度に1つだけ変更
まず現在の設定を複製し、複製した設定を編集して選択してください。以下ではiPhone / iPadのHome、Configという画面上の表記を使います。他のプラットフォームでは実際のメニューに従ってください。操作にはユーザー自身が用意した設定とサービスを使用してください。ノードやサブスクリプションの提供・販売・推奨は行っていません。
- Configを開き、現在使用中の設定ファイルを確認します。変更前のコピーを保存しておくと、元に戻せます。
- 編集する設定を開き、ルールのセクションを探します。テキストで編集する場合は、既存の
[Rule]セクションにルールを追加してください。同じ名前のセクションを分けて重複作成しないでください。 - まず
DOMAIN,ads.example.com,REJECTのような完全一致ルールを1つ追加し、このドメインに一致する可能性のある広範囲のルールより前に配置します。既存のFINALは変更しないでください。 - 編集した設定を保存して選択し、Home → Global Routingに戻ってConfigが選択されていることを確認します。接続スイッチがオンになっていることも確認してください。
- 対象のアプリやページで以前の接続を終了してからリクエストを再実行し、対象の機能と維持したい機能の両方を確認します。
- 追加したルールを一時的に削除または無効にして、同じリクエストを再実行します。ルールの有効・無効で機能に変化があれば、次にマッチ範囲が適切かを確認してください。
既存の接続やローカルキャッシュがあると、テスト結果に反映されるまで時間がかかることがあります。読み込み済みの画像はREJECTを追加しても消えず、アプリが以前の接続を再利用することもあります。新しいリクエストを発生させてから、ルールの有効時と無効時を比較してください。キャッシュに古い内容が残っているだけでルールが効いていないと判断したり、一度のタイムアウトをREJECTが原因だと決めつけたりしないでください。
ブロックの限界：ドメイン拒否はコンテンツフィルタリングではない
REJECTは個別に識別できるリクエスト先のブロックに適しており、ページ内のテキストや要素を細かく除去する機能ではありません。広告、ログイン、本文が同じドメインを使っている場合、そのドメインを拒否すると複数の機能に影響する可能性があります。HTTPSリクエストでは、DOMAIN系ルールだけで特定のURLパスを判別することはできません。また、ここで説明するドメイン拒否のためにHTTPS復号を有効にする必要はありません。
- 同じドメイン上のリソース：サービス全体のドメインを拒否すると、本文の画像、アカウント認証、決済コールバックまで遮断する可能性があります。個別に識別できる対象を優先してください。
- キーワードの範囲が広すぎる：
DOMAIN-KEYWORD,ad,REJECTは、特定の広告ドメインよりはるかに広い範囲に一致します。一般的なサービスのドメインにもこの文字列が含まれていれば該当する可能性があるため、最初のテストルールには適しません。 - 共有IP：複数のWebサイトが同じCDNアドレスを使うことがあります。IP-CIDRでそのアドレスを拒否すると、影響範囲が確認したサイトだけにとどまらない可能性があります。
- 変動するアドレス：サーバーのアドレスが変わると、手動で記録したIPでは対象をカバーできなくなる場合があります。逆に、古いアドレスが別のサービスに使われる可能性もあります。
- マッチ情報が不足している：処理経路で宛先IPだけが分かり、照合に使えるドメイン情報がない場合、ドメインルールが一致しないことがあります。キーワードの範囲をむやみに広げず、実際のリクエスト記録を確認してください。
まとめ：リソースを区別できない場合は、サービスの利用を優先
対象のコンテンツと必要なサービスが同じドメインを使っており、個別のリクエスト先を特定できない場合は、DOMAIN-SUFFIXやIP-CIDRの範囲をこれ以上広げないでください。誤判定を招くルールを取り消すほうが、広すぎる条件を例外の追加で補い続けるより管理しやすくなります。
よくある質問：誤判定、更新による上書き、自動接続
多くの問題は、現在の設定、ルーティング方針、直近の変更から確認すると原因を絞れます。まずルールをむやみに増やさず、再現可能な条件を1つに絞ってから、以下の順に確認してください。アプリ画面の接続状態が示すのはトンネルの状態であり、特定のREJECTルールに一致したことの証明にはなりません。
REJECTを追加したのに、対象のページを開けるのはなぜですか？
まずHome → Global RoutingでConfigを選択していることを確認し、次にConfigで編集後のファイルが選択されているか確認します。拒否ルールより上にDIRECTなど先に一致する条件がないか調べてください。最後に既存の接続を終了して新しいリクエストを送り、キャッシュや接続の再利用を除外します。
ブロック後にログインできなくなった場合、どのような例外を追加すればよいですか？
まず直近に追加した拒否ルールを取り消し、ログインできるように戻るか確認します。次にログイン処理で実際に使われているドメインを調べます。そのドメインがブロック対象と異なる場合は、完全一致の許可ルールを広範囲の拒否ルールより前に置いてください。同じドメインを共有している場合、ドメインルールだけで確実に区別することはできません。
更新後、手動で追加したルールが消えたのはなぜですか？
まず更新したのがHomeのサーバーサブスクリプションか、Configのリモート設定ファイルかを確認してください。サーバーリストの更新とルールファイルの更新は別の処理です。リモート設定を更新すると、ローカルで編集した内容が置き換わる場合があります。更新前にコピーを保存し、更新後はルールのセクションと順序を確認してから、必要な設定を選択してください。
Settings → On Demandでルールのオン・オフを代用できますか？
できません。On Demandは設定した条件に応じて接続を開始する機能であり、特定のドメインにDIRECTとREJECTのどちらを適用するかは指定しません。テスト時は、まずトンネルが接続済みであることを確認し、Global Routingと現在の設定を点検してください。特定のブロックを解除する場合は、該当するルールを編集します。
ルールを管理するときは、変更理由と元に戻す方法を記録してください。一度に扱う対象は1つにし、実際のドメイン、使用したルールタイプ、維持する必要がある機能を記録します。リモートから取得した設定を使う場合は、更新後にローカルの変更も再確認してください。こうすることで、「拒否範囲が適切か」と「現在の接続が正常か」を分けて判断でき、あらゆるネットワークの問題をブロックルールのせいにせずに済みます。