Shadowrocketのサーバー管理：既存サブスクリプションのインポート・更新・バックアップ

Subscribeでインポート：URLと取得内容を区別する

サブスクリプションとサーバー項目の関係

サブスクリプションURLは繰り返しアクセスするリソースの入口で、サーバー項目はクライアントが解析した具体的な接続先です。1つのサブスクリプションから複数の項目が取得されることがありますが、サブスクリプション名、項目名、現在選択中のサーバーは別々の設定です。管理時はまずサブスクリプションの所属先を確認し、その中の各項目についてプロトコルとパラメータを確認します。URLを保存できても、リモートの内容を正常に取得できたとは限りません。リストに名前が表示されても、実際の接続が確認済みとは限りません。

開始前に、元の情報から更新用の完全なサブスクリプションURLを確認してください。アカウントページや説明ページ、単一サーバーの共有リンクではありません。特にURLの?以降にあるクエリパラメータは、認証や取得内容の指定に使われる場合があるため残してください。コピー時に日本語の引用符、改行、チャットの前置き、末尾の句読点を含めないでください。また、見た目を整えるためにパラメータを削らないでください。サブスクリプションURLは機密情報として扱い、公開スクリーンショットには載せないでください。

Add ServerからSubscribeを登録する

HomeでAdd Serverを開き、Typeの選択画面でSubscribeを選び、現在のフォームに従ってURLと識別しやすいメモを入力します。表示言語によって項目の位置が異なる場合があるため、アプリ内に表示されるSubscribeと各項目の説明を確認してください。保存前にスキーム、ホスト名、パス、パラメータを一字ずつ確認します。保存後は、該当するサブスクリプショングループが表示されたか、サーバー項目が作成されたか、リクエストまたは解析エラーが表示されたかを確認します。3つの結果はそれぞれ記録してください。

初回はサブスクリプションを1つだけインポートすることをおすすめします。取得した内容を解析でき、項目の所属先も正しいことを確認してから次を追加すれば、問題が起きたときに入力箇所を特定しやすくなります。インポート後はHomeで使用するサーバーを選び、選択マークが該当項目に付いていることを確認してください。サブスクリプショングループを展開しただけでは、サーバーを選択したことにはなりません。その後、クイックスタートに沿って接続し、Connectivity Testを実行して、インポートした項目が現在の接続で実際に使われているか確認します。

リストが空の場合・リクエストに失敗した場合の確認手順

保存後にサーバーが表示されない場合は、アプリのエラーがアクセス失敗なのか、内容を解析できないのかを確認します。アクセスに失敗した場合は、現在のネットワークでリクエストできるか、URLが完全か、認証情報が有効かを確認してください。内容を解析できない場合は、リモートから返されたものがサーバー情報なのか、ログインが必要なページ、エラーの説明、空の応答ではないかを確認します。ブラウザにテキストが表示されても、ブラウザが内容を取得できたことを示すだけです。Subscribeで読み込める内容であることや、クライアントで正常にインポートできたことの証明にはなりません。

リストが空だからといって、同じ登録を何度も追加しないでください。重複してインポートすると、後の更新や削除の判断が難しくなるだけで、URLの誤りは直りません。サブスクリプションの登録は1つだけ残し、入力を確認してから一度更新してください。リモートの情報が変更されている場合は、利用中のサービスで案内されている最新のURLを使います。トラブル対処では、どの段階で失敗したかだけを記録し、URL全体を関係のない相手に共有しないでください。問題を説明するときは、エラーの種類、使用中のネットワーク、項目が作成されたかを伝えれば十分です。

以前は使えていたURLで失敗するようになった場合は、原因が分かるまで現在のサーバーリストを残してください。最後に更新が成功したときに表示されていた項目と、今回のエラーを記録し、リモートへの一時的なアクセス不能、返却内容の変更、ローカル入力の変更の3つに分けて確認します。管理の目的は一時的に名前をいくつか表示させることではなく、繰り返し更新できる情報源との関係を復旧することです。

Add Serverの手動入力項目：名前から推測せず、プロトコルごとに確認

Typeを選んでから接続情報を入力する

