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

01 / Subscribe

Subscribe：更新可能なサブスクリプションを追加する

サブスクリプションは、繰り返しアクセスできるリモートURLで、取得した内容からサーバー項目が作成されます。単一サーバーの共有リンクとは異なり、接続先を決めるConfigの設定ファイルとも別物です。インポート前に、手元の情報がどれに当たるか確認しましょう。サーバー一式を取得するURLならSubscribeを使い、プロトコル名で始まる単一の共有リンクならサーバーとしてインポートします。Webページ、アカウントページ、説明ページのURLをSubscribeに入力しても、ページが開けることと、内容を解析できることは別です。

保存前にURLとメモを確認する

Homeの追加メニューからAdd Serverを開き、TypeをSubscribeにしてサブスクリプションURLを入力します。画面のレイアウトによっては、種類をリストから選ぶ場合もあります。保存対象が任意のサーバープロトコルではなく、Subscribeになっていることを確認してください。メモには「個人用」「予備テスト」など用途を記し、認証情報をそのまま書かないようにします。貼り付けた後は、URLの先頭と末尾、疑問符、区切り記号を確認し、引用符、改行、文末の句読点が混入していないことを確かめてから保存し、初回の取得が完了するまで待ちます。

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

上記のURLは構造を示す例であり、実際のサービスを提供するものではありません。パスはリソースを指定し、疑問符の後ろにはクエリパラメーターが続きます。パラメーター名と値はそのまま保持し、例を参考に自分のURLを書き換えないでください。サブスクリプションURLはアクセス認証情報として機能することがあり、知っている人がサーバー情報を取得できる可能性があります。完全なURLを公開スクリーンショットやメモのタイトル、問い合わせ本文に載せないでください。構造を説明するときは、例示用ドメインと仮の値に置き換え、記号の位置だけを保ちます。

初回取得後に確認すること

保存の成功と取得の成功は別の状態です。まずサブスクリプションの配下にサーバーが表示されるか確認し、項目の種類、メモ、件数の変化が想定どおりかを確認します。件数は端末上での確認に使うもので、品質を示すものではありません。エラーが表示された場合は、同じサブスクリプションを何度も追加せず、エラーの原文を記録してください。サーバーが表示されても、接続済みとは限りません。Homeでデフォルトのサーバーを選び、Global Routingを確認したうえで、実際のリクエストを試します。初回接続の手順ははじめにに戻り、順番に実行してください。

取得に失敗した場合は、URL、ネットワーク、応答内容の順に確認します。まず元のURLと照合し、認証情報が期限切れになっていないか、変更されていないかを確かめます。次に、現在のネットワークからサブスクリプションURLにアクセスできるかを確認し、最後に、返された内容がサーバーデータなのか、ログインページやエラーページなのかを見分けます。確認のために、URLを見知らぬオンライン解析ツールへ入力しないでください。このサブスクリプションだけ失敗する場合は、エラー文と発生条件を記録します。すべてのネットワークリクエストに異常があるなら、まず端末のネットワークを確認し、同じネットワークの問題を複数のサブスクリプションの同時失効と誤認しないようにします。

サブスクリプションと接続状態は分けて管理する

サブスクリプションを更新するとサーバー情報を再取得できますが、現在のサーバーが使えることを保証するものではなく、あらゆる接続問題を解決する操作でもありません。サーバーが使えない場合は、同じサブスクリプション内の別のサーバーと比較してから、更新するか判断します。サブスクリプションはリモートの一覧を取得する入口、サーバーは接続パラメーター、Global Routingはそのパラメーターをリクエストにどう適用するかを決めます。この3つを分けて考えると、URLの修正、サーバーの切り替え、ルールの確認のどれが必要か判断しやすくなります。

02 / Add Server

Add Server：項目ごとに手入力内容を確認する

手入力は、サーバー情報がすべてそろっている場合、インポート結果を確認する場合、または少数の独立した項目を管理する場合に適しています。まずAdd Serverで正しいTypeを選び、その種類に表示される項目を入力します。Typeによって各パラメーターの意味が決まるため、適当なフォームに入力してから名前を変えてプロトコルを切り替えることはできません。入力を始める前に、アドレス、ポート、認証情報、TLS、トランスポートの要件を分けて整理します。情報が不足している場合は先に確認し、「一般的な初期値」で不足項目を補わないでください。保存できても、ハンドシェイクに失敗することがあります。

