CONFIGURATION REFERENCE

Shadowrocket
ルール・設定ガイド

このページでは、Shadowrocketの公式マニュアルのうち、ファイル構成、判定条件、実行ポリシーに沿って設定方法を解説します。初めて接続する場合は、まずはじめにを確認してから、必要な項目をこのページで見直してください。接続できている場合は、目次から該当する項目に進めます。

01 / FILE STRUCTURE

設定ファイルの構成と適用場所

設定ファイルとサーバー情報は別々に管理

Shadowrocketでは、サーバー情報と設定ファイルはそれぞれ異なる役割を担います。サーバー情報には接続先、ポート、プロトコル、認証パラメータを保存します。設定ファイルには、リクエストの判定方法、適用するポリシー、名前解決やリクエスト処理の設定を記述します。このマニュアルは、利用者が自分のサブスクリプションまたはサーバー情報を用意していることを前提としています。サーバーをインポートして選択できても、ルールが有効になったとは限りません。反対に、ルールを保存できても、PROXYの接続先が利用可能とは限りません。

編集を始める前に、Homeで選択中のサーバー、Configで使用中の設定ファイル、Global Routingの状態を確認してください。ファイル内のルールを確認する場合は、Configの設定状態が基本の入口です。ProxyとDirectは全体のルーティング状態を切り替えるもので、そのテスト結果だけでは特定のドメインルールが正しいか判断できません。サーバー、ファイル、全体のルーティング状態をそれぞれ記録し、一つを変更しただけで他も連動して変わったと思い込まないようにしましょう。

セクション見出しごとにファイルを読む

設定ファイルはセクションに分かれたテキスト形式です。角括弧で囲まれた見出しが、その後の内容の所属先を示します。[General]には全体設定、[Rule]には判定条件とポリシーを行ごとに記述します。[Host]にはドメインの静的マッピング、[URL Rewrite]には条件に応じたURL処理を記述します。セクション見出し自体はルールではなく、リクエストの判定にも使われません。[General]の下にDOMAIN-SUFFIXを書いても、キーワードが正しいだけで有効な振り分けルールにはなりません。

sample.conf · 構成確認用の最小例
  1. [General]
  2. bypass-system = true
  3. dns-server = system
  4. [Rule]
  5. DOMAIN-SUFFIX,example.com,PROXY
  6. FINAL,DIRECT

この例が示すルーティングの意図は2つだけです。example.comとそのサブドメインにはPROXYを適用し、それ以外はDIRECTにします。サーバーの認証情報は含まず、接続サービスも提供しません。例示用のドメインなので、特定のサービスにアクセスできることを保証するものではありません。ファイル全体を読むときは、まずすべてのセクション見出しを確認し、次に[Rule]内のFINALを探してください。先頭から特定のドメインを探すだけでは、記述されているセクションを見落とすことがあります。

カンマ、イコール、コメントの使い分け

[General]では、dns-server = systemのようにキー、イコール、値を記述します。[Rule]では通常、DOMAIN,example.com,DIRECTのように種類、判定対象、ポリシーを半角カンマで区切ります。この2つの書式は互換ではありません。編集時は半角の記号を使い、日本語入力によってカンマが全角に置き換わらないよう注意してください。コメントは単独の行に#を付けて記述し、目的をメモできます。ルールの行末に説明を付けるより、コメントを別の行に置くほうが項目の区切りを確認しやすく、コピーもしやすくなります。

すべての設定ファイルに4つのセクションが必要なわけではありません。静的マッピングがなければ[Host]は省略できます。URL処理が不要なら[URL Rewrite]も追加する必要はありません。必要最小限の設定から始め、用途が明確な項目を一つずつ追加すると、複数のファイルの内容をまとめて貼り合わせるより検証しやすくなります。セクションやパラメータが重複している場合は、重複項目の上書き動作に頼らず、定義を一つに整理してください。構成を大きく整理する前に、元のファイルを複製しておきましょう。

02 / GENERAL & DNS

GeneralのパラメータとDNS設定

ネットワークの範囲を確認してから、バイパス範囲を設定

[General]のパラメータは、後続ルールが動作する環境に影響します。bypass-system = trueはシステム関連の通信をバイパスする設定で、AppleのドメインすべてにDIRECTを指定するものでも、[Rule]の代わりになる汎用ルールでもありません。skip-proxyは、プロキシ処理をスキップするアドレス範囲を指定します。ルール判定に入る前にリクエストがバイパスされている場合、後からPROXYルールを変更しても想定した結果にならないことがあります。トラブルシューティングでは、ルールの行を移動するだけでなく、全体のバイパス設定と[Rule]の両方を確認してください。

