Shadowrocketの設定ファイル「.conf」の構成と使い方｜General・Rule・Host・URL Rewriteを解説

この記事の概要

.confを読む際は、基本設定、ルーティングルール、ドメインマッピング、リクエストの書き換えを区別し、現在有効な設定ファイルとGlobal Routingを確認しましょう。自身で用意したサービスとサブスクリプションがあり、ローカル設定を編集したい方向けの記事です。例は構文の説明のみで、接続に使えるパラメータは含みません。変更後はアプリ内の接続ログで実際のマッチ結果を確認してください。

1. .confのセクション構成：セクション名が役割を示す

Shadowrocketの.confはテキスト形式の設定ファイルです。角括弧で囲まれた部分がセクション名で、その後に続く内容は次のセクション名が現れるまで同じセクションに属します。[General]にはキーと値の設定、[Rule]には1行ごとのマッチルールが記述されます。内容を誤ったセクションに記述しても、期待どおりには動作しません。

Homeでは接続やサーバーの選択、Configでは設定ファイルの管理、Settingsではアプリの設定を行います。サブスクリプションで提供されるサーバーパラメータと、.confで通信の振り分けを決めるルールは別のものです。サーバーリストを読み込んだり更新したりしても、現在使用中の設定ファイルが切り替わるわけではありません。

4つのセクション

General、Rule、Host、URL Rewriteを解説

3つの画面

Home、Config、Settingsの役割

1つの最終ルール

例ではRuleの最後にFINALを配置

以下の例は構成を確認するためのもので、サーバー情報を含む完全な接続設定ではありません。example.comは例示用ドメイン、192.0.2.10はドキュメント用の例示アドレスです。実際の設定に接続パラメータとして残さないでください。

[General]
dns-server = system

