公式マニュアル · サーバー管理

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

まず追加する情報の種類を確認し、その後に更新、選択、バックアップを行います。サブスクリプションURL、個別サーバー、Configファイルはそれぞれ用途が異なります。リンクの見た目だけで判断しないでください。

このページは、すでに自分のサブスクリプションまたはサーバー情報をお持ちの方向けの管理ガイドです。初回接続は、まず使い方ガイドの手順に沿って操作し、その後、該当する章で詳細を確認してください。アプリの買い切り購入と接続サービスの契約は別です。アプリの入手と購入済み確認についてはダウンロードガイドをご覧ください。

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

サブスクリプションは、リモートのサーバー一覧を保存し、繰り返し更新できるようにするものです。一度だけサーバーを追加する機能とは異なります。追加後は、サブスクリプションの登録情報と、その中に展開されたサーバー項目の両方を確認してください。前者にはURLと更新情報が保存され、後者から接続先を選びます。一覧が増えただけでは、サブスクリプションが正しく登録されたとは限りません。URLを保存できても、リモートの内容を正常に取得できたとは限りません。この2つを区別すると、更新時と接続時のどちらで問題が起きたか判断しやすくなります。

追加前：入力する情報を見分ける

サブスクリプションは利用中のサービス提供元から入手してください。Shadowrocket用のサブスクリプションURLであることを確認し、アカウント管理ページ、案内ページ、単一サーバーの共有リンクと取り違えないようにします。サブスクリプションURLは個人用の認証情報です。通常のWebページのURLに見えても、サーバー一覧へのアクセス権が含まれている場合があります。URL全体を公開メモやチャットに貼り付けたり、問題報告用のスクリーンショットに写したりしないでください。自分で確認する場合も、画面録画やクリップボード同期を通じてアクセス情報が漏れないよう注意してください。

追加前に、元のテキストを保存し、先頭、末尾、途中に空白、改行、全角記号が混じっていないか確認します。メッセージアプリが自動で付けた句点や、コピー操作で一緒に選択された説明文にも注意してください。クエリパラメーターを勝手に削除したり、見慣れない文字を別の文字に置き換えたりしないでください。URLの大文字・小文字、パス、パラメーターが識別に使われている場合があります。表示名の整理と、実際のURLの変更は別の操作です。

Add ServerでSubscribeを選択する

Homeから追加画面を開き、Add ServerでTypeをSubscribeに設定します。完全なURLを入力し、見分けやすいメモを付けて保存してください。画面の配置はデバイスによって異なる場合があるため、現在のアプリ画面に従って操作します。初回はサブスクリプションを1つだけ追加し、保存後に対応する一覧が作成されたことを確認してから次に進みます。複数のURLを同時に追加すると、失敗した原因を特定しにくくなり、重複した項目を更新で増えたものと誤認することもあります。

保存後はHomeに戻り、サブスクリプション名、展開された項目、想定しているサーバーが一致するか確認してください。一覧の説明用項目を、そのまま接続可能なサーバーと判断しないでください。名前に状態表示が含まれる場合は、項目の種類と詳細も確認します。その後、必要なパラメーターがそろっていることを確認したサーバーを選び、接続をテストします。追加と接続は別の結果です。追加にはURLへのアクセスと内容の解析が必要で、接続にはサーバーへの到達性、認証、通信設定も関係します。

追加に失敗した場合：アクセス、内容、結果を分けて確認する

保存後に項目が表示されない場合は、まずURLが完全か確認し、次に現在のネットワークからサブスクリプションのホストへアクセスできるか確認します。ブラウザーでページが開けても、インポート可能な一覧が返されるとは限りません。ログイン画面、案内ページ、アクセスエラーもWebページとして表示される場合があります。そうしたページの文章をサーバー情報として手入力しないでください。サービス提供元に問い合わせるときは、追加画面、エラーメッセージ、発生した段階を伝えれば十分です。スクリーンショットを送る前に、URLに含まれる個人用アクセス情報を隠してください。

