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

1. Subscribeの追加と初回読み込み

サブスクリプションは、リモートURLからサーバーの一覧を読み込み、その後の更新先として関連付けて管理するものです。個別のサーバー項目は接続先を1つ記述するもので、どちらも「追加」できるからといって混同しないでください。読み込む前に、受け取ったものがサブスクリプションURL、個別の共有リンク、完全な設定テキストのどれに当たるか確認します。Webページのタイトルやファイルの拡張子は手がかりにとどめ、用途はサービス提供元の説明で確認してください。

サブスクリプション・サーバー・設定の違い

サブスクリプションはサーバー一覧を管理し、サーバー項目は接続パラメータを保存します。Config（設定）はルールなどの設定内容を管理します。サブスクリプションの読み込みに成功しても、Config（設定）のルールが置き換わったとは限りません。設定ファイルを読み込んでも、サーバーの認証情報が揃ったことにはなりません。まず、今回変更する対象がどの階層なのかを明確にし、操作後はその対象だけを確認すると、パラメータ不足をルーティングの問題と取り違えにくくなります。

読み込みの前に、ご利用のサービス提供元から完全なサブスクリプションURLを入手してください。説明ページやログインページのURL、ブラウザーのアドレスバーに表示されたリダイレクト後のページを、そのままサブスクリプションURLとして使わないでください。URLには疑問符以降に認証情報が含まれる場合があるため、コピー時は末尾まで含めてください。チャットツール上で省略表示されていても、コピーした内容が完全とは限りません。保護されたローカルのテキストで先頭と末尾を確認し、改行が混入していないかも確認してください。

Add ServerでSubscribeを選択

1. Home（ホーム）を開き、追加ボタンからAdd Server（サーバーを追加）を開きます。
2. Type（タイプ）でSubscribe（サブスクリプション）を選択します。通常のプロトコルタイプにサブスクリプションURL全体を貼り付けないでください。
3. 完全なURLをURL（アドレス）欄に入力します。認証情報を含めず、見分けやすい名前を設定して保存してください。
4. リクエストと解析が完了するまで待ち、Home（ホーム）に戻ってサブスクリプションのグループと、その配下のサーバーが表示されているか確認します。

画面のレイアウトによって追加ボタンの位置は異なる場合がありますが、判断基準はTypeがSubscribe（サブスクリプション）に切り替わり、専用のサブスクリプション欄にURLが入力されていることです。保存前に、余分な引用符や空白、説明文が混じっていないか確認してください。「形式を修正する」ために疑問符以降のパラメータを削除したり、見た目を整える目的でURLを書き換えたりしないでください。

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

上の例は「URLとクエリパラメータ」の構造を示したものです。実際に使う際は、パス、パラメータ名、認証情報を受け取ったときの状態のまま保持してください。このURLは、サブスクリプションから返されるサーバーURLとは別のものです。前者は一覧の取得に使い、後者が接続先になります。そのため、サブスクリプションの取得失敗とサーバーへの接続失敗は分けて確認し、一方のテストで他方を判断しないでください。

初回読み込み後の確認と失敗時の対応

読み込み後は、少なくとも3点を確認します。グループ名が正しいか、リストに想定した項目があるか、任意のサーバー項目のプロトコルとアドレスが妥当かを確認してください。サーバー数は明らかな異常を見つける目安にはなりますが、数だけでサブスクリプションの品質や接続状態を判断することはできません。まず1つの項目を選んで接続を確認し、その後にルールの調整が必要か判断してください。この段階では複数の自動接続オプションを同時に有効にせず、実際に使われている対象を特定しやすくしてください。

保存後にリストが空の場合は、まずエラーメッセージを残し、元のURLを確認してください。ログインページに戻る、認証情報が無効と表示される、解析できない本文が返る場合は、サブスクリプションの応答に関する問題です。項目が表示されているのに接続できない場合は、その後の接続に関する問題です。同じサブスクリプションを何度も追加して更新を試さないでください。重複したグループが増えるだけです。サブスクリプションの更新失敗・空リストの確認リストに沿って原因の階層を特定し、その後に再試行してください。

すでに別のサブスクリプションを利用している端末では、初回読み込みの前に、現在選択中のサーバーとルーティングの状態も記録しておきます。新しいサーバー一覧を追加することは、既存の一覧を削除する理由にはなりません。新しい一覧の確認が済んでから整理してください。読み込み結果が想定と異なっても、既存の状態に戻って確認でき、すべての設定を最初から作り直さずに済みます。

2. Add Serverの各項目を手入力してプロトコルを確認

