公式マニュアルルールガイド

Shadowrocket
ルール・設定ガイド

セクションごとに設定項目を確認し、リクエストごとにルールを調べます。iPad・iPhoneで、すでに利用中のサブスクリプションやサーバー情報を管理する際にお役立てください。

初回接続は、まずクイックスタートガイドに沿ってインポート、許可、動作確認を行ってください。このページでは、その後の設定構成や判定範囲、トラブルシューティングの手がかりを確認できます。例は構文の説明用であり、接続可能なサーバー情報は掲載していません。

設定形式 .conf 画面の入口 Config 判定方式 上から順に

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

Shadowrocketでは、接続情報とルール設定はそれぞれ異なる役割を担います。前者は、利用者がすでに持っているサーバーへの接続方法を指定し、通常はプロトコル、アドレス、ポート、認証情報などを含みます。後者は、各リクエストにどのポリシーを適用するかを指定します。Subscribeをインポートしてもルールファイルが選択済みとは限らず、.confをインポートしてもサーバーが追加されるわけではありません。設定を管理する前に、HomeのSERVER一覧とConfigで現在使用中のファイルをそれぞれ確認し、別々の項目として扱ってください。

まず4つのセクションを確認

設定ファイルは角括弧で囲まれたセクション名ごとに適用範囲が分かれています。[General]には全般的なパラメーター、[Rule]には順序のある判定ルール、[Host]にはホスト名のマッピング、[URL Rewrite]にはURL書き換え式を記述します。セクション名は単なる見出しではなく、後続の内容をパーサーがどう扱うかを示す目印です。同じ行でも置くセクションによって解釈が変わったり、無効な設定になったりするため、記述をコピーする際はセクションも確認してください。

[General]
bypass-system = true

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

[Host]
example.com = 192.0.2.10

[URL Rewrite]
^http://example\.com/ https://example.com/ 302

この例はセクションの区切りを示すもので、そのまま有効化する完全な設定ではありません。example.comとドキュメント用アドレスは構文説明のための例です。実際のリクエストは、利用者が持つサーバー、現在のポリシー、ネットワーク環境によって異なります。特に[Host]と[URL Rewrite]は名前解決やリクエスト先を変更するため、基本動作を確認する段階では具体的な項目を省き、接続が安定してから一つずつ追加してください。

セクション主な役割確認ポイント
[General]全般的なネットワーク・名前解決の設定パラメーターの意味、値、実行環境
[Rule]リクエスト条件と適用ポリシー種類、項目、順序、フォールバック
[Host]ホスト名に対する名前解決結果の指定接続先アドレス、有効期間、到達可能性
[URL Rewrite]式に基づいてリクエストURLを変更照合範囲、変更先、ループ

ファイルが存在してもルールが適用されるとは限らない

Configには複数のファイルを保存できますが、トラブルシューティングでは現在実際に使用されているファイルを特定する必要があります。編集内容を保存したらファイル一覧に戻って選択状態を確認し、HomeでGlobal Routingも確認してください。ルールによる振り分けを確認する際は、まずConfigの状態にします。ProxyとDirectは異なるグローバルルーティングを比較するための状態です。ファイルを保存しただけで、すべてのリクエストがそのファイルのルールに従って判定されるとは限りません。

編集前に動作確認済みのコピーを残し、作業用コピーには見分けやすい名前を付けてください。たとえば「ドメインルールのテスト」のように用途を示します。サーバーのパスワード、サブスクリプショントークン、個人アカウント情報はファイル名に含めないでください。リモートファイルとローカルコピーを併用する場合は、編集対象を確認してください。リモート更新によって同じファイル内のローカル変更が上書きされることがあります。重要なカスタム設定は記憶に頼らず、別途記録しておきましょう。

変更は検証可能な小さな単位に分ける

一度の変更は、できるだけ一つの層にとどめてください。特定のドメインの経路を変える場合は、まず該当する[Rule]の行だけを変更し、DNSやHost、サーバー認証情報は同時に変更しません。こうすれば、テスト結果が変わったときに原因を直前のルール変更に絞れます。複数の層を続けて変更してからテストすると、結果が改善してもどの変更が有効だったか分からず、次回の更新で再び手がかりを失うおそれがあります。

ファイルを読むときは、まずセクション名を探し、次にFINALを確認してから、フォールバックより前にある広範囲のルールを見ます。先頭から一行ずつ読むより、全体像をつかみやすい方法です。意味の分からないパラメーターは、通信の取り込み、名前解決、リクエスト判定のどれを制御するのか確認するまで、いったん元の値を保ってください。項目名から値を推測したり、別の設定形式にある似た項目をそのまま.confに転記したりしないでください。

02 General：全般設定とDNSの範囲

