Shadowrocket
サブスクリプションとサーバー
管理ガイド

01 / 入力内容の種類を確認

Subscribe：既存のサブスクリプションを読み込む

サブスクリプションリンクは、更新可能なサーバー一覧を取得するためのもので、個別サーバーの接続先アドレスとは異なります。読み込み後、Shadowrocketがリンクにアクセスして内容を取得・解析し、サーバー項目を作成します。一覧の名前や件数、接続パラメータが変更された場合は、再度更新すると端末に反映されます。操作を始める前に、手元にあるものが完全なサブスクリプションURLであることを確認してください。アカウントページや説明ページのURL、単一サーバーの共有テキストとは異なります。

リンクの用途と機密情報を確認する

利用中のサービスから、自分が使っているサブスクリプションリンクを取得し、元のテキストをそのまま保管してください。チャットアプリで再整形したり、長い末尾パラメータを不要と判断して削除したりしないでください。?以降の内容が利用者の識別に使われる場合があり、パス自体にアクセス情報が含まれることもあります。どこかで開けるURLでも、クライアントが読み込めるサーバー一覧とは限りません。ログインページが表示された場合はリンクの用途を確認し、アカウントのパスワードをサーバーのPassword欄に入力しないでください。

以下はURLの形式を示す例であり、実際の接続には使用できません。ドメイン名やパラメータはすべて架空です。実際のリンクは自分の端末と管理下のバックアップだけに保管し、問い合わせ用のスクリーンショットや公開メモ、共有アルバムには載せないでください。一部を隠しても、アクセスの手がかりが漏れる可能性があります。

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

Add ServerからSubscribeを開く

Homeの追加メニューを開き、Add Serverに進んでTypeを確認します。Subscribeを選択し、完全なサブスクリプションURLをURL欄に入力してください。用途を判別できる名前を付け、URLの先頭と末尾に空白や改行がないことを確認して保存します。画面構成は端末やアプリの状態によって異なる場合があります。操作場所を探すときは、ボタンの位置ではなくTypeやSubscribeの英語表記を目印にしてください。

保存後にHomeへ戻り、サブスクリプションのグループとサーバー項目を確認します。名前が表示されただけでは読み込み成功とはいえません。選択可能なサーバー項目が実際に作成されているかを確認してください。サブスクリプションだけが表示されて項目がない場合は、まずネットワークからURLにアクセスできるか、次に応答が認識可能な形式かを確認します。同じURLをすぐに何度も追加すると、失敗したリクエストが重複グループになることがあります。

一覧の更新と実際の接続を分けて確認

一覧を取得できたことが示すのは、サブスクリプションへのリクエストと内容の解析が完了したことだけで、各サーバーへの接続が保証されるわけではありません。反対に、更新に失敗しても、端末に保存済みのサーバーが使える場合があります。確認時は「サブスクリプションを更新できるか」と「既存の項目に接続できるか」を分けて記録し、一方の結果で他方を判断しないでください。サーバーを選択したうえで、Global Routingと接続スイッチも確認します。初回接続の手順ははじめにをご覧ください。

同じURLをすでに読み込んでいる場合は、新しく追加するのではなく、既存のサブスクリプションを更新してください。登録元が明確になり、その後の変更が一覧の更新によるものか判断しやすくなります。項目がサブスクリプション由来か手動追加か分からない場合は、所属グループと編集情報を確認してから変更方法を決めてください。サブスクリプション項目をローカルで編集しても、次回更新で上書きされる可能性があります。

02 / 各項目の整合性を確認

Add Server：サーバーパラメータを手動入力

手動追加は、必要なサーバーパラメータがそろっていて、項目ごとに確認しながら入力する場合に適しています。まずTypeを選び、その種類に必要な項目を入力してください。プロトコルの種類によってサーバーとの通信方法が決まるため、項目が少ないという理由だけで別の種類に変更してはいけません。Address、Port、Passwordはよく使われる項目ですが、種類によっては識別子、暗号化方式、トランスポートパラメータ、TLS関連の設定も必要です。いずれかが欠けていると接続に失敗することがあります。

