Shadowrocket 設定ファイル構成を詳しく解説：[General] [Rule] [Host] [URL Rewrite] の役割

まず .conf のセクションと処理順を理解する

Shadowrocket の .conf ファイルは、1行目から最終行まで順番に実行するスクリプトではありません。複数の角括弧付きセクション名で区切られた宣言型の設定です。セクション名によって後続の行を処理するモジュールが決まり、たとえば [General] には共通パラメータ、[Rule] には振り分けルールを記述します。空行は通常、読みやすくするためだけに使われ、行頭のコメントは説明用で照合には影響しません。

設定を読むときは、まずセクション名のつづり、次に各行の区切り文字、最後に同じセクション内の順序依存を確認します。右角括弧の欠落、中国語の読点、ポリシー名の誤記があると、その行が機能しない場合があります。編集後は Config に戻って設定を選び直し、ファイルを読み込めるかだけでなく、実際のドメインへのリクエストで動作を確認してください。

4つの主要セクションは、すべて同じ段階で機能するわけではありません。[Host] は特定のドメインからアドレスを取得する方法に影響し、[Rule] はリクエストに適用するポリシーを決め、[URL Rewrite] は認識可能な URL に対してリダイレクトや拒否を行います。これらを1つのセクションに混在させると、個々の行が正しく見えても期待どおりには動作しません。

[General]：DNS、bypass と基本動作

[General] は設定の共通パラメータセクションです。ここに記述する項目は、DNS 解決、システムのバイパス動作、ローカルネットワークアドレスの処理など、基本的な動作に影響します。振り分けルールの一覧ではないため、DOMAIN-SUFFIX や FINAL をここに記述することはできません。設定の提供元によって項目は異なるため、確認時は Shadowrocket の現在の画面で読み込み・書き出しできるフィールドを基準にしてください。

dns-server は、設定で使用する DNS の解決先を指定します。system と記述すると、システムで利用可能な DNS 設定を使用します。明示的なアドレスを指定する場合は、現在のネットワークから到達できることを先に確認してください。DNS はドメインをアドレスに変換しますが、最終的に PROXY と DIRECT のどちらを使うかは決めません。ポリシーは Global Routing と [Rule] によって決まります。

[General]
bypass-system = true
dns-server = system
ipv6 = false
skip-proxy = 127.0.0.1, localhost, *.local, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16

bypass-system は、システム関連のバイパス処理を使用するかどうかを制御します。skip-proxy は、プロキシ処理に渡さないホストやアドレス範囲を明示します。上の例にはループバックアドレス、.local 名、3つの代表的なプライベートアドレス範囲が含まれていますが、構文説明用であり、すべてのネットワークにそのまま適用できるわけではありません。社内ネットワーク、家庭用ストレージ、プリンターでは異なるサブネットが使われることがあるため、変更前に機器が現在取得しているローカルアドレスを確認してください。

ipv6 = false は、この設定で IPv6 を明示的に無効にする記述例です。ただし、一般的な修復策として扱わないでください。接続中のネットワーク、既存のサービス設定、対象サイトが IPv6 に正常対応している場合、無効化によって解決結果が変わる可能性があります。トラブルシューティングでは一度に1項目だけ変更し、変更前後の DNS 結果とアクセス状況を記録してください。

[Rule]：上から順に照合し、FINAL でフォールバック

[Rule] は、順序の影響を受けやすいセクションです。Shadowrocket の Global Routing を Config に設定すると、設定内の並び順に従ってリクエストを上から下へ確認します。最初に適用可能なルールに一致すると、その行末のポリシーを採用し、「より具体的な」後続ルールは検索しません。そのため、具体的なドメインは通常、広範なサフィックスルールや地域ルールより前に配置します。

一般的なルールは半角カンマで区切ります。DOMAIN は完全一致のドメイン、DOMAIN-SUFFIX はドメインサフィックス、IP-CIDR はアドレス範囲、GEOIP はアドレスの地域、FINAL はそれまでに一致しなかったリクエストを処理します。ポリシーには通常、PROXY、DIRECT、REJECT を指定します。

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

