CONFIGURATION REFERENCE 公式マニュアル・体系的なリファレンス

Shadowrocketの設定項目とルールリファレンス

設定ファイルの構成からルールの適用結果まで、項目ごとに書式を、症状ごとに原因を確認できます。自身のSubscribeまたはサーバー情報をお持ちの方向けの内容で、接続サービスの入手方法は扱いません。

はじめての設定ガイドでは、初回の読み込み、Global Routing（グローバルルーティング）の選択、接続までの手順を案内します。このページでは各設定セクションが結果に与える影響を解説するため、初回接続後の確認に適しています。初めて使う場合は、まずガイドを最後まで進めてから、該当する項目に戻って設定を変更してください。

01 / STRUCTURE

設定ファイルの構成と有効化

サーバー情報、Subscribe、Configを区別する

サーバー情報は、プロトコル、アドレス、ポート、認証情報など、指定したサーバーへの接続方法を示します。Subscribeは、ユーザーがすでに持っているサーバー項目の読み込みや更新に使います。Configは、共通オプション、ドメイン解決、リクエストの照合、ポリシーの割り当てを管理します。それぞれ役割が異なるため、Subscribeの読み込みに成功しても、特定のルールが適用されたとは限りません。また、すべてのリクエストが現在選択中のサーバーを経由するとは限りません。

設定を確認するときは、まずHome（ホーム）で利用可能なサーバーを確認し、次にGlobal Routingの状態を確認してから、Configで実際に有効なファイルを確認します。エディタでファイルを開いただけでは有効になりません。コピーを保存しても、現在選択中の設定が自動で切り替わるわけではありません。トラブルの記録にはこの3つの状態を併記してください。テスト方法が異なると、同じルールでも結果が変わる場合があります。

角括弧のセクション名と行ごとの書式

Shadowrocketの一般的な設定では、角括弧でセクションを指定します。Generalには共通のキーと値、Ruleには順番に評価されるルール、Hostには指定したホストのマッピング、URL RewriteにはURL書き換えの式を記述します。セクション名は書式の一部なので、翻訳しないでください。空行は主に内容を見やすく分けるためのものです。項目には半角の記号を使ってください。全角の読点や等号、スマートクォートを使うと、想定と異なる解析結果になることがあります。

# 設定ファイルの構成例。サーバー接続情報は含みません
[General]
dns-server = system
ipv6 = false

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

[Host]
intranet.example.com = 192.0.2.10

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

この例は各セクションの並び方を示すもので、既存の接続設定一式の代わりにはなりません。ドメインとアドレスはドキュメント用の例です。特にHostのマッピングを記述しても、内部サーバーが自動的に作られるわけではありません。実際に設定を統合するときは、該当する行を既存の同名セクションに追加してください。ファイル末尾に同じセクション見出しを繰り返し追加したり、Ruleの行をGeneralのキーと値の一覧に入れたりしないでください。

セクション主な役割確認ポイント
[General]共通の動作と名前解決のオプションキー名、値の型、ネットワーク条件
[Rule]リクエストの照合とポリシールールの順序とフォールバック
[Host]指定ホストのアドレスマッピングホスト名とアドレスの対応
[URL Rewrite]リクエストURLの書き換え・リダイレクト正規表現の範囲と遷移先URL

ローカル編集とリモート更新の違い

設定がリモートURLから取得される場合は、更新によってどの内容が置き換わるかを確認してください。リモートファイルを再取得すると、ローカルでの編集が上書きされることがあります。サーバーのSubscribe更新とConfigの更新も、必ずしも同じ操作ではありません。長期的に保持するルールは、管理可能な設定ファイルのコピーに記録し、取得元も記しておきましょう。記憶を頼りに後から再構成すると、複数回の更新後に元の内容と追加したルールを見分けにくくなります。

コピーには「普段使い」「ルールテスト」など用途が分かる名前を付け、曖昧な数字だけで区別しないようにします。コピーを作成したら、内容を変更する前に一度有効化し、基本の接続が元のファイルと同じことを確認してください。その後で編集を始めると、コピー、切り替え、ルール変更を個別に検証できます。最初の段階で差異が出た場合は、新しい設定を追加する前にファイルの内容と選択状態を確認します。

設定には、ユーザー自身のサーバー情報、プライベートアドレス、認証情報が含まれる場合があります。問題を共有するときは、関連するセクションだけを残して機密値を置き換え、カンマの位置、キー名、項目の順序は維持してください。エラー表示だけでは診断に不十分なことが多く、設定全体の公開は不要な情報の漏えいにつながります。機密情報を除いた最小限の設定例、期待する結果、実際のマッチ記録を共有すると効率的です。

ほかの設定例を読むときは、「書式が正しいこと」と「現在の環境に適していること」を分けて考えてください。同じルールでも、DNS、接続経路、Global Routingの状態によって結果が変わる場合があります。移行する前に各行の用途を確認し、説明できない行は追加しないでください。設定が複雑になるほど、各オプションで解決しようとしている観測可能な問題を明確にする必要があります。

02 / GENERAL

Generalの共通項目とDNS名前解決

キーと値のオプションはルールによる振り分けとは異なる