既存のサブスクリプションの更新に失敗した場合、古い登録を残し、すぐに削除して作り直すことは避けてください。失敗前後でサーバーが残っているか、選択中の項目が変わったか、特定の項目だけが利用できないのかを確認します。サブスクリプションURLが変更された場合は、新しい登録を追加して検証してから、古い登録を整理してください。これなら以前の状態に戻す手段を確保でき、URLの失効とサーバー自体の障害を切り分けられます。接続の基本手順をやり直す場合は使い方ガイドに戻ってください。原因が分からないまま設定を何度も変更しないでください。

02 · Add Server：プロトコルごとに手動入力項目を確認する

手動追加は、1台分の完全なサーバー情報を入手している場合に適しています。Add Serverを開き、まずTypeを選んでから、アドレス、ポート、認証情報を入力します。プロトコルごとに必要な項目は異なり、同じ「パスワード」という名称でも、別のプロトコルで必要なUUID、鍵、認証文字列の代わりにはなりません。必要な項目が見つからない場合は、元の案内を確認してください。名称が似ているからと推測したり、別のサーバーで使えた認証情報を流用したりしないでください。

共通項目を確認してから、プロトコル固有の違いを確認する

サーバーアドレスにはホスト名またはアドレスのみを入力し、WebページのURL全体をアドレス欄に貼り付けないでください。ポートは提供された情報に従い、別の欄に入力します。メモは識別用で、接続認証には使われません。「用途・提供元・通信方式」などを組み合わせて記録できますが、パスワードは名前に含めないでください。アドレスが同じでもポートが異なれば、別のサービスである可能性があります。逆に、名前が異なる2つの項目が同じ接続情報を使っている場合もあります。重複を確認するときは詳細を見てください。

認証項目は一字ずつ確認してください。コピー時に空白が混じっていないか、似た文字を取り違えていないか、長い文字列がメッセージアプリで切れていないかにも注意します。パスワード欄が黒丸で表示されていても、正しくコピーできたとは限りません。不安な場合は自分の元データから貼り直してください。UUIDも普通のメモのように書式を変えないでください。アドレス、ポート、認証を確認したら、最後にTLSとトランスポート層を確認します。一度に多くの項目を変更すると、原因を特定しにくくなります。

Type確認する項目よくある取り違え
Shadowsocksアドレス、ポート、パスワード、暗号化方式暗号化方式はサーバー側の設定と一致させる
VMess / VLESSUUID、通信方式、TLSと関連項目Typeを変更するだけではプロトコルを変換できない
Trojanパスワード、TLS、サーバー名接続先アドレスとTLSの検証用サーバー名は異なる場合がある
HTTP / SOCKS5アドレス、ポート、認証の要否認証が必要かどうかはサーバー側の設定で決まる
WireGuard鍵、アドレス、接続先、ルーティング項目鍵を通常のパスワードで代用できない
Hysteria2認証、TLS、UDPの到達性ローカルネットワークの制限が接続に影響することがある

TLSとトランスポート層：名称が似ていても役割は異なる

接続先アドレスはサーバーを見つけるために使います。TLSのサーバー名はハンドシェイクと証明書の検証に使われ、HTTP通信のHostはアプリケーション層のルーティングに使われる場合があります。一部の設定ではこれらの値が同じでも、常に置き換え可能というわけではありません。サービス情報に個別のサーバー名、パス、通信方式が指定されている場合は、それぞれの項目に入力してください。パスの先頭のスラッシュ、大文字・小文字、クエリ部分もサーバー側の識別に影響することがあります。読みやすさのために省略しないでください。

証明書エラーが出た場合は、まずサーバー名、デバイスの時刻、サーバー側の証明書の状態を確認してください。検証をスキップする設定を通常の解決策として使わないでください。証明書の検証失敗とパスワードエラーでは、確認すべき内容が異なります。前者はハンドシェイク時の接続先の識別、後者は認証情報を確認します。現在のネットワークからサーバーのポートに到達できない場合、認証項目を変更しても解決しません。ネットワーク、ハンドシェイク、認証、実際のリクエストの順に確認すると、関係のない設定を繰り返し切り替えるより、原因を絞り込みやすくなります。

