Shadowrocketの設定ファイル「.conf」の構造と読み方｜General・Rule・Host・URL Rewriteを解説

この記事の概要

Shadowrocketの.confはセクションごとに整理されたテキスト形式の設定ファイルで、サーバーのサブスクリプションではありません。まず角括弧で囲まれたセクション名を確認し、パラメータ、マッチ条件、ポリシーの順に読みます。適用時はHome → Global RoutingでConfigが選択されていることも確認してください。自分で用意した接続情報があり、設定の確認や編集を行う方を対象に、代表的な4つのセクションの役割、記述例、個別の検証方法を解説します。

1. セクション名を確認する。.confはサーバー一覧ではない

設定ファイルの内容は[General]や[Rule]などのセクション名で区切られます。各セクションの項目は、次のセクション名が現れるまでそのセクションに属します。角括弧、キー名のハイフン、ルール内の半角カンマはいずれも構文上の意味があるため、日本語の記号に置き換えないでください。[URL Rewrite]内のスペースもそのまま残します。

サーバー情報は「どこに、どのプロトコルと認証情報で接続するか」を示すものです。一方、設定ファイルは「どのように名前解決し、通信を振り分け、リクエストを書き換えるか」を定めます。ファイルにPROXYが記載されていても、利用可能なサーバー情報が含まれているとは限りません。以下では、利用者自身がサービス事業者やサブスクリプションを用意し、Homeでサーバーを選択済みであることを前提に説明します。

4つのセクションの役割とよくある誤解
セクション名	対象	代わりにはならないもの
`[General]`	DNS、IPv6などの全般設定	ドメインごとのルーティングルール
`[Rule]`	ドメインや宛先IPなどのマッチ条件とポリシー	サーバーアドレスと認証情報
`[Host]`	指定ドメインのローカル名前解決マッピング	HTTPリダイレクトまたは接続ポリシー
`[URL Rewrite]`	処理対象となるURLと書き換え処理	すべての暗号化通信の自動復号

以下の断片は構文を読み解くための例であり、既存ファイル全体を置き換えるための設定ではありません。example.comは例示用ドメイン、192.0.2.10は文書用に予約されたアドレス範囲です。実際のサービスのテストには使用しないでください。編集前に元のファイルを保存し、個人のアドレス、認証情報、サブスクリプションの認証情報を含む設定ファイル全体を公開しないようにしましょう。

2. General：全般設定を確認してからルーティングルールを編集

[General]では「キー名 = 値」の形式で記述します。以下は代表的な3つのパラメータの読み方です。すべてのネットワークに適した推奨設定の組み合わせではありません。特にDNSとIPv6の変更は、名前解決の結果やアドレス選択に影響する場合があります。一時的にアクセスできたからといって、設定が常に適切とは限りません。

[General]
dns-server = system
ipv6 = false
bypass-system = true

Generalのパラメータ

dns-server: systemはシステムのDNSを使用することを示します。
ipv6: falseは、この設定でIPv6を無効にすることを示します。
bypass-system: trueは、一部のシステム通信をバイパスすることを示します。

これらのパラメータは全般的な動作に影響し、ドメインごとにマッチするルールではありません。

Ruleのポリシー

PROXY: プロキシポリシーで処理します。利用可能なサーバーが別途必要です。
DIRECT: 直接接続し、プロキシサーバーを経由しません。
REJECT: マッチしたリクエストを拒否します。

全般設定とルールのポリシーは役割が異なります。問題を調べる際は、一度に変更する項目を1つに絞りましょう。

特定のドメインだけ接続経路が誤っている場合は、DNSをすぐに変更せず、まず[Rule]を確認します。複数のドメインで名前解決に失敗する場合は、dns-serverと現在のネットワークを確認してください。ipv6 = falseにしても、デバイスのほかのネットワーク設定が一括で変更されるわけではありません。デバイス上のすべてのアプリがIPv6を使わなくなるという意味でもありません。

3. Rule：上から順にマッチさせ、FINALは最後に置く

[Rule]は「ルール種別,マッチ条件,ポリシー」の形式が一般的です。FINALにはマッチ条件がなく、ポリシーを直接指定します。通常は上から順に確認し、最初にマッチしたルールが適用されるため、より具体的な例外を前に、最後にフォールバックルールを置きます。

