Shadowrocketのルールと設定ガイド

01 · 設定ファイルの構成と編集時の注意点

SubscribeとConfigの違い

Subscribeは通常サーバーリストの更新に使い、Configは接続動作とリクエストの振り分けを管理します。両者は別々の既存ソースから取得できます。サーバーリストでノードを選択できても、接続情報がクライアントに登録されていることを示すだけで、特定のルールが有効とは限りません。反対に、内容がそろった設定を読み込んでも、そこに指定されたプロキシ出口が利用できるとは限りません。編集を始める前に、Homeで選択中のサーバー、Configで使用中のファイル、Global Routingの現在のモードをそれぞれ確認してください。異なる3つの状態を一つの切り替えとして扱わないことが大切です。

設定ファイルは角括弧内のセクション名で役割が分かれています。Generalには接続や名前解決の全般設定、Ruleには順番に評価される振り分けルール、Hostにはホスト名とアドレスの対応、URL Rewriteには条件に合うリクエストURLの書き換えを記述します。セクション名は単なる説明文ではありません。角括弧内の名前を日本語に置き換えないでください。同じファイル内の設定項目は、対応するセクションの下に記述します。たとえばFINALはRuleのルールです。セクション表記を省略してGeneralの設定の後に書くと、意図しない解析結果になることがあります。

# 構成例：各セクションの役割のみを表示
[General]
dns-server = system

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

[Host]
intranet.example.com = 192.0.2.10

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

コピーを使って元に戻せる形で編集する

上の例は、あらゆるネットワークで使える完成済みの設定ではありません。特にHostのマッピングには文書用アドレスを使っています。実際に使用する際は、この例の項目を削除するか、ご自身が管理する内部アドレスに置き換えてください。既存ファイルを編集する前に、正常に動作するコピーを保存し、選択中のファイル名とモードを記録してから、テスト用ファイルを別に作成します。一度に変更するのは一つの動作だけにしましょう。たとえば、まずDOMAINルールを1つ追加してヒットを確認し、その後DNSを調整します。4つのセクションを同時に変更すると、元に戻してもどの変更が影響したのか分からなくなります。

設定ファイルは半角の英語記号を使うプレーンテキストです。等号、カンマ、角括弧を全角に置き換えないでください。文書ソフトからコピーする場合は、自動置換された引用符や見えない空白にも注意が必要です。行全体をコメントにする場合は先頭にシャープ記号を付けます。説明文は別の行に書き、長い日本語の説明をルールのポリシーの後ろに続けないでください。拡張子だけでは内容の正しさは分かりません。任意のテキストの拡張子を.confに変えても、構文が補われるわけではありません。保存後はConfigに戻り、ファイルが正常に読み込まれることと、編集したコピーが選択されていることを確認してください。

ローカル編集とリモート更新の関係

リモート設定は、次回の更新時にローカルの内容を上書きすることがあります。個別ルールを長く維持するには、まず現在のファイルがリモート更新の管理対象かどうかを確認し、ローカルコピーを使うか、アプリで提供されている編集方法を選びます。「保存したばかり」という理由だけで変更が保持されたと判断しないでください。ファイルを開き直し、目的のルールが想定した位置に残っていることを確認し、更新後にも再検証する方法が確実です。サブスクリプションURLにアクセス情報が含まれる場合があります。公開メモやトラブル時のスクリーンショットに記載しないでください。他の人に問題を説明するときは、ルールの種類と発生状況だけを共有しましょう。

このページで扱っていないセクションや項目が設定ファイルに含まれていても、例に合わせるためにセクションごと削除しないでください。既存の設定がローカルネットワーク、名前解決、特定リクエストの処理を担っている場合があります。該当項目の役割を確認してから、残すかどうかを判断してください。分からない場合は、元のコピーに戻ってテストします。このページは、まずセクションの役割を確認し、次に個別ルールを調べ、最後にポリシーと照合順序を確認する流れで参照してください。「構文として読み込めること」と「実際の動作が正しいこと」を分けて確認でき、見た目が整っているだけで設定を有効と判断するのを防げます。

02 · General、DNS、接続の前提

全般設定は振り分けルールの代わりにはならない

Generalの項目は接続や名前解決の基本動作に影響し、Ruleは条件に一致したリクエストに適用するポリシーを決めます。両者には関係がありますが、互いに代用できません。たとえばDNSサーバーを変更すると、対象ドメインから取得されるアドレスが変わることはありますが、明示されたDOMAINルールのPROXYがDIRECTに変わるわけではありません。Ruleを変更しても、誤記されたサーバーアドレスは直りません。問題を調べるときは、対象ドメインの名前解決、リクエストの振り分け、プロキシサーバーへの接続を別々に検証してください。接続できない原因をすべて「ルールの問題」と決めつけないようにしましょう。

