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

01 Subscribe：更新可能なサブスクリプションを登録する

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

サブスクリプションはサーバー情報を返すリモートURL、サーバー項目は読み込み後にローカルに表示される接続情報、Configはルールや関連する接続設定を管理するものです。相互に関係しますが、代用はできません。サブスクリプションを読み込んでサーバー一覧が表示されても、情報がアプリに取り込まれたことを示すだけです。現在のルールがそのサーバーにリクエストを送っていることや、リモート側のアカウントが引き続き有効であることまでは確認できません。作業前に、手元の情報がサブスクリプションURL、単体の共有リンク、ConfigのURLのどれかを確認してください。

この章では、ご自身のサブスクリプションをすでにお持ちであることを前提に説明します。準備としてURL全体と、サービス提供元から案内された形式の説明を手元に用意してください。アカウント状況を確認できるページがある場合は、サブスクリプションが有効か事前に確認します。URLに含まれる英単語だけで用途を判断しないでください。末尾に分かりやすい拡張子がないサブスクリプションURLもあります。アクセス情報が含まれることが多いため、URLはパスワードと同様に安全に保管してください。以下のURLは説明用の例であり、実際の接続には使えません。また、利用可能なサービスを示すものではありません。

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

Add ServerでSubscribeを保存する

1. Homeから追加画面を開き、Add Serverを選択して、TypeでSubscribeを選びます。
2. サブスクリプションURL全体をURLに入力し、見分けやすい名前をRemarksに設定して保存します。表示される項目はアプリの現行画面に従ってください。
3. 初回の取得が終わるまで待ち、一覧にこのサブスクリプションに属するサーバー項目が表示されるか確認します。再取得する場合は、対象のサブスクリプションに対応する更新操作を使います。

名前には「個人用・普段使い」のように用途を付けると分かりやすく、URL全体を繰り返し記載する必要はありません。保存前に、URLの先頭、疑問符以降のクエリパラメーター、末尾がすべて含まれているか確認してください。特にチャットからコピーした場合は、空白、改行、日本語の句読点が混入していないか注意します。QRコード、ブラウザページのタイトル、サブスクリプションURLは別のものです。案内ページのURLをURL欄に入力すると、サーバー情報ではなくWebページの本文が取得されることがあります。

初回取得後に確認する順序

まずグループ名を確認し、サーバーを1件選んでType、Address、Portを照合し、取得内容が手元の情報と一致するか確認します。サーバー項目の数はリモート側の管理状況によって変わるため、「数が多いこと」を正しく読み込めた基準にしないでください。名前が正常に表示されるのに一覧が空の場合は、リクエストの失敗、空の応答、形式を解析できない状態を切り分けます。その際は元のサブスクリプションを残し、エラー表示を記録してください。状況を把握する前に、削除と再登録を繰り返さないようにします。

初回のリクエストが失敗しても、URLが無効とは限りません。現在のネットワークからサブスクリプションURLにアクセスできない、リモート側が一時的に利用できない、ログインページが返されている場合もあります。利用可能な登録がすでにある場合は、その状態を保ってください。サーバーがまったくない場合は、現在のネットワークと別の信頼できるネットワークでそれぞれ一度ずつ確認し、設定を次々に変えて比較の基準を失わないようにします。詳しくはサブスクリプションを解析できない・サーバー一覧が空のときの確認方法をご覧ください。

この章を読み終えたら、サブスクリプションの親項目、その管理下にあるサーバー、現在選択している接続項目をそれぞれ特定できる状態を目指します。独立したサーバーだけが表示され、更新可能なサブスクリプションとの関連がない場合は、単体の共有リンクを読み込んだ可能性があります。表示名だけで自動更新されると判断しないでください。次回のメンテナンス前に、その項目が本当にSubscribeに属しているか確認します。

02 Add Server：手入力する項目を順に確認

名前からパラメーターを推測せず、プロトコルに合わせて入力する

手入力は、サーバーのパラメーターをすべて把握している場合に適しています。Add Serverを開いたら、まずTypeを選択し、そのプロトコルで必要な項目を入力します。Typeによって認証方式、トランスポートのオプション、暗号化設定は異なります。種類を切り替えた後も各項目の意味が変わらないとは限りません。サーバー名は識別用のラベルです。名前にTrojanなどのプロトコル名が含まれていても、資料に明記されたプロトコルの代わりにはなりません。

