この記事は、Shadowrocketで基本的な接続設定を済ませ、プロキシ経由の範囲を絞りたいユーザー向けです。Global RoutingをConfigに設定し、ルールの先頭に指定サイトのドメイン条件を置き、FINAL,DIRECTで未一致の通信を受けます。設定後は一時ルール、リクエストの挙動、ルール順を確認します。
まずConfigモードでリクエストが処理される流れを確認
Shadowrocketのルール分岐は、Global RoutingがConfigの場合に限り、Config内のRuleの順番どおりに実行されます。現在の姿勢がProxyなら通信は一括してプロキシポリシーに渡され、Directなら直接接続されます。Sceneでは条件に応じて姿勢が選ばれます。一部サイトだけをプロキシ経由にするには、まずHomeでGlobal Routingを確認し、Configを選択します。
ルールエンジンは上から順に評価し、最初に一致した時点で処理を終了します。リクエストが最初の適用ルールに一致すると、後続のDOMAIN-SUFFIX、GEOIP、FINALは判定されません。そのため、範囲の狭い例外ルールを広いルールより前に置き、最終ルールは末尾に残します。
ルール判定の入力はドメインだけではない
- ドメイン情報：DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORDで使用します。ホスト名に一致しますが、URLのパス、クエリパラメータ、ページタイトルには一致しません。
- 宛先IP：IP-CIDRとGEOIPで使用します。ドメインの名前解決後、宛先アドレスがIPレイヤーのルール判定に使われる場合があります。
- 宛先ポート：DOMAIN-SUFFIXはドメイン自体を判定します。サイトが一般的な80、443、または別のポートを使用していても、ホスト名が一致すればドメインルールは適用されます。
- 最終フォールバック：FINALは、それまでのルールで処理されなかった通信を扱うため、ルール一覧の末尾に置く必要があります。
DOMAIN-SUFFIX、DOMAIN-KEYWORD、GEOIP、FINALの違い
この4種類のルールは対象範囲が異なります。指定サイトだけをプロキシ経由にする場合は、通常DOMAINまたはDOMAIN-SUFFIXを中心に使います。DOMAIN-KEYWORDは、ドメイン構成が変わりやすくても明確に固定された文字列がある場合に限って使用します。GEOIPは宛先IPを地域データベースで分類し、FINALはドメインやアドレスを確認せず、残りのリクエストを処理します。
ルールの最後の項目はポリシーです。PROXYはプロキシポリシーに渡し、DIRECTは直接接続し、REJECTはリクエストを拒否します。Configでカスタムポリシーグループ名を使う場合、ルール末尾にはConfigに実在する名前を完全に同じ表記で指定してください。ポリシー名が一致しないと、ルールに一致しても期待どおりの出力結果になりません。
| ルールキーワード | 一致対象 | 適した用途 | 注意点 |
|---|---|---|---|
| DOMAIN | 完全なドメイン名 | 1つの明確なホスト名だけを処理 | サブドメインは自動的に含まれない |
| DOMAIN-SUFFIX | ドメインサフィックス | メインドメインとサブドメインをまとめて対象にする | 範囲を広げすぎない |
| DOMAIN-KEYWORD | ドメイン内の文字列 | 固定キーワードを含む複数のドメインに一致 | 関係のないドメインにも誤一致する可能性がある |
| GEOIP | 名前解決後の宛先IP | アドレスの所在地域で分類 | IPとローカルデータベースの判定結果に依存 |
| IP-CIDR | IPv4アドレス範囲 | 固定アドレス帯を処理 | アドレス変更後は設定の更新が必要 |
| FINAL | 残りすべてのリクエスト | デフォルトの出力経路を定義 | 必ずルールの末尾に置く |
同じドメインの広いルールと狭いルール
[Rule]
DOMAIN,static.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT上の例では、まずstatic.example.comをDIRECTに指定し、example.comとその他のサブドメインをPROXYにします。2行目を1行目より前に置くと、静的ホストも先にDOMAIN-SUFFIXへ一致し、後続のDOMAINによる例外は実行されません。
結論：例外、範囲、フォールバックの順に記述する
ルール順を確認するときは、「完全なドメイン名 → ドメインサフィックス → 広いキーワード → IP分類 → FINAL」の順に整理できます。別の順序が必要な場合も、狭い条件を、それを包含する広い条件より前に置いてください。
そのまま書き換えられる「指定サイトはプロキシ、その他は直接接続」のConfig
以下の例では予約済みのサンプルドメインを使用しており、実在のサービスには対応していません。編集前に現在のConfigをバックアップとして複製し、Configを開いて使用中のローカル設定のRuleセクションを編集してください。ユーザー自身の契約先から取得した設定は、更新時に手動変更が上書きされる場合があります。独立したローカルConfigを保管し、カスタムルールを記録しておくと安全です。
例のPROXYは、現在のConfigで利用できるプロキシポリシーに置き換えてください。ルールはリクエストを渡すポリシーを決めるだけで、既存設定のプロトコルは変更しません。既存の接続がShadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuardのいずれであっても、DOMAIN-SUFFIXの最初の一致処理は同じです。
[Rule]
DOMAIN,login.example.com,PROXY
DOMAIN-SUFFIX,example.net,PROXY
DOMAIN-KEYWORD,media-example,PROXY
GEOIP,CN,DIRECT
FINAL,DIRECT- 完全なドメイン名を置き換える：
login.example.comを、個別に処理したいホスト名へ変更します。DOMAINには完全なホスト名を記述し、https://、ポート、スラッシュ、ページパスは付けません。 - ドメインサフィックスを置き換える：
example.netを対象サイトのメインドメインに変更します。DOMAIN-SUFFIXは、そのドメイン自体と配下のサブドメインを対象にします。 - キーワードは慎重に残す：複数の対象ドメインが固有の文字列を共有していると確認できる場合だけ、DOMAIN-KEYWORDを使用します。不要であればこの行は削除できます。
- デフォルト経路を確認する：
FINAL,DIRECTは「その他の通信を直接接続する」ための要です。FINAL,PROXYと誤って記述すると、未一致のリクエストもプロキシポリシーに送られます。 - 保存して適用する：Configに戻り、編集した設定が選択中であることを確認します。その後HomeでGlobal RoutingをConfigに切り替え、接続を再確立します。
固定IPの例外が必要な場合
[Rule]
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
DOMAIN-SUFFIX,example.net,PROXY
FINAL,DIRECT192.0.2.0/24は文書用のサンプルアドレス帯です。no-resolveは、照合のために追加のドメイン解決を行わないことを示し、宛先がすでにIP形式で現れる場合に適しています。分散ネットワークを使うサイトは地域、時間、ネットワーク条件によって異なるアドレスを返すことがあるため、1回の名前解決結果をもとにアドレス帯を固定しないでください。
ルールが指定サイトだけに適用されることを確認する方法
保存できたことと、ルールが期待どおりに動作することは別です。確認時は、「Configが有効か」「対象ドメインが完全か」「より前の項目に先取りされていないか」「サイトが別のドメインを呼び出していないか」を分けて確認します。一度に1つだけ変更すると、どのルールが現象を引き起こしたか判断できます。
- 姿勢を確認：HomeでGlobal Routingを開き、現在がConfigであることを確認します。Proxy、Direct、またはSceneによって一時的に切り替わった別の姿勢になっていないか注意してください。
- 設定を確認：Configを開き、新しいルールを含むローカル設定が選択中か確認します。無効なコピーを編集しても、現在の通信は変わりません。
- まず一般サイトを確認：ルールに記述していないサイトを開きます。最終行がFINAL,DIRECTなら、直接接続の経路で処理されるはずです。
- 次に対象サイトを確認：DOMAIN-SUFFIXを記述したサイトを開きます。トップページは開くのに画像、ログイン、動画が失敗する場合は、ページが別のドメインも呼び出している可能性があります。
- 依存ドメインを追加：Shadowrocketで確認できるリクエストのホスト名をもとに、本当に必要なDOMAINまたはDOMAIN-SUFFIXを1つずつ追加します。意味が曖昧なキーワードに置き換えて範囲を広げないでください。
- 例外を再確認：対象サイト、一般サイト、システムでよく使うネットワーク機能をそれぞれテストし、新しいルールがFINALの後ろに置かれていないこと、無関係なドメインまで対象にしていないことを確認します。
一時的なREJECTでドメインの一致を確認する
ドメインが実際にページ読み込みへ関与しているか分からない場合は、そのドメインのポリシーを一時的にREJECTへ変更できます。該当リソースの読み込みが直ちに止まれば、ドメインとルール位置は有効です。確認後はすぐにPROXYまたはDIRECTへ戻してください。この方法はルールの特定用であり、長期設定には適しません。
[Rule]
DOMAIN-SUFFIX,assets.example.net,REJECT
FINAL,DIRECTエラー：Failed to load config
原因と対処：よくある原因は、Rule行のカンマ不足、セクション見出しの記述不完全、ポリシーフィールドの空欄です。Configに戻り、各行が「ルールキーワード,一致値,ポリシー」の構造になっているか確認します。また、[Rule]が1行だけで記述されていることを確認してから再読み込みしてください。
エラー：Policy not found
原因と対処：ルール末尾に記述したポリシー名が現在のConfigに存在しないか、大文字と小文字が実際の名前と一致していません。既存のポリシー名を確認し、一字ずつ正確に置き換えてください。他の設定にあるカスタム名をそのまま使わないでください。
よくあるずれと、さらに範囲を絞る方法
1つのサイトが通常使うドメインは1つとは限りません。メインページ、静的リソース、ログインAPI、メディアリソースが別々のホスト名に分かれていることがあります。そのため、メインドメインだけを記述した後に「ページの枠組みは開くが内容がない」場合、Shadowrocketがルールを無視しているのではなく、ページが必要とする別のリクエストを対象にできていない可能性があります。
一方、DOMAIN-KEYWORDは手軽ですが、文字列だけでは対象範囲を正確に判断しにくい点に注意が必要です。キーワードが無関係な複数のドメインに含まれていると、それらも同じポリシーに一致します。長期運用する設定ではDOMAINまたはDOMAIN-SUFFIXを優先し、DOMAIN-KEYWORDは検証済みの補助として使ってください。
DOMAIN-SUFFIXを設定したのに、サイト全体を読み込めないのはなぜですか？
まず、失敗したリソースに対応するホスト名を記録します。ログイン、画像、メディアが別のドメインから配信されている場合は、DOMAINまたはDOMAIN-SUFFIXを個別に追加してください。ドメインルールはパスに一致しないため、URLのパスをルールに記述しないでください。
なぜすべてのサイトがプロキシポリシーに入るのですか？
まずHomeでGlobal Routingが誤ってProxyになっていないか確認し、次にRuleの最終行がFINAL,DIRECTか確認します。FINALがPROXYになっていると、前のルールに一致しなかったすべてのリクエストがプロキシポリシーに送られます。
ルールを変更しても何も変わらないのはなぜですか？
Configを開き、現在選択中の設定を編集したか確認します。その後HomeでConfigの姿勢を選び、接続を再確立してください。対象ルールがFINALより前にあるか、前方に広いルールがあり先に一致していないかも確認します。
サブスクリプション更新後に手動ルールが消えた場合は？
サブスクリプションの内容が更新されると、該当する設定が書き換えられる場合があります。変更前にローカルコピーを保存し、カスタムRuleを記録してください。更新後はコピーと照合し、必要な項目を復元します。サブスクリプションの有効性と内容は、ユーザー自身のサービス提供者に確認してください。
80と443のポートごとにドメインルールを書く必要がありますか？
必要ありません。DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORDはホスト名に一致し、ポートごとには分かれません。同じドメインが80、443、または別のポートを使っていても、同じドメインルールでポリシーが決まります。
安定した設定の確認手順
- まずHome → Global Routing → Configを確認します。
- 次に、Configで選択中のファイルが、いま編集したファイルと同じか確認します。
- 正確なDOMAINを、広いDOMAIN-SUFFIXより前に置きます。
- DOMAIN-KEYWORDは、確かな根拠がある最小範囲に限定します。
- IPルールが必要な場合に、IP-CIDRまたはGEOIPを追加します。
- FINAL,DIRECTは必ず最後の行に残します。
- 変更後は対象サイトと、ルールに含めていない一般サイトを別々にテストします。