Shadowrocketの設定ファイル（.conf）を解説：[General]・[Rule]・[Host]・[URL Rewrite]の役割

この記事の概要

.confは設定ファイルであり、サーバーのサブスクリプションを別の名前で呼んだものではありません。自分のサブスクリプションをすでに利用していて、Configの内容を確認・編集したい方向けの記事です。操作手順はiPhone / iPadの画面を例に説明します。Mac、Windows、Android、Linuxでは、各バージョンの該当する設定項目を確認してください。読み終えると、全般設定、ルールによる振り分け、ローカルの名前解決、リクエストの書き換えを区別し、バックアップ、個別編集、再接続、ログ確認の順に検証できます。

1. Config、サーバー、Global Routingの違い

ShadowrocketのHomeでは登録済みサーバーの確認や選択を、Configでは設定ファイルの管理を行います。サーバー項目には接続に必要なアドレス、ポート、プロトコル、認証情報が保存されます。一方、この記事で扱う4つのセクションは、名前解決、通信の振り分け、リクエストの書き換え方を指定します。この4セクションを含む.confをインポートしても、利用可能なサーバーが新たに作られるわけではなく、既存のサブスクリプションの代わりにもなりません。

編集を始める前に、Home → Global Routingを確認します。Proxy、Direct、Config、Sceneは4種類のサーバープロトコルではなく、それぞれ異なるルーティングモードです。この記事の[Rule]を検証するには、まずConfigを選択してください。ProxyまたはDirectの状態では、全体の接続結果から特定のルールが適用されたかどうかを判断できません。

モード	確認するポイント	この記事との関係
Proxy	全体をProxy経由にする	この状態では[Rule]による振り分け結果を確認できません。
Direct	全体を直接接続にする	このモードでは、サーバーが利用可能かどうかを直接検証できません。
Config	現在有効な設定ファイル	この記事のルールの順序とポリシーを検証するために使用します。
Scene	Sceneの条件と関連設定	Sceneで実際に使われているルーティングと設定を先に確認してください。固定のConfigと同じものとは限りません。

設定をバックアップファイルを選択項目を編集再接続ログを確認

この手順は編集・検証の順序を示したもので、通信の処理順序ではありません。実際の接続では、DNS名前解決、ドメインとの照合、IPアドレスとの照合が相互に影響する場合があります。また、すべての通信が[URL Rewrite]を通るわけではありません。Settings → On Demandは条件に応じた接続動作を管理する機能であり、Configのルールによる振り分けの代わりにはなりません。

2. .confのセクション構文と安全な編集手順

セクション名は1行に単独で記述し、半角の角括弧で囲みます。パラメーターには通常、半角の等号を使い、ルールの各項目は半角カンマで区切ります。日本語入力のカンマや括弧を構文に混ぜないでください。以下は構成例です。使わないセクションを省略しても、設定ファイルが壊れているとは限りません。テキストの配置を示す例であり、サーバーの認証情報は含まれていません。

[General]
dns-server = system

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

[Host]
lab.example.com = 192.0.2.10

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

Configを開き、現在正常に動作しているファイルのコピーを保存します。リモート設定の場合は、元のURLとローカルで変更した内容も記録しておきます。
編集するファイルの編集画面を開き、編集対象と有効化する予定のファイルが一致していることを確認します。編集ボタンの場所はプラットフォームによって異なる場合があります。
一度に変更する内容は1種類に絞ります。たとえばDOMAIN-SUFFIXを1件だけ変更し、DNSの変更やマッピング、書き換えルールの追加を同時に行わないでください。
保存後、そのファイルが有効になっていることを確認します。Homeに戻り、Global RoutingがConfigになっていることを確認してから、再接続し、新しいテストリクエストを送信します。

コメントは、たとえば#でルールの用途を説明するように、1行に分けて記述します。行末コメントに対応していることを確認できていない場合は、パラメーター値の後ろに説明文を直接続けないでください。拡張子は.confのままにし、テキストエディターが.txtを追加しないように注意します。

3. [General]：全般設定とDNS名前解決

[General]には、設定全体に適用されるパラメーターを記述します。dns-server = systemはシステムのDNS設定を使うという意味で、systemという名前のサーバーを設定するものではありません。現在のネットワークで必ず名前解決できることを保証するわけでもありません。接続に失敗した場合は、DNSの失敗、ルーティングの誤り、接続先サービスの無応答を切り分けてください。

[General]
dns-server = system

他の人のパラメーター一覧を見て、設定全体をそのままコピーするのは避けてください。IPv6、DNS、バイパス設定は、それぞれ異なる動作に影響します。たとえばDNSを変更してもサーバーの認証情報の誤りは直りません。また、特定のアドレスの名前解決を無効にしても、あらゆるタイムアウトの原因を説明できるわけではありません。まず動作中の設定を保ち、原因となる現象を確認したうえで、1項目ずつ変更してください。