通常、Addressにはホスト名またはIPアドレス、Portにはサーバー側の待受ポートを入力します。ホスト名とポートが別々に案内されている場合、プロトコルの接頭辞、Webページのパス、クエリパラメーターをAddressに含めないでください。IPv6アドレスは、各項目の入力要件に従ってください。共有リンク内の角括弧やポート表記を、すべての入力欄にそのまま転記できるとは限りません。Portはサーバー側の設定と一致させます。一般的な例に使われているポートをそのまま流用しないでください。

認証、TLS、トランスポート層を個別に確認

Shadowsocksでは、パスワードと暗号化方式を組み合わせて設定します。VMessやVLESSではUUID認証が一般的で、Trojanでは対応するパスワード認証を使います。WireGuardは鍵、アドレス、ピア設定からなる別の構成であり、アドレスとパスワードだけを入力する形式ではありません。Hysteria2も、サーバー側の情報に従って認証やトランスポートのパラメーターを設定します。ここでは確認の進め方を説明しており、すべてのプロトコルで各オプションを共通して使えるという意味ではありません。

TLS関連の項目は、案内された値を保ってください。SNIはTLSハンドシェイクで使用するサーバー名です。接続先のAddressと証明書に対応する名前は異なる場合があるため、2つのドメインが表示されても重複とは限りません。証明書エラーが出た場合は、まずドメイン名、デバイスの時刻、サーバー証明書、トランスポート設定を確認します。証明書検証の無効化を汎用的な解決策として使わないでください。実際のアドレスや証明書の問題を見えにくくし、接続時の検証範囲を変えることになります。

WebSocketなどのトランスポートを使う場合、HostやPathがサーバー側のルーティングに影響することがあります。Pathのスラッシュ、大小文字、クエリパラメーターは意味を持つ場合があるため、見た目だけで簡略化しないでください。HostがAddressと完全に一致するとも限りません。案内されていない項目は、別の例を参考にして適当に追加するより、適切な初期値のままにする方が妥当です。資料に明記されている場合だけ変更し、変更内容と結果を記録してください。

保存後は一度に一つの条件を変えて確認

初回保存時は見分けやすいRemarksを設定し、手入力した項目とサブスクリプション由来の項目を区別することをおすすめします。まず保存と選択ができることを確認し、その後にテストと実際のアクセスを行います。失敗した場合は、根拠のあるパラメーターを一度に一つずつ調整します。たとえばPort、認証、最後にトランスポートの順に確認します。Type、TLS、Path、DNSを一度に変更すると、偶然復旧しても原因を特定できません。

同じサーバーの共有リンクは読み込めるのに手入力した項目を使えない場合は、項目を並べて比較できます。ただし、認証情報全体を公開しないでください。名前だけでなく、認証情報の文字、TLSの状態、SNI、トランスポートのパラメーターを重点的に比較します。資料が不完全な場合は、ご自身のサービス提供元に不足項目を確認してください。ホスト名だけから正しいパスワード、UUID、サーバーの待受方式を導き出すことはできません。

手入力した項目は、通常、元のサブスクリプションが更新されても自動では修正されません。サブスクリプションの項目を複製して調整した場合は、Remarksに「手動」と記し、変更理由を残してください。リモート側でPortや認証情報が変更されたら、手入力した複製も個別に確認します。名前が同じというだけで選んでしまい、一覧に古い設定が残っていたという事態を防げます。

03 Scan QR Codeとクリップボードからの読み込み

読み込み方法を選ぶ前に、データの内容を確認する

QRコードとクリップボードはテキストを受け渡す手段であり、テキストの用途を決めるものではありません。QRコードには、単体サーバーの共有リンク、SubscribeのURL、通常のWebページURLのいずれも含まれる可能性があります。スキャンに成功したことが示すのは、QRコードの内容を読み取れたということだけです。サーバーパラメーターが完全か、サブスクリプションが有効か、情報が信頼できるかまでは保証されません。読み込む前に、それが手元のどの情報に対応するか確認し、読み込み後はどのグループに追加されたか確認してください。

