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

1. Subscribe：既存のサブスクリプションを追加

入力するのはサブスクリプションURLか確認する

サブスクリプションURLは、再取得できるサーバーリストを指すもので、リスト内の個々のサーバーとは異なります。追加するとShadowrocketが応答内容を解析して項目を作成し、次回の更新時には同じURLから再取得します。取り込む前に、手元の情報がサブスクリプションリンク、単一サーバーの共有リンク、手入力が必要なサーバー情報のどれなのかを確認してください。URLの長さだけで用途を判断したり、ブラウザーで開いたアカウントページをサブスクリプションURLとして扱ったりしないでください。この記事では、すでにご自身のサブスクリプションをお持ちであることを前提に説明します。

サブスクリプションリンクには、アクセス認証情報を含むクエリパラメーターが付いていることがあります。コピーするときは、スキーム、パス、パラメーターを含めて全体を選択し、引用符、改行、日本語の句点、チャットアプリが追加した説明文などが混ざらないようにしてください。以下のURLは形式を確認するための例であり、接続には使用できません。実際のURLを公開スクリーンショット、共有メモ、問い合わせ文に載せないでください。一般的なURLに見えても、機密情報として扱う必要があります。

https://example.com/sub?token=xxxx

HomeからSubscribeを追加する

Homeの追加メニューからAdd Serverを開き、サブスクリプション用のSubscribeを選択します。URL欄にリンク全体を入力し、備考欄には識別しやすい名前を付けてください。保存前にURLが完全な状態か、特に末尾のパラメーターが残っているかを確認します。画面のレイアウトによってメニューの位置は異なる場合があります。実際に表示されている種類と入力欄に従い、通常のサーバー用Address欄にサブスクリプションURLを入力しないでください。保存後、取得が完了するまで待ってから一覧を確認します。

確認するときは、まずサブスクリプショングループが表示されているか、次にグループ内にサーバー項目があるか、最後に項目を1つ選び、プロトコル、アドレス、ポートが手元の説明と一致するかを確認します。この3点はそれぞれ、サブスクリプションの作成、応答の解析、内容の正しさを確認するもので、相互に代用できません。サブスクリプション名が表示されても、ローカルに項目が保存されたことしか分かりません。リストに項目があっても、すべてのサーバーに接続できるとは限りません。初回の取り込み後は、接続を確認するまで既存の利用可能な項目を残しておき、確認後に整理してください。

取得エラーと接続エラーを分けて確認する

保存後にサーバーが表示されない場合は、まずURLが完全にコピーされているかを確認し、現在のネットワークからサブスクリプションURLにアクセスできるかを調べます。ブラウザーにログイン画面、説明ページ、エラーメッセージが表示される場合、応答はサーバーリストとして解析できない可能性があります。ブラウザーで文字が表示されても、形式が正しいとは限りません。問題がある場合は、お手持ちのサブスクリプションの案内を確認してください。Webページの内容をサーバー情報に変えようとして、プロトコルの種類を何度も変更しないでください。取得段階のエラーでは、サーバーの暗号化設定を変更せず、まずURLと応答を確認します。

項目が表示されても接続できない場合は、サーバーの項目とネットワーク到達性を確認します。サブスクリプションの取得は成功していても、返された項目が古い場合や、一部の項目に必須パラメーターがない場合があります。サブスクリプショングループ名、失敗した項目のプロトコル、エラーが発生した段階を記録すれば十分です。リンク全体を公開する必要はありません。すべての項目で失敗する場合と特定の1項目だけが失敗する場合では、確認する順序が異なります。前者は共通のネットワーク条件とリストの内容を、後者はその項目固有の設定を優先して確認してください。

管理のため、サブスクリプションごとに用途、元のURLの安全な保管場所、手動で変更した内容を記録しておくと便利です。URLを公開メモに記載しないでください。更新や機種変更の際に、項目がサブスクリプション由来か手動作成かを判断しやすくなります。サブスクリプションが重複しているように見えても、すぐに片方を削除しないでください。まずURLと内容を比較し、備考だけが異なるのか確認してから、第8章の手順で整理します。

2. Add Server：手入力する項目とプロトコル設定

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