手動追加は、完全なサーバーパラメータをすでに持っていて、項目ごとに確認したい場合に適しています。HomeでAdd Serverを開いたら、まず実際に使用するプロトコルのTypeを選び、Address、Port、該当する認証項目を入力します。Typeによって必要なパラメータが変わるため、最初に別のプロトコルのフォームへすべて入力し、名前だけを変えて設定が切り替わったと考えてはいけません。メモは識別用であり、認証には使われません。名前にプロトコル名が含まれていても、実際にそのプロトコルが設定されている証明にはなりません。

Addressには通常、ホスト名またはアドレスを入力し、Portにはポート番号だけを入力します。現在の項目で完全なURLが明示的に求められていない限り、Web URL全体やパス、ポートをまとめてAddressに入れないでください。コピー後は、先頭と末尾の空白や、数字が入力システムによって全角に置き換わっていないか確認します。アドレス、ポート、認証情報、トランスポートのパラメータは、同じ既存サーバー情報から入力してください。似た複数の項目から寄せ集めると、接続先が異なる項目が混ざり、失敗する可能性があります。

認証項目は相互に置き換えられない

ShadowsocksではMethodとPasswordをサーバー側の設定に合わせる必要があります。VMessとVLESSのUUIDは任意のメモではなく、アカウントのログインパスワードでも代用できません。TrojanとHysteria2は、それぞれのフォームと手元の情報に基づいて認証値を確認してください。WireGuardではローカルの秘密鍵とピアの公開鍵の役割を理解し、入力欄を取り違えないようにします。この表は確認の目安であり、すべてのサーバーに使える共通パラメータではありません。必須項目は選択したTypeのフォームに従ってください。

パスワードや鍵は通常、大文字と小文字が区別されます。コピー時に自動修正されないよう注意してください。認証項目が空に見える場合は、接続結果を見ながら推測するのではなく、元の情報で本当に空欄が指定されているか確認します。共有リンクから取得したパラメータであれば、まず独立した項目としてインポートし、編集画面とテキスト情報を照合できます。元の解析結果を残しつつ、手入力でトランスポート設定を見落としていないか確認できます。ただし、そのリンクが同じサーバーの情報であることを確かめてください。

TLS、サーバー名、トランスポートパスを個別に確認する

TLSを有効にすると、接続先のアドレスと証明書検証に使うサーバー名が異なる場合があります。トランスポートのHostやPath、TLSのサーバー名にもそれぞれ用途があり、どれもドメインや文字列だからといって流用できるわけではありません。手元の情報に従って、トランスポートの種類、パスのスラッシュ、大文字・小文字、サーバー名を確認します。項目の不一致を隠すために証明書検証を無効にしないでください。証明書エラーが発生した場合は、端末の日付と時刻が正しいか、情報に記載されたドメインが現在も有効かも確認します。

保存後に編集画面をもう一度開き、入力漏れや誤った欄への入力がないか確認します。変更は一度に1項目だけ、根拠を確認してから行い、結果をテストしてください。プロトコル、ポート、認証情報、TLSを同時に変更しないでください。動作する完全なパラメータが分かっている場合は、比較用のテスト項目を別に作成できます。ただし、元の項目とテスト項目を明確に分け、未検証の項目を普段使うサーバーに設定しないようにしてください。

手動で追加した項目は通常、自分で管理する必要があり、Subscribeの更新でパラメータが修正されるとは限りません。サブスクリプションから作成された項目は、更新時に各項目が再生成される場合があるため、情報源の段階で確認するのが基本です。英語の画面用語が分からない場合は、画面用語の解説を参照してください。接続パラメータとGlobal Routingのポリシー設定を混同しないようにしましょう。

QRコード・クリップボードからのインポート：内容を確認してから保存

Scan QR Codeは入力方法を変える機能

QRコードはテキストを伝える手段であり、独立したサーバープロトコルではありません。単一サーバーの共有リンク、サブスクリプションURL、通常のWebページが含まれている場合があります。Scan QR Codeを使う前に、内容が自分の既存サーバー情報から取得したものであることを確認してください。読み取り後は、クライアントに表示された種類とインポート対象を確かめてから保存します。「スキャン成功」はサーバーが使えることを意味しません。画像内のテキストを読み取れたことを示すだけで、その後に形式の解析と接続確認が必要です。