共通項目と認証項目

Addressにはホスト名またはIPアドレス、Portには対応するポート番号を入力します。共有リンク全体をAddressに入力したり、ホスト名の後ろにポート番号を重ねて付けたりしないでください。プロトコルのプレフィックスを含むURLを受け取った場合は、共有リンクなのか、項目の説明なのかを先に確認します。メモは項目を識別するためのもので、接続には使われません。認証項目はTypeによって異なります。Passwordを使う場合もあれば、UUIDを使う場合や、ユーザー名や鍵が必要な場合もあります。認証情報をコピーする際は、大文字・小文字や区切り記号をそのまま保ち、前後に空白がないか確認してください。値を短くして試すのは避けましょう。

TLSとトランスポート方式は個別に確認する

TLSは該当する接続レイヤーの暗号化と認証を担い、トランスポート方式はデータの運び方を示します。互いに代替できるものではありません。手元の情報でTLSが必要とされている場合は、スイッチをオンにするだけでなく、サーバー名などの関連項目も確認します。WebSocketなどのトランスポートを使う場合は、PathとHostも確認してください。Pathの先頭のスラッシュやHostの綴りがリクエストに影響することがあります。選択したTypeによっては、対応する種類を選んだ後に表示される項目もあります。表示されていない項目をメモ、アドレス、パスワード欄に入力しないでください。

Address、TLSのサーバー名、トランスポート層のHostは、それぞれネットワーク接続、証明書検証、リクエストのルーティングを担う場合があり、3つの文字列が一致するとは限りません。インポート後に異なる値が表示されても、すぐ同じドメインに統一しないでください。手元の情報で明確に指定されている場合にだけ変更し、一度に変更する項目は1つにします。証明書エラーが発生した場合は、まず名前、端末の時刻、パラメーターがすべてそろっているかを確認します。検証を緩める設定を通常の対処法にしないでください。入力ミスを見逃し、認証の意味を損なうおそれがあります。

保存後の確認手順

まず分かりやすいメモを付けてテスト用の項目を保存し、選択してから接続します。保存できたことはフォームが受け付けられたことを示すだけで、アドレスへの到達、認証の成功、トランスポートの一致を証明するものではありません。まずConnectivity Testを確認し、次に実際のリクエストを行って、一部の接続先だけ失敗するのかを見ます。基本的な接続に問題がなく、特定のWebサイトだけ開けない場合は、認証情報を何度も変更せず、ルール、DNS、接続先の条件を確認してください。同じTypeの別項目が正常なら、項目を一つずつ比較します。パスワードやUUID全体を公開の問い合わせに載せないでください。

VMessとVLESSの項目の違いはUUID、暗号化、トランスポート方式の解説をご覧ください。WireGuardは確認項目が多いため、Private Key、Endpoint、MTUの解説も参照してください。手入力した項目は通常、個別のオブジェクトとして管理し、特定のサブスクリプションに合わせて同期されることを前提にしないでください。長期保存する手入力データは、検証後にバックアップし、どの項目が元の情報に基づくものか、どれが後から端末上で変更したものかを記録しておきます。

03 / Scan QR Code

QRコードとクリップボード：内容を確認してからインポートする

QRコードやクリップボードはテキストを受け渡す方法であり、独立したサーバープロトコルではありません。同じQRコードでも、単一サーバーの共有リンク、サブスクリプションURL、通常のWebページURLなどを含むことがあります。Scan QR Codeやクリップボードからインポートする前に、対象がどの種類の情報なのか把握し、結果を確認してください。手入力を省けても、内容の見極め、アクセス許可の確認、接続テストは必要です。出所が分かり、内容が完全な場合にのみ、そのままアプリに解析させてください。

Scan QR Codeの操作確認

