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

サブスクリプションに保存されるもの

Subscribeに保存されるのは、再度アクセスして情報を取得できる登録先です。クライアントがそのURLにアクセスすると、サーバーの一覧を取得し、読み取れる内容を端末に表示します。一覧内の各サーバー情報には、アドレス、ポート、プロトコル、認証情報が含まれます。サブスクリプションURLは、これらの情報をひとまとめに取得するためのものです。両者は別のものです。サーバーに接続できてもサブスクリプションURLが有効とは限らず、サブスクリプションを更新できても、一覧内のすべてのサーバーに接続できるとは限りません。

取り込む前に、手元の情報が自分のサブスクリプションURLであることを確認してください。アカウント管理ページ、単体の共有リンク、ルールファイルのURLとは異なります。ブラウザーでページが表示されても、サブスクリプションとして使えるとは限りません。クライアントが必要とするのは解析可能な一覧であり、ログイン画面、エラーメッセージ、通常のWebページではありません。認証情報を含むURLを公開の場に貼り付けず、自分の端末で確認してください。

手順に沿ってサブスクリプションを登録する

1. Homeの追加メニューからSubscribeを探します。画面が先にAdd Serverを表示する場合は、種類の選択肢にSubscribeがあるか確認してください。メニューの場所は端末に表示される画面をご確認ください。
2. URL欄にサブスクリプションURLを省略せずに貼り付け、先頭、末尾、クエリパラメーターが残っていることを確認します。「日常用」など、用途を区別できる名前を付けましょう。日付だけを名前にするのは避けてください。
3. 保存して初回の取得を行います。一覧が表示されたら、所属先とサーバー名を確認してください。同じURLを続けて何度も追加しないようにしましょう。
4. 自分に利用権限のあるサーバーを1つ選び、接続を確認します。初回接続とシステム権限の設定については、クイックスタートガイドもご覧ください。

例は構造を見分けるためのもので、実際の接続には使用できません。以下のURLに含まれるドメイン、パス、パラメーターはすべて説明用の架空の値です。実際のURLにはクエリパラメーターがない場合や、異なるパスが使われる場合があります。コピーするときは元の内容を保ち、例を参考に自分のURLへ項目を追加しないでください。

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

保存できても、取得できたとは限りません

登録が保存されたことは、入力内容が端末に受け付けられたことを示すだけです。初回のリクエストは、ネットワーク、URLの無効化、認証エラー、未対応の形式などが原因で失敗する場合があります。サブスクリプション名だけが表示され、サーバーがない場合は、まずエラー内容を確認し、「リクエストが完了しなかった」のか「リクエストは完了したが解析できなかった」のかを切り分けます。前者では端末のネット接続とURLへの到達性を確認し、後者では返された内容がWebページ、空の一覧、または現在の登録先に対応しない設定形式ではないかを確認します。

認証エラーが表示された場合は、登録済みサブスクリプションの管理ページでアクセス権とURL全体を確認してください。パラメーターを手当たり次第に削除・変更しないでください。証明書エラーの場合は、端末の日時とURLの綴りを確認します。証明書検証を無効にすることを、標準的な対処方法にしないでください。ネットワークへの接続にWeb認証が必要な場合は、先に通常の接続手順を完了してからSubscribeを再試行してください。公衆ネットワークのログイン画面をサブスクリプションの応答と取り違えないようにしましょう。

取り込み後に確認する3項目

1つ目は、サーバーが想定したサブスクリプションに属しているか確認し、手動で登録した情報と混同しないこと。2つ目は、サーバー情報を開いてプロトコルとアドレスが完全か確認することです。認証情報を他人に見せないでください。3つ目は、現在のConfigが取り込み操作によって意図せず置き換わっていないか確認することです。サブスクリプション一覧で選べるサーバーがわかり、Configでアクセス先の処理方法が決まります。両方を別々に確認してください。一覧に表示されたからといって、ルール設定が正しいとは限りません。

同じURLを複数の端末に登録しても、端末ごとの名前、選択中のサーバー、手動変更が自動で一致するわけではありません。各端末を独立した管理用コピーとして扱い、初回取得と接続結果をそれぞれ確認してください。サーバー情報が1件だけの場合は、単体の情報をサブスクリプションに加工する必要はありません。次の章へ進んでください。

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

