公式マニュアル · 機能と設定

Shadowrocketの機能と基本設定

まずGlobal Routingを確認し、次にサーバーとConfigを確認します。その後、接続の自動開始、DNS、Diagnosticsを調整します。設定ごとに役割が異なるため、問題の切り分け中に複数の項目を一度に変更しないでください。

Home Config Data Settings

このページでは、iPhoneとiPadでのShadowrocketの操作を説明します。画面上の項目名は英語のまま記載し、日本語で機能を説明します。項目の場所はアプリの画面変更に伴って変わる場合があるため、実際の端末で確認してください。システム要件はApp Storeの掲載内容をご確認ください。

Global Routing:通信モードの選び方

Global Routingでは、接続時の通信をConfig内のルールで判定するか、ProxyまたはDirectの経路を主に使うかを選びます。サーバーの選択やHomeの接続スイッチとは別の設定です。まずHomeでGlobal Routingを開いて現在の選択を確認し、目的に応じてConfig、Proxy、Directを選びます。

画面上の選択肢 通信の処理方法 適した用途 確認するポイント
Config(設定ファイル) 現在有効なConfigのルールに基づいて判定し、通信先のポリシーを決定します。 ドメイン名やアドレスなどの条件に応じて通信を振り分けたい場合。 Configが有効になっていること、ルールの順序、ポリシーの参照先が正しいことを確認します。
Proxy(プロキシ) 主に現在選択中のプロキシ経由で通信します。 一時的にプロキシ接続を確認し、ルールに関する問題の範囲を絞り込む場合。 選択中のサーバーが利用可能か確認します。この結果だけで個々のルールが正しいとは判断できません。
Direct(直接接続) 主に直接接続の経路を使用します。 現在のネットワークから対象へ直接アクセスできるか確認する場合。 DNS、アプリの設定、システムのネットワーク状態もあわせて確認します。

日常的に通信を振り分ける場合は、通常Configを使用します。操作前にConfigを開き、ファイルが読み込まれているだけでなく、実際に有効になっていることを確認してください。ファイルが存在する状態と、使用中の状態は異なります。有効でないファイルを編集しても、現在の接続動作には反映されません。

特定の接続先に問題がある場合は、現在の設定を記録したうえで、ProxyとConfigを短時間ずつ切り替えて比較できます。Proxyでは接続でき、Configではできない場合は、該当リクエストに適用されたルールとポリシーの行き先を確認します。これは切り分けの手掛かりであり、原因を確定するものではありません。テスト後は必要なモードに戻し、一時的な確認用設定をそのまま常用しないようにしてください。

ルールによる振り分け:条件・順序・ポリシー

ルールによる振り分けでは、リクエストのドメイン名や宛先アドレスなどをルールと順に照合し、該当するポリシーで処理します。Configで現在使用中の設定を開き、ルール一覧を確認してください。Global RoutingでConfigを選んでいる場合、この設定が振り分け確認の対象になります。変更前に元のファイルを保存し、比較できる状態にしておきましょう。

通常、各ルールは種類、照合対象、ポリシーで構成されます。ルールは上から順に評価され、最初に一致した時点で照合が終了します。そのため、特定ドメインの例外ルールは、それを包含する範囲の広いルールより前に置きます。FINALは通常、ほかのルールに一致しなかったリクエストを受けるため末尾に配置します。ルール数が多くても、優先順位が適切とは限りません。

キーワード照合対象設定時の注意
DOMAIN完全一致するドメイン名。単一のホストに対する例外に適しています。
DOMAIN-SUFFIXドメインのサフィックスとそのサブドメイン。広い範囲に適用されるため、完全一致ルールとの順序に注意してください。
DOMAIN-KEYWORDドメイン名に含まれるキーワード。条件の範囲が広く、意図しないドメインにも一致することがあります。
IP-CIDR / IP-CIDR6IPv4 / IPv6のアドレス範囲。アドレス範囲の記述を確認し、ドメイン名の解決と照合の関係にも注意してください。
GEOIPアドレスデータベースに基づく地域分類。データベース上の分類は、サービスの所在地や実際の通信経路を示すものではありません。
FINALそれまでのルールに一致しなかったリクエスト。フォールバックとして使用し、参照先のポリシーが利用可能か確認します。

