Shadowrocket
サブスクリプション・サーバー管理

Subscribeの入口とサブスクリプションの種類

サブスクリプションURLは、1台のサーバーの接続先ではなく、複数の接続情報を取得するための入口です。追加すると、通常は取得元のサブスクリプションと、そこから読み込まれたサーバー項目の両方がアプリに保存されます。取得元は次回の更新先を決め、サーバー項目は現在の接続に使うパラメータを決めます。個々のサーバーを編集しても、サブスクリプションの取得元が変更されるわけではありません。反対に、サブスクリプションURLを変更しても、既存の項目がすぐにすべて置き換わるとは限りません。まずこの違いを把握すると、問題が取得、解析、接続のどの段階で起きているか判断しやすくなります。

手元のリンクから追加先を判断する

手元の情報がサーバーサブスクリプションなのか、ルールを含む設定ファイルなのかを確認してください。URLがHTTPSで始まるだけでは区別できません。通常のWebページ、サブスクリプションの応答、設定ファイルはいずれもHTTPSを使えます。ファイル名から推測せず、手元の情報に記載された用途を確認してください。HomeでAdd Serverを開き、Subscribeを選ぶ手順はサーバーサブスクリプションの追加に使います。ConfigのSubscribeは設定ファイルのサブスクリプション用です。実際の画面表示に従ってください。名前は似ていますが、サーバー一覧とルール設定は別の種類の情報です。

1. 手元のサブスクリプションURLを末尾までコピーし、先頭、末尾、クエリパラメータが途切れていないか確認します。メッセージ中の引用符や改行が混ざらないようにしてください。
2. HomeでAdd Serverを開き、TypeからSubscribeを選びます。URL欄にアドレスを入力し、見分けやすい名前を付けます。
3. 保存後、Homeに戻り、サブスクリプションのグループとサーバー項目が表示されるか確認します。内容を確認してから項目を1つ選び、接続をテストしてください。
4. 手元の情報がルール設定のサブスクリプションであることを確認できた場合は、ConfigでSubscribeを選びます。追加後、実際に選択されている設定ファイルも確認してください。

保存と取得を別々に確認する

フォームを保存できたということは、入力内容がアプリに受け付けられたというだけで、接続先から解析可能な内容を取得できたとは限りません。保存後にサーバー項目が表示されない場合は、まずリクエストエラーの有無を確認し、次にURLが完全か確認してください。ログインページ、案内ページ、アクセスエラーの文面が返ってきた場合、ブラウザで開けても有効なサブスクリプションとは限りません。Webページの本文をサーバーアドレス欄に貼り付けないでください。手元の情報に戻って正しいURLと、現在のアカウントで読み込みが許可されているかを確認します。

追加後は、まず少数の項目を確認してください。項目の種類が手元の情報と一致しているかを確認し、適当な項目を開いてアドレスとポートが妥当か確認してから、手動で接続します。想定した件数と違っても、必ずしも追加失敗とは限りません。サブスクリプションが現在返す内容、アプリが対応する項目、フィルタ条件などが影響する場合があります。同じ取得元の説明と照らし合わせ、別の取得元の件数を基準にしないでください。初回テストでは、対象を誤認しないよう、選択するサーバーを1つに絞るのがおすすめです。

サーバーの追加が済んでいるのに接続できない場合は、同じサブスクリプションを何度も追加しないでください。Homeで選択中のサーバー、Global Routing、接続スイッチを確認し、接続スイッチがオンなのにインターネットにつながらない場合の確認手順に沿って原因を調べます。サブスクリプションの追加で解決するのは、情報をアプリに取り込む部分です。認証、接続先のサービス、DNS、ルールが正しいことまで保証されるわけではありません。

Add Serverの手入力項目を確認する

Add Serverは、サーバー1台分のパラメータをすべて把握しており、項目ごとに確認しながら登録したい場合に適しています。重要なのはすべての欄を埋めることではなく、正しいTypeを選び、そのプロトコルで必要な情報を入力することです。同じ名前の項目でも、Typeによって意味が異なる場合があります。画面に表示されていない項目を、経験だけを頼りに追加しないでください。アドレス、ポート、認証、通信方式はそれぞれ異なる階層の設定です。これらが手元のサーバー情報と一致して初めて、接続テストの結果を正しく判断できます。

