ShadowrocketのREJECTルール設定と適用範囲｜できること・できないこと

この記事の概要

ShadowrocketのREJECTは接続を処理するためのポリシーであり、ページ上の要素を除去する機能ではありません。接続が正常に使えており、Configを自分で調整したい方向けに、まずドメイン・IPルールの適用範囲を説明します。次に、部分的な変更、マッチの確認、設定の復元方法を紹介し、ルールが適用されない場合と、リソースを個別にブロックできない場合を区別します。

REJECTの対象は接続。ページ内の一部分ではない

ルールはマッチ条件と処理ポリシーで構成されます。クライアントは対象ドメインやIPなどの情報を取得できる場合、現在の設定に基づいて接続の処理方法を判定します。REJECTルールにマッチすると、その接続は拒否されます。ウェブページを読み込んで、特定の画像が広告かどうかを判定してから、その画像だけを削除する機能ではありません。そのため、ルールが適しているかどうかは、対象リソースを接続レベルで必要なリソースから切り分けられるかがポイントです。

たとえば、ページ本体が www.example.com、追加リソースが独立した metrics.example.com から配信されている場合は、後者にドメインルールを設定できます。ログイン、本文、追加リソースがすべて同じドメインで、パスだけが異なる場合、そのドメインを拒否すると、これらの機能にも影響することがあります。

3つの項目

よく使うドメインルール：タイプ、マッチ対象、ポリシー

TCP 443

HTTPSでよく使われるポート。リソースの種類を示すものではない

UDP 443

HTTP/3でよく使われるポート。独立したドメインを示すものではない

ポートは接続情報の一部にすぎません。接続が443を使っているからといって、ブロックすべきリソースだとは限りません。関連するポートをすべて拒否すると、多くの正常な通信に影響します。以下のドメインとIPは説明用の例であり、実際のブロックリストとして使わないでください。

よく使う設定例：まずDOMAINを使い、必要に応じてDOMAIN-SUFFIXやIP-CIDRを検討

以下はConfigの [Rule] セクションに追加できる部分的な例です。各行は独立した条件を表します。この数行をそのまま完全な設定として置き換えたり、例に合わせるために既存のポリシーグループやフォールバックルールを削除したりしないでください。

[Rule]
DOMAIN,metrics.example.com,REJECT
DOMAIN-SUFFIX,telemetry.example.com,REJECT
IP-CIDR,192.0.2.0/24,REJECT,no-resolve

ルールタイプ	マッチ範囲の例	使用前の確認事項
`DOMAIN`	`metrics.example.com` というドメインだけにマッチします。	まず単一のホストで検証し、必要な機能を担っていないことを確認する場合に適しています。
`DOMAIN-SUFFIX`	`telemetry.example.com` とそのサブドメインにマッチします。	`a.telemetry.example.com` も含まれ、完全一致より広い範囲が対象になります。
`IP-CIDR`	`192.0.2.0/24` はIPv4のネットワーク範囲を表します。	同じネットワーク範囲を複数のドメインが利用している場合があるため、用途を推測して使うのは避けてください。

DOMAIN-SUFFIX,example.com,REJECT は、親ドメインとそのサブドメインにもマッチします。「このサイトの特定の追加リソースだけをブロックする」という意味ではありません。ドメイン欄に https://、パス、クエリパラメータは入力しません。DOMAIN と DOMAIN-SUFFIX は、URL内の /banner/ などのパスにはマッチしません。

no-resolve は、このIPルールのために追加のドメイン解決を行わない指定です。このルールがドメイン接続にマッチしないという意味ではありません。クライアントが該当IPをすでに把握している場合もあるため、実際の接続情報に基づいて判断してください。IPv4ネットワーク範囲だけを指定しても、同じサービスのIPv6アドレスまで対象になるとは限りません。対象がIPv6を使う場合は、IPv4の範囲をむやみに広げず、実際のアドレスを確認してください。

まとめ：まず明確なドメインを1つ指定する

まずDOMAINルールを1つ設定し、対象と副作用を確認します。同じサブドメイン階層全体を拒否する必要があると確認できた場合に限り、DOMAIN-SUFFIXに範囲を広げてください。一度IPを確認しただけで、共有アドレスの範囲全体を拒否しないでください。

ルールの順序とGlobal Routing：構文が正しいだけでは不十分

