この記事の概要

この記事は、利用できるサービスをすでにお持ちで、.confファイルを読んだり編集したりする方を対象としています。まずConfigのファイルとHomeのサーバーを区別し、4つの設定セクションの書式を確認します。最後に設定を切り替え、個別にテストして変更を検証します。例はフィールドとマッチ方法の説明のみで、利用可能なサービス情報は含みません。

1. .confファイルとHome・Config・Settingsの違い

Shadowrocketの.confファイルはテキスト形式の設定ファイルで、角括弧で囲まれたセクション名ごとに役割が分かれています。[General]には通常、全般設定を記述します。[Rule]は通信の振り分けルール、[Host]はドメインのマッピング、[URL Rewrite]はリクエストURLの書き換えルールを記述するセクションです。この記事ではこの4つを取り上げますが、設定ファイルがこの4セクションだけで構成されるとは限りません。

Homeでは主に、登録済みのサーバーを選択して接続を操作します。Configでは設定ファイルを管理・選択し、Settingsではアプリ全体の設定を行います。サービスのサブスクリプション更新とリモート設定の更新は別の操作です。前者は通常サーバー情報、後者は設定内容を更新します。ローカルの変更が上書きされるか判断するには、どちらのリソースを更新しているかを先に確認してください。

4セクション
General・Rule・Host・URL Rewriteを解説
3か所
確認する場所：Home / Config / Settings
1項目
1回の作業で変更するのは、パラメータ1つまたはルール1つだけ

判断の順序：まず有効な設定を確認し、次にファイルの内容を確認

Configを開き、選択中のファイルと編集中のファイルが同じであることを確認します。次にHomeへ戻り、Global RoutingをConfigに設定してルールの振り分けを検証します。選択されていないファイルを保存しただけでは、そのルールが接続に自動適用されることはありません。

2. [General]：全般設定とDNSの基本

[General]では「キー = 値」の形式で記述します。DNS関連のパラメータはドメイン名の名前解決に使う設定を指定します。サーバーの遅延テストに成功しただけで、名前解決も正常だとは判断できません。遅延テストで確認できるのは該当するテスト経路のみです。実際のWebアクセスには、対象ドメイン、名前解決の結果、その後の接続も関係します。

[General]
dns-server = system
ipv6 = false

dns-server = systemはシステムのDNS設定を使う指定です。比較用の基準として使えますが、現在のネットワークで提供される名前解決サービスが必ず利用できるという意味ではありません。特定のリゾルバーを使う場合は、到達可能で信頼できるアドレスを確認して入力し、ネットワーク環境に合った設定にしてください。出所の分からない複数の設定をまとめて追加するのは避けましょう。

ipv6 = falseは、この項目のIPv6サポートを無効にする設定です。ここでの例は比較しやすいテスト条件を作るためのもので、すべてのネットワークでIPv6を無効にする必要があるわけではありません。デバイス全体のネットワークスタックを変更する設定でもありません。元の環境でIPv6を利用している場合は値を維持し、名前解決の記録と実際の接続結果をあわせて判断してください。

  • 変更前のdns-serverの値を記録し、元に戻せるよう設定のコピーを保存してください。
  • 同じドメインを使ってテストし、名前解決の成否と接続の成否をそれぞれ記録します。この2種類の失敗を混同しないでください。
  • 従来のDNSは通常ポート53を使用します。名前解決のリクエストが到達するかどうかと、Webサイトの443ポートに接続できるかどうかは、別々に確認する項目です。
  • テスト中に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

DOMAIN-SUFFIX,example.com,PROXYは、該当ドメインとそのサブドメインにマッチします。*.example.comと書く必要はありません。IP-CIDRは接続先IPが属するネットワーク範囲でマッチします。例のno-resolveは、このIPルールのために追加のドメイン名前解決を行わない指定です。すべてのドメインを先に名前解決してからネットワーク範囲を確認するものではありません。

GEOIP,CN,DIRECTは接続先IPの地理的位置情報に基づいてマッチします。Webサイトの言語、ドメインの末尾、運営主体を判定するものではありません。判定結果は使用するデータベースによって異なるため、特定のドメインが必ずDIRECTになるとは限りません。ドメインの通信ポリシーを明確に指定するには、前方に具体的なドメインルールを記述してください。