Typeを選んでから基本項目を入力する

1. HomeでAdd Serverを開き、まずTypeを確認します。Typeを変更した場合はフォームを見直し、前のTypeの認証情報が残っていないか確認してください。
2. サーバーアドレス欄にドメイン名またはIPアドレスを、Port欄に対応するポートを入力します。共有リンク全体やパス、ポートの後ろに続く文字列をアドレス欄に入れないでください。
3. Typeに応じて、Password、UUID、暗号化方式、その他の認証情報を入力します。大文字・小文字、ハイフン、必要な記号は元のままにしてください。
4. 手元の情報を参照して、TLS、SNI、通信方式、パスを確認します。保存後にもう一度開き、実際に保存された値を確認してください。

サーバーアドレスは接続先を指定し、TLSのSNIはハンドシェイク時に名前を通知します。両者は同じとは限りません。手元の情報にIPアドレスと別のドメイン名が記載されている場合、すべての項目を独断でドメイン名に置き換えないでください。Portは接続先が待ち受けるポートであり、サブスクリプションURLに使われるWebサイトのポートとは異なります。TLSを使うからといって、ポート番号を推測することもできません。手入力する各値には、対応する情報源が必要です。不明なパラメータは、よくある番号を片端から試すのではなく、先に確認してください。

認証と通信方式を分けて調べる

認証エラーと通信のハンドシェイクエラーでは、確認すべき項目が異なります。認証エラーなら、認証情報がすべて揃っているか、有効期限が切れていないか、プロトコルを間違えていないかを先に確認します。ハンドシェイクエラーなら、通信方式、TLSの名前、パスを確認してください。認証情報に入力時に置き換わりやすい記号が含まれる場合があります。コピー後に全角文字や前後の空白が混ざっていないか確認してください。UUIDは元の区切り方を保ち、Passwordはエンコードされた文字列に見えても独自にデコードしないでください。アプリに必要なのは対応する項目の元の値であり、見た目に読みやすい形式ではありません。

WebSocketなどの通信方式では、HostとPathがそれぞれリクエストの構成に使われる場合があります。アドレス全体をPathに入力したり、パスの先頭にあるスラッシュを安易に削除したりしないでください。TLSの設定、SNI、証明書の検証は相互に関係しますが、検証を無効にすることを通常の解決策にしないでください。証明書エラーが出た場合は、名前、デバイスの時刻、手元のサーバー設定が一致しているか確認します。パラメータが不明な場合は、複数のセキュリティ設定を同時に変えるより、エラー内容を残して手元の情報を確認するほうが原因を特定しやすくなります。

名前には用途や情報源を記録し、Passwordや完全なアクセス用トークンは含めないでください。「個人テスト / 手入力 / Trojan」のように記載すると、同じアドレスで異なるパラメータを使う項目を見分けやすくなります。変更前に、見分けやすいテスト用の項目を複製し、元の項目は残してください。一度に変更するのは1種類のパラメータに絞り、同じ手順で再テストします。成功したら、どの変更が効果をもたらしたか確認し、試した変更をすべて本番用の項目に残さないようにしましょう。プロトコル名の意味やルール用語は用語集で確認できます。

手入力した項目は通常、自分で管理する必要があります。サブスクリプションを更新しても、Passwordやポートが自動で同期されるとは限りません。アドレスがサブスクリプション内の項目と同じでも、別々の記録として管理されている場合があります。接続先のパラメータが変更されたら、取得元と手入力したローカルの項目をそれぞれ確認してください。古い手入力項目の接続失敗を、サブスクリプション全体の問題と取り違えないようにしましょう。

Scan QR Codeとクリップボードからの読み込み

QRコードとクリップボードは情報を受け渡す手段であり、独立した接続プロトコルではありません。同じQRコードに、サーバー1台分の共有リンクが入ることも、サブスクリプションURLが入ることもあります。クリップボードの内容も、名前や説明文、WebページのURLにすぎない場合があります。アプリが内容を認識した後は、追加対象の種類を確認してください。スキャン成功の表示が出ても、すぐに接続スイッチをオンにしないでください。内容を読み取り、種類を確認し、保存して項目を確認した後に、接続をテストするのが基本です。

