公式マニュアル · サブスクリプションとサーバー

Shadowrocket
サブスクリプション・サーバー管理マニュアル

サブスクリプション、サーバー、Configを区別してから、読み込み、更新、バックアップを行います。

本ページは、すでにサブスクリプションまたはサーバー情報をお持ちの方向けのマニュアルです。初めて接続する場合は、まず使い方ガイドで基本操作を完了してから、該当する章で項目や管理方法を確認してください。ガイドの読み込み・トラブル対処の手順は、本ページの更新、QRコード、テストの説明とあわせて参照できます。

サブスクリプションリンクは、ご利用のサービス提供元から入手してください。クライアントアプリの買い切り料金と接続サービスの料金は別です。Shadowrocketの購入と接続サービスの契約は、それぞれ別に確認してください。アプリの入手方法、価格、システム要件はApp Storeで正規アプリを確認・購入する方法をご覧ください。詳細はApp Storeの掲載内容をご確認ください。

確認する順序

SubscribeSERVERConfig

サブスクリプションはサーバーの一覧を管理し、サーバーには接続情報を保存します。Configはルールの処理方法を決めます。相互に関連しますが、同じ種類のデータではありません。

01 / SUBSCRIBE

サブスクリプションは、サーバー情報を取得するためのリモートの入口です。接続のオン・オフやルール設定とは異なります。通常は1つのURLから複数のサーバー情報を取得し、アプリがその内容をサーバーリストに表示します。読み込みが成功したか確認するには、入力欄が閉じたかだけでなく、サブスクリプションが保存され、サーバー項目が作成されたことも確認してください。サーバーが登録されても接続済みとは限りません。項目を選択し、Global Routingを確認して、実際にアクセスできるかテストしましょう。

手元の情報の種類を確認する

情報を受け取ったら、まずサブスクリプションURL、単一サーバーの共有リンク、Configファイルのどれにあたるか確認してください。サブスクリプションURLは更新して複数の情報を取得できます。単一サーバーのリンクは通常1台分の情報を示します。ConfigファイルにはDNS、ルール、ポリシーが含まれる場合があります。種類の異なる情報を同じ場所に入力しないでください。内容が不明な場合は、ファイル名やリンクの長さで判断せず、サービス提供元に種類と対応方法を確認しましょう。

サーバー一覧とルール設定では、更新の対象範囲も異なります。サブスクリプションを更新してサーバーアドレスが変わっても、現在のConfigのルールが変わるとは限りません。Configを切り替えても、サーバーのパスワードは自動で修正されません。問題が起きたら、まずどの種類の情報に問題があるか切り分けると、何度も読み込み直して解決しない事態を避けられます。初めて操作する場合は、動作確認済みのサブスクリプション1件で手順を確認してから、ほかの情報を追加すると結果を判断しやすくなります。

Subscribeを保存して取得内容を確認する

Homeの追加画面からAdd Serverを開き、サブスクリプションに適したSubscribeを選択します。URLを入力し、識別しやすい名前を設定してください。画面上の項目や配置は、現在のアプリ画面をご確認ください。保存する前に、特にクエリパラメータの大文字・小文字、ハイフン、末尾の文字までURLを一文字ずつ確認しましょう。説明文や改行、日本語の句点を一緒に貼り付けたり、「URLを短くする」ために疑問符以降を削除したりしないでください。

初回の取得には、現在のネットワークからサブスクリプションURLにアクセスできる必要があります。保存後にサーバーが表示されない場合は、リクエストの失敗と内容の解析エラーを切り分けてください。前者はネットワーク、証明書、権限などが原因の場合があり、後者は応答内容が対応する形式ではない可能性があります。URLを開いてログイン画面、案内文、Webページが表示されても、サーバー一覧を取得できたとは限りません。その場合はサービス提供元に応答形式とアクセス状況を確認し、「読み込めない」とだけ伝えるのではなく、エラーの原文も控えておきましょう。

3種類の情報の役割と確認場所
種類	保存される内容	最初に確認する項目
Subscribe	サブスクリプションURLと複数情報を取得する入口	URL、アクセス権、応答内容
SERVER	単一サーバーの接続情報	種類、アドレス、ポート、認証
Config	ルール、DNSなどの設定内容	現在選択中のファイルとルールの適用順

後から確認できる管理記録を作る

サブスクリプションには、「日常用 A」のように用途と提供元を識別する記号を組み合わせた名前を付けましょう。アクセス用トークンを名前に含めないでください。名前は端末内で識別するためのもので、認証情報の代わりにはなりません。初回読み込み後に、所属グループ、現在選択中のサーバー、テスト時のネットワークを記録しておくと、次回更新時に比較できます。似た名前のサーバーは、表示名だけで同一と判断せず、アドレスとプロトコルも確認しましょう。