LAN内の機器では、実際のアドレス設計に合わせてバイパス範囲を選びます。192.168.0.0/16と10.0.0.0/8はプライベートアドレス範囲の例であり、現在のネットワークで必ず使われているとは限りません。まず機器のネットワーク情報と接続先サービスのアドレスを確認し、そのうえで範囲を設定してください。範囲が広すぎると、プロキシ経由でアクセスする必要がある内部の接続先まで除外されることがあります。狭すぎると、プリンターやストレージなどへのローカルアクセスが適切でない経路を通る場合があります。

[General]
bypass-system = true
skip-proxy = 192.168.0.0/16, 10.0.0.0/8
dns-server = system

DNSの名前解決とルーティングポリシーは別のもの

dns-server = systemはシステムのDNS設定を使う指定で、基準となる設定として便利です。DNSはドメイン名をIPアドレスに変換し、ルーティングルールはリクエストに適用するポリシーを決めます。ドメイン名を解決できても、選択中のサーバーからそのアドレスへ接続できるとは限りません。リクエストがDIRECTに一致しても、DNSクエリが想定どおりの経路を使うとは限りません。接続タイムアウトをすべてDNSの問題と考えないよう、名前解決の結果、ルールの一致、最終的な接続をそれぞれ確認してください。

DNSを変更する前に、解決したい問題を明確にしてください。ドメイン名を解決できないのか、結果が想定と異なるのか、解決後に接続できないのかを切り分けます。特定の接続先だけで問題が起きる場合は、その接続先と[Host]のマッピングを確認し、すぐにファイル全体のDNS設定を置き換えないでください。複数のドメインを解決できない場合は、現在のネットワークでシステムDNSが使えるか確認します。暗号化DNSのアドレス、名前解決のための接続、実際の接続経路には相互依存がある場合があり、アドレスの形式だけで現在のネットワークに適した設定かどうかは判断できません。

変更が必要か判断する前に、まず各パラメータの役割を確認します。
パラメータ主な役割確認ポイント
bypass-systemシステム関連の通信をバイパスドメインの許可リストとして使わない
skip-proxy指定したアドレス範囲をバイパス対象アドレスが範囲に含まれるか
dns-serverDNS設定を指定名前解決サービスに接続できるか

ルールで名前解決が発生するかは判定条件による

DOMAIN系ルールは主にドメイン名を基準に判定します。IP-CIDRとGEOIPには、判定に使える接続先アドレスが必要です。ドメイン名で開始したリクエストでは、アドレス系ルールの判定に名前解決が関係する場合があります。IP-CIDRにno-resolveを付けると、そのアドレスルールのために追加でドメインを解決しないようにできます。クライアント全体のDNSを無効にする設定ではありません。アドレスを指定した接続や、特定のアドレスルールによる名前解決を避けたい場合に使えますが、アドレスがまだ得られていないドメインのリクエストはそのルールに一致しないことがあります。

アプリやシステムが名前解決の結果をキャッシュしている場合や、ウェブ接続が既存のセッションを再利用する場合があります。DNSを変更した後に同じページを再読み込みしても、新しい名前解決が行われたとは限りません。確認するには新しい接続を開始し、必要に応じてShadowrocketを再接続して、ログの時刻と接続先を確認してください。比較用としてdns-server = systemの動作する設定を残し、名前解決に関するパラメータを一度に一つだけ変更すると、新しい設定の影響と古いキャッシュによる見かけの変化を区別できます。

Wi-Fiとモバイル通信を切り替えた後だけ問題が起きる場合は、それぞれのネットワークでの状況を記録してください。システムDNS、ローカルアドレス範囲、サーバーへの接続可否はネットワークによって変わることがあります。この場合、skip-proxyの範囲を広げて問題を隠したり、DNSパラメータを重ねて追加したりしないでください。まず動作する基本設定に戻してネットワーク間の違いを確認し、よくある質問とトラブルシューティングの接続確認も参照してください。長期的に変更が必要とわかってから、普段使う設定ファイルにパラメータを記述します。

03 / DOMAIN MATCHING

DOMAIN系ルールの適用範囲

DOMAINは指定したドメイン名だけに一致

DOMAINはドメイン名を完全一致で判定します。DOMAIN,api.example.com,PROXYはapi.example.comに適用されますが、example.comは含まれず、ドメイン名に同じ文字列を含むotherexample.comにも一致しません。ルールの判定欄にはホスト名を記述し、プロトコル、パス、ポート、クエリパラメータは含めません。DOMAINの判定欄にウェブページの完全なURLを貼り付けると、URLとドメイン名を混同することになります。パスに応じた処理が必要なら、ドメインルールを広げるのではなく、URL処理に該当するか確認してください。

