Global Routing
リクエスト全体の処理方法を選ぶ項目です。Config、Proxy、Directの3つがあり、それぞれ設定、プロキシ、直接接続に対応します。Ruleの振り分けルールを適用するには、Configが選択されていることを確認してください。モードを切り替えてもサーバーのパラメータは変更されず、無効な認証情報が有効になることもありません。
公式マニュアル · 用語一覧
Shadowrocket 用語集
まず画面上の選択肢、プロトコルのパラメータ、ルールポリシーを区別してから設定を確認しましょう。ここでは用途別に用語を整理しています。カテゴリ名や用語のリンクを選ぶと、該当する説明に移動できます。
[General]
画面とスイッチ
モードはリクエストの処理方法を決め、スイッチは接続動作を制御し、テストは結果の確認に使います。これらは互いに代用できません。
Config
Global RoutingでConfigを選ぶと、Ruleに基づくポリシー選択を含め、現在の設定に従ってリクエストを処理します。一方、画面ナビゲーションのConfigは設定ファイルの管理画面を指します。ルールが適用されない場合は、モードと実際に選択されている設定ファイルの両方を確認してください。
Proxy
Global Routingのプロキシモードです。このモードではリクエストをプロキシ経由で処理し、通常の振り分けルールを1件ずつ適用しません。ルール末尾にある大文字のPROXYとは異なる階層の設定なので、日本語の意味だけで混同しないようにしてください。一時的なテスト後にルールによる振り分けへ戻す場合は、Configに切り替えてアクセス結果を再確認します。
Direct
Global Routingの直接接続モードです。リクエストは現在のネットワークから接続先へ直接アクセスします。直接接続の結果を確認する際に使えますが、現在のネットワークや接続先のサービス、DNSの名前解決にも左右されます。画面上のDirectとルールキーワードのDIRECTは大文字・小文字が異なり、前者は全体モード、後者は個別ルールの処理ポリシーです。
On Demand
On Demandはアプリ内で設定した条件に応じて接続動作を制御します。利用できる条件や選択肢は、現在のアプリ画面で確認してください。On Demandは接続するタイミングを決め、Ruleはリクエストの処理方法を決めます。自動接続や接続状態の変化が起きた場合は、ルールを調整する前にここで設定した条件を確認しましょう。
Add Server
ユーザーがすでに保有しているサーバー情報を入力する画面です。まずプロトコルを選び、手元の情報に従ってアドレス、ポート、認証パラメータを入力します。必要な項目はプロトコルごとに異なり、Typeを変更しただけでは設定が変換されたことになりません。保存後に主要な項目を見直し、コピー時の余分な空白や通信設定の入力漏れがないか確認してください。
Connectivity Test
接続先への到達性を確認する機能です。結果はテスト方法、接続先、現在のネットワークによって異なります。表示される遅延は利用可能な帯域幅を示すものではなく、すべてのWebサイトにアクセスできることを保証するものでもありません。問題を調べる際はテスト結果だけでなく実際のリクエストも確認し、サーバーへの到達、認証の成功、接続先へのアクセス成功を分けて判断します。
DNS
DNSはドメイン名をIPアドレスに変換する仕組みで、多くの場合、接続前に必要となる処理です。名前解決の失敗とプロキシ接続の失敗は別の問題であり、ルーティングポリシーを変更しても名前解決が必ず改善するとは限りません。ドメイン名にアクセスできない場合は、まず名前解決の設定と応答アドレスを確認し、その後、リクエストに適用されたルールを調べてください。
[General]
プロキシプロトコル
プロトコル名は接続の仕組みを表すもので、接続品質を示すものではありません。パラメータは、ユーザーがすでに保有しているサーバー情報に従って入力してください。
Shadowsocks
Shadowsocksでは、サーバーアドレス、ポート、暗号化方式、パスワードなどを指定してプロキシ接続を確立します。暗号化方式はサーバー側と一致させてください。名前が似ている選択肢を任意に置き換えることはできません。手元の情報に追加の通信パラメータが含まれている場合は、アドレスとパスワードだけでテストを始めず、各項目を確認します。
VMess
VMessはユーザー認証の仕組みを備えたプロキシプロトコルです。ユーザー識別子はサーバー側の認証設定と一致させる必要があります。通信方式、TLS、パス、Hostなどが関係する場合もあり、これらの項目は認証情報とはそれぞれ役割が異なります。サーバー情報が一覧に表示されていても、情報が保存されたことを示すだけで、すべての項目が正しいとは限りません。
VLESS
VLESSはユーザー識別子で認証するプロトコルです。通信方式と接続のセキュリティ設定は別途確認します。VMessとは異なるプロトコルなので、どちらもUUIDを使う場合があってもTypeを入れ替えることはできません。設定時はサーバーが指定するパラメータをすべて保持し、入力方法はアプリ内で実際に表示される項目に従ってください。
Trojan
Trojanは通常、TLSで接続を保護し、パスワードで認証します。アドレス、ポート、パスワードに加え、TLSに必要なサーバー名や証明書関連の設定も確認してください。認証情報が正しくてもTLSの検証に失敗すると接続できない場合があります。認証とTLSの各段階を分けて確認しましょう。
Hysteria2
Hysteria2はQUICをベースとし、UDPで通信します。サーバーの認証情報やTLSなどの設定を一致させる必要があります。現在のネットワークで通常のTCP接続ができても、UDPの通信経路が利用できるとは限りません。原因を調べる際はプロトコルのパラメータとネットワークの到達性を併せて確認し、遅延の数値だけで判断しないでください。
WireGuard
WireGuardは鍵で認証します。一般的な設定項目には、鍵、トンネルアドレス、Endpoint、許可するアドレス範囲があります。ここで使う鍵やアドレスは、一般的なプロキシプロトコルのパスワードやサーバーアドレスの代わりにはなりません。診断情報を共有するときは、秘密鍵などの認証情報を隠し、必要な項目名だけを残してください。
HTTP · SOCKS5
HTTPとSOCKS5は異なるプロキシプロトコルです。アクセスするWebサイトの種類ではなく、手元にあるサーバー情報に合わせて選択してください。ユーザー名とパスワードが必要か、保護された接続が提供されているかは、該当する設定で確認します。同じアドレスとポートを使っていても、両方のプロトコルを互換的に使えるとは限りません。
[Rule]
ルールキーワード
ルールの種類は照合する項目を決め、ポリシーは一致した後の処理方法を決めます。以下のドメイン名は構文の説明用です。
DOMAIN
DOMAINは指定したドメイン名に完全一致し、サブドメインは自動的に含まれません。たとえばDOMAIN,example.com,PROXYはexample.comに一致しますが、api.example.comにも一致するとは限りません。ドメインのサフィックス全体を対象にする場合は、DOMAIN-SUFFIXの照合範囲を理解したうえで書き方を選んでください。
DOMAIN-SUFFIX
DOMAIN-SUFFIXは指定したドメイン名とそのサブドメインに一致します。同じドメインサフィックスに属するリクエストをまとめて指定する場合に使います。DOMAIN-SUFFIX,example.com,PROXYはexample.comとapi.example.comを対象にします。特定のサブドメインに別のポリシーを適用する場合は、対象範囲の広いこのルールより前に、より具体的なルールを置いてください。
DOMAIN-KEYWORD
DOMAIN-KEYWORDはドメイン名に含まれるキーワードを照合します。特定の完全なドメインサフィックスに一致するルールではありません。キーワードが短い、または一般的すぎる場合、意図していないドメインまで対象になることがあります。追加する前に照合範囲を検討し、実際のリクエストで一致結果を確認して、広すぎるルールが先にポリシーを決めないようにしてください。
GEOIP
GEOIPはIPアドレスの地理情報データベースの分類に基づいて接続先を照合します。たとえばGEOIP,CN,DIRECTのように記述します。この分類はアドレスデータベースに依存し、Webページの内容、ドメインサフィックス、実際のサービス提供場所を直接判定するものではありません。使用時はDNSの応答アドレスと、それ以前のドメインルールに一致していないかも確認してください。
IP-CIDR
IP-CIDRは指定したIPv4アドレス範囲に一致します。スラッシュの後の数字はネットワークプレフィックス長です。IP-CIDR,192.168.0.0/16,DIRECTは、そのアドレス範囲に直接接続ポリシーを適用する記述です。範囲が広いほど対象も増えるため、ルールを作成する前に対象アドレスを確認し、リスト内の配置も検討してください。
IP-CIDR6
IP-CIDR6はIPv6アドレス範囲の照合に使い、IPv4のIP-CIDRとは分けて記述します。たとえばIP-CIDR6,2001:db8::/32,DIRECTは、文書用のサンプルアドレスを使った構文例です。IPv4ルールだけを設定しても、IPv6リクエストに同じポリシーが適用されるとは限りません。実際の応答アドレスを確認してください。
USER-AGENT
USER-AGENTは、読み取り可能なリクエストのUser-Agentフィールドに基づいて照合します。アプリ名からすべての通信を自動識別するものではありません。暗号化されたリクエストでは該当フィールドを直接読み取れない場合があるため、毎回このルールが使えるとは限りません。追加する前に必要なフィールドを取得できるか確認し、照合条件が適切か判断してください。
FINAL
FINALは、それ以前のルールに一致しなかったリクエストを処理するため、通常はRuleセクションの末尾に置きます。ドメイン名やアドレス範囲の照合値は不要です。一般的な記述例はFINAL,PROXYまたはFINAL,DIRECTです。早い位置に置くと、このフォールバックルールが先に処理し、後続のルールが使われなくなります。
[Rule]
ポリシーと照合順序
英字の大文字・小文字は設定の階層を見分ける手がかりです。画面上の選択肢ProxyとルールキーワードPROXYを混同しないでください。
Rule
設定ファイルの[Rule]セクションでは、照合条件と処理ポリシーをまとめて定義します。一般的なルールは種類、照合値、ポリシーで構成されます。Ruleはサーバーリストではなく、不足している認証情報を補うものでもありません。問題を調べる際は、Global RoutingでConfigが選択されていることを確認し、現在のファイルに記述されたルールを確認してください。
PROXY
PROXYはルールで使うプロキシポリシーのキーワードで、一致したリクエストをプロキシ経由で処理することを示します。実際の接続には、現在選択されているプロキシと有効なサーバーパラメータが必要です。PROXYと書くだけで接続できるわけではありません。これは該当するリクエストの処理方針を決めるもので、Global RoutingをProxyに切り替える別の書き方ではありません。
DIRECT
DIRECTは、一致したリクエストを直接接続で処理するポリシーです。特定のドメイン名やアドレスの処理方法を指定する場合に使います。直接接続でも、現在のネットワークから接続先にアクセスでき、必要な名前解決が完了している必要があります。ルールに一致したリクエストに適用されるもので、クライアント全体をGlobal RoutingのDirectモードに切り替える設定ではありません。
REJECT
REJECTは、一致したリクエストを拒否するポリシーで、指定した範囲へのアクセスを明確にブロックします。通常のページが開かない場合は、必要なドメインが範囲の広すぎる拒否ルールに含まれていないか確認してください。原因を確認せず設定全体を書き換えるのではなく、照合条件を絞るか、より具体的な例外を追加しましょう。
照合順序
ルールモードでは、ルールを上から順に判定し、最初に一致したルールがリクエストの処理方針を決めます。より具体的なルールが自動的に優先されて先頭へ移動することはありません。通常は明示的な例外を先に置き、範囲の広いルールを続け、最後にFINALを記述します。順序を変更した後はリクエストを再送し、新しい照合結果を確認してください。
例外を先に、フォールバックを最後に
次の例ではapi.example.comにDIRECTを適用し、同じドメインサフィックスに属するその他のリクエストにはPROXYを適用します。それ以外のリクエストはFINALで処理します。順序を理解するための例です。実際に使う前に、目的と手元の接続情報に照らして確認してください。
[Rule]
DOMAIN,api.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECTDOMAIN-SUFFIXを1行目に移動すると、api.example.comは先にその行に一致します。後続のDOMAINルールで、すでに決まったポリシーを上書きすることはできません。フィールドの詳細とルール例は設定項目リファレンスをご覧ください。
[Host] / [URL Rewrite]
サブスクリプションと設定ファイル
サーバー情報、ルールファイル、購入履歴はそれぞれ別のものです。いずれかを読み込んだり復元したりしても、他の操作が自動的に完了するわけではありません。
Subscribe
Subscribeは、ユーザーがすでに保有しているサーバーリストを読み込み、更新するために使います。内容は該当するサブスクリプションの提供元によって管理されます。サブスクリプションを更新しても、現在の設定ファイルが切り替わったり、ルールポリシーが変更されたりするわけではありません。サブスクリプションURLにアクセス認証情報が含まれる場合があるため、スクリーンショット、ログ、問い合わせ用の資料ではURL全体と認証パラメータを隠してください。
サーバー情報
サーバー情報とは、接続に必要なアドレス、ポート、プロトコル、認証情報などのパラメータ一式です。一般にノード情報と呼ばれることもあります。サーバーの表示名は識別用のラベルであり、実際の接続方法を決めるものではありません。手元にある情報を入力し、重要な項目を確認してください。インポート手順はクイックスタートをご覧ください。
設定ファイル
設定ファイルにはGeneral、Rule、Host、URL Rewriteなどのセクションがあり、それぞれ異なる役割を担います。サーバーのサブスクリプションは主に接続情報を提供し、設定ファイルはリクエストの名前解決、照合、処理方法を定義します。両者は同じものではありません。編集前に元のファイルを保存し、切り替え後は有効なファイルとGlobal Routingの選択内容を確認してください。
Host
[Host]セクションでは指定したドメイン名にアドレスを割り当てます。変更するのはドメイン名に対応するアドレスであり、PROXYやDIRECTを直接指定するものではありません。誤ったマッピングや古いマッピングによって、リクエストが不適切な接続先に向かうことがあります。その場合、Ruleの記述が正しくてもアクセスできない可能性があります。名前解決に問題がある場合は、ここでのマッピングとDNS設定を併せて確認してください。
URL Rewrite
[URL Rewrite]セクションでは、照合条件に基づいてリクエストURLを処理します。Ruleの接続ポリシーとは役割が異なります。書き換え後の接続先によってリクエストのパスやアクセス結果が変わる場合があるため、通常のドメイン振り分けルールとして扱わないでください。変更前に元のURL、照合範囲、想定する結果を明確にし、必要なリクエスト内容を処理できることを確認します。
iCloud同期
iCloud同期はアプリ内の関連設定と組み合わせて使用します。同期される内容やスイッチの状態は、アプリ内の表示で確認してください。データを同期してもApp Storeの購入履歴は復元されず、機種変更後の接続確認の代わりにもなりません。新しい端末では、サーバーリスト、現在の設定ファイル、ルーティングモード、初回接続に必要なシステム上の許可を確認してください。
購入済み
購入済みは、App Storeで元のアカウントの購入履歴を確認し、アプリを再入手するための入口です。ルールやサーバー情報を復元する機能ではありません。Shadowrocketは主にiPhoneとiPad向けです。その他のAppleデバイスとの互換性、システム要件、ユニバーサル購入の対象かどうかは、App Storeのページに記載された内容をご確認ください。機種変更の手順は購入済みからの復元方法をご覧ください。