Add Serverでは、独立したサーバー情報を登録できます。開始前に、すでに持っているサーバー情報を一式用意し、まずTypeを選択してから対応する項目を入力してください。種類によって認証項目や転送オプションは異なります。アドレスを先に入力してからTypeをむやみに切り替えると、一部の項目がリセットされたり、新しい種類に合わない値が残ったりする場合があります。情報が不足している場合は、手元のサーバー情報を確認してください。他の登録内容の見た目から推測しないでください。

アドレス欄には通常、ホスト名またはIPアドレスを入力します。Webページの完全なURLではありません。ポートは独立した数値欄に入力し、パス、クエリパラメーター、メモを含めないでください。資料にドメイン名が記載されている場合は、名前解決後のIPアドレスに勝手に置き換えず、ドメイン名を使うのが一般的です。TLSの認証やサーバーのルーティングがドメイン名に依存する場合があります。IPv6を使う場合は、画面の独立したアドレス欄と共有リンク内の角括弧表記を区別してください。

認証、TLS、転送の役割

Shadowsocksでは、サーバーと一致する暗号化方式とパスワードが必要です。似た名前の方式を選んでも同じものとは限りません。VMessとVLESSではUUIDがよく使われますが、両者を互換のある種類として扱えるわけではありません。Trojanでは通常、パスワードとTLSの設定が関係します。HTTPやSOCKS5でユーザー名とパスワードが必要かどうかは、使用するサーバーの設定によります。すべての認証情報をPassword欄にまとめず、それぞれの項目に正確に入力してください。

TLSは接続の暗号化と相手の認証を担い、SNIはハンドシェイク時にサーバー名を伝えます。接続アドレス、SNI、転送層のHostは、同じ場合も異なる場合もあります。サーバーの実際の指定に従ってください。Pathは特定の転送方式で使うパスであり、サブスクリプションURLのパスとは別です。ハンドシェイクに失敗したときは、ポートだけを何度も変えるのではなく、これらの設定が一致しているか確認してください。証明書検証の設定は、実際の証明書要件に合わせてください。

WireGuardやHysteria2などには、それぞれ専用のパラメーターがあります。一般的なユーザー名・パスワードの考え方を当てはめないでください。現在選択している種類で必要な項目だけを入力し、資料に記載のない詳細オプションは、まず初期値のままにします。資料に記載された項目が画面に見当たらない場合は、Typeと入力画面が正しいか確認してから、用語集で項目の意味を調べてください。似た名前でも役割の異なる欄へ値を移さないでください。

変更を最小限にして原因を特定する

保存前に空白や改行が混ざっていないか確認します。パスワードは大文字と小文字が区別される場合があり、コピー時に見えない文字が含まれることもあります。UUIDのハイフンと文字の順序は変更しないでください。メモは自分が見分けやすい名前に変更できますが、認証情報を手作業で「整える」のは避けましょう。保存後はそのサーバーを選択してテストし、自分にアクセス権のある正常なHTTPSページを開いて、接続段階と実際のリクエスト結果をそれぞれ確認します。

トラブル対処では、一度に変更する項目を1種類に絞ります。たとえば、まずアドレスとポートを修正して再テストし、次に認証情報、最後にTLSと転送を確認します。複数の項目を同時に変更して正常になっても、本当の原因がわからず、次回の更新で再び問題になるおそれがあります。元の登録がまだ使える場合は、「確認中」などのメモを付けて別の登録を作成し、テスト後にどちらを残すか決めましょう。使用中の設定を直接上書きせずに済みます。

手動入力で設定できるのは、単体サーバーの情報です。ルールによる通信の振り分けは自動では設定されません。登録が使えるようになったら、Global Routingと現在のConfigも確認してください。一部のWebサイトだけで問題が起きる場合は、ルールとDNSの確認に進みます。有効だと確認できた認証情報を変更し続けないでください。

QRコードはデータを運ぶ手段

QRコードには、単体の共有リンクやサブスクリプションURLのほか、通常のWebページURLが含まれることもあります。Scan QR Codeで読み取れたからといって、サーバー情報が含まれているとは限りません。スキャンする前に、QRコードが自分のサーバーやサブスクリプションの管理元から取得したものか確認してください。内容が不明なまま保存しないでください。読み取り結果がWeb URLの場合は、スキャンできたという理由だけで正しい登録先だと判断せず、サブスクリプションとして使えるか確認します。

