公式マニュアル / 設定項目

Shadowrocket
ルール・設定リファレンス

設定ファイルの各セクションからリクエストの評価まで、項目の意味や適用範囲、検証手順を確認できます。

このページは設定を詳しく確認するためのリファレンスで、初回接続の手順を説明するものではありません。自分のサブスクリプションまたはサーバー情報をまだ追加していない場合は、先に入門ガイドに沿って追加・選択・接続を行い、その後ルールを調整してください。接続できる状態の方は、目次から該当する項目をご覧ください。入門ガイドのConfigやルールの説明からも、詳しい内容をこのページで確認できます。

Shadowrocketには、iPhone / iPad、Mac（Appleシリコン・Intel）、Windows、Android、Linux版があります。iPhone / iPad版はApp Storeで2.99ドルの買い切り、その他のプラットフォームは無料です。システム要件はApp Storeの製品ページをご確認ください。入手方法はクライアントのダウンロード、デスクトップ版とAndroid版のインストール許可手順は同ページの案内をご覧ください。

§01 / ファイル構成

設定ファイルの構成

Shadowrocketの設定ファイルは通常 .conf 形式で保存し、角括弧でセクションを示して、それぞれに対応する内容を記述します。設定項目をすべて文章に書き写した記録でも、サーバーサブスクリプションそのものでもありません。まずセクション名を確認し、次にそのセクションで使えるフィールドの形式を確認してください。同じ文でも記述するセクションによって機能しなかったり、解析エラーになったりするため、キーワードだけで設定の正しさを判断することはできません。

各セクションの役割

[General]には、一般的な動作や解析に関するオプションを記述します。多くはフィールド名、等号、値の形式です。[Rule]には、上から順に評価する振り分けルールを記述します。一般的な形式は、種類、条件、ポリシーです。[Host]は、指定したホスト名を静的にアドレスへ対応付けます。[URL Rewrite]は、条件に一致するリクエストURLを書き換えます。ファイル内の空行の数より、セクション名とその前後の記述が重要です。

この4つのセクションを、常に順番どおりに通る処理パイプラインと考えないでください。リクエストがすべてのGeneral設定を経てからHostやRewriteを順に通るとは限りません。Generalはクライアントの動作、Hostは名前解決、Ruleはトラフィックのポリシー、Rewriteは条件に合うリクエストURLを扱います。それぞれ適用条件が異なります。ファイル内でセクションの位置を入れ替えても、ネットワーク処理の順序が変わるわけではありません。優先順位に直接関係するのは、Rule内の並び順です。

[General]
dns-server = system

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

[Host]
# 固定マッピングが必要な場合にのみ追加

[URL Rewrite]
# 対象リクエストを確認してから書き換えを追加

サブスクリプションと設定ファイルを分けて管理

サーバーサブスクリプションは主に接続先の取得・更新に使い、設定ファイルはそれらの接続先をリクエスト処理にどう使うかを記述します。自分のサブスクリプションを読み込んでHomeにサーバーが表示されても、振り分け用の設定ファイルが有効になっているとは限りません。同様に、PROXYを指定したルールを読み込んでも、接続可能なサーバーが自動で追加されるわけではありません。ルールを解析できるのに接続できない場合は、サーバーの選択と設定ファイルの適用状況を分けて確認してください。同じファイルを何度も読み込む必要はありません。

リモート設定も、別途管理が必要なデータです。更新時にローカルでの変更が保持されるかどうかは、実際の更新方法や編集方法によります。重要な変更は別名でコピーを保存してから更新してください。サブスクリプションの更新でルールも自動修正されるとは限らず、サーバーサブスクリプションの不具合がローカルルールの破損を意味するわけでもありません。サブスクリプションの更新方法はサブスクリプションの更新方法をご覧ください。このページでは設定ファイル自体を解説します。

設定ファイルには、サーバーの認証情報、プライベートアドレス、リクエスト記録に関する設定、書き換え先などが含まれる場合があります。ファイルを共有する前に、サーバー名だけでなく、URLのパラメーターやコメント、静的マッピングも確認してください。トラブル対処に必要なのは通常、該当する数行のルール、現在のモード、エラーの状況です。サブスクリプションURL全体を送る必要はありません。例のexample.comは説明用ドメインです。他者の実サービス情報に置き換えて公開しないでください。

編集・保存・有効化

Configで編集する設定を見つけ、まず現在使用中のファイルかどうかを確認してから、復元用のコピーを作成します。編集後に保存し、現在選択されている設定が編集したファイルのままかを確認してください。ファイル名が同じでも内容が同一とは限りません。リモートから再度ダウンロードしたファイルと、ローカルで編集したファイルが別々に残る場合もあります。特に複数の設定を試しているときは、一覧の名前だけでなくファイルの内容を比べるほうが確実です。

プレーンテキストで編集するときは、半角のカンマ、角括弧、等号をそのまま使い、日本語の句読点に置き換えないでください。ルールは1行に1つ記述し、コメントは別の行に # を付けて書きます。ポリシーの後ろに説明を続けて記述しないでください。エディター上で自動折り返しされても、実際の改行が挿入されていなければ通常は1つのルールです。コピー時は長いアドレスが途中で分割されていないか確認してください。フィールド全体が正しく読み取られる必要があります。

最初の検証では、ルールを少数に絞ってください。明確なドメイン条件とFINALを残し、結果を確認してからIP、Host、Rewriteを追加します。変更後に問題が起きた場合は、修正を重ねるよりコピーを復元したほうが原因を特定しやすくなります。後述の設定例は、各項目の意味を示すための部分的な例です。すべての例を一度に組み合わせる必要はありません。実際のファイルには、目的に合い、用途を説明できる項目だけを残してください。

