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

Subscribeの入口とサブスクリプションの登録

サブスクリプションURLとサーバーアドレスを区別する

サブスクリプションURLはサーバー一覧を取得するためのもので、サーバーアドレスは個々の接続設定がアクセスするホストです。どちらにもドメイン名が含まれる場合がありますが、同じ項目には入力できません。操作を始める前に、手元の情報がサブスクリプションURL、単一サーバーの共有リンク、または手動入力用のパラメーター一式のどれに当たるか確認してください。一覧を取得するURLがある場合にのみSubscribeを選びます。HTTPSで始まるというだけでサブスクリプションと判断しないでください。通常のWebページも同じ形式を使います。

HomeからAdd Serverを開き、TypeでSubscribeを選択します。画面に表示されるURLなどの項目に、手元にあるサブスクリプションURLを入力し、見分けやすい名前を付けてください。画面のレイアウトによって入口の位置が異なる場合があるため、英語の項目名を確認します。貼り付け後は、先頭、末尾、クエリパラメーターが欠けていないか確認してください。特に、チャットアプリが自動で挿入した空白や改行に注意します。保存前にサブスクリプションURLを個別サーバーのドメインに置き換えたり、不要に見えるパラメーターを削除したりしないでください。

登録の保存と一覧の取得は別の段階

サブスクリプションを保存できても、クライアントが登録情報を受け付けたことを示すだけで、サーバーからの取得に成功したとは限りません。保存後、サブスクリプションに用意されている更新操作で内容を取得し、Homeに戻ってサーバーが表示されるか確認してください。名前だけが表示されてサーバー項目がない場合は、接続をすぐ有効にするのではなく、更新結果を確認します。一覧が表示されている場合も、それが今回のサブスクリプションから取得した項目か、以前に手動で追加した記録かを見分けてください。

サブスクリプションの応答には、クライアントが認識できるサーバー情報が含まれている必要があります。ログインページ、説明ページ、エラーメッセージが返された場合、ブラウザーでURLを開けてもインポート可能とは限りません。まずクライアントに表示されるエラーを確認し、利用中のサービスの管理者にURLの用途と対応形式を問い合わせてください。認証情報を含むサブスクリプションURLを公開の検索ツールに入力しないでください。また、トラブルシューティングのために同じ完全なリンクを何度も別の場所へ貼り付ける必要はありません。

サブスクリプションとConfigの役割を確認する

サーバー一覧とConfig内のルールは役割が異なります。前者は接続先、プロトコル、認証情報を指定し、後者はリクエストをPROXY、DIRECT、REJECTのどれで処理するかを決めます。サブスクリプションをインポートしても、現在のルールファイルが置き換わるとは限りません。同様に、Configを切り替えてもサーバー一覧が再取得されるわけではありません。2つの操作を分けて確認すれば、一覧は正常なのにルールの違いで接続に失敗したと誤認するのを防げます。

インポート後、サブスクリプション名、インポート方法、現在選択中のサーバーを記録し、初回接続の手順に沿ってテストしてください。一覧が空の場合は、URL、応答内容、ネットワーク接続を確認します。一覧がそろっているのに接続できない場合は、パラメーターとテストの章に進みます。「一覧の取得、パラメーターの確認、接続、接続先へのアクセス」の順に切り分けてください。サブスクリプション、Config、DNSを同時に変更すると、どの変更が結果に影響したのか分かりにくくなります。

Add Serverの手動入力項目

Typeによって入力項目が変わる

手動追加は、サーバーの必要な情報がすべてそろっており、各項目を確認しながら入力したい場合に適しています。HomeからAdd Serverを開き、まずTypeを選択してから項目を入力してください。Shadowsocks、VMess、VLESS、Trojan、HTTP、SOCKS5、WireGuard、Hysteria2では必要な情報が異なります。Typeを切り替えたときに表示・非表示になる項目は、自由に置き換えられる別名ではありません。元の設定に明記されたプロトコルを選び、不足している情報を別のTypeで補おうとしないでください。

