· 上級設定 · 約10分

Shadowrocketの設定ファイル「.conf」の構成｜General・Rule・Host・URL Rewriteの役割

Shadowrocketの.conf設定ファイルをセクションごとに解説。General、Rule、Host、URL Rewriteの役割と書式、編集内容をConfigで反映する方法を紹介します。

この記事の概要

.confを編集するときは、まず各セクションの役割を確認し、次にConfigで実際に有効になっているファイルを確かめます。Generalには共通パラメータ、Ruleには接続ポリシー、Hostには静的な名前解決の設定、URL Rewriteには条件に合うURLの書き換えを記述します。サーバー情報をすでにお持ちで、設定ファイルの確認や管理が必要な方向けの記事です。例は書式の説明用で、利用可能なサーバーを含まず、既存設定のバックアップに代わるものではありません。

1. 設定ファイルの構成：セクション名は実行手順ではない

Shadowrocketの.confはテキスト形式の設定ファイルです。角括弧で囲まれた名前でセクションを区切ります。たとえば[General]と記述すると、次のセクション名が現れるまで後続の行はそのセクションに属します。セクションごとに書式が異なり、共通パラメータや静的マッピングには通常イコールを使い、Ruleではキーワード、条件、ポリシーをカンマで区切ります。

ここでは4つのセクションを取り上げますが、設定ファイルに含まれるセクションがこの4つだけとは限りません。既存ファイルを読むときは、内容を把握できていないセクションも残し、例に合わせるために削除しないでください。また、セクションの並び順はネットワークリクエストの処理順を表すものではありません。「HostがRuleの後にある」からといって、必ずルーティングの後に名前解決されるわけではありません。

4セクション
この記事で扱うのはGeneral、Rule、Host、URL Rewrite
カンマ3つ
no-resolveを含むIP-CIDRの例で使う区切りの数
FINALは1行
この記事のRule例の末尾に置く最終ポリシー
[General]
dns-server = system

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

[Host]
lab.example.test = 192.0.2.10

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

example.com、example.test、192.0.2.0/24は説明用の値です。静的マッピングで指定するアドレスは、実際の接続先サーバーではありません。例全体を日常的に使う設定へそのまま置き換えないでください。複製したファイルで、セクションごとに書式を検証する方法が適切です。

2. General：共通パラメータはルーティングルールではない

[General]には共通設定を記述します。ここでは確認しやすいパラメータとしてdns-server = systemを使います。イコールの左側がパラメータ名、右側が値です。systemはシステムのDNSを使用する指定です。これを[Rule]に書いたり、Ruleのカンマ区切り書式を使ったりしないでください。

[General]
dns-server = system

DNSは名前解決を行うもので、サーバーへの接続を代替したり、接続をPROXYとDIRECTのどちらにするか単独で決めたりするものではありません。たとえば、ドメイン名からIPアドレスを取得できても、サーバーへの接続に失敗することがあります。逆に、サーバーの遅延テストで結果が出ても、現在のDNSで対象ドメインを解決できるとは限りません。トラブルシューティングでは、名前解決と接続の結果を分けて記録してください。

3. Rule：上から順に照合し、FINALは末尾に置く

[Rule]はルーティングルールのセクションです。Home → Global RoutingでConfigを選択し、現在有効な設定のルールに照らして照合結果を確認してください。Proxyはすべての接続をプロキシ経由にし、Directはすべての接続を直接接続にするモードです。個別のルールを編集した結果の確認には使えません。Sceneを使う場合は、選択中のシーンとその条件を先に確認してください。Configと同じ動作だと決めつけないでください。

照合条件

DOMAIN-SUFFIX
example.com,PROXY
IP-CIDR
192.0.2.0/24,DIRECT,no-resolve
GEOIP
CN,DIRECT

3行のルールはそれぞれ、ドメインのサフィックス、IPアドレスの範囲、IPアドレスの地理情報に基づいて照合します。

ポリシーとフォールバック

PROXY
プロキシポリシーに渡します。利用可能なプロキシの出力先が必要です。
DIRECT
プロキシサーバーを経由せず、接続先に直接接続します。
FINAL
前のルールに一致しなかった場合に、指定したポリシーを適用します。例：FINAL,PROXY。

