ShadowrocketのREJECTルールとは？ブロックできる通信・できない通信

この記事の要点

ShadowrocketのREJECTは通信を拒否するポリシーで、ページ上の要素を削除する機能ではありません。まずConfigで対象ルールを含む設定を選び、Home → Global RoutingでConfigを選択します。利用中のサービス情報やサブスクリプションがあり、ローカルルールを調整する方向けに、ドメインの照合方法、URLの可視性、ルールの順序やキャッシュの影響を解説します。範囲を絞って検証し、誤ブロックを防ぎましょう。

1. REJECTが適用される範囲：ページの変更ではなく通信の照合

アプリが通信を開始しても、Shadowrocketの処理対象となる通信だけが、現在の設定にあるルールの判定を受けます。ルールは取得可能なドメイン、宛先IP、URLなどの情報を条件にします。REJECTルールに一致すると、その通信は拒否され、DIRECTやプロキシのポリシーには渡されません。アプリには読み込みエラーや再試行の表示が出ることがあります。また、アプリ側で別のアドレスに切り替える場合もあります。

アプリからの通信通信の処理条件の識別ルールの照合接続を拒否

この処理はページのレイアウトを認識せず、画像やテキストが「広告かどうか」も判定しません。対象コンテンツが独立したドメインから読み込まれる場合、そのドメインへの通信を拒否すれば、コンテンツの表示を防げることがあります。一方、メインページの応答にコンテンツが含まれている場合、REJECTでその一部だけを削除することはできません。空白の領域や読み込みアイコン、アプリが独自に表示するメッセージも、通信ルールで直接消せるものではありません。

まず「ブロック対象のコンテンツに独立した通信があるか」を確認し、そのうえで照合条件を選びます。表示領域が空白のままでも、通信が拒否されていないとは限りません。コンテンツが一時的に表示されなくても、ルールに一致したとは限りません。

2. DOMAIN-SUFFIXの書き方：独立したドメインから小さくブロック

DOMAIN-SUFFIXは、指定したドメインとそのサブドメインに一致します。以下のads.example.comは書式を説明するための例で、実際に使えるブロックリストではありません。ads.example.comとimg.ads.example.comには一致しますが、notads.example.comには一致しません。サブドメイン1つを対象にするために、親ドメイン全体をREJECTに設定しないでください。

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

上記の例は「対象ドメインへの通信を拒否し、それ以外は直接接続する」という考え方を示すものです。あらゆる通信要件に対応する完全な設定ではありません。既存の設定でFINALが別のポリシーを指定している場合は、元のフォールバックの意図を維持し、機械的にDIRECTへ置き換えないでください。既存の設定に[Rule]がある場合は、そのセクションにルールを追加し、同じ名前のセクションを重複して作成しないでください。

Configで現在の設定をバックアップし、編集しているファイルが有効化する予定のファイルであることを確認します。
対象ドメインのREJECTルールは、先に一致する可能性のある広範な許可ルールより前に配置し、FINALはルールの末尾に残します。
設定を保存して選択し、Home → Global Routingに戻ってConfigを選択します。
接続が有効になっていることを確認してから対象の通信を再試行し、ログイン、画像、本文など通常の機能に影響がないかも確認します。

通常の順序でルールが照合される場合、先に一致したルールによってポリシーが決まります。たとえば、先にDOMAIN-SUFFIX,example.com,DIRECTを記述し、その後にads.example.com向けのREJECTを記述すると、後者が適用されないことがあります。具体的な条件を先に、広範な条件を後に配置します。FINALは、それ以前のルールに一致しない場合の最終処理に使います。

3. Global Routingと照合条件：接続開始の条件とブロックルールを混同しない

ルールが適用されない場合は、まずHome → Global Routingを確認します。Proxy、Direct、Config、Sceneはそれぞれ異なるルーティング設定です。接続スイッチがオンというだけで、設定内のルールが使われているとは限りません。ここでは、選択中の設定に含まれるルールで通信を振り分けるConfigを、検証の基準とします。Sceneは個別にシーン設定を確認してください。この最小限のテストの前提には含まれません。

最小限のドメインテスト

設定を開く: Config → テスト用設定を選択
ルーティングを開く: Home → Global Routing → Config
対象ルール: DOMAIN-SUFFIX,ads.example.com,REJECT
フォールバックの例: FINAL,DIRECT