保存後の検証と変更時の注意点

保存前に、Typeが元の情報と一致しているかもう一度確認してください。保存後はこのサーバーだけを選んでテストし、Configファイルやローカルネットワークを同時に変更しないでください。追加した項目がサブスクリプション由来の場合は、まずサブスクリプションを更新して正しい情報を取得できるか検討します。サブスクリプションから生成された項目を直接編集すると、次回の更新で上書きされる場合があります。比較テストが必要な場合は、手動項目を別に残し、メモに一時的な確認用であることを記録してください。実験結果をサブスクリプションの元データと取り違えにくくなります。

手動入力では、不明な項目が自動で補われることも、入力した組み合わせをサーバーが受け付けるか検証されることもありません。保存できたとしても、アプリが入力形式を受け付けたことを示すだけです。接続に失敗した場合は、発生した段階とエラーを記録してから、情報の追加が必要か判断してください。UUID、トランスポート層、TLSの関係についてはVMessとVLESSの設定項目ガイドを、プロトコル名の確認には用語集をご覧ください。設定全体を変更する必要はありません。

03 · QRコードとクリップボード：コピー時のミスを減らす

QRコードとクリップボードは入力方法にすぎず、読み取る内容がサブスクリプション、サーバー、Configのどれにあたるかは決まりません。QRコードには単一サーバーのリンクが含まれている場合も、通常のWebページURLだけが含まれている場合もあります。クリップボードのテキストも同様です。追加前に入手元と用途を確認し、追加後に作成された項目を確認してください。成功メッセージが表示されても、現在のネットワークで使える設定とは限らず、アドレス、認証、通信設定の確認も必要です。

読み取り前：QRコードに含まれる情報を確認する

QRコードを読み取る前に、すでに入手しているサーバー情報に基づくものか、対応する案内と一致しているか確認してください。Scan QR Codeを使うときは、システムの案内に従ってカメラへのアクセスを許可します。カメラを起動できない場合は、システム設定でアクセス権を確認してから、アプリで再試行してください。別のデバイスに表示したQRコードを読み取る場合は、明るさと距離を調整し、周囲の枠をすべて画面に収めてください。反射、端の欠け、過度な圧縮、ぼやけた拡大表示は読み取りに影響します。画像認識の問題をサーバー設定の変更で解決しようとしないでください。

QRコードが現在のデバイス内の画像にある場合は、アプリの現在の画面に画像から読み取る方法があるか確認してください。表示されていない場合は、現在の画面にないボタンを探す必要はありません。元の資料にテキストリンクがあれば、クリップボードから追加し、保存後に各項目を確認できます。読み取りにくいからといってQRコードを公開の読み取りサービスにアップロードしないでください。QRコードにはパスワード、鍵、完全なサブスクリプションURLが含まれる場合があり、画像を公開することはテキストを公開するのと同様の漏えいリスクがあります。

クリップボードからの追加：一度に扱う内容を1種類にする

コピーするときは元資料にあるコピー機能を使い、手動選択で先頭や末尾を取りこぼさないようにします。Shadowrocketに戻ったら、現在の画面にあるクリップボードからの追加機能を使い、システムの案内に従って読み取りを許可してください。想定した案内が表示されない場合は、クリップボードにコピーした内容が残っているか確認します。アプリ切り替え後に別のテキストをコピーしたり、デバイス間でクリップボードを同期したり、画像をコピーしたりすると、元のテキストが置き換わることがあります。

複数のリンクを含むテキストには、番号、箇条書き、説明文が混ざりやすいため注意してください。まず確認済みのリンクを1つだけ追加し、項目が正しいことを確認してから残りを処理します。テキスト全体が認識されない場合は、リンク内の記号を直接書き換えるのではなく、コードフェンス、引用符、メッセージの引用記号が含まれていないか確認してください。改行の扱いは形式によって異なります。判別できない場合は、元資料から単独のリンクを取得し、複数行を無理に1つのアドレスに結合しないでください。