アプリ内のScan QR Codeを開いてカメラを起動し、システムの案内に従ってカメラへのアクセスを許可してから、QRコード全体を読み取り範囲に入れます。コードの端まで収め、焦点を合わせ、光の反射を避けてください。読み取れない場合は、すぐにQRコードが無効だと判断せず、距離を調整します。以前にカメラへのアクセスを拒否した場合は、端末のシステム設定でShadowrocketのカメラアクセスを確認し、アプリに戻って再度試してください。システムカメラで通常の文字やWebページが認識されても、Shadowrocket内にサーバー項目が作成されたとは限りません。

QRコードが別の端末に表示されている場合は、そのままスキャンできます。現在使用中の端末に画像が保存されている場合は、画面上のインポート機能が画像認識に対応していることを確認してから使用してください。ほかのシステム機能の動作を、アプリの機能として期待しないでください。情報量が多いQRコード、圧縮画像、端が切れた画像は読み取れない場合があります。鮮明な元画像を使うか、元のテキストを直接コピーしてください。個人の認証情報を含むQRコードを公開の読み取りサイトにアップロードしたり、認識率を上げるために関係のない人へ何度も転送したりしないでください。

クリップボードからインポートできる内容

コピーするときは、「サーバーアドレス：」などのラベル、コードブロック、説明文を含めず、リンクだけを選択してください。アプリに戻って対応するインポート機能を使い、システムからペーストの許可を求められたら、今回自分で行った操作であることを確認して許可します。項目が表示されない場合は、元のテキストに戻って全体をコピーできたか確認してください。後からコピーした内容でクリップボードが上書きされたり、システムの許可がなく読み取りに失敗したりすることがあります。コピー完了の表示だけで、インポートも完了したと判断しないでください。

複数行のテキストは、各行が完全な情報であり、現在のインポート方法が一括処理に対応していることを確認してください。画面表示上の折り返しであれば、通常は自分で改行を入れる必要はありません。実際に空白や改行を挿入すると、URIが壊れる場合があります。一部だけインポートに成功した場合は、失敗した項目の元のテキストを残し、端末上で一つずつ構造を確認してください。抜けを探すために一括で何度もインポートすると、成功した項目が重複し、新しく追加したものと以前の記録を見分けにくくなります。

インポート後に対象と項目を確認する

インポート後は、まず結果がどこに表示されるか確認します。Subscribeが追加された場合は、サブスクリプションURLや今後の更新を管理できます。単一のSERVERが追加された場合は、そのプロトコルの設定項目を開けるはずです。次にType、Address、Port、メモ、TLSやトランスポート関連の内容を確認します。リンクの一部から生成されたメモは識別用の文字列にすぎず、接続テストに合格したことを示しません。同じ名前の項目がある場合は、リストのタイトルだけで古い項目を上書きせず、設定の違いを確認してください。既存の使用可能な項目は、新しい項目の検証が終わるまで残しておくのが安全です。

認識に失敗した場合は、問題を3つに分けて確認します。カメラまたはペーストの許可が有効か、元のテキストが完全か、現在のインポート機能が対応する形式かを確認してください。テキストは取得できても解析できない場合は、次の章で共有リンクの構造を確認します。解析できても接続できない場合は、Add Serverの項目を見直します。問い合わせ時は、使用した操作、システムの許可画面が表示されたか、インポート結果、エラー文を記録してください。QRコードの元画像と完全なURIは機密情報として扱い、問い合わせと一緒に公開しないようにします。

04 / URI & Config

共有リンク：プロトコル、サブスクリプション、Configを区別する

サーバーの共有リンクは通常、プロトコルのプレフィックスで種類を示し、その後に接続に必要な情報が続きます。サブスクリプションURLは通常、複数の項目を取得するために使われます。Configファイルには、ルールやポリシーなど、接続動作に関する情報が含まれることがあります。どれもコピー可能なテキストに見えますが、インポート先や更新方法は異なります。まず対象を見分け、サーバーのインポート、Subscribe、Configのどれを使うか判断してください。ブラウザーで開けることを形式が正しい基準にしたり、ファイル名だけで応答内容を推測したりしないでください。

プレフィックス、パラメーター、メモの役割