[General]
# システムのDNS設定を使用
dns-server = system

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

この設定例では、完全一致するドメイン名example.comをPROXYに、それ以外の未一致リクエストをDIRECTに振り分けます。dns-serverのsystemは、システムが提供するDNS設定を使うことを意味します。現在のネットワークで、すべてのドメインを正しく名前解決できるとは限りません。ネットワークを切り替えたあとに動作が変わった場合は、まずシステムのネットワークと名前解決の条件を確認し、その後にアプリの設定を検討してください。見知らぬ設定から複数のDNSアドレスをそのままコピーするのは避けましょう。DNSサービスへの到達性、応答内容、現在のネットワークとの相性を確認する必要があります。項目数が多いほど確実に名前解決できるわけではありません。

ドメインルールとIPルールで判定対象が異なる

DOMAINとDOMAIN-SUFFIXはホスト名を判定し、IP-CIDRとGEOIPはアドレスを判定します。リクエストにドメイン名が保持されていれば、先行するドメインルールで出口を決められます。アドレスが必要なルールに対して、リクエストにドメイン名しかない場合は、名前解決が行われることがあります。解決されたアドレスはネットワーク、キャッシュ、サーバー側の振り分けによって変わる場合があるため、同じドメインでも毎回同じアドレス範囲ルールに一致するとは限りません。診断記録ではリクエストのドメイン名と実際の接続先アドレスを両方確認してください。ブラウザーのアドレスバーだけでは接続情報を把握できません。

IP-CIDRにno-resolveを付けると、そのアドレスルールのために名前解決を行うのを避けられます。「クライアント全体でDNSを使わない」という意味でも、すべてのドメインを無視するという意味でもありません。判定可能なアドレスをリクエストがすでに持っていれば、対応するネットワーク範囲に一致する場合があります。ドメイン名しかなく、判定に適したアドレスがない場合は、後続ルールの評価に進みます。このパラメーターを付けるかどうかは、どの段階でルールを評価したいかによって決めます。すべてのIPルールに必要な高速化設定として扱わないでください。

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

IPv6、ローカルネットワーク、キャッシュの注意点

IPv4のネットワーク範囲ルールがIPv6アドレスを自動的に対象にすることはありません。ネットワークや接続先がIPv6を使う場合は、適切なIP-CIDR6ルールが必要か、既存の接続設定でどのアドレス経路が許可されているかを確認してください。特定のアドレスファミリーを無効にすると一時的に症状が変わることはありますが、根本原因が解決したとは限りません。ローカルネットワーク内のデバイスも、すべてホスト名でアクセスできるとは限りません。ローカル探索、固定アドレス、異なる待ち受けポートなど、デバイスごとに条件が異なります。まず対象デバイスが同じネットワークにあるか確認し、振り分けルールが関係しているかを判断してください。

名前解決のキャッシュや確立済みの接続によって、テスト結果に変更がすぐ反映されないことがあります。DNSやHostを変更したあとは、新しいリクエストを送信し、必要なら再接続して、新しい診断記録を確認してください。古いページがすぐ変わらないからといって、設定を次々に追加しないでください。既存設定のipv6やbypass-systemなどの項目は、アプリ内の説明に従って適用範囲を確認します。項目名だけで作用を推測しないでください。特にシステムサービスやローカルネットワークの処理には、OS独自の経路も影響する場合があります。

「ドメイン名では開けないが、アドレスを直接指定すると接続できる」場合でも、すぐにHostを設定すべきとは限りません。多くのサービスは正しいHostリクエストヘッダー、TLS証明書の名前、サーバー側のルーティングを必要とするため、アドレスでのアクセスが失敗することもあります。名前解決、接続の確立、証明書の検証をそれぞれ確認してから、次の対処を決めてください。その他の症状はFAQのルール・トラブル対処も参照してください。元の動作する設定を残し、テスト用コピーでのみ名前解決の項目を変更することが、ネットワーク復旧後に潜在的な問題を残さない基本です。

03 · Ruleの種類とパラメーターの意味

ルールは条件、ポリシーの順に記述する