[General]のパラメーターは設定全体の実行環境に影響し、特定のドメインだけを判定するものではありません。ルールの構文が正しくても動作が想定と異なる場合は、ポリシーだけでなく、全般設定によって通信がルール処理に入る方法が変わっていないかも確認してください。「システム通信をどう取り込むか」「ドメイン名をどうアドレスに変換するか」「最終的にどの経路で接続するか」は関連しますが、同じ設定項目ではありません。

bypass-systemとskip-proxy

bypass-system = trueは、特定のシステム通信を該当する仕組みでプロキシ処理から除外するための設定です。[Rule]のDIRECT項目をすべて有効にすることと同じではなく、端末全体が直結になるという意味でもありません。特定の通信がルール判定の対象になるかどうかは、このパラメーターの真偽値だけで推測せず、実際のリクエスト記録と現在の通信取り込み条件を確認してください。

[General]
bypass-system = true
skip-proxy = 127.0.0.1, 192.168.0.0/16
dns-server = system

skip-proxyは、該当するプロキシ処理を経由しないアドレス範囲を指定します。例にはループバックアドレスと一般的なプライベートネットワークの一つを示していますが、家庭や職場のネットワークをすべて網羅しているわけではありません。ルーター、プリンター、LAN内のサービスが別のアドレス範囲にある場合は、実際のアドレスを確認してください。プライベートアドレス範囲をすべて一度に追加すると、本来管理された経路でアクセスする内部サービスの接続経路が変わる可能性があります。まず利用中のネットワークを把握しましょう。

ここでいうバイパスと[Rule]のDIRECTは、単純に同じものとして扱えません。前者は通信が後続の処理に進むかどうかに影響する場合があり、後者はルール層で直結ポリシーを選択します。LANルールにリクエスト記録がまったく残らない場合は、先にグローバル設定で除外されていないか確認してください。すでに前段階で処理が決まっているなら、そのルールの位置を変えても通常は結果を変えられません。

DNSの結果とルーティングポリシーは別々に確認

dns-server = systemは、該当するシステムの名前解決先を使う設定です。基本設定を理解しやすくするのに適していますが、どのネットワークでも必要な名前を解決できるとは限りません。DNSはホスト名をアドレスに変換し、PROXYやDIRECTは接続経路を決めます。ドメインルールがPROXYに一致しても、名前解決先が想定どおりだとは限りません。名前解決に成功しても、接続先ポートへの接続が成功するとは限りません。

ほかのDNSサーバーを設定する場合は、用途、権限、到達可能性を把握しているアドレスだけを使ってください。一度のテストを成功させるために複数の名前解決先を次々と追加すると、結果の違い、キャッシュ、ネットワーク切り替えが重なり、問題を再現しにくくなります。まずシステムの名前解決結果を記録し、ルーティングルールを変えずにほかの設定と比較すれば、問題が本当に名前解決層にあるかを確認できます。

アドレスルールによって名前解決が必要になる場合

ドメイン条件は通常、リクエストのホスト名を使って直接判定できます。一方、GEOIPやIP-CIDRの条件には接続先アドレスの情報が必要です。最初のリクエストがドメイン名のみの場合、アドレスルールを判定するために名前解決が必要になることがあります。ルール行に適切なno-resolveオプションが付いている場合、「このルールのためだけにドメイン名を積極的に解決しない」という意味であり、「接続全体でDNSが不要」という意味ではありません。この違いは、ドメイン名のリクエストがアドレス条件に一致するかどうかに直接影響します。

接続先アドレスがすでに分かっているリクエストと、まだ名前解決されていないドメイン名のリクエストでは、同じサービスにアクセスしても判定過程が異なることがあります。no-resolveを使う場合は、追加の名前解決を抑えるなど、その理由をルールの近くに記録してください。すべてのIPルールに決まり文句のように付けるものではありません。最終的なアドレスに基づいてポリシーを決める必要があるなら、名前解決が必要なことを理解し、その動作を検証してください。

ネットワーク変更後の確認手順

iPadまたはiPhoneでWi-Fiを切り替えたら、まず基本のネットワーク接続を確認し、その後に名前解決とLAN内への到達性を確認してください。同じプライベートアドレスでも、ネットワークが変われば別の機器を指すことがあります。以前の接続結果を常に有効だと考えないでください。On Demandは接続を開始する条件を制御するもので、DNSや[Rule]の設定確認に代わるものではありません。自動接続後も、新しいリクエストにどのポリシーが適用されたか確認してください。

全般設定は、項目数と用途を一致させることが大切です。特定のドメインルールで解決できる問題に対して、まずすべての名前解決経路を変える必要はありません。プライベートネットワークの一つの範囲を修正すれば解決するなら、バイパスリスト全体を拡大する必要もありません。保存前に半角カンマ、等号、アドレスのプレフィックスを確認し、保存後は新しいリクエストで再テストして、既存の接続やキャッシュによる影響を避けてください。

