手順 01 · 接続先を準備
Add Server:サーバーの追加とサブスクリプションのインポート
まず、手元の情報がサブスクリプションリンクなのか、単一サーバーのプロトコル、アドレス、ポート、認証情報なのかを確認します。追加画面の入口は近くても、入力方法は異なります。サブスクリプションは複数の項目を取得・管理するためのものです。単一サーバーは、該当するプロトコルに沿って各項目を入力します。サブスクリプションURLのドメインをサーバーのHostとして入力しないでください。
サブスクリプションリンクがある場合:Subscribeを選択
ShadowrocketのHomeを開き、SERVERグループのAdd Serverに進みます。既存のサブスクリプションを使う場合は、TypeでSubscribeを選び、対応するURL欄にリンク全体を貼り付けます。コピー時に空白、改行、引用符が入っていないか確認してください。リンクの「?」以降はサブスクリプションへのアクセス権限の識別に使われる場合があるため、削除しないでください。自分で見分けやすいメモを入力して保存し、取得が完了するまで待ちます。
Homeに戻り、リストにインポートしたグループまたはサーバー項目が表示されていることを確認します。中身のないサブスクリプション記録だけでは不十分です。取得には、現在のネットワークからサブスクリプションURLにアクセスできる必要があります。リクエストに失敗した場合は、まずリンクが有効かを確認し、次にネットワーク環境を確認してください。更新を繰り返しても、無効な認証情報は修復されません。リンク自体の確認に代わるものでもありません。
サーバー情報がある場合:まずTypeを確認
単一サーバーの情報を受け取った場合は、Add Serverで正しいTypeを選び、提供された情報に沿ってHost、Port、必要な認証項目を入力します。スクリーンショットにあるPasswordやMethodは特定のプロトコルの項目です。すべてのタイプで同じ項目が必要とは限りません。Shadowsocks、VMess、VLESS、Trojanなどは、サーバー側の設定と一致するタイプを選んでください。名前が似ているだけで置き換えることはできません。
Hostには通常、サーバーのアドレスまたはドメインを入力します。通信パス、TLS名、その他の拡張項目が別途指定されている場合は、対応する欄に入力し、Hostに連結しないでください。Scan QR CodeでQRコードを読み取ることもできますが、読み取り後にTypeと主要項目を確認してください。Import from Cloud JSONは特定の形式を読み込む機能です。任意のサブスクリプションリンクを開くためのものではありません。
保存してHomeに戻り、項目が存在することを確認してから、使用するサーバーを選択します。この段階で完了したのは情報のインポートであり、接続成功を示すものではありません。サブスクリプション更新後に項目が変わった場合は、次の手順に進む前に選択中の項目を確認してください。サブスクリプションリンクやQRコードには認証情報が含まれる場合があります。公開スクリーンショットや公開の場に掲載しないでください。
手順 02 · 通信の処理方法を決める
Global Routing:接続モードを選択
サーバー項目を保存したらHomeに戻り、Global Routingを開きます。ここで選ぶのはリクエストの処理方法であり、サーバーのプロトコルではありません。モードは設定(Config)、プロキシ(Proxy)、直接接続(Direct)の3種類です。現在の選択を確認してから接続を開始すると、モードの不一致をサーバーの障害と誤認しにくくなります。
設定(Config):現在の設定にあるルールで振り分ける
設定(Config)を選ぶと、有効な設定内のルールに基づいてリクエストの処理方法が決まります。Configを開き、リストにファイルがあるかだけでなく、実際に使用する設定ファイルを確認してください。編集画面にはGeneral、Rule、Hosts、URL Rewriteなどのセクションがあります。スクリーンショットは各項目の位置を確認するためのものです。初回接続時にすべてのセクションを編集する必要はありません。
Ruleの照合順序は結果に影響します。先に一致したルールが適用されると、通常、それ以降のルールはそのリクエストの処理方法の選択に関与しません。FINALは、それまで一致しなかったリクエストを処理します。DIRECTは直接接続、REJECTは拒否を意味します。プロキシやポリシーグループを指定するルールには、利用可能な接続先も必要です。PROXYと表示されていても、アプリがサーバーやポリシーグループを自動で補うわけではありません。
用途が明確な設定ファイルをすでにお持ちの場合は、内容を維持したまま、現在有効か、ポリシーに対応する項目があるかを確認してください。初回接続時にDNS、Rule、URL Rewriteを同時に変更しないでください。問題が起きた際に、どの変更が原因か特定しにくくなります。サブスクリプションと設定ファイルは別のものです。前者はサーバー項目を更新でき、後者は主にリクエストの処理方法を決めます。
プロキシ(Proxy)と直接接続(Direct):条件を明確にして比較
プロキシ(Proxy)では、通常このモードで処理されるリクエストに選択中のプロキシを使用します。サーバー自体が動作するかを一時的に確認する際に役立ちます。ただし、システム上のすべての通信が必ずプロキシ経由になるわけではなく、システムが保持する通信や関連設定が経路に影響する場合があります。Proxyではアクセスでき、Configではできない場合は、サーバー情報をすぐに入力し直すのではなく、設定のルールとポリシーの対応関係を確認してください。
直接接続(Direct)では、該当するリクエストを選択中のプロキシサーバーを経由せずに接続します。現在のネットワークで直接アクセスできるか比較する際に使えます。ただし、Directに切り替えてもHome上部の接続スイッチはオフになりません。クライアントの接続を終了する場合はHomeに戻り、スイッチをオフにして状態を確認してください。Global Routingの変更だけでは接続は終了しません。
初回の確認ではモードを一つに固定し、選択した内容を記録してから接続します。ルールの詳細は技術リファレンスをご覧ください。モードのよくある誤解についてはよくある質問をご確認ください。このガイドでは「現在何を選び、なぜ選んだか」を明確にします。すべてのルールを一度に設定する必要はありません。
手順 03 · システム接続を確立
Home:スイッチをオンにして許可を確認
Homeに戻り、SERVERグループで使用するサーバーが選択されていることを確認し、Global Routingに表示されたモードを確認します。サーバーの選択、モードの選択、接続の開始はそれぞれ別の操作です。リストにサーバーが表示されていても選択済みとは限りません。サーバーを選択していても、システム接続が有効とは限りません。
Home上部の接続スイッチをオンにします。初回接続では、システムからShadowrocketによるVPN構成の追加を求められる場合があります。表示内容を読み、操作を開始したのが直前に開いたShadowrocketであることを確認したうえで、システムの手順に従って許可し、デバイス認証を完了してください。この許可はシステムのネットワーク構成を作成するためのもので、サブスクリプションの認証やサーバー情報の確認に代わるものではありません。
システムの確認を終えたらHomeに戻り、上部の状態がNot Connectedから接続済みに変わったか、スイッチがオンのままかを確認します。システムのステータス領域に表示される接続アイコンは、デバイスや画面によって異なる場合があります。ステータスバーのアイコンだけでなく、アプリの状態と実際のアクセスを合わせて判断してください。
許可を取り消した場合は、アプリに戻って接続をもう一度試し、表示されるシステムの案内に従ってください。組織の管理下にあるデバイスでは、新しいVPN構成の追加が制限されている場合があります。この制限はサーバーのパスワードを変更しても解決しません。まずデバイスで操作が許可されているか確認してから、アプリ内の設定を調べてください。
接続スイッチをオンにしてすぐオフになる場合は、まず状態の変化と表示されたメッセージを記録し、システムの許可に関する問題かサーバー接続の問題かを切り分けます。状況を記録しないまま複数の項目を続けて切り替えないでください。現在のサーバーとモードを維持したまま接続を一度だけ再試行し、同じエラーが起きるか確認してから、後述の失敗箇所の確認に進みます。
iPadでも同じ順序で操作できます。ウィンドウサイズによってレイアウトは変わる場合があります。Home、SERVER、Global Routing、上部の接続スイッチを確認すれば、スクリーンショットに合わせてデバイスの表示設定を変える必要はありません。接続状態を保ち、Connectivity Testと実際の宛先で結果を確認します。
手順 04 · 状態、テスト、実際のアクセスを切り分ける
Connectivity Test:動作を確認
サーバーとモードはそのままにして、HomeでConnectivity Testを実行します。テストが完了するまで待ってから結果を確認してください。テストの成功は、その時点の条件でテスト方法と宛先に到達できたことを示すだけです。すべてのWebサイト、プロトコル、継続的な通信が正常に動作する保証にはなりません。失敗した場合もテスト方法を踏まえて判断し、結果だけを見てサブスクリプション全体を削除しないでください。
次に、普段アクセスする宛先を開き、画面に表示済みのページを見るだけでなく、最後まで読み込まれるか確認します。ブラウザーやアプリにはキャッシュが残る場合があり、古い内容が表示されても新しいリクエストが成功したとは限りません。ページを再読み込みするか、まだ開いていないコンテンツにアクセスし、画像やテキスト、その後のリクエストも読み込まれるか確認してください。
設定(Config)モードでは、プロキシ経由になる想定の宛先と、直接接続になる想定の宛先をそれぞれ少なくとも一つ確認します。どちらかが想定と異なる場合はDataを開き、画面で確認できるリクエストや通信の記録を調べてください。ルール、ポリシー、エラー情報が記録されていれば、リクエストが想定した経路に到達したか判断する材料になります。通信量が増えたことだけでは、特定の宛先が指定ルールに一致したとは判断できません。
| 確認できた状態 | 優先して確認する項目 | 次に行うこと |
|---|---|---|
| 接続中、テスト成功、宛先も正常に読み込まれる | 現在のサーバー、モード、設定が想定どおりか | この設定の組み合わせを維持し、以後の比較基準にする |
| テストは成功するが、一部の宛先が読み込まれない | 宛先に対応するルール、DNS、アプリのキャッシュ | 条件を一つだけ変更し、同じ宛先を再テストする |
| Proxyではアクセスできるが、Configでは想定どおりにならない | 現在の設定、Ruleの順序、ポリシーの接続先 | サーバーをすぐ作り直さず、Configを確認する |
| テストは失敗するが、実際の宛先にはアクセスできる | Test Methodとテスト宛先への到達性 | テスト結果の数値だけでなく、実際のアクセス記録も確認する |
Wi-Fiとモバイル通信を比較する場合は、まず現在の結果を記録し、ネットワークを切り替えて同じテスト宛先、サーバー、モードで再試行します。ネットワークの切り替えと同時にサブスクリプションを更新したり設定を変更したりすると、比較の基準が失われます。テスト中は通信が発生する場合があります。モバイル通信を利用する前に、ご自身のデータ通信の利用条件をご確認ください。
設定の組み合わせが有効だと確認できたら、必要なルールやOn Demandの条件を一つずつ戻します。変更を一つ加えるごとに、実際のアクセスを再確認してください。問題が起きた場合は、最初からやり直さず、直前に確認済みの設定に戻せます。見慣れない記録項目は用語集で確認してください。
手順 05 · 発生箇所に応じて対処
Settings:よくある失敗の確認
トラブルの確認では、サブスクリプションを追加できない、スイッチがオンのままにならない、接続中だが宛先にアクセスできない、のどの段階で問題が起きたかを明確にします。それぞれ必要な確認項目が異なります。まず直前に完了した手順に戻り、完了条件を満たしているか確認してから先へ進むと、すべての設定を一度にリセットするより原因を特定しやすくなります。
追加できない場合:入力内容とサブスクリプションの応答を確認
サブスクリプションの更新でエラーが出た場合は、リンク全体、現在のネットワーク、サブスクリプションの有効性を確認します。リンクにアクセスできても項目が追加されない場合は、応答内容がアプリに対応するサブスクリプション形式か確認してください。ログインページ、エラーページ、閲覧用の説明ページはサーバー設定データではありません。サーバーを個別に保存できない場合は、Typeに必要な項目とPortが正しく入力されているか確認します。
既存のサブスクリプション内のサーバーに変更があった場合は、更新後に選択中の項目を再確認し、古い項目を使い続けないようにしてください。サブスクリプションとConfigファイルは別々に確認します。一方の更新が成功しても、もう一方が同期されたことにはなりません。情報が有効か確認する必要がある場合は、現在利用しているサービスの提供元に問い合わせ、必要最小限のエラー内容だけを伝えてください。
接続できない場合:許可、認証、デバイスの時刻を確認
スイッチをオンにできない場合は、システムの許可が完了しているか、デバイスに管理上の制限がないかを確認します。スイッチはオンになるもののサーバーを利用できない場合は、Host、Port、認証情報、通信方式、TLS関連の項目を確認してください。プロトコルで必要な名前やパスが一致しない場合も、接続に失敗することがあります。項目の誤りを隠すために、証明書の検証を安易に無効にしないでください。
証明書や認証で時刻が関係する場合は、デバイスの日付と時刻が正しいか確認します。ほかのネットワーク接続設定も有効な場合は、実際にどの設定が動作しているか確認してから比較してください。初回の切り分けではネットワーク環境をできるだけ固定し、接続の切り替えと設定変更が重ならないようにします。
アクセスできない場合:Test MethodとOn Demandを確認
Settingsを開き、Test Methodで現在のテスト方法を確認します。方法によって確認する対象が異なるため、遅延の数値をWebページの読み込み速度とみなすことはできません。異なるテスト方法の数値を単純に比較するのも適切ではありません。テストだけに問題があり実際の宛先にはアクセスできる場合は、まずテスト条件を確認します。実際の宛先にもアクセスできない場合は、ルールとサーバーの経路を確認してください。
手動で接続をオフにした後に自動で再接続する場合や、Wi-Fiの切り替えで接続状態が変わる場合は、On Demandが有効か、その条件がどう設定されているか確認します。初回接続が安定するまでは自動接続を一時的に無効にし、Homeから手動で接続を確認してください。基本の流れが正常に動作した後で、必要な条件を一つずつ追加します。自動再接続をスイッチの故障と誤認して、サーバー設定を繰り返し変更しないでください。
原因を特定できない場合は、SettingsのDiagnosticsを確認し、今回の失敗時刻に対応する必要な情報を残してください。共有する前に、サブスクリプションリンク、認証項目、QRコード、個人を特定できるネットワーク情報を隠します。選択したモード、ネットワークの種類、失敗した手順、実施済みの個別テストを記載すれば十分です。設定全体を公開する必要はありません。