01 / SUBSCRIBE

Subscribeの追加とデータの違い

サブスクリプション、サーバー、Configの違い

サブスクリプションはサーバーリストを取得するためのアドレス、サーバー項目は接続に必要な具体的な設定、Configはルールなどの設定を保存するものです。それぞれ連携して使えますが、互いに置き換えることはできません。通常のWebページのアドレスをSubscribeに入力しても、接続可能なサーバーは自動生成されません。サーバーの共有リンクをルールファイルとしてインポートしても、期待した振り分けにはなりません。操作前に手元の情報の用途を確認すると、入口を変えて何度も試す手間を減らせます。

サブスクリプションを更新すると、通常は複数のサーバー情報が返されます。アドレス、ポート、プロトコル、認証情報などが含まれる場合があります。これは「リストをどこから更新するか」を示すもので、特定のサーバーを選択した状態や、接続を開始した状態を意味するものではありません。リストに名前が表示されたら、項目を確認してサーバーを選び、必要に応じてGlobal Routingを設定します。インポートの成功、接続の成功、目的のサービスが使えることは、それぞれ個別に確認してください。

この章では、ユーザー自身がサブスクリプションを用意していることを前提に説明します。準備の際は、サブスクリプションのアドレスを原文のまま保管し、既存のサービス説明に記載された形式、認証方法、更新要件も確認してください。管理ページ、ログインページ、支払い履歴ページのアドレスをサブスクリプションのアドレスとして使わないでください。同じドメインのアドレスでも、返されるデータは異なる場合があります。ブラウザーでページが表示されても、Subscribeで解析できるアドレスとは限りません。

Add Serverからサブスクリプションを登録する

Homeで追加メニューを開き、Add Serverに進んだらTypeを確認します。サブスクリプションを追加する場合はSubscribeを選び、アドレスをすべて入力します。用途がわかる名前やメモを付けて保存してください。デバイスによって画面上の項目配置は異なる場合があるため、実際の画面に従ってください。重要なのは、プロトコル別のサーバーアドレス欄にURL全体を貼り付けるのではなく、サブスクリプションとして登録することです。保存前にアドレスを最初から最後まで確認してください。

サブスクリプションのパスやクエリパラメーターは識別に使われることが多く、ドメインだけを残してはいけません。コピー時に句点、引用符、改行、先頭の空白が混入していないかも確認してください。改行に対応したメッセージでは、見た目の折り返しが実際の改行とは限りません。見た目だけを頼りに手作業でつなぎ合わせないでください。長いアドレスを入力し直すより、原文をコピーして貼り付けた後、先頭と末尾、重要なパラメーターを確認する方法が確実です。

保存後に一度更新し、サブスクリプションの下にサーバー項目が表示されるか確認します。件数が既存のサービス説明と合っているか、名前を識別できるか、プロトコル項目が揃っているかを確認してください。リストの内容はアカウントの権限やサーバー側のデータによって変わるため、特定の件数を期待する必要はありません。結果が空の場合は、既存のリストをすぐに削除せず、更新エラーや返されたデータの種類を確認してください。元の登録を残しておくと、アドレスが変更されていないか比較できます。

初回の再現可能な確認基準を作る

初回の更新が完了したら、設定が明確なサーバーを1つ選び、使用したネットワーク、Global Routingの状態、テスト対象を記録します。サブスクリプションのアドレス、ルールファイル、ネットワーク環境を同時に変更しないでください。問題が起きても、どの段階で変化したのか判断できなくなります。以前から使えている設定がある場合は変更せず、サブスクリプションだけをインポートしてリストを確認してください。インポートの問題とルールの問題を切り分けられます。

サブスクリプションによっては、利用量や有効期限などの追加情報が表示されます。これらはサーバー側から返された情報をアプリが表示するもので、表示内容だけで接続可否を判断することはできません。反対に、追加情報が表示されないからといって、サブスクリプションが無効とは限りません。更新が完了したか、項目を解析できるか、選択したサーバーで期待する接続ができるかを確認し、必要に応じて既存サービスのアカウント状態も確認してください。

対象役割これだけでは判断できないこと
Subscribeサーバーリストの取得と更新現在の接続が必ず使えること
サーバー項目プロトコル、アドレス、ポート、認証情報ルールが正しく適用されていること
Configルールと関連設定サブスクリプションの認証情報が有効であること

