Shadowrocket
ルール・Config設定ガイド

[General]

Configファイルの構成と適用範囲

ShadowrocketのConfigファイルは、ドメイン一覧だけで構成されているわけではありません。動作パラメーター、リクエストの振り分け、名前解決のマッピング、URL処理がそれぞれ異なるセクションに記述されます。各セクションの見出しは英語の角括弧で囲まれています。ファイルを読むときは、まずセクション見出しを確認し、次の見出しが現れるまで、各行がどの構文に属するかを見ていきます。ドメインが含まれているという理由だけで、異なる行を同じセクションにまとめてはいけません。たとえばRuleのドメインはポリシーを決め、Hostのドメインは名前解決のマッピングを決めます。役割は異なります。

最小構成から検証用の基準を作る

利用可能なサーバーを設定したら、まず以下の例で構成を確認できます。ここではGeneralで一部のシステム通信をバイパスするかどうかを示し、Ruleでローカルネットワークと最終ポリシーを指定しています。あらゆるネットワークに使える完全なテンプレートではなく、サーバー認証情報も含まれていません。実際に編集する際は、現在のConfigを複製して元ファイルを残し、コピー上で項目を一つずつ変更してください。例を使うために、必要なDNS設定やルール、ネットワーク関連のパラメーターを削除しないでください。

[General]
bypass-system = true

[Rule]
IP-CIDR,192.168.0.0/16,DIRECT
IP-CIDR,10.0.0.0/8,DIRECT
FINAL,PROXY

bypass-system = true は、一部のシステム通信をクライアントの処理対象にするかどうかに影響します。この設定だけで、すべてのシステムリクエストが接続ログに表示されるとは限りません。ルールログに記録されるのは、クライアントが実際に処理し、識別できたリクエストです。システム機能の記録が見つからない場合は、まず通信が処理対象に入っているか確認してください。Ruleの誤りと決めつけて、範囲の広いドメインルールを追加しないでください。

Configファイル・サーバー一覧・現在の接続を区別する

Configは通信の処理方法を記述するファイルで、Homeに登録されたサーバーは接続先を提供します。ルールに PROXY と書いても、サーバーアドレスがConfigに記録されるわけではなく、利用可能な接続が選択済みであることも意味しません。トラブルシューティングでは、現在有効なConfig、Global Routingのモード、Homeで選択中の項目をそれぞれ確認してください。ファイル名が似ていることや、読み込みが成功したことだけでは、今回のリクエストに編集済みの内容が適用されている証明にはなりません。

編集後は保存し、Configに戻って対象ファイルが選択されていることを確認してから、アプリの画面に表示される手順に従って接続を再適用してください。リモートConfigの場合は、ローカルでの編集と配信元からの更新の関係にも注意が必要です。再ダウンロードするとローカル編集が上書きされることがあり、コピーとして保存すると元の内容に自動追従しなくなる場合があります。コピーには用途が分かる名前を付け、ファイルの先頭に変更理由を記録しましょう。似たバージョンを数字だけで区別するのは避けてください。

構文チェックは文字と記述先のセクションから

ルールのフィールドには半角カンマ、キーと値の区切りには通常半角イコールを使い、セクション名とポリシー名は英語のまま記述します。全角の句読点、コピー時に混入した不可視文字、途中で改行された不完全なルールは、意図どおりに解析されない原因になります。1行につき有効な項目を1つだけ記述し、説明は別の行の先頭に # を付けて書いてください。フィールドの途中に説明を挟んだり、Webページの表示用行番号をファイルにコピーしたりしないでください。

保存できるファイルでも、実際の目的に合っているとは限りません。保存によって解決するのはテキストと構文の問題だけです。実際に反映されるかどうかは、使用中のファイルやモード、通信の処理範囲、サーバーの状態にも左右されます。メンテナンス時は正常にアクセスできる基準のConfigを残し、一度に変更する設定を一種類に絞って、同じリクエストで再確認してください。問題が起きても、どの段階まで戻せばよいかを特定しやすくなり、複数セクションの変更を同時に調べずに済みます。

[Rule]

ドメインルールの範囲と制限

ドメインによる振り分けは「このサービスにどのポリシーを適用するか」を表せますが、最初に適切なマッチ範囲を選ぶ必要があります。Ruleでよく使うドメインキーワードはDOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORDの3つです。いずれも完全なURLを照合するものではありません。プロトコル、パス、クエリパラメーター、ポートをドメイン欄に含めたり、ブラウザーのアドレスバーに表示された文字列全体をホスト名の代わりに使ったりすることはできません。判定する前にリクエストをプロトコル、ホスト、ポート、パスに分け、ホスト部分を取り出してください。

DOMAIN：指定したホスト名だけを対象にする