[General]の確認項目

セクション名: [General]
パラメーター: dns-server = system
検証する内容: 新しいリクエストの名前解決結果とエラーログ

まず名前解決が成功しているか確認し、その後で接続経路を判断します。

[Rule]の確認項目

セクション名: [Rule]
照合ルール: DOMAIN-SUFFIX,example.com,PROXY
最終ルール: FINAL,DIRECT

ルールが決めるのは接続ポリシーであり、サーバーの認証情報を設定するものではありません。

確認には新しい接続を使ってください。確立済みの長時間接続は以前の接続状態を引き継ぐことがあり、ブラウザーやシステムにDNSキャッシュが残っている場合もあります。ページを1回再読み込みしただけでは、新しいDNS設定が有効になったことも、保存に失敗したことも判断できません。

4. [Rule]：上から順に照合し、FINALは最後に配置

[Rule]は記述順に照合され、先にルールが適用されると、通常は後続ルールがその接続のポリシー選択に使われません。そのため、具体的な例外は広い範囲に一致するルールより前に置きます。以下の例では、特定のドメインを先にDIRECTにし、同じドメインのサフィックスに一致するそれ以外のリクエストをPROXYにします。

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

DOMAINはドメイン名に完全一致します。例のstatus.example.comは先にDIRECTに一致します。
DOMAIN-SUFFIXはexample.comとそのサブドメインに一致します。*.example.comと書く必要はなく、完全なWebページのURLを指定するのも誤りです。
IP-CIDRは接続先IPアドレスが属するネットワーク範囲に一致します。192.168.50.0/24はこのプライベートネットワークを示し、すべてのLANを意味するものではありません。
no-resolveは、このIPルールのためにドメイン名の名前解決を明示的に行わないようにする指定です。設定全体の「DNSを無効にする」スイッチではありません。
GEOIP,CN,DIRECTは接続先IPアドレスの地理情報データベース上の所属をもとに判定します。Webページの言語やドメインの末尾をもとに判定するものではありません。
FINAL,PROXYは、それ以前のルールに一致しなかった接続に適用されます。先頭に置くと、後続の通常ルールが照合されなくなります。

PROXYとDIRECTはポリシーを表すキーワードで、プロトコル名ではありません。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuardはサーバーへの接続方式を示すもので、ルールの末尾にポリシーとして指定することはできません。独自のポリシー名を使う場合は、設定内に対応する定義があり、スペルも完全に一致していることを確認してください。

要点：まずドメインを1つだけ検証し、その後に対象範囲を広げる

コピーした設定ファイルで、自分が管理するテスト用ドメインにDOMAINルールを1つ追加し、FINALより前に配置します。再接続後、新しいリクエストの照合ログを確認し、結果が正しいことを確かめてからDOMAIN-SUFFIXに切り替えます。これにより、構文の誤りと対象範囲の広げすぎを分けて調べられます。

5. [Host]：ドメイン名のマッピングとルーティングは別設定

[Host]ではローカルのドメイン名マッピングを設定します。左側にドメイン名、右側に割り当てるアドレスを記述します。ブラウザーのアドレスバーにあるプロトコル、ポート、パスをまとめて貼り付けないでください。マッピングで変更されるのは接続先アドレスの名前解決であり、通信が自動的にDIRECTになるわけでも、接続先サイトの証明書が修復されるわけでもありません。

[Host]
lab.example.com = 192.0.2.10
api.example.com = 192.0.2.20

記述・発生した現象	問題点	対処方法
`https://lab.example.com/path`	URLをドメイン名のキーとして指定している	左側には`lab.example.com`だけを記述します。
`192.0.2.10:443`	IPアドレスのマッピング値にポートを付けている	マッピングにはアドレスだけを指定します。HTTPSの443番ポートは接続先の情報です。
マッピング後に証明書エラーが発生する	そのアドレス上のサービスが、該当ドメイン名に有効な証明書を持っているとは限りません。	サーバー証明書とドメイン名を確認し、証明書エラーを無視してマッピングの問題を隠さないでください。
引き続きProxy経由になる	アドレスのマッピングではDIRECTは指定されません。	[Rule]に戻り、そのドメインまたは接続先アドレスに適用されるポリシーを確認します。

たとえば、自分が管理するテスト用ドメインを内部サーバーに向ける場合は、現在のネットワークまたは選択中のProxyからそのアドレスに到達できることも確認します。サービスにローカルネットワークからしかアクセスできない場合は、該当するDIRECTルールも別途確認してください。マッピングの正しさ、アドレスへの到達性、ポートの開放、証明書の有効性はそれぞれ独立した条件です。どれか1つだけを確認しても十分ではありません。