マッチング対象

DOMAIN-SUFFIX
example.com：ドメインのサフィックス
IP-CIDR
192.0.2.0/24：IPv4ネットワーク範囲
GEOIP
CN：接続先IPの国・地域コード

具体的なドメインルールを前に置き、IP関連のルールは実際の要件に合わせて並べます。

ポリシー

PROXY
プロキシ経由で接続
DIRECT
接続先に直接接続
REJECT
リクエストを拒否

FINALはルールキーワードです。FINAL,PROXYのように、後ろにポリシーを指定する必要があります。

ここでのPROXYには、サーバーアドレス、ポート、認証情報は含まれず、利用可能なサービスが作成されるわけでもありません。実際の接続先は、すでに登録されているサーバーと現在の選択内容によって決まります。見慣れないポリシー名がある場合は、設定ファイル内に対応するポリシー定義があるか確認してください。名前をプロトコル名に置き換えるだけでは解決しません。

4. [Host]：ローカルマッピングとルール振り分けの違い

[Host]では、特定のドメインに対するローカルマッピングを設定します。最も基本的な書き方は「ドメイン = IPアドレス」です。固定アドレスが分かっているテスト環境に適しています。以下の192.0.2.10はドキュメント用のサンプルアドレスで、実際のWebサイトが開けるか確認するためには使えません。

[Host]
lab.example.com = 192.0.2.10

この設定は「lab.example.comに指定したアドレスを使用する」という意味であり、「DIRECTで接続する」という意味ではありません。名前解決やマッピングで接続先のアドレスが決まった後も、接続には適用対象のルーティング設定が使われます。このドメインの接続先ポリシーを指定する場合は、別途[Rule]にルールを記述してください。

  • ドメイン移行：サーバー側でアドレスが変わると、固定マッピングが古いIPを指したままになる場合があります。あわせて確認してください。
  • HTTPS：マッピングによって証明書の検証要件が変わることはありません。サーバー証明書はリクエスト先のドメインと一致している必要があります。
  • アプリのキャッシュ：マッピングを変更した後は接続をやり直してください。すでに確立済みの接続では、名前解決が再実行されない場合があります。
  • 入力形式：左側にはドメインを入力します。https://、パス、ポートは付けないでください。

動的に接続先を振り分けるサイトで、1回の名前解決で得たアドレスを長期間固定しないでください。CDNを利用するサイトや、ネットワークに応じてアドレスが割り当てられるサイトでは、古いマッピングが通常の名前解決を迂回し、一部のリソースだけがタイムアウトすることがあります。すべてのリクエストが同時に失敗するとは限りません。

5. [URL Rewrite]：URLにマッチさせて書き換え動作を指定

[URL Rewrite]はリクエストURLを対象とする設定で、プロキシの接続先を選ぶものではありません。ルールには通常、マッチ式、転送先、動作を指定します。以下の例では、テスト用ドメインへのHTTPリクエストをHTTPSにリダイレクトします。末尾の302はリダイレクトのステータスコードで、ポート番号ではありません。

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

式の先頭にある^と末尾の$は、マッチする範囲を限定します。\.はドメイン内の通常のピリオドを表します。(.*)はパスとその後の文字列をキャプチャし、転送先の$1は最初のキャプチャグループの結果を参照します。ピリオドを.とそのまま書くと、正規表現では任意の1文字にマッチするため、意図した範囲より広くマッチする可能性があります。

  1. まずは自分で管理できるHTTPテスト用アドレスを1つ使ってルールを検証してください。複雑なログインページから始めるのは避けましょう。
  2. リダイレクトが発生するか、パスとクエリパラメータが想定どおり保持されるかを確認します。
  3. 転送先から元のアドレスへ再び戻らないことを確認し、リダイレクトループを防ぎます。
  4. 検証後、マッチ範囲を少しずつ広げます。元のルールは変更前の状態に戻せるよう保存してください。

6. Configで.confを編集・選択して検証する

