この記事の概要

Shadowrocketで自分のサブスクリプションを利用していて、ローカル設定ファイルを確認したい方に向けた記事です。接続情報と.confの役割を切り分け、4種類のセクション名、ルールの順序、書き換え形式を確認したうえで、一度に1項目ずつ変更して結果を検証します。例は構文の説明用で、既存の環境にそのまま適用できる完全な設定ではありません。

1. .confの役割：設定ファイルと接続情報を区別する

Shadowrocketの.confはテキスト形式の設定ファイルです。角括弧で囲まれたセクション名によって、後続の内容をどの機能が読み込むかが決まります。[General]には主にパラメータの割り当て、[Rule]には順序付きのルール、[Host]にはローカルのドメインマッピング、[URL Rewrite]にはURLの照合と処理方法を記述します。セクションごとに構文が異なり、相互に置き換えることはできません。

Homeにある接続情報と、Configで選択している設定ファイルは別のものです。通常、サブスクリプションの更新では接続項目を同期し、ローカルの.confを編集するとリクエストの処理方法を調整できます。サブスクリプションを更新しても、現在適用中のルールファイルが切り替わるとは限りません。逆に.confを読み込んでも、利用可能な接続情報が設定されるわけではありません。

4つのセクション名
General、Rule、Host、URL Rewriteを確認
最後のフォールバックは1つ
FINALはルール末尾で未照合のリクエストを処理
2種類の情報
Homeの接続項目とConfigの設定ファイルを別々に確認

編集を始める前に、Configで現在選択中のファイルを確認し、元ファイルのコピーを保管してください。Homeに戻り、Global Routingも確認します。[Rule]を検証する場合はConfigを使用します。ProxyとDirectは全体の振り分け方法を変更し、Sceneにはシーン設定も関係します。これらの状態を、Configでルールを1つずつ照合するテスト結果と混同しないでください。

  1. ファイルを読み込んだだけでなく、Configで選択されていることを確認します。
  2. そのファイルの編集画面を開き、セクション名に半角の角括弧が使われていることを確認します。
  3. Homeで接続項目があることを確認し、Global RoutingをConfigに設定します。
  4. 変更を保存したらテスト接続を再確立し、変更前から続いている長時間接続を使わないようにします。

2. [General]：全般設定を読み取るセクション。振り分けルールは記述しない

[General]ではキー = 値の形式を使います。各パラメータの適用範囲はキーの定義によって決まり、「先頭に置けばすべてのセクションに適用される」わけではありません。たとえばDNSパラメータは名前解決に、バイパス設定は一部の通信を処理対象にするかどうかに関わりますが、どちらも[Rule]のドメインルールの代わりにはなりません。

[General]
dns-server = system
skip-proxy = 127.0.0.1, localhost

ここでのdns-server = systemはシステムのDNS設定を使うという意味で、特定のサーバーを指定するものではありません。127.0.0.1はループバックアドレスです。これをskip-proxyに含める目的は、特定の公開Webサイトへの通信をDIRECTにすることとは異なります。この例は2種類のパラメータ記述を示すもので、一般的なネットワーク最適化の設定ではありません。

Settings → On Demandでは、条件に応じて接続を開始または切断する動作を管理します。[General]と同じ設定箇所ではありません。設定の問題を調べるときに接続が自動で復帰する場合は、On Demandの起動条件も確認してください。自動再接続を.confの未保存と取り違えないようにします。

3. [Rule]：上から順に照合し、FINALで最後のフォールバックを設定

[Rule]のルールは上から順に判定され、通常は種類、照合値、ポリシーで構成されます。照合条件を満たしたリクエストには、最初に一致したルールのポリシーが適用されます。「ドメインが長いほど自動的に優先される」わけでも、「最後の行が前のルールをすべて上書きする」わけでもありません。具体的な例外は、対象範囲の広いルールより前に記述します。

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

上の例では、api.example.comは先にあるDOMAINに一致してPROXYを使います。www.example.comは後続のDOMAIN-SUFFIXに一致し、DIRECTを使います。サフィックスルールを完全一致のドメインルールより前に移動すると、サフィックスルールが先に一致し、API用に設定した例外が機能しなくなります。