共有リンクには、プロトコルのプレフィックス、認証情報、アドレス、ポート、クエリパラメーター、メモのフラグメントなどが含まれることがあります。ただし、プロトコルによってエンコード方法は異なります。一部は情報の一部をエンコードし、別のものはトランスポートやTLSの設定をパラメーターで表します。あるプロトコルの分解方法を別のプロトコルに流用したり、似た項目を共通の項目とみなしたりしないでください。URIを手動で編集する前に、まず元のテキストを保存します。元の情報から再インポートできることを確認してから試してください。

一般的なURI構造では、疑問符の後ろにクエリパラメーターが続き、区切り記号でパラメーターを分け、ハッシュ記号の後ろにはメモのフラグメントが続くことがあります。パーセントエンコードは、空白、日本語、その他の特殊文字を表すために使われる場合があります。エンコードされた文字列を見つけても、手動で削除せず、そのまま保持してください。メモが文字化けしていても接続パラメーターが誤っているとは限りません。逆に、メモが正常に表示されても認証情報が完全とは限りません。名前の表示と接続テストは分けて判断し、まず項目を検証してから識別しやすいメモへの修正を検討してください。

リンクの見た目だけでなく、インポート結果を確認する

同じプロトコルでも共有形式が異なる場合があり、トランスポート方式によって項目も変わります。解析後にTLS、Path、Hostが不足している場合は、手元のパラメーターと照合し、インポートが完全か確認してください。プロトコルのプレフィックスだけを根拠に、初期値を推測して追加しないでください。テキストを認識できない場合は、必要な情報がすべてそろっていればAdd Serverから手入力できます。元の情報が解析できないリンクだけで、必要なパラメーターがない場合は、形式の説明を先に確認してください。推測で一見完全に見える誤った項目を作らないようにします。

サブスクリプションURLから返される内容は、アクセス権、URLの有効性、サーバー側の設定によって異なる場合があります。リクエストの応答がWebページ、認証画面、空の内容なら、「サーバーのインポート件数が少ない」のではなく、解析可能なデータを取得できていない状態です。Webページ内の適当なボタンのURLをSubscribeに入力して試さないでください。元のサブスクリプションの説明、エラー文、現在のネットワーク環境を確認し、応答内容の種類を特定してから、URLを修正するか解析の互換性を確認するか判断します。

Configとサーバーリストの役割

Configのルールは接続の振り分けを決め、サーバー項目はプロキシ接続のパラメーターを提供します。以下はShadowrocketのConfigで使うルールの一部で、ルールの順序とポリシーキーワードを示す例です。サブスクリプションURLではなく、サーバーの認証情報も含みません。例にあるPROXYとDIRECTはルールのポリシー名で、サーバーリストのメモで代用できるものではありません。完全なConfigにはほかの部分も含まれる場合があります。例を貼り付ける前に既存ファイルをバックアップし、該当するルール領域に挿入することを確認してください。

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

最初のドメインルールを先に判定し、その後のGEOIPルールで該当するIPの地域条件を処理します。FINALは、前のルールに一致しなかった場合の最終ポリシーです。ルールには順序がありますが、サーバーリストの並べ替えは主に管理や選択のためのもので、仕組みが異なります。Global RoutingがConfigの場合は、現在のConfigルールに従ってリクエストが処理されます。ProxyまたはDirectを選ぶと、全体の処理方法が変わります。そのため、サーバーをインポートした後にアクセス結果が想定と異なる場合は、共有リンクを作り直すだけでなく、選択中のサーバーとGlobal Routingの両方を確認してください。

05 / Update

更新方法：変更を管理し、使える状態を保つ

サブスクリプションの更新では、元のリモートURLに再度アクセスし、取得した内容に応じて端末内の項目を調整します。サーバーの追加や古い項目の削除、同じ名前の項目の接続パラメーター変更が行われることがあり、名前の更新だけではありません。更新する前に、どのサブスクリプションを使っているか、どのサーバーを選んでいるか、サブスクリプション内の項目を端末上で変更したかを確認してください。個別の変更を残す必要がある場合は、アプリのエクスポートやバックアップ機能で保存します。リモート更新でローカル編集が必ず保持されるとは限りません。

