OFFICIAL MANUAL / SETTINGS

Shadowrocketの設定と機能ガイド

まずリクエストの判定方法を確認し、次に接続を開始するタイミングを設定します。Global Routing、ルール、サーバー、システムの自動接続、診断の順に確認すると、複数の設定を同時に変更して原因が追えなくなる事態を避けられます。

Config / Proxy / Direct On Demand Data / Diagnostics

本ページはiPhoneとiPadを対象とし、画面上の用語は英語表記のまま記載しています。表示される項目は端末上のShadowrocketでご確認ください。システム要件はApp Storeの掲載内容をご確認ください。

01 / GLOBAL ROUTING

Config・Proxy・Directの3つのモード

概要：Global Routingは、処理対象のリクエストをクライアントがどのように扱うかを決めます。Configは現在の設定にあるルールに従って判定し、Proxyはプロキシ経由、Directは直接接続するモードです。これはリクエストの判定方法であり、プロトコルや速度の設定ではありません。Proxyに切り替えてもサーバーのパスワード誤りは直らず、Directに切り替えてもプロキシサーバーの動作確認にはなりません。

画面：HomeでGlobal Routingを開き、Config、Proxy、Directのどれが選択されているか確認します。接続スイッチはGlobal Routingとは別の項目です。スイッチがオンになっていても、接続状態が変化したことしか分からず、特定のドメインに想定どおりのポリシーが適用されたとは限りません。

モードと画面上の表示	判定方法	確認に適した場面	注意点
設定・Config	現在有効な設定のルールに従ってリクエストを処理します。	通常のルール振り分けや、特定のリクエストの判定結果を確認するとき。	設定が有効になっていることと、ルールの順序や最終ルールが想定どおりであることを確認してください。
プロキシ・Proxy	処理対象のリクエストをプロキシ経由で処理します。	一時的に切り替えて、問題がConfigの振り分けルールに関係するかを確認するとき。	サーバーの設定と接続が有効である必要があります。また、すべてのシステム通信に同じポリシーが適用されるとは限りません。
直接接続・Direct	処理対象のリクエストを直接接続で処理します。	現在のネットワークで直接接続できるかを比較するとき。	プロキシ経路の確認には使えません。また、システムのネットワーク設定をすべて無効にするものでもありません。

順番に切り替えて比較する

現在のGlobal Routing、選択中のサーバー、有効な設定を記録し、元の状態に戻せるようにします。
まずConfigで具体的な問題を再現し、「インターネットに接続できない」だけでなく、対象ドメインとリクエスト結果を記録します。
Proxyだけに切り替え、同じ対象に再度アクセスします。結果が異なる場合は、ルールの一致状況と適用先のポリシーを確認します。
基本ネットワークの状態を確認するにはDirectでも比較します。確認後は元のConfigに戻し、もう一度テストしてください。

注意点：テスト中にサーバーの変更、DNSの変更、設定の書き換えを同時に行わないでください。症状が改善しても、どの変更が影響したのか分からなくなります。実際の動作は設定内の個別処理、システムルーティング、接続先の方式にも左右されるため、モード名だけで一律の動作を判断せず、リクエストの記録とあわせて確認してください。

02 / RULE MATCHING

ルールの種類・順序・ポリシー

概要：ルールは、一致条件と処理ポリシーを結び付けます。DOMAINは指定したドメイン、DOMAIN-SUFFIXはドメインの末尾と関連するサブドメイン、DOMAIN-KEYWORDはドメインに含まれるキーワードを照合します。IP-CIDRとIP-CIDR6はアドレス範囲を対象とし、GEOIPはアドレスの地域情報に基づいて判定します。USER-AGENTはリクエストから該当情報を取得できる場合に使われるため、すべての接続で条件が利用できるとは限りません。

画面：Configで現在有効な設定を確認し、その中のルールを確認します。Homeでサーバーを選択しても、設定ファイルが切り替わるわけではありません。有効になっていない別のファイルを編集しても、現在のリクエスト判定には反映されません。確認前に、対象ファイルとGlobal Routingが想定どおりかを確かめてください。

条件を確認してから、ポリシーを読む

PROXYはプロキシポリシーで処理し、DIRECTは対象に直接接続し、REJECTは一致したリクエストを拒否します。ルールの適用先が設定内のポリシーグループの場合は、グループ内で実際に選択されているポリシーも確認してください。ポリシー名は接続成功を保証するものではありません。PROXYに一致しても、サーバーへの接続に失敗すればリクエストは完了しません。

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