手入力は、必要なパラメータがすべて揃っている場合、少数のサーバーだけ追加する場合、共有リンクから読み込んだ内容の違いを項目ごとに確認する場合に適しています。Add Server（サーバーを追加）を開き、正しいType（タイプ）を選んでから、そのタイプで表示される項目を入力してください。プロトコルを誤って選ぶと、同じ名前の項目でも意味が異なる場合があります。アドレスやパスワードを先に入力し、経験だけを頼りに後からタイプを切り替えるのは避けてください。

共通項目を正確に入力する

Address（アドレス）にはサーバーのドメイン名または指定されたアドレスを入力します。サブスクリプションURLや、ログイン用パスを含むWebページのURLではありません。Port（ポート）はサーバー側の待ち受けポートです。TLSを有効にしたからといって、特定の値になるとは限りません。Remarks（備考）は端末内で見分けるためのもので、認証には使われません。手入力の前に元のパラメータと画面を並べて確認し、特に数字の0と英字、半角記号、コピー時に付いた空白に注意してください。

上の表は項目の種類を説明するもので、すべてのプロトコルに同じ選択肢が表示されるという意味ではありません。項目が表示されない場合は、別の似た名前の欄に入力するのではなく、Typeと転送方式を確認してください。サービス提供元から案内されていないパラメータは、必要性を確認するまで、Web上の一般的な例で補って「完成したように見える」設定を作らないでください。

認証・転送・TLSを分けて入力する

Shadowsocksでは暗号化方式とパスワード、VMessではUUIDと明示されている関連オプション、VLESSではUUID・転送方式・セキュリティ設定、TrojanではパスワードとTLS関連のパラメータを確認します。名前が似ていても相互に置き換えられるとは限りません。VMessとVLESSの項目の違いは、まず手入力項目の比較ガイドで確認してから、個々のパラメータを照合してください。

転送方式とプロトコルタイプは別の階層です。たとえばWebSocketを使う場合、Host（ホスト）とPath（パス）の両方が必要なことがあります。パスのスラッシュ、大文字・小文字、クエリ部分は元の値を保ってください。TLSのServer Name（サーバー名）は関連する名前の検証に使われ、Address（アドレス）とは異なる場合があります。接続先、転送リクエストのホスト情報、証明書名にはそれぞれ別の役割があるため、どれもドメイン名に見えるからといって一律に書き換えないでください。

証明書エラーが発生しても、検証をスキップすることを通常の解決策にしないでください。まず端末の時刻、証明書名、サービス提供元の要件を確認し、パラメータが書き換わっていないか調べます。サーバー側の証明書設定が原因なら、クライアント側でパスワードを何度も変更しても解決しません。トラブルシューティングでは、単に「接続できない」と記録するより、どの段階でエラーが出たかを記録すると、無関係な項目を試し続けずに済みます。

特殊なプロトコルと保存後の確認

WireGuardでは鍵、ピア情報、アドレス、ルーティングパラメータを一組として扱います。「アドレスとパスワード」のように単純化できません。Hysteria2にはUDPベースの転送条件も関わるため、一般的な接続テスト1回ですべての要件を確認することはできません。これらのプロトコルは、受け取った完全なパラメータ説明に従って入力してください。明確な根拠がないまま、速度向上を狙って帯域幅、ルーティング、基礎的な転送オプションを変更しないでください。

保存後、追加した項目を開き直し、Type、アドレス、ポート、転送オプションが元の内容と一致しているか確認します。パスワード欄は伏せて表示される場合があります。スクリーンショットを撮るために機密情報をすべて表示しないでください。共有リンクから読み込んだ項目がある場合は、項目の対応関係を比べる参考にできますが、読み込み結果が正しいとは限りません。最終的には、サーバーから提供された完全なパラメータを基準にしてください。

手入力の誤りを調べる際は、一度に変更する項目を1つにし、変更前の値を記録して、変更後は同じ方法で検証してください。アドレス、ポート、TLS設定を続けて変更すると、接続が戻っても原因を特定できません。解決したら、必要な差分を非公開の記録に残し、用途を備考に記入してください。リストのスクリーンショットから漏れるおそれがあるため、パスワード、UUID、完全な鍵を備考に記載しないでください。

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

QRコードとクリップボードは、テキストをクライアントに渡す方法が異なるだけで、テキスト自体の用途は変わりません。QRコードには個別のサーバー共有リンクやサブスクリプションURLを含められます。クリップボードにもURL、設定の一部、複数行のテキストが含まれる場合があります。読み込む前に、追加したい対象が1項目なのか複数項目なのかを確認し、認識結果に応じて処理してください。認識できたことを、正しい対象が追加されたことと取り違えないようにします。

QRコードを読み取る前に内容を確認