完全一致ルールは、特定のサービス接続先に例外を設定する場合に便利です。たとえばexample.com全体にはPROXYを適用し、status.example.comだけDIRECTにできます。この例外は、より広いDOMAIN-SUFFIXより前に記述してください。サフィックスルールが先に一致すると、後続の完全一致ルールは判定されません。優先順位は行の順序で決まり、DOMAINのほうがDOMAIN-SUFFIXより具体的に見えるからではありません。クライアントがファイル内のルールを自動で具体性の高い順に並べ替えることはありません。

DOMAIN-SUFFIXはドメイン階層の境界で判定

DOMAIN-SUFFIX,example.com,PROXYはexample.comとそのサブドメインに一致します。たとえばwww.example.comやa.b.example.comが対象です。サフィックス判定はドメイン階層の境界に基づくため、文字列を含むだけのotherexample.comはサブドメインではありません。通常、サフィックスの前にドットを付けたり、アスタリスクを書いたりする必要はありません。*.example.comを通常のサフィックス例としてコピーすると、該当するルール構文にはないワイルドカードの考え方を持ち込むことになります。

[Rule]
# 完全一致の例外を先に
DOMAIN,status.example.com,DIRECT
# 親ドメインとサブドメインは後に
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT

ひとつのウェブページが、ページ本体、画像、認証、APIで別々のドメインにリクエストを送ることがあります。アドレスバーに表示されたドメインだけにルールを設定しても、依存先すべてに同じポリシーが適用されるわけではありません。まず接続ログから実際にリクエストされたホスト名を特定し、複数のDOMAINを使うか、適切な範囲をカバーするDOMAIN-SUFFIXを使うか判断してください。無関係な接続先を短いキーワード一つにまとめると、ひとつのページの調査によって別のアプリの通信経路まで変わることがあります。

DOMAIN-KEYWORDは文字列の部分一致

DOMAIN-KEYWORD,example,PROXYは、ドメイン名にexampleという文字列が含まれるかどうかで判定するため、example.comよりも広い範囲に一致する可能性があります。同じ登録ドメインの階層でなくても、この文字列を含む別のドメインに一致します。キーワードルールは、対象範囲が明確で、文字列による広い一致が本当に必要な場合に使います。特定の親ドメインとそのサブドメインだけを対象にするなら、DOMAIN-SUFFIXを優先してください。キーワードが短いほど、意図しない一致がないか慎重に確認してください。

種類判定対象選び方
DOMAIN指定したホスト名特定の接続先や個別の例外
DOMAIN-SUFFIX親ドメインとサブドメイン同じドメイン階層のサービス
DOMAIN-KEYWORDドメイン名に含まれる文字列文字列による広い一致が必要な場合

検証できる条件としてルールの意図を記述

ドメインルールを追加する前に、「status.example.comだけを直接接続する」のように適用範囲を一文で表し、実際の設定項目と照らし合わせてください。「すべてのサブドメイン」が対象なら、サフィックスルールが適切か確認します。「特定のディレクトリのパス」が条件なら、ドメインルールだけでは要件を表現できません。国際化ドメイン名は、接続ログに実際に表示されるホスト名を確認し、表示名と設定ファイル内の表記が一致しているか確かめてください。ウェブページのタイトルやアプリ名からドメインを推測しないでください。

テストでは、一致させたい接続先と、一致してはいけない接続先の両方にアクセスして、正反2種類の結果を確認します。ページが開いたかどうかだけでなく、ホスト名、一致したルール、適用されたポリシーを記録してください。ページが開いてもDIRECTで接続できているだけかもしれず、PROXYルールが機能した証拠にはなりません。ページが開かない原因も、サーバーや接続先サービスにある場合があります。変更後に無関係なリクエストまでPROXYに入る場合は、同じ種類のルールを末尾に追加し続けず、キーワードの範囲を絞ってから行の順序を確認してください。

04 / ADDRESS & REQUEST

GEOIP、IP-CIDR、USER-AGENT

IP-CIDRはアドレスとプレフィックスで判定

IP-CIDRは、IP-CIDR,192.168.0.0/16,DIRECTのようにIPv4アドレスの範囲を指定します。スラッシュの後の数字はプレフィックス長であり、ポート番号や対象アドレス数ではありません。数字が大きいほど範囲は狭くなります。単一のIPv4アドレスは/32で指定できます。ネットワーク範囲のルールを編集するときは、対象の実際のアドレスとネットワーク範囲の境界を照らし合わせてください。アドレスの先頭が似ているというだけでは、その範囲に含まれるとは限りません。プレフィックスを誤ると、無関係な多数のリクエストが同じポリシーの対象になることがあります。