QRコードの読み取りと保存後の確認

1. アプリ内のScan QR Codeからスキャン機能を開き、カメラで読み取る必要がある場合のみ、必要なアクセス許可を与えてください。
2. QRコード全体が読み取り範囲に入るようにし、画面を安定させます。コードの端が欠けたり、光が反射したり、別のQRコードが同時に映り込んだりしないようにしてください。
3. 読み取り後に表示された画面がAdd Server、サブスクリプションの入力、その他の確認画面のどれかを確認し、名前、Type、アドレス、Portをチェックしてください。
4. 保存後、Homeに戻り、追加した項目の取得元を確認します。同じ項目がすでにある場合は、どちらを残すか決める前に内容を比較してください。

QRコードが同じデバイス上に表示されている場合、実際のスキャン画面が写真からの読み込みに対応していれば、写真を使えます。対応する入口が見つからない場合は、何度もスクリーンショットを撮らず、元のテキストリンクから追加してください。写真で読み込んでも入力方法が変わるだけで、内容を確認する必要は変わりません。画像を縮小、圧縮、切り抜きしたり、印を重ねたりすると、完全な内容を読み取れなくなることがあります。鮮明な元画像を使うか、手元の情報からテキスト形式を取得してください。QRコードの情報量が多いほど、画面の鮮明さと周囲の余白が重要になります。

クリップボードから読み込める内容

リンクをコピーするときは、プロトコルの接頭辞から最後のパラメータまで、全体を選択してください。タイトル、箇条書き、説明文が混ざらないようにします。アプリに戻ったら、クリップボードの認識表示や実際の読み込み入口に従って操作してください。貼り付けの許可を求められた場合は、今回の操作に伴う読み込みであることを確認します。システム設定によって表示のタイミングは異なるため、自動表示がないだけでリンクが無効とは判断できません。まず該当する入力画面で貼り付けに対応しているか確認し、テキスト形式を確認してください。

チャットやWebページからコピーする際によくあるのが、表示されている内容と実際の内容が異なることです。ページに短縮URLしか表示されていなかったり、テキストに改行が挿入されていたり、末尾に句読点が付いていたりする場合があります。隠れた文字を推測して入力しないでください。画面を見ながら打ち直すのではなく、元のリンクをコピーしてください。複数行のテキストに説明とサーバー情報が混在している場合、すべて認識されるかは形式によります。最初は完全な情報を1件だけ追加し、正しく解釈されることを確かめてから、残りを処理するのがおすすめです。

スキャン後に表示されたTypeが元の情報と異なる場合は、保存をキャンセルし、別の記録のQRコードではないか確認してください。読み取り後に項目が欠けている場合は、元の情報を残したうえで、Add Serverを使って照合しながら入力します。似た項目を誤ったTypeのフォームに補い入力しないでください。すでに同じ項目がある場合は、名前に「QRコードテスト」などと付けて元の記録と区別できます。比較が済んだら一時的な項目を削除し、次のテストで誤って選ばないようにしてください。削除前に、復元できる唯一のコピーではないことを確認します。

追加後もクリップボードや写真には内容が残っています。実際の認証情報を含むQRコードを、公開する問題報告のスクリーンショットに使わないでください。機密性の高いリンクをクリップボードに長期間残すのも避けましょう。今回の操作が終わったら、通常のテキストをコピーしてクリップボードの内容を置き換え、必要に応じて一時的な画像を削除してください。各入口からの追加方法の比較はサブスクリプションとサーバーを追加する4つの方法をご覧ください。ここで説明した注意点は、どの入力方法にも当てはまります。

問題の記録には、「QRコードを認識しない」「認識後に種類が違う」「保存後に接続できない」のように記載すれば十分です。それぞれ入力、解析、接続の問題なので、個別に対処してください。画像の鮮明さの問題をサーバーの不具合と取り違えないようにしましょう。

共有リンクとConfigの形式