Scan QR Code（QRコードをスキャン）を使う際は、QRコード全体が読み取り範囲に入り、輪郭が鮮明に見えるようにしてください。反射や過度な拡大は避けます。システムからカメラの許可を求められた場合は、今回のスキャンに必要かどうかを判断してください。以前に拒否した場合は、システムの該当する権限設定を確認します。カメラの許可はスキャン機能に関するもので、VPN構成の許可に代わるものではなく、接続可能かどうかを示すものでもありません。

QRコードが別の端末に表示されている場合は、そのままスキャンできます。現在使用中の端末に写真として保存されている場合は、スキャン画面に画像認識機能が実際に用意されているときに使ってください。その項目がない場合は、サービス提供元から提供された元のテキストを使います。画面を何度も撮影したり、出所の分からない変換ページを使ったりしないでください。QRコード画像には認証情報が含まれる場合があるため、保存、送信、表示の際は機密情報として扱ってください。

認識後は結果の概要を確認します。Add Server（サーバーを追加）が開くのか、Subscribe（サブスクリプション）URLとして認識されたのか、アドレスと備考が想定どおりか、無関係なページへの移動を求められていないかを確認してください。想定と異なる対象が表示された場合はキャンセルし、元の説明を確認します。デコードできたことは、画像内の文字を読み取れたという意味にすぎず、現在の読み込み方法に適した内容とは限りません。

クリップボードの内容が完全か確認

共有テキストをコピーしたら、クライアントに実際に用意されているクリップボードからの読み込み機能を使います。システムからペーストの許可を求められた場合は、今回の操作に対して許可してください。コピーの完了と貼り付けの成功は別の段階です。後からコピーした内容でクリップボードが上書きされたり、実際のリンクではなく表示用のタイトルだけが保存されたりすることがあります。読み込みが反応しない場合は、すぐにクライアントを再インストールするのではなく、まずクリップボードの内容の種類を確認してください。

複数行のテキストは、境界部分で問題が起きやすくなります。共有リンクは通常、全体を欠けずに保つ必要があります。また、画面上の自動折り返しと実際の改行文字は別物です。コピーした内容に説明文、箇条書きの番号、引用符が含まれている場合は、明確なリンク本体だけを取り出します。内容が設定全体を読み込むためのものなら、段落を勝手に削除しないでください。対象によって整え方は異なるため、すべてのテキストに同じ削除ルールを適用しないでください。

1. 元の説明を確認し、サブスクリプション、個別の共有リンク、設定のどれに当たるかを見分けます。
2. 説明文を一緒にコピーしないよう、対象のテキスト全体をコピーします。
3. 内容に合った読み込み方法を使い、認識結果を確認してから保存します。
4. リストに戻り、追加された対象を確認して、既存の項目が重複していないか確認します。

認識の失敗と権限の問題は分けて対処

QRコードの読み取りに失敗しても元のテキストを読み込める場合は、まず画像の鮮明さとQRコード全体が写っているかを確認します。元のテキストも認識されない場合は、リンクのプレフィックス、文字の欠落、プロトコルの対応状況を確認してください。QRコードの隅を切り取って読み取りを続けないでください。余白や位置検出のパターンも認識に使われます。画像の条件またはテキストの内容を一度に1つだけ変え、どの段階が変化したか判断できるようにしてください。

貼り付け機能で内容を読み取れない場合は、まずシステムの許可が済んでいるか、コピー後にクリップボードの内容を書き換える操作をしていないか確認します。認識はできても保存後に失敗する場合は、権限ではなくパラメータと応答を確認してください。権限の確認は「読み取れるか」、パラメータの確認は「読み取った内容を使えるか」を判断するものです。別々に確認してください。

読み込みが終わったら、一般的な文字列をコピーして現在のクリップボードを上書きすると、後で誤って貼り付ける可能性を減らせます。ただし、すべての履歴や別の端末にあるコピーを削除できるわけではありません。一時画像、チャットの添付ファイル、ほかの端末にあるコピーは、それぞれ別に管理してください。内容が公開された場合、クリップボードを消去してもアクセスを取り消せません。認証情報の対処方法をサービス提供元に確認し、古い認証情報の状態を検証してください。

4. 共有リンクの形式と設定構文の違い

共有リンクはサーバーのパラメータをテキストにエンコードし、読み込み機能がその内容を対応する項目に割り当てます。プロトコルごとに構造が異なるため、文字列が長く見えるからといって内部形式が同じとは限りません。問題を調べるときは、まずプレフィックス、次に本文とパラメータを確認します。すべてのリンクを一律にデコード、再エンコード、記号置換すると、元の有効な内容を壊すおそれがあります。

長さではなく構造を確認する

vless://[email protected]:443?security=tls&type=ws&host=example.com&path=%2Fws#Example

