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

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

サブスクリプションURLからは複数のサーバー情報を取得でき、クライアントは後から同じURLにアクセスして、追加・削除・パラメータ変更を反映できます。サーバー情報は個々の接続先を表し、通常はプロトコル、アドレス、ポート、認証情報を含みます。Configは設定やルールなどを管理します。同じサービスの案内に記載されていても、それぞれ用途は異なります。ConfigのURLをサーバーのサブスクリプション欄に入力しても、利用可能な一覧を取得できるとは限りません。

操作を始める前に、手元の情報が完全なサブスクリプションリンクか確認してください。アカウントページや案内ページのURL、個別サーバーの共有リンクとは異なります。リンクはサービス提供元から入手し、案内されているShadowrocket用の形式を選んでください。一般的なファイル拡張子で終わるかどうかだけで種類を判断しないでください。動的なURLを使うサブスクリプションもあり、解析結果を決めるのは応答内容です。

Add ServerでSubscribeを選択する

Homeを開き、Add ServerからTypeでSubscribeを選び、URLに完全なリンクを入力します。用途や入手元がわかる名前を付けてください。アカウント情報を含む長いメモは避けましょう。画面のレイアウトは端末やアプリの表示状態によって異なる場合があります。表示されている項目を確認し、Typeが単一サーバー用のプロトコルではなくSubscribeになっていることを確かめてください。

貼り付けた後、リンクの先頭から末尾まで確認します。プロトコル部分、ドメイン、パス、疑問符以降のパラメータをすべて残し、末尾に日本語の句点、引用符、改行が混ざっていないことを確認してください。メッセージアプリでは長いリンクが複数行に折り返されて表示されることがありますが、見た目の折り返しだけで原文が変わるとは限りません。一方、手作業で分割してコピーすると途中が抜けることがあります。スクリーンショットを見ながら入力するのではなく、元のリンクをそのままコピーしてください。

1. TypeがSubscribe、URLが完全なサブスクリプションリンクになっていることを確認します。
2. 保存してHomeに戻り、該当するサブスクリプションまたはサーバーグループが表示されることを確認します。
3. 読み込みが完了するまで待ち、名前が表示されたかだけでなく、サーバーが想定したサブスクリプションに属しているか確認します。
4. サーバー情報を1件開いて項目を確認してから、接続とテストに進みます。

読み込みが完了したか確認する

登録情報の保存、サブスクリプションへのリクエスト、応答内容の解析、サーバー一覧の生成は、それぞれ別の段階です。入口が保存できても、リモートの内容を取得できたとは限りません。サブスクリプション名だけが表示され、サーバーがない場合は、更新が完了したかを確認してから、応答が空か、解析できない形式かを調べてください。同じURLを繰り返し追加すると入口が複数残り、どれを更新しているのか判別しにくくなるため避けましょう。

一覧が初めて表示されたら、サーバー情報を1件確認し、Type、Address、Port、認証項目が手元の情報と一致するかを調べます。名前は通常、説明のための文字列であり、パラメータの確認には代用できません。読み込まれたサーバー数が案内と異なっても、すぐにクライアントが情報を失ったと判断しないでください。リモートのサブスクリプションは、アカウントの状態や利用範囲に応じて異なる内容を返すことがあります。URLとアカウントの状態を確認し、返されるはずの情報をサービス提供元に問い合わせてください。

サブスクリプションを読み込めているのに特定のサーバーへ接続できない場合は、パラメータとテストの章を確認してください。サブスクリプションを作り直す必要はありません。サーバーが1件も生成されない場合は、リンクの完全性、リクエスト結果、内容の形式の順に確認します。異なる段階の問題として記録すると、まだ読み込めていない一覧に対して接続を繰り返し試すことを避けられます。

この章では、リモートの一覧を端末に登録する方法を扱います。更新のタイミング、更新によってローカルの編集内容が上書きされるか、一覧が空のときに何を残すべきかについては更新方法をご覧ください。接続の流れを一通り確認する場合は、クイックスタートに戻ってください。

接続先と表示名を分けて考える

