Shadowrocket ルールマニュアル
設定ファイルの構成と照合順序

設定ファイルとサブスクリプションは別のもの

設定ファイルはリクエストの処理方法を定め、サブスクリプションは主に利用者がすでに持っているサーバー項目の読み込みと管理に使います。どちらも接続に関係しますが、互いに置き換えることはできません。サブスクリプションの更新に成功しても、内容が読み込まれたことを示すだけで、現在のルールが正しいとは限りません。設定ファイルを保存できても、参照先のプロキシが利用可能とは限りません。トラブル対処では、ルールの例外をサーバーパラメーターの問題と取り違えないよう、まず両方を別々に確認してください。

Configで現在選択されている設定ファイルを確認し、該当する編集画面を開きます。試験する場合は、先にファイルを複製して見分けやすい名前を付け、元のファイルも残してください。複製しただけで、そのファイルを選択していなければ、接続結果に変更は反映されません。使用中のファイルを編集した場合は、保存後にアプリの案内に従って再読み込みしてください。確認時はリクエストを新たに発生させ、変更前に確立した接続を使い続けないようにします。

角括弧で設定の適用範囲を指定

Shadowrocketの一般的なテキスト形式の設定ファイルでは、セクション見出しで内容を整理します。[General]には一般設定、[Rule]には振り分けルール、[Host]にはホスト名のマッピング、[URL Rewrite]にはリクエストURLの書き換えルールを記述します。セクションは見た目を整えるためのものではありません。同じ行でも、置かれたセクションによって意味が異なる場合があります。設定例をコピーするときは、セクションの位置も確認してください。ファイル内にキーワードがあるだけで、設定が有効になっているとは限りません。

[General]
dns-server = system

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

この例は構成を示すものです。1行目はルートドメインに完全一致で適用し、2行目は同じサフィックスを持つほかのドメインに適用します。最後の行は残りのリクエストを処理します。dns-server = systemはシステムのDNS設定を使うことを示しますが、すべての環境で同じ名前解決結果になることを保証するものではありません。例を保存できたからといって、サーバー選択や接続認証、ネットワーク設定まで完了したと判断しないでください。これらの条件はアプリ内で個別に確認する必要があります。

変更内容を追跡できるよう、差分は最小限に

長いファイルを読むときは、まずセクション見出しを探し、次に解決したい問題に関係する箇所を確認します。セクションやフォールバックルールの重複、ファイル末尾に散在する一時的な項目は、判断を難しくします。同じ種類のローカル例外はまとめて配置し、目的は独立したコメント行に記録するのがおすすめです。コメントにはルールそのものを繰り返すのではなく、追加する理由を書きます。共有する予定のコメントに、実際のサブスクリプションURLや認証情報を書かないでください。

設定を読み込む前に、ファイル名だけで判断せず、内容を確認してください。特に最終ポリシー、DNS設定、Hostマッピング、書き換え設定を確認し、現在の環境に存在しないポリシー名を参照していないか調べます。ルールが多く含まれていても、元のサーバー構成にしか適用できない場合があります。見慣れないオプションは値をそのまま保ち、アプリ内で対応状況を確認してください。別形式の設定名を、現在のファイルに直接追加しないようにします。

自動更新される内容と手動で管理する内容は分けてください。設定の取得元が更新時にローカル編集を上書きする場合、変更は次回の更新で失われる可能性があります。まず更新対象がサブスクリプションなのか、設定ファイル全体なのかを確認してから、ローカルの例外を追加する場所を決めます。上書き範囲が不明な場合は、独立した複製を残して差分を記録してください。同じリモート設定を続けて編集するより復元しやすく、問題が更新によるものかローカル操作によるものかも判断しやすくなります。

以下のコード例には、セクション見出しを含むものとルール行のみのものがあります。ルール行だけの例は、すでにある[Rule]セクションに追加してください。各例のために同じセクションを新たに作る必要はありません。購入時や初回起動時の環境を確認する場合は、App Storeの正規配信確認ページをご覧ください。このマニュアルでは、アプリの入手方法と通信設定を同じ手順として扱いません。

Config、Proxy、Directを確認

設定ファイルに基づいて振り分ける場合は、Global RoutingでConfigを選択します。ProxyとDirectは異なるグローバル処理モードであり、設定ファイルのルールに追加する通常のルールではありません。Proxyが選択されている状態では、ドメインルールを変更してもConfigの振り分けが正しいことの確認にはなりません。Directの場合も、対象にアクセスできたからといって、プロキシサーバーがリクエストを受け付けたとは限りません。トラブル対処では、まずモードを確認してください。

