Shadowrocketの設定ファイル（.conf）の構造：[General]・[Rule]・[Host]・[URL Rewrite]を解説

この記事の概要

Shadowrocketで自分の接続サービスを設定済みで、.confを読んだり編集したりする方が対象です。まず4つのセクションの役割を確認し、パラメータ、ルールの順序、ホスト名の解決、URLの書き換えを順に見ていきます。最後にConfigでファイルを選択し、結果を確認します。example.comやテスト用アドレスは構文の説明に使う例であり、接続サービスとしては利用できません。

1. .conf・接続情報・ルーティングを区別する

.confはテキスト形式の設定ファイルです。角括弧内の名前はセクション名で、フォルダではありません。各セクションは見出しから次の見出しの直前まで続きます。空行は主に読みやすさのために使われます。ルールを誤ったセクションに書くと、英単語のつづりが正しくても、アプリが意図どおりに解析するとは限りません。

Homeでは登録済みの接続項目、Configでは設定ファイル、Settingsではアプリの設定を管理します。サブスクリプションから読み込んだ接続情報と、現在選択中の.confは別のものです。接続リストを更新しても設定ファイルが切り替わるわけではなく、設定ファイルを保存してもGlobal RoutingがConfigに変わるわけではありません。

4つのセクション

General、Rule、Host、URL Rewriteを解説

2か所を確認

Configで選択中のファイルとHome → Global Routing

1件のルールに一致

Ruleは上から順に評価し、最初に一致したルールを適用

Global RoutingのConfigは、現在の設定ファイルに基づいてルーティングするモードです。ProxyとDirectは全体のルーティング方法を切り替え、Sceneはシーンごとに選択できます。この記事のRuleの例を確認するときは、まずConfigを選択してください。そうすることで、モードの違いをファイルの未保存と誤認しにくくなります。

2. [General]：全体設定はキーと値で記述

[General]では通常、キー = 値の形式を使います。Ruleのカンマ区切り形式とは異なります。このセクションではDNSサーバー設定など、全体の処理方法を指定します。ネットワーク設定をまとめて汎用的な最適化リストとして上書きしないでください。現在のネットワーク環境やDNS設定、ルールが名前解決に求める条件によって、適切な設定は異なります。

[General]
dns-server = system

この例はシステムDNSを使う記述方法を示すもので、すべてのネットワークで適切とは限りません。DNSの名前解決と接続の成功は別の段階です。接続先のアドレスを取得した後も、ルーティングの選択、接続の確立、アプリケーション層での通信が必要です。ウェブページを開けないときにDNSだけを変更し、その後の段階を確認しないと、根本的な原因を見落とすことがあります。

Generalの読み方

セクション名: [General]
パラメータキー: dns-server
値の例: system

まずパラメータの意味を確認し、等号の右側の値を変更します。

Ruleの読み方

セクション名: [Rule]
マッチ条件: DOMAIN,example.com
適用するポリシー: PROXY

ルールは種類、マッチする値、ポリシーの順に記述し、等号は使いません。

テキストを確認するときは、句読点にも注意してください。セクション名には半角の角括弧、パラメータには半角の等号、ルールには半角カンマを使います。全角カンマや全角スペース、リッチテキストからコピーした引用符は、見た目が似ていても別の文字列になることがあります。

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,DIRECT

キーワード	この例のマッチ対象	結果と注意点
`DOMAIN`	`api.example.com`と完全一致するドメイン	先にDIRECTが適用され、次のPROXYルールは使われません。
`DOMAIN-SUFFIX`	`example.com`とそのサブドメイン	それ以外のマッチするドメインにはPROXYを適用します。
`IP-CIDR`	`192.0.2.0/24`のアドレス範囲	DIRECTを適用します。このアドレス範囲はドキュメント用の例です。
`GEOIP`	アドレスデータベースでCNに分類される宛先IP	IPアドレスの分類に基づき、ウェブページの言語やドメインの末尾では判定しません。
`FINAL`	それまでのルールに一致しなかった通信	この例では、フォールバックにDIRECTを指定しています。