手動追加は、必要なパラメータがそろっていて、サーバー情報を1件登録したい場合に適しています。HomeからAdd Serverを開き、最初にTypeを選択してください。プロトコルによって表示される項目は異なるため、すべて入力してから種類を変更するのは避けましょう。Typeを切り替えた後は、認証情報とトランスポートの項目をもう一度確認してください。項目が消えたり、以前の入力内容が別の意味として扱われたりすることがあります。

Addressにはサーバーのアドレスとして、通常はドメイン名またはIPアドレスを入力します。Portには資料に記載された接続ポートを入力してください。パスを含むウェブページのURLをAddressに貼り付けたり、アドレス末尾からポートを推測したりしないでください。表示名は一覧で見分けるためのもので、用途に合わせて付けられますが、名前にプロトコル名を含めてもTypeは変わりません。名前が正しくてもTypeが異なれば、期待した接続にはなりません。

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

Shadowsocksでは、資料に記載された暗号化方式とPasswordを確認します。VMessとVLESSではUUIDがよく使われますが、Typeだけを切り替えて他の設定をそのまま使えるわけではありません。TrojanではPasswordとTLS関連のパラメータを確認します。HTTPとSOCKS5では認証要件も異なります。項目の表示や必須条件は、選択したプロトコルと現在の画面に応じて確認してください。すべての種類に共通する入力表はありません。

TLS、SNI、Host、Pathはそれぞれ別の階層の項目です。Addressは接続先を指定し、SNIはTLS接続で使うサーバー名です。HostとPathは、選択したトランスポート方式のリクエストに関わる場合があります。同じドメイン名が使われることはありますが、必ず一致するわけではありません。元の資料に記載がない項目にAddressを機械的にコピーしたり、別サーバーの設定例を参考に値を補ったりしないでください。

証明書関連のエラーが出たら、まずシステム時刻、SNI、サーバー側の証明書設定を確認します。Allow Insecureは証明書の検証に関わる設定なので、通常の解決策として安易に有効化しないでください。証明書の検証に失敗した場合は、エラー表示を消すのではなく、失敗の原因を確認する必要があります。WireGuardやHysteria2などは対応するパラメータ一式を使い、PasswordやUUIDとの単純な対応に当てはめないでください。

保存後は変更を最小限にして原因を調べる

入力後は編集画面に戻り、もう一度確認してください。特に、Passwordの前後の空白、UUIDの文字抜け、Portの入力に注意します。入力方法によっては半角記号が全角に置き換わることがあり、手入力では間違いやすくなります。コピーできる場合は元の値をそのまま使ってください。誤りを見つけたら、一度に1項目だけ修正し、変更前後の状態を記録します。複数項目を同時に変更すると、原因を判断しにくくなります。

同じサーバーを共有リンクから読み込むと接続できるのに、手入力した記録では失敗する場合は、アドレスが無効だと決めつけず、2つの記録のType、認証、TLS、トランスポート層を並べて確認します。比較用に元の読み込み記録を残し、直接上書きしないでください。反対に、手入力では成功してサブスクリプションから生成された記録で失敗する場合は、サブスクリプションに古いパラメータが残っていないか確認します。

保存できたことが示すのは、入力項目が受け付けられたということだけです。認証やリモートサービスの検証に成功したとは限りません。次に記録を選び、Connectivity Testを実行してから、Global Routingと実際のアクセス結果を確認します。Trojanの項目についてはAddress、Port、Password、SNIの設定ガイドをご覧ください。特定のプロトコルの例を、他のプロトコルの標準設定として使わないでください。

スキャン前にQRコードの内容を確認する

QRコードには、単一サーバーの共有リンクやサブスクリプションURLを含められます。見た目だけでは内容の種類を判別できません。スキャンに成功したことは、画像内のテキストを認識できたという意味であり、URLにアクセスできることや、パラメータが有効であることを示すものではありません。QRコードを使う前に元の案内を確認し、サブスクリプションと個別サーバーのどちらかを見分けてから、Shadowrocketで表示されるScan QR Codeを使ってください。