Addressには通常、サーバーのホスト名またはIPアドレスを入力し、Portには接続先が指定したポート番号を入力します。URLの入力が明示されている場合を除き、プロトコルの接頭辞、Webページのパス、クエリ文字列をAddressに含めないでください。ドメイン名とIPアドレスは、常に置き換えられるわけではありません。ドメイン名を使う場合、名前解決、証明書名、サーバーのルーティングに関わることがあります。元の情報にドメイン名が指定されている場合は、そのまま入力してください。変数を減らす目的で、名前解決後のIPアドレスに置き換えるのは避けます。

認証、トランスポート、TLSを分けて確認する

PasswordやUUIDなどの認証情報は、文字と大文字・小文字を変えずに入力してください。ShadowsocksのMethodは接続先と一致させる必要があり、すべての暗号方式が相互に使えるわけではありません。VMessやVLESSでトランスポート方式も指定されている場合は、関連項目も確認してください。トランスポート層のHostやPathがリクエストの照合に使われることもあります。アドレス、ポート、認証情報が正しくても、ほかの必須項目が自動で補完されるとは限りません。

TLS、SNI、接続先アドレスは関連していますが、それぞれ別の項目です。接続先アドレスはアクセスする接続先を指定し、必要に応じてSNIでサーバー名を伝え、証明書の検証で接続先の正当性を確認します。元の設定にサーバー名が明記されている場合は、その値を確認してください。証明書の検証を無効にすることを、通常の解決策として使わないでください。証明書に関するエラーが発生した場合は、端末の時刻、名前の一致、接続先の証明書の状態を確認してから、トランスポート設定を見直します。ポートだけを変更して解決しようとしないでください。

プロトコルごとの項目を流用しない

WireGuardの秘密鍵、ピアの公開鍵、Address、Allowed IPs、MTUは、それぞれ独自の設定項目です。ここでのAddressはトンネルアドレスを指す場合があり、一般的なサーバーのAddressと同じ意味とは限りません。接続先の指定にはEndpointを使います。Hysteria2の認証情報とトランスポートの項目も、元の情報に従って入力してください。WireGuardの各項目についてはWireGuardの設定項目ガイドをご覧ください。不足している値を、ほかのプロトコルの項目から推測しないでください。

保存前に、元の情報と各項目を照合してください。見落としやすい前後の空白、全角記号、自動改行を重点的に確認します。保存後は編集画面を再度開き、入力内容が想定どおりに保持されているか確認してから接続テストを行います。認証段階でエラーが出た場合は、まず認証情報を確認します。接続先に到達できない場合は、ネットワークとアドレスを確認してください。試すたびに変更する項目を1つに絞り、変更前の値を記録しておくと、どの設定が実際の接続先の情報に合っていたか分からなくなるのを防げます。

QRコード・クリップボードからのインポート

Scan QR Codeで読み取るのは内容

QRコードはテキストを格納するもので、見た目だけではサブスクリプション、単一サーバー、通常のWebページのどれが含まれているか分かりません。Scan QR Codeを使う前に、自分の設定情報のQRコードであることを確認し、四隅まで画面に収めて、明るさとピントを調整してください。初めてカメラを使うときは、システムからアクセス許可を求められる場合があります。必要性に応じて許可するか判断してください。読み取れない場合は画像の状態とアクセス許可を確認します。既存のサーバーをすぐに変更したり、「空きを作る」ために記録を削除したりしないでください。

読み取り後、どの種類の記録としてインポートされたかを確認してください。QRコードに単一サーバーのリンクが含まれている場合は、通常、1件の接続情報が追加されます。サブスクリプションURLの場合は、別途一覧を取得する必要があります。確認画面が表示されたら、Type、Address、名前が適切か確認してください。「読み取り成功」だけで必要な設定がそろったとは限りません。QRコードに古い認証情報が含まれている可能性もあるため、インポート後に接続テストが必要です。読み取り操作だけでは、接続先の設定が今も有効かどうかは分かりません。

クリップボードのテキストをそのまま保つ

クリップボードからインポートするときは、必要なリンクや設定テキストだけをコピーし、説明文、番号、コードフェンス、文末の句読点を一緒に含めないようにします。現在の画面にクリップボードからのインポート項目がある場合は、表示される手順に従ってください。ペーストの許可を求められたら、操作を開始したアプリを確認します。コピー後すぐにインポートすると、別のコピー操作で内容が上書きされるのを防ぎやすくなります。クリップボードが空、または新しい内容に置き換わっている場合は、元の情報からもう一度コピーしてください。記憶を頼りに文字をつなぎ合わせないでください。

