公式マニュアル · 設定リファレンス

Shadowrocket ルール・設定ガイド

設定項目から最終ポリシーまで、リクエストの処理順に沿ってルールを確認します。

ShadowrocketはApp Storeのみで配信されるAppleプラットフォーム向けの有料クライアントで、主にiPhoneとiPadで利用できます。初めて使う場合は、まずクイックスタートガイドに沿って、手元にあるサブスクリプションを追加し、接続を確認してください。このページでは設定の構成、ルールの適用範囲、トラブルの切り分け方法を解説します。初回接続の手順に代わるものではありません。

以下の例は、利用者が自身のサブスクリプションまたはサーバー情報を持っていることを前提としています。アプリの買い切り購入と接続サービスの契約は別のものです。正規版の入手方法や購入の復元については、App Storeでのダウンロードと確認方法をご覧ください。システム要件と互換性はApp Storeページの記載をご確認ください。

01 設定ファイルの構成と変更範囲

Shadowrocketでは、サーバー情報、サブスクリプション、設定ファイルはそれぞれ役割が異なります。サーバー情報には接続先とプロトコルのパラメーターが記載され、サブスクリプションは利用者が持つ接続情報をまとめて読み込み、更新するために使います。設定ファイルは共通設定、照合条件、処理ポリシーをまとめるものです。Homeにサーバーが表示されていても、現在のConfigに対象リクエスト向けのルールが含まれているとは限りません。逆に、ルールが整った設定ファイルでも、サーバーアドレス、パスワード、プロトコルのパラメーターが欠けていれば補えません。問題を調べる前に、この3つを別々に確認し、原因をすべてルールのせいにしないようにしましょう。

まずセクション名を確認してから各行を読む

一般的な設定ファイルは角括弧で囲まれたセクション名で区切られます。[General]には共通動作の設定、[Rule]には上から順に評価されるルール、[Host]には静的なドメインマッピング、[URL Rewrite]にはURLの照合と書き換え項目を記述します。セクション名によって後続行の解釈が変わります。同じ行でも誤ったセクションに置くと、意図どおりに処理されない場合があります。読むときは、直近のセクション名を確認してからキーと値、またはルールの各項目を見てください。行にドメイン名があるだけで、振り分けルールだと判断しないようにしましょう。

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

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

[Host]
localhost = 127.0.0.1

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

この設定例は、セクション間の関係を示すものです。共通設定ではシステムDNSを使い、例示したドメインにはPROXYを適用し、一部のアドレスはGEOIPで判定、その他のリクエストはFINALに渡します。HostとURL Rewriteはそれぞれ別の処理を担います。この組み合わせがすべての利用者に適した推奨設定というわけではありません。特にDNS、IPv6、最終ポリシーは、利用中のネットワークと手元の接続サービスに合わせて確認が必要です。変更時は必要な既存項目を残し、内容を理解していない設定を例に合わせて削除しないでください。

Configで実際に使用中のファイルを確認する

Configを開いたら、まず「ファイルがある」ことと「ファイルが使用中」であることを区別しましょう。読み込みが完了しても、ファイル一覧に追加されたというだけで、現在の接続に選択されたとは限りません。選択状態を確認してから、該当ファイルの内容を開いてください。試す場合は、まずアプリで利用できる複製または書き出し機能を使ってコピーを保存し、用途が分かる名前を付けます。保存後に使用中の項目をもう一度確認しましょう。試験用ファイルを編集した一方で、実際の接続には古い別の設定が使われていると、保存が反映されなかったと誤解することがあります。

ファイルの取得元によって、変更が保持されるかどうかも変わります。リモートURLから取得した設定の場合、再更新時にローカルの編集が上書きされるか事前に確認してください。サブスクリプションのサーバー更新と設定ファイルの更新は別の操作です。サーバー一覧を更新してもRuleが変わるとは限らず、リモート設定を再取得してもサブスクリプションが更新されるとは限りません。長期間残したいカスタムルールは、追加した項目、挿入位置、変更理由を記録しましょう。リモートの内容が変わったら、ファイル名が同じだから内容も同じと決めつけず、差分を確認してから再統合します。

変更は一度に一つの層に絞る

「接続情報が正しい」「設定ファイルが選択されている」「ルールの順序が正しい」の順に基準を確認するのがおすすめです。最初の調整ではドメインルールを1つだけ変更し、General、Host、書き換えの各セクションはそのままにして、新しいリクエストでテストします。サーバーの変更、DNSの切り替え、最終ポリシーの変更、書き換えの有効化を同時に行うと、アクセスが復旧してもどの変更が有効だったのか分かりません。失敗した場合も、確実に戻せる範囲がなくなります。変更目的は「例示したドメインとそのサブドメインにPROXYを使う」のように具体的に書くと、「すべてのルールを最適化する」より検証しやすくなります。