手動追加は、完全なサーバー情報をお持ちで、項目を1つずつ確認しながら登録したい場合に使います。Add Serverを開いたら、最初にTypeを選択してください。プロトコルごとに表示される項目が異なるため、種類を間違えると、アドレスやパスワードが正しく見えても接続設定として成立しません。ポート番号だけからプロトコルを推測しないでください。ポートはプロトコルを示すものではありません。同じアドレスでも異なるサービスを提供している場合があります。お手持ちのサーバー設定に従い、プロトコル、ポート、認証方式、通信設定をまとめて確認してください。

共通項目では、通常Addressにサーバーのドメイン名またはアドレスを、Portにサーバーの待ち受けポートを入力します。備考は識別用です。完全なURLの入力を明示的に求める欄でない限り、AddressにWebページのパスや共有リンク全体を含めないでください。貼り付けた後は先頭と末尾に空白がないか確認し、Portにコロンを含めないようにします。パスワードや識別子などの認証情報は、英字の大文字・小文字、ハイフン、特殊文字を含めてそのまま入力してください。読みやすくするために置き換えたり、推測で補ったりしないでください。

プロトコルに応じて認証と通信設定を確認する

Shadowsocksでは、暗号化方式とパスワードを一致させる必要があります。別のプロトコル用の認証情報をそのまま入力しないでください。VMessとVLESSでは識別子の項目名が似て見えることがありますが、プロトコル上の意味は異なります。お手持ちの設定を参照し、認証、通信方式、安全性の設定をそれぞれ確認してください。TrojanはTLS設定と併用されることが多いため、パスワードだけを入力して証明書名に関する要件を見落とさないようにします。Hysteria2も、プロトコル名からサーバー設定を推測せず、お手持ちの情報に従って認証とTLSの項目を確認してください。

WireGuardの設定には、鍵、ピア、ネットワーク範囲など、意味の異なる項目が含まれます。一般的な「アドレスとパスワード」の設定として扱わないでください。取り込みや入力の際は、自分の秘密鍵とピアの公開鍵を区別し、秘密鍵をトラブル相談などで公開しないでください。HTTPやSOCKS5では、サーバーがユーザー名とパスワードを要求するか、どのプロトコルを設定しているかを確認します。ここに挙げたプロトコルは項目を見分けるためのもので、同じ設定値を使って種類を切り替えられるという意味ではありません。

安全性の検証を維持し、項目を1つずつ変更してテストする

TLSの証明書検証名とサーバーへの接続アドレスは異なる場合があります。SNI、Host、Pathも、ひとまとめの「ドメイン設定」として扱わないでください。認証に失敗した場合は、接続先、通信の入口、証明書の識別情報をそれぞれ確認します。証明書検証を無効にすることを一般的な解決策にしないでください。用途が分からない通信パラメーターも追加しないでください。サーバーの説明に任意項目の記載がない場合は、適切な初期値を維持し、その項目を本当に入力する必要があるか確認してください。

保存後は、この手動登録した項目だけを選んでテストします。変更が必要な場合は、一度に1種類の項目だけを変え、変更前後の結果を記録してください。パスワード、ポート、通信設定、ルールを同時に変更すると、失敗の原因を特定しにくくなります。サブスクリプション由来の項目を編集するときは、更新時に変更が上書きされるかどうかも確認してください。手動の調整内容を長期保存する場合は、画面に複製機能があれば別の項目として作成し、明確な備考を付けて区別します。サブスクリプション項目への一時的な変更が、長期間有効だと考えないでください。

手入力した項目で接続できたら、以前から接続できていた別の項目ではなく、意図した項目が選択されていることも確認します。一度切断してから対象を選び直して接続し、ご自身が利用する権限を持つサービスにアクセスして検証してください。項目に疑問が残る場合は、元のサーバー情報と照合します。よくある問題の分類はFAQをご覧ください。手当たり次第にパラメーターを組み合わせず、項目ごとに確認してください。

3. Scan QR Code：QRコードとクリップボードからの取り込み

QRコードは入力方法であり、設定の種類ではない

QRコードには、単一サーバーの共有リンク、サブスクリプションURL、通常のテキストなどを含められます。Scan QR Codeを使う前に、QRコードがお手持ちの設定に対応することを確認し、取り込みたいものが単一サーバーかサブスクリプショングループかを判断してください。スキャンに成功しても、テキストを読み取れたことしか分かりません。プロトコルの項目がすべて揃っていることや、サーバーへの接続が確認済みであることを示すものではありません。読み取り結果が想定と異なる場合は、すぐ保存して接続を有効にするのではなく、まず内容の種類を確認します。