Scan QR Codeを使うときは、コード全体がカメラの枠内に入るようにし、端が切れたり、画面が反射したり、画像が過度に圧縮されたりしないようにします。カメラ機能を初めて使う際、システムからカメラへのアクセス許可を求められる場合があります。スキャンを行うときに必要に応じて許可してください。QRコードがデバイスに画像として保存されている場合、画像から直接読み取れるか、入口がどこにあるかは現在の画面をご確認ください。認識のために、認証情報を含む画像を外部の読み取りサイトへ送信しないでください。

QRコード読み取り後の確認を省略しない

1. 読み取った内容が想定していた情報か確認し、単体サーバーかサブスクリプションかを特に確認します。
2. 編集画面や確認画面が表示された場合は、Type、Address、Port、Remarksを確認してから保存します。
3. Homeに戻って新しい項目を探し、所属グループを確認してからテストと選択を行います。

カメラのピントが合わない問題と、サーバーに接続できない問題は別の段階で発生します。前者は照明、距離、画像の鮮明さを調整し、後者はパラメーターとネットワークを調べます。スキャン後に対応していない内容と表示された場合は、まずデータの形式を確認してください。同じ鮮明なQRコードを何度も撮り直す必要はありません。サービス提供元のQRコードが案内ページを示している場合もあります。そこに記載されたアプリ用の情報を使い、Webページへの転送をサーバー情報の読み込みと取り違えないでください。

クリップボードには情報全体を一度だけコピーする

ご自身の情報からリンクをコピーする際は、専用のコピー操作を使い、説明文、引用符、文末の句読点まで一緒に選択しないようにします。Shadowrocketに戻り、現在の画面で利用できるクリップボードからの読み込み方法を使ってください。システムがペーストの許可を求めた場合は、直前にご自身でコピーした内容であることを確認してから続行します。クリップボードの内容を確認せずに複数のダイアログで続けて許可すると、以前にコピーした古い情報を読み込むおそれがあります。

複数行の情報を扱う場合は、アプリが該当する一括形式に対応しているか、先に確認してください。異なるプロトコルのリンク、説明文、サブスクリプションURLを一つのテキストに混在させても、想定した一括データとして処理されるとは限りません。まず1件で手順を確認し、明確に対応している一括形式を使う方法が確実です。一部だけ読み込めた場合は、すべてを再度貼り付けて項目を重複させるのではなく、元のテキストと1件ずつ照合してください。

内容が途中で切れている場合は、リンク末尾の名前部分とクエリパラメーターが残っているか確認してください。エディター上の長い行が画面表示だけで折り返されている場合、実際に改行が入ったとは限りません。一方で、転送方法によっては元のテキストが実際に変わることもあります。デバイス上でテキストの境界を確認できますが、認証情報全体を複数のメモや共有ドキュメントにコピーする必要はありません。比較する際は、コピーをあちこちに保存するより、文字位置と各項目の有無を確認してください。

同じ情報をSubscribeから読み込み済みの場合、単体項目として再度QRコードから読み込むと、通常はサブスクリプションに統合されず、別の独立した項目が作成されます。サブスクリプション更新の対象にならない可能性もあります。読み込み前に一覧に同じ項目がないか確認してください。一時的な確認用として読み込む場合は複製だと分かるRemarksを付け、テスト後はバックアップと削除の章を参照して整理します。

最後に、「情報の読み込みが成功したこと」と「システム接続が確立したこと」を分けて確認してください。新しい項目が一覧に追加されても、接続スイッチがオンになったとは限りません。システムのVPN構成許可は、カメラやペーストの許可とも別です。接続を開始するときに必要なシステム許可を設定し、実際のアクセスで結果を確認します。異なる権限の手順を一つの読み込みエラーとしてまとめないようにしてください。

04 共有リンク：形式、エンコード、Configとの違い

リンクの接頭辞から解析方法を見分ける

サーバーの共有リンクは通常、ss://、vmess://、vless://、trojan://など、プロトコルに応じたURIの接頭辞で始まります。接頭辞の後には、認証情報、アドレス、パラメーターが直接並ぶ場合も、エンコードされた構造化データが続く場合もあります。そのため、すべてのプロトコルに同じ分解方法を使うことはできません。接頭辞だけを置き換えて、あるプロトコルを別のプロトコルに変換できると考えないでください。

