公式マニュアル・総合リファレンス

Shadowrocketの設定項目
・ルール構文リファレンス

セクションごとに設定を読み解き、条件に沿ってルールを記述し、接続ログで結果を確認します。

このページでは、ルール構文や設定の範囲、トラブル対処を確認できます。初めて接続する場合は、先に使い方ガイドを読み、手元のサブスクリプションを読み込んで基本動作を確認してから、分流設定の調整に戻ってください。例にあるドメインやアドレスは書式の説明用であり、実際に必要なサービス情報の代わりにはなりません。

設定ファイルの構成：まずセクションの役割を把握する

Shadowrocketの設定ファイルは通常、.conf形式で記述します。角括弧内の名前がセクションを示し、その下の各行に設定、マッピング、ルールを記述します。すべてのパラメーターを並べた単なる一覧ではありません。同じ記述でも、置くセクションによって意味が異なったり、正しく解析されなかったりすることがあります。内容を知らない設定ファイルを読むときは、特定のドメインを検索するより先にセクションの境界を確認すると、ファイル全体の意図を把握しやすくなります。

よく使う4つのセクションと役割

[General]にはDNS関連のオプションなど、全般的な動作設定を記述します。[Rule]には通信のマッチ条件と適用するポリシー、[Host]には指定ドメインのアドレスマッピング、[URL Rewrite]には条件に合うURLを処理する式を記述します。それぞれ処理する段階が異なるため、互いに置き換えることはできません。特定ドメインを直接接続したい場合は、まずルールを検討してください。通信先を変える目的で、ドメインの名前解決結果を安易に変更するべきではありません。

セクション解決する内容主な記述内容
[General]全般的なネットワーク動作をどう設定するかdns-server = system
[Rule]条件に一致した接続にどのポリシーを適用するかDOMAIN,example.com,PROXY
[Host]指定ドメインをどのアドレスにマッピングするかexample.com = 192.0.2.10
[URL Rewrite]式に一致したURLをどう処理するかマッチ式、転送先、アクション

基本的な記述例で構文を確認

以下の例では、セクション、代入、ルールの3種類の書き方を示します。設定値の代入には等号、ルール項目の区切りにはカンマを使い、互いに置き換えることはできません。ルール内のPROXYはポリシーであり、サーバーアドレスではありません。例にはサーバー情報が含まれていないため、ルールの構造を確認するためのものです。使用する前に、アプリ内で利用可能な手持ちのサーバーを準備し、接続先として選択されていることを確認してください。

[General]
dns-server = system

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

行ごとに読むときは、まず半角カンマと等号を確認し、次にキーワード、項目数、ポリシー名をチェックします。日本語入力で入力した全角の句読点は見た目が似ていても、有効な区切りとして認識されない場合があります。セクション名は原文のままにしてください。行の先頭や末尾に紛れた見えない文字や、コピー時に混入したリッチテキストの記号も、正しく見えるルールを無効にすることがあります。プレーンテキストで編集し、空行も適切に残しましょう。

完全な設定ファイルとルール例の違い

このページのコード例の多くは、関連するセクションだけを示したものです。コード例をすべて順番につなげて、1つのファイルにしないでください。互いに独立した状況を説明している場合があり、特に複数のFINALを予備ルールとして重ねて記述することはできません。例を既存ファイルに加えるときは、対応するセクションに統合し、同じ種類のルールがすでにないか確認してから挿入位置を決めましょう。セクションの重複や相反するポリシーは、内容を把握しにくくします。

サーバーのサブスクリプションと設定ファイルは、別の種類のデータです。サブスクリプションは通常、サーバー項目の提供や更新に使われ、設定ファイルは接続時の動作を定めます。一方を用意しても、もう一方が準備できているとは限りません。サブスクリプションは利用しているサービスの提供元から入手し、読み込み先に合った形式か確認してください。リンクの種類がわからない場合は、サブスクリプションの読み込み方法を先に確認しましょう。リンク形式の問題を、設定を何度も切り替えて解決しようとしないでください。

この章の目標は、すべてのセクションを埋めることではなく、それぞれの役割を説明できるようになることです。必要性がはっきりしない機能は追加しなくても構いません。短く、意図を説明できる設定ほど検証しやすくなります。見慣れない項目は、アプリ内の説明と実際の動作を確認してください。どこかの設定ファイルに記載されているからといって、使用中のデバイスやネットワークにも適しているとは限りません。

General：全般設定とGlobal Routing

[General]は設定ファイル内の全般設定セクションで、Global Routingは実行時のルーティングモードを選択する項目です。関連はありますが、同じ階層の機能ではありません。ファイルにルールを記述しても、現在のモードがそのルールを使う設定になっているか確認が必要です。「ルールがあるのに反映されない」ときは、項目を変更する前にモードと現在の設定ファイルを確認してください。前提を取り違えたままルールを増やすおそれがあります。

Config・Proxy・Directの各モード

