Shadowrocket設定ファイルの書き方|.conf構文と分流ルールを実例解説

Shadowrocketの設定ファイルを直接編集したい方向けに、.confの基本構文と各セクションの役割を実例で解説します。ルールの優先順位やRULE-SETの参照方法に加え、リクエストログで通信の振り分けを確認する手順も紹介。URL RewriteやMITMを使う際の設定上の注意点、証明書とプライバシーのリスク…

ShadowrocketのConfigは、通信先と適用するポリシーをルールで結び付ける設定ファイルです。拡張子が.confでも、任意のテキストを並べれば読み込めるわけではありません。セクション名、キーと値の区切り、ルールの順序を正しく保ち、保存後は実際のログで一致したルールを確認する必要があります。以下の例に出てくるドメインやアドレスは書式説明用であり、接続先として利用できません。

この記事の要点

ShadowrocketのConfigファイルを自分で編集したい方向けに、基本的なセクション構成、[Rule]の優先順位、リモートRULE-SETの指定、読み込み後の確認手順を説明します。設定を変える前に元ファイルを複製し、最初は対象を限定したルールでテストしてください。MITMを使う場合の証明書とプライバシー上の注意点も取り上げます。

1. .confの構成と編集前の準備

ShadowrocketのConfigは、サーバー情報を追加する操作やSubscribeの更新とは別のものです。利用者自身が契約しているサービスの接続情報が必要な場合は、その情報をサービス提供元の案内に従って用意してください。当サイトは接続先やサブスクリプションを提供・販売・推奨していません。クライアントの購入と接続サービスの契約も別々です。

設定ファイルは、角括弧で囲んだセクション名と、その配下の設定行で構成されます。代表的なセクションには、一般設定の[General]、プロキシ定義の[Proxy]、グループ定義の[Proxy Group]、分流ルールの[Rule]、ホスト関連の[Host]があります。利用する機能に応じてセクションを設け、見出しの綴りや角括弧を変更しないでください。

[General]
loglevel = notify

[Proxy]
Example = ss, server.example.com, 443, encrypt-method=aes-128-gcm, password=REPLACE_WITH_YOUR_VALUE

[Proxy Group]
Select = select, Example, DIRECT

[Rule]
DOMAIN-SUFFIX,example.com,Select
GEOIP,CN,DIRECT
FINAL,Select

これは構文の説明用の短い例です。server.example.com、暗号方式、ポート、パスワードなどを実際の接続情報として使わないでください。Exampleという名前は、ここでは[Proxy Group]内から参照する項目名です。実際のファイルでは、サービス提供元から受け取った情報とShadowrocketが対応する書式に合わせて記述します。利用中のファイルがリモート管理されている場合、編集内容が次回更新で置き換わることがあるため、先に管理方法を確認してください。

ルールの基本

DOMAIN-SUFFIX
ドメインの末尾が指定値に一致する通信を判定します。
DOMAIN
指定したドメインそのものを判定します。
GEOIP
IPアドレスの地域情報を使って判定します。
FINAL
前のルールに一致しなかった通信の処理を指定します。

各ルールの最後には、適用するポリシー名を指定します。

編集時の確認

セクション
項目を対応する見出しの下に置きます。
区切り
ルールの項目はカンマで区切ります。
ポリシー
PROXY、DIRECTなど、定義済みの名前を使います。
バックアップ
変更前のファイルを複製して残します。

編集後は保存だけでなく、Configとして読み込まれた状態も確認します。

2. [Rule]の並び順とポリシーの考え方

[Rule]は上から順に評価され、先に一致したルールで処理が決まります。そのため、範囲の狭いルールを先に、広い範囲を対象にするルールを後に置くのが基本です。たとえば、特定のドメインをDIRECTにしたいのに、その前に広いDOMAIN-SUFFIXルールでPROXYを指定すると、後の例外まで到達しないことがあります。

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

この例では、video.example.comは最初のルールに一致してDIRECTになります。同じドメイン配下のほかの通信は次のDOMAIN-SUFFIXでPROXYとなり、以降も該当するルールがなければGEOIP、最後にFINALが処理を決めます。実際の通信ではアプリが接続するホスト名やIPアドレスが異なることもあるため、目的の通信がどのルールに一致したかをログで確かめてください。

結論:一度に変えるのは一つの条件

ルールを複数まとめて変更すると、どの行が結果に影響したのか分かりにくくなります。まず対象を一つに絞り、ルールの位置とログ上の一致結果を確認してから次の変更に進みましょう。

3. リモートRULE-SETを指定するときの確認点

RULE-SETは、ルールの一覧をリモートから参照するための指定です。基本的な考え方は、ルールセットのURLと、それに一致した通信へ適用するポリシーを組み合わせることです。URLは説明用のプレースホルダーで、実際には使えません。利用するファイルがRULE-SET形式に対応しているか、URLの配布元が示す書式と更新条件を確認してください。

[Rule]
RULE-SET,https://rules.example.invalid/example.list,PROXY
DOMAIN-SUFFIX,example.com,DIRECT
FINAL,PROXY