以下は項目の位置を確認するための説明です。パスワードとドメインは例示用の値であり、実際の接続には使えません。Trojanの例では認証情報がアドレスの前にあり、疑問符の後にパラメーター、#の後にRemarksがあります。VLESSの例には例示用のUUIDを使用しています。実際に使うときはご自身の元のテキスト全体を保ち、サーバー側が求めるトランスポートのパラメーターを確認してください。リンクの形式が完全に見えても、サーバーがその設定を受け付けるとは限りません。

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

vless://[email protected]:443?encryption=none&security=tls&type=tcp&sni=example.com#example-vless

繰り返しデコードしたり、手作業で連結したりしない

URIでは一部の文字が区切りとして使われるため、認証情報や名前に含まれる特殊文字はパーセントエンコードが必要な場合があります。エンコード後のパーセント記号と文字の並びは、任意に削除できる不要な文字ではありません。繰り返しデコードすると、元は項目の内容だった文字が新しい区切り文字として扱われるおそれがあります。サービス提供元から受け取ったリンクは、元の内容をそのままコピーしてください。「短く見せる」ためにパラメーターを削除したり、空白を追加したり、大小文字を書き換えたりしないでください。

VMessなどの共有形式にはBase64エンコードされた内容が含まれる場合がありますが、Base64は暗号化ではなくエンコード方式です。文字列をデコードできるからといって、結果を公開ページに貼り付けてよいわけではありません。復元された認証情報も機密情報です。解析できない場合は、複数の変換方法を次々に試すのではなく、まず接頭辞、内容の完全性、形式への対応状況を確認してから各項目を調べてください。

Remarksはリンク末尾に付くことが多く、通常は認証には使われません。ただし、末尾ならすべて削除してよいという意味ではありません。#より前にあるクエリパラメーターがTLS、SNI、トランスポートの種類、Pathを設定している場合、削除しても読み込み自体は成功する一方、元と同じ方法で接続できなくなる可能性があります。読み込み後のフォームが想定と異なる場合は、元のリンクと解析後の項目を比較し、パラメーターが途中で切れていないか、無視されていないか重点的に確認してください。

サーバー共有リンクと.confは別の種類の情報

単体の共有リンクは主に1台分のサーバー接続情報を表します。Shadowrocketの.confにはルールなどの設定を含めることができます。以下はルールの章で使う説明用の例で、順番に照合する基本構造を示したものです。接続情報一式ではありません。この例をコピーしてもサーバーは作成されず、サブスクリプションの代わりにもなりません。利用前に、必要なポリシーがご自身のConfigと接続環境で正しい意味になるか確認してください。

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

DOMAIN-SUFFIXはドメインのサフィックスに一致し、GEOIPは接続先IPの地理情報を使って判定し、FINALはそれ以前のルールに一致しなかったリクエストを処理します。ルールは上から順に照合されるため、前方の広いルールに一致すると、後方の詳細なルールが適用されない場合があります。サーバーの確認中にリクエストがDIRECTへ送られている場合、そのアクセス結果からプロキシサーバーの正常性は判断できません。読み込みと通信の振り分けを別々に確認する必要があるのはこのためです。

共有リンクの確実な確認方法は、「貼り付けられたか」ではなく、読み込み後のプロトコル、認証、トランスポートの各項目が元の情報と一致しているかを見ることです。項目が不足している場合は、共有形式にその情報が含まれているか、現在の解析機能が対応しているかを確認してから、資料に従って手動で補うか判断してください。項目の役割を理解しないまま別のサーバーの設定を流用すると、再現可能だった問題が新たな混在設定によって複雑になります。

ご自身の情報を移行する場合は、共有する対象が単体サーバー、サブスクリプションURL、Config全体のどれかを先に確認してください。含まれる範囲はそれぞれ異なります。単体の項目にはサブスクリプションの更新関係は含まれず、ルールの一部にも参照先がすべて含まれるとは限りません。何の情報で、何に使うのかを明記してから共有し、受け取った側で各項目を確認すると、説明のない長い文字列を送るより不足に気付きやすくなります。

05 更新方法：現状を保ってから変更を確認

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