共有リンクはサーバーのパラメータを受け渡し可能なテキストにしたもので、サブスクリプションから複数のリンクが返される場合もあります。プロトコルの接頭辞を見たら、サーバー1台の情報なのか、情報を取得する入口なのかを判断し、適切な方法で追加してください。よく使われる接頭辞にはss://、vmess://、vless://、trojan://、hysteria2://があります。ただし、接頭辞が同じでも、パラメータの組み合わせがすべて同じとは限りません。プロトコル、通信方式、セキュリティ設定、名前のエンコードも合わせて解析する必要があります。「リンクを認識できた」だけで項目の確認を省略しないでください。

接頭辞、クエリパラメータ、名前を分けて確認する

形式によっては認証情報とアドレスが本文にエンコードされ、別の形式ではアドレス、ポート、クエリパラメータが直接表示されます。疑問符の後にTLS、SNI、通信方式などの設定が続き、シャープ記号の後にメモ用の名前が付く場合があります。名前の表示が乱れていても、接続パラメータが壊れているとは限りません。逆に、名前が正しく表示されても、クエリパラメータがすべて正しいとは限りません。リンクの読みやすさだけで判断せず、アプリ内で解析後の内容を確認してください。名前はローカルで見分けやすい文字列に変更できますが、接続情報の元データは別途保管してください。

リンク中のパーセントエンコードは予約文字を表し、一部の本文にはBase64が使われます。この2つは別の仕組みなので、混同したり、リンク全体を何度もデコードしたりしないでください。パスワード、パス、名前に含まれる正規の記号を誤ってデコードすると、区切り文字に変わって項目の境界が変わることがあります。コピー時は元の文字列を保ち、確認する場合はアプリ内の項目を手元の情報と照合してください。完全な認証情報を公開のテキスト処理ツールに送らないでください。エンコードはテキストを受け渡しやすくする仕組みであり、機密を保護するものではありません。

サーバー情報とルールファイルの役割分担

サーバー項目は「どこに接続し、どう認証するか」を示し、Configは「リクエストにどのポリシーを適用するか」を示します。両者は併用できますが、互いに置き換えることはできません。ルールファイルだけを追加しても、必要なサーバーの認証情報が自動で得られるわけではありません。サーバーだけを追加しても、ルールが有効になったとは限りません。振り分け動作を確認するときは、Homeで選択中のサーバー、Global Routingの現在のモード、Configで実際に有効になっているファイルをすべて確認してください。エディタで開いているだけのコピーを見て判断しないようにしましょう。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY

上記はルール構文の例であり、すべてのネットワークに適した完全な設定ではありません。DOMAIN-SUFFIXはドメインの末尾で照合し、IP-CIDRはアドレス範囲を指定します。GEOIPは対応するIPアドレスの地域データを基に判定し、FINALは最後のフォールバックとして使われます。ルールは順序によって一致結果が変わります。範囲の広いルールを先に置くと、後にある具体的な条件が適用されないことがあります。PROXYとDIRECTはポリシーのキーワードです。日本語に置き換えたり、コピー時にカンマを変えたり、説明文を追加したりしないでください。

Global RoutingでConfigを選ぶ場合は、選択中の設定ファイルのルールを確認してください。ProxyとDirectは、全体のルーティング方法を選ぶための別のモードです。3つのサーバー情報やサブスクリプションの取得元を表すものではありません。特定のルールの影響を比較する場合は、まず現在のモードを記録し、同じ接続先を使って1回テストしてから、元のモードに戻してください。サブスクリプションの内容を確認する際にConfig全体も入れ替えると、アクセスの変化がサーバーとルーティングのどちらによるものか分かりにくくなります。

拡張パラメータに対応しているか分からない場合は、現在のアプリに該当する項目があるか、元の情報に説明があるかを先に確認してください。不明なパラメータをすべて削除して保存すると、リンクは追加できても必要な設定が失われることがあります。形式の問題は追加の前後で照合し、ルールの問題はConfigで調べてください。2つの確認手順を分けて進めましょう。

サブスクリプションの更新方法とエラー対応