アプリでScan QR Codeを開き、システムの案内に従ってカメラへのアクセスを許可するか選択します。QRコード全体が読み取り枠に収まるようにし、端の切れ、反射、過度な拡大を避けてください。現在のデバイスに保存したQRコードを使う場合は、実際の画面に写真ライブラリから読み取る機能が表示されているときに限り利用します。すべてのレイアウトで同じ場所に同じ操作があるとは限りません。画像は自分で保存した元の資料を使い、転送や圧縮、合成を何度も繰り返した不鮮明な画像は避けてください。

読み取り後に設定のプレビューが表示されたら、Type、アドレス、ポート、備考を確認してから保存します。QRコードには複数の情報がまとめて記録されている場合があります。見覚えのある備考だけで正しい内容だと判断しないでください。備考は識別用のラベルであり、サーバーの真正性を検証するものではありません。サブスクリプションURLが読み取られた場合は、サブスクリプションとして追加してリストを取得します。単一サーバーのプロトコルリンクの場合は、サーバーの取り込み手順で処理します。両者はその後の更新方法が大きく異なります。

クリップボードから取り込む前にテキストの前後を整える

共有リンクをコピーするときは、説明文、番号、箇条書き記号、引用符を含めず、リンクだけを選択してください。Shadowrocketを開いたときにクリップボードの読み取りや内容の取り込みを促すメッセージが表示されたら、まず内容の出所と目的を確認してから実行します。通知が表示されない場合は、現在の画面にある取り込み機能を使ってください。システムのクリップボード権限は読み取り手順に影響します。取り込みの通知がないからといってリンクが無効とは限らず、確認のために別の機密情報を何度もコピーするのも避けてください。

クリップボード内に複数行のテキストがある場合は、特に注意して確認します。サブスクリプションの応答にはエンコードされた複数の項目が含まれる場合があります。一方、チャットの履歴で複数のリンクが連結されているだけの場合もあり、同じ方法で取り込めるとは限りません。一括取り込みに失敗したら、まず完全な共有リンクを1つ選び、解析できるか確認してから元の形式を調べます。エンコードの仕組みが分からないまま、何度もデコードしたり、改行を追加したり、特殊文字を置き換えたりしないでください。有効なデータを壊すおそれがあります。

保存後に取り込み結果を確認する

取り込み結果は、少なくとも3段階で確認します。Homeに新しい項目があること、詳細画面で主要な項目を確認できること、接続テストに成功することです。QRコードを読み取れても項目が追加されない場合は、まだ保存していない編集画面にいるのか、独立したサーバーではなくサブスクリプショングループとして取り込まれたのかを確認します。リストが長い場合は、設定したばかりの備考を使って項目を探してください。見分けにくい複製を作らないよう、同じQRコードを続けて何度も読み取らないでください。重複して取り込んでも、元の設定項目の問題は解決しません。

保存前に読み取りで失敗した場合は、画像が完全か、プロトコルの接頭辞とテキスト形式が正しいかを確認します。保存後に接続できない場合は、認証、通信方式、サーバーへの到達性を確認します。この区別を付けることで、調査範囲を絞れます。他の人が整形し直したリンクは、安全に保管している元の資料と照合し、全角記号、自動改行、末尾の文字列に注意してください。画面に短く表示されたテキストをコピーしても、リンク全体がコピーされているとは限りません。

取り込みが完了したら、一時的なスクリーンショットやクリップボードの記録を適切に管理してください。QRコードやリンクが管理できない場所に漏れた場合は、元のサービスの認証情報管理手順に従って該当する情報を変更します。デバイス上から取り込んだ項目を削除しても、漏えいした認証情報が自動的に無効になるわけではありません。形式の見分け方は次章をご覧ください。システムの許可に関する問題は、まず初回接続ガイドで許可の手順を確認し、権限の問題と取り込みの問題を混同しないようにしてください。

4. 共有リンク：形式と設定の範囲

まず接頭辞を確認し、次に内容の種類を見分ける

共有リンクはプロトコルの設定をコピー可能なテキストにまとめ、手入力によるミスを減らすためのものです。一般的な接頭辞にはss://、vmess://、vless://、trojan://、hysteria2://があります。接頭辞からアプリは解析方法を判断できますが、通信方式や認証の詳細までは分かりません。単一の共有リンクは通常、1つのサーバー情報を表します。一方、サブスクリプションURLは複数のサーバー情報を再取得するためのものです。単一の共有リンクを保存しても、サブスクリプションリストが継続的に更新されるわけではありません。