これは項目の構造を説明するための例です。プレフィックスはVLESSを示し、ユーザー情報の位置には例示用UUID、ドメイン名とポートには接続先、疑問符以降にはセキュリティと転送のパラメータ、シャープ記号以降には通常表示用の備考が入ります。ここにある値は架空のもので、認証情報としては使えません。構造を理解すれば不足項目の特定に役立ちますが、任意のサーバー情報を組み合わせて使えるリンクを作れるわけではありません。

例の%2Fは、エンコードされたスラッシュを表します。リンクの受け渡しでは、文字が区切り文字と誤認されないようにエンコードが必要な場合があります。一方、Add Server（サーバーを追加）の個別項目には、通常、対応する実際の値が表示されます。リンク全体のパラメータをPath欄にそのまま貼り付けたり、正しくデコードされた値を再度デコードしたりしないでください。確認する際は、リンクの見た目が似ているかだけでなく、最終的な各項目を見てください。

プレフィックスによって読み取り方が異なる

Shadowsocksの共有形式では認証情報がエンコードされている場合があります。一般的なVMess形式では、内部項目を確認するためにエンコード内容の解析が必要です。TrojanとVLESSは見た目が似ている場合がありますが、認証項目とセキュリティ要件は異なります。プレフィックスだけを置き換えて、あるプロトコルを別のプロトコルに変換することはできません。認識できない内容を受け取った場合は、元の形式とクライアントの対応状況を確認し、変換方法を推測しないでください。

サブスクリプションURLは通常、サーバー一覧を取得するために使います。通常のWeb URLのように見えることもありますが、応答内容はクライアントが認識できるサブスクリプション形式でなければなりません。安全な接続で始まるURLだからといって、必ずサブスクリプションが返るとは限りません。ログインページやエラーページが正常に返される場合もあります。読み込み結果とエラー情報をあわせて判断し、形式を尋ねるためにリクエストURL全体を公開しないでください。

共有リンクはConfigのルールテキストとは別

Config（設定）のルールは、トラフィックの照合方法とポリシーを記述するもので、個別サーバーの共有リンクではありません。以下の例は、特定のドメイン、アドレス範囲の順に照合し、最後にフォールバックルールでその他のトラフィックの処理を決める構成です。これは設定のルール部分にすぎず、単独で完全な設定の代わりにはなりません。また、PROXYという名前の接続先が自動的に用意されるわけでもありません。

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

ルールは上から順に照合され、先に一致したルールが適用されます。後ろに自分の想定に近いルールがあっても、選び直されることはありません。PROXYとDIRECTはポリシーのキーワードなので、日本語に書き換えないでください。設定内でポリシーが何を参照しているか、現在どのサーバーを選択しているか、Global Routing（グローバルルーティング）がどの状態かを、それぞれ確認する必要があります。リストの読み込み成功で解決するのは、そのうちの一部だけです。

「サーバーの応答は確認できるが、特定のWebページへの通信先がおかしい」場合は、共有リンクを作り直すのではなく、どの設定とルールが使われているかを確認してください。REJECTに関する問題は、REJECTルールと照合範囲をご覧ください。リンクの解析とルールの照合を分けて調べることで、有効な認証情報を無関係に変更せずに済みます。

元のリンクを保存する場合は、個別サーバー用かサブスクリプション用か、その用途と入手経路もあわせて記録してください。備考だけを頼りにしないでください。同じ備考を使えますし、更新で変わることもあります。2つのリンクを比較する場合は、できるだけ端末内で差分を確認し、結論を記録する前に機密情報を隠してください。元のテキストを通常のメモとして共有しないでください。

5. サブスクリプションの更新と失敗時の復旧

サブスクリプションの更新では、元のURLに再度リクエストし、返された内容に基づいて、そのサブスクリプションに関連付けられたサーバー一覧を変更します。クライアント全体の再読み込みでも、App Storeのアプリ更新でもありません。まず、更新したい対象がサーバー一覧、Config（設定）の内容、アプリ本体のどれかを確認し、それぞれの操作に進んでください。更新時期も失敗の原因も異なります。

更新前に比較できる状態を残す

手動更新の前に、現在のサブスクリプション名、選択中の項目、リストのおおまかな構成を記録します。その中のサーバーを使用中の場合は、更新で項目が削除または改名され、元の選択が同じ対象を指さなくなる可能性にも注意してください。重要な操作の前に必要な情報を非公開で保存しておくと、更新失敗後に記憶を頼りに再構築するより確実です。ただし、項目の全情報が見えないリストのスクリーンショットだけをバックアップにしないでください。