03 Rule：ドメイン条件と照合範囲

[Rule]の一般的な行構成は「ルールの種類、照合内容、適用ポリシー」です。項目は半角カンマで区切り、ドメイン欄にはプロトコル、パス、ポートを記入しません。example.comで振り分ける場合はホスト名だけを指定し、完全なWebアドレスは記入しないでください。ドメインルールが判定するのはリクエストの接続先名であり、ページタイトルや本文、アドレス欄にあるすべての文字列ではありません。

DOMAIN：完全なホスト名を指定

DOMAIN,example.com,DIRECTは、example.comという完全一致の名前だけを対象にします。同じ文字列を含む別の名前には自動で一致せず、api.example.comにも自動適用されません。APIやログイン用ホストに個別のポリシーを設定する場合は、DOMAINを使うと範囲が明確です。通常は、より広い範囲に一致するサフィックスルールより前に置きます。

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

このルールでは、api.example.comは最初の行に一致してDIRECTになります。example.comと、サフィックス条件に合致するほかのサブドメインは2行目に進み、PROXYが適用されます。2行の順序を入れ替えると、広い範囲を対象にするサフィックス条件が先に一致し、後続の例外ルールが機能しません。ルールシステムが精度の高いDOMAINを自動的に上位へ移動することはありません。記述順序が実際の判定順序に大きく関わります。

DOMAIN-SUFFIX：ドメインとサブドメインを対象にする

DOMAIN-SUFFIX,example.com,PROXYは、example.comとそのサブドメイン（a.example.comやb.a.example.comなど）に適用されます。サフィックスはドメイン名の区切りを基準に判定されるため、notexample.comは同じドメインとして扱われません。ワイルドカードが必要だと思ってアスタリスクを付けるのはよくある誤りです。このルールタイプではドメインのサフィックスをそのまま指定し、正規表現に置き換える必要はありません。

サフィックスルールは、同じドメイン体系全体に一つのポリシーを適用する場合に適しています。ただし、Webサイトのすべての機能が同じドメインにあるとは限りません。ログイン、画像、ファイル、計測などのリクエストは別のドメインを使うことがあります。そのため「トップページは開くが添付ファイルを読み込めない」からといって、サフィックスルールが無効とは限りません。失敗したリソースのホスト名を確認してから、別のルールが必要か判断してください。

DOMAIN-KEYWORD：名前に含まれる文字列で判定

DOMAIN-KEYWORD,example,DIRECTは、exampleという文字列を含むドメインのリクエストに一致します。単一のサフィックスよりも、直感で範囲を制御しにくい条件です。異なる組織のホスト名まで対象になったり、名前の異なる関連リソースを見落としたりすることがあります。このような広範囲の条件が必要だと明確に分かっている場合を除き、完全一致ドメインまたはサフィックス条件を優先し、後で説明しにくい誤一致を減らしてください。

ルールの種類適した用途主な制約
DOMAIN特定ホストへの明確な例外サブドメインは自動的に含まれない
DOMAIN-SUFFIX同一ドメイン体系独立した別ドメインは対象外
DOMAIN-KEYWORD必要な場合に限る部分一致条件照合範囲が広がりやすい

リクエスト記録から条件を特定

ルールを追加する前に実際のリクエスト先ホストを特定してください。ページ名から推測しないでください。アプリは複数のバックエンドサービスに接続する場合があり、アドレス欄のドメインが入口にすぎないこともあります。再現可能な操作で問題を起こし、同じ時間帯の接続先名を確認してからDOMAINとDOMAIN-SUFFIXのどちらを使うか判断してください。記録に接続先アドレスしか表示されていない場合は、確実なドメイン条件を推測で補わないでください。

国際化ドメイン名を照合する場合、表示上の名前とネットワークで使われるエンコード形式が異なることがあります。クライアントの記録に表示され、実際に判定に使われるホスト名を確認してください。アドレスをコピーする際は末尾のパスやクエリパラメーター、意図しない空白も取り除きます。ドメインルールはURL Rewriteではないため、DOMAIN欄にパスを書いてもパス照合はできません。

複数のドメインルールを管理する場合は、「目的」と「構文上の範囲」を分けて記録してください。たとえば目的が自分のテストサービスに特定の経路を使わせることでも、条件には具体的なホスト名を記述します。「仕事用サイト」のような注釈だけでは、数か月後に広いキーワードを選んだ理由が分からなくなることがあります。照合の根拠と選択理由を残す方が、重複するルールを増やし続けるより長期的な管理に役立ちます。

04 IP、GEOIP、USER-AGENTの条件

