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

1. .confのセクション構成と反映の前提

Shadowrocketの.confは、セクションごとに構成されたテキスト形式の設定ファイルです。角括弧内の名前がセクションを示します。たとえば[General]がその例です。セクション名の後から次のセクションが始まるまでの内容が、そのセクションに属します。セクションごとに構文は異なり、Generalは主にキーと値、Ruleはカンマ区切りのルール、Hostは名前とアドレスの対応付け、URL Rewriteはマッチ条件、置換先、アクションで構成されます。

Homeでは接続項目の選択と接続状態を確認し、Configではルール設定ファイルを管理します。Settingsにはアプリの設定があります。サービスのサブスクリプションを追加しても、.confが有効になるわけではありません。同様に、.confを選択しても、利用可能な接続サービスが自動的に用意されるわけではありません。この記事では設定ファイルの構造のみを扱い、サービスの入手先には触れません。

Ruleの振り分け結果を確認するには、まずHomeでGlobal RoutingがConfigになっていることを確認します。ProxyとDirectは全体のルーティング方法が異なるため、Config内のルールが適用されたかどうかの確認には使えません。Sceneを使う場合は、そのSceneで実際に選択されているルーティング設定も確認してください。以下は問題を調べる手順であり、4つのセクションが内部で必ずこの順に処理されるという意味ではありません。

2. General：全体設定と振り分けルールの違い

[General]には、DNS関連の設定など、全体に適用される項目を記述します。一般的な形式はパラメーター名 = 値です。Ruleのカンマ区切り構文をそのまま記述することはできません。以下はシステムのDNSを使う記述例です。キーと値の構造を説明するためのもので、すべてのネットワーク環境に同じDNS設定を推奨するものではありません。

[General]
dns-server = system

dns-serverはアプリのDNS処理に影響しますが、すべてのリクエストの接続先を指定する設定ではありません。DNSは「名前に対応するアドレス」を解決し、Ruleは「リクエストに適用するポリシー」を決めます。両者には関係がありますが、同じ設定ではありません。アプリのキャッシュ、暗号化DNS、接続でドメイン名が送信されるかどうかも、確認できる結果に影響します。Webページが開けることだけを根拠に、DNS設定が想定どおり反映されたとは判断できません。

• 変更前に、現在のdns-serverの値をすべて記録してください。DNS、ルール、接続項目を同じタイミングで変更するのは避けましょう。
• キー名をコピーするときは英字の綴りと半角記号を保ち、=を全角文字に置き換えないでください。
• 同じキーには明確な設定を1つだけ残し、重複したキーのどちらが優先されるかに頼って管理しないでください。
• 意味の分からないパラメーターは、まず元のまま残してください。別の設定形式で使われている同名のパラメーターが、そのまま利用できるとは限りません。

変更後に多くのドメインで名前解決に失敗する場合は、まず直前に変更したGeneralの設定を元に戻し、同じネットワークと接続項目で再テストしてください。この場合、Ruleの対象を広げてもDNSの問題は通常解決せず、調査すべき要因が増えるだけです。

3. Rule：最初に一致したルールを適用し、FINALは末尾に配置

[Rule]のルールは上から順に照合されます。一般的な書式は種類,マッチ条件,ポリシーです。FINALにはマッチ条件がなく、ほかのルールに一致しなかったリクエストを処理します。具体的なルールを広範囲に一致するルールより前に置き、最後にフォールバックルールを配置します。

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

この例のexample.comと192.0.2.0/24は、文書で使う例示用の値です。1行目は、このドメインとサブドメインにPROXYを適用します。2行目は、例示したアドレス範囲に一致するリクエストにDIRECTを適用します。no-resolveは、このIPルールのためにドメイン名の名前解決を積極的に行わない指定です。アプリ全体のDNSを無効にするものではありません。

DOMAIN-SUFFIX,example.com,PROXYはnotexample.comには一致しません。文字列の一部に含まれているだけで一致するルールでもありません。GEOIP,CN,DIRECTは接続先IPとデータベース上の分類に基づいて判定され、Webページの言語、ドメインの末尾、サービス提供者の登録地では判定しません。リクエストが上位のドメインルールに一致した場合、下位のGEOIPルールはそのリクエストのポリシーを変更しません。

4. Host：名前の対応付けはプロキシやリダイレクトではない

[Host]はローカルで名前とアドレスを対応付けるためのセクションです。以下では、例示用ドメインを文書用の予約アドレスに対応付けています。構文を示すための例であり、実際のアクセスには使用できません。ネットワーク接続の確認先としてこの例を使わないでください。

[Host]
lab.example.com = 192.0.2.10

Hostが変更するのは、名前に対応するアドレスです。ブラウザーのアドレスバーに表示されるURLは変更されず、リクエストが自動的にDIRECTになるわけでもありません。適用されるポリシーは、現在のルーティング方法、Rule、利用可能なドメイン名やアドレス情報を踏まえて判断します。ドメインルールとアドレスルールの両方がある場合は、名前の対応付け後にIPだけで振り分けられると決めつけず、新しいリクエストの記録で結果を確認してください。