Configでルールを適用する場合、通常は上から順にマッチを確認し、最初にマッチしたルールのポリシーが適用されます。対象を許可するルールが先にあると、それ以降のREJECTはその接続を処理できません。FINALは、それ以前のルールにマッチしない場合のフォールバックです。引き続き判定させる通常のルールより前に置かないでください。

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

上の例では、まず特定のドメインを拒否し、その後、同じ親ドメインのほかの接続をDIRECTにします。先頭2行を入れ替えると、metrics.example.com は範囲の広いDIRECTルールに先にマッチします。末尾の FINAL,DIRECT はマッチ順を示すための例です。実際の設定では必要なフォールバックポリシーを維持し、マッチしなかったすべての通信の行き先を、この例に合わせて変更しないでください。

Config

Proxy

通信をプロキシ経由で処理し、Configの通常の振り分けルールごとに行き先を決定しません。このモードでは、ウェブページが拒否されたかどうかで、編集したConfigルールを検証できません。

用途：一時的な接続確認、通常の振り分けルールの影響を切り分ける場合。

Direct

通信を直接接続で処理するため、カスタムConfigルールのマッチ確認には適していません。直接接続でページを開けても、REJECTの構文に問題があるとは限りません。

用途：直接接続の結果と比較し、ネットワーク環境の違いを確認する場合。

Sceneを使用している場合は、シーンで最終的に適用される設定と処理方法も確認してください。トラブルシューティング中は一時的にConfigに固定すると、シーン切り替えによる変動を減らせます。ここではテストによく使う3つのモードを比較しています。Global Routingのすべての選択肢を網羅した一覧ではありません。

設定の一部を変更して検証する：ルールは一度に1つだけ追加

以下の手順は、すでに利用可能な設定があることを前提としています。Homeのサーバー項目、Configの設定ファイル、Settingsの一般設定は、それぞれ用途が異なります。有効になっていない設定を編集しても、現在の接続に適用されるルールは自動では変わりません。

元の設定を保管する

Configを開いて、現在有効な設定を確認し、まず複製を作成するかバックアップをエクスポートします。元のGlobal Routingモードも記録し、変更前の状態に戻せるようにしてください。
処理モードを固定する

Home → Global Routing → Configで、設定に基づいて処理するモードを選択します。Homeの接続スイッチがオンになっていることも確認してください。クライアントが接続を処理していない状態でルールをテストするのを防げます。
完全一致ルールを追加する

Configで現在の設定の編集画面を開き、[Rule] セクションを探します。対象を含む広範なルールやFINALより前に、対象を確認済みのDOMAINルールを1つ追加して保存します。
新しい接続を確立する

変更後の設定が引き続き有効になっていることを確認し、必要なら再接続します。対象のページまたはアプリを終了してから開き直し、クライアントの接続ログで該当ドメインのポリシーとマッチ情報を確認してください。
確認して元に戻す

ログイン、本文、画像、動画再生など、必要な機能を個別にテストします。問題が起きたら、追加した行だけを削除して保存し、接続し直してください。DNS、サーバー、複数のルールセットを同時に変更しないでください。

検証では、「対象の接続がREJECTにマッチしたか」と「必要な機能が引き続き使えるか」の2点を確認します。ページの一部が消えたことだけでは、ルールが正しく動作した証拠になりません。サーバーの一時的な障害、アプリのキャッシュ、リソースの読み込みタイムアウトでも似た状態が起こります。反対に、ページに古い画像が残っている場合も、ローカルキャッシュが更新されていないだけかもしれません。新しいリクエストが通ったとは限りません。

ブロックの限界：同一ドメイン内のコンテンツ、暗号化されたパス、アプリ内リソース

一般的なドメイン・IPルールはウェブページの本文全体を読み取る必要はありませんが、そのため本文の内容に応じた選別もできません。HTTPSではリクエストパス、クエリパラメータ、本文などが暗号化されます。ドメインルールを、暗号化された完全なURLを識別できるフィルターとして扱わないでください。クライアントが対象ドメインを取得できるかどうかは、接続方式、名前解決の経路、利用可能な接続メタデータにも左右されます。