設定に従って接続を処理するモードはConfig、通常アプリが処理する接続をプロキシ経由にするモードはProxy、直接接続するモードはDirectです。ここで説明しているのは全体の選択方法であり、システム上のすべての接続が必ず同じ経路を通るという意味ではありません。システム側で維持される動作、既存の接続、処理対象外の通信については、モード名だけで判断できません。

画面上の表示主な用途確認する点
Config設定に基づいてルールで振り分ける現在の設定、ルールの順序、最終ポリシー
Proxy一時的にプロキシ経由の接続を確認する選択中のサーバーと実際の接続結果
Direct一時的に直接接続できるか確認するローカルネットワークと接続先の応答

同じ接続先がProxyでは開き、Configでは失敗する場合、ルールのマッチ状況、DIRECTの経路、DNSの違いを確認できます。ただし、これだけで特定のルールが誤りだとは断定できません。比較テストの前後で、サーバー、接続先、ネットワークの条件を揃えてください。テスト後は元のモードに戻し、一時的なテスト状態が普段の利用状態になって、後から設定内容との対応がわからなくなるのを防ぎましょう。

DNS設定と通信ポリシーは別のもの

DNSはドメインをアドレスに変換し、ルールは接続をどのように処理するかを決めます。ドメインを正しく名前解決できても、接続先にアクセスできるとは限りません。また、PROXYを選択したからといって、各名前解決リクエストの経路まで決まるわけではありません。DNSの動作はアプリの設定、キャッシュ、ネットワーク環境、リクエスト方法にも左右されます。「どのアドレスに解決されたか」と「どのポリシーで接続するか」は、分けて確認してください。

[General]
dns-server = system

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

dns-server = systemは、この項目の参照先としてシステムのDNS設定を使用することを示します。現在のネットワークで適切な名前解決が行われると保証するものではありません。構文を理解するための出発点として使えますが、あらゆる環境に共通する設定ではありません。名前解決方法を変更する場合は、まず元の値を記録し、一度に1項目だけ変更してください。対象ドメインとほかのよく使うドメインをそれぞれ確認し、特定の接続先を直すことでほかのリクエストに影響が出ないようにしましょう。

既定値と明示的な設定の違い

全般設定の項目を削除すると、通常は既定の処理に戻ります。特定の真偽値を明示するのと同じとは限りません。既定の動作はアプリの設定にも左右される場合があるため、「この行がない」ことを「機能が必ず無効」と解釈しないでください。設定を移行するときは、用途が明確な項目だけを残しましょう。意味がわからない項目は複製した設定ファイルで試し、いわゆる最適化設定をまとめてコピーしないでください。

IPv6、DNS、ネットワーク範囲に関する設定は、ルールが判定できる接続情報にも影響します。たとえば接続先がIPv6アドレスを優先している一方、設定にはIPv4のネットワーク範囲しかない場合、汎用的なスイッチを追加するだけでは現象を説明できません。まず実際の接続アドレスを確認し、アドレスルールの追加、名前解決動作の調整、既定の設定の維持のいずれが適切か判断してください。アドレスファミリーを変更すると、ほかのサービスにも影響する可能性があるため、全体を再テストしましょう。

On Demandと設定ルールは分けて管理

On Demandは接続をいつ開始するかを扱い、[Rule]は接続が処理対象になったあと、どのように振り分けるかを扱います。ドメインルールをオンデマンド接続のトリガーとして記述することはできません。また、システムが自動接続したからといって、特定のルールがマッチしたとは限りません。アプリ内の項目からOn Demandの条件を確認し、設定ルールは別途検証してください。結果をそれぞれ記録すると、トラブルの切り分けが明確になります。

全般設定の目的は、動作を予測できるようにすることであり、設定ファイルを複雑にすることではありません。モードがConfigで、想定した設定ファイルが選択され、使用するサーバーが利用可能であることを確認してから、ルールの詳細に進んでください。基本的な接続がまだ確認できていない場合は、クイックスタートガイドに戻り、システムの許可設定と接続手順を確認しましょう。このページの以降の説明は、基本接続を検証できていることを前提としています。

ドメインルール：完全一致・サフィックス・キーワード

ドメインルールでは、「どのホストにどのポリシーを適用するか」を指定できます。サービスのアドレス変更を追い続けるより管理しやすい場合が多い一方、接続の処理時に対応するドメイン情報を取得できることが前提です。画面に表示されるURL、アプリが実際に接続するホスト、ログイン先、リソースのドメインは異なる場合があります。ブラウザーのアドレス欄に表示されたメインドメインをコピーするだけで、アクセス時に発生するすべてのリクエストをカバーできるとは限りません。

DOMAIN：ホスト名を完全一致で指定

DOMAINは、ホスト名全体を完全一致で指定します。次の例の1行目はapi.example.comだけを対象とし、同階層にあるほかのホストには自動的に適用されません。ドメイン欄にプロトコル、パス、ポートを含めないでください。https://や/loginはURLの別の要素です。DOMAINの欄にそのまま記述しても、ページのパスに応じた振り分けはできません。特定の接続先だけを制御したい場合は、対象範囲が明確なこの書き方を優先しましょう。

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