よく使うルールの多くは「種類、照合対象、ポリシー」の順で記述し、フィールド間は半角カンマで区切ります。種類によって後続フィールドの解釈が決まります。同じexample.comでも、DOMAINの後なら完全一致するドメイン名、DOMAIN-SUFFIXの後ならドメインのサフィックスを表します。ポリシーはルールに一致した後の処理であり、照合条件の一部ではありません。FINALは特別なフォールバックルールで、ドメインやアドレスのパラメーターは不要です。そのためFINAL,PROXYと記述します。機械的に3つ目のフィールドを追加すると、明確な意味が損なわれます。

3種類のドメインルールの使い分け

DOMAIN,api.example.com,PROXYはapi.example.comだけに適用され、www.example.comやexample.comには自動的に適用されません。同じサイトのルートドメインとサブドメインをまとめて一つのポリシーにする場合は、DOMAIN-SUFFIX,example.com,PROXYが適しています。サフィックスの照合はドメイン階層の境界に基づき、任意の文字列末尾を検索するものではありません。照合対象にはhttps://、ポート番号、パス、クエリパラメーターを含めないでください。これらはドメイン名の一部ではなく、含めても期待どおりに一致しないことがあります。

DOMAIN-KEYWORD,example,PROXYは、ドメイン名にexampleが含まれるかを判定します。example.comとは無関係のホスト名も対象になる可能性があるため、ブランド名の一部だけを根拠にサイト全体の振り分けを行う方法には向きません。まず境界が明確なDOMAINまたはDOMAIN-SUFFIXを使い、文字列での条件が本当に必要な場合にだけDOMAIN-KEYWORDを選びましょう。キーワードadsも正確な広告一覧を意味するわけではなく、通常のサービス用ドメインに一致することがあります。REJECTに使う場合は、通常のコンテンツまでブロックしないよう、実際のリクエストを確認してください。

[Rule]
DOMAIN,api.example.com,PROXY
DOMAIN-SUFFIX,example.org,DIRECT
DOMAIN-KEYWORD,tracking,REJECT
GEOIP,CN,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR6,fc00::/7,DIRECT,no-resolve
USER-AGENT,ExampleClient*,PROXY
FINAL,PROXY

アドレス、地域、リクエストヘッダーに基づくルールの限界

GEOIP,CN,DIRECTは、接続先IPの地域分類に基づいてポリシーを決めます。Webページの言語、サイト運営会社の所在地、ドメインの末尾を判定するルールではありません。コンテンツ配信ネットワークを利用するサイトでは、アクセス先の地域によって異なるアドレスが返ることがあり、IPデータベースにも更新状況や判定範囲の限界があります。常に特定の出口を使いたいドメインは、明示的なドメインルールにしてGEOIPより前に置いてください。IP-CIDRのスラッシュ後の数字はプレフィックス長です。値が大きいほど通常は対象範囲が小さくなります。IPv4アドレス1つだけを指定する場合は/32を使い、アドレスの後ろにポート番号を付けてネットワーク範囲の代わりにしないでください。

USER-AGENTは読み取り可能なリクエストヘッダーの内容を判定するルールであり、「特定のアプリを選ぶ」ための汎用機能ではありません。暗号化された通信のヘッダーは通常そのまま読み取れないため、USER-AGENTルールがすべてのHTTPSリクエストに適用されるとは限りません。このルールのためだけに復号範囲をむやみに広げないでください。例のアスタリスクはマッチパターンの一部で、ExampleClientは説明用の名前です。実在するアプリを指すものではありません。複数のアプリが同じヘッダーを使うことも、同じアプリがリクエストごとに異なる値を使うこともあります。実際の接続先ドメインの確認に代わるものではありません。

Ruleは実際の要件に合わせて簡潔に保ちましょう。完全なホスト名1つだけをプロキシ経由にするなら、広範なキーワード、地域全体、大きなアドレス範囲を先に追加する必要はありません。サイトのすべてのサブドメインを制御する場合も、現在見えているホスト名を一つずつ列挙する必要はありません。まず最小限の条件で期待する動作を再現し、必要に応じて範囲を広げます。不明なキーワードは用語集で確認できますが、最終的にはルール名から効果を推測するのではなく、現在のリクエストに一致するかを検証してください。

04 · PROXY、DIRECT、REJECTとモード

ルールのポリシーとGlobal Routingは別の選択項目

PROXYは一致したリクエストを現在のプロキシ出口に送り、DIRECTは接続先に直接接続し、REJECTはリクエストを拒否します。この3つのポリシーはそれぞれ別のサーバー情報を指すものではなく、PROXYという名前のノードが自動的に作成されるわけでもありません。PROXYを使う前に、ご自身が利用するサーバー情報を正しくインポートし、Homeで適切な出口を選んでください。設定ファイルで独自のポリシーグループ名を使っている場合は、設定内で定義され、名前の綴りが一致し、グループ内に有効な出口があることを確認します。