更新は既存のサブスクリプションに対して行います。毎回同じURL（アドレス）を追加し直す必要はありません。更新後はエラーメッセージ、項目の変化、現在の選択を確認し、画面に一瞬表示される更新アニメーションだけで判断しないでください。リストが同じに見えても、リモート側の内容に変更がなかった可能性があります。それだけでリクエストの失敗とは判断できません。反対に項目数が変わっても、すべてのパラメータが想定どおりとは限りません。

リクエスト・応答・解析の3段階で確認

第1段階では、現在のネットワーク、ドメイン名の解決、接続状態など、サブスクリプションURLにリクエストが到達するかを確認します。第2段階では、ログイン案内、アクセスエラー、認証情報の失効通知ではなく、想定した内容が返っているかを確認します。第3段階で初めて解析を調べます。内容が空か、形式に対応しているか、テキストが途中で切れていないかを確認してください。段階を分けると、「更新失敗」と表示されただけでサーバーのパスワードを変えるような対応を避けられます。通常、そのパスワードはサブスクリプションのリクエストには関与しません。

特定のネットワーク環境だけで失敗する場合は、可能であれば別の既存ネットワークでも確認し、エラーが発生する段階を比較してください。クエリパラメータにアクセス用認証情報が含まれる場合があるため、完全なサブスクリプションURLを公開テストツールに貼り付けないでください。ブラウザーに本文が表示されても、それはブラウザーがそのとき内容を取得できたことを示すだけです。クライアントのリクエストでも同じネットワーク条件、同じ応答形式になるとは限りません。

アカウント状態や認証情報に関するメッセージが表示された場合は、ご利用のサービス提供元から現在有効な情報を入手し、サブスクリプションURLを変更する必要があるか確認してください。クエリパラメータを削除したり、パスを短くしたり、大文字・小文字を変えたりして試さないでください。URLを変更する必要がある場合は、元のグループと現在の選択を記録してから変更し、新しいリストを確認した後で重複を整理します。元のURLが無効であることと、新しいURLが使えることは、それぞれ別に確認してください。

自動更新は実行状況を確認できる形で使う

設定にサブスクリプションの自動更新オプションがある場合は、まず実行条件を確認し、必要に応じて有効にしてください。バックグラウンドでの実行は端末の状態やシステムのスケジュールに左右されるため、指定時刻どおりに必ず実行されるとは限りません。アプリを長期間開いていない場合、ネットワークを切り替えた場合、バックグラウンド処理が制限されている場合は、予定時刻から成功を推測せず、実際のリストと手動確認の結果を基準にしてください。

「常に最新に保つ」ために、何度も頻繁にリクエストする必要はありません。短い間隔で試すと前後の状態を比べにくくなり、リモート側のリクエスト制限に達する可能性もあります。問題を調べる際は、繰り返し操作をいったん止め、エラー情報を一度記録してから、確認後に結果を追跡できる形で再試行してください。復旧したら、項目を1つ選んで接続を確認し、更新で元の依存パラメータや選択関係が変わっていないか調べます。

更新後にリストが空になった場合は、整理や削除を続けず、まだ利用できる元の情報を保管してください。リモート側から空の内容が返された可能性も、形式や認証情報に問題がある可能性もあります。画面が空というだけでは判断できません。5項目の確認リストに沿って調べ、復旧してから更新前後の項目を比較してください。エラーの詳しい分類はよくある質問でも確認できます。

最後に、更新の理由、成功したか、リストに変化があったか、接続を再確認したかを簡単に記録します。認証情報を記録する必要はなく、固定の更新間隔を決めつける必要もありません。次回異常が起きた際に比較の起点を作ることが目的であり、あらゆる変化をクライアントの設定のせいにするための記録ではありません。

6. 複数サブスクリプションの整理とConfigの関係

複数のサブスクリプションを管理する際に大切なのは、すべての項目を1つの長いリストにまとめることではありません。入手元を区別し、現在の選択を明確にして、更新や削除の対象を追える状態にします。整理する前に、サブスクリプションで管理される項目と手動で追加した項目を分けてください。名前が同じでも同じグループとは限らず、URLが同じでも2つの記録が完全に同一とは限りません。

備考には用途を記録し、秘密情報は書かない

サブスクリプションの備考には、「普段使いA」「予備テストB」のように、自分で用途を見分けられる名前を付けると便利です。すべてのプロトコル項目を詰め込む必要はありません。パスワード、完全なサブスクリプションURL、認証情報は記載しないでください。サーバーの表示名はリモート側で決まり、更新で変わることがあります。ローカルの管理記録では、項目名だけでなく、どのサブスクリプションに属するか、何に使うかを記録してください。