Typeを確認してから基本項目を入力

Homeの追加メニューを開き、Add ServerでTypeを実際のサーバーが使用するプロトコルに設定します。次に、元の情報を見ながらAddressとPortを入力してください。Addressには通常、ホスト名またはIPアドレスを入力します。ウェブページのパス、ユーザー名、余分な空白は含めないでください。Portは独立した数値です。コロンの後のポート番号をAddressにも重複して入力しないでください。項目で完全なURLを明示的に求められていない限り、共有リンク全体をホストアドレスとして入力しないでください。

Passwordには現在のサーバーに対応する値を入力してください。アプリ購入時のアカウントパスワードで代用することはできません。コピーした値を確認する場合は、第三者に見られない場所で先頭・末尾の文字や大文字・小文字を確認してください。公開スクリーンショットで照合しないでください。UUIDなどの識別情報を使うプロトコルでは、対応する項目に入力し、すべての認証情報をPassword欄にまとめないでください。名前は識別用で、認証には使われません。名前を変更しても認証情報の誤りは直りません。

プロトコルのパラメータは置き換えできない

Shadowsocksの暗号化方式はサーバーの設定と一致させる必要があります。VMessやVLESSなどの識別情報とトランスポート設定は、元の情報に照らして確認してください。Trojanの認証やTLS設定も、プロトコル名だけでは判断できません。HTTP、SOCKS5、WireGuard、Hysteria2はそれぞれ異なるパラメータ構成を持ちます。すべてに使える共通の初期値はありません。あるサーバーで使える組み合わせが、別のサーバーにも適合するとは限らないためです。元の情報に項目が不足している場合は、情報をそろえてから続けてください。

サーバーでTLSが必要な場合は、接続先と証明書検証に使う名前を区別してください。接続先はAddressで指定しますが、関連する名前の項目はTLSハンドシェイクに使われる場合があります。この2つは同じとは限りません。トランスポート層のHostやPathにもそれぞれ用途があり、文字列が似ているからといって置き換えないでください。証明書関連のエラーが出た場合は、検証を緩めて入力ミスを隠すのではなく、端末の時刻、ホスト名、元の設定を確認してください。

保存後に一度に1項目ずつ検証

項目を保存したらHomeに戻り、名前の似た古い項目ではなく、追加したサーバーが選択されていることを確認してください。まず接続テストを行い、接続中に、もともと利用権限のある接続先へアクセスします。失敗した場合は一度に1つのパラメータだけ変更し、変更前後の結果を記録してください。プロトコル、ポート、トランスポート設定を同時に変更すると、成功しても本当の原因が分かりにくくなり、次に設定を戻すときに同じ問題が起こりかねません。

サブスクリプションの項目を長期的に手入力で修正し続けるのは避けましょう。特定のパラメータを比較したい場合は、機能上可能であることを確認したうえで、用途を明記した独立のテスト項目を作成してください。サブスクリプション内の元の項目と混同しないようにします。検証後は、正しい元のパラメータを記録として保管してください。アプリの入手や初回VPN構成の許可についてはiPhoneでの入手方法をご覧ください。システムの許可に関する問題をサーバー項目の問題と混同しないようにしましょう。

03 / 内容を確認してから保存

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

QRコードやクリップボードを使うと手入力を減らせますが、サーバーが現在のネットワークに適しているかを自動で判断したり、元の情報に不足するパラメータを補ったりするものではありません。どちらの方法でも、まず自分が利用するサーバーまたはサブスクリプションの情報であることを確認し、解析結果と重要な項目を照合して保存し、その後にテストしてください。「認識された」ことを「設定が正しい」ことと同一視せず、QRコードの読み込みに成功しただけで既存の記録を上書きしないでください。

Scan QR Codeの手順