Ruleによる振り分けを検証する基本の環境は、Configモードです。ProxyモードとDirectモードは接続経路を比較するのに役立ちますが、Ruleの順序が正しいことの証明にはなりません。OSのサービス、ローカルネットワーク、アプリ固有の設定には、個別の処理範囲が存在することもあります。モード名を、デバイス上のすべての通信に無制限に適用されるものと考えないでください。モードを切り替えてテストする場合は、元の設定を記録します。テスト後はConfigに戻し、新しいリクエストでルールの動作を確認してください。戻し忘れると、その後の判断がすべてずれる可能性があります。

DIRECTは「クライアントの無効化」ではない

DIRECTルールは、その接続先へのリクエストを直接接続にするという意味です。Shadowrocketを終了したり、設定ファイルの残りをすべて無効にしたりするものではありません。クライアントは引き続き、他のリクエストの処理、名前解決、診断情報の記録を行うことがあります。ローカルネットワークのアドレス、内部サービス、通常の直接接続で問題ないドメインには、より具体的なDIRECT条件を設定できます。直接接続の成否は、現在のネットワークのルーティング、ファイアウォール、接続先サービスにも左右されます。DIRECTをすべての接続制限を回避する修復方法と考えないでください。

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

この例では、intranet.example.comをサフィックスルールより前に例外として置いているため、直接接続されます。example.comの他のホスト名は引き続きPROXYを使う場合があります。blocked.example.orgは明示的に拒否されます。最後のFINAL,DIRECTは、どのルールにも一致しない残りのリクエストを直接接続にします。すでに一致したリクエストが、後から末尾のルールに戻って評価されるという意味ではありません。設定を読むときは各行を個別に確認し、まず条件、次にポリシー、最後にファイル内の位置を踏まえて適用範囲を判断してください。

REJECTによる拒否と接続失敗の違い

REJECTは意図的にリクエストを拒否するルールであり、「プロキシ接続に失敗したら自動で直接接続する」という意味ではありません。対象を意図的に拒否した結果、ページが白くなる、リソースが読み込まれない、アプリにネットワークエラーが表示されることがあります。使用前に、その対象を拒否しても問題がなく、ログイン、画像、APIなどの別機能に影響しないことを確認してください。REJECTルールを削除してページが復旧した場合は、すぐにサイトの全リクエストをプロキシ経由にするのではなく、照合条件を絞り込みます。キーワードの範囲が広いほど、関連する通信まで影響を受けやすくなります。

PROXY経由の接続が失敗しても、すぐにFINALをDIRECTに変更しないでください。失敗はサーバーアドレスの名前解決、ポートへの接続、プロトコル認証、接続先へのアクセスなど、異なる段階で発生する可能性があります。フォールバックを変更すると未一致のすべてのリクエストに影響し、元の問題が見えにくくなることがあります。まずConnectivity Test、または対象を明確にしたリクエストで現在の出口を確認し、ご自身が利用する接続情報を照合します。接続テストに成功しても、特定サイトに接続できるとは限りません。一つのテスト結果だけですべてのリクエストが成功すると判断しないでください。

On Demandは接続をいつ確立または復旧するかを制御する機能であり、どのドメインに一致させるかを決めるものではありません。Global RoutingやRuleとは役割が異なります。接続が確立していない場合は、まず接続状態とオンデマンド条件を確認してください。接続済みなのに出口が想定と異なる場合は、振り分けを確認します。カスタムポリシーグループがあると選択項目が増える場合もあるため、「現在のモード—一致したルール—指定されたポリシー—実際の出口」の順に確認してください。モードの詳しい説明はプロキシモードをご覧ください。ポリシーの流れを調べる代わりに、接続を何度も切り替えないでください。

05 · 照合順序、優先順位、フォールバック

先に一致したルールが適用され、名前による自動並べ替えはない

Ruleの一般的なルールはファイルの上から順に評価され、先に一致したリクエストは通常、後続のより具体的なルールを待ちません。DOMAINが「より正確に見える」からといってDOMAIN-SUFFIXより自動的に優先されたり、IP-CIDRがGEOIPより常に優先されたりするわけではありません。優先順位はまずルールの位置で決まります。ルールを整理するときは、明確な例外を前に、一般的な範囲をその後に、最後にフォールバックを配置してください。読みやすくなり、後から追加したルールとの競合も減らせます。