ドメイン条件は名前を基準にし、アドレス条件は接続先のIPを基準にします。判定対象が異なるため、特定のドメインが常に同じアドレスに対応するとも、同じアドレスが一つのドメインだけに使われるとも限りません。コンテンツ配信、負荷分散、ネットワーク環境によって名前解決結果が変わることがあります。IPルールを主な判定方法にするのは、接続先が実際にアドレス範囲で管理されている場合に限ってください。

IP-CIDR：アドレスとプレフィックス長を理解する

IP-CIDR,192.168.0.0/16,DIRECTは、IPv4アドレスの範囲に一致するルールです。スラッシュの後の数字はネットワークプレフィックス長であり、ポート番号やアドレス数ではありません。通常、プレフィックスが長いほど範囲は狭くなります。単一のIPv4アドレスは/32で表せます。編集前に対象がどのネットワークに属するか確認し、アドレスの先頭が似ているだけで範囲を広げないでください。

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

192.0.2.10と2001:db8::/32はドキュメント用の例であり、接続先の実在サービスではありません。IP-CIDR6はIPv6アドレスの条件に対応します。IPv6アドレスをIPv4ルールに記入しても、自動変換されません。サービスが両方のアドレスを返す場合、IPv4ルールだけを確認すると、実際に使用されたIPv6接続を見落とすことがあります。記録にある接続先のアドレス種別を確認してから、必要なルールを判断してください。

LANルールと実際のネットワーク構成

家庭や職場のネットワークではプライベートアドレスがよく使われますが、具体的な割り当てはネットワークの管理方法によって異なります。プリンターにアクセスできない場合は、実際のアドレス、サブネット、ネットワーク分離の設定を確認してください。機器が別の分離ネットワークにある場合、ルールでDIRECTを選んでも、別のネットワークへの経路やアクセス権が自動で得られるわけではありません。ルールが選べるのは既存の経路であり、ルーターに存在しない接続を作ることはできません。

no-resolve付きのアドレスルールでは、リクエストに接続先アドレスがすでに含まれているか、もう一度確認してください。リクエストがドメイン名のまま判定に進む場合、このオプションによって追加の名前解決が行われず、アドレス条件に一致するための情報を得られないことがあります。目的に応じてno-resolveを維持する、具体的なドメインルールを追加する、または名前解決を許可したときの動作を確認してください。同じネットワーク範囲をむやみに複数のルールへコピーしないでください。

GEOIP：アドレスデータベースによる分類

GEOIP,CN,DIRECTは接続先IPの地理的な分類結果に基づいて判定します。CNは地域コードです。Webページの言語、ユーザーの所在地、サイトの登記地、コンテンツサービスの対象地域を判定するものではありません。中国語のページが別の地域のアドレスを使うことも、国際的なサービスが国内の配信アドレスに解決されることもあります。GEOIPをサービスの身元確認に使わないでください。

データベースによる分類には限界があり、変更されることもあります。一度一致した結果を恒久的な結論とみなさないでください。特定のサービスを安定して処理する必要がある場合は、具体的なドメインの例外をGEOIPより前に置きます。残りのアドレスを広い範囲で分類する場合は、その後にGEOIPを使います。分類結果が想定と違うときは、接続先IPとその時点の名前解決結果を記録してから、データベースとルール順を確認してください。サーバーのプロトコルに問題があると即断しないでください。

USER-AGENT：リクエスト情報の制約

USER-AGENTは、リクエストに含まれるUser-Agent情報に基づいて照合します。たとえばUSER-AGENT,ExampleClient*,DIRECTは、前方一致のパターンを表します。アプリの表示名を使ってすべての接続を識別するものでも、システムレベルのアプリ識別子でもありません。クライアントが該当するリクエスト情報を取得でき、リクエストにその項目が含まれ、対応する照合方式に合致する場合に限り、条件を判定できます。

暗号化された接続では、外側の接続からHTTP項目を直接読み取れないことが一般的です。そのため、すべてのHTTPSリクエストにUSER-AGENTが確実に一致すると考えないでください。このルールを一致させるために、証明書の信頼範囲や復号対象を広げることも避けてください。このマニュアルの基本設定では、そのような操作を前提にしていません。明確なドメイン指定で目的を達成できる場合は、検証しやすいドメイン条件を優先してください。

これらの種類を組み合わせるときは、まず「その時点で実際に見える情報は何か」を確認してください。ホスト名、IPv4、IPv6、または読み取り可能なリクエスト項目のどれでしょうか。判定に必要な情報がなければ、構文が正しくても一致するとは限りません。情報の可視性と照合構文を分けて確認すると、判断材料のないルールを繰り返し調整せずに済みます。

05 PROXY、DIRECT、REJECTと判定順序

