公式マニュアル · ルール解説

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

まず設定が適用されているかを確認し、次にルールが一致した理由を調べます。設定セクション、照合対象、実行ポリシー、診断記録を順に確認し、現在の設定を段階的に検証します。

設定ファイルの構成と適用範囲

まず現在のファイルを確認し、各セクションの役割を把握します。

Configで使用中のファイルを確認する

設定ファイルはサーバー一覧を別の形式で記述したものではありません。サーバー情報には接続先のアドレス、ポート、プロトコル、認証情報などを記述します。一方、設定ファイルではリクエストの分類方法、ポリシーの選択、解析や処理の一部を指定します。Configを開いたら、ファイルが読み込まれているだけで有効だと判断せず、現在選択されているファイルを確認してください。ファイルの存在、内容の保存、選択状態、Global RoutingがConfigになっていることは、それぞれ個別に確認する必要があります。編集したルールが接続に反映されない場合は、同じルールを追加する前にこの4点を確認すると効率的です。

編集を始める前に、現在使えるファイルのコピーを保存し、使用中のサーバーとGlobal Routingの状態を記録しておきましょう。初めて確認する場合は、各セクションの見出しを読んでから項目を確認してください。先頭から一行ずつ読んで、設定全体を推測する必要はありません。角括弧で囲まれた見出しが設定セクションを示し、その後の内容は所属するセクションに応じて解釈されます。同じ文字列でも、別のセクションでは意味が異なる場合があります。例にあるドメインは構文を説明するためのもので、実際に接続できるサービスを示すものではありません。

よく使われる4つのセクションの役割

セクション主な役割確認ポイント
[General]基本ネットワークと名前解決に関する設定現在のネットワーク環境に適した項目か
[Rule]リクエストの分類とポリシーの選択ルールの対象、順序、最終ポリシー
[Host]指定ホスト名のアドレスをマッピングアドレスが正しいか、名前解決を上書きする必要があるか
[URL Rewrite]認識可能なURLに書き換え処理を適用照合式、処理内容、可視性の範囲

Generalの設定は基本的な処理環境に適用されます。通常の振り分けルールをここに記述するものではありません。Ruleの各行は照合条件と結果を示します。たとえば、ドメインが一致した場合にDIRECTを選択します。Hostが変更するのは特定のホスト名に対する名前解決のマッピングであり、そのホストのプロキシポリシーを指定するものではありません。URL Rewriteは確認できるリクエストURLを書き換えますが、通常の接続経路をRuleのように判断するものではありません。この4つを混同すると、「ドメインのアドレスを設定したのに、なぜプロキシ経由なのか」といった誤解につながります。アドレスの決定とポリシーの決定は別々の判断です。

[General]
dns-server = system

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

この最小構成の例では、システムDNSを使用し、example.comとそのサブドメインにはPROXY、ローカルネットワークの1つのアドレス範囲にはDIRECTを指定し、それ以外の接続をFINALで処理します。利用可能なサーバー情報や完全なネットワーク要件は含まれていません。セクションの区切りとルールの構造を確認するための例です。目次を埋めるためだけに空のHostやURL Rewriteセクションを追加する必要はありません。該当する要件がなければ設定を簡潔に保つことで、変更の影響を把握しやすくなります。

編集・保存・読み込みはそれぞれ別の操作

ファイルから設定を読み込んだら、セクションが揃っているか、改行が保持されているか、カンマが半角かを確認します。リッチテキストからコピーした内容には、日本語の句読点、見えない空白、折りたたまれた改行が混ざることがあります。見た目が正しくても解析結果が異なる場合があります。保存後に編集画面をもう一度開き、実際に保存されたテキストが意図どおりか確認してください。そのうえでConfigに戻り、対象ファイルが選択されていることを確認します。リモートソースの設定を更新した場合は、手動変更が保持されるかも個別に検証してください。一度保存に成功しても、以後の更新で自動的に統合されるとは限りません。

複雑な構成のファイルを扱う場合は、まず説明可能な基準となる設定を作り、必要な項目だけを順に移してください。内容を追加するたびにテストし、高度な項目を一度にすべてコピーする必要はありません。ファイル名は識別の手がかりにはなりますが、現在のデバイスに適した内容である証明にはなりません。「直接接続」と書かれたコメントも、実際のポリシーより優先されるわけではありません。保存後のテキスト、現在のモード、接続記録を照らし合わせて結果を確認します。この方法は以降の各章でも共通です。

Global Routingと実行ポリシー

Global Routingはルーティングの方式を決め、ポリシーはルール一致後の処理を決めます。

Config、Proxy、Directの確認ポイント

Global RoutingのConfig、Proxy、Directはルーティング方式の選択肢であり、個別ルールの別名ではありません。Configは現在の設定に従って接続を処理する方式で、Ruleセクションを検証する際にまず確認する項目です。Proxyはプロキシ経路を一時的に確認するとき、Directはローカルネットワーク経由の接続と比較するときに使えます。ただし、すべてのシステム接続が同じように処理されることを示すものではありません。基本的なバイパス設定、システムが維持する接続、実際のネットワーク環境も確認範囲に影響するため、検証中のリクエストに絞って判断してください。