長いリンクはチャット画面で見た目上折り返されることがありますが、表示上の折り返しが実際の改行とは限りません。一方、複数のテキストをコピーすると、本当の改行が含まれる場合があります。形式を認識できないというエラーが出た場合は、まず先頭と末尾を確認し、次に途中で切れていないか確認してください。名前部分とエンコードされた内容では扱いが異なるため、すべての空白を一括置換しないでください。元のテキストからリンク全体をコピーし直し、インポート後の主要な項目と照合するのが確実です。

重複・一括インポート・読み取りエラーへの対応

一括インポートの前に、現在の入口がそのテキスト形式に対応しているか確認してください。複数のリンクを1行ずつ並べても、サブスクリプションとして処理されるとは限りません。1件の記録だけを受け付ける入力欄もあります。まず手元にある有効な情報を1件使って入口を確認してから、残りを処理してください。インポート後は、プロトコル、アドレス、ポートを見て件数と各項目の対応を確認します。名前だけを数えないでください。同じ名前でも接続先が異なることがあり、名前が違っても接続情報がまったく同じ場合があります。

重複してインポートしても、すぐに名前だけでまとめて削除しないでください。サブスクリプションが管理する記録と手動で追加した記録を区別し、現在どれを使用しているか確認します。QRコードとクリップボードで結果が異なる場合は、元の2つの内容が本当に同一かを確認してください。特に、QRコードの横にある別のリンクをコピーしていないか注意します。同じ情報がどちらの方法でも認識されない場合は、カメラよりも形式や内容に原因がある可能性が高いため、共有リンクの章で構造を確認してください。

インポート後はHomeに戻り、新しい記録を選択して再度テストしてください。既存の接続が新しいサーバーに切り替わっているとは限りません。また、ブラウザーの古いページがキャッシュを表示している場合もあります。テストする際は現在の選択内容を記録し、新しいリクエストで結果を確認してください。インポートできるかの確認だけが目的なら、項目のチェックで止めてかまいません。テストのためにOn Demandも同時に有効にする必要はありません。入力と接続を別々に行えば、失敗した手順を特定しやすくなります。

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

接頭辞、本文、パラメーター、名前

サーバーの共有リンクは通常、プロトコルの接頭辞、接続情報を含む本文、任意のクエリパラメーター、表示名で構成されます。よく使われる接頭辞にはss://、vmess://、vless://、trojan://があります。ただし、接頭辞を認識できても、後続の項目がすべてそろっているとは限りません。本文がエンコードされている形式も、認証情報とアドレスを直接含む形式もあります。接頭辞を置き換えて別の形式に変換することはできません。インポート時はリンク全体を保ち、見た目を頼りに別のプロトコル形式へ書き換えないでください。

リンク内の疑問符はクエリパラメーターの開始を示すことが多く、シャープ記号の後に表示名が含まれる場合があります。パーセントエンコードは一部の特殊文字を表します。これらは飾りではなく、構文上の意味を持ちます。手動で書き換える際にパラメーターの区切りを削除したり、エンコード文字をデコードしてからコピーしたりすると、クライアントが読み取る内容が変わる場合があります。名前を変更する場合は、認証情報やトランスポート設定を壊さないよう、インポート後の編集画面で表示名を変更してください。

単一リンクとサブスクリプションは別のもの

単一の共有リンクは通常、1件のサーバー記録を表します。一方、サブスクリプションURLはサーバー一覧を取得するために使います。サブスクリプションの応答には複数のサーバー情報が含まれる場合も、ほかの対応形式が使われる場合もあります。これは応答内容の形式であり、サブスクリプションURL自体の書き方とは異なります。ブラウザーに表示されたページ全体をAddressに入力したり、単一のサーバーリンクを継続更新できる一覧URLとして扱ったりしないでください。まず対象を区別してから適切なインポート方法を選ぶことで、その後の管理方法も明確になります。