サブスクリプションURL内のトークンは、アクセス権を直接与える場合があります。パスワードと同様に管理してください。URL全体を公開スクリーンショット、問い合わせのタイトル、共有メモに載せないでください。トラブルの相談には、エラーの種類、ネットワーク環境、ドメインの一部を伏せた情報を伝えられます。ランダムに見える文字列が短くても、機密情報ではないと決めつけないでください。トークンが漏えいした場合は、サービス提供元に再発行方法を確認しましょう。

02 / ADD SERVER

Add Serverの手動入力項目と確認方法

手動追加は、サーバー情報がすべてそろっていて、接続項目を一つずつ確認したい場合に適しています。まずプロトコルを選び、その種類に対応した項目を入力してください。先にアドレスとパスワードを入力してから、プロトコルを何度も切り替えるのは避けましょう。認証方法や通信設定はプロトコルごとに異なり、切り替えると一部の項目が適用されなくなる場合があります。手動入力では、既存の情報を正確に再現することが重要です。フォームを埋めるために設定の組み合わせを試す方法は適切ではありません。

アドレス、ポート、認証情報を分けて入力する

サーバーアドレスには資料に記載されたドメイン名またはIPアドレスを入力し、ポートには指定された番号を入力します。通常、アドレス欄にWebページのパスを付けたり、共有リンク全体を入力したりする必要はありません。ドメイン名の前後に空白がないこと、ポートが有効な整数であることを確認してください。資料にコロンが含まれる場合は、ポートとの区切りか、IPv6アドレスの一部かを見分けましょう。末尾の文字だけで機械的に分割しないでください。

選択したプロトコルに対応する認証情報を入力してください。Shadowsocksでは暗号化方式とパスワード、VMessとVLESSではUUID、Trojanでは通常パスワードを確認します。HTTPやSOCKS5ではユーザー名とパスワードを使う場合があります。UUIDをサーバーのドメイン名として入力したり、「メモ」の内容をパスワード欄に入れたりしないでください。似た文字の入力間違いを減らすにはコピーを使い、貼り付け後に前後の空白や不要な改行がないか確認しましょう。

手動入力時に確認する項目
プロトコル・項目	確認するポイント	よくある入力ミス
Shadowsocks	暗号化方式とパスワードの両方が一致しているか	暗号化方式を確認せずパスワードだけを見る
VMess / VLESS	UUID、通信方式、追加パラメータ	別のサーバーの通信設定をそのまま流用する
Trojan / Hysteria2	認証情報、TLS、プロトコル固有の設定	異なるプロトコルの設定項目を入れ替える
TLS / SNI	証明書の確認に必要な名前と条件	SNIを任意のメモとして変更する
Host / Path	指定された通信方式に必要な値	パスを勝手に削除したり、空白を加えたりする

TLS、SNI、通信設定を推測で入力しない

TLS関連の名前は、接続先のアドレスと必ずしも同じではありません。サーバーアドレスは接続先を示し、SNIはTLSハンドシェイクでホスト名を伝えるために使われます。資料にSNIが記載されている場合は、そのとおりに入力してください。指定がない場合、別のサーバーの値を流用しないでください。証明書エラーが発生した場合は、名前、端末の時刻、証明書の状態を確認し、日常的な対処として証明書の検証を無効にしないでください。

特定の通信方式では、HostやPathなどの項目も接続処理に影響します。パスのスラッシュ、大文字・小文字、クエリの内容が重要な場合があるため、読みやすさを理由に変更しないでください。同じアドレスとポートでも、通信設定が同じとは限りません。必要な項目が資料にない場合はサービス提供元に確認し、別の接続済みサーバーから設定をコピーして試さないでください。

手動登録は一度に一つずつ確認する

保存前に、サブスクリプションから作成された項目と区別できるメモを付けましょう。初回の確認では手動登録したサーバーだけを選び、Config、DNS、接続条件を同時に変更しないでください。まず現在のネットワークから接続できるか確認し、その後でルールが想定どおりに動作するかを調べます。複数の項目を同時に変更すると、復旧してもどの項目が結果に影響したのか判断しにくくなります。

手動登録は通常、サブスクリプションの更新によって自動で同じ内容に更新されません。サービス提供元がポート、パスワード、証明書の条件を変更した場合は、手動登録の内容も確認してください。情報の入手元と用途は記録しておきますが、表示されるメモにパスワード全体を書かないでください。テスト用の重複登録は確認後に整理し、古い項目を誤って選んで接続できないと判断しないようにしましょう。

WireGuardなどの種類には、専用の鍵、アドレス、対向側のパラメータがあります。「ドメインとパスワード」を入力する通常の方法では設定できません。必要な情報がすべてそろっている場合に限って手動設定してください。秘密鍵は他人に見られないよう保護しましょう。プロトコルの違いを確認するには、対応プロトコルと入力項目の概要を参照してから、この章に戻って各項目を確認してください。

03 / SCAN & CLIPBOARD

QRコード・クリップボードから読み込む手順