DOMAIN,example.com,PROXY は、指定したドメインにマッチさせるルールです。api.example.com まで自動的に対象になるわけではありません。特定のホストだけを例外にする場合は、DOMAINを使うと範囲が明確になり、確認もしやすくなります。同じサービスでも、メインサイトとファイル用APIで異なるポリシーを使うことがあります。該当するホスト名を個別に指定すれば、後続のサイト全体に適用するルールが例外を覆うのを防げます。通常、ドメイン名は大文字と小文字を区別しませんが、メンテナンス時に小文字へ統一すると重複を見つけやすくなります。

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

この例が対象にするのは、記載した3つのホストだけです。それ以外の名前にはFINALが適用されます。ページに画像やAPIデータが表示されない場合、DOMAINが機能していないのではなく、ページが一覧にない別のドメインを参照している可能性があります。ページを開くだけで複数の接続が発生することがあります。確認時は、読み込めなかったリソースのホスト名とメイン文書のホスト名を分けて調べ、アドレスバーの名前だけからすべての通信経路を判断しないでください。

DOMAIN-SUFFIX：ルートドメインとサブドメインを対象にする

同じドメイン配下のサービスに同じポリシーを適用する場合は、DOMAIN-SUFFIX,example.com,PROXY を使えます。example.comとapi.example.comなどのサブドメインが対象になります。任意の文字列末尾を照合するものではなく、otherexample.comはexample.comのサブドメインではありません。ルール欄にはドメインのサフィックスだけを記述し、先頭にアスタリスクを付けたり、https://を記述したりしないでください。

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

この例では、特定のホストをサフィックスルールより前に置いているため、local.example.comにはDIRECTを適用し、それ以外の該当するサブドメインにはPROXYを適用できます。行を逆にすると、サフィックスルールが先にこのホストを処理するため、後続の例外は適用されません。ルールが自動的に、より具体的な条件を優先するわけではありません。「具体的なルールを先に置く」という結果は、ファイルの記述順によって実現します。

DOMAIN-KEYWORD：広範囲にマッチするため要確認

DOMAIN-KEYWORDはドメインに含まれるキーワードを照合します。ドメインの所有範囲を基準にはしません。たとえばDOMAIN-KEYWORD,example,PROXYは、example.comだけでなく、exampleを含む複数のドメインにマッチする可能性があります。広い範囲へのマッチが必要な場合に使い、短く書けるという理由だけでDOMAIN-SUFFIXの代わりに使うのは避けてください。キーワードが短いほど、意図しない対象にマッチしやすくなります。

サイトの運営元を推測せず、記録されたドメインを確認

クライアントがドメインルールを適用できるかどうかは、今回の接続で利用可能なドメイン情報を取得できるかに左右されます。アプリがIPアドレスへ直接接続する場合や、既存の接続を再利用する場合、独自の名前解決を使う場合は、記録に表示される情報がブラウザーで入力した内容と異なることがあります。まずリクエスト記録に表示された接続先とマッチしたルールを確認してから、ドメイン条件とIP条件のどちらを使うか判断してください。アプリ全体をPROXYに通すために短すぎるキーワードを使って範囲を広げると、原因を特定しにくい副作用が生じることがあります。

国際化ドメイン名では、画面に表示される文字と実際のリクエストに使われるエンコード形式が異なる場合があります。トラブルシューティングでは、記録されたホスト名を基準にしてください。検索結果のリダイレクトURLを最終的なサイトだと決めつけるのも避けましょう。リダイレクトの過程で複数のドメインに接続することがあり、新しい接続ごとにルールが判定されます。「指定サイトはPROXY、それ以外はDIRECT」にしたい場合は、DOMAIN-SUFFIXとFINAL,DIRECTの設定例を参照し、範囲を広げる前に対象ドメインを明確に整理してください。

[IP]

IP・GEOIP・USER-AGENT

ドメインルールはサービス名を対象にし、IPルールは接続先アドレスの範囲を対象にします。互いに置き換えられる条件ではありません。同じドメインが複数のアドレスに解決されることもあれば、同じアドレス上で複数のサービスが提供されることもあります。特定のWebサイトを継続して指定したい場合は、ドメイン条件を優先してください。オフィスのネットワークや特定のデバイスへ直接接続したい場合は、IP-CIDRの方が意図を明確に表せます。条件を選ぶ前に、制御したい対象が「名前の集合」なのか「アドレスの集合」なのかを確認してください。

IP-CIDRとプレフィックス長

IPv4のCIDRは、ネットワークアドレスとスラッシュ以降のプレフィックス長で構成されます。プレフィックスが長いほど対象アドレスは少なくなります。/32は単一のIPv4アドレス、192.168.0.0/16は広いプライベートアドレス範囲を表します。CIDR欄にポートを含めたり、ネットワークアドレスの代わりにドメインを使ったりしないでください。1台のデバイスだけを対象にする場合は、手間を省くためにプライベートネットワーク全体を指定せず、対象アドレスを明示してください。

