Shadowrocketの設定ファイル構成を解説：General・Rule・Host・URL Rewriteの書き方

.conf・サブスクリプション・現在の接続を区別する

.confは設定テキストです。角括弧で囲まれた見出しがセクションを示し、その下の内容が該当セクションに属します。[General]では主にキーと値の組み合わせを使い、[Rule]ではカンマ区切りのルール行を使います。すべてのセクションに同じ書式を当てはめることはできません。#で始まる独立した行はコメントとして使えます。コメントがパラメータ値に混ざらないよう、説明は別の行に記述してください。

Homeは接続、サーバーの選択、Global Routingの確認に使います。Configでは設定ファイルの管理と選択、Settingsではアプリの設定を行います。サブスクリプションは通常サーバー一覧の管理に使われます。サーバー項目が更新されたからといって、現在のルールファイルも置き換わったとは限りません。設定ファイルがリモートリソースを参照している場合は、更新元も確認してください。

Configで編集する前に、元ファイルのコピーを保存し、Homeで現在選択されているサーバーとGlobal Routingの状態を記録しておきます。ファイルを保存しただけでは、そのファイルが選択されて使われているとは限りません。設定ファイルを選択していても、すべての通信が必ず記載のルールに従うわけではありません。トラブルシューティングでは、「ファイルの内容」「現在の設定」「ルーティングの状態」を分けて確認してください。

[General]：全般設定はキーと値で指定

[General]では、設定全体の動作に影響するパラメータを指定します。以下は、システムDNSの使用、IPv6の無効化、システム通信のバイパスを例に、キー = 値の書式を示したものです。この組み合わせは構文例であり、あらゆるネットワークにそのまま適用できる設定ではありません。

[General]
# システムが提供するDNSを使用
dns-server = system

# IPv6を有効にするかどうか
ipv6 = false

# システム関連の通信をバイパスする
bypass-system = true

• dns-server = system：システムが提供するDNSを使用します。Wi-Fiを切り替えると、システムで利用できる名前解決環境が変わることがあります。2つのネットワークで必ず同じ結果になるとは限りません。
• ipv6 = false：この設定におけるIPv6の動作を制御します。ルーターやデバイス全体のIPv6を無効にする設定ではありません。接続にIPv6が必要な場合は、変更する前にサーバーアドレスと現在のネットワークを確認してください。
• bypass-system = true：システム通信のバイパス処理に関する設定です。特定のWebサイトをDIRECTに指定するルールではありません。Webサイトごとの振り分けは[Rule]で確認してください。

同じキーに、互いに競合する値を複数記述しないでください。2つの設定を統合する場合は、既存のキーを照合してから、どちらを残すか決めます。セクション全体をそのまま追加するのは避けてください。DNS関連の問題では、「サーバーのドメインを名前解決できない」場合と「接続先Webサイトのドメインを名前解決できない」場合を区別してください。影響する接続段階が異なります。

[Rule]：1行ずつ照合し、具体的な条件を先に記述

[Rule]では、リクエストに適用するポリシーを指定します。一般的な書式はルールタイプ,照合値,ポリシーです。FINALには照合値がなく、適用先のポリシーを直接指定します。ルールは記述順に確認されるため、先のルールに一致したリクエストが、後ろの広い条件で再度振り分けられることはありません。

[Rule]
# example.comとそのサブドメインに一致
DOMAIN-SUFFIX,example.com,PROXY

# ドキュメント用の予約済みアドレス範囲。実際のサービスアドレスではありません
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve

# 宛先IPの地域データベース上の判定に基づいて照合
GEOIP,CN,DIRECT

# それ以前のルールに一致しない場合に適用
FINAL,PROXY

PROXYはプロキシポリシーを示し、利用可能なプロキシの出口が別途必要です。DIRECTは直接接続を示します。独自のポリシーグループを使う場合、ルール末尾には実在する名前を指定してください。表記、スペース、大文字・小文字を確認します。存在しないグループ名をルールに書いても、対応する出口が自動で作成されるわけではありません。

このセクションを検証するには、Home → Global RoutingでConfigを選び、Configで編集中のファイルが使われていることを確認します。Proxyは全体をプロキシ経由にする状態、Directは全体を直接接続する状態です。Sceneは設定済みのシーンに従って処理されるため、Configの別名ではありません。ルールを1件ずつ検証する場合は、全体の接続モードやシーン切り替えの影響を先に除外してください。