手動更新で状態を確認する

初回利用時、URL変更後、または内容が古いと思われる場合は、まず結果を確認しやすい手動更新を1回行います。開始前に接続中かどうか、使用中のネットワーク、現在の項目の状態を記録し、完了後に明確なエラーがあったか、サーバーに変化があったか、以前選択していた項目が残っているかを確認してください。同時にURLを変更し、ネットワークを切り替え、何度も更新するのは避けましょう。復旧しても原因が分からなくなります。1回の操作ごとに結果を確認すれば、取得、解析、接続の3つの段階を区別できます。

自動更新は、安定して取得できることを確認したサブスクリプションに適しています。現在の画面に更新スイッチや周期の選択肢がある場合は、実際の利用頻度に合わせて設定してください。更新頻度が高いほどよいとは限りません。更新動作は端末のネットワーク、システムのバックグラウンド処理、アプリの状態に左右されることがあり、特定の時刻に実行されるとは限りません。アプリを長期間開いておらず、内容が古いと思われる場合は、自分で確認して手動更新を1回行い、接続を検証してください。自動更新を有効にしただけで、リストが必ず最新だと判断しないでください。

URLの誤りと取得経路の問題を区別する

更新に失敗したら、まずURLが現在も自分の有効なURLか確認します。特に、認証情報をリセットした後も古いURLを使っていないか注意してください。次に、現在のネットワークからサブスクリプションの応答を取得できるかを確認します。接続をオンにしたときだけ失敗する場合、またはオフにしたときだけ失敗する場合は、それぞれの条件を記録し、取得経路に依存していないか調べてください。特定の方法で常に更新する必要があると決めつけないでください。Configのルールや現在のサーバー状態がリクエスト経路に影響することもあります。固定のスイッチ設定を当てはめず、実際の結果に基づいて確認します。

エラー応答も種類ごとに判断します。接続タイムアウトは設定された条件の範囲内でリクエストが完了しなかったことを示します。認証エラーは通常、アクセス認証情報の確認が必要です。解析エラーは、取得した内容が想定の形式ではなかったことを示します。1回の失敗で保存済みサーバーがすべて使えなくなったとは限らず、サブスクリプション全体をすぐ削除する必要もありません。以前の項目で接続できる場合は、それらを残し、更新の問題を分けて対処します。エラーページに個人情報が含まれる場合は、エラーの種類だけを記録し、応答全体を公開しないでください。

更新後に選択状態とルールを再確認する

更新後、以前選択していたサーバーの名前が変わったり、別の項目に置き換わったり、削除されたりする場合があります。Homeに戻ってデフォルトの選択を確認し、よく使う項目を再テストしてから、実際のリクエストを確認してください。名前が同じでもパラメーターが同じとは限らず、遅延テストに問題がなくてもすべての接続先にアクセスできるとは限りません。特定の名前を参照する設定がローカルにある場合は、名前の変更が参照に影響していないかも確認します。重要な用途で使う直前に一括変更するのは避け、検証時間を確保してから古い記録を整理してください。

サブスクリプションの更新とアプリのアップデートは別の操作です。前者は既存サブスクリプションから取得するサーバー情報を更新し、後者はApp Storeでアプリ自体を管理します。購入、復元、互換性については正規入手確認ガイドをご覧ください。システム要件はApp Storeの製品ページをご確認ください。接続エラーの原因をすべてアプリのアップデートに求めたり、サブスクリプションを1回更新したことをアプリの動作が変わった証拠とみなしたりしないでください。何が変化したのかを特定し、更新前後の具体的な項目やリクエスト結果を比較します。

06 / Organize

複数サブスクリプションの整理：名前、重複、管理範囲

複数のサブスクリプションを使う場合、リストをできるだけ短くすることではなく、それぞれの出所、用途、管理方法を見分けられる状態にすることが重要です。まず、サブスクリプションから追加された項目と、端末上で手入力した項目を区別し、サブスクリプション自体には分かりやすいメモを付けます。「日常用」「一時テスト」「個人端末」など用途に基づく名前を付け、パスワード、ドメインの完全な一覧、サブスクリプションの認証情報をタイトルに記載しないでください。メモは選択の助けにはなりますが、項目の記録に代わるものではありません。名前が重複したり更新が行われたりしても、どのサブスクリプションか特定できるようにします。