サブスクリプションの更新では、登録済みの取得元へ再度リクエストを送り、その時点で返された内容を解析します。古いサーバーが接続可能かをテストするだけの操作ではありません。更新後に項目が追加、削除、改名されたり、パラメータが変わったりすることがあります。実際の変化は、接続先が返す内容とアプリの処理方法によります。更新前に、どの項目がサブスクリプション由来で、どれが手入力の独立した項目なのか、現在どれを使用しているのかを把握してください。サブスクリプション内の項目を手動で変更した場合、その変更は次回の更新で上書きされる可能性があります。長期保存できる唯一の情報として扱わないでください。

結果を確認しながら手動で更新する

1. 現在の取得元の名前、選択中のサーバー、重要なローカル変更を記録します。重要な情報は先に復元可能な形でバックアップしてください。
2. 対象のサブスクリプションに用意されている更新操作を使い、取得元を1つずつ更新して、結果とエラー表示を確認します。
3. 更新前後のグループ、名前、パラメータを比較し、使用中の項目が残っているか確認します。
4. 確認済みのサーバーを1つ選んで再接続し、同じ接続先で効果を確認してから、ほかの取得元を更新してください。

内容を確認してから管理したい場合は、必要なときに手動で更新できます。アプリに自動更新設定がある場合は、手動更新が正常に完了してから、管理方法に応じて有効にしてください。自動更新の間隔と、接続先の情報が変更される頻度は別です。頻繁にリクエストしても、無効になった認証情報は直りません。システムのバックグラウンド動作条件、ローカルネットワーク、その時点でのアプリの状態によって実行タイミングが変わるため、予定時刻どおりに必ず完了するとは限りません。問題があるときは、まずアプリを前面に表示して手動で実行し、明確な結果を確認してください。

リクエストの失敗と接続の失敗を分ける

サブスクリプションURLにアクセスできない場合は、ローカルネットワーク、DNSの名前解決、URLの完全性を先に確認します。現在の接続状態がリクエスト経路に影響している可能性がある場合は、状態を記録してから条件を揃えて比較してください。記録を残さずに何度も切り替えると、再現が難しくなります。認証に関する応答が返る場合は、リンクがまだ有効か確認してください。内容を解析できない場合は、返されたものがサブスクリプション情報なのかWebページなのかを判断します。認識可能な内容を取得できてから、サーバーパラメータと接続可否を調べてください。

更新が成功しても、すべてのサーバーが使えるとは限りません。サブスクリプションから正常に情報を取得できても、個々のサーバーに一時的に接続できない場合があります。反対に、古い項目で接続できても、サブスクリプションの入口が正常とは限りません。それぞれの結果を分けて記録してください。更新後に一部の項目しか残らない場合は、接続先が内容を変更したか、フィルタ条件が設定されているか、アプリが該当する種類を解析できるかを先に確認します。何度も連続して更新せず、最初の更新で起きた変化を調べ、元のエラー内容を残してください。重要な問題調査の手がかりを失わずに済みます。

サブスクリプションURLを変更する場合は、古い取得元をバックアップし、新しいURLの用途を確認してください。別の名前で新しい取得元を追加し、項目と接続が正常であることを確かめてから、古い記録を整理します。変更時に古い取得元の削除、設定の消去、アプリのリセットを同時に行わないでください。失敗した際に比較対象がなくなります。更新後はGlobal RoutingとConfigが想定どおりかも確認してください。明確な設定変更を目的とする場合を除き、サブスクリプションの管理に伴ってルーティング動作まで変えないようにしましょう。

メンテナンス結果には、更新した取得元、変更内容、検証した項目、結論を記録すれば十分です。サブスクリプションURL全体をログに記載する必要はありません。作業を振り返りやすくしつつ、スクリーンショットやメモに機密情報が残るのを防げます。

複数のサブスクリプション、名前、重複項目の整理

複数のサブスクリプションを使う場合は、表示名が整っているかだけでなく、「どの取得元から来た項目か」を把握することが重要です。同じ名前でもアドレス、ポート、認証情報が異なる場合があり、名前が違っていても同じ接続先を指していることがあります。整理する前に、サブスクリプションの取得元、取得元に含まれるサーバー、独立した手入力項目、テスト用の一時コピーを区別してください。それぞれを見分けられるようにしておくと、更新時にグループを間違えたり、テスト項目の削除時に使用中の正式な項目を誤って消したりするのを防げます。