形式によっては、エンコードされた認証情報、クエリパラメーター、#以降の備考が含まれます。エンコードは表記方法であり、情報を秘匿する手段ではありません。リンク全体を持つ人は、通常その中の設定情報も取得できます。リンクによってはパーセントエンコードが使われ、備考の日本語もエンコードされる場合があります。問題を調べるときは元のテキストを保持してください。見た目を整えるために等号、パーセント記号、区切り文字を手作業で削除したり、末尾の備考をパスワードの一部と誤認したりしないでください。

パラメーターが対応していても、内容が完全に一致するとは限らない

同じプロトコルでもリンクによって項目の表現方法が異なり、取り込み機能がすべての任意パラメーターの組み合わせに対応しているとは限りません。取り込みが完全かどうかは、成功メッセージの有無ではなく、取り込み後の各項目で判断してください。特に通信方式、TLS、SNI、Host、Pathなどが欠けていると、サーバー項目は作成されても想定した接続ができない場合があります。元のリンクに追加パラメーターがある場合は、アプリが認識しているかを1つずつ確認し、似た名前の設定項目に推測で割り当てないでください。

共有リンクから1つの項目を取り込んでも、Config全体が置き換わることは通常ありません。サーバーは接続先を決め、ルールはリクエストにどのポリシーを適用するかを決めます。両方を組み合わせて使います。Global RoutingではConfigの設定に基づき、現在のルールを使ってリクエストを処理します。ProxyとDirectでは動作が異なります。問題を調べる際は、まず現在の接続モードを確認し、次にルールを確認する必要があるか判断してください。ルールの設定によるDirect接続を、共有リンクからサーバー情報を取り込めなかったと誤認しないようにします。

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

上の説明はルールとサーバー情報の役割の違いを示すもので、設定例の全体を提示するものではありません。DOMAIN-SUFFIXはドメインの末尾で照合し、GEOIPはIPアドレスの地域情報に基づいて判定し、FINALは最終的なフォールバックを担います。ルールの順序は一致結果に影響します。PROXYとDIRECTはポリシーを示すキーワードであり、サーバーのパスワードではありません。Add Serverの認証欄にも入力しないでください。実際に使用する前に、各ルールが適用される範囲を理解し、現在のConfig内の該当箇所を確認します。

共有・保存する情報の範囲を明確にする

資料を共有または保存する前に、エクスポート対象が単一サーバー、サブスクリプションURL、ルール設定のどれなのかを確認してください。復元したときに得られるものはそれぞれ異なります。サーバーリンクは接続設定を再作成し、サブスクリプションURLはリストを再取得し、ルールファイルはリクエストの処理方法を復元します。いずれか1種類だけをバックアップしても、利用環境全体を復元できるとは限りません。ルールの調査を依頼する場合は、関係するルールを必要に応じて伏せて共有し、接続情報をまとめて渡さないでください。

形式に迷った場合は、共有リンクとサブスクリプションリンクの違いを確認してから、元の資料で入力対象を確認します。共有リンクを一般的なWebページのURLに書き換えたり、HTTPSのサブスクリプションURLに任意のプロトコル接頭辞を付けたりしないでください。形式の変換は、各項目の意味を理解し、変換先の形式がその項目に対応している場合にのみ有効です。接頭辞を手動で置き換えてもプロトコルは変換されず、設定の一部が失われるおそれがあります。

5. 更新方法：更新とエラーへの対処

サブスクリプションの更新で変わる内容を把握する

サブスクリプションの更新はサーバーリストを再取得する操作です。現在の接続速度を上げたり、アプリ自体を更新したりするものではありません。リモートのリストが変わると、項目の追加・削除、名称や設定の変更が発生する場合があります。サブスクリプションに関連付けられたローカルの変更も、更新によって上書きされることがあります。重要な項目の備考、ポート、通信設定を変更した場合、その内容が永久に保存されるとは考えないでください。更新前に必要な変更点を記録し、元の設定を修正するか、独立した手動項目として残すかを判断します。