2段階の名前付けルールを決める

1段階目はサブスクリプションのメモで、「このサーバー群は、保存したどの入口で管理されているか」を示します。2段階目はサーバーのメモで、「現在どの項目を選択しているか」を示します。リモートのリストに独自の命名ルールがある場合、端末上で多くの名前を変更する前に、次回の更新で名前が再生成されないか考慮してください。自分用の説明を残すには、個人用のメモで用途を管理するか、現在の画面で明確に提供されているメモ機能を使います。管理情報を長期間保存するために、リモートの項目へ余分な文字を追加するのは避けてください。

一時テスト用の独立した項目には、「テスト」と用途を明記し、検証後に残すか決めます。すべてを「よく使う」と名付けたり、数字だけの連番を付けたりしないでください。更新で新しい項目が追加されると、連番では実際の関係が分かりにくくなります。整理中は接続中のサーバーを維持し、サブスクリプションを1つずつ確認してください。一度の操作で全項目の名前変更、重複削除、デフォルト選択の切り替えをまとめて行わないようにします。段階的に処理すれば、問題が起きてもどの操作に戻ればよいか分かりやすくなります。

名前だけで重複を判断しない

同じ名前の項目でも、ポート、認証情報、トランスポート設定が異なる場合があります。名前が違っても、接続設定がまったく同じこともあります。重複かどうか判断するには、端末上でType、Address、Port、認証、TLS、トランスポートの各項目を比較してください。比較中に機密情報を公開の表へコピーしないでください。設定が同じでも2つのサブスクリプションに別々に登録されている場合は、更新元が異なります。一方を削除しても次回の更新で再び表示されるとは限らないため、どちらのサブスクリプションで管理するか先に決めてください。

サブスクリプション内で項目が重複している場合は、まず取得内容に由来するものか確認してください。更新のたびに再表示されるなら、端末上で削除してもリストが一時的に変わるだけです。同じサブスクリプションを重複してインポートした場合は、完全なURLと管理上の用途を確認してから、どちらを残すか決めます。メモが同じという理由だけで削除しないでください。整理する前に、デフォルトのサーバーが削除対象に含まれていないか確認し、検証済みの代替項目を用意します。現在の画面に明確な一括整理機能がない場合は、意味が不明な一括操作を試すより、一つずつ処理するほうが安全です。

表示順と実際のルーティングを分けて考える

並べ替えは項目を探しやすくするためのもので、先頭のサーバーが自動的にデフォルトになったり、障害時に自動で切り替わったりするわけではありません。表示順を変更した後も、Homeで選択状態を確認してください。Configのポリシーグループを使う場合は、そのグループ独自の選択ルールも確認します。サーバーリストの順序とポリシーグループの動作は別のものです。安定してよく使う項目は見つけやすい場所に置き、一時テスト用の項目は識別しやすくして、接続前に未検証の項目を選ばないようにしましょう。

認証情報を含まない個人用の管理リストを作り、サブスクリプションのメモ、用途、端末上で変更したかどうか、直近の操作結果だけを記録できます。ここでいう結果は、「実際のリクエストを確認済み」「トランスポート項目の確認が必要」など、自分で観察した事実にしてください。名前だけから利用可能か推測しないでください。詳しい手順は複数サブスクリプションのグループ分け、並べ替え、重複項目の整理をご覧ください。整理後は普段の利用環境でテストし、管理リストが分かりやすくなっただけでなく、接続状態も説明できることを確認します。

07 / Connectivity Test

遅延テストと並べ替え：結果の範囲を理解する

遅延テストは、現在のネットワークとテスト方法のもとで、特定の接続処理が完了したか、その所要時間がどれくらいかを確認するものです。継続的な通信速度とは異なり、特定のWebサイトやアプリが使えることを直接証明するものでもありません。結果を判断する前に、テスト方法、テスト対象、現在のネットワーク環境を確認します。方法が異なる数値をそのまま順位付けしないでください。タイムアウトもその時点での結果にすぎず、それだけでサーバーが恒久的に使えないと判断できません。再テスト、実際のリクエスト、ほかの項目との比較を合わせて確認します。

