公式ガイド・機能と設定

Shadowrocketの機能
とよく使う設定

まず通信をどの方式で処理するかを決め、次にルール、サーバー、接続条件を確認します。設定の適否は接続スイッチだけでなく、実際のリクエストがどのルールに一致したかで判断してください。

このページでは主にiPhone / iPadでの操作を説明します。画面上の項目名は端末に表示される英語表記を確認してください。システム要件はApp Storeの掲載内容をご確認ください。

通信処理の設定

Global Routingの3つのモード

Config、Proxy、Directで全体の処理方式を選びます。設定ファイルにルールがあっても、現在の通信が必ずルールに従うとは限りません。

概要:Global Routingはルーティング方式を選ぶ画面です。Configは現在有効な設定のルールを使用します。Proxyはクライアントで処理する通信を選択中のプロキシポリシーに渡し、Directは直接接続します。ProxyとDirectは画面上の選択肢で、ルール内のPROXYやDIRECTはポリシーを示すキーワードです。適用される階層が異なります。

場所と設定方法:HomeでGlobal Routingを開き、モードを選択して戻り、現在のサーバーと接続状態を確認します。初めて使うときは、まず登録済みサーバーに接続できることを確かめてください。日常的な振り分けにはConfigを選び、Config画面で有効なファイルを確認します。ファイルをインポートしただけで有効になったと判断しないでください。

画面上の選択肢 処理の基準 利用する場面 確認するポイント
Config(設定) 現在の設定に含まれるルールと対応するポリシー ドメインやアドレスなどの条件に応じて通信を振り分ける場合 ファイルが有効か、ルールの順序、最終的に適用されるポリシー
Proxy(プロキシ) 現在選択中のプロキシサーバーまたはポリシー 振り分けルールの影響を抑えて、プロキシ経由の経路を一時的に確認する場合 サーバー設定、認証情報、対象リクエストへの接続性
Direct(直接接続) 現在のネットワークからの直接接続経路 通常のネットワーク状態との比較や、ローカルネットワークの確認 ローカルネットワークとDNS。プロキシの動作確認には使えません。

注意点:モードを切り替えても、確立済みの長時間接続は以前の状態を保つことがあります。確認するときはリクエストを新たに実行し、必要ならテスト対象のアプリを終了して開き直してください。Proxyは比較テストに便利ですが、Config内のすべてのルールが正しい証明にはなりません。Directでアクセスできても、そのテスト時に直接接続が使えたことを示すだけです。

条件とポリシーを分けて考える

ルール振り分けと評価順序

ルールではまず「何に一致するか」を定め、次に「どう処理するか」を指定します。Configを使う場合は、順序とポリシー名の両方を確認してください。

概要:ルール振り分けでは、リクエストのドメインや宛先アドレスなどに応じて処理ポリシーを選びます。DOMAINは指定したドメイン、DOMAIN-SUFFIXはドメインの末尾、DOMAIN-KEYWORDはドメイン内のキーワードを照合します。IP-CIDRとIP-CIDR6はアドレス範囲に、GEOIPはアドレスの地域情報に基づいて判定します。ルールによって必要な情報は異なり、DNSの解決結果がアドレス系ルールの判定に影響する場合もあります。

場所と設定方法:Configで現在の設定を編集し、[Rule]セクションを確認します。通常、より具体的な条件を前に、デフォルトの処理ルールを後ろに配置します。DIRECTは直接接続、PROXYはプロキシポリシーへの転送、REJECTは拒否を示します。カスタムポリシー名を使う場合は、現在の設定内で有効な名前かも確認してください。

ルール構文の例・完全な設定ファイルではありません

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

指定したドメインサフィックスを先に照合し、その後にローカルネットワークのアドレス範囲を処理する例です。前のルールに一致しない場合は、FINALで後続の処理を決めます。

