Shadowrocketの設定ファイル（.conf）の構造と使い方｜General・Rule・Host・URL Rewriteを解説｜Shadowrocket Q&A

この記事の概要

自分で管理するサーバーやサブスクリプションを利用していて、.confの内容を確認・調整したい方に向けた解説です。まずConfigで有効なファイルを確認し、基本設定、振り分けルール、ドメインのマッピング、URL書き換えを順にチェックします。読み終えると、変更箇所をどのセクションに記述するか、最小限の変更で問題を切り分ける方法がわかります。ドメインやアドレスは構文説明用の例であり、利用可能なサービス設定ではありません。

1. .confとは？使用中のファイルを確認する方法

.confは設定テキストであり、Homeに表示されるサーバー一覧とは別のものです。Shadowrocketでは設定ファイルを使ってルールや関連パラメータを管理できますが、サブスクリプションの更新に成功しても、現在有効なルールファイルが更新されたとは限りません。まずConfigで選択中の設定を確認し、次にHome → Global Routingでモードを確認してください。これで、ファイル内のルールが通信の振り分けに使われているか判断できます。

Configを開き、現在選択されているファイルを確認してファイル名を控えます。編集する場合は、先に元ファイルのコピーを保存してください。
ファイルの編集画面を開き、角括弧で囲まれたセクション名を目印に内容を確認します。ドメイン名だけを検索して、そのまま変更しないでください。
Home → Global Routingに戻ります。ファイル内のルールをテストするにはConfigを選択してください。ProxyとDirectでは、このファイルの個々のルールに基づく経路選択は行われません。
保存後、編集したファイルが有効になっていることをもう一度確認し、同じ接続先でテストします。接続が以前の状態を引き継いでいる場合は、いったん切断して再接続してから確認してください。

セクション名によって、その後の内容の解釈方法が決まります。[General]の後には通常、key = value形式のパラメータが記述され、[Rule]の後にはカンマ区切りのルールが続きます。次のセクション名が現れるまで、同じ形式として解釈されます。[Host]にDOMAIN-SUFFIXの行を追加したり、セクション名に全角の角括弧を使ったりしないでください。

[General]
dns-server = system

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

[Host]
lab.example.com = 192.0.2.10

2. [General]と[Host]の役割

[General]は基本動作を設定し、[Host]はドメイン名とアドレスの静的な対応付けを指定します。名前解決に問題がある場合は、まずConfigで現在使用中のファイルにあるこの2つのセクションを確認してください。どちらも振り分けルールではありません。[Host]にドメインを記述しても、リクエストが必ずDIRECTになるわけではありません。また、DNSパラメータを変更しても、Global Routingが自動的にConfigへ切り替わることはありません。

[General]の確認項目

記述形式: key = value
パラメータの例: dns-server = system
主な役割: DNSなどの基本設定を指定
確認場所: Config → 現在のファイル → 編集画面

既存パラメータの意味を確認してから、項目ごとに調整してください。セクション全体を一度に置き換えないでください。

[Host]の確認項目

記述形式: ドメイン名 = IPアドレス
構文例: lab.example.com = 192.0.2.10
主な役割: 指定したドメイン名に静的アドレスを割り当てる
含まれない情報: URLのパスとサーバーポート

マッピング先が変わったら設定も更新してください。古いアドレスが残っていると、接続に失敗し続けることがあります。

dns-server = systemはシステムDNSを使用する指定であり、すべてのリクエストに対する出力経路を指定するものではありません。現在のファイルで別のDNS設定を使っている場合は、先に元の値を記録し、変更前後の名前解決結果を比較してください。ドメイン名からアドレスを取得できても、リクエストの結果はルール、選択中のサーバー、リモート側での名前解決などにも左右されます。「DNS応答がある」だけでWebページにアクセスできるとは判断できません。

[Host]はHTTPSの証明書による本人確認を変更する機能ではありません。たとえば、lab.example.comを自分で管理するテスト用アドレスに向けても、ブラウザは引き続き元のドメイン名でアクセスします。そのため、サーバー証明書はそのドメイン名に対応している必要があります。アドレスのマッピングが正しくても、証明書エラー、接続先ポートが待ち受けていない、またはサーバーに該当サイトが設定されていない場合は接続できません。証明書エラーを無視して、マッピングの問題を隠さないでください。

特定のドメインだけに問題がある場合は、[Host]に古いマッピングが残っていないか確認し、そのドメインに適用されるルールも確認してください。
複数のドメインを名前解決できない場合は、[General]のDNSパラメータを確認し、変更前のファイルと比較してください。
ドメイン名を解決できても接続がタイムアウトする場合は、接続経路とサーバーポートを確認してください。HTTPSでよく使われるポートは443ですが、名前解決に成功しても、そのポートに到達できるとは限りません。