重複項目は、同じものを複数回読み込んだ場合、手動の項目とサブスクリプション由来の項目を両方残した場合、異なるグループに同じ接続先が含まれている場合などに発生します。重複かどうかを判断する際は、少なくともプロトコル、アドレス、ポート、認証情報、転送設定を比較してください。2つの項目は、パスまたは証明書名の一部だけが違っていて、それが接続可否を左右する場合もあります。リスト上の名前が同じというだけでまとめて削除したり、見た目を整えるためにリモート側のパラメータを書き換えたりしないでください。

手動の項目を残す場合は用途を明記し、元のサブスクリプションに連動して更新されないことも記録してください。重複したサブスクリプションを整理する場合は、有効な更新URLを持つグループ、現在の選択が属するグループ、もう一方に独自の項目が含まれていないかを確認します。確認後に不要な対象を削除し、次回更新後に再確認してください。重複項目が一時的に隠れただけで、実際には解消していない可能性があります。

サーバー一覧とGlobal Routingは別々に管理

Global Routing（グローバルルーティング）は、トラフィック全体をどのような方針で処理するかを決めるもので、サブスクリプションの管理に代わるものではありません。サブスクリプションを追加しても、その項目が自動的に接続先になったり、ルールが書き換わったりするわけではありません。問題を調べる際は、まずルーティングの状態、次に選択中のサーバーと設定、最後に個別ルールを確認してください。これらを混同すると、「サブスクリプションを切り替えたのに変化がない」と誤認しやすくなります。

表が示すのはルーティングの状態であり、システム上のすべての通信が必ずそのとおりになるという保証ではありません。実際の処理はシステムや関連設定にも左右されます。Direct（直結）の状態でアクセスできても、新しく読み込んだサーバーが使えるとは限りません。Config（設定）の状態で、対象のルールにDIRECTが指定されている場合も、そのアクセスをプロキシ接続のテストとして扱えません。確認の際は、実際にどのポリシーで通信しているかを把握してください。

Configの参照先と自動接続も確認

Config内でサーバーやポリシーグループを名前で参照している場合、更新で名前が変わると参照関係を確認し直す必要があります。新しい項目が、古い名前の用途を自動的に引き継ぐとは限りません。Configを編集する前にバックアップし、参照先、ルールの順序、フォールバックポリシーを確認してください。一度に変更するのは1か所にし、Configとサブスクリプションを同時に入れ替えて結果を比較できなくならないようにします。

On Demand（オンデマンド接続）は、システムの条件に応じて接続を開始する設定であり、サブスクリプションの更新機能ではありません。整理や切り替えの際に接続が自動的に再開した場合は、リストの保存失敗と決めつけず、この機能が有効かも確認してください。再現可能なテストを行う際は、自動接続の状態を明確にし、テスト後は元の設定に戻します。日常使用時とは異なる動作が残らないようにしてください。

整理は、名前を付け、所属を確認し、現在の選択を検証してから、本当に不要な対象を削除する順に進めます。各段階が終わるごとにHome（ホーム）へ戻って結果を確認してください。あるグループに問題があっても、該当するグループだけを対処でき、1回の整理で手動記録やConfigの参照先をすべて損なわずに済みます。

複数の端末で使う場合も、用途の説明は統一すると便利ですが、リスト、選択、Configが同期済みとは限りません。iPhoneとiPadで同じ状態を再現する必要がある場合は、各端末でサブスクリプション、現在の項目、ルーティングの状態を確認してください。システム要件と対応端末はApp Storeのページに記載された情報をご確認ください。入手方法はiPadでのダウンロードと初回起動をご覧ください。

7. Connectivity Testによる遅延テストと並べ替え

Connectivity Test（接続テスト）の結果は、特定の条件下で特定のテスト方法を使った結果にすぎません。すべてのWebサイト、すべてのプロトコルの通信、継続的なデータ転送が正常であることを示すものではありません。テスト前に対象、方法、使用中のネットワークを確認し、テスト後は実際のアクセスも検証してください。リストの数値は候補を絞り込む参考にはなりますが、長期的な安定性や通信速度を保証するものではありません。

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

接続先が応答すれば、ネットワーク経路の一部に到達できる可能性が示されます。プロキシ経由でリクエストを完了するには、認証、暗号化、転送、接続先へのアクセスも関係します。テスト方法によって確認できる範囲が異なるため、あるテストの成功を別の条件にも当てはめないでください。テスト画面で方法を選択できる場合は、まず現在の方法を確認し、同じ方法で同じグループの項目を比較します。異なる条件の結果を一度の並べ替えに混在させないでください。

ある項目がタイムアウトしても、すぐに削除する必要はありません。接続先が一時的に応答しない、現在のネットワークで該当する転送が制限されている、名前解決に失敗した、テストのリクエストが実際の利用状況を反映していない、といった可能性があります。まず同じネットワークで状態が分かっている項目を再テストし、比較対象にしてください。特定のプロトコルだけで失敗するかも確認します。共通する条件が分かってから、Add Server（サーバーを追加）で各項目を確認してください。