ルールの前半は「どのリクエストか」を記述し、末尾のポリシーは「どう処理するか」を示します。このページで扱う基本ポリシーのキーワードはPROXY、DIRECT、REJECTです。表記は英語のまま使用します。PROXYは現在適用されているプロキシ経路を使い、DIRECTは直接接続し、REJECTは一致したリクエストを拒否します。これらは遅延の段階を表すものではなく、接続結果に応じて自動で切り替わることもありません。

ポリシーはサーバー設定の代わりにならない

PROXYを使うには、利用可能なユーザー所有のサーバー情報と適切な選択状態が必要です。ルールがPROXYに一致しても、認証、ポート、プロトコルの設定が間違っていれば接続に失敗することがあります。DIRECTも、接続先へ到達できる基本ネットワークが必要です。接続の成功を保証するものではありません。REJECTは明示的な拒否です。送信したくないことが明確なリクエストに適していますが、重要なインターフェースに適用するとログイン、同期、コンテンツ読み込みに影響する場合があるため、先に依存関係を確認してください。

項目作用する層確認方法
PROXYルールの適用ポリシープロキシ経路とサーバーの状態を確認
DIRECTルールの適用ポリシー基本ネットワークと接続先への到達性を確認
REJECTルールの適用ポリシー拒否が想定どおりか確認
設定 / ConfigGlobal Routingのモード現在の設定でルールを検証
プロキシ / ProxyGlobal Routingのモードグローバルプロキシ経路との比較に使用
直結 / DirectGlobal Routingのモード基本ネットワーク経路との比較に使用

先に一致したルールがポリシーを決める

通常の[Rule]による順序判定では、リクエストは上から順に照合され、最初に一致したルールがポリシーを決めます。後続のルールがより具体的でも、前の結果を自動で上書きすることはありません。いわゆる「優先順位」を決めるのは、まず記述位置です。ルール名が専門的に見えるか、項目が長いかは関係ありません。特定の例外を広い条件より前に置き、ファイルの順序に沿って各判定を説明できるようにしてください。

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

api.example.comにはDIRECTを適用し、blocked.example.comはREJECTします。example.comのサフィックスに一致する残りの名前にはPROXYを適用します。これらのドメイン条件に一致しない場合に限り、プライベートネットワークの範囲とGEOIPを確認します。example.comの名前解決先がCNに分類されても、先にサフィックスルールでポリシーが決まっていれば、後続のGEOIPによってDIRECTに変更されることはありません。

FINALはフォールバックであり、修正用の行ではない

FINALにはドメインやアドレスの条件がありません。一般的な形式はFINAL,PROXYまたはFINAL,DIRECTで、フォールバックとして使う位置に記述します。FINALを前に置くと、後続の通常のルールが処理されなくなります。管理時は意図が明確な最終ポリシーを一つ残し、選択理由を記録してください。異なる方向を示すFINALを複数残して、互いに補完することを期待しないでください。

どちらのフォールバックにも、明確な適用条件があります。FINAL,DIRECTは、個別に指定されていない通信を直結します。FINAL,PROXYは、個別に指定されていない通信をプロキシ経路にします。利用可能なサーバー、対象の用途、障害時の影響を考慮して選択してください。どちらか一方が常に正しいわけではありません。フォールバックを変更する前に、よく使うサービスをテストし、どの通信の経路が変わるか確認してください。

ルーティングのモードとルールのポリシーを区別

Global RoutingのConfig、Proxy、Directは画面上のモードです。ルール内のPROXY、DIRECTは設定ファイルのキーワードです。文字は関連していますが、同じ設定項目として扱わないでください。ルールを確認するときは、まずConfigに戻します。ProxyやDirectで一時的に比較した後は、元に戻したか確認してください。次のテストでもグローバルモードのままなのに、特定ルールが変化したと誤解するおそれがあります。

REJECTのテストでは、特に対象を限定してください。まず識別しやすい単一のテストホストを使い、一致記録を確認してからサフィックスへ範囲を広げることを検討します。広いキーワードで大量のリクエストを一度に拒否し、「ページが少し速くなったようだ」という印象だけで判断しないでください。重要なリソースは、後の同期、支払い確認、セッション更新で初めて使われることがあります。短時間問題が見えなかっただけでは、依存関係を十分に確認したことにはなりません。

06 HostとURL Rewrite：マッピングと書き換え

[Host]と[URL Rewrite]はいずれもアクセス結果を変える可能性がありますが、処理する層は異なります。Hostは名前に対応するアドレスを扱い、URL Rewriteは一致したURLの書き換えやリダイレクトを扱います。[Rule]はリクエストに適用するポリシーを決めます。3つの層を分けて理解すると、ページの接続先が変わった理由、証明書エラーの原因、振り分け条件が想定どおりに現れない理由を特定しやすくなります。

Host：ホスト名の名前解決結果を固定