QRコードとクリップボードは入力方法であり、読み込み結果は実際に含まれる内容によって決まります。QRコードには単一サーバーのリンクやサブスクリプションURLが含まれる場合があります。コピーしたテキストに説明文、改行、複数の情報が混在していることもあります。操作前に、サーバーを1台追加するのか、更新可能なサブスクリプションを登録するのかを確認しましょう。読み取りに成功しても、保存後に登録の種類を確認してください。

Scan QR Codeを使う前に、入手元と読み取りやすさを確認する

アプリのスキャン画面からScan QR Codeを開き、システムの案内に従ってカメラへのアクセスを許可します。読み取るQRコードは、すでにお持ちのサーバー情報から取得したものを使用し、出所の分からない設定情報は読み込まないでください。QRコード全体が画面内に入るようにし、反射、遮蔽、傾きに注意します。別の画面に表示されたQRコードを読み取る場合は、明るさと距離を調整してください。まず読み取りの問題を解決し、その後でリンク形式が対応しているか確認しましょう。

カメラへのアクセスを許可していない場合は、システム設定でShadowrocketのカメラ権限を確認してから、アプリに戻って再試行します。QRコードの画像が現在の端末に保存されていて、アプリ画面に写真から読み取る機能がある場合は利用できます。その項目がない場合は、元のテキストリンクを入手してクリップボードから読み込んでください。認証情報を含むQRコードを保存するために、公開画像共有サービスや不明な読み取りサイトへアップロードしないでください。

クリップボードから読み込むときは内容全体を保つ

コピー前に、選択範囲に対象のリンクだけが含まれていることを確認してください。「クリックして読み込む」などの説明文を含めたり、リンク末尾のパラメータを抜かしたりしないでください。アプリに戻り、現在の画面に表示されるクリップボード読み込み操作を使います。システムの貼り付け許可が表示された場合は、今回の操作に合わせて選択してください。内容を認識できない場合は、信頼できる端末内のテキスト環境でコピー結果を確認します。クリップボードに画像や説明文しかないのに、許可を何度も求めないでください。

ブラウザーに表示された文字列が、リンクの実際の内容とは限りません。ページによってはURLが短く表示され、文字を選択しても省略された部分しかコピーされない場合があります。資料にあるコピー機能を使うか、リンク全体が取得できているか確認してください。日本語の引用符、括弧、末尾の句読点も読み込みに影響します。説明用のレイアウト文字だと明らかなものだけを削除し、意味の分からない部分を勝手にデコードしたり書き換えたりしないでください。

読み込み後はすぐに再スキャンせず、追加された情報を確認する

読み込み後にHomeへ戻り、追加された項目の名前、プロトコル、アドレス、所属を確認してください。サブスクリプションを読み込むつもりだったのに単一サーバーだけが追加された場合、QRコードには単一サーバーの共有リンクが含まれていた可能性があります。サブスクリプションは追加されたもののサーバーリストが空の場合は、取得結果を確認します。名前が正しくても、パラメータがすべてそろっているとは限りません。必要に応じて、ポート、認証、通信設定を元の資料と照らし合わせてください。

同じQRコードを繰り返し読み込むと、重複登録が作られる場合があります。再操作の前に、すでに保存されていないか確認してください。並べ替えで位置が変わっただけ、またはグループが折りたたまれているだけの可能性もあります。重複を見つけたら、動作確認済みの一件を残し、手動で読み込んだのかサブスクリプションから作成されたのかを記録しましょう。所属を確認する前に大量削除すると、使用中の項目を誤って消したり、次回更新時に似た項目が再作成されたりするおそれがあります。

失敗した段階ごとに原因を切り分ける
症状	最初に確認する項目	次に行うこと
QRコードを読み取れない	QRコード全体、反射、カメラ権限	元のテキストリンクを入手して読み込む
テキストを解析できない	リンク全体、句読点、内容の種類	対応するリンク形式を確認する
記録は保存されたがリストが空	サブスクリプションか、取得が成功したか	応答内容とアクセス状況を確認する
項目はあるが接続できない	パラメータ、現在のネットワーク、接続許可	接続確認とトラブル対処へ進む

読み込み後の機密情報を管理する

QRコードとクリップボードには、認証情報がそのまま含まれている場合があります。読み込み後、不要になった一時的な画像やテキストを処理し、ほかの端末に自動同期されていないか確認してください。クリップボードを別の内容で上書きすれば誤貼り付けの予防にはなりますが、ほかのアプリや端末に保存済みのコピーまで消えるとは限りません。情報が公開された疑いがある場合は、端末の記録を削除するだけでなく、サービス提供元に認証情報の再設定方法を確認してください。

読み込みに成功しても接続できない場合は、ガイドのトラブル対処手順に沿って確認してください。QRコードを読み直しても、証明書、パスワード、サーバーの状態に関する問題は自動で解決しません。読み込み前後の違いとエラーメッセージを記録し、「読み取り失敗」「取得失敗」「接続失敗」を分けて説明すると、追加を繰り返すより原因を特定しやすくなります。