ファイルを戻すときも、順序立てて確認しましょう。元の設定に戻した後、現在のモードと選択中のサーバーを確認します。必要であれば接続を切って再接続し、新しいリクエストを送ってください。既存の接続、キャッシュされたページ、バックグラウンドでの再試行は、変更前の挙動を引き継ぐことがあります。設定が復元されたかどうかを判断する唯一の根拠にしないでください。初回の読み込みがまだ済んでいない場合は、基本の手順に戻り、まず接続を確認してから次の章へ進みましょう。接続先が利用できない状態で、関係のないルールを何度も変更するのを避けられます。

02 General、DNS、アドレス解決

[General]は共通動作を設定するセクションですが、「速度設定の一覧」ではありません。DNS、IPv6、システムのバイパスなどの設定は、ルール判定の前後でリクエストから取得できる情報に影響し、ネットワークとの互換性も変えることがあります。既存の設定を読むときは、各キーをアプリ内の該当する説明と照らし合わせてください。他の利用者の設定値を固定の正解と見なさないようにしましょう。特にWi-FiとCellularを切り替えると、ネットワークが提供するリゾルバー、アドレスファミリー、到達経路が変わることがあります。同じ設定で挙動が違っても、必ずしもルールに誤りがあるとは限りません。

DNSは名前解決を担い、最終ポリシーとは別のもの

ドメインにアクセスするときは、通常、接続先のアドレスを取得する必要があります。DNSはドメインに対応するアドレスを返し、Ruleは一致したリクエストに適用するポリシーを決めます。両者には関係がありますが、互いの代わりにはなりません。ドメインの名前解決に成功しても、PROXY経由の接続が失敗する場合があります。IPルールの挙動がおかしい場合も、想定と実際の解決結果が異なる可能性があります。問題を調べるときは、まずアクセス先のドメインを記録し、名前解決の成否、返されたアドレス、最終的に一致したルールを確認しましょう。「開けない」からといって、すぐにDNSの問題と決めつけないでください。

[General]
dns-server = system
ipv6 = false

dns-server = systemは、この設定でシステムDNSを使うことを示します。特定のパブリックDNSアドレスを手動で指定するものではありません。現在のネットワークの挙動を把握するための出発点にはなりますが、すべてのネットワークに適するとは限りません。内部ドメインがあるネットワークでリゾルバーを変更すると、正しい応答を取得できなくなることがあります。システムによる名前解決自体に問題がある場合は、先にネットワークを確認してください。DNSを変更する前に元の値を記録し、変更後は新たな名前解決と接続の結果で検証しましょう。ブラウザーにキャッシュされたページを更新するだけでは不十分です。

IPv6の設定は到達性を見て判断する

ipv6 = falseは、この例では関連するIPv6の動作を無効にします。すべての環境に当てはまる速度向上の設定ではありません。IPv6に対応するネットワークやサービスでは、IPv4とは接続条件が異なることがあります。無効にして挙動が変わっても、アドレスファミリーや経路を調べる手がかりになるだけで、どちらかが常に速いと結論づけることはできません。IPv6を有効にする場合は、接続先がIPv6アドレスを提供しているか、利用するサーバーとプロトコルが想定どおりに処理するか、Ruleに該当するIP-CIDR6の項目があるかも確認してください。

IPルールで問題を調べるときは、今回のリクエストで実際に使われたアドレスを確認する必要があります。IPv4の範囲だけを確認していても、リクエストがIPv6を選んでいれば、結論の根拠が不足します。また、1回のテストで得たアドレスを長期的なHostマッピングとして固定しないでください。同じドメインでもネットワーク、地域、サービスの振り分けによって異なるアドレスが返ることがあり、固定すると通常の可用性調整を妨げるおそれがあります。まずドメインルールで経路を選択し、静的なマッピングが明確に必要な場合に限って、Hostの適用範囲と保守コストを検討しましょう。

システムのバイパスとルールログの範囲を理解する

bypass-system = trueはシステムトラフィックのバイパス動作に関係します。適用範囲はアプリ内の最新の説明に沿って確認してください。すべてのアプリのリクエストが同じRuleを通るという意味でも、有効にすれば各アプリの挙動が一致するという意味でもありません。期待したログが表示されない場合は、ルールに加えて、既存の接続が再利用されていないか、システムコンポーネントがリクエストを開始していないか、別のバイパス設定が適用されていないかも確認しましょう。まず対象のリクエストが現在の接続処理に入っていることを確かめてから、Ruleの評価順序を調べます。

再現性のあるテスト手順は次のとおりです。まずシステムDNSを基準として残し、ドメインを1つ選んで名前解決とアクセスの結果を記録します。次に、名前解決に関する設定を1つだけ変更し、再接続して新しいリクエストを送ります。最後に、アドレス、ヒットしたルール、エラーが発生した段階を比較します。DNSを変えて特定のネットワークだけ復旧した場合は、新しい設定をすぐに全端末に適用するのではなく、そのネットワークが提供する名前解決サービスを調べてください。設定の目標は挙動を説明できることです。1回ページが開いたというだけでは、すべてのリクエストが想定どおりだとは証明できません。

自宅のWi-Fiでは正常なのにCellularへ切り替えると問題が起きる場合は、まず各テスト条件を分けて記録します。On Demandの条件によって接続状態が変わっていないかを確認し、Global Routing、現在のサーバー、名前解決の結果も照合してください。関連する条件はOn Demandによるオンデマンド接続の説明も参照してください。ネットワークの変化と名前解決の変化を分けて調べるほうが、DNSの値を次々に変更するより安定した原因を見つけやすくなります。