表は3つのモードの主な用途を示しており、設定内のほかの項目がすべて置き換わるという意味ではありません。DNS、既存の接続、アプリ自体のネットワーク動作も観察結果に影響することがあります。モードの切り替えは比較のための方法であり、特定の処理が確実に正常だと証明するものではありません。テスト時は現在のモードと選択中の設定を記録し、終了後は意図した設定に戻してください。そうしないと、その後の調整も誤った前提に基づく可能性があります。

モード、ルール、サーバーの3段階で判断

トラブル対処では、まず設定による振り分けが有効か、次にリクエストがどのルールに一致するか、最後にポリシーが利用する接続情報が使えるか、という3段階で確認します。ルールでPROXYを選択するのは処理経路を指定するものであり、サーバーアドレス、ポート、認証情報を補うものではありません。利用可能な項目がサブスクリプションにない場合、細かいドメインルールを追加しても接続情報の代わりにはなりません。まず利用者自身のサーバー情報を確認してから、例外の追加を検討してください。

画面上のProxyと、設定ファイル内のPROXYを混同しないでください。前者はGlobal Routingの選択肢で、後者は設定テキストのポリシーキーワードです。どちらもプロキシ経由の通信に関係しますが、異なる階層の項目です。同様に、画面上のDirectとルール内のDIRECTも、文脈に応じて区別する必要があります。設定を編集するときはキーワードを大文字のまま保つと、モード名とルールのパラメーターを混同しにくくなります。

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

このルールは、Configが処理に使われていることを前提に、指定したドメインサフィックスに一致するリクエストをPROXY、それ以外をDIRECTで処理します。確認時は、一致するはずのリクエストと一致しないはずのリクエストを両方テストしてください。対象サイトが開けるかだけでは、ルールが正しいのか、グローバルモードが意図した処理を上書きしているのか、もともと直接接続できるのかを区別できません。

モードを何度も切り替えず、比較テストで問題の範囲を絞る

Proxyでは接続できるのにConfigでは失敗する場合は、Configで使われるファイル、ポリシーの参照先、照合順序を優先して確認してください。この違いだけでドメインルールの誤りと断定することはできません。Hostマッピング、名前解決設定、より前にあるREJECTルールなどが差を生む場合もあります。両方のモードで失敗する場合は、ルールを増やす前にサーバーパラメーターと基本的なネットワーク接続を確認してください。

Directでは成功しProxyでは失敗する場合は、プロキシ経由の経路を調べてください。対象サフィックス全体をすぐにDIRECTへ変更しないようにします。一時的に直接接続へ変更すれば比較できますが、通信経路も変わるため、元の問題を回避しただけかもしれません。接続確立、名前解決、その後のアクセスのどの段階で失敗するかを記録してから、変更する項目を決めてください。一度に変更する条件は1つにすると、結果を判断しやすくなります。

切り替え後は対象を開き直すか、操作をもう一度実行してください。必要に応じて既存の接続を終了してからテストします。長時間接続は確立時の処理方法を使い続ける場合があり、キャッシュされたページでは新たな通信が発生したと誤認することもあります。リクエストが確実に発生する操作を選び、アプリ内で確認できる接続記録も参照してください。詳しい操作手順はチュートリアルのGlobal Routingの説明をご覧ください。

DOMAIN：指定したホスト名に完全一致

DOMAINはドメインに完全一致するルールです。example.comを指定した場合に一致するのは、このホスト名自体です。すべてのサブドメインに自動的に適用されるわけではありません。対象ホストが1つに限定される場合は、完全一致ルールのほうが確認しやすいでしょう。ルートドメインとサブドメインの両方を処理するには、サフィックスルールを検討してください。完全一致の値にプロトコル、パス、クエリパラメーターを加えないでください。これらはドメインの一部ではありません。

DOMAIN,example.com,DIRECT
DOMAIN,www.example.com,PROXY
DOMAIN,api.example.com,PROXY