注意点:ルールは記述順に評価されるため、先にある広い条件が後続の具体的な条件に先回りして一致することがあります。FINALはそれ以前のルールに一致しない場合に使います。後続の照合が必要なルールより前に置かないでください。USER-AGENTなどの条件は、クライアントがリクエスト情報を取得できるかどうかにも左右され、すべての通信に適用できるとは限りません。変更後はルール本文だけでなくDataで実際の判定結果を確認すると、順序の問題を見つけやすくなります。

設定にDNS、Hostなどのセクションがある場合は、リクエストへの影響も合わせて確認してください。特定のページの問題を解決するために設定全体を一度に置き換えるのは避けましょう。まず現在のファイルをバックアップし、関係するルールだけ変更してから、同じ宛先へ再度リクエストして比較します。

接続情報と設定ファイル

サブスクリプションとサーバー管理

サーバー情報には接続パラメーターを、設定ファイルにはルールなどの動作を記録します。サブスクリプションの更新と設定の切り替えは別の操作です。

概要:サーバー情報にはアドレス、ポート、プロトコル、認証情報などの接続パラメーターを保存します。Subscribeでは、利用者が登録したサブスクリプションを管理します。ShadowrocketはShadowsocks、VMess、VLESS、Trojan、WireGuard、Hysteria2、HTTP、SOCKS5などのプロトコルに対応しています。プロトコル名は設定項目の一部にすぎません。同じプロトコルでも、トランスポート、TLS、認証の設定を登録済みサーバー情報と一致させる必要があります。

場所と設定方法:Homeの追加メニューからAdd Serverを開きます。サブスクリプションを利用する場合はSubscribeを選び、自分のサブスクリプションURLと識別しやすいメモを入力します。サーバー情報が1件だけの場合は、該当するプロトコルを選んで各項目を入力してください。QRコードがあればScan QR Codeを使えます。クリップボードから読み込む前に、追加する接続情報が含まれていることを確認しましょう。

インポート後、一覧に目的の項目が表示されたことを確認し、プロトコル、アドレス、ポート、必要なセキュリティ設定をチェックします。次に項目を選んでConnectivity Testを実行し、実際のリクエストも試してください。テストに応答があっても、その条件で結果が得られたことを示すだけで、認証、DNS、ルール、接続先サービスがすべて正常とは限りません。

注意点:サブスクリプションを更新すると、サーバー名、件数、パラメーターが変わることがあります。手動で変更した項目が更新内容で上書きされる場合もあります。手動登録とサブスクリプションは別の名前で管理し、必要な情報を更新前にバックアップして、更新後に現在の選択を確認してください。失敗したサブスクリプションURL、QRコード、接続URL全体をスクリーンショットや投稿で公開しないでください。アクセス認証情報が含まれている可能性があります。

サブスクリプションとルール設定は分けて確認してください。サーバー一覧を更新しても、Configのルールが必ず変わるわけではありません。Configを切り替えても、サーバー情報が更新されるわけではありません。複数のサブスクリプションの整理、共有、バックアップ、削除についてはサブスクリプションとサーバーの管理ガイドをご覧ください。

ネットワーク条件に応じた接続管理

On Demandによる自動接続

On Demandは接続を試みるタイミングを制御し、Global Routingは接続後の通信処理を制御します。両者は互いに置き換えられません。

概要:On Demandは設定したネットワーク条件に応じてシステム経由で接続を開始し、ネットワークを切り替える際の手動操作を減らせます。サーバーの可用性を保証するものでも、通信を振り分けるルールでもありません。接続が開始された後のリクエストは、現在のGlobal Routingと設定に従って処理されます。

場所と設定方法:SettingsのOn Demandを開き、端末に表示される条件を確認します。初めて設定する場合は、現在のWi-Fi環境での接続動作など、確認しやすい条件を1つだけ有効にしてください。保存後に設定画面を閉じ、ネットワークを実際に切り替えて、システムの接続状態とShadowrocketの状態を確認します。想定どおり動作することを確かめてから条件を追加しましょう。