カメラを初めて使うときは、システムからカメラの使用許可を求められる場合があります。用途を確認してから許可してください。以前に拒否した場合は、システム設定でShadowrocketのカメラ権限を確認できます。スキャン時はQRコード全体が枠内に入るようにし、端が切れたり、画面が反射したり、画像が過度に圧縮されたりしないようにします。長い内容を含むQRコードは模様が細かくなるため、カメラに何度も近づけるより、元画像を拡大する方が効果的なことがあります。

QRコードが現在使用中の端末に表示されている場合は、アプリで利用できる画像読み取り機能を使ってください。該当する機能が画面にない場合は、手元にある元のテキストリンクを使って読み込みます。認識できないからといって、QRコードを不明なウェブサイトにアップロードして解析したり、実際の認証情報を含む画像を公開用に作り直したりしないでください。元のQRコードは復元用に保管し、公開資料として広めないようにしましょう。

クリップボードには1件分の完全な内容をコピーする

クリップボードから読み込む場合は、まず元の資料から完全な内容を1件コピーし、Shadowrocketに戻って現在表示されているクリップボード読み込み操作を使います。システムでペーストの確認が表示されたら、直前にコピーした内容であることを確かめてください。以前コピーした内容をそのまま使うのは避けましょう。別のアプリでのコピーによって上書きされていることや、デバイス間のクリップボード同期で予期しない内容が入っていることがあります。

コピーする範囲はリンクだけにし、タイトル、番号、コードフェンス、チャットの引用記号を含めないでください。複数のリンクをまとめて読み込めるかは形式によります。確認しやすくするため、最初は1件ずつ読み込むことをおすすめします。読み込みのたびに一覧に追加された内容を確認してから次に進むと、重複や誤った記録を後から区別しやすくなります。

1. 元の資料に戻り、リンクをコピーするか、元のQRコードを表示します。
2. Scan QR Code、またはアプリで現在利用できるクリップボード読み込み操作を選びます。
3. 確認画面または編集画面でTypeを見分け、Address、Portなどの重要な項目を確認します。
4. 保存後、記録の登録先を確認してからテストします。読み込み完了の通知だけで判断しないでください。

クリップボードの内容を認識できない場合は、それがサブスクリプションURL、プロトコルの共有リンク、通常の説明文のどれなのかを確認してください。完全なサブスクリプションURLであれば、Add Serverに戻り、Subscribeを選んでURLを手動で貼り付けます。個別サーバーのリンクは対応するプロトコルとして処理してください。画面に入力を受け付けさせるために、すべてをSubscribeに変更してはいけません。受け渡し方法が違っても、内容の種類を見分ける必要があります。

読み込みの認識エラーと接続エラーは分けて対処する

スキャンしても反応しない場合は、まず画像の品質と権限を確認します。認識後に形式エラーが出る場合は、テキストの構造を確認します。サーバーが生成されたのに接続できない場合は、項目とネットワークの確認に進みます。この3つの状況を分けて説明すると、トラブルの切り分けが早くなります。たとえば「カメラに模様は映るが記録が作成されない」と「Trojanの記録は作成されたが認証に失敗する」では、確認する内容がまったく異なります。

読み込み後に同じ名前の記録が表示されても、すぐに片方を削除しないでください。異なるサブスクリプションから作成されたものか、Portやトランスポート方式が違うかを確認します。QRコードに付けられた名前は識別用のメモにすぎず、名前が同じでもパラメータが同じとは限りません。重複を確認できたら、入手元が明確で復元可能な記録を残し、このページの削除手順に沿って処理します。確認前にまとめて削除しないでください。

他の人に問題を説明する場合は、読み込み方法、認識されたType、エラーが起きた段階、確認済みの項目だけを伝え、内容全体は共有しないでください。読み込み後は、認証情報を含む内容をクリップボードに残さないよう、別の機密性のないテキストをコピーして置き換えます。情報が漏えいした疑いがある場合は、ローカルの記録名を変えるだけでなく、サービス提供元から新しい情報を入手してください。

プロトコルのプレフィックスで解析方法を見分ける

