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

この記事の概要

Shadowrocketの設定ファイルは、各種パラメータやルール、URL処理をまとめるもので、サーバーのサブスクリプションとは別のものです。利用するサービスの情報をすでに持っていて、.confファイルを読んだり編集したりする方を対象に、4つのセクションの見分け方、Configへの読み込み・編集・選択方法、Global Routingと接続ログでの確認方法を解説します。

1. 設定ファイル・接続情報・動作モードの違い

.confはテキスト形式の設定ファイルです。セクション名は角括弧で囲み、その下に対応する内容を記述します。[General]にルールを書いたり、[Rule]にDNSパラメータを記述したりしても、意図した設定にはなりません。ファイルを読むときは、まずセクション名を確認してから各行の構文を見ましょう。ドメイン名だけを検索して、そのまま貼り付けて変更するのは避けてください。

4つのセクション

General、Rule、Host、URL Rewriteを解説

3つの画面

Homeは接続、Configは設定ファイル、Settingsはアプリ設定を管理

最後の1行

FINALはルール一覧の最後に置くフォールバック

この記事では、利用するサービスの情報をすでにお持ちであることを前提に説明します。Homeのサーバー情報は接続先やポート、認証方式を示し、Configのファイルはリクエストの振り分け方法を定義します。設定ファイルを読み込んでも、不足しているサーバー情報が自動で補われるわけではありません。また、サーバーのサブスクリプションを更新しても、現在選択中の設定ファイルが更新されるわけではありません。

Home：登録済みのサーバー情報と接続先を確認し、Global Routingを確認します。
Config：設定ファイルの読み込み、選択、編集を行います。一覧に表示されていても、選択中とは限りません。
Settings：アプリの設定を変更します。たとえばSettings → On Demandでオンデマンド接続の条件を管理できます。On Demandはルールによる振り分けの代わりにはなりません。

2. [General]：全般パラメータをキーと値で記述

[General]では、キー = 値の形式で記述します。DNSなどの全般パラメータを設定するセクションであり、DOMAIN-SUFFIXルールは記述しません。問題を調べるときは、まず変更前の値を記録し、一度に1項目だけ変更してください。DNS、ルール、接続先を同時に変えると、どの変更が影響したのか判断しにくくなります。

[General]
dns-server = system

この例では、DNSにシステムが提供する名前解決サーバーを使用します。ただし、あらゆるネットワーク環境に適した設定とは限りません。ネットワーク自体に名前解決の問題がある場合、systemのままにしても自動で解決するわけではありません。別のDNSサーバーを指定する場合は、利用可能であることを確認したアドレスを、アプリが対応する形式で記述してください。

パラメータ行の確認ポイント

セクション名: [General]
パラメータ名: dns-server
代入記号: 半角の英字 =
この記事の例の値: system

まずパラメータを記述するセクションを確認し、値の形式と実際のネットワーク環境を照合します。

ルール行の確認ポイント

セクション名: [Rule]
ルールの種類: DOMAIN-SUFFIX
照合する内容: example.com
適用するポリシー: PROXY

ルールの各項目は半角カンマで区切ります。パラメータ行のように等号で記述する形式ではありません。

「設定を完全にする」ために、ネット上で見つけたパラメータをすべて追加する必要はありません。内容を説明できる設定だけを残しましょう。IPv6やタイムアウトなどの動作を変更する場合は、出所の分からない数値を流用せず、アプリ内の説明と対応パラメータの値を確認してください。

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

[Rule]では、リクエストに適用するポリシーを指定します。ルールは上から順に照合され、一致した時点で対応するポリシーが適用されます。そのため、範囲の狭い例外は、通常、より広い範囲のルールより前に置きます。以下は構文の例です。example.comはサンプルのドメイン名なので、実際の接続先に合わせて変更してください。

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

キーワード	この例で照合する対象	確認ポイント
`DOMAIN`	login.example.comと完全一致	この例外は、後続のドメインサフィックスルールより先に処理されます。
`DOMAIN-SUFFIX`	example.comとそのサブドメイン	URLのパス、スキーム、ポートは記述しません。
`IP-CIDR`	192.168.0.0/16のアドレス範囲	`no-resolve`を指定すると、このIPルールのためだけにドメイン名の名前解決が行われるのを防げます。
`GEOIP`	IPジオロケーションデータベースでCNに分類されるアドレス	ドメインのサフィックスではなく、IPデータベースに基づいて判定します。
`FINAL`	前のルールに一致しなかったリクエスト	最後に配置します。後ろに記述したルールは、通常、照合される機会がありません。