[Rule]
# 特定のホスト名を先に例外として指定
DOMAIN,api.example.com,DIRECT
# 同じサイトのほかのリクエストにはプロキシを使用
DOMAIN-SUFFIX,example.com,PROXY
# どのルールにも一致しないリクエストは直接接続
FINAL,DIRECT

この順序では、api.example.comは1行目に一致し、DIRECTになります。www.example.comは1行目に一致しませんが、2行目に一致してPROXYを使います。前後の行を入れ替えると、api.example.comが先にサフィックスの範囲に入り、DIRECTの例外が適用されにくくなります。ルールの優先順位をテストするには、両方の条件に一致する対象を選んでください。そうすれば、順序によって結果が変わることを確認できます。互いに重ならない2つのドメインへアクセスしても、ルールの適用範囲は検証できません。

FINALは後続へ評価が続く通常の条件ではない

FINALは、それ以前のルールに一致しなかったリクエストを処理するため、通常はRuleの最後に置きます。途中に置くと、後続の一般ルールが残りのリクエストを処理できなくなります。ファイル末尾に新しいルールを追加するときは、FINALより後ろに書いていないか確認してください。FINALを複数書いても、状況に応じて自動切り替えするフォールバックにはなりません。異なる範囲に別々のポリシーを適用したい場合は、フォールバックを繰り返すのではなく、それぞれの範囲の条件を明確にしてください。

[Rule]
DOMAIN,portal.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

この例では、ドメインの例外がアドレスの地域判定より前にあります。そのため、example.comがGEOIPに一致する可能性のあるアドレスに解決されても、先に一致したリクエストにはドメインルールが適用されます。リクエストにドメイン照合に使える情報がなければ、アドレス条件を続けて確認します。この違いをルールが不規則に動作していると解釈しないでください。判定に使える情報は、リクエストが処理に入る時点で何を保持しているかによって異なります。順序と条件のどちらに問題があるかを切り分けるには、ホスト名、接続先アドレス、一致した行、最終ポリシーを記録してください。

重複、包含、リモート設定の上書き

ルールの重複は必ずしも構文エラーにはなりませんが、メンテナンスの手間を増やします。同じDOMAIN-SUFFIXを前でPROXY、後ろでDIRECTにしても、後のルールで想定どおりに上書きできるとは限りません。整理する前に同じドメインを検索し、より広いサフィックスやキーワードがすでにないか確認します。さらに、先行するアドレスルールに一致していないかも調べてください。重複を削除する前に元のコピーを保存し、必要な例外が含まれていないことを確かめます。整理の目的は単に行数を減らすことではなく、各ルールの作用を説明できる状態にすることです。

既存設定が外部ルールを参照している場合は、メイン設定内でその参照を置いている位置も確認してください。外部リストの内容だけでなく、その内容がいつ評価されるか、どのポリシーが適用されるか、更新後に範囲が変わっていないかも確認が必要です。仕組みが分からない参照を、名前だけで「優先度が高い」と判断しないでください。このページの個別例は、ローカルのテスト用コピーで基本条件を確認してから、既存の複雑な設定と一つずつ照合するために使えます。階層が不明な設定に検証なしで挿入するのは避けてください。

照合順序のテストに必要なルールは、例外1つ、範囲ルール1つ、FINALだけです。3つの動作を確認したあと、残りの項目を少しずつ戻します。追加するたびに同じテスト対象へアクセスし、新しい接続の記録を確認すれば、どの追加分がルールの重複を起こしたのか特定できます。Proxyに切り替えるとアクセスできるのにConfigではできない場合は、アプリを再インストールする前に、一致したポリシーを確認してください。一部のサイトだけを指定する詳しい方法はDOMAIN-SUFFIXルールの書き方をご覧ください。

06 · HostとURL Rewriteの適用範囲

Hostは名前解決の対応を変更し、接続先のポリシーは選択しない

Hostセクションでは、ホスト名に対応するアドレスを指定します。「この名前がどのアドレスに解決されるか」を設定するもので、「どのポリシーで接続するか」を決めるものではありません。たとえば内部サービスを利用者自身が管理するアドレスに固定したい場合、Hostに明示的なマッピングを設定し、必要に応じてRuleでDIRECTを選びます。2つのセクションは役割を分けて考えてください。Hostのマッピングだけではリクエストが直接接続になるとは限らず、DIRECTだけでは正しい内部名前解決が補われません。マッピング先のアドレスが想定するサービスのものかを確認しないと、後続ルールが正確でも誤った接続先につながります。