PROXYはプロキシ経由、DIRECTは宛先への直接接続、REJECTはリクエストの拒否を示します。ルールから設定ファイル内のポリシーグループを参照する場合は、ルール末尾の記述だけでなく、グループ内で現在選択されている項目も確認してください。次の例はルールの順序を示すものです。example.comは説明用のドメイン名であり、例全体を既存の設定と置き換えないでください。

DOMAIN,ads.example.com,REJECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,10.0.0.0/8,DIRECT
FINAL,PROXY

この例では、完全一致の例外をサフィックスルールより前に置いています。順序が逆だと、ads.example.comは先に範囲の広いルールに一致します。問題を切り分ける際は、まず実際に一致したルールを特定してから順序を変更してください。効果を期待するルールを末尾に追加するだけでは解決しません。詳しくはルールの照合順序とFINALの解説をご覧ください。

Subscribeとサーバーの管理

サーバー情報には個別の接続パラメータを保存します。Subscribeは利用者自身が用意したサブスクリプションを使って、複数のサーバーを管理する機能です。一方、Configは主にルールや関連設定を保持します。これらは関連していますが、同じ種類のデータではありません。既存のリンクは実際の種類に応じて読み込んでください。URL形式であることだけを理由に、ConfigのURLとサブスクリプションのURLを入れ替えて使うことはできません。

Homeの追加メニューからAdd Serverを開き、手元の情報に合わせてTypeを選びます。手動で追加する場合は、Address、Port、プロトコルごとに必要な認証項目を確認してください。たとえばTrojanとShadowsocksでは必要な項目が異なります。各パラメータはサーバー側の情報と一致させてください。パラメータが合わない状態でTypeを変更しても解決しません。項目の意味はプロトコル技術リファレンスをご覧ください。

既存のサブスクリプションを読み込むには、Add ServerのTypeでSubscribeを選び、URLなどの該当欄に自身のサブスクリプション情報を入力します。保存後にHomeへ戻り、サブスクリプション内にサーバー一覧が表示されたことを確認してから、使用する項目を選びます。Scan QR Codeを使う場合は、認識された内容の種類と入手元を確認してください。保存後もパラメータの確認が必要です。QRコードの読み取りに成功しても、接続が成功したとは限りません。

サブスクリプションを更新すると、一覧の内容を再取得できます。提供元がアドレスやパラメータを変更した場合に便利です。更新後は、選択中のサーバーが一覧に残っているか、名称が変わっていないか、既存のポリシーが有効な項目を参照しているかを確認してください。サブスクリプションから作成された項目を一時的に編集しても、次回の更新で変更が上書きされることがあります。重要な変更を加える前に、設定の保存方法を確認しましょう。

Connectivity Testでは、現在のテスト条件で各項目の応答状況を比較できます。ただし、結果はTest Method、テスト対象、ネットワーク、サーバーの状態に左右されます。一覧に応答があっても、すべての接続先にアクセスできるとは限りません。応答がない場合も、まず現在のサービスに適したテスト方法か確認してから、サーバーのパラメータを変更してください。

On Demand:条件に応じて接続を開始

On Demandは、設定した条件に応じてシステムにVPN接続を開始させる機能です。これは「いつ接続するか」を決めるものであり、「特定のドメインにどのポリシーを適用するか」を決めるものではありません。接続後の通信処理は、引き続きGlobal Routingと現在のConfigに従います。On Demandを別の振り分けルールとして扱わないでください。

まずHomeで手動接続を一度試し、既存のサーバーと設定が正常に動作することを確認してから、SettingsでOn Demandを開きます。画面に表示されるネットワーク条件を実際の環境に合わせて設定してください。Wi-Fi名などの条件を指定する場合は、入力ミスがないことと、端末が該当ネットワークに接続していることを確認します。手動接続が成功していない段階で複数の自動接続条件を追加すると、問題の発生箇所を特定しにくくなります。

設定後は実際に使用するネットワーク環境を切り替え、想定どおりに接続が開始されるか確認し、Homeで接続状態を確認します。「接続が開始されるべき状況」と「開始されないべき状況」の両方をテストしてください。現在のWi-Fi環境で一度試すだけでは、ほかのネットワーク条件も正しく設定されているとは判断できません。