[Rule]
IP-CIDR,192.168.1.20/32,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT
IP-CIDR,10.0.0.0/8,DIRECT
IP-CIDR,172.16.0.0/12,DIRECT
FINAL,PROXY

上記の3つの範囲は、よく使われるプライベートIPv4アドレス空間です。現在のネットワークで実際に使われていることを示すものではありません。ネットワークに経路の重複、リモートの社内ネットワーク、専用アクセス要件がある場合は、実際のアドレス設計に合わせて調整してください。ルールでDIRECTを選ぶのはプロキシを使わないという意味であり、存在しない経路をシステムに作成したり、アクセス権のないアドレスへの接続を可能にしたりするものではありません。

IP-CIDR6とデュアルスタック通信

IPv6にはIP-CIDR6を使います。例：IP-CIDR6,fd00::/8,DIRECT。IPv4とIPv6のアドレスを同じキーワードの後ろに記述しないでください。デバイスが両方のアドレスを取得し、アプリがどちらか一方を優先して接続することがあります。そのため、IPv4のルールだけを修正しても、実際の接続経路が変わるとは限りません。テストでは、一度のDNS問い合わせ結果だけでなく、実際に使われたアドレスファミリーを確認してください。

[Rule]
IP-CIDR,192.168.0.0/16,DIRECT
IP-CIDR6,fd00::/8,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY

この設定例は異なるアドレス条件の組み合わせを示すもので、あらゆるローカルネットワークに対応することを保証するものではありません。IPv6のリンクローカル範囲、ネットワークインターフェース、システムルーティングには、それぞれ別の制約があります。記録にIPv6の接続先があるのに設定がIPv4だけの場合は、まず想定される動作を確認してから必要な範囲を追加してください。アドレス空間全体にDIRECTを適用することを、汎用的な解決策にしないでください。

GEOIPが判定するのはIPアドレスの地域情報

GEOIP,CN,DIRECTは、クライアントが使用するIPアドレスの地域情報データベースに基づいて接続先を判定します。Webページの言語やドメインの登録国、アカウントの地域を識別するものではありません。コンテンツ配信ネットワークは接続場所によって異なるアドレスを返す場合があり、データベースの情報が実際の配備状況と一致しないこともあります。そのためGEOIPは広範囲のポリシーの一部として使うのに適していますが、特定サイトの所属地域を判断する唯一の根拠にはできません。重要なサービスには、その前に明示的なドメインルールを追加できます。

ドメイン名のリクエストに宛先アドレスを必要とするルールを適用する場合、名前解決が発生することがあります。no-resolveを指定すると、IPルールのマッチのためにドメイン名を追加で解決することを避けられます。例：IP-CIDR,192.168.0.0/16,DIRECT,no-resolve。アプリ全体のDNSを無効にする設定ではなく、既知のIPアドレスがマッチしなくなるわけでもありません。名前解決の要否に応じて使い、常に速度を向上させる設定だと考えないでください。

USER-AGENTで確認できる情報の制限

USER-AGENT,ExampleApp*,DIRECTは、取得可能なUser-Agent情報に基づいてマッチします。例にあるアスタリスクは、その後に続く文字列を対象にします。これはリクエストの識別情報にマッチするもので、OS上のアプリ名やインストールパッケージ名を判定するものではありません。複数のアプリが同じ識別情報を使うことも、1つのアプリがリクエストごとに異なる識別情報を送信することもあります。そのため、確実なアプリ単位の振り分け手段としては使えません。

暗号化されたリクエストでは、クライアントがHTTPリクエストヘッダーを読み取れないことがあります。RuleにUSER-AGENTを追加しても、これらの情報を自動的に取得できるわけではありません。このために証明書関連の設定をむやみに変更しないでください。記録に該当フィールドがない場合は、情報を確認できないことを前提に、観察可能なドメイン条件やアドレス条件を使います。パスやリクエストヘッダーを必要とする要件は、通常の接続振り分けとは分けて検討してください。実際にはマッチする機会のないルールを、設定済みと誤認するのを防げます。

[Policy]

ポリシーとGlobal Routingの関係

ルールは「この条件にマッチするか」を判定し、ポリシーは「マッチした場合にどう処理するか」を決めます。PROXY、DIRECT、REJECTはポリシー名であり、プロトコルの種類やサーバーアドレスではありません。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuardなどは接続方式を表します。同じPROXYを指定したルールでも、現在利用可能なプロキシ接続を通じて処理できます。ポリシー名をプロトコル名に変えても、サーバー設定にはなりません。