キーワード照合対象確認ポイント
DOMAIN完全一致のドメインプロトコル、ポート、パスは記述しない
DOMAIN-SUFFIXドメインとそのサブドメインより具体的な例外を前に置く
IP-CIDRIPv4アドレスの範囲アドレス、マスク、名前解決の条件を確認
GEOIP宛先IPの地域情報データベースWebサイトの表示言語で判定するものではない
FINAL前のルールに一致しなかったリクエスト末尾に置き、ドメインは指定しない

no-resolveはIPルールに追加するオプションで、このIPルールのために別途ドメイン解決を行わないことを示します。アプリ全体のDNSを無効にする意味ではなく、ドメインへのリクエストが必ずそのIP範囲に一致するという意味でもありません。判定には、リクエストに宛先IPがすでに含まれているかどうかも関係します。

結論：ルールが機能しない場合は、まずモードと先に一致するルールを確認

まずHome → Global RoutingをConfigに設定し、対象ルールより前に範囲の広いルールがないか確認します。リクエストがどの行に一致したかを確認してから、ポリシーを変更するか判断してください。接続プロトコルやDNSを先に変更する必要はありません。

PROXYとDIRECTはポリシーを示すもので、プロトコル名ではありません。PROXYを使うには、現在の環境で利用できる接続が必要です。FINALをPROXYに変更しても、接続項目が自動的に作成されるわけではありません。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuardなどの接続方式と、DOMAIN-SUFFIX、IP-CIDRなどの照合方式は、別の階層に属します。

4. [Host]：名前解決先を固定するセクション。出口ポリシーは選択しない

[Host]ではローカルのドメインマッピングを設定します。次の例では、テスト用ドメインをドキュメント用のアドレスに割り当てます。左側にドメイン、右側にIPアドレスを記述します。192.0.2.10は文書用の例示アドレス範囲に属し、アクセス可能な業務用サーバーのアドレスではありません。

[Host]
demo.example.test = 192.0.2.10

Hostは適用可能な名前解決結果に影響しますが、ドメインを記述しただけで通信が自動的に直接接続されるわけではありません。最終的にDIRECTとPROXYのどちらを使うかは、Global Routing、ルール、実際の通信経路を踏まえて判断します。ドメインをリモートで解決する場合、ローカルマッピングが最終的な宛先アドレスを必ず決めるとも限りません。

Hostマッピングの確認

セクション名
[Host]
左側
demo.example.test
右側
192.0.2.10
処理対象
ドメインからアドレスへのローカルマッピング

ドメインの後ろにパスを付けたり、IPアドレスにポートを連結したりしないでください。

Ruleのポリシー確認

セクション名
[Rule]
照合タイプ
DOMAIN
照合値
demo.example.test
ポリシーの例
DIRECT

DIRECTを選択しても、直結の指定になるだけで、宛先の有効なアドレスが用意されるわけではありません。

Hostマッピングを設定しても、HTTPS証明書にドメイン名が必要という条件は変わりません。指定したIPアドレスに名前解決できても、対象サーバーがそのドメインに対応する正しい証明書を提供していなければ、証明書エラーが発生することがあります。その場合はサーバーのドメイン設定を確認し、ルールの優先順位の問題と混同しないでください。

5. [URL Rewrite]：正規表現、転送先、ステータスコードを確認

[URL Rewrite]でよく使われるリダイレクト形式は、「照合式、転送先URL、リダイレクトのステータスコード」を空白で区切ります。処理対象はURLであり、単純なドメイン照合ではありません。正規表現では、ピリオド、括弧、境界記号にもそれぞれ意味があります。

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

このルールはhttp://example.com/で始まるURLに一致し、キャプチャした後続部分を転送先URLの$1に挿入します。たとえば入力がhttp://example.com/docs?a=1の場合、転送先はhttps://example.com/docs?a=1となる想定です。これは構文の例であり、外部のテストページへのアクセスを求めるものではありません。

