Shadowrocketに手持ちのサブスクリプションを読み込み、Configを編集する方向けの記事です。まずGlobal RoutingがConfigになっていることを確認し、ルール条件と実行ポリシーを区別します。確認しやすいルール例を使って、完全一致のドメイン、ドメインサフィックス、IP範囲、FINALの配置を説明し、「一致しない」と「一致後も通信できない」という異なる問題を、条件を一つずつ変えて切り分けます。
Global Routingを確認してからConfigを編集する
Shadowrocketでは、Homeで接続や既存のサービスを選択し、Configで設定ファイルを管理し、Settingsでアプリの設定を行います。サブスクリプション項目に含まれるのは接続に必要な情報であり、現在の設定ファイル内のルールとは別です。既存のサブスクリプションを更新しても、編集したルールが有効になるわけではありません。設定ファイルを保存しただけでは、Homeでそのファイルが振り分けに使用されているとは限りません。
確認する場所はHome → Global Routingです。この記事ではConfigモードでのルール判定を扱います。ProxyやDirectをルールとして扱うものではありません。Global RoutingにはSceneもあり、シーンの選択に関係します。この記事の静的ルールを調べる際は、まずConfigに切り替え、シーンの変更による影響を避けてください。
Config
推奨現在有効な設定のルールに従ってポリシーを選択します。この記事のDOMAIN-SUFFIX、IP-CIDR、FINALの例は、Configのルールが適用されることを前提としています。
適した用途：カスタムルールと最終フォールバックの個別検証
Proxy
トラフィックをプロキシ経由で処理します。この記事のカスタムルールに従ってDIRECTやREJECTを個別に選択するモードではありません。プロキシ接続が使えるかを調べる際の比較条件として利用できます。
適した用途：ルールによる振り分けの影響を一時的に切り分ける
Direct
トラフィックを直接接続で処理します。このモードのままでは、Config内のPROXYルールが有効かどうかをアクセス結果から判断できません。
適した用途：ローカルネットワークから直接アクセスした場合の動作確認
ルール行の書式：条件が先、ポリシーが後
一般的なルールでは、フィールドを半角カンマで区切り、設定内の[Rule]セクションに記述します。ドメインルールは通常「タイプ、照合対象、ポリシー」の順です。FINALには照合対象のフィールドがないため、「FINAL、ポリシー」と記述します。全角カンマや説明文をルール行に含めないでください。また、数行追加するためだけに同じファイル内へ複数の[Rule]セクションを作らないでください。
[Rule]
DOMAIN,api.example.com,PROXY
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.168.50.0/24,DIRECT,no-resolve
FINAL,PROXYexample.comはドキュメント用の例示ドメインで、192.168.50.0/24はプライベートネットワークの例です。実際のネットワークでこの範囲が使われているとは限りません。この例はフィールドの構成と順序を説明するものであり、既存の設定を置き換える汎用ルール集ではありません。
| キーワード | 条件の例 | 確認ポイント |
|---|---|---|
DOMAIN | api.example.com | 完全一致するドメインにマッチします。ほかのサブドメインは対象になりません。 |
DOMAIN-SUFFIX | example.com | 指定したドメインとそのサブドメインにマッチします。ワイルドカードのアスタリスクは不要です。 |
IP-CIDR | 192.168.50.0/24 | 宛先のIPv4アドレスが属するネットワーク範囲にマッチします。ドメイン名の文字列を照合するものではありません。 |
GEOIP | CN | 宛先IPアドレスの地理情報データベース上の地域に基づいて判定します。ページの内容で判定するものではありません。 |
FINAL | 条件フィールドなし | それ以前のルールに一致しなかったリクエストを受け持つため、ルールリストの末尾に配置します。 |
DOMAIN-SUFFIXはドメインの境界で照合し、任意の文字列を含むかどうかでは判定しません。たとえばexample.comはwww.example.comにマッチしますが、notexample.comまで対象になるわけではありません。ルールにはhttps://、ページのパス、クエリパラメーターも記述しません。これらはドメインフィールドに含まれないためです。
マッチ順序：例外を先に、広い範囲を後に
ルールは「後から書いたものが前のルールを上書きする」わけではなく、長い条件や詳細な条件が自動的に優先されることもありません。ルール判定の対象となるリクエストは、Shadowrocketが上から順に確認し、最初に一致したルールのポリシーを適用します。そのため、範囲の広いルールに含まれる個別の例外は、広いルールより前に配置する必要があります。
[Rule]
DOMAIN,api.example.com,PROXY
DOMAIN-SUFFIX,example.com,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXYapi.example.com：1行目のドメインルールに一致するため、PROXYが適用されます。後続のサフィックスルールによってDIRECTに変更されることはありません。www.example.com：1行目には一致せず、2行目に一致するため、DIRECTが適用されます。- それ以外の宛先：GEOIPを引き続き確認し、条件に一致しなければ最後にFINALのPROXYが適用されます。
DOMAIN-SUFFIXをDOMAINより前に置くと、api.example.comは先にサフィックスルールに一致し、後ろにある完全一致の例外は実行されません。同様に、幅広い範囲を対象にするルールセットを個別の例外より前に置くと、その例外が機能しないことがあります。調べるときは、対象のルールが「存在する」ことだけでなく、それより前のルールも確認してください。
PROXY、DIRECT、REJECT、FINALの役割
ルールタイプは「何に一致させるか」を、ポリシーは「一致した後にどう処理するか」を表します。ここで使うポリシーはPROXY、DIRECT、REJECTです。一方、FINALは追加の照合条件を持たないフォールバック用のルールタイプです。この二つを区別すれば、FINALを新しい通信プロトコルと誤解することはありません。
PROXY- 一致したリクエストをプロキシ経由で処理します。実際の接続先は、現在の選択内容と設定内のポリシーの関係も確認してください。PROXYと記述するだけで利用可能なサービスが用意されるわけではなく、認証情報の誤りも解消されません。
DIRECT- プロキシ経由にせず、現在のネットワークから宛先へ直接アクセスします。直接接続の可否は、ローカルネットワーク、DNS、宛先のサービスが到達可能かどうかに左右されます。すべてのネットワーク制限を回避できるという意味ではありません。
REJECT- 一致したリクエストを拒否します。明確に不要な宛先をブロックするテストに適していますが、範囲が広すぎるとログイン、画像、アプリのAPIにも影響する場合があります。必ず元に戻す方法を用意してください。
[Rule]
DOMAIN,blocked.example.com,REJECT
DOMAIN-SUFFIX,example.com,DIRECT
FINAL,PROXYこの例では、まずblocked.example.comを拒否し、同じサフィックスに属するほかのドメインは直接接続、それ以外のリクエストはPROXYで処理します。FINALを1行目に置くと、このルールまで到達するリクエストがすべて先に処理され、後続のドメインルールは判定されません。
IP-CIDR、GEOIP、DNS：アドレスの取得元を区別する
ドメイン条件とIP条件では、使用する情報が異なります。DOMAIN-SUFFIXはドメインを、IP-CIDRとGEOIPは宛先アドレスを対象にします。ドメインはあるものの利用可能な宛先IPがまだないリクエストでは、IP系ルールの判定にDNS解決が関係することがあります。ドメインルールに一致しなかったからといって、ネットワーク範囲の記述ミスだと決めつけないでください。
IP-CIDR,192.168.50.0/24,DIRECT,no-resolve
IP-CIDR,192.168.50.10/32,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY上の2つのIP-CIDRは、ネットワーク範囲と単一アドレスの違いを示しています。1行目は192.168.50.10をすでに含むため、同じポリシーなら通常2行目を残す必要はありません。この単一アドレスに別のポリシーを適用する場合は、後から追加するのではなく、/32の例外を/24のルールより前に移動してください。
no-resolveは、このIPルールのためだけに追加のドメイン解決を行わないことを意味します。アプリ全体のDNSを無効にする設定でも、リクエストに宛先IPがなくなるという意味でもありません。- リクエストに利用可能な宛先IPがすでにあれば、そのアドレスでネットワーク範囲を判定できます。宛先IPがなく、ルールもDNS解決を行わない場合、ドメイン情報だけでIP照合されることはありません。
GEOIP,CN,DIRECTは、IPの地理情報データベースに基づいて判定します。CDNの振り分け、DNSの応答、データベース上の地域情報によって結果が変わることがあり、中国語のページであることは一致条件ではありません。- ドメインへのアクセスでは、IPv6にも注意が必要です。IPv4のIP-CIDRルールがIPv6アドレスを自動的に対象にすることはありません。宛先でIPv6が使われている場合は、対応するIPv6ルールも確認してください。
ルールで照合できるのは、実際に取得できるリクエスト情報だけです。アプリがIPアドレスに直接接続し、関連付けられるドメイン情報がない場合、ドメインルールに一致しないことがあります。広範囲のDOMAIN-SUFFIXを増やすより、実際の宛先ドメインやアドレスを記録して確認しましょう。
変更と検証：一度に変える条件は一つだけ
現在使える設定を残したうえで、小さな範囲から変更します。リモート設定とローカルコピーを区別してください。リモートの内容を更新すると、ローカルでの変更が上書きされることがあります。通常、既存のサブスクリプションの更新で処理されるのは接続項目であり、更新が成功してもカスタムルールが有効になった証拠にはなりません。テスト前に、既存のプロキシ接続が使えることも確認してください。
-
元のファイルを残す
Configを開き、現在使用中の設定を確認して、復元できるコピーを残します。リモート配信元の内容を変更する場合は、次回の更新でテスト用ルールが上書きされないよう、編集可能なローカルコピーを先に用意してください。
-
ルールセクションを編集する
Configでテストするファイルの内容を開き、[Rule]を探します。単一ドメインの例外を該当するサフィックスルールより前に置き、FINALが末尾にあることを確認します。保存したら、その設定を選択してください。
-
振り分けを確認する
Home → Global Routing → Configに戻ります。現在のプロキシ選択を確認し、Proxy、Direct、Sceneのほかの動作が今回のルールテストに影響しないようにしてください。
-
リクエストを再実行する
対象のページを閉じてから開き直し、必要に応じて接続も確立し直します。既存の長時間接続が再利用される影響を抑えられます。各テストで変更するのは、ルールの順序かポリシーのどちらか一つだけにし、DNSやプロキシの設定を同時に変更しないでください。
-
記録して元に戻す
宛先、適用されたルール、ポリシー、アクセス時の状況を記録します。現在利用できるリクエスト記録と照合してください。結果が想定と異なる場合は元の設定に戻し、同じ宛先で再テストします。
テスト記録では、「実際に確認した結果」と「想定される動作」を分けて記載してください。たとえば、自分が管理するテスト用ドメインを一時的にREJECTに設定した場合、該当リクエストが拒否されることが想定されます。それでもページに内容が表示されるなら、ルールシステム全体の不具合と結論づける前に、キャッシュ、別のドメイン、既存の接続を確認してください。この記事のルール例は、お使いのネットワークでテストした結果を示すものではありません。
よくある問題：マッチ結果から原因を特定する
DOMAINを追加したのにDIRECTになるのはなぜ？
まずHome → Global RoutingでConfigが選択されていることを確認し、次にConfigで実際に使用中のファイルを確認します。そのうえで、より前にあるDOMAIN-SUFFIX、IP系ルール、ルールセットが先に一致していないか調べます。完全一致の例外は、それを含むルールより前に移動し、保存後にリクエストを再実行してください。
FINALをPROXYにしているのに、一部のリクエストが直接接続になるのはなぜ？
FINALが受け持つのは、それ以前のルールに一致しなかったリクエストだけです。対象がDOMAIN-SUFFIXやGEOIPなどのDIRECTルールにすでに一致していないか確認してください。FINALを先頭に移動するのではなく、実際に一致しているルールを変更するか、その前に範囲の狭い例外を追加します。
PROXYに一致しても開けない場合、順序を変えるべき？
PROXYに一致している場合は、まず現在のプロキシ、認証情報、宛先ポート、DNSを確認してください。比較のため、一時的にHome → Global Routing → Proxyを試すこともできます。テスト後はConfigに戻してください。ポリシーの実行失敗とルールの不一致は、別々に切り分ける必要があります。
REJECTを追加したらアプリ全体に問題が起きました。どう戻せばいい？
Configで追加したルールを削除するか、バックアップを復元してから接続を再確立してください。その後、実際のリクエスト先ドメインに合わせて照合範囲を狭め、まずDOMAINで単一の宛先を検証します。共有サフィックス全体や広範囲のネットワークをまとめて拒否しないでください。
最終確認の順序は固定しておきましょう。現在の設定が正しいか、Global RoutingがConfigか、最初に一致したルールは何か、そのポリシーを実行できるかの4点です。これらを確認してからルールの範囲を広げてください。明確な復旧手順を保てるため、設定の選択や接続パラメーターの問題を大量の重複ルールで覆い隠さずに済みます。