この例では、login.example.comへのアクセスは最初の行に一致し、DIRECTが適用されます。一方、www.example.comは2行目に一致してPROXYが適用されます。最初の2行を入れ替えると、ログイン用ドメインも先にサフィックスルールに一致し、1行目の例外が機能しなくなります。

4. [Host]：ドメインのマッピングとプロキシルールは別の設定

[Host]では、ドメイン名にローカルのマッピングを指定します。「この名前がどのアドレスに対応するか」を定義するもので、[Rule]が定義する「このリクエストにどのポリシーを適用するか」とは役割が異なります。マッピングを追加した後も、該当するリクエストがどのルールに一致したかを確認してください。

[Host]
device.example.com = 192.0.2.10

192.0.2.10はドキュメント用の例示アドレスであり、接続可能な実機のアドレスではありません。ここでは「ドメイン名=アドレス」という形式を示しています。このままコピーしてもウェブページは開けません。実際に使う場合は、接続先として正しいことを確認したアドレスを指定し、現在のネットワークから到達できることも確認してください。

左側にはドメイン名を記述します。https://や/pathは付けません。
マッピングを設定しても、ブラウザーのアドレスバーに表示されるドメイン名は変わらず、HTTPS証明書の要件も自動で変更されません。
誤ったアドレスを指定すると、接続失敗や証明書の不一致が起こることがあります。マッピングの誤りを隠すために、証明書の検証を無効にしないでください。
アプリが独自の名前解決方法を使っている場合や、既存の接続が再利用されている場合は、設定変更がすぐに反映されないことがあります。新しい接続を試し、接続ログも確認してください。

明確なマッピングの必要がなければ、このセクションは記述しなくて構いません。問題の切り分けのために一時的に行を追加した場合は、確認後に削除するか元の値に戻してください。古いマッピングが残ると、接続先サーバーのアドレスが変わっても旧アドレスが使われ続けることがあります。

5. [URL Rewrite]：URLのパターンに応じてリクエストを書き換える

[URL Rewrite]では、URLの照合と書き換えを設定します。プロキシのポリシーを選択するものではありません。一般的な書式には、照合パターン、転送先URL、処理方法が含まれます。以下ではHTTP URLのリダイレクトを例に、文字列の先頭を示す方法、ドメイン内のピリオドをエスケープする方法、302による一時リダイレクトの構文を説明します。

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

目的に応じてセクションを選び、2種類のルールを混同しない

接続ポリシーを変更する場合

[Rule]を使います。
たとえば、example.comにPROXYを適用します。
接続ログで一致したルールとポリシーを確認します。

リクエスト先のURLを変更する場合

[URL Rewrite]を使います。
たとえば、一致したHTTP URLをHTTPSにリダイレクトします。
照合パターン、転送先URL、リダイレクトループの有無を確認します。

「どの経路で接続するか」と「どのURLにリクエストするか」は別の設定です。それぞれ個別に検証してください。

例の^は文字列の先頭を示し、\.はピリオドそのものに一致します。パターンの範囲が広すぎると、無関係なURLにも影響することがあります。また、転送先URLが元のルールに再度一致すると、リダイレクトループが発生する場合があります。HTTPSリクエストは暗号化されているため、ルールを1行追加するだけでパスを読み取って書き換えられるとは限りません。追加設定の要否は、具体的な処理方法によって異なります。この記事ではHTTPSの復号設定を扱いません。

6. Configでの読み込み・編集・有効化手順

現在使えているファイルを残してから、新しいファイルを読み込むか複製を編集してください。リモート設定のURLは、自分で信頼性を確認した提供元のものを使い、返される内容が設定テキストであることを確認します。ログイン画面やウェブページの説明文では設定ファイルとして使えません。トークンを含むURLは機密情報です。公開するスクリーンショットや問い合わせ記録には載せないでください。

元のファイルを保存

Configを開き、現在選択中のファイル名を記録して、元のテキストも別に保存します。後のテストで問題が起きた場合は元のファイルに戻せるようにし、状態が不明なまま変更を重ねないでください。
ファイルを読み込む