追加後に行う3つの確認

1つ目は項目の種類です。サブスクリプションを追加した場合は、更新可能な登録が作成されているか確認します。単一サーバーを追加した場合は、対応するサーバーが表示されているか確認します。2つ目は主要な設定項目です。少なくともType、アドレス、ポートを確認し、次に認証と通信設定がそろっているか確認してください。3つ目は一覧内の所属先です。別のサブスクリプションや重複したテスト項目に紛れ込んでいないか確認します。名前が同じでも結果が完全に同じとは限らず、名前が異なっていても別のサーバーとは限りません。

QRコードを繰り返し読み取って複数の項目ができた場合は、動作確認済みのものを残し、ほかの項目を比較してから整理します。確認が済む前に既存の項目をすべて削除しないでください。読み取りで項目が作成されても接続できない場合は、同じQRコードを何度も読み取るのではなく、設定項目とネットワークを確認します。QRコードの読み取り、リンクの解析、接続の確立はそれぞれ別の段階です。最初の段階を繰り返しても、3番目の段階の問題は解決しません。

権限は用途ごとに管理してください。カメラはQRコードの読み取りに、クリップボードは自分でコピーした内容の読み取りに使います。どちらもシステムのVPN構成に対する許可とは別の権限です。追加が終わった後に権限を制限する場合は、システム設定で変更できます。その後、対応する機能を使う際に再度確認してください。初回接続と許可ダイアログの流れは使い方ガイドを、項目が作成されたのに使えない場合は接続トラブルの確認手順をご覧ください。権限を何度もリセットする必要はありません。

05 · 更新方法：変更前に元へ戻す手段を確保する

サブスクリプションの更新は、リモートの内容を再取得してローカルの一覧に反映する処理です。各サーバーを修復する機能ではなく、現在使用中のサーバーが残ることを保証するものでもありません。更新前に、現在選択している項目、所属するサブスクリプション、その名前に依存する設定があるかを確認してください。更新を制御したデータ変更として扱い、結果を確認してから古い項目を整理します。接続に問題があるときに続けて更新するより、原因を特定しやすくなります。

手動更新が役立つ場面

サービス情報が明確に変更された場合、一覧に必要な項目がない場合、サブスクリプションを引き続き読み込めるか確認したい場合は、手動で更新できます。更新前にサブスクリプション名と現在の選択項目を記録し、更新後に項目の追加、削除、名前の変更がないか確認します。自動更新の設定がある場合は、実際の画面から選択してください。特定の更新間隔がすべてのユーザーに適しているとは限りません。更新頻度はURLの利用条件と自分の使い方に合わせてください。

更新頻度を上げても接続が安定するとは限りません。リモートの一覧に変更がなければ、繰り返し取得しても同じ内容が返るだけです。サーバーのポートに到達できない場合も、更新で改善するとは限りません。まず一覧の古さが原因か判断し、その後で更新するか決めてください。手動で登録したサーバーにはサブスクリプションとの関係がないため、別のサブスクリプションを更新しても情報が同期されることはありません。元の資料の設定が変更された場合は、その情報に対応する管理方法で更新してください。すべての一覧を何度も操作する必要はありません。

更新に失敗した場合：エラーを確認してからアクセス経路を選ぶ

更新は、現在のネットワーク経路からサブスクリプションのホストにアクセスして行います。ローカルネットワークから直接アクセスできる場合もあれば、現在の接続状態が結果に影響する場合もあります。失敗したら、名前解決エラー、接続タイムアウト、認証失敗、内容を認識できない状態のどれに当たるか記録してから該当箇所を確認してください。「更新失敗」という表示だけを見てルーティング設定をすべて切り替えないでください。アクセス経路を変更するときも一度に一つだけ変更し、再試行後に結果を確かめます。どの変更が影響したか分かりやすくなります。