この3行は、それぞれ異なる完全なホスト名を処理します。2行目は1行目に一致せず、3行目にも自動的に適用されません。Webサイトでは、ページ、ログイン、画像、APIが別々のホストに分かれていることがありますが、ブラウザーのアドレスバーに表示されるのはその一部です。トップページは正常でもログインに失敗する場合は、実際に失敗したリクエストのホスト名を確認してからルールを追加してください。アドレスバーに表示されたルートドメインだけを見て、サービス全体が一致したと判断しないようにします。

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

DOMAIN-SUFFIX,example.com,PROXYはサフィックスによる一致を表し、通常はルートドメインとそのサブドメイン（例：www.example.com）が対象になります。任意の文字列を含むか調べるルールではありません。notexample.comは文字列の末尾が似ているだけで、同じドメインサフィックスとして扱われるわけではありません。ルールを読むときはドメインのラベル境界に注目し、URL全体を検索するルールだと解釈しないでください。

よくある誤りは、サフィックスルールに*.example.comという書き方が必要だと思い込むことです。この場合はexample.comと記述すればサフィックスを指定でき、ワイルドカードは必要ありません。ルールの値に末尾のスラッシュも付けません。対象URLをコピーしたら、まず完全なURLからホスト名を取り出し、プロトコル、ポート、パス、クエリを除いてから、完全一致とサフィックスのどちらを使うか判断してください。

DOMAIN-KEYWORD：範囲が広いため、誤一致に注意

DOMAIN-KEYWORDは、ドメイン名に指定した文字列が含まれるかを確認します。完全なドメインラベルを境界として扱わないため、サフィックスルールより影響範囲を把握しにくい傾向があります。複数のドメインを共通文字列で処理する必要がない限り、列挙できる完全なホスト名や明確なサフィックスを優先してください。キーワードが短いほど無関係なリクエストにも一致しやすく、後から特定のホストがプロキシ経由になった理由を説明しにくくなります。

DOMAIN,api.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,example,REJECT
FINAL,DIRECT

この順序では、最初に特定のホスト名をDIRECTで処理します。同じサフィックスに一致するほかのリクエストは次にPROXYで処理します。キーワードを含み、前の2行では処理されなかったドメインが、最後にREJECTへ進む可能性があります。この例は3種類の範囲の違いを示すものであり、広範なキーワードで関連する名前をすべて拒否することを勧めるものではありません。3行目を先に置くと、残したい例外が適用されない可能性があります。

ドメインルールで照合するには、クライアントが一致判定に使えるドメイン情報を取得できる必要があります。リクエストがアドレスに直接接続する場合、元のホスト名が必ず特定できるとは限りません。逆に、ドメインが複数のアドレスに名前解決されても、各アドレスを個別にルールへ記述する必要があるとは限りません。実際のリクエスト形式に合わせて選んでください。ホスト名を安定して識別できる場合はドメインルールを使い、ネットワークアドレス範囲を処理する必要が明確な場合にアドレスルールを検討します。

ドメインルールを追加したら、ルートドメイン、サブドメイン1つ、似ているが無関係なドメインがそれぞれどう処理されるか確認してください。まずは紙上で動作を確認すればよく、例に挙げたすべてのサイトへ実際にアクセスする必要はありません。基本構文の詳しい説明はDOMAIN、DOMAIN-SUFFIXなどのルールタイプ解説をご覧ください。続く章ではアドレスルールとドメインルールが重なる場合の判断方法を説明します。

IP-CIDRとIP-CIDR6でアドレス範囲を指定

IP-CIDRはIPv4アドレス範囲、IP-CIDR6はIPv6アドレス範囲に使います。スラッシュの後の数字はプレフィックス長であり、ポート番号やワイルドカードの数ではありません。単一のIPv4アドレスは/32、単一のIPv6アドレスは/128で表せます。ネットワーク範囲を広げると対象も増えるため、あるアドレスへの接続に失敗したからといって、隣接する大きな範囲まで同じポリシーに含めないでください。

IP-CIDR,192.0.2.10/32,DIRECT,no-resolve
IP-CIDR,192.0.2.0/24,PROXY,no-resolve
IP-CIDR6,2001:db8::/32,DIRECT,no-resolve

ここでは説明用のアドレスを使用しており、実在するサーバーを示すものではありません。1行目は特定のアドレスに対する例外、2行目はより広いアドレス範囲で、順序によって例外が有効になるかが変わります。IPv6の例は別のアドレスファミリーの構文を示しており、IPv4ルールの代わりにはなりません。実際の対象が両方のアドレスファミリーを返す可能性がある場合は、それぞれの処理を確認してください。片方だけ確認して、アクセス全体が意図どおりだと判断しないようにします。