初回のインポートが成功したら、短い記録を残しておくと便利です。サブスクリプションの用途、追加方法、最後に正常確認した環境、手動で追加したサーバーがあるかを記録してください。認証情報そのものを書き写す必要はなく、安全に保管している場所を記載できます。更新に失敗したときは、すべての設定をリセットする前にこの記録を確認してください。接続までの基本手順は使い方ガイドで確認できます。

02 / ADD SERVER

Add Serverの手動入力項目とプロトコルの確認

まずTypeを選び、共通項目を入力する

手動追加は、サーバーの設定情報が揃っている場合、単一項目を確認したい場合、または個別のテスト記録を残したい場合に適しています。Add Serverを開いたら、最初にTypeを選び、その後に各項目を入力してください。プロトコルによって項目の意味は異なります。アドレスとポートを使うからといって、Typeを入れ替えることはできません。Typeを変更した場合は、入力済みの内容も確認し直してください。以前の項目が残っていたり、認証方式が合わなかったり、任意項目が初期値に戻ったりすることがあります。

サーバーアドレスには通常、ドメイン名またはIPアドレスを入力します。一般にアドレス欄へWebのプロトコル接頭辞、パス、クエリパラメーター全体を入力する必要はありません。ポートは専用の欄に入力してください。手元の情報が共有リンク全体の場合は、内容の一部を切り出して入力するのではなく、インポート機能を使ってください。IPv6アドレスにはコロンが含まれるため、手入力時はアドレス本体とポートを区別してください。見た目で最後の区切りを推測してはいけません。

名前やメモは、ローカルで項目を識別するためのものであり、認証情報ではありません。用途や提供元に基づいて名前を付けられますが、パスワード、サブスクリプションの完全なアドレス、秘密鍵は記載しないでください。保存後、項目を開き直してType、アドレス、ポート、認証情報が正しいか確認します。入力欄がマスク表示されていても、内容が正しいとは限りません。コピー時に先頭や末尾へ空白が入っても気づきにくいため、元の情報と項目ごとに照合してください。

プロトコル固有の項目は一式を正しく合わせる

Shadowsocksでは暗号化方式とパスワードを確認し、サーバー側の設定と一致させます。VMess、VLESSなどでは、それぞれの識別情報とトランスポート設定を確認してください。あるプロトコルのパスワードの考え方を、別のプロトコルに当てはめてはいけません。Trojanでは認証情報とTLS関連の設定も確認します。共通の設定一式を探すのではなく、既存のサービスで指定された設定をそのまま再現することが重要です。

TLSのサーバー名、接続先アドレス、トランスポート層のHostは、同じ場合もあれば意図的に異なる場合もあります。接続先アドレスは最初に接続する場所を指定し、サーバー名はTLSの認証に使われます。Hostやパスは上位のトランスポート設定に関わる場合があります。3つの項目を同じに見せるために、すべてサーバーのIPアドレスへ変更しないでください。接続先がIPアドレスでも、正しいサーバー名がドメイン名であることがあります。元の情報に従って設定してください。

WireGuardの秘密鍵、公衆鍵、インターフェースアドレス、ピアアドレスなどは、それぞれ用途が異なります。設定全体を1つの入力欄に貼り付けないでください。Hysteria2の認証情報とTLS設定も、サーバー側の設定に合わせる必要があります。ローカルネットワークでUDPを使えるかどうかは、別の条件です。トランスポートの特徴はHysteria2とQUICの解説で確認できますが、設定項目の照合は省略できません。

項目グループ確認する内容よくある誤り
アドレスとポート接続先とポート番号URL全体をアドレス欄に入力する
認証パスワード、識別子、鍵文字の抜け、余分な空白、項目の入力先違い
TLS有効化の状態とサーバー名接続先IPで認証用ドメインを置き換える
トランスポート種類、パス、Host勝手にスラッシュを追加したり、大文字・小文字を変更したりする

保存後は項目ごとに確認し、同時に複数の設定を変更しない

手入力が初めて完了したら、まずサーバーのドメイン名を解決できるか確認します。次にトランスポート接続、最後に対象へのリクエストが想定した経路を通るか確認してください。認証エラー、TLS検証エラー、接続タイムアウトは、それぞれ異なる問題です。タイムアウトだからといってすぐにパスワードを変更したり、認証エラーだからといって先にルールを変更したりしないでください。画面に具体的なエラーが表示される場合は、エラーの種類と発生段階を記録すると、「使えない」とだけ記録するより原因を絞り込みやすくなります。