方式主な用途トラブルシューティング時の注意点
設定：Config現在の設定によるルール振り分けを検証有効なファイルと照合記録の両方を確認
プロキシ：Proxyプロキシ経路での接続状況を比較元のルールが正しく一致した証明にはならない
直接接続：Directローカルネットワーク経由の接続状況を比較プロキシサーバーの設定が正しい証明にはならない

たとえば、あるドメインがProxyでは接続できるのにConfigでは失敗する場合、調査対象を設定上の経路、名前解決の違い、ポリシーの選択に絞れます。ただし、すべてのドメインルールに問題があるとは限りません。Configでその接続に一致したルールと、最終的にどのポリシーが選ばれたかを確認してください。反対に、Directでは接続できて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,DIRECT

この3つのドメインはそれぞれ異なるポリシーを示す例であり、実際の設定にそのまま使えるものではありません。DIRECTをPROXYに変えても、接続経路の選択が変わるだけで、接続先のアドレス、証明書、認証情報が自動的に修正されるわけではありません。接続失敗時にREJECTへ変更するのも修復ではなく、接続を明示的に終了する操作です。設定を管理する際は、コメントに英単語の意味だけでなく、なぜそのポリシーが必要なのかを記録してください。ネットワーク環境が変わったときに、どのルールを見直すべきか判断しやすくなります。

ポリシー名、選択対象、失敗時の切り替え

ファイルで独自のポリシー名を使う場合は、現在の設定にその名前の定義があることを確認してください。大文字・小文字や空白も実際の設定と一致させます。参照行だけをコピーして、参照先のポリシーを忘れないようにしてください。選択や接続テストを含むポリシーでは、ルールの一致は分類の第1段階にすぎず、最終的な接続結果は選択された対象の状態にも左右されます。記録に想定したポリシー名が表示されても、実際の接続先を引き続き確認してください。ルールが正しくてもサーバーが利用できない状況はあり得るため、両者を分けて対処します。

「前のルールに一致しなかった」場合と「一致後に接続が失敗した」場合も区別してください。前者は後続のルールまたはFINALで処理されます。後者の場合、接続に失敗したからといって同じリクエストがRuleに戻り、接続できる次のルールを探すとは限りません。再試行やポリシー内の切り替えが行われるかどうかは、該当する設定や機能によって異なります。Ruleの並び順を予備サーバーの一覧として扱わないでください。この違いを理解すると、「次のルールに使える接続先があるのに、なぜ試さないのか」という疑問を解決しやすくなります。

モードやポリシーを変更したら、新しいテスト接続を作成し、変更前後のモード、一致した行、接続先を記録してください。接続スイッチの表示だけで成功と判断したり、モード、サーバー、DNSを一度に変更したりしないでください。ほかの条件を変えずに確認すれば、変化の原因を特定しやすくなります。ルールを学ぶときは、まずConfigで少数の明確なルールを使って再現可能な結果を確認し、その後、日常の設定に広げましょう。

DOMAIN系ドメインルール

完全一致、ドメインサフィックス、文字列の部分一致では、対象範囲がそれぞれ異なります。

DOMAIN：完全なドメイン名に一致

DOMAINはドメイン名全体に一致させるルールです。単一のサービス入口に明確な例外を設定するときに適しています。DOMAIN,api.example.com,PROXYはapi.example.comを対象とし、example.com配下のすべてのホストを対象とするものではありません。ドメイン欄にはプロトコル、パス、ポートを含めず、ブラウザーのアドレス欄にあるURL全体を貼り付けないでください。同一ホスト内のパスごとに分ける必要がある場合、通常のDOMAINルールではその粒度で照合できません。要件がドメインのルーティングか、リクエストURLの処理かを先に確認してください。

完全一致ルールは影響範囲を限定しやすく、ログとの対応も確認しやすい点が利点です。APIの例外を追加する場合は、ページのURLだけでなく、実際のリクエスト先ホストを確認してください。ページからログイン用、静的リソース用、API用など複数のドメインへリクエストが送信されることがあります。メインページのルールだけを変更しても、ほかのリクエストには元のポリシーが適用される場合があります。ページの一部だけ動作しないときは、失敗した接続先を個別に確認してください。ページ全体を単一ドメインへの1回のリクエストとして扱わないようにしましょう。

DOMAIN-SUFFIX：ドメイン階層に基づく一致

[Rule]
# 具体的な例外は広いサフィックスルールより前に置く
DOMAIN,api.example.com,PROXY
DOMAIN-SUFFIX,example.com,DIRECT
FINAL,PROXY