インポート後に主要な項目が空欄の場合は、クライアントの既定値を使うのではなく、形式の不一致、テキストの欠落、リンク内のパラメーター不足を疑ってください。特にトランスポート、TLS、認証情報の既定値は、元の設定と異なる場合があります。手元にある構造化された設定と項目ごとに照合できますが、読みやすい名前だけからプロトコルを推測しないでください。地域や用途を示す名前はラベルにすぎず、アドレス、プロトコル、利用可否の技術的な根拠にはなりません。

ルールファイルの編集にはConfigを使用

Shadowrocketの.confファイルにはルールを記述できますが、ルールの一部をサーバーの共有リンクとして扱うことはできません。以下の例はマッチ順序と動作を示すもので、サーバー情報は含まれておらず、個人の設定ファイルをそのまま置き換えるものでもありません。使用前に既存ファイルのほかのセクションとポリシーの関係を確認してください。設定を編集する場合は先にコピーを保存し、該当部分を特定してから変更します。短い例をファイル全体に上書きしないよう注意してください。

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

DOMAIN-SUFFIXはドメインのサフィックスで照合し、GEOIPは関連するIPの地理情報で判定し、FINALはそれ以前のルールに一致しなかったリクエストを処理します。ルールは順番に評価され、前のルールに一致すると後続の確認に影響します。例のPROXYは該当するプロキシ動作を示すもので、特定のサーバーを定義しているわけではありません。ルールの構文が正しくても、サーバーの認証情報が無効なら、FINALを変更しても認証は復旧しません。

共有する前に、相手のデバイスに完全な認証情報が本当に必要かを確認し、自分で管理できる方法を選んでください。トラブルシューティングの相談であれば、通常はプロトコル名、エラーの種類、必要な項目を伏せ字にした構造だけで十分です。認証情報を含むテキストを他人が入手した場合、ローカルのメッセージを削除しても認証情報は無効になりません。アクセスを取り消す必要がある場合は、自分が管理するサービス側で該当する認証情報を変更し、クライアントの記録も更新してください。

サブスクリプションの更新とエラーへの対応

更新で変わるのは一覧。すべての設定が変わるわけではない

サブスクリプションを更新するとURLに再度アクセスし、応答内容を解析します。サーバーの追加、古い項目の削除、既存パラメーターの変更が行われる場合があります。これはApp Storeのアプリ更新やConfigファイルの更新とは別の操作です。アプリの機能が更新されてもサブスクリプションの内容が同期されるとは限らず、サブスクリプションの取得が成功してもルールファイルが変わるわけではありません。サーバー一覧が変化した場合も、現在の設定がそろっているかを以前の名前だけで判断せず、どの種類の更新が行われたか確認してください。

更新前に、現在使用中の項目と手動で変更した項目を記録してください。サブスクリプションに属する記録は、再取得時に作り直されたり上書きされたりする可能性があります。重要なローカル変更を、その配下の項目にだけ保存しないでください。試験用の設定を残す場合は、用途を明記した独立したコピーを保存してから更新します。サブスクリプション側の項目の識別方法と、クライアントでの変更の表示方法は、内容の形式によって異なることがあります。名前が同じだからといって、内部的に同じ記録が維持されるとは限りません。

手動更新と自動更新の使い分け

手動更新は、初回インポート、設定変更の通知を受けたとき、トラブルシューティング後の再確認に適しています。現在の設定に自動更新の項目がある場合は、必要性と対象を確認して選択してください。自動更新は常時監視ではなく、バックグラウンドでの処理はシステムの状態にも左右されます。重要な利用の前には一覧と直近の結果を自分で確認し、設定が有効になっているだけで内容も予定どおり更新されたと判断しないでください。

更新に失敗しても、短時間に何度も続けて実行する必要はありません。短時間にリクエストを繰り返しても、URLの誤りが直るわけではなく、ログに同じ現象が増える可能性があります。まずエラーを記録し、端末のネットワークが正常に動作することを確認してから、ドメイン名の解決、接続、応答ステータス、内容の解析のどこで失敗したか判断してください。サブスクリプションURLが変わった場合は、正しい記録を編集して全項目を確認します。同じ接続先のサブスクリプションを何件も追加し、状態の異なる一覧を増やさないでください。

更新後、使用中の記録を確認する

