Shadowrocketの.conf設定を攻略｜ルール優先順位と分流の実践例

1. .confの構造と編集前に確認すること

.confは、設定項目をセクションごとに記述するテキスト形式の設定ファイルです。よく見るセクションには、共通設定の[General]、サーバー定義の[Proxy]、選択ポリシーの[Proxy Group]、通信ルールの[Rule]があります。ほかに、ドメインとIPの対応を記述する[Host]、URL書き換えを扱う[URL Rewrite]、MITMやスクリプト関連のセクションが含まれる場合もあります。ファイルごとに構成は異なり、すべてのセクションが必須というわけではありません。

編集を始める前に、Configで現在選択されているファイルを確認し、複製またはエクスポートして戻せる状態にします。Subscribeから取得したリモート設定を直接変更すると、次回の更新で変更が置き換わることがあります。自分で管理するローカルファイルなのか、サービス提供元から更新されるファイルなのかを先に区別してください。接続サービスとサブスクリプションは利用者自身が用意するもので、アプリの買い切り購入に含まれるものではありません。

以下は構造を読むための短い例です。実際に利用するには、使用中の設定に必要なサーバーやポリシー定義が別途必要です。例の内容で既存ファイル全体を置き換えないでください。

[General]
# 共通設定を記述するセクション

[Proxy]
# 接続先の定義。既存ファイルの内容を保持する

[Proxy Group]
# ルールから参照するポリシーを定義

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

2. ルール優先順位とFINALの読み方

[Rule]のルールは、マッチ条件と処理ポリシーを組み合わせて記述します。たとえばDOMAIN-SUFFIX,example.com,DIRECTは、example.comとそのサブドメインにDIRECTを適用する例です。DOMAINは指定したホスト名そのものを対象にし、IP-CIDRはIPアドレス範囲を対象にします。ドメインルールはURLのパスにはマッチしないため、ページ内の特定の画像だけを狙う指定ではありません。

通常のルールは上から順に評価され、最初に一致したルールのポリシーが使われます。広い範囲に一致するルールを上に置くと、その下にある個別ルールまで到達しないことがあります。FINALは、それ以前のルールに一致しなかった通信を処理するためのフォールバックです。テスト中のルールを一番下に置いていても、その前のルールに一致すればテスト対象になりません。

例外を先に、対象範囲の広いルールを後にするのが読みやすい構成です。たとえば特定ホストだけPROXYにし、ドメイン全体はDIRECTにする場合、ホスト指定を先に書きます。ポリシー名は、設定内に定義された名前と正確に一致している必要があります。名前の大文字・小文字や記号を変えた場合も含め、ルールだけでなく参照先を確認してください。

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

3. 遠隔ルールセットを使うときの設計

遠隔ルールセットは、ルール群を別の取得元から読み込む仕組みです。ローカルの[Rule]に多数の行を貼り付けずに管理できる一方、取得元への接続、ファイルの形式、更新後の内容に依存します。ルールセットを追加する際は、使用中の設定が対応する形式と構文を確認し、利用するポリシー名がConfig内に存在することを確かめてください。設定ファイルに記載された取得先が信頼できるものかも確認が必要です。

ルールセットの行は、通常のドメインルールと同様に配置順が重要です。上位に広範囲のルールセットがあり、対象ドメインがそこで先に処理されると、後ろに書いた個別ルールで期待する変更ができない場合があります。逆に、個別の例外をルールセットより先に置けば、その例外を優先できます。対応する構文は設定の書式やアプリの仕様に従い、サンプルの行を無検証で貼り付けないでください。

更新後に通信結果が変わった場合は、まずルールセットの取得時刻や変更内容を確認し、次に該当ドメインがどの条件に一致するかを追います。取得元の内容を確認できない、または記述形式が不明な場合は、安易に有効化せず、元に戻せる複製を保管してから検証してください。サブスクリプションのURLや認証情報が含まれる設定を、公開の場所へ貼り付けることも避けましょう。

4. Configを編集して動作を確認する手順

設定変更の結果を判定するには、同じネットワーク、同じ接続先、同じGlobal Routingを保って比較します。テスト中にサーバーやDNS、ルールを同時に変えると、どの変更が結果に影響したか分かりにくくなります。まずConfigで選択中のファイルとHomeの接続状態を記録し、変更対象を1つに絞りましょう。

1. ファイルを複製

   Configで対象ファイルを確認し、複製またはエクスポートして元の状態を残します。リモート設定なら、更新でローカル変更が失われる可能性も考慮してください。

2. 変更箇所を絞る

   まずは[Rule]の1行、またはルールセットの配置だけを変更します。変更前後の行を記録し、他の設定項目は同時に編集しないでください。

3. 接続条件を固定

   Homeで現在のサーバーと接続状態を確認し、Global RoutingがConfigになっているかを見ます。別のルーティング設定やSceneを使用している場合は、実際に適用中の状態も確認します。

4. 同じ通信を再試行

   対象ドメインを新しいリクエストで開き、必要なら接続を再確立してから確認します。既存の接続が残っていると、ルール変更がすぐに観察できないことがあります。

5. 結果を記録して戻す

   成功・失敗、表示されたエラー、使用したルールを記録します。予想と異なる場合は、先行ルール、ポリシー名、ファイルの選択状態を確認し、原因が分からなければ複製前の設定に戻します。

設定ファイルの編集画面や保存操作の表示は、実際の画面に従ってください。ファイルを保存しただけで、現在使用中のConfigに切り替わったとは限りません。編集後はConfigで選択状態を再確認し、変更したファイルが有効になっていることを確かめます。テストに使ったドメインが例示用のexample.comなら、実際のサービスを判定する材料にはなりません。

5. MITM証明書と外部スクリプトの注意点

MITMは通信を仲介して内容を確認・処理するための機能で、通常のルールによる接続先の振り分けとは目的が異なります。HTTPS通信の内容を扱うには、対象端末側で証明書を設定し、必要な信頼設定を行う場合があります。証明書を信頼させる操作は、通信を検査できる範囲に関わるため、意味を理解していない証明書をインストールしたり、目的を確認せずに信頼を有効にしたりしないでください。

MITMを有効にしても、すべてのアプリや接続を正常に処理できるわけではありません。証明書ピンニングなど、アプリ側の仕組みによって接続が成立しないことがあります。必要な対象と目的を限定し、検査が終わったら不要な設定を解除します。機密情報を扱うアプリでの影響を把握できない場合は、MITMを有効にしない選択が安全です。

外部スクリプトは、設定や通信に対してコードを実行するため、取得元と内容の確認が重要です。スクリプトのURLを登録するだけでは安全性は保証されません。更新によってコードが変わる可能性があり、実行環境や権限の範囲によってはプライバシーやアカウント情報に影響するおそれがあります。必要性が明確で、内容と提供元を確認できるものに限って扱い、不要になったら設定から削除してください。

設定ファイルは、接続を成立させるだけでなく、通信をどの条件でどこへ振り分けるかを決める重要なデータです。まずバックアップを作り、ルールの対象範囲と優先順位を読んでから変更し、1回のテストで1つの要因だけを確かめると、原因を追いやすくなります。MITMやスクリプトは便利さだけで判断せず、権限、取得元、解除方法まで確認したうえで必要最小限に利用してください。