証明書の検証を無効にする方法を、一般的な解決策として使わないでください。サーバー名の誤り、デバイス時刻の異常、サーバー側の証明書の問題などを見えにくくする可能性があります。まず元の情報、デバイスの時刻、接続先を確認し、その後にトランスポート設定を見直します。項目の意味、適用範囲、リスクを理解している場合に限り変更し、テスト記録に記載してください。一時的な診断設定を通常の設定と混同しないためです。

サブスクリプションから生成されたサーバーを直接編集すると、次回の更新でサーバー側の内容に上書きされる場合があります。テストする場合は、画面が対応していれば独立した複製を作成し、用途を明記して、サブスクリプションの元の項目と同じ名前を付けないようにしてください。テストごとに変更する項目は1つだけにし、結果を確認してから変更を残すか戻すかを決めます。手動で追加した項目が有効と確認できたら、その差分を既存の設定情報の確認手順に反映してください。用途不明の複製を長期間管理する方法は避けましょう。

03 / IMPORT

QRコード・クリップボードからのインポート手順

Scan QR Codeで変わるのは入力方法

QRコードはテキストを格納する形式です。単一サーバーのリンク、サブスクリプションのアドレス、通常のWebページが含まれることがあります。Scan QR Codeを使う前に、QRコードが自身のサブスクリプションまたはサーバー情報に対応していることを確認してください。読み取りに成功したということはテキストを取得できたというだけで、現在の入力先に適した内容であることや、サーバーへの接続確認が済んだことを意味しません。読み取り後に対象の種類を確認してから保存してください。

カメラで読み取る際、システムからカメラへのアクセス許可を求められる場合があります。以前に許可しなかった場合は、システムのアプリ権限設定を確認してください。リストを何度もインポートし直す必要はありません。撮影距離を調整し、反射を避け、QRコード全体を画面に収めると読み取りやすくなります。端が切れていたり、表示が小さすぎたり、別の模様に覆われていたりすると、内容を正しく読み取れないことがあります。これはサーバー設定の正しさとは別の問題です。

QRコードとアプリが同じデバイスにある場合は、実際の画面に画像を読み取る機能があれば利用できます。該当する機能がない場合は、元のリンクをコピーしてクリップボードからインポートしてください。認証情報を含む画像を公開の読み取りページにアップロードしないでください。保存が必要なQRコード画像も認証情報を含むファイルとして扱い、通常の説明用スクリーンショットだと思って安易に転送しないでください。

クリップボードから取り込む前に原文を確認し、結果を照合する

コピー時はリンク全体だけを選択し、説明文、番号、箇条書きの記号、文末の句読点を一緒にコピーしないようにしてください。貼り付けた内容を読み取る許可を求められた場合は、自分で開始した操作であることを確認してから許可します。期待した内容が読み込まれない場合は、すぐにインポート機能の不具合と判断せず、テキストの元に戻って再コピーし、後からコピーした確認コード、検索語、別の内容に置き換わっていないか確認してください。

複数の共有リンクを含むテキストもありますが、提供元によって区切り方は異なります。改行を含むテキストなら何でも一括でインポートできるとは限りません。まず完全なリンクを1つ取り込み、種類と項目が正しいことを確認してから全体を処理してください。結果が想定より少ない場合は、空行、途中の改行、説明文を確認し、比較できるよう原文を残します。インポートを繰り返すと重複項目が増えるだけで、途中で切れたリンクは修復できません。

サブスクリプションのアドレスをインポートすると、通常は更新できる登録項目が作成されます。単一サーバーのリンクをインポートした場合は、通常、独立した項目が1つ作成されます。今後もリストを自動更新したいのに通常のサーバーが1つ表示される場合は、コピーした情報の種類を確認し直してください。反対に、サブスクリプションのQRコードを読み取って複数の項目が表示されても不思議ではありません。ただし、対応するサブスクリプションの登録が残っているかも確認してください。リストの件数だけでインポート方法を判断しないでください。

「読み取り・解析・接続」を分けてトラブルを調べる

最初の段階は読み取りです。カメラや画像から完全なテキストを取得できるか確認します。次は解析です。取得したプロトコル形式をアプリが認識できるか、必要な項目が揃っているかを確認します。最後に接続を確認します。サーバーへの到達、認証、リクエストが想定したルールに一致しているかを調べてください。QRコードにまったく反応しない場合は、まず読み取りの問題を解決します。項目が表示されているのに接続できない場合、読み取り方を変えても通常は解決しません。