条件をそろえてから比較する

複数のサーバーを比較する場合は、できるだけ同じネットワーク、同じテスト方法、近い時間帯に測定し、片方はモバイルネットワーク、もう片方はWi-Fiという比較を避けます。テスト中は大容量通信など競合するトラフィックを減らし、普段使う項目から予備の項目へ順に測定してください。画面に複数の方法がある場合は、確認できる接続段階が方法によって異なることを理解しましょう。基本接続ができても、認証、TLS、トランスポート層、接続先へのリクエストまで完了したとは限りません。実際のリクエストに近いテスト方法は、通常より多くの段階を確認できますが、テスト対象の影響も受けます。

Connectivity Testと実際のアクセス結果を併せて確認する

サーバーを選択して接続をオンにしたら、Connectivity Testで疎通を確認し、実際に使いたいWebページやアプリも開いてみます。テストに成功しても接続先にアクセスできない場合は、Global Routingが想定どおりか、接続先が該当ルールに一致しているか、DNSの名前解決が正常かを確認してください。根拠がないまま問題の原因をすべてサーバーに求めないでください。逆に接続先にはアクセスできるのに特定のテストだけ失敗する場合は、テスト対象側の応答条件も考慮し、正常に動作している項目をテスト1回だけで削除しないようにします。

Global RoutingのConfigは現在の設定に従ってリクエストを処理し、Proxyはプロキシ経由、Directは直接接続で処理します。比較するときは、まず現在の状態を記録し、一度に変更する条件は1つだけにして、テスト後に必要な設定へ戻してください。モードによって結果の意味が変わります。Directでページが開けても、選択中のサーバーが使える証明にはなりません。Configでアクセスに成功しても、そのリクエストがDIRECTに一致していた可能性があります。サーバーを検証する場合は、テスト対象のリクエストが想定した経路を通っているか確認してください。

並べ替え後に選択状態を確認する

遅延順の並べ替えは、その時点の結果に基づいて表示を並べ直すだけです。数値が小さい項目でも、長時間の利用で安定するとは限らず、通信量が多いとも限りません。1回の最小値だけを見て頻繁に切り替えないでください。繰り返し測定しても結果が安定し、実際の利用でも問題のない項目を優先し、検証済みの予備を1つ残す方法が有効です。並べ替え後は、デフォルトの選択状態をもう一度確認してください。リストが長い場合や同名の項目がある場合は、見た目上の先頭が選択中とは限りません。

同じサーバーでもネットワークによって結果が大きく異なる場合は、パスワードを変更し続けず、ネットワーク条件を記録してください。更新後に一部の項目だけ失敗するようになった場合は、項目に変更があったか確認します。すべての項目に同時に異常が出た場合は、共通の条件を先に確認してください。障害の記録には、テスト方法、ネットワークの種類、Global Routing、エラーの原文、実際の接続先での結果を含められますが、サブスクリプションURL全体は記載しないでください。初回接続の確認順はデフォルトサーバー、接続スイッチ、Connectivity Testの確認表もご覧ください。基本手順の見落としを防げます。

08 / Backup & Remove

削除とバックアップ：対象を確認してから実行する

削除する前に対象を確認してください。単一のサーバー、Subscribe全体、Config内の設定ファイル、アプリ本体は、それぞれ別の階層です。復元に必要な情報も異なります。サーバーを削除してもサブスクリプションへのアクセス認証情報は無効になりません。サブスクリプションを削除してもリモートのリソースが解約されるわけではありません。バックアップの目的は、必要な端末上の状態を復元できるようにしながら、認証情報を適切に保護することです。誰でもアクセスできる場所に、すべての情報をそのままコピーすることではありません。

復元する対象に合わせてバックアップする

