Shadowrocketのルール・設定ガイド｜Shadowrocket 公式マニュアル

このページはShadowrocket公式マニュアルの設定リファレンスです。初回接続を済ませ、設定の動作を詳しく確認したい方を対象としています。サブスクリプションの初回追加、サーバーの選択、VPN構成の許可については、先に使い方ガイドに沿って基本手順を完了し、必要な章を参照してください。

以下の手順は、ご自身のサブスクリプションまたはサーバー情報をお持ちであることを前提としています。アプリの買い切り購入と接続サービスの契約は別です。ShadowrocketはApp Storeから入手できます。購入の確認方法はApp Storeでの正規版確認をご覧ください。iPhone、iPadのシステム要件はApp Storeの記載をご確認ください。

設定ファイルの構成と編集方法

Shadowrocketの設定ファイルには、ルールと関連する動作設定が記述されています。一般的なテキスト形式の拡張子は.confです。サーバー情報を含むサブスクリプションそのものでも、Homeで現在選択しているサーバーでもありません。ルールを確認する前に、この3つの役割を整理しましょう。サーバー情報は接続先を示し、サブスクリプションは登録済みサーバーの一覧と更新を管理し、設定ファイルはリクエストをどの条件で処理するかを指定します。それぞれを個別に確認すれば、接続経路の問題をルールの誤りと取り違えにくくなります。

設定セクションによって各行の意味が決まる

角括弧で囲まれた見出しが設定セクション名です。たとえば[General]や[Rule]があります。セクション名以降の内容は、次のセクション名が現れるまでそのセクションに属します。Generalにはキーと値の設定、Ruleにはカンマ区切りの照合式、Hostにはホスト名のマッピング、URL RewriteにはリクエストURLの書き換えを記述します。どちらもドメインに関係するからといって、Hostのマッピングや書き換え式をRuleに記述することはできません。解析時には、まずセクションに基づいて行の意味を判断し、次に各パラメーターを読み取ります。

構成例 · 動作設定の全体ではありません

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

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

[Host]
example.com = 192.0.2.10

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

上記の例はセクションの境界を示すもので、全体をそのままコピーすることはおすすめしません。Hostのアドレスは説明用で、実際のサービスへの接続には使えません。書き換え行も構文の例です。実際に変更する際は、現在の問題に必要な箇所だけを取り出し、自分の設定ファイルのコピーに追加してください。ドメインの振り分けだけを検証するなら、HostとURL Rewriteを同時に追加する必要はありません。複数の要因を一度に変えると、結果が変わってもどの変更が影響したのか判断できなくなります。

選択中の設定を確認してから編集する

Configを開いたら、まず現在使用中の設定ファイルを確認してから内容を表示・編集します。リストにファイルがあるだけでは、現在の設定として選択されているとは限りません。同じ名前のコピーが別の保存場所にある場合もあります。設定名、入手元、変更前の重要なルールを記録しておきましょう。保存後はConfigに戻って選択状態を確認してください。編集用コピーを変更しただけなのに、設定を切り替えたと誤認するのを防げます。画面上の項目の位置は、実際の端末に表示される内容をご確認ください。

変更前に復元可能なコピーを保存し、「日常用ルールのコピー」など、用途を区別できる名前を付けてください。数行を記憶しておくだけではバックアップになりません。元のファイルには、ポリシーグループ、ルール参照、DNS関連の設定などが含まれている場合があります。更新される設定を使っている場合は、更新によってローカル編集が上書きされるかを事前に確認してください。リモート更新とローカル保存は同じ操作ではありません。重要な変更は、内容が永続すると決めつけず、更新後にも確認してください。

テキスト形式と設定例の使い方

ルールでは、カンマ、角括弧、等号に半角の英数字記号を使用してください。説明を独立したコメント行に書く場合は日本語の句読点を使えますが、ルールのフィールドに全角の読点が混ざると、本来分かれるパラメーターがひとまとまりとして扱われることがあります。例をコピーしたら、行頭と行末に書式用の引用符や箇条書き番号、見えない空白が含まれていないか確認してください。エディター上で長いルールが折り返されていても、実際の改行とは限りません。ルールは1行につき1件で記述します。

このマニュアルのコードブロックは、独立したセクションの場合もあれば、既存の設定に追加する数行の場合もあります。統合する際は、同名のセクションを繰り返し追加せず、既存の該当セクションを見つけてください。フォールバックルールも一か所にまとめて管理します。元のファイルに追加設定がある場合、このページに出てくる数個のセクションだけを見て、残りを削除してはいけません。既存の設定の用途を理解してから残すか判断すると、「ファイルの整理」によって正常に動作していた設定を壊すリスクを減らせます。

Home、Config、Settingsの役割がまだわからない場合は、画面に表示される英語用語の解説を先にご覧ください。設定編集の目的はファイルをできるだけ短くすることではなく、各セクションの役割を説明でき、変更をいつでも戻せる状態にすることです。現在の設定、変更箇所、検証内容を正確に把握できてから、照合動作を確認しましょう。

GeneralとGlobal Routing