PROXY：リクエストを現在のプロキシ経路へ送る

ルールでPROXYを選択するには、設定済みで利用可能なプロキシ接続先が必要です。アドレス、ポート、認証、トランスポート、TLSなどの設定が正しいかどうかは接続設定の問題です。ドメインがルールにマッチするかどうかは振り分けの問題です。片方が成功し、もう片方が失敗することもあります。ログにPROXYが表示されてもWebページにアクセスできない場合、ルールが無効とは限りません。選択中のサーバーに到達できない、認証に失敗している、またはサーバーから接続先へ到達できない可能性もあります。

まずHomeで選択中の項目を確認し、Connectivity Testで接続状況を調べます。テスト結果が示すのは、そのテスト条件での状態だけです。すべてのサイト、ポート、プロトコルで接続できることを保証するものではありません。Trojanのパスワード、SNI、TLSフィールドを確認したい場合は、Trojanの設定項目ガイドを参照してください。接続先の認証エラーを、ドメインルールの追加で隠そうとしないでください。

DIRECTとREJECTの違い

DIRECTは接続先へプロキシを経由せず接続することを意味しますが、ローカルネットワーク、システム権限、DNS、ルーティング、接続先サービスの影響は受けます。直接接続に失敗しても、プロキシに切り替える必要があるとは限らず、クライアントがリクエストを遮断した証拠にもなりません。REJECTはマッチしたリクエストを拒否します。拒否すると決めた接続先に使うもので、別の接続経路への自動切り替えや、プロキシ接続失敗時の一時的なフォールバックを意味するものではありません。

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

この例では、拒否する条件を先頭に置き、次に内部サービス、その後にサフィックスルールで残りのサブドメインを処理します。REJECTの後にアプリへ表示されるエラーはリクエストの種類によって異なる場合があります。エラーページの見た目だけでルールのマッチを判断しないでください。接続先、ポリシー、ルールの記録が一致しているかを確認する方が確実です。

Global Routingの3つのモード

Global RoutingのConfig / Proxy / Directは、画面上のConfig / Proxy / Directに対応します。Configは現在のConfigファイルに従って通信を振り分け、Ruleの動作確認に使います。ProxyとDirectは、処理対象となる接続全体をプロキシ経由または直接接続へ振り分けるモードです。Configと同じように、通常のRuleが1行ずつ適用されるとは限りません。また「全体」といってもシステムが通信を処理する範囲に限られ、デバイス上のすべての通信が必ず同じ経路を通るという意味ではありません。

モードの比較は原因特定に使い、同時に複数の設定を変更しない

Configで失敗しProxyで成功する場合は、振り分けの方向や名前解決の経路が原因かもしれませんが、記録を確認して判断してください。両方で失敗する場合は、Ruleの範囲をすぐに広げるのではなく、プロキシ接続と接続先サービスを確認します。Directで成功してProxyで失敗する場合は、プロキシ側が対象の接続先やポートに対応しているか確認してください。モードを切り替えた後はリクエストを再送し、既存の接続が再利用された結果を新しいモードの動作と取り違えないようにします。

On Demandはネットワーク条件に応じて接続を開始するタイミングを決めます。特定のドメインがPROXYとDIRECTのどちらにマッチするかとは別の処理です。自動接続が開始したからといってポリシーが正しいとは限りません。自動接続が開始しない場合も、Ruleで接続条件を修正することはできません。接続の切り替え、Global Routing、Config、サーバーの選択を4つの項目に分けて確認すると、問題を早く特定できます。関連する画面用語は用語ガイドをご覧ください。

[Priority]

ルールのマッチ順序とよくある設定

Ruleの基本は上から順にチェックし、最初にマッチした有効な条件のポリシーを適用することです。すべての条件を集めてから、最も具体的に見えるものを選ぶわけではありません。後の行が前の行を自動的に上書きすることもありません。Configを整理する際は、明確な例外を範囲の広い条件より前に置き、FINALは末尾に記述してください。キーワードをたくさん覚えるより、この仕組みを理解することが大切です。「ルールが効かない」という問題の多くは、前のルールがすでに接続先を対象にしていることが原因です。

指定ドメインはPROXY、その他はDIRECT

プロキシを使う範囲が明確で、その他のリクエストをローカルネットワーク経由にしたい場合に適した設定です。まず例外となるホストを指定し、次にドメインサフィックスを記述して、最後にFINAL,DIRECTを設定します。サイトが必要とするすべてのサービスを自動的に検出することはありません。ログイン、画像、APIが別のドメインを使う場合は、リクエスト記録を見て個別に確認してください。ページが正しく表示されないからといって、DOMAIN-KEYWORDに範囲を広げたり、FINALをPROXYに変えたりしないでください。

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