名前には用途を記録し、認証情報は含めない

サブスクリプション名には、自分が分かる用途や資料の取得元を示す略称を付けると便利です。サーバーのメモにはプロトコルやテストの目的を記録できます。たとえば「仕事用 / メイン」「個人テスト / 手入力」のようにすると区別しやすくなりますが、Password、アクセス用トークン、完全なアカウント識別子は含めないでください。接続先の状態やローカルネットワークは変わるため、テスト結果を名前にするのも避けましょう。過去のテスト結果を恒久的な名前にすると、最新の確認結果ではなく古い印象に頼って選んでしまう可能性があります。

1. 取得元ごとに確認し、取得元のラベルと所属項目を把握してから操作します。全項目の一覧画面からまとめて削除しないでください。
2. 独立した手入力項目と一時コピーには、用途が分かるメモを付けます。元の情報は安全な場所に保管してください。
3. 重複が疑われる項目は、表示名だけでなくType、アドレス、Port、認証、通信方式を比較します。
4. 残す項目を決めたら、設定やポリシーから元の名前が参照されていないか確認します。その後、少しずつ整理して動作を検証してください。

サブスクリプション内の名前は接続先が管理している場合があり、更新後もローカルで変更した名前が維持されるとは限りません。自分用の分類を長く維持したい場合は、アプリが実際に提供している取得元のグループ分けやメモ機能を使い、接続先が管理する項目を大幅に書き換えないでください。独立したコピーを保存する場合は、以後は元の取得元から更新されず、自分で管理する必要があることも記録しておきます。コピーが多いほど、後の同期に手間がかかります。コピーは問題調査や復元に必要な場合に作成し、更新のたびにすべて複製する運用は避けましょう。

重複かどうかはパラメータを比較して判断する

表示名が完全に同じでも、分かるのは名前が重複しているということだけです。認証情報が異なれば利用できる範囲が異なる場合があり、通信経路が違えば接続先の設定も異なる可能性があります。削除前に項目を開いて比較し、少なくともアドレス、ポート、プロトコル、セキュリティ設定を確認してください。認証情報の確認は安全な環境でのみ行います。アドレスだけ同じでほかの項目が異なる場合は、それぞれテストして違いを記録してください。一覧の見た目が似ているだけで不要と判断したり、1回のテストで遅延が近かったことを重複の根拠にしたりしないでください。

Configで特定のサーバー名やポリシーグループのメンバー名を使っている場合、名前の変更や項目の削除が参照関係に影響することがあります。整理する前にHomeだけでなく、該当するConfigも確認してください。PROXYなどのポリシーキーワードを使う場合は、現在選択している項目との関係も把握しましょう。表示名が同じでも参照が維持されるとは限りません。整理後は想定したサーバーを選び、Configで有効なファイルを確認してから、同じ接続先でテストします。問題が発生した場合は変更範囲を広げず、まず直前の名前や項目を元に戻してください。

取得元が複数あっても、頻繁に切り替える必要はありません。管理時は検証済みの項目を基準として決め、ほかの取得元は必要に応じてテストしてください。「現在使用中」「予備として検証」「確認待ち」のように状態を記録すると、名前順に並べるだけより作業を振り返りやすくなります。記録は安全な場所に保管し、状態を示す文字列に実際の認証情報を含めないでください。1回の整理では取得元を1つだけ扱い、更新、確認、テストを終えてから次に進むと、パラメータの混同や見落としを減らせます。

一時的に使っていない項目でも、復元できることをまだ確認していない場合は、すぐ削除せず残しておくほうが安全です。元の情報が使えること、バックアップから復元できること、Config内の参照を処理したことを確認してから整理してください。一覧をすっきりさせるだけでは整理完了とはいえません。取得元を追跡でき、復元方法が明確になっていることが大切です。

Connectivity Test、遅延、並べ替え