上の例の1行目は、api.example.com に優先して DIRECT を適用します。2行目を1行目より前に置くと、完全なドメインが先に DOMAIN-SUFFIX,example.com に一致し、後の例外ルールは実行されません。no-resolve は、この IP ルールの照合時に追加のドメイン解決を行わないための指定で、対象アドレスだけを確認すればよいルールに適しています。

Global Routing は、ルールを判断に使うかどうかを変えます。Config は現在の設定のルールを使用し、Proxy はプロキシポリシーを強制し、Direct は直接接続します。Scene は設定済みのシーン条件に従って動作を決めます。単一のルールをテストするときは、Proxy や Direct のままになっていないことを確認してください。そうでなければ、[Rule] を変更しても期待した違いが現れません。

1. Home で、テストするサーバー設定が選択されていることを確認します。
2. Global Routing を Config に切り替えます。
3. Config で、対象の .conf が選択されていることを確認します。
4. 検証する具体的なルールを、広範なルールより前に移動します。
5. リクエストを再実行し、適用されたポリシーが想定どおりか確認します。
6. 最後に、FINAL がルールセクションの末尾にあることを確認します。

[Host]：固定ドメインマッピングと振り分けルールの違い

[Host] は、指定したドメインを明示的なアドレスにマッピングします。設定内で DNS の解決結果を上書きする機能と考えられます。これは「このドメインからどのアドレスを得るか」を解決するもので、リクエストを PROXY、DIRECT、REJECT のどれに振り分けるかは決めません。最終的なポリシーは [Rule] で処理する必要があります。

以下では、ドキュメント用に予約されたアドレスで形式を示します。192.0.2.0/24 と 2001:db8::/32 はドキュメント例専用であり、実際のサービスアドレスとして扱わないでください。実際の設定には、自分で管理している、または利用可能であることを確認した対象アドレスを指定します。

[Host]
example.com = 192.0.2.10
api.example.com = 192.0.2.20
ipv6.example.com = 2001:db8::10

Host マッピングで最もよくある確認ミスは、ドメイン階層が一致していないことです。example.com だけを記述しても、api.example.com に同じマッピングが自動的に適用されるとは限りません。サブドメインも対象にする場合は、現在の設定が対応するマッチ方法を項目ごとに確認し、実際の解決結果で検証してください。見た目が似ているドメインだけで判断しないでください。

[URL Rewrite]：リダイレクト、拒否、HTTPS の可視性

[URL Rewrite] は、URL のマッチング式に基づいてリクエストの結果を変更します。一般的な用途は、302 リダイレクトを返すことや、reject で条件に一致するリクエストをブロックすることです。URL を処理する機能であり、[Rule] が主にドメイン、アドレス、地域に基づいてポリシーを選択するのとは異なります。相互に代用することはできません。

式内のドットはエスケープし、パスの境界もできるだけ明確に記述します。広すぎる式はページ、API、静的リソースを同時に捕捉し、ページの構造が崩れたりアプリのリクエストが失敗したりする原因になります。作成時は、まず1つのテストドメインと1つのパスに限定し、結果を確認してから範囲を広げてください。

[URL Rewrite]
^http://example\.com/old$ http://example.com/new 302
^http://api\.example\.com/private - reject

1行目は、旧アドレスへの完全一致を新しいアドレスへリダイレクトします。末尾の 302 は一時的なリダイレクトのステータスです。2行目はハイフンで置換先の位置を埋め、reject を処理動作として指定します。フィールド間は半角スペースで区切り、正規表現内に日本語の句読点を入れないでください。

