Shadowrocketの設定ファイル構成を解説：.confのGeneral・Rule・Host・URL Rewriteの役割

この記事の概要

Shadowrocketの.confファイルでは、接続環境、ルールによる振り分け、静的なドメインマッピング、URLの書き換えを設定できます。自分の接続設定があり、振り分けを変更したい方向けに、まず4つのセクションを確認し、最小限の例で構文をチェックします。その後、Configで編集済みファイルを選択し、Homeで実際の適用結果を確認します。接続パラメータと振り分け用ファイルは別々に確認してください。ファイルを保存しただけでは、そのファイルに切り替わっていません。

1. ファイルと接続パラメータを区別する

Home、Config、Settingsでは、それぞれ異なる内容を管理します。Homeでは登録済みの接続を選択し、接続状態やGlobal Routingを確認します。Configでは設定ファイルとルールを管理し、Settingsではアプリの設定を行います。たとえばSettings → On Demandでは、オンデマンド接続の条件を設定できます。問題を調べる際は、変更したいのが「接続するタイミング」「接続先」「リクエストの処理方法」のどれなのか、まず確認しましょう。

一般的なサブスクリプションの更新で管理されるのは主に接続項目であり、現在の.confにあるRuleセクションの更新とは異なります。設定ファイルをリモート更新すると、ローカルでの変更が上書きされることもあるため、編集前にローカルコピーを保存してください。この記事では、利用者自身が接続サービスとサブスクリプションを用意していることを前提に、ファイル構成と確認方法を説明します。

セクション	主な役割	代替できない内容
`[General]`	DNSやIPv6などの基本動作を設定	個別ドメインの振り分けルール
`[Rule]`	ドメインやIPなどの条件でポリシーを選択	接続項目の認証パラメータ
`[Host]`	指定したドメインに静的アドレスを割り当て	サーバー側の証明書とサイト設定
`[URL Rewrite]`	URLに一致する条件でリダイレクトなどを実行	通信をPROXYへ振り分けるルール

角括弧内のセクション名は構文の一部なので、英語表記のまま残してください。一般的にはGeneral、Rule、Host、URL Rewriteの順に記述すると読みやすくなりますが、この順に処理されるわけではありません。特に順序に注意が必要なのはRule内のルールです。ファイル全体が「先頭から末尾へ順番に実行される」と考えないようにしましょう。

2. General：基本的な接続動作

Generalでは、「キー = 値」の形式がよく使われます。編集時は半角の記号を使い、真偽値にはtrueまたはfalseを指定してください。項目の値の後ろに日本語の説明を書き足さないでください。以下は各項目を理解するための例で、すべてのユーザーが既存の設定を置き換えるための汎用テンプレートではありません。

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

Generalの項目

bypass-system: true：システム関連の通信をアプリがバイパスする動作を維持します。
dns-server: system：現在のネットワークが提供するシステムDNSを使用します。
ipv6: false：設定上でIPv6を無効にします。通信事業者のネットワークを修復する設定ではありません。

まず元の値を記録し、変更は一度に1項目だけにして、同じ対象を繰り返しテストしてください。

Ruleのキーワード

DOMAIN-SUFFIX: 完全なドメイン名とそのサブドメインに一致します。
IP-CIDR: IPv4アドレスの範囲に一致します。
FINAL: それまでのルールに一致しなかったリクエストを処理します。

Generalは基本動作を定義し、Ruleはリクエストに適用するポリシーを決めます。互いに代用できません。

dns-server = systemを指定しても、現在のネットワークのDNSが必ず使えるとは限りません。これは名前解決に使うDNSを指定する設定です。接続テストには応答があるのにドメインへアクセスできない場合は、Ruleの最終ポリシーだけを変更するのではなく、まず名前解決の結果を確認してください。接続テストで遅延時間が返っても、対象サイトのDNS、TLS、HTTPリクエストがすべて正常だとは限りません。

ipv6 = falseも、あらゆるWebページの問題を直す設定ではありません。IPv4とIPv6では到達性やプロキシの接続先、対象アドレスが異なる場合があります。元のファイルで利用環境に合わせてIPv6が設定されている場合は、まずその設定を維持し、再現可能な接続先で項目ごとに比較してください。

3. Rule：マッチ条件とポリシー

Ruleの一般的な形式は「種類,マッチする内容,ポリシー」で、各項目は半角カンマで区切ります。通常は上から順に照合し、一致した時点で対応するポリシーが適用されます。FINALには追加のマッチ条件がなく、最後に記述して残りのリクエストを処理します。以下の例では、指定ドメインをPROXYへ振り分け、ドキュメント用のIP範囲とGEOIPがCNのアドレスをDIRECTへ、それ以外もDIRECTへ振り分けます。

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