Connectivity Testは、特定の条件でテストした結果を確認する機能であり、サーバーの品質を恒久的に評価するものではありません。接続を確立するのか、プロトコルのハンドシェイクまで行うのか、テスト対象にアクセスするのかは、選択したテスト方式によって異なります。時間が表示されたら、まず何を測定した値なのかを確認してから比較してください。アドレスに到達できても認証が成功したとは限らず、認証が成功してもすべてのWebサイトにアクセスできるとは限りません。各段階を分けて考えると、「テスト結果は出るのに実際にはアクセスできない」といった状況を説明しやすくなります。

条件を揃えて結果を比較する

1. デバイスがWi-Fiとモバイル通信のどちらを使っているか確認し、まずローカルネットワークが利用可能か確かめます。
2. テスト方式と接続先を1つずつ決め、Global Routing、選択中のサーバー、関連する設定を記録してください。
3. 同じ条件で少数の候補をテストし、異常な結果は再度確認します。複数のパラメータを同時に変更しないでください。
4. 候補のサーバーに実際に接続し、よく使う操作を試してから、使用する順序を調整してください。

TCP系のテストで分かるのは、主に接続先のポートに接続できるかどうかです。プロキシの認証や、その後のデータ通信まですべて正常であることを単独で証明するものではありません。異なる通信方式を使うプロトコルでは、同じテスト結果でも意味が異なることがあります。アプリがプロキシ経由での接続テストを提供している場合は、接続先の応答状態も判断に含めてください。接続先に到達できない、名前解決に問題がある、一時的にリクエストを拒否しているといった状況も結果に影響します。テスト方式が異なる場合、時間をそのまま並べて共通の結論にまとめるのは適切ではありません。まず測定条件を揃えてください。

並べ替えは自動選択ではない

テスト結果で並べ替えると、通常は一覧の表示順が変わるだけです。アプリが必ず先頭の項目に切り替わるわけではありません。実際に接続する対象は、現在選択中のサーバーとConfig内のポリシーで決まります。並べ替え後は選択状態を確認してください。Configでポリシーグループを使っている場合は、そのグループの選択方式も確認します。1回の測定で最も短かった時間は、その接続先と条件における一度の結果にすぎません。継続的な通信速度が速いことや、あらゆる用途に適していることを示すものではありません。一覧上の位置を接続状態の代わりにしないでください。

一度に多数のテストを行うと、デバイス、ローカルネットワーク、接続先に短時間の負荷がかかり、瞬間的な変動の影響も受けやすくなります。候補を少数ずつテストすると、条件を比較しやすくなります。ときどきタイムアウトする項目は、同じ条件で再テストしてください。繰り返し失敗する場合はパラメータを確認し、アドレスに到達できないのか、認証エラーなのか、接続先へのリクエストが失敗したのかを切り分けます。1回の赤いステータスや結果の空欄だけを理由に項目を削除しないでください。ローカルネットワークが不安定な場合は特に注意が必要です。

同じサーバーでもWi-Fiとモバイル通信で大きく差が出る場合は、サーバーのパラメータを変えずに各ネットワークの条件を記録し、ローカルの接続環境が関係しているか判断してください。同じネットワークでどのサーバーも失敗する場合は、個々の認証情報を入力し直す前に、ローカルネットワークとDNSを確認します。1つだけ繰り返し異常が出る場合は、Type、Port、TLS、通信方式を比較してください。こうした段階的な確認で無駄な作業を減らせます。具体的な手順は通信速度が遅い場合の段階別チェックをご覧ください。

テストの記録には、方式、接続先、ネットワーク条件、結果を含めてください。時間の数値だけを保存する必要はありません。並べ替え後も取得元ごとのグループと見分けやすい名前を維持すると、次回の更新後に再検証しやすくなります。同じ操作で結果を再現できて初めて、メンテナンスの判断材料として使えます。差の理由が分からない場合は確認待ちとして記録し、特定のプロトコルやサーバーが恒久的に使えないと決めつけないでください。

削除、バックアップ、機種変更後の復元