Generalには共通の動作設定があり、Global Routingでは全体的な処理モードを選択します。どちらも接続に影響しますが、設定の階層は異なります。「ルールが適用されない」ときは、まずGlobal Routingを確認し、その後に設定ファイルを調べてください。現在のモードがConfigでなければ、Ruleを何度編集しても期待した結果にならない場合があります。逆に、一時的にモードを切り替えて正常に戻ったとしても、問題の範囲が変わったことを示すにすぎず、サーバーや設定ファイル全体に問題がないとは断定できません。

3つのモードの確認・検証方法

画面上の表示	説明	検証時の用途
Config	Configモード。現在の設定に基づいてトラフィックを振り分けます。	ルールの条件、順序、ポリシーを検証します。
Proxy	Proxyモード。主なリクエストをプロキシ経由で処理します。	Configと比較して、振り分けの問題範囲を絞り込みます。
Direct	Directモード。主なリクエストを直接接続で処理します。	現在のネットワークから直接アクセスした場合の状態を確認します。

表では「主なリクエスト」としています。システムのバイパス、ローカルネットワークの条件、クライアントのほかの設定も個々の通信に影響するためです。Global Routingは、システムのあらゆる動作を一律に上書きする機能でも、接続のオン・オフを切り替える設定でもありません。Proxyに切り替えても、利用可能な既存サーバーが必要です。Directにしても、現在のネットワークから目的の接続先に必ずアクセスできるとは限りません。比較する際は、同じ接続先、同じネットワーク、近い時間帯で試し、外部環境の変化をモードの違いと混同しないようにしてください。

Configモードでは、画面上のConfigと設定セクション[Rule]の両方が振り分けに関わります。一方、ルール末尾のPROXYは、そのルールに指定されたポリシーです。名称は関連していますが、互いに置き換えられません。ルール末尾にConfigと書いても、「設定に従って処理する」という意味にはなりません。同様に、画面でProxyを選択していても、特定のPROXYルールに実際に一致したとは限りません。全体のモードと個々の接続の処理結果を、それぞれ確認してください。

よく使われるGeneral設定を2つ確認する

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

bypass-system = trueは、システム関連のバイパス動作を有効にする設定です。接続処理の境界に関わるもので、特定のドメインに対するポリシーの代わりではありません。既定値を維持する場合、通常の通信の振り分け理由は、まずRuleで確認してください。システム通信や特定のネットワークサービスへの影響が疑われる場合に限り、バイパス設定を検証項目に加えます。安易に切り替えると複数のリクエストが同時に変化し、問題を再現しにくくなることがあります。

dns-server = systemは、システムが提供するDNS設定を使用することを示します。systemは値であり、任意の日本語に置き換える説明用の語ではありません。システムDNSの結果は、Wi-Fi、モバイル通信、その他のシステムネットワーク設定によって変わる場合があります。そのため、ネットワークを変えた後に同じ設定でも名前解決の結果が変わるのは、必ずしもルール内容の変化が原因とは限りません。元の設定で別のDNSが指定されている場合は、まず値を記録し、システムDNSを試す必要があるか検討してください。

設定ファイルを完成形に見せるために、理解していないGeneralパラメーターを大量にコピーしないでください。設定項目には相互の依存関係がある場合があり、入手元の異なる設定例は同じ問題に対して異なる前提を置いていることもあります。動作している基本設定は維持し、具体的な症状に沿ってパラメーターを1つだけ変更し、その理由を記録する方法が確実です。端末上に関連する項目がある場合は、アプリ内設定と現在の設定ファイルの両方を確認してください。ファイルに特定のキーがあるかどうかだけでは、実際の動作を判断できません。

接続スイッチ、On Demand、ルールは別の機能

On Demandは条件に応じて接続を開始する機能で、ドメインルールの代わりにはなりません。接続が確立していない状態でRuleへのドメイン一致を調べても、許可や起動の問題は解決しません。接続済みなのに目的の通信が異なる経路を通る場合も、On Demandを何度も変更してルールの順序を修正することはできません。まずVPN構成の許可、接続状態、現在のネットワークを確認してから、個々のリクエストの処理を調べてください。「接続がいつ有効になるか」と「接続中の通信にどのポリシーを適用するか」を分けて考えられます。

初回接続時に表示されるシステムの確認画面とルールファイルは、別の設定レイヤーです。詳しくはVPN構成の許可画面についてをご覧ください。バックグラウンドで頻繁に接続が開始される、またはバッテリー消費が変わった場合は、On Demandとバッテリー使用量を確認してください。あらゆるバックグラウンド動作をRuleの削減で解決しようとせず、問題のレイヤーに合った情報を確認しましょう。

Generalの確認後、現在のネットワーク、設定ファイル、Global Routing、選択中の既存サーバー、On Demandの有効・無効を明確に記録してください。以降のルール検証では、この条件を変えずにテストします。条件をそろえることで、追加したルールとアクセス結果の関係を説明できるようになります。

DOMAIN系のドメインルール

