Shadowrocket ルール・設定リファレンス

01 / CONFIG STRUCTURE

設定ファイルの構造：サーバー情報と動作ルールを区別する

Shadowrocketでは、サーバー情報は「どのサーバーを経由して接続するか」を決め、設定ファイルは「各リクエストをどのように処理するか」を定めます。両者は関連しますが、同じものではありません。手持ちのサブスクリプションは通常、サーバー項目の読み込みや更新に使用します。通信を振り分けるルールを含む設定ファイルは、Configで内容を確認して有効にする必要があります。Homeにサーバーが表示されていても、カスタムルールが有効とは限りません。設定を読む前に、現在選択しているサーバー、有効な設定ファイル、Global Routingの状態を記録してください。以降の確認条件をそろえられます。

4つの設定セクションの役割

一般的なテキスト形式の設定ファイルでは、角括弧でセクション名を示します。[General]にはDNSやシステム通信に関する設定など、全般的なパラメータを記述します。[Rule]にはリクエストの照合条件と対応するポリシーを記述します。[Host]には指定したドメインのアドレス対応を記述します。[URL Rewrite]では、式に一致するURLを処理します。セクション名は単なる見出しではありません。行が属するセクションによって解釈が変わります。ドメインルールをGeneralに貼り付けても、行の構文が正しくてもRuleのルールとしては機能しません。

[General]
bypass-system = true
dns-server = system

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
FINAL,PROXY

[Host]
localhost = 127.0.0.1

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

この例は設定ファイルの構造を確認するためのもので、すべての環境に適用できる汎用設定ではありません。Generalの2行は、真偽値パラメータとDNSの値をそれぞれ示します。Ruleの3行はドメイン、アドレス範囲、最終ポリシーを示します。Hostのlocalhostはローカルループバック名の例で、最後の行はHTTPからHTTPSへのリダイレクトを示します。例のドメインは実際のサービスを表すものではありません。コピーする前に目的を明確にしてください。特にFINALの値は、他のルールに一致しなかったすべてのリクエストに影響します。例がPROXYだからといって、そのまま使わないでください。

句読点、段落、読みやすさ

ルールのフィールドは半角カンマ、パラメータの代入には半角イコール、セクション名には半角の角括弧を使います。日本語入力で全角のカンマ、引用符、空白が入力されると、意図どおりに解析されないことがあります。各ルールは1行ずつ記述してください。ページ上の折り返しを新しいルールと間違えないようにしましょう。読むときは「キーワード、照合値、ポリシー、任意のパラメータ」の順に分けて確認できますが、すべてのキーワードでフィールド数が同じとは限りません。FINALには照合値がないため、機械的に3列にしないでください。

設定セクションの並びを、固定された処理手順と考えてはいけません。ファイル内でGeneralがRuleより上にあっても、各リクエストがすべての全般パラメータを処理してから他のセクションを順に実行するわけではありません。HostやURL Rewriteも、Ruleの後に続くルールではありません。上から順に読む必要があるのは、Rule内の照合順序です。設定ファイルの構造とルールの優先順位を分けて考えれば、設定セクション全体を移動して「ルールの優先順位を上げる」といった効果のない変更を避けられます。

Configで有効な設定を確認する

Configを開いたら、まず現在選択されているファイルを確認し、読みたいファイルや編集対象を開きます。コピーを編集する場合は、用途が分かる名前を付け、元のファイルを残してください。編集内容の保存とファイルの有効化は別々に確認する必要があります。保存しただけでは、そのファイルが現在の接続に使われているとは限りません。ファイル一覧に戻って選択状態を確認し、Global Routingも確認します。画面上の項目の位置はアプリの変更に伴って変わることがあります。固定の画面位置ではなく、ファイル名、選択状態、実際のリクエスト結果を判断材料にしてください。