LAN内の範囲は、[General]のskip-proxyとあわせて確認してください。ある範囲がすでに全体設定でバイパスされている場合、[Rule]に同じ範囲のDIRECTを記述しても重複するだけで、ルールエンジンがその行に一致した証拠にはならないことがあります。特定のルールの動作を確認する場合は、まずリクエストがルール判定に入っているかを明確にしてください。普段使う設定に必要な直接接続ルールを残す場合は、用途をコメントに記述しましょう。項目を重複させても優先順位は上がりません。

[Rule]
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
IP-CIDR6,fc00::/7,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

IP-CIDR6とno-resolveの範囲

IP-CIDR6はIPv6アドレス範囲を指定するためのルールです。IPv6アドレスをIP-CIDRにそのまま記述しても、同じように処理されるとは限りません。fc00::/7はローカルIPv6範囲の例であり、すべてのIPv6リクエストをDIRECTにすべきという意味ではありません。ドメイン名からIPv4とIPv6の両方が返される場合があるため、どちらか一方のアドレスだけを見ると実際の接続経路を見落とすことがあります。「同じドメインなのに一致したりしなかったりする」場合は、まずリクエストで使われたアドレスの種類を確認し、必要に応じて該当するルールを追加してください。

no-resolveはアドレスルールに追加するパラメータで、そのルールの判定のためにドメイン名を積極的に解決しないようにします。アドレスを指定して開始したリクエストは、すでにあるアドレスを使って判定できます。一方、判定に使えるアドレスがまだないドメイン名のリクエストは、この行に一致しないことがあります。構文の誤りではなく、利用条件の違いです。名前解決を短縮する目的で、すべてのアドレスルールに機械的にno-resolveを付けないでください。また、強制的に直接接続したり、リモートDNSを使ったりするポリシーではありません。

GEOIPはドメインの所属地域を判定するものではない

GEOIP,CN,DIRECTは、ドメインの末尾、ウェブページの言語、サービスのブランドではなく、接続先IPアドレスの地域分類に基づいて判定します。同じドメインでも異なる地域のアドレスに解決される場合があり、アドレスデータベースの分類がリアルタイムの通信品質を示すわけでもありません。特定のドメインに安定したポリシーを適用したい場合は、まずDOMAINまたはDOMAIN-SUFFIXで明示し、残りの通信を処理するためにGEOIPを後ろに配置してください。そうしないと、アドレスの変化によって同じサービスでもネットワークごとに異なるポリシーが適用されることがあります。

USER-AGENTはリクエストから見える項目を使って判定

USER-AGENTは、HTTPリクエストから確認できるUser-Agentの内容に一致させるルールです。アプリの表示名からプロセスを識別するものではありません。USER-AGENT,ExampleClient*,DIRECTという例は前方一致を意図していますが、該当するリクエスト項目を参照できる場合に限り判定できます。通常の暗号化通信では、HTTPリクエストヘッダーをそのまま確認できないことがあります。アプリが実際にこの項目を送信していても、クライアントがルール判定に利用できるとは限りません。すべてのアプリの通信を振り分ける汎用的な代替手段には適していません。

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

USER-AGENTを機能させるためにリクエストの復号を有効にすると、追加の信頼設定や互換性の確認が必要になります。初めて通信を振り分ける際に必須の手順ではありません。ドメインルールで要件を表現できるなら、まずドメインルールを使ってください。アドレスルールとリクエスト条件ルールのどちらも、判定できるアドレスが存在するか、リクエスト項目が見えるか、前のルールにすでに一致していないかを確認する必要があります。これらを一つずつ確認するほうが、ルールをファイルの下から上へ移動するだけより確実です。

05 / POLICY & PRIORITY

PROXY、DIRECT、REJECTと判定順

ポリシーはルール一致後の処理を指定

ルールの種類は何を判定するかを決め、ポリシーは一致後の処理を決めます。PROXYはリクエストをプロキシ経由にします。シンプルな設定では通常、現在選択中のサーバーが使われます。設定ファイルにポリシーグループなどの関連設定がある場合は、実際に選択されている接続先も確認してください。DIRECTはプロキシサーバーを経由せず、接続先に直接接続します。ただし、通信は現在のネットワーク、DNS、接続先サービスの状態に左右されます。REJECTは一致したリクエストを拒否する指定であり、接続失敗時に自動で切り替える予備ポリシーではありません。