ドメインルールは、接続に関連付けられたホスト名に基づいてポリシーを選択します。ページタイトル、アプリ名、アドレスバーのURL全体を照合するわけではありません。ルールを書く前に、対象が特定のホスト名なのか、ドメイン全体なのか、名称に特定の文字列を含むホスト群なのかを決めてください。それぞれDOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORDが適しています。条件が広すぎると無関係なリクエストまで対象になり、狭すぎるとページの入口だけに一致して、実際のコンテンツ読み込みに使われる別のドメインを見落とす可能性があります。

DOMAIN：特定のホスト名だけを指定

[Rule]
DOMAIN,api.example.com,PROXY
DOMAIN,static.example.com,DIRECT

1行目はapi.example.comだけに適用され、example.comやv2.api.example.comには自動的に適用されません。2行目は、同じ親ドメイン配下のホスト名ごとに異なるポリシーを設定できることを示しています。厳密なルールは、すでに確認できている例外に適しています。たとえば、ほとんどのリクエストは同じ経路を使い、特定のホストだけ別に処理したい場合です。フィールドにはプロトコル、パス、クエリパラメーター、ポートを付けないでください。これらはDOMAINに指定するホスト名の一部ではありません。

ログに想定と異なるホスト名が表示される場合は、まずリダイレクトとリソースの読み込み状況を確認してください。URLを入力した後、ページがログイン、画像、API用の別ドメインにアクセスすることがあります。入口のホストにDOMAINルールを追加しても、関連するすべてのリクエストに一致するわけではありません。対象を広げるのではなく、まず失敗したリクエストのホスト名を確認し、その関連性を説明できる場合に限ってルールを追加してください。

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

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

DOMAIN-SUFFIX,example.com,PROXYは、example.comとそのサブドメインに一致します。単純な文字列検索ではなく、ドメインの境界に基づいて判定するため、DOMAIN-KEYWORDとは対象範囲が異なります。この例では、local.example.comにDIRECTを適用する例外を先に置き、その後に後方一致ルールを置いて、それ以外の対象ホストにPROXYを適用しています。後方一致ルールを先に置くと、先に一致した時点で処理されるため、通常は個別の例外が適用されません。

サフィックスルールに*.を付ける必要はなく、正規表現として書くものでもありません。example.com/pathと記述しても、「このパスだけを処理する」という意味にはなりません。ドメインとパスは別の照合対象です。無関係な親ドメインが複数ある場合は、短すぎるサフィックスでまとめず、別々のルールを記述してください。実際のドメイン境界に沿ったルールであれば、ログから動作を説明しやすくなり、ほかのサービスへの意図しない影響も抑えられます。

DOMAIN-KEYWORD：ドメイン名の一部に幅広く一致

[Rule]
DOMAIN-KEYWORD,example,PROXY

DOMAIN-KEYWORDは、ドメイン名に指定した文字列が含まれるかどうかで照合します。この例はexample.comだけでなく、exampleを含む別のドメインにも一致する可能性があります。DOMAIN-SUFFIXの短縮形として使わないでください。キーワードが短いほど、対象範囲を予測しにくくなります。1つの組織が管理するドメイン群が対象なら、まず特定のホスト名またはサフィックスを検討してください。異なるドメインに共通する文字列を対象にする必要がある場合に限り、キーワードルールを検討します。

ルールタイプ	適用条件	主な確認点
`DOMAIN`	特定のホスト名。	実際に失敗しているサブドメインを見落としていないか。
`DOMAIN-SUFFIX`	親ドメインとそのサブドメイン。	前に個別の例外ルールを置く必要があるか。
`DOMAIN-KEYWORD`	ドメイン名に指定した文字列が含まれる。	ほかのドメインまで意図せず対象にならないか。

ドメインルールの照合には、クライアントが接続に関連するホスト情報を取得できることも必要です。アプリがIPアドレスを直接使用する場合や、記録に接続先アドレスしか表示されない場合は、ドメインルールに照合できる情報があるとは限りません。まず接続記録で確認できる情報を調べ、必要に応じてアドレスルールを検討してください。同じドメインを別の書き方で何度も追加する必要はありません。名前解決後のアドレスと元のドメインが、常に1対1で対応するわけでもありません。

ドメインルールを検証する際は、対象が明確なホストを選び、古いページを閉じて新しいリクエストを発生させ、その処理ポリシーを確認してください。ブラウザーのキャッシュ、アプリの接続再利用、バックグラウンドリクエストが古い結果に影響する場合があります。新しく発生した対象接続が期待どおりのポリシーを使って初めて、そのルールを検証できたといえます。ページ全体を開けることだけでは、ルールの対象範囲が正しいとは確認できません。

IP、GEOIP、リクエスト条件

アドレスルールは、接続先IPまたはアドレスの地域情報を条件にします。特定のネットワーク範囲、IPアドレスを直接使用する接続、ドメインルールで分類されない後続の通信に適しています。ドメインルールを別の形で書いたものではありません。1つのドメインに複数のアドレスが割り当てられることがあり、同じアドレスで複数のドメインが使われる場合もあります。アドレスだけで振り分けると、同じアドレスを共有する別のサービスにも影響する可能性があります。明確な要件はまずドメインで表現し、必要に応じて適切な位置にアドレスルールを追加すると、範囲を管理しやすくなります。