§02 / General

GeneralとDNS

設定の動作を調べるときはGeneralから確認しますが、意味のわからないフィールドをまとめてコピーするのは避けてください。設定ファイルを読み込めたことは、テキストを解析できたことを示すだけで、すべての項目が現在の環境に適しているとは限りません。まず各フィールドに対応するアプリ内の設定や説明を確認し、既定の動作を変更する必要があるか判断します。名前解決の問題では、名前の問い合わせに失敗しているのか、アドレスは取得できても到達できないのか、接続ポリシーの選択が間違っているのかを区別してください。

必要最小限のフィールドから始める

dns-server = systemは、システムが提供するDNSの参照先を使う設定です。比較の基準として使えますが、どのネットワークでも必ず同じ結果になるわけではありません。システムが取得するDNSサーバーは、Wi-Fi、モバイル通信、上位ルーターの環境によって変わります。テスト時には接続中のネットワークも記録してください。同じファイルで結果が異なっても、設定の保存に失敗したのではなく、名前解決の経路が変わっただけの場合があります。

[General]
dns-server = system

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

この例は、ドメインルールとシステムの名前解決の関係を切り分けるためのもので、一般的な推奨設定ではありません。既存の設定にほかのGeneral項目が含まれていても、例に合わせてすべて削除する必要はありません。まずバックアップを取り、一度に変更するフィールドは1つにして、エラーの状況が変化するか確認してください。アプリ全体の設定とファイル内のフィールドが実際にどう作用するかは、現在のアプリの表示やリクエスト記録も確認してください。1つの例からすべての設定の優先関係を推測することはできません。

設定ファイル内の真偽値、アドレス一覧、数値パラメーターは、それぞれのフィールドで指定された形式に従う必要があります。値の後ろに説明文を付けたり、別のソフトにある同名フィールドから使える値を推測したりしないでください。特にプロキシのバイパス、除外ルート、DNS設定は名前が似ていても作用する層が異なります。トラフィックがそもそもクライアントに入っていない場合、Ruleの順序を変えても通常は期待した変化がありません。

名前解決とルールの一致

DOMAINとDOMAIN-SUFFIXは既知のホスト名を条件にできますが、IP-CIDRとGEOIPには宛先アドレスの情報が必要です。IPルールの評価にドメインの名前解決が必要な場合、DNSに失敗すると、これらの条件が期待どおりに評価されないことがあります。ルールに no-resolve が付いている場合は、そのIP条件のためだけに追加の名前解決を行わないという意味です。リクエスト全体でDNSを禁止する設定でも、すべての接続を数値アドレスに強制する設定でもありません。

アプリがIPアドレスへ直接接続したり、独自の仕組みでアドレスを取得したりする場合、クライアントが元のドメイン名を把握できるとは限りません。ブラウザーのアドレスバーにドメイン名が表示されていても、すべての接続に利用可能なドメイン情報が含まれるとは限りません。Webページは複数のホストからリソースを取得する場合があります。リクエスト記録を確認するときは、メインページ、静的リソース、APIリクエストを個別に見て、実際の条件がドメインとIPアドレスのどちらなのかを確認してから選んでください。

名前解決に成功しても接続できない場合があります。返されたアドレスに現在の経路から到達できない場合や、PROXYで使うサーバーから宛先にアクセスできない場合などです。DNSを変更して一時的に状況が変わっても、根本原因が解決したとは限りません。アドレスのキャッシュ、接続の再利用、宛先から複数のアドレスが返ることも観察結果に影響します。同じネットワークでテストを繰り返し、ページが最初に開いたかどうかだけでなく、実際の接続先アドレスも確認してください。

IPv6・キャッシュ・検証範囲

IPv6に対応したネットワークでは、異なるアドレスファミリーのアドレスが同時に返る場合があります。IPv4のネットワーク範囲だけをルールに記述しても、IPv6接続まで自動的に対象になるわけではありません。逆に、アドレスファミリーを制限しても、誤ったルートや名前解決の問題は解決しません。まず失敗した接続で使われたアドレスの種類を確認し、IP-CIDR6の追加や上位ネットワークの対応状況を検討してください。デュアルスタック環境の問題をすべてドメインルールのせいにしないでください。ドメイン条件とアドレスへの到達性は別の問題です。

キャッシュが残っていると、設定を変更しても変化がないように見えることがあります。DNSキャッシュには名前解決の結果が保存され、ブラウザーやアプリが既存の接続を再利用する場合もあります。ルールを保存しただけで、既存の接続が必ず最初から評価されるわけではありません。検証前に関連リクエストを終了し、必要であればクライアントを再接続してから新しいアクセスを開始してください。ページを続けて再読み込みすれば毎回新しい名前解決と接続が行われるとは限りません。記録の時刻と宛先アドレスのほうが参考になります。

複数のドメインを解決できない場合は、まずGeneralを利用可能な基準設定に戻し、現在のネットワークを確認してください。特定のドメインだけに問題がある場合は、スペル、Hostによる上書き、そのドメイン自体の名前解決結果を確認します。同じ宛先にDirectでは接続でき、Proxyでは失敗するなら、サーバー経由の経路を調べてください。DNSの参照先をむやみに変更し続ける必要はありません。接続トラブルの確認手順は接続中なのにインターネットにアクセスできない場合をご覧ください。