Generalでは「キー名 = 値」の形式で共通の動作を指定します。カンマ区切りのRuleとは書式が異なります。このセクションの変更は複数のドメインに影響することがあるため、特定サイトだけを直す際の第一候補にするのは避けましょう。アクセスに問題がある場合は、まず名前解決の失敗、アドレスへの到達不能、誤ったルール適用のどれが原因かを確認してください。共通項目を変更すると、問題のなかったリクエストの動作まで変わる可能性があります。

dns-server = systemは、システムが提供するDNS設定を使うことを示します。仕組みを理解するための出発点にはなりますが、どのネットワークでも同じ結果になるとは限りません。ネットワークの切り替え、システム設定、ドメイン自体の名前解決方式によって、返されるアドレスは変化します。ユーザー側でDNSサーバーの指定が必要な場合は、その技術情報に従って設定してください。例にあるアドレスだからといって、現在のネットワークにも適用できるとは限りません。

[General]
dns-server = system
ipv6 = false
skip-proxy = 127.0.0.1, localhost

ipv6 = falseはブール値の書き方を示す例であり、すべてのユーザーにIPv6の無効化を求めるものではありません。有効にするかどうかは、現在のネットワーク、サーバーの対応状況、接続先アドレスを踏まえて判断してください。無効化後にアクセスできても、それだけで原因が特定できたとは限りません。変更前後の名前解決結果を記録し、到達不能なIPv6アドレスが返されていたのか、接続の再確立に伴って別の設定も変わったのかを切り分けます。

ドメイン情報とアドレス情報が得られるタイミングを把握する

アプリがリクエストを送信するとき、クライアントがURL、ドメイン、接続先アドレスのすべてを同時に把握しているとは限りません。ドメイン名で接続するリクエストもあれば、アドレスを直接使うものもあります。既存の接続では、キャッシュされた情報が引き続き使われる場合もあります。ドメインルールとアドレスルールでは必要な情報が異なります。トラブルの切り分けでは、まずリクエスト記録にどの情報が含まれているかを確認し、その条件でルールを適用できるか判断してください。

アドレスルールの判定に、ドメインの名前解決が必要になる場合があります。ルールにno-resolveを付けると、そのアドレスルールの確認だけを目的とした名前解決を避けられます。クライアント全体のDNSを無効にする設定ではありません。リクエストが最初からアドレスで指定されている場合は、既存のアドレス情報を使ってマッチすることがあります。この違いは不要な名前解決を抑えるうえで重要であり、同じアドレスルールでもリクエストによって挙動が変わる理由にもなります。

[Rule]
DOMAIN,portal.example.com,DIRECT
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
FINAL,PROXY

上の例では、まず明示したドメインを処理し、次に既知のアドレスがドキュメント用ネットワーク範囲に含まれるか確認して、最後にフォールバックへ進みます。リクエストにドメインしかなく、最初のルールに一致しない場合、no-resolve付きのアドレスルールは自身の判定のために追加の名前解決を行いません。そのため、ドメインの解決先が該当ネットワーク範囲だったとしても、このルールに必ず先にマッチするとは限りません。実際のリクエスト情報とマッチ記録を確認してください。

skip-proxyとリクエスト経路

skip-proxyはシステムプロキシレベルで例外とする宛先を指定するもので、RuleのDIRECTと同じ意味ではありません。トラフィックがクライアントに届く経路は種類によって異なり、システムプロキシの例外だけで完全なルール設計を代替することもできません。振り分け結果を検証する必要がある場合は、Ruleに条件を明示し、対象のトラフィックがクライアントの処理対象となる経路にあることを確認してください。

内部ドメインでは、まずシステムのネットワークが必要な名前解決を提供しているか確認します。ルールでDIRECTを選んでも、システムがホストの正しいアドレスを把握する必要があります。Hostにアドレスを指定しても、デバイスからそのアドレスへの到達経路が必要です。名前解決、ポリシー、接続性は連続しつつも別々の段階です。一つだけ変更しても、ほかの段階の問題は解決できません。

DNSの結果は、アプリ、システム、クライアントにキャッシュされる場合があります。名前解決の設定を変更したら、テスト中のページを閉じて新しいリクエストを開始し、必要に応じてアプリ内の該当するキャッシュ削除機能を使います。キャッシュの削除、サーバーの変更、ルールの調整を同時に行うと、アクセスが回復しても、どの変更が有効だったか分からなくなります。再テストでは、ネットワークの種類、接続先ホスト、解決されたアドレス、実際に適用されたポリシーを記録してください。

一部のドメインだけに問題がある場合は、まず正常なドメインとグループ分けして比較し、共通オプションをすぐに置き換えないでください。失敗するドメインのアドレスが返されるか、そのアドレスが変化しているか、同じポリシーでほかの宛先に接続できるかを確認します。DNSの問題はネットワーク切り替え後に発生することもあります。変更前後の状態を残すと、ネットワーク条件が変わったのか、別の設定ファイルに置き換わったのかを判断しやすくなります。

03 / DOMAIN MATCHING

DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORD

完全なドメイン名とサフィックスの範囲

DOMAINは、完全なホスト名を指定して一致させます。条件にapi.example.comと書いた場合、対象はそのホストだけです。www.example.comや、さらに下位のサブドメインは自動では含まれません。条件にプロトコル、ポート、スラッシュ、URLのパスを含めないでください。同じホスト内の異なるページを区別することもできません。ドメインレベルではそれらに違いがないためです。

