設定ファイルの構成とGeneral
設定ファイルはリクエストの名前解決、照合、処理方法を定義し、サーバー情報は実際の接続に必要なパラメータを指定します。両者は互いに代用できません。ファイルに PROXY と記述されていても、利用可能なサーバーがあるとは限りません。反対に、サーバーを読み込んでいても、特定のルールファイルが有効になっているとは限りません。変更を始める前に、Configで使用中の設定を、Homeで接続先を確認し、「どのルールを使うか」と「どこに接続するか」を分けて把握してください。
4つのセクションの役割
角括弧で囲まれた見出しは、セクションを区切るためのものです。[General]には一般設定、[Rule]には上から順に照合する振り分けルール、[Host]にはホスト名とアドレスの静的マッピング、[URL Rewrite]には条件に合うURLの書き換えやリダイレクトを記述します。これらは互いに置き換えられる4種類のルールではありません。ドメインに適用するポリシーは通常Ruleで指定し、ドメインをどのアドレスに名前解決するかはHostまたはDNSで扱います。
[General]
bypass-system = true
dns-server = system
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
FINAL,PROXY
[Host]
example.com = 192.0.2.10
[URL Rewrite]
^http://example\.com/$ https://example.com/ 302このテキストはセクションと構文の説明用で、そのまま有効にする完成済み設定ではありません。example.comは説明用のドメイン、192.0.2.10は文書用のサンプルアドレスです。ここでのHostとURL Rewriteは書式を示すもので、両方を同時に有効にする必要があるという意味ではありません。練習するときはGeneralと少数のRuleだけを残し、基本接続を確認してから、検証したいセクションを個別に追加してください。例同士の影響を避けられます。
Generalの項目は用途を理解して使う
dns-server = systemはシステムのDNS設定を使用する指定です。現在のネットワーク動作を確認する出発点にはなりますが、すべてのリモートリクエストが必ず同じローカルのリゾルバーで処理されるとは限りません。サーバーのプロトコルや接続方法、リクエスト経路によって、最終的な名前解決の場所は変わります。名前解決に問題がある場合は、この1行だけで判断せず、リクエスト記録にあるドメインと接続先アドレスも確認してください。
bypass-system = trueはシステム関連の通信をバイパスする設定です。「すべてのローカルアドレスをDIRECTにする」という意味ではなく、明示的なIP範囲ルールの代わりにもなりません。システム通信の処理範囲に関わるため、変更すると確認できるリクエストの範囲に影響する場合があります。特定のLANセグメントをDIRECTにしたいだけなら、まずRuleにその範囲を指定して実際のリクエストを検証してください。関係のないGeneral項目まで変更しないようにしましょう。
| セクション | 主な役割 | 代用できないもの |
|---|---|---|
| General | 一般的なネットワーク・名前解決の設定 | 個別サーバーの認証情報 |
| Rule | リクエストを照合してポリシーを選択 | ドメイン名とアドレスの静的マッピング |
| Host | 指定した名前に対応するアドレス | リクエストに適用する接続ポリシー |
| URL Rewrite | 式に基づく表示URLの処理 | すべてのリクエストに対するフォールバック振り分け |
保存・反映・リモート更新は別の操作
エディタで保存できても、内容が書き込まれたことしか分かりません。そのファイルが選択されているとは限りません。変更後はConfigに戻って現在の設定を確認し、Global RoutingでConfigが選択されていることも確認してください。リモート管理されている設定では、ローカルでの変更と上流のファイルを区別する必要があります。再更新するとローカルの内容が上書きされる場合があります。長期的に残すカスタムルールは別途バックアップし、挿入位置も記録してください。更新で置き換わる可能性のあるテキストに唯一のコピーを残さないようにしましょう。
設定を調べるときは、まず復元できる原文を保存し、項目を1つだけ変更します。変更前のネットワーク環境、Global Routing、テスト用ドメイン、想定するポリシーを記録してください。変更後は同じリクエストで再検証します。結果が想定と異なれば、その項目を元に戻して再テストするほうが、正体の分からない設定を次々追加するより原因を特定しやすくなります。特に、異なる出所のGeneral設定をすべてつなぎ合わせないでください。重複するキーや相互に影響する設定があると、結果を解釈しにくくなります。
Ruleとルールの種類
Ruleの基本形は「種類、照合する内容、ポリシー」で、フィールドは半角カンマで区切ります。FINALは照合内容を必要としないため、通常は種類とポリシーの2項目だけです。ルールキーワードは英語のままにし、ドメイン欄にはプロトコル、パス、クエリパラメータを含めないでください。以下の例では、Configが選択され、PROXYに利用可能な接続先があることを前提としています。そうでなければ、ルールに正しく一致してもリクエストが成功するとは限りません。
DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORD
DOMAINは単一のホスト名に完全一致させるもので、特定のサブドメインだけを処理したい場合に適しています。DOMAIN-SUFFIXはドメインのサフィックス境界に基づいて一致し、ルートドメインとそのサブドメインに使われます。たとえばexample.comのサフィックスルールはapi.example.comにも一致しますが、末尾の文字列が同じというだけの別ドメインに一致するわけではありません。DOMAIN-KEYWORDはドメイン内のキーワードに基づいて一致するため、対象範囲が広くなりがちです。意図せず含まれる別のホスト名がないか、追加で確認してください。
[Rule]
DOMAIN,api.example.com,PROXY
DOMAIN-SUFFIX,example.com,DIRECT
DOMAIN-KEYWORD,example,REJECT
FINAL,PROXYこの順序では、api.example.comは最初のDOMAINに一致するため、後続のDIRECTには進みません。example.comに属するその他のサブドメインは2行目で処理されます。3行目が対象にできるのは、前の2行に一致せず、ドメイン名にexampleを含むリクエストだけです。この例は一般的な推奨設定ではありません。条件が重複するルールをあえて使い、複数のルールに一致する場合に順序が重要な理由を示しています。
GEOIPとIP-CIDR
GEOIPは、宛先IPアドレスのデータベース上の割り当てに基づいて照合します。たとえばGEOIP,CN,DIRECTのように指定します。判定するのはWebページの言語、サイトの登録地、ユーザーの所在地ではありません。ドメインが複数のアドレスを返すことがあり、データベースにも収録範囲や更新の限界があります。同じサイトでもネットワークによってポリシーが変わる場合は、すぐにルールの不具合と決めつけず、実際の宛先IPを比較してください。
IP-CIDRはIPv4アドレスとプレフィックス長を表します。192.168.0.0/16は該当するアドレス範囲全体に一致し、192.168.0.0だけを指定するものではありません。単一のIPv4アドレスは/32で指定できます。IPv6にはIP-CIDR6を使います。IP条件を確認する場合、宛先アドレスがすでに分かっていればその値で判定できます。ドメインだけが分かっているリクエストで、照合のために追加の名前解決を行うかどうかは、ルールのオプションと実際の記録をあわせて確認してください。
[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,PROXYno-resolveは、そのIPルールのためだけに名前解決を能動的に行うことを避ける指定です。すでに確認できる宛先IPを無視するという意味でも、ドメインのリクエストが必ずこのネットワーク範囲ルールに一致するという意味でもありません。LANのサービスにホスト名で接続する場合は、明示的なDOMAINルールも必要になることがあります。ネットワーク範囲を追加する前に、リモートリソースのアドレスと重複していないか確認してください。範囲が広いほど、意図しないリクエストまで含まれる可能性が高くなります。
USER-AGENTとFINALの適用範囲
USER-AGENTは、読み取り可能なリクエストのUser-Agentに一致させるためのものです。アプリの本人確認を確実に行う仕組みではなく、暗号化されたすべてのリクエストからアプリ名を特定できるわけでもありません。該当フィールドがリクエストに含まれるか、内容を確認できるか、値が変わっていないかによって結果が変わります。一定のホスト群を安定して処理したい場合は、まずドメイン条件を確認してください。USER-AGENTのルールが一致しなかったからといって、確認していない範囲まで対象を広げないようにしましょう。
[Rule]
USER-AGENT,ExampleClient*,DIRECT
FINAL,PROXYFINALは、それ以前のルールに一致しなかったリクエストのフォールバックで、通常はRuleの末尾に配置します。エラー処理用のルールではないため、前段で一致したサーバーへの接続が失敗しても自動的に引き継ぐことはありません。FINALを前に置くと、その後にある通常ルールは照合されなくなります。長い設定を確認するときは、まずFINALの位置を特定し、実行したいルールがすべてその前にあるか確認しましょう。先頭から一語ずつ読むより効率的です。
Hostと名前解決の範囲
Hostは「名前にどのアドレスを対応させるか」を設定し、Ruleは「リクエストにどのポリシーを適用するか」を決めます。Hostでアドレスを指定しても、DIRECTになるわけでも、サーバーやネットワーク上の制限を回避できるわけでもありません。マッピングが意図どおりか判断するには、実際のリクエストのホスト名、マッピング後のアドレス、最終的に一致したポリシーの3点を分けて確認してください。アドレスが変わっただけでは、接続全体が正しくなったとは判断できません。
静的マッピングの基本形
[Host]
example.com = 192.0.2.10
api.example.com = 192.0.2.20左側にホスト名、右側にアドレスを指定します。例のアドレスは説明用で、利用可能なサービスを指していません。実際のマッピングを設定する前に、ご自身が管理するネットワークや手元にあるサービス資料でアドレスを確認してください。一度の検索結果だけで長期的に有効だと判断しないようにしましょう。具体的な名前を1つずつ指定すれば、特定の名前へのマッピングをドメイン全体の振り分けと誤解しにくくなります。処理したいホストごとに名前解決の結果を確認してください。
マッピングが変更するのはアドレス情報だけで、Webページ本来のホスト名が別の名前に自動変更されるわけではありません。HTTPSでは証明書の検証とサーバー側のホスト名判定も重要です。宛先アドレスに接続できても、そのアドレスが元のホスト名に正しいサービスを提供していない場合、証明書の不一致、別サイトの表示、接続の切断などが起こる可能性があります。このような場合は、まずマッピングを元に戻して違いを確認してください。アドレスの誤りを隠すために検証要件を緩めないでください。
Hostはサイト全体の固定設定ではない
1つのページから複数のホストにアクセスすることはよくあります。トップページ、画像、API、ログイン、静的ファイルで、同じホスト名を使っているとは限りません。入口のホストをマッピングしても、他のリソースが同じアドレスを使うとは限りません。ページの本文は表示されるのに一部の内容が欠ける場合は、リクエスト記録から失敗したリソースの実際のホスト名を調べ、マッピングとの関係を確認してください。原因を確かめずにマッピングを広げたり、すべてのサブドメインを根拠のない同一アドレスに向けたりしないようにしましょう。
静的アドレスを設定すると、通常DNSが行う接続先の選択も変わります。元の名前解決結果はネットワーク、地域、サービスの状態に応じて変わることがありますが、アドレスを固定すると、その変化はローカルのマッピングに自動反映されません。一時的なトラブル対処では、特定の名前解決結果に問題があるかを確認するために利用できます。長期的に残す場合は、明確な保守根拠が必要です。自分で管理しておらず、アドレスが変わるサービスでは、静的マッピングを恒久的な解決策と考えないでください。
DNS・キャッシュ・リクエスト経路を分けて確認
Hostを変更した直後に古いページを再読み込みしても、新しいリクエストではなく既存の接続が再利用されている場合があります。アプリ、システム、ネットワーク経路にキャッシュが残っている可能性もあります。検証するときは、変更前のアドレスを記録し、該当ページを閉じるか古いリクエストを終了してから、同じホストに再アクセスし、新しい記録を確認してください。記録が変わらない場合は、同じ行を何度も保存するのではなく、現在の設定が有効か、リクエストが想定した経路を通っているかを確認します。
ドメインの名前解決がリモート側で行われる接続や、アプリが独自に名前解決する場合、あるいはIPアドレスを直接使う場合があります。そのため、「Hostにホスト名を記述した」ことと「すべての接続でそのマッピングが使われる」ことは同じではありません。接続の種類に応じて、どの段階で名前とアドレスを確認できるかを調べてください。IPに直接アクセスするリクエストでは、そもそも対応するドメイン名の検索がありません。ドメインマッピングを追加しても、通常は接続先は変わりません。
| 確認できたこと | まず確認する項目 | 次に行うこと |
|---|---|---|
| アドレスが変わらない | 現在の設定、実際のホスト名、既存の接続 | 新しいリクエストを作成して記録を比較 |
| アドレスは変わったが接続できない | サーバーのポート、証明書、ホスト名への対応 | マッピングを削除して比較 |
| ページの一部しか読み込まれない | 失敗したリソースが別のホストを使っているか | リソースごとに原因を特定 |
| ネットワークによって結果が異なる | ルートの到達性とリモート側の名前解決経路 | ほかの条件を変えずに再テスト |
Hostの検証では、変更するホストは1つだけにし、想定アドレスを明確にして、元に戻すための記録を残してください。マッピングを削除して問題が解消した場合、少なくともマッピングが問題に関与していたことは分かります。ただし、アドレスの無効化、証明書の不一致、アクセス経路の不通は区別する必要があります。原因を記録してから設定を残すか削除するか決めてください。一時的な診断設定を長期設定に残すと、数週間後にアドレスが変わったとき原因を追跡しにくくなります。
URL Rewrite
URL Rewriteは、URLの式に一致するリクエストを処理します。よくある用途は、明確に指定したHTTPアドレスをHTTPSにリダイレクトすることです。DOMAINルールの別表記ではなく、PROXY、DIRECT、REJECTのポリシー選択に代わるものでもありません。設定する前に、アクセス先を変更したいのか、接続経路だけを変えたいのかを明確にしてください。特定のドメインに別のポリシーを適用したいだけなら、通常はリダイレクトを追加するのではなくRuleを変更します。
まず範囲を絞ったリダイレクトから試す
[URL Rewrite]
^http://example\.com/$ https://example.com/ 302この例は、照合式、転送先URL、ステータスコードで構成されています。先頭の^は文字列の先頭から照合し、末尾の$は文字列の末尾まで照合することを示します。\.はドメイン内の実際のピリオドを表し、正規表現の任意の1文字を示すピリオドとして扱われるのを防ぎます。この例は指定したホストのHTTPルートパスだけに一致し、302でリダイレクトします。そのホストのすべてのパスやクエリパラメータは対象にしません。
式の範囲を狭くするのは、テスト結果を解釈しやすくするためです。ドメインだけを指定して後続部分を制限しないと、より多くのパスが対象になる可能性があります。転送先をルートパスに固定すると、元のリクエストのパスやクエリ情報が失われることもあります。どの部分を引き継ぐ必要があるかを決めるには、ルートパス、サブパス、クエリパラメータの3種類のリクエストを挙げてから式を設計し、検証してください。最初から広い条件で試行錯誤しないようにしましょう。
リクエストの可視性によって適用範囲が決まる
HTTPのURLと、暗号化された接続内の完全なURLでは、確認できる条件が異なります。宛先のドメインが見えるからといって、HTTPSリクエストのパス、クエリ、User-Agentも読み取れるとは限りません。暗号化された通信の関連情報を処理できるかどうかは、別途確認が必要です。この記事の例は、明確なHTTPリクエストから始めるもので、1つの書き換えを有効にするために証明書の信頼設定を変更したり、復号範囲を広げたりする必要はありません。
ブラウザーが既存のセキュリティポリシーに基づき、HTTPを先にHTTPSへアップグレードする場合があります。そのため実際のリクエストは、アドレスバーに最初に入力した内容と異なることがあります。想定した302が見られなくても、それだけで式の誤りとは判断できません。まず照合対象のHTTPリクエストが実際に送信されたか確認してください。アクセス方法、ブラウザー履歴、サイト側のリダイレクトも観察結果に影響します。検証記録には最初のリクエストと、その後のリクエストチェーンを含めてください。
リダイレクト後は新しいリクエストが発生する
リダイレクトを受け取ると、通常クライアントは転送先URLに新しいリクエストを送信し、そのリクエストについても改めて名前解決とルール処理が行われます。元のリクエストに適用された振り分けルールが、転送先のリクエストにも必ず同じ結果をもたらすわけではありません。リダイレクト先のホスト名が変わる場合は特に、新しいホストが別のDOMAINやDOMAIN-SUFFIXルールに一致しないか、名前解決と接続に問題がないか確認してください。
リダイレクトループは、たとえばローカルルールがHTTPをHTTPSに転送し、サーバーが同じ入口を元のHTTPアドレスに戻すなど、条件の食い違いによって起こることがあります。繰り返し転送される、読み込みに失敗する、ブラウザーでリダイレクト回数が多すぎると表示される場合があります。このようなときは追加した書き換えルールを一度無効にし、元のサイトの動作を確認してから、各段階で返される転送先を調べてください。症状を覆い隠すために、さらに広い書き換えルールを追加しないでください。原因の特定が難しくなります。
| 確認項目 | 記録する内容 | よくある誤認 |
|---|---|---|
| 照合範囲 | プロトコル、ホスト、パス、クエリ | ドメイン一致を完全なURL一致と誤解する |
| 転送先アドレス | 実際のリダイレクト先 | 意図せずパスやクエリが失われる |
| リクエストチェーン | 最初のリクエストと後続リクエスト | 最終ページを最初の処理結果とみなす |
| リダイレクトの繰り返し | 各段階で返される転送先 | サーバー側のリダイレクトを見落とす |
ログイン、フォーム、一時的な認証情報を含むURLを扱う場合は特に注意してください。クエリパラメータに機密情報が含まれることがあるため、テスト記録を共有する前に削除してください。リクエストメソッドとリダイレクトのステータスコードの関係も、アドレスの変化だけでは判断できません。最初の検証では、自分で管理でき、ログイン状態のない一般的なページを選び、式が想定したリクエストだけを処理することを確認してから、実際の用途に適しているか検討してください。
ポリシーとGlobal Routing
ポリシーは一致後にリクエストをどう処理するかを示し、Global Routingは現在の全体的なルーティング状態を示します。トラブルを調べるときは、先にGlobal Routingを確認し、その後でルールのポリシーフィールドを確認してください。順序を逆にすると、Ruleを一つひとつ調べても、現在の処理に想定どおり使われていない設定を検証し続けることがあります。説明上は「設定」「プロキシ」「直接接続」と呼べますが、画面上の項目名はそれぞれConfig、Proxy、Directです。
PROXY、DIRECT、REJECT
PROXYはプロキシ経由の接続を指定するため、利用可能な接続先が必要です。具体的なサーバーアドレスではなく、認証情報を自動で補うものでもありません。DIRECTは宛先に直接接続する指定ですが、「直接」であっても到達できるとは限りません。現在のネットワークのルーティング、DNS、対象サービスの状態が影響します。REJECTは該当リクエストを拒否します。明確にブロックしたい対象に使うもので、失敗後に別の経路を試す指定ではありません。
[Rule]
DOMAIN,api.example.com,PROXY
DOMAIN,printer.example.com,DIRECT
DOMAIN,blocked.example.com,REJECT
FINAL,PROXYこの例のホスト名は、3種類の動作を説明するためのものです。api.example.comは一致後にPROXYを使います。接続に失敗しても、失敗を理由に次のDIRECTへ自動的に進むことはありません。printer.example.comは直接接続しますが、成功するかどうかは名前解決の結果と現在のネットワークから到達できるかによります。blocked.example.comは明示的に拒否されるため、失敗はポリシーどおりの結果であり、サーバーの故障ではありません。
3種類の全体モードを比較する
| 画面上の項目名 | 説明 | 主な確認対象 |
|---|---|---|
| Config | 設定 | 現在の設定に基づく振り分け結果 |
| Proxy | プロキシ | 既存サーバーへの接続経路 |
| Direct | 直接接続 | 現在のネットワークでの直接接続の状態 |
ProxyではアクセスできるのにConfigでは失敗する場合、Configで実際にどのポリシーが適用されたかを確認してください。ただし、すぐにルールキーワードの誤りと決めつけることはできません。2つのモードでは、名前解決の場所、宛先アドレス、接続経路が異なる場合があります。確実に比較するには、ホスト名、実際のアドレス、適用されたポリシーを記録し、どの段階から差が生じたかを確認してください。ページが開いたかどうかだけでは判断できません。
Directでは失敗し、Proxyでは成功しても、設定全体をPROXYに変更すべきとは限りません。LAN機器、現在のネットワーク内でのみ公開されているサービス、その他の特定のリソースでは、引き続きDIRECTが必要な場合があります。Global Routingの一時的な切り替えは問題の範囲を絞るのに役立ちます。長期的なポリシーは、リソースの要件を理解した上でRuleに記述してください。比較が終わったら元のモードに戻し、以後のルールを誤った状態で検証しないようにしましょう。
ポリシー名と実際の接続能力を分けて確認
設定によっては独自のポリシー名が使われています。このようなファイルを読む際は、英語のラベルに見える値をすべて組み込みポリシーとみなさないでください。現在の設定内にその名前の定義があるか、どの接続先を指すか、その接続先がまだ存在するかを確認します。基本的な振り分けを学ぶ段階では、複雑な選択関係を同時に導入するより、PROXY、DIRECT、REJECTで流れを把握するほうが確認しやすくなります。
接続先が利用できない場合でも、ルール自体は正しく一致することがあります。認証情報の変更、サーバーアドレスへの一時的な到達不能、サーバー側で現在のパラメータに対応していないことなどがあれば、「適切なポリシーを選んだのに接続できない」状態になります。この場合、DOMAINの照合範囲を変更してもサーバーは修復されません。手元にあるサービス情報でアドレス、ポート、認証情報を確認し、Connectivity Testを実行した上で、実際のサービスリクエストの結果とは分けて記録してください。
同様に、Connectivity Testの成功は、テストに含まれる経路の一部で応答が得られたことを示すだけです。すべての宛先、プロトコル、サービス操作が成功するとは限りません。Webリクエスト、長時間接続、その他の通信方式では条件が異なることがあります。特定のサービスだけが失敗する場合は、そのサービスが使用するホスト名とリクエストの種類を調べてください。テストが一度成功しただけで、サーバー側や宛先側の問題を完全に除外しないようにしましょう。
既存のサブスクリプション内のサーバーとローカルルールも、別々に管理するものです。サブスクリプションを更新すると選択できる接続先が変わることがありますが、ローカルルールの順序が修復されるわけではありません。Ruleを編集しても、期限切れのサーバーパラメータは更新されません。更新操作の違いについてはサブスクリプション更新と接続失敗の原因をご覧ください。サーバー情報の変更と設定ファイルの変更を混同せずに済みます。
ルールの適用順と優先順位
Ruleの基本は上から順に確認し、最初に一致したルールのポリシーを適用することです。「より具体的なルールを優先する」は設定を記述するときの指針であり、自動的に並べ替えられる仕組みではありません。DOMAINは、より正確だからといって前のDOMAIN-SUFFIXを飛び越えません。IP-CIDRも後続のドメイン条件に自動的に優先されることはありません。意図した優先順位にするには、対象を広く含む条件より前に例外を記述します。
同じリクエストで上から順に確認する
[Rule]
DOMAIN,api.example.com,PROXY
DOMAIN-SUFFIX,example.com,DIRECT
DOMAIN-KEYWORD,example,REJECT
GEOIP,CN,DIRECT
FINAL,PROXYapi.example.comの場合、1行目に完全一致するため、それ以降のドメインサフィックス、キーワード、アドレスの割り当て、FINALはポリシーを決定しません。www.example.comの場合は1行目に一致せず、2行目のサフィックス条件に一致してDIRECTになります。最初の2行に一致しない場合に限り、3行目のキーワード条件が有効になります。順に確認するときは、「条件に一致するか」と「一致後に何をするか」を2列に分けて記録し、キーワードの印象だけで行を飛ばさないようにしましょう。
2行目を1行目より前に移すと、api.example.comはサフィックスルールに先に一致し、元の完全一致の例外は機能しなくなります。これはDOMAINの照合能力が変わったのではなく、確認順が変わった結果です。この仕組みが分かると、「追加したルールがまったく効かない」ときは、ファイルの末尾に同じ条件を繰り返し追加するのではなく、上にそのリクエストを処理するルールがないか確認できます。
範囲の広いルールと狭いルールの配置
一般的には明確な例外を先に置き、次にドメイン群や範囲の広い条件、その後に必要なIPルールを置き、末尾にFINALを残します。ただし、すべての状況に当てはまる固定順ではありません。管理しているネットワーク範囲を必ず先にDIRECTにする必要がある場合は、関連する広い条件より前に置くことがあります。重要なのは、要件を明確にし、具体的なリクエストで条件が重複するか確認することです。決まった並べ方を機械的に当てはめないでください。
同じ宛先がドメイン条件とIP条件の両方に一致することがあります。たとえば、指定したドメインサフィックスに属し、名前解決後のアドレスがGEOIPの範囲に入る場合です。どのルールが適用されるかは、実際に利用できる情報とルールの順序によって決まります。IPルールにno-resolveを追加した場合は、ドメインしか分からない状況で追加の名前解決が行われるかも確認してください。記述上の順序と、その時点で利用できないリクエスト情報を混同しないようにしましょう。
FINALは2回目のチャンスではない
FINALが処理するのは、それ以前のルールに一致しなかったリクエストだけです。ルールがPROXYを選択した後でサーバー接続に失敗しても、「ルールに一致しなかった」ことにはならず、Ruleの次の行にあるDIRECTやFINALへ進むこともありません。予備の接続手段が必要な場合は、該当する接続設定やポリシーが実際にどう対応しているか確認してください。エラーからの復旧を期待してFINALを繰り返し追加しても解決しません。Ruleは接続先の選択を担い、接続失敗は選択後の段階で起こります。
トラブル対処では、「想定したルールに一致しなかった」場合と「想定したルールに一致したが実行に失敗した」場合を区別してください。前者ではホスト名、ルールの種類、順序、現在の設定を確認します。後者では接続先、名前解決の結果、対象サービスを確認します。この2種類を混同すると、振り分け範囲を変更しながら偶然リクエスト経路まで変えてしまい、最終的に一度成功しても原因を説明できなくなります。
| 現象 | よくある原因 | 確認すること |
|---|---|---|
| 完全一致の例外が有効にならない | 上の広いルールに先に一致している | 重複する条件を確認して順序を調整 |
| 末尾に追加したルールが効かない | ルールがFINALより後ろにある | 照合される範囲内へ移動 |
| サーバー接続に失敗してもDIRECTにならない | ルールの順序を失敗時の再試行と誤解している | 接続先と実行段階を確認 |
| 同じドメインでも結果が変わる | 宛先IPまたは確認できる情報が変化している | ドメイン名だけでなくリクエスト記録を比較 |
長いルールを管理するときは、各例外がどの広いルールを上書きするのか、その理由とあわせて記録しておくと便利です。重複行を削除する前に、ドメインだけでなく全フィールドを比較してください。同じドメインでもポリシーが異なる場合や、同じネットワーク範囲でもオプションが異なる場合は、無意味な重複とは限りません。整理後は事前に選んだ代表的なリクエストでテストします。少なくとも、完全一致の例外、通常のサブドメイン、FINALに一致する対象を含めてください。
記述例と変更手順
以下では要件ごとに設定例を分けて紹介します。各例は主な目的を1つだけ示すもので、すべてを組み合わせればどのネットワークでも使える設定になるわけではありません。使用前に自分が処理したい対象に置き換え、既存のサーバー情報を残した上で、現在のファイルに先に一致するルールがないか確認してください。既存の設定にFINALがある場合は、必要な例外を既存の末尾ルールより前に配置し、重複するルール一式をさらに付け足さないようにしましょう。
同じドメイン内での完全一致の例外
[Rule]
DOMAIN,api.example.com,PROXY
DOMAIN-SUFFIX,example.com,DIRECT
FINAL,PROXYここでは特定のAPIだけにPROXYを使い、同じドメイン内の他のホストにはDIRECTを適用します。重要なのは、範囲を狭く指定してから広げることです。api.example.comと、実際に存在する別のサブドメインにそれぞれアクセスし、異なるポリシーが適用されることを確認してください。APIへのアクセスが成功しただけでは、例外ルールが正しいとは限りません。Global RoutingがProxyでも成功するため、サフィックスルールが処理に使われている証拠にはならないからです。
APIからリダイレクトが発生する場合や、ページが別のドメインを呼び出す場合は、後続のリクエストも確認してください。最初のリクエストが完全一致の例外に一致しても、その1回の処理が正しかったことしか分かりません。複数のホストが連携するサービスでは、実際の記録に基づいて1つずつ整理してください。入口として見えるホスト名がすべてのリソースを網羅しているとは限りません。対象を広げる前に、新たに加えるホストが必要なサービスに属することも確認しましょう。
LANのアドレス範囲とホスト名を分けて設定
[Rule]
DOMAIN,printer.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ここではホスト名とアドレス範囲について、別々に直接接続を指定しています。ホスト名は例なので、実際にはご自身が管理する環境の名前を入力してください。no-resolve付きのネットワーク範囲ルールがあるからといって、すべてのドメインが必ず名前解決後に一致するとは限りません。そのためLAN内の名前は個別に指定できます。テスト前に、対象機器へアクセスできるネットワークに接続していることも確認してください。DIRECTは別の場所にあるLANへのルートを作成しません。
同じアドレス範囲が、管理下の別のネットワークでも使われている場合、ネットワーク範囲ルールが用途の異なる対象に一致する可能性があります。特に複数のネットワークでプライベートアドレスが重複している場合、アドレスが「内部ネットワークらしい」というだけで経路を決めないでください。アクセスしたい機器、実際のネットワーク、宛先アドレスを先に書き出し、必要な範囲に絞ります。最初から広い範囲を指定するのではなく、単一の機器なら、より限定されたプレフィックスを検討してください。
アドレスの割り当てに基づく振り分けと末尾のフォールバック
[Rule]
DOMAIN,api.example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXYこの例では、完全一致の例外、アドレスの割り当て条件、フォールバックを指定しています。Webサイトの内容や言語に基づく分類ではありません。アドレスが分散しているサービスでは、名前解決後のIPが変わるとGEOIPの判定も変わる可能性があります。テストではURLだけでなく、実際のアドレスも記録してください。要件が特定のドメイン群を対象とするものであれば、明示的なドメインルールのほうが説明しやすい場合がありますが、利用するリソースとネットワーク環境に応じて判断してください。
FINALにPROXYを指定する場合も、ユーザーが利用可能なサーバーを持ち、一致しないリクエストをその経路に通す意図があることが前提です。運用上の目的が異なる場合は別のフォールバックを選べますが、それまで個別に指定されていなかった多くのリクエストに影響する点を理解してください。FINALの変更は影響範囲が大きいため、1つのページが開くかどうかだけで評価せず、日常的に利用する代表的なリソースもあわせて検証してください。
保存・編集・検証・復元
- 現在の設定ファイルを保存し、選択中のファイル、Global Routing、接続先を記録します。
- 「特定のホストをDIRECTからPROXYに変更する」など、検証可能な要件を1つ書きます。
- 既存のルールを検索し、そのホストに最初に一致する可能性のある条件を見つけて挿入位置を決めます。
- 1か所だけ変更して保存し、現在の設定が引き続きこのファイルであることを確認します。
- 新しいリクエストを作成し、一致したルール、宛先アドレス、ポリシー、実際の結果を確認します。
- 結果が想定と違う場合は元の内容に戻し、同じ対象を再テストして差分を記録します。
復元用ファイルを自動更新中の設定元と混同しないでください。サブスクリプションやリモート設定を更新した後は、カスタムルールが想定した位置に残っているか、ルールが参照する接続先に変更がないかを再確認します。更新完了は取得処理の終了を示すだけで、機能の検証に代わるものではありません。変更が多い場合は、一度に設定全体を上書きするより、動作する状態を段階ごとに保存したほうが、問題が入り込んだ箇所を見つけやすくなります。
検証とトラブルの切り分け
検証の目的は、接続スイッチがオンになっていることだけを確認することではありません。具体的なリクエストが想定した設定で処理され、想定した条件に一致し、対応する経路で結果を得られるかを確認します。テスト対象を1つに決め、「サーバー、Global Routing、DNS、ルール、対象サービス」の順に確認してください。各段階で確認できた事実と、まだ除外できない要因を記録します。同じテスト中にサブスクリプションの更新、サーバーの変更、DNSの変更を同時に行わないでください。
接続先から実際のリクエストまで順に確認
まず、手元にあるサーバーのアドレス、ポート、認証情報、プロトコル設定を確認し、Connectivity Testで基本的な疎通状況を調べます。テストに失敗した場合は、Ruleの順序をすぐに変えるのではなく、現在のネットワークとサービス情報を確認してください。テストが応答したら、実際のサービスリクエストを送信し、特定のホストだけが失敗していないか観察します。基本テストと実際のサービスリクエストは異なります。前者が応答したからといって、後者に必要な経路やパラメータがすべて正しいとは限りません。
次にGlobal Routingを確認します。現在のモードがProxyまたはDirectの場合は、状態を記録してからConfigに切り替え、ルールを検証してください。Configで問題が発生する場合は、実際のリクエストのホスト名と宛先アドレスを見て、想定したテスト対象と一致しているか確認します。ページがリダイレクトされたり、独立したAPIを呼び出したりすることがあります。エラーが起きたホストはアドレスバーに表示されているホストとは限りません。入口のドメインにルールを追加し続けないようにしましょう。
記録で3種類の失敗を見分ける
1つ目は、ルールが想定どおりに一致しないケースです。現在の設定が違う、照合内容が誤っている、上のルールが先に処理している可能性があります。2つ目は、ポリシーは正しいのに接続できないケースです。サーバーへの到達性、アドレス、対象サービスを確認してください。3つ目は、名前解決の問題です。ドメインがアドレスに解決されるか、アドレスが想定どおりか、Hostが結果を上書きしていないかを比較します。3種類を分けると、変更すべき範囲を絞りやすくなります。
記録にREJECTがある場合は、まず設定に戻って該当条件を見つけ、その対象を本来ブロックする意図があったか確認してください。DIRECTと表示されている一方で、手元にあるリモート接続経路を通じてしかアクセスできない対象の場合は、ポリシーの意図を確認します。PROXYと表示されていてサーバー認証に失敗する場合は、まず手元にあるサービス情報を確認してください。エラーメッセージは原因を探る手がかりにはなりますが、実際に一致したルールや接続先の確認を省くことはできません。
On Demandとルールによる振り分けを分けて検証
On Demandは条件に応じて接続または切断を行い、Ruleは接続中のリクエストを処理します。自動接続が作動しない場合、最初にドメインルールの誤りと決めつけないでください。現在のネットワークがOn Demandの条件を満たしているか、実際に接続が確立しているかを確認します。反対に、接続済みでもすべてのリクエストがPROXYを使うとは限りません。Configでは一部のリクエストがDIRECTまたはREJECTに振り分けられることがあります。
自動動作を検証する場合は、まず手動で接続し、同じ設定でリクエストが正しく処理されることを確認します。その後、ネットワークを切り替えたときの作動を個別にテストしてください。切り替え前後のネットワーク、接続状態、リクエスト時刻を記録し、On Demandの条件とRuleを同時に変更しないようにしましょう。具体的な条件についてはWi-Fi・モバイル通信・ドメイン条件によるOn Demandの設定をご覧ください。バックグラウンド接続の選択についてはバックグラウンドでのバッテリー消費と常時接続をご覧ください。
よくある確認事項
ルールを変更しても結果が変わらない場合、まず何を確認しますか？
現在選択されているConfigファイル、Global RoutingがConfigになっていること、上のルールに先に一致していないこと、新しいリクエストでテストしていることを順に確認します。内容を保存する操作と設定を選択する操作は別です。既存の接続が使われている場合、画面を更新しただけでは新しいルールの有効性を判断できません。
PROXYに一致したのにアクセスできないのはなぜですか？
ルールへの一致は選択段階が実行されたことを示すだけで、接続に成功したことを意味しません。接続先、認証情報、名前解決のアドレス、対象サービスを確認してください。リクエストの失敗後に次のRuleやFINALへ自動的に進むことはありません。詳しい確認手順は接続スイッチがオンなのにインターネットに接続できない場合のチェックリストをご覧ください。
サブスクリプションを更新したら、既存のルールも再確認が必要ですか？
ルールが参照する接続先が引き続き存在するか、リモート設定の更新によってローカルの変更が置き換わっていないか確認してください。サーバー情報とルールファイルでは更新範囲が異なります。更新後は、完全一致の例外、通常の照合対象、FINALに一致する対象をそれぞれ再テストしてください。
アプリを購入すれば接続できるようになりますか？
クライアントアプリの買い切り購入 ≠ 接続サービスの契約。購入後も、ご自身のサブスクリプションまたはサーバー情報が必要です。アプリの入手先はApp Storeのみです。デベロッパがShadow Launch Technology Limitedであること、公式アイコン、アプリID 932747118を確認してください。手順はApp Storeでのダウンロードと購入方法をご覧ください。
トラブル対処の記録を共有する前に、サブスクリプションの完全なURL、認証情報、個人のネットワーク名など、機密情報を削除してください。通常は、個人情報を伏せたホスト名、ルールの種類、ポリシー、エラーが発生した段階を残せば説明できます。トラブル対処が終わったら、一時的に変更したGlobal Routingを元に戻し、不要になったHostや書き換えテスト項目を削除して、検証済みの設定をもう一度保存してください。同様の問題が起きたときは、この基準状態と比較してから項目ごとに再テストできます。