同じドメインでパスが異なる場合：example.com/article と example.com/promo が同じホストを使っている場合、DOMAINでは後者のパスだけを拒否できません。IPルールに広げても、パスを識別できるようにはなりません。
1つの接続を共有する場合：HTTP/2やHTTP/3では、1つの接続で複数のリクエストを処理できます。REJECTは、同じ接続内から特定のページ要素だけを選ぶ機能ではありません。接続を拒否すると、同時に転送されている正常なリソースにも影響することがあります。
アプリ内に保存されたリソース：アプリに保存済みの画像、画面表示、テキストは新しいリモート接続を必要としません。ネットワークルールで、こうしたローカルのコンテンツを削除することはできません。
サーバー側で統合されたコンテンツ：本文とほかのコンテンツが同じAPIから一度に返される場合、そのAPIを拒否すると本文も一緒に表示されなくなることがあります。一部だけを残せるとは限りません。
共有インフラ：複数のサービスが同じCDNやIPを使っている場合があります。アドレス範囲を拒否した後にほかのサイトも開けなくなったら、ブロック範囲をさらに広げるのではなく、アドレスルールを絞るか取り消してください。

REJECTにマッチしても、アプリに空欄やエラーメッセージ、キャッシュ済みのコンテンツが表示されたり、別のドメインで再試行されたりすることがあります。接続が拒否されることと、画面が再レイアウトされることは別の問題です。対象が決済、アカウント認証、メディアAPIとインフラを共有している場合は、必要な機能を優先して維持してください。異常なリクエストをすべてなくすことを目指すのは適切ではありません。

よくあるトラブルシューティング：ルールがマッチしないのか、対象を個別に処理できないのか

REJECTを設定したのに、なぜ開ける？

まずHome → Global Routing → Configを確認し、次にConfigで実際に有効なファイルを確認します。対象を含むDIRECT、ポリシーグループのルール、FINALより後ろにルールがないかを確認してください。接続を確立し直してログを確認します。画面に残っているキャッシュだけで判断しないでください。

同じドメインのほかのページに影響させず、特定のURLだけをブロックできますか？

DOMAINとDOMAIN-SUFFIXはドメインだけを基準にマッチします。パスをフィルターするために、ドメイン欄へ完全なURLを貼り付けることはできません。まず対象リソースに独立したホストがあるか確認してください。パスだけが異なる場合は、同じドメインへの正常なアクセスまで拒否しないよう、ドメインルールを広げないでください。

ルール追加後、ログインと画像の両方に問題が出た場合は？

最後に追加したルールを取り消して再接続し、機能が戻ることを確認します。DOMAIN-SUFFIXまたはIP-CIDRを使った場合は、共有ホストやアドレスまで対象になっていないか確認してください。接続ログで対象が独立していると確認できた場合に限り、範囲の狭いDOMAINルールに変更します。

サブスクリプションを更新すると、ローカルルールも自動で更新されますか？

HomeのSubscribeサーバーサブスクリプションとConfigの設定ファイルは別のものです。サーバーリストを更新しても、ローカルルールが更新されるわけではありません。リモート設定の更新では、手動の変更が上書きされることがあります。更新対象と現在有効な設定をそれぞれ確認し、ローカルの変更内容は複製して保存してください。

Settings → On Demandでルールのマッチを確認することもできません。On Demandは条件に応じて接続をいつ確立するかを制御し、REJECTは接続がルール判定に入った後の処理ポリシーを決めます。トラブルシューティング中に接続状態が変わる場合は、On Demandの条件も確認してください。ただし、オンデマンド接続の設定をブロックルールの編集場所として使わないでください。

ルールを残す基準：対象が明確で、副作用を許容でき、元に戻せる

ルールは数が多いほどよいわけではありません。追加するルールにはそれぞれ、明確な対象、再現できる現象、取り消す方法が必要です。用途を説明できない出所不明の広範なルール、特にIP範囲全体や広い親ドメインを拒否するルールは、日常利用の設定にそのまま追加しないでください。

変更前の設定を保管し、追加したルールの対象ドメインと理由を記録します。
ルールの追加後、新しい接続のログを確認し、アカウント、決済、再生など実際に使う機能をテストします。
アプリやウェブサイトがリソースのドメインを変更したら再検証します。以前うまくいったからといって、今後も有効とは限りません。
リモート設定を更新する場合は、ローカルの変更が上書きされるか事前に確認し、更新後に有効状態をもう一度確認してください。

ShadowrocketはApp Storeから入手するクローズドソースの商用アプリです。主にiPhone、iPadで利用でき、開発者はShadow Launch Technology Limitedです。アプリの買い切り購入と通信サービスのプランは別です。接続サービスは提供していません。既存のサブスクリプションリンクは利用中のサービス提供元から入手してください。価格、システム要件、購入対象地域はApp Storeの掲載情報をご確認ください。