更新成功の表示が出たら、サブスクリプション配下の項目が想定どおりか、特に現在の選択項目が残っているか確認してください。元の項目が削除されている場合は、有効な項目を選び直して接続をテストします。クライアントに以前の結果が残っている場合は、「一覧が表示されていること」と「今回のリクエストが成功したこと」を区別してください。古い一覧が残っているだけでは、今回の取得が成功した証拠になりません。一方、一覧に変化がなくても、接続先で内容が変更されていない可能性があるため、更新結果と合わせて判断します。

通常のネットワーク接続とプロキシ経由で動作が異なる場合は、まず更新リクエストが実際にどの経路を使うか確認してください。現在選択中のサーバーを必ず経由すると決めつけないでください。遅延テストは正常なのにサブスクリプションのドメイン名を解決できない場合は、DNSと名前解決のトラブルシューティングを参照してください。元の値を記録せずにDNS、ルーティング、サブスクリプションURLを同時に変更すると、成功・失敗の原因を切り分けにくくなります。

メンテナンス後は、今回内容を取得できたか、どの項目が変わったか、再確認を行ったかを簡潔に記録してください。記録にサブスクリプションの認証情報を含めないでください。更新後に現在の接続が使えなくなった場合は、有効と確認済みのバックアップと比較してから、新しいパラメーターを確認します。古い一覧を同じサブスクリプションに再インポートして、その後も維持されると期待しないでください。長期的な管理には、有効なサブスクリプションの内容を使用します。

複数のサブスクリプションとサーバーの整理

接続状況ではなく、管理方法や用途で名前を付ける

複数のサブスクリプションがある場合は、個人テスト、日常利用、予備など、用途を区別できる名前を付けます。個別に手動追加した記録には、情報の入手元の種類が分かる名前を付けてください。名前は検索しやすくするために使い、認証情報、完全なアドレス、一時的なテスト結果を含めないでください。遅延時間を名前に入れるとすぐに古くなり、「利用可能」を恒久的なラベルにすると誤解を招きます。安定した命名では、リアルタイムの性能を示すのではなく、管理元と用途を表します。

サブスクリプション名と、その配下にあるサーバー名は異なる階層の情報を表します。管理時は、まずサーバーがどのサブスクリプションに属するかを確認し、次に接続情報を確認してください。表示名だけで重複と判断しないでください。異なるサブスクリプションから同じ名前の項目が返されることも、同じサブスクリプションから似た名前の項目が複数返されることもあります。残しておきたいローカルのテスト用記録には、それと分かる名前を付けてください。更新や整理の際に、接続先が管理する項目と自分で管理する項目を区別できます。

重複は主要な項目を比較して判断する

重複かどうかを判断するには、少なくともType、Address、Port、関連するトランスポート設定を比較してください。認証が必要なプロトコルでは認証情報も同じか確認しますが、一般的なメモに認証情報を書き写す必要はありません。接続先が同じでも認証情報やトランスポート設定が異なれば、用途が異なる場合があります。反対に、名前が違っても接続項目がすべて同じなら、重複してインポートされた可能性があります。削除前に現在選択中の項目を確認し、使用中の独立した記録を誤って削除しないようにしてください。

一覧を見た目上そろえるために、サブスクリプションの全項目を手動記録としてコピーしないでください。更新との連携が失われ、以降のパラメーター変更を1件ずつ反映する必要があります。独立した記録として残すのは、固定パラメーターが必要なテスト用コピーなどに限り、元のサブスクリプションの変更が自動反映されないことを明記してください。同じURLを複数のサブスクリプションとして追加している場合は、異なるフィルターや管理上の目的があるか確認してから整理します。URLが似ているというだけで一括削除しないでください。

一覧の整理とGlobal Routingは別に確認する

サーバーの並べ替えは検索や選択をしやすくするための操作で、リクエストの処理方法を決めるのはGlobal Routingです。一覧の先頭にある項目が、すべてのリクエストの接続先になるわけではありません。現在の選択、Config内のポリシー、ルーティングモードをそれぞれ確認してください。整理後はHomeに戻って現在の選択を確認し、使用中のConfigを開いてルールの動作を確認します。名前や順序を変えただけで、ルールファイル全体を書き換える必要は通常ありません。