REJECTは一致した接続を拒否します。直接接続のポリシーと混同しないでください。

  1. DOMAIN-SUFFIX,example.com,PROXY：example.comとそのサブドメイン（例：www.example.com）に一致します。この文字列を含むすべてのドメインに対するあいまい検索ではありません。
  2. IP-CIDR,192.0.2.0/24,DIRECT,no-resolve：指定したIPv4アドレス範囲に一致します。no-resolveは、このIPルールの判定のためにドメイン名の解決を積極的に行わない指定です。アプリ全体のDNSを無効にするものではありません。
  3. GEOIP,CN,DIRECT：IPの地理情報に基づいてCNに一致させます。判定対象はIPデータであり、ドメインのサフィックスやサーバー情報に含まれる地域ラベルではありません。
  4. FINAL,PROXY：前のルールに一致しなかった接続をPROXYに渡します。ポリシーのフィールドだけで、ドメインやネットワーク範囲の条件はありません。

接続が前のルールに一致すると、それ以降のルールでポリシーが再選択されることはありません。そのため、適用範囲の広いルールより前に、より具体的な例外を置き、FINALは末尾に配置します。すでに前のルールに一致した接続は、ファイルの末尾に例外を追加しても結果が変わりません。

まとめ：モードを確認してから順序を調整

ルールが正しく見えるのに期待した結果にならない場合は、まずHome → Global RoutingがConfigになっているか確認し、次に現在の設定ファイルと最初に一致する可能性のあるルールを調べてください。同じドメインのルールを繰り返し追加するのは避けましょう。

4. Host：静的な名前解決とポリシー選択は別

[Host]では、指定したホスト名を指定したアドレスに対応付けます。接続先のアドレスがすでに明確な場合に使います。ここで設定するのは「この名前をどのアドレスに対応させるか」であり、「この接続をどの出力先にするか」ではありません。Hostでアドレスを指定していても、接続の処理方法は現在のルーティングモードと関連ルールに基づいて判断されます。

[Host]
lab.example.test = 192.0.2.10

静的アドレスは接続先サービスの変更によって使えなくなることがあり、動的に振り分けられるサービスでは特に注意が必要です。問題が起きたら、まず設定ファイルの複製からこのマッピングを削除して接続し直し、改善するか比較してください。Hostの項目を追加し続けるのは避けましょう。

5. URL Rewrite：URLを書き換える機能で、プロキシは選択しない

[URL Rewrite]では、条件に一致するURLに書き換え処理を行います。Ruleとの違いは、Ruleが接続ポリシーを選択するのに対し、URL RewriteはリクエストURLを処理する点です。ドメインのルーティングルールをそのままこのセクションに記述したり、プロキシサーバーのパラメータをリライト設定で代用したりすることはできません。

[URL Rewrite]
^http://example\.com/ https://example.com/ 302
フィールド例説明
照合パターン^http://example\.com/指定したHTTPアドレスで始まるURLに一致します。ピリオドの前のバックスラッシュは、ピリオドを文字として照合するためのものです。
転送先URLhttps://example.com/この例では固定の転送先アドレスを使い、パスのキャプチャと再利用は説明しません。
アクション302一時リダイレクトを返し、クライアントに転送先URLへの後続リクエストを行わせます。

このルールは意図的に平文のHTTPだけに一致させています。元のURLにパスやクエリパラメータが含まれていても、転送先フィールドでキャプチャグループを参照していないため、自動的には引き継がれません。パスを保持するには、正規表現のキャプチャ範囲を決めてから結果を1つずつ検証してください。リダイレクト後にログインコールバックやクエリパラメータが失われるのを防げます。

この例を「すべてのHTTPSアドレスをパスごとに書き換えられる」設定へ拡張しないでください。HTTPS内のURLを確認するにはMITMなどの追加条件が関わり、アプリの動作や証明書の仕組みにも左右されます。この記事ではMITMを有効にする必要はなく、証明書のインストールも扱いません。ここではこのセクションのフィールド構成だけを説明します。

6. Configで反映：ファイルを保存して選択し、接続を再確立