04 / LINK FORMATS

共有リンクの形式とConfigとの違い

共有リンクは接続情報を符号化したもので、一般的なWebページのURLとは異なります。プロトコルごとにプレフィックスや項目の構成が異なり、パラメータが符号化されている場合もあります。リンクが完全かどうかを判断するときは、パスワードを目で読み取ろうとするのではなく、プレフィックス、本文、クエリパラメータ、メモが保たれているか確認してください。認識できないリンクは、形式の説明と元の内容を確認し、むやみに文字を置き換えないでください。

単一リンクとサブスクリプションURLを区別する

ss://、vmess://、vless://、trojan://などで始まる内容は、通常、対応するプロトコルのサーバー情報を示します。一方、一般的なHTTPSのサブスクリプションURLは、複数の情報を取得するためのネットワーク上の入口です。プレフィックスは種類を見分ける手がかりになりますが、内容の有効性や対応状況までは保証しません。同じプロトコルでも符号化形式や追加パラメータが異なることがあるため、アプリが対応する形式で解析できるか確認してください。

共有リンクをブラウザーのURLとして検証しないでください。ブラウザーで特定のプロトコルのリンクを開けなくても、サーバーが使えないとは限りません。逆にHTTPSのアドレスでページが表示されても、読み込み可能なサブスクリプションとは限りません。確認すべきなのは、応答が想定する形式か、アプリに正しい情報が登録されたかです。原因を調べるときは、入口の種類を明確にしてから対応する読み込み方法を選びましょう。

# サブスクリプションURLの構造例のみ。利用可能なサービスではありません
https://example.com/sub?token=xxxx

# よく使われる単一サーバー共有リンクのプレフィックス
ss://
vmess://
vless://
trojan://

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

リンク内のパーセントエンコードやBase64の内容には、必要な項目が含まれる場合があります。「見た目を整える」ために手作業で変換しないでください。文字列によっては、プラス記号、スラッシュ、等号にエンコード上の意味があります。コピー時にプラス記号が空白に変わったり、末尾が欠けたりすると解析に失敗することがあります。まず元の内容全体を取得し直してから、対応状況を確認してください。一度のコピーエラーをプロトコル自体の問題と決めつけないようにしましょう。

疑問符以降のパラメータには、TLS、通信方式、パス、その他のプロトコル設定が含まれる場合があります。追跡用情報と決めつけて一律に削除しないでください。共有形式によっては、ハッシュ記号以降がメモとして使われますが、アプリで処理できるよう元の形式を保ちましょう。日本語の名前が正しく表示されない場合、メモのエンコードが原因で、接続情報には影響しないことがあります。表示名と接続可否を分けて確認してください。

サーバーリンクはConfigの代わりにはならない

サーバーを読み込んでも、ルール、DNS、Global Routingまで設定されたことにはなりません。ルールに基づいて通信を振り分けるには、現在のConfigと設定モードを確認してください。一時的にProxyまたはDirectを使う場合も、通信の処理方法が異なります。サーバー名に用途が書かれていても、それはメモにすぎません。アプリが対応するルールを自動作成するわけではなく、実際の設定確認の代わりにもなりません。

以下はShadowrocketの.confにおけるルール記述の例で、マッチングの仕組みを示すものであり、完全な設定ファイルではありません。ルールはファイルに記載された順に上から評価され、最初に一致した時点で終了します。FINALは最後のフォールバックとして設定します。PROXY、DIRECT、REJECTはルールのアクションであり、任意に並べ替えられる3段階の優先順位ではありません。

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

形式の問題とルールの問題を分けて確認する

リンクの解析後にアドレス、ポート、プロトコルが欠けている場合は、まず元の内容と形式の互換性を確認してください。サーバー情報がそろっているのに特定のドメインへのアクセス経路が想定と異なる場合は、ルールの適用状況を調べます。ルールの問題を共有リンクの編集で直そうとしたり、項目の不足を見知らぬConfigの読み込みでごまかしたりしないでください。一度に扱う問題を一つに絞ると、結果を判断しやすくなります。

問題について相談するときは、プロトコルの種類、エラー内容、機密情報を伏せた項目構成を共有できます。ただし、認証情報を含む本文全体は送らないでください。表示名だけを隠しても不十分な場合があります。機密情報は、符号化された本文やURLのパラメータに含まれていることがあります。伏せ方が分からない場合は、症状と項目名だけを伝え、元の情報は信頼できる保管場所に残しておきましょう。相談のために情報の露出範囲を広げないでください。

Config、Proxy、Directの使い分けについては、Global RoutingのConfig、Proxy、Directの解説をご覧ください。本章ではデータ形式と情報の区分を扱います。日常的な接続手順は使い方ガイドを参照してください。

05 / UPDATE

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