HTTPS URLを処理できるかどうかは、暗号化された通信を正当な許可の範囲内で復号しているか、関連設定がそろっているかによって異なります。URL Rewriteルールを追加しただけで、HTTPSのパスや内容を取得できるわけではありません。この記事では形式を示すためにHTTPを使っており、HTTPSの復号設定や証明書の信頼設定を追加する必要はありません。

6. 保存後の検証方法：設定の役割ごとにテストする

設定ファイルのセクションの並び順は、リクエスト処理全体の実行順を示すものではありません。4つのセクションを上から順に処理する固定のパイプラインとして捉えないでください。検証では、選択中のファイルと全体モードを確認してから、名前解決、ルールの一致、URLの動作を個別に確認します。1回の検証で変更する要素は1つにします。

元ファイルをバックアップ選択中の項目を確認1項目を変更接続を再確立結果を確認
  1. 基準状態を記録：正常に動作する設定を保管し、テスト用ドメイン、ネットワークの種類、Global Routingの状態を記録します。
  2. 構文を確認：角括弧、等号、半角カンマ、スペルを確認し、ルールが誤ったセクションに入っていないことを確かめます。
  3. ルールを検証：Configモードで対象への新しいリクエストを作成し、アプリに表示される接続ログで宛先、ポリシー、一致状況を確認します。ログがある場合はその記録を根拠にし、ページの表示速度だけで判断しないでください。
  4. マッピングを検証：自分が管理し、サービス設定が正しいドメインを使って実際の宛先アドレスを確認します。この記事に掲載されている文書用アドレスで接続性をテストしないでください。
  5. 書き換えを検証：自分が管理するHTTPのテスト用エンドポイントを使い、転送先URLとリダイレクト回数を確認します。古いキャッシュで設定変更が見えなくならないよう注意してください。
  6. 問題があれば元に戻す：元の設定に戻して接続を再確立します。元に戻して正常になった場合は、先ほど変更した項目だけを追加します。

リモート設定とローカルファイルも分けて管理してください。リモート更新で上書きされるファイルを編集する場合は、別のコピーを先に保存し、実際にそのコピーが選択されていることを確認します。サブスクリプションの更新とリモート設定の更新はそれぞれ個別に確認してください。Homeの接続項目に変更があっただけでは、ローカルルールが置き換わったとは判断できません。

7. よくある質問：保存できたのに、なぜ結果が期待どおりにならない？

FINALを1行目に置いても、後続のルールは動作しますか？

FINALはルールの末尾に置きます。前のルールに一致しなかったリクエストを処理するため、先頭に置くと後続ルールが想定どおりに機能しません。具体的な例外を範囲の広いルールより前に移し、FINALを末尾に残して再テストしてください。

Hostを変更したのに、なぜサイトが直接接続されないのですか？

Hostでは出口ポリシーを選択しません。まずHome → Global Routingを確認し、次に[Rule]でそのドメインに一致するポリシーを確認してください。名前解決がローカルで行われているかも確認し、リモートの解決結果をローカルマッピングの失敗と取り違えないようにします。

サブスクリプションを更新したのに、なぜConfigのルールが変わらないのですか？

接続用サブスクリプションと設定ファイルは別の種類の情報です。Configに戻って選択中のファイルとその取得元を確認してください。リモート設定を更新する場合は該当するファイルを操作し、Homeの接続サブスクリプションを繰り返し更新しないでください。

保存しても変化がありません。元のファイルを削除する必要がありますか？

まず削除しないでください。選択中のファイルを編集したか確認し、保存後に接続を再確立して、新しいリクエストでテストします。接続が自動的に復帰する場合はSettings → On Demandの条件を確認し、変更前後でテスト条件をそろえてください。

トラブルシューティングの記録には、少なくとも選択中の設定ファイル、Global Routingの状態、変更したセクション名と行、テスト対象、確認した結果を含めてください。記録を共有する前に、サブスクリプションURL、トークン、接続情報を削除します。通常は該当ルールと匿名化した対象情報があれば、照合ロジックの検討に十分です。