利用中のサーバーまたはサブスクリプションに対応するQRコードを用意し、ShadowrocketでScan QR Codeを開きます。システムの案内に従ってカメラへのアクセスを許可してください。QRコード全体を読み取り範囲に入れ、反射や遮蔽、小さすぎる表示を避けます。読み取り後に表示される内容を確認します。単一サーバーとして解析された場合はType、Address、Portを、サブスクリプションとして解析された場合はURLと名前を確認してください。元の情報と一致することを確かめてから保存します。

QRコードが不鮮明な場合は、鮮明な元画像または元のテキストを入手してください。何度も拡大・縮小して切り抜くのは避けましょう。画像の圧縮で読み取りに必要な細部が損なわれたり、画面の明るさ不足や反射が読み取りを妨げたりすることがあります。QRコードが同じ端末にある場合は、現在の画面に画像を読み込む操作があるか確認してください。該当する操作がなければ、内容確認を省略してQRコードを読み取ろうとせず、元のテキストから読み込めます。

クリップボードには対象のテキストだけをコピー

コピーする際は共有内容全体だけを選択し、説明文、チャットの時刻、番号、文末の句読点などを一緒に含めないでください。Shadowrocketに戻り、画面に表示されるクリップボードからの読み込み操作を使います。システムの案内に従って貼り付けを許可してください。プレビューが表示された場合は、サブスクリプションかサーバーかを確認し、項目を照合します。貼り付けの許可を求める表示はクリップボードへのアクセス管理であり、サーバーへの接続要求でもVPN接続の成立を示すものでもありません。

複数行のテキストをコピーした場合、1件のリンクとは異なる結果になることがあります。初回はまず1件だけ読み込み、形式が正しく認識されることを確認してから残りを処理してください。読み込み後の項目数がおかしい場合は、元のテキストに重複リンクやタイトルが含まれていないか、URLが途中で改行されていないか確認します。何度も貼り付けを繰り返さないでください。繰り返し操作しても似た項目が増えるだけで、元データの形式の問題は解決しません。

権限・読み取り・接続のエラーを切り分ける

カメラが開かない場合は、まず端末でShadowrocketにカメラの使用を許可しているか確認します。カメラは起動するが読み取れない場合は、QRコードの鮮明さと内容の形式を確認してください。読み取りに成功しても接続できない場合は、サーバーパラメータとネットワークを確認します。この3段階の問題はそれぞれ異なります。クリップボードも同様です。貼り付けを拒否されてテキストを読み取れない場合は権限の問題、読み取れても項目が作成されない場合は解析の問題、保存後のテストに失敗した場合は接続の問題です。

読み込みが終わったら、機密情報を含まない普通のテキストをクリップボードにコピーし、後で誤って貼り付ける可能性を減らしましょう。QRコードをスクリーンショットで共有したことがある場合は、画像が共有アルバムや自動同期される公開領域に入っていないかも確認してください。画像を削除しても認証情報が無効になるわけではありません。内容が外部に漏れたと分かった場合は、元のサービスの管理方法に従って該当する認証情報を変更し、端末上の記録も更新してください。

QRコードなど、どの方法で読み込んでも、最後は同じ手順で確認します。グループ、種類、接続先を見てから項目を選択し、テストしてください。画面を開いたばかりで操作に慣れていない場合は、Homeの各エリアの説明も参考になります。読み込み方法の問題と、Homeで別のサーバーを選んでしまう問題を切り分けやすくなり、名前が似た別の項目をテストすることも防げます。

04 / リンクの見た目だけで設定を判断しない

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

サーバーの共有リンクは、サーバーパラメータを転送できるテキストにまとめたものです。サブスクリプションURLは、内容が継続的に変わる可能性のある一覧を指します。Configはルールや関連設定を記述します。いずれもリンクで共有されることがありますが、用途は異なります。読み込む前に「この内容は単一のサーバー、一覧、Configのどれか」を確認し、適切な入口を選んでください。特定の文字列で始まることやブラウザで開けることだけでは、どの項目に入力すべきか判断できません。

構造を見分け、認証情報を推測して組み立てない