完全一致ルールを管理するときは、例外ごとに短いコメントを添え、ほかのホストと分ける理由を記録しておくと便利です。コメントには用途やテスト結果を記し、アカウント情報、トークン、機密性の高いURL全体は保存しないでください。完全一致ルールが増えた場合は、まずサービスごとに整理し、サフィックスルールが本当に必要か検討しましょう。数行減らすためだけにマッチ範囲を広げると、意図しない通信までマッチする可能性が高まります。

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

DOMAIN-SUFFIX,example.com,PROXYは、example.comとそのサブドメインに適用されます。たとえばwww.example.comやapi.example.comが対象です。ドメインのサフィックス境界に基づいてマッチし、任意の文字列が含まれるかどうかで判定するものではありません。似た綴りの別ドメインまで自然に対象になるとは考えないでください。通常はルートドメインを記述し、先頭にアスタリスクを付けたり、後ろにパスを追加したりしません。

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

この順序では、例外を先に処理し、その後に一般的な範囲を適用します。local.example.comへの接続は先頭の完全一致ルールにマッチし、それ以外の対象サブドメインには後続のサフィックスルールが適用されます。サフィックスルールを先に置くと、後続の完全一致ルールが「より具体的」だからといって優先されることはありません。ルールはブラウザーのスタイルセレクターのように、一覧全体から最も詳細なものを選ぶ仕組みではありません。

DOMAIN-KEYWORD：範囲を確認してから使う

DOMAIN-KEYWORDは、ドメインに指定したキーワードが含まれるかを確認するため、特定ドメインより広い範囲にマッチします。互いに関係のない複数のドメインに同じ文字列が含まれる場合があります。命名規則に共通点があり、影響範囲を把握できている場合に適しています。ブランド名、短い略称、一般的な英単語を、正確なサービスの境界として使うのは避けましょう。無関係な通信まで同じポリシーに振り分けられる可能性があります。

[Rule]
DOMAIN-KEYWORD,example,PROXY
FINAL,DIRECT

上の例はキーワードルールの構文を示すもので、日常の振り分けにそのまま使うものではありません。マッチの基準は文字列であり、サイトの運営元、サービスの種類、ページの内容ではありません。接続ログに安定した完全なホスト名が表示されている場合は、DOMAINまたはDOMAIN-SUFFIXを優先しましょう。ルールの意味が一目でわかり、限られた範囲のテストで検証できます。

種類対象範囲主なリスク
DOMAIN1つの完全なホスト名同じサービスの別ホストを見落とす
DOMAIN-SUFFIX指定したドメインとそのサブドメイン同じポリシーが不要なサブドメインまで対象にする
DOMAIN-KEYWORDドメインに含まれるキーワード無関係なドメインにもマッチし、対象範囲を把握しにくい

1回のアクセスに複数のルールが必要な理由

ログイン、画像、API、メディアの配信に、それぞれ別のドメインが使われている場合があります。メインページは表示されるのにログインできない場合は、失敗した接続の実際のホストを確認してください。すぐに曖昧なキーワードの対象範囲を広げないでください。明確なドメインを1つずつ追加して再試行し、そのルールによって該当する接続が変わったことを確認しましょう。リダイレクトが発生する場合は、転送後の接続先も確認してください。最初の接続先にマッチしても、転送先に同じポリシーが適用されるとは限りません。

接続ログにアドレスしか表示されず、使えるドメイン情報がない場合、DOMAINルールを追加しても効果がないことがあります。リクエストがアドレスを直接使っているか、ドメイン情報を取得できるか、アドレスルールが先にマッチしていないかを確認してください。ドメインルールが解決するのは、既知のホストにマッチさせる問題であり、サービスを自動的に見つけるものではありません。よくある疑問は、よくある質問の振り分けに関するトラブル対処もあわせて確認できます。

IPアドレスとリクエスト条件：GEOIP、IP-CIDR、USER-AGENT

接続先がIPアドレスで示される場合や、ネットワーク範囲で対象を指定したい場合は、アドレスルールを使用できます。ドメインルールとの主な違いは、マッチする対象です。ドメインルールはホスト名、アドレスルールは接続先のIPアドレスを扱います。同じドメインが複数のIPアドレスに解決されることも、1つのIPアドレスが複数のドメインに使われることもあります。アドレスルールは範囲が明確なネットワークに適しており、根拠がないまま、すべてのドメインルールの代わりに使うものではありません。

IP-CIDR：アドレスとプレフィックス長