一覧が長い場合は、現在の画面で使えるグループ分け、検索、並べ替え機能を利用して対象を絞ってから、パラメーターを確認してください。入口の場所は実際の画面に従い、特定のレイアウトを再現するためにすべての記録を作り直す必要はありません。サブスクリプションを1件ずつ整理し、各グループの項目を見分けられることを確認してから次に進みます。分けて作業すれば、異常が起きた際に直近の変更を特定しやすくなります。

整理の際は機密情報も確認してください。用途のメモにPassword、UUID、完全なサブスクリプションURLを含めず、公開するスクリーンショットではサブスクリプション名に個人を特定できる情報が含まれていないか確認します。複数のデバイスで同じ整理方法を保ちたい場合は、まず1台で命名規則とバックアップ範囲を決めてから、別のデバイスに復元して差異を確認してください。複数のデバイスで同時に手動で名前を変更すると混乱しやすいため、名前そのものよりメンテナンスの順序を明確にします。

Connectivity Testの結果と並べ替え

まずテスト対象を確認する

Connectivity Testの結果は、実際に行ったテスト方法に沿って解釈してください。方法によって、接続先への到達性、プロキシ経由のテスト対象へのアクセス、または別の特定の段階を確認する場合があります。1つの数値で利用状況全体を表すことはできません。テスト前に関連設定を確認し、テスト対象、方法、現在のネットワークをそろえて比較してください。異なるネットワーク、テスト対象、方法で得た数値をそのまま並べ、同じ条件での性能結果として扱わないでください。

接続先から応答があっても、認証、TLS、トランスポート、接続先へのアクセスがすべて成功したとは限りません。遅延が表示されても認証情報が無効だったり、パラメーターが合わなかったりすれば、実際のリクエストは完了できない場合があります。一方、テスト対象に一時的に到達できないからといって、サーバー全体が使えないとは限りません。テスト結果を手がかりにしつつ、実際に利用する通常の接続先で確認してください。結果に差がある場合は、どの段階で失敗したかを特定し、タイムアウト表示の項目をすべてすぐに削除しないでください。

条件をそろえて比較・並べ替える

並べ替える前に、端末のネットワークとテスト設定を一定に保ち、テスト中にWi-Fiからモバイル通信へ切り替わらないようにしてください。候補を少数に絞って繰り返し確認すると、一覧全体を一度だけテストするより結果を解釈しやすくなります。並べ替えはその時点の条件での結果であり、以降の通信速度、安定性、接続先へのアクセスを保証するものではありません。短時間の差をサービス品質の変化と結び付けたり、一度だけ最も小さかった数値で今後のすべてのリクエスト経路を決めたりしないでください。

テスト後に項目を選択したら、選択状態が実際に変わったことを確認してください。必要に応じて接続を確立し直し、新しいリクエストを送信します。ブラウザーのキャッシュ、既存の長時間接続、ほかのアプリのセッションによって、結果の反映が遅れる場合があります。古いページが表示されていても、新しいサーバーが正常に動作した証拠にはなりません。新しい操作を行い、現在のGlobal Routingモードも確認してください。Directの場合、直接アクセスに成功してもプロキシの動作確認にはなりません。

問題を検証できる手順に分ける

基本ネットワーク、サーバーの設定項目、接続状態、DNS、ルール、接続先のサービスの順に確認してください。基本ネットワークに問題がある場合は、まず端末が通常どおりインターネットに接続できる状態に戻します。設定項目に問題がある場合はAdd Serverに戻って照合してください。接続先のドメイン名だけが解決できない場合にDNSを確認します。すべての候補で同じ結果になる場合は、各サーバーの認証項目を変更するより、現在のネットワーク、テスト対象、Configなど共通する要因を優先して確認してください。

ログやDataにある情報を使うと、リクエストが実際に送信されたか、どの経路を通ったかを確認できます。ただし、今回の操作に近い記録を確認し、過去のエラーを現在の結果と取り違えないようにしてください。トラブルシューティング資料を共有する場合は、必要なエラーの種類と伏せ字にした項目だけを残し、完全な認証情報を送らないでください。遅延は正常なのにWebページを開けない場合は、DNSのトラブルシューティングを参照し、名前解決とリクエスト経路を分けて確認してください。