個別サーバーの共有リンクには、通常 ss://、vmess://、vless://、trojan:// などのプロトコルプレフィックスが含まれます。プレフィックスは解析方法の目安になります。その後に続く情報は、エンコードされた項目の場合もあれば、クエリパラメータ付きのアドレス形式の場合もあります。プレフィックスからおおよその種類は判断できますが、認証情報、TLS、トランスポート層がすべて正しいかどうかまでは確認できません。

共有リンクには、ユーザー情報、ホスト、ポート、クエリパラメータ、メモなどが含まれることがあります。プロトコルや生成方法によって構成が異なるため、どのリンクにも同じ分解方法を当てはめないでください。元の文字列を保持したままShadowrocketに解析させ、編集画面で項目を確認するのが確実です。テキストエディタで先に書き換えるのは避けましょう。

https://example.com/sub?token=xxxx
trojan://[email protected]:443?security=tls&sni=example.com#Example

上記はサブスクリプションURLと個別サーバーのリンク形式の違いを示すもので、すべて学習用のダミー情報です。実際の接続には使用できません。疑問符以降は通常クエリパラメータ、シャープ記号以降はメモとして使われますが、具体的なプロトコル形式を確認してください。リンク内のパーセントエンコードにも意味があります。読みやすくするために別の文字へ置き換えると、Password、パス、メモの内容が変わることがあります。

エンコードは暗号化ではなく、サブスクリプションはルールファイルではない

一部のリンクやサブスクリプションの応答では、Base64などのエンコードを使って内容を表現します。エンコードはデータの表記方法であり、認証情報を秘匿する暗号化ではありません。長い文字列がそのまま読めなくても、完全な認証情報として扱ってください。トラブルの確認で内容全体を公開のデコードツールに貼り付けないでください。コピーが完全か、応答が想定した種類か、アプリで正常に解析できるかを確認すれば十分です。

サブスクリプションの応答には、複数のサーバーリンクや対応する別の形式が含まれる場合があります。ブラウザで開いたとき、テキストとして表示されたり、ファイルの保存が始まったり、ログイン画面が表示されたりすることがあります。どの表示も、現在の入力欄に適した内容であることを単独では証明しません。実際の応答がログイン案内、エラー説明、ウェブページの場合、リクエストがリモートアドレスに届いていても、クライアントはサーバーを生成できないことがあります。

Config内のルール記述は別の種類の情報です。以下はShadowrocketの一般的なConfig構造を示し、ルールが [Rule] の下に記載されることを説明する例です。サーバーの認証情報は含まれておらず、SubscribeのURLの代わりにはなりません。既存のConfig構造を理解し、変更範囲を確認してから、ルールを自分のConfigに適用してください。

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

読み込み内容と実際のルーティングをつなげて確認する

サーバー情報は「どの接続先を使うか」を決め、Global Routingは「通信でどの接続方法を選ぶか」を決めます。Configモードでは現在の設定に従い、Proxyモードではプロキシ経由、Directモードでは直接接続します。サーバーを読み込んだ直後でもDirectのままなら、通信がそのサーバーを経由しないことは読み込み失敗を意味しません。テスト結果は現在のモードと合わせて判断し、一覧に選択マークがあるかだけで判断しないでください。

Configモードでは、ルールの順序と現在有効なConfigも重要です。例のDOMAIN-SUFFIXはドメインのサフィックスで一致を判定し、GEOIPはIPアドレスの割り当て情報を使い、FINALはそれ以前のルールに一致しない場合の最終ルールです。FINALの1行だけをコピーして、完全な振り分け設定ができたと考えないでください。また、例の一部をあらゆるネットワーク環境で使える設定として扱わないでください。

同じ資料にサブスクリプションとConfigの両方が記載されている場合は、それぞれの用途、更新方法、管理場所を確認してください。サーバー一覧を更新してもルールファイルが更新されるとは限りません。Configを切り替えてもサーバーのパラメータが置き換わるとは限りません。バックアップの説明にはそれぞれを分けて記録しておくと、「一覧は正常だが一部の通信経路が想定と違う」ときに適切な箇所から確認できます。

更新が必要なとき