アプリの正規性を確認できない場合は、まず正規アプリの確認方法を参考に、デベロッパ名のShadow Launch Technology Limited、公式アイコン、アプリID 932747118を確認してください。ShadowrocketはAppleプラットフォーム向けの有料クライアントです。入手先はApp Storeのみです。システム要件はApp Storeのページに記載された内容をご確認ください。基本環境を確認してから、このページの部分的な設定例を目的に合わせて編集するほうが、サーバーと設定を同時に変更するより原因を特定しやすくなります。

03 / DOMAIN MATCHING

ドメインルール：完全一致、サフィックス、キーワード

安定したドメイン名で振り分け先を指定できる場合は、まずドメインルールを検討してください。アドレスを直接列挙するより「特定のサイトやサービス」という意図を反映しやすく、サーバーアドレスの変更にも左右されにくくなります。ただし、ドメイン名は完全なURLではありません。DOMAINの照合値にプロトコル、パス、クエリパラメータ、ポートを貼り付けないでください。ブラウザーのアドレス欄にある完全なURLからホスト名を取り出し、その名前だけを対象にするのか、配下のすべてのサブドメインも含めるのかを判断します。

DOMAIN：指定した名前だけに一致

[Rule]
DOMAIN,api.example.com,PROXY
DOMAIN,account.example.com,DIRECT
FINAL,PROXY

1行目はapi.example.com、2行目はaccount.example.comを対象にしています。DOMAINは「この語句を含む」という条件ではなく、他のサブドメインも自動的に対象にしません。実際のリクエストがimages.api.example.comの場合、同じサービスに属しているように見えても、1行目に一致するとは限りません。DOMAINによる完全一致は、少数の明確な例外に適しています。たとえば、大半のリクエストには最終ポリシーを適用し、特定のホスト名だけDIRECTにするケースです。使用前に実際のリクエストから完全な名前を確認し、ページに表示されたブランド名をホスト名と取り違えないようにしてください。

DOMAIN-SUFFIX：ドメイン境界に沿ってサフィックスに一致

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

DOMAIN-SUFFIX,example.comはexample.comとそのサブドメイン（www.example.comなど）に一致します。ドメインの境界に沿って判定するため、任意の文字列の末尾を比較する条件ではありません。したがって、notexample.comは通常このサフィックスの対象にはなりません。上の例ではprivate.example.comへの完全一致の例外を、広いサフィックスより前に置いています。この2行を逆にすると、サフィックスが先に一致して例外の完全一致ルールが期待どおりに機能しなくなります。ルールの行数より、どの範囲が他のルールを覆うかに注目してください。

サフィックスには通常、アスタリスクを付ける必要はありません。*.example.comをDOMAIN-SUFFIXの標準値として使うと、ワイルドカード式とサフィックス照合という異なる仕組みを混同することになります。また、画像用ドメインを対象にするために、短い汎用サフィックスまで範囲を広げないでください。範囲が広いほど、関係のないサービスまで含める可能性が高くなります。まず実際のサービスで使われている登録ドメインを基準にし、すべてのリクエストが同じサフィックスを使うと決めつけず、リクエスト記録に基づいて個別のドメインを追加してください。

DOMAIN-KEYWORD：範囲が広く、誤一致もしやすい

[Rule]
DOMAIN-KEYWORD,example,PROXY
FINAL,DIRECT

DOMAIN-KEYWORDはドメイン名に含まれるキーワードに一致します。ここでのexampleは完全なドメインではなく、DOMAIN-SUFFIXのようなドメイン境界の条件もありません。そのため、関係のない名前に一致する可能性があります。広い条件が必要で、影響範囲を確認できる場合に限って使用してください。対象がexample.comとそのサブドメインだけなら、通常はサフィックスルールのほうが意図に合います。ルールが短いからといって正確とは限らず、キーワードが少なくても管理しやすくなるとは限りません。

ページのドメインがすべてのリクエストのドメインとは限らない