テストでは少なくとも、PROXYにするホスト、DIRECTのままにする例外、一覧に含まれないホストの3種類を用意してください。それぞれのマッチルールとポリシーを確認すれば、設定全体の意図を検証できます。example.comへの接続が成功しただけでは、local.example.comの例外やFINALの方向が正しいことは確認できません。

プライベートアドレスはDIRECT、その他はPROXY

別の設定例では、まずローカルデバイスへの接続を確保し、その他のリクエストをPROXYへ送ります。ここでいう「その他」には、リストにない業務ドメインやアプリの接続も広く含まれるため、サーバーが利用可能であることと、リモート接続による経路の変化を事前に確認してください。プライベートアドレスの指定も実際のネットワークに合わせる必要があります。リモートの同じプライベートアドレス帯へプロキシ経由で接続する業務では、一般的なLAN向けDIRECTルールが接続先と競合する可能性があります。

[Rule]
IP-CIDR,192.168.0.0/16,DIRECT
IP-CIDR,10.0.0.0/8,DIRECT
IP-CIDR,172.16.0.0/12,DIRECT
IP-CIDR6,fd00::/8,DIRECT
FINAL,PROXY

この例では、意図を明確にするためGEOIPを使っていません。ここにGEOIP,CN,DIRECTを追加すると、より広い範囲を対象にする別の振り分けになります。どちらも要件を表現できますが、新しい条件の追加は動作に影響しない装飾ではありません。各行に説明できる役割を持たせ、対応するリクエストを検証してください。

FINALは接続失敗時の予備経路ではない

FINALは、前の条件にマッチしなかった場合に使うポリシーです。前の接続が失敗した後に切り替わるポリシーではありません。リクエストがPROXYにマッチした後にタイムアウトしても、通常は次の行にあるFINAL,DIRECTは試されません。可用性を切り替える設定が必要な場合は、専用のポリシー設定を確認してください。FINALを複数並べても切り替えは実現できません。日常のメンテナンスでは、同じキーワードを重ねるより、FINALを1つだけ明確に残す方が確認しやすくなります。

[Rule]
# 先に単一ホストの例外を設定
DOMAIN,download.example.com,DIRECT
# 次に残りのサブドメインを対象にする
DOMAIN-SUFFIX,example.com,PROXY
# 最後に前の条件にマッチしなかったリクエストを処理
FINAL,DIRECT

Configの統合前にルールの重複・遮蔽を解消する

2つのルールをまとめる前に、それぞれのFINAL、広範囲のドメイン条件、広いIP範囲を比較してください。1つ目のFINALが途中に残っていると、2つ目のルールは構文が正しくてもチェックされないことがあります。同様に、example.com全体を対象にするサフィックスルールが後続の複数のホストルールを覆うこともあります。ルールの重複があると、後から加えた変更が反映されたと誤解しやすくなります。

「明示的な拒否、具体的な例外、サービスのドメイン、アドレス範囲、地域条件、最終ポリシー」の順で確認すると整理しやすくなります。ただし、これは整理方法であり、クライアントが強制する優先順位ではありません。業務上IP条件をドメイン条件より前にする必要があれば、順序を明確に変更し、理由を記録してください。キーワードを機械的にアルファベット順に並べると、最初にマッチするルールが変わるため避けてください。

複数のサービスが共有するアドレスを、1回の名前解決で得たIPアドレスに置き換えて長期的に使うのは避けてください。アドレスが変わったり、無関係なサービスが同じアドレスを使用したりすることがあります。ルールの上位に追加すると、ほかのリクエストにも影響します。変更前後の差分を記録し、元に戻せるファイルを残すことは、「項目が多いほど完全」という考えより、複雑なConfigの保守に役立ちます。症状別の詳しい確認方法はよくある質問をご覧ください。

[Host]

HostマッピングとDNS経路

HostとRuleは同じConfigに記述されますが、解決する問題は異なります。Hostは名前に対応するアドレスを指定し、Ruleはリクエストに適用するポリシーを決めます。ドメインをIPアドレスにマッピングしてもDIRECTになるわけではなく、ドメインにPROXYを指定してもDNS結果が固定されるわけではありません。ドメインへのアクセスで問題が起きた場合は、「名前をどのようにアドレスへ変換するか」と「接続をどのように接続先へ送るか」を分けて確認してください。そうしないと、関係のないセクションを何度も変更してしまうことがあります。

静的マッピングの基本構文

次のHostの例は、文書用アドレスを使ってイコールの左右の構成を示しています。左辺は完全なホスト名、右辺は接続先IPアドレスです。プロトコルやURLのパスは含みません。実環境で使う場合は、自分が管理している、または利用を許可されている接続先アドレスに置き換えてください。例示用アドレスで接続テストをしたり、出所が分からないアドレスを常用サービスに固定したりしないでください。