no-resolveはルール照合のために追加で名前解決する動作を制御

アドレスルールでドメイン名のリクエストを処理するには、アドレスを取得する必要がある場合があります。no-resolveは、このルールの照合だけを目的とする名前解決を避けるための指定です。すでに利用可能なアドレス情報がある場合の結果は、実際の処理に基づいて判断してください。クライアント全体のDNSを停止する指定でも、ほかの経路での名前解決を必ず防ぐ指定でもありません。汎用的な名前解決の不具合を直すスイッチと解釈すると、原因の調査がずれてしまいます。

ドメインに基づく安定した振り分けが必要なサービスには、通常はまずドメインルールを使います。ネットワーク範囲を明示的に処理する必要がある場合に、アドレスルールを使ってください。同じアドレスを複数のホストが共有することも、同じホストがネットワークやリゾルバー、時間によって異なるアドレスを返すこともあります。一度の名前解決結果を長期的なルールに固定すると、後から変わったアドレスを処理できなかったり、共有アドレス上の別サービスに影響したりする場合があります。

GEOIPはアドレスの地域分類であり、サイトの識別ではない

GEOIP,CN,DIRECTは、IPアドレスデータベースの地域分類に基づいてポリシーを選択します。判定対象はアドレスの地域情報であり、運営主体やページ内容ではありません。分散型のインフラを使うサービスでは、ドメインの正体と接続先アドレスの地域分類が異なる場合があります。データベースは更新され、分類の境界も変わるため、ある時点の地域判定をサービスの実際の設置場所についての恒久的な結論にしないでください。

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

この例では、まず特定のドメインに処理経路を指定し、次にそれ以外のリクエストをアドレス分類で処理し、最後にフォールバックへ進みます。この順序なら、意図が明確なドメインルールが広範なアドレス判定より優先されます。GEOIPを先に置くと、該当アドレス範囲に解決されたドメインが先に処理され、後続のドメインルールが適用されない可能性があります。特定のルールタイプが本質的に優先されるのではなく、条件を最初に満たすルールが適用されます。

USER-AGENTはリクエスト情報の可視性に依存

USER-AGENTは確認可能なリクエストヘッダーの特徴に基づいて照合するため、該当するリクエスト情報がある場面で使えます。ただし、すべてのアプリを確実に識別する方法ではありません。異なるアプリが同じ識別子を使う場合もあれば、同じアプリがリクエストごとに異なる識別子を使う場合もあります。特に暗号化された通信では、通常のネットワーク転送でHTTPヘッダーを読み取れるわけではありません。一致する項目が見えなければ、ルールがアプリ名から内容を推測することもありません。

USER-AGENT,ExampleClient*,DIRECT

この行はルールタイプの書式とワイルドカード形式を示すだけで、端末にそのプログラムがあることを意味しません。例を一致させるために端末のセキュリティ設定を変更しないでください。また、明確に指定できるドメインルールの代わりにUSER-AGENTを使わないでください。機能しないと思われる場合は、実際のリクエストに確認可能な該当フィールドが含まれているかを先に確認してから、順序を調べます。そもそも確認できないフィールドなら、似たルールを追加しても通常は解決しません。

アドレス、地域、リクエストの特徴に基づくルールは、実際に確認できる情報と合わせて解釈してください。記録に対象アドレスが1つだけある場合は、リクエスト先のアドレスなのか、名前解決結果なのか、プロキシサーバーのアドレスなのかを確認します。これらは別の対象です。サーバーに接続する外側の経路を対象サイトのアドレスと取り違えると、振り分けの判断全体が誤ります。判別できない場合は、最小限のドメインルールに戻して比較し、アドレス条件を段階的に追加してください。

ルールは「何に一致するか」、ポリシーは「どう処理するか」を定める

一般的なドメインルールは、タイプ、照合対象、ポリシーで構成されます。DOMAIN-SUFFIX,example.com,PROXYでは、最初の2項目が条件を、最後の項目が一致した後の処理方法を決めます。最後の項目を変えても照合範囲は変わりません。PROXYをDIRECTに変更しても、選択されるドメインは同じで、通信経路だけが変わります。この役割分担を理解すると、ポリシーの問題をドメイン範囲の問題として誤って修正するのを防げます。

