Shadowrocketの設定ファイル「.conf」構造ガイド：General・Rule・Host・URL Rewriteの役割

.confの役割と適用箇所を確認する

Shadowrocketの.confはテキスト形式の設定ファイルです。角括弧でセクション名を示し、各セクションでは対応する種類の設定だけを扱います。[General]には通常、キーと値の組み合わせを記述し、[Rule]にはルールを1行ずつ記述します。同じ行形式をすべてのセクションに流用することはできません。拡張子が正しくても、すべての設定項目が有効とは限りません。

読み始める前にConfigで現在選択中の設定ファイルを確認し、Home → Global Routingでルーティングモードを確認します。ファイル内の振り分けルールを検証するには、Configを使用してください。ProxyまたはDirectでは、実際の通信結果だけを見て[Rule]の記述が正しいか判断できません。Sceneを使う場合は、シーンに実際に関連付けられている設定も確認しましょう。

接続情報と振り分け設定は別のものです。既存のサブスクリプションを更新しても、主に更新されるのは該当する接続情報であり、ローカルの.confも同期して変更されたとは限りません。また、リモート設定ファイルの更新によってローカル編集が上書きされる場合があります。試す前に元ファイルを保存し、コピー上で項目ごとに変更してください。

General：キーと値で全般の動作を設定

[General]ではkey = value形式で記述します。まずキー名を確認し、次に値の種類を確認しましょう。真偽値を指定する項目もあれば、アドレスやリストを指定する項目もあります。等号やカンマを全角の記号に置き換えたり、このセクションにルール行を記述したりしないでください。以下は互いに独立した設定例で、あらゆるネットワークで推奨される値を示すものではありません。

[General]
dns-server = system
ipv6 = false

dns-server = systemはシステムのDNSを使用する設定ですが、あらゆるネットワーク環境で名前解決が正常に行われることを保証するものではありません。ipv6 = falseはIPv6に関する全般設定であり、ドメイン振り分けルールではありません。また、サーバーへのIPv6接続確認の代わりにもなりません。問題が起きたら元の値を残して比較し、DNSの変更、IPv6の調整、ルール順の変更を同時に行わないでください。

Rule：先に一致したルールを適用し、FINALは末尾に置く

[Rule]で重要なのはルールの数ではなく、並び順です。通常のルール行は、種類、照合対象、ポリシーで構成されます。FINALには照合対象が不要です。先にあるルールが一致すると、同じリクエストに対して後続のルールでポリシーが再選択されることはありません。そのため、具体的な例外は広い条件より前に配置します。

[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

例に使われている192.0.2.0/24はドキュメント用のアドレス範囲で、利用可能なサービスのアドレスではありません。DIRECTは直接接続、PROXYはプロキシ経由の接続先を示します。カスタムポリシー名を使う場合は、現在の設定でその名前が定義されていることを確認してください。名前が似ていても同じポリシーとは限らず、プロトコル名をそのまま既存のポリシーとして扱うこともできません。

Host：名前解決のマッピングを変更し、リクエスト先は変更しない

[Host]では、ドメイン名に対するローカルの名前解決マッピングを指定します。一般的な形式はドメイン名 = IPです。変更するのは「この名前をどのアドレスに解決するか」であり、「通信をどの経路で送るか」ではありません。ドメイン名を固定アドレスに割り当てても、実際のルーティング設定に従ってリクエストが送信されます。

[Host]
lab.example.com = 192.0.2.10

• キーにはドメイン名を指定：lab.example.comのように記述します。https://やパスを含む完全なURLは指定しないでください。
• 値にはアドレスを指定：ここにある192.0.2.10は構文の説明用です。実際に使う場合は、自分に使用権限があり、接続可能なアドレスに置き換えてください。
• ポートは変更されない：元のリクエストがHTTPSの既定ポート443を使う場合、Hostのマッピングだけでは8443に変更されません。
• 証明書のドメイン名は変更されない：HTTPSでは引き続き、元のドメイン名に対応する証明書が検証されます。別のサーバーにマッピングしても、証明書の検証に通るとは限りません。

トラブルシューティングでは、「ドメイン名が正しく解決されない」場合と「接続先に接続できない」場合を区別します。アプリがIPアドレスへ直接接続する場合や、独自の名前解決方法でアドレスを取得する場合は、Hostのマッピングだけでリクエストに適用されると判断できません。変更後にリクエストを再実行し、必要に応じて既存の接続を切ってからテストします。古い接続の再利用による結果を、新しい設定の結果と取り違えないようにしてください。

URL Rewrite：正規表現でリクエストURLを照合

[URL Rewrite]では、アプリが認識できるHTTPリクエストURLを処理します。以下の例では、正規表現で特定のHTTP URLに一致させ、302でリダイレクトします。照合式、転送先URL、アクションの3つを空白で区切ります。Ruleのカンマ区切り形式とは異なります。

[URL Rewrite]
^http://example\.com/guide$ https://example.com/guide 302

1. ^は文字列の先頭を指定し、URLの途中にある似た文字列への誤一致を防ぎます。
2. example\.comでは、バックスラッシュによってピリオドを文字として指定しています。正規表現でエスケープしないピリオドは、ほかの文字にも一致します。
3. /guide$はパスの末尾を指定します。クエリパラメータを含む/guide?from=testは、この完全な式には一致しません。
4. 302はリダイレクトのアクションを示します。クライアントがリダイレクトに従うかどうかは、リクエストを送信したアプリで確認してください。

この例を「HTTPSならどのURLでも直接書き換えられる」と解釈しないでください。通常の暗号化トンネルから分かるのは接続に必要な情報であり、HTTPSのパス全体を扱えるわけではありません。HTTPSの内容を照合するには、MITM、対象ホストの範囲、証明書の信頼設定、アプリ側の制約が関係します。この例は暗号化されていないHTTPリクエストを対象としており、復号範囲を広げる必要はありません。

4つのセクションを組み合わせる：変更は一度に1つずつ検証

4つのセクションをすべて有効にする必要はありません。ドメインの振り分けだけが必要なら、まずGeneralとRuleを設定します。固定の名前解決が不要ならHostを追加する必要はなく、URLの書き換えが明確に必要でなければURL Rewriteも追加しません。出所不明の設定を多数追加するより、必要な設定だけに絞るほうが問題を特定しやすくなります。

1. 基準となる状態を残す：Configで元の設定を保持し、現在のHome → Global Routingの選択内容と、変更前にアクセスできたテスト先を記録します。
2. まずルールを変更：特定のドメインを対象にするルールを1つだけ追加します。保存して変更後の設定を選択し、ルーティングモードをConfigにしてテストします。
3. 次に名前解決を確認：固定アドレスが本当に必要な場合のみHostを追加します。対象ドメイン、想定IP、ポートを記録し、名前解決の問題と接続エラーを区別してください。
4. 最後に書き換えを検証：明確なHTTPパスで正規表現を確認します。複数の条件が混ざらないよう、HTTPSの復号設定は同時に追加しないでください。
5. 確認内容を記録：アプリで利用できるリクエストログを確認し、ドメイン、一致したルール、実際のポリシーを照合します。失敗した場合は直前に変更した項目だけを元に戻し、同じリクエストを再度実行してください。

Settings → On Demandはオンデマンド接続の動作を制御するもので、ルールの構文を修正する機能ではありません。手動で切断しても自動的に再接続する場合は、ここで接続を開始する条件を確認してください。それだけで.confが保存されていないと判断する必要はありません。テスト中は接続方法を一定に保ち、同じルールの変更前後を比較しましょう。

よくある質問：保存できても期待どおりに動かない理由