Shadowrocket
ルール・設定リファレンス

Config、Proxy、Directの役割

ルールを確認する前に、HomeでGlobal Routingを確認してください。設定モードのConfigは、現在の設定にある振り分けロジックに従って処理します。Proxyは主にリクエストをプロキシ経由で処理し、Directは主に直接アクセスします。ProxyとDirectのモードは、Ruleの評価順序を検証するための代替環境ではありません。Proxyで特定のドメインにアクセスできても、そのテスト経路でプロキシ接続が機能している可能性を示すだけで、DOMAIN-SUFFIXの書き方が正しいことの証明にはなりません。

このページのルールの説明は、Global RoutingがConfigに設定され、対象の設定が有効で、接続を再確立していることを前提にしています。画面にSceneも表示される場合は、現在のシーンで実際にどの設定とポリシーが使われているかを確認してください。シーン名そのものをルールとみなさないでください。デバイスによって画面構成が異なる場合があります。現在の画面に表示される選択結果を確認し、「リクエストが最終的にどの処理ロジックを使うか」を明確にしてください。ボタンの位置だけを覚えるのではなく、実際の選択状態を確認することが重要です。

Generalは2つ目のRuleではない

Generalのオプションは、使用するDNSの参照元、特定のアドレスファミリーを処理するかどうか、特定の処理範囲から除外する対象など、基本的な処理環境に影響します。Rule内の条件を1行ずつ評価する仕組みとは異なります。より上位のネットワーク設定ですでに対象リクエストが除外されている場合、Ruleの末尾にそのリクエスト向けのルールを追加しても、期待どおりに動作しないことがあります。トラブルシューティングではGeneralも確認しますが、一般設定を一度にすべて変更しないでください。

たとえば、dns-server = systemはシステムのDNSを使用することを示します。すべてのリクエストが直接接続される、あるいはアクセス先のドメイン名が必ず解決できるという意味ではありません。接続経路はポリシーによって決まり、名前解決で得たアドレスは後続の接続に使われるため、それぞれ個別に確認する必要があります。元の設定にほかのDNSオプションがある場合は、まず設定どうしの関係を理解してください。例に合わせるために既存の設定全体を置き換えないでください。

[General]
dns-server = system

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

この例では、完全なドメイン名api.example.comだけを明示的にPROXYに振り分けます。Configモードでは、この設定を使って最初の条件を確認できます。別のモードに切り替えると、接続方向を見ても2行の評価順序を証明できません。比較テストでは、最初にモードを記録し、同じリクエストを実行してから、元のConfigに戻してください。一時的に切り替えただけでも、その後のルールテストで共通の前提が崩れることがあります。

接続状態と既存セッション

設定を保存した後も、すでに確立された長時間接続が以前の経路を使い続ける場合があります。ブラウザーの接続再利用、アプリのバックグラウンドセッション、名前解決のキャッシュも確認結果に影響します。テストでは対象アプリの既存セッションをできるだけ終了し、必要に応じて接続を切断して再接続してから、新しいリクエストを送信してください。再生中のメディア接続の経路が変わらないからといって、新しいルールが適用されていないとは限りません。ページがローカルキャッシュから表示された場合も、ネットワーク接続に成功したとは判断できません。

Connectivity Testはサーバーの基本的な接続状態を確認するのに役立ちますが、個別のアプリのリクエストと同じテストではありません。サーバーテストに成功しても、対象ドメインの名前解決に失敗したり、サーバー側がリクエストを拒否したりする場合があります。逆に、ページが一部表示されても、関連するすべてのサブドメインに同じポリシーが適用されたとは限りません。ルールを正しく検証するには、テストアイコンだけに頼らず、具体的なリクエストと一致したルールを確認してください。

IP-CIDR：ネットワークプレフィックスで照合

IP-CIDRは、アドレスとプレフィックス長を使ってIPv4アドレスの範囲を指定します。192.168.0.0/16は、16ビットのネットワークプレフィックスで区切られたアドレス範囲を表します。URLが192.168で始まるかどうかを調べるものではありません。通常、プレフィックス長が大きいほど範囲は狭くなります。単一のIPv4アドレスは/32で指定できます。編集前に対象がネットワーク全体か単一のホストかを確認し、サブネットマスク、ポート番号、CIDRプレフィックスを同じパラメーターに混在させないでください。