IP-CIDRでは、IPv4アドレスとプレフィックス長を使ってネットワーク範囲を指定します。スラッシュの後の数字はネットワークプレフィックス長であり、ポート番号や接続数ではありません。数値が大きいほど対象範囲は狭くなります。1つのIPv4アドレスは/32で表せます。記述する前に実際のネットワーク範囲を確認し、1台のアドレスを広すぎるネットワークとして指定して、ほかの接続まで同じポリシーに振り分けないようにしてください。

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

この例は、よく使われるプライベートアドレス範囲を直接接続する意図を示していますが、すべて追加する必要があるかはデバイスが接続しているネットワークによって異なります。ルールが決めるのは、アプリの処理対象となる通信のポリシーです。ルーターがアクセスを許可している保証にはならず、ローカルネットワークのアクセス許可や接続先デバイスの設定の代わりにもなりません。接続先が実際には別のネットワークにある場合、DIRECTと記述しても、そのネットワークへの経路が自動的に作られるわけではありません。

no-resolveの役割と注意点

no-resolveはアドレスルールに付けるオプションで、そのルールを試すためだけにドメインを名前解決することを避けます。「DNSを無効にする」という意味でも、その後の接続で名前解決が不要になるという意味でもありません。接続先がすでにアドレスで指定されていればネットワーク範囲で判定できますが、ドメインしかなく、利用可能なアドレスがまだないリクエストを、このルールが自ら名前解決して対象にすることは期待できません。ローカルネットワークのアドレスを指定する例では、不要な名前解決を避けるためによく使われます。

ドメインの名前解決後のアドレスに応じて振り分けたい場合は、no-resolveを追加するとマッチ条件が変わる可能性があることを理解してください。トラブル対処では、このオプションを何度も付けたり外したりするより、「使用できるアドレス情報がある場合」と「ない場合」のリクエストを比較すると役立ちます。アドレスルール用のオプションを、DOMAINやFINALの行にそのままコピーしないでください。ルールごとに必要な項目は異なります。

GEOIP：アドレスの地域情報に基づく判定

GEOIPはIPアドレスの地域情報に基づいて判定します。たとえば次の例のCNは地域コードです。サイトの表示言語、企業の所在地、ドメインの末尾から判断するものではありません。サービスが分散して運用されている場合、解決されたアドレスの地域が利用者の予想と異なることがあります。地域データが最新でない場合もあります。特定の例外を安定して適用するには、地域ルールにサービスの識別を任せず、明確なドメインルールを先に置いてください。

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

この例では、api.example.comへの明示的なポリシーを先に適用し、それ以外の接続に地域判定を行います。先に例外を指定していない場合、このドメインが地域条件に合うアドレスに解決されると、DIRECTになる可能性があります。設定が意図どおりかどうかは、実際にマッチしたルールと接続先アドレスを確認してください。サイト名だけでは判断できません。アドレスデータベースに関連する動作は、アプリで現在利用できるデータと設定もあわせて確認しましょう。

IP-CIDR6とUSER-AGENTの注意点

IP-CIDR6はIPv6のネットワーク範囲を指定します。次のアドレスはドキュメント用の例であり、プレフィックスの書き方を示すものです。実際のサービスアドレスとしては使用できません。IPv4ルールがIPv6の接続先に自動的に適用されることはありません。接続が実際にIPv6を使っている場合は、必要に応じて個別に対応してください。IPv4ルールがマッチしないからといって、ルール一覧全体が機能していないとは限りません。

[Rule]
IP-CIDR6,2001:db8::/32,PROXY
USER-AGENT,ExampleClient*,PROXY
FINAL,DIRECT

USER-AGENTは、リクエストから確認できるUser-Agent情報をもとに判定し、ワイルドカードで文字列を指定できます。例のExampleClientは書式を示すための値であり、実在するアプリを意味しません。デバイスにインストールされているアプリ名で判定するものでも、プロセス名で判定するものでもありません。リクエストに該当情報がない、情報を確認できない、クライアントが識別情報を変更した、といった場合は、期待どおりにマッチしないことがあります。

特に暗号化された接続では、通常の振り分け処理でHTTPリクエストヘッダーを読み取れるとは限りません。USER-AGENTルールを使うためだけに、解読の対象範囲を安易に広げないでください。このページの基本的な振り分け例で、そうした処理を追加する必要はありません。通常は、確認・検証しやすいドメイン条件やアドレス条件を優先し、USER-AGENTは前提条件のある補助的な方法として扱いましょう。サービスを判別する汎用的な方法ではありません。

ポリシーと優先順位：先にマッチしたルールを適用

ルールの左側には条件、右側にはマッチした場合のポリシーを記述します。最もよく使われるポリシーキーワードはPROXY、DIRECT、REJECTで、それぞれプロキシ経由、直接接続、拒否を示します。ルールにマッチしても、接続先にアクセスできるとは限りません。マッチした時点で処理方法が決まっただけで、その後サーバーの利用不可、接続先からの拒否、ネットワーク状況などで失敗する場合があります。「適切なポリシーが選ばれたか」と「その経路を利用できるか」は分けて検証してください。