アプリ内のスキャン画面からScan QR Codeを開き、システムの案内に従ってカメラへのアクセスを許可するか決めてください。その後、QRコード全体を枠内に収めます。カメラを許可しない場合は、手元にあるテキストを使ってインポートできます。操作を続けるために、関係のないシステム権限を変更する必要はありません。画像の反射、欠けた角、解像度不足、画面の拡大・縮小は読み取りに影響します。細かく切り抜いた画像を何度も試すのではなく、鮮明な元のQRコードを用意してください。

読み取り結果は3段階で確認する

1つ目は対象の種類です。Add Serverの編集情報が開いたのか、SubscribeのURL登録が開いたのかを確認します。2つ目は接続項目です。アドレス、ポート、プロトコル、認証情報がそろっているか確認します。3つ目は管理上の所属先です。新しい項目が想定したサブスクリプションに属するのか、手動で個別に保存された項目なのかを確認します。読み取り後に通常のWebページが開いた場合、QRコードにWebページへのリンクが含まれている可能性があります。そのURL全体をサーバーパラメータとして入力しないでください。

同じ端末に保存したQRコード画像を写真アプリから直接読み取れるかどうかは、現在のスキャン画面で実際に利用できる機能に従ってください。該当する項目がなければ、隠しジェスチャーがあると考える必要はありません。保存済みの元テキストを使うか、管理下にある別の端末に既存のQRコードを表示して読み取れます。認証情報を含む画像を、公開共有アルバムやグループチャット、画面録画に残さないようにしてください。特に、メモだけを隠してもコード全体が見えていれば情報は隠せていません。

クリップボードから取り込む前に不要な文字を除く

コピーする際は、チャット全体ではなく、完全な共有リンクまたはサブスクリプションURLだけを選択してください。ペーストの許可を求められたら、自分が開始した操作であることを確認してからアプリによる読み取りを許可します。アプリにインポートの案内が表示されたら、解析された件数と種類を確認してください。案内が表示されない場合は、画面上に実際に用意されているインポート方法を使います。表示されていない案内を、プロトコル非対応のサインと決めつけないでください。クリップボードを何度も上書きするより、1回コピーして1回確認するほうが問題を追跡しやすくなります。

リッチテキストには、箇条書き、引用符、目に見えない空白、手動の改行が含まれることがあります。先頭と末尾を確認する場合は、管理下にあるプレーンテキスト環境を使ってください。認証情報をオンライン変換ページに貼り付けて確認してはいけません。複数項目をまとめてインポートする場合は、各項目の区切りを確認し、2つのリンクが1行に連結されたり、1つのエンコード文字列が複数に分割されたりしていないか確認します。アプリの報告件数が想定と異なる場合は、不完全な結果をリストに残して接続を試すのではなく、元のテキストを確認してください。

QRコードとテキストでインポート結果が異なる場合は、両方が本当に同じ内容か照合してください。QRコードは古い情報から作られていて、クリップボードには新しいURLがコピーされている場合があります。また、テキストに余分なエスケープ文字が含まれている可能性もあります。元の情報を保管し、名前の一致だけで判断せず、対象の種類、アドレス、ポートを比較してください。インポートできたことを確認したら、クリップボードを通常のテキストに置き換え、不要になった機密スクリーンショットを削除して、誤共有のリスクを減らします。

共有リンクの形式：プロトコル、エンコード、項目の区切りを保つ

単一リンクとサブスクリプションURLの管理上の違い

単一サーバーの共有リンクには通常、接続に必要な情報がテキストとして含まれており、インポートすると特定のサーバー項目が1つまたは複数作成されます。一方、サブスクリプションURLはリモートの内容を指し、後から再取得して更新できます。どちらもクリップボードやQRコードで受け渡せますが、管理方法は異なります。単一リンクのパラメータは、リモートのサブスクリプションが変更されても自動修正されません。サブスクリプションの項目は更新時に追加、置換、削除される場合があります。まず情報の種類を見分けてから、元データを保存してください。