インポート後、新しい項目の編集画面を開き、Type、アドレス、ポート、認証、TLS設定を確認してください。リンクに含まれる拡張パラメーターは、解析方法によっては完全に対応しない場合があります。「保存済み」であることは、目視確認の代わりになりません。既存の情報で指定されているパス、サーバー名、トランスポート方式が表示されていない場合は、必要な設定を補うか正しい形式の情報を取得してから、接続をテストしてください。

「対応していない形式」などと表示された場合は、チャットアプリの転送ページではなく、元のリンクをコピーしたか確認します。プロトコル接頭辞を別のものに変えて無理にインポートしたり、意味のわからないクエリパラメーターを削除したりしないでください。パラメーターはTLSやトランスポートの動作を決めることがあります。削除後に保存できても、別の意味の項目になる可能性があります。形式の確認は次の章を、接続段階の問題はよくある質問とトラブル対処を参照してください。

インポート後、新しい項目の登録先を確認し、誤って作成された重複項目を削除して、不要な認証情報入りの画像を整理します。クリップボードの機密テキストを関係のない通常のテキストに置き換えることはできますが、別のデバイスやアプリに保存済みのコピーまで消えるわけではありません。完全なリンクを管理できない場所に送信してしまった場合は、端末内の項目を削除するだけでなく、既存サービスの管理手順に従って関連する認証情報を変更してください。

05 / UPDATE POLICY

サブスクリプションの更新と失敗時の復元

更新で変わるのは表示だけではなく、リストの内容

サブスクリプションの更新では、元のアドレスに再度リクエストを送り、返されたデータに基づいてサーバー項目を更新します。サーバー側で項目が追加、削除、変更される場合があります。そのため、更新は単に「もう一度接続テストする」操作ではありません。更新前に、リストの変化と接続状態の変化を区別してください。データを取得できてもリスト内の全サーバーが使えるとは限らず、以前使えたサーバーに接続できても、サブスクリプションの認証情報が有効だとは限りません。両者は別々に変化することがあります。

手動で変更したサブスクリプションの項目が必ず維持されると思い込まないでください。サーバー側の記録とローカルの記録の対応関係は、名前や識別情報、アプリの処理方法に左右されます。手動の変更を長期的に保管する場合は、独立した記録や対応しているローカル管理方法を使い、サーバー側の元データではないことを明記してください。そうしないと、次回の更新後に項目が上書きされたのか、再作成されたのか、同じ名前の別サーバーを選んだのか判断しにくくなります。

更新前に、現在使っているサブスクリプションとサーバー、復元できるバックアップの有無を確認してください。安定して動作している環境では、すべてのデバイスを同時に更新する必要はありません。まず1台で更新し、変更点を確認して動作を検証してから、他のデバイスを更新できます。新しいリストの影響を確認でき、予期しない問題が起きても比較用の元の状態を残せます。すべてのデバイスが同時に基準を失う事態を避けられます。

リストの更新頻度に合わせて間隔を決める

更新頻度は、既存サービスの要件とリストの変更頻度に合わせてください。頻繁に更新すればよいわけではありません。同じアドレスへ短時間に繰り返しリクエストすると、サーバー側の制限にかかる可能性があり、トラブルの記録も時系列で追いにくくなります。画面に自動更新の設定がある場合は、実際の動作と起動条件、ネットワークの要件を確認してください。モバイルOSのバックグラウンド実行はデバイスの状態にも左右されるため、指定した間隔で必ず実行されるとは限りません。

手動更新は、初回追加時、既存サービスから変更の案内を受けたとき、リストが古いと思われるとき、メンテナンス時間内に変更を管理したいときに適しています。更新後は項目の変化、選択中のサーバー、実際の接続を確認してください。更新処理が終わったかだけを見て判断しないでください。以前の項目が削除されていた場合は、リストに残っているサーバーを選び直して検証します。名前が似ていても、以前と同じ設定がすべて残っているとは限りません。

サブスクリプションの取得に使われるネットワーク経路が、更新結果に影響する場合もあります。サーバーには接続できるのにサブスクリプションを更新できない場合は、現在のネットワークからサブスクリプションのリソースへアクセスできるか、ドメイン名を解決できるか、別途認証が必要かを確認します。ネットワークの切り替えは比較テストに使えますが、一度に変更する条件は1つだけにして結果を記録してください。リストを取得するためにConfig全体を変更すると、更新経路と通常の接続設定が混在してしまいます。

まず失敗の種類を確認し、その後に復元するか決める