[Host]
portal.example.com = 192.0.2.20

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

ここではDOMAINでDIRECTを指定し、Hostでアドレスを設定して、それぞれの判断を分けて説明しています。名前解決に成功して192.0.2.20が返されても、現在のネットワークから接続できるとは限りません。ルート、ポートの待ち受け、アクセス権、サーバーの状態が満たされている必要があります。実際のテストには利用可能なアドレスを使ってください。記録上でマッピングが反映されたことと、サービスにアクセスできることは別々の確認項目です。

アドレスを固定しても証明書のドメイン名は変わらない

HTTPSでは引き続き元のドメイン名で本人確認が行われ、サーバーは通常、SNIを使って証明書やサイトを選択します。Hostが変更するのはアドレスとの対応関係だけです。無効な証明書が一致するようになったり、そのドメインを提供していないサーバーが正しいコンテンツを返したりするわけではありません。マッピング後に証明書エラーが発生した場合は、証明書の検証を緩めて不正なアドレス設定を隠すのではなく、サーバーがそのドメインを正しく提供しているか確認してください。

同様に、ブラウザーでIPアドレスへ直接アクセスした場合と、ドメイン名を使ってHostマッピング経由でアクセスした場合とで、同じ結果になるとは限りません。リクエストのホスト情報が異なったり、サーバー上の仮想ホストが変わったりする可能性があります。トラブルシューティングでは元のドメイン名とアクセス経路を維持し、検証対象のマッピングだけを変更してください。複数の条件を同時に変えると、どの変更が結果に影響したのか特定できません。

Generalの名前解決パラメーターを個別に確認

GeneralにはDNS関連の設定を含めることができます。たとえばdns-server = systemは、システムの名前解決を使う設定です。これは標準的な経路を理解するための簡単な例であり、すべての環境でこの値を使う必要があるという意味ではありません。ネットワーク環境、アプリ独自の名前解決、プロキシ側の処理方式も、実際に確認できる動作に影響します。DNSサーバーの変更を、あらゆる問題に共通する解決策と考えないでください。

[General]
dns-server = system

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

この例では静的マッピングを設定せず、Hostを使う場合と比較できるようにしています。古いマッピングが有効なままの場合、DNSサーバーを変更しても、そのホストに対応するアドレスが変わらないことがあります。アプリが既存の接続を再利用している場合は、DNSを再問い合わせしても現在の接続に反映されないことがあります。Hostの設定があるか、新しい接続を確立したかを先に確認してから、名前解決の設定が反映されたか判断してください。

キャッシュ・アプリ独自の名前解決・複数アドレス

DNSの結果はシステム、クライアント、アプリのキャッシュに保持されることがあります。Webサイトへの接続が長時間再利用される場合もあります。変更直後にページを再読み込みしても、新たな名前解決が実行されるとは限りません。実行中の処理を停止し、接続を再適用してから、対象を開き直してください。必要に応じてアプリのキャッシュ機能を使います。1つの接続先の古い情報を消すために、設定やネットワーク全体をリセットしないでください。

同じ名前からIPv4とIPv6の両方が返される場合、片方のアドレスを固定したり、片方の結果だけを確認したりしても、すべての接続が想定どおりになったとは限りません。接続記録にある実際のアドレスを基準に、アドレスファミリー、マッチしたルール、ポリシーをそれぞれ確認してください。社内ネットワークの名前を調べる場合は、元のネットワークと別のネットワークの両方でテストします。オフィスを離れると、元のDNS検索ドメインやプライベートアドレスへのルートが使えなくなることがあります。

メンテナンス時は各マッピングの用途を明記し、サーバーが引き続きそのドメインを受け付けるか定期的に確認してください。一時的な調査が終わったら、不要なマッピングを削除して基準の設定に戻します。数か月後に期限切れのアドレスをルールの不具合と誤認するのを防げます。記録できないリクエストに対し、推測だけでHostを追加しないでください。まずリクエストのホスト名、接続先アドレス、エラーの種類を確認してから、適切な変更箇所を選びます。

[URL Rewrite]

URL Rewriteの式と適用範囲

URL Rewriteは識別可能なURLを処理します。Ruleでホスト名やアドレスに基づいて接続ポリシーを選ぶ機能とは異なります。明確なURLの書き換えやリダイレクトが必要な場合に使い、アプリ全体の振り分け設定として使わないでください。追加する前に、変更したい対象が接続経路、名前とアドレスの対応、リクエストURLそのもののどれなのかを確認してください。最初の2つにはそれぞれRuleとHostを使い、URL自体を変更する場合だけ、この章の設定を検討します。

確認可能なHTTPリダイレクトから始める