単一サーバーの共有テキストには、ss、vmess、vless、trojanなどのプロトコル接頭辞が付いている場合があります。実際に読み取れるか、どの拡張項目が含まれるかは、現在のShadowrocketでの解析結果に従ってください。接頭辞の確認は最初の手順にすぎず、パラメータ全体の確認に代わるものではありません。見慣れない形式を接頭辞の書き換えで無理にインポートしないでください。見た目が似たテキストでもエンコード方式が異なる場合があり、数文字を変えても別のプロトコルには変換されません。

エンコードされたテキストは手作業で編集しない

共有形式の中には、パラメータをBase64で保存するものや、URIに似た項目構造を使うものがあります。Base64はテキストのエンコード方式であり、認証情報を保護する仕組みではありません。エンコードされた内容を見られる人は、情報を元に戻せる可能性があります。形式によって文字セット、パディング、パラメータの位置も異なるため、リンクを短くするために末尾の文字を削ったり、長い文字列に含まれるプラス記号やスラッシュを不要な記号として削除したりしないでください。元のテキストを保ち、クライアントに解析させてください。

URI形式の内容では、?がクエリパラメータの開始、&が各パラメータの区切り、#以降がメモとして使われる場合があります。ただし、認証値にパーセントエンコードが必要な文字が含まれていることもあるため、見た目だけで分解・再構成しないでください。コピー時に文字が変化したのか、元からその値だったのかも区別する必要があります。繰り返しデコードすると予約文字が壊れることがあり、エンコードされていない区切り文字は認証値を複数の項目に分割してしまう場合があります。形式を判断できる明確な根拠がなければ、自分の元の共有テキストを入手し直してください。

解析後は名前ではなく項目を確認する

リンクのメモは通常、サーバーを識別するためのもので、接続動作を決めるものではありません。名前が同じ項目でも、ポート、UUID、トランスポートパス、TLSのサーバー名が異なる場合があります。名前が違っても、同じパラメータを指していることもあります。重複を調べる場合は、編集画面でプロトコル、アドレス、ポート、重要なオプションを比較してください。認証情報を含む完全なリンクを通常のメモとして保存すると、リスト表示や検索、スクリーンショットで機密情報が見える範囲を広げるおそれがあります。

共有機能を使って自分が管理する端末間で既存情報を移す場合も、エクスポート対象を確認してください。単一サーバーの共有では、通常、サブスクリプションの情報源を引き継げません。サブスクリプションの共有も、Config全体のバックアップにはなりません。移行前に、移行先で必要なのが単一サーバー、更新用のサブスクリプションURL、ルール設定ファイルのどれかを確認し、それぞれ個別にエクスポートして検証します。1つの項目をインポートできても、他の設定まで移行できた証明にはなりません。

ルール設定の構文もそのまま保つ必要があります。以下はShadowrocketのルール構成の例で、サーバーの認証情報は含みません。この断片だけでは接続できないため、実際に使用するときは現在の設定とポリシー参照を確認してください。ルールは上から順に照合され、FINALはそれ以前のルールに一致しなかった場合の処理として末尾に置きます。具体的なルールより前に移動しないでください。

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

サーバー情報とこの種のルール断片は分けて保管してください。ルールテキストをSubscribeに貼り付けたり、サブスクリプションURLをConfig全体として扱ったりすると、入力欄が文字列を受け付けても、解析対象は異なります。判断に迷ったら元の情報の用途を確認し、用語集でSubscribe、Config、関連するルールキーワードを区別してください。誤ったインポートを繰り返し、管理しにくい項目を増やさないようにしましょう。

サブスクリプションの更新方法：リクエスト成功と内容の変化を区別する

手動更新は一連の確認手順として行う

サブスクリプションの更新は、保存済みのURLに再度アクセスして取得内容を処理する操作です。既存サーバーの接続テストではありません。実行前に、どのサブスクリプションを更新するか確認し、現在選択中のサーバーとグループの状態を記録します。実行後は、アプリの通知、項目の変化、デフォルトの選択が想定どおりかを別々に確認してください。リクエストに成功しても項目が変わらない場合、リモートの内容がローカルと同じだった可能性があります。リストに変化があっても、新しい項目の接続確認が済んだとは限りません。どちらの場合も追加の確認が必要です。