ローカルネットワーク上のサービスには、通常、ローカルアドレスへの直接接続が必要ですが、例外は実際のネットワーク設定に応じて指定してください。プライベートアドレス範囲をDIRECTにしても、異なるネットワーク間のルーティングが用意されるわけではなく、デバイスやルーターのアクセス制御を自動的に回避するものでもありません。接続するWi-Fiが変わりアドレス範囲が変わると、以前のローカル例外が同じサービスを対象にしなくなることがあります。社内、ゲスト、家庭のネットワークでアドレスが重複する場合もあるため、現在の環境で検証してください。

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

no-resolve：ルール評価のための名前解決を抑制

IP系ルールでは、no-resolveパラメーターを使って、そのルールの照合だけを目的とした追加の名前解決を行わない意図を示せます。対象アドレスがすでに分かっている場合や、アドレス範囲の確認だけのために名前解決を避けたい場合に適しています。「接続全体でDNSが不要」という意味ではありません。また、後続のプロキシ、アプリ、ほかのルールで名前解決が行われないとも限りません。リクエストにアドレスがすでに含まれているか、後続にどの条件があるかによって、実際の動作は異なります。

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

この例では、明確なドメインポリシーを先に置き、ローカルアドレスの例外を後に置いています。リクエストにドメイン名しかない場合、no-resolve付きのIPルールがそのドメインからプライベートアドレスを必ず判別できるわけではありません。リクエストに接続先IPがすでに含まれている場合は、そのアドレスを使って判定できます。アドレス分類のために名前解決を許可するか、ドメインを基準にした処理を優先するか、必要な動作を選んでください。すべてのIPルールに機械的に同じパラメーターを追加しないようにしましょう。

IP-CIDR6：IPv6の範囲を個別に処理

IPv6はIPv4のネットワーク範囲に自動的に含まれません。環境でIPv6を使用している場合は、テスト対象に含める必要があります。IP-CIDR6もCIDR形式で範囲を指定しますが、アドレスにはIPv6表記を使います。例の2001:db8::/32は書式説明用のドキュメント用アドレス範囲であり、実際のネットワークで使用するものではありません。実際のルールには、自分が管理している、または処理が必要だと確認できたアドレス範囲を指定してください。

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

ドメインがIPv4とIPv6の両方のアドレスを返すと、アプリは一方を優先することも、並行して試すこともあります。そのため、一度の成功や失敗だけでは、どのアドレスルールが処理に関与したのか判断しにくい場合があります。使用されたアドレスファミリーと接続先IPをそれぞれ記録し、ルールの適用範囲を確認してください。IPv6経路に問題がある場合は、ネットワークの接続性と設定の対応状況を確認します。アドレスファミリーを任意に無効化することを、あらゆる問題に対する一律の解決策にしないでください。

GEOIP：IPアドレスの地域判定であり、コンテンツの分類ではない

GEOIP,CN,DIRECTは、接続先IPの地理情報をもとに判定します。Webページの言語、サイト運営者、デバイスの所在地を基準にするものではなく、すべてのIPがユーザーの想定どおりに分類される保証もありません。CDN、共有アドレス、サービスの移行により、同じドメインでもネットワークによって異なるアドレスが返ることがあります。そのため、GEOIPに一度一致した結果を、そのサイトのすべてのリクエストに当てはめないでください。

安定したドメインポリシーが必要な場合は、まずドメインの例外を明示し、その後に広範囲なアドレス分類条件としてGEOIPを使う方法を検討してください。分類の違いを調べる際は、その時点で解決されたIP、テストしたネットワーク、一致した行を記録します。「このサイトはこの地域のはず」といった判断だけで済ませないでください。現在使用している地理情報が用途に適しているかも確認しましょう。分類結果は、接続先アドレスやネットワークの到達性を検証する代わりにはなりません。

DNSの結果と振り分け結果は別々に確認

DNSはドメイン名を接続に必要なアドレスへ変換し、Ruleはリクエストに適用する処理ポリシーを決定します。互いに影響することはありますが、同じ設定ではありません。ドメイン名を解決できても接続に失敗することがあり、経路によって名前解決を行う場所が異なる場合もあります。問題を調べる際は、ドメイン名、取得したアドレス、一致したルール、最終的なポリシーの4点を記録してください。「ドメイン名にIPがある」だけでは振り分けが正しいとは言えず、PROXYと表示されるだけでは接続先に到達できるとは限りません。