リモートルールの記述位置にも順序が影響します。この例ではRULE-SETがDOMAIN-SUFFIXより先なので、両方に一致する宛先があれば先に評価されたRULE-SETのポリシーが適用されます。例外を優先したい場合は、狭い範囲のルールを前に置くか、ルールセット内に例外が含まれているかを確認します。読み込める形式、更新のタイミング、エラー時の扱いはファイルやアプリの仕様に依存するため、特定の結果を前提にしないでください。

URLが正しく見えても、ネットワークから取得できるとは限りません。URLの入力ミス、HTTPS証明書の問題、提供元側の応答、接続経路などを個別に確認します。リモートルールを取得できないときは、同時に多数のルールを編集せず、まずエラー表示とログを記録してください。取得元の信頼性も重要です。内容が更新される設定であるため、誰が管理するルールか、どの範囲の通信を対象とするかを把握してから読み込みましょう。

4. Configを複製して編集し、ログで動作を確認する

いきなり普段使っている設定を置き換えず、編集可能なファイルの複製を用意してから試します。メニューの表示位置はアプリのバージョンによって異なる場合があります。以下は英語表示の画面名を使った確認の流れです。変更前のファイル名、編集した行、テストした宛先を控えておくと、問題が起きたときに元へ戻しやすくなります。

  1. 元ファイルを保管

    Configを開き、現在の設定を確認します。編集対象をコピーまたは複製できる場合は、元のファイルを残して別名のテスト用Configを用意します。リモート管理の設定で編集が保持されるか分からないときは、先にその動作を確かめてください。

  2. 対象行だけ編集

    Config → 対象のファイル → Editの順に開き、必要なセクション内だけを変更します。ルールのカンマ、ポリシー名、ドメインの綴りを見直し、見本のexample.comや.invalidを実際の接続設定として残さないでください。

  3. 保存して選択

    変更を保存したらConfigの一覧へ戻り、テスト用ファイルが選択されていることを確認します。Homeへ移動してGlobal RoutingがConfigになっていることも確かめます。ProxyやDirectを選んだままでは、Configのルールを使ったテストにならない場合があります。

  4. 通信を一つ試す

    Homeで接続状態を確認し、テスト対象のアプリやサイトから一つだけ通信します。接続が始まらない場合は、Configの選択状態と接続状態を先に確認し、ルールの動作確認と接続先の問題を混同しないようにします。

  5. 一致した行を確認

    Homeの通信ログまたは接続履歴を開き、対象のドメイン、適用されたルール、ポリシーを確認します。ログ画面の名称や配置はバージョンによって異なる場合があります。該当行が見つからない場合は、再現した時刻と対象アプリを記録し、ドメイン名が想定どおりかを見直してください。

ログに通信が表示されることは、ルールが評価されたかを確かめる手掛かりになりますが、接続先サービスが正常に応答したことまで保証しません。ルールが一致しているのに接続できない場合は、ポリシーの選択、サーバーの状態、名前解決、ネットワーク条件を分けて調べます。確認が終わったら、テスト用Configを選択したままにするのか、元のConfigへ戻すのかを明確にしてください。

5. MITMの証明書とよくある質問

MITMは、対象となる通信の内容を確認・処理する必要がある場合に関係する機能です。設定ファイルに[MITM]の項目があるだけで、HTTPS通信を安全に復号できるわけではありません。機能の設定に加えて、対象端末で信頼される証明書が関係する場合があります。必要性を理解できないときは有効にせず、まず通常のルール振り分けだけで要件を満たせるか検討してください。

証明書は通信内容を扱える権限に関わるため、発行元と用途を確認してから扱います。端末への証明書追加や信頼設定は、Shadowrocketの画面とiOSの案内に従い、知らない証明書や出所を確認できない証明書を信頼しないでください。秘密鍵や証明書ファイルを公開したり、第三者に送ったりしないことも重要です。必要なドメインだけに対象を限定し、不要になったら機能を無効化して、端末に残る証明書の扱いも確認してください。

保存したのにConfigとして切り替わりません

Configの一覧に戻り、編集したファイルが表示されるか、選択状態になっているかを確認します。Home → Global RoutingでConfigが選ばれていることも見直してください。読み込みエラーがあれば、最後に追加した行を一時的に戻して原因を切り分けます。

ルールを書いたのに想定と違うポリシーになります

Homeの通信ログまたは接続履歴で、対象の通信に一致したルールを調べます。より広いルールが上にないか、ルールセットが先に一致していないか、指定したポリシー名が定義済みかを確認してください。

RULE-SETのURLを追加したのに反映されません

URLの綴りと取得元の説明書を照合し、ネットワーク接続とエラー表示を確認します。URLの内容を公開の検査サイトへ貼り付けず、必要なら提供元の案内で対応形式と更新方法を確認してください。

MITMの証明書は常に信頼してよいですか

いいえ。証明書の出所と必要な用途を確認し、理解した対象だけに使います。利用を終えたらMITMを無効にし、不要な証明書が端末に残っていないか設定を確認してください。

構文の変更は、一行ずつ進めると原因を特定しやすくなります。元ファイルを残し、Configを選択し、Global RoutingをConfigにしてから、ログで一致したルールを確認するのが基本の流れです。アプリの入手先はApp Storeです。製品情報とシステム要件はApp Storeの表示をご確認ください。

Shadowrocket正規版の入手方法