サブスクリプションの更新では、リモートの内容を再取得し、アプリの現在の動作に応じて端末内の情報を同期します。各サーバーの接続を修復する機能ではありません。リモート側の変更によりサーバーが追加、削除、変更され、端末内の選択や名前も変わる場合があります。更新前に、情報の同期、アドレス変更の確認、接続不良の調査のどれが目的かを明確にしてください。目的が違えば、確認すべき結果も異なります。

更新前に比較できる基準を残す

手動更新の前に、サブスクリプション名、現在選択中のサーバー、テストするネットワークを記録してください。必要に応じて、機密情報を伏せたパラメータの概要も残します。接続できる項目がある場合は、ルールファイルやネットワーク条件を同時に変更しないでください。更新後に追加、削除、変更された項目を比較すると、新しい情報が返されたのか、リクエストに失敗してリストが変わらなかったのかを判断できます。

Subscribeに対応する項目または管理画面から、現在のアプリに表示される更新操作を使ってください。更新のたびに削除して再登録すると、端末内のメモ、所属情報、比較の手がかりを失う可能性があります。連続してタップしても、リモート側に新しい情報がすぐ作られるわけではありません。アクセス頻度の制限につながる場合もあります。待機または失敗のメッセージが表示されたら、内容を読んでから再試行するか判断してください。

自動更新は実際の結果で確認する

現在の画面に自動更新の設定がある場合は、利用頻度に合わせて設定し、どの情報に適用されるか確認してください。モバイル端末のバックグラウンド動作は、システムのスケジュール、ネットワーク、バッテリーの状態に左右されます。設定した間隔どおりに必ず実行されるとは限りません。利用前に情報が古い可能性がある場合は、手動更新を一度実行して結果を確認しましょう。スイッチがオンになっていることだけに頼らないでください。

更新頻度を上げても接続が安定するとは限りません。リモート側に変更がなければ、同じ内容を繰り返し取得するだけです。サービス提供元から設定変更の連絡があったとき、リストと手元の情報が一致しないとき、登録が有効か確認したいときに更新しましょう。更新のたびに手動で項目を修正している場合は、本来サブスクリプションで管理する項目を手動登録として扱っていないか確認してください。

更新に失敗したときの段階別チェック
段階	考えられる症状	確認・対処する項目
ネットワーク接続	タイムアウト、ドメインを解決できない	現在のネットワーク、DNS、アドレスへの到達性
アクセス許可	認証失敗、アクセス拒否	トークン、有効状態、アクセス条件
内容の解析	Webページが返る、形式エラー	応答が必要なサブスクリプション形式か
リストの同期	登録の追加・削除、名前の変更	リモート側の変更と現在の選択項目

リクエスト失敗時は、現在使える状態を保つ

更新のタイムアウトは、すべてのサーバーが使えなくなったことを意味しません。まず端末がネットワークに接続できるか確認し、サブスクリプションURL自体に到達できないのか、現在のネットワークに問題があるのかを切り分けてください。環境によっては、サブスクリプションの取得に既存の接続が使われるかどうかが設定やルーティング条件によって異なります。一律に判断しないでください。ネットワークを切り替えて再試行する場合は、その変更を記録します。トークン、アドレス、Configを同時に変更して原因を見失わないようにしましょう。

認証やアクセス状態のエラーが出た場合は、サブスクリプションURLが変更されたか、トークンが有効か、アクセス制限があるかをサービス提供元に確認してください。公開ページにURL全体を貼り付けて相談しないでください。応答が空でも、すぐに端末内のリストを消去しないでください。リモート側が意図的に空の一覧を返したのか、案内ページに置き換わったのかを確認してから復旧方法を決めましょう。

更新後に選択状態とルールの参照先を確認する

同期が完了したら、現在のサーバーが残っているか、同じ名前でパラメータの異なる項目が追加されていないか確認します。サーバー名を参照する設定は特に注意してください。名前が変わると、既存の選択が以前と同じ接続先を示さなくなる場合があります。サブスクリプションを同期しても、カスタムConfig内の参照先がすべて自動で修正されるとは限りません。現在選択中の項目を確認して実際にアクセスをテストし、その後で古い名前やメモを整理しましょう。

更新後に一部のサーバーだけで問題が起きた場合は、ほかの正常な項目を残し、アドレス、ポート、認証情報の変更を一つずつ比較してください。一つの項目の問題を解決するために、サブスクリプション全体を何度も削除・再登録しないでください。リモート側の内容に問題がある場合は、具体的な変更点と失敗した段階を伝えましょう。端末内には必要な復旧情報を残し、移行については削除とバックアップの章を確認してください。

06 / ORGANIZE

複数のサブスクリプションと登録元の整理

複数のサブスクリプションを管理する際は、名前の統一よりも、各登録の入手元と管理方法を把握できることが重要です。サブスクリプションから作成されたサーバー、手動登録したサーバー、一時的なテスト項目を見分けられるようにしましょう。区別できないと、サーバーが使えなくなったときに、サブスクリプションを更新するのか、手動設定を修正するのか、一時項目を削除するのか判断しにくくなります。整理は今後の管理に役立つ範囲にとどめ、見た目を整えるためだけに階層を増やす必要はありません。