PROXYが使う接続項目は、現在の設定とアプリ内の選択内容で確認する必要があります。設定に独自のポリシー名が含まれる場合は、その名前に対応する定義があることと、メンバーが現在の環境に合っていることを確認してください。「プロキシ」を意味する名前が付いていても、選択中のサーバーを指すとは限りません。ルールをコピーするときに、元のファイルの独自名称をそのまま残すと、参照先と実際の項目が一致しなくなることがあります。

DIRECTは経路の指定であり、接続成功の保証ではない

DIRECTは一致したリクエストを直接接続経路に送りますが、ローカルネットワーク、対象サービス、名前解決結果にも依存します。ルールをDIRECTに変更しても失敗する場合は、ルールが一致していないと決めつけず、直接接続経路を調べてください。反対に、直接接続に成功しても、元のプロキシ経路の認証、証明書、通信パラメーターが正常だとは限りません。ポリシーの選択とネットワークへの到達性は別々の結果として、記録と実際のアクセスで確認してください。

REJECTはリクエストを意図的に拒否する動作です。ルールを追加する前に、対象ホストがログイン、認証、ページ表示に必要なリソースを提供していないか確認してください。名前だけから用途を推測すると、共有インターフェースまで拒否することがあります。変更後にページの一部が表示されなくなった場合は、新しく追加した拒否ルールを一時的に削除して再テストしてください。プロキシ例外の追加、DNS変更、URL書き換えを同時に行うと、どの変更で機能が戻ったのか判断できません。

FINALにはドメインの照合値を指定しない

FINALは、前のルールに処理されなかったリクエストに適用するフォールバックです。一般的な書き方はFINAL,DIRECTまたはFINAL,PROXYで、ドメインルールのような照合値は必要ありません。特定のドメインに一致する条件がないため、ルール一覧の最後に置いてください。途中に置くと、後続の通常ルールが適用されず、ルールを変更しても結果が変わらないように見えることがあります。

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

この例は「完全一致の例外1つ、サフィックス範囲1つ、それ以外は直接接続」を示します。既定の処理をプロキシにしたい場合は、最後の行をFINAL,PROXYに変更し、前にあるDIRECTの例外を残す必要があるか改めて確認してください。ファイル全体の既定の方向を考慮せず、最後の行だけをコピーしないでください。既定の方向を変えると、前のルールを変更しなくても、列挙されていない多くのリクエストの経路が変わります。

意図を明確にしてからフォールバックの方向を選ぶ

FINALを選ぶ前に、目的を一文で説明できるようにしてください。指定した一部のホストだけをプロキシ経由にして、それ以外は直接接続するのか。それとも大半のリクエストをプロキシ経由にして、一部だけ直接接続するのか。前者は通常FINAL,DIRECTと組み合わせて考えやすく、後者は例外とFINAL,PROXYの関係を慎重に管理する必要があります。すべてのネットワークに共通する正解はありません。利用者自身のアクセス要件と、すでにある接続条件に基づいて判断してください。

フォールバックルールは障害時の自動切り替えではありません。FINAL,PROXYは、前のプロキシ接続に失敗した場合に別のポリシーを試すという意味ではありません。前の照合条件に一致したかどうかを処理し、接続の成否は判断しません。ルールの一致と接続結果は別の段階で起こります。同じドメインに異なるポリシーのルールを続けて書き、1つ目が失敗したら2つ目に進むことを期待しないでください。通常の順次照合では、そのような再試行は行われません。

メンテナンスでは、ルール一覧の最終的な処理先を1つに明確化すると、読みやすく確認もしやすくなります。FINALが複数ある場合は、実際に到達する最初の位置を特定し、その後にある無効な項目を整理してください。削除前に複製を残し、別のセクションに属する内容を誤って消さないようにします。最終的な設定では、各通常ルールの目的と、列挙されていないリクエストの行き先が分かる状態にしてください。

「より具体的に見える」ルールより、先に一致したルールが優先

通常の順次ルールは上から順に評価され、最初に一致した項目のポリシーが適用されます。DOMAINが必ずDOMAIN-SUFFIXより優先されると考えたり、後ろに追加したルールが自動的に既存ルールを上書きすると考えたりしないでください。具体性は順序を決める際の重要な基準ですが、記述順を無視してよいわけではありません。残しておきたい完全一致の例外は、それに一致しうる広いルールより前に置きます。

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

