Shadowrocketの機能と設定

ROUTING MODE

Global Routingの3つのモード

Global Routingでは、接続時に適用する全体的なルーティング方式を選びます。HomeからGlobal Routingを開き、用途に応じてConfig、Proxy、Directを選択してください。Configは設定ファイルに基づく処理、Proxyはプロキシ経由、Directは直接接続を指します。操作時は英語の項目名を確認してください。モードの選択とHomeの接続スイッチは別の設定です。モードを選んだ後、接続が有効になっているかも確認します。

ルールで振り分ける場合はConfigを使います。Config画面で現在有効な設定ファイルを確認し、Homeに戻ってサーバーの選択状態を確認してください。ファイルをリストにインポートしただけでは、現在の設定として選択されたことにはなりません。また、ファイルにPROXYと記述されていても、サーバーの設定が利用可能とは限りません。

対象にアクセスできない場合は、一時的にProxyへ切り替えて比較できます。Proxyでは成功し、Configでは失敗する場合、まず該当するルール、ポリシー、DNSを確認してください。すぐにすべてのサーバーを作り直す必要はありません。Directでテストするときも、対象とネットワークの条件を変えずに比較します。確認後は元のモードに戻し、切り分け用の設定をそのまま使い続けないようにしてください。

RULE MATCHING

ルールの種類とポリシー

ルールによる振り分けでは、リクエストの条件と処理ポリシーを組み合わせます。ルールはConfigで現在使用中の設定ファイルにある[Rule]セクションに記述します。通常は上から順に判定され、最初に一致したルールのポリシーが適用されます。そのため、具体的なドメインは広い条件より前に置き、FINALは末尾に配置します。ルールが存在するかだけでなく、その前に一致するルールがないかも確認してください。

この例では、example.com自体は先にDOMAINに一致し、DIRECTで処理されます。そのサブドメインはDOMAIN-SUFFIXに一致し、PROXYで処理されます。IP-CIDRはIPアドレス範囲を指定し、FINALはそれ以前のルールに一致しなかったリクエストを処理します。この例はルールの順序を示すものです。確認せずに設定全体と置き換えないでください。

PROXY、DIRECT、REJECTはポリシーであり、ルールの条件ではありません。PROXYはリクエストをプロキシ経由で処理し、DIRECTは直接接続を使い、REJECTは一致したリクエストを拒否します。問題を切り分けるときは、どの条件に一致したか、その条件にどのポリシーが指定されているかを分けて確認してください。独自のポリシー名を使っている場合は、その名前が有効か、実際にどのサーバーを参照しているかも確認します。

変更前に元の設定を保存し、変更後はそのファイルが引き続き有効になっていることを確認して、新しいリクエストで検証してください。既存の接続は以前の経路を使い続ける場合があります。再生や転送が続いていることだけでは、新しいルールが反映されたとは判断できません。設定の構文、セクション、ルールの順序については設定リファレンスをご覧ください。

SERVER MANAGEMENT

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

サーバー情報には接続先、プロトコル、認証パラメータが記載されています。サブスクリプションは、既存のサーバー項目をまとめて提供・更新するものです。サーバーのサブスクリプションとルール設定ファイルは用途が異なります。どちらもテキスト形式のリンクだからといって、同じ場所にインポートしないでください。操作前に、手元の情報がサーバーのサブスクリプション、単一サーバーの共有情報、設定ファイルのどれに当たるか確認します。

Add Serverとインポート方法

サーバーを手動で追加するには、HomeからAdd Serverを開き、プロトコルを選択してからアドレス、ポート、認証情報を入力します。Shadowsocks、VMess、VLESS、Trojan、HTTP、SOCKS5、WireGuard、Hysteria2では必要な項目が異なります。手元のサーバー情報に従って入力してください。TLS、転送方式、サーバー名などもサーバー側の設定と一致させます。プロトコル名だけから推測して入力しないでください。