§03 / ドメイン条件

ドメインルールの種類

ドメイン条件は、サイトやサービス名に応じた振り分けを設定するときに便利です。よく使われるDOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORDは、同じ意味の別表記ではありません。マッチする範囲が順に広がり、誤って一致するリスクも異なります。まず、特定のホスト名、ドメインとそのサブドメイン、あるいは特定の文字列を含むすべてのホスト名のどれを対象にするかを決め、必要最小限の条件を使ってください。広いキーワード条件を先に書き、例外を大量に追加する方法は避けましょう。

DOMAINの完全一致

DOMAIN,example.com,PROXYは、ホスト名example.comへの接続にPROXYを使う指定です。同じサイトに属するapi.example.comまで自動的に対象になるわけではありません。完全一致ルールは、ログインAPI、ダウンロード用ホスト、確認済みの特定のリクエスト先などを個別に扱うのに適しています。適用範囲を説明しやすく、記録との照合も簡単です。一方、サイトで新しいリソース用ドメインが追加された場合は、ルールを追加するか再検討する必要があります。

ルールのドメイン部分に、スキーム、ポート、パスを含めないでください。完全なURLをDOMAINに指定すると、ホスト名の条件にURLの情報が混ざってしまいます。example.comの特定のページにアクセスするときも、ルールはパスの文字列を参照しません。同じホスト上の2つのディレクトリだけを区別したい場合、ドメインルールだけでは対応できません。まずアプリに適切なリクエスト処理機能があるかを確認してください。部分一致を期待してパスをDOMAINに書くことはできません。

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

この例では、api.example.comは先に完全一致ルールにマッチし、DIRECTになります。それ以外のexample.comのホスト名は、後続のサフィックスルールの対象です。この結果はルールの並び順によるもので、DOMAINがDOMAIN-SUFFIXより常に優先されるわけではありません。順序を入れ替えると、先にあるサフィックスルールがこのホスト名を処理し、そのルールにマッチしなかったリクエストだけが後続の条件に進みます。

DOMAIN-SUFFIXのドメイン境界

DOMAIN-SUFFIX,example.com,PROXYは、example.com自体と、そのサブドメインであるwww.example.comやapi.example.comなどにマッチします。ドメインのサフィックス境界に基づく条件であり、任意の文字列の末尾を比較するものではありません。notexample.comはexample.comのサブドメインではありません。サフィックスルールを書く前に、指定するのが対象のドメインか、ブラウザーからコピーした完全なURLかを確認してください。

サフィックスの前に、ワイルドカードのつもりでアスタリスクを付けないでください。このルール種別自体がマッチ方法を表しているため、example.comをそのまま指定します。サフィックスが短いほど、通常は対象範囲が広くなります。パブリックサフィックスや非常に広い組織ドメインを指定すると、関係のないリクエストにも影響する場合があります。設定を管理するときは、対象範囲の目的をコメントに残してください。後で広いルールがまだ必要か判断しやすくなります。

Webサイトのリソースがすべてメインドメインにあるとは限りません。画像、決済、認証、ファイルのダウンロードに別ドメインが使われている場合、メインドメインのサフィックスルールを追加しても一部の機能が失敗することがあります。これはDOMAIN-SUFFIX自体の不具合とは限りません。リクエスト記録で失敗したホスト名を特定し、対象のサービスに必要なものかを確認してから、範囲を明確にした条件を追加してください。ページ上のブランド名からリソースのドメインを推測しないでください。

DOMAIN-KEYWORDの適用範囲

DOMAIN-KEYWORD,example,PROXYは、ドメイン名にexampleを含む場合にマッチします。サフィックス条件より範囲が広く、同じ組織に属さないホスト名も含むことがあります。安定した命名規則があり、その適用範囲を許容できる場合に使います。短い語、一般的な語、ブランド名の略称をキーワードにすると、意図しないリクエストにマッチしやすくなります。ブロックに使う場合は特に注意してください。誤って一致すると、関係のないサービスまで利用できなくなる可能性があります。

種類条件の例マッチ範囲
DOMAINapi.example.com指定したホスト名に完全一致。
DOMAIN-SUFFIXexample.comドメイン自体とそのサブドメイン。
DOMAIN-KEYWORDexampleドメイン名に指定した文字列を含む。

既存の設定を整理するときは、まずキーワードルールに現在マッチしているホスト名を一覧にし、数個の完全一致ルールやサフィックスルールに置き換えられるか検討します。目的は行数を増やすことではなく、曖昧な条件を検証可能な範囲にすることです。一時的なトラブル対処では、すでに確認できている完全なホスト名を優先してください。結果を検証してから対象範囲を広げることで、偶然の一致を完全な解決策と誤認するのを防げます。

3種類の条件はいずれも、リクエストの最終的な成功を保証するものではありません。PROXYにマッチしても、利用可能なサーバーが必要です。DIRECTにマッチしても、現在のネットワーク環境に左右されます。REJECTにマッチすると、リクエストは拒否されます。ルールがマッチした記録がある場合は、ポリシーや接続経路を調べてください。ドメインの記述を変更し続ける必要はありません。該当する記録がない場合は、リクエストがクライアントに入っているか、古い接続が再利用されていないかも確認してください。

§04 / アドレスとリクエストの識別

IPと識別範囲