03 DOMAIN系ルールとドメインの範囲

ドメインルールは「特定の名前、または名前の集合にどのポリシーを適用するか」を指定するのに適しています。1回の名前解決結果を固定IPとして記述するより、サービス名に沿った指定になり、保守もしやすくなります。よく使われる種類はDOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORDです。違いは優先度ではなく、照合範囲です。Shadowrocketはリストの上から順に確認するため、範囲の狭いルールを広いルールより後に置くと、実行されないことがあります。まず対象範囲を言葉で整理してから種類を選びましょう。先にルールをコピーして、どこまで一致するかを後で推測するのは避けてください。

DOMAIN：完全一致のドメイン名を指定

DOMAIN,api.example.com,PROXYは、指定した完全一致のドメイン名に適用されます。APIのサブドメインと同じサイトの他のサブドメインを分けて扱う場合に便利です。値にURLは指定できません。https://、パス、クエリパラメーター、ポート番号は含めないでください。特定のページパスを処理したい場合、DOMAINだけでは表現できません。同じドメイン内の異なるパスも、ドメイン条件としては同じ扱いになります。ブラウザーのアドレス欄にあるURL全体をドメイン欄に貼り付けるのは、よくある照合失敗の原因です。

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

この例では2つの完全一致するドメイン名をそれぞれ処理し、その他のサブドメインは後続のルールに進みます。検証時は、リクエストが設定したドメイン名を実際に使っているか確認しましょう。ページはまずメインドメインにアクセスし、ログイン用ドメインへ移動した後、別の静的リソース用ドメインからコンテンツを読み込む場合があります。メインページが開いても、すべてのリソースが同じポリシーで処理されたとは限りません。リクエストの記録から問題のドメインを特定し、完全一致ルールを追加するか範囲を広げるか判断してください。リソースの読み込みに失敗したからといって、サイトのすべてのドメインに同じポリシーを適用しないようにしましょう。

DOMAIN-SUFFIX：ドメインとサブドメインに一致

DOMAIN-SUFFIX,example.com,PROXYは、例示したドメインとそのサブドメインに適用され、同じドメインツリーをまとめて処理するのに適しています。ドメイン境界に基づいて照合され、任意の文字列を含むかどうかを調べるものではありません。たとえばnotexample.comは、末尾の文字が似ているだけで同じドメインツリーには属しません。通常はルートドメインをそのまま指定し、先頭にアスタリスクを付ける必要はありません。値にパスも記述しないでください。1つのAPIだけを直接接続にしたい場合は、先に完全一致の例外を記述し、その後にサフィックスルールを置きます。

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

この順序は、「APIの例外を優先し、それ以外の例示ドメインにはPROXYを使う」という意図を明確に示します。2行を逆にすると、APIリクエストが先にサフィックス条件に一致し、後ろの完全一致ルールが適用されません。DOMAINがDOMAIN-SUFFIXより自動的に優先される特別な仕組みはありません。結果を決めるのは配置順です。多数のドメインを管理するときは、同じサービスの完全一致例外をまとめてから範囲の広いルールを置き、例外を設定した理由も変更記録に残しましょう。後で整理するときに誤って削除するのを防げます。

DOMAIN-KEYWORD：文字列で範囲を指定する際の注意

DOMAIN-KEYWORD,example,PROXYはドメイン内のキーワードで照合するため、通常はサフィックスルールより範囲が広くなります。安定したキーワードで対象を定義できる場合には便利ですが、意図していない別のドメインにも一致するおそれがあります。一般的な短い文字列ほど誤一致のリスクが高まります。1回のテストで成功しても、特定サービスのドメイン全体と同じ範囲をカバーするとは限りません。範囲を予測しやすくしたい場合は、明確なDOMAINまたはDOMAIN-SUFFIXを優先してください。

種類	照合範囲	確認ポイント
`DOMAIN`	指定した完全一致のドメイン	プロトコル、パス、ポートは含めない
`DOMAIN-SUFFIX`	ドメインとそのサブドメイン	例外ルールを先に置く
`DOMAIN-KEYWORD`	ドメイン内のキーワード	関係のない名前まで一致しないか確認

ドメインルールが機能するかは、クライアントが対象の名前を取得できるかにも左右されます。接続先がIPアドレスとしてしか分からない場合、DOMAINに必ず一致するとは限りません。既に確立した長時間接続では、ルールを変更しても既存セッションにすぐ反映されないことがあります。検証では新しい接続を開始し、記録にある実際の接続先と一致した項目を確認してください。必要ならテスト後に関連アプリを終了してから、リクエストをやり直します。「特定のドメインだけ例外が効かない」場合は、まず上位にある範囲の広いルールを調べ、次に名前情報が取得できているかを確認します。名前解決やキャッシュの調査はその後です。

04 GEOIP、IP-CIDR、その他のルール