api.example.comへアクセスする場合は、1行目で結果が決まり、2行目には進みません。www.example.comでは1行目に一致せず、2行目が処理します。列挙されていないほかのドメインは、最後の行に進みます。このような動作は、実際に接続する前に推論できます。机上で特定のルールに適用される機会がないと分かった場合は、原因を探すためにネットワークを何度も切り替える必要はありません。

使用場面1：指定したサイトだけをプロキシ経由にする

一部のサイトだけをプロキシ経由にする場合は、まず完全一致またはサフィックスで対象を指定し、その後にFINAL,DIRECTを選びます。最初から地域、キーワード、アドレス範囲のルールを大量に追加すると、もともと単純だった目的が異なる範囲のルールに左右されます。サイトが複数のドメインに依存する場合は、リクエスト記録を確認して段階的に追加してください。ページ名だけからインフラ全体を推測したり、広すぎる共通文字列をサービス全体の範囲として使ったりしないようにします。

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

この最小例は構成を説明するもので、実際のすべてのWebサイトがサフィックス1つだけで処理できることを意味しません。ルールを追加するときは、追加するホストがAPIや静的リソースなど何を担うかを記録し、その範囲に経路を変えたくないリクエストが含まれないか確認してください。使用場面の詳しい説明は指定したサイトだけをプロキシ経由にするルール設定をご覧ください。その後、このページに戻って順序を確認してください。

使用場面2：既定はプロキシ、一部を明示的に直接接続

別の構成では、明確な直接接続条件を先に記述し、残りのリクエストをFINAL,PROXYで処理します。この場合、広範なDIRECTルールを追加すると、既定のプロキシ経路から外れる通信が増えます。変更前に、例外の根拠がドメイン、ネットワークアドレス、地域分類のどれなのか確認してください。根拠に応じて適切なルールを使い、ドメインと無関係な条件を、手軽だからという理由でサフィックスで表現しないようにします。

[Rule]
DOMAIN,api.example.com,DIRECT
IP-CIDR,192.0.2.10/32,DIRECT,no-resolve
FINAL,PROXY

この例にある2つの例外は、ホスト名とアドレスにそれぞれ基づいており、互いの代わりにはなりません。1つ目の条件が使えるかどうかは、リクエストにドメイン情報があるかに左右されます。2つ目はアドレスを対象とし、no-resolveを指定しています。実際に調べるときは、最終結果がどちらもDIRECTだからといってまとめず、どのルールに一致したかを記録してください。照合条件を残しておくと、アドレスやリクエスト形式が変わった後の差も説明しやすくなります。

競合の調査と段階的なメンテナンス

ルールの競合が見つかったら、想定しているルールより前に一致する可能性のある項目を探します。キーワード、地域、広範なアドレス範囲も対象です。同じ完全なドメイン名だけを検索しないでください。ドメイン名を文字列として含まないGEOIPルールが先に処理する場合もあります。原因が分かったら、同じ内容を別の場所に重複して追加するのではなく、完全一致の例外を前に移動するか、広いルールの範囲を狭めてください。

変更後は、想定どおり一致するケースと一致しないケースを両方テストしてください。前者で対象リクエストが意図したポリシーに進むことを確認し、後者で範囲が意図せず広がっていないことを確認します。前者だけをテストすると、広いルールによる誤一致を長期間見逃すことがあります。テスト時のモード、設定名、操作順序を記録し、別の環境で得た結果を混同しないようにします。機密性の高いアドレスや完全な認証情報は記録せず、照合条件とポリシーの結果を残せば十分です。

冗長なルールを削除するときも、順序を確認してください。同じ内容のルールが2つある場合は通常どちらか一方で十分ですが、似た条件でも対象が異なることがあります。目的を記録してから1つずつ削除し、各段階で主な操作を再テストしてください。ルールの整理とサブスクリプション更新、サーバー変更を同時に行わないようにします。変更を分ければ、どの段階まで戻せば元の動作に復元するか明確になります。

Hostは名前とアドレスの対応を変更するもので、ポリシーを直接選択しない

[Host]はホスト名のマッピングに使います。名前に対応するアドレスを指定する機能であり、そのホストにPROXYまたはDIRECTを直接指定するものではありません。マッピング後も、リクエストの経路は現在の処理方法によって決まります。指定したアドレスに名前解決できても、振り分けポリシーが正しいとは限りません。ポリシーが正しくても、マッピング先が現在のサービスに有効な接続先とは限りません。