別の画面にQRコードを表示するときは、全体が鮮明に見えるようにし、周囲に余白を確保してください。画面の反射や四隅の欠けを避けます。カメラを近づけすぎると四辺が同時に映らず、遠すぎると小さな模様が読み取れないことがあります。距離と明るさを調整してから再度読み取ってください。QRコードには通常の共有リンクと同等の認証情報が含まれる場合があります。読み取りを頼むために公開の場へ投稿しないでください。

カメラの権限と画像からの読み取り

Scan QR Codeを使う際にシステムからカメラの使用許可を求められた場合は、許可するとリアルタイムでスキャンできます。以前に許可しなかった端末では、システム設定からShadowrocketのカメラ権限を変更してください。現在のスキャン画面に画像から読み取る機能がある場合は、自分で保存した元画像を選択できます。その機能が画面にない場合は、別のプラットフォームのスクリーンショットを参考に存在しないボタンを探さず、元のテキストから取り込んでください。

スキャン後、保存する前に認識された種類、名前、アドレスを確認します。期待したサブスクリプション全体ではなくサーバーが1件だけ表示された場合は、QRコードに単体のリンクが含まれていた可能性があります。反対に、サブスクリプションのQRコードでも、保存して初回取得を完了するまで全サーバーが表示されないことがあります。何度も読み込んで重複を作るのではなく、対象の種類を確認してください。

クリップボードから取り込む手順

1. 自分の資料から元のテキスト全体をコピーします。「リンクをコピー」など、元の内容を取得できる操作を使い、説明文、箇条書き、引用符まで一緒にコピーしないようにしてください。
2. Shadowrocketに戻り、画面に表示されるクリップボードからの取り込み操作を使います。貼り付けを許可するかシステムに尋ねられた場合は、取り込みを行うときに許可してください。
3. 認識結果を確認します。単体の共有リンクならサーバー情報、サブスクリプションURLならサブスクリプションとして認識されるはずです。認識できない場合は元のテキストを残し、何度も保存を試さないでください。
4. 保存後、登録先を確認してから接続テストまたはサブスクリプションの取得を行います。完了したら、機密情報を含まない通常のテキストをコピーしてクリップボードの内容を置き換えてもよいでしょう。

クリップボードが空、貼り付けが許可されていない、コピー内容にリッチテキストの書式が含まれている、といった理由で取り込みに失敗することがあります。端末内のプライベートなテキスト編集環境で、プロトコルの先頭と末尾がそろっているか確認してください。余分な説明文、全角記号、途中で分断された改行がないかも確認します。実際のパスワードをWeb検索欄や公開オンライン解析ページに貼り付けないでください。

複数の項目や重複を処理する

複数の共有リンクは通常、1行に1件ずつ記載します。一括取り込みが可能かどうかは、現在の画面で認識された結果を確認してください。まず1件で手順を確認してから残りを処理すると、問題の範囲を絞れます。テキスト全体が異常な名前として認識されたり、1件しか表示されなかったりした場合は、保存できたことを一括取り込み完了の証拠にしないでください。元のテキストに戻り、区切り方を確認して各項目を照合します。

同じサーバーをQRコードとクリップボードからそれぞれ取り込むと、通常は2つの端末内記録が作られ、自動で統合されるとは限りません。名前が同じでも設定が同じとは限りません。一方だけでポートや転送項目が更新されていることもあります。削除する前にType、アドレス、ポート、登録元を比較し、現在使えることを確認した一方を残してください。認証情報は自分の端末で確認し、比較のために2件分の情報をチャットへ送らないでください。

認識できたのに接続に失敗する場合は、第2章で項目を確認します。サブスクリプションを保存できてもサーバーが表示されない場合は、第1章で初回取得を確認してください。「認識、保存、取得、接続」を4つの段階に分けると、取り込み方法を何度も変えるより原因を特定しやすくなります。権限に関する詳しい情報は、FAQのインストールと初回起動の項目をご覧ください。

単体の共有リンクは自動更新されません