ドメインルールとは異なり、IPルールは接続先のアドレスに基づいて判定します。既知のネットワーク範囲、内部サービス、アドレスの所属地域による分類に適していますが、特定サイトのすべてのサービス範囲を自動で表現できるわけではありません。サイトが複数のアドレスを使うことも、同じアドレスを複数のサービスで共有することもあります。1回の名前解決で得たアドレスを広いネットワーク範囲に拡張すると、別の接続先までルールの対象になりかねません。アドレス条件を設定する前に、固定アドレス、管理対象のネットワーク範囲、データベースによる所属判定のどれが必要かを確認し、それぞれに合った方法を選びましょう。

IP-CIDRとIP-CIDR6の適用範囲

IP-CIDRはIPv4アドレス範囲、IP-CIDR6はIPv6アドレス範囲を指定します。スラッシュの後の数字はネットワークプレフィックス長であり、ポート番号ではありません。IPv4の/32とIPv6の/128は、それぞれ1つのアドレスを表します。プレフィックス長の数字が小さいほど、通常は対象範囲が広くなります。内部ネットワークでは実際のネットワーク範囲に合わせて指定し、アドレスの先頭が似ているからといって範囲をむやみに広げないでください。例にある文書用の予約アドレスは形式の説明に使ったもので、実際の接続先ではありません。

[Rule]
IP-CIDR,192.0.2.10/32,DIRECT,no-resolve
IP-CIDR,198.51.100.0/24,PROXY,no-resolve
IP-CIDR6,2001:db8::/32,DIRECT,no-resolve
FINAL,PROXY

no-resolveは、そのIP条件を試すためだけにドメイン名の追加解決を行うのを避ける設定です。「すべてのDNSを無視する」スイッチではなく、リクエスト全体で名前解決が不要になることを保証するものでもありません。リクエストにドメイン名しかなく、判定に使える接続先アドレスがまだない場合、このオプション付きのIP条件が必ず一致するとは限りません。その場合も、後続の適用可能なルールが引き続き確認されます。追加の名前解決を避けたい場合と、名前解決の結果をアドレス分類に使いたい場合では、設定の選び方が異なります。

GEOIPはIPアドレスの所属地域を判定する

GEOIP,CN,DIRECTは、利用可能なアドレス情報に基づいて、接続先が指定された地域コードに属するか判定します。調べるのはIPアドレスの所属であり、ドメインのサフィックス、サイトの表示言語、アクセスする人の所在地ではありません。サービスの実際の配置をすべて反映するとも限りません。同じドメインでもネットワークによって異なるアドレスが返されると、一致結果が変わることがあります。データベース上の分類と運用実態に差がある場合もあります。特定ドメインに必ず一定のポリシーを適用したい場合は、GEOIPの前に明示的なドメインルールを置き、地域判定に個別の例外を任せないようにしましょう。

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

この順序では、まずAPIのポリシーを固定し、その後、判定可能なその他の接続先にGEOIPを適用し、最後に残りを処理します。今回の名前解決でAPIがCNに該当するアドレスを取得しても、先にDOMAINルールが一致するためPROXYが使われます。逆にGEOIPを先に置くと、APIが地域条件で処理され、後ろの例外まで進まないことがあります。この問題を調べる際は、実際のアドレスとルールの配置順の両方を確認してください。ドメイン名と地域ラベルだけを見て、クライアントの判定誤りと決めつけないようにしましょう。

USER-AGENTを使える条件と制限

USER-AGENTは取得可能なリクエストヘッダーに依存するため、すべてのアプリで使える確実な識別方法ではありません。アプリがヘッダーを書き換える場合や、同じアプリでもリクエストによって値が異なる場合があります。暗号化された接続では、リクエストヘッダーを直接取得できないこともあります。特定のアプリからのリクエストだからといって、必ず照合できるUSER-AGENTが含まれるとは限りません。サービスの経路を安定して選びたい場合は、アプリの表示名から条件を推測するのではなく、明示的なドメインとアドレスで表現できるかを確認してください。

[Rule]
USER-AGENT,ExampleClient*,PROXY
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT

例にあるExampleClient*は照合値の形式を示すためのものです。実際に観測できる情報と、アプリが対応する照合方法に合わせてください。このルールを一致させるためだけに、内容を理解していない通信の復号設定を有効にしないでください。このページではUSER-AGENTを一般的な振り分けの前提としていません。リクエストヘッダーを記録から確認できない場合は、観測可能なドメインやIP条件に切り替えるほうが検証しやすく、ネットワークが変わっても管理しやすくなります。設定の分かりやすさは、ルールの種類の多さではなく、条件の明確さで決まります。

IPルールを回帰テストする場合は、少なくとも一致するはずの対象と一致しないはずの対象を1つずつ選び、両方で新しい接続を確立していることを確認してください。内部ネットワークは、別のWi-Fiでも個別にテストしましょう。同じアドレス範囲が、別のネットワークではまったく異なる機器を指すことがあります。単一ルールの異常ではなく、全体的に接続が遅い場合は、速度低下を段階的に調べる方法も参照してください。サーバーへの到達性、ローカルネットワーク、ルールの照合を分けて確認できます。