設定内のPROXY、DIRECT、REJECTはポリシーを表すキーワードです。一方、Homeでのサーバー選択とGlobal RoutingのProxy、Directは画面上の状態です。大文字・小文字も使う場所も異なり、同じ概念として扱うことはできません。ルールをPROXYに変更しても、サーバーのパスワード、ポート、プロトコル設定は修正されません。PROXYに一致したリクエストがすべて失敗する場合は、各ルールをDIRECTに置き換えて解決したと判断するのではなく、まずプロキシ経路を確認してください。

Global Routingの3つの状態

ファイル内のルールをテストするときは、まずConfigの設定状態になっているか確認してください。
状態画面上の表示確認する内容
設定Config現在の設定ルールに基づく振り分け
プロキシProxyプロキシ接続経路の確認
直接接続Direct直接接続経路の確認

この表はテスト時の状態を整理するためのものであり、システムのバイパス設定などを無視して、どのような場合もすべての通信が処理されることを示すものではありません。診断のためにProxyまたはDirectを一時的に使い、接続経路を比較することはできます。確認後はConfigに戻し、現在のファイルでルールの一致を確認してください。「ファイルを変更したのに変化がない」原因が、全体プロキシまたは全体直接接続のままになっていることもあります。結果を記録するときは、状態と接続先をあわせて記録し、同じ接続先でもルーティング条件によって結果が異なることを区別してください。

最初に一致したルールで確定し、後続には進まない

[Rule]は上から順に判定され、最初に条件に一致したルールでポリシーが決まります。具体的なルールを汎用的なルールより前に置くのは、ルールを整理するための原則です。クライアントが自動で並べ替えるアルゴリズムではありません。前のDOMAIN-KEYWORDがドメインに一致した場合、後のDOMAINがより具体的でも上書きできません。同じ条件が重複していると、後の項目は通常、到達しない重複ルールになります。後から書いた内容が前の設定を自動で置き換えると期待せず、整理してください。

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

この例では、status.example.comは最初の行に一致するため、後続のサフィックスルールは判定されません。blocked.example.comにはREJECT、その他のexample.comのサブドメインにはPROXYが適用されます。それ以外のリクエストはGEOIPで判定され、最後にFINALで処理されます。PROXYに一致した後に接続が失敗しても、後続のDIRECTを探しに進むことはありません。ルールの判定と接続処理は別の段階です。接続結果によって、すでに確定した最初の一致ルールが変わることはありません。

FINALは明確なデフォルト方針を示す

FINALには判定欄が不要で、FINAL,PROXYまたはFINAL,DIRECTと記述します。前のルールに一致しなかったリクエストを処理するため、[Rule]の最後に配置してください。FINALの後ろにあるルールは、残りのリクエストを処理できません。デフォルトのポリシーを選ぶ前に、「個別に指定していない接続先をどこに振り分けるか」を決めてください。コピーしたファイルのデフォルト設定を理由なくそのまま使わないようにしましょう。FINALを2つ記述しても優先・予備経路にはならず、2つ目は障害時の切り替えには使われません。

REJECTを追加する場合は、対象をできるだけ限定し、単独でテストしてください。ひとつのページで、統計情報、画像、認証、サービスAPIが同じドメインを共有することがあります。範囲が広すぎると、ページは開いても機能に問題が出る場合があります。本当に拒否が必要か、ドメインを限定して表現できるかを確認し、関連するリクエストも確認してください。元に戻す場合は、自分で追加した拒否ルールを削除または無効にして、新しい接続を開始します。先に一致したREJECTを、後ろに追加したDIRECTで打ち消すことはできません。

06 / HOST & URL REWRITE

HostマッピングとURL Rewriteの役割

Hostはアドレスの対応付けを変更し、ポリシーは決定しない

[Host]では、lab.example.com = 192.168.1.20のように、ドメイン名とアドレスの静的な対応を指定します。「このドメイン名にどのアドレスを割り当てるか」を設定するもので、「リクエストをプロキシ接続にするか直接接続にするか」を決めるものではありません。このマッピングを使う場合も、ドメイン名または接続先アドレスに対する[Rule]の処理を確認してください。この例は、利用者が管理するローカルサービスの説明用です。指定したアドレスが想定する接続先に対応していると確認できた場合にのみ使用し、例示用のアドレスを実際のウェブサイトへの接続に使わないでください。

[Host]
lab.example.com = 192.168.1.20

[Rule]
DOMAIN,lab.example.com,DIRECT
FINAL,PROXY