並べ替えと長期的なメンテナンスは分けて考えてください。一時的にタイムアウトした項目は再確認のために残し、接続先から削除されたことや認証情報が失効したことを確認できた記録は削除手順に進みます。1回のテストをきっかけに大量削除したり、ルールを自動変更したりしないでください。安定した結果が得られたら、テスト条件と現在の選択を記録しておきます。以前の並べ替えに頼り続けるより、ネットワーク環境が変わるたびに再確認するほうが実際の状態を把握できます。

削除、バックアップ、機種変更時の復元

バックアップ対象を整理する

バックアップの前に、サブスクリプション、独立したサーバー、Configファイル、関連設定を区別してください。ルールファイルを保存しても、すべてのサブスクリプションURLや認証情報が保存されたとは限りません。サーバーの共有リンクを保存しても、現在のルールや端末設定がすべて保管されるわけではありません。現在の書き出し機能や同期機能で何が保存されるか確認し、不足する対象は別途保存してください。手動入力したパラメーターの元情報が見つからない場合は、削除前に復元可能なコピーがあることを必ず確認します。

iCloud関連の機能を使う場合は、端末で使用しているアカウントとアプリ内の関連設定を確認し、実際に同期されたことを確かめてください。クラウド上での表示、システムの空き容量、ネットワーク状態が操作に影響します。スイッチがオンになっているだけでバックアップが完了したと判断しないでください。同期は過去の状態を保存するアーカイブとは限りません。削除が次の同期でほかの端末にも反映される場合があります。削除前の状態を残す必要がある場合は、独立したコピーを別に保存し、現在の整理操作でそのコピーまで変更されないことを確認してください。

削除前に対象と影響範囲を確認する

サーバーを1件削除する前に、サブスクリプションに属しているか、現在使用中か確認してください。サブスクリプション配下の項目を端末上で削除しても、次回更新時に再表示される場合があります。接続先で管理されている一覧を恒久的に変更したい場合、端末上の項目を削除するだけではサブスクリプションの応答は変わりません。サブスクリプション全体を削除すると影響が広がる可能性があるため、関連項目と現在の選択を確認してから、確認画面の案内に従ってください。名前が似ている項目を隠すために、一覧全体を誤って削除しないよう注意してください。

独立したサーバーを整理する際は、必要なパラメーターのコピーを保存してから、Config内で関連するポリシーや名前が参照されていないか確認してください。名前とポリシーの関係は、Homeの一覧が整っているかどうかだけでなく、実際の設定で確認します。削除後は現在の選択とルーティング経路を再確認し、必要に応じて有効な項目を選んで新しいリクエストをテストしてください。目的が項目の無効化だけなら、すぐに完全削除するより、明確な名前を付けたバックアップを残すほうが元に戻しやすくなります。

新しい端末には順番に復元して確認する

機種変更の際は、まず購入済みアプリの復元方法に沿ってApp StoreからShadowrocketを入手し、その後、自分のデータを復元してください。アプリの購入記録と接続情報は別のものです。アプリを復元しても、サブスクリプション、サーバー、Configがすべて戻るとは限りません。システム要件と購入の適用条件はApp Storeの掲載内容をご確認ください。新しい端末で初めて接続する際は、VPN構成の許可を求めるシステムの案内に従ってください。許可のダイアログを、サブスクリプションの検証成功と取り違えないでください。

復元は、手元にある元の情報の確認から始めるのがおすすめです。まずサブスクリプションURLと個別の設定情報が有効か確認し、次にサーバー記録とConfigを復元してから、Global Routing、DNS、On Demandなどの関連設定を確認します。復元するたびにテストすれば、似たバックアップを一度に複数インポートして、どれが有効なのか分からなくなるのを防げます。古い端末をまだ使える場合は、新しい端末で一覧、接続、接続先へのアクセスをすべて確認できるまで、古い端末の状態を保ち比較用にしてください。

復元後に項目が不足している場合は、データが壊れていると決めつけず、バックアップの対象範囲と選択したファイルを確認してください。項目がそろっていても接続できない場合は、パラメーターとテストの章に進みます。接続先でサブスクリプションの認証情報が変更されている場合、古いバックアップから復元できるのは古い情報です。自分が利用できる有効な情報に更新してください。同期、書き出し、機種変更について詳しくは設定のバックアップと機種変更時の移行をご覧ください。復元した対象を記録し、不要になった一時コピーは安全に処分してください。