サーバー管理で最後に行うのは削除ではなく、削除後に明確な復元手段があることの確認です。アプリ、サブスクリプションの取得元、サーバー項目、Configファイルはそれぞれ別の対象であり、1つを復元してもほかの内容が自動で戻るわけではありません。App Storeの購入履歴はアプリを再入手するためのものです。自分のサーバー認証情報、サブスクリプションURL、ローカル設定は、それぞれ別に保管してください。機種変更後に情報がないと気付いて調べるより、事前に対象を整理しておくほうが確実です。システム要件と購入の適用範囲はApp Storeのページで確認してください。

対象ごとにバックアップ項目を整理する

サブスクリプションの取得元は、URL全体と用途の説明を保存します。独立した手入力項目は、プロトコル、アドレス、ポート、認証、必要な通信設定を保存します。Configはファイル全体と有効状態を保管してください。アプリにエクスポートやバックアップ機能がある場合は、実際に何が含まれるか確認します。ファイル名だけで保存範囲を判断しないでください。設定テキスト全体を出力する機能もあれば、現在のサーバーだけを共有する操作もあります。復元前に、それぞれに何が含まれているか把握してください。元の情報を安全に保管しておくと、エクスポート時に拡張パラメータが抜けていないか確認しやすくなります。

1. 取得元、手入力した項目、Config、重要な設定を書き出し、復元に必要な情報の保管場所を記録します。
2. アプリに実際に用意されている入口からエクスポートし、必要な対象が含まれているか確認してから、保護された場所に保存してください。
3. 可能であれば、一意の有効な元データを上書きせず、テスト用の項目や移行先のデバイスで復元を確認してください。
4. 復元後の項目、選択中のサーバー、Global Routing、Configを確認してから、接続とアクセスをテストします。

共有用QRコード、個別の共有リンク、完全なバックアップでは、保存される範囲が異なります。サーバー1台のQRコードだけでは、サブスクリプションの取得元や更新の関係を復元できないことがほとんどです。サブスクリプションURLだけを保存しても、ローカルで変更したメモ、独立した項目、ルールファイルは復元できません。一方、完全なバックアップには大量の機密情報が含まれる場合があります。アクセスできる人を制限し、公開用のスクリーンショットと一緒に保管しないでください。暗号化の有無、ロック解除方法、移行先デバイスでの読み込み方は、元の情報を削除する前に確認します。復元に失敗してから考えるのでは遅すぎます。

項目の削除、取得元の削除、設定の無効化を区別する

サブスクリプション内の項目を削除しても、接続先からその項目が削除されたとは限りません。次回の更新時に再び表示されることがあります。サブスクリプションの取得元全体を削除すると、紐づく項目にも影響する場合があるため、実行前にアプリの確認メッセージを読んでください。Configを無効にしたり切り替えたりしても、サーバーが削除されるわけではありませんが、リクエストの処理方法は変わります。一度に操作する対象は1種類に絞り、操作後に現在の選択を確認してください。サーバーが削除されたのに、古い名前を見て接続先を判断することがないようにしましょう。ポリシーから参照されている場合は、Config内のメンバーが残っているかも確認してください。

復元後に、接続スイッチ、システムの許可、アプリ内の選択が以前のデバイスと同じだとは限りません。まずShadowrocketを開いて、読み込んだ内容を確認してください。次に、確認済みのサーバーとGlobal Routingを選択し、システムの案内に従ってVPN構成を許可します。システムの確認画面はデバイスのネットワーク設定を作成するためのもので、サーバー情報を補うものではありません。アプリの再入手と購入履歴の確認は機種変更・再インストールのガイド、クライアントの料金については買い切り購入と接続サービス料金の解説をご覧ください。

誤って削除した場合は、追加の整理をいったん止め、既存のバックアップ、元の情報、まだ変更していない別のデバイスを確認してください。ローカルの独立項目が戻るかどうかを何度も更新して試したり、内容が完全なコピーに上書きしたりしないでください。バックアップから復元したら、まず内容の範囲を確認してから接続をテストします。使用可能と確認できるまでは元のバックアップを残してください。不完全な新しいファイルで唯一の古いファイルを上書きするのを防げます。整理が終わったら、最終的に残した項目と復元情報の保管場所を記録し、重要なパラメータを変更するたびにバックアップを更新してください。