3. [Rule]は上からどのように照合される？

[Rule]は記載順に評価され、最初に一致した有効なルールのポリシーが適用されます。Home → Global Routing → Configを開いてから、現在のファイルでルールの順序を確認してください。以下はルールによる振り分けの判定手順を示したものです。DNS、Host、URL Rewriteが常に同じ固定順序で内部処理されるという意味ではありません。

リクエストを識別順に照合最初の一致ポリシーを適用デフォルト処理

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

キーワード	例の意味	確認ポイント
`DOMAIN`	api.example.comという完全一致のドメインだけに適用されます。	例外となる完全一致ルールは、対象範囲の広いルールより前に配置します。
`DOMAIN-SUFFIX`	example.comとそのサブドメインに一致します。	https://、パス、ポートは記述しません。
`IP-CIDR`	192.0.2.0/24のアドレス範囲に一致します。	`no-resolve`を指定すると、このルールのためだけに追加の名前解決が行われるのを防げます。
`GEOIP`	IPの位置情報データベースを使ってCNに一致させます。	判定基準はIPデータです。Webサイトの言語やドメインの末尾ではありません。
`FINAL`	それ以前のルールに一致しなかったリクエストを処理します。	後続のルールを先に適用してしまわないよう、末尾に配置します。

完全一致の例外ルールは、広範囲に一致するルールより前に配置します。この例では、api.example.comが先にDOMAINに一致してDIRECTになり、それ以外のexample.comのサブドメインに一致するリクエストはPROXYになります。先頭の2つのルールを入れ替えると、完全一致のドメインも先にサブドメインルールに一致します。ここでのPROXYはプロキシポリシーを示すもので、サーバー設定が自動で追加されるわけではありません。Homeで利用可能なサーバーが選択されていることを確認してください。

no-resolveは、すべてのDNSを無効にする指定ではありません。このオプションが制御するのは、該当するIPルールでの名前解決の動作です。接続先IPがまだわからないドメイン名のリクエストに対し、no-resolve付きのルールが必ず一致するとは限りません。一方、IPアドレスを直接指定したリクエストは、既知のアドレスに基づいて判定できます。切り分ける際は、ドメイン名でのアクセスとIPアドレスでの直接アクセスを分けてテストしてください。

要点：具体的な例外を先に移動し、最後にデフォルトポリシーを変更する

特定のドメインの接続経路が意図と異なる場合は、その上に対象範囲の広いルールがないか確認し、必要な完全一致ルールを前に移動してください。最初にFINAL全体を別のポリシーへ変更すると、ほかの一致しなかったリクエストの経路まで変わってしまいます。

4. [URL Rewrite]とドメイン振り分けの違い

[URL Rewrite]はURLの照合と書き換えを行うもので、プロキシ経路は選択しません。リクエスト先のURLを別のURLへリダイレクトする場合に、このセクションを確認してください。特定のドメインをPROXYにしたい場合は、[Rule]を変更します。以下は文書用の例示ドメインだけを対象にしたHTTPリダイレクト構文であり、通常のアクセスに使うルールではありません。

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

^と$で照合範囲を指定します。example\.comのバックスラッシュは、ピリオドを通常の文字として照合するために使います。
(.*)で後続の内容をキャプチャします。転送先URLの$1は、そのキャプチャ結果を参照します。
302は一時的なリダイレクトを示し、後続のリクエストを別のURLへ誘導します。プロキシサーバーのポート番号ではありません。
対象はhttp://にだけ一致するため、すでにhttps://を使っている接続先が同じルールに再度一致することはありません。

VPNを経由しただけで、HTTPSの完全なパスが自動的に見えるわけではありません。暗号化されたURLのパスや内容を読み取って書き換えるには、通常、MITMに関する設定、対象ホストの範囲、証明書の信頼設定が必要です。URL Rewriteを1行追加するだけでは不十分です。この例はHTTPを使って構文を説明しているため、設定を読む目的で証明書の信頼範囲を広げる必要はありません。

書き換えをテストするときは、最終ページが開くかだけでなく、リダイレクトの経路を確認してください。ブラウザに以前のリダイレクトがキャッシュされていたり、アプリが直接HTTPSを使ったりすると、ルールが効いていないように見えることがあります。まず元のリクエストが正規表現に一致することを確認し、次に想定どおり302リダイレクトが発生するか確認してください。「最終的にページが開いた」だけでは、この書き換えルールに一致した証拠にはなりません。

5. ファイル変更後の段階的な確認方法