no-resolveは、このIPルールに一致させるためにドメイン名を積極的に名前解決しない、という意味です。アプリ全体のDNSを無効にするものではありません。リクエストに宛先IPがすでに含まれていれば、アドレス範囲で判定できます。この例のGEOIPにはこのオプションが付いていません。特定のルールに付いたオプションを、Ruleセクション全体の設定だと解釈しないでください。

PROXYはポリシーであり、サーバー情報を自動で作成するものではありません。利用可能な接続項目があらかじめ必要です。DIRECTは直接接続を意味しますが、現在のネットワークから宛先にアクセスできることを保証するものではありません。確認時は、適用されたポリシーと実際の接続結果の両方をチェックしてください。

4. [Host]：名前解決先を指定し、プロキシポリシーは指定しない

[Host]では、ローカルのホスト名解決を設定します。指定するのは「この名前がどのアドレスに対応するか」であり、「このリクエストをどの経路にするか」ではありません。以下では、例のドメイン名をドキュメント用のテストアドレスに割り当てます。このアドレスはウェブサービスを提供する公開サーバーではないため、アクセスできなくても構文の有効性は判断できません。

[Host]
lab.example.com = 192.0.2.10

設定するのはドメイン名とアドレスの対応です。URL全体を等号の左側に置くのではなく、https://やパスを含めないでください。
Hostではポート番号は変換されません。https://lab.example.com/にアクセスする場合、通常のHTTPSのデフォルトポートは443です。通常のHTTPのデフォルトポートは80です。
HTTPSでは証明書の検証も必要です。ドメイン名の解決先を別のサーバーにしても、そのサーバーの証明書が元のドメイン名に自動で一致するわけではありません。
マッピング後のルーティングはRuleと合わせて確認してください。このドメインにDIRECTを適用するには、RuleにDOMAIN,lab.example.com,DIRECTと明記し、対象を含む可能性のある広範なルールより前に配置します。

アプリ独自の名前解決キャッシュ、再利用中の接続、アプリが独自の暗号化DNSを使っている場合などは、テスト結果に変更が反映されないことがあります。変更後は古いページを閉じ、新しいリクエストを送信してください。必要に応じてShadowrocketの接続も再確立します。キャッシュの問題を特定する前にHost項目を次々と追加しないでください。

5. [URL Rewrite]：リクエストURLを書き換え、Ruleの代わりにはならない

[URL Rewrite]では正規表現でURLをマッチし、指定したアクションを適用します。以下は、例のドメインへのHTTPリクエストをHTTPSにリダイレクトする例です。末尾の302はリダイレクトのステータスコードであり、ポート番号でもプロキシポリシー名でもありません。

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

^はURLの先頭からのマッチに限定します。\.はドメイン名に含まれる実際のピリオドを表し、任意の文字をピリオドとして扱うのを防ぎます。
(.*)はスラッシュ以降の文字列をキャプチャし、転送先URLの$1で1番目のキャプチャ結果を参照します。
この正規表現では、http://example.com/docsのリダイレクト先はhttps://example.com/docsです。
リダイレクト後に発生する新しいリクエストにも、ルーティング設定が適用されます。URLをHTTPSに変更しても、ポリシーがPROXYに変わるわけではありません。

HSTSやキャッシュ済みのリダイレクトにより、ブラウザが最初からHTTPSを使うことがあります。その場合、例のHTTPルールが適用される機会はありません。テストでは「クライアントがHTTPリクエストを送信していない」場合と「書き換え式に誤りがある」場合を区別してください。アドレスバーに最終的にHTTPSが表示されることだけで、ルールが実行されたとは判断できません。

6. Configで保存・選択・検証する