PROXYとDIRECTにはそれぞれ利用可能な接続経路が必要

PROXYは現在選択されているプロキシに応じた経路で通信します。サーバー情報がない場合に、利用可能な接続先を自動で補うことはありません。選択中のサーバーが使えなければ、ルールが正しくても接続は失敗します。DIRECTはデバイスが現在のネットワークから接続先に到達できることが前提で、プロキシより優先される修復方法ではありません。どちらも同じ接続先にリクエストして実際の動作を確認してください。ルールの記述だけで速度や安定性を判断することはできません。

REJECTは、マッチしたリクエストを明示的に拒否します。これは管理上の指定であり、接続に失敗したときの予備ポリシーではありません。広い範囲のドメインをREJECTにする前に、その範囲にログイン、認証、リソース用のAPIが含まれないか確認してください。メインページは開くのに一部の機能が失敗する場合があります。その際は、サーバーの設定を変更する前に拒否ログを確認しましょう。

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

具体的なルールは広いルールより前に配置

ルールは通常、一覧の上から順に評価されます。最初にマッチしたルールのポリシーが適用され、すべての条件を確認してから「最も具体的なルール」が選ばれるわけではありません。上の例では2つの例外を先に処理し、そのほかのexample.comの範囲にサフィックスルールを適用します。サフィックスルールを1行目に移すと、先の範囲が例外の対象もカバーしてしまいます。設定ファイルを読むときは、特定のルールがあるかだけでなく、処理の流れを追うように1行ずつ判断してください。

優先順位を決めるのはキーワード自体ではなく、一覧内の位置です。DOMAINがDOMAIN-SUFFIXより自動的に優先されるわけでも、ドメインルールがアドレスルールより優先されるわけでもありません。メンテナンスしやすくするため、「明示的な例外、サービス範囲、ネットワーク範囲、最終ポリシー」の順に整理できますが、これは管理上の慣習であり、アプリが自動的に並べ替えるものではありません。読み込み後に実際の一覧を確認し、想定した順序になっていることを確かめましょう。

FINALは最終ポリシーであり、自動フェイルオーバーではない

FINALにはドメインやアドレスの条件を指定せず、通常はルール一覧の最後に置いて、前のルールにマッチしなかった場合のポリシーを指定します。「前の接続が失敗したら次を実行する」という指示ではありません。あるルールがPROXYにマッチして接続に失敗しても、次の行にあるDIRECTへ自動的に切り替わることはありません。条件のマッチと接続経路の障害は別の問題です。混同すると、意図どおりに機能しない予備設定になります。

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

この例では、明確に指定した範囲にだけPROXYを適用し、それ以外にはDIRECTを使います。最後の行をFINAL,PROXYに変更すると、どのルールにもマッチしなかった通信はプロキシ経由になります。どちらも意図を明確に表現できますが、すべての状況に当てはまる正解はありません。必要な例外を洗い出し、最終ポリシーを変えた後は、専用ルールのない接続先も再テストしてください。記述済みのドメインだけをテストして終わりにしないでください。

ルールを1行ずつ追って競合を確認

接続先を手作業で確認するときは、実際のドメインとアドレスを記録してから、最初のルールに戻り、「現在わかっている情報が条件に合うか」を順に確認します。最初にマッチした行で止め、その位置とポリシーを記録してください。推測した結果と実際のログが異なる場合は、現在の設定、DNSの結果、既存の接続、接続先の情報が同じかを確認します。この方法で、広いルールによる遮蔽、例外の誤り、最終ポリシーの不足を切り分けられます。

接続先最初にマッチする想定のルール結果
blocked.example.comDOMAIN,blocked.example.com,REJECT拒否
local.example.comDOMAIN,local.example.com,DIRECT直接接続
www.example.comDOMAIN-SUFFIX,example.com,PROXYプロキシ経由

優先順位を表すために同じルールを重複させたり、複数のFINALで処理結果を推測したりしないでください。重複行を削除する前に、ポリシーや追加オプションに違いがないか確認しましょう。統合後は、意味を説明できる順序で1つにまとめます。管理できている状態とは、ルールの数が多いことではなく、よく使う接続先について「なぜこの行にマッチするか」を説明できることです。ポリシーが正しいのに接続できない場合は、同じ条件のルールを重ねず、接続の診断に進みましょう。

HostとURL Rewrite：アドレスのマッピングとURLの処理

[Host]と[URL Rewrite]は、ルールファイル内でよく使われますが、分流ルールを別の形で書いたものではありません。Hostは指定ドメインの名前解決先を変更し、URL Rewriteは式に一致するURLを処理します。接続ポリシーを決めるのはRuleです。変更したい対象が「名前に対応するアドレス」「リクエストURL」「接続先の経路」のどれなのか、先に整理してからセクションを選んでください。複数箇所を変更して結果を説明できなくなるのを防げます。

Hostマッピングには実際に有効な接続先アドレスが必要