DOMAIN-SUFFIXは、指定したドメインとそのサブドメインに一致します。条件がexample.comなら、そのドメイン自体に加え、api.example.comなどのサブドメインも対象になります。任意の文字列の末尾を照合するものではなく、notexample.comまで含むという意味ではありません。先頭にアスタリスクを付ける必要はありません。ブラウザーで使う一般的なURLをそのまま条件に貼り付けないでください。

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

このルールでは、アカウント用ホストが先に完全一致の例外ルールにマッチし、それ以外のexample.com配下のホストはサフィックスルールで処理されます。サフィックスルールを先頭に置くと、アカウント用ホストも先にそちらにマッチし、後続の例外ルールは適用されません。完全一致の条件は範囲が狭いものの、ファイル内の順序に関係なく自動で優先されるわけではありません。広いルールより前に配置してください。

キーワードマッチが意図しない範囲に及ぶ場合

DOMAIN-KEYWORDは、ドメイン名に指定したキーワードが含まれるかを調べます。同じ文字列を含む複数ドメインをまとめて対象にしたい場合に使えますが、組織の所属や単語の境界は判定しません。キーワードが短いと、無関係なホストまで一致する可能性があります。対象が既知のドメイン1つか数個なら、範囲を明確に説明できるDOMAINまたはDOMAIN-SUFFIXを優先してください。

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

この例では、まずexample.comの例外を残し、それ以外でexampleという文字列を含むドメインをPROXYに振り分けます。順序の意味を示す例であり、一般的な推奨ルールではありません。キーワードを使う前に、実際のリクエストから対象にしたいホストと対象外にしたいホストを挙げ、それぞれが想定どおりか確認してください。成功したページを1つ試すだけでは、検証として不十分です。

種類条件の例適用範囲
DOMAINapi.example.com指定した完全なホスト名だけに一致
DOMAIN-SUFFIXexample.com親ドメインとそのサブドメイン
DOMAIN-KEYWORDexampleドメイン名に指定文字列を含むもの

ページを構成する複数のホスト

ブラウザーのアドレスバーに表示されるホストだけで、ページ読み込みに使われるすべての宛先が分かるとは限りません。画像、フォント、ログイン認証、API、動画の分割データが別のドメインから配信されることがあります。メインページは表示されるのに一部の内容が読み込めない場合は、失敗したリソースのホストを確認してからルールを追加してください。トップレベルドメイン全体に同じポリシーを適用するのは簡単ですが、影響範囲が広がり、本当に必要な条件が見えにくくなることがあります。

同じサービスでも、外部ストレージやコンテンツ配信のホストを使う場合があり、必ずしもメインサイトのドメインサフィックスに含まれるとは限りません。実際のアクセス記録やサービスのドキュメントで関係を確認し、似た綴りだけで判断しないでください。複数のアプリが共有するドメインのポリシーを変更すると、ほかのアプリにも影響することがあります。必要に応じて、より限定的な例外を残し、メインサイトのサフィックスだけでは足りない理由を記録してください。

ホスト名を使わずアドレスへ直接接続するリクエストもあれば、別名解決を経由してもルール記録には元のリクエストドメインが表示される場合もあります。あるDNS問い合わせで見つかった別名だけを根拠に、ドメインルールが必ずその別名に一致すると判断しないでください。トラブルの切り分けではクライアントの記録にある宛先フィールドを確認します。記録がアドレスだけの場合は、アドレスルールとドメイン情報の可視性を続けて確認してください。

ドメインルールをテストするときは、まず一時的な完全一致ルールを置いて、対象を単一ホストに絞ります。マッチを確認したらサフィックスルールに広げ、サブドメイン1つと無関係なドメイン1つもテストします。この手順で書式、順序、範囲の3点を検証できます。テスト後は一時ルールを削除してください。用途を忘れて、広いルールより前に例外が残り続けるのを防げます。

ドメイン一覧を管理するときは、説明できないサフィックスを増やすのではなく、各ルールが実際のどの要件に対応するかを記録します。重複ルールを増やしても信頼性は上がりません。同じ条件でポリシーが異なる行の重複は、特に誤解を招きます。整理する際は有効な先頭のルールを残し、後続の重複が古い内容か確認してください。変更後は、ログイン、静的リソース、APIなど異なるリクエストを再テストします。

04 / ADDRESS AND METADATA

IP-CIDR、GEOIP、USER-AGENT

アドレス範囲とプレフィックス長

IP-CIDRは、ネットワークアドレスとプレフィックス長でIPv4アドレスの範囲を指定します。プレフィックス長が大きいほど、通常は範囲が狭くなります。単一アドレスは32ビットのプレフィックスで指定できます。入力前に対象が1台のホストかネットワーク全体かを確認してください。先頭の数ブロックが似ているというだけで範囲を広げないようにします。LANの場合は、現在のネットワークに実際に割り当てられているアドレス範囲を確認し、関係のない接続先までDIRECTに含めないでください。

[Rule]
IP-CIDR,192.0.2.10/32,DIRECT,no-resolve
IP-CIDR,198.51.100.0/24,PROXY,no-resolve
IP-CIDR6,2001:db8::/32,DIRECT,no-resolve
FINAL,PROXY