サブスクリプションの更新では、リモートからサーバー情報を再取得します。アプリの更新はApp Storeから行うもので、両者は別の操作です。サブスクリプションの更新に失敗しても、すぐにアプリを更新する必要があるとは限りません。アプリを更新しただけでサブスクリプションも更新されたと判断することもできません。日常的なメンテナンスでは、リモート情報の変更、接続障害、アプリの操作上の問題のどれを解決したいのかを特定し、対応する操作を選ぶことで不要な変数を減らせます。

更新する前に、現在のネットワークからサブスクリプションURLにアクセスできることを確認し、選択中のサーバーと利用可能な状態を記録してください。リモート側で名前、アドレス、Port、認証情報、項目数が変更されると、ローカルの一覧にも反映されます。更新で常に項目が増えるとは限らず、古い項目が必ず残るとも限りません。重要な手入力の変更は先にバックアップしてください。更新時にサブスクリプション管理下のデータがリモート側の内容で置き換わる場合があります。

更新するタイミングと範囲を選ぶ

ご自身のサービス提供元から変更の案内があったとき、項目が使えなくなったとき、情報を確認したいときは、手動更新が適しています。現在の画面に自動更新の設定がある場合は、ご自身のネットワーク環境と使用頻度に合わせて設定し、しばらく後に実際の結果を確認してください。自動化しても確認は必要です。ネットワークに接続できない、アカウント状況が変わった、応答形式に問題があるといった理由で、期待どおりに更新されない場合があります。

接続に一度失敗しただけで、すべてのサブスクリプションを続けて更新することはおすすめしません。複数のリクエストが同時に失敗すると、共通のネットワーク問題なのか特定のサブスクリプションの問題なのか判別しにくくなります。リモート側で頻繁なリクエストが制限される場合もあります。まず関連するサブスクリプションを一つ更新し、エラーと一覧の変化を確認してから、ほかの項目を更新すると状況を把握しやすくなります。接続を重要な操作に使っている場合は、利用可能な状態を保ち、適切なタイミングでメンテナンスしてください。

ボタンの状態ではなく、結果で成功を判断する

更新後は、変更されるはずの項目を少なくとも1件確認し、実際に情報が更新されたか確かめてください。ボタンが再び操作可能になったり、読み込みアイコンが消えたりするのは、操作が終了したことを示すだけで、応答内容が正しいとは限りません。サービス提供元がPortの変更を案内したのにローカルの値が古い場合は、正しいサブスクリプションを更新したか、URLが正しい情報を参照しているか、リモート側で変更が公開済みかを確認してください。すべての項目をすぐに削除して作り直さないでください。

サブスクリプションによっては、使用量や有効期限の情報が含まれています。こうした情報はリモートから提供され、アプリは表示を担いますが、使用可能量を独自に確認したことを意味しません。表示がない場合やサービス提供元の記録と一致しない場合は、応答ヘッダーや情報の内容と、アカウント状況を別々に確認してください。項目名に含まれる日付だけで利用権限を判断したり、古い表示を更新完了の証拠と見なしたりしないでください。

更新後、以前選択していた項目の名前が変わったり、置き換えられたり、削除されたりする場合があります。その場合は選択中の項目を改めて確認し、実際にアクセスしてください。Configのルールがカスタム名やポリシーを参照している場合は、参照先が引き続き有効かも確認します。データ更新は成功しているのにアクセス経路が変わった場合、サブスクリプションの取得失敗ではなく、参照先や選択の問題であることがよくあります。通信の振り分けについてはGlobal Routingの3つのモードの違いをご覧ください。

リモート側の情報に誤りがあると確認できた場合は、アプリ内でパラメーターを一つずつ推測するのではなく、修正を待ってください。一時的に手入力した利用可能な項目には印を付け、次回更新時にサブスクリプション管理下の項目と取り違えないようにします。復旧後は一時的な複製を整理し、長期的な管理対象を、関係が明確なサブスクリプションと少数の手入力項目にまとめます。

06 複数サブスクリプションの整理：名前、所属、ルール参照

サブスクリプションの所属関係を分かりやすくする

複数のサブスクリプションを管理する目的は、項目をできるだけ増やすことではなく、各項目の更新元、保管理由、現在の使用状況を把握することです。まずSubscribeの各親項目に一貫した別名を付け、リモートから取得した項目は元の識別情報を保ちます。別名には用途や情報の種類を記載できますが、認証情報全体は含めないでください。2つのサブスクリプションから同じサーバー名が返されても、所属グループから区別できるようにします。