単体の共有リンクには通常、1台分のサーバー情報が記載されています。プロトコル、認証情報、アドレス、ポート、必要に応じて転送パラメーターなどが含まれます。取り込み後に作成されるのは、その時点の設定のコピーです。サーバー側で後からパスワードやポートが変更されても、共有リンクから追加したという理由で自動同期されることはありません。サブスクリプションURLは通常、再取得可能な一覧を参照します。更新対象はその一覧と所属するサーバー情報であり、単体の共有リンクとは更新の仕組みが異なります。

よくあるプレフィックスにはss://、vmess://、vless://、trojan://があります。プレフィックスによって、後続の内容をどの形式として解析するかが決まります。任意に付け替えられるラベルではありません。別のプロトコルに書き換えても変換にはならず、認証方法、データ構造、転送の意味がまったく異なる場合があります。未対応の形式が表示された場合は、元のエクスポート形式を確認してください。

エンコード、クエリパラメーター、メモ

形式によっては、認証情報や全体の構造がエンコードされてリンクに含まれます。エンコードは表示形式を変えるだけで、暗号化による保護ではありません。公開してよい情報になるわけでもありません。一見判読しにくい文字列から、パスワード、UUID、サーバーアドレスを復元できる場合があります。リンクを「整える」ために、等号、ハイフン、アンダースコアを手作業で削除しないでください。エンコードの一部である可能性があります。

クエリパラメーターは通常、疑問符の後に続き、アンパサンドで区切られます。転送方式、TLS、Host、Pathなどが含まれる場合があります。リンク末尾のシャープ記号以降は、メモとして使われることがあります。メモの日本語、空白、特殊文字はパーセントエンコードされている場合があります。解析はクライアントに任せ、デコード済みのテキストを再度エンコードしないでください。メモを変更しても接続に影響しないことは多いものの、シャープ記号より前のパラメーターを誤って削除すると接続設定が変わる場合があります。

Webページやメールからコピーすると、アンパサンドがHTMLエンティティに変換されたり、半角文字が組版用の文字に置き換わったりすることがあります。リンクがほぼ正しく見えても、解析結果から項目が抜ける場合があります。文字を推測して直すのではなく、元のテキストを取得し直すのが確実です。長いリンクが表示上で折り返されていても、元の文字列に改行が含まれるとは限りません。実際の文字列を端末上で確認してください。

エンコード部分を手で直さず、解析結果を確認する

名前が表示されたかだけでなく、取り込み後のType、アドレス、ポート、認証、転送の各項目を確認してください。任意パラメーターの扱いは、形式や実装によって完全には一致しないことがあります。プレフィックスを認識できても、現在の取り込み画面では一部の項目が反映されない場合があります。資料に記載された項目が解析結果にない場合は、第2章を参考に別のサーバー情報として補完し、元の資料も戻せるよう保管してください。

以下は構造を読みやすくするための例です。ドメイン名とパスワードは架空の値で、接続には使えません。認証情報、ホスト、ポート、クエリパラメーター、メモのおおよその位置を示しています。すべてのプロトコルが同じ構造を使うわけではなく、詳細項目をすべてここに記述できるという意味でもありません。

trojan://[email protected]:443?security=tls&sni=example.com#Manual-Example

HTTPSのURLからサーバー一覧ではなく完全な設定ファイルが返される場合は、その内容に合った設定の取り込み画面を使ってください。Subscribeに無理に入力して自動対応を期待しないでください。完全な設定ファイルにはルール、DNS、サーバー情報が含まれ、単体の共有リンクより影響範囲が広い場合があります。取り込む前に現在の設定をバックアップして内容を確認し、上書きしてから元のファイルを探すことのないようにしてください。

項目の構成を詳しく知りたい場合は、共有リンクの形式とサブスクリプションURLの違いをご覧ください。どの形式でも、元のリンクは機密情報として扱ってください。外部にトラブルを相談する際は、プロトコルとエラーが発生した段階だけを説明し、認証情報、URL全体のパラメーター、それらを復元できるQRコードは隠してください。

更新によって変わる内容

サブスクリプションを更新すると、リモートの内容を再取得し、応答に応じて端末内のサーバー情報が更新されます。名前、アドレス、ポート、認証情報、一覧内の項目が変わる可能性があるため、単なる「表示の更新」ではありません。更新前に使用中のサーバー名と用途を記録しておくと役立ちます。端末内で変更した情報が必要な場合は、先にバックアップしてください。リモートの一覧から項目が削除されると、更新時にその項目も消えることがあります。古い情報がまだ見えることを、今後も残る保証と考えないでください。