静的マッピングを使うと名前解決の結果が固定されるため、接続先アドレスが変わったら設定も更新する必要があります。元のサービスが複数のアドレスに振り分けて負荷を分散している場合、ひとつのアドレスに固定すると通常の振り分けを妨げることがあります。変更前の名前解決結果を記録し、ドメイン名、アドレス、利用目的が一致しているか確認してください。ある端末で接続できても、ほかのネットワークに適した設定とは限りません。たとえば、対応するWi-Fiから離れるとローカルアドレスに接続できないことがあります。その場合はネットワークの範囲を確認し、同じマッピングで接続を繰り返さないでください。

マッピングは証明書やサービスの識別情報を代替しない

HTTPSサービスにドメイン名でアクセスする場合、接続先のアドレスと証明書に対応するドメイン名は別の条件です。[Host]でアドレスを変更しても、サービスの証明書が任意のドメイン名に対応するようになるわけではなく、サーバー側のドメイン名設定も修正されません。証明書エラーが発生した場合は、そのドメイン名に対してサービスが正しい証明書を提供しているか確認してください。静的マッピングで検証を回避することはできません。マッピングを元に戻して接続し直すと、元からあるサービスの問題と、追加したアドレス固定の影響を区別しやすくなります。

URL Rewriteは正規表現で対象を指定

[URL Rewrite]にはURLの判定式と対応する処理を記述します。次の例では、特定のパスを別のパスにリダイレクトします。302は一時的なリダイレクト応答を表します。これはプロキシポリシーではなく、PROXYを自動でDIRECTに切り替えるものでもありません。ルール内のexample.comは説明用の文字列で、外部サービスの接続先ではありません。使う前に処理が現在のリクエスト環境に適しているか確認し、まず具体的なパスで検証してください。ドメイン全体のすべてのパスに一致するような広い式は避けてください。

[URL Rewrite]
^http://example\.com/legacy$ http://example.com/current 302

式内の^は先頭、$は末尾を示します。ドメイン名のドットを\.と書くことで、正規表現で任意の1文字として解釈されるのを防ぎます。この例は、/legacyで終わり、クエリパラメータが付いていない完全なURLだけに一致します。/legacy/やクエリパラメータ付きのリクエストは同じ条件に一致しません。パスやパラメータを引き継ぐ必要がある場合は、拡張する前にキャプチャグループと置換の関係を確認してください。.*を安易に使って、すべての内容を一致範囲に含めないようにしましょう。

HTTPSで見える情報の範囲を先に確認

通常のHTTPS接続では、HTTPの完全なURLパスを直接確認できません。このようなリクエストにパス単位の書き換えを適用するには、通常、追加のリクエスト復号設定と証明書の信頼設定が関係します。[URL Rewrite]を追加しただけでパスが見えるようになるわけではありません。アプリによっては追加の証明書検証を行うため、関連機能を有効にすると互換性に影響することがあります。明確な要件がなければ、標準の接続動作を維持してください。ドメイン単位の振り分けに、パス書き換えのための復号設定を追加する必要はありません。

リダイレクトによって新しい接続先が生成されるため、新しいリクエストについてもルーティングとサービス条件を再確認する必要があります。別の書き換えルールによって接続先が元のパスに戻ると、ループになる場合があります。検証時には、元のURL、一致した式、リダイレクト先、最終的な接続先を記録してください。ブラウザーに最後に表示されたページだけを確認するのでは不十分です。まずほかの書き換えルールを無効にして一つずつテストし、その後で段階的に戻すと、ルール同士の影響と接続先サービスのリダイレクトを切り分けられます。リダイレクトが続く場合は、正規表現の範囲を広げず、まず書き換え設定を元に戻してください。

07 / EDITING WORKFLOW

設定の編集手順とルールの書き方

現在のファイルを複製し、変更を最小限にする

編集前に、現在使えている設定を保存し、用途が区別できる名前で元のファイルとテスト用ファイルを分けてください。変更する接続先、判定範囲、適用したいポリシーを明確にしてから、Configで対象のファイルを開いて編集します。保存後、テスト用のファイルが現在の設定になっていることを確認し、Global RoutingをConfigにして、対象のリクエストを新たに開始してください。サーバー、DNS、デフォルトポリシー、複数のルールを同時に変更すると、結果が変わった原因を特定できなくなります。