サーバー側でアドレス、認証情報、利用範囲が変更されると、端末の一覧に古い情報が残ることがあります。その場合は該当するサブスクリプションを更新してください。更新の主な目的はリモートの一覧との同期であり、現在の接続速度を上げることではありません。一度アクセスがタイムアウトしただけなら、まず現在の記録とネットワークをテストしてください。すべてのサブスクリプションを更新し、Configを切り替え、接続を再起動すると、どの操作が結果に影響したのか分かりにくくなります。

アプリに用意されているサブスクリプション管理機能から、対象を更新し、そのグループの結果を確認します。現在の画面に更新間隔や自動更新の設定がある場合は、必要に応じて設定してください。アプリが常にバックグラウンドで動作するとは限りません。また、更新通知が見当たらないことを同期完了の証拠と考えないでください。重要な変更を確認する場合は、手動で更新して結果を調べる方が確実です。

更新前に、現在利用できるサーバーの名前と重要なパラメータを記録し、必要なら独立したバックアップを保存してください。サブスクリプションはリモート側で管理される一覧です。更新後にサーバー名が変わったり、削除されたり、パラメータが変わったりすることも同期結果の一部です。以前の記録を残せば比較に役立ちますが、引き続き利用できるかはリモートサービスの状態次第です。バックアップは有効期間を延ばすものではありません。

リクエスト、解析、利用の3段階で切り分ける

リクエスト段階で失敗した場合は、まず現在のネットワークが正常かを確認し、次にURLに余分な空白や欠落がないかを調べます。サブスクリプションURLのドメインを名前解決できないなら、内容を取得する前の段階で問題が起きています。サーバーのPasswordを繰り返し編集しても解決しません。既存の一覧もすぐに削除しないでください。記録を残しておくと、リモートの入口が一時的にアクセスできないのか、端末に保存済みのサーバーも使えないのかを比較できます。

解析段階で失敗したら、実際に何が返されたのか確認します。アカウントの期限切れやアクセス制限の案内、通常のウェブページが、サーバー一覧の代わりに返されることがあります。こうした内容からクライアントがサーバーを生成できなくても、適当なプロトコルに変更する必要はありません。アカウントの状態とURLの利用範囲を確認し、サービス提供元から正しいサブスクリプション情報を入手してください。

一覧は生成されるのに接続できない場合は、個別サーバーのパラメータとConnectivity Testを確認します。サブスクリプション更新の成功は、サーバーが利用可能であることを意味しません。一覧内の接続先がメンテナンス中の場合や、認証情報がリモートの状態と一致しない場合があります。「更新は成功、記録は存在、テストは失敗」と状況を具体的に記録すると、「サブスクリプションがおかしい」とだけ説明するより原因を特定しやすくなります。

更新の繰り返しと手動修正の上書きを避ける

短い間隔で何度更新しても、誤った応答内容が変わるとは限りません。リモート側のアクセス制限が発生することもあります。1回失敗したら、現在のリクエストが終わるのを待ち、どの段階で失敗したかを確認してから、目的を持って再試行してください。ネットワークを切り替えて比較するときは、URLを変更せずネットワーク条件だけを変えます。変数を1つに絞れば、問題がローカルネットワークかリモートの入口にあるか判断できます。

サブスクリプション内の名前やパラメータを手動で変更すると、次回の同期で上書きされることがあります。一時的な確認には、用途がわかる名前を付けて独立した記録にコピーしてください。長期的に直す必要がある場合は、更新のたびにローカルで変更するのではなく、リモートのサブスクリプション内容を確認します。自動更新で適切に管理するには、元の情報が正しいことが前提です。

更新が完了したら、現在選択中の記録が残っているか確認し、もう一度テストしてください。サーバー名の変更や削除があった場合、以前の名前だけで同じ接続先が選ばれていると判断しないでください。詳しい確認手順はサブスクリプション更新の失敗・一覧が空のときのチェックリストをご覧ください。その他の接続トラブルはよくある質問をご確認ください。

管理単位に合わせてサブスクリプションを整理する