URLにアクセスできてもログイン画面、アクセス制限、空の内容が返される場合、原因がアプリの解析とは限りません。サブスクリプションURLの個人用アクセス情報が変更されたか、リモート側が一時的にエラーページを返している可能性があります。元のURLは秘密の場所に保管し、サービス提供元に状態を確認してください。エラーページをConfigファイルとして保存したり、ページ内にある似た形式の文字列からサーバーを作成したりしないでください。内容の形式が異なるときは、サーバーのポートを変更しても解決しません。

上書き、名前の変更、一覧が消えた場合の確認

サブスクリプションから生成された項目は、できるだけリモートの情報に合わせてください。認証、通信設定、メモを直接変更すると、更新時に上書きされたり、自分でも分かりにくい差異が生じたりする場合があります。長期的に残す独立したテスト項目は、手動で作成し、元のサブスクリプションとは分けて明確な名前を付けてください。更新後に何が変わったかをリモートの内容と照合しやすくなり、ローカルの一時変更をサービス提供元の設定と誤認しにくくなります。

更新後に一覧が大幅に減ったり、説明文だけになったりした場合は、それ以上の整理をいったん止めてください。元のサブスクリプションが残っているか、現在の選択項目が消えたか、更新結果がサービス情報と一致するか確認します。一覧を元どおりに見せようとしてサブスクリプション全体をすぐ削除すると、URLと所属を示す手がかりも失われます。URLを変更する場合は、新しい登録を追加し、一覧の展開と接続結果を確認してから古い登録を残すか判断してください。古い認証情報が失効している場合は、自分のバックアップにもその旨を記録します。

アプリの更新、サブスクリプションの更新、Configの更新は別々の処理です。アプリはApp Storeで更新し、サブスクリプションの更新ではサーバー一覧を読み込み、Configの変更はルールや関連設定に影響します。実施した時期が近くても、いずれかの処理が他の処理を自動で完了させるわけではありません。問題を調べるときは「何を更新したか、更新前の状態、更新後の状態」を記録してください。「更新後に使えなくなった」とだけ伝えるより原因を特定しやすくなります。アプリの入手と更新についてはApp Storeダウンロードガイドをご覧ください。

06 · 複数サブスクリプションの整理：所属先を確認してから重複を扱う

複数のサブスクリプションを管理する際は、一覧をできるだけ短くすることより、各サーバーの入手元を把握できる状態にすることが重要です。名前、地域の説明、遅延が似ていても、重複とは限りません。同じサブスクリプション内の複数のサーバーが、アドレスを共有しながら異なるポート、認証、通信設定を使っている場合もあります。整理前にサブスクリプションごとの所属を確認し、接続情報を比較してください。用途の異なる項目を誤って削除しないためです。

継続して使える名前の付け方

サブスクリプションのメモには「普段使い」「予備」「テスト」などの変わりにくい内部ラベルを使い、見分けやすい入手元の略称を添える方法があります。名前は用途を区別するために使い、パスワード、完全なサブスクリプションURL、個人を特定する情報は含めないでください。サーバー名はリモート側で付けられていることが多く、更新後に変わる場合があります。重要な項目を名前だけで管理しないでください。よく使うサーバーについては、所属するサブスクリプションや主要な接続設定も別に記録しておくと、移行時に確認しやすくなります。

見た目を整えるために、サブスクリプションから生成されたすべての項目を何度も改名しないでください。更新で変更が上書きされたり、名前に依存する自分の設定との対応が崩れたりすることがあります。サブスクリプションの階層を先に整理し、サーバー名は元のまま残す方法が安全です。テスト用には独立した手動項目を使い、一時的な説明を記録してください。名前に地域名や回線名があっても、提供元が付けた表示にすぎません。実際の設置場所、性能、現在の利用可否を示すものではありません。

重複確認で比較する項目