上記のアドレスはすべてドキュメント用で、実際のサービスアドレスではありません。1行目は単一のIPv4アドレス、2行目はIPv4ネットワーク、3行目はIPv6のプレフィックス表記を示します。IP-CIDR6はIPv6アドレス範囲に使います。コロンを含むアドレスをIP-CIDRに指定しないでください。プレフィックスが表すのはアドレスの集合であり、ポート範囲ではありません。同じサーバー上にある異なるサイトを区別することもできません。

複数のドメインが同じアドレスを共有している場合、アドレスルールがそれらすべてに影響することがあります。そのため、対象ホストが分かっている場合は、通常まずドメインルールを検討します。ネットワーク範囲で管理する必要がある場合に限り、アドレスルールを使います。逆に、固定された内部機器を対象とし、リクエストがアドレスを直接使う場合は、ドメインルールでアドレスルールを代替できません。書き方の簡潔さではなく、対象を識別する方法に基づいて選びます。

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

GEOIPは、アドレスデータベース上の地域分類に基づいて判定します。例はGEOIP,CN,DIRECTです。このルールが示すのは接続先アドレスの分類であり、ドメインの登録地やサービス提供者の所在地ではありません。コンテンツ配信ネットワークを利用するサイトでは、ネットワークによって解決されるアドレスが異なる場合があります。データベースも実際の利用状況と一致しないことがあるため、地域ルールは広範な補助条件として使うのが適切です。

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

この例では、特定のAPIに適用するポリシーを先に固定し、残りのリクエストを地域条件で処理します。GEOIPを先に置くと、APIの解決先アドレスがその地域に分類された場合、完全一致のドメイン例外が実行されないことがあります。後ろにより具体的なドメイン条件があっても、ルールは記載順に評価され、自動で選び直されません。意図しない振り分けが起きたら、まずマッチした位置を確認し、その後でアドレスデータベースを調べる必要があるか判断してください。

GEOIPの判定では、対象ドメインの名前解決が必要になる場合があります。no-resolveを付けるかどうかは、この条件のために名前解決を行うかを踏まえて決めてください。付けると、ドメインしかなく利用可能なアドレス情報がないリクエストは、後続のルールへ進むことがあります。付けない場合は、追加の名前解決による待ち時間が発生する可能性があります。どちらが常に正しいという決まりはありません。実際の記録で確認してください。

USER-AGENTで判定できる範囲の制限

USER-AGENTは、確認可能なリクエスト内のUser-Agent情報に基づいてマッチします。アプリの識別情報による振り分けとは異なります。複数のアプリが同じ識別子を送ることもあり、同じアプリでもリクエストの種類によって識別子が変わる場合があります。通常の暗号化接続ではHTTPヘッダーがすべて自然に見えるわけではありません。すべてのアプリ通信を識別できると期待したり、システム全体のプロセス選択機能として使ったりしないでください。

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

ExampleClient*は書式を示す例です。実際の条件には、ユーザーが確認できるリクエスト識別情報を使ってください。アプリ名からUser-Agentを推測すると、ブランド名とリクエストヘッダーが一致せず失敗することがあります。リクエスト記録に該当情報がない場合は、確認できるドメインまたはアドレスの条件を使います。情報不足を補うためにワイルドカードを次々と広げないでください。

アクセス制御をUSER-AGENTだけに頼らないでください。この項目はリクエストのメタデータであり、強固な認証情報ではありません。同じ宛先でもリクエストによって値が異なる場合があります。特定のホストを遮断したい場合は、ドメイン条件を直接記述するほうが確認しやすくなります。同じホスト上の異なるサービスを区別したい場合は、まずクライアントから見える情報で違いを表現できるか確認し、ルールで処理するのが適切か判断してください。

アドレスルールとメタデータルールをテストするときは、既存接続と新規接続、ドメイン名でのアクセスとアドレスでのアクセスをそれぞれ確認します。一度マッチしたからといって、似たすべての通信にも当てはまるとは限りません。記録に必要なフィールドがない場合は「現時点では判断できる情報が不足」と記し、確認しやすいルールを残してください。偶然の結果を広範なデフォルトポリシーとして固定しないようにします。

05 / POLICY AND PRECEDENCE

PROXY、DIRECT、REJECTとルールの優先順位

まずGlobal Routingの状態を確認

Global RoutingのConfig、Proxy、Directは、それぞれ設定に基づく振り分け、プロキシ、直接接続の状態を表します。Ruleごとの振り分けを確認するときはConfigを選び、実際に有効な設定ファイルも確認してください。ProxyとDirectは、それぞれの全体状態で接続を処理するためのもので、通常の振り分けルールが正しいことの証明には使えません。画面上のProxyと、ルールキーワードのPROXYは大文字・小文字が異なります。階層を区別して読んでください。

階層名称意味と確認ポイント
Global RoutingConfig現在の設定でルールのマッチを確認
Global RoutingProxy / Direct全体の接続モード。ルール行とは別
RuleのポリシーPROXY現在のプロキシ選択に処理を委ねる
RuleのポリシーDIRECTローカルネットワークから直接接続
RuleのポリシーREJECTマッチしたリクエストを拒否