サブスクリプションの登録に対して画面上の更新操作を実行したら、結果が出るまで待ってから次に進んでください。処理中に何度もタップしないでください。頻繁に更新しても誤ったURLは直らず、複数のリクエスト結果の順序が分かりにくくなることがあります。失敗した場合は、通知をもとにネットワークに接続できない、認証に問題がある、内容を解析できない、のどれかを確認してから次の手順を決めます。URLを変更する場合はサブスクリプションの登録自体を確認し、生成されたサーバー項目だけでアドレスを変更しないでください。

自動更新を即時反映の保証と考えない

現在のSettingsやサブスクリプション編集画面に自動更新のオプションがある場合は、実際の意味と設定可能な範囲を読んでから、必要に応じて有効にします。アプリがどのようなバックグラウンド状態でも、正確な時刻にリクエストを完了すると考えないでください。端末のネットワーク、システムのスケジュール管理、アプリの状態が実行条件に影響します。更新されたパラメータを使って接続する前に、前面で直近の更新結果を確認し、必要なら手動更新と接続確認を行ってください。

更新頻度は情報の変化に合わせて決め、短ければよいとは考えないでください。長期間安定しているサブスクリプションは、一度接続に失敗しただけで何度も更新する必要はありません。利用中のサービスでパラメータ変更が明示された場合は、更新後に変更された項目を確認します。自動更新とサーバーの自動選択も別の機能です。前者は情報を更新し、後者は実際の接続先に関わります。リストを更新しただけで、クライアントが最適な項目に切り替えたと決めつけないでください。

ローカル編集とリモートの内容の境界

サブスクリプションから作成された項目は、次回の更新時に項目が再設定される場合があります。メモ、ポート、その他のパラメータをローカルで変更した場合、その変更が上書きされる可能性を考慮してください。変更が保持されるかどうかは、現在の画面と実際の更新結果で確認します。カスタムパラメータを長期的に使う必要がある場合は、機能が許す範囲で独立した手動項目を作成し、管理方法を明確にしてください。サブスクリプションの項目を不変のローカル記録と考えたり、未確認の上書きルールに頼ったりしないでください。

更新後に項目が増減したり、同じ名前の項目が表示されたりした場合は、まずリモートの情報に実際の変更があるか確認してから、現在の選択を確認します。以前のサーバーが削除されたり、新しい名前が異なるパラメータに対応したりする場合があります。接続中の混乱を避けるため、重要な通信を行っていないときに更新し、完了後は選択マークを再確認してからテストしてください。以前の項目を使う場合は、リスト上の位置ではなく、パラメータと所属先を確認します。

更新に失敗した場合は、URLとクライアントの設定を変えずに、自分が管理できる別のネットワークで比較できます。ネットワークを変えると成功する場合は、まずリクエスト経路を確認します。どのネットワークでも失敗する場合は、URLと返却形式を確認してください。サブスクリプションの更新問題をサーバーの遅延値のせいだと決めつけたり、リストの削除、URL変更、複数のネットワーク設定切り替えを同時に行ったりしないでください。一度に条件を1つだけ変更すれば、結果を比較できます。

簡単な管理記録を残すほうが、記憶に頼るより確実です。対象、操作の理由、項目に変化があったか、確認結果だけを書き、認証情報の全文は保存しないでください。次に同じ通知が出たとき、サブスクリプションへのアクセス、内容の解析、サーバー接続のどの段階で問題が起きたか判断できます。正常なリストへのインポートや削除を繰り返す誤操作も防げます。

複数サブスクリプションの整理：所属先と選択の根拠を保つ

URLを公開せず、サブスクリプションに名前を付ける

複数のサブスクリプションを管理する際は、各項目がどの登録から更新されたか分かることが重要です。個人の端末での用途や管理範囲に基づく、短く安定した識別用のメモを付けてください。完全なサブスクリプションURL、アカウント識別子、鍵は名前に入れないでください。メモは項目を区別するために使い、パラメータの保存場所にしないでください。サーバー名には識別に必要な情報を残し、後から照合できなくなるほどすべてを同じ短い名前にしないようにします。

