この記事の概要

この記事は、Shadowrocketで自分のサービスを追加済みで、Configのルーティングを調整したい方向けです。現在の設定とGlobal Routingを確認したうえで、例示用ドメインを使ってルールの順序、ポリシー、FINALの役割を把握し、リクエストログで適用結果を確認します。例は構文の説明であり、接続サービスを提供するものではありません。

1. ルールを有効にする前にConfigとGlobal Routingを確認

カスタムルールは設定ファイルの[Rule]セクションに記述します。編集を始める前に、画面下部のConfigで現在使用中の設定を確認してください。別のファイルを開いて内容を確認しただけでは、その設定に切り替わっていません。まず元の設定を保存し、複製したファイルを編集すれば、解析エラーや意図しないブロックが発生したときに復元できます。

Homeに戻り、Global Routingを確認します。この記事のルール検証ではConfigを使用してください。ProxyとDirectは全体のルーティング設定であり、このどちらかを選んだ状態でのアクセス結果から、個別のカスタムルールが有効かどうかは判断できません。Sceneを使用中の場合は、実際に適用されるルーティングを確認してください。切り分け中は一時的にConfigへ固定すると、確認すべき要素を減らせます。

  1. Configを開き、現在使用中の設定名を記録して、元の内容を保存します。
  2. その設定の[Rule]セクションを編集し、ほかのセクションの見出しと必要な設定は残します。
  3. 保存後、編集した設定が引き続き選択されていることを確認します。
  4. Home → Global Routingを開いてConfigを選択し、新しいテストリクエストを実行します。

2. 上から順に照合：優先されるのは位置

同じ設定内のルールは、一覧の上から順に確認されます。条件に一致するルールが最初に見つかった時点で、そのルールのポリシーが適用され、後にある「より詳細な」ルールは確認されません。そのため、特定のドメインは広い範囲を指定するサフィックスルールより前に、例外ルールは一般ルールより前に置き、FINALは最後に配置します。

リクエスト情報 先頭のルール 順に照合 最初の一致 ポリシーを適用

以下は順序を誤った例です。api.example.comにアクセスすると、最初のDOMAIN-SUFFIXルールが一致してPROXYが適用されます。後ろのDOMAINルールは、対象範囲が狭いからといって自動的に優先されるわけではありません。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN,api.example.com,DIRECT
FINAL,PROXY

このサブドメインだけを直接接続にしたい場合は、先頭の2行を入れ替えます。example.comは説明用に予約されたドメインです。実際の対象に合わせてルールを作成し、接続確認用のサービスとして例を使用しないでください。

[Rule]
DOMAIN,api.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,PROXY

要点：例外ルールは対象を含むルールより前に置く

ポリシーを変更しても反映されない場合は、同じドメインをリスト末尾に追加するのではなく、上にある広範囲のDOMAIN-SUFFIX、IPアドレス範囲のルール、先に配置されたFINALを確認します。

3. DOMAIN-SUFFIX、IP-CIDR、GEOIPの照合対象

ドメインルールとIPルールでは、確認する対象が異なります。DOMAINは完全一致のドメイン、DOMAIN-SUFFIXはドメインのサフィックス、IP-CIDRは接続先のIPv4アドレスが指定したネットワーク範囲に含まれるかを照合します。GEOIPはIPの位置情報データベースを使って、接続先アドレスの地域を判定します。GEOIPのCNが示すのは接続先IPの判定結果であり、端末や選択中のサーバーの所在地ではありません。

キーワード構文例照合内容
DOMAINDOMAIN,api.example.com,DIRECT指定した完全一致のドメインだけに一致します。
DOMAIN-SUFFIXDOMAIN-SUFFIX,example.com,PROXYexample.comとそのサブドメインに一致し、notexample.comには一致しません。
IP-CIDRIP-CIDR,192.168.0.0/16,DIRECT,no-resolve指定したIPv4ネットワーク範囲に一致します。この例はプライベートアドレスの範囲です。
GEOIPGEOIP,CN,DIRECT接続先IPの位置情報データベースの判定に基づいてCNに一致します。
FINALFINAL,PROXYそれ以前のルールに一致しなかったリクエストを処理します。