複数のサブスクリプションを管理する場合は、まず登録元を明確に分けます。更新、削除の対象や、サーバーがどのリモート一覧から生成されたかを判断できるよう、それぞれに異なる名前を付けてください。すべてを「デフォルト」や「よく使う」と名付けたり、認証情報を含むサブスクリプションURL全体をメモ欄に入れたりしないでください。後者は、スクリーンショットや日常的な画面表示から認証情報が漏れるリスクを高めます。

「普段使い」「予備」「テスト用」など、用途が安定してわかる名前を付け、各入口と用途の対応はご自身だけが見られる管理メモに記録する方法がおすすめです。すでに命名ルールがある場合は、並べ替えのために繰り返し名前を変えず、ルールを維持してください。名前に地域や用途を書いても、サーバーの実際の動作が証明されるわけではありません。手元の情報とテスト結果で確認してください。

同じサブスクリプションを繰り返し読み込むと、名前が似た複数のグループができることがあります。整理する前に、入口、サーバー項目、更新状態を比較し、グループ名だけで判断しないでください。異なるURLが重複する一覧を返す場合もあれば、同じ入口がアカウントの状態によって異なる内容を返す場合もあります。整理の目的は不要なコピーを減らすことであり、似て見える記録を無理に統合することではありません。

サブスクリプション由来の記録と手動追加の記録を分けて管理する

サブスクリプションから生成された記録はリモート側の変更に追従するため、手動追加の記録は個別に提供されたパラメータの保存や一時的な確認に適しています。両方を併用できますが、名前やグループで区別できるようにしてください。確認のためにサブスクリプションの記録を独立した記録にコピーした場合は、ローカルコピーであることとコピーした理由をメモします。そうすれば、元のサブスクリプションを更新した際に、コピーも同期されたと誤解せずに済みます。

一時的なコピーは、いつの間にか説明できない古い記録になりがちです。トラブルの確認が終わったら、保管するか、説明を更新するか、削除するかを決めてください。保管する場合は、SNIを修正した、資料に指定されたPortに変更したなど、元の記録との違いを記載します。単に「使える」とだけ記録すると、そのときのネットワークやパラメータがわからず、後から再現できません。

アプリにサブスクリプション別の表示、絞り込み、一覧の折りたたみ機能がある場合は、対象を1つの管理単位に絞ってから変更してください。一括操作の前に、絞り込み条件と実際の選択範囲を確認します。特に絞り込みで非表示になった記録も選択対象に含まれていないか注意してください。判断できない場合は、重要でない記録1件で操作を試してから残りを処理し、一覧全体を一度に変更しないでください。

選択、並べ替え、ルールの参照は別のもの

一覧内の位置は表示順を決めるだけで、通常は現在の接続先を示しません。サーバーを一覧の先頭に移動しても、Homeで実際に選択されている記録を確認してください。Configでポリシーやグループを使っている場合は、ルールが最終的にどの接続先を使うかも確認します。見た目の「先頭」とルーティング上の「現在の接続先」は異なります。整理の際に混同しないでください。

Configが特定の名前を参照している場合、関連する記録の名前変更や削除が、その後の選択や管理に影響することがあります。変更前にConfig内の関連箇所を確認し、変更前後の名前の対応を記録してください。よくわからないConfigでは、記録名の一括変更とルールの変更を同時に行わないでください。まずサーバー一覧だけを整理して確認し、その後Configを個別に確認すると、問題があったときに元に戻す範囲を絞れます。

iPhoneとiPadで同じ情報を管理する場合は、共通のグループ名を使えますが、並べ替え、選択、同期の状態が両方の端末で完全に一致するとは限りません。各端末で入口と現在の選択項目を個別に確認してください。整理後は、どの情報がサブスクリプションに追従し、どの情報を手動で管理するかを簡単な一覧に残しましょう。サーバー一覧のスクリーンショットだけを保存するより、復元に役立ちます。

何を測定しているかを把握する