再現できる比較手順を作る

1. 現在のネットワークとGlobal Routing（グローバルルーティング）の状態を記録し、リストを同時に更新していないことを確認します。
2. 比較する項目を同じテスト方法で確認し、テスト中にネットワークを切り替えないでください。
3. 異常な結果は再テストし、最良の1回だけでなく、継続して発生するかを確認します。
4. 項目を1つ選んで接続し、実際のタスクで名前解決とアクセスの結果を確認します。

比較の際は、できるだけ条件を絞ってください。大量のデータをダウンロードしながら、数値の変化をサーバーのせいにしないでください。また、Wi-Fiとモバイル通信を切り替えた後に、同じ比較表の結果をそのまま使わないでください。数値は時間帯、混雑、接続先によって変わります。単独の数値を保存するより、テスト条件を記録するほうが役立ちます。トラブルシューティングのテストでは、最小値を追うのではなく、結果を説明できることを重視してください。

Hysteria2のようにUDPが関わるプロトコルでは、一般的な接続応答だけで転送条件を確認しきれません。異なる転送方式を使う項目は、単純な同一テストだけで優劣を判断できません。プロトコルの設計と適用範囲については、Hysteria2とQUICの基礎をご覧ください。管理上の判断は、プロトコル名から先入観で決めず、実際の用途と繰り返し確認した結果に基づいてください。

並べ替えで変わるのは表示順

テスト結果による並べ替え機能がある場合は、現在のグループだけが対象か、すべての項目が対象かを確認します。並べ替え後は選択中のマークを再確認し、リストの先頭が現在の接続先だと思い込まないでください。サブスクリプションを再度更新すると、リストの順序や表示名が変わることもあります。普段の使用では「前回一番上だった項目」という記憶に頼らず、対象を明示的に選んでください。

数値が低い場合、そのテストがより短時間で完了したことを示すにすぎません。大容量ファイルの転送が速いことや、長時間の接続が安定することを意味するものではありません。特定のタスクを行う場合は、まず実際にアクセスできることを確認し、その後に中断が続くかを観察してください。項目を頻繁に切り替えると、経路と接続状態が同時に変わって原因を特定しにくくなります。候補を少数に絞って1つずつ確認するほうが、全項目を何度も並べ替えるより確かな判断につながります。

遅延テストは正常なのにWebページが開かない

まず、テストした項目が実際に選択されているか、Global Routing（グローバルルーティング）がテスト目的に合っているか、対象の通信がConfig（設定）で別のポリシーに一致していないかを確認します。次に、ドメイン名の解決失敗、接続タイムアウト、証明書エラーを切り分けてください。エラーが起きた段階によって対処方法は異なります。リストに数値が表示されているからといって、DNSやルールの確認を省き、すべての認証情報を入れ直さないでください。

ドメイン名でのアクセスだけに失敗する場合は、DNS設定とWebページが開かない場合の確認手順に沿って確認してください。ただし、一時的にIPアドレスでアクセスできたことを長期的な解決策とみなさないでください。証明書、接続先の振り分け、アプリのリクエストが引き続きドメイン名に依存する場合があります。すべての実際のアクセスに失敗する場合は、プロトコル、転送方式、ネットワーク条件を順に確認し、根拠なくルーティングルールを何度も切り替えないでください。

問題をほかの人に説明する際は、テスト方法、発生条件、エラーの段階、実施済みの確認事項を伝えます。アドレスと認証情報を隠しても、「サブスクリプションは更新できる、項目のテストも通る、特定の種類のアクセスだけ失敗する」という経過は説明できます。遅延の数値だけが写ったスクリーンショットより、原因を絞り込みやすくなります。

8. 削除・バックアップ・再読み込み後の確認

削除前に、対象の階層を確認してください。サーバーを1つ削除する、サブスクリプションのグループを削除する、Config（設定）を削除する、アプリを削除する操作は、それぞれ別です。確認画面に表示された対象と範囲を確かめてから続行してください。「すぐに追加し直せる」ことはバックアップの代わりにはなりません。リモートURLが使えなくなる可能性もあり、手動変更した内容がサブスクリプションから再取得できるとは限りません。

復元したい状態に合わせてバックアップ

サーバー一覧だけを復元する場合でも、有効なサブスクリプションURLまたは完全なサーバーパラメータが必要です。ルールの動作を復元するには、現在使用しているConfigと関連する参照先も必要です。手動変更を復元するには、元の値、変更後の値、変更理由を記録してください。リストのスクリーンショットは名前の確認には役立ちますが、復元に必要な項目の代わりにはなりません。バックアップを作る前に復元したい状態を明確にし、それに必要な情報を集めてください。ファイルが揃っているように見えるだけでは十分ではありません。