05 PROXY、DIRECT、REJECT、Global Routing

ルールの末尾には通常、処理ポリシーを指定します。PROXY、DIRECT、REJECTはそれぞれ、プロキシ経由、直接接続、拒否を表しますが、Global Routingの3つのモードと同じものではありません。ポリシーはルールに一致した後の処理方法を決め、モードは全体の接続でどのルーティング方式を使うかを決めます。両者を混同すると、「DIRECTと書いたのにプロキシ経由になる」「ルールを変更しても何も変わらない」と誤解しやすくなります。テスト前にGlobal Routing、現在のConfig、実際に一致した項目の順に確認しましょう。

Config：現在の設定ファイルに沿って確認

Configモードは画面上の表記で、Ruleを検証する際の基本状態です。このモードでは、対応する処理経路に入ったリクエストが設定条件に基づいてポリシーを選択します。すべての通信が利用者の期待どおりになることを自動で保証するものではなく、現在の設定と関連項目に処理を委ねます。誤ったファイルを選択している場合、上位に範囲の広いルールがある場合、Hostがアドレスを変更している場合などは、結果が異なることがあります。ルールを編集したり、画面を記録したり、他の人に相談したりするときは、「接続を有効にした」とだけ伝えるより、現在Configであることを明記すると状況が伝わりやすくなります。

ProxyとDirect：比較用のモード

Proxyモードでは主にプロキシ経路を、Directモードでは直接接続の挙動を確認できます。比較条件として利用できますが、システムのバイパス、名前解決、プロトコルの挙動すべてを上書きする絶対的なスイッチではありません。テスト時はサーバー、ネットワーク、接続先を同じに保ち、モードだけ切り替えてください。ProxyではアクセスできるのにConfigではできない場合は、まずルール、最終ポリシー、関連設定を確認します。Proxyでもアクセスできない場合は、Ruleを書き換える前に接続情報とサーバーへの到達性を調べましょう。

モード	主な用途	テスト時の確認項目
Config / `Config`	現在の設定ファイルに基づいてポリシーを選択	選択中のファイル、ヒットしたルール、FINAL
Proxy / `Proxy`	プロキシ接続経路を比較	現在のサーバー、プロトコルのパラメーター、到達性
Direct / `Direct`	直接接続経路を比較	ローカルネットワーク、名前解決、接続先への到達性

PROXYだけでは接続サービスは用意できない

PROXYは、一致したリクエストを該当するプロキシ経路に渡すだけです。サーバー情報を自動で作成したり、無効になったサブスクリプションを修復したりするものではありません。まずHomeで、選択中のサーバーが手元にある接続情報に基づいていることを確認し、アドレス、ポート、認証情報、プロトコルのパラメーターを照合してください。プロトコルによっては、通信方式、TLS名、その他の拡張項目も関係します。名前が同じだからといって、必要な設定がすべて揃っているとは限りません。アプリの買い切り購入と接続サービスは別です。ルールが正しくても、サーバーが必ず使えるとは限りません。

[Rule]
DOMAIN,api.example.com,PROXY
DOMAIN,local.example.com,DIRECT
DOMAIN,blocked.example.com,REJECT
FINAL,PROXY

DIRECTは現在のネットワークから接続先へ直接接続することを示しますが、接続先に必ずアクセスできるという意味ではありません。内部ドメインは特定のWi-FiのDNSに依存することがあり、サーバーによっては特定の送信元アドレスからの接続しか許可しない場合もあります。DIRECTで失敗した場合は、すぐにPROXYへ変更するのではなく、ローカルネットワークと名前解決の結果を確認してください。ルールが正しいかどうかと、接続先に到達できるかどうかは別の問題です。意図したDIRECTに一致していても、接続先が拒否するなど、接続環境が要件を満たさず失敗する場合があります。

REJECTの適用範囲を明確にする

REJECTは一致したリクエストを拒否します。アクセス不要と明確に分かっている接続先に使うのが適切です。最初から広いキーワードや大きなアドレス範囲にREJECTを適用すると、ページに必要なAPI、ログイン後の遷移、リソースのリクエストまでブロックするおそれがあります。ページの一部が空白になる、読み込みを繰り返す、ログインできないといった場合は、関連リクエストが拒否ルールに一致していないか確認してください。ルールを削除する前に、複製上で範囲を一時的に狭め、同じ操作をもう一度テストします。問題の原因がその条件だと確認してから、必要最小限の変更を残しましょう。

FINALにもポリシーの指定が必要です。たとえばFINAL,PROXYは、それ以前のルールに一致しなかったリクエストをプロキシ経路に送り、FINAL,DIRECTは残りを直接接続します。どちらがすべての利用者に適するという既定の答えはありません。最終ポリシーを決める前に、どのリクエストに例外が必要か、利用するサービスに到達できるか、ルールをどう管理するかを整理してください。よくある事象はQ&Aでも確認できますが、トラブルの記録には現在のモードと実際に一致したポリシーを残しましょう。「接続に失敗した」とだけ記録しても、原因の切り分けには不十分です。

06 評価順序、例外、FINAL

