REJECTは、ルールに一致したリクエストを拒否するためのポリシーであり、ページ上の要素を消す機能ではありません。利用可能なConfigがあり、ブロックルールを追加したい方を対象に、まずGlobal RoutingがConfigになっていることを確認します。次に単一のDOMAINルールを追加し、リクエストログで一致状況を確認してください。URLパス単位で処理する場合は、URL Rewriteの前提条件も確認します。例に登場するドメインとアドレスは構文の説明用で、実在のサービスを示すものではありません。
1. REJECTの役割：接続を拒否し、ページは編集しない
Shadowrocketのルールは、マッチ条件と適用するポリシーで構成されます。REJECTはポリシーの指定で、一致したリクエストを拒否します。プロトコルではなく、別途サーバーを追加する必要もありません。ルールが有効になるのは、対象の通信がShadowrocketの処理経路を通り、現在のConfigのルールで判定される場合です。
ドメインルールが判定するのは接続先のドメインであり、Webページ内の文字や画像の内容、ボタンの位置ではありません。たとえば、ページが統計用リソースを別ドメインから読み込んでいる場合、そのドメインを拒否すれば該当リソースの取得を止められることがあります。一方、本文やログイン、画像が同じドメインに依存している場合は、それらの機能も同時に使えなくなる可能性があります。ルールがレスポンスの内容を自動で判別することはできません。
拒否後の表示は、リクエストを行ったアプリによって異なります。空白になる、読み込みに失敗する、再試行の案内が表示される、以前の内容が残るなどのケースがあります。「ページがまだ表示されている」だけでルールが動作していないとは判断できません。また、読み込み失敗がREJECTによるものとも限りません。通信の切断、DNSの問題、サーバーエラーでも似た症状が起こります。
2. 基本構文：まずDOMAINを使い、必要に応じて範囲を広げる
ドメインルールは「ルールキーワード、マッチ対象、ポリシー」の順に記述し、各項目を半角カンマで区切ります。以下は構文を説明するための独立した例です。1行目は指定したホストだけを拒否し、2行目は指定したサフィックスとそのサブドメインを拒否します。最後の行は、それ以外のリクエストを直接接続します。実際に使う場合は、必要なルールだけを既存のConfigに追加してください。この例全体で既存の振り分け設定を置き換えないでください。
[Rule]
DOMAIN,ads.example.com,REJECT
DOMAIN-SUFFIX,telemetry.example.com,REJECT
FINAL,DIRECT| 記述例 | 一致する対象 | この指定だけでは一致しない対象 |
|---|---|---|
DOMAIN,ads.example.com,REJECT | ads.example.com | img.ads.example.com |
DOMAIN-SUFFIX,telemetry.example.com,REJECT | telemetry.example.com および v1.telemetry.example.com | nottelemetry.example.com |
DOMAIN-SUFFIX,example.com,REJECT | example.com とそのサブドメイン | example.com.other.invalid |
DOMAINまたはDOMAIN-SUFFIXのマッチ対象に、https://、ポート番号、パス、クエリパラメーターを含めないでください。https://example.com/banner?id=1はURLであり、ドメインではありません。この文字列全体をドメインルールに書いても、パス単位でブロックできるわけではありません。
ポイント：まず単一ホストで確認し、その後サフィックスに広げる
まずDOMAINで、ログに記録されたホストを限定して指定します。対象ページの機能に問題がないことを確認してから、DOMAIN-SUFFIXの使用を検討してください。ルール行を減らす目的で、複数のサービスが使う上位ドメインをそのまま拒否しないでください。
3. ルールの順序とGlobal Routing：正しく書いても適用されているとは限らない
HomeでGlobal Routingを確認します。ローカルConfigの通常の振り分けルールを検証する場合は、Configを選択してください。ProxyとDirectはグローバルなルーティング設定です。その状態での結果から、Config内のREJECTルールが有効かどうかは判断できません。Sceneは実際のシーン設定に応じて確認し、Configと同じものとして扱わないでください。続いてConfigで、変更したConfigが選択され、有効になっていることを確認します。
- Configで現在の設定のコピーを保存してから、編集するローカルConfigを開きます。
[Rule]内に、対象範囲を明確にしたREJECTルールを1つ追加します。同じ名前のセクションを重複して作らないでください。- 例外ルールは、それを上書きする可能性のある広範なルールより前に置き、
FINALはルールの末尾に配置します。 - 保存後、変更したConfigが現在使用中であることを確認し、Homeに戻ってGlobal RoutingがConfigになっていることを確認します。
- 対象のリクエストをもう一度発生させ、リクエストログの接続先、ポリシー、マッチしたルールを確認します。
[Rule]
DOMAIN,account.example.com,DIRECT
DOMAIN-SUFFIX,example.com,REJECT
FINAL,DIRECTこの例では、まずaccount.example.comにDIRECTの例外を設定し、その後、example.comのサフィックスに一致するほかのリクエストを拒否します。通常のルールは上から順に評価され、最初に一致したルールのポリシーが適用されます。広範なサフィックスルールを先に置くと、後続の例外ルールではすでに適用された判定を取り消せません。
4. DOMAIN-SUFFIXとURL Rewriteの適用範囲
DOMAIN-SUFFIXはHTTPのパスを判定しません。同じホストで/article/と/banner/の両方を提供している場合、ドメインルールで後者だけを拒否することはできません。URL Rewriteは、確認できるHTTPリクエストURLを対象に、対応するマッチ条件と処理方法で動作します。ただし、これをもって「すべてのHTTPSパスを直接読み取れる」とは限りません。
HTTPSのパスとクエリパラメーターはTLSで保護されています。これらの内容を確認するには、通常、対象ホストのHTTPS復号を適切に設定し、証明書をインストールして信頼する必要があります。URL Rewriteを1つ追加するだけで、こうした条件が自動的に整うわけではありません。証明書ピンニングなどの仕組みにより、この処理を受け付けないアプリもあります。HTTP/3などの通信経路も個別に対応状況を確認してください。ポート番号だけで書き換えの可否は判断できません。
| 処理方法 | 主な判定対象 | 主な制限 |
|---|---|---|
| DOMAIN / DOMAIN-SUFFIX | 接続先ホスト名 | 同じホスト内のパスごとに内容を区別できない |
| URL Rewrite | 読み取り可能なHTTPリクエストURL | HTTPSパスの可視性は、復号の条件とアプリの動作によって異なる |
| REJECT | 前段のルールに一致したリクエスト | リクエストを拒否する。ページ要素を判別する機能ではない |
証明書とHTTPS復号は信頼の境界を変えます。ブロックルールを試すだけのために、すべてのホストへ対象を広げないでください。この記事では、すべてのホストに対する復号設定は紹介しません。適用範囲を確認できない場合は、正確なドメインルールを維持するか、対象アプリが提供するコンテンツ設定を利用してください。
5. IP-CIDRとGEOIP：アドレスの判定はコンテンツ分類ではない
接続先がIPアドレスを直接使う場合もあれば、複数のサービスが共有するコンテンツ配信基盤を使う場合もあります。その場合、「ドメインルールで照合できるホスト名が得られていない」のか、「IPルールの範囲が広すぎる」のかを切り分けてください。GEOIPはIPアドレスの地域を判定し、IP-CIDRは指定したネットワーク範囲内のアドレスかを判定します。どちらも、レスポンスが広告や統計データかどうかは判断できません。
[Rule]
IP-CIDR,192.0.2.0/24,REJECT,no-resolve
FINAL,DIRECT192.0.2.0/24はドキュメント用の例示ネットワークであり、実際にブロックすべき対象ではありません。no-resolveは、このIPルールのためにドメイン名の解決を積極的に行わない指定です。利用可能な接続先アドレスがすでにある場合は、そのアドレスでマッチすることがあります。すべてのDNSを無効にする指定でも、IPルールをドメインルールに変える指定でもありません。
- 1つのIPアドレスを複数のドメインが共有している場合、そのIPを拒否すると、正常な画像、ログイン用API、ほかのWebサイトにも影響する可能性があります。
- 1つのドメインが複数のIPv4アドレスやIPv6アドレスを使うことがあります。IPv4アドレスを1つだけ処理しても、そのドメイン全体を網羅したことにはなりません。
- GEOIPの地域判定はコンテンツの用途を表しません。「特定の種類のコンテンツ全体が不要」という場合の代替条件には適しません。
- DNS、キャッシュ、接続の再利用は観測結果に影響します。1回の名前解決だけで判断せず、新しいリクエストのログも確認してください。
6. 検証と切り戻し：リクエストログで再現可能な判断を行う
テストでは、一度に変更する条件を1つだけにします。まずルールを変更する前のページ表示を確認してから、ルールを1つ追加し、対象ページを再度開くか、該当する操作を実行してください。アプリが既存の接続を再利用している場合、新しいルールがその接続に反映されないことがあります。コンテンツがキャッシュ済みなら、新しいリクエスト自体が発生しない場合もあります。必要に応じて対象アプリを終了して再起動し、新たに記録されたリクエストを確認してください。
- 接続先を確認：実際のリクエストホストを確認します。リダイレクト後にホストが変わることがあるため、ブラウザーのアドレスバーだけを見て判断しないでください。
- 通信経路を確認：接続状態とGlobal Routingを確認し、テスト対象のリクエストが現在のConfigの処理経路を通っていることを確かめます。
- ルールの一致を確認：新しいリクエストにREJECTが適用されたかを確認します。一致していない場合は、まずルールの順序、ドメインの記述、現在のConfigを確認してください。
- 影響を確認：対象箇所が消えたかだけでなく、ログイン、画像、再生、支払いなどの正常な機能も確認してください。
- 切り戻せることを確認：追加したルールを削除または無効にして、もう一度リクエストを実行します。問題が解消した場合は、マッチ範囲をさらに絞ってください。
コンテンツへのリクエストを確認する代わりに、遅延テストを1回行うだけで済ませないでください。Connectivity Testの成功でわかるのは、そのテスト対象に対する結果だけです。対象ドメインにREJECTが一致したことや、ページの特定パスが処理されたことの証明にはなりません。トラブルシューティング用の情報をまとめる場合は、接続先ホスト、適用されたポリシー、操作の順序を記録します。共有前に、サブスクリプションURL、トークンなどの認証情報は削除してください。
7. よくある質問：ルールが有効でもコンテンツが表示される場合
REJECTを追加したのに、画像が表示されるのはなぜですか？
まず、新しい画像リクエストが発生したか確認してください。ブラウザーやアプリのキャッシュにあるデータ、すでにダウンロード済みのリソースは、ルールを追加しても自動的には削除されません。読み込みを再実行して、リクエスト先のホストを確認します。画像が別のドメインから配信されている場合は、ログに記録された実際のホストを対象に判断してください。安易に上位ドメイン全体へ範囲を広げないでください。
ブロック後に空白が残ります。空白も消せますか？
REJECTが影響するのはリクエストであり、ページのレイアウトはWebサイトやアプリが決めます。リソースの読み込みに失敗した後も、表示領域が残ることがあります。空白をなくすために無関係なドメインまで拒否しないでください。まず対象リソースが拒否されていることを確認し、接続レベルのルールで対応できる範囲を理解しましょう。
同じドメイン内の一部のコンテンツだけを読み込みたくない場合は、どうすればよいですか？
まず、すべてのサービスに影響するサフィックスルールを取り消してください。DOMAINとDOMAIN-SUFFIXではURLパスを区別できません。URLを確認でき、処理条件が明確な場合に限り、URL Rewriteを検討します。コンテンツが同じAPIレスポンスに含まれている場合、ホスト単位で拒否すると、正常なデータも一緒にブロックされるのが一般的です。
しばらくすると、ルールが効かなくなったように見えるのはなぜですか？
Configで、現在選択中のConfigとルールが残っているか確認し、続けてGlobal Routingを確認してください。リモートConfigの更新、Configの切り替え、同じコンテンツを提供する別ホストなどによって結果が変わることがあります。自動接続に関係する場合は、Settings → On Demandも確認してください。On Demandは接続を開始する条件を制御するもので、Config内のマッチルールの代わりにはなりません。
動画内の宣伝部分をすべてブロックできますか？
そのような保証はできません。宣伝部分が同じメディアストリームに含まれている場合や、すでに端末へダウンロードされている場合、接続レベルでは個別に拒否できるリクエストがありません。まず、個別に識別できるホストから配信されているか確認してください。区別できない場合は、広範なREJECTルールを追加し続けると、動画全体が再生できなくなる可能性が高まります。
最終的に残すルールは、対象が明確であること、リクエストログで確認できること、正常な機能を復旧できることの3点を満たす必要があります。ルールの数が多くても、より正確に網羅できるとは限りません。個別に判別できない内容は、対象を広げ続けるのをやめるほうが、推測でサフィックスルールを増やすより管理しやすくなります。
Shadowrocketの正規購入とConfig設定を確認
Shadowrocketはクローズドソースの商用アプリで、買い切り方式です。入手先はApp Storeのみです。開発元はShadow Launch Technology Limited、アプリIDは932747118です。アプリの買い切りと接続サービスの契約は別です。この記事は、ご自身のサービスとConfigをお持ちであることを前提としています。主にiPhoneとiPadで利用できます。システム要件と購入可能な地域は、App Storeのページで確認してください。