アドレスルールは、宛先IPやネットワーク範囲が明確な場合に使います。一般的な種類はIP-CIDR、IP-CIDR6、GEOIPです。ネットワーク範囲を指定するもので、ドメインが属する組織を特定する条件ではありません。また、アプリの動作を完全に識別するものでもありません。同じサービスが複数のアドレスを使う場合や、1つの共有アドレスで複数のドメインが使われる場合もあります。設定前に、制御したいのが名前、ネットワーク範囲、識別可能なリクエストのどれかを確認し、異なる条件を混同しないようにしてください。

IP-CIDRとIP-CIDR6

CIDRでは、スラッシュの後ろに指定するプレフィックス長でアドレス範囲を表します。IPv4の 192.168.0.0/16 は対応するプライベートアドレスのネットワーク範囲を表し、192.0.2.10/32 は単一のIPv4アドレスを表します。プレフィックス長はポート番号でも、任意の範囲番号でもありません。ネットワーク範囲に合うアドレスを指定してください。アドレスと意味を把握していないプレフィックスを組み合わせると、意図せず広いネットワークを対象にするおそれがあります。

[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
IP-CIDR6,2001:db8::10/128,PROXY,no-resolve
FINAL,PROXY

IPv6にはIP-CIDR6を使い、単一のアドレスは/128で表せます。例の2001:db8::10は文書用の例示アドレスで、実際のサーバーではありません。fc00::/7はIPv6のローカルアドレス範囲です。この種のルールが必要かどうかは、ネットワーク構成によります。DIRECTを指定しても、システムが宛先に必ず接続できるわけではありません。ローカルルート、デバイスのファイアウォール、サービスの待ち受けアドレス、クライアントの対象範囲が結果に影響します。

LAN上のプリンターや管理画面にアクセスできない場合は、まず接続先の実際のアドレスを確認し、リクエストがクライアントに入っているかを調べてください。システムが直接処理するアドレスがあり、Ruleに記録されないのは異常ではありません。一方、プライベートネットワーク範囲にDIRECTを追加しても、すべてのデバイスが自動的に検出されるわけではありません。自動検出で使うブロードキャストやマルチキャストと、特定アドレスへの通常の接続は別の仕組みです。それぞれ分けて検証してください。

GEOIPとno-resolve

GEOIP,CN,DIRECTは、宛先IPの地理的な分類がCNの場合にマッチします。判定対象はアドレスデータベース上の分類です。Webページの言語、ユーザーの所在地、ドメインの末尾、サイト運営者の所在地を判定するものではありません。データベースの更新が遅れていたり、サービスのアドレスが変わったりする場合があるため、特定サイトに常に同じポリシーを適用する保証にはなりません。例外処理が必要なドメインには、前方に完全一致ルールを置くほうが確認しやすいことがあります。

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

no-resolveを付けたIPルールは、その条件を判定するためだけに、アドレス情報がまだないドメインを追加で名前解決しません。リクエストの宛先がもともとIPアドレスの場合や、利用可能なアドレス情報がすでにある場合は、ルールにマッチすることがあります。このパラメーターは「すべてのIPルールを無効にする」ものでも、特定のルールの優先順位を上げるものでもありません。判定のために追加の名前解決を行うか、その処理に依存するかに応じて設定してください。

ドメインルールとGEOIPが併存する場合、先行するドメイン条件にマッチすると、後続の地理条件は通常そのリクエストのポリシーを決めません。特定のドメインを常にPROXYにしたい場合は、明確な例外を広範なアドレス分類より前に置いてください。名前解決を減らす目的で機械的にすべてのルールへno-resolveを付けると、名前解決結果に依存する振り分けが機能しないことがあります。最適化の前に、正しい動作を再現できる基準を用意してください。

USER-AGENTの識別範囲

USER-AGENTは識別可能なリクエストヘッダーの内容を条件にするもので、アプリ名を指定するルールとして使うものではありません。対応するHTTP情報をクライアントが読み取れる場合に使います。例の USER-AGENT,ExampleClient*,DIRECT は、パターンで特定のリクエストヘッダーを表します。ExampleClientは説明用の値で、実際の記録に該当する内容がある場合にのみ意味があります。スマートフォンのホーム画面にあるアプリ名を入力しても、アプリ単位の振り分けが自動で行われるわけではありません。

通常のHTTPS接続ではリクエストヘッダーが暗号化されているため、ネットワーク接続情報が見えるだけでUser-Agentを読み取れるとは限りません。ルールをマッチさせるためだけに、追加のコンテンツ処理を有効にしたり証明書をインストールしたりしないでください。通常の振り分けには、まず確認できるドメインやアドレスの条件を使います。リクエスト単位の詳細な条件は、確認できる範囲、処理条件、プライバシーへの影響を理解したうえで、管理された対象で検証してください。

USER-AGENTルールに一度もマッチしない場合は、順に確認してください。リクエストヘッダーが参照可能か、パターンが実際の文字列に合っているか、前のルールがすでにマッチしていないか、接続が再利用されていないかを調べます。マッチしないことをすぐにプロトコルの非対応と決めつけたり、広いキーワードで一時的に問題を覆い隠したりしないでください。ルールが評価できる情報は、その時点でクライアントが取得している情報によって決まります。設定ファイルに識別条件を何行書いたかではありません。

§05 / 適用ポリシー

ポリシーと動作モード

Ruleの最後の主要なフィールドは通常ポリシーです。PROXY、DIRECT、REJECTは異なる処理結果を表しますが、それぞれ必要な条件は異なります。PROXYには利用可能なプロキシ経路が必要です。DIRECTは現在のネットワークから直接接続します。REJECTはリクエストを拒否します。これらの語を確認する前に、現在のGlobal Routingの選択状態を確認してください。Ruleの内容が正しくても、設定モードでリクエストを処理していない場合があります。ファイルを変更し続けると、トラブル対処が難しくなります。

PROXY・DIRECT・REJECT

PROXYは、マッチしたトラフィックをプロキシ経路で処理する指定です。基本的な設定ではHomeで選択中のサーバーを使うため、まずそのサーバーに接続できることを確認してください。ルール中のPROXYには、サーバーアドレス、パスワード、プロトコルのパラメーターは含まれません。すべての行にPROXYと書いても、ポート、認証、サーバー側の状態が自動で修正されるわけではありません。接続に失敗した場合は、「ルールにマッチしたこと」と「プロキシ接続が成功したこと」を別々の事実として記録してください。

DIRECTは、そのプロキシ経路を通さずに宛先へ直接アクセスする指定です。ただし、すべてのシステムネットワーク機能を介さないという意味ではありません。現在のネットワークのDNS、デフォルトルート、ほかのVPN設定、上位ネットワークの制限は引き続き接続に影響します。LAN上のリソースにDIRECTを使う場合は、デバイスがそのネットワークに実際に接続していることも確認してください。モバイル通信に切り替えた後は、DIRECTルールだけで以前アクセスできたプライベートアドレスに接続できるとは限りません。

REJECTは、マッチしたリクエストを拒否するための指定です。対象範囲が明確で、ブロックしてよいと確認できている場合に使います。障害を修復するポリシーではなく、ドメイン名だけから有害なコンテンツかどうかを判断するものでもありません。範囲が広すぎると、ページの本文は表示されても、ログイン、認証コード、ファイル転送などが失敗する場合があります。ブロックルールを追加した後は、トップページが開くかだけでなく一連の操作を確認してください。例外を増やし続けるより、元に戻せる手段を残すことも重要です。

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

Global Routingの3つのモード

Global RoutingのConfigモードは選択中の設定に従って振り分けます。Proxyモードは、そのモードの対象となるリクエストをプロキシ経由で処理します。Directモードは直接接続を使います。これらは動作モードであり、Rule内の3つのルールではありません。また、PROXY、DIRECT、REJECTと単純に一対一で対応するものでもありません。特にDirectモードは、現在の設定ファイルの先頭にルールが自動追加されるという意味ではありません。

画面上のモード主な用途確認するポイント
Config / 設定選択中の設定に従って振り分けます。現在のファイル、マッチしたルール、最終ポリシー。
Proxy / プロキシプロキシ経路などを確認するときに使います。選択中のサーバーと宛先への接続性。
Direct / 直接接続直接接続との比較に使います。現在のネットワークと直接接続の結果。

表のモードは、システム権限や除外設定などのネットワーク境界を回避できるものではありません。リクエストがクライアントに入っていない場合、モードを切り替えても経路が変わらないことがあります。Sceneなどの入口が画面にある場合は、その入口自体の設定に沿って現在の状態を確認してください。名前だけから有効なルールを推測することはできません。トラブル対処では、まずConfig、Proxy、Directのいずれか明確なモードに戻し、記録と照合してから次に進みます。

Configで失敗しProxyで成功しても、振り分けや設定に関係する部分を調べる手がかりになるだけで、ドメインルールの誤りが確定するわけではありません。DNS、Host、拒否ルール、フォールバックポリシーの違いも影響します。Proxyでも失敗する場合は、選択中のサーバーと宛先への経路を優先して確認してください。モードを切り替えるたびに新しい接続を作り、同じ宛先でテストしてください。そうすることで比較結果を判断しやすくなります。

カスタム名と実際の宛先

設定によっては、ルールの対象にポリシーグループ名や具体的なサーバー名を使います。このような名前は、現在の設定で参照可能なオブジェクトに対応している必要があり、任意のラベルを指定すればよいわけではありません。別の人の設定ファイルからグループ名だけ残し、対応する定義を含めないと、読み込み時の警告や動作上の問題が起きる場合があります。基本的なトラブル対処では、まずコピー上で意味を理解している組み込みポリシーを使って範囲を絞り、アプリのカスタムポリシー対応を確認しながら元に戻してください。複雑な構成を一度に移行するのは避けましょう。

設定を確認するときは、PROXYだけを検索しないでください。ルールが似た名前のポリシーグループを参照し、そのグループ内の選択先がHomeの現在の項目と異なる場合があります。ルールの対象、グループの選択、最終的な接続先サーバーをあわせて確認してください。「プロキシ」という表示があるだけで、経路が一致しているとは限りません。問題を共有するときは、個人のサーバー識別情報を中立的な名前に置き換えてもかまいませんが、オブジェクト間の対応関係は保ってください。情報を隠した結果、トラブル対処に必要な手がかりまで失わないようにします。

モードのテストが終わったら、普段使う予定のモードに戻し、現在の設定が引き続き選択されていることを確認してください。一時的にProxyにしてWebページが表示されても、Configの問題が解消したとは限りません。元に戻し忘れると、直接接続の例外も本来の意味を失います。初めてサーバーを選択し、接続スイッチをオンにする順序は入門ガイドをご覧ください。このページではモードとルールの適用範囲を解説します。

§06 / 優先順位

評価順序とフォールバック

Ruleを読むときの基本は、上から順に条件を確認し、最初に有効になった一致でポリシーが決まることです。すべての条件を採点して最も詳細なものを選ぶわけではありません。ルール種別、条件の長さ、ポリシー名だけで優先順位が自動的に上がることもありません。リクエストが特定の経路を通った理由を調べるには、まずマッチしうる最初のルールを見つけ、後続の条件が判断に使われなかったかを確認します。ファイル内で対象ドメインが最後に出てくる箇所だけを検索しないでください。

例外を広い条件より前に置く

example.comとそのサブドメインを既定でPROXYにしつつ、api.example.comをDIRECTにする場合は、完全一致の例外をサフィックス条件より前に置きます。これは管理しやすい並べ方であり、必須の文法ではありません。すべてのサブドメインに同じポリシーを適用するなら、前のルールに上書きされる完全一致ルールを残す必要はありません。実際には機能していないルールを削除すると、現在もリクエストを制御しているという誤解を防げます。

[Rule]
# 完全一致の例外を先に評価
DOMAIN,api.example.com,DIRECT

# 同じドメインのほかのリクエストを処理
DOMAIN-SUFFIX,example.com,PROXY

# 最後に残りのリクエストを処理
FINAL,DIRECT

キーワードルールは特に配置に注意が必要です。上のほうに DOMAIN-KEYWORD,example,REJECT があると、この例のapi.example.comは先に拒否され、後のDIRECTで「修正」されることはありません。想定外の結果になった場合は、対象の近くにある数行だけでなく、その前にある広範な条件をすべて確認してください。ルールが増えるほど、各グループの範囲や例外をコメントで説明する必要があります。ルール種別の名前だけで説明の代わりにはなりません。

アドレスルールも同じ考え方で確認します。特定のドメイン条件にすでにマッチしている場合、後続のGEOIPはそのリクエストのポリシーを決めません。先行するIP条件でアドレス情報が必要な場合は、名前解決の動作もマッチ結果に影響します。ルールを並べる際は、論理的な適用範囲だけでなく、必要な情報を取得できるかも考慮してください。まず表現したい動作を明確にしてから、名前解決の負荷を検討します。問い合わせを1回減らすために重要な例外をマッチしない位置へ移動しないでください。

FINALは最後に残るリクエストを処理

FINAL,PROXYは、それ以前のルールにマッチしなかったリクエストにPROXYを使う指定です。FINALにドメインやアドレスの追加パラメーターは不要で、後ろに記述した値がポリシーになります。関連するルール一覧の末尾に置いてください。途中に置くと、フォールバックに進んだリクエストは後続のルールまで評価されません。ファイルにFINALが複数ある場合、段階的なフォールバックとして扱わず、意図がわかる1つの最終ルールに整理してください。

FINALにDIRECTとPROXYのどちらを指定するかは、設定の目的によります。どちらの書き方が常に正しいということはありません。多数の直接接続例外とFINAL,PROXYを組み合わせる構成と、少数のプロキシ用ドメインにFINAL,DIRECTを組み合わせる構成では、既定の対象範囲が異なります。2つの設定を比較するときは、先行する例外と末尾のポリシーをあわせて確認してください。FINALの1行だけを比べると、大半のリクエストを実際に決める条件を見落とし、設定者の意図を誤解しやすくなります。

フォールバックルールが、接続障害時に自動で経路を切り替えるわけではありません。リクエストがPROXYにマッチして接続に失敗しても、クライアントが後続のDIRECTや別のFINALを続けて試すとは限りません。後続ルールは予備サーバーの一覧ではありません。サーバー単位の選択や復旧が必要な場合は、該当する選択機能を確認してください。同じドメインに別のポリシーを続けて記述する方法では解決できません。振り分けの判定と接続失敗後の処理を分けて考えることが、ルールの動作を理解するうえで重要です。

競合・重複・ルールの統合

条件もポリシーも完全に同じルールが重複している場合、通常は読みづらくなるだけです。条件が同じでポリシーが異なる場合は、どちらが先にあるか、両方を残す理由があるかを確認してください。Rule全体を単純にアルファベット順へ並べ替えることはできません。例外と広い条件の関係が変わってしまうためです。整理する前に、明示的なブロック、単一ドメインの例外、ドメイン群、アドレス範囲、フォールバックなど、用途ごとに分類してから、本当に同じ意味のルールを整理します。

2つの設定を統合するときに、2つ目のRuleセクションとFINALをそのまま1つ目の後ろに追加しないでください。それぞれの意図を確認し、互いに上書きするドメイン、異なるポリシー名、重複するフォールバックがないか調べてから、説明可能な1つの一覧にまとめます。リモートのルール内容が変わった場合も、新しい条件で対象範囲が広がっていないか再確認してください。以前動作したとしても、更新後も同じマッチ関係が維持されるとは限りません。

並び順を検証するには、コピー上で競合する条件だけを残し、同じ宛先に対して新しいリクエストを繰り返し作成して、記録に表示されるマッチ種別とポリシーを確認します。上方の広いルールを削除した後で結果が変われば、上書き関係が原因の可能性があります。変化がない場合は、別のファイルを編集していないか、Config以外のモードを使っていないかを調べてください。ルールを次々と先頭へ移動するより、対象を絞って根拠を確認するほうが、安定した結論を得やすくなります。

§07 / 名前とアドレスの書き換え

HostとURL Rewrite

HostとURL Rewriteはいずれもアクセス結果を変える場合がありますが、処理する層が異なります。Hostはホスト名にアドレスを割り当て、URL Rewriteは条件に合うリクエストURLを処理します。どちらもプロキシサーバーを選択する機能の代わりではなく、サブスクリプション情報を記述する場所でもありません。トラブル対処ではRuleと分けて考えてください。DIRECTに正しくマッチしていても、Hostが古いアドレスを示しているために失敗する場合があります。逆に、リクエストを書き換えた結果、別のドメインが記録されることもあります。

Hostによる静的マッピング

Hostセクションでは、一般的な静的マッピングを example.com = 192.0.2.10 のように記述します。左側がホスト名、右側がアドレスです。スキームやWebページのパスは記述しません。192.0.2.10は文書用の例示アドレスであり、実際のサイトには使えません。実際の設定には、自分が管理するか、使用を確認できているアドレスを指定してください。固定マッピングが必要なホストだけを対象にし、サイトのリソース用ドメインすべてが同じアドレスだと推測しないでください。

[Host]
# 文書用の例示アドレス。形式の説明にのみ使用
example.com = 192.0.2.10
api.example.com = 192.0.2.20

固定マッピングで変更されるのは名前解決の結果であり、TLSで使われるサイトの識別情報ではありません。HTTPS接続では、接続先サーバーが該当ドメインを正しく処理し、要件を満たす証明書を提供する必要があります。ドメインを応答可能なアドレスに向けるだけで、ページが利用できるとは限りません。別のサービスのアドレスを指定すると、証明書エラー、既定のページ、接続拒否などが発生する場合があります。誤ったマッピングを隠すために証明書チェックを無視せず、正しい接続先に戻してください。

Hostはポート設定の代わりにもなりません。同じサーバー上でも、ポートによってサービスが異なる場合があります。静的マッピングが表すのは名前とアドレスの対応関係だけです。アプリが誤ったポートに接続している場合は、該当する接続設定や宛先URLを修正してください。トラブル対処では、元のホスト名、解決されたアドレス、実際のポートを記録し、それぞれ照合します。ドメインを解決できるかだけでは、最終的な接続先が正しいか判断できません。

URL Rewriteの条件と結果

URL Rewriteルールでは通常、正規表現で対象のURLを指定し、置換先と対応するアクションを設定します。次の例は、説明用ドメインへのHTTPアクセスをHTTPSへリダイレクトし、キャプチャしたパスを保持するものです。書式を示す例なので、コピーする前にマッチ範囲と置換結果を理解してください。対象のリクエスト内容を確認できない状況では、ルールを設定してもすべての接続を処理できるわけではありません。

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

正規表現の ^ は先頭を示し、\. はドットそのものを表します。(.*) は後続の文字列をキャプチャし、置換先の $1 は最初のキャプチャグループを参照します。ドットをエスケープしないとマッチ範囲が広がり、ホスト名の境界を指定しない式では意図しない宛先まで対象になる場合があります。ルールを「適用しやすくする」ために境界を削除しないでください。具体的なリクエストに当てはめ、どのような置換結果になるかを1つずつ確認します。

リダイレクトによってクライアントが新しいアドレスへ再度アクセスする場合があるため、ループにならないか確認してください。たとえば、一方のルールでURL AをURL Bに変更し、もう一方でBをAに戻すと、アクセスが復旧せずリクエストが繰り返されます。クエリパラメーターを扱う場合は、キャプチャ範囲で必要な情報が保持されるかも確認してください。認証処理やページ送りのパラメーターが失われるおそれがあります。ログインや決済に使う前に、制御された単純なHTTPの宛先で検証してください。

適用範囲と元に戻す方法

通常のHTTPSではパスとリクエストヘッダーが暗号化されているため、クライアントが宛先ドメインを認識していても、完全なURLを読み取れるとは限りません。この章では、書き換えのために証明書やコンテンツ復号の設定を追加することは求めていません。ホストごとにPROXYとDIRECTを切り替えたいだけなら、Ruleを使うほうが簡潔です。識別可能なリクエストURLを変更する明確な必要がある場合にのみRewriteを検討してください。ドメイン振り分けを強化するルールとして、安易に重ねて使わないでください。

トラブル対処では、HostのマッピングとRewriteのルールを別々に無効化してください。両方を同時に削除して、そのどちらかに原因があったと判断しないようにします。まず元の名前解決に戻して宛先アドレスを確認し、次に書き換えなしでリクエストをテストします。その後、Rewriteを1つずつ戻し、最初に差が現れた手順を記録してください。古いアドレス、正規表現の範囲、ループ、宛先サービスの動作を切り分けやすくなり、正常なリダイレクトをプロキシ接続の障害と誤認することも防げます。

長期間使うマッピングや書き換えルールは、定期的に確認してください。サービス移転後は固定IPが使えなくなることがあり、サイトのパス変更後は古い正規表現がマッチしなくなったり、新しい業務用URLまで対象にしたりする場合があります。コメントには用途と検証方法を記録し、実際の認証情報は書かないでください。用途を説明できない項目は、古い設定にあったからという理由で残し続けず、コピー上で無効にして動作を確認しましょう。メンテナンスでは、動作を理解でき、元に戻せる状態を保つことが重要です。

§08 / 設定の検証

設定の検証とメンテナンス

設定を検証する目的はルールを増やすことではなく、変更のたびに結果の理由を確認できるようにすることです。開始前に、現在のネットワーク、Global Routingのモード、選択中のサーバー、設定ファイルを記録し、安定した明確なテスト対象を選んでください。これらの前提が同時に変わると、結果がどの変更によるものか判断しにくくなります。利用可能と確認済みの基本設定をコピーで保存し、新しいルールはまずテスト用のコピーに追加して検証してから、日常の接続に使ってください。

最小限で説明可能な設定を作る

最小限の設定には、テスト対象の条件と明確なFINALがあれば十分です。最初からすべてのセクションを含める必要はありません。ドメインの例外をテストするときはHostとRewriteを加えず、名前解決をテストするときは多数のアドレス条件を混在させないでください。長期的に簡素なルールだけを使うという意味ではありません。1つの現象に対する原因候補を減らすためです。各行の目的を一言で説明できれば、残すか、移動するか、削除するかを判断しやすくなります。

[General]
dns-server = system

[Rule]
# 指定したホストがプロキシ経由で処理されるか確認
DOMAIN,example.com,PROXY
FINAL,DIRECT

設定例で確認できるのは、指定した条件下での動作だけです。あらゆるアクセスに適しているとは限りません。使用する前に利用可能なサーバーがあることを確認し、Configモードでテストしてください。例示ドメインへアクセスする必要がない場合は、自分が確認中でアクセス権のある宛先に置き換えられます。ただし、指定するのはホスト名だけです。テストに成功した後、ほかのルールを少しずつ戻し、追加するたびに検証してください。問題が初めて発生した変更を特定しやすくなります。

LANの問題では、自動検出リストを見るだけでなく、確認済みのアドレスを使ってサービスのポートへ接続するほうが有用です。Webページの問題では、本文、ログイン、静的リソースを分けて確認してください。ページを1つ表示できても、サイト全体に同じポリシーが使われているとは限りません。記録から実際に失敗したリクエストを選び、ホスト名、アドレス、時刻を確認してください。同時に発生したバックグラウンド接続をすべて障害の一部とみなす必要はありません。

記録をもとに失敗段階を切り分ける

第1段階では、リクエストがクライアントに入っているかを確認します。記録がまったくない場合は、ルールを変更する前に、接続スイッチ、システム権限、対象範囲、古い接続の再利用を確認してください。初回の権限許可に関する問題はVPN構成の追加許可画面についてをご覧ください。リクエストが記録されたら、第2段階として、ドメインやアドレスの情報がそろっているか、現在の設定ファイルの順序に応じたルールにマッチしているかを確認します。

第3段階では、ポリシー適用後の接続経路を調べます。PROXYにマッチして失敗する場合は、選択中のサーバー、プロトコルパラメーター、宛先への到達性を確認してください。DIRECTにマッチして失敗する場合は、現在のネットワークと宛先サービスを確認します。REJECTにマッチした場合は、意図した拒否かをまず確認してください。Connectivity Testはサーバーへの接続性を確認するのに役立ちますが、テスト対象と実際のサービスは異なります。テストに成功しても、すべてのWebページへアクセスできる証明にはなりません。ツールの結果と実際のリクエストを分けて記録してください。

第4段階では、キャッシュと状態の違いを切り分けます。変更後に保存し、該当ファイルが引き続き選択されていることを確認してから、古いリクエストを終了します。必要に応じて再接続し、同じ宛先へアクセスしてください。比較中はネットワークを変えず、Wi-Fiからモバイル通信に切り替えたりサーバーを変更したりしないでください。特定のネットワークだけで問題が起きる場合は、そのネットワークの名前解決やルートの違いを優先して調べます。すべてのネットワークで起きる場合は、設定の共通部分や宛先サービスを検討してください。

バックアップ・更新・問題の記録

メンテナンス記録には、「ネットワークを修正」のような結論だけでなく、変更の目的、対象ルール、検証方法を明記してください。「指定ホストのDOMAIN例外をサフィックス条件より前に移動し、再接続後にDIRECTへマッチした」と記録すれば、「ルールを移動したら直った」だけの場合より再現しやすくなります。共有する記録からは、プライベートなサブスクリプションのパラメーターや認証情報を削除し、問題の説明に必要な構成と匿名化した宛先だけを残してください。

確認された状況まず確認する項目変更範囲を広げない
該当するリクエスト記録がない接続状態、権限、対象範囲、古い接続。ドメインルールを重ねて追加しない。
意図しないポリシーにマッチモード、現在のファイル、先行する上書き条件。DNSとサーバーを同時に変更しない。
想定したポリシーにマッチしたが接続に失敗名前解決の結果と、そのポリシーで使う実際の接続経路。接続エラーを並び順の誤りと決めつけない。
更新後に動作が変わった設定の差分、ポリシー名、新しく追加された条件。復元可能な基準設定を上書きせず、先にコピーを保存。

リモート設定を更新する前にローカルの変更を保存してください。更新後はファイルの長さだけで判断せず、General、Rule、Host、Rewriteに実質的な変更がないか比較します。サーバーサブスクリプションの更新では、接続先の項目が残っているか、現在の選択が変わったかを別途確認してください。2種類の更新を混同しないようにします。自分で設定ファイルを管理する場合は、自動更新の内容と手動で追加した例外の管理方法を明確にし、次の更新で修正内容が上書きされないようにしてください。

元に戻す場合は、利用可能と確認済みの設定コピーに切り替え、モードとサーバーを改めて確認してください。最後の1行だけを取り消せば状態がすべて復元されるとは限りません。復元後は同じ宛先で再検証し、それから追加のテストを行うか判断します。原因を特定できない場合は、よくある質問の項目を確認し、最小限の再現手順を添えてください。インストールや入手方法の問題はダウンロードページのインストール許可手順をご覧ください。このページのルール変更は、システムへのインストールや権限設定の手順に代わるものではありません。