Configの右上にある「+」をタップし、手元にある設定ファイルのURLを入力して、Downloadからファイルを取得します。読み込み後は、一覧に表示されたファイルと実際の内容を確認してください。サーバーのサブスクリプションURLを.confファイルのURLと取り違えないようにします。
テキストを編集

Configで対象ファイルの右側にある情報ボタンを開き、Edit Plain Textに進みます。まずセクション名を確認し、行ごとに編集してください。画面の表示がローカライズされている場合は、現在表示されている該当の編集項目を選びます。
設定ファイルを選択

保存後にConfigへ戻り、対象ファイルをタップして選択マークが付いたことを確認します。Home → Global Routingに戻ってConfigを選択してください。テキストを保存しただけでは、ほかのモードが自動的にConfigへ切り替わることはありません。
もう一度動作を確認

Homeで登録済みの接続先が使えることを確認し、接続し直して対象ドメインと対象外ドメインを1つずつテストします。接続ログで接続先、ポリシー、一致したルールを確認し、必要に応じて元のファイルと比較してください。

リモート設定を更新すると、ローカルでの変更が上書きされることがあります。継続して使うルールは別のコピーに保存し、更新後に各セクションの内容を比較してください。設定ファイルにサーバー情報、認証情報、専用アドレスが含まれる場合は、共有前に項目ごとに削除してください。ファイル名を隠すだけでは不十分です。

7. Global Routingと接続ログで反映状況を確認

「読み込み済み」と「設定ファイルに従って振り分け中」は同じ状態ではありません。この記事の[Rule]の例を検証する場合は、まずGlobal RoutingがConfigになっていることを確認してください。ほかのモードは用途が異なるため、一時的にモードを切り替えた結果を、ルールファイルが反映された証拠として扱わないでください。

Config

推奨

現在の設定ファイルに記述されたルールに基づいてポリシーを決定します。この記事で紹介するドメインの例外、サフィックス照合、FINALによるフォールバックは、このモードで検証してください。

用途：この記事の振り分けルールを確認・編集・検証する。

Proxy

プロキシを利用できる通信をまとめてプロキシ経由にします。登録済みの接続先が使えるか確認するためのモードであり、この記事のルールを1つずつ検証する用途には向きません。

用途：ルールの影響を一時的に切り分け、プロキシ接続を確認する。

Direct

直接接続を使い、ネットワークの到達性を比較できます。このモードに切り替えてアクセス状況が変わっても、元の設定にあるドメインルールが誤っているとは限りません。

用途：現在のネットワークで直接接続できるか確認する。

Scene

設定済みのScene条件に基づいてルーティングを決定します。問題を調べるときは、設定ファイルだけでなく、Sceneの条件と実際に選択されているモードも確認してください。

用途：Sceneの切り替え条件を明確に設定し、把握している場合。

接続スイッチがオンかどうかだけでなく、確認できる結果を基にテストしてください。ブラウザーのキャッシュ、既存の接続、アプリごとのリクエスト方法が判定に影響することがあります。変更後は新しいリクエストを送り、接続ログも参考にしてください。以下の表はトラブルシューティングの手がかりであり、すべてのアプリで同じ動作を保証するものではありません。

確認された現象	まず確認する項目	次の手順
ルールを保存してもポリシーが変わらない	現在のファイルが選択されているか、Global RoutingがConfigになっているか	選択状態を確認して再接続し、新しいリクエストのログを確認します。
特定のドメインだけ接続できない	前方にあるDOMAIN、DOMAIN-SUFFIX、REJECTのルール	ファイルの順に確認し、最初に一致するルールを特定します。
ドメインが古いアドレスに名前解決される	Hostのマッピング、DNSキャッシュ、既存の接続	マッピングを元に戻し、新しい接続で比較します。
URLが何度もリダイレクトされる	URL Rewriteの照合範囲と転送先URL	該当する書き換えルールをいったん削除し、1行ずつ戻して確認します。
更新後に独自ルールが消えた	同名のリモート設定を更新したかどうか	ローカルのコピーに戻し、更新前後のテキストを比較します。

確認が終わったら、現在使っているファイル、リクエストに一致したルール、そのポリシーが適用された理由を説明できる状態を目指します。この3点を説明できてから、より複雑なルールを追加してください。マッピングや書き換えが不要なら、該当セクションは空のままにするか、追加しなくて構いません。