日常的な確認では、まず手動で1回更新し、明確なエラーが出るかを確認してからリストの変化を調べます。サブスクリプション関連の操作は、リスト上のジェスチャーや編集メニューから利用できる場合があります。現在の画面の表示に従ってください。更新完了後は、通知が消えたかどうかだけでなく、サブスクリプショングループと以前選択していた項目も確認します。現在のサーバーが削除されたり名称が変わったりした場合は、利用可能な項目を選び直して接続状態を確認します。リストの更新と使用中の接続先の切り替えは別の操作です。常に連動して完了するとは限りません。

実際の利用頻度に合わせて自動更新を設定する

自動更新の設定は、アプリで実際に利用できるサブスクリプション設定から確認してください。アプリを開いたときに更新される場合でも、あらゆるバックグラウンド状態で正確な間隔ごとに更新されるとは限りません。システムのスケジュール、ネットワーク状態、アプリの動作状況によって実行時刻が変わることがあります。重要な利用の前にリストが有効か確認したい場合は、バックグラウンドで更新済みかを推測するより手動で確認する方が確実です。サブスクリプション名に含まれる日付だけで、最後の取得が成功したかどうかを判断しないでください。名前は固定の文字列かもしれません。

更新の頻度を上げても、信頼性が高まるとは限りません。同じURLに短時間で何度もアクセスすると、ネットワークの変動、リモート側のアクセス制限、キャッシュされた応答などの影響を受ける場合があります。まず1回取得し、失敗した場合はエラー内容と発生段階を確認します。異なる結果が出るまで更新ボタンを連続して押すのは避けてください。自動更新後に問題が起きた場合は、「取得エラー」「リストの変更」「接続エラー」のどれかを記録します。それぞれ対処方法が異なります。重要なローカル項目は、更新間隔を短くするより安全にバックアップしておく方が役立ちます。

URL、ネットワーク、内容の3段階で確認する

最初にURLを確認します。元のリンクが途中で切れていないか、クエリパラメーターがすべて残っているか、サブスクリプションURLをWebページのURLに置き換えていないかを確認してください。機密情報を含むURLを公開オンラインツールで調べないでください。元のテキストとローカルで照合できます。認証情報が変更されていても、古いURLが端末に残っている場合があります。アプリを再起動しただけでは新しいURLに変わりません。新旧URLの関係を確認してから既存のサブスクリプション項目を変更し、用途の異なるサブスクリプションを混同しないようにします。

次にネットワークを確認します。現在の接続からサブスクリプションのサーバーにアクセスできるかと、取り込み後のサーバーに接続できるかは別の問題です。タイムアウトやドメイン名の解決エラーが発生する場合は、別の利用可能なネットワークで再確認します。その際は比較できるようURLを変更しないでください。ネットワークを切り替えながらリンクやルールも変更すると、どの変更が影響したのか判断できなくなります。現在のルーティングが取得に影響していると思われる場合は、まず設定を記録して慎重に確認し、一時的な変更を長期設定として扱わないでください。

最後に内容を確認します。リクエストが成功しても、有効なリストが返されたとは限りません。リモートからエラーの説明、ログインページ、空の応答、対応していない形式が返される場合があります。その場合でも「最初からやり直す」ために、利用可能なリストをすべて先に削除しないでください。元のサービスの案内で指定された形式を確認し、個人情報を伏せたエラーの種類を記録します。1つのサブスクリプションだけに問題がある場合は、そのグループのURLと応答を優先して確認します。すべてのグループで同時に問題が起きた場合は、共通のネットワーク条件とアプリの状態を確認してください。

更新に成功しても接続結果が変わった場合は、まずサーバーが置き換わっていないか確認し、次に選択中の項目とGlobal Routingを確認します。その後、ルールと接続先へのリクエストを調べてください。問題の前後の状況を簡潔に記録しておくと、同じ確認を繰り返さずに済みます。手動更新とアプリ起動時の自動更新についてはサブスクリプションの更新方法をご覧ください。項目を再確認する場合は、第2章の手順を参照してください。

6. 複数サブスクリプションの整理：グループ分けと命名

登録元と利用目的を分けて記録する

複数のサブスクリプションを管理するときに大切なのは、リストを短くすることではなく、各項目の登録元、更新時の変化、現在の接続先を把握できることです。サブスクリプショングループは登録元を、サーバーの備考は項目の識別を、ローカルの記録は変更内容を管理します。これらを長い名前1つに詰め込んだり、見た目を揃えるためにすべてのグループを同じ名前にしたりしないでください。同じ名前は選択ミスを招きやすく、同じURLは重複登録を示している可能性があります。それぞれ別に確認しましょう。