[Host]
intranet.example.com = 192.0.2.10

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

192.0.2.10は文書用アドレスです。この例は構文の説明に限って使用し、内部サービスにそのまま設定しないでください。実際の値を入力する前に、ご自身のネットワーク管理者またはサービス設定の記録でアドレスとポートを確認します。サービスアドレスがネットワークによって変わる場合、Hostを固定すると、あるネットワークでは接続できても別のネットワークでは失敗することがあります。複数アドレスで負荷分散しているサービスを単一アドレスに固定すると、障害時の切り替えに影響する可能性もあります。異常な名前解決の原因を調べず、長期間使う固定マッピングで置き換えないでください。見知らぬメモから古いサイトアドレスをコピーするのも避けましょう。

マッピングはTLS名やサーバー設定を置き換えない

ドメイン名でHTTPSにアクセスする場合、接続先アドレスと証明書を検証する名前は別の概念です。Hostで接続先アドレスを変更しても、サーバーはそのドメインに適合する証明書と応答を提供する必要があります。マッピング後に証明書エラーが出ても、検証を無視して設定が正しいと判断しないでください。対象サービスがそのドメインをサポートしているか、サーバー側のサイト設定が正しいかを確認します。同じアドレスで複数のサイトを運用している場合があります。アドレスへ接続できることだけでは、そのドメインで必要なコンテンツが返る証明になりません。

Hostの変更後も、キャッシュや接続の再利用がテスト結果に影響します。ファイルを保存して選択中であることを確認してから、新しいリクエストを送信してください。必要に応じて開いているページを閉じてから開き直し、実際の接続先アドレスを比較します。特定のアプリだけ挙動が変わらない場合は、独自の名前解決を使っているか、アドレスに直接アクセスしている可能性も考慮してください。他のアプリにマッピングが適用されたからといって、デバイス上のすべてのリクエストが同じ経路になるとは限りません。固定マッピングごとに用途と出所を記録し、サービスの移行後に確認すると、「ルールを変更していないのに突然使えない」という状況を減らせます。

URL Rewriteはアドレスのパターンに基づいてリクエストを処理する

URL Rewriteは認識可能なリクエストアドレスを書き換える機能です。サーバーリストの更新でも、ドメイン振り分けの別名でもありません。一般的には、照合式、置換先のURL、動作を指定します。次の例ではリダイレクトを使い、例示サイトのHTTPアドレスをHTTPSへ転送し、キャプチャグループで元のパスを保持します。正規表現のピリオドはエスケープし、先頭アンカーで照合位置を制限します。そうしないと、一見単純な式でも無関係なアドレスに一致する可能性があります。実際に使う前に、一致する例と一致しない例をそれぞれ列挙して確認してください。成功する例を1つ試すだけでは不十分です。

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

ここでの$1は、前の括弧でキャプチャした内容を参照します。302は、クライアントが置換先のURLへアクセスするよう指示するステータスコードです。接続先サイトが実際にHTTPSを提供している必要があります。ルールによってサーバーに証明書を追加したり、ページを作成したりすることはできません。リダイレクトで次のリクエストのホスト名が変わると、別のRuleが適用される場合があります。最終的な出口が変わった場合は、接続先が変わったか確認してください。置換後のアドレスが同じ式に再び一致したり、サーバーが旧アドレスへ戻したりするとループすることもあります。その場合はすぐにルールを無効にし、リダイレクト全体を確認してください。

HTTPSリクエストのパスやヘッダーは通常暗号化されており、すべてのURL Rewriteで直接処理できるとは限りません。復号を伴う場合は、証明書の信頼、対象ホストの範囲、アプリとの互換性にも注意が必要です。このページでは、ルールによる振り分けのために復号を有効にする必要はありません。また、単純な条件を試す目的で処理範囲を広げることも推奨しません。出口の要件をドメインルールで解決できるなら、Ruleを優先して使ってください。Host、Rule、URL Rewriteはそれぞれ別の問題を解決します。組み合わせて使う場合は、名前解決、ポリシー、書き換え後の新しいリクエストを個別に検証してください。リダイレクトが一度成功しただけで、設定全体が正しいと判断しないでください。

07 · よく使うルールの書き方と調整方法

指定したサイトだけをPROXY経由にする

