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

この記事の概要

Shadowrocketの.confは設定テキストであり、接続サービスの契約ではありません。利用できる接続先があり、設定を読んだり編集したりする方を対象に、4つのセクションの役割、設定コピーでの変更、Global RoutingのConfigによるルール確認を解説します。例は構文の説明用です。ドメインとアドレスは文書用の値であり、実際に利用できるサービスを示すものではありません。

1. セクション見出しと各行の書式を確認する

角括弧はセクションの開始を示します。[General]以下の設定は、次のセクション見出しが現れるまでGeneralに属します。空行は読みやすくするための区切りであり、セクション見出しの代わりにはなりません。編集時は英語のキーワード、半角のカンマ・等号・角括弧を保ち、入力方式によって記号が全角に置き換わらないようにしてください。

4つのセクションは、4種類のプロキシプロトコルでも、ファイルの上から順に実行される4段階のネットワーク処理でもありません。Generalは全体設定、Ruleはリクエストの処理方針、Hostは指定ドメインのマッピング、URL Rewriteは条件に合うURLの処理を担います。「上から順に評価」が特に重要なのはRule内のマッチ順です。この考え方をファイル全体にそのまま当てはめないでください。

4つのセクション

この記事の範囲：General / Rule / Host / URL Rewrite

2種類の区切り記号

GeneralとHostでは主に等号、Ruleではカンマを使用

フォールバックは1つ

最小構成の例では、FINALをRuleの末尾に配置

[General]
dns-server = system

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

[Host]
test.example.com = 192.0.2.10

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

2. General：全体設定と振り分けルールは別のもの

Generalは通常、パラメーター名 = 値の形式で記述します。たとえばdns-server = systemは、システムのDNSを使う設定です。これは名前解決に関する動作を指定するもので、「すべてのリクエストをDIRECTにする」「すべてのリクエストをPROXYにする」という意味ではありません。リクエストの処理方針は、現在のGlobal Routingのモードと適用されるルールで決まります。

[General]
dns-server = system

DNSを変更する前に、問題がどの段階で起きているかを確認してください。ドメインを名前解決できないのか、接続先アドレスは取得できても接続できないのかを切り分けます。DNS、ルール、接続先の設定を同時に変更すると、結果が変わっても原因を特定できません。既存の設定にほかのGeneralパラメーターが含まれている場合があります。ここに示す1行だけを根拠に、セクション全体を置き換えないでください。

元の設定に含まれる有効なパラメーターは維持し、今回確認する項目だけを変更してください。
値には半角文字を使い、値の直後に日本語の説明を書き足さないでください。
GeneralにはDOMAIN-SUFFIXやFINALを記述しないでください。これらはRuleで使います。
システムDNSと指定したリゾルバーで結果が異なる場合は、まず結果を記録してから変更が必要か判断してください。

3. Rule：マッチ条件・方針・順序をまとめて確認する

Ruleの基本形式はタイプ,マッチ対象,方針です。DOMAIN-SUFFIX,example.com,PROXYはexample.comとそのサブドメインにマッチし、PROXYを適用します。マッチ対象にhttps://やパスは含めません。完全なURLを指定するものでもありません。単一のホスト名だけにマッチさせる場合は、DOMAINを使うと意図が明確です。