まず、サブスクリプションには用途が分かる簡潔で変わりにくい名前を付け、元のURLと変更履歴は安全な場所に保管してください。サーバー名は元のラベルを利用し、独立した手動項目には見分けやすいローカル用の印を付けます。備考にパスワード、秘密鍵、サブスクリプショントークンを含めないでください。備考は一覧、スクリーンショット、エクスポートに表示されることがあるため、認証情報の保存には適しません。名前に固定的な性能を保証するような表現も使わないでください。一度の測定結果が今後も続くとは限りません。

重複項目は、内容を確認してから整理する

同じドメイン名とポートを使う2つの項目でも、認証、通信方式、安全性、ルーティングの用途が異なる場合があります。一方、名前が異なっていても設定内容が同一の項目もあります。整理するときは、まずプロトコルとアドレス、次に認証と通信設定、最後に所属するサブスクリプションを比較してください。認証情報の比較は端末内で行い、公開テキストに貼り付けないでください。項目の意味が一致し、今後の更新との関係も把握できた場合に限り、片方を残すことを検討します。

同じサブスクリプションを何度も取り込んだ結果、項目が重複している場合は、サーバーを1つずつ削除するのではなく、サブスクリプションURLを比較します。重複して作成されたサブスクリプショングループは、次回の更新後にも似たリストを再生成することがあります。整理前に現在使用しているグループを特定し、必要な情報をバックアップしてから、余分なグループを削除してください。同じグループ内で似た名前の項目があるだけの場合は、リモートのリストを確認します。画面をすっきりさせるために、異なる設定で用途がある項目を削除しないでください。

選択中の項目、並び順、ポリシーを個別に確認する

リストの順序が変わっても、現在の接続先が切り替わったとは限りません。手動での並べ替え、テスト後の並べ替え、再取り込みによって項目の表示位置は変わる場合がありますが、実際に選択されている項目は確認が必要です。長いリストを整理するときは、現在のサブスクリプショングループとサーバー名を記録してから作業し、終了後にもう一度確認してください。リモートの更新で名前が変わった場合は、以前の表示位置だけで判断せず、プロトコルとアドレスも照合します。表示位置は一覧を見やすくするためのもので、安定した識別情報ではありません。

Global RoutingのConfig、Proxy、Directも、サブスクリプションのグループ分けとは区別してください。グループ分けはリストを管理するためのもので、ルーティングのモードはリクエストの処理方法を決めます。1つのサブスクリプショングループに多数の項目があっても、アプリが用途に合わせて自動選択するわけではありません。グループ名に用途を記載しても、ルールの動作は変わりません。リクエストの処理方法を指定する場合は、備考名に頼らず、現在のConfigでルールとポリシーを確認してください。

一時的なテスト項目は、問題を再現して安全な記録を作成した後など、削除する条件をあらかじめ決めておきます。接続テストで一度遅い結果が出ただけで、使えない項目だと判断しないでください。長期間使用していないサブスクリプションも、復元に必要な資料が揃っているか確認してから整理します。作業は少しずつ行い、各段階で現在の接続と残っているグループを確認してください。一度に多数の項目を削除、改名、再取り込みすると、問題発生時に原因となった操作が分からなくなります。

iPhoneとiPadで同じ命名規則を使うことはできますが、各デバイスの選択状態、並び順、テスト結果はそれぞれ確認してください。名前が一致しているだけで、動作状態も同じだとは限りません。アプリの購入とデバイスについてはiPadでの入手方法をご覧ください。設定の移行は第8章の手順で別途確認します。名前を識別しやすくしながら、デバイスごとにネットワーク条件やローカルの状態が異なることも考慮できます。

7. Connectivity Test：接続テストと並べ替え

測定値が何を示すのかを確認する

Connectivity Testは、接続テストの結果を確認する機能です。測定値はテスト方法に応じて解釈する必要があります。テスト方法によっては、接続先への到達性、接続確立、サーバー経由でテスト対象にアクセスするまでの時間などを示します。すべての数値を、実際の通信全体の応答時間だと考えないでください。実行前に、現在使用されているテスト方法と対象を確認し、比較する場合は同じ方法を使います。1回の測定値が低くても、ダウンロード速度が速いことや、すべてのWebサイトで同じ結果になることを意味しません。