指定した一部のサイトだけをプロキシ経由にし、それ以外を直接接続にする場合は、「明確なドメイン条件＋FINAL,DIRECT」の構成を使えます。確認できる対象を1つ選んで始め、未確認のキーワードを大量に読み込まないでください。以下ではexample.comとそのサブドメインをプロキシの対象にし、内部ホストは別ルールで直接接続にします。実際に使う前に、ご自身が管理する必要のあるドメインに置き換え、現在のプロキシサーバーが利用可能か確認してください。例示ドメインは照合関係を示すもので、アクセスして実サービスをテストするためのものではありません。

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

実際のサイトは、アドレスバーに表示されるドメインだけでなく、別のログインAPI、静的リソース、ファイルサーバーにもリクエストを送ることがあります。ページの文章は表示されるのに画像が読み込まれない場合は、すべての通信をPROXYにするのではなく、読み込めないリソースの実際のリクエストを確認してください。対象に含める必要があると分かった場合にだけ、対応するDOMAINまたはDOMAIN-SUFFIXを追加します。複数のサービスが同じリソースドメインを共有している場合、広すぎるサフィックスは他のサイトにも影響します。その場合は完全なホスト名を使うと、影響範囲を限定しやすくなります。

明確な例外を指定し、それ以外をPROXYにする

内部サービス、ローカルネットワークのアドレス、特定地域のアドレスをDIRECTにし、それ以外をプロキシにする方法もよく使われます。この場合のFINAL,PROXYはフォールバックであり、すべてのリクエストが1行目からPROXYを使うという意味ではありません。既知の例外を先に置き、ドメインとアドレスの条件を用途の具体性に合わせて並べてください。特定のドメインを確実にプロキシ経由にする場合は、アドレスの地域判定でDIRECTに入らないよう、地域ルールより前に置くことができます。重要な通信は、地域分類ではなく明示的なルールで指定してください。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN,intranet.example.org,DIRECT
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,PROXY

この例は内部アドレス範囲の一部を示すもので、あらゆるローカルネットワークの状況を網羅していません。家庭、職場、仮想ネットワークでは、異なるアドレスやデバイス探索の方式を使うことがあります。実際のネットワーク構成に合わせて追加してください。例をそのままコピーしただけで、すべてのローカルサービスが対象になるわけではありません。no-resolveの適用範囲にも注意してください。該当するアドレス条件のために名前解決を行わない設定であり、内部ホスト名をアドレスに変換する機能ではありません。内部名を解決できない場合は、システムDNS、Host、ご自身の内部名前解決設定を確認してください。

対象を正確に指定し、広範な誤ブロックを防ぐ

確認済みのリクエスト対象を拒否する場合は、名前によくある単語を根拠に広くREJECTするのではなく、まずDOMAINを使います。完全なホスト名なら確認や解除がしやすくなります。以下ではtelemetry.example.comだけを拒否し、example.comの他のホストはプロキシ経由のままにします。DOMAIN-KEYWORD,telemetry,REJECTに変更すると、同じ文字列を含む別のドメインにも影響する可能性があります。範囲を広げるかどうかは、実際のリクエスト記録と明確な要件に基づいて判断してください。ルールが「網羅的に見える」という理由だけで範囲を広げないでください。

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

REJECTを検証する際は、対象リクエストが実際に拒否されること、ページの主要機能が動作すること、ログインや送信などの操作に問題がないことを確認します。一つのエンドポイントが計測機能と業務上の応答を兼ねる場合もあり、名前だけでブロック後の影響は分かりません。不具合が発生したら、追加したばかりのルールを無効にし、同じ操作を再度試します。原因を確認してからルールを残すか削除するか決めてください。ブロックを続けるために例外を重ね、設定を理解しにくい修正の寄せ集めにしないでください。

用途を記録し、ルール例をメンテナンスに活用する

3つの例は異なる要件に応じた出発点です。それぞれにFINALがあるため、そのまま連結しないでください。統合する場合は、まず全体のフォールバックを決め、必要なドメイン例外、内部アドレス、拒否ルールを選んでから、順序を確認します。追加した条件ごとに「内部APIは直接接続」や「指定サイトはプロキシ経由」のように用途を記録し、サブスクリプションの認証情報は記載しないでください。要件がなくなった場合、用途を手掛かりに対応するルールを削除すれば、何百行もの中から出所を推測する必要がありません。

利用中のサブスクリプションを変更したあとにPROXY経由だけが失敗する場合は、ドメイン条件を書き換えるのではなく、まずサーバーの選択と接続情報を確認してください。ルールが指定するポリシーは同じでも、そのポリシーの背後にある出口が変わっている可能性があります。複数のサブスクリプションをまとめる方法や重複ノードへの対処は、複数サブスクリプションの管理方法をご覧ください。設定の役割を明確に保ちましょう。サーバー情報はサーバーの管理、接続先の照合はRule、名前解決はGeneralまたはHostで扱うと、ネットワーク変更後に調整箇所をすばやく特定できます。