1つのページから、ログイン、画像、API、静的リソース用のドメインにそれぞれリクエストを送信する場合があります。トップページは開いてもログインできない場合、同じルールの動作が不安定なのではなく、別のリクエストに異なるポリシーが適用されている可能性があります。操作中にリクエスト記録を確認し、実際に失敗した名前を特定してからルールを追加してください。サードパーティのリソース用ドメインは複数のサービスで共有されることがあります。あるページに表示されたからといって、そのドメインへのすべてのアクセスに同じポリシーを適用するべきだとは限りません。

リクエスト記録にIPアドレスしかなく、照合に使えるドメイン情報がない場合、ドメインルールは適切な確認箇所ではない可能性があります。その場合は、アドレスルール、DNS、リクエストの発生方法を確認してください。似たドメインルールを増やすだけでは解決しません。国際化ドメイン名や特殊な形式の名前についても、実際の記録に表示された形式を基準にしてください。変更後は、対象の名前と、似ているものの一致してはいけない名前をテストします。必要な範囲をカバーし、境界外の対象まで含めていないことを確認できます。

05 / POLICY

Global RoutingとPROXY、DIRECT、REJECT

Global RoutingのConfig、Proxy、Directはモードの選択肢です。一方、Rule内のPROXY、DIRECT、REJECTはルールの処理ポリシーです。似た語句ですが、階層が異なります。ルールが有効かどうかを確認するときは、まずGlobal Routingを確認してください。Config以外のモードでは、Ruleを変更しても接続結果が変わるとは限りません。ProxyやDirectに一時的に切り替えてテストした場合は、カスタムルールを検証する前に元のモードへ戻してください。

PROXY：プロキシ経由を選択するが、接続先への到達を保証するものではない

ルールポリシーのPROXYは、現在選択されているプロキシ経由で接続する意図を示します。サーバーアドレスそのものではなく、サーバーに必要な認証情報やプロトコルパラメータを補うものでもありません。手持ちのサーバー情報で、アドレス、ポート、認証情報、その他の設定に誤りがあれば、ルールが正しくPROXYに一致しても接続に失敗することがあります。そこで、リクエストが意図したポリシーを選んだことと、そのポリシーで使う接続経路が利用可能であることを別々に確認してください。この2つをまとめて「ルールが効かない」と判断すると、調査の方向を誤ることがあります。

Homeで選択しているサーバーも記録してください。同じ設定ファイルを使っていても、サーバーを変えると結果が異なることがあります。これはRuleの構文が変わったことを意味しません。カスタムポリシーやグループを使う場合は、その名前と実際の参照先を確認し、定義されていない名前を例に書かないでください。この記事では、追加のグループ定義に依存しないよう、3つの組み込みポリシーを使っています。Trojanのパラメータを詳しく確認する場合は、Trojanパラメータの解説をご覧ください。プロトコルのパラメータを直すためにドメインルールを変更しないでください。

DIRECT：現在のネットワークから直接接続する

DIRECTはShadowrocketの停止や、OSのVPN設定の無効化を意味しません。現在の処理で接続先への直接接続を選択します。接続先に到達できるかどうかは、現在のネットワーク、名前解決の結果、サービス自体の状態に左右されます。LAN内の接続先にDIRECTを使うのは意図に合うことが多いものの、デバイスが該当するネットワークに接続されている必要があります。デバイスが同じネットワーク上にない場合や、LAN内のサービスが該当アドレスで待ち受けていない場合、DIRECTルールで元々存在しない接続性を作ることはできません。

REJECT：一致したリクエストを明示的に拒否する

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

1行目は指定した名前への接続を拒否し、2行目は残りのサフィックスに一致するリクエストにPROXYを適用します。最後に、それ以外の通信を処理します。REJECTは接続させたくない対象を明確に指定するためのもので、決めかねている最終ポリシーの代わりにはなりません。拒否する名前がログイン、認証、コンテンツ読み込みにも使われていると、ページの一部が正常に動作しなくなることがあります。変更前にその名前の用途を確認し、変更後はトップページが表示されるかだけでなく、重要な操作も確認してください。