[Host]
example.com = 192.0.2.10
api.example.com = 192.0.2.11

ここに示すアドレスは説明用です。実際に設定する前に、自分が管理するサービスでそのマッピングが必要か確認し、接続先アドレスの管理方法も把握してください。DNSで一度確認したアドレスを、長期的に変わらない接続先とみなさないでください。動的に接続先を選ぶサービスでは、固定マッピングが通常の振り分けを回避してしまい、ネットワーク変更やサービス移行後に断続的な失敗を招くことがあります。プロキシが不安定に見えても、実際にはマッピングが古くなっているだけかもしれません。

ドメインを別のアドレスに割り当てても、そのアドレス上のサービスに正しい証明書、仮想ホスト設定、アクセス権が自動的に備わるわけではありません。暗号化されたサイトでは、ホスト名と証明書の検証も重要です。ホスト名や証明書のエラーが発生したら、サービスとマッピングの対応を確認し、検証を緩めて問題を覆い隠さないでください。Hostは接続先が分かっている場合の設定に適しており、未知のサービスの接続先を推測するためのものではありません。

URL RewriteはリクエストURLを処理するもので、プロキシ設定の代わりではない

[URL Rewrite]では、条件に一致するURLの書き換えやリダイレクトを指定します。照合対象にホスト名だけでなくURLの構造も含む点で、DOMAINなどのルールとは異なります。追加する前に、アクセス先を変更したいのか、通信経路だけを変えたいのかを確認してください。後者はポリシーと振り分けで設定するもので、プロキシ経由にするためにサイトのURLを書き換える必要はありません。

[URL Rewrite]
^http://example\.com/(.*)$ https://example.com/$1 302

この例では、指定したホストのHTTP URLを対応するHTTPS URLへリダイレクトし、一時的なリダイレクトを表す302を使います。正規表現内のピリオドはエスケープして、任意の文字をドメイン区切りとして誤認しないようにします。先頭と末尾の境界で照合範囲を限定し、括弧でパスをキャプチャします。置換先の$1はそのキャプチャ結果を参照します。正規表現をコピーするときは、バックスラッシュと半角記号をそのまま保ち、テキストエディターによる全角文字への置換に注意してください。

リクエストURLを確認・処理できるかどうかは、プロトコルとアプリ内の対応機能によって異なります。HTTPSの正規表現を設定しただけで、暗号化されたすべてのリクエストの完全なURLを読み取れるとは限りません。通常の転送で暗号化された内容を取得できるわけではありません。このページの例では、証明書の信頼設定を変更して書き換えを行うことはしません。書き換えを学ぶ際は、自分で管理でき、条件が明確なリクエストを使い、見知らぬサイトに処理範囲を広げないでください。

ループ、広すぎる範囲、認証情報の拡散を防ぐ

リダイレクト後のURLが同じ条件に再び一致すると、ループする可能性があります。入力と出力を並べて確認し、プロトコル、ホスト、パスのいずれかが変わって新しいリクエストが元の照合範囲から外れることを確かめてください。連続リダイレクトは対象サイトの応答が原因の場合もあり、ブラウザーの警告だけでローカルルールのループとは断定できません。まずローカルの書き換えを無効にして比較し、元のサービスが引き続きリダイレクトするか確認してください。

置換先によって、リクエストに含まれる情報の送信先が変わる可能性があります。クエリパラメーターを含む完全なURLを、安易に別のホストへ書き換えないでください。ログイン状態、一時的なパラメーター、アプリ内の遷移は、ホスト名に依存する場合があります。テストには実際の認証情報を含まない例を使い、パスやクエリが想定どおり保持されるか確認してください。正規表現への一致は、テキスト上の条件を満たすことを示すだけで、サービスの処理が正常に機能する保証ではありません。

HostとURL Rewriteは別々に確認してください。まずマッピングだけを有効にして、名前の対応とアクセスを確認します。次に書き換えを1つ追加し、想定したリダイレクトが発生するか観察してください。両方を同時に変更すると、誤ったアドレスが原因なのか新しいURLが原因なのか分かりにくくなります。元に戻すときは今回追加した項目を取り消してからリクエストを再発行し、以前の接続やキャッシュされたリダイレクトが判断に影響しないようにします。

画面の結果から推測せず、実際のリクエストをルールまでたどる