[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
FINAL,PROXY

[Host]
example.com = 192.0.2.10

[URL Rewrite]
^http://example\.com/ https://example.com/ 302

1つのファイルにこれらのセクションが含まれていても、リクエストがファイル内のセクション順に処理されるとは限りません。セクションは設定を整理するための構成であり、解析、ルーティング、書き換えにはそれぞれ異なる処理条件があります。特に、上から「Rule、Host、最後にURL Rewrite」という固定のリクエスト処理順だと解釈しないでください。

2. General：基本動作とDNS設定

[General]には基本設定を記述します。このセクションを確認するときは、キー名、等号の右側の値、値のリストに使われている区切り文字を1つずつ確認してください。別の設定形式にある似た項目をそのまま貼り付けず、Shadowrocketの編集画面で認識・保存され、実際に使用できる設定項目を使いましょう。

[General]
dns-server = system

ここでのdns-server = systemは、システムDNSを使う設定です。すべてのリクエストが必ずDIRECTになるという意味ではなく、特定のサイトをPROXY経由にする指定でもありません。DNSはドメイン名の解決を、ルールは通信の振り分けを担当します。原因の切り分けでは相互に影響することがありますが、役割は異なります。

ドメイン名では開けないが、IPアドレスへの直接アクセスには応答がある：まず名前解決の結果とDNS設定を確認し、すぐにRule全体を置き換えないでください。
ドメイン名は解決できるが、想定と異なる経路になる：DNSだけを変更するのではなく、Global RoutingとマッチしたRuleを確認してください。
ネットワークを切り替えると結果が変わる：システムDNSは接続中のネットワークによって変わる場合があります。テスト時にWi-Fiとモバイル通信のどちらを使ったか記録しましょう。
既存ファイルを編集する：同じ設定を複数記述して優先関係が不明確にならないよう、既存の同名設定を優先して変更してください。

DNSの変更とルーティングの変更は分けてテストしましょう。Generalの複数項目、Hostのマッピング、Ruleを一度に変更すると、ページが開けるようになっても、どの変更が効いたのか特定できず、後から元に戻すのも難しくなります。

3. Rule：上から順にマッチし、FINALは最後に配置

[Rule]では、リクエストに適用するポリシーを指定します。ルールは記述順に評価され、最初にマッチしたルールによって処理方法が決まります。具体的なルールを、より広範囲にマッチするルールより前に配置してください。FINALにはドメインやアドレスの条件がなく、それ以前のルールにマッチしなかった通信を受けるため、このセクションの最後に置きます。

キーワード	構文例	確認ポイント
`DOMAIN-SUFFIX`	`DOMAIN-SUFFIX,example.com,PROXY`	このドメインとサブドメインにマッチします。任意の文字列を含むかどうかの判定ではありません。
`IP-CIDR`	`IP-CIDR,192.0.2.0/24,DIRECT,no-resolve`	IPv4のネットワーク範囲でマッチします。no-resolveを指定すると、このルールの判定のためにドメイン名の解決を試みません。
`GEOIP`	`GEOIP,CN,DIRECT`	IPアドレスの地理情報データベースによる分類で判定します。Webページの言語による判定ではありません。
`FINAL`	`FINAL,PROXY`	追加のマッチ条件を指定せず、最後に残りの通信を受けます。

PROXYとDIRECTはポリシーであり、プロトコル名ではありません。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuardなどの接続方式のパラメータは、該当するサーバー設定で確認してください。ポリシーの代わりにFINAL,Trojanと記述することはできません。カスタムポリシー名を使う場合は、その名前が実在し、使用可能であることも確認してください。

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

この順序では、api.example.comは先にDOMAINにマッチしてDIRECTが適用されます。一方、www.example.comは後続のDOMAIN-SUFFIXにマッチし、PROXYが適用されます。DOMAIN-SUFFIXを前に移動すると、先に記述した特定の例外が適用されません。テストでは対象の完全なホスト名にアクセスし、同じサイトの別のサブドメインで代用しないでください。

要点：まずマッチした行を確認し、その後に最終ルールを変更

対象の通信が前方のDOMAINまたはDOMAIN-SUFFIXにすでにマッチしている場合、FINALを変更してもポリシーは変わりません。まず接続ログでマッチ結果を特定し、該当ルールの位置や内容を調整してください。

4. HostとURL Rewrite：アドレスのマッピングとリクエストの書き換えは別

[Host]では指定したドメイン名にアドレスを割り当てます。[URL Rewrite]では、リクエストURLに対するマッチ式に基づいて書き換えやリダイレクトを行います。前者は「この名前に対応するアドレス」を、後者は「条件に合うURLをどう変更するか」を扱います。どちらもRuleのルーティングポリシーの代わりにはなりません。

Hostのマッピング

セクション名: [Host]
左辺: example.com
右辺: 192.0.2.10
記述方法: example.com = 192.0.2.10

例示アドレスは構文の確認用です。実際に使用するマッピングはユーザー自身で確認してください。

URL Rewriteによるリダイレクト

セクション名: [URL Rewrite]
マッチ式: ^http://example\.com/
転送先URL: https://example.com/
動作: 302、一時的なリダイレクト

マッチ式、転送先URL、動作は半角スペースで区切ります。

Hostを設定しても、ブラウザーのアドレスバーに表示されるドメイン名がIPアドレスに変わるわけではなく、接続先サーバーがそのドメイン名を自動的に受け付けるわけでもありません。HTTPSでは、証明書の名前がアクセス先のホスト名と一致している必要があります。ドメイン名と一致しないサーバーにマッピングすると、証明書エラーや想定外のサイト応答が発生することがあります。マッピングを修正し、証明書検証の無効化を通常の解決策にしないでください。

URL Rewriteの例では、^は先頭からのマッチ、\.はドメイン名中のリテラルのピリオド、302はクライアントを転送先URLへリダイレクトする指定です。この例はHTTP URLをHTTPSのURLへリダイレクトする方法を示すもので、任意のパスやクエリパラメータが維持されるとは限りません。維持する場合は、キャプチャグループと置換式を明示的に設計してください。

まず1つのテストURLで式を検証し、すべてのドメインにマッチするような広範囲の記述をいきなり使わないでください。
HTTPの例ではHTTPSコンテンツの復号は必要ありません。HTTPSのパスや内容を読み取るルールでは、通常、別途HTTPS復号の条件と信頼設定が必要です。
Hostを追加した後にアクセス異常が起きたら、まずそのマッピングを取り消してください。URL Rewriteを追加した後にリダイレクトが繰り返される場合は、転送先URLが同じルールに再びマッチしていないか確認してください。

5. Configでの編集手順：バックアップ、保存、有効化、確認

Configでファイルを編集する前に、現在実際に有効になっている設定を確認してください。ファイルがリストに存在すること、テキストが保存されていること、設定が選択されて有効になっていることは、それぞれ別の状態です。有効でないファイルを編集しても、現在の接続に新しいルールはすぐには反映されません。

元ファイルを保管複製を編集保存して有効化モードを確認新しいリクエストを送信ログを確認

元ファイルを保管：Configで元ファイルの名前を確認し、ファイル操作から複製を保存するか、元ファイルをエクスポートしてください。リモート設定URLから取得したファイルの場合は、後の更新で手動変更が上書きされないよう、復元できるローカル版を先に保存しましょう。
編集画面を開く：対象設定のファイル操作からテキスト編集画面を開きます。セクション名はそのままにして、必要な箇所だけを変更してください。アプリの画面構成によっては、ファイル操作メニュー内に入口があります。現在の画面表示を確認してください。
構文を確認して保存：Ruleのフィールドは半角カンマ、GeneralとHostのキーと値は等号、URL Rewriteのフィールドはスペースで区切ります。全角カンマ、全角角括弧、説明文をパラメータに誤って含めないよう注意してください。
設定を選択：Configのリストに戻り、編集したファイルが有効になっていることを確認します。その後、Homeで現在のサーバーと接続状態を確認してください。
Global Routingを確認：RuleのテストにはConfigを使用してください。ProxyとDirectは全体のルーティングモードです。そのアクセス結果だけでは、個々のRuleが有効かどうかを判断できません。Sceneを使用する場合は、シーンで実際に使われている設定とポリシーも確認してください。
新しい接続を作成：保存後、新たにテストリクエストを送信し、必要に応じて接続を切断してから再接続してください。既存の接続やキャッシュに以前の状態が残ることがあります。新しい接続ログで対象ドメイン、マッチしたルール、最終的なポリシーを比較しましょう。

Settings → On Demandでは自動接続の条件を設定します。Ruleの適用順を決める項目ではありません。「変更後に自動で再接続する」場合はこの設定を確認し、「特定のドメインに誤ったポリシーが適用される」場合はGlobal Routingと現在の設定ファイルを確認してください。自動接続と通信の振り分けを分けて調べることで、変更箇所を正確に特定できます。

6. よくある質問：設定が反映されない、更新で上書きされる、元に戻す

いずれの問題も、現在のファイル、現在のモード、新しいリクエストのログを照らし合わせて確認してください。ブラウザーでページを開けたとしても、1回のアクセスが成功したことしか分かりません。特定のルールが実行されたことや、想定したサーバーが使われたことの証明にはなりません。

Ruleを保存したのに、以前と同じポリシーが使われるのはなぜですか？

まずConfigで、編集したファイルが選択されていることを確認します。次にHome → Global RoutingがConfigになっているか確認してください。新しいリクエストを送信して接続ログを確認します。前方のルールにすでにマッチしている場合は、その行を変更するか順序を調整してください。FINALの後ろにルールを追加し続けても解決しません。

サブスクリプションを更新すると、手動で編集した.confも更新されますか？

サーバーのサブスクリプション更新とリモート設定の更新は別の操作です。更新したのがHomeのサーバーリストか、Configのリモートファイルかをまず確認してください。リモート設定を再取得するとローカルの内容が置き換わる場合があります。重要な変更は複製を保存し、更新後に項目ごとに比較してください。

Hostを追加したら証明書エラーが発生しました。どこを修正すればよいですか？

まず追加したマッピングを取り消し、新しい接続で再テストしてください。マッピング先のアドレスが元のホスト名に対応するサービスを提供していることを確認し、サーバー証明書も確認します。誤ったマッピングを維持するために証明書検証を無効にしないでください。Hostで変更できるのはアドレスの対応関係であり、証明書が対象とする名前は変更できません。

設定を壊してしまった場合、既存のサブスクリプションに影響させずに復元するには？

Configでバックアップファイルを選び直し、テスト前のGlobal Routingに戻してから、接続を再確立して確認してください。Homeに登録済みのサーバーやサブスクリプションを先に削除しないでください。元の設定が正常に戻ったことを確認してから、複製に変更を1つずつ加え、問題のある行を特定しましょう。

最終確認では、まずファイルが有効かを確認し、次にルーティングモード、マッチ結果の順に確認してから、DNS、Host、書き換え条件を調べます。設定ファイルの価値は、動作を検証でき、変更を元に戻せることにあります。1つのファイルにできるだけ多くの項目を詰め込むことではありません。