PROXYはルール内でサーバーを定義するものではなく、現在利用可能なプロキシ選択を参照します。サーバー情報の誤り、認証の失敗、サーバーへの到達不能があると、ルールに正しくマッチしてもリクエストは失敗します。DIRECTも、デバイスのあらゆるシステムネットワーク条件を無視するという意味ではありません。現在のネットワーク、DNS、接続先サービスの状態に左右されます。REJECTは明示的な拒否を意味するため、原因不明の問題を試しに調べる際のデフォルトにはしないでください。

最初のマッチと明示的な例外

Ruleは一般に上から順に評価され、最初にマッチした条件によってリクエストのポリシーが決まります。ドメインの長さ、ルールの種類、記述した時刻を基準に並べ替えられることはありません。設定を組み立てる際は、「完全一致の例外、対象サービスのドメイン、アドレスによる補足、最終フォールバック」の順にすると整理しやすくなります。ただし、これは考えやすくするための構成例であり、必ずそのまま使う固定リストではありません。各ルールをその位置に置く理由を説明できるようにしてください。

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

ログイン用ホストが1行目にマッチすると、example.comのサフィックスルールは適用されません。別のexample.com配下のサブドメインは2行目まで進みます。明示的に指定した拒否対象は3行目で処理され、それ以外のリクエストが地域判定に進みます。設定を読むときは、関連がありそうな行だけを見るのではなく、具体的なホストを1つ選んで先頭から順に当てはめてください。

3行目の拒否対象が、それより前にある広範なDIRECTルールにも含まれていると、拒否条件が実行されない可能性があります。同じREJECTを重複して書いても解決しません。ルールの位置を移動するか、先行ルールの条件範囲を狭めてください。無効なルールを削除する前に、ドキュメント用の説明として意図的に残されているかも確認します。本当に無効なら、矛盾する有効ルールを残すより、コメントで説明するほうが明確です。

FINALはフォールバックであり、自動修復ではない

FINALにはドメイン条件を指定する必要はありません。基本形はFINAL,PROXYまたはFINAL,DIRECTです。前のルールにマッチしなかったリクエストを処理するため、Ruleの末尾に置いてください。途中に置くと、後続の通常ルールが想定どおりに評価されなくなります。設定を確認する際は、まずFINALの出現回数を調べ、通常は明確な最終ポリシーを1つだけ残します。用途を分けるために複数のフォールバックを並べないでください。

フォールバックを選ぶ際は、実際の利用要件と既存の接続条件を考慮します。FINALをPROXYにすると、分類されていないリクエストはプロキシ選択に渡されます。DIRECTにすると、分類されていないリクエストは現在のネットワークから直接接続します。いずれも接続先への到達を保証するものではありません。特定のサービスだけに問題がある場合は、フォールバック全体を切り替えて試すのではなく、根拠のある完全一致の例外を追加してください。

# 完全一致の例外は、それを含む広いルールより前に置く
[Rule]
DOMAIN,health.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT

上の例をテストする場合は、少なくとも疎通確認用ホスト、別のexample.comサブドメイン、まったく無関係なドメインを確認します。この3種類で、例外、サフィックス、フォールバックをそれぞれ検証できます。最初の種類だけを試すとFINALの誤変更を見落とす可能性があります。メインサイトだけを試すと、完全一致の例外が広いルールに上書きされていることに気づけない場合があります。ルール検証では、成功する経路だけでなく境界条件も確認してください。

On Demand（オンデマンド接続）は、該当するネットワーク条件で接続を確立するかどうかを決めるもので、リクエストのポリシーを決めるRuleの代わりにはなりません。自動接続の後も、現在のGlobal RoutingとConfigを確認してください。ネットワーク切り替え後に結果が変わった場合は、接続が再確立されたか、設定が同じか、DNSが変わったかを個別に確認します。On Demandが有効というだけで、すべてのリクエストが想定した経路を通るとは限りません。

ルールへのマッチとサービスの利用成功は分けて確認してください。マッチ記録は分類ロジックの証拠であり、接続先からの応答は現在の経路が利用可能であることを示します。両方が必要です。失敗した場合は、まず「ポリシーの選択が誤っている」のか、「ポリシーは正しいが接続できない」のかを切り分けます。初回接続に関する問題はよくある質問もご覧ください。購入やサーバー認証の問題を、ルールの優先順位の問題と混同しないようにします。

06 / HOST AND URL REWRITE

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

Hostはアドレスの対応を変更するが、サイトの識別情報は変更しない

Hostは指定したホストに静的なアドレスを割り当てます。接続先アドレスが明確な管理環境などで使われます。内部機器を自動検出したり、そのアドレスへの到達を保証したりするものではありません。設定前に正確なアドレスを入手し、対象ホストがそのアドレスでサービスを提供していることを確認してください。適当に見つけたアドレスを入力すると、リクエストが誤った宛先へ送られるだけで、名前解決の問題は解決しません。

[Host]
portal.example.com = 192.0.2.20
files.example.com = 192.0.2.21

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

Hostはアドレスを指定し、Ruleはポリシーを指定します。2つのセクションは異なる段階を定義します。ここで使うアドレス範囲はドキュメント専用です。実際に使用する場合は、自身の環境で有効な値に置き換えてください。対象アドレスに特定のネットワークからしか到達できない場合、デバイスがそのネットワークから離れると、静的マッピングが残っていても接続できないことがあります。同じマッピングをさらに追加するのではなく、到達経路を確認してください。

