Shadowrocket .conf設定ファイルの構成：General・Rule・Host・URL Rewriteの書き方

1. 設定ファイル・サーバー・動作モードを区別する

.confはテキスト形式の設定ファイルです。通常、セクション名は単独の行に記述し、次のセクション名が現れるまで、後続の項目はそのセクションに属します。[General]にはキーと値の設定、[Rule]には1行につき1つのマッチルールを記述します。この2つの構文は互換性がありません。dns-server = systemを[Rule]に置いても、有効なドメインルールにはなりません。

Homeではサーバーの選択、接続の制御、Global Routingの確認を行います。Configでは設定ファイルを管理・選択し、Settingsではアプリの設定を変更します。サーバー項目は「どの出口を経由して接続するか」を指定し、設定ファイルは「リクエストごとにどのポリシーを適用するか」を指定します。サーバーサブスクリプションの更新が成功していても、Configで意図したルールファイルが選択されているとは限りません。

[Rule]を検証するには、Home → Global RoutingでConfigを選択します。ProxyとDirectは全体の動作モードであり、個々の設定ルールがマッチしたかどうかを判断するためのものではありません。Sceneは選択中のシーン設定に従って動作するため、トラブルシューティングではシーンで使用されている設定も確認してください。まずConfigに固定すると、動作モードの変化による影響を減らせます。

2. [General]：内容を把握できる全般設定から始める

[General]ではキー = 値の形式を使います。次の設定はテスト用の設定ファイルに記述できます。dns-server = systemはシステムが提供するDNSを使用します。bypass-systemとskip-proxyは、システムや指定アドレスを経由しない動作に関わる設定です。接続速度を上げる汎用スイッチとして扱わないでください。

[General]
dns-server = system
bypass-system = true
skip-proxy = 127.0.0.1, 192.168.0.0/16

127.0.0.1はループバックアドレス、192.168.0.0/16はプライベートアドレス範囲です。この例では2つの範囲だけを示しており、すべてのローカルネットワークを網羅するものではありません。LANで別のネットワーク範囲を使用している場合は、ネットワークアドレスとアクセス先を先に確認してください。広すぎる範囲をそのまま除外し、後続のルールで補う方法は避けましょう。

「追加」を意図して同じセクションに同じキーを何度も記述しないでください。重複項目の扱いはパラメータによって異なるため、整理する際は明確な値を1つだけ残します。DNSを変更する前に元の値も記録してください。ドメインの名前解決失敗とプロキシのハンドシェイク失敗は別の問題です。サーバーを変更しても、誤ったDNS設定が自動的に修正されるわけではありません。

3. [Rule]：個別ルールを先に、FINALを最後に

Configモードでは、ルールは記述順に確認され、最初にマッチした項目のポリシーが適用されます。次の例では、完全一致ドメイン、ドメインサフィックス、アドレス範囲、地域判定、フォールバックルールを順に示します。example.comとexample.orgは構文の説明用です。ルールにサーバーアドレスやサブスクリプションの認証情報は含まれていません。

[Rule]
DOMAIN,blocked.example.com,REJECT
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-SUFFIX,example.org,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

• DOMAINは指定したドメインに完全一致します。そのため、ここではblocked.example.comが後続のサフィックスルールではなく、先にREJECTにマッチします。
• DOMAIN-SUFFIX,example.com,PROXYは指定したドメインとそのサブドメインにマッチします。WebページのURLパスは照合しません。
• IP-CIDRは接続先IPが属するアドレス範囲に基づいて判定します。追加オプションのno-resolveは、このIPルールのためにドメインの名前解決を能動的に行わないことを示します。リクエスト全体でDNSが不要になるという意味ではありません。
• GEOIP,CN,DIRECTは接続先IPの地域情報に基づいて判定します。ドメインのサフィックスや運営主体による判定ではありません。
• FINAL,PROXYは、それ以前のルールにマッチしなかったリクエストを処理します。ルールの末尾に配置してください。

PROXY、DIRECT、REJECTはポリシーを示すキーワードであり、3種類のプロトコルではありません。PROXYには利用可能なプロキシ出口が必要です。DIRECTは接続先に直接接続し、REJECTはマッチしたリクエストを拒否します。設定で名前付きポリシーグループを使用する場合は、ルールが参照するグループ名が存在することを確認してください。例のPROXYを、定義されていない名前に安易に置き換えないでください。

4. [Host]：ドメインとアドレスのマッピングだけを設定する

[Host]では通常、ドメイン = IPアドレスの形式を使います。左側に完全なURLを、右側にパスやポートを記述しません。以下では、予約済みのテスト用ドメインとドキュメント用のアドレスで形式を説明します。隔離したテスト用設定にコピーして確認できますが、これらのアドレスが実際にアクセス可能なサービスを示すわけではありません。

[Host]
portal.example.test = 192.0.2.10
api.example.test = 192.0.2.20

Hostマッピングで変更されるのは名前解決の結果であり、リクエストが自動的にDIRECTになるわけではありません。自分のテスト用ドメインを直接接続させる場合は、[Rule]の適切な位置に対応するポリシーを別途追加してください。マッピングが正しくても、HTTPS接続には証明書とリクエストのドメイン名が一致している必要があります。Hostの項目だけでは、証明書名の不一致は解決できません。