上記は説明用の抜粋であり、設定全体を置き換えて使えるものではありません。最初のドメインルールはexample.comとそのサブドメインを対象とし、GEOIPルールは該当するアドレスの地域判定に使います。FINALは、それまでのルールに一致しなかったリクエストを処理します。example.comは構文の説明用であり、変更が必要な実際の接続先ではありません。

設定方法：まず設定のコピーを保存します。次に、より具体的な例外条件を広い条件より前に置き、最後にFINALを確認してください。用途を明確にしたルールを一度に1つだけ追加し、保存して設定が有効になったことを確かめてから対象にアクセスします。同じ種類のルールがすでにある場合は、重複や先に一致するルールを確認し、末尾に追加し続けないでください。

注意点：ルールは通常、記載順に判定されます。前のルールに一致すると、後のルールは適用されない場合があります。アドレスを使うルールではドメインの名前解決が関係し、解決結果やデータベースの内容によって判定が変わることもあります。REJECTはリクエストを拒否するルールであり、ページ内容を編集する機能ではありません。ログイン、画像などのリソース、APIのドメインを誤って拒否すると、ページが真っ白になる、画像が表示されない、操作に失敗するといった症状が起きることがあります。

詳しく調べるときは、「ルールに一致しない」「誤ったポリシーに一致する」「ポリシーは正しいが接続できない」を別々の問題として切り分けてください。それぞれ確認すべき設定が異なり、ドメインルールを追加するだけでは解決できません。症状に応じてトラブルシューティングガイドを参照し、実際のリクエスト経路を確認してください。

03 / SERVERS & SUBSCRIBE

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

概要：サーバー項目には、プロトコル、アドレス、ポート、認証、転送方式などのパラメータが保存されます。Subscribeは、ユーザーがすでに利用しているサブスクリプションの項目を更新する機能です。サブスクリプションはサーバー項目の取得と管理、Configはルールや関連設定を扱うもので、同じものではありません。サーバーをまとめて読み込んでも、現在のルールが変更されたり、すべてのサーバーに接続できるようになったりするわけではありません。

画面：Homeのサーバー一覧からAdd Serverを選び、ユーザーがすでに持っているサーバー情報を追加します。既存のサブスクリプションはSubscribeの該当項目から読み込みます。Scan QR Codeを使う前に、QRコードの提供元が信頼できることを確認してください。項目はプロトコルによって異なります。現在のプロトコルに必要な情報だけを入力し、別のプロトコルのパラメータを流用しないでください。

読み込み後に確認する4項目

プロトコルとサーバーアドレスを確認します。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuardでは各項目の意味が異なります。名称が似ていても互換性があるとは限りません。
ポート、認証情報、転送パラメータを一つずつ確認します。サーバー側でTLSや特定の名前が必要な場合は、ユーザーがすでに利用している設定どおりに入力してください。
サーバー項目を1つ選び、Connectivity Testを実行してから、実際のリクエストでも確認します。一覧に名前が表示されるのは読み込み結果を示すだけで、接続できることの確認にはなりません。
サーバー項目の取得元と更新方法を記録します。手動で加えた変更を残す場合は事前にバックアップし、次回のSubscribe更新後に復元できなくならないようにしてください。

設定方法：読み込み、選択、テストの順に進め、ルールの変更は最後に行います。サブスクリプションを更新できない場合は、リンクが完全か、現在のネットワークから取得元にアクセスできるか、ユーザー側のサブスクリプションが有効かを確認します。更新に成功したら、表示されたメッセージだけで判断せず、サーバー項目が実際に変わったかを確認してください。トラブルの情報を共有するときは、サブスクリプションの認証情報、パスワード、個人のアドレスを隠してください。

注意点：サブスクリプションの更新だけで、あらゆる接続問題が直るわけではありません。サーバーのタイムアウトは、パラメータ、ネットワーク、サーバーの状態が原因の場合があります。何度も削除して読み込み直すと、比較に必要な情報を失うことがあります。読み込みの手順は入門ガイド、正規の入手先と購入の確認方法はApp Storeでの入手ガイドをご覧ください。

04 / ON DEMAND

On Demandによるオンデマンド接続

概要：On Demandを使うと、設定した条件に応じてシステムが接続を開始できます。これは「いつ接続するか」を決める機能です。Global Routingとルールは「リクエストをどう処理するか」を決めます。On Demandを有効にしても振り分けルールは自動作成されず、サーバーのパラメータも修正されません。まず手動接続が正常に使えることを確認してから設定してください。