接続タイムアウトは、リクエストが制限時間内に完了しなかったことを示しますが、原因はドメイン名の解決、ネットワーク経路、サーバーからの応答などさまざまです。タイムアウトという表示だけで原因を決めつけないでください。認証エラーが返された場合は、アドレス全体が変更されていないか、認証情報が有効か、サービス側でリンクの再発行が必要か確認します。Webページや認証画面が返された場合は、通信自体が成功していても、アプリがサーバーリストとして解析できない可能性があります。

解析エラーと空のリストも分けて対応してください。解析エラーは形式の変更、内容の欠落、未対応の項目などが原因の可能性があります。空のリストは、サーバー側から利用可能な項目が返されていない可能性があります。元のアドレスとエラー情報を保管し、既存サービスの説明を確認してください。必要であれば、認証情報を保護したうえで返されたデータの種類を確認します。空の結果を別のサブスクリプションに何度もインポートしたり、バックアップなしで既存の記録をすべて置き換えたりしないでください。

更新後、一部のサーバーだけが使えなくなった場合は、まず該当項目のプロトコル、アドレス、トランスポート方式に変更がないか比較し、リスト内の他の既知の項目もテストしてください。1つ失敗しただけでサブスクリプション全体を削除したり、大量の再試行で問題を覆い隠したりしないでください。新しい項目が現在のネットワーク条件に合わない場合は、使える項目を残して原因を確認したほうが、同じサブスクリプションを何度もインポートするより明確です。詳しい切り分けはよくある質問とトラブル対処をご覧ください。

更新は、更新のアニメーションが止まった時点ではなく、「リストの確認が終わり、重要な用途を検証できた」時点で完了と考えてください。成功・失敗した段階を記録し、必要な復元用データを保管します。次回の自動更新で一時的な修正がすぐに上書きされないかも確認してください。認証情報を変更した場合は、他のデバイスが古いアドレスを使っていないか確認し、1台ずつ更新します。異なるデバイスの古い結果を同じ更新の結果と混同しないためです。

06 / ORGANIZE

複数サブスクリプションの整理とルール参照

まず提供元を区別し、表示順を整える

複数のサブスクリプションを管理する場合、サーバー項目を長いリストにまとめることより、各項目がどのサブスクリプションから取得されたか把握することが重要です。用途を区別できる短く安定した名前を付け、提供元と用途はサブスクリプション側に、個々の違いはサーバーのメモに記載してください。テスト結果に応じて名前を頻繁に変えると、次回の更新や並べ替え後に同じ項目を見つけにくくなります。

「用途—提供元の略称—補足」の形式で名前を付ける方法があります。提供元の略称は自分で決め、完全なドメイン名やアカウント情報を含める必要はありません。2つのサブスクリプションが同じ名前の項目を返す場合は、まずそれぞれの提供元を確認してから、実際に重複しているか判断してください。名前が同じでもアドレス、認証、トランスポート設定が異なる場合があります。名前が違っても接続先が同じとは限りません。表示名だけでなく重要な項目を比べて重複を判断してください。

手動で追加したサーバーは、サブスクリプションから取得した項目と区別してください。メモに独立した項目、テスト用の複製、長期保管する項目などと記載し、設定を再確認する時期も記録できます。一時的な修正を唯一の有効な項目として長く使い、元のサブスクリプションも更新され続けることを忘れないようにしてください。提供元が明確なら、サーバー側で管理される変更と自分で管理する変更を区別でき、互いの設定を上書きするリスクを減らせます。

サーバーリストとGlobal Routingの役割は別

リストを整理しても、通信の振り分け方法は自動的に変わりません。Global RoutingのConfig、Proxy、Directは、それぞれ異なる動作モードです。Configでは現在の設定に基づいてリクエストの行き先を決め、Proxyでは通常の通信を選択中のプロキシ経路に送り、Directでは直接接続します。実際のリクエストはシステムの制約や関連設定にも影響される場合があるため、これらを同じ切り替えスイッチとして扱わないでください。

Directになっている場合、サーバーを選んでリストを整理しても、リクエストがそのサーバーを経由しているとは限りません。Configの場合は、テスト対象の通信がルールによってPROXYに振り分けられているか確認してください。状態を切り替えて比較テストできますが、テスト後は通常の設定に戻します。一時的に特定の宛先へ接続するために切り替えた後、通常のルールによる振り分けから外れていることを忘れると、後の確認が難しくなります。

以下はShadowrocketの.confで使うルール構文の例です。順序と通信先を説明するもので、サーバーの認証情報は含みません。通常、ルールは上から順に照合され、先に一致したリクエストを最後の行で再判定することはありません。例のドメインは実際のテスト用ではありません。自身の設定に追加する前に既存ルールの位置とポリシー参照を確認し、重複した最終ルールで後続の内容を遮らないようにしてください。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY

整理する項目の変更範囲を決める

Configのポリシーグループが特定のサーバー名や絞り込み条件を参照している場合、項目名の変更、移動、削除によって選択肢が変わることがあります。名前を統一する前に、Configにそのような参照があるか確認してください。サブスクリプションの更新後にポリシーグループが空になった場合は、提供元による名称変更で絞り込み条件に一致しなくなった可能性もあり、サブスクリプション全体が無効とは限りません。「サブスクリプションに項目があるか」「条件に一致するか」「現在どのポリシーが選ばれているか」の順に確認します。

Global Routing確認する項目整理だけでは代わりにならない確認
Configルールの順序とポリシー参照リクエストが実際に一致したルールを確認する
Proxy現在選択中のプロキシ経路プロトコルと接続先の利用可否を確認する
Directローカルネットワークから直接接続した結果特定のサーバーを使用したことの証明

見た目の煩雑さを減らしたい場合は、削除する前に、画面に絞り込みや折りたたみなどの表示機能があるか確認してください。提供元が引き続き返すサーバーを削除しても、次回の更新で再び表示されることがあります。手動削除を繰り返しても安定した管理方法にはなりません。名前で絞り込む場合は対象範囲を確認し、似た名前の使える項目まで除外しないようにしてください。提供元が名前を変更した後も結果を確認します。

複数のデバイスでリストを整理する場合、「並び順が同じ」ことを「設定が完全に同じ」と考えないでください。デバイスごとにネットワークやConfigが異なる場合があり、1台だけに手動の項目が残っていることもあります。移行前に、サブスクリプションのアドレス、重要なルール、既定の選択など、本当に揃える必要がある内容を整理してください。ローカルでのテスト結果や一時的な並べ替えは、移行しなくてよい場合があります。バックアップを小さくし、古い状態を別のデバイスに持ち込むのを防げます。

まとめて整理した後は、重要な用途に使える項目があること、ポリシー参照先にメンバーが残っていること、新しい命名方法を説明できることの3点を確認してください。統合、名前変更、重複削除、ルール変更を一度に行ってからテストするのは避けましょう。サブスクリプションごとに処理し、それぞれの確認が終わってから次に進みます。結果を説明でき、元に戻せる整理であれば、見た目を整えるだけでなく、元の長いリストより管理しやすくなります。

07 / CONNECTIVITY TEST

遅延テスト、並べ替え、実際の接続性

何をテストしているか確認する

Connectivity Testの結果は、具体的なテスト方法、テスト対象、ネットワーク環境によって異なります。接続確立までの時間を主に測るテストもあれば、プロキシ経由で対象にアクセスした際の応答も含めて測るものもあります。数値を比較する前に、現在のテスト方法を確認してください。異なる方法の結果を同じ基準で比べてはいけません。短い時間であっても、そのテストの特定の段階を示すだけです。継続的な通信速度や、すべてのアプリの使い心地を直接表すものではありません。

遅延、通信量、安定性はそれぞれ別の指標です。Webページの初回表示は名前解決や接続確立の影響を受け、大容量ファイルの転送は継続的な通信速度に左右されます。通話やリアルタイム操作では揺らぎやパケット損失が重要です。テスト結果による並べ替えは候補を絞るのに役立ちますが、実際の用途での確認に代わるものではありません。候補を選んだ後も、自分の用途で接続が安定するか確認し、リストの上位にあるというだけで他の異常を無視しないでください。

テストのタイムアウトも原因は1つではありません。サーバーに到達できない、テスト対象が応答しない、ネットワークが特定のトランスポートを制限している、テスト方法がその経路に適していないなど、複数の可能性があります。テストには失敗しても実際のリクエストが正常な場合は、テスト対象と方法を確認します。テストと実際のリクエストの両方に失敗する場合は、プロトコル、認証、ネットワーク経路を確認してください。2種類の結果を別々に記録すると、テスト先の問題をサーバー全体の障害と誤認しにくくなります。

比較できるテスト条件を整える

サーバーを比較する際は、同じデバイス、ネットワーク、テスト方法、対象を使い、バックグラウンドで大量の通信を行わないようにします。候補を少数に絞って一度テストし、少し時間を置いて再度テストして、結果が大きく変わらないか確認してください。たまたま得られた低い数値やタイムアウトだけで、長期的な品質を判断することはできません。モバイルネットワークの切り替えやスリープ解除後は、現在のネットワーク状態を確認してから結果を解釈してください。