08 · 検証手順、トラブル対処、メンテナンス

テスト対象と確認記録を固定する

設定の検証では、「ページを開けるか」だけでなく、想定した経路で開けるかも確認します。PROXYにすべきドメイン、DIRECTにすべきドメイン、FINALの確認に使う未登録ドメインをそれぞれ1つ選びます。REJECTを使う場合は、明示的に拒否する対象も追加します。各テストで想定するポリシーを記録し、実際の接続先、一致したルール、最終出口を確認してください。テスト対象を固定すると前後の比較に意味が生まれます。毎回異なるサイトを試すと、サーバー側の変動を設定変更の影響と誤認することがあります。

1. ご自身が利用するサーバー情報をインポートし、Homeで使用可能な出口を選択します。
2. Configでテスト用コピーを選び、Global RoutingをConfigに設定します。
3. 接続を確立し、新しいリクエストで固定したテスト対象にアクセスします。
4. アプリで利用できるリクエスト記録または診断画面で、一致条件とポリシーを確認します。
5. 一度に変更するのは1か所だけにし、同じテストを繰り返します。問題がなければ、元に戻せるコピーを保存します。

Connectivity Testは一部の接続条件を確認するのに役立ちますが、実際のサービスを使ったテストの代わりにはなりません。サーバーへの接続に成功しても、接続先サイトの認証、リソースの読み込み、リクエスト方式が正常とは限りません。同様に、Webページが開けなくても、サーバー全体が利用できないとは限りません。問題が起きたら、名前解決、接続、ルール照合、アプリケーション層の応答のどこで失敗しているかを特定してから、適切なツールを選びます。十分な記録がない場合は、大量の設定を何度も切り替えるより、再現に必要な最小限の設定例を残すほうが原因を絞り込めます。

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

「ルールに一致しない」場合は、サフィックスを広げる前に実際のホスト名を確認してください。ページが別のドメインにリダイレクトする場合や、アプリがAPI用ホストにアクセスする場合、アドレスを直接使う場合もあります。条件が正しければ、ファイルが選択されているか、保存されているか、Global RoutingがProxyやDirectのままになっていないかを確認します。その後、上の行を確認し、範囲の広いキーワード、アドレスルール、途中に置かれたFINALがないかを調べます。この順で確認すれば、状態の誤りをルールの追加で対処することを避けられます。

「ルールには正しく一致するのにアクセスできない」場合は、接続経路を確認します。ご自身が利用するサービスのアドレス、ポート、認証情報、プロトコル固有の接続パラメーターを確認してください。認証エラーを広範なRuleで隠さないでください。TrojanなどTLSを使う接続では、サービス提供元が指定した名前とパラメーターも確認します。設定値はご自身のサービス情報に基づく必要があり、ルールの例から推測しないでください。関連項目はTrojanのパスワード、SNI、TLSの要点をご覧ください。サーバーリストが空の場合は、まずサブスクリプションを更新してください。ルールで不足しているサーバー情報を補うことはできません。

設定の復元、更新、トラブル情報の整理

変更がうまくいくたびに、用途が明確な安定版のコピーを保存し、条件と変更理由を記録します。リモート設定やサブスクリプションを更新した後は、アプリ全体に問題が出るのを待たず、既存のテスト対象を確認してください。新しい内容で問題が起きた場合は、検証済みのコピーに戻して基準の状態を復元し、その後に項目ごとに比較します。古いファイルと新しいファイルを混ぜて修正を続けないでください。使用しなくなったHostマッピング、不要な例外、重複ルールは、依存している設定がないことを確かめてから整理します。

トラブル情報をまとめるときは、必要な構成だけ残します。現在のモード、関連するRuleの前後数行、テスト用ドメイン、想定ポリシー、実際の結果を記録してください。サブスクリプションURL全体、サーバーのパスワード、アクセストークン、個人情報を含むリクエストアドレスは公開しないでください。スクリーンショットを共有する前に、これらの情報が写っていないか確認します。原因を判断できない場合は、まず最小限のルールを使ったコピーで再テストし、FAQとサブスクリプション更新失敗時の確認手順を参照してください。サブスクリプションの解析エラーとルールによる振り分けの問題を混同しないようにしましょう。