QRコードがある場合はScan QR Codeを使えます。共有情報がある場合は、対応するインポート操作を利用してください。Subscribeを使うときは、現在の画面がサーバーのサブスクリプションを管理する場所なのか、Configの設定サブスクリプションなのかを確認します。インポート前に情報の種類を確かめ、インポート後はどのリストに追加されたかを確認してください。ルールファイルのURLをサーバーのサブスクリプションURLとして扱わないようにします。

更新、選択、ローカル編集の保持

サブスクリプションを更新したら、まず項目が変わったか確認し、Homeに戻って想定したサーバーが選択されているかを確認します。更新の成功は、内容を取得して処理できたことを示すだけで、各サーバーへの接続を保証するものではありません。Connectivity Testと実際のリクエストで引き続き確認してください。更新できない場合は、URLが完全か、現在のネットワークからアクセスできるか、サブスクリプションが有効かを確認します。

サブスクリプションから作成された項目を手動で編集する前に、次回の更新で再作成または上書きされないか確認してください。重要なローカル変更は別途記録し、サブスクリプションを削除する前に、使用中のサーバーが含まれていないか確認します。サブスクリプションURL、QRコード、認証情報にはアクセス情報が含まれる場合があります。問い合わせ時に元の内容を公開しないでください。

CONNECTION TRIGGER

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

On Demandは、設定したネットワーク条件に応じて接続を開始します。「いつ接続するか」を制御する機能であり、「特定のドメインをどのポリシーで処理するか」を決めるものではありません。設定はHomeのOn Demandから開き、現在の画面に表示されるネットワーク条件を設定して有効にします。システムのVPN設定が正常に機能する必要があるため、先に手動接続を一度確認してください。

設定前に、特定のネットワークで接続するのか、ネットワーク条件の変化後に接続を再開するのかを明確にします。アプリに表示されるWi-Fi、モバイル通信、ネットワーク条件の各項目を確認し、条件間の関係が分からないまますべて有効にしないでください。テストでは、まず安定したネットワークで確認し、次に別のネットワークへ切り替えて動作を見ます。同じネットワークでページを何度も開くだけでは、ネットワークの変化を条件とする動作は検証できません。

On Demandで接続した後も、リクエストはGlobal Routingと現在の設定に従って処理されます。無効なサーバーを修復したり、ルールの選択を代替したりする機能ではありません。手動で切断しても再び接続される場合は、On Demandが有効のままか、現在のネットワークが接続条件を満たしているかを確認してください。一時的な切り分けではOn Demandをオフにして手動接続と比較し、確認後に必要な条件へ戻します。

TRAFFIC OBSERVATION

Dataで通信量を確認する

Dataでは、クライアントに記録された通信量を確認できます。Dataを開き、現在選択されている統計項目、期間、画面に表示される分類を確認してから、送受信量の変化を見ます。テスト前の数値を記録し、内容が明確なリクエストを1回送って増加量を比較すると、累計だけを見るより今回の操作による通信を把握しやすくなります。

クライアントの統計は、サービス提供元の課金記録と同じとは限りません。集計期間、対象範囲、計算方法が異なる場合があります。Dataの合計をアカウントの残量と見なしたり、ダウンロード量が増えたことだけでWebページが完全に読み込まれたと判断したりしないでください。バックグラウンド通信、アプリの再試行、接続時の通信量も統計に反映される場合があります。

観察の基準を取り直す必要がある場合は、必要な情報を記録してから、画面に用意されたリセット操作を使います。統計をリセットしても接続の問題は解決しません。また、ルール変更と同時に行わないでください。ページの表示に失敗してもDataの数値が変化する場合は、リクエストの結果、適用されたポリシー、対象の状態を続けて確認します。数値が変化しない場合は、接続スイッチ、現在のモード、テスト用のリクエストが新たに送信されたかを確認してください。

COMMON SETTINGS

Settingsとよく使う設定項目

Settingsには、テスト、補助機能、同期、診断などの設定があります。DNSなどの動作が現在の設定ファイルで定義されている場合もあります。ここでは機能ごとの確認場所を説明します。具体的な階層や選択肢は現在のアプリ画面で確認してください。名前が似ていても、Settingsの全体設定とConfig内のファイル設定が同じ範囲に適用されるとは限りません。

DNS：設定が有効な場所を確認