example.com = 192.0.2.10は、その名前にアドレスを指定する設定です。アクセス先のドメイン名をこの数字のアドレスに置き換えるものではなく、HTTP HostやTLSで使うサーバー名、接続先の証明書が自動で変わるわけでもありません。サーバーは引き続き元の名前を正しく処理できる必要があります。到達可能なIPアドレスを指定しても、接続先がそのドメインのサービスを提供していなければ、誤ったページや証明書不一致の警告が表示されることがあります。

[Host]
example.com = 192.0.2.10
api.example.com = 192.0.2.11

例の2つのマッピングは互いに独立しており、ルートドメインの項目がすべてのサブドメインに自動で適用されるわけではありません。複数の名前を固定する場合は、それぞれの接続先と使用目的を確認してください。マッピング先のアドレスは、自分で管理し検証できる環境のものを使用します。変化の多い公開サービスの古いアドレスを長期間固定すると、通常の負荷分散や障害時の切り替えが機能しなくなることがあります。

Hostは自分が管理するテスト環境や、明確な理由がある名前解決の修正に使います。未知のアドレスを試す目的で使うものではありません。トラブルシューティングでは作業用コピー内の該当マッピングを削除または無効にし、システムの名前解決結果と比較してください。通常の名前解決に戻して接続が回復する場合は、マッピング先の有効性、ポートの開放状態、証明書の名前を確認します。プロキシルールをさらに追加するのではなく、まずマッピングを調べてください。

URL Rewrite：範囲を限定して接続先の変更を指定

URL Rewriteでは、一般に照合パターン、置換先、処理方法を組み合わせて記述します。以下はexample.comのHTTPアドレスを対応するHTTPSアドレスへリダイレクトする構文例です。形式の説明用であり、実際に使う前に接続先サービスがHTTPSに対応していることと、サーバー側の既存処理と競合しないことを確認してください。実際のサービスアドレスで試す場合は、作業用コピーを使って一つの入口から検証してください。

[URL Rewrite]
^http://example\.com/ https://example.com/ 302

照合部分のドットを\.とするのは、文字どおりのドットに限定するためです。example.comとだけ記述すると、正規表現のドットが任意の1文字として扱われ、照合範囲が広がる可能性があります。先頭の^は文字列の先頭から照合する指定です。ドメインの後にスラッシュを置くことも、ホスト名の境界を限定するのに役立ちます。書き換えルールでは、広い範囲のリクエストに一致する式ではなく、できるだけ正確な対象を指定してください。

暗号化された内容を自由に変更する汎用機能ではない

完全なURLをクライアントが読み取れるかどうかは、リクエストの形式と参照できる情報によって異なります。HTTPSではパスが暗号化層の内側にあることが多く、URL Rewriteを設定すればあらゆるHTTPSパスに一致すると考えてはいけません。外側から見える接続先と、完全なHTTPリクエストは同じではありません。接続ポリシーだけを変更したい場合は、[Rule]に戻ってドメインまたはアドレス条件を使ってください。リクエスト内容の処理を追加する必要はありません。

このページでは、証明書の信頼範囲や復号対象を拡大する手順を基本設定に含めていません。リクエスト情報を追加で参照する機能が必要な場合は、権限の範囲と適用対象を理解したうえで、アプリ内の説明を確認してください。通常の接続失敗を直すために出所の分からない証明書を追加したり、サービスの認証失敗をURL Rewriteの機能不足と誤解したりしないでください。

リダイレクトループと重複条件

あるルールがアドレスAをBに変更し、別のルールやサーバーがBをAに戻すと、リダイレクトループが発生することがあります。ブラウザーが何度も転送されたり、転送回数が多すぎると表示されたりする場合は、書き換えルールを一つずつ無効にし、各回のLocationの変化を記録してください。PROXYとDIRECTを切り替えると到達性は変わることがありますが、互いに相手へ戻る論理的な関係は修正できません。

設定を組み合わせて管理する場合は、まず通常のDNSとルーティングを検証し、次にHost、最後にURL Rewriteを個別に有効にしてください。3つの層を同時に変更すると、最終的な接続先が名前解決、リダイレクト、ページ側のリクエストのどれによって決まったか分かりにくくなります。変更ごとに目的と戻し方を記録し、テスト後は一時的なマッピングを削除してください。残ったテスト項目を、後から恒久的な要件と誤認するのを防げます。

07 よくあるルール構成と設定の管理

管理しやすい設定とは、ルールの数が多い設定ではなく、各リクエストの処理結果を少数の条件で説明できる設定です。組み合わせを考える前に、既定の経路を明確にしてください。大部分を直結にして指定ドメインだけプロキシを使うのか、大部分をプロキシにして明確な例外だけ直結にするのかを決めます。この方針をFINALに反映し、範囲の狭い具体的な例外から順に前へ置きます。