DOMAIN-SUFFIX,example.com,DIRECTはexample.comとそのサブドメインを対象にします。任意の位置にある文字列を検索するのではなく、ドメインサフィックスの境界に基づいて照合します。そのため、別の名前にexample.comという文字列が含まれていても、必ず一致するとは限りません。通常、サフィックスにアスタリスクや先頭のプロトコルは付けません。この広いルールを具体的な例外より後に置けば、api.example.comは先頭の行に一致し、それ以外の同じサフィックスに属する対象がDIRECTになります。

上記2行の順序を逆にすると、広いルールが先にapi.example.comを処理します。後の具体的なルールは、詳細に書かれていても自動的に優先されません。設定を確認するときは、ルールの条件だけでなく、その前に対象範囲の広いルールがないかも見てください。サフィックスルールは同じドメイン体系に共通のポリシーを適用するのに便利ですが、その体系に必要なすべてのサービスが含まれるとは限りません。外部リソースやリダイレクト先は別途確認が必要です。

DOMAIN-KEYWORD：広範な部分一致に注意

DOMAIN-KEYWORDはドメイン内の指定文字列に一致するため、異なるドメイン体系にまたがる共通の文字列を対象にする場合に適しています。ブランドやサービスの意味を認識したり、ドメインの所有者を検証したりするものではありません。たとえばexampleというキーワードは、その文字列を含む複数のホストに一致する可能性があり、明確なサフィックスより広い範囲を対象とすることがあります。example.comとそのサブドメインだけが対象なら、まずDOMAIN-SUFFIXを検討してください。広いキーワードを使う前に、意図せず一致する可能性のある対象を洗い出し、その範囲を許容できるか判断しましょう。

種類値の例使い分け
DOMAINapi.example.com単一の完全なホストにのみポリシーを適用
DOMAIN-SUFFIXexample.comルートドメインとそのサブドメインを対象にする
DOMAIN-KEYWORDexample指定文字列を含むドメインに意図的に一致させる

この3種類のルールに、「具体的なタイプが広いタイプより優先される」という固定の順序はありません。Ruleセクション内の並び順に従って処理されます。そのため、対象範囲の小さい例外を前に置き、共通のサフィックスを続け、必要な場合に限ってキーワードを使うと整理しやすくなります。これは設定の可読性を高めるための方法であり、解析器が強制する形式ではありません。キーワードルールがすでに複数のサフィックスを対象にしている場合、同じポリシーのサフィックス行を追加しても、管理の手間が増えるだけかもしれません。

ドメインが見えない場合は、無理に原因を決めつけない

アプリがIPアドレスへ直接接続する場合、独自の名前解決を使う場合、または記録にドメイン情報がない場合、DOMAIN系ルールが完全なホスト名を取得できるとは限りません。まず記録で確認できる接続先を調べ、IPルールが必要か判断してください。ブラウザーにドメインが表示されているからといって、すべての通信にも同じ情報があるとは限りません。ドメインルールが照合に使えるかどうかは、処理時に接続から何の情報を取得できるかによって決まり、ユーザーが別の画面で何を見たかには左右されません。

ドメインリストを整理する際は、各ルールグループの目的と例外を記録し、前のルールに完全に含まれる重複項目を削除すると管理しやすくなります。テストでは対象ドメイン、サブドメイン1つ、誤って一致してはいけない類似ドメインを確認してください。必要な接続がルールに一致したことと、対象範囲が広がりすぎていないことの両方を検証できます。1つの対象で成功しただけでは、ルールの範囲が正しいとは判断できません。

IP、GEOIP、USER-AGENT

ルールによって参照する情報は異なります。まず接続から実際に取得できる情報を確認してください。

IP-CIDRとIP-CIDR6のネットワーク範囲

IP-CIDRはネットワークアドレスとプレフィックス長でIPv4アドレスの範囲を表し、IP-CIDR6はIPv6に使用します。プレフィックス長が大きいほど範囲は狭くなります。単一のIPv4アドレスは/32、単一のIPv6アドレスは/128で指定できます。ネットワーク範囲を追加する前に、その範囲全体が処理対象として本当に必要かを確認してください。1つのアドレスへの接続に失敗したからといって、広いアドレスブロック全体に同じポリシーを適用しないでください。接続先が共有インフラを使用している場合、広すぎる範囲が無関係なサービスにも影響することがあります。