2つ目のサブスクリプションを追加する前に、1つ目のインポートと接続確認が完了していることを確認してください。その後は1つずつ追加し、新しいグループと項目の範囲を確認します。グループを折りたたむ機能がある場合、使用していないグループを閉じて表示をすっきりさせることはできますが、折りたたみは表示を変えるだけで、無効化、削除、現在の接続先の変更にはなりません。リストを見るときは展開状態と選択状態を分けて考え、実際の接続先はクライアントに表示される選択マークで確認してください。

重複項目はパラメータと管理元を比べる

名前が同じでも重複とは限らず、名前が異なっても別の項目とは限りません。判断する前にType、Address、Port、重要な認証・トランスポート項目を比較し、それぞれが別のサブスクリプションから取得されたものか確認します。複数のサブスクリプションが似たサーバーを返す場合、異なる情報源を残すことで各自の更新関係を維持できます。生成された項目を削除しても、次回更新時に再び表示されることがあります。整理する前に、表示上の重複を減らしたいのか、特定の情報源の管理をやめたいのかを明確にしてください。

リストの整理はルーティングの変更ではない

Global RoutingでConfigを使う場合、リクエストは現在の設定内のルールに従います。Proxyを使う場合は、現在のプロキシサーバーまたは関連するポリシーを確認します。Directでは、そのモードに従ってトラフィックが直接処理されます。サブスクリプションがリストにいくつあるかで、リクエストが特定のサーバーを経由するかどうかは決まりません。設定内で名前を指定するポリシーがある場合は、参照先が有効かどうかも確認してください。Homeでサーバーを選択しただけで、すべてのリクエストがそこを通ると判断しないでください。

メモを変更するときは、特にConfigからの参照に注意してください。ルールやポリシーが特定の名前を参照している場合、名前を変更した後に参照関係も確認する必要があります。表示を整えるために一括で名前を変更すると、かえって管理が複雑になることがあります。現在のConfigが特定の名前を参照しているか確認してから、変更範囲を決めてください。設定に不慣れな場合は、元のファイルを残して小さな範囲で検証するほうが、すべての項目を一度に改名するより復元しやすく、問題箇所も特定しやすくなります。

繰り返し実行できる管理手順を作る

日常の整理では、まず1つのサブスクリプションを更新して変更を確認し、次に使用予定の項目をテストし、最後に重複または無効な項目を整理するという順序を決めておくと便利です。1つのグループを処理してから次に進めば、複数のサブスクリプションを同時に更新して変更元が分からなくなるのを防げます。1つのサブスクリプションが一時的に失敗しても、正常な登録まで削除して作り直さないでください。確認済みの状態は残し、問題が発生した登録だけを調べます。

項目数が多い場合は、まず所属先で範囲を絞り、画面で実際に利用できる検索や並べ替えを使って探します。検索で見つからない場合、名前の変更、グループの折りたたみ、フィルターの影響が考えられます。記録が削除されたとは限りません。テスト対象を切り替える前に、現在利用できる項目を記録し、テスト後に想定した項目を選び直してください。複数サブスクリプションの管理で大切なのは、情報源、パラメータ、ルーティング、現在の選択を明確に保つことです。リストを短くしたり、名前を統一したりすることが目的ではありません。

画面用語を確認する場合は用語集をご覧ください。接続を最初から設定する場合はクイックスタートに戻ってください。このページで紹介する整理方法は管理上の混乱を減らすためのもので、利用中のサービスの権限、パラメータの有効期間、利用可能範囲を変更するものではありません。

遅延テストと並べ替え：応答、ハンドシェイク、リクエストを分けて判断する

1つのテスト値ですべての利用結果は分からない

テスト結果は、まずどの方法で確認したかによって変わります。ポートへの接続確認、プロトコルを使うテスト、実際のWebリクエストでは、確認できる範囲が異なります。ある方法で応答があっても、該当する経路で通信できることしか示さない場合があります。認証、TLS、ルール、接続先サービスまでの経路全体を検証できるとは限りません。数値を比べる前に、現在のテスト設定と説明を確認し、異なる確認範囲の値を並べていないか確かめてください。