IP-CIDR：文字列ではなくプレフィックスで範囲を指定

[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

CIDRのスラッシュ後の数字はネットワークプレフィックス長を示し、ポート番号やアドレス数ではありません。プレフィックスが長いほど、通常は対象範囲が狭くなります。例には一般的なプライベートIPv4ネットワークを挙げていますが、お使いのローカルネットワークがそのすべてを使用するという意味ではありません。ルールを書く前に、端末のネットワーク情報で実際の環境を確認してください。特に組織のネットワークや個人用VPNに接続している場合、対象アドレスが現在のWi-Fiのローカルネットワークに属さないことがあります。

単一のIPv4アドレスには、単一アドレス範囲を示す/32を使用できます。1つの接続先を迂回するためにプレフィックスを長い値から極端に短くしないでください。多数のアドレスの処理が同時に変わります。ローカルデバイスの検出に失敗する場合は、デバイス検出に使われる通信と、その後のデバイスへの接続を分けて確認してください。プライベートネットワークのルールを1つ追加するだけでは、あらゆるローカル検出機能が期待どおりに動作するとは限りません。

IP-CIDR6とno-resolveの適用範囲

[Rule]
IP-CIDR6,fd00::/8,DIRECT,no-resolve
IP-CIDR6,2001:db8::10/128,DIRECT,no-resolve

IP-CIDR6はIPv6アドレス用で、IPv4ルールでは代用できません。2行目は説明用アドレスを使い、単一アドレスのプレフィックス指定を示しています。端末がIPv4とIPv6の両方を利用できる場合、同じ接続先への通信でも異なるアドレスファミリーが使われることがあります。IPv4ルールだけを設定してIPv6を確認しないと、「ルールが適用されるときとされないときがある」ように見える場合があります。名前解決の結果にどのアドレスが表示されるかだけでなく、実際の接続記録に基づいて判断してください。

no-resolveは、このアドレスルールへの照合のために追加で名前解決することを避ける設定です。システムのDNSを停止する機能でも、アプリの名前解決を防ぐ設定でもありません。接続先をIPで指定している場合は、そのアドレスを直接照合できます。ドメイン名しかなく、利用可能なアドレス情報もない場合、このオプションによってルールが期待どおりに一致しないことがあります。「既知のアドレスで判定する」のか、「名前解決してから判定する」のかを明確にして検証してください。

GEOIP：言語ではなくアドレスの地域分類で照合

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

GEOIPは地理データベースで分類された接続先アドレスに基づいて照合します。CNはこのルールで使用される地域コードです。ページの言語、ドメインの末尾、組織名から照合結果を推測するものではありません。コンテンツ配信ネットワークのアドレス振り分けは変わることがあり、データベース上の分類が想定と異なる場合もあります。特定のホストに固定のポリシーを適用するなら、明示的なドメインルールをGEOIPより前に置き、名前解決が想定した地域になることに依存しないでください。

no-resolveを付けたGEOIPルールも、利用可能なアドレス情報に制約があることを理解して使ってください。一致しない場合は、まず対象IPとドメイン情報を確認できるか調べ、その後でデータベース上の分類を確認します。GEOIPとFINALをむやみに入れ替えても解決しません。FINALはフォールバックとして末尾に置くルールです。GEOIPより前に置くと、後続のルールが通常どおり照合されなくなります。

USER-AGENT：確認可能なHTTP情報に基づくルール

[Rule]
USER-AGENT,ExampleClient*,DIRECT

USER-AGENTの条件はHTTPリクエストヘッダーに基づき、端末に表示されるアプリ名ではありません。例では架空のヘッダープレフィックスを使ってワイルドカード照合を示していますが、実在する特定のアプリを識別するものではありません。暗号化された接続では、クライアントがこの情報を読み取れない場合があります。そのため、すべてのリクエストに使えるアプリ単位の振り分けルールとして扱わないでください。ヘッダーはアプリの更新やリクエストの種類によって変わることもあるため、長期的に安定しているか個別に検証してください。

ルールの種類は、確認できる根拠に応じて選びます。ホスト名がわかっている場合はドメイン、アドレス範囲が明確な場合はCIDR、アドレスの地域分類が必要な場合はGEOIPを使います。USER-AGENTは、リクエスト内容を確認でき、条件が安定していると確認できた場合に限って検討してください。観察できる情報に合わせてルールを選べば、結果を説明できないまま異なる条件を何度も試す事態を避けられます。

ポリシー、照合順序、FINAL

ルールは通常、タイプ、照合値、ポリシーで構成されます。FINALには通常の照合値は必要ありません。タイプは何を確認するか、ポリシーは一致した後にどう処理するかを示します。このページでは基本ポリシーとしてPROXY、DIRECT、REJECTを扱います。これらはGlobal Routingの画面上のモードとは別の階層です。ルールを読むときは、まず条件、次に結果、最後にそのルールが実際に適用される可能性があるかを確認してください。期待するポリシー名をファイル内で検索するだけでは不十分です。

PROXY、DIRECT、REJECTの意味

ポリシー	処理内容	追加で確認する項目
`PROXY`	プロキシ経由で接続する。	現在使用しているサーバーと接続パラメーター。
`DIRECT`	直接接続する。	ローカルネットワーク、名前解決の結果、接続先への到達性。
`REJECT`	一致した接続を拒否する。	条件の対象範囲が広すぎないか、関連するリクエストに影響しないか。

PROXYを指定しても、利用可能なサーバー情報が自動で作られるわけではなく、接続先への接続が成功する保証もありません。ルールに一致していても、サーバーに到達できない、プロトコルパラメーターが一致しない、リモート側から接続先にアクセスできない、といった理由で失敗することがあります。DIRECTも「必ず成功する」ポリシーではなく、直接アクセスを選択するだけです。REJECTは接続を明示的に拒否します。判断できない場合に使う一律の代替策ではありません。認証やAPIのリクエストを誤って拒否すると、アプリ全体に不具合があるように見えることがあります。

既存の設定に名前付きポリシーグループが使われている場合もあります。ルール末尾がこの3つのキーワードでない場合は、元の設定に戻り、名前の定義と現在の選択状態を確認してください。グループ名をPROXYに置き換えたうえで、元の選択ロジックが維持されると考えてはいけません。別の設定からグループ名だけをコピーしても、参照先となる定義がなければ使えません。スペル、空白、名前の不一致が参照エラーの原因になる場合もあります。

最初に一致したルールが優先され、「より具体的」でも自動で優先されない

[Rule]
DOMAIN,local.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

通常のルールは記載順に確認され、先に一致したルールが適用されます。この例では、個別の例外をサフィックスルールより前に置き、次にプライベートネットワークとアドレス分類を処理し、最後にフォールバックを設定しています。あらゆる環境に適用できる固定テンプレートではなく、読みやすい並べ方の例です。広い範囲に一致するサフィックスを先頭に置くと、後ろにDOMAINの個別ルールがあっても、「より具体的」という理由で優先されることはありません。

アドレスルールとドメインルールの間にも、順序による影響があります。広範囲に一致するアドレス条件を前の方に置くと、後続のドメイン例外が適用されない場合があります。逆に、ドメインが先行ルールに一致すれば、そのアドレスがどの地域に属するかは、その時点で通常のルール処理を左右しません。トラブル対処では、ファイルを上から確認し、最初に条件を満たすルールを探してください。追加したルールだけを確認しても解決にはなりません。

重複ルールは原因を見えにくくします。同じ条件に異なるポリシーを指定したルールが2つある場合、後のルールが想定どおり適用されるとは限りません。重複を削除する前に、管理領域や自動更新される設定元が異なるか確認し、どの箇所を修正するか決めてください。大きな設定では、広範囲のルールを一時的に除外するため、特定条件のテストルールを前方に置いてもかまいません。テスト後は元の構成に戻し、説明できない優先順位の変更を残さないようにしてください。

FINALはフォールバック。PROXYを必ず指定する必要はない

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

この例では、example.comに一致するリクエストにPROXYを適用し、それ以外はDIRECTにします。最終行をFINAL,PROXYに変更すると、前のルールに一致しないすべての通常リクエストの処理が変わります。どちらも要件に応じて使えますが、まず既定の接続経路を明確にしてから例外を追加してください。例でPROXYがフォールバックに使われていても、自分の設定全体のアクセス方針をそのまま変更しないでください。

FINALは通常のルールの末尾に置き、フォールバックが一か所に明確にまとまるようにしてください。その後にDOMAINやGEOIPを追加すると、前のルールで通信が処理されてしまい、「保存はできたのにルールが適用されない」状態になることがあります。ファイルの末尾は特に注意して確認してください。複数の設定例をコピーすると、ある例のFINALが途中に残り、その下に新しいルールを追加してしまうことがあります。

ルールが意図どおりなのにアクセスできない場合は、同種のルールを追加し続けず、接続経路の確認に切り替えてください。手順は接続失敗時の確認手順をご覧ください。ルールは選択された経路の理由を説明し、接続の確認はその経路が成功または失敗した理由を明らかにします。分けて考えると、再現可能な結論を得やすくなります。

HostマッピングとDNSの確認

Hostはホスト名とアドレスの対応を指定し、Ruleは接続に適用するポリシーを決定します。互いに代用できません。ドメインを特定のアドレスにマッピングしても、DIRECTで接続する指示にはなりません。ドメインにPROXYを指定しても、名前解決後のアドレスが固定されるわけではありません。トラブル対処では、「リクエストのホスト名」「実際の接続先アドレス」「適用されたポリシー」を分けて記録し、どのレイヤーにずれがあるか確認してください。ページが開くかどうかだけでは、これらの違いを区別できないことがあります。

Hostの基本的な書き方と適用範囲

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

左側にマッピング対象のホスト名、右側に指定するアドレスを記述します。ここにあるアドレスは説明用で、接続可能なサーバーを示すものではありません。Hostの項目にはRuleの3フィールド形式を使わず、末尾にPROXYやDIRECTも追加しません。追加後は、アドレスを固定する必要があるか、対象サービスの管理者がそのアドレスを明示しているか確認してください。ある時点で取得した結果だけを根拠に、動的に変わるサービスを長期間1つのアドレスに固定しないでください。

固定マッピングを設定すると、通常の名前解決で行われる動的な選択の一部が使われなくなります。コンテンツ配信、負荷分散、フェイルオーバーを利用するサービスでは、地域、ネットワーク、時間によってアドレスが変わる場合があります。以前のマッピングが一時的に有効でも、その後タイムアウト、証明書エラー、一部リソースの読み込み失敗につながることがあります。このような場合はHostの該当項目を確認し、いったん通常の名前解決に戻して比較してください。ドメインの振り分けルールをすぐ追加する必要はありません。

Hostは、リクエストに含まれるすべての識別情報を変更する設定ではありません。HTTPSでは、証明書の検証はリクエストしたホスト名にも関連します。IPアドレスを指定しても、任意のサイト証明書を受け入れることにはなりません。証明書エラーが発生した場合は、接続先ドメイン、マッピング先アドレス、端末の時刻を確認してください。信頼要件を下げてマッピングの問題を隠さないでください。根拠が不十分であれば、変更範囲を広げるよりマッピングを元に戻すほうが、元の状態に復旧しやすくなります。

DNSとルールの関係

DNSは名前をアドレスに変換します。ホスト情報を取得できる場合、ドメインルールは名前に基づいて照合し、アドレスルールには対応するアドレス情報が必要です。両者は密接に関係しますが、すべての接続で同じ順序、同じ情報が外部から確認できるわけではありません。アプリやシステムのキャッシュ、プロキシ経由の名前解決方法が、確認できる結果に影響する場合があります。そのため、「システムで調べたアドレス」と「今回の接続で使われたアドレス」は分けて記録してください。

[General]
dns-server = system

[Rule]
DOMAIN,api.example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
FINAL,DIRECT

この例は判定の階層を示します。1行目は特定のドメインに基づいて処理し、2行目はアドレス情報を取得できる場合に限り、例示したネットワーク範囲を照合し、最後にフォールバックを適用します。DNSの問題を一律に解決する設定例ではありません。api.example.comが1行目に一致した場合、例示用ネットワークのアドレスに解決されたからといって、2行目のポリシーが適用されるとは限りません。逆に、リクエストがホスト名を伴わずIPアドレスを直接使用する場合は、照合の流れが異なることがあります。

名前解決の問題を分けて確認する

すべてのドメインにアクセスできず、既知のアドレスへの接続結果が異なる場合は、現在のネットワークの名前解決機能、GeneralのDNS設定、Hostによる上書きの有無を確認してください。特定のドメインだけに問題がある場合は、スペル、古いマッピング、サービス自体の状態、拒否ルールの有無を先に確認します。ページが真っ白だからといって、すぐにDNSの問題と判断しないでください。ページ本体は読み込めても、後続のAPIや認証リクエストで失敗していることがあります。

Wi-Fiとモバイル通信を切り替える際は、ネットワークの変化を記録してください。システムDNS、IPv6の利用可否、ローカルネットワークへのアクセス条件は、ネットワークによって変わることがあります。同じ設定でも結果が異なる場合は、これらの入力条件を確認し、相反するルールを2つ作って無理に「対応」させないでください。比較テストでは違いの原因を特定し、最終的な設定でその違いを説明できるようにします。特定のネットワークで偶然使えたことだけを記憶するためのものではありません。

HostまたはDNSを変更したら、新しいテスト接続を開始してください。既存の接続では、変更前のアドレスが引き続き使われる場合があります。必要に応じて対象アプリを終了してから再度開き、新しいリクエストの記録を確認してください。ページを再読み込みすればすべてのネットワーク状態が更新されるとは限りません。複数の設定を一度に消去して「再起動したら直った」とだけ記録するのも避けてください。変更の順序を残せば、新しい名前解決、古い接続の終了、その他の操作のどれが結果に影響したのか確認できます。

DNSのトラブル対処では、問題のホスト名、発生時のネットワーク、マッピングの有無、実際に使われたアドレス、最終的に適用されたポリシーを確認できる形で記録します。これらの情報が不足している状態でGeneralの別の項目を変更しても、不確定要素が増えるだけです。よくある接続・名前解決の問題は、よくある質問もあわせて確認してください。

URL Rewriteと照合範囲

URL Rewriteは、確認できるリクエストURLを書き換えたりリダイレクトしたりする機能です。Ruleによる接続経路の選択とは別の機能です。Ruleは「接続にどのポリシーを適用するか」を決め、URL Rewriteは「条件に一致したリクエストURLをどう処理するか」を決めます。example.comをPROXY経由にするだけなら、ドメインルールを記述してください。リクエストURLを変更する必要があり、変更後の動作も理解できている場合に限り、書き換えセクションを使います。

リダイレクト式の構成

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

この行は、照合式、置換先URL、処理方法で構成されています。例では一時的なリダイレクトを示す302を使用します。確認可能なリクエストURLが左側の式に一致すると、右側のURLへのリダイレクトが返されます。HTTPSでの可視性や複雑なパスのキャプチャを基本構文の説明に混在させないよう、例ではHTTPと完全なパスを使っています。例示ドメインは説明用で、実際にアクセスしてテストするサービスを示すものではありません。

式の^は先頭、$は末尾に一致させるアンカーです。\.は文字としてのピリオドを表します。エスケープを省略すると、正規表現のピリオドは通常、より広い意味で照合されます。末尾のアンカーを省略すると、追加のパスやクエリを含むURLまで一致することがあります。編集時は記号の意味を一つずつ確認してください。式が「URLらしく見える」だけで、通常のURL文字列と同じだと判断しないでください。

右側のURLも完全かつ明確に指定してください。HTTPをHTTPSに変えても、対象サービスが同じ内容を該当URLで提供するとは限りません。ホスト名やパスの変更は、ログイン状態、クロスオリジンリクエスト、APIの動作にも影響する可能性があります。書き換えで変更できるのは指定されたリクエストの処理であり、対象サービスに存在しないページを作ることはできません。ブラウザーで動作する式でも、アプリがリダイレクトに対応していなければ、そのアプリのリクエストでは失敗することがあります。

複雑な条件を追加する前に対象範囲を絞る

初回のテストでは、すべてのドメインに一致するパターンを避け、1つのホストと1つのパスから始めてください。正確な照合が期待どおりに動作することを確認してから、サブパスやクエリパラメーターを許可する必要があるか検討します。式を広げるたびに、新たに一致するリクエストの種類を列挙してください。クエリを引き継ぐ必要がある場合は、パラメーターを置換先URLにどう引き継ぐか明確にします。自動的にそのまま引き継がれるとは限りません。

正規表現のキャプチャグループ、エスケープ、設定ファイルのテキストは、それぞれ異なるレイヤーの問題です。設定ファイルに直接記述する場合と、同じテキストを別の形式に埋め込む場合とでは、必要なエスケープ処理が異なることがあります。説明ページに表示された二重エスケープを、設定ファイルでも必要なバックスラッシュの数と決めつけないでください。このページのコードは設定ファイルに記述するテキストです。コピー後はエディターで文字単位に確認し、引用符やエスケープをさらに追加しないでください。

同じ書き換えセクションに複数の式を設定する場合は、条件が重ならないようにし、具体的な条件から一般的な条件へ並べてください。RuleのFINALをURL Rewriteに流用しないでください。構文が異なります。既存の設定に複雑な書き換えの組み合わせがある場合は、コピーで該当する組み合わせを一時的に無効にして比較し、対象の式だけを個別に有効にして検証してください。入手元のわからないルールを一度に複数追加して、ページが開くかだけを確認する方法は避けてください。

HTTPS、証明書、リクエスト内容の可視性

HTTPSはリクエスト内容を保護します。ドメイン名がわかるだけで、クライアントが完全なパスを読み取り、任意の書き換えを実行できるとは限りません。リクエストを処理できるかどうかは、実際の機能設定や接続条件にも左右されます。このページの例ではHTTPS復号を有効にする必要はなく、ルールを確認するために証明書をインストールする必要もありません。ドメインによる振り分けで要件を満たせる場合は、影響範囲が明確なRuleを優先してください。

証明書や信頼に関する変更は、個別に影響を評価してください。特に、書き換え式を動作させるためという理由で、入手元を説明できない設定を許可してはいけません。証明書エラー、アプリによる接続拒否、書き換え式に一致しない問題は、それぞれ異なる現象です。まずシステムやアプリに実際に表示されたエラーを記録し、リクエストが処理可能なレイヤーに到達しているか確認してください。そうしないと、可視性の制約を正規表現の誤りと取り違え、照合範囲を広げ続けることになります。

ループやキャッシュによる誤認に注意する

置換後のURLが元の式に再び一致すると、リダイレクトが繰り返される可能性があります。ブラウザーには、何度も転送される、エラーページが表示される、読み込みが終わらないといった症状が現れます。トラブル対処では、開始URL、置換後のURL、置換後のURLも同じ式に一致するかをそれぞれ書き出してください。検証後も条件を十分に絞り、ブラウザーが偶然リクエストを停止することに頼ってループを避けないでください。

リダイレクト結果はアプリにキャッシュされる場合があり、式を無効にしても以前の動作がすぐに消えるとは限りません。新しいリクエストを使ってURLの変化を記録し、必要に応じて対象アプリの既存セッションを終了してください。元の設定に戻した後も問題が続く場合は、キャッシュと接続先サービスの応答を先に確認します。すぐに設定の保存失敗と判断しないでください。元のURLから最終URLに至る各段階を説明できれば、書き換えのトラブル対処は完了です。

設定の検証とトラブル対処の手順

設定のトラブル対処では、すべての項目を繰り返し切り替えるのではなく、現象を説明できる最小限の原因を探します。開始前に、現在のネットワーク、Global Routing、設定名、使用中のサーバー、対象リクエストを記録してください。そのうえで「api.example.comへの新しい接続にはPROXYを適用する」のように、具体的な期待結果を定めます。目標が明確であれば検証も容易になります。「すべて正常に戻る」は最後の確認には使えますが、1つのルールをテストする最初の基準には適しません。

まず接続の基準状態を確認し、ルールはまだ変更しない

最初に、ShadowrocketでVPN構成の許可が完了し、接続を確立できることを確認します。接続自体を開始できない場合は、システムの確認画面と接続状態を先に調べてください。接続は確立するものの、使用中のサーバーに到達できない場合は、サーバー情報とネットワークを確認します。Ruleを判断するのは、基本接続がテスト可能な状態になってからです。Connectivity Testは接続状況を調べる手がかりになりますが、テスト項目が1つ成功しても、すべてのドメイン、すべてのプロトコルのリクエスト、すべてのルールを検証したことにはなりません。

次に、Global RoutingでConfigが選択されていることと、現在使用中の設定が編集したファイルと同じであることを確認します。コピーに保存して元の設定を使い続けていることは、よくある原因です。ファイル内の見分けやすいルールと照らし合わせてから保存し、必要に応じて再接続してください。解析エラーが表示された場合は、ファイルの構文を先に修正します。無効な設定をもとに照合結果を推測してはいけません。

条件、順序、ポリシーを順に確認する

実際のリクエストに関連付けられたホスト名または接続先アドレスが、ルールのフィールドと一致するか確認します。
Ruleの先頭から下へ確認し、先に一致する条件がないか探します。
FINALが後続の通常ルールより前に置かれていないか確認します。
一致したポリシーまたは名前付きポリシーグループと、実際の接続経路を確認します。
新しい接続で再テストし、変更前の記録と結果を比較します。

リクエストのホスト名がルールと異なる場合は、まず照合対象を確認します。ホスト名が一致するのに別のポリシーが使われる場合は、ルールの順序または設定の選択状態を確認してください。ポリシーが正しいのに接続できない場合は、経路と接続先を調べます。このように分岐して確認すると、「接続に失敗したからドメインルールを追加し、それでも失敗したのでDNSを変え、さらにキーワードを広げる」といった繰り返しを避けられます。テストごとに1つの疑問に答え、すべての設定を一度に検証しようとしないでください。

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

この最小構成例は原因の特定方法を示すもので、既存の設定全体を置き換えるものではありません。実際のテストは保存したコピーで行い、広範囲のルールの影響を避けるため、特定条件のルールを一時的に使います。その条件で期待したポリシーが適用されたら、元の設定にあるルール群を少しずつ戻してください。それでも結果が変わらない場合は、リクエスト情報が確認できるか、設定が適用されているか、現在のモードが正しいかを調べます。同じ意味のルールを次々追加するより、信頼できる結論を得られます。

現象を確認可能な種類に分ける

確認できた現象	優先して調べる項目	避けること
編集後も処理結果がまったく変わらない。	現在の設定、Global Routing、保存状態、既存の接続。	同じ条件のルールを続けて追加する。
一致したポリシーは正しいが、アクセスに失敗する。	使用中のサーバー、パラメーター、接続先、ネットワーク。	ドメインルールの対象範囲を広げるだけで解決しようとする。
一部のリソースだけ失敗する。	失敗したリクエストの実際のホスト名と拒否ルール。	入口のドメインがすべてのリクエストで使われると決めつける。
ネットワークを変えると動作が異なる。	システムDNS、アドレスファミリー、ローカルネットワークの条件。	設定ファイルが自動的に変化したと決めつける。

断続的に発生する問題では、成功したときの記録だけでなく、失敗した時刻、ネットワーク、接続先を記録してください。ページによっては以前の接続を再利用し、サービスによっては名前解決結果が変わることがあります。リクエストを繰り返しても、毎回同じ条件とは限りません。記録を確認する際は、テスト操作に対応する新しい接続を基準にし、バックグラウンド同期や別のアプリの通信をテスト結果と混同しないでください。

Dataや関連する診断記録を確認する場合は、対象リクエストに必要な情報だけを収集してください。記録全体には、ドメイン、パス、クエリ内容、個人識別情報が含まれる可能性があります。共有する前に削除してください。他の人に問題を説明する際は、機密情報を除いたルールの抜粋、現在のモード、再現手順を伝えます。設定全体やサブスクリプションURLをそのまま渡さないでください。関係のない記録を大量に共有するより、判断の過程を再現できる情報を示すほうが有用です。

復元、整理、次の確認

原因を確認できたら、解決に必要な変更だけを残し、原因特定のために追加した広範囲のルール、Hostマッピング、書き換え式を元に戻してください。その後、日常的に使うほかの接続先も確認します。特に、例外ルールで保護されていたリクエストに注意してください。最後に、復元可能なコピーを保存し、変更の目的を記録します。設定が更新される場合は、次回の更新後に重要な内容を確認し、ローカルの変更が置き換えられていないか確かめてください。

日常的なインポートと初回接続については使い方ガイドをご覧ください。購入、アプリID、開発者情報の確認方法は正規版の確認方法、一般的な操作についてはよくある質問をご確認ください。このページでは設定の記述方法を解説しています。実際の動作は、使用中の端末で新しい接続を行い、確認可能な記録を一つずつ調べてください。