サブスクリプションから取得したリストだけを復元する場合は、有効なサブスクリプションURLと必要な説明を保存しておくほうが、項目を1つずつ書き写すより簡単です。ただし、URLが将来変更される可能性も考慮してください。手入力したサーバーを復元するには、完全なプロトコルパラメーターを保存するか、アプリのサーバー共有・エクスポート機能を使います。ルーティング動作も復元したい場合は、該当するConfigも別に保存する必要があります。サーバーリンクだけではルールは復元されません。現在の画面にあるバックアップ機能を使うときは、対象範囲の説明を読み、1つの機能ですべての設定が保存されると決めつけないでください。

バックアップには、サブスクリプションの認証情報、パスワード、UUID、鍵が含まれる場合があります。元の情報と同じレベルで保護してください。自分で管理でき、アクセス制限のある保存先に置き、「メモのみの一覧」と「完全な認証情報を含むバックアップ」を明確に区別することをおすすめします。公開共有リンクを長期バックアップとして使ったり、完全なサーバー情報を問い合わせに添付したりしないでください。構造を説明するためのコピーは例示用の値に置き換え、実際の復元用コピーは完全な状態で保ち、両者を混同しないようにします。

単一の項目を削除する場合とサブスクリプション全体を削除する場合の違い

サブスクリプションから追加された項目を1つ削除する前に、次回の更新で再作成されないか確認してください。端末内のサーバー一式を削除したい場合は、サブスクリプション全体の削除範囲を確認します。サブスクリプション全体を削除する際は、確認画面をよく読み、関連する項目も一緒に削除されるか判断してください。それぞれの対象に対する操作は互いに代用できません。表示中の項目を1つ削除してもサブスクリプションの更新が止まるとは限らず、端末内のデータを消しても、すでに漏えいしたリモートの認証情報は無効になりません。

現在選択中のサーバーを削除する前に、検証済みの別の項目へ切り替え、必要な接続を続けられることを確認してから古い項目を削除します。リストにその1つしかない場合は、先に復元用の情報を準備してください。「削除してから考える」という順序で操作しないようにします。一括整理では少数の項目から試し、結果を確認してから続けてください。パラメーターが異なる同名項目をまとめて削除するのを防げます。Configも個別にバックアップしてください。サーバーが残っていても、元のルールやポリシー設定の代わりにはなりません。

復元の手順とバックアップの確認

復元を始める前に、アプリをApp Storeから入手済みか確認してください。購入済みアイテムの復元方法は端末の買い替え・再インストール時の復元ガイドをご覧ください。購入履歴で復元できるのはアプリを入手する権利であり、サーバーやConfigが自動的に復元される保証ではありません。続いてサブスクリプションまたは手入力した項目を復元し、項目とデフォルトの選択を確認してから、必要なConfigを復元し、最後にGlobal Routingを確認します。この順序なら、接続に問題が起きた場合に該当する階層を特定しやすく、すべてのバックアップを一度に読み込んで競合を見分けられなくなる事態を防げます。

バックアップが完了したら、実際に読み取れることを確認します。エクスポート内容が空ではないか、サブスクリプションURLが完全か、独立した項目に必要な情報が含まれているか、Configが保存しておきたいものかを確認してください。元データを削除しなくても、範囲の確認、項目の照合、管理されたインポートなどで検証できます。管理されたインポートで重複項目が作られた場合は、復元データが有効だと確認してからテスト用のコピーを削除します。「以前バックアップした」と覚えているだけより、保存先に今もアクセスできるか定期的に確認するほうが確実です。

認証情報が公開されたことに気付いた場合、スクリーンショット、リンク、端末上の記録を削除するだけではアクセスのリスクを解消できません。利用中のサービスの管理方法に従って該当する認証情報を変更または無効化し、アプリ内のURLとバックアップも更新してください。日々の管理では、変更前に状態を保存し、変更後に接続を検証し、検証後に重複項目を整理して、最後にバックアップを更新するという順序を保つとよいでしょう。接続手順を最初から確認したい場合ははじめにへ戻ってください。よくある操作の疑問は接続スイッチ、Global Routing、サブスクリプション更新、購入済みアイテムの復元に関するQ&Aをご覧ください。一部の問題を解決するために、すべてのデータを作り直す必要はありません。