テスト結果は、現在のネットワーク、ドメイン名の解決、サーバーの負荷、テスト対象の応答、タイムアウトの設定にも左右されます。同じ項目でもネットワークが異なれば結果が変わることがあるため、条件の違いを無視して測定値だけを比較しないでください。一括テストでは複数のリクエストが同時に実行され、単独テストとは結果が異なる場合もあります。安定したネットワークでまず候補を絞り込み、実際に使う少数の項目を個別に再テストして、利用目的に沿って確認するのがおすすめです。

条件を揃えてテストし、結果を見て並べ替える

テスト中にリストが更新されないよう、先にサブスクリプションを更新してください。使用中のネットワークとテスト方法を確認してから、比較する範囲を選びます。項目数が多い場合はグループごとにテストし、毎回すべてを対象にする必要はありません。テスト後は、正常な結果とタイムアウトを区別してから並べ替えます。テスト結果による並べ替え機能があれば、一時的な候補選びに利用できます。並べ替え後も項目を識別できるよう、分かりやすい名前を付けてください。

遅延による並べ替えは候補を絞るのに役立ちますが、接続先の選択をそのまま任せるものではありません。テスト対象への応答が速い項目でも、実際に利用するサービスでは異なる結果になる場合があります。候補を選んだら、対象の項目が選択されていることとGlobal Routingを確認し、接続して目的のサービスにアクセスします。テストに成功しても実際の通信が失敗する場合は、リストで最小の数値を何度も選び直すのではなく、ルール、ドメイン名の解決、接続先からの応答を確認してください。

失敗を単一項目、グループ全体、接続先の違いに分けて確認する

1つの項目だけが失敗する場合は、アドレス、ポート、認証、通信設定を確認し、同じグループ内の正常な項目と共通点や違いを比較します。グループ全体で失敗する場合は、現在のネットワークから関連するアドレスにアクセスできるかを確認し、次にサブスクリプションの内容に変更がないか調べます。すべてのグループで失敗する場合は、テスト方法とテスト対象が現在の環境に適しているかも確認してください。この順序なら、不要な削除を避けられます。共通条件を確認する前に、すべての項目の設定が壊れたと判断しないでください。

テスト対象には応答するのに実際の接続先にアクセスできない場合は、リクエストが想定した経路を通っているか確認します。ConfigのDOMAIN、DOMAIN-SUFFIX、GEOIP、FINALなどのルールが照合結果に影響します。現在Directになっている場合、サーバーのテストに成功しても、通常のリクエストが自動的にProxyへ切り替わるわけではありません。アプリで利用できる接続情報やログを使ってポリシーを確認できます。ただし、ドメイン名、アドレス、認証情報を伏せ、問題に必要な最小限の内容だけを残してください。

候補を比較する場合は、近い時間帯、同じネットワーク、同じテスト方法で少数回テストし、結果の安定性を確認してください。何度も測定して最も良い数値だけを選ばないでください。接続が確立したら、実際の作業が完了するかも確認します。日常の利用確認の代わりに連続した一括テストを行わず、テストによる通信量やバックグラウンド動作にも注意してください。バッテリー消費が気になる場合は、バックグラウンド動作とOn Demandの使い分けをご覧ください。

最終的には、選択理由を説明できる記録を残します。使用したネットワーク、テスト方法、アクセスした対象、そのときの結果を記録してください。条件が分からない並べ替えのスクリーンショットより、原因調査に役立ちます。一時的なタイムアウトが発生した項目は、しばらく様子を見てください。不要であることと復元方法を確認してから削除に進みます。テストは判断材料を提供するもので、削除は設定管理の操作です。一度の失敗だけで自動的に削除を決めないでください。

8. 削除とバックアップ：復元用資料と移行後の確認

削除する対象を先に確認する

削除する前に、対象が独立したサーバー、サブスクリプションから作成された項目、サブスクリプショングループ全体、Configのどれかを確認してください。独立した項目を削除すると、通常はローカルの設定が削除されます。サブスクリプショングループを削除すると、そのグループと関連リストにも影響する場合があります。確認画面のメッセージは省略せずに読み、慣れた操作だと思ってすぐに確定しないでください。サブスクリプション由来のサーバーを1つだけ削除しても、次回の更新でリモートから再作成される場合があります。サブスクリプション全体の削除とは意味が異なるため、必要な範囲を先に決めてください。