まずType、アドレス、ポートを比較し、次に認証、TLSのサーバー名、通信方式、関連項目を確認してください。すべて同じ項目は重複インポートの可能性がありますが、異なる更新関係に属していないか確認が必要です。2つのサブスクリプションに同じサーバーが含まれている場合、一方を削除すると、その入手元から今後配信される変更情報も失う可能性があります。どれを残すかは、現在の一覧が重複して見えるかどうかではなく、自分の管理上の必要性で判断してください。

名前が重複している場合でも、先にまとめて削除し、記憶を頼りに作り直すのは避けてください。サブスクリプションを1つずつ選び、各項目の特徴を記録して確認してから次に進みます。失効した項目の原因を追跡する必要がある場合は、秘密のメモを残してから削除するか判断してください。一覧に表示される状態メッセージも、サーバー項目とは別に見分けましょう。アカウントや利用状況を示している場合があり、すべてを「接続できないサーバー」として扱ったり、それを根拠に実際のサーバーがすべて使えないと判断したりしないでください。

確認できた状況最初に確認する項目その後に判断すること
名前が完全に同じ所属先、Type、アドレス、ポート別のサーバーかどうか
設定が同じに見える認証、通信設定、更新関係両方の入手元を残す必要があるか
更新後に名前が重複したリモート側の変更と古い手動項目テスト用の複製を整理するか
テストに失敗した項目テスト方法とネットワーク状況削除せず保留するか

一覧の整理はルーティングの変更ではない

順番の変更、メモの編集、重複項目の削除は、主に管理方法に影響します。実際のリクエストの処理は、Global Routingと現在のConfigにも左右されます。サーバーが一覧の先頭にあっても、すべてのリクエストがそのサーバーを使うとは限りません。Configを使用しているとき、DIRECTに一致するリクエストは引き続きルールに従って直接接続します。Proxyを選択している場合も、選択中のサーバーが使用したいものか確認してください。一覧を整理した後は、選択状態をもう一度確認します。

複数のサブスクリプションがあっても、アプリがすべての項目から自動的に最適なサーバーを選ぶとは限りません。自動選択や切り替えが行われるかは、現在の設定と関連機能によって異なります。一覧の数だけから判断しないでください。結果を確認しやすくするには、まず1台を明示的に選んで検証してから、複雑な選択方法を検討します。テストに失敗した項目を複数のサブスクリプションに繰り返しコピーしても、重複が増えるだけでサーバー側の状態は変わりません。

整理を終えたら、短い確認を行います。サブスクリプションURLが保存されていること、重要なサーバーを識別できること、現在の選択項目が正しいこと、独立したテスト項目に分かりやすい名前が付いていることを確認してください。デバイスを変更する場合は、必要なConfigと更新関係も記録します。少しずつ整理する方が、一度に大量の項目を削除するより元に戻しやすくなります。用語が分からない場合は用語集を、初回接続については使い方ガイドのトラブル対処をご覧ください。理解する代わりに削除しないでください。

07 · Connectivity Test：遅延と並べ替えの結果を理解する

遅延テストはサーバーの応答を大まかに比較するのに役立ちますが、実際の通信速度、長期的な安定性、特定のWebサイトへのアクセスを単独で判断するものではありません。テスト方法によって測定する段階が異なります。アドレスやポートへの到達性を中心に確認するものもあれば、より多くのリクエスト処理を含むものもあります。Connectivity Testの現在の設定を確認し、何を測定しているか把握してから結果を見てください。数値が小さくても、認証が正しいことや、その後の通信が継続できることを保証しません。

テスト前に条件をそろえ、結果と状況を記録する

複数のサーバーを比較するときは、できるだけ同じローカルネットワーク、同じテスト方法、近い時間帯で実行してください。テスト中にWi-Fiからモバイル通信へ切り替えると、ネットワークの変化が結果に混ざります。バックグラウンド処理、電波の変動、ネットワークの混雑も結果に影響します。最初は候補を少数に絞り、何度か確認してから範囲を広げてください。一度の結果を恒久的な順位と見なしたり、数値を下げるために無関係な設定を変え続けたりしないでください。