安定していて機密性の低い命名ルールを使う

サブスクリプション名には、「日常用 A」「予備用 B」のように用途と提供元の記号を組み合わせられます。手動登録には「手動」、一時登録には「テスト」と分かる印を付けましょう。名前にパスワード、サブスクリプションURL全体、認証トークンを含めないでください。同じ提供元には一貫した記号を使うと、更新やバックアップの際に対応関係を確認しやすくなります。メモには用途を記録できますが、サーバーが今後も使えると断定しないでください。状態はネットワークやリモート側の条件によって変わります。

サブスクリプションから作成された名前は、更新時にリモート側の内容で置き換わる場合があります。重要な管理情報をその名前だけに記録しないでください。長期間保管する必要のある説明は、保護された別の記録に保存し、サブスクリプションの記号と識別に必要な特徴を記載します。リスト上の位置だけでサーバーを覚えないでください。更新、折りたたみ、並べ替えで位置が変わることがあります。名前、プロトコル、所属を組み合わせて確認しましょう。

名前ではなく情報を照合して重複を判断する

同じ名前の2件が異なるアドレスに接続する場合があります。反対に、異なる名前でも同じ接続先を使うことがあります。重複かどうかを確認するには、プロトコル、アドレス、ポート、主要な認証情報や通信設定を比較してください。比較中に機密情報を公開しないようにしましょう。2件が異なるサブスクリプションから作成されている場合、パラメータが一時的に同じでも、今後の更新内容が異なる可能性があるため、まず登録元を保持してください。

重複を見つけたら、操作ミスで作成したと明らかな一時項目から整理します。確認せずにサブスクリプション配下の項目を削除しないでください。端末内で変更した内容が、次回更新時に再作成されたり上書きされたりする場合があります。実際の動作は現在のアプリ画面で確認してください。サブスクリプションを長期間使わない場合は、移行とバックアップを済ませてから入口を削除します。サーバーを数台だけ削除しても、次回更新で同じ一覧が返される可能性があります。

管理方法に応じて整理ルールを決める
登録の種類	見分け方の例	管理方法
サブスクリプションから作成	サブスクリプションの記号とサーバーの所属	主な同期方法としてサブスクリプションを更新する
手動登録	手動登録であることと用途をメモする	元の情報と項目ごとに照合する
一時的なテスト	テスト用と分かる印を付ける	結果を確認したら速やかに整理する
使用を停止する予定	移行状況を別に記録する	代替項目を確認してから削除する

リストのグループとルールのポリシーは別のもの

Homeで表示用に分けられたグループを、Config内のポリシー選択と同じものとして扱わないでください。同じサブスクリプションの下に表示されるのは、サーバー情報の入手元が同じという意味です。ルールによって自動的に切り替わることを示すものではありません。実際の通信処理は、Global Routing、現在のConfig、設定内のポリシー参照によって決まります。リストを整理した後は、現在の選択が日常の用途に合っているか確認してください。

Configが名前を参照している場合、名前の変更によって対応関係が変わる可能性があります。変更前にカスタムルールやポリシーがその名前に依存していないか確認し、旧名と新名の対応を記録しておきましょう。名前を統一するためにすべての項目を一度に変更し、同時にサブスクリプションも更新しないでください。名前の整理とリモート同期を別々に行えば、接続や選択に影響した操作を特定しやすくなります。

一度に大量に整理せず、小さな範囲で進める

サブスクリプションを一つずつ整理する方法がおすすめです。まず入口が有効か確認し、リストの所属を確認して、サーバーを一つテストしてから、明らかな重複の一時項目を整理します。一つのグループが終わってから次に進みましょう。折りたたみ、名前変更、並べ替え、全件削除を同時に行わないでください。一度に変更する情報を絞ると、想定どおりにならなかった場合も前の状態に戻しやすく、リスト全体を作り直さずに済みます。

テストと並べ替えの結果は整理の参考の一つであり、削除を決める唯一の基準ではありません。現在のネットワークでタイムアウトしたサーバーが、別のネットワークでは動作する場合があります。一時的に遅延が大きくても、パラメータが無効とは限りません。「現在接続できない」「パラメータが古い」「不要になった」を分けて記録してから、残す、修正する、削除するのいずれかを判断してください。一時的なネットワークの問題で情報を失わないようにしましょう。

複数の端末で使う場合は、各端末の同期方法と管理担当を明確にしてください。同じサブスクリプションを登録していても、手動メモ、並べ替え、選択状態が自動で一致するとは限りません。同期の仕組みを確認せず、一方の変更がすべての端末に反映されると思い込まないでください。別のiPhoneやiPadに移行した後も、サーバー、Config、システムの接続許可を個別に確認しましょう。