注意点:On Demandを有効にすると、条件を満たした際にシステムが接続を再開することがあります。そのため、手動で切断した後に再び接続状態になっても、スイッチの故障とは限りません。まずOn Demandの条件を確認してください。自動接続を一時的に止める場合は、オンデマンド条件を変更し、Wi-Fiやモバイル通信を切り替えた後に状態を再確認します。一度手動で切断した結果だけで判断しないでください。

テスト環境にほかのネットワーク設定がある場合は、まず現在の状態を記録し、干渉要因を一つずつ切り分けてください。毎回変更する条件を一つに絞り、元に戻せる設定を残しておくと、変化がOn Demand、ローカルネットワーク、サーバー接続のどこに由来するか判断できます。

結果をもとに設定を見直す

Dataの通信量とリクエスト記録

Dataでは、クライアントが処理した接続や通信量を確認できます。問題の判断には、累計値より対象リクエストの詳細が役立つことがあります。

概要:Dataから通信量や接続記録を確認し、リクエストの宛先、適用されたポリシー、関連する接続情報を調べられます。記録されるのはクライアントが取得できたデータです。サービス提供元の請求情報とは異なり、集計値だけでアプリのすべての通信状況を判断することもできません。

場所と確認方法:Dataを開き、利用できる統計範囲と記録画面を確認します。ルールを検証する場合は、テスト時刻を控えてから対象ページを一つだけ開いてください。Dataに戻り、該当するリクエストのドメインまたはアドレスと、表示されたポリシーを確認します。Global Routingの2つのモードを比較する場合は、それぞれリクエストを新たに実行し、結果を別々に記録してください。古い記録を新しいテスト結果と取り違えないようにします。

注意点:1つのページが複数のドメインにアクセスすることがあり、同じアプリがバックグラウンド接続を維持する場合もあります。メインのドメインにPROXYが適用されていても、ページ内のすべてのリソースが同じ経路を通るとは限りません。統計期間、記録の保存範囲、キャッシュも確認結果に影響します。削除する前に、トラブル調査に必要な情報が含まれていないか確認してください。

記録を共有する場合は、問題に関係する項目だけを残し、サブスクリプションURL、認証情報、その他の個人情報を隠してください。状況の説明には、使用したモード、ネットワークの種類、テスト対象、発生手順を含めます。設定全体を公開しないでください。

よく使う項目を確認

Settingsと診断ツール

以下の機能は用途ごとに設定します。現在の端末で項目が表示されない場合は、実際の画面を確認し、別の環境のスイッチ状態を当てはめないでください。

DNS:名前解決と接続を切り分ける

概要と場所:DNSはドメイン名をアドレスに変換します。確認時はSettingsのDNS関連項目だけでなく、現在のConfigにDNS設定が含まれているかも確認してください。一方だけを見て最終的な動作を判断することはできません。

設定方法と注意点:まず現在の値を記録し、名前解決方式と、設定したサーバーに現在のネットワークからアクセスできるかを確認します。「テストは応答するのにページが開かない」場合は、ドメインを解決できるか、解決されたアドレスが妥当か、DNSリクエスト自体がどの経路を通るかを個別に確認してください。名前解決方式、ルール、サーバーを同時に変更せず、既知の設定に戻して一つずつ比較します。詳しくはDNS名前解決の失敗とページが開かない場合の対処をご覧ください。

Test Method:テスト条件を統一する

概要と場所:Test Methodでは、接続テストに使う方法を指定します。Settingsで現在の選択を確認してください。方法によって確認するネットワークの段階が異なるため、結果を同じものとして扱うことはできません。

設定方法と注意点:サーバーを比較するときはTest Methodを統一し、同じローカルネットワークを使ってください。選択した方法でテスト対象が必要な場合は、その設定も確認します。テストの失敗は対象やプロトコルの応答に起因することがあり、すぐにサーバーを削除する必要はありません。テスト時間が短くても、大容量ファイルの転送が速いとは限りません。実際のリクエストで用途を満たすか確認してください。