構成例1：DIRECTをフォールバックにし、指定ドメインにPROXYを適用

以下は「確実に指定した名前だけにプロキシ経路を使う」構成の例です。api.example.comは完全一致の直結例外です。example.comのサフィックスに一致するほかのリクエストにはPROXYを適用し、それ以外はFINAL,DIRECTで処理します。重要なのは例示用ドメインそのものではなく、例外、ドメイン群、LAN、フォールバックの順序です。

[General]
bypass-system = true
dns-server = system

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

接続先サービスが別の独立したドメインを実際に使っている場合、この例で自動的に判定されることはありません。新しい条件はリクエストの記録を根拠に追加し、サービス名をキーワードにして似た名前を一括で対象にしないでください。アプリが複数のリクエストで一連の動作を完了する場合は、入口ページが表示されるかだけでなく、起動、ログイン、読み込み、送信まで確認してください。

構成例2：PROXYをフォールバックにし、明確な範囲を直結

別の構成では、例外に一致しないリクエストにPROXYを適用します。利用者がすでに持つサーバーが該当する通信を処理でき、ローカル経路を使い続けるリクエストを把握していることが前提です。例ではドメインの例外とプライベートネットワークの範囲を残し、さらにアドレス分類にGEOIPを使っています。GEOIPを残すかどうかは、よくある設定に記述されているからではなく、実際の要件に基づいて判断してください。

[General]
bypass-system = true
dns-server = system

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

2つの設定例は管理方針が異なるため、そのまま連結しないでください。連結すると、前半のFINALで判定が終了し、後半の大半の項目が適用されなくなります。設定を統合するときは、各例のFINALを先に削除し、具体的なルールと重複条件を整理します。最後に全体の目的に合うFINALを一つだけ残し、統合後の動作を項目ごとに検証してください。

Subscribeと設定ファイルは別々に更新

Subscribeの更新は通常、既存のサーバー一覧を対象とします。一方、設定ファイルの更新ではルール、パラメーター、ポリシーの参照先が変わる場合があります。片方を更新しただけで、もう一方も正しく同期されたとは限りません。一覧内の名前が変わり、カスタム設定が特定の名前を参照している場合は、その参照先が現在も存在するか確認してください。このページで基本キーワードのPROXYを使うのは、ルールの意味が教材内のサーバー名に依存しないようにするためです。

SubscribeのURLにはアクセストークンが含まれる場合があるため、機密情報として扱ってください。トラブルシューティングの資料を共有するときは、必要なルールと接続先の種類だけを残し、完全なSubscribeのURL、サーバー認証情報、個人を特定できる情報を削除します。共有リンクとSubscribeのURLの違いは、接続情報リンクの形式に関する説明を参照してください。インポートや更新の仕組みは異なり、テキストとしてコピーできるというだけで同じ種類のデータとは限りません。

保存、切り替え、元に戻す

Configで編集またはインポートしたら、まずファイルが正常に開けることを確認し、現在選択されている項目を確認してください。保存してHomeに戻り、Global RoutingがConfigになっていることを確認してから、新しいリクエストでテストします。接続を確立し直す場合は、影響を受ける操作を先に終了し、アプリの現在の画面に従って接続を切り替えてください。継続中の長時間接続は、接続開始時の経路を引き続き使う場合があります。

元に戻す際は、「直前に追加した内容を消す」という曖昧な対応ではなく、動作確認済みの作業用コピーを基準にしてください。変更の目的、該当セクション、テスト対象、観察結果を毎回記録します。リモート設定の更新によってローカル変更が上書きされた場合は、まず作業用コピーを復元して基本接続を確認してから、どの項目を再統合するか判断してください。問題が起きている最中に、出所の分からない設定を次々にインポートしないでください。

クライアントの買い切り購入 ≠ 接続サービスのプラン。Shadowrocketの購入と、利用者がすでに契約・利用している接続サービスは別に管理されます。当サイトではサーバーやサブスクリプションを提供、販売、推奨していません。アプリの入手先とデベロッパ情報を確認するには、App Storeで正規アプリを確認する方法をご覧ください。クライアントはAppleプラットフォーム向けにのみ配信されています。システム要件はApp Storeのページをご確認ください。

08 ルールの検証とトラブルシューティング

トラブルシューティングでは、まず「接続できない」「接続は確立したがリクエストが失敗する」「リクエストは成功したが経路が想定と違う」を区別してください。3つの状態では必要な証拠が異なります。Homeに接続状態が表示されても、すべての接続先へ到達できるとは限りません。Connectivity Testの結果だけで、実際のサービスリクエストが想定したルールに一致したとも判断できません。

手順1：再現可能なテスト対象を決める