DNSはドメイン名をIPアドレスに変換します。名前解決の結果は接続や、一部のIPルールの判定に影響します。DNSを確認するには、まずConfigで現在の設定ファイルを開き、[General]のdns-serverと、現在の画面にあるDNS関連の項目を確認してください。以下のsystemはシステムDNSを使う例です。あらゆるネットワークに適した固定の推奨設定ではありません。

名前解決に問題があると思われる場合は、サーバーを同時に変更せず、同じドメインへの新しいリクエストを変更前後で比較してください。設定した名前解決方式が現在のネットワークから利用できることを確認し、次にルールが名前解決後のIPアドレスに依存しているかを調べます。DNSを変更しても、サーバー認証、接続先の証明書、既存の接続は自動的に変わりません。エラーが起きた場合は、名前解決の失敗と接続の失敗を区別してください。

Test Method：テスト条件をそろえる

Test MethodはSettingsにあり、サーバーのテスト方法を選択できます。実行前に現在の方法と設定可能な項目を確認し、Connectivity Testを行ってください。方法によって測定する段階が異なります。ポートに接続できても対象ページへのリクエストが完了したとは限らず、プロキシ経由のテストに成功してもすべての対象へアクセスできるとは限りません。

サーバーを比較するときは、Test Method、テスト対象、ネットワーク条件をそろえてください。異なる方法で得た数値をそのまま比較したり、1回のテストが短時間で終わったことを長期的な速度の保証と見なしたりしないでください。テストに失敗したら、接続先への到達性、認証情報、転送パラメータ、テスト対象を個別に確認し、最後に実際の利用先への接続を確認します。

Today Widget：状態確認と操作の補助

Today Widgetは、システムのウィジェットに関連する補助機能です。Settingsでアプリが提供する関連項目を確認し、システムが対応する方法で追加または管理してください。表示場所や操作方法はデバイスとシステムによって異なります。現在のシステム画面で確認してください。ウィジェットを設定する前にアプリ内でサーバーを選択し、接続を確認しておくと、初期設定の問題とウィジェットの問題を切り分けやすくなります。

ウィジェットの表示は補助情報であり、システムによる更新はすぐに反映されるとは限りません。状態に疑問がある場合はHomeを開き、実際の接続スイッチ、Global Routing、サーバーの選択を確認してください。ウィジェットの一度の表示だけで現在のルーティングを判断しないでください。ウィジェットを削除しても、アプリ内のOn Demandがオフになるわけではありません。

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

iCloud関連の機能を使う前に、システムでiCloudが利用可能か、Shadowrocketにアクセス権があるかを確認し、続けてアプリのSettingsにある同期項目を確認してください。現在の機能が対応する範囲で同期し、サーバー、設定、統計、システムの許可がすべて複製されるとは限りません。初回同期の前に、重要な設定を復元できるよう控えを残してください。

複数のデバイスで同じ内容を編集する場合は、同期が完了したことを確認してから編集を続けてください。どの状態が意図したものか分からなくなるのを防げます。デバイスを変更した後も、現在の設定、選択中のサーバー、システムのVPN許可を確認してください。App Storeでの購入済みアプリの再取得とiCloudのデータ同期は別の手順です。アプリを再取得できても、利用データがすべて復元されるとは限りません。

Diagnostics：再現可能な情報を記録

Diagnosticsは、動作状態や接続の問題を調べるための機能です。Settingsの診断関連メニューから、現在利用できるツールを確認できます。調査前に、ネットワークの種類、Global Routing、現在の設定、問題が発生した操作を記録してから、もう一度再現してください。診断情報は実際に失敗した時刻と対応させます。早い段階で保存した記録には、分析対象のリクエストが含まれていない場合があります。

診断結果を共有する前に、サブスクリプションURL、パスワード、認証情報、不要な個人情報を削除してください。名前解決が完了したか、接続がどの段階で失敗したか、どのポリシーが適用されたかなど、原因の判定に必要な情報だけを残します。問題の特定に必要な情報を一度収集したら、詳細なリクエスト記録を不要なまま長期間残さないよう、通常の記録設定に戻してください。