リスト全体をテストすると、多数のリクエストが同時に送信され、テスト自体がリソースを使う場合があります。項目が多い場合は、用途やプロトコルで絞り込み、グループごとにテストしてください。すべての項目を連続して何度もテストする必要はありません。会議やダウンロードなど重要な作業中は、大量のテストと実際の利用を同時に行わないでください。テスト後に一時的な変動があった場合は、繰り返しのテストを止めて元の接続を観察します。負荷による影響をサーバー側の継続的な異常と混同しないようにしてください。

ローカルネットワークの影響を確認するには、Wi-Fiとモバイル通信を使って条件を管理した比較テストができます。ただし、サーバーとルールを同時に変更しないでください。特定のプロトコルが一方のネットワークだけで異常になる場合は、ネットワーク条件をさらに確認してください。そのプロトコルの項目をすべて削除するのは適切ではありません。Hysteria2などUDPを使うトランスポートでは、ローカルネットワークの条件とサーバー設定を分けて確認します。詳しい手順は通信速度が遅い場合の段階的な確認方法をご覧ください。

並べ替えは表示の変更であり、接続を保証するものではない

遅延で並べ替えた後、選択中のサーバーが変わっていないか確認してください。リストの先頭に表示されていること、選択状態であること、ポリシーで実際に使用されていることは別々の状態です。リスト上の位置だけで接続先を判断しないでください。Configのポリシーグループを使っている場合は、別の項目が選択されていないかも確認します。実際のリクエストと関連する記録を確認して初めて、期待した経路で通信していると判断できます。

テスト結果は環境によって変わるため、以前の数値を長期間残しても参考にならないことがあります。ネットワーク、サブスクリプションのアドレス、サーバーのトランスポート設定が変わった場合は、重要な候補を再テストしてください。古い並べ替え結果を永久の優先順位と考えたり、提供元の名前を性能の保証と見なしたりしないでください。日常の管理記録にはテスト条件も記載し、背景のない数値だけを保存しないようにします。

すべての項目が同時にタイムアウトする場合は、サーバーを1つずつ切り替える前に、ローカルネットワーク、システムの接続状態、テスト対象に到達できるかを確認します。特定のサブスクリプション内の項目だけが失敗する場合は、その更新状態と共通する設定を比較してください。複数のサブスクリプションで同じプロトコルが失敗する場合は、ローカルネットワークとそのプロトコルの設定に注目します。共通点で分類すると、項目を1つずつ作り直すより早く原因を絞り込め、元の記録も残せます。

最終的な選択は、単独の最小値を追い求めるのではなく、具体的な用途を基準にしてください。現在のネットワークで検証済みの候補を少数残し、どのサブスクリプションに属するか把握して、接続に問題が起きたら同じ条件で確認します。一度のテスト結果だけで項目を大量に削除しないでください。まず問題が再現するか確認してから、整理や更新を検討します。再現性のある比較結果が、長期的な管理方法を決める根拠になります。

08 / BACKUP & RESTORE

削除、バックアップ、復元の確認

削除前に対象と影響範囲を確認する

サーバーを1つ削除する、サブスクリプション全体を削除する、Configを削除する操作では、影響する対象が異なります。サブスクリプションから取得したサーバーを削除しても、次回の更新で再び表示される場合があります。サブスクリプションの登録を削除すると、操作範囲に応じて関連リストも削除されることがあります。Configを削除すると、ルールや他の設定に影響する可能性があります。実行前に確認画面を読み、現在の選択が対象に依存していないか確認してください。名前が似ているというだけでまとめて削除しないでください。

重複項目を整理する前に、何を基準に重複と判断するか決めてください。アドレスが同じでも、ポート、認証、トランスポート設定が異なる場合があります。サブスクリプションが同じ名前を返しても、用途が異なる可能性があります。確信が持てない項目は、すぐに削除せず、メモを付けて残しておくほうが安全です。項目がポリシーグループから参照されている場合は、先に参照先を変更するか代替項目を確認してください。削除後に候補がなくなる可能性があります。

デバイス上で削除しても、サーバー側のアクセス権が取り消されるわけではありません。サブスクリプションのアドレスが漏れた場合、アプリの登録を削除しても、他の人が持つコピーは無効になりません。サーバーのパスワードや秘密鍵も同様です。アクセス権を取り消すには、既存サービスの認証情報管理手順を使い、その後、自分のすべてのデバイスの記録を更新してください。ローカルでの整理は保存範囲の管理、サーバー側での認証情報変更はアクセス権の管理であり、互いに代用できません。