HTTPSでは、元のドメイン名が引き続きサイトの識別情報の検証に使われます。Hostでドメインを別のアドレスに向けても、証明書が自動で正しくなるわけではなく、リクエストのホスト識別情報がそのアドレスに変わるわけでもありません。証明書の名前が一致しない場合は、マッピング先とサーバー設定を確認してください。検証を無効にすることを通常の修正方法にしないでください。対象サービスの移行後は、静的マッピングを速やかに見直します。

Hostの設定とキャッシュが、確認結果に同時に影響する場合もあります。変更後も古いアドレスに接続する場合は、既存の接続を終了し、アプリ側のキャッシュも確認してください。新しいリクエストが新しいマッピングを使っていることを確認してから、有効性を評価します。元の名前解決に戻す場合は、テスト用マッピングを削除してリクエストを再送するほうが、同じホストに複数の値を追加して競合させるより追跡しやすくなります。

URL RewriteがマッチするのはURLの式

URL Rewriteは正規表現でリクエストURLを照合し、設定に応じて書き換えまたはリダイレクトします。ドメインの振り分けとは別の仕組みです。ドメインルールはポリシーを決め、書き換えルールは接続先の式を変更します。特定ホストをDIRECTにしたいだけなら、URL書き換えは不要です。管理されたURLの移行やパスの調整など、明確な要件がある場合に限り、このセクションを追加してください。

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

この例では、旧ホストのHTTP URLを新しいホストへリダイレクトし、後続の部分を保持します。先頭のキャレットはURLの開始位置を指定します。バックスラッシュにより、ドメインのドットを文字どおりに照合します。括弧でキャプチャグループを作り、遷移先のドル記号と数字でそのグループを参照します。末尾の302は一時的なリダイレクトを示します。書式の説明用の例であり、遷移先ドメインは利用可能なサービスではありません。

開始位置の条件を省略したり、ドットをエスケープしなかったりすると、正規表現のマッチ範囲が広がります。正規表現のドットは通常、任意の1文字を表し、一般的なドメイン区切りのドットとは異なります。編集前に、似たURLをいくつか使って確認してください。旧ホストはマッチし、ほかのホストはマッチせず、新ホストのURLも再度マッチしないことを確認します。範囲が狭いほど、意図したリクエストだけに書き換えが適用されることを確かめやすくなります。

リダイレクト、暗号化、ループの確認

クライアントがどのURL情報を処理できるかは、実際のリクエスト経路と暗号化情報の可視性によって異なります。URL Rewriteを追加すれば任意のHTTPSパスを読み取れるとは限りません。トンネル内からホスト情報しか見えない場合、完全なパスを使う式は実行条件を満たさないことがあります。情報が確認でき、範囲を限定できるリクエストで先に検証してください。パスの問題だけを解決するために、証明書の信頼範囲や検査範囲をむやみに広げないでください。

リダイレクト後、アプリは新しい宛先にリクエストを送ります。その宛先も現在の振り分け設定に従い、到達可能でなければなりません。旧宛先のルールが正しくても、新しい宛先に同じポリシーが適用されるとは限りません。新ホストから旧ホストへ戻されると、リダイレクトループが発生し、ブラウザーにはリダイレクト回数が多すぎると表示されることがあります。各リダイレクトの発信元と遷移先を個別に確認し、サーバー側の動作とローカルルールが重複していないか調べてください。

永続リダイレクトはクライアントにキャッシュされることがあるため、検証段階では管理しやすい一時的なリダイレクトを使い、確認後に要件に応じて最終方式を決めるのが適切です。ローカルルールを削除しても、アプリのキャッシュによってテスト結果がすぐに変わらない場合があります。新しいリクエストからテストし、アドレスバーの最終表示だけでルールが実行中か判断せず、実際のリダイレクト経路を記録してください。

クエリパラメーターには認証情報やサービスの状態が含まれることがあります。構造を理解せずに削除したり、つなぎ合わせたりしないでください。キャプチャ式でクエリ部分を保持できるか、具体的なサンプルで確認します。パス内の特殊文字も、エスケープの違いに影響することがあります。ログイン、決済、フォーム送信などの重要な処理では、サービス本来のリダイレクト設計を優先してください。単純なGETリクエストでのテスト結果を、すべてのリクエスト方式に当てはめないようにします。

07 / COMPOSITION

ルールの組み合わせ・統合・設定管理

説明できる最小限のルールから始める

ルールを作る前に、要件を自然な言葉で明確にします。たとえば「アカウント用ホストは直接接続し、ほかのサービスのサブドメインは現在のプロキシを使い、それ以外は直接接続する」といった形です。次に各要件を該当する条件へ置き換えます。追加するルールが本当に必要か判断しやすくなり、テストに失敗した際も要件そのものに戻って確認できます。広いマッチ条件をさらに追加して、既存の競合を覆い隠すことを防げます。

[Rule]
# アカウント用ホストの例外
DOMAIN,accounts.example.com,DIRECT

# サービスのドメイン
DOMAIN-SUFFIX,example.com,PROXY

# ユーザーが確認した拒否対象
DOMAIN,blocked.example.net,REJECT

# そのほかのリクエスト
FINAL,DIRECT

