Shadowrocketを利用中で、現在の設定を調整したい方向けの記事です。まずルール条件とREJECTの処理を区別し、検証用ドメインで判定順序を確認したうえで、接続ログから誤ブロックを調べます。利用者自身が用意したサービスやサブスクリプションを使用することが前提です。例は構文の説明用であり、普段使いの設定を置き換える完成済みの構成ではありません。
1. REJECTは処理結果であり、コンテンツ識別機能ではない
ShadowrocketはAppleプラットフォーム向けの有料アプリです。入手先はApp Storeのみで、開発元はShadow Launch Technology Limited、アプリIDは932747118、購入方式は買い切りです。主な対応デバイスはiPhone / iPadです。その他のデバイスの互換性とシステム要件は、App Storeの表示をご確認ください。アプリの買い切り購入と通信サービスの契約は別です。この記事ではローカル設定の判定と処理を扱い、接続サービスの提供は行いません。
DOMAIN-SUFFIX,example.com,REJECTというルールでは、DOMAIN-SUFFIXがマッチタイプ、example.comが条件、REJECTが一致したときの処理です。条件に合う通信を拒否し、それより下のルールには進みません。また、拒否した通信を自動的にプロキシ経由で再試行することもありません。
この流れが対象とするのは、Shadowrocketの処理対象に入る新しい通信だけです。すでに確立した接続、アプリのキャッシュ内のコンテンツ、処理対象外の通信は、ルールを1つ追加しただけですぐに消えるわけではありません。そのため、画面に以前の画像が表示されていても、REJECTが機能していないとは限りません。新たに発生させた通信と接続ログで確認してください。
2. ルール順序の前にGlobal Routingを確認する
Home → Global Routingで現在のルーティングモードを確認します。この記事の通常の設定ルールを検証する場合は、まずConfigを選び、Configで実際に有効になっている設定ファイルを確認してください。別のファイルにルールを保存しても、そのファイルを使用していなければ、現在の通信処理は変わりません。
| モード | 処理内容 | 確認ポイント |
|---|---|---|
Config | 現在の設定に従ってルールで通信を振り分けます。 | この記事のルール順序とREJECTの一致結果を検証する際に使用します。 |
Proxy | すべての通信をプロキシ経由にします。 | 通常のConfigルールと同じ条件の検証環境として扱うことはできません。 |
Direct | すべての通信を直接接続にします。 | 切り替え後にアクセスできても、プロキシサーバーに障害があるとは限りません。 |
Scene | 設定済みのシーンに従って処理します。 | テスト条件が変わらないよう、現在のシーン条件とルーティング設定を先に確認してください。 |
Settings → On Demandでは、条件に応じた自動接続を設定します。ルール一覧ではなく、特定のドメインをREJECTにするかDIRECTにするかを決める機能でもありません。テスト中にWi-Fiとモバイル通信を切り替えた場合は、トンネルの接続状態、Global Routing、現在の設定を改めて確認してください。自動接続の開始とルールへの一致を混同しないようにしましょう。
- 変更前に現在の設定をバックアップし、Global Routingの状態とテスト対象のドメインを記録します。
- Configで実際に使用している設定を編集し、条件またはルールを一度に1つだけ変更します。
- 保存後、現在も同じ設定ファイルが選択されていることを確認します。対象ページを閉じて、通信を新たに発生させます。
- 新しい通信の宛先、一致したルール、最終的な処理を確認してから、次の変更を判断します。
3. DOMAIN-SUFFIX、IP-CIDR、FINALの書き方
ルールは通常、上から順に照合され、最初に一致したルールの処理が適用されます。より具体的な例外は広い条件のルールより前に置き、FINALは末尾に配置して一致しなかった通信を処理します。広い範囲を対象にするREJECTを先に置くと、その後にDIRECTを追加しても、すでに一致した通信は救済できません。
以下は読みやすさを重視した学習用の例です。ドメインと192.0.2.10は説明用に使用しています。独自のポリシー名に依存しないよう、最後のルールにはDIRECTを指定していますが、日常の設定ですべての通信を直接接続するという意味ではありません。この例で既存の完全な設定を置き換えないでください。
[Rule]
DOMAIN,keep.example.com,DIRECT
DOMAIN-SUFFIX,example.com,REJECT
IP-CIDR,192.0.2.10/32,REJECT,no-resolve
GEOIP,CN,DIRECT
FINAL,DIRECTドメインの一致範囲
- DOMAIN
- keep.example.com,DIRECT：完全一致するドメインだけを例外にします。
- DOMAIN-SUFFIX
- example.com,REJECT：ルートドメインとそのサブドメインを対象にします。
- 一致しない類似ドメイン
- notexample.comはexample.comのサブドメインではありません。
完全一致の例外を先に置き、その後にサフィックスルールを置きます。文字列に特定の文字が含まれるかどうかで判定するものではありません。
IPとフォールバックの範囲
- IP-CIDR
- 192.0.2.10/32,REJECT,no-resolve：例示用のIPv4アドレス1つに一致します。
- GEOIP
- CN,DIRECT：IPの地理情報データベースに基づいて判定します。
- FINAL
- DIRECT：それまでのルールに一致しなかった通信を処理します。
no-resolveは、このIPルールに一致させるためにドメイン名の名前解決を積極的に行わない設定です。すべてのDNSクエリを無効にするという意味ではありません。
上記の順序では、keep.example.comは先に完全一致の例外に一致し、img.example.comは後続のサフィックスREJECTに一致します。IPルールを判定できるかどうかは、その時点で宛先IPアドレスを取得できるかにも左右されます。GEOIPが示すのはデータベース上の地域情報であり、サーバーの所在地やコンテンツの性質を保証するものではありません。これらの条件をすべて同じ種類のドメインフィルターとして扱わないでください。
4. 同一ドメインのコンテンツとHTTPS：REJECTでできること・できないこと
ドメインルールで判断できるのは「この宛先ドメインを拒否するかどうか」であり、「ページ内のどのコンテンツを削除するか」ではありません。主要な機能とブロックしたいコンテンツが同じドメインを共有している場合、そのドメインにREJECTを設定すると、ログイン、画像、決済画面への遷移など、ほかの依存通信にも影響する可能性があります。
| 対象となる状況 | ドメインにREJECTを設定した場合 | そこから判断できないこと |
|---|---|---|
| 独立したサブドメインでリソースを配信 | 宛先を識別でき、ルールに一致すれば、そのサブドメインへの通信を拒否できます。 | ページ内に残る空白のプレースホルダーまで消えるとは限りません。 |
| 同じドメイン上にある複数のHTTPSパス | そのドメインへの通信が拒否されます。 | ドメインルールだけでは/contentと/metricsを区別できません。 |
| 複数のドメインで1つのIPアドレスを共有 | IP-CIDRの設定が複数の異なるサービスに影響する可能性があります。 | 1つのIPアドレスを1つのWebサイトと同一視できません。 |
| 通信がUDP 443を使用 | 実際の宛先とルールへの一致状況を確認する必要があります。 | ポート番号だけで通信の種類やブロック済みかどうかは断定できません。 |
通常のドメインルールやIPルールは、通信がトンネルを通るだけでHTTPSの完全なパスや本文を取得できるようになるわけではありません。暗号化された接続のアプリケーション層コンテンツを、DOMAIN-SUFFIX条件で部分ごとに選別することはできません。Shadowrocketが対応する接続プロトコルとローカルルールは別のレイヤーです。プロキシプロトコルを変更しても、ドメインルールにページ要素を識別する機能が加わるわけではありません。
結論：対象を切り分けられない場合は、拒否範囲を絞る
同じドメインが必要な機能とブロックしたい通信の両方に使われている場合は、ドメイン全体へのREJECTを解除し、独立して識別できる宛先がないか確認してください。個別の条件が見つからない場合は、広範囲なIP拒否ルールを追加し続けるより、機能を維持するほうが検証や管理が容易です。
5. 誤ブロックの調べ方：接続失敗から原因を追う
ルールによる誤ブロックでは、メインページは開くのにログインが終わらない、テキストは表示されるのに画像が読み込まれない、特定の操作が毎回同じ段階で失敗する、といった症状が見られます。ただし、これらは手がかりにすぎず、REJECTへの一致を直接示すものではありません。DNSの失敗、リモート接続の失敗、アプリ自体のエラーでも似た症状が起こることがあります。
- 再現手順を固定する。失敗した時刻、操作内容、ネットワーク、設定名を記録します。たとえば、複数のアプリを同時に試すのではなく、同じログインページを毎回開きます。
- 接続ログを確認する。失敗した時刻の前後に、対象のドメインまたはIPアドレスを探します。REJECTと表示されているか、どのルールに一致したかを確認してください。REJECT以外の場合は、DNS、接続の確立、リモート側の応答を調べます。
- 直近の変更を1つ戻す。追加したルールを一時的に削除し、設定を保存してから同じ操作を再度行います。どの変更が影響したのか分からなくなるため、ルール一式をまとめて削除しないでください。
- 必要な宛先に例外を追加する。必要な依存先ドメインを確認できた場合は、広範囲な拒否ルールより前に、完全一致のDOMAIN例外を追加します。適用するポリシーは既存設定に合わせて選び、常にDIRECTにする必要はありません。
- 設定を戻して検証する。主要な機能と、もともと拒否する予定だった対象の両方を再テストします。両方が想定どおりになって初めて、例外によってブロック範囲全体が解除されていないことを確認できます。
新しいルールをテストする際は、対象への接続を新たに確立してください。必要に応じてトンネルを切断してから再接続し、On Demandによって想定外の状態に変わっていないことも確認します。画面に残るキャッシュ済みコンテンツは、再読み込みしてから判断してください。問題を共有するときは、対象やルール、エラーの内容を特定できる範囲で示し、サブスクリプションの完全なURL、token、パスワードなどの認証情報は伏せてください。
6. よくある質問：コンテンツが見えてもルールが無効とは限らない
REJECTを追加したのに、以前の画像がまだ表示されるのはなぜですか？
まずページを再読み込みし、新しい接続を確認してください。画像はアプリのキャッシュから表示されているか、ルールを追加する前にすでに読み込まれている可能性があります。新しい宛先への通信が引き続き成功し、想定したREJECTにも一致していない場合に、現在の設定、ドメイン条件、判定順序を確認します。
ドメインを拒否したら、ログイン全体が失敗するのはなぜですか？
まずルールを解除して同じ操作を再現し、失敗時の通信先と照らし合わせます。認証とサービス本体のリソースが同じドメインを共有していることがあります。必要なサブドメインだけを維持したい場合は、広範囲なDOMAIN-SUFFIXより前に完全一致のDOMAIN例外を追加して、ログインの流れを再テストしてください。
REJECTをFINALの後に置いても変化しないのはなぜですか？
FINALは、それまでのルールに一致しなかった通信を処理するフォールバックです。FINALより後ろにある通常のルールでは、すでにフォールバック処理された通信を扱えません。具体的な条件をFINALより前に置き、完全一致の例外、対象の拒否、その他の振り分け、最後のフォールバックという順序を保ちましょう。
リソースが使用したIPアドレスをすべて拒否できますか？
まず、そのIPアドレスがほかの必要なサービスと共有されていないか確認してください。CDNのアドレスは変わる可能性があり、1つのIPアドレスで複数のドメインが運用されていることもあります。特定のドメインだけを制限したい場合は、検証可能なドメイン条件を優先してください。対象が特定できていない段階で、広範囲なIPネットワークを使わないでください。
調査後は、変更したルール、目的、再現手順、元に戻す方法を簡潔に記録しておきましょう。後から問題が起きた場合は、確認範囲を広げる前に直近の変更を見直します。Home、Config、Settingsの基本操作ははじめにで、ルール用語は用語集で確認できます。