例は書式の説明用です。テストには、実際に対象であると確認したドメインを使用してください。

接続と照合の範囲

自動接続の設定: Settings → On Demand
On Demandの役割: 条件に応じて接続を開始する機能で、REJECTルールの代わりにはなりません
IP-CIDR条件: 宛先IPが属するネットワーク範囲で照合
GEOIP条件: 宛先IPの地理情報で照合

まず接続とConfigを確認し、次にリクエストからどの照合情報を取得できるか確認します。

ドメインルールを使うには、リクエストに対応するドメイン情報を取得できる必要があります。アプリがIPアドレスに直接アクセスする場合、異なる名前解決経路を使う場合、または観測できる情報が限られる場合は、ドメイン条件に必ず一致するとは限りません。IP-CIDRはネットワーク範囲、GEOIPは地理情報を条件にできますが、どちらもIP上のコンテンツの用途までは判定できません。特に、共有サーバーやコンテンツ配信先では誤ブロックが起こりやすくなります。

Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuardは接続プロトコルの名称であり、「ページの内容を識別する」ためのルール条件ではありません。REJECTに一致した通信は、プロトコルを変更しても許可されるようにはなりません。まず一致したルールとポリシーを確認し、その後で別の接続問題がないかを判断してください。

4. URL-REGEXの書き方：パスを照合できるかはURLの可視性次第

URL-REGEXは正規表現でURLに一致させるためのルールで、ドメインルールより細かくパスを指定できます。以下の例は、サンプルのホストで/banner/から始まるパスだけに一致します。^はURLの先頭、\.はピリオドそのもの、https?はHTTPまたはHTTPSを表します。正規表現で条件を記述できても、すべての接続でクライアントが完全なURLを取得できるとは限りません。

URL-REGEX,^https?://ads\.example\.com/banner/,REJECT

条件	必要な情報	主な制約
`DOMAIN-SUFFIX`	宛先ドメイン	同じドメイン内の異なるパスは区別できません。
`URL-REGEX`	照合可能なURL	HTTPSで暗号化されたパスは通常、そのまま読み取れません。
`IP-CIDR`	宛先IPとネットワーク範囲	同じIP上の複数のサービスに影響する場合があります。

HTTPSでは、パスやクエリパラメーターを含むHTTPリクエストの内容が暗号化されます。一般的な443番ポートを使っていても、ホスト名が分かることと/banner/を読み取れることは別です。HTTPSのパスを照合するには、通常、対象の通信がMITMで処理でき、対象ホストの範囲、証明書の信頼、アプリの互換性などの条件を満たす必要があります。URL-REGEXを、ほかの設定なしで暗号化されたパスを読み取れるルールとして扱わないでください。

アプリによっては証明書ピンニングなどの検証機能があり、MITMで処理する接続を拒否することがあります。その場合は対象の処理を中止し、元の設定に戻してください。アプリのエラーを正規表現の誤りだけが原因だと決めつけないでください。クライアントが対応する処理経路であれば、平文HTTPからURL情報を取得できる場合がありますが、実際のリクエストとログを確認して照合結果を判断してください。

結論：ドメインが独立している場合は、まずドメインルール

対象が独立したドメインから読み込まれることを確認したら、まずDOMAIN-SUFFIXルールを1つテストします。同じドメイン内のパスを区別する必要があり、URLを確認できることも検証できた場合に限り、URL-REGEXを検討してください。

5. ブロックできる通信・できない通信：同じドメインのコンテンツ、キャッシュ、アプリ内通信

REJECTは、明確に識別でき、拒否しても必要な機能を損なわない独立した通信に適しています。「アプリ内通信」だからといって、自動的にルールを回避するわけではありません。処理対象に含まれ、照合条件を満たせば、その通信も拒否されることがあります。難しいのは、メインのサービスと同じドメインを使う、アドレスが変わる、既存の長時間接続を使う、または新しい通信が発生しない場合があることです。