編集を終えても、現在の接続で新しい設定が使われるとは限りません。Configに複数のローカルファイルやリモート設定がある場合は、実際に選択されているファイルを確認する必要があります。ファイル名が似ているときは、テスト用の複製に見分けやすい名前を付け、元のファイルを復元用に残しておきましょう。

元ファイルをバックアップ複製を編集保存して選択モードを確認再検証
  1. Configを開いて、現在有効なファイル名を記録し、元ファイルの複製を保存します。編集するファイルの画面を開いたら、セクション名と変更予定の行を確認してください。
  2. 一度に変更するのは1つのセクション内の少数の項目にとどめます。保存してConfigに戻り、編集内容が保持されていることを確認してから、テストする設定を選択します。
  3. Home → Global Routingに戻り、Configを選択します。Sceneを使う場合は、シーンの選択結果を先に確認し、切り分けのために一時的にConfigへ切り替えるか判断してください。
  4. Homeで利用可能なサーバーが選択されていることを確認します。PROXYはポリシー名にすぎず、サーバーアドレス、ポート、認証情報を自動で用意するものではありません。
  5. ネットワークが一時的に切断されても問題ないことを確認してから、接続スイッチを一度オフにして再びオンにし、対象へのリクエストを新たに実行します。既存の長時間接続はそのまま再利用されることがあるため、変更前から開いているページだけを確認しないでください。
  6. リクエストの記録を確認し、対象ドメイン、対象IP、ポリシーの結果を照合します。動作が想定と異なる場合は、元の設定に戻して同じテストを繰り返し、今回の変更による差か判断してください。

サーバーのサブスクリプションと.conf設定ファイルも区別してください。前者は通常サーバー情報の管理に使い、後者はルールや共通設定の管理に使います。サーバーのサブスクリプションを更新しても、Configで有効なファイルが切り替わるわけではありません。また、リモート設定を再取得すると、そのファイルに直接書き込んだ変更が上書きされる場合があります。継続して管理する前に、どれがリモートの設定元で、どれが自分のローカル複製なのか明確にしてください。

まとめ：元に戻せる変更を1つずつ検証

「変更した行」「有効にしたファイル」「テストしたリクエスト」を毎回記録してください。同じリクエストで変更前後の差を説明できた場合に限り、その変更を日常的に使う設定へ反映しましょう。

7. よくある質問：症状から設定セクションを特定

Ruleを変更したのに、どのサイトも同じ接続方法になるのはなぜですか？

まずHome → Global RoutingでConfigが選択されているか確認し、次にConfigで有効なファイルを確認してください。それでも同じ場合は、Ruleの先頭に適用範囲の広すぎるルールがないか、FINALが早い位置にないか調べます。新しくリクエストを実行して検証し、既存の長時間接続を更新するだけで判断しないでください。

Hostにアドレスを設定したのに、HTTPSでエラーが出るのはなぜですか？

そのアドレスで対象ホスト名のサービスが実際に提供されているか確認し、証明書がそのドメインに適用されるか調べてください。Hostが変更するのは名前とアドレスの対応だけです。複製した設定から該当行を削除して比較し、アドレスの誤りを証明書検証の緩和で隠さないようにしてください。

URL Rewriteの保存には成功したのに、リダイレクトされないのはなぜですか？

実際のリクエストが例のHTTPアドレスで始まっているか確認し、次に正規表現のバックスラッシュ、空白による区切り、末尾のアクションを調べてください。ブラウザがリクエスト送信前にHTTPSへ切り替えている場合、HTTPだけを対象とするこのルールには一致しません。

更新後に手動で変更したルールが消えました。どこを確認すればよいですか？

まずConfigで現在選択されているファイルを確認し、リモート設定を再取得していないか調べてください。事前に保存したローカル複製と比較し、必要だと確認できた変更だけを移してください。サーバーのサブスクリプション更新と設定ファイルの更新を同じ操作と見なさないでください。

調整を続ける前に、ルールリファレンスでキーワードを確認するか、設定ガイドでルーティングモードとほかの機能を区別してください。Settings → On Demandではオンデマンド接続の条件を管理します。Configのファイル選択を代替するものではなく、Ruleの各行の書式も変更しません。

App Storeで正規品を確認App StoreでShadowrocketをダウンロード