画面：SettingsでOn Demandを開き、端末で利用できるネットワーク条件と動作を確認します。設定時にシステムのVPN構成の許可を求められる場合があります。システムの確認画面は構成の追加を許可するもので、サーバーに接続できることを示すものではありません。ほかのシステムVPN構成を利用している場合は、意図した構成が有効かどうかも確認してください。

まず1つの条件から試す

オンデマンド接続を一時的に無効にし、手動で接続して、現在のサーバーとConfigが想定どおり動作するかを確認します。
On Demandの現在の設定を記録し、ネットワーク条件と動作を1つずつ変更します。Wi-Fiの条件を使う場合は、ネットワーク名をよく確認してください。
可能な範囲でWi-Fiとモバイル通信を切り替え、接続が開始されるかを確認します。その後、リクエストが想定したルールで処理されるかを確認してください。
テスト後に有効な条件を記録し、互いに上書きする複数の条件によって動作が分かりにくくならないようにします。

注意点：手動で切断した後に再接続するのは、スイッチの不具合ではなく、システムがオンデマンド接続の条件を再び満たしたためかもしれません。自動接続を止めるには、Homeのスイッチを何度も押すのではなく、On Demandに戻って該当する設定を確認してください。Web認証が必要なWi-Fiでは、まずネットワーク側の認証を完了してから接続の問題を確認します。端末の状態、システムのポリシー、ネットワークの変化が接続開始のタイミングに影響します。オンデマンド接続をアプリごとに独立したプロキシスイッチと考えないでください。

05 / DATA

Dataの通信量と確認範囲

概要：Dataでは、クライアントが記録した通信量を確認できます。テスト中に通信が発生したか、送受信量に変化があったかを把握するために使います。通信サービスの残高を確認する画面ではなく、サービス提供元の課金記録の代わりにもなりません。表示値はクライアントが記録できる範囲を示すもので、端末全体の通信量と同じとは限りません。

画面：Dataを開き、表示されている統計の対象と範囲を確認します。端末によって表示される詳細は異なるため、画面上の見出しや選択項目を基準にしてください。統計のリセット項目がある場合は、必要な記録を保存してから使うかどうかを判断します。ローカルの数値をリセットしても、外部サービスの課金期間は変わりません。

設定方法：特定の対象をテストする前に、Dataの開始時点の値を記録します。確認するページやアプリだけを開き、リクエストが完了してから変化を比較してください。ほかのタスクによる通信が混ざらないよう、バックグラウンドのダウンロードやシステムアップデートはできるだけ一時停止します。対象のリクエストにどのポリシーが適用されたかを判断するには、リクエスト記録も確認してください。総通信量が増えただけでは、PROXY経由とは判断できません。

注意点：送受信量の比率は実際の利用内容によって異なり、短時間の変化からサーバーの速度が安定しているとは判断できません。プロトコルのオーバーヘッド、再試行、統計の集計方法によって数値に差が生じることもあります。バッテリー消費を調べる場合は、Dataの値をシステムのバッテリーやモバイル通信の使用記録と比較できます。ただし、通信量が多いだけでクライアントの異常とは限りません。通信が続けばネットワークの動作も増えます。

06 / SETTINGS

Settingsの主な項目

Settingsではアプリの一部の環境設定を管理できますが、すべての設定を一元管理する場所ではありません。DNSなどは現在のConfigで定義されている場合もあるため、有効な設定と関連画面の両方を確認してください。以下の操作は端末に実際に表示される項目を基準にします。見当たらない項目を似た名前の設定で代用したり、設定ファイルに推測で項目を追加したりしないでください。

DNS：名前解決とルーティングを分けて確認

概要と画面：DNSはドメイン名をアドレスに変換します。関連設定はSettingsの該当項目と現在のConfigの両方で確認してください。名前解決に成功してもプロキシ接続が成功したとは限らず、名前解決の失敗がサーバー認証の誤りを示すとも限りません。ドメインルールとアドレスルールは異なる情報を使うため、DNSの変更によってルールの判定が変わることがあります。

設定方法：まず現在の設定を記録し、すべてのドメインで問題が起きるのか、特定のドメインだけなのかを確認してから、名前解決の設定と到達性を調べます。一度に変更するのは1か所だけにし、保存後は同じ対象で再確認してください。必要に応じて接続を作り直し、既存の接続が確認結果に影響しないようにします。注意：提供元が不明なDNS設定を複数重ねたり、特定のDNSサービスだけであらゆる問題を解決しようとしたりしないでください。