Generalで指定したDNSの参照元は、名前解決の環境に影響します。システムのDNSを使う場合、結果はWi-Fi、モバイル通信、システムのネットワーク設定によって変わることがあります。別の参照元を指定する場合も、現在のネットワークから利用できるか、設定に別の名前解決オプションがないかを確認してください。テスト結果を得るために、記録を残さずDNS、サーバー、ルール順序を同時に変更しないでください。アクセスできるようになっても、何が有効だったのか判断できなくなります。

Hostは名前とアドレスの対応関係を明示する

Hostは、自分が管理する実験用サービス、固定の内部デバイス、一時的な移行テストにアドレスを指定する場合に適しています。通常はドメイン名、等号、アドレスの順で記述します。ページのパスやプロトコルのパスワードを記述するものではありません。次の例ではlab.example.comをプライベートアドレスに割り当て、そのドメインのポリシーをDIRECTにしています。Hostはアドレスマッピングを、Ruleは接続の処理方向を、それぞれ指定します。

[General]
dns-server = system

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

[Host]
lab.example.com = 192.168.10.20

このアドレスが意味を持つのは、ネットワーク上に該当するデバイスとサービスが実際に存在する場合だけです。マッピングを保存しても、サーバーが作成されたり、別のLANにアクセスするためのルートが追加されたりするわけではありません。接続先サービスがHTTPSを使用する場合は、証明書のドメイン名がアクセス先と一致する必要があります。TCP接続できるアドレスをドメインに割り当てても、TLSの検証に成功するとは限りません。証明書エラーが発生した場合はドメイン名、証明書、サービスの設定を確認してください。検証の無効化をHostの通常の手順にしないでください。

公開サービスのアドレスを固定し続けない理由

公開サービスでは、DNSによって接続先が異なる地域、負荷、アドレスファミリーに振り分けられることがあります。特定のアドレスを手動で固定すると、この振り分けが使われなくなります。一時的に接続できたアドレスが、後で移行されたり、サービスを停止したり、現在のネットワークに適さなくなったりする可能性があります。共有サービスでは、リクエストに含まれるドメイン名を使ってサイトを選ぶ場合もあります。Hostは、理由が明確で検証でき、元に戻せるマッピングに使用してください。トラブルシューティングで見つけたIPを、すべてのデバイスに恒久的に設定するのは避けましょう。

一時的なマッピングが必要な場合は、元のドメイン名、解決結果、置き換えたアドレス、元に戻す方法を記録してください。テスト後はマッピングを削除し、通常の名前解決に戻ったか確認します。古いHost項目が残っていると、ドメイン名が以前のアドレスに明示的に割り当てられたままになり、後からDNSを変更しても効果がないように見えることがあります。こうした問題はGeneralのDNS参照元を変更するだけでなく、まずHostに対象の完全なドメイン名がないか検索してください。

キャッシュとアドレスファミリーによる結果の違い

名前解決のキャッシュは、システム、アプリ、ブラウザー、接続処理フローなど、複数の場所に存在する場合があります。設定を保存してすぐにページを更新しても、以前に取得したアドレスや既存の接続が使われることがあります。マッピング変更前後の結果を比較するには、新しいリクエストセッションを開始し、必要に応じて再接続して、実際の接続先アドレスを確認してください。ページが再表示されるかどうかだけでキャッシュが消去されたと判断しないでください。ページ自体がローカルデータから表示されている場合もあります。

もう1つよくある違いは、IPv4とIPv6が共存することです。IPv4アドレスを1つだけマッピングし、1つのアドレスファミリーしかテストしないと、アプリの接続動作全体を説明できない場合があります。アプリの実際の接続記録から最終的に選ばれたアドレスを確認し、対応する範囲がIP-CIDRまたはIP-CIDR6に含まれるか調べてください。IPアドレスに直接接続するリクエストには変換するドメイン名がないため、通常、Hostのドメインマッピングはトラブルシューティングの入り口にはなりません。

最小限で元に戻せる検証手順を作る

まず現在正常に動作している設定をコピーします。テストする権限のあるドメインを1つ選び、期待するポリシーを記録してから、完全なドメイン名を指定したルールを1つ追加します。関連する広範囲の条件とFINALより前にあることを確認し、保存してコピーを有効にした後、Global RoutingをConfigに設定します。続いて新しい接続を確立し、対象ドメイン、接続先アドレス、一致した条件、適用されたポリシーを確認してください。すべてが期待どおりになった場合に限り、ルールの範囲を段階的に広げるか、通常の設定に統合します。