[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,PROXY

先頭の2行はよく使われるプライベートIPv4範囲、3行目はIPv6のユニークローカルアドレス範囲の例です。これだけですべてのローカルネットワークを網羅できるわけではありません。実際のLANでは別のプライベートアドレス範囲や異なるアドレス設計が使われている場合があるため、端末のネットワーク環境を確認してください。IPv6はIPv4ルールによって自動的に処理されません。IPv4の範囲を指定しても、同じサービスのIPv6接続に同じポリシーが適用されるとは限りません。同じドメインへの接続結果が変わる場合は、記録にあるアドレス種別も確認しましょう。

no-resolveは追加の名前解決を抑制し、接続先アドレスを作り出すものではない

IPルールの末尾に付けるno-resolveは、そのルールとの照合のためにドメインの名前解決を追加で開始しないようにします。接続先アドレスがすでにわかっている場合や、複数のIPルールを確認する際に不要な名前解決を避けたい場合に使用します。DNSを完全に無効にしたり、後続のアドレス判定をすべて省略したりするものではありません。現在の接続にドメイン名しかなく、使用可能な接続先アドレスがない場合、no-resolve付きのIPルールでは一致を判定できないことがあります。その場合は最終的に別のルールでポリシーが決まります。

そのため、ローカルドメインにDIRECTを指定する場合、プライベートネットワーク範囲とno-resolveを追加するだけでは不十分なことがあります。ホスト名がローカルDNSでのみ有効なら、名前解決の方法、結果を取得できるか、前にあるドメインルールがすでにリクエストを処理しているかも確認してください。no-resolveを汎用的な高速化スイッチとして扱わないでください。これは照合中に追加の名前解決を行うかどうかを変える設定です。すべてのルールに機械的に追加するのではなく、問い合わせを制御する必要に応じて使いましょう。

GEOIPはアドレスの分類であり、サービスの帰属を判定するものではない

GEOIP,CN,DIRECTは、アドレスデータベースで宛先IPが分類された結果に基づいてDIRECTを適用します。Webサイトの表示言語やドメインサフィックスを判定するものではなく、運営主体やコンテンツの保管場所を証明するものでもありません。データベース、実際の宛先アドレス、名前解決の結果が一致に影響します。1つのドメインが複数のインフラに対応することがあり、名前解決の変化でアドレスの分類が変わる場合もあります。安定したポリシーが必要なサービスには、まず明確なドメインルールで意図を指定し、GEOIPはより広い後段の分類として使う方法が適しています。

GEOIPを調べるときは、まず今回の接続で実際に使われたアドレスを記録し、前にあるドメインルールで照合が終了していないか確認してください。宛先アドレスが想定した範囲に属していても、GEOIPの行まで処理が到達したとは限りません。逆に、GEOIPに一致しなかったからといって、すぐにデータベースの誤りと判断することもできません。接続がその判定経路に入っていない可能性もあります。地理的な分類を厳密なセキュリティ境界として使わず、認証、アクセス制御、サーバー証明書の検証の代わりにしないでください。

USER-AGENTで照合できる範囲

[Rule]
# リクエスト情報を照合に利用できる場合のみ、この条件を評価
USER-AGENT,ExampleApp*,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT

USER-AGENTはリクエストから取得できるUser-Agent情報に一致させます。例のアスタリスクはパターン内のワイルドカード部分を示します。端末にインストールされたアプリ名からプロセスを識別するものではなく、アプリのすべての接続を識別できる保証もありません。暗号化されたリクエストや該当フィールドを含まない接続では、このルールに使える情報がない場合があります。トラブルシューティングでは、「アプリが接続を開始したこと」と「その接続に照合可能なUser-Agent情報があること」を分けて考えてください。アプリ名だけでルールに一致するはずだと判断しないようにしましょう。

複数種類の条件を使う設定では、「明確なドメイン例外、必要なリクエスト情報の条件、特定のネットワーク範囲、より広いアドレス分類、FINAL」の順に確認すると整理しやすくなります。ただし、最終的な順序は要件によって決まります。条件を追加するたびに、どの情報を前提とするか、情報を取得できない場合にどのルールで処理するかを説明できるようにしてください。ルール数を数えるより、この記録の方が管理に役立ち、異なるルールを同じ種類の重複設定と誤解することも防げます。

照合順序、上書き、FINAL

上から順に照合し、一致した時点で終了します。詳細なルールが自動的に優先されるわけではありません。

ルール名ではなく、順に照合して判断

Ruleセクションを読む基本は、具体的なリクエストを当てはめ、先頭の行から順に確認することです。一致する条件が見つかったら、その行のポリシーが適用され、後続の通常ルールで再分類されることはありません。そのため、先にある広い条件が後続の具体的な条件を覆う場合があります。「例外を優先する」とは隠れた仕組みではなく、管理者が例外を共通ルールより前に置いた結果です。設定を理解するには、順序を調整する前に対象範囲の重なりを整理してください。

[Rule]
# まず単一ホストの例外を残す
DOMAIN,api.example.com,PROXY

# 次にドメイン体系全体を処理
DOMAIN-SUFFIX,example.com,DIRECT

# 既知のローカルネットワークの対象
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve

# より広いアドレス分類
GEOIP,CN,DIRECT

# それ以外の接続に適用する最終ポリシー
FINAL,PROXY

api.example.comは先頭の行に一致するため、サフィックス行でポリシーが変わることはありません。static.example.comは先頭の行には一致せず、サフィックス行によってDIRECTになります。既知のローカルネットワーク内のIPアドレスは、先行する2つのドメイン条件に該当しない場合、ネットワーク範囲の条件で処理されます。どの先行条件にも一致しなかった接続にのみFINALが適用されます。いずれも条件の判定であり、複数の接続経路を順に試すものではありません。ポリシー適用後に起きるネットワーク接続の失敗は、次の段階で扱います。

FINALは残りの接続を処理する

FINALは「最も重要なドメインルール」ではなく、先行条件に分類されなかった接続に適用する最終ポリシーです。FINAL,PROXYは既定でプロキシ経由にする設計、FINAL,DIRECTは既定で直接接続する設計を表します。どちらが適切かは前段の例外と実際の要件によって異なります。FINALを変更すると、単一の対象ではなく、未分類の接続全体に影響するため、具体的なドメインルールの追加より影響範囲が大きくなる場合があります。

FINALはルール一覧の末尾に置き、その後に有効にしたい通常ルールを追加しないでください。ファイルの末尾に行を追加しただけでは、前にFINALがあることに気づかず、新しい行が一度も実行されない場合があります。ファイルを統合するときは、重複するFINALがないか特に確認してください。2つの完全なRuleセクションをそのまま連結しても、後半が元どおり動作するとは限りません。先に既定のポリシーを1つ決め、両方のファイルで有効な例外をそのFINALより前に整理します。

重複、競合、到達不能なルール

同じ条件と同じポリシーのルールが重複しても、通常は確認の手間が増えるだけです。同じ条件に異なるポリシーが指定されている場合は、先にある行が適用されます。より見つけにくい競合は対象範囲の包含によって起こります。たとえば、前のDOMAIN-SUFFIXが後のDOMAINを含む場合や、広いネットワーク範囲が狭い範囲を含む場合です。完全に同じ文字列だけでなく、対象範囲が重なっていないかも確認してください。狭い範囲の例外が必要なら、条件を前方に移し、後続のルールとの関係をコメントに記録します。

現象よくある原因確認方法
具体的なルールに一致しない前に対象範囲の広いルールがある同じ対象を先頭から順に確認する
追加したルールが反映されないルールがFINALより後にある有効な例外をFINALより前に整理する
1行の変更で多くの対象が変わる広い条件または既定ポリシーを変更した代表的な対象を複数選んで再テストする

設定が外部ルールセットを参照している場合、参照行も現在の順序における判定ポイントとして扱ってください。外部コンテンツの更新で照合範囲が広がったり狭まったりし、後続のローカルルールに以前のリクエストが届かなくなる場合があります。更新後に結果が変わったら、ローカルの参照位置と外部コンテンツの変更を両方確認してください。ローカルファイルだけを比較すると、照合結果を変えた本当の要因を見落とすことがあります。

再現可能なテスト項目を用意する

順序を変更する前に、少なくとも4種類の対象を選びます。具体的な例外、共通サフィックス、既知のローカルアドレス、FINALで処理される対象です。それぞれで想定する一致行とポリシーを記録し、新しい接続を作成して順に検証します。大量の数値を記録する必要はありません。同じモードで同じ対象を確認したとき、結果を説明できることが重要です。新しいルールで1つの対象が直っても、正常だった別の対象に影響が出た場合は、ファイル末尾に修正を追加し続けず、対象範囲の重なりを確認してください。

ルール順序を決めた理由は、特に広いルールより前に置く必要がある例外について、隣接するコメントに残してください。ファイルの並べ替えや統合をするときに、「種類ごとに整理した結果、動作が変わった」という事態を防げます。ルール一覧の目的は見た目を整えることではありません。想定したリクエストが正しい位置で照合を終え、未分類の対象にも明確な処理先があることが大切です。

DNS、Host、URL Rewrite

名前解決、ルーティング、リクエストの書き換えは関連しますが、互いの代わりにはなりません。

ドメインの名前解決と接続経路を分けて考える

DNSはホスト名をアドレスに変換し、Ruleは接続に適用するポリシーを決めます。両者は互いの観察結果に影響することがありますが、同じ設定ではありません。ドメインを何らかの方法で名前解決した後、ルールによって直接接続かプロキシ接続かが決まります。接続方法によっては、異なる場所で名前解決が行われることもあります。トラブルシューティングでは、「どのアドレスを取得したか」と「どのポリシーで接続したか」を分けて記録してください。PROXYが指定されているからといって名前解決が必ずリモート側で行われると推測したり、DIRECTだからすべての名前解決が同じローカル経路を使うと決めつけたりしないようにしましょう。

[General]
dns-server = system

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

dns-server = systemは、システムが提供するDNS設定を使うことを示す簡潔な基本例であり、すべてのネットワーク環境に適した固定設定ではありません。システムDNSで内部ホストを解決できない場合、そのホストにDIRECTを指定しても正しいアドレスが生成されるわけではありません。特定のネットワークでのみ名前解決できるか確認し、端末がその環境に接続されているかを調べてください。逆に、ドメインを正常に解決できても、接続先のポートに到達できるとは限りません。名前解決の成功は接続前の処理の一部にすぎません。

Hostマッピングの用途と管理上の注意

[Host]
# ドキュメント用のサンプルアドレス。接続可能な実ホストではありません
lab.example.com = 192.0.2.10

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

Hostセクションでは、指定したホスト名に明示的なアドレスを割り当てられます。例にある192.0.2.10はドキュメント用のアドレスで、項目の構造を示すものです。このマッピングにDIRECTの意味はありません。実際のポリシーはRuleで指定します。実際のアドレスを設定するときは、想定した接続先のものかを確認し、証明書、サーバーのホスト名判定、サービスの更新も考慮してください。古いアドレスにドメインを固定すると、名前解決が安定したように見えても、サービス移行後に無効な接続先へアクセスし続けることがあります。

一時的な診断では、マッピングを使って名前解決の要因を切り分ける方法があります。検証後は設定を残すか判断し、その理由を記録してください。動的アドレスや負荷分散を使用する接続先では、静的マッピングを長期間使うことで本来の振り分けが損なわれる場合があります。一度の名前解決結果をコピーしただけで、恒久的に正しいアドレスだと判断しないでください。証明書の名前が一致しない場合も、検証を無効にして問題を隠すのではなく、接続先アドレス、ホスト名、サーバー証明書が本来一致しているか確認します。

URL Rewriteが処理するのは確認可能なリクエストURL

[URL Rewrite]
^https://example\.com/old$ https://example.com/new 302

この例では、正規表現で完全なURLを指定し、302リダイレクトで別のURLへ転送します。先頭の^と末尾の$は一致範囲を限定し、ドメイン内のピリオドはバックスラッシュでエスケープして任意の文字として扱われないようにします。リクエストにクエリパラメーターや末尾のスラッシュが含まれると、この完全な式には一致しない場合があります。これは書き換えの失敗ではなく、条件がその形式を対象にしていないためです。正規表現を作る前に、対象にしたいURLの形式を列挙し、境界をどこまで広げるか決めてください。

リダイレクトは、元の接続にPROXYまたはDIRECTを選択することと同じではありません。ブラウザーがリダイレクトを受け取ると、新しいリクエストを送信することがあり、その接続先は改めてルーティング判定されます。書き換え後にループする場合は、新しいURLが同じルールまたは別の式に再び一致していないか確認してください。テストには、結果を確認しやすい狭い範囲のルールを使います。最初からドメイン体系全体に広い式を適用すると、どのリダイレクトでリクエストが変わったのかを特定しにくくなります。

暗号化されたリクエストの可視性を考慮する

HTTPSの完全な経路情報は、通常のネットワークルーティング処理から直接見えない場合があります。設定にURL Rewriteを記述しても、すべての暗号化リクエストで完全なURLが自動的に照合可能になるわけではありません。処理できるかどうかは、リクエストの可視性や関連設定によって異なります。通常のドメイン振り分けで、パスを見るために処理範囲を広げる必要はありません。このページの書き換え例はセクションの構文を説明するものであり、ルールを学ぶために証明書関連の機能を追加で有効にする必要はありません。そうした設定を、あらゆる接続問題の最初の解決策として扱わないでください。

これらのセクションを管理するときは、キャッシュと既存の接続も考慮してください。システム、アプリ、ブラウザーに名前解決結果、リダイレクト結果、接続状態が保持されることがあります。変更後は新しいリクエストで再テストし、キャッシュの影響と設定が反映されていない状態を区別してください。アプリによって結果が異なる場合は、各アプリが実際にリクエストしたドメイン、アドレス、プロトコルを比較します。すぐにセクションの優先順位の違いだと判断しないでください。最終的には、今回の接続で確認できた記録を使って結果を説明します。

よくあるルールの組み合わせと設定の管理

要件を狭い範囲の条件として表し、元に戻せる方法で少しずつ統合します。

まず既定の動作を一文で定義する

設定を書く前に、特別に指定していない接続をどう処理するか、どの接続先を既定の動作から変更するかを決めます。前者はFINAL、後者は例外の一覧に対応します。既定の動作を一文で説明できない場合、新しいルールが本当に必要か判断しにくくなります。最初に大量のドメインを集めてから、設定全体の目的を推測しないでください。ルールが増えるほど対象範囲の関係は複雑になります。複数のファイルから集めた設定でも、管理の手間が自動的に減るわけではありません。

[Rule]
# 既定はプロキシ、明確な対象だけ直接接続
DOMAIN,printer.example.com,DIRECT
DOMAIN-SUFFIX,home.example.com,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
FINAL,PROXY

この例は、既定でプロキシを使い、明示した対象には直接接続する構成です。printer.example.comとhome.example.comはサンプル名です。ユーザー自身の環境に合わせて判断する必要があり、ローカルサービスを提供するものではありません。既定では直接接続し、一部のドメインだけプロキシを使う要件なら、少数のPROXY条件を作り、FINALをDIRECTに変更します。既定の設計が異なる2つのファイルをそのまま重ねると、一方の例外が他方で重複や競合になる場合があります。

例外、共通ルール、拒否する対象

[Rule]
# 単一ホストを共通サフィックスより前に配置
DOMAIN,api.example.com,PROXY
DOMAIN,blocked.example.com,REJECT
DOMAIN-SUFFIX,example.com,DIRECT
FINAL,PROXY

この組み合わせには、プロキシを使う例外、接続を拒否する例外、サフィックスに共通のポリシーが含まれます。2つの具体的なホストをサフィックスより前に置くことで、それぞれ異なる処理を適用できます。REJECTは、明確に接続を停止したい対象に使用してください。接続が遅いという理由だけで追加するのは適切ではありません。拒否ルールを追加した後にページの機能が制限された場合は、DNSを変更し続けるのではなく、必要なAPIを拒否していないか確認します。ルールに正しく一致しても、表現された要件が適切とは限りません。ルーティングと機能の両方を検証してください。

ローカル機器にDIRECTを設定する場合も、一度見つけたアドレスをすべて長期ルールにしないでください。機器のアドレスが固定か、ホスト名が安定しているか、同じローカルネットワークへの接続が必要かを確認します。ルールで接続経路を選ぶことはできますが、現在のネットワークにない機器へ自動的に接続できるようにはなりません。ローカルネットワークの範囲に依存する場合は、Wi-Fiを切り替えた後にアドレス設計を再確認してください。別のネットワークで同じアドレス範囲が異なる意味を持つことがあります。

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

Subscribeで読み込む接続情報とConfigのルール設定は、異なる役割を持ちます。サブスクリプションを更新すると、サーバー名、件数、パラメーターが変わる場合があります。設定が接続先の名前を参照している場合は、参照が引き続き有効か確認してください。サブスクリプションの更新ですべてのローカルポリシー参照が自動修正されるとは限りません。また、ルールファイルのバックアップだけで接続に必要な認証情報をすべて保存できるわけでもありません。移行時は接続情報、現在の設定、モードの状態を個別に確認し、組み合わせて動作することを確かめてください。

ユーザー自身のサブスクリプションURL、認証情報、秘密鍵は機密情報です。問題を共有する場合は、これらを隠し、必要なルール条件、ポリシー名、エラーが起きた段階だけを残してください。サンプルファイルにも実際の認証情報を含めないでください。WireGuardの項目とルーティングルールの役割を確認するには、WireGuard設定パラメーターの説明をご覧ください。プロトコルのパラメーターは接続方法を定め、Ruleはどの対象にその経路を使うかを定めます。この2つの設定は互いに代用できません。

統合・更新・ロールバックの手順

設定を統合するときは、まず現在使えるファイルをバックアップし、追加する実際の要件を列挙します。Ruleの行数だけで比較せず、新しいGeneral設定、Hostの上書き、URL Rewrite、ポリシー参照が追加されていないか確認してください。その後、重複するFINALを削除し、例外を関連する広いルールより前に置き、参照先の名前が存在することを確認します。関連するルールだけを一度に統合し、保存して有効にした後、代表的な対象をテストしてください。問題が起きた場合、どの変更を戻せばよいか明確になります。

リモートソースの設定更新は、更新操作が完了したかを見るだけでなく、変更内容を確認してください。ルールの順序、既定のポリシー、アドレスの上書きを比較し、ローカルに残していた例外が引き続き存在するか特に確認します。長期的に手動で管理する場合は、用途が不明な高度な項目を減らし、重要なルールには理由を記録してください。説明しやすいファイルほど問題発生時に復元しやすくなります。管理のしやすさは、ルールの数ではなく、明確な境界と検証記録によって支えられます。

ネットワークの問題と複雑な設定の問題を区別するため、最後に簡潔な基準設定を保存しておきましょう。この設定もユーザーが利用するサーバーと組み合わせて使うもので、単独で接続サービスを提供するものではありません。日常の設定に問題が起きたら基準設定に切り替え、同じ対象への接続結果を比較します。基準設定で問題がなければ、複雑なルールをグループごとに戻してください。設定全体を何度も読み込み直すより結果を把握しやすく、トラブルシューティング中に有効な設定を失うことも防げます。

ルールの照合確認と段階的なトラブルシューティング

まず処理の流れを確認し、同じ対象で比較します。一度の成功だけで結論を出さないでください。

第1段階：現在の状態を確認し、新しい接続を作成

「ルールが反映されない」ときは、まず端末の現在のネットワーク、Global Routing、選択中の設定、接続先を記録し、対象が明確なリクエストをもう一度送信します。既存の接続には、開始時の状態が保持されている場合があります。ファイルを変更した後、接続が再利用されているページを更新しただけで結論を出さないでください。接続スイッチがオンなのは、クライアントが該当する動作状態に入ったことを示すだけで、想定したルールが接続先に適用された証拠にはなりません。確認すべきなのは今回のリクエストの記録であり、ボタンが正しい位置に見えるかどうかではありません。

次に、テスト対象を1つに絞ります。ブラウザーでページを開くと複数のリソースがリクエストされることがあります。画像が表示されてもAPI接続が成功したとは限らず、APIが失敗してもドメイン体系全体に問題があるとは限りません。識別しやすい失敗ホストを1つ選び、ドメインまたはIP、一致したルール、ポリシー、エラーの内容を記録します。現在の画面で確認できない情報は不明と記録し、画面の表示だけから存在しない照合記録を推測しないでください。

第2段階：不一致、誤ったポリシー、実行時の失敗を区別

確認できた結果優先して調べることすぐに行わないこと
FINALに一致先行条件の範囲、確認できる情報、ファイルの選択同じドメインの行を繰り返し追加する
誤ったポリシーに一致先行ルールによる上書き、ポリシー参照プロトコルとDNSを同時に変更する
想定したポリシーに一致したが接続に失敗実際の接続先、名前解決、接続先への到達性ルールの構文が必ず間違っていると決めつける
該当する記録がない新しいリクエストか、処理対象に入ったか古い記録から今回の結果を推測する

FINALに一致した場合は、同じ対象を先頭の行から確認します。完全なURLをDOMAINの値にしていないか、ドメイン名がなくIPアドレスだけになっていないか、no-resolveによって想定したアドレス判定が行われていないかを調べてください。誤ったポリシーに一致した場合は、前にある広いルールを探します。正しいポリシーに一致したのに接続できない場合は、分類と接続処理を分けて調べる必要があります。具体的なルールを次々と前に移すのではなく、選択された接続先を確認してください。

第3段階：ローカルネットワークと現在のサーバーを比較

Connectivity Testは、現在利用しているサーバーの接続状況を確認する参考になります。ただし、1回のテストが成功しても、すべての対象、プロトコル、実際のサービスが正常とは限りません。テストの失敗だけでRuleの問題とも判断できません。テストと実際のリクエストでは、接続先や処理経路が異なる場合があります。補助的な証拠として結果を使い、実際のリクエストがどの段階で失敗したかと照らし合わせてください。宛先を解決できないのか、リモートへの接続を確立できないのか、接続後にサービスが異常を返すのかによって、確認すべき項目は異なります。

ConfigとProxyの結果が異なる場合は、同じ接続先を固定して、対象の名前解決結果と照合記録を比較します。Directでも失敗する場合は、ローカルネットワークから対象へ正常に接続できるか確認してください。特にLAN内のホストや内部名は、利用環境に制約されることがあります。接続が完全に失敗するのではなく速度が低下する場合は、ローカルのWi-Fiまたはモバイル通信、転送パラメーター、実際の経路を分けて調べます。接続速度を段階的にトラブルシューティングする方法をご覧ください。原因を特定する代わりに、PROXYの対象範囲を広げ続けないようにしましょう。

第4段階：変更を戻し、代表的な対象を再テスト

直近の変更を一度に1グループだけ戻し、同じ対象で新しい接続を作成して再テストします。広いルールを削除すると正常に戻る場合は、そのルールが何を対象にしていたかを調べてください。同じ種類のルールをすべて恒久的に削除する必要はありません。URL Rewriteを無効にするとリダイレクトが正常になった場合は、サーバーを変更するのではなく、式とリダイレクトループを確認します。簡潔な設定に戻しても同じ問題が続くなら、複雑なルール以外に原因がある可能性があります。ネットワーク、名前解決、現在の接続設定に調査の重点を移してください。

[Rule]
# 単一対象の分類を一時的に検証する例。日常利用の完全な設定ではありません
DOMAIN,api.example.com,PROXY
FINAL,DIRECT

このような簡潔な設定は、既知の対象が想定したポリシーに一致するかを確認するのに役立ちます。実際にテストするドメインに置き換え、元に戻せる設定を残してください。検証が終わったら、日常の設定に戻します。戻し忘れると、ほかの接続にもテスト用ファイルのFINALが適用されます。現在どのファイルを使用しているか数日後に忘れないよう、一時設定にも目的が分かる名前を付けてください。テスト成功後は元のルールをグループごとに戻して再確認し、差を生んだ最小の変更を特定します。

購入、再インストール、購入済みアプリの復元に関する問題は、まず購入済みアプリの復元方法をご覧ください。これらの手順はRuleの照合とは関係ありません。ShadowrocketはApp Storeからのみ入手でき、主な利用端末はiPhoneとiPadです。システム要件と互換性はApp Storeのページをご確認ください。復元後も、ユーザー自身の接続情報と設定を確認する必要があります。購入履歴だけでは、利用環境に関する情報すべてを復元できません。

結論は「このドメインは先行するサフィックスルールに一致したため、具体的な例外に移したところPROXYに変わった」のように、検証可能な事実として記録してください。「設定が直った」とだけ書かないようにしましょう。原因と結果を残しておけば、次に似た症状が起きたとき、同じ問題かどうかをすばやく判断できます。操作の流れを最初から確認する場合はクイックスタートガイドに戻り、特定のルールを調べる場合は、このページの目次から該当する章を開いてください。実際の入力、照合結果、実行結果に基づいて確認しましょう。