1. Add Server / Subscribe：サーバーの追加・インポート
まず、手元の情報の種類を確認します。サーバー一覧を更新するURLがある場合は、サブスクリプションとしてインポートします。サーバーのアドレス、ポート、プロトコル、認証情報が個別にある場合は、サーバーを追加します。どちらもHomeから操作します。サブスクリプションURLをサーバーアドレス欄に入力したり、サーバー情報だけのテキストをサブスクリプションURLとして送信したりしないでください。
サブスクリプションURLがある場合：Subscribeを選択
Shadowrocketを開いてHomeに移動し、右上の追加ボタンからAdd Serverを開きます。TypeでSubscribeを選び、URLにサブスクリプションURL全体を入力します。Remarksには「個人用」など、見分けやすい名前を付けます。名前はアプリ内で識別するためのもので、URLの修復やサーバーの設定変更はできません。保存前にURLの先頭、パス、クエリパラメーターがすべて含まれているか確認してください。特に疑問符以降を省略しないようにします。
保存後にHomeへ戻り、サブスクリプションの更新が完了するまで待ち、該当するグループにサーバーが表示されることを確認します。サブスクリプション名だけが表示され、グループ内にサーバーがない場合は、インポート成功とは限りません。更新中でないか、リクエストエラーが表示されていないかを確認し、元のURLを見直してください。ブラウザで開いたときにテキストやエンコードされた文字列が表示されるサブスクリプションURLもあります。通常のWebページのように表示されないことだけを理由に、URLが無効だと判断しないでください。
メッセージや書類で受け取った情報をコピーする場合は、末尾の空白、改行、日本語の句読点、途中で切れたパラメーターに注意してください。サブスクリプションURLにはアクセス用の認証情報が含まれることがあります。URL全体を公開スクリーンショット、記事のコメント、テスト記録に載せないでください。有効性の確認は、同じサブスクリプションを何度も追加するのではなく、利用中のサービスの窓口にお問い合わせください。
サーバー情報が個別にある場合：プロトコルに沿って入力
同様にAdd Serverを開き、Typeで情報に指定されたプロトコルを選択してから、サーバーアドレス、ポート、認証情報を入力します。必要な項目はプロトコルによって異なります。パスワード、識別子、通信方式、TLS関連の設定は互いに置き換えられません。元の情報に従って入力し、不明な項目を空欄にしたり、別のサーバーの設定を流用したりしないでください。
サーバーアドレス欄には通常、指定されたホスト名またはIPアドレスだけを入力します。ポートは専用の欄に入力し、パスを含むWebアドレス全体を貼り付けないでください。インポート可能なサーバーURLやQRコードを受け取っている場合は、アプリの該当するインポート機能またはScan QR Codeを使用できます。インポート後は、名前だけで判断せず、項目を開いてプロトコル、アドレス、ポートを確認してください。
保存してHomeに戻ったら、使用するサーバーを選び、選択中のマークを確認します。一覧に複数の項目があっても、同時に通信を処理するわけではありません。初回テストでは一つだけ選び、名前を控えておきます。その後のテストとアクセス確認も同じサーバーで行ってください。この段階ではOn Demandを有効にせず、自動接続の条件が手動確認に影響しないようにします。
2. Global Routing：通信のルートを選択
サーバーをインポートしたら、次に通信の処理方法を選びます。HomeでGlobal Routingを開き、現在の選択を確認してください。3つのモードは設定（Config）／プロキシ（Proxy）／直接接続（Direct）です。変更されるのはルーティングの判断方法であり、サーバーのパスワードを修正したり、無効なサブスクリプションを有効にしたりするものではありません。
設定（Config）：現在の設定に基づいて処理
設定（Config）では、現在有効な設定のルールに従って通信を処理します。Configを開き、実際に有効になっているファイルを確認してから、含まれるルールとポリシーを確認してください。サーバーのサブスクリプションをインポートしただけでは、すべての接続先に適切なルールが設定されているとは限りません。サーバー一覧とルール設定は役割が異なるため、それぞれ確認が必要です。
ルールを確認するときは、マッチ条件、順序、最後の処理方法に注目します。DOMAIN-SUFFIXはドメインの末尾一致、IP-CIDRはIPアドレスのネットワーク範囲との一致に使います。FINALは、それ以前のルールに一致しなかった場合に適用するポリシーです。以下はルール構文の例であり、そのままインポートできる完全な設定ではありません。example.comは例示用ドメインで、実際のテスト対象を示すものではありません。
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
FINAL,PROXYPROXYとDIRECTはポリシーのキーワードであり、サーバー名ではありません。PROXYはプロキシポリシーで処理し、DIRECTは直接接続します。ルールやポリシーグループで別の指定がある場合は、実際に選択されている内容も確認してください。ルールが存在するだけで、通信が必ずそのルールに一致するとは限りません。先行するルール、有効な設定ファイル、通信先のドメインなども結果に影響します。
プロキシ（Proxy）：プロキシ経路を個別に確認
プロキシ（Proxy）では、対象となる通信を現在のプロキシポリシーに渡します。初回のトラブル対処では、一時的にこのモードを使うと、「サーバーが動作するか」と「ルールが想定どおり適用されるか」を分けて確認できます。ただし、すべてのアプリの動作を保証するものではありません。システム通信の範囲、現在のネットワーク、接続先サービスの状態もアクセス結果に影響します。ルールに従った振り分けに戻す場合は、設定（Config）に戻してください。
直接接続（Direct）：直接アクセスの基準を確認
直接接続（Direct）はプロキシを介さず接続するため、プロキシ経路が有効になっている証拠にはなりません。現在のネットワークから接続先へ直接アクセスできるかを確認する際に使います。直接接続（Direct）に切り替えてページが表示されても、その回の直接アクセスが成功したことを示すだけで、サーバー情報が正しいとは限りません。次に接続する前にGlobal Routingをもう一度確認し、一時的なテストモードのままにしないようにしてください。
3. Home：接続を開始してシステムの許可を行う
Homeに戻り、使用するサーバー、Global Routing、現在のネットワークを順に確認します。初回は同じネットワークを保ち、たとえば同じWi-Fi上で一連のテストを行ってから、モバイル通信を個別にテストしてください。サーバーを選ぶ前に接続を何度も切り替えたり、サーバー、ネットワーク、ルールファイルを同時に変更したりしないでください。問題が起きたときに原因を特定しにくくなります。
Home上部の接続スイッチをオンにします。初回接続時は、システムからVPN構成の追加を求められることがあります。これはアプリがシステムのネットワーク接続を確立するために必要な許可です。画面に表示されたアプリ名と説明を確認し、今回の操作で表示されたことを確かめてから、システムの指示に従って承認と認証を行ってください。この操作はシステム画面で完了します。デバイスのロック解除情報やAppleアカウントの認証情報をサーバー項目に入力する必要はありません。
Shadowrocketに戻り、スイッチと接続状態が維持されているか確認します。スイッチがすぐにオフに戻る場合は、システムの許可を取り消していないか、未対応の通知がないか、別のVPN構成が使用中でないかを確認してください。システムのSettingsでVPNの状態を確認してから、アプリに戻って再試行できます。スイッチをオンのままにするために、用途が分からないシステム構成をむやみに削除しないでください。
接続状態になったことは、システムの接続経路が起動したことを示すだけで、選択中のサーバーからすべての接続先にアクセスできることを保証しません。パスワード、ポート、通信設定に誤りがあれば、実際の通信に失敗することがあります。許可を完了したら、ステータスバーの表示だけで判断せず、次のセクションでテストしてください。iPhone・iPadのステータスバーの表示はデバイスやシステム画面によって異なるため、アプリとシステムの接続状態を照合してください。
テストを終了するときは、Homeで接続スイッチをオフにし、システム接続が終了したことを確認します。その後、自動的に再接続される場合は、On Demandが有効になっていないか確認してください。手動での初回手順が完了するまでは自動接続の条件を使わないことで、「オフにした直後に再接続する」といった動作による誤認を減らせます。
4. Connectivity Test：接続と通信を確認
確認は3段階で行います。サーバーテストの結果、システム接続の状態、実際の通信が想定したポリシーで処理されたかです。それぞれ確認できる内容が異なり、互いに代用はできません。まずHomeでConnectivity Testを実行し、選択中のサーバーをテストします。結果が安定してから実際にアクセスしてください。テスト中にサーバーを切り替え、前の結果を別のサーバーの結果として扱わないようにします。
Connectivity Testの結果は、テスト方法と接続先によって異なります。数値が表示されても、そのテストで応答が得られたことを示すだけで、すべてのWebページやアプリが使えるとは限りません。timeoutの場合も、テスト方法と接続先を考慮する必要があり、一度の結果だけで全サーバーが無効だと判断できません。初回は現在選択中のサーバーを中心に確認し、一覧全体の結果を混同しないようにしてください。
次にブラウザを開き、現在のネットワークで通常表示できると分かっているページにアクセスしてから、ポリシーを確認したい接続先にもアクセスします。確認のたびに新しいリクエストを送信し、読み込み済みのページやキャッシュだけを見て判断しないでください。「接続先、ネットワーク、サーバー、Global Routingのモード」を記録すると、「使える／使えない」だけの記録よりも次のトラブル対処に役立ちます。
設定（Config）を使う場合は、アプリのDataで確認できる接続記録から、直前に送信した通信を探し、接続先、ルール、ポリシーを確認します。記録によって確認できる情報は異なります。ポリシーの詳細が表示されない場合は、推測で補わないでください。現在有効な設定が使われていること、また通信に適用されたDIRECT、PROXY、または設定で指定された別のポリシーが意図どおりかを確認します。
プロキシ（Proxy）ではアクセスできるのに設定（Config）で想定どおりにならない場合は、まずConfigに戻ってルールの順序とポリシーの選択を確認してください。すぐにサーバーの認証情報を変更しないでください。どちらのモードでも失敗し、直接接続（Direct）では確認用ページを開ける場合は、サーバーと接続経路を確認します。この比較で原因を絞り込めますが、結論を出すには接続先とエラー記録も確認してください。
5. よくある失敗：順番に原因を確認
最初に失敗した手順から確認します。一覧が空の場合はインポート、サーバー項目があるのにテストに失敗する場合はサーバー設定、接続後に一部の接続先だけ問題がある場合はルールと接続先を確認します。元の設定と項目を残し、変更は一度に一つだけにして、再テスト後に結果を記録してください。連続して削除、再インポート、ルール変更を行うと、もともと単純だった問題の再確認が難しくなります。
サブスクリプションの保存後も一覧が空
Subscribeの項目に戻り、URL全体が入力されているか確認します。アカウントページや案内ページではなく、サブスクリプションURLをコピーしたことを確かめてください。更新が完了しているか、現在のネットワークからURLにアクセスできるかを確認し、利用中のサービスの窓口でサブスクリプションの状態と内容を確認します。更新エラーや空の内容が返された場合、同じURLを再追加しても通常は解決しません。リクエスト時と内容の解析時のどちらで失敗したかを確認してください。
更新前に使用できていた項目がある場合は、情報を残し、一覧を再取得するために一括削除しないでください。手動更新後、ネットワーク切り替え後、アプリの再起動後のどの時点で失敗したかを記録すると、更新のタイミングが関係しているかを判断しやすくなります。詳しくはサブスクリプション更新後にサーバー一覧が空になる場合の確認手順をご覧ください。
Connectivity Testでtimeoutが表示される
まず、テスト対象が現在選択中のサーバーであることを確認し、アドレス、ポート、プロトコル、認証情報、通信設定を一つずつ見直します。デバイスの日付と時刻が正しいかも確認してください。特にTLSや時刻に関連する認証を使う場合、システム時刻の誤りが失敗の原因になることがあります。別のネットワークでもう一度テストし、現在の接続環境とサーバー自体の問題を切り分けます。ネットワークを切り替えた後も、同じサーバーと同じテスト対象を使ってください。
推測でポートを何度も変えたり、認証を無効にしたり、TLS設定を変更したりしないでください。設定値はお手元のサーバー情報に従い、サービスの状態は利用中のサービス窓口に確認してください。記録方法の詳細はサーバーのtimeout・接続失敗への対処をご覧ください。手順に沿って結果を記録します。
接続済みだがWebページを開けない
まず、元のネットワークで確認用ページにアクセスできることを確かめます。Wi-Fiのログインが完了していない、モバイルデータ通信が利用できないといった基本的な問題を除外してください。次にGlobal Routingを確認します。直接接続（Direct）の場合、通信はプロキシポリシーで処理されません。設定（Config）の場合は、有効なファイルと適用されるポリシーを確認します。DNS関連のエラーが明確に確認できた場合に限り、DNS設定を調べてください。サーバー、ルール、DNSを同時に変更しないようにします。
特定の接続先だけ失敗する場合は、ほかの利用可能な接続先と比較し、その通信の記録を確認してください。接続先サービスの障害、ルールの適用違い、サーバー側のアクセス制限、認証エラーでは、結果が異なることがあります。すべてを「アプリが接続されていない」とまとめないでください。特定のアプリだけに問題がある場合は、そのアプリから新しい通信を発生させます。既存の接続やキャッシュにより、結果の反映が遅れる場合があります。
設定変更後に結果が分からなくなった
最後に状態を明確に記録した時点に戻します。元のサーバー、Global Routing、設定ファイルを復元し、今回追加したOn Demandの条件をオフにしてから、動作確認の手順をもう一度行います。一時的に成功しただけで設定が安定したと判断しないでください。同じ条件で繰り返し確認してから、ネットワークを切り替えた場合の動作を個別に調べます。
トラブル対処の記録は、時刻、ネットワークの種類、サーバーのローカル名、モード、エラーの内容にとどめてください。ほかの人に状況を伝える前に、サブスクリプションURL全体、パスワード、キー、その他の認証情報を隠します。設定の一部を共有する場合も、これらの情報が含まれていないか確認してください。購入、ストアからの入手、機種変更時の復元についてはインストールガイドをご覧ください。アプリの入手に関する問題と、既存サーバーへの接続問題を混同しないようにしてください。