07 / CONNECTIVITY TEST

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

遅延テストで分かるのは、特定の条件における応答状況であり、接続品質のすべてではありません。一度遅延が小さくても、あらゆるWebサイトにアクセスできるとは限りません。一度タイムアウトしただけで、サーバーが恒久的に使えないとも判断できません。現在のテスト方法が、接続の確立、特定のリクエスト、その他の到達性のどれを測定しているか確認してから数値を見てください。テスト結果、実際のアクセス、ルールの適用状況をあわせて判断し、リスト内の最小値だけを基準にしないでください。

テスト環境をそろえてからサーバーを比較する

Connectivity Testを実行する前に、端末のネットワーク、接続が確立しているか、現在のGlobal RoutingとConfigを確認してください。複数のサーバーを比較する場合は、同じ条件でテストします。一方をWi-Fi、もう一方をモバイル通信でテストしないでください。テスト中に大容量のダウンロードをしたり、ネットワークを何度も切り替えたりすると、環境の変化が結果に混ざり、サーバー間の比較が難しくなります。

現在の画面でテスト方式や対象を選べる場合は、その設定を記録し、同じサーバー群に同じ条件を使ってください。テスト対象自体が一時的に不安定な場合もあります。すべてがタイムアウトしたら、まず対象と端末のネットワークを確認し、サーバー全体が使えないと即断しないでください。時間を空けて再テストすれば結果の安定性を確認できますが、見栄えのよい数値を求めて頻繁にテストを繰り返す必要はありません。

応答時間、通信速度、実際の利用可否を区別する

応答時間は特定の処理にかかる時間を表し、通信速度、長時間の安定性、特定サービスへのアクセス可否を直接示すものではありません。リモート側の負荷、ネットワーク経路、接続先サービスの状態が使い勝手に影響します。サーバーを選ぶときはテスト値だけでなく、よく使う操作を安定して完了できるかも確認してください。短時間のテストを実利用の代わりにしたり、結果が長期間変わらないサーバーの特性だと考えたりしないでください。

サーバーのテストに成功してもWebページを開けない場合は、すぐにサブスクリプションを読み込み直さず、DNS、ルール、TLS、接続先のサイトを確認してください。テストではドメイン解決や実際のリクエストを確認していない場合があり、通信経路も異なることがあります。まず明確なテスト対象で確認し、どの段階でエラーが出たか調べましょう。詳しくは遅延は正常なのにWebページが開けない場合のDNS対処をご覧ください。

Global Routingと確認範囲
モード	主な処理方法	確認時のポイント
設定 / Config	現在のConfigのルールに従って通信を振り分ける	接続先のドメインにどのルールが適用されたか確認する
プロキシ / Proxy	プロキシモードで接続を処理する	現在選択中のサーバーを確認する
直結 / Direct	直結モードで接続を処理する	これだけではプロキシサーバーが使えるとは確認できない

並べ替えで変わるのは表示順であり、自動選択されるとは限らない

遅延順に並べ替えると、今回のテストで応答が速かった項目を見つけやすくなります。ただし、並べ替え後にアプリが自動で先頭の項目へ切り替わるとは限りません。現在の選択マークを確認し、必要であればサーバーを手動で選んでからアクセスをテストしてください。Configに別のポリシーや選択ロジックが含まれる場合は、実際にどの項目が参照されるかも確認します。リストの選択項目とルールが最終的に使う接続先が異なる場合があります。

並べ替え後に見慣れたサーバーが見つからない場合は、重複して読み込まず、名前と所属で探してください。タイムアウトした項目がリストの後ろに移動したり、グループが折りたたまれて表示されなくなったりする場合があります。複数のサブスクリプションがある場合は、並べ替えが現在のグループだけに適用されるのか、リスト全体に適用されるのか、現在の画面で確認してください。重要なのは登録の特定情報を保つことであり、何行目にあったかを覚えることではありません。

失敗した段階ごとに結果を記録する

実際の動作確認はいくつかの段階に分けられます。登録情報がそろっているか、サーバーに接続できるか、システムの接続許可が有効か、ドメインを解決できるか、接続先へのリクエストが完了するかを確認してください。失敗したときは、どの段階で止まったか記録します。初回接続時に表示されるシステムのVPN構成に関する確認は、接続許可の手順です。サブスクリプションの認証エラーと混同しないでください。詳しくはVPN構成の追加を求められた場合の説明をご覧ください。

同じ条件で特定のサーバーだけが繰り返し失敗し、ほかの項目は正常な場合は、そのサーバーの認証情報、ポート、リモート側の状態を確認してください。すべての項目が同時に失敗した場合は、端末のネットワーク、テスト対象、Configの変更など、共通する条件を優先して調べます。「共通の原因を先に確認し、個別のパラメータはその後に調べる」という順序は、無作為に項目を変更するより効率的で、サービス提供元にも状況を説明しやすくなります。

08 / BACKUP & REMOVE