no-resolveは、このIPルールへの照合を試みるためだけにドメインを解決しない、という指定です。全体のDNSを無効にするものではなく、アプリがドメインへアクセスする際に必要な通常の名前解決も妨げません。リクエストに利用可能な接続先IPがすでにあれば、IPルールの照合対象になる場合があります。これを理由に、すべてのドメインリクエストが照合をスキップする、またはルールに一致すると判断しないでください。

IP-CIDRの/16はプレフィックス長であり、ポート番号ではありません。この例の範囲は192.168.0.0から192.168.255.255までで、すべてのプライベートアドレスを含むわけではありません。ほかのローカルネットワークも直接接続する場合は、実際のネットワークごとに設定してください。また、ドメインルールではHTTPSの443番ポートとHTTPの80番ポートを区別しません。

3種類
この記事で使うポリシー：PROXY / DIRECT / REJECT
/16
例に使うプライベートネットワークのIPv4プレフィックス長
443
HTTPSで一般的な接続先ポート。ドメインルールの項目ではありません

4. PROXY、DIRECT、REJECTとFINALの関係

PROXY、DIRECT、REJECTは、ルールに一致した後に適用されるポリシーです。PROXYは現在選択中のプロキシに処理を渡します。設定で独自のポリシーグループを使用している場合は、グループ内の選択内容も確認してください。DIRECTは直接接続の経路を使う指定であり、システムVPNを無効にするものではありません。REJECTはリクエストを拒否します。明確に遮断が必要な対象に使い、名前解決の失敗を直す目的では使用しないでください。

FINALはルールの種類であり、4つ目の接続方式ではありません。ドメインやネットワーク範囲の条件はなく、FINAL,ポリシーと記述します。通常のルールのように3つのフィールドをそのまま使う書き方ではありません。FINALをリストの途中に置くと、その後にある通常のルールは照合されません。

対象ごとにポリシーを指定

PROXY
現在選択中のプロキシに処理を渡します。利用可能なサービスが必要です。
DIRECT
対象を直接接続の経路で処理します。ローカルネットワークの状態にも左右されます。
REJECT
リクエストを拒否します。一致対象を誤るとアクセスできなくなります。

対象に適した接続経路を決めてから、ポリシーを選択します。

末尾にフォールバックを設定

FINAL,PROXY
それ以前のルールに一致しないリクエストをプロキシに渡します。
FINAL,DIRECT
それ以前のルールに一致しないリクエストを直接接続します。
配置場所
ルール一覧の末尾に置き、その前に例外ルールと一般ルールを配置します。

フォールバックの選択は想定する接続経路によって異なり、固定の正解はありません。

「指定したドメインはプロキシ、それ以外は直接接続」にする場合は、対象ドメインにPROXYを指定し、最後にFINAL,DIRECTを置きます。「直接接続を明示した対象だけDIRECTにし、それ以外はプロキシに渡す」場合は、その逆の構成にします。どちらの場合も、必要なローカルアクセスの例外を先に処理してください。ルールの数だけで、どちらが適切かを判断することはできません。

5. 1行ずつ照合できるルール例

以下の例には、特定の例外、拒否対象、ドメインサフィックス、プライベートネットワーク、地域判定、フォールバックが含まれます。順序を説明する例であり、完全な設定ファイルではありません。既存設定の[General]などは残してください。使用前に実際の対象に合わせて調整し、この部分だけで設定ファイル全体を置き換えないでください。

[Rule]
DOMAIN,api.example.com,DIRECT
DOMAIN,telemetry.example.com,REJECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY
  • api.example.com：最初の行に一致してDIRECTが適用され、サフィックスルールは照合されません。
  • telemetry.example.com：2行目に一致してREJECTが適用されます。これは構文を示すための例であり、このドメインの用途について判断するものではありません。
  • www.example.com：最初の2行には一致せず、3行目に一致してPROXYが適用されます。
  • 接続先IPが192.168.1.20の場合：先にドメインルールに一致していなければ、4行目でこのプライベートアドレスに一致します。
  • その他の対象：GEOIPが接続先アドレスをCNと判定した場合はDIRECT、それ以外はFINALに進みPROXYが適用されます。

