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

1. .confファイルの構造：セクション名によって各行の解釈が変わる

Shadowrocketの.confはテキスト形式の設定ファイルです。角括弧で囲まれた名前は、[General]のような設定セクションの見出しです。見出し以降の内容は、次の見出しが現れるまでそのセクションに属します。同じ行でも、置かれたセクションによって意味が変わります。編集前に、まず該当箇所を確認してください。

[General]には主に全般設定、[Rule]には通信のマッチ条件とポリシー、[Host]にはローカルのドメインマッピング、[URL Rewrite]にはURLの書き換えルールを記述します。これらは順番に実行される4つの振り分けルールではありません。特に、ファイル内のセクションの並び順を、ネットワークリクエストが必ず通る処理順と解釈しないでください。

以下は構造を確認するための例です。example.comは例示用ドメイン、192.0.2.10は文書用に予約された例示アドレスであり、実際のサービスアドレスではありません。この内容を使用中の設定にそのまま置き換えないでください。#で始まる独立したコメント行は説明用で、ルールのマッチングには使われません。

[General]
dns-server = system

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

[Host]
lab.example.com = 192.0.2.10

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

設定をコピーする際は、半角の角括弧、カンマ、等号を使用してください。ルールの末尾に日本語の説明を追加しないでください。変更内容を後から確認できるようにするには、すべてのセクションを並べ替えるのではなく、対象行の前に独立したコメントを追加して変更理由を記録します。

2. General：全般設定とDNSの設定

[General]では、通常キー = 値の形式で設定を記述します。例のdns-server = systemは、システムが提供するDNSサーバーを使用する設定です。これは振り分けルールではなく、すべてのリクエストがDIRECTになるという意味でもありません。ドメイン名の名前解決と、接続に適用されるポリシーは、それぞれ別に確認する必要があります。

DNSクエリには通常53番ポートが使われますが、ログに表示されたポート番号だけで名前解決全体の経路を判断することはできません。暗号化DNSと通常のDNSでは通信方式が異なります。元の設定に明示的なDNS設定がある場合は、まず現在の値を記録してから必要に応じて変更してください。特定のドメインを調べるために、すべての名前解決設定をまとめて置き換えるのは避けましょう。

ファイル内の設定とSettingsのスイッチも、同じ種類の設定ではありません。たとえばSettings → On Demandは接続を開始する条件を扱うもので、特定のドメインをDIRECTに変更する機能ではありません。問題の切り分け中はOn Demandの元の状態を記録してください。手動で接続を切った後に再接続が自動で始まり、直前の変更が保存されていないと誤認するのを防げます。

3. Rule：マッチ対象、順序、FINAL

[Rule]のルールは上から順に確認され、マッチしたルールに指定されたポリシーが適用されます。そのため、例外を正確に指定するルールは、通常、より広い条件のルールより前に置きます。例外ルールをFINALの後に追加しても、先に適用された最終ルールを上書きすることはできません。

DIRECTは直接接続、PROXYはプロキシポリシーの使用、REJECTは拒否を意味します。PROXY自体にサーバーアドレス、認証情報、接続サービスは含まれません。この記事では、利用者がすでに自身のサービス事業者とサブスクリプションを用意していることを前提としています。例を使う前に、Homeに利用可能な接続項目があることを確認してください。

no-resolveは、このIPルールにマッチさせるためだけにドメイン名を積極的に名前解決することを防ぎます。すべてのDNSを無効にする指定ではなく、ドメイン名に自動でアドレスを割り当てるものでもありません。GEOIPはIPデータベースに基づいて判定します。ウェブページの言語、ドメインの末尾、利用者の現在地で判定するものではありません。

Global RoutingのProxy、Direct、Config、Sceneは、それぞれ異なるルーティングモードです。Configでは設定ファイルのルールに基づいて振り分けます。Sceneでは、該当するシーンの設定も確認が必要です。現在のモードを記録しておくことは、ルールの問題を再現するために欠かせません。

4. Host：ローカルのドメインマッピングと振り分けポリシーの違い

[Host]では、ドメイン名 = IPアドレスの形式でローカルマッピングを設定できます。たとえば次の行は、lab.example.comを文書用の例示アドレスに対応させます。これはドメイン名とアドレスの対応を設定するもので、リクエストにDIRECTとPROXYのどちらを使うかは指定しません。

[Host]
lab.example.com = 192.0.2.10

• 左側にはドメイン名を入力します。https://、パス、クエリパラメーターは入力しません。
• 右側のアドレスには、利用者自身が管理している、または使用を許可された環境のものを指定してください。例示用アドレスは実際の接続確認には使えません。
• この行ではサーバーのポートを指定しません。HTTPSの標準ポートは443です。それ以外のポートは、リクエストURLまたはアプリの接続設定で指定します。
• HTTPSへのアクセスでは、ドメイン名と証明書の照合も行われます。別のIPアドレスにマッピングしても、証明書が自動で一致するわけではありません。

