Connectivity Test
現在のテスト方法に応じた接続可否を確認します。一つの結果だけで、すべてのリクエストが利用可能だと判断しないでください。
OFFICIAL MANUAL / GETTING STARTED
追加、モード選択、接続、確認、トラブルシューティングの順に進めます。まず既存の設定で実際のリクエストを確認し、その後にルールや設定を段階的に調整してください。
STEP 01 / ADD SERVER
情報が単一サーバーのパラメータなのか、サブスクリプションURLなのかを確認します。それぞれ使用する画面が異なります。サブスクリプションURL全体をHostに入力しないでください。
HomeのSERVERグループでAdd Serverを開き、サーバーの編集画面に進みます。まずTypeをタップし、お手元の情報に合ったプロトコルを選択してから、Host、Portと対応する認証情報を入力してください。Typeによって表示される入力項目が変わるため、プロトコルを先に選んでからパラメータを確認します。すべて入力してからTypeを切り替えるのは避けてください。
Shadowsocksを例にすると、Hostにはサーバーのドメイン名またはIPアドレス、Portにはポート番号を入力します。PasswordとMethodには、それぞれお手元の情報に記載されたパスワードと暗号化方式を入力してください。HostはウェブページのURLではないため、ページのパスを付けないでください。Portにはコロンを含めず、番号のみを入力します。Trojan、VMess、VLESSなど別のプロトコルを利用する場合は、対応するTypeに切り替え、各項目を入力してください。Shadowsocksと同じ項目構成を流用しないでください。
入力後、前後の空白、大文字・小文字、数字を一つずつ確認して保存し、Homeに戻ります。新しい項目が表示されても、情報が保存されたことを示すだけで、サーバーに接続できることの確認にはなりません。項目のプロトコル、アドレス、ポートを確認してから、使用する項目を選択してください。プロトコルの各項目の意味が分からない場合は、用語ガイドを参照してください。不明な値はご自身が利用するサービスの提供元に確認し、推測で補わないでください。
サブスクリプションURLをお持ちの場合は、Config画面でSubscribeを探し、URL全体を貼り付けて読み込みを確定します。画面のレイアウトによって入口の位置が異なる場合があります。アプリ内の実際の表示に従ってください。URLのパスやクエリパラメータは削除せず、不要に見える文字もそのまま残します。サブスクリプションURLには認証情報が含まれる場合があります。該当する入力欄にのみ貼り付け、公開のコメントやスクリーンショットに載せないでください。
読み込み後、処理が完了するまで待ち、Homeに戻ってSERVERグループに想定した項目が表示されるか確認します。一覧が空の場合は、読み込みエラーやネットワークエラーがないか確認してください。同じサブスクリプションを何度も追加しないでください。サブスクリプションの読み込みで取得できるのはサーバー一覧です。Configの設定ファイルにはRuleなどが含まれる場合もあります。一覧が表示されても、ルーティングルールが設定済みとは限りません。次にGlobal Routingを個別に確認してください。
サーバーのQRコードをお持ちの場合は、Scan QR Codeで読み取り、認識された内容を確認できます。クリップボードに対応するURLがある場合は、アプリの案内に従って読み込んでください。Import from Cloud JSONは別の読み込み方法です。お手元の情報形式がこの入口の要件に合う場合にのみ使用します。すべての方法を試す必要はありません。手元の情報に合った方法を一つ選んでください。
STEP 02 / GLOBAL ROUTING
Homeに戻ってGlobal Routingを開きます。ここではリクエストの処理方法を選択します。サーバーのプロトコルを選ぶ画面ではありません。
Global RoutingでConfig、Proxy、Directから選択し、確定してHomeに戻ったら、現在選択されている項目を確認します。初回利用時は、まず確認したい内容を明確にしてください。ルールに従ってリクエストを振り分ける場合はConfigを使います。選択したプロキシサーバーでリクエストを処理できるか一時的に確認する場合は、Proxyで比較できます。ローカルネットワークの基本的な接続だけを確認する場合はDirectを使います。3つのモードを順番にオンにするのではなく、必要なものを一つ選択してください。
| モード | リクエストの処理方法 | 使用前の確認事項 |
|---|---|---|
| Config(設定) | 現在の設定にあるルールとポリシーに従ってリクエストを処理 | 設定ファイルが選択されているか、ポリシーの参照先が有効か |
| Proxy(プロキシ) | Proxy経由でリクエストを処理し、選択したサーバーを確認 | サーバーが正しく選択されているか、実際のリクエストが成功するか |
| Direct(直接接続) | 直接接続でリクエストを処理 | ローカルネットワークが利用できるか |
Configを開き、使用する設定ファイルを確認してから、その編集画面を開きます。公式スクリーンショットにあるGeneral、Rule、Hosts、URL Rewrite、HTTPS Decryptionは設定ファイル内の各セクションです。今回の初回設定では、まずRuleを確認すれば十分です。接続するために、ほかのセクションを一つずつ変更する必要はありません。スクリーンショットは設定ファイルの編集画面を示しており、HomeのGlobal Routing選択画面ではありません。名称は関連していますが、操作の目的は異なります。
Ruleでルールの順序と適用先のポリシーを確認します。通常、ルールは上から順に照合され、先に一致すると、その後のルールが同じリクエストの処理に使われない場合があります。DOMAIN-SUFFIXはドメインのサフィックス、GEOIPはIPアドレスの地理情報、FINALはそれ以前のルールに一致しない場合の処理に使います。テスト目的でFINALを安易に削除したり、内容が分からないポリシー名を設定にコピーしたりしないでください。
たとえばDOMAIN-SUFFIX,example.com,PROXYはルール構文の例であり、接続に必要なサーバー情報ではありません。実際に使う前に、PROXYが現在の設定にある有効なポリシーまたは選択先に対応していることを確認してください。ルールに記載した文字列からサーバーが自動的に作成されることはありません。ルール構文に不慣れな場合は、既存の設定を維持してください。照合の詳しい仕組みはGlobal Routingとルール振り分けの解説をご覧ください。
この手順の最後に、Homeで現在のGlobal Routingを確認できる状態にします。Proxyで一時的に比較した場合は、確認後に予定していたConfigへ戻し、実際のリクエストを再確認してください。比較時のモードを元に戻し忘れ、意図せず既定の設定として使い続けないようにしてください。
STEP 03 / CONNECT
サーバーとモードを確認してから接続します。初回利用時はシステムの許可も必要です。システムの確認画面が表示された状態は、接続が確立したことを意味しません。
Homeに戻り、SERVERで選択中の項目がテストするサーバーと一致しているか確認します。Global Routingが前の手順で選択したモードのままであることも確認してください。問題がなければ、画面上部のスイッチをオンにします。未接続時はNot Connectedと表示されます。オンにした後は、画面上部の状態表示とシステムの案内を確認し、接続状態が切り替わるまで待ちます。状態が安定する前にサーバーやスイッチを何度も切り替えないでください。
初回操作時に、ShadowrocketによるVPN構成の追加を許可するようシステムから求められる場合があります。操作を開始したアプリが開いたばかりのShadowrocketであることを確認し、システムの案内に従って許可して、デバイスが求める方法で認証してください。この構成は、関連するネットワークリクエストをシステムからアプリに渡すためのものです。利用可能なサーバー情報は含まれず、サブスクリプションの読み込みに代わるものでもありません。許可しない、またはキャンセルした場合、今回の接続を続行できないことがあります。接続を再度開始し、許可を完了してください。
許可が完了したらアプリに戻り、画面上部が接続状態のままか確認します。スイッチがすぐにオフに戻る場合は、許可が完了したか、選択した項目が存在しパラメータが保存されているかを先に確認してください。この段階でDNS、Rule、その他の詳細設定を次々に変更しないでください。後から接続できても、どの変更が影響したのか判断しにくくなります。
接続時は、デバイス上で別のVPN接続が動作していないか確認します。切り替える必要がある場合は、現在の接続を停止してからShadowrocketに戻り、今回のテスト接続を開始してください。接続が置き換わる現象をパラメータエラーと誤認しないためです。アプリを前面に戻した後は、以前にシステムの表示が出たことだけに頼らず、接続状態を改めて確認してください。
接続状態がオンのままであれば、システムのネットワーク構成が動作中であることを示します。ただし、それだけではすべての接続先にアクセスできることや、すべてのリクエストが選択したサーバーを経由することは確認できません。次にConnectivity Testと実際のページ表示を行い、テスト対象と実際の利用状況をそれぞれ確認してください。
STEP 04 / CONNECTIVITY TEST
まずテストを行い、次に実際にアクセスするページを開き、最後にポリシーを確認します。各段階で確認できることは異なるため、結果を組み合わせて判断してください。
現在のテスト方法に応じた接続可否を確認します。一つの結果だけで、すべてのリクエストが利用可能だと判断しないでください。
確認したいリクエストを新たに実行してください。キャッシュ済みのページだけを見て接続成功と判断しないでください。
通信量の変化と利用可能な記録を合わせて、リクエストが確認できるか、処理ポリシーが想定どおりかを調べます。
HomeでConnectivity Testをタップし、テストが完了するまで待って、成功、タイムアウト、その他のエラーのいずれかを記録します。テスト結果はSettingsのTest Methodやテスト対象によって異なります。一度のタイムアウトだけで、すべての接続が失敗したと判断しないでください。結果の数値の大小だけで設定の正否を決めるのも避けてください。まずテストが完了したかを確認し、次に実際のリクエストに応答があるかを調べます。
接続をオンにしたまま、アクセスしたいページまたはアプリを開き、リクエストを新たに実行します。古いページが表示されただけの場合より、ページ全体の読み込み、ログインの完了、新しいコンテンツの取得を確認できる方が、実際のアクセス状況を判断しやすくなります。キャッシュの可能性がある場合は、更新するか、新しいブラウジングセッションで試してください。検証中にサーバー、ネットワーク、モードを同時に変更すると、前後の違いを再現できなくなります。
その後Shadowrocketに戻り、Dataの通信量の変化を確認します。現在の画面でリクエスト記録を確認できる場合は、先ほどの接続先ドメイン名や時刻から該当する記録を探してください。通信量が増えていても、ネットワーク通信があったことしか示せず、対象のリクエストがプロキシ経由だった証明にはなりません。Global Routing、適用されたルール、最終的なポリシーも確認してください。Configでは、ルールに従って一部のリクエストがDirectになることが想定どおりの場合もあります。
Proxyでは実際のリクエストが成功し、Configに戻すと失敗する場合は、ルール、ポリシーの参照先、関連する名前解決の動作を優先して確認します。すぐにサーバー項目全体を作り直す必要はありません。反対に、どのモードでもローカルネットワークの基本的な接続に問題がある場合は、まずデバイスのネットワークを確認してください。「使用したネットワーク、選択したサーバー、モード、失敗したリクエスト」を記録しておけば、次の手順を明確にできます。
STEP 05 / DIAGNOSTICS
まず問題が読み込み、許可、接続、アクセスのどの段階で起きたかを特定します。一度に変更する項目は一つにし、再テストしてから変更を維持するか判断してください。
Subscribeに戻り、URLが末尾のパラメータまで完全にコピーされているか、改行や余分な空白がないか確認します。まずデバイスのネットワークが使えることを確認してから、同じ入口で一度更新し、具体的なエラーを確認してください。サブスクリプションの更新に成功しても、一覧の内容が利用できるとは限りません。応答内容が入口の要件に合わない場合や、ご自身が利用するサービスが停止している場合は、提供元に情報を確認してください。URLを推測で書き換えたり、元のエラーを見えにくくするために同じ内容を何度も読み込んだりしないでください。
Homeに戻って接続を再度オンにし、確認待ちのシステムダイアログが残っていないか確認します。必要に応じてデバイスのシステム設定を開き、Shadowrocketに対応するVPN構成があること、現在の接続が別のVPNに置き換えられていないことを確認してください。まず許可と接続状態を解決してから、サーバーの応答を確認します。システム接続が確立していない段階では、Ruleを変更しても通常はこの問題を解決できません。
SERVERで現在の項目の編集画面を開き、Type、Host、Port、認証情報を確認します。名前が似た別の項目を選択していないかも確かめてください。TLSを使うプロトコルでは、お手元の情報に基づいてSNI、証明書の検証、関連する通信設定も確認します。デバイスの日付や時刻が正しくないと、TLSの検証に影響することがあります。証明書エラーが発生した場合は、検証要件を下げて対処するのではなく、まずドメイン名、時刻、サーバー情報を確認してください。
現在のGlobal Routingを記録してから、一時的にProxyに切り替え、同じ接続先を再テストして元のモードに戻します。Configだけで問題が起きる場合は、Ruleの照合順序、ポリシー名、選択中の設定ファイルを優先して確認してください。ドメイン名の名前解決に問題がある場合は、既存のDNS設定を調べ、最近変更した項目を元に戻してからテストします。DNSは名前解決経路の一部を決めるもので、あらゆる接続エラーに対する万能な解決策ではありません。関連する用語はDNSとネットワーク用語をご覧ください。
Settingsを開いてTest Methodを確認し、2回のConnectivity Testで同じ方法が使われているか確かめます。さらに調べる場合は、Diagnosticsで現在利用できる診断機能を使い、発生時刻、エラーメッセージ、操作の順序を記録してください。On Demandは条件に応じて接続を開始する機能です。初回の手動確認中にこの機能を設定済みの場合は、接続状態が自動的に変化していないか注意し、自動動作を手動操作の結果と取り違えないようにしてください。
ご自身が利用するサービスの提供元に問い合わせる場合は、プロトコルの種類、問題が起きた段階、ネットワーク環境、実施済みの比較内容を伝えてください。スクリーンショットや記録を送る前に、サブスクリプションURL、Password、認証パラメータ、鍵などの機密情報を隠します。トラブルシューティングのために設定全体を公開しないでください。まずエラーメッセージと再現手順を伝えることで、問題を絞り込める場合があります。
確認後は、予定していたGlobal Routingに戻して、実際のリクエストをもう一度検証します。新しい設定が有効だと確認してから、必要な設定のバックアップを保存し、既存のサブスクリプションを元の入口から定期的に更新してください。アプリのアップデートはApp Storeから行います。アプリを再インストールしても、サーバーやルールの情報が復元されるわけではありません。体系的なトラブルシューティングについては、使い方ガイドの接続トラブルシューティングをご覧ください。