すでに確立している接続と、次に新しく確立する接続も分けて考えてください。一覧の更新が完了しても、既存の接続がすぐに新しい設定へ切り替わるとは限りません。必要に応じて、保存後に再接続し、実際のアクセスを確認します。重要なアップロード、会議、リモート作業の最中に更新や切り替えを繰り返すと、接続の再確立によって作業に影響する場合があります。一時的な中断を許容できる時間に行ってください。

手動更新と自動更新の使い分け

変更を確認しながら項目ごとに判断したい場合は、手動更新が適しています。まずバックアップを取り、1回取得して一覧の差分を確認し、現在の用途でテストします。画面に自動更新や間隔の設定がある場合は、利用頻度に合わせて有効にできます。ただし、短い間隔にしても安定性が保証されるわけではありません。頻繁に更新するとリクエストが増え、リモート側の頻度制限に達する場合があります。バックグラウンドでの更新も、システムの実行スケジュールやネットワーク状況に左右されます。

自動更新を有効にしていても、ときどき結果を手動で確認してください。端末が長期間オフライン、システムによるバックグラウンド動作の制限、サブスクリプションへのアクセス権の変更などで、更新が古い状態のままになることがあります。自動更新のスイッチだけで判断せず、リクエストが正常に完了したか、一覧の内容が実際に変わったかを確認してください。プラットフォームごとにスケジュールの仕組みは異なるため、複数の端末が同じタイミングで同一の一覧を取得するとは限りません。

エラーが発生した段階に応じて対処する

リクエストがタイムアウトした場合は、端末のネットワーク、ドメイン名の解決、接続先への到達性を確認します。認証エラーなら、自分のアクセス権と元のURLを確認してください。解析エラーの場合は、応答がWebページ、案内文、別形式のデータに変わっていないか確認します。一覧の更新が成功してサーバーへの接続だけ失敗する場合は、サブスクリプションURLへのリクエストを繰り返すのではなく、選択中のサーバーとプロトコルの設定を確認してください。エラーが発生した段階によって、次に行うことは異なります。

現在のネットワークから更新URLにアクセスできない場合は、自分が利用権限を持つ別のネットワークでも試し、端末側とリモート側のどちらに原因があるかを切り分けます。接続中のサーバーがある場合は、今回のリクエストがどのネットワーク経路を通ったかも確認してください。ルーティング、DNS、サブスクリプションURLを同時に変更しないでください。何度も失敗したら再試行を一旦止め、エラー文と発生条件を記録してから必要な項目を確認します。

サブスクリプションの更新とConfigの更新は別

サーバーのサブスクリプションとルール設定には、それぞれ独立した更新画面がある場合があります。サーバーに接続できるのに一部の接続先にアクセスできない場合は、問題をすべてサーバーのせいにせず、Global RoutingとConfigを確認してください。以下はルールの順序を理解するための例です。指定ドメインに一致するルール、指定地域のIPに一致するルールの順に確認し、最後にその他の通信を処理します。完全な設定ではないため、既存ファイルの置き換えに使わないでください。

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

ルールは上から順に照合され、最初に一致したルールで処理が決まります。FINALは、前のルールに一致しなかった場合に使います。例のPROXYは該当するプロキシ処理を表します。実際に使う前に、Config内のポリシーとサーバー選択の関係を確認してください。DNSの解決結果、ルールの順序、現在のモードによって最終的な通信経路は変わります。一覧にサーバーがあるからといって、すべてのリクエストがそのサーバーを経由するとは限りません。

1回の更新でサーバーと設定の両方が変わった場合は、2段階に分けて確認します。まずサーバーへの接続を確かめ、次にルールの動作を確認してください。自分で変更した項目は記録しても、認証情報をトラブル対処のメモに書かないでください。スイッチをオンにするとネットに接続できない場合は、サーバー、Global Routing、DNS、ルールを順に確認する手順を参照し、一度に変更する項目は1つにします。

見分けやすい名前の付け方

