Shadowrocketでカスタムルールを有効にするには、まずGlobal Routing、次に現在の設定ファイル、最後にルールの順序を確認します。ご自身の接続設定がある方向けに、予約済みドメインとドキュメント用のIPアドレス帯を使って、ルールの書き方やフォールバック、確認方法を解説します。例は構文を理解するためのもので、そのまま日常の設定に置き換えられる完成済みの設定ではありません。
ルールを編集する前にGlobal Routingを確認
ルールを変更する前に、Home → Global Routingで現在の選択項目を確認してください。現在の設定ファイルに記述されたルールで通信を振り分けるには、Configを選択します。ProxyまたはDirectになっている場合、現在のファイルのルールを1つずつ評価して接続先を決める動作ではないため、ルールの順序を変更しても期待した結果にならないことがあります。
Config
おすすめ現在有効な設定のルールに従って接続方法を選択します。直接接続、プロキシ経由、拒否のいずれになるかは一致したルールによって決まり、「一致しなければ直接接続」とは限りません。
用途：カスタムルールの作成・確認・日常利用
Proxy
アプリに処理を委ねた接続を、全体的にプロキシ経由にします。プロキシ接続が使えるかを比較する際に利用できますが、この状態での結果から特定のルールに一致したとは判断できません。
用途：プロキシ経由とルールによる振り分けを一時的に比較
Direct
アプリに処理を委ねた接続を、直接接続にします。DirectはシステムのVPN設定をオフにすることでも、現在の設定ファイルを削除することでもありません。
用途：現在のネットワークから接続先へ直接接続した場合の結果を比較
Global RoutingではSceneを使う場合もあります。Sceneはシーンの選択に関係するため、この記事の例を確認する際は、Sceneの変更とルールの変更が混同しないよう、まずConfigに切り替えてください。また、同じConfigという名称でも、Global RoutingのConfigは動作モード、画面下部のConfigは設定ファイルを管理する場所を指します。ファイルが一覧に表示されていても、現在使用中とは限りません。
ルールの構文：条件を先に、ポリシーを後に
設定ファイルのルールは[Rule]セクションに記述します。一般的な条件ルールは「タイプ、照合値、ポリシー」で構成され、各項目は半角カンマで区切ります。全角カンマやポリシー名への余分なスペース、別のセクションへの記述は、解析や照合が想定どおりに行われない原因になります。次の4つのキーワードを確認しましょう。
| キーワード | 例 | 確認ポイント |
|---|---|---|
DOMAIN-SUFFIX | DOMAIN-SUFFIX,example.com,PROXY | example.com本体とサブドメインに一致します。URLのパスは指定しません。 |
IP-CIDR | IP-CIDR,192.0.2.0/24,DIRECT | IPv4アドレス範囲に一致します。/24は先頭24ビットがネットワークプレフィックスであることを示します。 |
GEOIP | GEOIP,CN,DIRECT | 接続先IPアドレスの地理情報データベース上の所属で判定します。ドメイン名の文字列による判定ではありません。 |
FINAL | FINAL,PROXY | 照合値を指定せず、それ以前の条件に一致しなかった通信を処理します。 |
DOMAIN-SUFFIX,example.com,PROXYはapi.example.comに一致します。一方、別のドメイン名の末尾に文字列「example.com」が含まれているだけでは一致しません。ドメインの階層が区別されます。https://example.com/pathや、照合値に:443を指定しないでください。このルールはドメイン名で照合し、ウェブページのパスやポートでは判定しません。
IP-CIDRとGEOIPは、接続先IPアドレスの情報を利用します。ドメインへの接続時に名前解決が行われるか、いつIPアドレスで判定するかは、設定内のDNSやルールオプションにも左右されます。GEOIPの結果はウェブサイト運営者の所在地を示すものではありません。また、同じドメインが常に同じIPアドレス範囲に解決されるとは限りません。
上から順に評価：具体的な例外を先に記述
ルールは上から順に評価され、一致するとそのルールのポリシーが適用されます。後続の「より適切な」ルールを探すことはありません。ドメインの後方一致部分が長いルールや、より小さいIPアドレス範囲が自動的に優先されることもありません。そのため、具体的な例外、広い範囲を対象にする条件、最後にフォールバックの順で記述します。
[Rule]
DOMAIN-SUFFIX,api.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,PROXYこの例では、api.example.comとそのサブドメインは最初のルールに一致して直接接続され、www.example.comは2番目のルールに一致します。最初の2つのルールを入れ替えると、api.example.comは広い範囲を対象とするexample.comの条件に先に一致し、PROXY経由になります。下にあるDIRECTの例外ルールは、この判定では適用されません。
IPアドレス範囲も同じ順序で評価
[Rule]
IP-CIDR,192.0.2.128/25,REJECT,no-resolve
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
FINAL,PROXY192.0.2.128/25は192.0.2.0/24に含まれます。接続先IPが分かっている場合、192.0.2.130は先にREJECTに一致し、192.0.2.20は次のルールまで評価されてDIRECTに一致します。この2つを入れ替えると、範囲の広い/24が先に全体を対象にするため、REJECTの例外が適用されなくなります。
PROXY・DIRECT・REJECTとFINALの関係
最初の3つは「一致した接続をどう処理するか」を示し、FINALは「それまでのルールに一致しなかった場合の処理」を示します。同じ種類の照合条件ではありません。特にFINAL,PROXY自体にはドメインや地域による判定が含まれないため、前の方に置くと後続のルールに到達しなくなります。
- PROXY：プロキシ経由で処理します。接続できるかどうかは、現在選択しているプロキシ、または設定から参照されるポリシーが利用可能かにも左右されます。PROXYと記述しただけで接続先が用意されるわけではありません。
- DIRECT：選択中のプロキシサーバーを経由せず、接続先に直接接続します。接続先に到達できるとは限らず、接続先のサービス、DNS、ローカルネットワークも結果に影響します。
- REJECT：一致した接続を拒否します。ウェブページでは、リソースの欠落や読み込みエラーとして表示される場合がありますが、アプリの不具合とは限りません。
- FINAL：ルールの末尾に置き、それまでに一致しなかった通信を処理します。一般的な書き方は
FINAL,PROXYまたはFINAL,DIRECTです。どちらを使うかは、明確な振り分けの目的に応じて決めてください。
指定したドメインだけをプロキシ経由にし、それ以外は直接接続する場合は、すべてのルールを確認したうえでFINAL,DIRECTを使います。指定していない接続先もプロキシ経由にする場合はFINAL,PROXYを使います。要件を問わず使える共通の正解はありません。FINALを変更すると、それ以前のルールに一致しないすべての接続先が変わるため、影響範囲はドメインルールを1つ追加する場合より大きくなることがあります。
[Rule]
DOMAIN-SUFFIX,blocked.example.com,REJECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECTこの例では、特定のサブドメインを先に拒否し、それ以外のexample.comのドメインはプロキシ経由、その他の接続先は直接接続にしています。3種類の処理を組み合わせる方法を示したもので、プライバシー保護やネットワークアクセスのための完全な設定ではありません。ご自身の設定に追加する前に、必要な既存ルールを残し、参照するプロキシポリシーが現在の設定と一致しているか確認してください。
変更と検証：一度に変更するのは1項目
現在使用中の設定をそのまま上書きしないでください。元のファイルを残し、複製したファイルを編集します。リモート更新されるファイルの場合は、今後の更新でローカルの変更が上書きされる可能性も考慮してください。操作手順は次のとおりです。画面に表示されるファイル名は、実際に保存した名前を確認してください。
動作モードを確認
Home → Global Routing → Configを開き、現在選択されているプロキシを記録します。DNS、プロキシの選択、On Demandは同時に変更しないでください。
元のファイルを残す
画面下部のConfigを開き、現在有効なファイルを確認します。編集前にファイル操作で複製を作成するか、バックアップをエクスポートして、元に戻せる状態を保ちます。
ルールを変更
Configで編集するファイルを開き、
[Rule]セクションを探します。例外ルールを1つ追加するか、2つのルールを入れ替えるだけにして、末尾のFINALは残します。保存後、変更したファイルが使用中であることを確認してください。接続をやり直す
Homeに戻って接続状態を確認し、対象アプリで以前のリクエストを終了してから、新たに接続します。テキストを変更しただけでは、既存の長時間接続は自動的に新しい接続へ切り替わりません。
接続ログを確認
Dataで該当時刻の接続ログを確認し、接続先のドメインまたはIPアドレス、照合されたルール、実際に適用されたポリシーを照らし合わせて判断します。テスト対象と変更前後の結果を記録し、ウェブページが開くかどうかだけで判断しないでください。
たとえばドメインの例外を確認する場合は、例外となるサブドメインと一般的なサブドメインをそれぞれ確認します。FINALを検証する場合は、それ以前の条件に該当しないことが明確な接続先を選んでください。ご自身のテスト用サービスを使う場合、HTTPSで一般的なポートは443、HTTPでは80です。この記事のドメインサフィックスルールは、これらのポートによって通信を振り分けるものではありません。
接続できないことだけでは、ルールが機能していないとは判断できません。PROXYに一致してもプロキシ経由で接続できない場合、DIRECTに一致してもローカルネットワークから接続できない場合、REJECTに一致してリクエストが拒否された場合は、いずれも似たようなページエラーになることがあります。「想定した条件に一致したか → 想定したポリシーが適用されたか → その経路で接続できるか」の順に確認し、ページの表示結果からルールを推測しないでください。
よくある質問：ルールを設定したのに結果が変わらない
ルールを変更しても、すべての接続先がプロキシ経由になるのはなぜ？
まずHome → Global RoutingでProxyが選択されていないか確認し、次にConfigで現在有効なファイルを確認してください。Configを使用している場合は、最初のルールから順に確認し、条件の範囲が広すぎて先に一致していないか、FINALが例外ルールより前に置かれていないかを調べます。
DIRECTを下に置いたのに、上のPROXYより優先されないのはなぜ？
後から書いたルールが先のルールを上書きするわけではありません。より具体的なDIRECTの条件を、それを含むPROXYの条件より前に移動し、保存してから新しい接続を開始してください。リスト上の表示名だけを変更したのではなく、ルールの順序を変更したことも確認しましょう。
IP-CIDRを追加したのに、ドメインへの接続が一致しないのはなぜ？
実際の接続先IPアドレスが指定範囲に含まれているか、no-resolveを使用しているかを確認してください。ドメインが複数のアドレスを返す場合や、IPv6を使う場合もあります。IPv4のIP-CIDRの例ではIPv6を対象にできません。ドメイン名による振り分けが目的なら、ドメイン条件を明示して指定してください。
更新後に追加したルールが消えた場合は？
まずConfigで、更新されたものがリモート設定ファイルか別の項目かを確認し、バックアップと比較します。サブスクリプション内のサーバー一覧と、設定ファイル内のルールは別のデータです。ローカルで変更したファイルを別途保存し、復元後に有効なファイルを再確認してください。リモートの内容で上書きされるファイルを繰り返し編集しないようにしましょう。
接続を切っても自動的に再接続するのはなぜ？
Settings → On Demandを開き、オンデマンド接続の条件を確認してください。On Demandは接続を確立するタイミングを管理するもので、[Rule]の逐次評価を置き換えるものではありません。まず接続状態を一定にしてから、Global Routingとルールを確認すると、異なる2つの動作を混同せずに切り分けられます。
目的が分かる最小限の変更だけを残しましょう。具体的な例外を先に、範囲の広い条件を後に置き、FINALは末尾にします。検証のたびに、動作モード、有効なファイル、接続先、適用されたポリシーを記録してください。ルールを増やせば精度が上がるとは限りません。それぞれのルールが何を対象とし、なぜその位置にあるのか説明できる状態にしておくと、後から管理しやすくなります。画面や接続に関する用語は用語集をご覧ください。問題が続く場合はトラブル対処を確認してください。