クライアントに対象ごとの書き出し機能や共有機能がある場合は、まず書き出し範囲を確認し、自分で管理できる保護された場所に保存してください。サーバーの書き出しにルールが含まれるとは限らず、Configの書き出しにもローカル設定がすべて含まれるとは限りません。含まれるか判断できない設定は、現在のConfig名、Global Routing（グローバルルーティング）の状態、On Demand（オンデマンド接続）が有効かどうかなど、必要な状態を別途記録してください。

バックアップには完全なアクセス認証情報が含まれる場合があるため、閲覧できる人を制限し、公開メモ、共有アルバム、公開添付ファイルに保存しないでください。サブスクリプションURLだけでも秘密情報として扱います。ファイル名や備考には用途を記載し、パスワードを直接含めないでください。バックアップを更新したら、保存先とアクセス権を確認します。元のファイルを保護していても、一時コピーが別の場所に残っている場合があります。

削除前に参照先と現在の選択を確認

サーバーを1つ削除する場合は、まずサブスクリプション管理下の項目かどうかを確認してください。サブスクリプション管理下にある場合は、次回の更新で再び追加される可能性があります。サブスクリプション全体を削除する場合は、現在の接続先、独自の手動変更、Configからの参照が含まれていないか確認します。削除すれば関連する参照も自動修正されるとは限りません。削除後もリストとConfigをそれぞれ確認してください。

あるグループを一時的に使わないだけなら、削除する必要があるか先に判断してください。用途が分かる備考と有効なバックアップを残したほうが、すぐに消去するより元に戻しやすい場合があります。実際に削除する際は対象を1つずつ処理し、範囲が確認できていない状態で続けて一括操作しないでください。想定外の結果が出たら、後続の整理をすぐに止め、保存した情報を使って復元します。復元可能な問題を、すべての設定を失う事態に広げないでください。

再読み込みだけでは復元完了にならない

1. まずサブスクリプションまたは手動サーバーを復元し、Type、アドレス、転送項目を確認します。
2. 次に必要なConfig（設定）を復元し、ポリシーの参照先とルールの順序を確認します。
3. Global Routing（グローバルルーティング）の状態を確認し、有効な項目を1つ明示的に選択します。
4. 接続テストと実際のアクセスを確認し、最後に自動接続関連の設定を元に戻します。

この順序なら、各段階の結果を個別に確認できます。自動接続を先に有効にしてからConfigとサブスクリプションをまとめて読み込むと、作業中に接続状態が変わり、エラーの原因を特定しにくくなります。復元中は元のバックアップを残し、最初の読み込みに成功しただけで上書きしないでください。普段のタスクが正常に動くことを確認してから、新しい有効状態を次回の復元用として別に保存します。

機種変更時やアプリを再入手する場合、App Storeの購入済み記録はアプリを再入手するためのものであり、サブスクリプション、サーバー、ルールがすべて復元されるとは限りません。アプリの入手とデータの復元は別の操作です。購入条件と対応端末はApp Storeのページに記載された情報をご確認ください。まず購入済みアプリの復元についてを読み、ご自身のバックアップから内容を復元してください。確認されていない同期を前提にしないでください。

認証情報が変わった場合の古いコピーの扱い

リンクや認証情報の変更後に再読み込みを行う場合は、新しい内容が実際に有効になったことを確認し、古い項目が別のグループに残っていないか調べてください。ローカルのコピーを削除してもリモートの認証情報は無効になりません。また、リモートの認証情報が無効になっても、すべてのバックアップが自動的に削除されるわけではありません。それぞれ別に対処してください。アクセスの有効性はサービス提供元に確認し、ローカルのコピーは復元後に保管の必要性に応じて整理します。

最後に3点を確認します。現在の接続先を明確に見分けられるか、使用中のConfigとルーティングの状態が想定どおりか、バックアップに復元に必要な情報が揃っているかを確認してください。一時的なクリップボードの内容、QRコード画像、不要になった書き出しデータも整理しますが、有効なバックアップを誤って削除しないよう注意してください。管理の目的はリストを最短にすることではなく、次回の更新、トラブル対応、復元で確認の起点を明確にすることです。

整理が終わったら、入門ガイドに戻り、基本手順に沿ってもう一度確認できます。それでも問題がある場合は、よくある質問で「読み込み」「更新」「接続」の該当する段階を確認してください。すでに検証した事実と未確認の条件を記録し、正しいと分かっている設定を繰り返し変更しないようにします。