次の例は、マッチした暗号化されていないHTTPアドレスを、同じドメインのHTTPSアドレスへリダイレクトします。302は一時的なリダイレクトを表します。構文を示す例であり、接続先のサイトがHTTPSに対応していることを保証するものではありません。左側に元のアドレスにマッチする式、中央に置換先、最後に処理方法を記述します。各項目を分ける空白には半角スペースを使い、全角の句読点に置き換えないでください。

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

^は文字列の先頭にマッチを限定し、\.はドメイン中のピリオドそのものを表します。(.*)は後続部分をキャプチャし、$1は置換先で最初のキャプチャグループを参照します。ドメインのピリオドを正規表現の任意の1文字として記述すると、想定より広い範囲にマッチします。キャプチャ参照が抜けていると、元のパスが失われ、別のページへリダイレクトされる場合があります。

ホストとパスを指定してマッチ範囲を限定

安全性を高めるには、特定の単語を含むすべてのURLを書き換えるのではなく、通常はプロトコル、ホスト、パスのプレフィックスを明確に指定します。ドメインとパスの両方にキーワードが含まれる場合があり、アンカーのない式はクエリパラメーターに誤ってマッチすることもあります。想定どおりマッチするURLを1つ用意し、似ているがマッチしてはいけないURLもいくつか準備してください。成功例を1つ見るだけでなく、境界となるケースで検証します。

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

この例が対象にするのは、指定ホストのoldから始まるパスだけです。ほかのサイトやパスは書き換えません。元のURLにクエリパラメーターがある場合は、キャプチャ後の置換結果も想定どおりか確認してください。ログイン状態、一時的な認証情報、送信操作を含むURLには特に注意が必要です。パスやリダイレクト方式を変更すると、サーバー側のリクエスト解釈に影響することがあります。

1行のルールだけでHTTPSの内容を読めるわけではない

HTTPSではリクエストの内容が暗号化された接続の中にあるため、完全なURLパスやリクエストヘッダーをクライアントが直接読み取れるとは限りません。ルールにHTTPSの式を追加しても、すべての暗号化通信を処理できるわけではありません。利用できる情報の範囲は、実際の接続方式と関連設定によって異なります。Rewriteの追加と内容を確認できることを混同せず、例にマッチさせるためだけに証明書関連の設定をむやみに有効にしないでください。

一部のアプリは追加の証明書制約や独自のネットワーク処理を使っているため、ブラウザーで有効な方法をそのまま適用できるとは限りません。特定サイトをPROXYに通したいだけなら、ドメインのRuleで意図を表せます。暗号化された内容を読み取る必要はありません。必要な接続レイヤーに対象を限定すれば、余計な依存を減らし、設定の影響範囲も確認しやすくなります。

リダイレクトループやキャッシュによる誤判定

クライアントがAをBに書き換え、サーバーがBをAに戻すと、リダイレクトループが発生します。何度も読み込みが繰り返されたり、リダイレクト回数が多すぎると表示されたり、ページを開けなくなったりします。どのRewriteが原因か明確に表示されないこともあります。調査時は追加したRewriteだけを一時停止し、Ruleは変更せずにループが止まるか確認してください。Global Routingも同時に切り替えると、どの変更が結果に影響したか特定できなくなります。

ブラウザーにサーバーのリダイレクトやStrict Transport Securityの情報が保存されていると、HTTPリクエストが送信される前にHTTPSへ切り替わる場合があります。この場合、HTTPルールが記録に表示されなくても、式の構文が誤っているとは限りません。制御可能なテスト用アドレスを使って新しいアクセスを行い、実際のプロトコルとリダイレクトの流れを確認してください。実際の業務で使う送信操作を試験目的で繰り返さないでください。重複した処理が実行されるおそれがあります。

1回のアクセス中にRewriteとRuleの両方が適用される場合があります。元のURLを書き換えた後、新しいリクエストの実際の接続先に応じて接続処理が行われます。そのため「最終的にどのポリシーが使われたか」は、最初に入力したURLではなく、書き換え後のリクエストを確認してください。メンテナンス時は書き換えの目的、想定する入力と出力を記録し、テスト後に一時的なルールを削除します。認証や支払いを含む処理ではサービス本来のアドレス動作を維持し、一般的な例を実際の業務にそのまま適用しないでください。

[Diagnostics]

確認・メンテナンス・トラブルシューティング

Configを検証するには、「想定した条件にマッチしたこと」と「接続が想定した経路で完了したこと」の両方を確認する必要があります。ページが表示されただけでは十分ではありません。キャッシュから表示されたり、既存の接続が使われたりする場合があります。テストツールで接続可能と表示されても、接続先のサービスがリクエストを受け付けたとは限りません。再現可能なテスト操作を決め、毎回一つの設定だけを変更してください。対象ホスト、接続先アドレス、マッチした行、ポリシー、結果を記録します。