Connectivity Testでは、現在のテスト条件におけるサーバーの接続状況を確認できます。具体的な測定内容は、アプリで選択されているテスト方法と対象によって異なります。ミリ秒で表示される結果をすべて同じ指標と考えないでください。ネットワーク経路、ドメインの名前解決、リモートの接続先、テスト対象などが結果に影響します。異なる時刻やネットワークで測定した数値を、同じ条件での結果として直接比較しないでください。

遅延は主に特定のテスト段階にかかる時間を示すもので、継続的な通信速度を直接表すわけではなく、すべてのウェブサイトへのアクセスを保証するものでもありません。テスト結果が速い記録でも、実際のリクエストで認証、TLS、ルール、アクセス先の問題が起きることがあります。タイムアウトしてもサーバー全体が恒久的に使えないとは限りません。まず現在の環境に合ったテスト方法かを確認し、実際のアクセス結果と合わせて判断してください。

比較を始める前に、Wi-Fiかモバイル通信かを記録し、大量のデータ通信が進行していないことを確認します。テスト対象と方法もそろえてください。サーバーごとの差を比較したい場合は、ネットワークとGlobal Routingを同時に切り替えないでください。再現性のあるテストには、安定した条件が必要です。一度だけ良く見える数値を基準にしないでください。

少数のテストを繰り返して安定性を確認する

まず現在選択中の記録をテストし、操作が完了することを確認してから、必要に応じて同じグループの他の記録をテストします。結果が続けて変動する場合は、特定の記録だけが変化しているのか、グループ全体が同時に変化しているのかを確認してください。全体が同時に遅くなる場合は、ローカルネットワークや共通経路の確認が重要です。特定の記録だけが継続して失敗する場合は、その接続先のパラメータとリモートの状態を確認します。一度の結果だけで記録を削除しないでください。

テスト後は、実際の用途に合ったアクセスを試し、通信経路が想定どおりか確認してください。Global RoutingがDirectの場合、アクセスに成功してもサーバーが正常とは限りません。Configモードでは、ルールによって一部のリクエストが直接接続されることがあります。必要に応じてアプリ上の情報から該当リクエストを確認し、直接接続の成功をプロキシ接続の検証済みと誤解しないようにしてください。

実際のアクセスに失敗した場合は、ドメインを名前解決できない、接続待ちになる、TLSエラーが出る、リモートから応答が返るなど、どの段階かを具体的に記録します。段階によって確認項目は異なります。名前解決の問題ならDNSと経路、認証の問題なら認証情報、ルールの問題ならConfigを確認してください。テストボタンを繰り返し押すだけでは同じ状態を再確認するだけで、エラーの段階を分析したことにはなりません。

並べ替えは選択を補助するもので、判断の代わりにはならない

現在の画面で遅延順に並べ替えられる場合は、結果がすべてそろってから使い、古い結果と新しい結果を混在させないようにします。未測定、失敗、有効な結果では並び方が異なることがあるため、並べ替えた後も個々の状態を確認してください。一覧の先頭は現在の並べ替え条件による位置にすぎず、常に最適な接続先とは限りません。ネットワークの状況が変われば、以前の並び順は参考にならないことがあります。

普段の利用では、確認済みの記録を候補として少数残し、それ以外は登録元ごとに折りたたむか整理できます。切り替え先を確保しながら、毎回すべての記録をテストする負担を減らせます。候補を選ぶ際は、接続の安定性、パラメータの入手元が明確であること、実際のアクセス結果を考慮し、遅延だけで判断しないでください。テストは選択を補助するものであり、サービス提供元の価値を評価するものではありません。

特定のサーバーとモードの組み合わせが使えると確認できた場合は、その状態を基準として残してから、問題のある記録を1項目ずつ確認します。基準を残さずに一覧を一括更新、削除、名前変更すると、追加の変更と元のネットワークのどちらが原因なのか判断しにくくなります。モードの選び方はGlobal Routingの機能説明、よくある接続トラブルはよくある質問をご覧ください。

削除する対象を確認する

個別サーバーの削除、サブスクリプション入口全体の削除、Configの削除は別の操作です。サブスクリプションから生成された個別記録を削除しても、次回の更新で再び作成される場合があります。サブスクリプション入口を削除すると、そのグループ内のサーバーにも影響することがあります。実行前に確認画面の説明を読み、1件の記録とグループ全体のどちらが対象かを確かめてください。長押しした位置や一覧の見た目だけで範囲を推測しないでください。