拒否ポリシーを設定しても、ページ上の特定コンテンツだけを確実に消せるとは限りません。ウェブページの表示要素とネットワークリクエストは1対1で対応せず、1つのドメインが複数の機能を担うこともあります。特定のリソースを遮断するために範囲が広すぎるサフィックスやキーワードのルールを使うと、正常なリクエストにも影響しやすくなります。対象を限定して始め、リクエスト記録で条件を確認してから範囲を広げるか検討してください。新たな問題が起きたら、例外を重ねて元の誤りを分かりにくくする前に、追加した拒否ルールを元に戻してください。

FINAL：他のルールに一致しないリクエストの行き先を指定する

FINALは照合値を持たない最終ルールで、一般的な書式はFINAL,PROXYまたはFINAL,DIRECTです。グローバルモードとは別の概念で、Configのルールとして、前のルールに一致しなかったリクエストだけを処理します。どちらのポリシーを選ぶかは、想定するデフォルトの動作によって異なります。どのユーザーにも正しい値があるわけではありません。PROXYを使う場合は、手元のサーバーが利用可能であることを確認してください。DIRECTを使う場合は、ルールに記載されていない接続先が直接接続されることを理解してください。

3つのモードで現象が異なる場合は、すぐに結論を出さず、違いを記録してください。Directで接続できてProxyで失敗するなら、サーバーへの経路を調べる必要があるかもしれません。Proxyでは接続できてConfigで失敗するなら、一致したポリシーや他の設定を確認します。どのモードでも失敗する場合は、接続先や現在のネットワークに問題がある可能性もあります。具体的な判断には接続記録も必要です。モード切り替えの結果だけで他の原因をすべて排除することはできません。

07 / HOST AND URL REWRITE

Host と URL Rewrite：アドレスの割り当てとURLの書き換え

Hostは名前とアドレスの対応を扱い、URL Rewriteは式に一致するURLを処理します。どちらもPROXYやDIRECTを選択する機能ではありません。アクセスに失敗したときは、まず何を変更したいのかを明確にしてください。同じドメインを別のアドレスに解決したいのか、古いURLから新しいURLへ転送したいのか、それとも別の接続経路を使いたいのかを確認します。最初の2つはこの章に関係する可能性がありますが、3つ目はRuleで設定します。通信を振り分けるためにHostを変更すると、アドレスや証明書の問題を招くことがあります。

Hostの最小例と適用範囲

[Host]
localhost = 127.0.0.1

左側が名前、右側がアドレスです。localhostと127.0.0.1はローカルループバックの例です。ここでいう「ローカル」は接続を開始するデバイス自身を指し、ルーターや選択中のプロキシサーバーではありません。リモートサーバーにアクセスする業務で、このアドレスを使わないでください。対応を記述してもアドレス情報が提供されるだけで、そのアドレス上で必要なサービスが自動的に起動するわけではありません。対象ポートで待ち受けていない、ネットワークに到達できない、サービス設定が合っていない場合は、名前とアドレスが対応していても接続に失敗することがあります。

実際のドメインにアドレスを固定する前に、アドレスの管理者、安定性、その方法でアクセスしてよいかを確認してください。多くのサービスは地域や負荷に応じてアドレスを動的に返すため、結果の1つを固定すると元の振り分けが機能しなくなることがあります。対応を記述すると通常のDNSの変化が見えなくなり、後で調査するときに、名前解決サービスが常に古いアドレスを返していると誤解する場合もあります。Hostは明確で管理可能な対応関係に適しており、一時的に得られた解決結果を期限なく保存する用途には向きません。

HostはTLS証明書の検証を代替しない