[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,DIRECT：この完全一致のドメインだけにマッチし、次のサフィックスルールに対する例外になります。
DOMAIN-SUFFIX,example.com,PROXY：example.comとそのサブドメインにマッチします。サフィックスはドメイン境界で判定され、任意の文字列に含まれているだけではマッチしません。
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve：指定したIPv4ネットワークにマッチします。no-resolveは、このルールの判定だけを目的にドメインを積極的に名前解決するのを防ぎます。
GEOIP,CN,DIRECT：宛先IPの地理情報に基づいて判定します。Webページの言語やドメインのサフィックスによる判定ではありません。
FINAL,PROXY：先行するルールにマッチしなかった場合にプロキシポリシーを使います。リクエストの成功を保証するものではありません。

この順序では、api.example.comは先に完全一致ルールにマッチし、www.example.comはサフィックスルールにマッチします。最初の2つを入れ替えると、より広いサフィックスルールが先に適用され、完全一致の例外が機能しません。「ルールを追加したのに反映されない」と感じるよくある原因の1つです。

4. Host：名前解決の結果を変える。URLは変えない

[Host]では、指定したドメインを特定のアドレスにマッピングできます。以下の行は「このドメインをこのアドレスに名前解決する」という意味です。ブラウザーをIPアドレスにリダイレクトするものでも、DIRECTやPROXYを直接指定するものでもありません。

[Host]
lab.example.com = 192.0.2.10

名前解決先を変更しても、ブラウザーのアドレスバーにはlab.example.comが表示されたままです。HTTPSでは、リクエストで使うドメインとサーバー証明書が正しく対応している必要があります。別のサイトにしか応答しないアドレスにドメインをマッピングすると、証明書エラー、異なるサイトの表示、接続失敗が起きることがあり、目的のコンテンツが自動的に表示されるわけではありません。

「接続先アドレス」と「通信経路」を区別する

Hostの名前解決マッピング

完全なドメイン名が正しく記述されているか確認します。
マッピング先のIPが現在も該当サービスを提供しているか確認します。
HTTPSではドメインと証明書の要件も満たす必要があります。

Ruleのルーティングポリシー

ドメインルールとその並び順を確認します。
IPルールと、名前解決後のアドレスを確認します。
接続ポリシーはDIRECTまたはPROXYで指定します。

HostとRuleは併用できますが、マッピング先アドレスはポリシーの代わりにはなりません。また、ポリシーで誤ったマッピング先アドレスを修正することもできません。

ローカルマッピングは明示的な上書き設定です。サービスのアドレスが変更された場合は、設定を再確認してください。Hostを追加してから問題が起きた場合は、該当するマッピングを削除して保存し、接続をやり直して同じドメインを再テストします。DNS、ルールの順序、サーバーを同時に変更すると、どの操作で改善したのか判断できません。

5. URL Rewrite：マッチ式・転送先・処理をセットで確認

[URL Rewrite]ではURL書き換えルールを定義します。以下の例は、特定のHTTPドメインのルートパスをHTTPSへリダイレクトし、末尾の302で一時的なリダイレクトを指定します。構文とマッチ範囲を示す例であり、すべてのWebサイトに同じルールを適用するという意味ではありません。

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

マッチ式：^は先頭、$は末尾を指定します。\.はピリオドそのものを表し、ドメイン内のピリオドが正規表現のワイルドカードとして扱われるのを防ぎます。
転送先：https://example.com/はリダイレクト先です。この例では転送先を固定しており、ほかのパスやクエリパラメータは引き継ぎません。
処理：302はリダイレクトのステータスコードです。サーバーのポート番号でもプロキシのプロトコルでもありません。

式で末尾を指定しているため、このルールはhttp://example.com/docsやクエリ文字列付きのURLにはマッチしません。マッチ範囲を変更する前に、パスやパラメータを引き継ぐ必要があるか確認してください。すべてのリクエストを同じルートパスに転送すると、ログイン時のコールバック、検索結果、API呼び出しに支障が出る場合があります。

6. 有効化と検証：Configの選択状態を確認し、1項目ずつテスト

ファイルを保存した状態、ファイルを選択した状態、ルールがルーティングに適用されている状態は、それぞれ異なります。編集後はConfigで現在選択されているファイルを確認し、Homeに戻ってGlobal Routingを確認してください。以下ではShadowrocket内のルーティング状態を比較します。対象はアプリの処理範囲に入る接続であり、デバイス上のすべてのネットワーク通信を保証するものではありません。

Config

推奨

現在の設定ファイルのルールに従ってポリシーを選択します。マッチしなかったリクエストの経路はFINALの内容で決まるため、「それ以外は必ず直接接続」とは限りません。

適した用途：この記事のRuleの記述例の検証や、日常的なルールベースのルーティング。

Proxy

全体のルーティングをプロキシに設定し、Configの個別ルールによる経路選択を行いません。切り替えることで、ルールの選択に問題があるかを切り分ける参考になります。

適した用途：一時的にプロキシ経路と比較する場合。DOMAIN-SUFFIXのマッチ順の検証には適しません。

Direct

全体のルーティングを直接接続に設定します。この状態でWebサイトにアクセスできても、設定ファイル内のPROXYルールが有効である証明にはなりません。

適した用途：現在のネットワークで直接接続した場合の状態を確認し、プロキシ経路と接続先サービスの問題を切り分ける場合。

Global RoutingのSceneでは、シーンごとにルーティング動作を設定できます。Configと同じものではありません。設定ファイルを初めて確認するときは、まずConfigを選択してください。Settings → On Demandも有効な場合は、自動接続の条件を確認しましょう。自動再接続の結果を、ファイルを編集した効果と誤認しないようにしてください。

元のファイルを保存

Configを開き、現在使える設定のコピーを保存してから、テストするファイルを編集します。例の断片でファイル全体を置き換えないでください。
ファイルを選択

Configで変更を保存し、選択中の表示がどのファイル名に付いているか確認します。リモートファイルの場合は、次回の更新でローカルの変更が上書きされないかにも注意してください。
ルーティング状態を確認

Home → Global Routingを開いてConfigを選択し、Homeで選択されているサーバーが利用可能なものか確認します。
接続をやり直す

既存の接続の影響を除外するには、Homeで接続スイッチをいったんオフにしてからオンにし、対象のリクエストを再実行します。既存の接続を再利用しているページを更新するだけでは不十分です。
1項目ずつ再テスト

まずHome → Connectivity Testで接続の基本状態を確認し、次に対象のドメインをテストします。一度に変更するルールやパラメータは1つにし、結果を記録してください。

Connectivity Testの結果だけでは、アプリケーション層まで含めた検証にはなりません。テストに成功しても、特定のURL Rewriteが実行されたことや、特定のWebサイトのすべてのリソースに同じポリシーが適用されたことは証明できません。Webサイトは複数のドメインにリクエストすることがよくあります。メインページは表示されるのに画像が読み込めない場合は、関連するドメインを個別に確認し、広範なルールを追加するだけで済ませないでください。

7. よくある質問：ファイルは正しいのに動作が想定と違う

DIRECTを設定したのに、なぜプロキシ経由になるのですか？

まずHome → Global RoutingがConfigになっているか確認し、次に現在選択されている設定ファイルを確認します。そのうえで、該当ルールより上に、より広い範囲にマッチするDOMAIN-SUFFIXなどのルールがないか確認してください。具体的な例外ルールを広範なルールより前に置き、保存して接続をやり直してから再テストします。

サブスクリプションを更新すると、Ruleも自動で新しいルールに切り替わりますか？

サーバーのサブスクリプション更新と設定ファイルの更新は別のものです。Homeのサーバー一覧が変わっても、Configのルールファイルが更新されたとは限りません。サーバー一覧と現在の設定ファイルをそれぞれ確認してください。設定がリモートURLから取得されている場合は、更新前にローカルの変更を保存し、後から上書きされないようにします。

HostにIPを設定したのに、HTTPSでエラーになるのはなぜですか？

まず、そのIPが該当ドメインのサービスを提供しているか、サーバー証明書がそのドメインに対応しているかを確認します。Hostの項目を一時的に削除して接続し直し、同じURLに再度アクセスして比較してください。証明書検証を無効にしても、ドメインマッピングの問題は解決しません。

FINAL,PROXYを追加するだけで接続できますか？

できません。FINALが指定するのはフォールバックポリシーだけで、サーバーアドレス、ポート、認証情報は含まれません。まずHomeに自分で用意したサーバーがあり、選択されていることを確認してからConnectivity Testを実行してください。接続自体に失敗している場合、ドメインルールを追加しても通常は解決しません。

最終確認は、現在のファイル、Global Routingの状態、ルールの順序、DNSとHost、対象リクエストの動作の順に行います。ルールのキーワードについてはルールリファレンス、ルーティング状態の選択についてはルーティングモードの説明をご覧ください。複数の設定をまとめて置き換えるより、変更前後のファイルを保存しておくほうが、元に戻したり原因を特定したりしやすくなります。