変数を一度に1つだけ変更すると、設定と現象の関係を把握しやすくなります。テスト前に、使用中のファイル、Global Routingのモード、選択中のサーバーを記録してください。サブスクリプションを更新してサーバー一覧が変わった場合は、サーバーの変化をルールの変更と取り違えないよう、テストに使うサーバーを固定してください。

基準を記録：正常に動作する元ファイルを保存し、変更前に同じ接続先が正常に開くのか、タイムアウトするのか、名前解決に失敗するのか、証明書エラーになるのかを記録します。
モードを確認：Home → Global RoutingでConfigを選択します。Sceneを使用している場合は、シーンの条件によって実際に選択されているモードを確認してください。ファイルのルールが使われていると決めつけないでください。
1か所だけ変更：たとえば、完全一致のDOMAINルールを1つだけ追加します。保存後もそのファイルが有効になっていることを確認し、リクエストを再送してください。
既存の接続を切り離す：確立済みの長時間接続は、以前の経路を使い続ける場合があります。元のリクエストを終了し、必要に応じて再接続してから、同じ接続先にアクセスしてください。
元に戻して比較：変更後に問題が発生した場合は、元のファイルに戻して再テストします。元に戻しても問題が続く場合は、ルールを次々に追加するのではなく、サーバー、ネットワーク、接続先のサービスを確認してください。

Connectivity Testは接続性を確認する手がかりであり、実際のリクエスト検証の代わりにはなりません。Homeでテストを実行した後も、問題が発生している特定のドメインを開いて確認してください。テストに成功しても、指定した条件でテスト先に到達できることがわかるだけです。すべてのドメインのDNS、Hostマッピング、ルール、URL Rewriteが正しいとは限りません。

On Demandは接続を開始する条件を設定する機能であり、個々のリクエストに適用するルールを選ぶものではありません。ネットワーク条件に応じて接続が自動的に変化する場合は、Settings → On Demandで接続条件を確認してください。オンになっていても特定のドメインが意図しない経路を通る場合は、Global RoutingとConfigを確認します。異なる種類の問題を、同じスイッチで何度も解決しようとしないでください。

元のファイルでは正常で、新しいファイルでは異常が起きる場合は、変更したセクションとルールの順序を優先して比較してください。
DIRECTでは正常でPROXYでは異常が起きる場合は、選択中のサーバーと接続先への到達性を確認してください。すぐにDNS設定が原因だと判断しないでください。
特定のドメインだけに問題がある場合は、完全一致ルール、静的マッピング、そのドメインに適用される書き換え条件を確認してください。
設定ファイルがリモートから更新される場合は、ローカルコピーを保存し、更新後に手動変更が上書きされていないか確認してください。

6. 設定ファイルに関するよくある質問

ファイルにルールを書いたのに、なぜすべて同じ経路を通るのですか？

まずHome → Global RoutingでProxyやDirectが選択されていないことを確認し、次にConfigで有効なファイルを確認してください。その後、対象ルールより前に広い範囲に一致するDOMAIN-SUFFIXがないか、FINALが途中に置かれていないか確認します。変更後はリクエストを再送し、以前のセッションが再利用されないようにしてください。

サブスクリプションを利用していても、.confを個別に確認する必要がありますか？

はい。通常、ユーザーが利用するサーバーのサブスクリプションはサーバー情報を管理し、ルールファイルは別の設定を担います。サブスクリプションの更新後は、Homeでサーバーに変更がないか確認し、Configで使用中のファイルも確認してください。サーバー一覧の更新に成功しただけで、ルールも更新されたと判断しないでください。

[Host]にlab.example.com:443と記述できますか？

ここにはドメイン名とIPアドレスの対応を記述し、ドメイン名にポートを付けないでください。サーバーポートはリクエストURLまたは接続設定で決まります。接続先がHTTPSの443番ポートを使う場合は、アドレスのマッピング、443番ポートへの到達性、証明書のドメイン名をそれぞれ確認してください。これらをHostの1行にまとめて記述することはできません。

FINAL,DIRECTとFINAL,PROXYはどちらを選べばよいですか？

ルールに一致しなかったリクエストをどう扱いたいかに応じて選択してください。前者はデフォルトのリクエストを直接接続し、後者はプロキシポリシーを適用します。ConfigでFINALより前にどのドメインやアドレスをカバーしているか確認してから、残りの通信の扱いを決めてください。どちらの記述も、ルール全体の設計に代わるものではありません。

[URL Rewrite]を削除すれば、すべてのWebページの問題を直せますか？

いいえ。まず元のファイルを保存し、問題の接続先に関連する書き換えだけを一時的に外してテストしてください。変化がなければ元に戻し、[Host]、DNS、[Rule]を確認します。問題が解消した場合は、正規表現の照合範囲を狭め、リダイレクト先も確認してください。