この記事は、Homeに接続情報を追加済みで、Configから.confファイルを確認または編集する方向けです。接続パラメータと設定ルールの違いを確認してから、DNS、ルールの適用順、ローカルの名前解決、リクエストの書き換えを順に見ていきます。最後に、1項目ずつ変更し、リクエストログで反映状況を確認します。ドメイン名とアドレスの例は構文の説明用であり、そのまま使える接続設定ではありません。
1. .confファイルとHomeの接続情報の違い
Shadowrocketの.confファイルは、角括弧でセクションを区切るテキスト形式の設定ファイルです。各セクションは見出しから始まり、次のセクション見出しの直前まで続きます。空行は読みやすくするための区切りであり、セクション見出しの代わりにはなりません。また、JSONではないため、各行を二重引用符で囲んだり、行末にカンマを付けたりする必要はありません。
Homeに登録するサーバーアドレス、ポート、認証情報、プロトコルの選択肢によって接続方法が決まります。一方、Configで有効にする設定はリクエストの処理方法を決めます。ルールファイルだけでは、有効な接続パラメータがない限りプロキシ接続は確立できません。サブスクリプションは利用中のサービス提供元から入手します。接続用サブスクリプションとリモートの.conf設定は用途が異なり、URLがhttpsで始まるというだけでどちらかを判断することはできません。
まずすべてのセクション見出しを確認し、各行がどの構文に当たるかを見ていきます。[General]と[Host]では、等号で区切るキーと値がよく使われます。[Rule]では、英語のカンマで区切られたフィールドが使われます。[URL Rewrite]には、正規表現、転送先、アクションが含まれます。異なるセクションの書式を混在させないでください。
2. [General]：全般設定とDNSを確認
[General]には全般的な動作設定を記述します。「接続テストには応答があるのに、ドメインにアクセスできない」場合は、すべてのルールをすぐに変更するのではなく、まずここにあるDNS設定を確認します。以下はキーと値の構文を示すための設定例であり、完全な設定ではありません。
[General]
dns-server = systemdns-serverはDNSリゾルバーの指定先を表し、systemはシステムのDNSを使う設定です。これは「すべてのDNSリクエストがプロキシ経由になる」という意味ではありません。実際の名前解決経路は、ネットワーク環境や他のDNS設定にも左右されます。リゾルバーを特定のパブリックアドレスに変更しても、ドメインを必ず名前解決できるとは限りません。
全般設定の確認ポイント
- セクション
- [General]
- 設定項目
- dns-server
- 設定例
- system
- 構文
- キー = 値
まず現在の値を確認し、変更前後の名前解決の状況を記録します。
ルールテストの前提条件
- 接続情報
- Homeで確認
- 設定ファイル
- Configで有効になっていることを確認
- ルーティングモード
- Global Routing → Config
- 自動接続
- Settings → On Demand
On Demandは接続を開始する条件を管理します。[Rule]のマッチングルールの代わりにはなりません。
変更前に元の値を保存してください。リゾルバーを変更した後、すべてのドメインで同時に名前解決エラーが起きる場合は、まずその項目を元に戻して再テストします。出力ポリシー、マッピング、書き換えを同時に変更するのは避けてください。そうすることで、リゾルバーに到達できないのか、名前解決後の接続で失敗しているのかを切り分けられます。
3. [Rule]：マッチングとポリシーの適用順
[Rule]は上から順に評価され、マッチした時点で該当するポリシーが適用されます。一般に、特定のドメインを対象とするルールは、範囲の広いIPルールや地理ルールより上に置きます。残りのリクエストを処理するFINALは末尾に配置します。以下は構造を確認するための例です。PROXYを使うには、対応するプロキシの出力先が利用可能である必要があります。
[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とそのサブドメインにマッチします。 | 任意の文字列を含むかどうかで判定するものではありません。 |
IP-CIDR | 192.0.2.0/24のアドレス範囲にマッチします。 | no-resolveは、そのルールにマッチさせるための名前解決を積極的には行わないことを表します。 |
GEOIP | IPジオロケーションデータベースに基づいてCNにマッチします。 | 判定基準はIPデータであり、ウェブサイトの使用言語ではありません。 |
FINAL | それまでのルールにマッチしなかったリクエストをPROXYに送ります。 | ドメインのフィールドがないため、3フィールド形式にはしません。 |
DIRECTは直接接続を表し、インターネット接続を停止する意味ではありません。PROXYはプロキシポリシーを使う指定であり、接続パラメータが自動生成されるわけではありません。元のファイルで独自のポリシー名が使われている場合は、対応するポリシーが実際に定義されていることを確認してください。名前だけを置き換えて、ポリシーの定義を見落とさないようにします。
確認ポイント：ルーティングモードを確認してからルールの順序を調整
[Rule]をテストする際は、まずGlobal RoutingをConfigに設定し、リクエストがどのルールにマッチしたかを確認します。ProxyまたはDirectになっている場合は、Configに戻して再テストしてください。その結果だけでルールの構文が無効だとは判断できません。Sceneも、固定のFINALルールと同じものではありません。
上の例にある192.0.2.0/24は、説明用のドキュメントアドレスです。通常のアクセス先として使うものではありません。ドメインルールとIPルールは対象が異なり、前者はドメイン名、後者はIPアドレスを判定します。特にno-resolveを使う場合、「ドメインのリクエストが特定のIPルールにマッチしなかった」ことを、そのまま名前解決の障害とみなさないでください。
4. [Host]：ローカルの名前解決とルーティングルールの違い
[Host]では、ローカルの名前解決を設定します。以下は形式を示すため、例のドメインをドキュメント用アドレスに割り当てています。このアドレスで実際のサービスにアクセスしても、有効な応答は得られません。
[Host]
demo.example.com = 192.0.2.10この設定行が指定するのは「このドメインをどのアドレスに名前解決するか」であり、「このリクエストにどの接続を使うか」ではありません。マッピング後に適用されるポリシーは、ルーティングモードとルールを確認して判断します。また、ブラウザーのアドレスバーに表示されるドメイン名は変わらず、HTTPS証明書の検証に使われるホスト名も自動的には変わりません。
- アドレス移行のテスト：接続先サーバーが正しいと確認できている場合は、明示的なドメインマッピングで新しいアドレスをテストできます。テスト後は一時設定を削除してください。
- 証明書エラーが発生する場合：接続先サーバーが元のドメイン名に対して有効な証明書を提供しているか確認します。任意のアドレスにマッピングしても、証明書の問題は解決しません。
- マッピング後もプロキシ経由になる場合：
[Rule]のドメインルールと最終ポリシーを確認してください。ポリシー設定の代わりに[Host]を変更することはできません。 - 特定のドメインだけ異常な場合：まず古いマッピングが残っていないか確認してから、パブリックDNSを調べます。ローカルの上書き設定を見落とさないようにしてください。
5. [URL Rewrite]：名前解決とリクエストの書き換えを区別
[URL Rewrite]は、処理対象となるリクエストURLを照合して書き換えます。DNS設定でもドメインのルーティングルールでもありません。以下では、HTTPのURLをHTTPSのURLに転送する例で、「正規表現・転送先・アクション」の書き方を説明します。
[URL Rewrite]
^http://example\.com/(.*)$ https://example.com/$1 302^と$でマッチ範囲を限定し、URLの一部分だけにマッチするのを防ぎます。example\.comのバックスラッシュは、ドットを文字どおりのピリオドとして扱うためのものです。エスケープされていないドットは、正規表現では他の任意の文字にもマッチします。(.*)はスラッシュ以降の内容をキャプチャします。転送先の$1は、最初にキャプチャしたグループを参照します。302は一時的なリダイレクトを表します。書き換え後のリクエストでも、ドメインの名前解決と接続の確立が必要です。
HSTSやブラウザー独自のHTTPS優先機能によってリクエスト送信前にURLがHTTPSへアップグレードされると、上記のHTTPルールにマッチするリクエストが発生しない場合があります。その場合は、アドレスバーに最初に入力した内容だけで判断せず、実際に送信されたURLを確認してください。
書き換えとマッピングは個別に検証してください。[Host]は名前解決の結果に影響し、[URL Rewrite]は条件に一致するリクエストURLに影響します。両方を同時に変更すると、原因の切り分け範囲が広がります。特にリダイレクト後にホスト名が変わる場合は、そのホスト名の名前解決と適用ポリシーも再確認してください。
6. Configで設定を編集・有効化・検証する
ファイルを読んだだけでは、設定が有効になったことにはなりません。Configで現在有効な設定を確認し、コピーを編集してください。ファイル名だけで実行中の設定を判断しないようにします。リモート設定の更新によってローカルの変更が上書きされることもあるため、自分で管理する内容とリモートの提供元を区別してください。
- 元の内容を保存します。現在の設定名、
dns-serverの値、Global Routingのモードを記録し、変更前のコピーを残してください。 - テスト対象を1つ選びます。アクセス権があり、想定される動作が分かっているドメインを使用してください。この記事のexample.comとドキュメント用IPは構文の説明用であり、プロキシの接続テストには使いません。
- 変更する箇所は1つだけにします。たとえば、
DOMAIN-SUFFIXルールを1つ移動し、DNSの変更や新しい書き換えルールの追加は同時に行いません。 - 保存して有効化を確認します。必要に応じて接続を確立し直し、新しいリクエストを送信してください。既存の接続やキャッシュ結果を新しいルールの結果と取り違えないようにします。
- リクエストログを確認します。実際のドメイン名、マッチしたルール、出力ポリシー、エラーの種類を照合してください。名前解決の失敗、接続タイムアウト、証明書エラーはそれぞれ異なる段階の問題です。個別に対処してください。
変更後に異常が起きた場合は、直前に変更した項目を元に戻し、同じテストを繰り返します。元に戻す操作によって結果が安定して変わることを確認できてから、原因の範囲をさらに絞り込んでください。サブスクリプションの更新成功は、対象の内容を取得して処理できたことを示すだけで、Configのルールが変更されたことを意味しません。同様に、リモート設定の更新成功もHomeの接続認証情報が更新されたことを意味しません。
7. 設定ファイルに関するよくある質問
[Rule]を変更しても、通信先が変わらないのはなぜですか？
まずConfigで、編集したファイルが現在有効な設定か確認します。次にGlobal Routing → Configを確認してください。その後、新しいリクエストを送信し、上にある広い範囲のルールに先にマッチしていないか確認します。先にマッチしている場合は、対象を絞ったルールをその前に移動して再テストしてください。
PROXYを指定したのに、接続できないのはなぜですか？
Homeに戻り、選択中の接続が有効か確認します。アドレス、ポート、認証情報がサービス提供元の情報と一致していることも確認してください。PROXYは処理ポリシーを指定するだけで、Shadowsocks、VMess、VLESS、Trojanの接続に必要なパラメータを補うものではありません。
サブスクリプションを更新すると、手書きのルールも更新されますか？
まず、更新したのが接続用サブスクリプションかリモート設定かを区別してください。接続用サブスクリプションは主にサーバー項目を管理します。手書きのルールはConfigで確認してください。リモート設定はローカルのコピーを保存し、更新後にカスタマイズした内容が残っているか1項目ずつ比較します。
複数の.confファイルをそのまま連結してもよいですか？
そのまま連結しないでください。セクションごとに内容を整理し、同名の設定、重複するマッピング、ポリシー名、ルールの適用順を確認します。FINALはルールの末尾に配置してください。統合後は、少数の確認済みリクエストで検証してから、ほかの内容を追加します。
引き続き問題を調べる場合はトラブル診断をご覧ください。設定やキーワードの意味を確認するには、機能と設定または用語集をご覧ください。確認とテストは、自分の設定とリクエストログに基づいて行い、サンプルファイルを汎用の接続設定として使わないでください。