Shadowrocketの.confファイルはセクションごとに設定を記述します。サブスクリプションのURLを書き込むだけで通信の振り分けが完了するわけではありません。自分で契約したサービスとサブスクリプションを利用し、Configで設定を確認する方向けに、各セクションの役割、ルールやドメインマッピング、リダイレクトの例を解説します。設定は一項目ずつ変更し、再接続してリクエスト記録を確認する手順で検証します。
1. .confのセクション名・キーと値・適用条件
設定ファイルはテキスト形式です。角括弧内の名前がセクションを示します（例：[General]）。次のセクションが始まるまでの内容は、現在のセクションに属します。セクション名のスペースはそのまま残してください。[URL Rewrite]を別の表記に変更してはいけません。キーと値の設定には通常キー = 値を使い、ルールではフィールドをカンマで区切ります。この2つの書式は混同しないでください。
Homeでは接続とサーバー選択を管理し、Configでは設定ファイルを管理します。テキストをインポートまたは保存しただけでは有効になりません。Configで現在選択中のファイルを確認し、Home → Global RoutingでConfigを選択してください。Proxyは全通信をプロキシ経由にする設定、Directは全通信を直接接続する設定です。Sceneでは設定済みのシーンに応じてルーティング方法を選択します。ルールの順序を確認するときはConfigに固定し、シーン切り替えの影響を避けてください。
以下は単独で読める基本構成の例です。どのルールにも一致しない通信をDIRECTに送るため、ファイルが正しく解析されるかを確認する用途に適しています。あらゆるネットワークで使える完成済みの設定ではありません。example.comは説明用のドメインであり、本サイトがサービスを提供していることを示すものではありません。
[General]
dns-server = system
[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
FINAL,DIRECT- 通常のテキストエディタで編集し、句読点には半角の英数字記号を使ってください。説明文をルールの後ろに直接追記しないでください。
- ルールは1行に1つ記述します。コメントを付ける場合は別の行にし、
#から始めてください。 - 編集前に元ファイルのコピーを保存し、テスト用コピーを編集してください。DNS、ルール、書き換え設定を同時に変更しないでください。
- 実際の設定ファイルには、ここで紹介する4つ以外のセクションが含まれる場合があります。
2. General：基本動作を設定し、ルールの順序は管理しない
[General]には全体に適用する基本設定を記述します。たとえばdns-server = systemは、システムのDNS設定を使うことを示します。ただし、システムで選択されているリゾルバーがすべてのネットワークで利用できるとは限りません。別の名前解決方法に変更する前に、現在のWi-Fiまたはモバイル通信、対象ドメイン、発生している問題を記録してください。
DNSはドメイン名をIPアドレスに変換し、Ruleは通信に適用するポリシーを選択します。関連はありますが、同じ設定ではありません。名前解決に失敗しているとき、DOMAIN-SUFFIXルールを追加してもリゾルバーの問題は解決しません。同様に、DNSからアドレスが返ってきても、接続先のポートやプロキシ経路が利用できるとは限りません。
Generalの基本チェック
- セクション名
[General]- 設定項目
dns-server- 設定例
system- 書式
dns-server = system
まず現在の名前解決方法を確認し、変更するか判断してください。
アプリ内での適用確認
- ファイルの場所
- Config
- ルーティングの選択
- Home → Global Routing
- 確認時の設定
- Config
- 自動接続の設定
- Settings → On Demand
On Demandは条件に応じた接続を制御する機能であり、Ruleのマッチング処理を代替するものではありません。
テキストを編集するときは、設定名だけで項目の動作を推測しないでください。対応が確認されていないキーは無視されたり、解析エラーの原因になったりする可能性があります。Generalに項目を追加する場合は、アプリ内の設定編集画面にある該当項目と説明を確認し、変更前の値を残してください。On Demandの自動接続動作も別途確認し、トラブルの切り分け中に自動再接続で作業が中断されないようにしてください。
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とそのサブドメインに一致します。 | ドメイン名だけを記述し、プロトコル、ポート、パスは付けません。 |
IP-CIDR | 192.0.2.0/24のアドレス範囲に一致します。 | 説明用に予約されたネットワーク範囲であり、利用可能なサーバーアドレスではありません。 |
GEOIP | IPアドレスの位置情報データベースを使ってCNを判定します。 | 判定結果はIP位置情報データベースに依存します。ドメイン末尾だけでは判断できません。 |
FINAL | それ以前のルールに一致しなかったリクエストにPROXYを適用します。 | 一致値のフィールドは不要です。FINAL,PROXYと記述します。 |
no-resolveを指定すると、このIPルールとの照合のためにドメイン名を積極的に名前解決するのを避けられます。これは「すべてのDNSを無効にする」指定ではありません。リクエスト自体やほかのルールで名前解決が必要になる場合があります。リクエストにドメイン名しかなく、照合に使えるIPアドレスがない場合、no-resolve付きのIPルールには一致しないことがあります。実際の記録を確認してください。
PROXYはプロキシポリシー、DIRECTは直接接続ポリシーを表し、プロトコル名ではありません。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuardは接続プロトコルを示します。接続に必要な設定情報は、ユーザー自身が利用するサービスから取得してください。ポリシーにPROXYと記述しても、利用可能な接続が自動で作られるわけではありません。テスト前にHomeに利用可能なサーバーが登録されていることを確認してください。
ルールの問題を確認する：まずリクエストが一致した行を特定
対象ドメインの通信経路が想定と異なる場合は、まずリクエスト記録でドメイン名、マッチしたルール、適用ポリシーを確認してから、該当するルールだけを移動してください。Generalの設定を一度に変更すると、どの変更が影響したのか判断できません。
4. Host：ドメインのアドレスを固定し、出力ポリシーは選択しない
[Host]では、ドメイン名とアドレスの対応を指定します。基本の書式はドメイン名 = IPアドレスです。変更されるのはドメイン名に対応するアドレスです。RuleのDIRECTやPROXYを置き換えるものではなく、到達できないアドレスを接続可能にすることもできません。
[Host]
lab.example.com = 192.0.2.10この例は書式の説明用です。192.0.2.10は説明用に予約されたアドレスのため、インターネット接続のテストには使えません。自分のテスト環境では、管理下にあるドメインと実際に到達可能なアドレスを指定し、サービスの待ち受けポートも確認してください。Hostの1行には名前のマッピングだけを記述し、192.0.2.10:443のようにポートを付けないでください。HTTPではTCP 80、HTTPSではTCP 443が一般的です。ポートはURLまたはアプリの接続設定で決まります。
- ドメイン名には
lab.example.comを指定します。https://lab.example.com/pathのようなURL全体は指定しません。 - HTTPSを使う場合、サーバー証明書がリクエスト先のドメイン名と一致している必要があります。IPアドレスを固定しても証明書の検証は回避できません。
- テスト前に既存の接続を切断してから、リクエストを新しく送信してください。接続の再利用やキャッシュによって変更結果が見えなくなるのを防げます。
- テスト用のマッピングを削除した後、再度確認してください。一時的なアドレスが本番用の設定に残っていないことを確かめます。
「アドレスは変わったのにページが開かない」場合は、アドレスへの到達性、ポート上のサービス、証明書、ルーティングポリシーを個別に確認してください。Hostは名前解決の問題を切り分ける手段の一つです。インターネット上で見つけた任意のアドレスを長期利用する設定に書き込むのは避けてください。
5. URL Rewrite：URLにマッチさせ、リダイレクト動作を指定
[URL Rewrite]では、URLのマッチングと書き換えを設定します。以下の例は正規表現でHTTPのURLにマッチさせ、302でリダイレクト先を返します。DNSマッピングを作成する機能ではなく、ドメインをPROXYに指定する別の書き方でもありません。
[URL Rewrite]
^http://example\.com/(.*)$ https://example.com/$1 302^はURLの先頭、$は末尾を指定します。URLの途中の一部だけにマッチするのを防ぎます。example\.comではピリオドをエスケープしているため、正規表現で任意の1文字を表すのではなく、文字どおりのピリオドとして扱われます。(.*)はスラッシュ以降の部分をキャプチャします。転送先の$1は最初のキャプチャグループを参照します。302はリダイレクト動作を表します。ブラウザーは応答を受け取った後、転送先にリクエストを送ります。両端の通信が直接入れ替わるわけではありません。
この正規表現はhttp://example.com/で始まるURLだけにマッチします。https://example.com/や、明示的なポートを含むhttp://example.com:80/にはマッチしません。こうした適用範囲はテスト前に明確にしてください。「すべてにマッチさせる」ためにドメイン部分を安易に広げると、関係のないリクエストまで書き換えるおそれがあります。
リダイレクトがループする場合は、まず追加したルールを削除し、元のサイトの応答を確認してください。HTTPからHTTPSへの一方向のリダイレクトでも、サーバー側のリダイレクト処理と干渉することがあります。最終的にページが開くかだけで判断せず、初期URL、応答ステータス、転送先をそれぞれ記録してください。
6. 段階的に検証：名前解決・ルーティング・書き換えを分けて確認
4つのセクションは、基本動作、通信の振り分け、名前のマッピング、URLの処理をそれぞれ担います。4段階で必ず実行する固定の手順ではありません。リクエストごとに、名前解決の要否、URLを参照できるか、ドメインルールに一致するかなどが実際の処理に影響します。以下の数字はこの記事の設定例を説明するもので、アプリの対応範囲全体を示すものではありません。
- Configで元ファイルのコピーを保存し、テスト用ファイルが選択されていることを確認します。Home → Global RoutingでConfigを選択してください。
- まずGeneralとRuleだけをテストします。自分でアクセスできると確認済みの接続先を使い、日時、ネットワークの種類、選択したサーバーを記録してください。
- 接続を停止してから再接続し、新しいリクエストを送信します。名前解決エラー、接続タイムアウト、TLSエラー、HTTPステータスコードを区別してください。
- Hostが必要な場合は、管理下にあるドメインのマッピングを1つだけ追加し、変更前後の接続先アドレスを比較してください。
- 最後にURL Rewriteだけをテストし、リダイレクト先を確認してください。失敗した場合は、設定全体を上書きせず、直近に変更した項目を元に戻します。
サーバー遅延テストで結果が得られても、そのテストで応答があったことを示すだけです。対象サイトのDNS、TCP 443、TLS、HTTPリクエストがすべて正常とは限りません。HTTP 403が返された場合は、サーバーから応答があったことを意味します。すぐに.confの書式が原因だと判断せず、サーバー側のアクセス条件を確認してください。
7. よくある質問：設定を保存したのに結果が変わらないのはなぜ？
Ruleを変更したのに、すべてのサイトがプロキシ経由になるのはなぜ？
まずHome → Global RoutingがProxyになっていないか確認します。Configに変更したら、Configに戻り、編集したファイルが選択されていることを確認してください。再接続して新しいリクエストを送信し、マッチしたルールを確認します。ウェブページの表示速度だけでポリシーを判断しないでください。
FINALをファイルの先頭に記述してもよいですか？
Rule セクションの最後に置きます。具体的なドメインやアドレスのルールを前に移し、たとえば DOMAIN-SUFFIX,example.com,DIRECT を先に、FINAL,PROXY を後に記述すると、そのドメインが直結ルールに一致する機会を確保できます。
サブスクリプションを更新すると、自分で変更した設定は保持されますか？
まずHomeのサーバーサブスクリプションと、Configのリモート設定を区別してください。前者は通常、サーバー項目を更新します。後者は設定ファイルを再取得する際に、ローカルの変更が上書きされることがあります。編集内容を長期的に保持するには、独立したローカルコピーに保存し、更新後に選択中のファイルを確認してください。
HostにIPアドレスを設定したら、HTTPSでエラーになるのはなぜ？
そのIPアドレスで対象ドメインのHTTPSサービスが稼働しているか、証明書がそのドメインをカバーしているかを確認してください。まずHostのマッピングを解除して結果を比較します。証明書の検証を無効にして、ドメイン名、アドレス、サーバー設定の問題を回避しないでください。
設定を保存した後の最終確認は3点です。現在のファイルが正しいこと、Global Routingの設定が正しいこと、新しいリクエストが想定したルールにマッチすること。この3点を確認してからDNS、接続先サービス、書き換えの適用範囲を調べると、接続障害をファイル形式の誤りと取り違えにくくなります。