DOMAIN-SUFFIX,example.com,PROXYは、example.comとそのサブドメインに一致します。この文字列を含むすべてのドメインに一致するわけではありません。
IP-CIDRはアドレス範囲に一致します。例にある192.0.2.0/24はドキュメント用のアドレスであり、接続可能なネットワークとして使うものではありません。
no-resolveは、このIPルールのために追加のドメイン解決を行わないことを示します。設定全体のDNSを無効にする指定ではありません。
GEOIP,CN,DIRECTは、IPの地理情報データベース上の分類に基づいて一致します。Webページの言語やドメインの末尾、ユーザーの現在地で判定するものではありません。
FINAL,DIRECTは、一致しなかった通信をDIRECTへ振り分けます。FINAL,PROXYに変更すると、一致しなかったすべてのリクエストの接続先が変わります。

より具体的な例外は、通常、範囲の広いルールより前に記述します。たとえば、特定のサブドメインをDIRECTへ、それ以外の同一ドメインをPROXYへ振り分ける場合は、先にDOMAIN,static.example.com,DIRECTを書き、その後にDOMAIN-SUFFIX,example.com,PROXYを記述します。順序を逆にすると、サブドメインが上位のサフィックスルールに先に一致することがあります。

4. Host：静的なドメインマッピング

Hostは「ドメイン = アドレス」の形式で記述し、固定アドレスがわかっている場合に使います。Ruleとは役割が異なり、Hostは「このドメインをどのアドレスに解決するか」、Ruleは「このリクエストにどのポリシーを適用するか」を設定します。一方だけを変更しても、もう一方が自動的に連動するわけではありません。

[Host]
lab.example.com = 192.0.2.10

上記のドメインとアドレスは構文の説明用です。192.0.2.10はドキュメント用アドレスで、利用可能なサービスではありません。実際に設定する際は、有効性を確認したアドレスを使い、対象サーバーがそのドメインへのリクエストを正しく受け取れることを確認してください。

静的マッピングは、接続先サイトのアドレスが変わっても自動更新されません。サイトの移転後に接続失敗が続く場合があります。
複数のドメインが同じIPを使っていても、互いに置き換えられるとは限りません。HTTPSでは、ドメイン、証明書、サーバーのサイト設定が一致している必要があります。
Webページは画像、スクリプト、API用のドメインにもアクセスすることがあります。メインページのドメインだけをマッピングしても、すべてのリソースが同じアドレスを使うとは限りません。
テスト用のマッピングを削除した後は、関連する接続を再確立してください。既存の接続が古い設定を使っている結果を、新しい設定が無効だと誤認しないようにします。

証明書エラーが発生しても、検証を無効にして誤ったマッピングを隠さないでください。まず追加したHostの行を削除して元の名前解決に戻し、対象ドメインの証明書とサーバーアドレスを確認します。頻繁にアドレスが変わる一般公開サイトでは、アドレスの長期的な固定が保守の負担になることがあります。

5. URL Rewrite：書き換えと振り分けを区別する

URL Rewriteは、URLのマッチ式に基づいて指定したアクションを実行します。DOMAIN-SUFFIXのようなRuleの構文は使いません。以下は正規表現でHTTPのURLに一致させ、HTTPSのURLへ302リダイレクトする例です。構成を示すためのもので、そのまま実運用に使えるルールではありません。

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

ここでの^はURLの先頭からの一致を指定し、\.は文字としてのピリオドを表します。末尾の302はリダイレクトのステータスコードです。この単純な例では、一致したリクエストを固定のURLへリダイレクトしますが、元のパスやクエリパラメータは引き継ぎません。パラメータを維持する必要があるログイン、決済、APIのリクエストには使用しないでください。

確認項目	Rule	URL Rewrite
マッチ対象	ドメイン、宛先IPなどの条件	処理対象となるリクエストURL
実行例	DIRECTまたはPROXYを適用	302を返し、別のURLへ転送
よくある問題	範囲の広いルールが先に一致する	正規表現の範囲が広すぎる、パスが失われる、リダイレクトがループする

HTTPSのパスやクエリパラメータは暗号化されたリクエストに含まれるため、通常の振り分けでは読み取れません。HTTPSリクエストの内容を書き換えるには、別途HTTPS復号の設定、証明書の信頼設定、対象ドメインの管理が必要です。URL Rewriteを1行追加するだけでは実現できません。振り分けだけを確認する場合、この例のためにHTTPS復号を追加設定する必要はありません。

