Add Server：サーバーの追加またはサブスクリプションの読み込み
この段階では、Home に選択可能なサーバー項目を表示することを目指します。接続スイッチはまだオンにしません。まず、手元の情報がサーバー一覧を更新するサブスクリプションリンクなのか、個別サーバーのプロトコル、アドレス、ポートなどのパラメーターなのかを確認します。情報の種類によって入力方法が異なります。サブスクリプションリンク全体を Host に入力したり、個別サーバーのアドレスを Subscribe リンクとして扱ったりしないでください。
サブスクリプションリンクがある場合：Type で Subscribe を選択
Home に移動し、右上の + をタップして Add Server を開き、Type をタップして Subscribe を選択します。追加画面に戻り、該当するリンク入力欄にサービス提供元から取得した完全なリンクを貼り付けて保存します。入力の前後に空白や改行を加えないでください。チャットアプリ経由で転送されたリンクの場合、表示文字列だけをコピーしていないか、末尾のパラメーターが欠けていないか確認します。
保存後、Home に戻り、サブスクリプションの読み込みが終わるまで待ちます。内容の取得に成功すると、リストに該当するグループまたはサーバー項目が表示されます。まずリストが空でないことを確認し、次に項目を選択できるか確認します。サブスクリプションの記録だけが表示され、サーバーが見つからない場合は、同じサブスクリプションを何度も作成しないでください。基本ネットワークが利用できること、リンクが有効であること、提供元の内容形式が読み込み方法に適合していることを確認します。
個別サーバーの情報がある場合：プロトコルに応じた項目を入力
同様に Home の + から Add Server を開き、Type で手元の情報に記載されたプロトコルを選択します。スクリーンショットは Host、Port、Password、Method がある追加画面です。ほかの Type では項目が異なる場合があるため、切り替え後に実際の画面を確認してください。Host にサーバーアドレス、Port にポートを入力し、Password や Method などは手元のパラメーターどおりに入力します。名称が似ている項目を独自に置き換えないでください。
パラメーターに UUID、TLS、転送方式、パスが含まれる場合も、項目ごとに確認します。サーバー名は識別用であり、接続パラメーターの代わりにはなりません。画面の Scan QR Code は、対応する既存の QR コードの読み取りに使えます。Import from Cloud JSON は別の情報読み込み方法です。任意のテキストや通常のサブスクリプションリンクをこの形式として読み込まないでください。手元の情報に合う方法を1つ選べば十分です。すべての方法を試す必要はありません。
次の手順に進む前に：Home に戻り、SERVER に対象の項目があり、使用する項目を識別できることを確認します。リストが空の場合はこの手順で読み込みの問題を確認してください。情報が読み込まれていない問題を解決するために Global Routing を変更しないでください。
Global Routing：リクエストの処理方法を選択
サーバー項目を用意してから、リクエストの処理方法を決めます。Home で Global Routing をタップし、Config、Proxy、Direct の3つのモードを確認します。ここで選ぶのはリクエストの処理方法であり、サーバーを再度読み込む操作ではありません。モードを切り替えても、誤ったアドレスやパスワード、無効になったサブスクリプションは修正されません。
- Config：現在の設定ファイルのルールに従って、リクエストに適用するポリシーを決定します。ルールを用意し、リクエストごとに経路を分けたい場合に適しています。
- Proxy：通常このモードで処理されるリクエストに、プロキシ経路を使用します。現在選択中のサーバーが利用できるかを比較確認できます。すべてのシステムリクエストが必ず同じ経路を通るという意味ではありません。
- Direct：直接接続する経路を使用します。対象のリクエストをプロキシサーバー経由にする場合は、誤ってこの項目を選択していないか確認してください。
日常的に Config を使用する前に、画面下部の Config を開き、目的の設定ファイルが選択されていることを確認します。サブスクリプションは通常サーバー一覧の提供や更新に使われ、設定ファイルはルールや関連設定を管理します。Subscribe を読み込んでも、意図したルールが同時に読み込まれるとは限りません。スクリーンショットにある General、Rule、Hosts、URL Rewrite、HTTPS Decryption は設定編集の各セクションです。今回の使い方では、個別に変更する必要はありません。
ルールを理解するには、まず「上から順に照合し、一致したポリシーで処理する」と覚えてください。たとえば DOMAIN-SUFFIX はドメインのサフィックス照合、GEOIP は該当する IP 地理データの照合、FINAL は前のルールに一致しない場合の最終処理に使います。PROXY、DIRECT、REJECT はそれぞれ異なる処理ポリシーです。同じサーバーを選んでいても、リクエストによって経路が異なる理由になります。
まずは既存の設定を維持し、接続テストのために Add Rule をむやみに追加しないでください。また、用途がわからないまま HTTPS Decryption を有効にしないでください。モードと照合の仕組みを詳しく知りたい場合はプロキシモードの説明をご覧ください。App Store からの入手、正規版の確認、アカウントに関する情報は正規版ガイドにまとめています。モードを選んだら Home に戻り、接続を開始します。
Home：項目を選択して接続を開始
Home に戻り、SERVER グループで使用するサーバーを選択します。サブスクリプションのグループ名と実際のサーバー項目が同時に表示されることがあります。グループを展開しただけではなく、目的の項目が選択されていることを確認してください。サブスクリプションを更新したばかりの場合は、項目が変わっている可能性があるため、接続前に選択状態を再確認します。
Global Routing を確認したら、Home 上部のスイッチをオンにします。初回接続時は、システムから VPN 構成の追加を許可するよう求められる場合があります。現在の操作が Shadowrocket からのものであることを確認し、システムの案内に従って許可してください。デバイスのパスコードや認証が必要な場合があります。許可が完了する前にスイッチを何度も切り替えないでください。許可後にアプリへ戻り、上部の Not Connected 表示が変わったか、スイッチがオンのままか確認します。
オンにしてもすぐにオフに戻る場合は、まずシステムの許可が完了しているか確認し、明確なエラーメッセージがあれば内容を確認します。この場合、原因が必ずサーバー回線にあるとは限りません。アプリのローカル接続設定が作成されていない、システムの操作がキャンセルされた、デバイス上の接続設定が干渉しているなどの理由で、接続が開始されないことがあります。まずメッセージの原文を記録し、一度に複数の項目を変更しないでください。
上部に接続中と表示されれば接続設定が有効になっていますが、それだけでサーバーやすべての対象リクエストが正常とは判断できません。サーバーパラメーターの誤り、接続先に到達できないこと、ルールの選択違いは、後続の確認で切り分けます。次に項目の疎通と実際のアクセス結果を個別に確認します。
初めて使う場合は、手動で接続を確認できるよう、On Demand の既存設定を変更しないでください。手動でスイッチを切り替えたときの状態変化を確認しやすくなります。今回の確認を終える際は、まず Home で手動切断します。その後、自動的に再接続する場合は Settings で On Demand の条件を確認してください。
Connectivity Test：接続と実際のリクエストを確認
確認は2段階で行います。まず選択中の項目で現在のテストが完了するかを確認し、次に実際に使うアプリやページが動作するかを確認します。Home で Connectivity Test を実行し、テストが終わるまで待って、結果または失敗のメッセージを確認します。テスト方法によって結果の意味が異なるため、1つの数値だけで全体の状態を判断しないでください。1回の失敗から、すべてのサーバーが利用できないと決めつけることもできません。
次に、実際に使うアプリやページを開き、同じページを再読み込みするなど、簡単で繰り返し可能な操作を行います。同じサーバーと同じネットワークを使い、確認中に Wi-Fi からモバイル通信へ切り替えないでください。結果が変わった理由を判断しにくくなります。開いたままのページにはキャッシュが表示されることがあります。必要に応じて、以前読み込まれた画面を見るだけでなく、リクエストを再実行してください。
Connectivity Test の結果が表示されても、実際のアプリにアクセスできない場合は Global Routing のモードを確認します。Config はルールに従って経路を分けます。ある対象が DIRECT に一致している場合、ほかの対象がプロキシ経由だからといって、その対象もプロキシ経由とは限りません。同じ対象で一時的に Proxy を使って比較し、テスト後に元の Config に戻して該当ルールを確認します。比較テストの目的は経路の違いを特定することであり、特定のモードを長期間使うことではありません。
実際のアプリが正常に使える一方で特定のテストが失敗する場合は、Settings の Test Method とテスト条件を確認してください。すぐにサーバーを削除する必要はありません。反対に、テストに成功しても特定の機能に問題がある場合は、対象、ネットワーク、リクエストの種類に範囲を絞ってください。「すべての機能が正常」と結論づけることはできません。再確認できるテスト記録には、選択した項目、Global Routing、基本ネットワーク、具体的な操作の成否を含めます。サブスクリプションリンクやパスワードは記録する必要はありません。
Settings：失敗した箇所に応じて確認
「基本ネットワーク → 情報が正しいか → 現在のモード → 対象のリクエスト」の順で確認します。一度に変更するのは1項目にし、変更後は確認手順に戻って同じテストを繰り返します。改善しない場合は、次の項目を確認する前に元の値へ戻してください。使用可能な設定を保ち、問題がどの段階で発生するかを把握しやすくなります。
読み込み後にサーバー項目が表示されない
まず接続をオフにした状態で基本ネットワークが使えることを確認します。次にリンクが完全であること、Type で Subscribe を選んだこと、リンクの有効期限が切れていないことを確認してください。サブスクリプションの状態やアクセス制限については、サービス提供元に確認します。Host を変更したり、リンクのパラメーターをむやみに入れ替えたりしてサブスクリプションを「修正」しようとしないでください。同じ記録を繰り返し追加することも避け、確認しやすいように1つ残してから更新を確認します。
項目はあるが、接続またはテストに失敗する
手動で追加したサーバーの場合は、Type、Host、Port、認証項目を1つずつ確認します。TLS や特定の転送パラメーターが必要な場合は、手元の情報と照合してください。サブスクリプションから読み込んだ項目の場合は、まず更新してから再選択します。システム時刻が正しいことを確認し、Wi-Fi とモバイル通信での結果も区別します。特定の項目だけ失敗する場合は、手元にある別の記録と比較できますが、名称が似たパラメーターを組み合わせて試さないでください。
接続中だが、一部のアプリだけに問題がある
まず Global Routing と Config を確認し、対象が PROXY、DIRECT、REJECT のどのルールに一致する想定か確認します。特定のリクエストだけに問題がある場合は、現象を記録してから関連設定を確認してください。DNS、TCP、UDP など複数の項目を同時に調整しないでください。Settings に設定項目があるからといって、初回利用時に変更が必要とは限りません。既知の設定を維持するほうが、差異を特定しやすくなります。
自動再接続が起きる、またはテスト結果を判断しにくい
Settings で On Demand を開き、現在のネットワークに該当する自動接続条件があるか確認します。手動で切断した後に再び接続状態になった場合は、サーバーを何度も削除するのではなく、まずこの設定を確認してください。テスト結果と実際のアクセスが一致しない場合は、Test Method を確認して現在のテスト内容を把握し、同じネットワークに戻って再度実行します。
原因を特定できない場合は、Diagnostics を開いて利用可能な診断情報を確認します。エラーの原文、発生した手順、再現可能な操作を記録してください。外部に共有する前に、サブスクリプションリンク全体、認証情報、QR コード、その他の個人情報を削除します。診断情報は問題の範囲を絞るためのものであり、サーバーの状態をサービス提供元に確認する代わりにはなりません。
最終的に、問題がどの段階にあるかを明確にします。情報が読み込まれていない、システムの許可が完了していない、サーバー接続に失敗している、またはリクエスト経路が想定と異なる、のいずれかです。読み込みの問題は手順 01、ルールの問題は手順 02に戻って確認します。記録を残さず、すべての項目を最初から変更しないでください。