バックアップするデータと対象範囲を明確にする

バックアップ前に、復元が必要な対象を整理してください。サブスクリプションのアドレス、手動で追加したサーバー、Configファイル、ポリシー選択、覚え直すのが難しいローカル設定などです。アプリのエクスポートやバックアップ機能によって含まれる範囲は異なります。1つのファイルにすべての内容が含まれるとは限りません。実際の選択肢と説明を確認し、完了後は管理できる場所に保存します。どの対象が含まれ、どの設定を手動でやり直す必要があるかも記録してください。

サブスクリプションのアドレスがあればリストを再取得できる場合がありますが、手動で追加したサーバーやルール設定のバックアップにはなりません。反対に、古いリストにサーバー設定が含まれていても、今後サーバー側の変更を更新できるとは限りません。復元計画では、再取得できるデータとローカルからしか復元できないデータの両方を考慮してください。サブスクリプションから取得した項目は、表示順を保つために大量の独立した複製を作らないようにします。管理元がわからなくなるのを防げます。

バックアップファイル、エクスポートした共有リンク、QRコードはすべて機密情報として扱ってください。自分で管理できる保存先を選び、アクセス範囲を制限し、ファイル全体を公開のサポート依頼に添付しないでください。エクスポート機能に暗号化やパスワード保護がある場合は、実際にどの範囲を保護するか確認し、復元用のパスワードは別の安全な場所に保存します。リセットや交換を予定しているデバイスだけに、唯一の復元用パスワードを保存しないでください。

データ復元する内容追加で確認する項目
サブスクリプションの登録サーバー側のリストを再取得するアドレスと認証情報が有効か
独立したサーバー手動で入力した設定を復元するプロトコルと認証項目が揃っているか
Configファイルルールと設定を復元するポリシー参照先に対応する項目があるか
管理メモ命名と一時的な変更の内容を把握する残す変更と元に戻す変更

実際の動作確認をもって復元完了とする

機種変更や再インストール後は、まずアプリを入手し、バックアップの範囲に従ってデータを復元してください。iPhone / iPadでは、アプリの入手とサブスクリプションの復元は別の手続きです。購入済みのアプリを復元しても、サーバー情報まで自動的に揃うわけではありません。他のプラットフォームでは全プラットフォーム対応のダウンロードページから入手し、バックアップ形式と、移行先が対応するインポート方法を確認してください。あるプラットフォームのバックアップ一式を、確認せず別のプラットフォームの設定にそのまま置き換えられるとは限りません。

復元する際は、まずConfigと既存の情報をインポートし、必要な項目が揃っているか確認します。その後、依存関係に応じてポリシー参照と現在の選択を設定してください。移行先にすでに一部の項目がある場合は、無計画に新旧のデータを統合しないよう、先に現在の状態をバックアップします。同じ名前の項目を見つけても、すぐにまとめて削除せず、提供元と設定を比較してください。1つのグループの内容が正しいことを確認してから次に進むと、復元中の原因不明な重複や上書きを減らせます。

初回の復元後、古いデバイスのデータをすぐにすべて削除しないでください。サブスクリプションを更新できるか、手動サーバーの編集画面を開けるか、重要なルールがあるか、Global Routingが想定した状態かを確認し、実際の用途で接続を検証してください。システムから接続機能の再許可を求められる場合があります。この権限は通常のバックアップ項目として扱わず、現在のデバイスに表示された手順に従って許可し、接続後に状態を確認してください。

復元テストには、失敗時の対応確認も含めてください。サブスクリプションの更新に失敗した場合、元の情報の保存場所がわかるか。サーバー項目が削除された場合、検証済みの代替項目があるか。設定の参照先が無効になった場合、該当するルールとポリシーを確認できるか。バックアップの価値はファイルをインポートできることだけではなく、変更があっても必要な機能を復旧する方法がわかることです。内容がわからないままファイルを保存するだけでは、確実な復元方法になりません。

最後に一時的なエクスポートファイル、期限切れのQRコード、不要な複製を整理し、現在の状態を説明できる管理記録を1つ残してください。認証情報を変更した場合は、古いバックアップに今後共有すべきでない情報が含まれていないか確認し、自分の保存方針に従って処理します。日常の基本操作はクイックスタートガイドを、具体的なエラーはよくある質問とトラブル対処をご覧ください。次回、大規模な更新、整理、移行を行う前に、この章でバックアップの範囲と復元手順を再確認してください。