特定の記録を一時的に使わないだけなら、すぐに削除せず、確認済みの別の記録を選べます。削除が必要な場合は、現在唯一使える接続先ではないこと、既存のConfigから参照されていないことを確認してください。入手元がわからないローカルコピーは、元のパラメータが保存されているか確認します。復元情報がない状態で削除すると、比較できる状態から資料を集め直す状態に戻ってしまいます。

一覧から内容を削除しても、漏えいした認証情報が無効になるわけではなく、リモートのアカウント状態も変わりません。サブスクリプションURLやPasswordの漏えいが疑われる場合は、サービス提供元から新しい情報を入手し、案内された手順で古い認証情報を処理してください。ローカルでの削除はこの端末上の記録を変更するだけで、リモート側の認証情報更新の代わりにはなりません。

バックアップは3つの階層を対象にする

1つ目はサブスクリプションの入口と入手元の説明、2つ目は個別に追加したサーバーパラメータ、3つ目はConfigと必要なルール設定です。サブスクリプションURLだけを保存すればリモートの一覧を再取得できますが、手動追加の記録やルールまで復元できるとは限りません。Configだけをエクスポートしても、すべてのサブスクリプション認証情報やアプリ設定が含まれるとは限りません。実際のエクスポート内容を確認し、復元できる範囲を把握してください。

アプリでiCloud同期やエクスポートを利用する場合は、現在使えるオプションと完了状態を確認してから、機種変更に必要な内容を十分に保管できているか判断してください。同期を有効にしても、すべての内容が別の端末に転送されたとは限らず、誤削除を元に戻せるとも限りません。同期は複数端末の状態をそろえること、バックアップは復元可能なコピーを残すことが目的です。重要な変更の前には、別の場所にも資料を保存してください。

バックアップファイル、QRコード、共有リンクには認証情報が含まれる場合があります。必要な人だけがアクセスできる場所に保管してください。探しやすくするために公開ドキュメントや公開アルバムへ置かないでください。資料には用途と含まれる内容を記載すれば十分で、ファイル名にPasswordを重ねて記録する必要はありません。保存後に実際に開き、内容がそろっていることを確認してください。機種変更時になって空のファイルや通常のウェブページを保存していたと気づくことを防げます。

購入、読み込み、選択、検証の順に復元する

新しいiPhoneまたはiPadでは、まずApp Storeでアプリを確認し、購入済みのアプリを復元します。購入の適用範囲とシステム要件はApp Storeの掲載内容をご確認ください。アプリの購入記録から復元できるのはアプリの入手であり、サーバー、サブスクリプション、Configが自動的に復元されるとは限りません。購入に関する手順は購入済みアプリの復元ガイドをご覧ください。データ消失への対処として再購入をしないでください。

1. 正しいApp Storeの製品ページからアプリを入手し、初回起動を完了します。
2. 同期データを復元するかバックアップを読み込み、サブスクリプション、個別記録、Configがそろっているか確認します。
3. 必要に応じてサブスクリプションを更新し、現在選択中のサーバーとGlobal Routingを確認します。
4. Connectivity Testと実際のアクセスを確認してから、旧端末の資料を整理します。

復元後に同じ名前の記録が表示されても、すぐに重複を一括削除せず、それぞれが同期、エクスポート、再読み込みのどれに由来するか確認してください。まず検証済みの記録を基準として残してから、不要なコピーを整理します。新しい端末と古い端末で動作が違う場合は、ネットワーク、Config、サーバー項目、システム権限を1つずつ比較してください。一覧名が同じだからといって、設定も完全に一致しているとは限りません。

移行の詳しい手順はConfigのバックアップ、iCloud同期、機種変更時の復元手順をご覧ください。日常の管理では、更新と削除を別々の操作として行います。まず新しいデータが有効かを確認し、その後で古い内容を整理してください。明確な復元手段を残せるため、次回のトラブル確認でも内容を把握しやすくなります。