一括テストは確認対象を絞るための目安であり、「1番上の項目が常に最適」と判断するものではありません。現在のネットワーク、テスト先、端末の負荷、実行時刻は結果に影響します。同じネットワーク条件で一連のテストを行い、使う予定の少数の項目は実際に接続して確認してください。ネットワークを切り替えた直後に表示される以前の結果は、前の条件での結果にすぎません。再テストせずに選択の根拠として使わないでください。

Connectivity Testは現在の接続に合わせて確認する

Homeで使用するサーバーを選び、選択マークを確認してから接続スイッチをオンにします。システムがVPN構成の追加を求めた場合は、案内を読み、自分の操作意図に沿って許可してください。その後Connectivity Testを実行し、Global Routingも確認します。Directを使用中の場合、テストの成功はプロキシサーバーの認証が正しいことの証明にはなりません。Configを使う場合は、テスト先に適用されるルールと、そのルールが最終的に使用するポリシーも確認します。

実際の確認には、自分がアクセスする必要のある接続先を含めてください。Connectivity Testに成功しても特定のアプリが使えない場合は、そのアプリのリクエストに別のルールが適用されていないか、ドメイン名を正常に解決できるか、接続先サービスに個別の問題がないかを確認します。システムにVPNの状態が表示されただけで確認を終えないでください。システムの状態は接続設定が動作していることを示しますが、すべての接続先へのリクエストが成功したことを意味しません。初回接続の手順は初回接続の確認ガイドをご覧ください。

タイムアウトは段階ごとに原因を確認する

タイムアウトが発生したら、まず現在のネットワークを確認し、次にサーバーのアドレスとポート、認証、トランスポート、TLSを確認します。ドメイン関連のエラーがある場合は、名前解決とサーバー名も確認してください。ポートに接続できない場合と認証が拒否された場合は、問題の段階が異なります。実際の通知に応じて分けて対処してください。エラー情報が不十分な場合は、ほかのパラメータを維持したまま、自分が管理できる別のネットワークで比較できます。根拠なく複数の項目を続けて変更すると、テスト結果を特定の原因に結び付けられません。

端末のシステム日時は、証明書や一部の認証手順にも影響します。日付、タイムゾーン、自動設定が実際の状況に合っているか確認し、エラーを回避するために検証を長期間無効にしないでください。同じネットワークでほかの既知の項目が正常なのに1つだけ失敗する場合は、その項目のパラメータとリモートの状態に絞って調べます。異なる複数の項目が同時に失敗する場合は、共通する条件から確認します。詳しい手順はタイムアウト・接続失敗のトラブル対処をご覧ください。

並べ替えで表示順は変わるが、選択の代わりにはならない

遅延順に並べ替えると確認しやすくなりますが、それだけで現在の接続先が自動的に切り替わるわけではありません。並べ替え後は使用する項目を明示的に選び、選択マークを確認してから再度テストしてください。空欄、未テスト、失敗の結果を同じ数値として比較しないでください。各状態が画面でどのように表示されるか確認します。複数サブスクリプションを使用している場合は、並べ替えが現在のグループだけに適用されるのか、より広いリストに適用されるのかも確認してください。項目が消えたと誤解するのを防げます。

テスト後は、必要な範囲の記録だけを残してください。テスト方法、使用したネットワーク、実際のリクエストに成功したかが分かれば十分です。トラブル情報を共有する際は、サーバーの認証情報、サブスクリプションURL、個人データを隠してください。テスト記録の目的は、条件と現象を伝えることです。再現できない数値を並べることではありません。条件が同じであれば、ネットワーク、パラメータ、ルールの変化を前後で比較できます。

削除・バックアップ：対象を確認してから削除し、復元を検証する

削除前に対象を見分ける

サーバー項目、サブスクリプション登録、Configファイルの削除では、影響が異なります。操作前に、現在の画面、選択中の対象、確認メッセージに記載された範囲を確認してください。リストから単一サーバーを削除しても、リモートのサブスクリプション内容は変わりません。サブスクリプション登録を削除しても、外部サービス上の権限が処理されるわけではありません。ボタンの近くにある名前だけで影響を判断せず、画面の位置と確認メッセージから、今回の削除が項目、グループ、設定ファイルのどれを対象にしているか確認してください。