[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

この例では、api.example.comは先にあるDOMAINルールにマッチするため、後続のDOMAIN-SUFFIXには進みません。それ以外のexample.comのサブドメインは、サフィックスルールにマッチします。2行を入れ替えると、より広いサフィックスルールが先に適用され、特定ドメインの例外が意図どおり機能しなくなります。FINALは先行するルールにマッチしなかったリクエストを処理するため、通常は末尾に置きます。

ドメインでマッチ

DOMAIN: api.example.comのように、完全なドメイン名にマッチします。
DOMAIN-SUFFIX: example.comとそのサブドメインにマッチします。任意の文字列に含まれるかどうかを調べるものではありません。
DOMAIN-KEYWORD: ドメイン内のキーワードでマッチするため、想定より広い範囲に適用される場合があります。

具体的な例外を広範なルールより前に配置します。ドメインルールにURLのパスは記述しません。

アドレスとフォールバックでマッチ

IP-CIDR: アドレスのネットワーク範囲にマッチします。192.0.2.0/24はこの記事で使う文書用の例示ネットワークです。
GEOIP: 宛先IPの地理情報データベースに基づいてマッチします。結果はデータベースの記録によって異なります。
FINAL: マッチ対象は記述せず、FINAL,PROXYなどのフォールバック方針を指定します。

no-resolveは、このIPルールのために追加のドメイン名前解決を行わないようにする設定です。すべてのDNSを無効にする意味ではありません。

DIRECTは直接接続、PROXYはプロキシ方針での処理を表します。方針名はサーバーアドレスではありません。GEOIPの判定結果はIPアドレスとデータベースに依存するため、中国語のWebサイトが必ずCNにマッチするとは限りません。特定のドメインに例外を設定する場合は、Webページの言語からGEOIPを推測するのではなく、明確なドメインルールを優先してください。

4. Host：名前解決先を固定し、処理方針は選択しない

Hostは、指定したドメインとアドレスの対応を設定します。基本形式はドメイン = IPアドレスです。Ruleの「マッチした後にどの方針で処理するか」とは役割が異なります。ドメインを指定したアドレスに対応付けても、そのリクエストが自動的にDIRECTになるわけではありません。現在のルーティングモードとルールをあわせて確認してください。

[Host]
test.example.com = 192.0.2.10

この行が設定するのはtest.example.comのマッピングだけであり、example.comのすべてのサブドメインに自動で適用されるわけではありません。動的アドレスや分散型の接続先に依存するサイトでは、サービスの変更後に固定アドレスが使えなくなることがあります。追加理由を記録し、マッピングを削除した状態でもう一度確認できるようにしてください。由来が分からないHost項目を古い設定から残し続けないでください。

HostとRuleで変更する項目を区別する

名前解決先を指定する

Hostに完全なドメイン名と確定した接続先アドレスを記述します。
そのアドレスが、アクセスしたいサービスのものであることを確認します。
実際にアクセスする前に、この記事の文書用例示アドレスを削除してください。

処理方針を変更する

RuleにDOMAINまたはDOMAIN-SUFFIXを追加します。
DIRECT、PROXY、または定義済みの有効な方針を選びます。
特定の例外は、広範なルールやFINALより前に配置します。

名前解決先とルーティング方針を別々に確認してください。振り分けルールの代わりにHostを使わないでください。

5. URL Rewrite：URLでマッチし、ドメインの振り分けには使わない

URL Rewriteでは、マッチするアドレスを式で指定し、置換先または対応するアクションを設定します。以下はHTTPからHTTPSへの302リダイレクトの例です。正規表現の\.はドットそのもの、(.*)はパス部分のキャプチャ、置換先の$1は最初のキャプチャグループを参照します。

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

入力例：http://example.com/help。
置換先：https://example.com/help。
^と$はマッチ範囲の先頭と末尾を指定し、アドレスの一部分だけにマッチするのを防ぎます。
302はリダイレクト応答のステータスコードです。プロキシのポート番号でも、Ruleの方針名でもありません。

この例がマッチするのは、HTTPで始まるURLです。すべてのHTTPSパスを直接読み取れるという意味ではありません。HTTPSではパスが暗号化されており、パスを扱うには追加の前提条件があります。URL Rewriteセクションを追加するだけで、それらの条件が整うわけではありません。この記事では証明書関連の設定変更は不要です。このHTTPの例を確認するために、変更範囲を広げることもおすすめしません。

6. 保存後にConfigを選び、変更を1つずつ検証する

ファイルを編集することと、その内容を有効にすることは別の手順です。Configで変更を保存した後、対象の設定ファイルが選択されていることを確認してください。Ruleを検証するときは、Home → Global RoutingでConfigを選択します。ProxyまたはDirectのままでは、アクセス結果から編集した振り分けルールの正否を判断できません。

元の設定を保管する

Configで現在使用中のローカル設定を開き、まずコピーを保存するか元の内容をバックアップします。ファイル名を記録し、使える設定を1つだけ残した状態で直接上書きしないでください。
1項目だけ変更する

対象の設定ファイルを編集し、1つのセクション内の対象項目だけを変更します。たとえば、まずDOMAIN,api.example.com,DIRECTを追加し、HostやDNSは同時に変更しないでください。
保存して選択する

保存後にConfigへ戻り、対象の設定ファイルが選択されていることを確認します。続いてHome → Global Routing → Configに進み、今回のテストでルールによる振り分けが使われていることを確認してください。
新しいリクエストでテストする

既存の長時間接続だけを確認しないよう、対象へのリクエストを新たに実行します。リクエストのドメイン、想定する方針、実際の結果を記録してください。必要であれば再接続してからテストします。
変更前と比較する

追加した行を削除し、同じ対象をもう一度確認します。結果が想定と異なる場合は、マッチ順序と現在選択されている設定を再確認してください。変更を重ねて追加しないでください。

Config

Proxy

リクエストをProxyモードで処理し、Ruleごとの振り分け方針は選択しません。プロキシ接続が使えるかを切り分ける比較には利用できますが、ルールにマッチしたことの確認には使えません。

用途：利用可能な接続先がある状態で、接続の問題とルールの問題を切り分ける。

Direct

リクエストをDirectモードで処理します。このモードでの結果を使って、PROXYルールが正しいかどうかは判断できません。

用途：同じ接続先が直接接続でどう動作するかを確認する。

Global RoutingのSceneはシーン設定に関わる項目であり、Configによるルール検証と混同しないでください。Settings → On Demandではオンデマンド接続の条件を管理します。ここはRuleの編集画面ではありません。ネットワーク条件によって接続が自動的に変わる場合は、テスト前にこれらの独立した設定を確認してください。接続状態の変化を.confの構文エラーと取り違えないためです。

7. 設定が反映されないときは、症状から原因を絞り込む

「ファイルを保存できた」ことは編集が完了したというだけで、各ルールが意図どおり機能する証明にはなりません。確認時は、まずファイルとモードを特定し、その後に対象、順序、構文を見直してください。以下は接続先を変更せず、現在利用できる接続環境で1つずつ確認できます。

症状	最初に確認する項目	確認方法
Ruleを追加しても変化がない	現在の設定ファイルとGlobal Routing	Configで対象のファイルが選択されていることを確認し、Home → Global RoutingでConfigを選びます。
特定ドメインの例外が機能しない	ルールの順序	DOMAINの例外をより広いDOMAIN-SUFFIXより前に配置し、FINALは末尾に残します。
特定のドメインだけアクセスできない	Hostの固定マッピング	そのドメインの古いマッピングを削除して再テストします。DNSは同時に変更しないでください。
URL Rewriteで変化がない	プロトコル、ホスト名、式	リクエストがHTTPかHTTPSか、ドットのエスケープとパスがマッチしているか確認します。
保存後にファイルの解析エラーが発生する	セクション見出しと半角記号	角括弧、カンマ、等号を確認し、直近の変更を元に戻してから設定を開き直します。

利用中のサブスクリプションは通常、接続情報の管理に使われます。「サブスクリプションを更新する」ことと「現在のローカル.confが更新される」ことは同じではありません。設定の取得元がリモートの場合は、リモートの元ファイルとローカルコピーを区別してください。その後の更新で、元の内容が変わることがあります。ローカルで加えた変更を記録しておくと、同じファイルを何度も読み込むより問題の追跡が容易になります。

最小構成での検証には必要なGeneral、対象のRule、FINALだけを残し、不要なサンプルセクションは追加しないでください。
1回の変更につき、変更内容・テスト対象・結果をそれぞれ記録し、複数の条件を同時に調整しないでください。
構文全体や各セクションの詳しい説明は設定リファレンスをご覧ください。用語の意味は用語集で確認できます。