Shadowrocketの.confファイルは、サーバー一覧ではなく、セクションごとに設定を管理します。自分のサーバーやサブスクリプションをすでに利用していて、既存の設定内容を確認したい方向けに、現在選択中の設定とGlobal Routingを確認してから、全般設定、ルールの順序、ローカルマッピング、リクエストの書き換えを順に確認し、最後に一項目ずつ変更して結果を検証する方法を解説します。
1. まず.confファイルが現在の接続に使われているか確認
ファイルを編集しても、現在の接続にその設定が適用されるとは限りません。まずConfigで選択中の設定を確認し、Homeに戻ってGlobal Routingを確認します。[Rule]をテストする場合はConfigを選択してください。ProxyとDirectは全体のルーティングモードであり、個々の振り分けルールの正しさを判定するためには使えません。
Homeでは主にサーバーの選択と接続の操作、Configでは設定ファイルの管理、Settingsではアプリの設定を行います。サーバーのサブスクリプション更新と.confの編集は別の作業です。前者は主にサーバー項目を更新し、後者は名前解決や振り分けなどの動作を定義します。サブスクリプションを問題なく読み込めても、設定内で指定したポリシー名が存在するとは限りません。
| Global Routingの選択肢 | 確認時の意味 |
|---|---|
| Proxy | 現在のサーバーを全体プロキシモードでテストします。個別の振り分けルールの検証には適しません。 |
| Direct | 全体をDirectモードにしてネットワークをテストします。この結果だけでPROXYルールが機能していないとは判断できません。 |
| Config | 現在の設定に従って振り分けを実行します。この記事でルールを検証する際に選ぶ項目です。 |
| Scene | シーンの設定に従ってルーティングします。トラブルシューティング時は、実際にどのシーンが選択されているか確認してください。 |
- Configで現在のファイルをバックアップし、編集するコピーを開きます。
- Homeで動作確認済みのサーバーを選び、Connectivity Testで基本的な接続性を確認します。
- Global RoutingをConfigに設定し、変更を保存して、テスト用のファイルが選択されたままか確認します。
- 接続を再確立し、同じ宛先にアクセスして変更前後の状態を比較します。
2. セクション名と基本の書き方：構成を把握してから編集
セクション名には半角英字と角括弧を使います。各行は次のセクション名が現れるまで、そのセクションに属します。[General]は一般にキーと値の組み合わせで記述し、[Rule]ではカンマ区切りのルール項目を使います。すべてのセクションを同じ形式で書けるわけではありません。また、半角カンマを全角カンマに置き換えないでください。
[General]
dns-server = system
ipv6 = false
[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY
[Host]
lab.example.com = 192.0.2.10
[URL Rewrite]
^http://www\.example\.com/ https://www.example.com/ 302このサンプルは構文の説明用であり、あらゆるネットワークに適した推奨設定ではありません。example.comは例示用のドメイン、192.0.2.0/24はドキュメント用のアドレス範囲で、接続可能な実サーバーではありません。実際に使う場合は、自分が管理するドメインやネットワークに合わせて変更してください。不要なHostやURL Rewriteの行は削除します。
書式付きテキストエディターによる句読点の自動置換を避けるため、.confファイルはプレーンテキストで保存します。コメントは独立した行に書くと確認しやすくなります。ルールをコピーする際は、説明文をフィールドに貼り付けないでください。インポートできても、基本形式が受け付けられたことしか分かりません。ポリシーの参照先と実際の動作も確認してください。
3. [General]：全般設定と振り分けルールは別もの
[General]は設定全体の動作に影響します。上の例では、dns-server = systemはシステムのDNSを使う設定、ipv6 = falseはこの設定でIPv6を無効にする指定です。IPv6を無効にすれば必ず解決するわけではありません。DNSの変更、ルールの編集、サーバーの切り替えを同時に行うと、どの変更が結果に影響したのか分からなくなります。
Generalの確認項目
- セクション名
- [General]
- DNSの例
- dns-server = system
- IPv6の例
- ipv6 = false
- フィールド形式
- キー = 値
一度に変更するパラメーターは1つだけにし、テスト前に元の値を記録します。
接続動作の確認項目
- 接続の操作
- Home上部のスイッチ
- オンデマンド接続
- Settings → On Demand
- ルールのテスト
- Home → Global Routing → Config
- 設定の選択
- Configで現在のファイルを確認
On Demandは条件に応じた接続を管理する機能で、Ruleによる振り分けを代替するものではありません。
DNSの問い合わせ成功、宛先への接続成功、正しいポリシーの適用は、それぞれ別の確認項目です。ドメインにアクセスできない場合は、まず名前解決で期待するアドレスが返るか確認し、その後に接続ログを確認します。DNSの応答があっても、サーバーに到達できない、宛先ポートが閉じている、またはポリシーが誤っていると、アクセスに失敗します。
- DNSをテストするときはネットワークとサーバーを固定し、Wi-Fiとモバイル通信を何度も切り替えないでください。
- DNSまたはHostを変更した後は、宛先への接続を再確立します。アプリやシステムに古い名前解決結果がキャッシュされている場合があります。
- Settings → On Demandによる自動接続が有効な場合は、トラブルシューティングを始める前に条件を記録します。自動再接続を設定未保存と誤認しないためです。
4. [Rule]：上から順に照合し、FINALは末尾に置く
[Rule]は接続に適用するポリシーを決定します。通常のルールは、ルールタイプ、照合対象、ポリシーで構成されます。FINALには照合対象のフィールドがありません。ルールは記載順に評価され、一度一致した接続は、後ろにより具体的なルールがあっても再評価されません。そのため、具体的な例外は広い条件より前に置きます。
[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| キーワード | 例の意味 |
|---|---|
| DOMAIN | api.example.comに完全一致します。下にあるドメインサフィックスのルールより優先されます。 |
| DOMAIN-SUFFIX | example.comとそのサブドメインに一致します。文字列のどこかに含まれる場合を指すものではありません。 |
| IP-CIDR | 指定したIPv4アドレス範囲に一致します。no-resolveを指定すると、このルールの照合のためにドメイン名を能動的に解決しません。 |
| GEOIP | IP地理情報データベースを使ってCNに一致するアドレスを判定します。結果はアドレスとデータベースの内容によって異なります。 |
| FINAL | それまでのルールに一致しない場合はPROXYを使います。ルール一覧の末尾に置いてください。 |
この順序では、api.example.comは先にDOMAINに一致し、サフィックス条件に一致する他のサブドメインはDIRECTを使います。先頭2行を入れ替えると、範囲の広いサフィックスルールが先に一致し、元の個別例外が機能しなくなります。ここでのPROXYはポリシーの参照先であり、プロトコル名やサーバーアドレスではありません。
要点：ルールの順序を先に直し、例外の追加はその後
特定のドメインに誤ったポリシーが適用され続ける場合は、まず上にあるDOMAIN-SUFFIXやFINALに一致していないか確認します。完全一致のルールを広い条件より前に移動し、接続し直して検証してください。同じルールを重複して追加する必要はありません。
カスタムのポリシーグループ名を使う場合は、現在の設定内でその名前が定義されていることを確認してください。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuardはサーバー接続プロトコルです。プロトコル名をルールの末尾に記入するだけでは、そのプロトコルを使う接続先にはなりません。ルールではポリシーを選択し、サーバー項目ではプロトコルのパラメーターを設定します。それぞれ分けて確認してください。
5. [Host]：ローカルマッピングは強制的な直接接続ではない
[Host]は指定したドメインのローカルマッピングに使われ、管理下の環境で固定アドレスをテストする場合などに利用できます。下の例では、lab.example.comをドキュメント用アドレスの192.0.2.10に割り当てています。ポートやDIRECT、PROXYは指定されていません。最終的な接続先は、ルーティングモードとルールを合わせて判断します。
[Host]
lab.example.com = 192.0.2.10- 左辺にはドメイン名を記入します。
https://、パス、クエリパラメーターは含めません。 - 右辺には宛先のIPアドレスを記入します。
:443をアドレスの一部として扱わないでください。 - HTTPSでは引き続き元のドメイン名で証明書が検証されます。別のアドレスにマッピングしても、証明書の不一致が自動的に解消されるわけではありません。
- 検証時は接続を再確立してください。アプリ独自のキャッシュや名前解決の仕組みが結果に影響することがあります。
マッピング後にアクセスがタイムアウトする場合は、まず宛先IPに実際に到達できるか確認し、続けてポートとルールの適用状況を確認します。DNSの結果が変わっただけで設定が正しいと判断しないでください。テストが終わったら一時的なマッピングを削除します。実サーバーのアドレスが変更された後も、古い固定マッピングが通常の名前解決を上書きするおそれがあります。
6. [URL Rewrite]：URLを照合する機能であり、接続先の変更ではない
[URL Rewrite]では、正規表現でリクエストURLを照合し、置換先と動作を指定します。次の例は、http://www.example.com/で始まるリクエストを、固定のHTTPSトップページへ302リダイレクトします。302はHTTPステータスコードであり、ポート番号ではありません。また、この書き方では元のパスやクエリパラメーターは引き継がれません。
[URL Rewrite]
^http://www\.example\.com/ https://www.example.com/ 302^はURLの先頭から照合する指定です。同じ文字列が別の位置にある場合に誤って一致するのを防ぎます。\.はドメイン内のピリオドを文字として表します。エスケープしていない.は正規表現では任意の1文字を表します。- 2つ目のフィールドは固定の転送先アドレス、3つ目のフィールド
302はリダイレクトの動作を指定します。 - 管理下のテスト用アドレスで単一ルールを先に検証し、リダイレクトが繰り返されないことを確認してから設定を残します。
書き換えルールはプロキシポリシーではなく、サーバーへの接続失敗を解決するものでもありません。この例ではHTTPリクエストを照合対象にしています。すべてのHTTPSリクエストについて、完全なパスを直接読み取って書き換えられるとは限りません。暗号化されたリクエストの可視性や証明書の処理は別の設定項目です。このHTTPの例をテストするために、証明書の設定まで変更しないでください。
パスを引き継ぐ場合は、キャプチャグループと置換時の参照方法を明確に設計し、トップページ、サブパス、クエリパラメーター付きのリクエストを個別にテストします。範囲の広い正規表現をすべてのサイトにそのまま適用しないでください。ログイン、決済、署名付きURLはパスやパラメーターの変更に敏感です。誤った置換でリクエストの検証に失敗することがあります。
7. 保存後の検証方法：状況に応じて原因を絞り、設定全体は置き換えない
検証時はネットワーク、サーバー、テスト対象を同じ状態に保ち、変更する設定は一度に1つだけにします。まずConnectivity Testで基本的な接続の問題を切り分け、その後、対象リクエストの接続ログと適用されたポリシーを確認します。遅延テストに成功しても、対象サイトにアクセスできるとは限りません。既存の接続が以前の状態を再利用する場合もあるため、対象ページを閉じてからリクエストを再送してください。
ファイルを保存したのに、ルールが反映されないのはなぜ？
まずConfigで現在選択されているファイルを確認し、次にHome → Global RoutingでConfigを選択します。同じ宛先に再接続して、ルールを確認してください。引き続き誤ったポリシーが適用される場合は、そのルールより前に範囲の広いルールが一致していないか確認します。
Hostを追加してもHTTPSでエラーになるのはなぜ？
マッピング先のIPで動作するサービスが元のドメイン名を受け付け、そのドメイン名に一致する証明書を提供しているか確認してください。Hostが変更するのはアドレスのマッピングであり、証明書の識別情報ではありません。まずマッピングを解除して結果を比較してください。証明書検証を無効にして設定ミスを隠さないでください。
サブスクリプションの更新に成功したのに、PROXYで接続できないのはなぜ？
Homeに戻り、現在選択中のサーバーを確認してConnectivity Testを実行します。サブスクリプションの更新成功は、項目を取得できたことを示すだけです。サーバーへの到達性、認証パラメーターの正しさ、ルールが参照するポリシーの有無をそれぞれ確認してください。
URL Rewriteを追加したらリダイレクトが繰り返される。まず何を削除すればよい？
まず追加したばかりの書き換えルールを削除し、他の設定はそのままにして再テストします。次に、置換先が同じ式に再び一致していないか、サイト側が元のアドレスにリダイレクトしていないか確認してください。一致範囲を絞ったうえで、そのルールだけを有効にします。
最後に、2種類の更新を区別してください。サーバーのサブスクリプションを更新した後は、選択中の項目が変わっていないか確認します。リモート設定を更新した後は、ローカルでの編集が上書きされていないか確認します。長期的に残す変更は、目的を記録したうえで専用のローカルコピーに保存してください。原因を調べるには、未検証のパラメーターを追加し続けるより、検証済みの前の設定に戻すほうが簡単です。