この組み合わせは、各ルールを個別に確認しやすいよう短くしています。サーバーアドレスやSubscribeの内容は含まず、ユーザーがすでに利用可能な接続情報を持っていることが前提です。サービスを追加するときは、まず対象ホストを確認してから完全一致とサフィックスのどちらを使うか決めてください。ページの読み込みに失敗したからといって、未確認のドメインを大量に追加しないでください。後からどの行が実際の処理に関わったのか分からなくなります。

ルール統合時の意味上の競合を解消する

2つの設定を統合するときは、テキストをそのまま前後につなげるだけでは不十分です。それぞれのセクションを特定し、同じ種類の項目を該当するセクションにまとめたうえで、ルールの順序とFINALを確認します。Generalに同じキーで異なる値がある場合、Hostに同じホスト名で異なるアドレスがある場合、Ruleに同じ条件で異なるポリシーがある場合は、重複時の不明確な挙動に頼らず、どれを残すか判断してください。

ドメインサフィックスと完全一致のドメインにも、見えにくい競合が生じることがあります。一方のルールがexample.com全体にPROXYを適用し、もう一方がその中の特定APIにDIRECTを指定している場合、単純な重複行ではありません。完全一致の例外を広いルールより前に置く必要があります。統合時は、同じ親ドメイン周辺にあるすべての項目を検索し、より上位のサフィックスやキーワードが先に対象を覆っていないか確認してください。

# 統合後の順序：例外を先に、広い条件を後に
[Rule]
DOMAIN,api.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY

元の設定にカスタムポリシー名が含まれる場合は、移行先にも同名の定義が存在し、名前の大文字・小文字が一致していることを確認してください。このページでは基本的な意味を説明するためにPROXY、DIRECT、REJECTを使っていますが、未知のポリシー名がそのまま使用できるとは限りません。参照先が分からない場合は、どのサーバー選択またはポリシーグループにつながるのかを確認してから、残すかどうか判断します。

変更記録と更新範囲を管理する

変更のたびに、対象、変更した行、検証結果を記録してください。コメントは独立した行に置き、長い説明ではなく用途や例外の理由を簡潔に記します。特に一時的な診断ルールには、削除する条件も記録してください。何度かテストを重ねるうちに忘れられ、見えない優先ルールになるのを防げます。整理時には、コメントが実際のポリシーと一致しているかも確認します。古いコメントは、説明がない場合より設定を理解しにくくすることがあります。

リモート設定を更新する前にローカルのコピーをバックアップし、取得に成功したかだけでなく重要なセクションを比較してください。配信元がフォールバックを変更したり、広い範囲のルールを追加したり、名前解決オプションを調整したりすると、ローカルの例外にも影響します。ローカルの内容を再統合する場合は、ルールの意味に基づいて配置を確認してください。古い例外をそのままファイル末尾に貼り付けると、FINALの後になって適用されないことがあります。

Subscribeの更新は主に既存のサーバー項目に関わるもので、ルール同期の一括代替手段ではありません。更新後にプロキシ経由の接続に問題が出た場合は、現在選択中のサーバーが引き続き有効か、認証情報が変わっていないか、古い項目が置き換わっていないかを確認します。ルールが引き続きPROXYにマッチしていても、参照先の接続選択が変わればサービスの結果も変わります。この問題はドメインルールの順序を調整しても解決しません。

設定のバックアップとサーバーの認証情報は、保管する範囲を分けてください。エクスポートしたファイルに接続情報が含まれる場合もあれば、サーバー一覧を別途保存する必要がある場合もあります。機種変更後、ファイル名が同じというだけで内容が揃っているとは判断できません。具体的な準備と復元の手順は設定のバックアップと機種変更後の復元方法をご覧ください。旧端末が使えるうちに、復元できることを一度確認しておきましょう。

増え続けるルールは定期的に整理してください。一度もマッチしない、用途が不明、より広い条件にすでに含まれるルールは、まずテスト用コピーで無効化して様子を見てから削除を判断します。整理の目的は行数を減らすことではなく、有効な各ルールの必要性を説明できる状態にすることです。あらゆる種類の条件を追加するより、通常の利用を安定させるほうが管理しやすくなります。

プロトコルの接続情報とルールのポリシーも分けて管理します。たとえばWireGuardの鍵とアドレスは接続の確立に関わり、DOMAIN-SUFFIXはどの宛先をそのプロキシ選択に渡すかを決めます。両者は別の階層の問題です。項目の意味はWireGuardの設定項目ガイドをご覧ください。認証エラーを解決するために、対象ドメインのルール範囲をむやみに広げないでください。

08 / VERIFICATION

ルールの検証、トラブルの切り分け、復元確認

再現できるテスト条件を整える

有効なテストには、明確な接続先ホスト、期待するポリシー、固定したネットワーク、確認済みの設定状態が必要です。まずConfigの状態を選び、有効なファイルと現在のサーバーを記録してから、新しいリクエストを開始します。テスト中にSubscribeを更新したり、ネットワークを切り替えたりしないでください。条件が変わり続けると、一度成功してもルール修正の効果を証明できず、その結果を今後の管理に活用することも難しくなります。

変更ごとに、3種類のテスト対象を選ぶとよいでしょう。ルールにマッチすべき対象、例外に進むべき対象、影響を受けるべきでない対象です。それぞれについてルール、ポリシー、サービスの結果を記録します。サフィックスルールを追加する場合は、親ドメイン、サブドメイン、似ているがそのサフィックスには属さないドメインを含めます。アドレスルールを追加する場合は、範囲内と範囲外の両方を確認し、成功した例だけで判断しないでください。