次のHostの例では、完全なホスト名をドキュメント用のアドレスにマッピングします。このアドレスは書式の説明用であり、実際のサービスへの接続には使えません。実際に固定マッピングを使うのは、接続先アドレスを把握し、そのホスト名でサービスが応答することを確認でき、アドレスの変化も管理できる場合に限ってください。共有ホスティング、負荷分散、サービスの移行によって、固定したアドレスが使えなくなることがあります。

[Host]
api.example.com = 192.0.2.10

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

Hostの行ではDIRECTやPROXYを指定しません。例では接続ポリシーをRuleセクションで決めています。マッピングが成功しても、ポリシーが正しいとは限りません。ドメインが指定アドレスに解決されても、接続先がそのホスト名に対応するサービスを正しく提供し、証明書もアクセス時のホスト名と一致している必要があります。証明書やホスト名のエラーが起きた場合は、マッピングを元に戻して接続先を確認してください。アドレスの選択ミスを、検証要件を緩めて隠そうとしないでください。

ドメインに以前は接続できたのに、固定マッピング後に失敗する場合は、まず該当するHostの行を削除するか元に戻し、同じ条件で再試行してください。サービスのアドレスが変わった可能性や、ネットワークから異なる到達可能なアドレスが返された可能性があります。マッピングの前後の結果を記録すれば、問題がマッピングによるものか判断しやすくなります。継続して管理できないドメインでは、手動でアドレスを固定するより通常の名前解決を維持するほうが、安定しやすい場合があります。

URL Rewriteを構成する3つの要素

URL Rewriteには通常、マッチ式、置換先、処理アクションを指定します。次の例では、指定したドメインのHTTP URLをHTTPSへリダイレクトします。式はURLの先頭からマッチし、括弧でパスをキャプチャします。置換先の$1はキャプチャした内容を参照し、末尾の302はリダイレクトアクションを示します。これは構文を説明する独立した例であり、すべてのサイトに同じルールを追加する必要があるという意味ではありません。

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

式に含まれるドットはエスケープして、ドメインの文字どおりのドットとして扱います。エスケープしないドットは、正規表現ではより広い意味を持ちます。先頭の^はURLの開始位置からマッチさせ、似た文字列を含む別のURLへの誤マッチを減らします。記述した後は、マッチさせたいリクエストだけでなく、マッチさせたくないリクエストもテストしてください。1つの成功例を確認するだけでは不十分です。

リダイレクトはプロキシポリシーの切り替えではない

リダイレクトが発生すると、クライアントは新しいリクエストを送信します。転送後の接続先にも、適用されるルールに基づいた処理が必要です。元の接続をPROXYにするものではなく、サーバーパスワードやプロトコル設定の誤りを直すものでもありません。置換後にホスト名が変わる場合は、元のホストと転送先ホストのルールをそれぞれ確認してください。ルール同士が互いに転送し合う、またはサーバー側の転送とローカル処理が競合すると、リダイレクトループが発生することがあります。まず該当するRewriteを無効にし、対象範囲を絞りましょう。

URLを処理できるかどうかは、プロトコル、リクエスト情報の可視性、関連機能の設定にも左右されます。一般的なHTTPの例から、あらゆるHTTPSのパスを読み取れると考えないでください。暗号化された接続では、パスやリクエストヘッダーが通常の振り分け処理から見えるとは限りません。このページでは、そのための追加の復号機能を有効にする必要はありません。ホスト名で振り分けるだけなら、ドメインルールを優先し、必要な範囲に絞って処理してください。

管理時は各マッピングの解除条件を記録

適切な管理記録には、追加した理由だけでなく、削除するタイミングも必要です。たとえばサービスのアドレスを一時的にテストする場合は、テスト終了後に通常の名前解決へ戻します。サービス移行のためにリダイレクトを追加した場合は、入口が統一された時点で再評価します。解除条件のない一時的な項目は、長期的な障害の原因になりかねません。ファイルを変更する前に、ほかのセクションにも同じドメインがないか検索してください。一か所を元に戻しても、別の箇所でリクエストが変更され続けることがあります。

接続結果が想定と異なる場合は、元のURL、マッピング先アドレス、書き換え後のURL、最終的にマッチしたポリシーを順に書き出してください。想定と異なる項目が1つでもあれば、まずその処理層を確認します。こうすることで、アドレスの古さ、広すぎる式、転送先、ポリシー選択の誤りを切り分けられます。すべての異常を「ルールが効かない」とまとめず、最小限の設定を検証してから複雑な機能を追加しましょう。

設定の読み込みと管理：提供元・選択状態・復元を確認

設定管理で重要なのは、ファイルの数ではありません。現在有効な内容を把握し、更新によって上書きされる箇所を理解し、検証済みの状態に戻せることです。手持ちのサブスクリプションは利用しているサービスの提供元から入手してください。読み込む前に、リンクがサーバー一覧、完全な設定ファイル、その他のデータのどれを提供するものか確認します。読み込み先によって必要な内容は異なります。ブラウザーで開けるリンクでも、使用する読み込み先が解析できる形式とは限りません。