動作環境を長い新規設定で直接置き換え、大量の問題から原因を推測するのは避けてください。リモート設定では元の取得元とローカルの差分を保存します。更新されるサブスクリプションでは、サーバーデータの変更とルールファイルの変更を区別してください。更新後に問題が発生した場合は、どの項目が更新されたのかを先に確認します。サーバーアドレスや認証情報の変更と、DOMAINの入力ミスは別の問題です。同じルール変更で両方を解決することはできません。

1. 現在のネットワーク、Config名、Global Routing、テスト対象を記録し、元のコピーを保存します。
2. ルールまたはパラメーターを1つだけ変更し、所属セクションと前後のルールによる上書きを確認します。
3. 保存後、変更したファイルが実際に有効になっていることを確認し、新しいテストセッションを開始します。
4. ログに記録されたドメイン、アドレス、ルール、ポリシーを照合します。必要に応じてDirectとProxyを比較の基準として使ってください。
5. Configに戻して結果を記録します。期待どおりでない場合は変更を元に戻し、次の項目を確認します。

現象から原因の範囲を絞り込む

期待したルールの一致記録がまったくない場合は、まずモード、選択中の設定、現在のセッションで実際にリクエストが送信されたかを確認します。次に、ドメインをURLとして入力していないか、前方に広範囲の条件がないか、IPアドレスへ直接接続していないかを調べます。PROXYに一致してもアクセスできない場合は、対象ドメインのルールを追加し続けず、選択中のサーバー、プロトコルのパラメーター、DNS、接続先サービスを確認してください。ルールに一致したかどうかと接続できたかどうかは、別々の結果として記録します。

プロトコルとルールのトラブルシューティングも分けて行います。たとえばTrojanのアドレス、ポート、パスワード、SNIは接続パラメーターです。詳しくはTrojanのパラメーター設定のポイントを参照してください。Hysteria2とネットワークのUDP環境についてはHysteria2とQUICの解説をご覧ください。プロトコルのパラメーターが間違っている場合、ルールに一致しても認証情報を補うことはできません。

診断情報を共有する前に機密情報を削除

問題の説明に必要な最小限の記録には、ルールの抜粋、使用したモード、対象ドメイン、失敗した段階を含めます。サブスクリプション全体は不要です。共有前にサブスクリプションURLのトークン、サーバーのパスワード、識別情報、プライベートネットワーク情報を削除してください。スクリーンショットではアドレスバー、QRコード、通知欄も確認します。example.comなどの例示用ドメインに置き換える場合は、置き換えた箇所を説明しつつ、ルールの順序と構文は残してください。そうしないと、上書き関係を判断できません。

ルールは実際の用途ごとに保守してください。使わなくなったHost項目を削除し、重複するドメインルールを整理し、FINALが最後にあることを確認します。重要な用途については、いくつかのテスト入力を用意しておきましょう。ネットワークを切り替えた後は、LANアドレスとアドレスファミリーを再確認してください。家庭のWi-Fiで一度確認したからといって、あらゆる環境で問題がないとは限りません。ルールが多いほど適用範囲が正確になるわけではありません。それぞれの例外について、目的、入力例、元に戻す方法を説明できることが、長期的な保守につながります。

クライアントの入手方法と利用条件

Shadowrocketはクローズドソースの商用アプリです。iPhone / iPad版はApp Storeで2.99米ドルの買い切り、Mac（Appleシリコン／Intel）、Windows、Android、Linux版は無料です。アプリの買い切り購入と接続サービスの契約は別です。本サイトではサーバーやサブスクリプションを提供、販売、推奨していません。このマニュアルでは、ユーザーがすでに用意した情報の使い方を解説します。iPhone / iPadのシステム要件はApp Storeの掲載内容をご確認ください。各プラットフォームの入手方法とシステムの許可に関する案内は全プラットフォームのダウンロードページにまとめています。その他のプラットフォームのインストーラーは本サイトの/dl/から取得できます。

接続の許可設定とHome画面を改めて確認する場合ははじめにに戻ってください。入手、購入済みアプリの復元、インストールに関するよくある質問はダウンロードに関するよくある質問をご覧ください。ルールの問題を調べる際は、まず現在の状態を保存し、再現可能な最小限の変更でテストします。結果を説明できない場合は変更を元に戻し、原因をさらに絞り込みましょう。一時的な修正を設定に残し続けないでください。