6. [URL Rewrite]：正規表現による照合とリダイレクト

[URL Rewrite]はリクエストURLを処理する設定であり、サーバーサブスクリプションの更新ツールではありません。以下のルールはexample.comの平文HTTP URLだけに一致し、パスを保持したままHTTPS URLへ302リダイレクトします。変更するのはリクエストURLの処理方法であり、[Rule]でPROXYやDIRECTを選択するものではありません。

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

^はURLの先頭から、$は末尾までを照合範囲とし、意図しない他のURLへの適用を防ぎます。
example\.comではピリオドをエスケープしており、文字としてのピリオドを表します。正規表現でエスケープしていないピリオドは、通常は任意の1文字に一致します。
(.*)はスラッシュ以降の内容をキャプチャし、置換先URLの$1でその内容を参照します。
302はリダイレクトのステータスコードであり、ポート番号ではありません。サーバーの443番ポートに置き換えないでください。

テストには、自分が管理するサービスのアドレスを使います。たとえばパスとクエリパラメーターを含むHTTPリクエストを送り、リダイレクト先のLocationに想定した内容が保持されているか確認します。ブラウザーのHTTPS自動アップグレードやHSTSによって、リクエストがHTTPで送信されない場合があります。そのため、最終的にブラウザーでHTTPSが開いたことだけでは、ルールが適用された証拠になりません。

よくある誤りは、照合範囲が広すぎる、置換先が同じルールに再び一致する、ルールを[Rule]セクションに記述する、といったものです。リダイレクトが繰り返される場合は、追加した書き換えルールをいったん無効にして元のリクエストに戻し、正規表現の範囲を絞ってください。同じループを解消するために、複数のリダイレクトを同時に追加しないでください。

7. 保存後に反映されない場合：ファイル、モード、照合条件を確認

まず「どのファイルが使われているか」を確認し、次に「テストする条件にリクエストが合致しているか」を確認します。サーバーサブスクリプションの更新とリモート設定の更新は別の操作です。前者は主に登録済みのサーバー項目に影響し、後者は設定ファイルの内容を置き換える場合があります。リモート設定をローカルで編集した場合は、更新前にコピーを保存してください。更新後の内容を、エディターで保存できなかった結果と取り違えずに済みます。

ルールを保存したのに、どのサイトも同じポリシーで接続されるのはなぜですか？

まずConfigで、保存したファイルが有効になっていることを確認します。次にHome → Global RoutingでConfigを選びます。その後、FINALが末尾にあることを確認し、既存のテスト接続を終了して新しいリクエストを送信し、実際の照合ログを確認してください。

[Host]を追加したのに、Webページが開かないのはなぜですか？

まずマッピング値と、自分のサーバーの実際のアドレスを1文字ずつ照合します。次に、利用中のネットワークから接続先アドレスとポートに到達できるか確認してください。HTTPSの443番ポートを使う場合は、サイトの証明書も確認します。本文中の192.0.2.10は構文説明用で、実際のサービスアドレスには使えません。

サブスクリプションを更新しても、新しいルールが表示されないのはなぜですか？

Homeでサーバー一覧を確認し、Configでルールファイルを確認します。サーバーサブスクリプションの更新は設定ファイルの更新とは異なります。[Rule]を変更する場合は、有効になっている設定ファイルを編集してください。ルールをサーバーアドレス欄に貼り付けないでください。

設定を変更した後、切断しても自動で再接続するのはなぜですか？

Settings → On Demandで現在の条件を確認します。手動で比較テストをする場合は、関連する自動接続条件を一時停止して検証し、終了後に元の設定へ戻してください。On Demandは接続を開始する条件を制御する機能であり、[Rule]の順序は変更しません。

原因を特定できない場合は、バックアップ設定に戻し、同じサーバー、同じネットワーク、同じテスト対象を使ってください。バックアップでは動作し、編集版で失敗する場合は、変更点を1つずつ追加して確認します。両方で失敗する場合は、ルールの対象範囲をさらに広げるのではなく、サーバーへの接続と接続先サービスを優先して調べてください。診断情報を他の人に共有する前に、サブスクリプションURLのトークン、認証情報、その他の個人データを削除してください。

全般設定に問題がある場合：[General]を元の値に戻します。
接続先が想定と異なる場合：Global Routing、現在のファイル、ルールの順序、ポリシー名を確認します。
特定のドメインだけ名前解決できない場合：[Host]、DNSキャッシュ、新しい接続での名前解決結果を確認します。
リクエストが繰り返しリダイレクトされる場合：追加した[URL Rewrite]を無効にし、1件ずつ戻してテストします。