すでに利用しているサーバーのサブスクリプションとリモート設定では、更新方法が異なる場合があります。サーバー一覧を更新しても、ローカルのルールが更新されるとは限りません。リモート設定を再取得すると、そのファイルへのローカル変更が上書きされる場合があります。リモートの内容を編集する前に、保存と更新の方法を確認し、独自に追加したルールの意図を複製ファイルや別の記録に残してください。どの内容を自分で追加したのか、ファイル名だけで管理しないでください。ルールのグループごとに、用途がわかるコメントを付ける方法が確実です。

デフォルトは直接接続、指定したドメインだけプロキシ接続

明示したドメインをプロキシ経由にし、それ以外を直接接続する場合は、次の構成を使えます。DOMAIN-SUFFIXは例示した親ドメインとそのサブドメインに一致し、FINAL,DIRECTはそれ以外のリクエストを処理します。接続先を追加するときは、まず既存のサフィックスルールですでに対象になっているか確認してください。範囲内であれば、同じポリシーを重ねて追加する必要はありません。サービスが別のドメインに依存する場合は、より広いキーワードで推測するのではなく、実際の接続記録を確認して追加してください。

[General]
dns-server = system

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

デフォルトはプロキシ接続、特定の接続先は直接接続の例外に

別の要件として、個別に指定していないリクエストはプロキシ経由にし、LAN内や特定ドメインへの直接接続例外を設ける方法があります。FINAL,PROXYでは、残りのリクエストがプロキシ経路に依存するため、現在のサーバーが使えることを先に確認してください。アドレスの例外とドメインの例外は、それぞれ範囲を明確にして設定します。ひとつの内部ドメインに対応するために、すべてのプライベートアドレス以外へ範囲を広げないでください。普段使う設定に全体のバイパス設定がある場合は、関連パラメータを照らし合わせ、同じネットワーク範囲のルールを重ねて追加する必要があるか確認します。

[Rule]
DOMAIN,lab.example.com,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
FINAL,PROXY

この2つの構成は、どちらも固定の推奨設定ではなく、異なるデフォルト方針を表します。2つのFINALをそのまま混在させることはできません。統合する場合は、まず最終的なデフォルトポリシーを決め、必要な個別ルールをその前に配置してください。ひとつのドメインだけ変更したい場合は、設定全体のデフォルトポリシーまで変更しないでください。例外を検証する際は、対象が個別ルールに一致するか確認し、未指定の接続先がFINALに従うかも確認します。2つのテスト結果を照らし合わせてください。

設定ファイルを統合する際は、長さより先に競合を整理

保存済みの複数の設定ファイルからルールを整理する場合は、まず種類と判定範囲をもとに重複を確認してください。同じ条件に異なるポリシーが指定されている場合は、どちらが現在の意図に合うか決めます。完全一致ルールとサフィックスルールが重なる場合は、必要な例外の順序を維持してください。キーワードとサフィックスが重なる場合は、キーワードの範囲が広すぎないか確認します。ルールが多いほど判定が正確になるわけではありません。重複したルールや到達しないルールは、確認の手間を増やします。整理した後も、FINALは明確に一つだけにしてください。

設定ファイルを「個別の例外」「サービスのドメイン」「アドレス範囲」「デフォルトポリシー」の4グループに分けると、手作業で確認しやすくなります。ただし、必須の並び順ではありません。グループごとにコメントで目的を説明できますが、実際の優先順位は行番号で決まります。アドレスの例外を広いドメイン条件より優先する必要がある場合は、実際の要件に合わせて位置を調整してください。グループを整理するたびに同じ接続先で再テストし、結果を記録します。一度に並べ替えると、元の動作を再現できなくなることがあります。

インポート画面やサーバー項目の操作方法は、このページでは詳しく扱いません。既存の情報を整理し直す場合は、サブスクリプションのインポート方法を参照してください。プロトコル項目については、プロトコルとパラメータの解説をご覧ください。認証情報や通信パラメータの誤りをルールの変更で補わないでください。これらは別の層で発生する問題です。

08 / VERIFICATION

ルールの一致確認とトラブルシューティング

テストごとに4つの事実を記録

ルールを検証する際は、接続先のホスト名またはアドレス、現在のGlobal Routing、一致したルールまたはポリシー、最終的な接続結果を最低限記録してください。ページが開いたかどうかは最後の項目にすぎず、それ以前のルーティングを示す証拠にはなりません。現在の接続やログで接続先とポリシーを確認する際は、アプリに実際に表示された内容を基準にしてください。複数のリクエストが別々のドメインや接続に対応する場合があります。繰り返しリクエストできる明確な接続先を一つ選び、対応する新しいログを追跡してください。バックグラウンドのリクエストをテスト対象と取り違えないようにしましょう。