Today Widget:状態を確認してから操作

概要と場所:Today Widgetでは、システムウィジェットに関連するクイック操作や状態表示を設定できます。Settingsの該当項目を確認してください。表示場所や操作方法は、現在の端末で追加できるウィジェットに応じます。

設定方法と注意点:アプリ内でサーバーを選び、初回接続を確認してから、システムのウィジェット管理画面で利用可能なウィジェットを追加します。操作後はHomeに戻り、実際の接続状態を確認してください。表示がすぐに更新されなくても、ウィジェットの見た目だけで切断や接続成功を判断しないでください。テスト状態を混乱させるような切り替えを繰り返す必要もありません。

iCloud:同期前にコピーを保存

概要と場所:iCloud関連の項目では、デバイス間のデータ保存や同期を設定します。Settingsの該当画面を開き、現在表示されている対象データと操作説明を確認して、同期、インポート、復元で扱われる内容を区別してください。

設定方法と注意点:まず端末のiCloudの状態を確認し、保持したい設定や記録をバックアップしてから、該当する機能を有効にするか操作を実行します。別の端末で結果を確認するときは、Configとサーバー情報を一つずつ確認し、すべてが同期済みだと思い込まないでください。同期は購入履歴の復元とは別です。アプリの入手はApp Storeから行います。上書きや削除の前に、操作の影響範囲を確認してください。

Diagnostics:段階ごとに問題を切り分ける

概要と場所:Diagnosticsは診断機能への入口です。Settingsで端末から利用できるツールと出力内容を確認してください。診断は手がかりを集めるためのものであり、サーバー設定や設定ファイルの確認に代わるものではありません。

設定方法と注意点:まず最小限の手順で問題を再現し、関連する検査を実行します。ローカルネットワーク、DNS、サーバー接続、ルール判定、接続先からの応答の順に確認してください。どの段階で失敗したかを記録し、最後に表示されたエラーだけで済ませないようにします。書き出す前に認証情報や個人情報が含まれていないか確認し、変更前後の結果を比較できるよう残してください。

設定後の確認

一度に変更するのは一つの条件

「接続できるか」「名前解決できるか」「ルールに一致したか」「接続先が応答するか」を分けて確認してください。一度のテスト結果だけで経路全体を判断しないようにします。

  1. 接続情報を確認。Homeで選択中のサーバーを確認し、アドレス、ポート、プロトコル、認証情報が自分の接続情報と一致しているかをチェックします。サブスクリプションを使う場合は、直近の更新で想定した項目が取得できたかを確認してください。
  2. モードを確認。Global RoutingがConfig、Proxy、Directのどれになっているか確認します。ルール振り分けを検証するときはConfigを選び、Configで有効なファイルとルールの順序を確認してください。
  3. テストリクエストを新たに実行。対象を明確にして再アクセスし、古い接続を使い回さないようにします。現在のローカルネットワークとテスト時刻を記録し、サーバー、DNS、ルールを同時に切り替えないでください。
  4. 結果を確認。Dataでリクエストの宛先と処理ポリシーを確認します。接続動作が繰り返し変わる場合はOn Demandを、ドメインの名前解決に問題がある場合はDNSの経路を確認してください。
  5. 元に戻せる状態を保つ。効果があった変更は目的を記録し、改善しなかった変更は速やかに元に戻します。さらに切り分ける場合は、最小限の再現手順と、機密情報を隠した診断結果をまとめてください。

初回インポートから接続確認までの手順ははじめにをご覧ください。登録済みサブスクリプションの整理、更新、バックアップについてはサーバー管理をご覧ください。アプリはAppleプラットフォームのみで提供され、入手先はApp Storeに限られます。購入、互換性、システム要件はApp Storeの掲載内容をご確認ください。

App Storeでダウンロード