複数のサブスクリプションを管理する場合は、まず「サブスクリプション名」と「サーバー名」を区別します。前者は更新先の登録元を把握するため、後者は接続先を選ぶためのものです。サブスクリプション名には「日常用」「テスト環境」など、自分で用途や環境を判断できる名前を付けます。サーバーのメモには用途や登録元を補足できます。「新規」「予備」のように背景がわからない名前だけを使うと、時間が経ったときに残す項目を判断しにくくなります。

名前にパスワード、完全なサブスクリプショントークン、その他の認証情報を含めないでください。自分の端末にしか表示されない一覧でも、スクリーンショット、画面共有、バックアップのファイル名から名前が漏れることがあります。リモート側が自動生成したサーバー名は、次回更新で元に戻る可能性があります。ローカルで変更した名前を維持したい場合は、画面上でどのように扱われるか確認してください。一度保存できたからといって、今後も変わらないとは限りません。

登録元を分けてから重複を整理する

同じ名前のサーバーが別のサブスクリプションに属していたり、プロトコル、ポート、転送設定が異なっていたりすることがあります。アドレスが同じでも完全に重複しているとは限りません。整理する前に、少なくとも所属先、Type、アドレス、ポートを確認し、認証情報と転送設定が一致するか端末上で照合します。名前だけを見て一覧の半分を削除しないでください。すぐに判断できない項目にはメモを付け、使用を止めて、確認が済んでから整理しても構いません。

同じURLをサブスクリプションとして2回登録すると、更新時期の違いから内容が一致しなくなる場合があります。残す方を選び、1回更新してから、使用中のサーバーが適切か確認してください。必要な情報がそろっていることを確かめてから、もう一方を削除するか判断します。削除前に現在のサーバーとConfigから参照されていないかも確認し、使っている登録を単なる重複として扱わないようにしてください。

サーバー、ポリシー、モードを分けて管理する

一覧を整理しても、すべての通信の処理方法が自動で変わるわけではありません。Global RoutingのConfig、Proxy、Directは、それぞれ設定に従う、プロキシを使う、直接接続するという基本的な処理方法です。画面にSceneがある場合は、実際の用途に合わせて設定を確認してください。サーバーの選択とモードの選択は別の操作です。サーバーを選んでいても、モードがDirectなら、その接続がプロキシ経由だとは判断できません。

Configがサーバーやポリシーを名前で参照している場合、名前の変更や削除によって参照関係に影響が出ることがあります。整理前にConfigにそのような依存関係がないか確認し、整理後にポリシーの選択とルールの一致を確認してください。名前を変更して一覧が見やすくなっただけで完了とせず、日常の用途に合ったアクセスを少なくとも1回実行し、想定した方法で通信されることを確かめます。

整理は元に戻せる小さな単位で進める

一度に扱うサブスクリプションは1つにします。現状をバックアップし、重複を確認して名前を整理し、更新とテストを済ませてから次のグループへ進みます。異常が起きても、直近に行った変更と結び付けやすくなります。「すべて更新、すべて名前変更、古い項目を削除、Configを置き換え」を一度に行うと、問題が複雑に絡み合います。バックアップがあっても、どの部分を戻すべきか判断しにくくなります。

複数の端末を使う場合も、それぞれで内容を確認してください。スマートフォンで項目を削除しても、パソコンに保存された別のコピーから自動で消えるとは限りません。使わなくなったサブスクリプションは、登録した各端末で個別に確認します。反対に、サーバー側でアクセス権を取り消しても、端末の記録が自動で消えるわけではありません。使えなくなった情報が一覧に残る場合は、自分で整理してください。

認証情報を含まない管理メモを残し、サブスクリプションの用途、ローカルで追加した項目、依存するConfig、最後に確認した結果だけを記録する方法がおすすめです。実際の認証情報は保護されたバックアップに保存し、公開用のトラブル対処情報と混在させないでください。削除とエクスポートの範囲は第8章、テストと並べ替えは次の章をご覧ください。

Connectivity Testで確認できること

Connectivity Testは、一定の条件下で接続状況を確認する機能です。テスト方法によっては接続の確立だけを調べる場合もあれば、プロキシ経由のリクエストまで確認する場合もあります。開始前にSettingsで選択中の方法と対象を確認してください。所要時間が短くても通信速度が速いとは限らず、長時間の接続が安定するとも限りません。1回のタイムアウトだけで、サーバーが恒久的に使えないと判断するのも早計です。測定条件と合わせて結果を解釈してください。