6. 保存後にConfigで反映する

編集後は、「ファイルが保存されていること」と「そのファイルが現在使用されていること」の両方を確認してください。ファイルがリストに表示されても、存在が確認できるだけです。また、HomeのGlobal RoutingがProxyまたはDirectのままでは、アクセス結果からRuleが想定どおりに動作したとは判断できません。以下は、既存ファイルを小規模に変更する場合の手順です。

元のファイルを残す

Configを開き、現在選択されているファイルを記録してから、ローカルコピーを保存します。リモート更新されたファイルの場合は、次回の更新で変更が上書きされないよう、テストには別のコピーを使ってください。
コピーを編集する

Configでコピーの編集画面を開き、対象のセクションだけを変更します。角括弧、半角カンマ、等号、ポリシー名を確認してください。保存後、もう一度開いて内容を確かめます。
設定を選択する

Configのファイル一覧に戻り、編集したファイルを選択します。選択マークが、元ファイルや名前の似た別のリモートファイルではなく、コピーに付いていることを確認してください。
モードを切り替える

Home → Global Routing → Configを開き、Homeで現在選択されている接続項目も確認します。必要に応じて再接続し、以降のリクエストに新しい設定を適用してください。
リクエストを検証する

まずHome → Connectivity Testで接続を確認し、同じ対象に再度アクセスします。接続ログでドメイン、マッチしたルール、ポリシーを確認してください。失敗した場合は元のファイルに戻して再テストします。

Config

Proxy

アプリが処理し、バイパスされていない通信をプロキシへ振り分けます。Ruleに従って個別に振り分ける動作とは異なります。システムによるバイパスなどの基本動作は別途考慮してください。

適した用途：一時的に接続の可否を比較し、プロキシの問題と振り分けの問題を切り分ける。

Direct

直結モードを使用します。この状態で対象にアクセスできても、現在の直結経路が使えることを示すだけで、PROXY項目や指定したプロキシルールが正常だとは判断できません。

適した用途：同じ対象への直結結果を比較し、問題の範囲を特定する。

Sceneを使用している場合は、そのSceneに実際に関連付けられている設定とポリシーを確認してください。ファイル名だけで適用範囲を判断しないでください。変数を減らすため、この記事のルールを初めて検証するときは、明示的にConfigモードを選択できます。On Demandは自動接続の条件を管理する機能で、ドメインがどのRuleに一致するかは決めません。

7. よくある質問と切り戻しの確認

FINALを変更したのに、Webサイトの経路が変わらないのはなぜですか？

まずHome → Global RoutingがConfigになっているか確認し、次にConfigで選択中のファイルを確認してください。FINALが処理するのは、それ以前のルールに一致しなかったリクエストだけです。すでにDOMAIN-SUFFIXやGEOIPに一致している場合、FINALを変更してもそのリクエストには影響しません。接続を再確立してからログを確認してください。

保存時に形式が正しくないと表示された場合、まず何を確認すればよいですか？

まず、セクション名が角括弧で正しく囲まれているか、Ruleで半角カンマを使っているか、GeneralとHostで等号を使っているか確認してください。今回追加した部分を一時的に削除し、既存の内容を保存できることを確かめてから、1行ずつ戻します。複数の場所からコピーした大量の設定を一度に追加しないでください。

更新後に手書きのルールが消えたのはなぜですか？

まず、更新したのがHomeのサブスクリプション項目なのか、Configのリモートファイルなのかを確認します。リモートファイルの更新によって本文が置き換わることがあります。保存しておいたローカルコピーからルールを戻し、必要な新しい内容を項目ごとに統合してください。接続項目の更新をルールのバックアップと混同しないようにしましょう。

遅延は表示されるのにWebページが開かない場合、ファイル全体を書き換える必要がありますか？

すぐにファイル全体を書き直す必要はありません。今回追加した Host と URL Rewrite をいったん取り消し、DNS の名前解決、実際に適用されたポリシー、接続先の状態を確認してください。Connectivity Test で遅延が返っても、確認できるのはテスト対象の経路だけです。実際の Web ページへのアクセス確認の代わりにはならないため、必要に応じてトラブルシューティングを続けてください。

信頼できる変更記録には、少なくとも元ファイル名、変更した項目、テストしたドメイン、Global Routingのモード、実際の結果を残してください。この5点を記録しておけば、次回問題が起きたときにすぐ切り戻して再現できます。DNS、ルール、接続項目を同時に変更して原因がわからなくなるのを防げます。用語を確認するには用語集をご覧ください。接続に問題がある場合は、接続トラブルシューティングに沿って確認してください。