接続を停止するつもりだったのに再び接続された場合は、On Demandが有効のままか、設定した条件を満たしているか確認してください。自動動作を一時停止するには、関連する接続条件を先に無効にしてから、接続スイッチを確認します。ネットワークの切り替えやバックグラウンド動作に対するシステムの処理も結果に影響するため、すべての環境で同じタイミングで動作するとは限りません。

Data:通信量とリクエストの確認

Dataでは、アプリに記録された通信量の統計や、確認可能なリクエスト情報を表示します。「接続中にデータが流れたか」「テストの前後で記録に変化があったか」といった確認に使えますが、サービス提供元の請求明細や詳細な速度テストではありません。集計方法、保存範囲、画面表示は端末上の実際の設定に従います。

Dataを開いたら、まず集計範囲、時間、利用可能な分類を確認し、単一の接続先へのアクセスをテストします。累計値だけを見るより、テスト前後の変化を比較するほうが有用です。接続の詳細やリクエスト記録が表示される場合は、ドメイン名、宛先アドレス、ポリシー情報を組み合わせて通信経路を確認します。項目が表示されない場合、特定のルールが適用されたと推測で判断しないでください。

もう一度確認する場合は、必要な情報を記録してから、画面に用意されているリセットまたは消去機能を使います。統計の消去とサーバーパラメータの変更は別の操作であり、誤ったルールが自動的に修正されるわけではありません。テスト中はほかのアプリのバックグラウンド動作をできるだけ抑え、更新や同期などの通信が統計に混ざって判断に影響しないようにしてください。

Dataの数値が増えていても、記録対象の通信があったことを示すだけで、目的のサービスが正常に利用できたとは限りません。アプリが再試行中だったり、別のリソースを取得していたりする場合もあります。逆に、テスト時に目立った変化がなくても、接続状態、現在のモード、集計範囲が関係している可能性があります。統計値だけで結論を出さず、Home、Global Routing、実際のアクセス結果をあわせて確認してください。

Settings:よく使う項目の設定範囲

Settingsにはアプリ全体の設定、テストの設定、同期、補助ツールなどがあります。Configにも名前解決や接続に関する設定が含まれる場合があります。変更前に、対象の設定がアプリ全体とConfigのどちらに属するかを確認し、現在の値を記録して有効なファイルを保存してください。画面にない項目を別のガイドと同じ場所で探そうとせず、端末に表示される項目を基準にしてください。

DNS:名前解決の設定元を確認

DNSはドメイン名をアドレスに変換する、接続前の重要な仕組みです。まずSettingsで関連項目を確認し、現在のConfigでDNSが指定されているかも調べてください。一か所を変更すればすべての設定に反映されるとは限りません。利用可能であることを確認したDNSサービスと、アプリが対応する形式を使用し、保存後に同じドメイン名でもう一度テストします。DNS設定を変更した直後はキャッシュの影響も考慮し、必要に応じて画面上の方法でキャッシュを消去してから再確認してください。

ドメイン名の名前解決に成功しても、その後の接続が成功するとは限りません。ドメイン名とアドレスで接続結果が異なる場合は、DNSを調査対象にできます。ただし、宛先をアドレスに直接置き換えるとTLS証明書の検証やリクエストの動作が変わる可能性があります。この比較を恒久的な解決策として扱わないでください。また、同じテスト中にDNS、Global Routing、プロトコルの項目を同時に変更することは避けてください。

Test Method:テスト方法をそろえて比較

Test Methodは、Connectivity Testで使用するテスト方法を指定します。Settingsで該当項目を開き、現在の画面で選べる方法を設定したうえで、関連するテスト対象を確認してください。方法ごとに検証する接続段階が異なるため、結果を同じ条件のものとして比較できるとは限りません。方法を変更した場合は、比較したい項目を再テストしてください。変更前の一覧と新しい結果をそのまま並べ替えて判断しないようにしましょう。