サブスクリプションの別名とサーバーのRemarksは役割が異なります。親項目は更新元を識別し、子項目は個々の接続先を識別します。手入力した複製には、管理方法も分かるように記載してください。「個人用・普段使い」「個人用・予備」「手動・テスト」のような名前を付けられますが、「予備」と付けただけで自動切り替えが設定済みになるわけではありません。名前は管理用の目印であり、実際の選択は現在の設定によります。

表示名だけで重複項目を削除しない

同じ名前の項目でも、同じサーバーを指すとは限りません。Addressが同じでも、Port、認証、トランスポートが異なる場合があります。重複かどうかを判断するには、所属するサブスクリプション、Type、Address、Port、主要なトランスポート項目の順に比較します。認証情報はローカルで確認し、照合のために公開表へ書き出す必要はありません。2つのサブスクリプションが同じ接続先をそれぞれ管理している場合、ローカルの子項目を削除しても、次回更新時に再び表示されることがあります。

そのため、管理下の子項目を繰り返し削除するのではなく、まず該当するサブスクリプションを残す必要があるか判断してください。同じサブスクリプションを重複して登録している場合は、現在使用している関係をどちらの親項目が管理しているか確認し、バックアップを取ってから不要な親項目を削除します。テストで作成した独立項目の場合は、現在のルールや選択から参照されていないことを確認してから削除してください。一度にまとめて消さず、段階的に整理し、その都度アクセスを確認して依存関係を復元できなくなる事態を避けます。

一覧の並び順と通信の振り分けを混同しない

サーバー一覧の表示順は、主に項目を探しやすくするためのものです。項目を最上部に移動しても、すべてのリクエストがその項目を使うとは限りません。名前順に並べ替えても、自動的に優先順位やフェイルオーバーが設定されるわけではありません。実際のリクエスト先には、Global Routing、現在選択中のサーバー、Config内のルールとポリシーの参照も影響します。一覧を整理した後は、先頭の名前だけで接続経路を判断せず、これらの設定を確認してください。

カスタムConfigが特定の名前を参照している場合は、名前を変更する前に参照方法を確認してください。項目を明示的な名前で指定するConfigもあれば、フィルター式でまとめるConfigもあり、名前の変更が及ぼす影響は異なります。リモート更新で元の名前が変わる可能性もあります。名前の付け方とConfigの参照先が一致するように管理してください。名前を変更しても一覧に項目が残っているというだけで、すべてのルール参照が自動で同期されたと判断しないでください。

名前によるフィルターはできるだけ具体的にし、広すぎるキーワードで無関係な項目まで含めないようにします。リモート側の名前は固定されたものではありません。地域名、記号、番号などを使ったフィルターは、更新後に抽出結果を確認してください。候補が空になったり、想定以上に増えたりすると、サーバー自体に接続できてもポリシーの選択に影響する可能性があります。その場合は認証情報を何度も変更するのではなく、候補の集合と参照先を確認してください。

長期間使っていないサブスクリプションは、保持する必要があるかを検討し、整理前に必要な復元情報を保存してください。利用できない状態、一時的に接続できない状態、不要になった状態を混同しないようにします。最初の2つは障害の確認であり、不要になった状態は管理上の判断です。用途を確認してから削除すれば、一覧を整えるために使用中の予備情報を誤って消すことを防げます。

07 Connectivity Test：遅延、並べ替え、実際のアクセス

テストで確認できる範囲を把握する

Connectivity Testの結果は、テスト方法と合わせて判断してください。TCP系のテストでは主にサーバーのPortへの接続状況を確認し、HTTP系のテストでは指定した接続先やリクエストの処理も関係します。テスト方式が異なる結果をそのまま比較することはできません。Portが応答しても、認証、TLS、プロキシ転送、接続先のWebサイトがすべて正常とは限りません。テストが失敗した場合も、サーバーが恒久的に利用できないとは限りません。まず、どの段階で失敗したかを確認します。

テスト前にSettingsで、関連するテスト方式と接続先がどのように設定されているか確認してください。実際に表示される設定項目はアプリの画面に従ってください。複数のサーバーを比較する場合は、ネットワーク、接続先、テスト方式をできるだけ揃えます。モバイル通信とWi-Fi、時間帯、デバイスの電波状況は、結果に影響する場合があります。項目ごとに異なる条件でテストした場合、数値が揃って見えても信頼できる比較にはなりません。