一括テストでは複数のリクエストが同時に発生するため、ローカルネットワークやリモート側の処理能力に制限があると、単独テストより結果が不安定になることがあります。単独では正常なサーバーが一括テストで時々失敗する場合は、対象を減らして再確認してください。すべての項目が同時に失敗する場合は、まずデバイスが正常にインターネットへ接続できているか、テスト先が現在の環境に適しているか、テスト方法に制限がないかを確認します。すべてのサーバーが使えなくなったとすぐに判断しないでください。

タイムアウト、認証失敗、実際のリクエストの異常を区別する

タイムアウトは、今回のテストが所定の待機時間内に想定した結果を得られなかったことを示しますが、原因を直接示すものではありません。アドレスの名前解決、ポートへのアクセス、通信のハンドシェイク、テスト先の応答などが関係することがあります。明確な認証エラーが表示された場合は、パスワード、UUID、その他の認証情報を重点的に確認してください。サーバーへの接続は確立できても特定のWebサイトにアクセスできない場合は、ルール、接続先ドメイン、DNS、TLSなどを調べます。遅延の数値だけを見て操作を続けないでください。

実際の使用状況を確認するには、自分が知っていてアクセスが許可されている通常のページを選び、ページ全体が開くか、連続したリクエストが安定するか、特定の接続先だけで問題が起きるかを確認します。システムに接続中と表示されただけで確認を終えないでください。システムの状態はローカルの接続機能が有効であることを示しますが、すべてのリモートリクエストの成功を意味しません。キャッシュ済みのページが表示されてもネットワークが正常とは限りません。新しいリクエストと、アプリに表示される接続情報も合わせて確認してください。

並べ替えは候補の絞り込みに使い、選択と検証の代わりにはしない

遅延順に並べ替えたら、どの一覧が並べ替えられたか、現在の選択項目が変わったかを確認してください。表示位置が変わっても、接続先が変わるとは限りません。最上位の項目がすべてのリクエストに適しているとも限りません。応答が安定している候補から1台を選んで実際に検証し、予備も1台残しておくとよいでしょう。結果を固定の性能評価として記録するより、テスト時のネットワーク状況を記録する方が参考になります。

アクセス結果の判断にはGlobal Routingも影響します。Configを使用している場合、接続先がDIRECTに一致することがあり、ページが正常に開いても選択したサーバーが使える証明にはなりません。特定のプロキシ接続を確認する場合は、テスト対象に適用されるルールも確認してください。ルーティング状態の切り替えは、検証する範囲を明確にするためだけに使います。テスト後は必要な設定に戻し、一時的な設定を忘れてその後の通信方法が変わらないようにしてください。

通信速度の低下と遅延の増加には関係がありますが、同じ問題ではありません。小さなリクエストにすぐ応答しても、継続的な通信では回線の混雑、パケットロス、サーバー負荷、ローカルネットワークの影響を受ける場合があります。まず単一サーバーを再確認し、次に時間帯や接続ネットワークを変えて比較し、最後にプロトコルと通信設定を確認してください。各段階の結果を残します。詳しい切り分け方法はShadowrocketの通信速度が遅いときの4段階チェックをご覧ください。サブスクリプションを繰り返し更新しても、この検証の代わりにはなりません。

08 · 削除とバックアップ：復元する範囲を明確にする

削除する前に、対象が単一サーバー、サブスクリプション全体、Configファイルのどれか確認してください。影響範囲はそれぞれ異なります。単一サーバーを削除すると一覧だけが変わる場合があります。サブスクリプションを削除すると、管理上の関係も一緒に失われることがあります。Configを削除すると、ルールの選択に影響する可能性があります。関連する動作はアプリに表示される現在の確認メッセージに従ってください。バックアップと検証なしに複数の階層を続けて削除しないでください。一覧を消去することは、あらゆる接続問題に共通する解決策ではありません。