HTTPS リクエストのパスは暗号化された内容に含まれるため、ドメインへの接続だけでは完全な URL を確認できない場合があります。HTTPS のパスを確認または書き換えるには、Shadowrocket でユーザーが明示的に許可した証明書と復号範囲を設定し、自分が確認したテストドメインだけで有効にしてください。対象範囲を設定していない場合、HTTP の例は機能しても HTTPS の例は機能しません。これは暗号化された内容の可視性の違いであり、必ずしも正規表現の誤りではありません。

• まず完全な開始記号 ^ と終了記号 $ で、テストするアドレスを完全一致に限定します。
• ドメイン内の英文ピリオドは \. と記述し、任意の1文字に一致するのを防ぎます。
• まず単一のルールをテストし、前方の式が先に一致していないことを確認します。
• ページのリソースが欠落した場合は、直近に追加した書き換え行を一時的に無効にして再テストします。
• HTTPS は、確認と許可が済んだドメイン範囲だけを対象に検証してください。

最小構成の設定と読み込み後の確認手順

4つのセクションを組み合わせるときは、まず少数のテスト行だけを含む最小構成を作ることをおすすめします。最小構成の目的はすべての要件を網羅することではなく、各現象を1行に対応させることです。DNS は General、アドレスの上書きは Host、振り分けは Rule、URL の動作は URL Rewrite が制御します。

[General]
bypass-system = true
dns-server = system
skip-proxy = 127.0.0.1, localhost, *.local, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16

[Host]
test.example.com = 192.0.2.10

[Rule]
DOMAIN,test.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

[URL Rewrite]
^http://example\.com/old$ http://example.com/new 302

読み込み後に Config を開き、設定が選択されていることを確認してから Home に戻り、Global Routing を Config に設定します。既存のサービス提供元の設定サブスクリプションを使用している場合は、更新後にローカルで加えた変更が残っているか再確認してください。リモート更新によって古い内容が新しい内容に置き換わる場合があります。URL 形式をテストするときは、https://example.com/sub?token=xxxx のような明確な例でフィールドの位置を確認できますが、例の値を利用可能なサービスとして扱わないでください。

1. 元の .conf のコピーを残し、テストファイルには見分けやすい名前を付けます。
2. すべてのセクション名が半角の角括弧で囲まれ、セクション名の後に余計な文字がないことを確認します。
3. Rule の各行が半角カンマを使い、ポリシーが行末にあることを確認します。
4. 具体的なルールが広範なルールより前にあり、FINAL が最後にあることを確認します。
5. Host のアドレス形式が正しく、ドメインにプロトコルの接頭辞やパスが含まれていないことを確認します。
6. URL Rewrite の正規表現、置換先、動作フィールドの数がすべて揃っていることを確認します。
7. Home を開いて Global Routing を確認し、その後、解決、振り分け、書き換えを個別にテストします。

設定が正常に動作しない場合は、複数のセクションを同時に変更しないでください。まず [General] と1行の FINAL だけを残して基本接続を確認します。次に DOMAIN のテストルールを1行追加し、その後 Host マッピングを追加して、最後に URL Rewrite をテストします。段階的に戻すことで、エラーが解決、照合、書き換えのどこにあるかをすばやく特定できます。

設定確認における最終的な判断基準

設定が正しいかどうかを、接続スイッチがオンになっていることだけで判断しないでください。完全な検証には少なくとも4項目が必要です。ドメインが想定したアドレスを取得できるか、Global Routing が想定した状態か、リクエストが正しいポリシーに一致するか、URL Rewrite が対象パスだけに影響しているかを確認します。各項目が明確なセクションと具体的な設定行に対応している必要があります。

Shadowrocket は Apple プラットフォーム向けのクローズドソースの商用アプリで、主に iPhone と iPad で使用します。Mac、Apple TV、Apple Vision の互換性とシステム要件は App Store の掲載内容を基準にしてください。正規の入手先は App Store で、開発者名は Shadow Launch Technology Limited、アプリ ID は 932747118、購入方式は買い切りです。クライアントの購入と、ユーザーがすでに保有しているサービス設定は別の事項です。