サーバーの共有情報は、ss://、vmess://、vless://、trojan://などで始まる場合があります。接頭辞からプロトコルを見分けられますが、その後の情報がすべて平文とは限りません。エンコードされたデータを使う形式や、アドレスとクエリパラメータで表す形式、表示名を付ける形式があります。まずアプリに元データを解析させてから各項目を確認してください。見た目を頼りに「だいたい同じ」リンクを組み立てないでください。

エンコードされたテキストだからといって、機密性があるわけではありません。読み込み可能な内容には通常、接続に必要な情報が含まれ、受け取った人がそのパラメータを読み取れることもあります。共有するときは普通のブックマークではなく、機密情報として扱ってください。QRコードは同じ内容を別の形で表したもので、アクセス範囲は変わりません。リンクをQRコードにしても、漏えいした場合の影響は小さくなりません。

エンコード・改行・名前の違い

リンク内のパーセントエンコードは特殊文字を表すためのもので、読みやすくするために安易に書き換えないでください。プラス、スラッシュ、等号などの文字は形式によって異なる意味を持つことがあります。チャットツールが挿入した空白や改行で、内容を正しく解析できなくなる場合もあります。読み込み結果に項目が不足している場合は、まず元テキストの先頭・末尾と長さが保たれているか、不要な日本語の句読点が混ざっていないか確認してください。サーバーパスワードを変更して直そうとするのは避けましょう。

形式によっては、#以降の部分に表示名が含まれますが、この方法を使うかどうかは形式ごとに異なります。名前に地域名が書かれていても、実際のサーバー所在地が確認されたわけではなく、接続品質が保証されるわけでもありません。名前だけを変更しても接続先は通常変わりませんが、共有テキストを手動編集すると別のパラメータを誤って変更する可能性があります。日常的な整理はアプリ内で名前を変更し、接続パラメータを扱う場合は元の情報を照合してください。

ルールファイルでサーバー情報を代用しない

Configのルールは通信の処理方法を決めるもので、誤ったサーバーパラメータを使える状態にするものではありません。以下はShadowrocketのConfigでよく見られるルールの例です。マッチング順とポリシーの意味を説明するためのもので、個人の設定にそのまま置き換えられる完全なファイルではありません。実際に使用する前に、必要なポリシーが現在のConfigで有効かを確認し、DNSやサーバーなどの設定も目的に合っているか確認してください。

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

1行目はドメインのサフィックス、2行目は接続先IPの条件で一致を判定し、最後の行はそれまでのルールに一致しなかった通信を処理します。ルールは上から順に評価されるため、最後の行だけを見てすべてのリクエストが選択中のサーバーを経由すると判断しないでください。ルールの動作を確認するには、Global RoutingでConfigを選び、現在読み込まれているConfigと照らし合わせます。ProxyまたはDirectを選択している場合は、同じルールを前提に経路を判断できません。

そのため、サーバーの読み込み後に一部の接続先だけが不安定な場合は、同じ共有リンクを何度も読み込み直すのではなく、Configの振り分けも確認してください。反対に、Configを切り替えても認証エラーは解消しません。画面上の用語が分かりにくい場合は、Home、Config、Proxy、Directの違いをご覧ください。入力形式、サーバー接続、ルーティングポリシーを別々に確認すると、効果のない試行を減らせます。

05 / 更新の前後で状態を確認

サブスクリプションの更新方法と失敗時の確認

サブスクリプションの更新は一覧を再取得して項目を同期する操作です。Shadowrocketアプリのアップデートでも、利用中のサービス期間の延長でもありません。アプリのアップデートはApp Storeで管理され、サブスクリプションの更新は保存済みURLと応答内容によって決まります。安定して更新するには、まず手動更新が成功することを確認してから自動化を検討してください。URLの確認が済んでいない段階で、何度もリクエストを実行するのは避けましょう。

まず手動更新で状態を確認