独立したリソース用ドメイン：そのドメインへの通信を拒否すれば新しい接続を防げますが、認証コード、画像、ログインにも使われていないか確認してください。
同じドメイン内の異なるパス：DOMAIN-SUFFIXはドメイン全体に適用されるため、特定のページ領域だけを区別できません。URL-REGEXもURLを取得できる範囲でしか使えません。
同じレスポンスに含まれるコンテンツ：本文と追加コンテンツが同じレスポンスで返される場合、通信を拒否すると両方がブロックされ、本文だけを残すことはできません。
ローカルキャッシュと内蔵素材：新しい通信なしでアプリに表示されるコンテンツは、REJECTルールを追加しても自動的には消えません。
代替アドレスと再試行：あるアドレスへの通信を拒否すると、アプリが別のアドレスにリクエストすることがあります。親ドメイン全体のブロック範囲を広げるのではなく、後続のリクエストを確認してください。
既存の接続：新しいルールを、確立済みのすべての接続を即座に切断する命令と考えないでください。検証時には、対象のアプリから新たに接続を開始してください。

たとえば、ログインAPIとブロック対象のリソースがどちらもapi.example.comにある場合、そのドメインにREJECTを設定するとログインも失敗する可能性があります。複数のドメインが同じIPを共有している場合、ネットワーク範囲で拒否しても精度が上がるとは限りません。ルールの範囲はリクエストの構造に合わせてください。根拠が不足しているからといって、ブロック範囲を広げないでください。

6. 検証と元に戻す方法：一度に変更するのは1項目

有効な検証では、「対象の通信が拒否されたか」と「必要な機能を引き続き使えるか」の両方を確認します。Connectivity Testは選択中の接続先への到達性を診断する機能で、REJECTへの一致をテストするものではありません。テスト結果が正常でもブロックルールの適用を証明することにはならず、異常でも対象ドメインが拒否された証拠にはなりません。

変更前の状態を記録：元の設定を残し、対象コンテンツの表示場所、確認済みのリクエストドメイン、ログインなどの正常な機能を記録します。
ルールを1つだけ変更：具体的なドメインルールを1つ追加し、プロトコル、フォールバックポリシー、DNS設定を同時に変更しないでください。
設定状態を確認：Configで選択中のファイル、Home → Global Routing → Config、接続スイッチの状態を確認します。
リクエストを再実行：対象のページを再読み込みするかアプリを再起動し、既存の接続やキャッシュによる影響を取り除きます。
根拠を確認：利用可能なリクエスト記録やログで対象ドメイン、一致したルール、最終ポリシーを確認します。ページの見た目だけで判断しないでください。
変更前と比較して元に戻す：ルールを削除するかバックアップを復元し、同じ手順をもう一度実行します。必要な機能に影響が出た場合は、まず使える状態に戻してください。

REJECTを設定したのに、コンテンツが表示されるのはなぜですか？

まずHome → Global RoutingでConfigが選択されていることを確認し、次にConfigで選択中のファイルを確認します。その後、リクエストを再実行してください。新しい対象リクエストの記録がなければ、広範なルールを追加する前に、キャッシュ、内蔵素材、既存の接続を確認します。

ブロックしたらログインできなくなりました。どうすれば元に戻せますか？

Configで追加したREJECTルールを削除するか、バックアップを復元して保存し、設定を選び直します。対象ドメインがログインAPIと共有されているか確認してください。検証せずに親ドメイン全体や共有IPのネットワーク範囲を拒否しないでください。

URL-REGEXは正しいのに、HTTPSのパスに一致しないのはなぜですか？

まず実際のリクエストURLと正規表現が一致するか確認し、次に通信の完全なURLを取得できるか確認します。ドメインしか見えない場合、パスを照合するための情報が不足しています。443番ポートや接続成功だけを根拠に、MITMが機能していると判断しないでください。

設定を更新したら、追加したルールが消えました。なぜですか？

サーバー情報のサブスクリプション更新とリモート設定の更新を区別してください。前者は主にサーバー情報を更新し、後者は設定内容を置き換える場合があります。変更前に別の場所へバックアップを保存し、更新後はConfig内のルール、順序、選択状態を確認してください。Homeのサーバー一覧だけを確認して終わらせないでください。

振り分け条件について詳しく知りたい場合は技術リファレンスをご覧ください。初回接続やルーティングモードの操作については入門ガイドのGlobal Routingの説明をご確認ください。当サイトではノードやサブスクリプションの提供・販売・推奨は行っていません。クライアントの購入と、利用者が別途契約する接続サービスはそれぞれ独立したものです。