1. まず、サービスが実際に待ち受けているアドレスとポートを確認します。たとえば、自分のテスト用サービスが443で待ち受けているか確認してください。
2. Hostの左側にはドメイン名だけを記述します。https://や:443は記述しません。
3. 名前解決の結果だけでなく、Ruleでそのドメインに適用されるポリシーを確認してください。
4. 接続先アドレスが変わった場合は、古いマッピングを更新または削除してからリクエストを再実行します。既存の接続やアプリのキャッシュにより、再テストの結果がすぐに反映されないことがあります。

接続方法や通信処理によっては、リモートのプロキシが接続先ドメインの名前解決に関与することもあります。トラブルシューティングでは、リクエスト先、選択中のポリシー、実際の接続結果をあわせて確認してください。端末上で一度DNSを検索しただけでは、接続経路全体で同じアドレスが使われたとは判断できません。

5. [URL Rewrite]：式・転送先・アクションを区別する

[URL Rewrite]が処理するのはURLであり、プロキシの出口選択ではありません。以下の例では、例示用ドメインへのHTTPリクエストをHTTPSにリダイレクトします。マッチ式、転送先、302アクションは空白で区切ります。$1は式の最初のキャプチャグループを参照し、ホスト名より後ろの部分を保持します。

[URL Rewrite]
^http://example\.com/(.*)$ https://example.com/$1 302

たとえばhttp://example.com/docs?a=1を入力すると、ルールの転送先はhttps://example.com/docs?a=1になります。バックスラッシュはドメイン名のピリオドを文字そのものとして扱い、先頭の^はマッチする位置を先頭に限定します。302はリダイレクトを返す指定です。以降のHTTPSリクエストには、別途接続とルール振り分けの処理が行われます。

• まずはドメインを1つに絞って明確にテストし、すべてのWebサイトを対象にする広範な式は使わないでください。
• この例がマッチするのはHTTPだけです。転送先はHTTPSなので、転送後のURLが同じルールに再度マッチすることはありません。
• パスを書き換える場合は、スラッシュ、キャプチャグループ、クエリパラメータを一つずつ確認し、転送先URLの連結ミスを防いでください。
• このルールを追加しても、既存のHTTPSリクエストで完全なパスが見えるようにはなりません。暗号化されたリクエスト内容の処理には別の条件が関わりますが、この記事の例ではMITMの設定は不要です。

ドメイン振り分けのためにURL Rewriteを追加しないでください。example.comにPROXYを適用するだけなら、[Rule]にDOMAIN-SUFFIXを記述します。自分のテスト用ドメインの名前解決先を固定するだけなら、[Host]を使います。役割を分けておくと、問題が起きたときに変更を戻しやすくなります。

6. 保存・有効化・検証：一度に変更するのは1セクション

編集前に、Configで現在正常に使えている設定のコピーを保存し、Homeで選択中のサーバーとGlobal Routingも記録してください。サーバーサブスクリプションとリモート.conf設定は、更新対象が異なります。前者は通常サーバー項目を更新し、後者は設定ファイルの内容を更新します。リモート設定に対応する内容を直接編集すると、次回更新時にローカルの変更が上書きされる可能性があります。テスト用に独立したローカルコピーを作成してください。

1. 基準状態を確認：Homeで利用可能なサーバーを選択して接続し、Connectivity Testで基本的な接続を確認します。このテストだけでは、特定のWebサイトやルールの検証にはなりません。
2. コピーを編集：Configでテストする設定を開き、該当するセクションを見つけて、パラメータ1つまたはルール1つだけを変更します。保存したら設定一覧に戻ります。
3. 有効化を確認：Configで対象ファイルを選択し、Home → Global RoutingでConfigを選びます。必要に応じて再接続し、新しい設定を今回の検証に反映させます。
4. リクエストを再現：同じドメイン、プロトコル、パスで新しいリクエストを送信します。HostやURL Rewriteを変更した後は、特に以前のページのキャッシュを判断材料にしないようにしてください。
5. 結果を照合：接続ログで接続先とポリシーを確認します。結果が想定と異なる場合は、まず今回の変更だけを元に戻し、変更前後を比較してください。

たとえばDOMAIN-SUFFIXのテストでは同じサブドメインへのアクセスを固定し、Hostのテストでは接続先サービスとポートを固定します。URL Rewriteのテストでは、ブラウザーが自動補完したHTTPSではなく、http://を明示して入力してください。「リクエストが送信されていない」「誤ったポリシーにマッチした」「出口への接続に失敗した」を分けて記録すると、DNS、ルール、サーバーを同時に変更するより原因を特定しやすくなります。

7. よくある質問：設定が正しく見えても反映されない

構文の詳細はルールマニュアルをご覧ください。実際の設定では用途を説明できるパラメータを残し、ドメイン振り分け、アドレスマッピング、URL書き換えを分けて管理します。変更のたびに対象、想定するポリシー、ロールバック用ファイルを記録しておくと、後から更新内容を確認しやすくなります。