現在選択中のサーバーを削除する場合は、先に代わりの接続先を決めて動作を確認してから、古い項目を削除してください。設定ポリシーが削除予定の名前を参照している場合は、その参照先も確認します。削除後はHomeに戻り、選択状態、Global Routing、現在のConfigを確認してください。クライアントが自分の想定どおりに次の項目を自動選択するとは限りません。システムに接続状態が表示されていても、実際のリクエストを改めて検証してください。

サブスクリプションの項目は更新後に再表示される場合がある

サブスクリプションから作成されたサーバーをローカルで削除すると、次回の更新でリモートの内容に基づいて再作成されることがあります。削除に失敗したとは限らず、ローカルのリストが情報源の内容と再び同期された可能性があります。サブスクリプション全体の管理をやめる場合は、該当する登録を処理し、確認画面で関連項目への影響範囲を確認してください。サーバーを一時的に使わないだけなら、何度も削除と更新を繰り返すより、選択状態とグループ表示を明確に保つほうが管理しやすくなります。

一括削除の前にリスト上の位置を基準にしないでください。並べ替え、グループの展開、更新によって位置が変わります。名前と情報源を1つずつ確認し、必要なら対象を1つのグループに絞って操作します。ルールが項目を参照しているか分からない場合は、削除して接続失敗から関係を推測するのではなく、項目を残して参照先を調べてください。削除は管理操作であり、通常のトラブル対処で最初に行う手順ではありません。以前の状態を比較できるように残すと、原因を見つけやすくなります。

バックアップでは種類の異なるデータを保管する

完全な復元に必要な情報には、元のサブスクリプションURL、個別に手動追加したサーバーパラメータ、Configファイル、再設定が必要なアプリのオプションが含まれる場合があります。サーバーの共有リンクを1つ保存しても、サブスクリプション全体の更新先には通常代わりません。Configをバックアップしても、サーバーの認証情報が含まれているとは限りません。アプリで利用できるエクスポートやバックアップ機能を使う場合は、項目の説明を読み、対象範囲を確認してください。ファイル名や容量だけで内容が完全だと判断しないでください。

バックアップファイルには、パスワード、UUID、鍵、サブスクリプションの認証情報が含まれる場合があります。アクセス保護が設定され、自分で管理できる場所に保管してください。一般的な文書のように公開共有したり、識別しやすくするために認証情報をファイル名に入れたりしないでください。端末の修理、譲渡、交換の前に、ローカルファイル、アルバム内のQRコード、クリップボードに関連情報が残っていないか確認します。バックアップの保護とは、コピーを残すだけでなく、どのアカウントや端末がアクセスできるかを制限することです。

復元の確認とアプリの再インストールは分けて行う

端末の交換やアプリの再インストールの前に、復元可能な情報をすでに持っていることを確認してから、元の端末を操作してください。アプリはApp Storeから再入手します。購入済みアプリの復元と購入対象については購入済みアプリの復元ガイドをご覧ください。システム要件はApp Storeのページに記載された内容をご確認ください。アプリの再インストールとサーバーデータの復元は別の作業です。購入履歴ですべてのローカル設定も戻ると考えたり、システムバックアップがあるだけで復元に成功したと判断したりしないでください。

移行先の端末で復元した後は、データの種類ごとに確認してください。サブスクリプションURLが存在し、更新できるか。手動項目のパラメータがそろっているか。Configが選択されているか。関連するポリシー名が有効か。最後に、想定するサーバーを選び、Global Routingを確認し、Connectivity Testを実行して実際の接続先へのリクエストを検証します。この一連の手順が完了して初めて、現在の用途に使えるバックアップだと判断できます。バックアップファイルを開けることや、いくつかの名前が見えることは、復元途中の結果にすぎません。

バックアップや共有情報が漏えいした疑いがある場合は、自分が利用中のサービスの管理範囲で該当する認証情報に対処し、クライアント内の登録も更新してください。ローカルのコピーを削除するだけでは、すでに公開された認証情報は無効になりません。復元の検証が済んだら、必要に応じて古いコピーを整理し、対象範囲と用途を確認したバックアップを1つ残してください。日常の管理では「根拠を保存してから状態を変更し、最後に結果を確認する」ことで、問題発生後に情報を組み直すより確実に対応できます。