[Host]：ドメインマッピングを変更する設定。出口の変更ではありません

[Host]では、ドメインに対応するアドレスを指定します。以下の例では、完全なホスト名をドキュメント用に予約されたアドレスへ割り当てています。書式はホスト名 = IPアドレスです。このアドレスにはWebサイトが配置されていないため、コピーしてリクエストが失敗しても想定どおりです。実際のサーバーが利用可能かどうかの判断には使えません。

[Host]
# 書式の説明用
portal.example.com = 192.0.2.10
api.example.com = 198.51.100.20

HostマッピングはHTTPリダイレクトでも、DOMAIN-SUFFIXルールでもありません。ブラウザーのアドレスバーには元のドメインが表示され、HTTPS証明書もリクエスト先のドメインと一致している必要があります。そのドメインの証明書がないサーバーを指定すると、ネットワーク接続が成功しても証明書エラーが発生することがあります。マッピングの問題を証明書エラーの無視で解決しようとしないでください。

検証時は完全なホスト名を使って新しいリクエストを送信してください。既存の接続が再利用されることがあるため、Webページが開いたままかどうかだけでは判断できません。マッピングを削除して正常に戻った場合は、より広いDIRECTルールを追加するのではなく、宛先アドレス、サーバーの待ち受け設定、証明書を確認してください。リモートプロキシ側でドメインを再度名前解決するかどうかは接続方式によって異なります。ローカルマッピングでリモート側の名前解決まで制御できると考えないでください。

[URL Rewrite]：URLに一致した場合に書き換えを実行

[URL Rewrite]ではURLの照合とアクションを指定します。[Rule]のカンマ区切り形式は使いません。以下の例では、HTTPアドレスを一時的にHTTPSへリダイレクトします。アクション内の302はリダイレクトのステータスコードであり、サーバーのポート番号ではありません。

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

1. ^はURLの先頭から照合することを示し、意図せずアドレスの途中に一致するのを防ぎます。
2. example\.comでは、バックスラッシュによってピリオドを通常の文字として扱います。正規表現で任意の1文字を表す記号にはなりません。
3. (.*)はドメイン以降の部分を捕捉します。置換先の$1は、その部分を参照します。
4. url 302はURLリダイレクトのアクションを指定します。書き換え後の新しいリクエストも、通常どおり名前解決、振り分け、接続が必要です。

書き換えによってサーバーの機能が補われるわけではありません。宛先サイトがHTTPSに対応し、有効な証明書を備えている必要があります。遷移先から元のアドレスへ再度戻る場合、リダイレクトループになることがあります。テストでは、まず特定のドメインに限定したルールを使い、最初からすべてのHTTPアドレスに広い正規表現を適用しないでください。

保存後の確認手順とよくある問題

4つのセクションは1つのファイルに共存できますが、機械的に実行される4段階の処理と考えてはいけません。Generalは全体の動作、Ruleはポリシーの照合、Hostはドメインマッピング、URL Rewriteは確認可能なリクエストURLの書き換えを担います。不具合は実際の症状に沿って切り分けてください。「最後のセクションが前のすべての設定を上書きする」とは限りません。

1. Configでコピーを保存してそのファイルを選択し、同じ名前の別設定を誤って選んでいないことを確認します。
2. Homeに戻り、サーバーが利用可能であることを確認してから、ルールによる振り分けを検証するためにGlobal RoutingをConfigに設定します。
3. 対象への新しいリクエストを送り、宛先ドメイン、想定するポリシー、実際の接続結果、エラーメッセージを記録します。必要に応じて関連するリクエストの記録も確認してください。
4. 直前に行った変更を1つ取り消し、もう一度テストします。変更とロールバックによって結果が安定して変わることを確認してから、次の設定を統合してください。

設定ファイルには、用途を説明でき、結果を検証できる設定だけを残してください。リモートルールを統合する前に、照合範囲、適用ポリシー、更新によってローカルの内容が上書きされるかを確認します。構文をさらに確認するにはルールリファレンスをご覧ください。初回接続の手順は使い方ガイドをご確認ください。