1回のテスト結果で長期的な品質は判断できない

遅延は特定の条件下で測定した1回または複数回の往復時間であり、ダウンロード速度、継続的な転送速度、長時間接続の安定性を示すものではありません。最も小さい値が近距離の接続入口によるものでも、その後の接続先へのアクセスには経路や負荷など別の要因が関わります。テスト結果は候補の絞り込みに使い、実際の利用で確認してください。数値が最も小さい項目だけを残し、用途のあるほかの項目をすぐに削除することは避けます。

タイムアウトが発生した場合は、まず1、2件だけ再テストし、すべてのサブスクリプションで一括テストを繰り返すのは避けてください。大量の同時テストは接続リクエスト自体を増やし、現在のネットワークやリモート側の制限を受ける場合もあります。同じ時間にすべての項目が失敗する場合は、共通のネットワーク、テスト先、現在の設定を優先して確認します。特定の項目だけが継続して失敗する場合は、その項目のAddress、Port、認証、トランスポートを重点的に確認すると、原因を絞りやすくなります。

並べ替えは検索に、アクセスは確認に使う

遅延順に並べ替えた後は、表示されている結果が直前に測定した値か、未テストまたは失敗した項目が混ざっていないか確認します。状態によって並び順が異なる場合があるため、空欄を遅延ゼロと見なさないでください。並べ替えは項目の選択とは別です。並べ替え後に目的の項目を明示的に選び、システムの接続状態を確認してください。Configでポリシーグループを使っている場合は、グループ内の別項目に切り替わっておらず、実際のリクエストが対象の項目を通っているかも確認します。

1. ネットワークとテスト方式を固定し、対象サーバーをテストして異常の範囲を記録します。
2. 確認する項目を選び、対象への通信がDIRECTにならないようGlobal Routingと現在のConfigを確認します。
3. 接続を確立したら、通常利用する接続先にアクセスし、ホームページが表示されるかだけでなく、リクエストが正常に完了するか確認します。
4. 失敗した場合は正確なエラーを記録し、名前解決、接続確立、認証、TLS、接続先へのアクセスを個別に調べます。複数の項目を同時に変更しないでください。

テストに成功しても実際のアクセスが失敗する場合は、ルールによって接続先が別のポリシーに振り分けられていないか、DNSが想定したアドレスを返しているか、TLSが一致しているか、接続先自体が利用可能かを確認します。反対に、テスト先に接続できなくても実際の用途では問題なく使える場合、テスト条件が適切でない可能性があります。単一のテスト結果だけで実際の状況を否定しないでください。両方の結果を原因の切り分けに使い、どちらか一方だけを無理に正解としないようにします。

一時的な切り分けのためにGlobal Routingを変更した場合は、確認が終わったら普段の設定に戻してください。Proxyはプロキシ経由の経路を確認するのに役立ちますが、あらゆる問題を解決するものではありません。Directは直接接続との比較に使えますが、プロキシ経路の正常性を証明するものではありません。Configを使用する場合は、実際に一致したルールを確認してください。対象がREJECTで拒否されている場合、サーバーを変えても解決しないことがあります。ルールと誤一致を確認するには、REJECTポリシーとルールの適用範囲をご覧ください。

最後に残すべきなのは、用途が明確で、パラメーターを管理でき、実際の利用で要件を満たす項目です。特定の並べ替えで一時的に最上位になった名前だけを基準にしないでください。テストは調査範囲を絞るために使うもので、アカウント状態の確認やバックアップの代わりにはなりません。長期的に比較する際は、同じ方法を使い、対象を少数に絞ると、変化の原因を把握しやすくなります。

08 削除とバックアップ：対象に合わせて復元する

削除する対象を先に特定する

サーバー項目、Subscribeの親項目、Config、システムのVPN構成を削除すると、それぞれ異なる対象が処理されます。単体項目には接続パラメーター、サブスクリプションの親項目にはリモート更新との関係、Configにはルールなどの設定が含まれます。システムのVPN構成はデバイス上の許可と接続設定に関わります。操作前に対象の階層を確認してください。すべての削除を「最初からやり直す」ための操作と考えると、不要な情報を残したまま必要なルールを削除してしまう場合があります。