HTTPS接続では、リクエストのドメイン名と証明書などの条件も関係します。ドメインを特定のアドレスに割り当てても、そのアドレスがドメイン名に合ったサービスを提供するとは限らず、証明書名の不一致が自動的に解決するわけでもありません。TLSエラーが発生した場合は、接続先の名前とアドレス、サーバー側の設定を確認してください。検証を無効にすることを通常の解決方法にしないでください。テスト後に対応が不要になった場合は削除し、新たに接続するときに実際のアドレスを確認して、古い設定が他の調査に影響しないようにしましょう。

URL Rewriteを構成する3つの要素

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

この行には、照合式、置換先、リダイレクトのステータスコードがこの順で含まれています。先頭の^は文字列の先頭から照合することを示します。exampleの後ろのバックスラッシュは、ピリオドを通常の文字として扱うためのものです。省略すると、正規表現のピリオドは通常、任意の1文字を表し、照合範囲が広がります。末尾のスラッシュも条件の一部です。ここでは一時的なリダイレクトとして302を使っていますが、これですべてのHTTPアクセスが修復されるわけではありません。また、元のURLのパスやクエリパラメータが自動的に保持されるとも限りません。

例の置換先は固定URLで、照合したURLの残りの部分を明示的に保持していません。実際の要件にパスやクエリパラメータが含まれる場合は、キャプチャ範囲と置換方法を先に設計し、少数の管理可能な対象でテストしてください。元のドメインが同じだからといって、ログインのコールバック、APIリクエスト、通常のページをすべてサイトのトップページにリダイレクトしないでください。広すぎる書き換えはリクエストの意味を損ない、ページでリダイレクトループが発生することもあります。書き換え後のURLが別の書き換え条件にも一致する場合は、その相互作用も確認してください。

HTTPSで確認できる情報の制約

完全なHTTPSの通信経路とリクエスト内容は通常、暗号化された接続の中にあります。URL Rewriteを追加するだけで、すべての暗号化通信に適用できるとは限りません。この章ではHTTPS復号を求めず、証明書のインストールをルールによる通信振り分けの前提にもしていません。目的がドメインに基づく接続先の振り分けだけなら、ドメインルールを使い、完全なURLを見るための追加設定は不要です。この機能が適用できるかどうかは、実際に確認できるリクエスト情報と、アプリが対応している処理条件に基づいて判断してください。

どちらの設定セクションも、テストには取り消しの手順を含めてください。元の値を保存してから、対応付けまたは書き換えを1件だけ追加します。目的の動作を確認した後、変更を取り消して再テストし、現象が変更に応じて安定して変わるか確認します。取り消し後も問題が続く場合は、項目を追加し続けるのではなく、キャッシュ、既存の接続、接続先サービスの変化を検討してください。設定ファイル全体で4つのセクションの関係を確認する場合は、設定ファイルの構造ガイドをご覧ください。この章では、影響範囲を説明と検証が可能な範囲にとどめることを重視します。

08 / CHANGE AND VERIFY

設定の変更とトラブルの切り分け：再現可能な検証手順を作る

設定が正しいことと、アクセスに成功することは、関連はありますが別の結論です。正しいルールが一時的に利用できない接続経路を選ぶこともあります。アクセスに一度成功しても、キャッシュや既存接続によるもので、新しいルールが判定に使われたとは限りません。信頼できる検証には、テスト条件を固定し、元の設定を保存し、一度に1つの要素だけを変更し、新しいリクエストの結果を記録することが必要です。この章では、ここまでの各ルールを元に戻せる手順に整理しています。特定のドメインだけに問題がある場合、変更後も変化がない場合、設定の更新後に動作が変わった場合などに役立ちます。

手順1：設定を変更する前に、現在の状態を記録する