ドメインサフィックスルールがGEOIPより前にあるため、example.comの一般的なサブドメインには先にPROXYが適用され、接続先IPの地域による判定には進みません。これがルール順序で意図する動作です。ドメインのポリシーを後続の一般的な地域ルールより優先します。別の動作にしたい場合は順序を組み替え、既存の例外に影響しないか確認してください。

6. 新しいリクエストと一致ログで検証する

Webページが表示されたことから分かるのは、今回のアクセスが完了したことだけで、意図したポリシーが適用された証明にはなりません。1つのページが複数のドメインにリクエストを送ることもあります。メインのドキュメントにはDIRECT、静的リソースにはPROXYやREJECTが適用される場合もあります。確認時はHomeの接続スイッチだけを見るのではなく、リクエストログで対象を特定し、一致したルールと最終的なポリシーを確認してください。

  1. 環境を固定：現在のConfig、Global Routing、選択中のプロキシを記録し、テスト中はネットワークとポリシーを同時に切り替えないでください。
  2. 新しい接続を開始：設定を保存してから、新しいテストリクエストを実行します。既存の長時間接続では以前の経路が引き続き使われることがあるため、新しいルールの判定には適しません。
  3. 対象を確認：アドレスバーに表示されたサイト名だけでなく、実際のリクエストの完全なドメインを確認します。
  4. 最初に一致したルールを確認：結果が想定と異なる場合は、一覧の先頭から最初に一致したルールを探します。広範囲のサフィックスや、前に配置されたFINALを特に確認してください。
  5. 経路と接続可否を分けて確認：PROXYが適用されて失敗する場合は、選択中のサービスと名前解決を確認します。DIRECTで失敗する場合は、ローカルネットワークから対象にアクセスできるか確認してください。
  6. 変更は一度に1つ：ルールの位置またはポリシーを1つだけ変更し、保存して再検証します。最後に適用結果を記録してください。

要点：まずルールの一致を確認し、その後に接続失敗を調べる

ログで対象が意図したルールに一致していることを確認できたら、いったん順序の変更を止め、DNS、接続先アドレス、選択中の接続経路を調べます。一致したルールが想定と異なる場合に限り、条件と位置を調整してください。

リモート管理されている設定のルールを使っている場合、更新後にカスタム行が残っているかも確認してください。サーバーの購読情報の更新と設定ルールの更新は別の操作です。「サービス一覧が更新された」ことは、「現在のルールが置き換わった」ことを意味しません。変更前後の内容とテスト対象を記録しておけば、次回の更新後にも同じ動作を再確認できます。

7. よくあるケース：ルールを変えても想定どおりにならない

FINALの後ろにルールを追加しても反映されないのはなぜ？

FINALは、それ以前のルールに一致しなかったすべてのリクエストを処理します。その後にある通常のルールは実行されません。カスタムルールをFINALより前に移動し、さらにその上に対象を含むルールがないか確認してください。

ドメインにDIRECTを指定したのに、リソースがPROXYを通るのはなぜ？

まず、そのリソースが別のドメインにリクエストしていないか確認してください。DOMAINが対象にするのは完全一致のドメインで、DOMAIN-SUFFIXも指定されたサフィックスだけを対象とします。ページが参照する別サイトまで自動的に含まれるわけではありません。実際のリクエストログをもとに個別に判断し、1つのリソースの問題を解決するために対象範囲を広げすぎないでください。

REJECTを適用したらページが真っ白になりました。どうすれば戻せますか？

まず拒否された対象を特定し、該当ルールを一時的に削除するか、バックアップを復元してから、新しいリクエストで再テストします。ログイン、認証コード、静的リソースでは、それぞれ異なるドメインが使われる場合があります。遮断対象と影響範囲を確認してから、REJECTを再度有効にしてください。

ShadowsocksやVMessなどのプロトコルを切り替えると、ルールの優先順位も変わりますか？

接続に使うプロトコルとルールの照合順序は別のものです。プロトコルを変更しても、後ろにあるDOMAINが前のDOMAIN-SUFFIXより優先されることはありません。まずルールにどのポリシーが適用されているかを確認し、次にそのポリシーが使うサービスの接続条件を確認してください。