読み込む前にデータの種類を確認

サーバーのサブスクリプションを更新すると、サーバー名、項目数、パラメーターが変わる場合があります。ルール設定を更新すると、ポリシーや順序が変わる場合があります。両者は分けて記録してください。手持ちのサーバーを追加するだけなら、読み込みを成功させるために、すでに検証した設定ファイル全体を置き換える必要はありません。完全な設定ファイルを読み込む場合は、General、Host、Rewriteなどの追加設定が含まれているか確認し、現在のネットワーク動作が変わるか把握しておきましょう。

Configでファイルを管理する場合は、読み込み後に想定した設定ファイルが選択されていることも確認してください。ファイルが一覧にあることと、現在有効であることは別です。複製したファイルを編集しても、実行時にそのファイルへ切り替わっているとは限りません。日常用とテスト用を用途がわかるファイル名で区別し、選択状態も記録しましょう。具体的な読み込み手順はアプリ内の表示を確認してください。初めて使う場合は使い方ガイドも参考になります。

1回の変更を検証できる範囲に絞る

たとえばローカルサービスを直接接続したい場合は、まず完全一致のドメインルールを1つ追加します。DNSの置き換え、ネットワーク範囲の追加、FINALの変更、Rewriteの追加を同時に行わないでください。変数を1つ増やすごとに、説明すべき分岐も増えます。バックアップを取ってから該当セクションだけ変更し、同じ接続先で再試行して、ほかのよく使う接続先に影響がないことを確認します。問題がないことを確認してから、ルールの対象範囲を広げるか判断してください。

# 今回はlocal.example.comの直接接続ルールだけを追加
[Rule]
DOMAIN,local.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,PROXY

コメントには「今回何を変更したか」と「どのように検証するか」を明記し、最適化、修正、高速化のような曖昧な表現だけで済ませないでください。ファイル名、コメント、テスト記録に実際のサブスクリプショントークンを含めないようにします。サブスクリプションのリンクにはアクセス資格情報が含まれていることがあります。トラブル対処のため他人に共有するときは、クエリーパラメーター全体と機密性の高いサーバー情報を取り除いてください。ルールの問題を説明するために、実際の認証情報を公開する必要はありません。

リモート更新とローカル変更は分けて確認

リモート設定を再度更新すると、管理方法によってはローカルの変更が置き換えられることがあります。更新前に独自の項目とその位置を記録し、更新後はルールの順序、最終ポリシー、追加セクションを比較してください。ファイル名が同じだからといって内容も同じとは限りません。ルールが消えたときも、すぐに複数のファイルを再読み込みしないでください。まず更新対象と有効な設定の選択状態を確認してから、必要な独自の内容を戻しましょう。

サーバー項目の名前が変わっていないかも確認してください。ほかの設定で名前を参照している場合、更新後の名称が一致しないと参照が無効になることがあります。このページでは組み込みポリシーを主に扱っていますが、サーバーの選択が想定した項目のままか確認しましょう。読み込みや更新後は、サーバーへの接続、Configモード、ルールのマッチ状況をそれぞれ検証してください。サーバー更新の問題を、ルール構文の問題と取り違えないようにします。

設定の復元と購入・アカウントの状態復元は別

設定ファイルが管理するのはネットワーク動作であり、App Storeでの購入を復元するものではありません。ShadowrocketはAppleプラットフォーム向けの有料アプリで、入手先はApp Storeのみです。購入済み項目の復元については、購入済み項目の復元方法を確認してください。システム要件はApp Storeのページに記載された内容を確認してください。アプリの買い切り購入と通信サービスのプランは別です。アプリを購入しても設定にサーバーが自動追加されるわけではなく、利用できるサービス情報が別途必要です。

デバイスを切り替える前に、引き継ぐ設定とサーバー情報を別々に保存し、機密情報の保存場所も確認してください。システムのバックアップ、アプリ内の読み込み、App Storeの購入済み項目の復元は、それぞれ役割が異なり、互いに代わるものではありません。再インストール後にアプリを開けても、以前のルール、サブスクリプション、選択状態が復元されたとは限りません。古いファイルをまとめて読み込むより、項目ごとに順番に確認するほうが混乱を避けやすくなります。

サブスクリプションの更新に失敗する場合や一覧が空の場合は、まずリンク形式、有効性、サービス提供元の状態を確認してください。解析の問題をRuleセクションの書き換えで解決しようとしないでください。サブスクリプションの更新失敗・サーバー一覧が空の場合の確認手順も参考になります。作業後は直近の検証済みバックアップを残し、使わなくなったテスト用ファイルを整理すると、古い設定を誤って選ぶリスクを減らせます。

検証とトラブル対処：実際にマッチしたルールを確認