Hostを変更しても古いアドレスに接続される場合は、開いているウェブページを閉じてから新しいリクエストを送信してください。ブラウザーやアプリのキャッシュ、確立済みの接続が確認結果に影響することがあります。ページの表示が変わったかどうかだけで判断せず、リクエストログで対象のドメイン名とアドレスを確認してください。

アプリによっては独自の名前解決を行ったり、あらかじめ設定されたIPアドレスに直接接続したりするため、このマッピングが想定どおり使われないことがあります。その場合は、アプリが実際にドメイン名とIPアドレスのどちらにリクエストしているかを先に確認してください。名前解決の問題が特定できていない段階で、適用範囲の広いRuleを追加して対処するのは避けましょう。

5. URL Rewrite：ドメインの振り分けではなく、URLパターンに基づく書き換え

[URL Rewrite]と[Rule]では、フィールドの構成が異なります。以下の例にはマッチ式、転送先URL、302が含まれています。これはHTTPリダイレクトを記述するもので、指定した旧アドレスにマッチした場合、クライアントを新しいアドレスへ転送します。PROXYポリシーではなく、サーバーへの接続設定にも使いません。

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

1. ^は文字列の先頭を指定し、似た文字列を別の位置に含むURLまでマッチするのを防ぎます。
2. \.はドメイン名に含まれる文字としてのピリオドを表します。正規表現でエスケープしていないピリオドは、より広い範囲にマッチします。
3. /old$はパスの末尾を指定するため、クエリパラメーターが後ろに付いたURLは、この完全一致の式にはマッチしません。
4. https://example.com/newはリダイレクト先のURLです。転送後も、通常どおり名前解決、振り分け、接続が必要です。
5. 302は一時的なリダイレクトを表します。テストでは、アドレスバーに最後に表示された内容だけでなく、リダイレクトの経路も確認してください。

この例では、意図的に暗号化されていないHTTP URLをマッチ対象にしています。HTTPSではパスやクエリパラメーターを含むリクエスト内容が暗号化されるため、この例を任意のHTTPSページを書き換えられる設定と解釈しないでください。HTTPSリクエストの内容を読み取る書き換えには、追加のMITM条件と信頼設定が必要です。URL Rewriteを1行追加するだけでは実現できません。この記事では、これらの設定を有効にする手順は入門向けの編集内容に含めていません。

リダイレクトループを防ぐため、転送先URLが同じルールに再度マッチしないようにしてください。最初のテストでは、対象を1つの管理可能なアドレスに絞り、マッチ条件を正確に保ちます。結果を確認してから、対象範囲を広げる必要があるか検討してください。すべてのドメインにマッチする正規表現から始めるのは避けましょう。

6. Configでの読み込みと編集：変更は1項目ずつ検証

Homeでは主に接続とルーティングモードを管理し、Configでは設定ファイルを管理し、Settingsではアプリの設定を行います。接続項目やサブスクリプションがあっても、特定の.confファイルが選択されているとは限りません。また、ファイルを読み込んでも、そのファイルが現在の設定として使われるとは限りません。編集後はConfigに戻り、選択状態を確認してください。

1. 元の設定を保存します。編集前に、現在利用できる設定のコピーを保存します。ファイル名、Global Routingのモード、今回変更する行を記録してください。
2. 読み込むファイルを用意します。自分が所有する.confファイルを読み込むか、信頼できる設定URLを使用します。リモートのテキストによってDNS、振り分け、書き換えの動作が変わる可能性があるため、読み込み前に内容を確認してください。
3. Configを開きます。追加メニューから、ファイルまたはURLを読み込む方法を選択します。読み込み後、ファイル名を確認し、想定したセクション見出しが含まれているか確認してください。
4. 編集画面を開きます。対象設定の操作メニューからテキスト編集を開き、セクションごとに設定値またはルールを1つ変更して保存します。編集メニューの表示方法は、現在の画面に従ってください。
5. 使用する設定を確認します。保存したファイルをConfigで選択し、Home → Global RoutingでConfigが選択されていることを確認します。テスト前に必要に応じて接続し直してください。
6. 同じリクエストを再現します。同じ対象に再度アクセスし、リクエストログでマッチしたルール、ポリシー、宛先アドレスを確認します。失敗した場合は、直前に変更した項目を元に戻してから、もう一度テストしてください。

リモート設定の更新と接続項目のサブスクリプション更新は、別々の操作です。前者では.confの内容が置き換わることがあり、後者では主に既存のサブスクリプションに含まれる接続項目が更新されます。リモート更新で上書きされるファイルに独自の変更を直接書き込むと、次回の更新で失われる可能性があります。別のコピーを保存し、更新の前後で重要なセクションを比較してください。

設定が有効かどうかを判断するには、「保存したファイル」「現在選択されているファイル」「Global Routingのモード」「新しく送信したリクエスト」のすべてを確認します。保存完了の表示だけでは、リクエストに新しいルールが適用されたとは判断できません。

7. 設定ファイル編集でよくある質問