安全に削除・移行・バックアップする手順

削除する前に、対象、影響範囲、復旧に必要な情報を確認してください。単一サーバー、サブスクリプションの登録、Configファイル、システムのVPN構成は別の情報です。一つを削除しても、ほかの情報まで整理されるわけではありません。接続を停止するのが目的なら、まず接続を切り、On Demandの条件を確認します。リストを整理する場合は、登録情報を処理してください。通常の切断操作の代わりにすべての情報を削除しないでください。

必要な情報をバックアップしてから削除する

バックアップには、有効なサブスクリプションURL、手動登録したサーバーのパラメータ、実際に使用しているConfig、それぞれの所属や用途を理解するための説明を含めてください。サブスクリプションURLがあればリモート側の最新情報を再取得できる場合がありますが、過去のサーバー一覧を復元できるとは限りません。Configファイルに手動登録したサーバーがすべて含まれるとも限りません。復元が必要な情報ごとに、再作成に使える資料があるか確認してください。リストのスクリーンショットだけを保存しないでください。

現在のアプリに書き出し、共有、バックアップの機能がある場合は、保存される内容の範囲を確認し、認証情報やカスタム設定が含まれるか確認してください。操作によっては、状態全体ではなく単一の登録しか書き出されない場合があります。元の登録を削除する前に、信頼できる場所でファイルを開き、内容が読めて必要な情報がそろっているか確認してください。ファイルが作成されたことだけで、復元も必ず成功すると考えないでください。

機密情報を含むバックアップを保護する

バックアップにサブスクリプショントークン、パスワード、UUID、秘密鍵が含まれる場合があります。自分で管理できる安全な場所に保存してください。端末間で同期する場合は、同期アカウント、アクセスする端末、共有範囲を確認し、初期設定で公開されているフォルダーには保存しないでください。用途と対象が分かる説明を付けつつ、ファイル名に認証情報全体を含めないようにします。一時的な書き出しの後は、メッセージの添付ファイル、写真、その他の一時保管場所にあるコピーも処理しましょう。

アプリを再入手することと、利用データを復元することは別です。iPhoneやiPadを買い替えた場合に、App Storeから購入済みアプリを入手する方法は購入済みアプリの復元方法をご覧ください。アプリを再インストールできても、サーバー、サブスクリプション、カスタムConfigがすべて復元されるとは限りません。システムバックアップで復元できると決めつけず、重要な情報を再構築できるか事前に確認し、独立したチェックリストを用意してください。

削除する情報と確認すべき影響
削除する情報	事前に確認すること	復元に使う情報
単一サーバー	現在使用中か、サブスクリプションから作成されたか	元のパラメータまたは有効なサブスクリプション
Subscribeの登録	関連するサーバーとConfig内の参照先への影響	完全で有効なサブスクリプションURL
Configファイル	現在使用中のConfigか、カスタム設定があるか	保護されたConfigのコピー
システムのVPN構成	接続許可とOn Demandの条件への影響	アプリからシステムの許可を再度求める

範囲を絞り、順番に整理する

サーバーを削除する前に、動作確認済みの別の項目へ切り替え、名前を参照する設定がないか確認してください。サブスクリプションを削除する場合は確認メッセージを読み、関連項目がどう扱われるか確認します。連動する動作は現在のアプリ画面で確認してください。サブスクリプション配下のサーバーだけを削除しても、次回更新で再作成される場合があります。提供元の情報を継続して使わない場合は、更新のたびに削除するのではなく、サブスクリプション自体をどうするか検討しましょう。

Configを削除する前に、カスタム設定を書き出し、代わりに使えるConfigがあることを確認してください。削除後にアクセス方法が変わった場合は、サーバーのパスワードをすぐ変更せず、現在のGlobal Routingと選択中のファイルを確認します。システムのVPN構成を削除すると、次の接続時に再び許可を求められる場合があります。これはシステムの接続構成を再作成する操作であり、サブスクリプションの再購入やサーバー認証情報の無効化ではありません。

復元後に読み込み、選択、確認の順でチェックする

復元時は、まずサブスクリプションまたは手動登録したサーバーを追加し、リストと所属を確認します。次に必要なConfigを読み込んで選択し、最後にGlobal Routingとシステムの接続許可を確認してください。古い登録を大量に復元してすぐに重複を削除するのではなく、まず一連の手順で接続できることを確認します。以前のConfigを使う場合は、参照先のサーバー名が現在も存在するか確認してください。情報を復元できても、参照先が無効になっている場合があります。

新しい端末での確認が終わるまで、古い端末とバックアップ内の有効な情報を残してください。日常のアクセス、更新の入口、カスタムルールが正常に動作することを確認してから、不要なコピーを整理します。バックアップ内のサブスクリプショントークンやパスワードがすでに変更されている場合は、サービス提供元から入手した最新情報を使ってください。古いバックアップは構成の確認には使えますが、有効な認証情報としては使えません。