ルールの検証では、現在どの設定ファイルを使っているか、Global Routingがどのモードか、リクエストの実際の接続先は何か、どのルールにマッチしたか、最終ポリシーは何か、接続のどの段階で失敗したかを、説明できる形で記録します。「ネットにつながらない」だけでは問題を切り分けられません。まず対象を1つ、テストを1回に絞り、処理の段階ごとに確認してください。設定ファイル全体を何度も置き換えるより、通常は効率的です。

手順1：テスト条件を固定

現在のネットワーク、選択中のサーバー、設定ファイル名を記録し、繰り返しアクセスできる接続先を1つ選びます。テスト中は条件をできるだけ変えず、ネットワーク、サーバー、ルールを同時に切り替えないでください。アプリが既存の接続を再利用する場合があり、設定変更後も、すでに確立した接続にルールがすぐ適用し直されるとは限りません。必要なら対象のリクエストを終了して再送信し、新しい接続ログを確認します。既存の接続結果を新しいルールの結果と取り違えないようにしましょう。

以下の例を使って最小限の比較設定を作れますが、バックアップ内でテストし、例のドメインは実際に管理している接続先に置き換えてください。ルールの数を減らして、マッチした理由を説明しやすくするための例です。日常のすべての通信に使う汎用設定ではありません。最小構成で問題がなければ、元の設定をグループごとに戻します。特定のグループを戻したときに再発する場合は、そのグループの対象範囲、順序、追加設定を重点的に確認してください。

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

手順2：テスト機能の意味を理解する

Connectivity Testは、指定したテスト方法でサーバーに到達できるかを確認するのに役立ちますが、個々の接続先への実アクセスの代わりにはなりません。テストに成功しても、すべてのプロトコル、ポート、リモートサービスが使えるとは限りません。失敗した場合も、テスト方法と実際のリクエストをあわせて確認する必要があります。接続先へのアクセス結果と接続ログの両方を見て、1つのテスト値だけでルール全体が正しいと判断しないでください。

現象まず確認する点次に行うこと
Proxyでは接続できるがConfigでは失敗する現在の設定と最初にマッチしたルールDIRECT、REJECT、名前解決の違いを確認
メインページは表示されるがログインできないログインとAPIの実際のドメイン関連する接続に異なるポリシーが適用されていないか確認
ルールを変更しても結果が変わらない有効なファイル、モード、既存の接続接続を新しく確立し、新しいログを確認
PROXYにマッチしても接続できない選択中のサーバーとプロトコルの設定サーバーへの接続と接続先サービスを分けて検証

手順3：症状に応じた処理層を確認

名前解決に失敗する場合は、ドメインの綴り、DNS設定、Hostマッピングを確認します。接続がタイムアウトする場合は、実際の接続先アドレス、ポリシーの経路、接続先サービスを調べてください。明示的な拒否がある場合は、REJECTルールによる拒否なのか、接続先の応答による拒否なのかを切り分けます。アプリに表示されるサービス側のエラーが、必ずしもネットワークエラーとは限りません。接続先のログイン状態、リクエスト権限、APIの条件が原因となることもあります。証拠を確認せずにネットワーク設定を変更しないようにしましょう。

ページの一部のリソースだけ読み込めない場合は、失敗したリクエストごとにホストとポリシーを確認してください。すぐにすべての通信を同じ方向へ切り替えないでください。同じドメインでもネットワークによって結果が異なる場合は、名前解決結果とアドレスファミリーを記録し、アドレス地域ルールの影響を確認します。更新後にだけ問題が発生する場合は、更新前後の設定内容とサーバーの選択を比較してください。先に差分を特定し、新しいルールを追加するか判断しましょう。

手順4：元に戻す操作もテストする

検証済みの設定に戻して同じリクエストを再試行してください。問題が解消すれば、今回の設定変更を重点的に調べる必要があります。問題が残る場合は、ネットワーク、サーバー、接続先自体を確認します。設定を戻すことは、設定が無効だと決めつけるためではなく、変更の影響を確かめる比較テストです。テストごとの差分を1つに絞り、想定と結果を記録してください。根拠のないまま設定を重ねずに済みます。

問題を報告するときは、画面上のモード、接続先の種類、ルール例、想定したポリシー、実際にマッチしたルールを提示してください。サブスクリプションの完全なリンク、パスワード、トークン、個人のアドレスは取り除き、接続ログ内の無関係なドメインも削除しましょう。ルールを1行だけ切り取るより、最初にマッチした行の前後に必要な情報を残すほうが役立ちます。順序の問題は、その行自体ではなく前方にある広いルールが原因の場合があるためです。

初回の読み込み、許可設定、接続手順を確認し直す場合は使い方ガイドへ、短いQ&Aをまとめて確認する場合はよくある質問へ進んでください。購入方法や正規版の確認はApp Storeで正規版を確認を参照してください。このページは、まず設定ファイルの構成を確認し、次に条件と順序を確かめ、最後に実際の接続で検証する流れです。ルールの数より、動作を説明できることを重視してください。