6つの確認項目を決まった順で調べる

1. クライアントの接続が有効で、直前にネットワークが切り替わっていないことを確認します。
2. Global Routingが今回のテストに必要なConfigになっているか、以前のProxyやDirectが残っていないかを確認します。
3. Configで現在選択中のファイルを確認し、開いて変更内容が保存されていることを確かめます。
4. Homeで選択中のサーバーを確認し、接続パラメーターと基本的な疎通を個別にチェックします。
5. 対象へのリクエストを再送し、実際のドメイン、アドレス、マッチしたポリシーを確認して、古い接続の再利用を除外します。
6. 観察結果に直接関係する設定を1つだけ変更し、同じ操作を再度行って差分を記録します。

この順序なら、接続レイヤーとルールレイヤーを分けて確認できます。最初の段階で接続が有効でなければ、DOMAIN-SUFFIXを変更しても意味がありません。現在のファイルが違えば、構文が正しくてもリクエストに反映されません。読み込み手順に不慣れな場合は、まず使い方ガイドに沿って接続が成功することを確認してから、ルールを調整してください。サーバー設定と振り分けを空のConfigで同時に調整するより、原因を特定しやすくなります。

症状に応じて確認箇所を選ぶ

記録で想定外のルールにマッチしている場合は、ファイルを上にたどり、最初に接続先を対象にした条件を確認してください。記録に想定どおりのポリシーが表示されている場合は、接続と接続先サービスを調べます。同じドメインでもリクエストごとに動作が異なるなら、アドレスファミリー、ポート、実際のアドレス、接続の作成時刻も比較してください。こうした異なる条件を「ルールが効いたり効かなかったりする」という一言で片付けないでください。

Config全体を削除せず、最小構成で再現する

Configが複雑で原因を特定できない場合は、現在のファイルを複製し、必要なGeneral、対象条件を1つ、FINALだけを残して再現してください。元ファイルは戻せるように残し、内容を消去しないでください。次の例は特定のドメイン条件にマッチするかを確認する用途に使えます。テスト対象は利用中のサービスに置き換えてください。example.comへのアクセス結果から、自分のサーバーの状態を判断しないでください。

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

最小構成で想定どおりに動作した場合は、元のルールをグループごとに戻し、どの段階で結果が変わるかを確認してください。これにより、前のルールに覆われる項目、範囲の広すぎるキーワード、早すぎる位置にあるFINALを見つけられます。復元時もGeneralや名前解決の条件を同じにしてください。動作の変化が、追加したRuleではなくDNS経路による可能性もあります。一度成功しただけでファイル全体が正しいと判断せず、PROXY、DIRECT、REJECT、最終ポリシーに対応する例をそれぞれテストしてください。

サブスクリプション更新とローカルConfigを分けて管理

Subscribeの更新は主に登録済みサーバー情報に関係し、Configの更新はルールや通信の処理方法に関係します。更新元が異なる場合や、更新のタイミングが異なる場合もあります。更新後は、実際に何が変更されたかを確認してください。サーバー一覧を更新すればローカルルールも自動で修正されるとは限りません。サブスクリプションURLはサービス提供元から入手してください。個別の共有リンクとの違いは、共有リンク形式の説明をご覧ください。

Config、エクスポートしたファイル、ログには、サーバーアドレス、アカウント情報、認証情報付きのURLが含まれる場合があります。問題を他の人に説明するときは、必要なルールと加工済みの記録だけを共有し、認証情報や完全なサブスクリプションURLを削除してください。ルール例のドメインは公開しても問題ありませんが、実際のアクセス記録から利用状況が分かることがあります。Config全体を送る前に、各項目を確認してください。

変更後の回帰テスト

最後に、普段使うネットワークで対象サービス、ローカルネットワークへの接続、これまで正常だったほかのアプリをそれぞれ確認し、新しいルールの影響が広がっていないことを確かめます。On Demandを設定している場合は、ネットワーク切り替え後に接続が開始するかも個別にテストし、ドメインのマッチ確認と混同しないでください。変更前のファイル、変更理由、いくつかのテスト例を残しておくと、後で問題が起きた際にConfig、サーバー、接続先サービスのどこが変わったのか区別できます。

このページではConfigの仕組みとルールの適用範囲を解説しています。インストール方法と入手先はダウンロードガイド、よくあるエラーメッセージはよくある質問、用語の意味は用語ガイドをご覧ください。新しい問題が起きたら、まず確認できる事実を集め、該当する章で確認してください。Configを適切に保守するには、各ルールの目的を明確にし、変更のたびに検証でき、問題があれば元に戻せる状態を保つことが大切です。ファイルをただ長くすることが目的ではありません。