Connectivity Testは接続状態の確認に使えますが、ウェブページが必要とするすべての接続に想定どおりのルールが適用された証拠にはなりません。サーバーへの接続を確認した後も、実際の接続先にリクエストし、どのルールに一致したか確認してください。ルール変更後も既存の接続が続いていたり、ブラウザーがキャッシュを使っていたりする場合があります。必要に応じて再接続し、新しいセッションを開始してください。変更前後を比較する際は、ネットワーク、サーバー、接続先を同じに保ち、検証するルールだけを変更します。ほかの条件が変わると、結果に影響します。

設定が反映されない場合は、まず適用経路を確認

編集後に変化がない場合は、ファイル、ルーティング状態、ルールの順序の3点を確認してください。まず、同じ名前の別ファイルではなく、現在使用中のファイルを保存したか確認します。次に、Global RoutingがConfigになっているか確認してください。最後に[Rule]の先頭から順番に見て、対象に先に一致している条件がないか確認します。範囲の広いキーワード、大きなネットワーク範囲、前の方にあるFINALに注意してください。追加した行の構文が正しいというだけで、その前のルールを確認せずに済ませないでください。最初に一致したルールが、順序付きリスト全体の結果を決めます。

症状最初に確認次に行うこと
変更してもポリシーが変わらない使用中のファイル、Config、前にあるルール最小構成のファイルで再確認
PROXYに一致するが接続できない選択中のサーバーと接続パラメータプロキシ経路を単独でテスト
ドメイン名を解決できないDNS、Host、ネットワーク環境名前解決に関する変更を元に戻す
ページの一部の機能が動かない依存ドメインとREJECT関連するリクエストを一つずつ確認
リダイレクトが繰り返されるURL Rewriteとリダイレクト先書き換えを無効にして再接続

ルールに一致しても、接続成功とは限らない

ログに想定したポリシーが表示されているなら、次は実際の接続経路を調べます。PROXYで失敗する場合は、Homeで選択中のサーバーが利用可能か、認証項目、ポート、通信条件が手元の情報と一致しているか確認してください。DIRECTで失敗する場合は、現在のネットワークから接続先へ直接つながるか確認します。REJECTの場合は、拒否が意図した結果か確認してください。明確な接続エラーを、ルールの優先順位の問題として扱い続けないでください。必要に応じてProxyとDirectで一時的に比較し、確認後はConfigに戻して再テストします。

一部の機能だけが失敗する場合は、ページ本体へのリクエストと後続のAPIリクエストを分けて確認してください。ログイン、ファイルのアップロード、画像の読み込み、持続的な接続では、異なるドメインや接続方式が使われることがあります。ページが開いても、依存先すべてが正常とは限りません。重要なAPIリクエストにREJECTが適用されていないか、依存先が想定外のFINALに振り分けられていないか確認してください。特定の通信方式だけが失敗する場合は、サーバーとプロトコルの対応状況を確認します。通信層の診断を、ドメインの判定範囲を広げることで代用しないでください。

最小構成で原因を特定してから、元のファイルに戻す

最小構成には、必要な[General]、接続先を指定する1つのルール、1つのFINALだけを残し、自分で追加したHost、書き換えルール、広いキーワードは一時的に外します。これは基本的な判定が想定どおりか確認するためのもので、元の設定を永久に破棄するためのものではありません。最小構成で動作する場合は、元の設定をグループごとに戻し、差が生じるところを確認してください。それでも失敗する場合は、まず接続先名、名前解決の結果、サーバー経路を確認します。一度に1グループだけ戻すことで、問題の原因を具体的に特定できます。

元に戻すときは、設定内容とテスト時のルーティング状態の両方を復元し、新しい接続を開始してください。問題を記録する場合は、接続先、ネットワークの種類、ルールの抜粋、エラーの内容を含められます。ただし、サブスクリプションURLに含まれる認証情報、サーバーのパスワード、その他の機密情報は削除してください。実際の認証情報をそのままトラブルシューティング記録に貼り付けると、局所的な接続問題が情報漏えいにつながります。構成の説明に必要な例だけを残せば、ルールの順序、セクションの位置、項目数を確認できます。

初回接続やVPN構成の許可については、はじめにに戻って確認してください。購入、購入済みアプリの復元、システム要件については購入済みアプリの復元方法をご覧ください。システム要件はApp Storeのページに記載された内容をご確認ください。よくある症状の比較はよくある質問とトラブルシューティングをご覧ください。このページでは設定の仕組みを解説します。アプリの購入、サーバーへの接続、ルール判定を一つのトラブル窓口として扱うものではありません。