サブスクリプション管理下の子項目を削除しても、リモートから同じ情報が返されれば次回更新時に再び表示されることがあります。親項目を削除すると、管理下の項目も同時に削除される場合があります。具体的な範囲は、現在表示される確認メッセージを読んでください。どちらの場合も、ローカルで削除しただけではリモート側の利用権限は取り消されず、漏えいしたサブスクリプションURLも無効になりません。リモートのアカウントや認証情報は、ご自身のサービス提供元の手順で管理してください。

実際に必要な情報を含めてバックアップする

共有リンクを1件保存しても、通常は1件分の接続しか復元できません。サブスクリプションURLだけでは、ローカルで変更した名前、手入力の複製、ルールファイル、個別設定まで復元できない場合があります。バックアップ前に必要な範囲を列挙してください。サブスクリプションURL、重要な手入力項目、使用中のConfig、接続に必要な設定が含まれます。「バックアップ」という名前のファイルにすべてが含まれるとは限りません。現在のエクスポート機能の説明で対象範囲を確認してください。

アプリにバックアップやエクスポートの機能がある場合は、生成されるデータの内容、認証情報が含まれるか、復元時に既存データが上書きされるかを確認してください。情報を分けて保存する場合は、「ルール設定」「個人用サブスクリプションURL」「手入力のテスト項目」のように、用途と範囲を各ファイルに記載します。ファイル名に実際のサーバーパスワードを含める必要はありません。バックアップには機密性の高い認証情報が含まれる可能性があるため、アクセスを制限し、ご自身のデバイスのセキュリティ方針に従って保護してください。

一括上書きせず、小さな範囲で復元を確認する

1. まず現在のデバイスにある項目を残す必要があるか確認し、必要に応じて現状のバックアップを別途作成します。
2. 情報の種類に応じてサブスクリプション、手入力項目、Configを復元し、読み込み結果を確認します。同じ情報を複数のグループに重複して追加しないでください。
3. 現在選択中のサーバー、Global Routing、Config、関連設定を確認します。一覧に項目が表示されただけで復元完了と判断しないでください。
4. テストと実際のアクセスを確認してから重複項目や一時ファイルを整理し、対象範囲が明確な有効なバックアップを1つ残します。

デバイスを変更する場合は、アプリ本体とアプリ内データをそれぞれ確認してください。App Storeから購入済みのアプリを入手しても、すべてのサブスクリプションやローカル設定が想定どおりに復元されるとは限りません。デバイスデータと一緒に移行されるかは、実際の移行方法と復元結果をご確認ください。購入と購入済みアプリの復元については機種変更・再インストールの手順をご覧ください。開発者名はShadow Launch Technology Limited、製品ページのアプリIDは932747118です。

別のiPhoneまたはiPadに復元した後、システムからVPN構成の許可を再度求められる場合があります。古いデバイスで許可済みでも、新しいデバイスで許可された証拠にはなりません。また、サーバー側のデバイス数や同時接続数の制限も確認してください。リモート側の制限をバックアップの破損と取り違えないようにします。まずパラメーターが分かっている項目を1件使って確認し、その後でほかの情報を順に復元すると、デバイスの許可、データ移行、サーバー状態を切り分けやすくなります。

バックアップも定期的に管理してください。リモート側で認証情報が再設定された場合、アドレスが変更された場合、ローカルのルールを変更した場合は、古いバックアップが使えなくなることがあります。すべての確認が正常に完了した後で有効なバックアップを更新し、対象範囲を明記してください。内容を区別できない機密情報の複製を無制限に保存しないでください。また、新しいバックアップから復元できることを確認する前に、唯一の古いバックアップを急いで削除しないようにします。削除も保管も、復元できることを基準に判断してください。

このページで説明した管理の流れは、情報の入手元を明確にし、読み込み後に項目を確認し、更新前に現状を保ち、整理時に参照先を調べ、テスト後に実際のアクセスを検証し、削除前にバックアップを確認することです。具体的なエラーが残る場合はよくある質問から症状に応じて確認してください。初回接続をやり直す必要がある場合ははじめにに戻り、一つの手順に沿って段階的に確認します。サブスクリプションやConfigをすべて同時に作り直す必要はありません。