Homeで更新するサブスクリプションを見つけ、その項目に対応する更新操作を実行します。実行前にグループ名、現在選択中のサーバー、残しておきたいローカルの名前を記録してください。完了後、項目が想定どおり変わったか確認します。画面表示は変更される場合があるため、スワイプの方向やアイコンの位置ではなく、サブスクリプションに対応する操作項目を基準にしてください。複数のサブスクリプションがある場合は、まず1つだけ更新して結果を確認してから、残りを処理します。

更新が完了しても、現在選択中の項目が引き続き有効とは限りません。同じ名前でパラメータが異なる項目に置き換わる場合や、選択中のサーバーが一覧から削除される場合があります。更新後に選択状態を確認し、接続テストを行ってください。項目に大きな変化があった場合は、以前の記録と現在の応答を照らし合わせます。サーバーのメンテナンスや一覧の変更による妥当な差異まで、すぐにエラーと決めつけないでください。

自動更新には確認できる前提が必要

現在の画面に起動時の自動更新などの設定がある場合は、項目の説明を読んでから有効にするか決めてください。自動更新は実行条件とその時点のネットワークに依存します。アプリが常に同期を続けるという意味ではありません。端末がネットワークに接続されていない、URLに一時的にアクセスできない、応答を解析できない場合、アプリを開いても一覧が更新されるとは限りません。判断基準はスイッチの状態ではなく、更新結果と実際の項目です。

特定の項目を安定して使う必要がある場合は、接続を使う直前に大規模な整理を行うのではなく、結果をすぐ確認できる時間に更新してください。テストに成功したサブスクリプションは無理のない頻度で更新し、失敗が続くものは原因を確認しましょう。何度も再試行するだけでは解決になりません。自動更新はバックアップの代わりにもなりません。誤った内容や予期しない変更も、ローカルに同期される可能性があります。

リクエスト・応答・解析の順に確認

まず端末自体がネットワークに正常に接続できるか確認し、必要なら異なるネットワーク環境でも試します。次にURLが完全か、変更されていないか、認証情報が有効かを確認してください。最後に、応答内容がクライアントで対応しているサブスクリプション形式か確認します。アカウントのログインページ、アクセス案内、エラー文は、リクエストに応答があってもサーバー一覧とは限りません。そのような内容をAdd Serverのアドレス欄に読み込まないでください。

サブスクリプションURLへのアクセス経路とサーバーへの接続経路は異なる場合があります。そのため、「現在のサーバーが使える」からといって、更新リクエストも必ず成功するとは限りません。経路に問題があると思われる場合は、設定をすぐに消去せず、現在のGlobal Routingとネットワーク環境を確認しながら1項目ずつ検証してください。問題を調べている間も使えるローカル項目を残しておくと、現在の状態を保ちやすくなります。データが破損していてバックアップもあると確認できた場合に限り、サブスクリプションの再作成を検討してください。

詳しい手順はサブスクリプションの手動・自動更新と失敗時の確認方法をご覧ください。問題を記録するときは、グループ名、操作した時間帯、ネットワークの種類、エラーの状況だけを書き、実際のURLは記載しないでください。この情報で、一時的なネットワークの問題と継続的な形式の問題を見分けやすくなり、次回更新時の比較にも役立ちます。

06 / 数より登録元を明確に

複数サブスクリプションのグループ分け・命名・重複整理

複数のサブスクリプションを管理する際は、サーバーを長いリストにまとめるのではなく、各項目の登録元、管理方法、復元方法をいつでも把握できる状態にします。サブスクリプションのグループと手動追加項目を区別し、用途が分かる名前を付け、選択状態を明確にして誤操作を防いでください。整理前にバックアップを取り、まず1つのグループだけを変更して、現在の接続に影響がないことを確認してから進めましょう。

名前を2段階で付け、認証情報を名前に含めない

サブスクリプション名は一覧を区別し、サーバー名は一覧内の項目を区別します。サブスクリプション名には「日常用」「予備テスト」など用途を設定できます。サーバー名は更新後も識別できるよう、元の情報が分かる部分をなるべく残してください。完全なサブスクリプションURL、パスワード、識別情報を名前に含めないでください。名前はHomeやスクリーンショット、共有プレビューに表示されることが多く、機密情報の保存には適していません。