確認された症状優先して確認する項目次に行うこと
期待したルールにマッチしないファイル、接続モード、リクエスト情報先行する広いルールと新しいリクエストを確認
PROXYにマッチするが接続できないサーバー接続と認証接続経路と接続先サービスの問題を切り分ける
DIRECTにマッチするが接続できないローカルの名前解決とネットワーク経路解決されたアドレスと到達可能な範囲を確認
メインページは表示されるが、一部のリソースが失敗するリソースが実際に使うホスト依存するリクエストを個別に確認
変更しても結果が変わらないキャッシュと既存の長時間接続新しいリクエストを開始し、ファイルを確認

未マッチとマッチ後の接続失敗を切り分ける

マッチしない場合は、まず対象リクエストにルールが必要とする情報が本当にあるか確認します。アドレスだけのリクエストにはドメイン条件がマッチできず、見えないリクエストヘッダーにはUSER-AGENT条件がマッチできません。次にRuleを先頭から確認し、より前にあるサフィックス、キーワード、地域条件、FINALを探します。最後に半角記号、ポリシーの綴り、その行が正しいセクションにあるか確認してください。

ルールにマッチしているのにアクセスできない場合は、根拠なくルールを移動するのをやめます。PROXYの場合は、現在のサーバーに接続できるか、認証情報が有効か、接続先サービスに到達できるかを確認します。DIRECTの場合は、ローカルネットワークから解決されたアドレスにアクセスできるか確認します。特定の宛先だけ失敗する場合は、まず宛先ごとの差を比較してください。同じポリシーを使うすべてのリクエストが失敗する場合は、そのポリシーで共通する接続条件を確認します。

Connectivity Test（接続テスト）は特定の条件での結果を示しますが、個々のサービスリクエストの検証に代わるものではありません。テスト対象に応答があっても、ログインAPI、動画リソース、ほかのプロトコルによるリクエストが成功するとは限りません。テスト結果は問題の範囲を絞るための情報として扱い、実際に失敗したリクエストと合わせて判断してください。1つの数値だけで設定全体を評価しないでください。

キャッシュ、長時間接続、ネットワーク切り替えへの対処

設定を変更しても、確立済みの接続すべてが新しいポリシーで直ちに再接続するとは限りません。ブラウザーによる接続の再利用、アプリのバックグラウンド通信、メディアの連続再生には、以前の状態が残る場合があります。検証時は該当するセッションを終了して新しいリクエストを開始し、必要に応じてクライアントの接続を再確立してください。既存ページの再生が続いていることは、古い接続が機能している証拠にすぎず、新しいルールが後続の接続に適用されたことを示すものではありません。

Wi-Fiからモバイル通信に切り替えると、DNSサーバー、到達可能なアドレス、接続状態が同時に変わる場合があります。元のネットワークでは到達できた内部ホストに切り替え後アクセスできなくても、ルールの誤りとは限りません。On Demandで接続が確立されたか、Global Routingの状態が維持されているか、接続先が元のネットワーク経路に依存していないかを確認してから、ネットワークごとに設定を分ける必要があるか判断します。

Data（通信量統計）は、記録対象となる範囲の通信量を示すもので、ルールにマッチしたことを直接証明するものではありません。特定のサーバーに通信量が表示されても、そのサーバーを今回のテスト対象が経由したとは限りません。キャッシュが使われると、通信量が目立って増えない場合もあります。集計方法と数値の見方は通信量統計の解説をご覧ください。振り分けの検証は、個々のリクエスト単位で行います。

最小構成での再現と安全な復元

複雑な問題は、テスト用コピーを使って段階的に設定を絞り込みます。必要なGeneral、対象を1つに絞ったルール、FINALを残し、関係のないHostとURL Rewriteは一時的に取り除きます。内容を一組外すたびに同じテストを繰り返し、差を確認してください。普段使いの設定からすべてのセクションを直接削除しないでください。基準となる状態を失うと、正常だった動作まで復元しにくくなります。

# 1つの宛先を切り分けるためのRuleセクション。接続設定全体ではありません
[Rule]
DOMAIN,api.example.com,PROXY
FINAL,DIRECT

最小構成のルールが想定どおりにマッチしたら、元の内容を一組ずつ戻し、最初に結果が変わる位置を特定します。最小構成でもマッチしない場合は、さらにルールを統合するのではなく、有効化の状態とリクエスト情報を見直してください。各段階で変数を1つだけ変更すれば、「ファイルが有効でない」「先行条件に上書きされた」「接続経路に問題がある」を区別しやすくなり、同じ試行を繰り返さずに済みます。

さらに確認が必要な場合は、機密情報を除いた関連セクション、実際のホスト、マッチしたポリシー、ネットワーク条件、再現手順を用意してください。Subscribeの完全なURL、鍵、認証情報は公開しないでください。切り分けを続けられない場合は、検証済みのバックアップに戻し、元のサービスが復旧したことを確認してから次のテストを行います。読み込みと初回の購入確認の手順ははじめての設定ガイドをご覧ください。購入済みアプリの確認と復元については購入済みアプリの復元方法をご確認ください。