ルールリストの基本は上から順に確認し、最初に一致した適用可能な項目でポリシーが決まることです。すべての条件を集めてから、最も「正確」なルールを自動選択する仕組みではありません。通常の順序ルールでは、後ろにある細かな条件が前の広い条件を自動的に覆すことはありません。そのため、設定ファイルはルールの種類だけでなく、配置順も重要です。ルールが機能しないときは、その行だけを検索するより、リストの先頭から確認するほうが早いことがあります。リクエストに一致しているのは、上にある既存の項目かもしれません。

明確な例外を先に、範囲の広い条件を後にする

保守しやすい並べ方の一例は、具体的なサービスの例外、ドメインツリーや管理対象のネットワーク範囲、一般的な分類、最後にFINALという順です。これが唯一の正しい構成というわけではありませんが、「この接続先が他と異なる理由」を読み取りやすくなります。たとえばAPIにはPROXYを使い、同じドメインツリーのその他のリクエストにはDIRECTを使う場合は、DOMAINのAPIルールをDOMAIN-SUFFIXより前に置きます。後からキーワードルールを追加したときも、既存の例外範囲を誤って上書きしないか確認してください。

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

api.example.comへの新しいリクエストは、1行目の条件を満たした時点でポリシーが決まるため、後のサフィックス条件で結果を説明する必要はありません。static.example.comへのリクエストは1行目に一致しないため、2行目が判定されます。ドメインルールに一致しない接続先では、その後にアドレス条件やGEOIPを確認します。この順序は手作業での確認にも使えます。対象ごとに各行へ「一致」「不一致」と書き、最初に一致した位置を見れば、設定の動作と変更意図が一致しているか判断できます。

FINALは未一致時の処理であり、ルールを修正するものではない

FINALは通常、Ruleの末尾に置き、それ以前の条件に一致しなかったリクエストに明確な処理を適用します。先頭に置くと、後続の通常ルールが実行されなくなり、後ろにも有効な例外があるように誤解させるおそれがあります。FINALが重複している場合は、設定の統合時に整理できていない可能性があります。複製上に目的に合う末尾のFINALを1つだけ残し、その前の項目を見直してください。前のFINALを「上書き」するために2つ目を追加したり、集計やテスト用の目印として使ったりしないでください。

設定ファイルを2つ統合する場合、2つのRuleセクションをそのまま前後に連結して終わりにしてはいけません。まず完全一致の例外を取り出し、同じ条件に異なるポリシーが設定されていないか確認します。次に範囲の広い項目の順序を決め、最後に明確なFINALを1つにまとめます。重複した条件は構文上問題がなくても、実際に有効な行を保守担当者が読み違える原因になります。テキストの重複だけで削除せず、適用範囲を理解してください。サフィックスルールが、異なる多くの完全一致ドメインルールを覆うことがあります。

競合するケースで確認する

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

この例では、APIリクエストが最初の行に一致するため、2行目で結果が決まることはありません。修正するには2行の順序を変えます。プロキシサーバーを変更したり、同じDOMAINを末尾にもう一度コピーしたりする必要はありません。逆に、最初のDIRECTでサブドメインすべてを処理したいのであれば、実際には機能しない後続の例外を削除し、設定ファイルに本来の意図を反映させましょう。ルールは少なければよいというものではありませんが、残す各ルールには説明できる適用範囲とテストの根拠が必要です。

ルール変更後は、接続の再利用によって反映の確認が遅れる場合があります。既に確立した接続が以前の経路を使い続けることがあり、ページを再読み込みしても新しい接続が発生したとは限りません。設定を保存し、選択状態を確認してから接続を確立し直し、新しい操作でテストしてください。比較する場合は同じネットワーク、サーバー、接続先を使い、ネットワーク切り替えによるアドレスの変化を順序の違いと混同しないようにしましょう。動的にアドレスが変わるドメインでは、テストごとの実際の名前解決結果も記録します。

最後に逆方向からも確認します。対象の例外が機能することだけでなく、新しいルールが近接するサービスに影響していないか調べてください。完全一致ドメインをキーワードに変更した場合は、同じ文字列を含む無関係な名前も少なくとも1つ確認します。GEOIPを上位に移動した場合は、以前PROXYに固定していたAPIが、今も例外に先に一致するかを確認します。ルールの管理は末尾に項目を足し続けることではなく、条件の境界を維持することです。整理するたびに復元用の複製を保存し、決めておいたテストを再実行してください。

07 HostとURL Rewriteの役割と適用範囲

HostとURL Rewriteは同じ設定ファイルに登場することがありますが、Ruleとは異なる問題を解決します。Hostは静的マッピングで名前解決の結果に影響し、URL RewriteはURLの条件に基づいて書き換えやリダイレクトを行います。Ruleは処理ポリシーを選択します。ドメインにPROXYが適用されても、名前解決や書き換えが正しいとは限りません。Hostを追加しても、リクエストが自動的に直接接続になるわけではありません。トラブルの切り分けでは、項目ごとに無効化または復元して試し、「接続先がどう変わったか」と「どの経路で接続したか」を分けて確認しましょう。