現在のネットワークの種類、Global Routing、有効なファイル、選択中のサーバーを記録し、どの操作で問題が発生するかを具体的に説明してください。「使えない」とだけ記録せず、トップページが開かない、画像が表示されない、ログインできない、APIリクエストが失敗する、LAN内のデバイスにアクセスできない、などに分けてください。繰り返し実行できる操作を1つ決め、できるだけ同じ対象でテストします。問題がもともと断続的に起きている場合は、変更前に何度か状態を確認してください。そうしないと、変更後の偶然の成功を修正の効果と誤認しやすくなります。

手順2：コピーを保存し、変更範囲を絞る

Configで元のファイルを残し、コピーを編集します。関連するセクションに同じ種類のルールがないか、条件の重複や途中のFINALがないかを確認してください。特定のドメインだけに問題がある場合は、広いキーワードルールをすぐに追加するのではなく、範囲の狭いDOMAIN例外を1つ追加してみます。DNSを調整する場合はRuleの順序を変えず、Hostを調整する場合はサーバーを変更しないでください。そうすれば、結果の変化と明確な1つの変更を結び付けられます。

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

この部分例は、完全一致の例外を検証するためのものです。api.example.comにはPROXY、サフィックスに一致するその他の名前にはDIRECT、それ以外のリクエストには最終ポリシーを適用します。各行の意味を確認してから、自分の対象と期待するポリシーを対応付けてください。例のドメインを使って実際の接続をテストしたり、すでにあるFINALの後ろにこの部分例全体を追加したりしないでください。既存ファイルの構造が複雑な場合は、まずコピー上で最小の再現例を作ってロジックを確認してから、長期運用する設定に統合してください。

手順3：保存して有効化し、新しいリクエストを送る

編集後に保存結果を確認し、Configに戻って有効な設定を確認してから、Global RoutingをConfigに設定します。対象の操作をもう一度行い、必要に応じて一度切断して再接続し、既存接続の再利用が観察に与える影響を減らしてください。再接続しても、アプリ内のキャッシュがすべて消えるわけではありません。リクエスト記録もあわせて確認し、新しいネットワークリクエストが発生しているか判断してください。テスト中に「ページの表示が変わらない」ことを、そのまま「ルールが変わっていない」とみなさないでください。ページが関連するリソースを再リクエストしていない可能性があります。

手順4：まずルールの一致を確認し、次に接続を調べる

リクエストに適用されたポリシーが想定と異なる場合は、Ruleの先頭に戻って、他のルールとの包含関係、実際のホスト名、アドレスファミリー、Global Routingを確認してください。ポリシーが想定どおりなのに失敗する場合は、選択中のサーバー、プロトコル情報、DNS、接続先の応答を確認します。特定のネットワークだけで失敗する場合はネットワーク条件を比較し、特定のサーバーだけで失敗する場合はサーバーへの接続結果を比較してください。ポリシーが正しいのに重複ルールを追加し続けないでください。重複項目では認証エラー、到達できないアドレス、接続先サービスの異常は直せません。

手順5：隣接する対象を再テストし、復元方法を記録する

対象へのアクセスが回復した後も、同じサフィックス内の他のリクエスト、その範囲に属さない対象、影響を受ける可能性のあるLANアクセスを確認してください。最終ポリシーを変更した場合は、ルールに一致しないすべてのリクエストの接続先が変わる可能性があるため、より広い範囲で再テストします。どの行をなぜ変更し、どう検証し、どう元に戻すかを記録してください。機密性の高いリクエスト内容全体を保存する必要はありません。長期運用する設定の価値は、変更した当日に動作することだけでなく、後から見ても理解できることにあります。

原因を特定できない場合は、スイッチをオンにしても接続できない場合の確認手順を続けて確認するか、よくある質問で該当する項目を探してください。読み込みと接続の手順を改めて確認する場合は、クイックスタートガイドに戻ってください。購入やデバイスの互換性については、App Storeの正規アプリ情報をご覧ください。システム要件とユニバーサル購入の対象かどうかは、App Storeのページに記載された内容をご確認ください。ルールの問題を解決するために、クライアントを再購入する必要はありません。