Test Method：テスト結果の見方

概要と画面：SettingsでTest Methodを確認します。これは接続テストに使う方法を選ぶ項目で、設定後はHomeに戻ってConnectivity Testを実行できます。テスト方法によって確認するネットワークの段階は異なります。特定の確認に応答がなくても、実際の通信がすべて失敗するとは限りません。

設定方法：サーバーを比較するときは、Test Method、ネットワーク、テスト時刻をできるだけ揃え、その後で実際の接続先を使って確認します。注意：テストの数値は通信速度を保証するものではなく、最小の数値がすべてのサイトで最速とは限りません。テスト方法を変えても、サーバーのポート、パスワード、転送設定は修正されません。

Today Widget：ショートカットと接続状態

概要と画面：Today Widgetはショートカット操作に関する設定です。追加できるかどうかや表示方法は、端末のシステム対応状況によって異なります。まずSettingsで関連項目を確認し、システムが用意するウィジェット管理画面から操作してください。ウィジェットからの操作は、Homeでの設定全体の確認に代わるものではありません。

設定方法：追加したらアプリに戻り、現在のサーバーとGlobal Routingを確認してから、ショートカット操作で想定どおり接続できるかテストします。注意：ウィジェットの表示更新には時間がかかることがあります。表示と実際の状態が異なる場合は、アプリ内の状態と実際のリクエストを基準にしてください。該当項目が見つからない場合、同じ外観にするために無関係なネットワーク設定を変更しないでください。

iCloud：同期と復元を分けて確認

概要と画面：iCloud関連の項目は、アプリが対応するデータ同期やバックアップのための設定です。Settingsの該当項目とシステムのiCloud設定で確認できます。アプリの購入記録はApp Storeアカウントに紐づくもので、設定データの同期を意味しません。それぞれ個別に確認してください。

設定方法：まず端末でサインインしているiCloudアカウント、システムの許可設定、空き容量を確認し、アプリに表示される同期範囲を確認します。端末を移行する前にローカルのコピーを保存し、新しい端末でサーバー、Config、選択状態を一つずつ確認してください。注意：すべてのデータが自動で上書きされたり、すぐに同期されたりするとは限りません。サブスクリプションや認証情報は機密情報のため、同期ファイルもアクセスを制限して扱ってください。

07 / DIAGNOSTICS

Diagnosticsと設定の確認手順

概要：Diagnosticsはトラブル対処に必要な情報を収集・表示し、問題が名前解決、ルール、サーバー接続、リクエストのどの段階にあるかを調べるために使います。診断情報は判断材料であり、自動修復の結果ではありません。まず症状を明確にし、端末で利用できる関連ツールを選んでください。すべてのスイッチを一度に有効にするのは避けましょう。

画面：SettingsでDiagnosticsまたは該当する診断項目を探し、HomeのConnectivity Test、Data、利用可能なリクエスト記録とあわせて確認します。ツールの表示や出力内容は、現在の端末の画面を基準にしてください。追加の記録を有効にする場合は、トラブル対処中だけ使用し、終了後に元の設定に戻して不要な詳細データを長期間残さないようにします。

1つの問題につき、比較できる証拠を一組残す

前提を記録：Wi-Fiかモバイル通信か、Global Routing、使用中のサーバーとConfigを記録します。パスワードなどの認証情報は記録しないでください。
基本ネットワークを確認：ネットワーク自体で通信できることを確認し、必要に応じてWi-FiのWeb認証が完了しているか調べます。
サーバーを確認：Connectivity Testを実行します。失敗した場合は、プロトコル、アドレス、ポート、認証、転送パラメータ、システム時刻を確認してください。
特定の対象で再現：明確なドメインにリクエストを送り、名前解決の成否、一致したルール、実際に使われたポリシーを確認します。
変更は1項目だけ：設定を変更したら同じ対象で再テストします。改善しない場合は元に戻し、変更が残って次の判断に影響しないようにしてください。

注意点：タイムアウトは、待機時間内にリクエストが完了しなかったことを示すだけで、問題がどちら側にあるかを直接示すものではありません。一部の対象だけが失敗する場合は、まず対象とルールを確認します。すべての対象で問題が起きる場合は、基本接続と共通設定を調べてください。診断情報を共有する前に、サブスクリプションリンク内の認証情報、サーバーの認証情報、個人のドメイン、利用状況が特定される内容を隠し、症状に関係する最小限の情報だけを残してください。