Hostで名前とアドレスを固定する場合

[Host]
localhost = 127.0.0.1
test.example.com = 192.0.2.10

1行目はローカルの名前解決マッピングでよく使われる例、2行目は構文を示すための文書用予約アドレスで、利用可能なサービスではありません。実際にマッピングを固定するのは、接続先のアドレスが明確で、それを使ったテストが必要な場合に限ってください。通常の名前解決では複数のアドレスやフェイルオーバーが使われることがありますが、Hostを設定するとローカルで確認した結果に固定されます。サービスのアドレスが変わると、以前は使えたマッピングが障害の原因になる可能性があります。カスタムマッピングごとに用途を記録し、一時的なテストを終えたら削除するか検討しましょう。

静的マッピングは通常、リクエストで使うドメイン名そのものを変更せず、TLSの名前検証に代わるものでもありません。HTTPSのドメインを別のサーバーに向けても、そのサーバーが元のドメインを正しく処理し、一致する証明書を提供できる必要があります。アドレスに到達できれば必ずアクセスできると考えるのはよくある誤りです。証明書の名前が一致しない場合は、まず通常の名前解決に戻すかサーバー設定を確認してください。DOMAIN-SUFFIXのポリシーに証明書エラーの原因を求めたり、検証を無効にして誤ったマッピング先を隠したりしないでください。

URL RewriteはURLの条件を照合する

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

この例では、条件に一致したHTTPアドレスを例示したHTTPSアドレスへリダイレクトします。正規表現の^は先頭を、\.はドメイン内の文字としてのピリオドを表します。末尾のスラッシュは照合範囲を限定します。ピリオドをエスケープしないと、正規表現では任意の1文字として扱われる場合があります。ドメインの後に適切な境界がないと、本来対象にしないアドレスまで一致することがあります。転送先は固定値なので、パスやクエリパラメーターがすべて自動的に引き継がれるとは限りません。

302はリダイレクトの応答を示します。リダイレクトが行われると、クライアントは新しいURLにアクセスします。元のリクエスト内部で接続に関するすべての動作をひそかに置き換えるものではありません。新しいリクエストでも名前解決、経路の選択、接続が必要です。転送先に到達できなければ、書き換え自体が成功していてもページは正常に開きません。テストでは、元のアドレスが式に一致するか、応答が想定した接続先を示すか、その後のリクエストが正常に処理されるかをそれぞれ確認してください。ブラウザーのアドレスが変わっただけでは、後続のリソースも正しく処理されたとは証明できません。

観測できる範囲を確認してから書き換えを有効にする

HTTPとHTTPSで見える情報は異なります。設定にルールを書けば、暗号化されたリクエストの完全なURLをすべて直接読み取れるとは限りません。追加の条件がないと観測できない情報については、まずアプリ内の関連説明を確認し、証明書と信頼設定に関する影響を検討してください。このページで扱う通常のルール振り分けは通信の復号を必要とせず、アクセス問題を直すための標準手順として復号を勧めるものではありません。特定ドメインにPROXYを適用するだけならRuleを使い、パスの照合のために余分な処理層を導入する必要はありません。

保守しやすい書き換えルールには、元の対象範囲、転送先、期待する応答を明記します。キャプチャグループを含む複雑な正規表現をコピーする場合は、置換文字列からキャプチャ内容をどう参照するか確認し、最も単純なパスとクエリパラメーター付きのパスをそれぞれテストしてください。構文が似ている式を、そのまま同じ意味と考えてはいけません。一時的な診断用ルールは長期利用するルールと分けて記録し、テスト終了後に削除します。複雑だからといって正確とは限りません。実際の要件を満たす最小限の式のほうが、確認も容易です。

HostとURL Rewriteを組み合わせて調べる場合は、まず通常のDNSと最小限のRuleを残し、接続先に元から到達できるかを確認してから追加します。Hostを追加した場合だけ失敗するなら、アドレスと証明書を確認します。書き換えを追加した場合だけ失敗するなら、照合範囲、転送先、ループを確認してください。両方を取り消しても失敗する場合は、サーバーとネットワークの問題に戻ります。この順序なら、誤ったマッピングやリダイレクトをルール追加で補うのを避けられ、最終的に残した各セクションの役割も明確になります。

08 設定の検証、トラブルの切り分け、復元

編集後の検証は、「Webページが開くか」だけを結論にせず、明確な目的を決めて行います。対象のドメイン、ネットワーク、使用するサーバー、一致すべきルール、期待するPROXY、DIRECT、REJECTのいずれかを具体的にしてください。次に現在のConfigとGlobal Routingを確認してから、新しいリクエストを送ります。失敗した場合も、ルールが正しく適用されたか、問題が名前解決、接続、認証、接続先の応答のどの段階にあるかを区別できます。やみくもにルールを追加・削除し続ける必要はありません。

繰り返し確認できるテスト記録を作る