ファイル編集の最後に必要なのは、エディタを閉じることではありません。どのファイルを保存したか、どのファイルが現在選択されているか、接続が再読み込みされたかを確認してください。ここでは、すでにあるローカル設定ファイルを使います。編集するセクションは一度に1つに絞り、テストに成功してから次の項目に進みます。

元ファイルを保管する

Configを開き、編集するファイルをエクスポートするかコピーします。ファイル名を記録し、同じ名前のリモート設定とローカルコピーを取り違えないようにしてください。
テキストを編集する

Configで対象のファイルをタップし、Edit Plain Textを開きます。該当するセクションの内容を編集し、半角の句読点を確認してから保存します。
設定ファイルを選択する

Configに戻り、このファイルをタップしてUse Configを選びます。編集画面にとどまっているだけではなく、変更後のファイルに現在選択中の表示が付いていることを確認してください。
ルーティングモードを確認する

Home → Global Routing → Configを開きます。Homeで選択されている接続項目も確認してください。自動接続がテストに影響する場合は、Settings → On Demandで接続条件を確認します。
再テストする

必要に応じていったん切断してから再接続し、対象へのリクエストを再送信してリクエストログを確認します。通常どおりアクセスできる宛先を比較用に使い、Connectivity Testの1回の結果だけでルール全体を判断しないでください。

ルーティングの適用とコンテンツ処理を分けて確認する

Ruleを確認する

Global RoutingをConfigに設定します。
完全一致するドメインと、同じ末尾を持つ別のドメインをそれぞれテストします。
リクエストログで宛先、適用されたルール、ポリシーを確認します。

Hostと書き換えを確認する

リクエストが想定した名前解決方法を使っていることを確認します。
宛先アドレス、プロトコル、リダイレクトのレスポンスを確認します。
以前の接続、キャッシュ、HSTSの影響を除外します。

まずファイルが読み込まれていることを確認し、次にリクエストが該当する処理を受けていることを確認します。変更する変数は一度に1つにしてください。

7. 設定ファイルを変更した後によくある質問

ファイルを保存したのに、すべて同じポリシーで処理されるのはなぜですか？

まずHome → Global RoutingでConfigが選択されているか確認し、次にConfigで現在のファイルを確認します。その後、Ruleの上部に範囲が広すぎるルールがないか、FINALが早い位置にないかを確認してください。テキストの保存、ファイルの選択、ルーティングモードの選択は、それぞれ別の操作です。

Hostを新しいアドレスに変更したのに、HTTPSでエラーになるのはなぜですか？

新しいサーバーが443番ポートで待ち受けているか、またサーバーの証明書が元のドメイン名をカバーしているか確認してください。Hostが変更するのは名前解決の結果だけです。URL内のホスト名は変わらず、証明書の検証も回避されません。元のマッピングに戻してテストすると、今回のアドレス変更が原因かどうかを判断できます。

サブスクリプションを更新すると、Ruleも自動で新しい内容になりますか？

そうとは限りません。Homeの接続サブスクリプション更新と、Configのリモートファイル更新は別々に確認してください。前者は主に接続項目を更新し、後者は設定ファイルの内容に関わります。ローカルコピーを使っている場合は、現在もそのコピーが選択されていることを確認してください。

いくつかのウェブサイトだけをPROXYにしたい場合、4つのセクションすべてを変更する必要がありますか？

通常はRuleに対象ドメインのPROXYルールを追加し、必要に応じてFINAL,DIRECTをフォールバックとして設定するだけで十分です。構成をそろえるためだけにGeneral、Host、URL Rewriteを追加する必要はありません。利用可能な接続項目があり、Home → Global RoutingでConfigを選択していることが前提です。

設定ファイルは、セクション名と構文、ルールの順序、ルーティングモードと実際のリクエストの順に確認するとよいでしょう。接続の問題をさらに調べる場合はトラブルシューティングを、キーワードの意味を確認する場合は用語集をご覧ください。テキストの誤り、ルーティングの選択、ネットワークへの到達性を分けて確認できます。