同じサブスクリプションを複数の端末で使う場合、グループ名を統一することはできますが、端末間で内容が同期されているとは限りません。各端末で取得した一覧の時期が異なる場合があり、選択中のサーバーやローカルの名前も異なることがあります。差異がある場合は、別端末の設定をそのまま上書きする前に、URLと更新結果を照合して整理が必要か判断してください。

同じ名前でも重複とは限らない

重複かどうかは名前だけでなく、接続パラメータを比較して判断します。同じ名前でもホスト、ポート、トランスポート方式が異なる場合があります。名前が違っていても、同じパラメータを示すことがあります。少なくともType、Address、Port、必要なトランスポート設定を確認してください。認証情報も識別に関わりますが、比較する場合は第三者に見られない環境で行い、平文の認証情報一覧を公開用に作成しないでください。

同じサブスクリプションを重複して読み込み、グループが2つできた場合は、正常に更新できる方を残し、明らかに重複している方を削除するのが基本です。異なるサブスクリプションにある似たサーバーは、更新元や管理状態が異なることがあるため、安易にまとめないでください。登録元を残しておけば、後から項目名が変わったり、使えなくなったり、削除されたりした理由を確認できます。同じ名前の項目を一括削除するより、グループごとに整理して確認しましょう。

表示順と選択中の項目を区別する

並べ替えで変わるのは項目の探しやすさであり、接続先として選択中のサーバーとは限りません。項目をリストの先頭に移動した後も、実際に選択されているか確認してください。テスト結果順に並べても、アプリが最上位の項目へ自動的に切り替わるとは限りません。整理後は選択状態を確認し、実際に接続してテストします。複数のグループに似た名前がある場合は、目的のグループを開いてから選択し、古い項目を選ばないよう注意してください。

画面で並び順を変更できる場合は、よく確認するグループを見つけやすい位置に置き、必要に応じて元の記録も参照できるようにしてください。見た目を整えるために、サブスクリプション内のすべての項目名を頻繁に変更するのは避けましょう。更新で項目が再作成されることがあります。長期間残したいメモは、用途、サブスクリプション、確認が必要な項目を記した個人用の管理メモに保存してください。更新後も名前が残ることを前提にしないでください。

テスト用と日常用の項目を分ける

問題の切り分け用に手動で複製した項目には、テスト用と分かる名前を付けてください。確認後は削除するか残すかを決め、数週間後にどの項目がサブスクリプション管理下なのか分からなくなるのを防ぎます。独立した複製には、元のサブスクリプションの後日の変更は自動反映されません。元と同じ名前でも、古い設定のままになることがあります。日常利用と一時的な検証を分けると、「サブスクリプションは更新済みだが古い複製を選んでいた」という状況を防げます。

整理が終わったら、各グループを更新できるか、よく使うサーバーを選択できるか、テスト用の項目を処理したかを確認します。詳しい整理手順は複数サブスクリプションのグループ分け・並べ替え・重複サーバーの整理をご覧ください。項目の消失や重複など、具体的な問題についてはよくある質問から症状に合った内容を確認できます。

07 / 数値だけで分かるのは経路の一部

Connectivity Test・遅延・並べ替え

Connectivity Testは、現在のテスト条件におけるサーバーの応答を確認するための機能です。これだけで実際の使い心地全体が分かるわけではありません。遅延が小さければ、特定のテストが短時間で完了したことを示しますが、通信速度が高い、長時間安定する、すべての接続先にアクセスできるという意味ではありません。まずテスト条件をそろえて既存のサーバーを比較し、実際の用途で確かめてください。1回の結果を長期的な結論にしないことが大切です。

テスト前にネットワークと方法をそろえる