編集前に、現在利用できるファイルのコピーを保存してください。リモート設定のファイルを使っている場合は、ローカルに別名で保存してから試すと、次回のリモート更新で変更が上書きされるのを防げます。たとえば、コピーには自分で見分けやすいlocal-test.confという名前を付けられます。ファイル名によって設定の有効・無効が決まるわけではありません。

元の設定をバックアップ 項目を1つ編集 保存して選択 接続を再確立 リクエストを確認
  1. Configを開く：対象のファイルを見つけ、ファイル操作からテキスト編集を開きます。編集画面への入り方やアイコンは、画面の変更に伴って異なる場合があります。実際に表示される項目を確認してください。
  2. セクションの位置を確認：キーと値が正しいセクション名の下にあるか確認してください。dns-server = systemを[Rule]に貼り付けたり、FINAL,PROXYをGeneralのパラメータとして記述したりしないでください。
  3. 保存して選択：Configのファイル一覧に戻り、保存したファイルに有効状態のマークが付いていることを確認します。エディターでファイルを開いただけでは、設定は切り替わりません。
  4. モードを確認：Home → Global Routingに戻り、Configを選択します。ProxyとDirectは、全体をプロキシ経由または直接接続にする場合の比較に使います。ファイル内のルール振り分けが有効であることの検証には適しません。Sceneは、設定済みのシーン条件とあわせて判断してください。
  5. テスト接続を再確立：一時的に接続が切れても問題ない場合は、接続し直してからテストページを再度開き、古い接続を使わないようにします。リクエスト記録で接続先、ポリシー、エラー情報を確認してください。

Settings → On Demandでは、設定済みの条件に応じた自動接続を設定します。.confファイルの選択とは別の設定項目です。トラブルシューティング中に接続状態が勝手に変わる場合は、On Demandの条件も確認してください。自動再接続を、保存した設定が接続を開始したためだと誤認しないようにしましょう。

検証では、比較できる状態を記録してください。たとえば、同じテスト用ドメインが変更前は名前解決できても接続がタイムアウトし、変更後も名前解決は成功したままルールの適用結果がDIRECTになった場合、マッチングと接続先に変化があったことは分かります。実際にアクセスできるようになったかは、ページのリクエストが完了するまで確認してください。接続スイッチの状態だけでは判断できません。

7. 設定ファイル編集でよくある質問

ルールを保存したのに、アクセス時に以前のポリシーが使われるのはなぜですか？

まずConfigで現在選択されているファイルを確認し、次にHome → Global RoutingがConfigになっているか確認してください。両方を確認したら、対象ルールより上にある広範囲のルールが先にマッチしていないか調べます。古い接続が以前のポリシーを使い続けている可能性を除くため、リクエストを再実行してください。

FINALを1行目に置くとどうなりますか？

FINALは、その行まで到達したリクエストを処理します。前方に置くと、後続の通常ルールにマッチする機会が失われます。[Rule]の末尾に移し、具体的なドメインやネットワーク範囲などの条件を前に置いて、順番に確認してください。

更新後に手動で変更した内容が消えるのはなぜですか？

まず、更新したのがリモート設定か、Homeにあるサービスのサブスクリプションかを確認してください。リモート設定を再取得すると、ローカルの内容が上書きされる場合があります。実験的な変更を長期的に残す場合は、独立したローカルコピーに保存し、以降もそのコピーが選択されていることを確認してください。

Hostのマッピングを削除してもドメインにアクセスできない場合は？

設定を保存して接続し直し、対象ページを閉じてから再度開きます。その後、別のマッピング、ルール、アプリ内の接続キャッシュが残っていないか確認してください。続けてDNSの応答と実際の接続先アドレスを調べ、名前解決の失敗、接続タイムアウト、証明書エラーを切り分けます。汎用的な対処として固定IPを繰り返し追加しないでください。

設定が完了したら、検証済みのローカルコピーを保存し、変更したフィールドとテスト結果を記録してください。後で問題が起きたときは、この状態を基準にして変更を1つずつ戻します。設定とサーバーを一度に入れ替えるより、原因を特定しやすくなります。