測定結果には、端末のWi-Fiやモバイル通信、DNS、端末の負荷、サーバーの状態、テスト先の応答が影響します。ネットワークを切り替えた後は、以前の順位が当てはまらない場合があります。異なるネットワーク、時間、テスト方法で得た数値を混ぜて比較しないでください。実際の用途から離れたテスト先の結果だけで、すべてのアクセスが同じ使い心地になると推測しないようにしましょう。

比較できるテスト手順を整える

1. 端末が通常どおりインターネットに接続できることを確認し、大量の帯域を使う作業を一時停止します。同じネットワークを使い、テスト条件をできるだけそろえてください。
2. Settingsでテスト方法と対象を確認し、比較するサーバー情報には同じ設定を使います。
3. テストを1回実行し、完了してから失敗した項目を確認します。進行中に続けて何度も実行しないでください。
4. 候補を少数に絞って何回か再テストし、そのうち1つを選んで実際にアクセスします。認証、TLS、接続先の応答にエラーがないか記録してください。

一覧が長いと、すべてをテストすることで接続リクエストが増え、短時間に発生する競合が結果に影響する場合があります。現在の用途に合うサーバーを選んで範囲を絞り、比較してください。すべてが同時に失敗する場合は、端末のネットワークやテスト先など、共通する条件を先に確認します。1件だけ繰り返し失敗するなら、その設定を確認してください。1件ずつパスワードを変更するより、共通の原因を優先して調べるほうが効率的です。

並べ替えと自動選択は別の機能

遅延順に並べ替えても、通常は一覧の表示順が変わるだけです。現在のサーバーが自動で切り替わったり、先頭の項目が使用中になったりするとは限りません。並べ替え後は選択状態を確認し、Global RoutingとConfigでポリシーの選択も確認してください。Configに独自の選択ロジックが含まれている場合、一覧の順序と実際に使われる対象が異なることがあります。

名前順は特定の登録を探すとき、登録元ごとのグループ分けは更新を管理するとき、遅延順は条件をそろえて候補を比較するときに便利です。それぞれ目的が違うため、1つの並び方ですべてを解決する必要はありません。現在の画面に特定の並べ替え機能がない場合も、すべてのサーバー名を変更して代用する必要はありません。見た目の順番より、登録元を追跡できる名前を保つことが大切です。

遅延は低いのにアクセスできない場合

基本テストに成功してもWebページを開けない場合は、段階を分けて確認します。まず実際のリクエストが選択中のサーバーを経由しているか確認し、次にGlobal Routing、ルール、DNSを確認し、最後に接続先の応答を調べます。ポートへの接続が確立しても、接続先サービスがリクエストを拒否したり、後続のTLS処理に失敗したりすることがあります。原因をすべて「遅延が高いから」と考えないでください。

一部のドメインだけで失敗する場合は、REJECT、DIRECT、または適切でないポリシーに一致していないか確認します。すべてのドメインで名前解決エラーが出る場合は、まずDNSと基本のネット接続を確認してください。更新後に1件だけ問題が起きた場合は、第2章に戻って認証と転送設定を確認します。ログに記録されたエラーの段階は、一覧横の数値より原因の特定に役立ちます。外部に状況を説明するときは必要なエラー文だけを残し、アドレスと認証情報を隠してください。

実際にアクセスできることを確認してから、普段使うサーバーを決めましょう。切り替え時には、進行中の接続を再確立する必要がある場合があります。問題が続く場合は、スイッチをオンにしてもネットに接続できない場合の確認手順をご覧ください。システム権限の問題については、VPN構成の追加を求められる場合の説明をご確認ください。テストの目的は、使用条件から切り離した最小値を競うことではなく、問題の範囲を絞ることです。

削除前に対象の階層を確認する

サーバー1件の削除、サブスクリプション全体の削除、Configの削除、システムのVPN構成の削除は、それぞれ異なる操作です。サーバー1件が一覧から消えても、サブスクリプションの登録先まで削除されたとは限りません。次回の更新で再び表示されることがあります。サブスクリプションを削除すると、所属する一覧も一緒に削除される場合があります。確認画面を読み、名前と対象範囲を確認してください。一覧上の位置だけで削除対象を判断しないでください。