• この行ではポートを指定しません：https://lab.example.com/へのアクセスでは通常443番ポート、http://lab.example.com/では通常80番ポートが使われます。Hostの対応付けで443番ポートが別のポートに変更されることはありません。
• 証明書の名前は引き続き検証されます：HTTPS接続では証明書に記載されたドメイン名が検証されます。名前を別のサーバーに向けても、ドメイン名が一致しない証明書が有効になるわけではありません。
• キャッシュが確認を妨げることがあります：既存の接続やアプリ内のキャッシュにより、古い結果が引き続き使われる場合があります。保存後は古いページの接続を終了して、新しいリクエストを送信してください。
• すべての名前解決がこの対応付けを通るとは限りません：アプリが独自に名前解決する場合や、IPアドレスを直接使う場合は、想定したHostの効果を確認できないことがあります。

まず自分で管理するテスト用ドメインでHostの動作を確認し、設定を残すか判断してください。接続ポリシーを変更する場合はRuleを編集します。WebページのURLを別のURLに置き換える場合は、Hostの項目を増やすのではなくURL Rewriteを確認してください。

5. URL Rewrite：URLを照合して指定したアクションを実行

[URL Rewrite]は、確認できるURLのうち条件に一致したものを処理します。以下はHTTPからHTTPSへの302リダイレクト例です。最初の部分が正規表現、次が置換先のURL、最後の302がアクションです。URLの照合とHTTPSで暗号化された内容の境界を分かりやすくするため、入力にはHTTPを使用しています。

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

1. ^はURLの先頭から照合する指定です。同じ文字列が途中に現れただけで一致するのを防ぎます。
2. example\.comのバックスラッシュは、ドットを文字どおりのピリオドとして扱うためのものです。エスケープされていない.は、正規表現ではより広い意味になります。
3. (.*)はドメイン名の後のスラッシュ以降をキャプチャし、置換先の$1は最初のキャプチャ結果を参照します。
4. 302はリダイレクトを返す指定です。アプリがリダイレクトに従うかどうかは、アプリ自身のHTTP処理にも左右されます。

たとえばhttp://example.com/docs?a=1を入力すると、このルールで作られる遷移先はhttps://example.com/docs?a=1です。遷移先に該当ページがあることや、HTTPS接続に成功することを保証するものではありません。ルールが変更するのはリクエストの処理方法です。サーバーの証明書、パス、アクセス権限は別途満たす必要があります。

URL Rewriteは、ドメイン単位で振り分ける方法の代わりにはなりません。ドメイン全体にポリシーを適用する場合はRuleを使います。特定のリクエストをブロックする場合は、ドメイン単位で拒否するのか、URL単位で処理するのかを先に整理し、異なる階層の構文を同じセクションに混在させないでください。

6. 変更を反映する：保存、選択、新しい接続で確認

「ファイルを保存したこと」と「そのファイルを使用中であること」は別です。特にConfigに複数のローカルファイルやリモート設定がある場合、コピーを編集しても、実際には古い設定が使われていることがあります。リモート設定の更新でローカルの変更が上書きされる場合もあるため、まず判別しやすい名前でローカルにバックアップを作成してから試してください。

1. 現在の状態を記録：Homeで選択中の接続項目、Global Routingの設定、Configで選択中のファイルを記録します。
2. バックアップして1項目ずつ編集：Configで元のファイルを複製し、1つのセクション内の1項目だけを変更します。テスト用のルールは行頭に#を付けてコメントアウトし、セクション全体を削除しないでください。
3. 保存後に有効な項目を確認：Configに戻り、編集したファイルが選択されていることを確認します。編集画面を開いただけでは不十分です。
4. Configで検証：Homeに戻り、Global RoutingがConfigになっていることと、選択中の接続項目が利用可能であることを確認します。
5. 新しい接続で確認：古いページやセッションを終了してからアクセスします。必要に応じて手動で切断し、再接続してください。既存の接続に依存しない状態でテストできます。
6. 結果を記録して元に戻す：対象ドメイン、接続先アドレス、一致したルール、実際に適用されたポリシーを確認します。結果に問題がある場合は、直前に変更した項目を元に戻し、同じ条件で再テストしてください。

「更新」は2種類に分けて考える必要があります。Homeでのサービスサブスクリプション更新は、主に接続項目を変更します。Configでのリモート設定の更新は、GeneralやRuleなどのテキスト内容を変更する場合があります。どちらも「設定の更新」とまとめて、同じ効果だと考えないでください。更新前に対象を確認し、更新後は内容と選択状態をチェックします。

Settings → On Demandで管理するのは自動接続の条件であり、Ruleのマッチ条件ではありません。手動で切断したあと自動的に再接続する場合は、まずOn DemandとシステムのVPN設定を確認してください。.confが保存されていないとは限りません。反対に、自動接続に成功しても、新しいルールが適用された証明にはなりません。

7. よくある質問：ファイルを読み込めても、結果が想定と違うのはなぜ？

.confが正しいかどうかは、ファイルを読み込めるかだけでは判断できません。セクション名とフィールドで構文が読み取れるか、選択中の項目とルーティング方法で処理対象になっているか、新しいリクエストの記録で実際の動作を確認します。この順に確認すれば、「記述ミス」「有効化されていない」「リクエストが条件に一致していない」を切り分けやすくなります。