スクリーンショットだけでなく、復元用の情報をまとめる

バックアップには、復元に必要なサブスクリプションURL、個別に追加したサーバーの設定、使用中のConfig、重要な環境設定の説明を含めてください。スクリーンショットは画面の識別には役立ちますが、パスワード、鍵、長いURL全体が写らない場合が多く、元の情報の代わりにはなりません。サブスクリプションは、再度一覧を取得できるURLを残します。手動追加のサーバーは、認証情報と通信設定も完全に記録してください。名前とポートだけでは復元できません。

アプリにエクスポートまたはバックアップ機能がある場合は、保存する対象と含まれる情報を確認してから、自分が管理する安全な場所に保存してください。ファイル名に「バックアップ」とあっても、必要な情報がすべて含まれているとは限りません。デバイスのシステムバックアップが必要な項目をすべて保存するとも限りません。現在の環境を損なわないようにファイルの内容を確認するか、管理された手順で復元を検証する方法が確実です。重要なサブスクリプションと個別項目を本当に復元できるか確認してください。

削除した項目が再び表示されることがある理由

サブスクリプションから生成されたサーバーは、リモートの一覧で管理されます。そのうち1件だけを削除しても、次回更新時に同じ項目が再作成される場合があります。削除に失敗したのではなく、更新によってリモートの内容が再同期された可能性があります。サブスクリプションが不要になった場合は、URLが安全に保存されていることと、現在の接続がそのサブスクリプションに依存していないことを確認してから登録を整理してください。一時的にサーバーを使いたくないだけなら、選択先の切り替えと項目の削除は別の操作です。使用を停止するためにすぐ削除する必要はありません。

削除前に、使用中のConfigが特定のサーバー名や選択関係に依存していないか確認してください。項目を削除しても、元のルールと同じ動作が自動的に引き継がれるとは限りません。削除後はGlobal Routing、現在のConfig、選択中のサーバーを確認し、実際のリクエストをテストします。一覧に予期しない変化が起きた場合は、それ以上の操作を止め、ローカルバックアップや元のサブスクリプションから復元できるか確認してください。同じ確認作業中に残りの手がかりまで消さないようにします。

デバイス移行後の復元：まず一部を確認してから残りを追加する

新しいiPhoneまたはiPadでは、まずApp Storeからアプリを復元し、必要なシステム権限を確認します。システム要件と購入の適用条件はApp Storeページの記載をご確認ください。アプリの購入済み復元と、サブスクリプション、サーバー、Configの復元は別の作業です。アプリを再入手しても、すべての接続情報が戻るわけではありません。具体的な手順は購入済みアプリの復元ガイドをご覧ください。移行の準備中に旧デバイスを消去せず、設定項目の確認と切り戻しに使える状態で残してください。

情報を復元する際は、まずサブスクリプションを1つ追加し、一覧が正しく展開されるか確認します。次に手動登録した項目を復元し、最後に必要なConfigを選んでGlobal Routingを確認してください。実際の接続を一度確認してから、ほかのサブスクリプションと環境設定を追加します。この順序なら、問題が起きたときにどの段階で変化が加わったか特定しやすくなります。すべての情報を一度に復元し、ネットワークやルールも同時に変更すると操作は早くても、バックアップと新しいデバイス環境のどちらに原因があるか分かりにくくなります。

復元後は、選択中の項目、サブスクリプションの更新、テスト方法、実際のリクエストを確認してから、古い情報の扱いを決めてください。サブスクリプションURLや認証情報が公開された可能性がある場合は、サービス提供元から新しい情報を入手し、バックアップも更新します。ローカルのコピーを削除しても、漏えいした認証情報は無効になりません。最後に、情報の種類と復元順だけを記した簡潔な非公開の復元メモを残してください。公開メモに機密情報を保存しないでください。次回すぐに接続を確認するときは使い方ガイドで基本手順を確認し、このページで各項目と管理方法を調べられます。