テストのたびに、接続先、ネットワーク環境、選択中のサーバー、設定ファイル、一致結果を記録します。少なくとも、PROXYにする明確な例外、DIRECTにする明確な例外、FINALに進む一般的な接続先の3種類を用意してください。拒否ルールを検証する場合は、REJECTになる想定の接続先も追加します。テストには利用者自身がアクセス権を持つサービスを使い、検証のために新しい接続サービスを探す必要はありません。2回の結果を比較する際は、変更した項目以外の条件をできるだけ同じに保ちます。

確認項目	記録する内容	問題がある場合の確認先
設定状態	現在のConfigとGlobal Routing	選択されていないファイルを編集していないか
名前解決の結果	対象のドメインと実際のアドレス	DNS、Host、アドレスファミリー
ルールの判定結果	最初に一致した項目とポリシー	上位の広いルール、FINALの位置
接続結果	失敗した段階とエラーメッセージ	サーバーのパラメーター、ローカルネットワーク、接続先の状態

Connectivity Testと実際のリクエストを分けて確認

Connectivity Testは、指定した条件での接続状況を調べる補助として使えます。ただし、テストに成功しても、すべてのWebサイト、リクエスト、振り分けルールが動作するとは限りません。実際のリクエストでは、異なるドメイン、アドレスファミリー、接続方式、認証手順が使われることがあります。逆に、テストに失敗しても、すべてのサービスが利用できないとは限りません。テスト対象とエラー情報を確認しましょう。まずテスト機能で問題の範囲を絞り、その後、実際のサービスへの新しいリクエストでルールと経路を確認してください。単一の結果をネットワーク全体の状態と見なさないようにしましょう。

すべてのPROXYリクエストが失敗する場合は、最小限の設定を保ち、現在のサーバーと手元にある接続サービスの状態を確認します。特定ドメインだけ失敗する場合は、一致したルール、名前解決、接続先の応答を調べます。ページ本体は表示されるのにリソースが欠ける場合は、リソース用ドメインとREJECTルールを個別に確認します。ネットワークを切り替えたときだけ失敗する場合は、DNS、On Demand、アドレスファミリーの変化を記録してください。このように場合を分けて調べるほうが、Generalの設定を一度にすべて変更するより効果的です。1つのAPIの異常で、正常に動作している他のルールを壊すことも避けられます。

ログには必要な情報だけを残す

アプリのログで接続先、一致したルール、エラーが発生した段階を確認します。ただし、サブスクリプションのURL、パスワード、認証項目を公開の相談場所に貼り付けないでください。問題を調べるための資料を保存するときは、スクリーンショットやテキストに機密情報が含まれていないか確認し、再現に必要な最小限のルールだけを共有します。サーバー名に利用者独自の情報が含まれる場合もあるため、同様に確認してください。設定ファイルを丸ごと共有しても、トラブルの解決が早まるとは限りません。明確なリクエスト条件と最初に一致した証拠を残すほうが、整理されていない大量のログより役立ちます。

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

上の最小例では、ルールの順序を示しつつ、接続に必要な認証情報を公開せずに済みます。実際の問題をまとめるときは、実際のサービス名を例示用ドメインに置き換えながら、「完全一致の例外をサフィックスルールより前に置く」といった構造は維持できます。実際のアドレスの所属が問題に関係する場合は、情報を伏せていることを明記し、例示したアドレスを実際のテスト結果と誤解されないようにしてください。再現用の資料にはロジックを説明するための情報があれば十分です。サブスクリプションやサーバーの認証情報を含めたり、非公開URLを問題のタイトルやファイル名に使ったりしないでください。

設定を戻した後、リモート更新で再度上書きされていないか確認

期待と異なる動作が起きたら、変更前の複製を復元し、そのファイルが選択されていることを確認します。元のGlobal Routingとサーバーを選び直し、再接続して同じテストを実行してください。復元直後に正常になった場合は、変更を1つずつ追加し直して最小の差分を特定します。復元後も失敗する場合は、ネットワークやサービスの状態も変化していないか確認しましょう。リモート設定を再取得するとローカルの修正が上書きされることがあります。復元後は、一覧の名前が以前と同じかを見るだけでなく、ファイルの内容も確認してください。

日常の管理では、安定版の設定、試験用の複製、簡潔な変更記録を用意しておくと便利です。ルールを追加した後は決めておいたテストを実行し、サブスクリプションを更新した後は選択中のサーバーが想定どおりか確認します。別のデバイスに移行した場合は、設定が読み込まれているかを改めて確認してください。アプリの購入済み状態がすべての接続情報と一緒に同期されるとは限りません。iPadでの購入と利用については、iPadで購入済みのアプリを使う方法をご覧ください。購入の復元で確認できるのはアプリの入手状況です。設定の移行やサーバーのパラメーター確認に代わるものではありません。

接続手順を最初から確認する場合はShadowrocketの使い方ガイドをご覧ください。よくある問題をすぐに調べる場合はQ&Aとトラブル対処、アプリの入手元を確認する場合は正規版を見分ける3つのポイントをご確認ください。アプリのアイコン、開発者名Shadow Launch Technology Limited、アプリID 932747118は、App Storeページで照合してください。設定は、内容を理解でき、検証でき、元に戻せることを基準に管理します。ルールの数やファイルの長さで品質を判断しないでください。