振り分けを確認するときは、リクエストが新たに発生したか、どの条件に一致したか、最終的にどのポリシーが使われたかの3点を確認します。ページが開くのは最終的な結果にすぎず、最初の2点を単独では判断できません。反対に、ページの表示に失敗しても、ルールが正しい経路を選んだ後で問題が発生した可能性があります。アプリ内で確認できる接続記録と診断情報を参考に、対象ホストと関連ルールを記録してください。すべての失敗をルールの不具合として扱わないようにします。

まず基本的なネットワーク接続を確認し、次にGlobal Routingと選択中の設定名、保存と読み込みの状態を確認します。その後、対象のリクエストを新たに発生させ、ルールを上から順に確認して最初に一致した条件を特定します。ポリシーが意図どおりだと確認してから、サーバーへの接続性、プロトコルパラメーター、対象サービスの状態を調べてください。この順序なら無駄な変更を減らし、サーバーの問題を大量の恒久的なDIRECT例外に置き換えることも避けられます。

Connectivity Testと実際のサービス利用で確認できる内容は異なる

Connectivity Testの結果は、アプリ内で選択したテスト方法と合わせて解釈してください。接続確認の参考にはなりますが、実際のサービスが使うすべてのドメイン、パス、プロトコル条件を網羅するわけではありません。テストが成功しても実際の対象へアクセスして確認してください。失敗した場合も、テスト対象が現在の環境に合っているか確認します。1つの表示結果から経路全体の状態を断定したり、テスト数値をルール一致の証拠として扱ったりしないでください。

サーバーがタイムアウトする場合は、アドレス、ポート、認証項目、プロトコル関連パラメーターが利用者自身の情報と一致するかを優先して確認してください。TLSを使う場合は、ホスト名やシステム時刻などの条件にも注意します。パラメーターの誤りをドメインルールの変更で覆い隠さないでください。手順に沿って調べる場合はサーバーのタイムアウト確認手順をご覧ください。よくある接続の問題は接続トラブルのQ&Aにまとめています。

例外を積み重ねるより、最小構成で再現する

複雑な設定の原因が分からない場合は、複製したファイルに対象を明確にしたルール1つとFINALだけを残します。関係のないマッピングや書き換えを一時的に外し、同じ操作でテストしてください。最小構成で想定どおりに動作したら、元のルールをグループごとに戻し、結果が変わる箇所を特定します。この一時的な簡略化は原因調査のためのものであり、長期利用する設定を確認なしに置き換えるものではありません。元に戻した後は、ほかの機能も再テストしてください。

テスト中は、ネットワーク、サーバーの選択、アクセス操作をできるだけ一定に保ちます。ネットワークを変えると名前解決や接続条件が変わり、サーバーを変えるとプロキシ経路が変わり、サブスクリプションを更新すると項目のパラメーターが変わることがあります。これらを同時に変更すると、成功・失敗の原因を判断できません。ネットワークを切り替えて比較する場合は、切り替え前後の条件を記録し、ルール変更と同じテストに含めないようにします。

更新、復元、安全な情報共有

設定を管理する際は、動作する基準を残してください。大きな変更を行う前にファイルを複製し、変更の目的、対象のセクション、期待する動作を記録します。変更後は、同じ主要操作で再確認してください。サブスクリプションの読み込みと更新の詳細はサブスクリプションの読み込みと更新方法をご覧ください。更新後に違いが生じた場合は、まず内容を比較し、サーバー情報とルールファイルのどちらが変わったのか確認してから、戻す対象を決めます。

ほかの人に問題を伝える際は、必要最小限の設定例、モード、一致結果だけを共有してください。サブスクリプションの完全なURL、認証項目、実際のサーバー情報、個人のアクセス状況が分かる可能性のある記録は削除します。設定ファイルにはルール以外の機密情報が含まれる場合もあります。コードの一部にドメインしか見えないからといって、ファイル全体をそのまま共有しないでください。結果を見せるときも、記録に個人情報が含まれていないか確認してください。

元のファイルに戻した後も、選択されているかどうかを改めて確認してください。複製の名前を元に戻しただけで、復元が完了したとは限りません。再読み込みしてリクエストを新たに発生させ、対象ドメイン、反例、フォールバックの3つを確認します。古い接続だけに問題が残る場合は、いったん終了してからテストしてください。新しいリクエストでも問題が続く場合は、モード、ルール、ポリシー、接続経路の順に調べ、同じルールの構文だけを何度も書き換えないようにします。