現在使っているサーバー情報とConfigからの参照を先に確認します。削除する対象が現在使用中のサーバーなら、動作確認済みの別のサーバーに切り替えるか、中断しても問題ない時間に接続を切ってください。Configから名前で参照されている対象を削除すると、通信が意図したとおり処理されなくなる場合があります。削除後は一覧が整理されたかだけでなく、選択中の項目、ポリシー、実際のアクセスが想定どおりか確認します。

バックアップはルールファイル1つを保存するだけではありません

Configをエクスポートしても、すべてのサブスクリプションURL、個別のサーバー情報、認証情報、ローカル設定が含まれるとは限りません。一覧のスクリーンショットから接続情報を復元することもできません。バックアップの前に現在のエクスポート機能の説明を読み、実際に保存される範囲を確認してください。復元に必要な情報は、登録済みサブスクリプション、手動入力または個別に取り込んだサーバー、ルールとDNSの設定、端末内の管理設定の4種類に分けて考えるとよいでしょう。それぞれの復元元を把握してください。

現在の画面にDataなどのデータエクスポート機能がある場合は、選択肢を確認して何が含まれるか調べてください。単体の共有リンクだけを出力できる場合は、その1件のサーバー情報のエクスポートとして扱い、端末全体のバックアップだと考えないでください。プラットフォームやデータ形式が異なる場合、完全に互換性があるとは限りません。整理する前に、エクスポートしたファイルを想定した取り込み画面が認識できることと、必要な対象が含まれていることを確認します。

機密情報を含むバックアップの保存と復元

サブスクリプションURL、共有リンク、データファイルにはアクセス用の認証情報が含まれる場合があります。自分で管理し、アクセス制限を設定できる場所に保存してください。ファイル名には用途と端末名を記載し、トークンやパスワードは含めないでください。個人用ストレージ経由でファイルを移した後も、過去のコピーと共有権限を確認します。他人にトラブル対処を頼む場合は、隠す処理をした構造情報だけを伝え、完全なバックアップを一般の添付ファイルとして送らないでください。

復元は影響範囲の小さいものから行います。まずサブスクリプションを復元または再登録して取得を完了します。次に独立したサーバー情報を復元して動作を確認し、必要なConfigを取り込みます。最後にGlobal Routing、端末内の選択、システム権限を確認してください。各段階で結果を確認してから次に進みます。古いファイルを一度にすべて取り込むと重複が生じたり、古い設定が新しい設定を上書きしたりして、原因の特定が難しくなります。

端末を変更すると、システムのVPN使用許可を改めて求められる場合があります。以前の端末の許可がそのまま引き継がれるとは限りません。VPN構成の追加を求められた場合は、システム画面に従って許可します。拒否した後で接続が必要になった場合は、クライアントから再度要求し、システム設定を確認してください。サーバー情報の復元とシステム権限の復元は別の手順です。権限の問題を解決するためにサブスクリプションの取り込みを繰り返さないでください。

誤削除、無効化、アクセス権の取り消し

サブスクリプションを誤って削除しても、有効なURLが残っていれば再登録して現在のリモート一覧を取得できる場合があります。ただし、以前のローカルメモや、リモート側から削除された項目まで復元できるとは限りません。独立して手動登録した情報は、元の資料やエクスポートしたコピーがなければ、サブスクリプションの更新で自動復元されるものではありません。まず自分のバックアップ範囲を確認してから復元方法を選び、アプリのデータをすべて消去することを通常のトラブル対処の出発点にしないでください。

端末内の記録を削除しても、その端末のデータが変わるだけで、サーバー側のアクセス権は取り消されません。サブスクリプションURL、パスワード、QRコードが漏れた可能性がある場合は、自分が管理権限を持つサービス側で該当する認証情報を変更または無効化し、各端末に再登録してください。古い項目を一覧から削除するだけでは、認証情報を取得した別のコピーから引き続きアクセスを試される可能性があります。

このページの操作が終わったら、クイックスタートガイドに戻って接続手順を確認するか、FAQで症状に合った項目をご覧ください。ルールや画面の項目の意味は用語集で、アプリの入手方法やシステムのインストール案内はアプリのダウンロードページで確認できます。サーバー情報、ルール設定、システム権限を分けて管理すると、更新時や端末変更時に確認する順序が明確になります。