まず端末が安定したネットワークに接続されていることを確認し、テスト中にWi-Fiとモバイル通信を切り替えないようにしてください。現在のテスト設定と接続先を確認し、同じ比較では同じ方法を使います。テスト方法が異なれば数値の意味も異なります。接続の確立を中心に測るものもあれば、アプリケーション層の応答まで含むものもあります。異なる方法で測った値を一緒に並べたり、別の端末や時間帯の値を現在の結果と置き換えたりしないでください。

HomeでConnectivity Testを実行したら、まず明らかに応答しない項目を確認し、使用可能な候補は複数回テストします。偶然1回だけ非常に小さな値が出るより、何度か安定した結果の方が参考になります。テスト中に端末で大量のネットワーク通信が行われていると、結果に影響する場合があります。まず他の通信による影響を減らし、差がサーバーによるものか、端末側の帯域競合によるものかを見分けてください。

タイムアウト・変動・実際のアクセスを分けて確認

タイムアウトは、現在のテストが想定時間内に結果を得られなかったことを示します。それだけでサーバーが恒久的に利用できないとは判断できません。端末のネットワーク切断、テスト先へのアクセス不可、サーバー認証の失敗、中継経路の問題などが考えられます。まず正常と分かっているネットワーク接続と比較し、その後サーバーパラメータとテスト設定を確認してください。すべての項目が同時に失敗する場合は、共通の条件を先に調べ、サーバーごとにパスワードを変更しないでください。

一部の項目だけが失敗し、ほかは正常な場合は、失敗した項目のアドレス、ポート、プロトコル設定を確認してください。Connectivity Testに成功しても実際の接続先にアクセスできない場合は、Global Routing、現在のConfig、接続先の状態を調べます。テスト先と実際の利用先が異なり、ルールの経路も異なる可能性があるため、遅延テストを繰り返すだけでは原因を特定できないことがあります。

ルーティングモードを確認してから結果を判断

Configでは、接続先ごとに適用されるポリシーが異なる場合があります。ウェブページを開けたからといって、そのリクエストが選択中のサーバーを経由したとは限りません。問題の切り分けでProxyに切り替える場合は、元のモードを記録し、確認後に戻してください。Directは端末のネットワークから直接アクセスする状況を把握するのに役立ちますが、サーバー自体のテストには代用できません。比較結果には、実施時のモードも記録してください。

並べ替えで候補を絞り、実際の用途で確認

遅延順に並べ替えたら、比較的安定した候補から1つ選び、権限のあるウェブページへのアクセスや通常のデータ転送など、実際に必要な作業を試してください。最初の応答、継続中の通信、中断後の再接続が用途に合うかを確認します。一度に多くの異なる内容をテストすると、接続先のサイト、端末のネットワーク、サーバーそれぞれの影響を切り分けにくくなります。長時間の安定性は、実際に使いながら確認してください。

地域名は整理には役立ちますが、品質を保証するものではありません。地理的な距離以外にも、通信経路、混雑、サーバー負荷、接続先の位置が使い心地に影響します。リストの最小値だけを追うより、検証済みの候補を少数残す方が実用的です。テスト結果は時間とともに変わるため、並び順を永久的な結論と考えず、ネットワーク環境が変わった場合は同じ方法で再比較してください。

テスト後は最終的に選択されている項目を確認し、検証済みで利用可能な代替候補を少なくとも1つ残してください。整理のためにほかの記録をすべて削除するのは避けましょう。テスト値と実際の使い心地の違いは、遅延・地域・プロトコルの選び方をご覧ください。接続許可や初回認証の確認が必要な場合は、最初の接続手順に戻り、すべての問題を遅延のせいにしないでください。

08 / 復元できることを確認してから削除

削除・バックアップ・復元の確認

削除する前に対象を区別してください。サーバー1件、サブスクリプション全体、Config、アプリ本体は、それぞれ別のデータです。項目を1件削除するとローカルの一覧だけに影響する場合がありますが、サブスクリプションを削除すると管理対象のグループ全体に影響する場合があります。確認画面の説明を一字ずつ読んでください。安全な手順は、復元に必要な情報を保存し、バックアップを読み取れることを確かめてから削除することです。「後で思い出せる」はバックアップになりません。