現在の接続に使われている項目を削除した後、接続状態や次の選択が想定どおりになるとは限りません。整理する前に現在の項目を記録し、接続を切ってから削除し、完了後に改めて項目を選択して確認できます。使わない項目を一時的に非表示にしたいだけなら、現在の画面に適切な管理方法があるか確認し、復元できない削除を唯一の整理方法にしないでください。削除後の影響が分からないグループは、バックアップが終わるまで残しておきましょう。

復元用の資料を種類ごとに準備する

確実に復元できるよう、サブスクリプションURL、手動で登録したサーバー情報、ルール設定をそれぞれバックアップします。サブスクリプションURLからリストを再取得できますが、リモートの内容が現在と同じであるとは限りません。単一の共有リンクからサーバー設定を再作成できても、アプリの設定全体が含まれるとは限りません。Configにはルールが保存されますが、接続に必要な認証情報がすべて保存されるわけではありません。使用中の項目を一覧にし、種類ごとに復元可能な資料があるか確認してください。エクスポートファイルが1つあるだけで、すべてが揃ったと判断しないでください。

現在の画面に共有、エクスポート、バックアップの機能がある場合は、まず対象範囲の説明を読み、必要な内容を保存してください。含まれるか分からない項目は、元の設定を残したまま、ローカルでエクスポート結果を確認するか復元を試します。手動登録した項目は、認証、TLS、通信方式、特殊な項目が揃っているか特に注意して確認してください。識別用の備考やテストのスクリーンショットは設定のバックアップになりません。アドレスとポートだけを記録して、認証情報を抜かさないようにしてください。

バックアップには認証情報を含まない説明を添え、対象の用途、エクスポート範囲、現在のルール設定、必要な手動変更を記載すると管理しやすくなります。ファイル名は内容を識別できるものにしつつ、パスワードやトークンを含めないでください。信頼できる保存先を使う場合も、デバイスの紛失、アクセス権、古いコピーの削除を考慮します。暗号化して保存すると内容を保護できますが、復元時に必要なアクセス手段も安全に保管してください。バックアップがあっても開けない状態にならないよう注意します。

機種変更や再インストール後は段階的に復元する

アプリはApp Storeから入手します。購入済みの項目とアカウントについては購入済みアプリの復元ガイドをご覧ください。システム要件とユニバーサル購入の対象かどうかは、App Storeの掲載内容をご確認ください。アプリを再入手できても、サブスクリプション、手動登録したサーバー、Configが自動的に復元されるわけではありません。新しいデバイスを開いたら、現在の内容を確認してから必要な資料を取り込みます。一部のデータがすでに復元されている状態で、グループ全体を重複して取り込まないようにしてください。

サブスクリプション、独立したサーバー、Config、接続確認の順に復元します。種類ごとに作業を終えるたび、項目と設定を確認してから次へ進んでください。サブスクリプションを再取得するとリストが変わっている場合があるため、選択中の項目を確認します。独立した項目では重要な設定を確認し、ルールを復元したら現在使用中のConfigとGlobal Routingを確認します。その後、システムの案内に従ってVPN構成を許可し、実際に接続して確認してください。リストに項目が表示されたことだけで移行完了としないでください。

新しいデバイスで接続を確認するまで、元のデバイスの資料とバックアップを残してください。新旧のデバイスで結果が異なる場合は、すぐにすべてのデータを上書きせず、まずネットワーク条件、選択中の項目、ルーティングのモードを比較してから設定を確認します。元に戻す必要がある場合は、事前に記録した対象範囲に基づいて復元してください。古いConfigで新しい変更を上書きしたり、古いサブスクリプションからリストを重複して作成したりしないよう注意します。移行中は一度に1種類の設定だけを変更し、各段階の理由と結果を確認できるようにしてください。

最後に、バックアップが現在の状態でも使えるか確認します。認証情報を変更した後は古いコピーが無効になっている場合があり、ルールの変更後は古いファイルが意図した用途を反映しないことがあります。更新後は不要になった機密情報のコピーを安全に削除してください。ローカルの項目やファイルを削除しても、すでに漏えいした認証情報が無効になるわけではありません。情報が漏れた場合は、元のサービスの認証情報管理手順に従って対応します。日常操作に戻る場合はクイックスタートガイドを、具体的なエラーの特定にはFAQの分類をご覧ください。