Shadowrocket
設定・ルールガイド
General · Rule · Host · URL Rewrite
このページでは、設定構造や各項目の役割、ルール分岐の範囲を体系的に確認できます。初めて使う場合は、まずクイックスタートに沿って、手元にあるサブスクリプションの追加、サーバーの選択、接続、動作確認を済ませてから、該当する章に戻って設定を変更してください。すでに接続できる場合は、目次から問題に関連する項目を直接確認できます。2つのページは、操作の手順と設定項目のリファレンスをそれぞれ扱っており、初回接続前にすべて読む必要はありません。
この記事は、ご自身のサブスクリプションまたはサーバー情報をお持ちであることを前提としています。ShadowrocketはAppleプラットフォーム向けの有料クローズドソースアプリです。アプリの買い切り購入は、接続サービスの契約とは別です。当サイトでは接続先やサブスクリプションの提供、販売、推奨は行っていません。購入とインストールについてはApp Store正規版のダウンロードガイドをご覧ください。システム要件はApp Storeページの記載をご確認ください。
設定ファイルの構造と適用範囲
サーバー情報と設定ファイルを区別する
サーバー情報には、リモート接続に必要なアドレス、ポート、プロトコル、認証項目が記載されています。一方、設定ファイルはリクエストの処理方法、使用するルール、ドメインの解決方法を定めます。サブスクリプションをHomeに追加しても、Configのルールファイルが置き換わるわけではありません。反対に、Ruleを含むファイルを追加しても、ご自身のサーバー認証情報が自動で補われることはありません。トラブル対処では、まずこの2つを確認し、違う場所を繰り返し変更しないようにしましょう。
Configで現在選択されている設定を確認し、編集内容を開きます。追加、保存、選択はそれぞれ別の操作です。リストにファイルが表示されているのはファイルが存在する証拠にすぎず、エディタに新しい内容が表示されているのも、そのファイルを閲覧中だということしか示しません。接続を制御しているかどうかは、現在選択されている設定で確認してください。変更前にファイル名と選択状態を記録し、保存後にもう一度確認します。必要に応じて接続をいったん切り、再接続してから新しい設定でテストしましょう。
4つのセクションの役割
セクション名は角括弧で囲み、各項目やルールは該当するセクションの下に記述します。Generalは共通設定、Ruleはリクエストの照合とポリシー、Hostは静的なドメインとアドレスの対応付け、URL Rewriteは条件に合うURLの書き換えを担当します。それぞれの役割は置き換えられません。ドメインマッピングをRuleに書いてもHostとして機能せず、リダイレクト式をGeneralに書いても実行可能な分岐ルールにはなりません。セクション名とルールキーワードは英語表記のまま使用します。
| セクション | 対象 | 代表的な記述 |
|---|---|---|
[General] | 共通動作と名前解決の設定 | dns-server = system |
[Rule] | リクエストのポリシー選択 | FINAL,DIRECT |
[Host] | ドメインとアドレスのマッピング | localhost = 127.0.0.1 |
[URL Rewrite] | 表示されるURLの照合と書き換え | 正規表現、転送先URL、ステータスコード |
[General]
bypass-system = true
skip-proxy = 192.168.0.0/16, 10.0.0.0/8, localhost
dns-server = system
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
FINAL,DIRECT
[Host]
localhost = 127.0.0.1
[URL Rewrite]
^http://example\.com/ https://example.com/ 302この例では、どのルールにも一致しないリクエストをDIRECTに渡し、例示用ドメインだけにPROXYを適用します。汎用的なプロキシ設定ではありません。コピーする前に、末尾のポリシーを理解してください。Generalのスキップ範囲も後続の処理経路に影響します。リクエストが先の段階ですでにプロキシを迂回している場合、Ruleの行を移動するだけではルール照合に戻せません。
編集・保存・バックアップの基本手順
まず現在使えているファイルを残し、実験用にコピーを作成します。一度に変更するのは1つのセクションまたは1つのルールだけにし、保存後に再選択してテストしてください。ファイルがリモートURLから取得されている場合は、次回の更新でローカルの変更が上書きされないかも確認します。変更を長期的に保持するには、一時的な差分に頼らず、個別に管理できるローカルコピーに保存しましょう。バックアップ名は用途が分かるものにし、アカウント名、サーバーアドレス、認証情報は含めないでください。
ルールのパラメーターはカンマで区切り、共通項目やHostのキーと値は等号で区切ります。日本語の句読点、説明文、Webページからコピーした際に混入する特殊な空白は設定に含めないでください。複数行の例で改行は実際の改行です。表示上の折り返しではありません。エディタで1行が長く表示される場合は横方向に確認し、ルールをむやみに複数行に分割しないでください。コメントは#で始まる独立した行に記述し、ポリシーの後ろに説明を追加しないようにします。
ファイルを保存できても、意味がすべて正しいとは限りません。スペルが正しくても範囲が広すぎるDOMAIN-KEYWORDは、正常に実行されながら無関係なリクエストまで照合することがあります。有効なFINALも、早すぎる位置にあると後続のルールを遮る可能性があります。確認では構文、選択状態、実際のリクエスト結果をすべて確認してください。エディタにエラーが表示されないことだけでは不十分です。
Generalの項目とDNSの処理
Generalは単なるルールの前置きではない
Generalは、一部のリクエストが処理フローに入る方法や、ドメイン名の解決元を決定します。Ruleを確認する前にここを確認してください。接続がプロキシ処理に入るか、アドレスを取得済みか、照合に使えるドメイン情報が残っているかによって、後続の結果が変わることがあります。Generalを固定のテンプレートとして扱わないでください。あるLAN向けに設定したスキップ範囲も、別のネットワークでは適切でない場合があります。
bypass-system = trueは、該当するシステム通信をプロキシ処理から迂回させます。「すべてのリクエストを直接接続する」スイッチではなく、Global RoutingのDirectと同じ意味でもありません。この設定を使う場合は、対象のシステムリクエストが通常のルール経路を通らない場合があることを理解してください。システム機能に問題があるときは、具体的なリクエストとネットワーク環境を確認します。1つのWebページのテスト結果から、すべてのシステム通信の動作を推測しないでください。
skip-proxyは、プロキシ処理をスキップする対象範囲を指定します。対象として多いのはLANアドレスやローカルホスト名です。ここでのスキップと、RuleでDIRECTを指定するのとでは処理段階が異なります。DIRECTはリクエストがルール処理に入った後に選択されるポリシーです。スキップでは通常のプロキシルール経路を通らない場合があります。ログに想定したRuleのヒットがない場合、同じルールをファイルの先頭に複製するのではなく、まずスキップリストを確認してください。
[General]
bypass-system = true
skip-proxy = 192.168.0.0/16, 10.0.0.0/8, localhost
dns-server = systemsystemの意味とテストの基準
dns-server = systemは、システムが提供するDNSを使うことを意味し、特定のDNSサーバーを固定する設定ではありません。Wi-Fiやモバイルネットワークを切り替えると、システムが取得するDNS設定も変わることがあります。LAN内の名前は、現在のネットワークのDNSでしか解決できない場合もあります。まずsystemを基準として既存ネットワークで対象を解決できるか確認し、その後、必要であればご自身の環境に応じて別のDNSを指定してください。
DNSは名前をアドレスに変換し、ルールはリクエストのポリシーを決めます。両者は関連しますが、同じ機能ではありません。DOMAINルールは既知のドメイン名で照合できますが、GEOIPやIP-CIDRはアドレスを対象とするため、名前解決の結果が必要になる場合があります。ログに名前解決の失敗が表示されているなら、必要なアドレスをまだ取得できていない状態です。すぐにPROXYサーバーの利用不可と判断したり、FINALを追加して未取得のアドレスを解決しようとしたりしないでください。
アプリのリクエストとDNS問い合わせを区別することも重要です。WebページがPROXYで開けても、すべてのDNS問い合わせが同じ経路を通っているとは限りません。実際の名前解決は、アプリ、システムキャッシュ、設定項目にも左右されます。正確に判断するには、ルール行のポリシー名からDNSの経路を推測せず、実際のログと現在の設定を確認してください。サーバーのホスト名を使う場合は、接続先サーバー自体を名前解決できることも確認します。接続の入口で起きた失敗を、対象Webサイトのルール分岐の失敗と取り違えないようにしてください。
DNS変更前後の確認ポイント
外部ドメインは解決できるのに内部ドメインを解決できない場合は、内部DNSを提供するネットワークから離れていないか確認します。すべての名前解決に失敗し、既知のアドレスへ直接アクセスできる場合は、DNSの参照先を重点的に確認してください。DNS、サーバー、Ruleを同時に変更すると、接続が戻ってもどの変更が有効だったのか分かりません。毎回1つだけ変更し、同じネットワークと対象で新しい接続を使って再テストし、結果を記録してください。
DNSキャッシュの影響で、変更結果がすぐに反映されないことがあります。システム、クライアント、アプリが以前の結果を保持している場合があり、ブラウザも既存の接続を再利用することがあります。設定を保存してページを更新するだけでは、新しい名前解決が行われない場合があります。古い接続を切って再接続し、対象アプリを開き直してください。それでも異常が続き、必要性が明確な場合に限り、システムのネットワーク状態をさらに確認します。キャッシュからの応答1回だけで、新しい設定を検証できたと判断しないでください。
IPv4とIPv6も分けて確認してください。ドメインが両方のアドレスを返し、ネットワークによっては一方への到達性が低いため、名前解決は成功しても接続がタイムアウトする場合があります。その場合は、解析元を機械的に変更するのではなく、実際に使用されたアドレスと一致したルールを確認します。出所の分からない項目を増やすより、動作する基準設定を残し、「名前、アドレス、ポリシー、接続結果」の4点を対応付けてください。
DOMAIN系ルールの範囲
完全一致とドメインサフィックス
DOMAINは指定したドメイン名に一致し、特定のホスト名だけを処理したい場合に適しています。たとえばapi.example.comだけをPROXYにし、同じサイトのほかの名前には影響させない場合は、完全一致のルールを優先してください。パラメーターにはドメイン名だけを指定し、プロトコル、パス、ポート、クエリ文字列は含めません。完全なWebアドレスをDOMAINに指定しても、より細かい条件になるわけではありません。ルールが照合する対象とは異なります。
DOMAIN-SUFFIXはドメイン階層のサフィックスで照合します。example.comを指定すると、そのドメイン自体とwww.example.com、api.example.comなどのサブドメインが対象になります。任意の文字列の末尾を境界なしで照合するものではありません。ドメインの階層を区切るドットが重要です。通常、サフィックスにはドメイン名をそのまま指定し、アスタリスクを手動で追加する必要はありません。URLのパスも末尾に付けないでください。
[Rule]
DOMAIN,api.example.com,PROXY
DOMAIN-SUFFIX,example.com,DIRECT
FINAL,DIRECTこの順序ではapiの完全一致ルールが先に適用され、その後にほかのexample.comへのリクエストが対象になります。DOMAIN-SUFFIXを先に置くと、apiのリクエストも範囲の広いルールに先に一致します。後ろのDOMAINが「より具体的だから優先される」ことはありません。具体性はルールを並べるときの判断基準であり、ルールエンジンが自動で並べ替える基準ではありません。
キーワードルールを慎重に使う理由
DOMAIN-KEYWORDはドメイン名に含まれるキーワードで照合し、文字列ベースの範囲指定が本当に必要な場合に使います。サイトの所有者を識別したり、その単語が特定のサービスを指すか判断したりする機能はありません。exampleは異なる階層やサフィックスの名前に含まれる可能性があり、DOMAIN-SUFFIXより広い範囲に一致することがあります。明確なドメイン名やサフィックスで表現できる場合は、範囲を確認しやすいルールを優先してください。
| 種類 | パラメーター例 | 選び方 |
|---|---|---|
DOMAIN | api.example.com | 特定のホストだけに例外を設ける |
DOMAIN-SUFFIX | example.com | 同一ドメインとサブドメインに同じポリシーを適用する |
DOMAIN-KEYWORD | example | キーワードを含む名前を対象にする必要がある |
[Rule]
DOMAIN,login.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,example,PROXY
FINAL,DIRECTここでキーワードルールを示しているのは範囲の違いを説明するためであり、実際のファイルに3種類すべてを記述する必要はありません。ログイン用のホスト名にはDIRECTを適用し、続いてドメインとサブドメインにはPROXYを適用します。キーワードを含むほかの名前は3行目で処理されます。実際の設定では、明確な必要性のない広範囲のルールを削除し、誤照合とトラブル対処の手間を減らしてください。ルールを増やせば設定が正確になるとは限りません。
ドメインルールの照合に必要な情報
ドメインルールを使うには、リクエスト処理時に利用できるドメイン情報が必要です。アプリがIPアドレスに直接接続する場合や、該当する処理段階で元のドメイン名と関連付けられない場合、ルールエンジンはアドレスルールの確認に進むことがあります。ブラウザのアドレスバーにドメイン名を入力したからといって、その後のすべての接続に同じ名前が保持されるとは限りません。ページが画像、API、フォントなど別のドメインからリソースを読み込む場合もあります。
トップページは開くのに一部のリソースだけ失敗する場合は、トップページの名前にルールを追加し続けるのではなく、ログから実際に失敗したリクエストのドメインを探してください。1つのWebページが複数のドメインに依存していることがあります。それらすべてに同じポリシーを適用するかどうかは、実際のリクエストを確認して判断します。手間を省くために短いキーワードを似た名前全体に広げたり、あるアクセスが成功しただけで必要な依存先をすべてカバーしたと判断したりしないでください。
テストでは、ルールに一致すべき名前と一致しないはずの名前を1つずつ用意し、それぞれのポリシーを確認します。前者ではルールの適用を、後者では範囲が広すぎないかを確認できます。DOMAIN-SUFFIXを使う場合は、ルートドメインとサブドメインの両方を確認してください。DOMAINの場合は、隣接するサブドメインが誤って対象にならないことを確認します。成功したページを1つだけテストするより、このように一致する対象としない対象の両方を試す方が、範囲の誤りを見つけやすくなります。
ドメイン名の大文字・小文字は、通常トラブル対処の中心ではありませんが、設定パラメーターの表記は統一すると確認しやすくなります。国際化ドメイン名、特殊な名前、アプリが実際に使用する正規化後の形式は、ログに表示される照合対象を基準にしてください。Webページに表示された名称からルールのパラメーターを推測しないでください。ページタイトルやリンクの文字列と、実際に接続するホスト名は異なる場合があります。変更後はテスト内容を記録しておくと、次回、原因がルールの変更かリクエスト対象の変化かを判断しやすくなります。
IP-CIDR、IP-CIDR6、GEOIP
アドレス範囲はドメインの分類ではない
IP-CIDRはIPv4のアドレス範囲を対象とし、ネットワークアドレスとプレフィックス長で指定します。192.168.0.0/16は単一のホストではなく、そのプライベートアドレス範囲を表します。1つのIPv4アドレスだけに一致させる場合は、該当するアドレスに/32を付けます。ルールを作成する前に、実際の対象アドレスとサブネットマスクを確認してください。ルーターのアドレスをネットワーク全体と取り違えたり、1台を対象にするためにすべてのプライベートアドレスへ範囲を広げたりしないでください。
IP-CIDR6はIPv6アドレス範囲を対象とし、同様にプレフィックス長で範囲を決定します。fc00::/7はIPv6のユニークローカルアドレス範囲を表し、::1/128はループバックアドレスだけを表します。IPv4とIPv6のルールは互いに置き換えられません。ドメインが両方のアドレスを取得する場合、IPv4の範囲を指定してもIPv6接続は自動的に制御されません。トラブル対処では、ログに記録された実際のアドレスの種類を確認してください。
[Rule]
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
IP-CIDR6,fc00::/7,DIRECT,no-resolve
FINAL,PROXYこの例では、指定したローカルアドレス範囲にDIRECTを適用し、それ以外のリクエストはPROXYに渡します。すべての特殊用途アドレスを対象にするものではなく、Generalのスキップ設定に代わるものでもありません。「ローカルネットワークは直接接続」と読んでも、すべてのLAN内の名前にアクセスできるわけではありません。名前が正しいアドレスに解決され、ネットワークが該当デバイスへの接続を許可し、対象サービスも利用可能である必要があります。
no-resolveが制御するのは名前解決の実行
no-resolveは、このアドレスルールとの照合のためだけに追加の名前解決が行われるのを防ぎます。DIRECTの別名でも、設定全体でDNSを無効にする指定でもありません。リクエストに照合可能なアドレスがすでに含まれていれば、そのアドレスで引き続き判定できます。一方、ドメイン名しかなく、必要なアドレスも未取得の場合、このルールが名前解決を行ってから一致するとは限りません。追加するかどうかは、照合したいリクエストの形式に応じて判断してください。
もともとIPアドレスでアクセスするLAN内のデバイスには、no-resolve付きのネットワークルールが分かりやすい場合があります。内部名を使ってアクセスする場合は、名前解決によってローカルアドレスを取得できるかも確認してください。「名前解決を減らす」ためにすべてのアドレスルールへこのパラメーターを追加すると、解析結果に依存していた照合経路が変わることがあります。結果に差が出た場合は、最終的にWebページが開いたかだけでなく、そのルールを確認した時点でリクエストにアドレスがあったかを確認してください。
GEOIPはアドレスデータベースによる判定
GEOIPはIPアドレスのデータベース上の帰属情報に基づいて判定します。GEOIP,CN,DIRECTは一般的な構文例です。Webページの言語、ドメインのサフィックス、アカウントの地域、ユーザーの所在地で分類するものではありません。日本語や中国語のページでも、異なる地域に帰属する複数のアドレスを使うことがあります。同じドメインでも、分散型サービスから返されるアドレスは異なる場合があります。そのためGEOIPは広範囲のアドレス分類には使えますが、特定サービスが必ず直接接続できることを示すものではありません。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYGEOIPより前にドメインの例外を配置すると、その名前に明示したポリシーを先に適用できます。その後、アドレス範囲や地域情報で残りのリクエストを処理し、最後にFINALで受けます。必要なドメイン例外より前にGEOIPを置くと、アドレス条件を満たしたリクエストは先にアドレスルールに一致する場合があります。「ドメインを優先」するには順序で表現します。ルールの種類によって自動的に優先されるわけではありません。
データベース上の地域情報と、その時点のネットワーク到達性に必然的な関係はありません。GEOIPに一致して接続できない場合は、ローカルネットワークから対象へ到達できない可能性や、対象サービス側の問題が考えられます。データベースの構文が無効だとは限りません。安定した例外が必要なら、確認可能なドメインに基づく具体的なルールを作成してください。テスト時に一時的に返されたアドレスを、広いアドレス範囲の恒久的な例外にしないでください。
アドレスルールの確認は、接続の再利用に影響されることがあります。ネットワーク範囲のポリシーを変更しても、アプリが既存の接続を使い続けると、新しい照合ログが記録されない場合があります。接続を新しく確立し、対象IP、ルールの種類、最終的なポリシーを確認してください。同じ名前の名前解決結果が毎回異なる場合は、何度もFINALを移動するのではなく、アドレスプールの変化かルール範囲の不足かを判断できるよう、結果の違いを記録しておきましょう。
ポリシー、Global Routing、照合順序
設定内のポリシーと画面のモードを分けて確認
ルールに記述するPROXY、DIRECT、REJECTはリクエスト処理のポリシーです。HomeのGlobal RoutingにあるConfig、Proxy、Directは全体のルーティングモードを表します。名称は関連していますが、混同しないでください。Configを使用している場合は、現在の設定のRuleを確認します。ProxyやDirectに切り替えた後は、通常の設定モードでのルール分岐を前提にテスト結果を解釈しないでください。トラブル対処の記録には、まず現在のモードを明記しましょう。
| 画面上の表示 | 意味 | 確認するポイント |
|---|---|---|
| Config | Config：現在の設定に従って処理 | 選択中のファイル、ルール順序、最終ポリシー |
| Proxy | Proxy：プロキシモードでリクエストを処理 | 現在のサーバーとプロキシ経路 |
| Direct | Direct：直接接続モードでリクエストを処理 | ローカルネットワークから対象への到達性 |
全体のモードを切り替えても、システム通信の迂回やスキップ範囲などの境界設定がなくなるわけではありません。3つのモードを比較する目的は、サーバー経路の問題と設定の照合問題を切り分けることです。すべてのシステムリクエストが必ず同じ経路で処理されることを証明するものではありません。テスト後は想定するConfigの状態に戻してからルールを確認してください。そうしないと、設定ファイルが正しくても、期待した分岐結果を確認できない場合があります。
よく使う3つのポリシーの意味
PROXYは一致したリクエストを現在のプロキシ経路に渡します。利用可能なサーバー情報が必要です。ルールにPROXYと書いてあっても、サーバーの認証が済んでいることや、リモート先に接続できることは保証されません。DIRECTは現在のネットワークから対象へ直接接続しますが、アクセス成功を意味するものではありません。ローカルルーティング、名前解決、対象サービスに問題があれば失敗することがあります。REJECTは一致したリクエストを拒否します。明確に遮断したい対象に使い、原因の分からない接続障害を隠すために使わないでください。
追加の名前付きポリシーを設定で参照する場合は、その名前が現在のファイル内で定義され、サポートされていることを確認してください。サーバーのメモ欄を自由にポリシーキーワードとして扱うことはできません。この記事の例では、ファイル外の要素への依存を減らすため、基本の3つのポリシーだけを使用しています。サーバーのメモ、サブスクリプション名、ルールのポリシーはそれぞれ異なる階層に属します。名前が似ていても置き換えられません。
上から順に確認し、最初に一致したルールで決定
Ruleはファイルに記述された順に確認され、条件に一致したルールがリクエストのポリシーを決定します。後続の通常ルールが「よりよい一致」を探して処理を引き継ぐことはありません。明示的な例外を先に置き、広範囲の分類を後にし、最後にFINALで残りのリクエストを処理するのが基本です。この並べ方は確認しやすくなりますが、重要なのは実際の適用範囲です。一見具体的なキーワードルールでも、後続のサフィックスルールより範囲が広い場合があります。
[Rule]
DOMAIN,blocked.example.com,REJECT
DOMAIN,api.example.com,PROXY
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYblockedという名前は先に拒否し、apiという名前はPROXYで処理し、それ以外のexample.comはDIRECTにします。1行目とサフィックスのルールを入れ替えると、拒否する例外がサフィックスルールに先に一致してしまいます。FINALを先頭に置くと、そこで処理が決まり、後続のルールは意図どおりに動かなくなります。順序を確認するときは、対象のドメインがファイルに記載されているかを探すだけでなく、リクエストが各ルールの条件を上からどう通るかを確認してください。
FINALには照合対象を指定せず、通常はFINAL,PROXYまたはFINAL,DIRECTの形式でRuleの末尾に記述します。これはデフォルトの選択を表し、すべてのリクエストが必ずFINALを通るという意味ではありません。FINALが適切かどうかは、まず「先行するルールで分類されなかったリクエストをどう処理するか」を考え、次にご自身のサーバーが利用できるか確認します。末尾にどちらを指定するかに、利用状況を問わない唯一の正解はありません。
設定を管理するときは、「拒否する例外、完全一致ドメイン、ドメインサフィックス、アドレス分類、末尾のポリシー」のようにグループ分けし、各グループの前にコメントを記述すると確認しやすくなります。ルールを追加するたびに、既存のルールが新しい対象に先に一致しないか確認してください。同じ行を繰り返しても信頼性は高まりません。後続の行で先の判断を上書きできると誤解する原因になります。重複行を削除する場合も、設定範囲を誤って消さないよう、パラメーターが完全に同じかを確認してください。
Proxyモードでは使えるのにConfigでは使えない場合は、まず一致したルール、DIRECTの分岐、REJECT、DNSとの関連を確認します。両方で失敗する場合は、サーバー情報とネットワークを確認してください。Directで使える場合も、すべての対象に直接接続するのが適切だと証明されたわけではありません。その時点でテストした対象への経路が利用できたことを示すだけです。同じ対象を3つのモードでテストし、結果を記録して比較しましょう。
Hostの静的マッピングとアドレス範囲
名前をマッピングし、ポリシーは指定しない
Hostは指定したドメイン名を静的アドレスに対応付けます。変更するのは名前に対応するアドレス情報であり、PROXYやDIRECTを選択したり、Ruleを置き換えたりするものではありません。内部サービスのアドレスを指定し、直接接続させたい場合は、マッピングとポリシーを別々に設定します。Hostを記述しただけでリクエストが自動的にDIRECTになると期待したり、DOMAINを書いただけで指定したアドレスに名前解決されると期待したりしないでください。異なる機能を混同することになります。
[Host]
localhost = 127.0.0.1
intranet.example.com = 192.168.1.20
[Rule]
DOMAIN,intranet.example.com,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
FINAL,PROXYここで示す内部名とアドレスは説明用の例です。ご自身のネットワークに該当するサービスが実際に存在する場合にのみ意味があります。例示用ドメインを設定に追加しても、サーバーが作られるわけではありません。静的マッピングによって対象サービスが起動することもありません。使用する前にデバイスのアドレス、ポート、現在のネットワークを確認し、この種のマッピングが必要か判断してください。例をそのまま利用可能な接続先と取り違えないようにしましょう。
localhostは現在のデバイスを指す
localhost = 127.0.0.1はIPv4のループバックアドレスで、リクエストを開始したデバイス自身を指します。ルーターやプロキシサーバーのアドレスではありません。iPhoneからlocalhostにアクセスしても、別のデバイス上のサービスには自動的に接続されません。ご自身のLAN内にあるデバイスへ接続する手順の場合は、実際に到達可能なアドレスか正しい内部名を使い、サービスがほかのデバイスからの接続を受け付ける範囲で待ち受けているか確認してください。
プライベートアドレスは、該当するネットワークのルーティング内でのみ意味を持ちます。自宅のWi-Fiで使える192.168.1.20も、別のネットワークに切り替えると存在しないか、まったく別のデバイスを指す場合があります。内部名をプライベートアドレスに固定する前に、使うネットワークの範囲を考慮してください。複数のネットワークで同じファイルを長期間使う場合、静的マッピングによって名前が使えなくなったアドレスを指し続け、DNSエラーではなくタイムアウトとして現れることがあります。
HostではTLSの本人確認を回避できない
HTTPS接続では、対象の証明書とリクエスト先のホスト名が一致するか確認されます。ドメイン名の参照先を別のアドレスに変えても、そのアドレス上にある任意の証明書が信頼されるわけではありません。サーバーがホスト名に応じてサイトを切り替える場合もあります。マッピング後に証明書エラーが出たら、そのアドレスが該当サービスのものか、証明書が元の名前を対象としているかを確認してください。「Hostが反映されていない」とすぐに判断しないようにしましょう。名前解決の成功と本人確認の成功は分けて考える必要があります。
1つのIPアドレスで複数のサイトが提供されることがあり、ドメイン名はリクエスト先を区別するために使われます。そのため「IPに接続できる」ことは、「そこに対応付けたすべてのドメインが動作する」ことを意味しません。内部のHTTPSサービスを確認するときは、名前、アドレス、ポート、証明書をすべて確認してください。この記事では静的マッピングに合わせて証明書の信頼設定を変更することは求めません。ご自身のサービスに設定済みの正しい名前とアドレスを優先して使ってください。
静的マッピング、キャッシュ、動的サービス
動的アドレスや分散型サービスを使う名前を固定アドレスにすると、元の振り分けが損なわれる場合があります。ある時点で名前解決できたアドレスが、長期的に適しているとは限りません。サービスの構成が変わると、古いアドレスが同じ内容を提供しなくなる場合がありますが、静的マッピングによって通常の名前解決が引き続き上書きされます。明確な管理上の理由がない限り、1回の名前解決を短縮するためだけに、一般公開されているサービスのドメインを固定しないでください。
アプリが独自に名前解決結果や既存の接続を保持している場合があり、すべてのリクエストが同じ名前解決経路を通るとは限りません。Hostを変更した後は新しい接続を作成し、実際の接続先アドレスを確認してください。ログに古いアドレスが表示される場合は、設定を選び間違えたと判断する前に、キャッシュと接続の再利用を確認します。エディタに新しいマッピングが表示されたことだけで、対象アプリに反映されたと判断しないでください。すべてのアプリで同じ結果になるとも限りません。
マッピングを削除した後も、古いキャッシュの影響で通常の名前解決に戻るまで時間がかかる場合があります。元に戻す場合は元のファイルを残し、該当するマッピングだけを削除して保存し、設定を再選択してから同じ対象で再テストしてください。名前解決が元に戻っても特定のアドレスにアクセスできない場合は、静的アドレスの無効化が以前の問題だった可能性があります。引き続き名前解決に失敗する場合は、DNSの章に戻り、システムの参照先とネットワーク環境を確認してください。
Hostを長期的に管理する場合は、各マッピングの用途を説明できるようにしてください。「ローカルテスト用サービス」「内部固定アドレス」などの理由を独立したコメント行に記録し、アカウント認証情報は書かないでください。デバイスへのアドレスの再割り当て、ネットワーク範囲の変更、サービスの移行があった場合は、マッピングも確認します。Hostの項目を必要最小限に絞って用途を明確にすると、無効になった項目を見つけやすくなり、無関係な通常のリクエストへの影響も抑えられます。
URL RewriteとUSER-AGENTの適用範囲
URLの書き換えとルーティングの選択は異なる
URL Rewriteは、表示可能なリクエストURLを照合して書き換えます。Ruleはリクエストの条件に基づいてポリシーを選択します。あるアドレスを別のアドレスにリダイレクトしても、PROXYで接続されるとは限りません。転送先で発生するリクエストは、現在のルーティング設定に従って処理されます。この違いを理解しておけば、「書き換えは成功したのに転送先が開かない」ときに正規表現だけを変更し、転送先のドメインルール、名前解決、接続状態の確認を忘れることを防げます。
[URL Rewrite]
^http://example\.com/ https://example.com/ 302この行は、一致するHTTPアドレスをHTTPSアドレスにリダイレクトする構文例です。左側は正規表現、中央は転送先URL、末尾はリダイレクトのステータスコードです。^は文字列の先頭から照合し、\.はドットそのものを表します。ドメイン名の後にスラッシュを置くことで、ホスト名の境界を限定します。エスケープを忘れると、正規表現のドットは任意の文字に一致し、意図しない名前まで対象になる可能性があります。
パスとクエリパラメーターを保持するか明確にする
上の短い例では、元のパスやクエリパラメーターを保持する指定がなく、業務上のパラメーターを維持する必要があるリクエストにはそのまま適用できません。転送先URLにAPIのパス、検索パラメーター、認証情報が含まれる場合、固定のトップページへのリダイレクトによってリクエストの意味が変わります。書き換えを作る前に入力と期待する出力を整理し、キャプチャグループが必要か判断してください。先に広範囲の式をコピーして、ページがたまたま開くかどうかだけで正しさを判断しないようにしましょう。
[URL Rewrite]
^http://example\.com/(.*)$ https://example.com/$1 302この例ではキャプチャグループと$1を使い、スラッシュ以降の内容を保持する形式を示しています。ただし、あくまで構文例です。転送先サービスがHTTPSに対応し、クライアントがリダイレクトに従ってリクエストを続ける必要があります。エンコードされた文字、クエリパラメーター、複数回のリダイレクトを含む場合は、実際のリクエスト結果を確認し、新しいアドレスが期待どおりか確かめてください。リダイレクトはサーバー内部のパスを書き換える機能ではなく、リモートサービスが提供する内容を変更するものでもありません。
302と恒久的なリダイレクトではキャッシュの扱いが異なります。テスト中は一時的なリダイレクトの方が変化を確認しやすいものの、ブラウザやアプリ独自のキャッシュにも注意してください。設定反映後に別のルールで元のアドレスへ戻されると、リダイレクトループが起きる場合があります。ブラウザにリダイレクトが多すぎると表示されたら、最後のルールだけを変更せず、それぞれの遷移元と転送先を確認してください。まず、理由を説明できる書き換えを1つだけ有効にして検証します。
HTTPSで見える情報と処理上の制約
通常のHTTPS通信では、パスやリクエストヘッダーは暗号化された接続内にあります。クライアントが接続を中継しているからといって、すべての項目を書き換えられるわけではありません。HTTPSの内容を処理するには、追加のMITM設定、ドメイン範囲、証明書の信頼設定が関係し、アプリの証明書検証方式による制限を受けることもあります。この記事の最小構成例にはこれらの設定は含まれていません。任意のHTTPSアプリをそのまま書き換えられるという意味ではありません。
内容を処理できる場合でも、ご自身が理解しテストする必要のあるドメインに範囲を限定してください。1つのルールを一致させるために、すべてのリクエストへ対象を広げないでください。ログイン用パラメーター、セッション情報、個人データを含むURLを公開メモにコピーしないようにしましょう。現在の問題が接続失敗だけであれば、まずRule、DNS、サーバーを確認します。通常、最初にコンテンツの書き換えを行う理由はありません。ルーティングのトラブル対処とコンテンツの変更は分けてください。
USER-AGENTではアプリ全体を識別できない
USER-AGENTは、Ruleで表示可能なHTTPリクエストヘッダーを照合する種類であり、アプリ名からすべての接続を識別する機能ではありません。暗号化通信内の該当ヘッダーが見えない場合、照合は期待できません。アプリによって識別子が異なったり、複数のネットワークコンポーネントを使ったり、利用可能な該当フィールドを提供しなかったりすることもあります。明確なリクエストの実例がある場合に使い、「特定アプリの全通信」に適用する汎用ルールとして使わないでください。
[Rule]
USER-AGENT,ExampleClient*,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECTここでのExampleClientは説明用の識別子で、アスタリスクは照合パターンのワイルドカード範囲を示します。実際に確認できるフィールドがこのパターンに一致する場合にのみ、1行目が意味を持ちます。条件を満たさないリクエストは後続のルールへ進みます。この行を前に置くと、一致したリクエストは後ろのドメインサフィックスにも一致する場合でも、先にDIRECTが適用されます。ルールを並べる前に、この優先関係が意図した動作か確認してください。
USER-AGENTやURL Rewriteを検証する場合は、まず照合対象が見えることを確認し、次に式に一致すること、最後に結果が正しいことを確認します。この3段階を分けて記録してください。一致ログがないからといって、すぐにワイルドカードの範囲を広げないでください。フィールドが見えない、リクエストが再発行されていない、設定が選択されていないなど、同じように見える原因は複数あります。まず通常のドメインルールでルーティングの基準を確認し、その後で内容に関する条件を1つずつ追加すると、元に戻しやすいテストになります。
設定の検証、トラブル対処、メンテナンス手順
再現可能な基準を先に作る
トラブル対処を始める前に、現在のネットワーク、Global Routingのモード、選択中の設定、現在のサーバー、テスト対象を記録してください。異なるWi-Fi、対象、サーバーの結果をひとまとめにして比較しないでください。ご自身のサブスクリプションを更新したばかりの場合は、Homeで期待するサーバーが選択されているか先に確認します。設定テキストが変わっていなくても、サブスクリプションの内容や選択対象が変われば結果が異なることがあります。
Connectivity Testはサーバーのテスト結果を判断する参考になりますが、1回のテスト成功で、すべての対象に接続できることやRuleが期待どおりに一致することが証明されるわけではありません。テスト機能と対象アプリではリクエスト経路が異なる場合があります。まず基準情報として記録し、実際の対象に新しい接続を行ってドメイン、アドレス、ポリシーを確認してください。接続スイッチがオンになっていても、クライアントが接続状態になったことを示すだけで、対象へのリクエストが成功したことの確認にはなりません。
処理経路に沿って順に確認
最初にファイルが実際に選択されているか確認します。次にGlobal RoutingがConfigになっているかを確認し、Generalによって対象が通常の処理経路を迂回していないか確認します。その後、実際に照合されるドメイン名またはIP、ヒットしたルールとポリシーを確認し、最後に選択した経路の接続結果を調べます。この順序なら、前提が整っていない段階で後続のルールを検討することを避けられます。また、「照合処理に入っていない」場合と「照合したが接続に失敗した」場合を区別できます。
| 状況 | 優先して確認する項目 | 次の手順 |
|---|---|---|
| 新しいルールの一致ログがない | ファイル、モード、スキップ範囲、接続の再利用 | 正しいファイルを選び、新しい接続で確認する |
| DIRECTに一致した後、タイムアウトする | ローカルでの名前解決、ルーティング、対象サービス | 同じ対象への直接接続を基準に比較する |
| PROXYに一致した後、失敗する | 現在のサーバー、認証、対象への到達性 | まず利用中のサーバー経路を確認する |
| 一部のリソースだけ失敗する | 実際に使われたリソースのドメインと各ポリシー | 失敗した対象だけに例外を設ける |
| 書き換え後にリダイレクトループが発生する | 入力、出力、後続のリダイレクト | 該当する書き換えを一時停止し、1つずつ戻す |
ログを確認するときは、同じ時刻に発生した新しいリクエストを探してください。古いログのポリシーは変更前の設定による場合があります。接続の再利用によって、新たな照合処理が行われないこともあります。接続を再起動して対象を開き直すと、こうした影響を減らせます。それでも想定したログがない場合は、対象から実際にリクエストが送られたか、IPアドレスで直接接続されているか、スキップ設定の影響を受けていないかを確認してください。ルールを重複して追加するのは避けましょう。
最小限のルールで1つの仮説を検証
ドメインルールの範囲が正しくない可能性がある場合は、動作中の設定をコピーし、必要なGeneral、対象の完全一致ルール、FINALだけを残します。関連するキーワードルール、Host、URL Rewriteは一時的に除外してください。最小構成のファイルは、長期的に使うためではなく、1つの仮説を確かめるためのものです。完全一致ルールが安定して動作したら、サフィックス、アドレス分類、ほかの例外を順に戻し、どの層で処理結果が変わるかを特定します。
[General]
dns-server = system
[Rule]
DOMAIN,api.example.com,PROXY
FINAL,DIRECTこの例を試すには、ご自身が利用できるサーバーが必要です。Proxyモードでも失敗する場合、Ruleを増やしても解決につながる根拠はありません。サーバーとネットワークに戻って確認してください。最小構成では成功し、完全な設定では失敗する場合は、先に一致する範囲、静的マッピング、DNS設定を2つのファイルで比較します。追加するたびに1つのグループだけを戻し、最初に差が出た箇所を記録します。すべてを一度に追加するよりも、通常は原因を早く特定できます。
情報を保護し、元に戻せる状態を保つ
トラブル対処の資料を共有する前に、サブスクリプションURL、認証項目、個人用ドメイン、機密パス、アカウントを特定できるクエリパラメーターを取り除いてください。ルールの種類、対象の分類、ポリシー、エラーの状況は残し、実際の名称は例示用ドメインに置き換えられます。スクリーンショットやログに認証情報が含まれることもあります。設定ファイルでないからといって確認を省かないでください。基本的なルール構文を説明するために、ご自身のサブスクリプションを公開する必要はありません。
長期的なメンテナンスでは、最近正常に動作したローカルコピーを残し、変更の目的とテスト結果を記録してください。リモート設定の更新後はファイル名だけを比べず、選択状態、FINAL、General、重要な例外を確認します。ルールは追加しやすく削除しにくいものです。用途をグループごとに見直してください。理由を説明できない広範囲のルールは、新しい例外を重ねて補うのではなく、コピー上で削除したときの動作を確認しましょう。
基本操作はクイックスタートガイドで確認できます。画面表示やルールの用語は用語集をご覧ください。接続スイッチがオンなのにWebページを開けない場合は、サーバー、モード、DNS、ルールのトラブル対処に沿って確認します。システムの許可設定で問題が起きた場合は、VPN構成の追加を求める表示についてをご覧ください。それぞれ別の問題を扱うページです。同じ症状に対して購入、追加、設定をすべてやり直す必要はありません。