データの種類ごとに復元用の情報を用意

サブスクリプションは、完全な元のURLと用途の説明を保管してください。手動サーバーは必要なパラメータをすべて保存し、Configは現在使用している内容と関連情報を残します。サブスクリプションURLから最新の一覧を再取得できても、過去の名前、並び順、ローカルでの変更までは復元できないことがあります。Configファイルに手動入力したすべてのサーバー情報が含まれるとも限りません。ルールファイルを1つ保存しただけで全データをバックアップできたと考えないでください。

現在の画面に書き出しやバックアップの機能がある場合は、対象範囲を確認してから生成内容を自分で管理する安全な場所に保存してください。書き出し操作に認証情報、サブスクリプション、ローカルの選択状態、アプリ設定がすべて含まれるとは限りません。書き出した後は、ファイルが実際に保存されたか、再度読み取れるか、内容を判別できる名前かを確認します。保存先にアクセスできない、または内容が空の場合、バックアップとして有効ではありません。

サブスクリプションを削除する前に関連項目を確認

削除対象の項目が現在の接続に使われているかを確認し、削除する前に検証済みの別項目へ切り替えるか、接続を終了してください。Configで特定のポリシーやサーバーを名前で参照している場合は、その参照が削除後も有効か確認します。リストから削除できても、ルールが自動的に代わりの接続先を見つけるとは限りません。削除後はHomeの選択状態と実際の接続を確認し、名前だけ残って接続先が無効になった設定関係を放置しないでください。

重複項目だけを削除したい場合は、明らかに重複しているグループを優先し、ほかの設定まで一緒に消さないでください。サブスクリプション内の項目をローカルで削除しても、一覧に残っていれば次回更新時に再び表示されることがあります。表示上の重複を長期的に減らしたい場合は、繰り返し削除するのではなく、現在の画面で利用できる整理機能を確認してください。サブスクリプションの内容管理とローカル一覧の整理は分けて考えましょう。

復元は最小範囲から始める

端末を買い替えたり再設定したりした場合は、まずApp Storeからアプリの購入を復元し、その後に個人のサブスクリプションとConfigを復元します。購入記録とサーバーデータは別のものです。アプリを入手できても、既存のサブスクリプション、パラメータ、名前が必ず戻るとは限りません。購入済み項目と利用条件は端末の買い替えと購入済みアプリの復元方法をご覧ください。iPhone・iPadのシステム要件と購入条件はApp Storeの掲載内容をご確認ください。

個人データを復元するときは、まずサブスクリプション1件または手動サーバー1件だけを読み込み、解析結果を照合して接続テストを行います。その後、Configやほかのグループを順に追加してください。最初からすべての設定を上書きすると、サーバー情報の期限切れ、Configの参照切れ、端末設定の違いのどれが原因か判断しにくくなります。復元後は名前、並び順、選択状態も確認します。「ファイルを開けた」だけでは完了とみなさないでください。

バックアップへのアクセスを制限し、定期的に確認

サーバーパスワードやサブスクリプションの認証情報を含むファイルは、管理された安全な場所に保管し、公開の共有フォルダには置かないでください。バックアップを読める人は、元の共有リンクと同程度のアクセス権を得る可能性があります。問題を相談する際は必要な構成だけを伝え、URLの機密パラメータ、認証情報、QRコードを削除してください。バックアップの漏えいが確認された場合、ファイルの削除だけでは不十分です。影響を受けた認証情報を変更し、安全なバックアップを作り直してください。

日常の管理は、決まった手順で進めると安心です。まずバックアップを取り、その後に更新します。先に項目を照合してからテストし、代替項目を確認してから削除してください。一度に扱う問題は1つに絞り、変更内容は簡潔な個人用メモに残します。復元経路を明確にでき、次回のトラブル時にも何が変わったか確認しやすくなります。初回接続の手順ははじめにをご覧ください。症状別の確認方法はよくある質問を参照してください。