自分が把握しているテストページを開くなど、明確な操作を一つ選び、接続先のホスト名、現在のネットワーク、失敗時の状況を記録します。バックグラウンドのリクエストを減らすため、一度に一つの操作だけを実行してください。ログインやアップロード時だけ問題が起きる場合は、その段階をテストし、ホーム画面を繰り返し更新しないでください。処理の段階によって異なる接続先が使われることがあります。トップページが開いても後続のリクエストを検証したことにはなりません。

続いて、現在のファイル、Global Routing、サーバーの選択、直近の変更を記録します。ネットワーク切り替え後に問題が発生した場合は、切り替え前と後のネットワークでそれぞれ再テストしてください。証拠を保存する前に、アプリの再インストールやすべての設定のリセットを続けて行わないでください。故障を説明する状態が消え、原因を「一つのルールの変更」から、より広い範囲の再設定へと追跡し直すことになります。

手順2：設定が判定に使われているか確認

Configで実際に選択されているファイルを確認し、編集内容が保存済みであることを確認してから、HomeのGlobal Routingを確認してください。ProxyまたはDirectのままでは、全体の経路を比較することはできますが、それだけで[Rule]の特定条件が無効だとは判断できません。Configに戻って新しいリクエストを発生させ、接続先、照合条件、適用ポリシーがファイルの順序どおりかを確認します。

Global Routing: Config
Config: 現在の作業用コピー
Target: api.example.com
Expected Rule: DOMAIN,api.example.com,DIRECT
Expected Policy: DIRECT

これは記録用の形式であり、クライアントの実行ログではありません。実際の結果は今回のテストに基づいて記録し、想定値を観察結果として書き写さないでください。記録に対象リクエストが見当たらない場合は、既存の接続が再利用されたか、別のグローバル条件によって先に除外されたか、記録時刻が操作と一致しているかを確認してください。

手順3：症状から範囲を絞り込む

症状優先して確認する項目次に確認する情報
想定外のルールに一致する前にある広範囲の条件とFINALの位置実際の接続先名とルール行
PROXYに一致するが接続できないサーバー設定と経路の到達性認証、タイムアウト、接続先ポート
ドメイン名では失敗するが、アドレスには到達できるDNS、Host、証明書の名前名前解決の結果とサービス名
ページの一部のリソースが失敗する独立したリソース用ドメインとREJECT失敗したリソースの実際のホスト名
LAN機器に到達できないネットワーク範囲、分離設定、バイパス条件機器のアドレスとローカルネットワーク経路

誤ったルールに一致する場合は、まず一致可能な最初の前置条件を探してください。よくある原因は、DOMAIN-KEYWORDの範囲が広すぎる、サフィックスルールが完全一致の例外より前にある、FINALがファイルの途中に置かれている、などです。順序を修正したら新しいリクエストを発生させてください。末尾に同じルールを追加し続けても、前の条件ですでに処理されたリクエストは再判定されません。

適用ポリシーは正しいのに接続できない場合は、その経路に必要な条件を確認します。PROXYでは利用者がすでに持つサーバーのアドレス、ポート、プロトコル、認証情報を確認します。DIRECTでは基本ネットワークと接続先への到達性を確認します。REJECTでは、意図して拒否しているかをまず確認します。認証の失敗にはドメインルールを追加しても通常は効果がありません。接続先がすでに拒否されているなら、DNSを変更しても自動で別のポリシーには切り替わりません。

手順4：キャッシュ、既存の接続、設定ミスを区別

ドメイン名の解決結果や既存の接続には、以前の状態が一時的に残ることがあります。ルールを変更した後は、制御可能な新しいリクエストで検証してください。必要に応じてアプリの操作に従って接続を再確立し、結果を確認します。キャッシュの変化のたびに、設定がランダムに適用されたと考えないでください。「変更前」「保存後」「新しいリクエスト後」の状態を記録すれば、編集上の問題と接続のライフサイクルを区別しやすくなります。

特定のアプリだけ失敗する場合は、別のドメイン、異なるアドレス種別、特殊な通信方式を使っていないか確認してください。テストページが一つ開いても、すべての通信経路が利用できるとは限りません。遅延の数値だけでサービス全体の使い勝手を判断することもできません。テスト結果とサーバー選択の見方は、遅延テストと接続先の判断方法をご覧ください。テスト対象は、利用者がすでに持っている一覧の範囲にしてください。

手順5：再確認できる結論をまとめる

トラブルシューティングの後は、有効な最小限の変更だけを残し、テスト中に一時変更したGlobal Routingを元に戻してください。結論には、問題の原因となった条件、変更した行、検証方法、元に戻す方法を記録します。原因を特定できない場合は、情報を伏せた設定の一部と実際の症状を保存し、よくある質問を確認してください。初回の許可やインポート手順をやり直す場合は、クイックスタートガイドに戻ってください。