テスト対象から応答があっても、選択した方法で確認できる接続段階に応答があったことを示すだけで、すべてのアプリやWebサイトが正常に動くとは限りません。「方法、対象、ネットワーク環境」の3つの条件を記録し、実際のサービスへのアクセスでも確認してください。一つの応答値をサービス品質や安定性の保証として扱わないでください。

Today Widget:確認や操作を簡単にする

Today Widgetは、システムのウィジェットからアプリを手軽に操作するための機能です。まずSettingsで関連項目を確認し、次にシステムのウィジェット編集画面で追加できるか、端末上でどの操作が利用できるかを確認してください。表示内容はシステムバージョンやウィジェットの対応状況によって異なる場合があります。実際の端末画面をご確認ください。

ウィジェットはアプリを開く手間を減らすもので、設定の確認に代わるものではありません。ウィジェットで接続を操作した後、状態が想定と異なる場合はHomeに戻って確認し、On Demandが接続開始に関係していないかも調べてください。ウィジェットに前回表示された状態だけで、現在接続中かどうかを判断しないでください。

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

iCloud関連の項目を使うと、条件を満たした端末間でアプリが対応するデータを同期できます。SettingsでiCloudの設定を確認し、システム側でShadowrocketのiCloud利用が許可されていることも確認してください。初めて有効にする前に、重要なConfigをバックアップし、現在選択中のサーバーとモードを記録しておきましょう。同期対象は画面上の説明に従い、一時的な状態、統計、認証情報がすべて同期されるとは限らない点に注意してください。

端末を変更した後は、データの同期を待ってからファイル、サーバー、ポリシーの参照先を一つずつ確認します。同期は接続テストではなく、履歴がすべて復元されたことを意味するものでもありません。2台の端末で同じConfigを同時に編集した場合は保存内容を確認し、古い内容で変更済みのルールを上書きしないようにしてください。移行手順は設定のバックアップと移行方法をご覧ください。

Diagnostics:問題を特定して診断情報を取得

Diagnosticsでは、アプリが提供する診断情報を取得できます。Settingsで該当項目を開き、画面に表示される方法から必要な診断を選んでください。問題が起きたときのネットワーク、Global Routing、選択中のサーバー、操作手順を記録してから再現すると、長時間にわたり複数の操作を混在させた記録より原因を特定しやすくなります。

診断結果は分析の手掛かりであり、自動修復するものではありません。共有する前に、サブスクリプションURL、サーバーアドレス、アカウント情報、アクセス先が含まれていないか確認し、必要に応じて伏せ字にしてください。記録全体をそのまま公開しないでください。調査が終わったら、一時的に有効にした記録項目を元に戻し、不要になった診断データを必要に応じて削除してください。

よく使う設定の確認手順

設定項目が多い場合は、決まった順番で確認すると変更の繰り返しを減らせます。まず元に戻せる状態を保存し、変更は一度に一つに絞ってください。保存後は毎回同じ接続先で検証し、結果を記録します。これにより、パラメータの誤り、ルールの振り分け、自動接続の条件を切り分けやすくなります。

  1. 入力内容を確認します。Homeで現在のサーバーを確認し、既存のサブスクリプションが更新済みか、手動で入力したType、Address、Port、認証情報が一致しているかを調べます。
  2. 通信モードを確認します。Global Routingで現在の選択を確認します。Configを使う場合はConfigを開き、実際に有効なファイルを確認してから、ポリシーの参照先とFINALを確認してください。
  3. 手動で接続を検証します。接続を開始して、接続先を一つ選んでアクセスします。Dataと利用可能な記録も確認し、Connectivity Testだけを成功の判断基準にしないでください。
  4. 補助設定を調整します。必要に応じてDNS、Test Method、Diagnosticsを一つずつ確認し、元の値を記録してください。接続に関わる複数の項目を同時に変更しないようにします。
  5. 最後に自動動作を有効にします。手動接続の確認後にOn Demand、Today Widget、iCloudを設定し、接続条件、操作、同期の結果をそれぞれテストしてください。

問題のある箇所を特定できない場合は、まずトラブルシューティングをご覧ください。初回利用時で読み込みや権限の設定が済んでいない場合は、多くの応用設定を変更する前にクイックスタートから始めましょう。確認済みの設定を一つ保存しておくと、変更を重ねるよりも後から管理しやすくなります。