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

01 / SUBSCRIBE

Subscribe サブスクリプションの読み込み

サブスクリプションは、繰り返しアクセスできるサーバー情報の取得先であり、個々のサーバーのアドレスではありません。読み込み時にShadowrocketが取得先へアクセスし、対応する内容を解析してサーバー項目として表示します。その後、同じサブスクリプションを更新すると、項目が追加・削除・置き換えられる場合があります。管理時は「取得先」と「取得結果」を区別しましょう。取得先は次回のデータ取得元、取得結果はHomeで選択できるサーバーです。表示名だけでは、取得先が正しいか、内容が完全かは判断できません。

読み込み前に情報の種類を確認

利用者自身が用意した完全なサブスクリプションURLを準備し、アカウントページや説明ページのURL、単一サーバーの共有リンクではないことを確認します。取得先URLにはクエリパラメータが含まれる場合があり、それらもURLの一部です。コピー後、疑問符以降を削除したり、チャットアプリの説明文や句読点、改行まで一緒に貼り付けたりしないでください。資料に取得先とアカウントのログインページが記載されている場合、両者は別のものです。

Homeで追加画面を開き、Add ServerでTypeをSubscribeに設定してから、完全なURLを入力します。画面にサブスクリプション専用の追加方法がある場合は、そちらから進んでも構いません。サーバーのポートを手入力するのではなく、サブスクリプションURLを入力することが判断のポイントです。用途や自分で決めた識別子を使って、見分けやすい名前を付けて保存し、取得結果を待ちます。ボタンの位置や選択肢はアプリの現在の画面で確認し、アイコンの位置から機能を推測しないでください。

初回取得後に3段階で確認

まず、サブスクリプションが保存されているかを確認し、編集画面を開き直してURLが完全かを確認します。次に、サブスクリプション内にサーバーが表示されるかを確認し、成功メッセージだけでなく、名前、プロトコル、グループも見ます。最後に、項目を1つ選んで接続をテストします。サブスクリプションの保存、内容の解析、サーバーへの実際の接続はそれぞれ別の結果です。いずれか1つで残りを判断することはできません。

取得後にリストが空の場合も、既存の項目は残し、エラー表示と発生した段階を記録します。ブラウザでURLを開けても、解析可能なサブスクリプションが返されるとは限りません。ログインページ、アクセス制限の説明、空の応答が返される場合があります。反対に、ブラウザに読みにくいテキストが表示されても、それだけでデータが壊れているとは判断できません。アプリの解析結果と、利用者が持つ資料に記載された形式を照らし合わせてください。応答の全文を公開の掲示板に投稿しないでください。

サブスクリプションリストとルール設定は別

Subscribeは主にサーバー情報の取得と管理に使います。Configで有効にした設定は、ルールやポリシーなどの動作を決めます。サブスクリプションを読み込んでも、すべてのWebサイトが新しいサーバーを使うとは限りません。Global Routingの選択状態、実際に選択中のサーバー、設定内のポリシー参照も確認してください。初回接続を設定する場合は、サブスクリプションとルールを同時に変更するより、クイックスタート手順に沿って順番に確認すると、原因を特定しやすくなります。

同じリンクを繰り返し読み込むと、管理対象が複数作成され、その後の更新・削除・トラブル対応が複雑になることがあります。再追加する前に、リストに既存のサブスクリプションがないか確認し、まず更新を試してください。独立したテスト用コピーを残す必要がある場合に限り、用途が分かる名前を付けます。リストが空になるケースの確認方法は、サブスクリプションを読み込めない・リストが空のときの確認事項をご覧ください。すでに読み込んだ項目は、比較対象として使えるよう、原因を調べる前に削除しないでください。

02 / ADD SERVER

Add Server 手動入力する項目

手動追加は、利用者がサーバーの接続情報をすべて用意している場合や、個別の項目を確認したい場合に適しています。Add Serverで正しいTypeを選び、そのプロトコルに表示される項目を入力します。プロトコルの選択は単なる名前付けではありません。認証方式、データの形式、接続パラメータが決まります。パスワードを使うからといって、ShadowsocksとTrojanを入れ替えることはできません。ポートを変更しても、プロトコルを別のものに変えることはできません。

アドレス、ポート、認証情報を分けて確認

サーバーアドレスには通常、ドメイン名またはIPアドレスを入力します。項目の指定に従ってホスト部分を入力し、WebページのURLに含まれるパスをそのまま入れないでください。ポートにはサーバー側が待ち受けている番号を指定します。任意の数字を選ぶものではありません。備考は項目の識別用で、認証には使いません。ユーザー名を備考に入力したり、表示名をホスト名として使ったりしても、正しく接続できません。入力後はキーボードを閉じ、元の資料と各項目を照合してください。先頭と末尾の空白や、見た目が似た文字にも注意します。

プロトコルのパラメータは組み合わせて確認

Shadowsocksでは暗号化方式とパスワードの両方が一致している必要があります。パスワードだけ確認して、暗号化方式を見落とさないでください。VMessやVLESSではUUIDが使われることが多く、資料に記載されたトランスポート方式も確認します。TrojanのパスワードとTLS関連項目には、それぞれ異なる役割があります。HTTPやSOCKS5でユーザー名とパスワードが必要な場合は、別々に入力してください。資料で認証が指定されていない場合、値を勝手に追加しないでください。使用できる項目は選択したプロトコルやアプリの画面によって異なるため、実際の表示に従います。

TLSを有効にする場合、接続先アドレスとサーバー名は異なることがあります。SNIはTLSハンドシェイクで使うサーバー名です。証明書の検証では、サーバー証明書に記載された名前も関係します。接続先にIPアドレスを使うからといって、SNIも同じIPアドレスにするとは限りません。証明書エラーが発生したら、検証を無効にするのではなく、名前、デバイスの時刻、元の資料を確認してください。検証を無効にすると信頼の範囲が変わるうえ、パスワードやトランスポートパスの誤りは解消されません。

資料でWebSocketなどのトランスポート方式が指定されている場合、HostとPathはトランスポートの設定と合わせて確認します。パスでは大文字・小文字やスラッシュが区別されることがあり、余計な空白や先頭のスラッシュの不足でハンドシェイクに失敗する場合があります。Hysteria2やWireGuardなどには専用のパラメータがあるため、別のプロトコルの項目一覧で代用できません。必要な情報が不足している場合は、まず手元の資料を確認してください。すべてのスイッチを手当たり次第に切り替えて原因を探す方法は避けましょう。

保存後は比較用に元の項目を残す

接続できない既存のサーバーを修正する場合、最初に現在の項目を複製するか、値を記録します。その後、疑わしいパラメータを一度に1つだけ変更してください。アドレス、ポート、TLSを同時に変更すると、接続結果が変わっても原因を特定しにくくなります。手動追加した項目には個別の備考を付け、サブスクリプション内の同名項目と区別します。サブスクリプションの項目は更新時に再生成される場合があり、ローカルでの一時的な変更が残るとは限りません。長期的な管理方法として頼らないでください。

03 / IMPORT

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

QRコードとクリップボードはテキストを渡す手段であり、サーバー情報そのものを変えるものではありません。QRコードには単一の共有リンクが含まれる場合も、サブスクリプションURLが含まれる場合もあります。コピーした内容が説明文だけということもあります。操作を始める前に、読み込むデータの種類を確認してください。解析後にサーバーが1つ表示されるのか、取得が必要なサブスクリプションなのかを見分けます。テキストを読み取れたことは、パラメータが完全であることや、サーバーが使えることの証明にはなりません。

QRコードを読み取る前に見やすさを確認

アプリでScan QR Codeを使い、利用者が用意した資料のQRコードにカメラを向けます。四隅がすべて読み取り範囲に入るようにしてください。反射や傾きを避け、拡大しすぎないようにします。別のデバイスに表示したQRコードを読み取る場合は、画面の明るさを少し上げ、距離を保ってください。長いリンクは模様が細かくなります。圧縮されたチャットのプレビュー画像は正しく読み取れないことがあるため、ぼやけた画像を繰り返し試すのではなく、元の鮮明な画像を使います。

カメラのアクセスを拒否した場合は、システム設定でShadowrocketのカメラへのアクセスを確認し、アプリに戻って再度試します。アクセス権限の問題とQRコードの内容の問題は分けて考えてください。カメラ画面がまったく表示されない場合は権限を、カメラは使えるのに読み取りが完了しない場合は画像の品質を確認します。現在の画面に写真ライブラリから読み込む機能がある場合は、画面の案内に従って画像を選びます。その項目が表示されない場合、すべてのQRコード読み取り画面で同じ操作ができるとは限りません。

クリップボードからは必要な内容だけを読み込む

コピーする前に、長いテキストが画面端で折り返されている部分も含め、リンク全体が選択されていることを確認します。画面上の折り返しは実際の改行とは限りませんが、手作業でつなぐ際に余分な空白が入ることがあります。Shadowrocketに戻り、画面にあるクリップボードからの読み込み方法を使うか、サブスクリプションURLをSubscribeのURL欄に貼り付けます。貼り付けの許可を求められたら、自分が行った操作であることを確認してから許可してください。拒否すると内容は取り込まれませんが、プロトコルが非対応という意味ではありません。

メモやメッセージからコピーするときは、リンクの前にある番号、後ろの説明、リンクを囲む引用符まで一緒にコピーしがちです。前後の範囲を確認してから、もう一度コピーしてください。URLを「整える」つもりで、パーセント記号、等号、プラス記号、疑問符を削除しないでください。これらはエンコードやパラメータの一部である場合があります。サービス側で元のテキストが短い要約に置き換えられたり、途中で省略されたりしている場合は、プレビューから補完するのではなく、元の資料からコピーします。

読み込み結果は件数ではなく項目で確認

項目が解析されたら編集画面を開き、Type、ホスト、ポート、認証情報が元の資料と一致するか確認します。QRコードに古い情報が含まれていたり、表示名が現在のサブスクリプションと同じだったりする場合があります。「リストに項目が増えた」だけでは十分な確認になりません。読み込みを繰り返して同名項目ができた場合は、それぞれの所属先と主要な項目を確認し、正常に使えるものを残してから、重複と確認できた項目を整理します。区別する前にまとめて削除しないでください。

QRコードからサブスクリプションURLを読み込んだ場合、その後にネットワーク経由でデータを取得する必要があります。単一の共有リンクを読み込んだ場合は、通常、サーバー項目がローカルに作成されます。前者はサブスクリプションの取得エラーとして、後者は項目の解析または接続エラーとして確認します。読み込み後にサーバー情報ではなくWebページが開く場合も、まずQRコードに含まれるデータの種類を確認してください。Webページ内のURLを何でもサーバーアドレスとして入力すると、取得先の問題が項目の問題にすり替わってしまいます。

読み込み後、接続するまでにはサーバーの選択、Global Routingの確認、システムのVPN設定の許可などが必要です。初めて操作する場合は、使い方ガイドに戻って手順を続けてください。QRコードと手入力で同じ情報を読み込んだのに結果が異なる場合は、ネットワークを切り替えて差を隠すのではなく、2つの項目を比較して解析結果の違いを確認します。

04 / LINK FORMAT

共有リンクの形式と読み込み時の注意点

単一の共有リンクには通常、プロトコル、認証情報、サーバーアドレス、一部の追加パラメータがまとめて記載されています。単一リンクは1つの接続先を表し、サブスクリプションは更新可能な項目の取得先を示す点が異なります。リンクの長さや、ネットワークアドレスが含まれているかだけで判断しないでください。プロトコルの接頭辞が付いた単一リンク、リストを取得するためのURL、説明用のWebページは、それぞれ別の種類のデータです。対応する読み込み方法を使ってください。

まず構造を確認し、その後パラメータを確認

よく使われる接頭辞にはss://、vmess://、vless://、trojan://があります。接頭辞から解析方式を判断できますが、アプリがその形式のすべての拡張項目を認識するとは限りません。プロトコルによって本文の構造は異なり、エンコードされた情報を含むものや、アドレスとクエリパラメータに似た形式のものがあります。すべてを「コロンの前がユーザー名、後ろがパスワード」として分解することはできません。エンコード済みの部分を直接編集しないでください。

リンクの末尾にシャープ記号で備考が付く場合や、パラメータにパーセントエンコードが使われる場合があります。エンコードは特殊文字を扱うため、または日本語以外の名前を表すために使われます。手作業で文字を置き換えると、解析結果が変わることがあります。備考は通常、接続には使われませんが、クエリパラメータはTLS、トランスポート方式、パスを決める場合があります。名前が文字化けしても接続できる場合は、まず備考の表示を確認します。接続できない場合は、プロトコル項目を確認し、別の問題として扱ってください。

解析に成功しても、すべてのパラメータが同じとは限らない

1つのリンクに基本的な認証情報と追加のトランスポート設定が含まれる場合があります。読み込み後にアドレスとパスワードだけが表示されても、ほかの設定がすべて反映されたとは限りません。項目を開き、元の資料と照らし合わせて、必要なトランスポート、安全な接続、サーバー名などを確認してください。リンク形式に複数の表記方法がある場合は、アプリの解析結果を基準にします。認識されない項目は、手元の資料を参照して1つずつ確認し、不明なパラメータを備考やアドレス欄に入れないでください。

サーバー項目を共有リンクとして書き出す場合、受け取る側に必要なパラメータがすべて含まれているか確認します。個別の項目を共有しても、管理環境全体を共有したことにはなりません。サブスクリプションの更新関係、現在のConfig、ルールとポリシー、一部の全般設定はリンクに含まれない場合があります。デバイスを移行する場合は、このページの最後にある章の階層別バックアップを使い、現在使えるリンクを1つ保存しただけで設定全体をバックアップしたと思わないでください。

サーバー情報とルール設定は置き換えられない

以下はShadowrocketのルール例です。.conf設定ファイルのRuleセクションに属し、サーバーの共有リンクではなく、認証情報も含みません。例示ドメインにはPROXYを使い、それ以外のリクエストにはDIRECTを使う設定です。編集する前に、現在の設定で各ポリシーが何を意味するか確認してください。このテキストをAdd Serverに貼り付けても、接続可能なサーバーは作成されません。

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

共有する前に、相手が必要としているものがサーバー情報、サブスクリプションの取得先、ルールのどれかを確認します。ルールについて相談する際は、多くの場合、マッチ条件とポリシー名があれば十分で、サーバーの認証情報は必要ありません。リンクの不具合を調べる場合は、プロトコルの接頭辞、パラメータの有無、エラーの状況を記録し、認証情報全体を隠してください。エンコードは暗号化ではありません。読みにくいリンクでも、情報を公開してよいとは限りません。

特定のWebサイトで既存のサーバーを使いたい場合は、リストを何度も読み込むのではなく、ルールを調整します。特定のWebサイトにPROXYを使うルール設定で、ルールの順序とFINALの関係を確認できます。まず情報がどの階層に属するかを見極めてから操作方法を選ぶと、「読み込みに成功したのに動作が変わらない」という誤解を減らせます。

05 / UPDATE

サブスクリプションの更新と失敗時の切り戻し

サブスクリプションの更新は、取得先から最新のサーバー情報を取り直す操作です。あらゆる接続の問題を解決するものではありません。サーバー側でアドレス、ポート、認証情報、利用可能な項目が変更された場合、更新でその変更を反映できます。一方、デバイスのネットワーク、現在のルール、システムの許可に原因がある場合、更新だけでは解決しないことがほとんどです。始める前に、取得に失敗したのか、リストが変わったのか、既存の項目が接続できないのか、状況を整理してください。状況によって確認する順序が異なります。

経過を確認できる更新手順にする

更新前に、現在選択中のサーバーと所属するサブスクリプションを確認し、いくつかの重要な名前を記録します。必要に応じて先にバックアップしてください。その後、対象のサブスクリプションだけを更新し、すべてのグループを同時に更新したり、ルールまで変更したりしないでください。操作後は、エラー表示の有無、リストの変化、選択中の項目が残っているかを順に確認します。名前が消えた場合は、取得先から返された内容が変わった可能性があり、ローカルで誤って削除したとは限りません。名前が変わらなくても、アドレスや認証情報が同じとは限りません。

更新にネットワーク通信が必要な場合は、デバイスから取得先にアクセスできることを確認します。状況によっては、現在の接続経路が結果に影響するため、安全に試せる範囲で異なるネットワーク状態を比較しても構いません。その際は一度に変える条件を1つにします。更新を何度も連続して押しても、適切なテストにはなりません。短時間に繰り返すと制限にかかる場合があり、エラー表示も上書きされてしまいます。最初に失敗したら原因を記録し、目的を絞って再試行してください。

取得・解析・利用の段階に分けて確認

取得に失敗した場合は、URLが完全か、ネットワークに接続できるか、取得先が有効かを確認します。解析に失敗した場合は、返された内容が対応するサブスクリプションデータか、ログインページや案内文に置き換わっていないかを確認します。更新に成功しても接続できない場合は、新しいサーバー項目、選択状態、ルールのポリシーを確認してください。3つの状況を分けて記録します。「サブスクリプションの更新に成功」は、取得と解析が一定の結果に達したことを示すだけで、すべてのサーバーへの実際のアクセスを確認したことにはなりません。

取得先で認証情報が切り替わった場合、古いリストに名前が残っていても接続できなくなることがあります。反対に、更新リクエストに失敗しても、古い項目が引き続き使える場合があります。変化した段階を判断するため、現在のリストは残してください。ただし、ローカルのキャッシュが今後も使えるとは限りません。更新結果に問題がある場合は、後続の一括操作を止め、取得先の状態と元の資料を確認します。確認できていない同じURLを使ってサブスクリプション全体を削除し、すぐに作り直さないでください。

更新頻度とローカル変更の関係

更新は、手元のサブスクリプション資料で変更が案内されたとき、項目が使えなくなったとき、移行の前など、実際に確認が必要なタイミングで行います。アプリの画面に自動更新の設定がある場合は、デバイスのネットワーク環境や使い方に応じて有効にするか判断してください。自動更新でも毎回成功するとは限らず、結果の確認も必要です。通信が制限されている環境やデータ通信量を抑えたい場合は、バックグラウンドでの取得もネットワーク通信であり、ローカルの更新ではないことを理解しておきましょう。

サブスクリプション内の項目をローカルで編集する前に、更新で変更が上書きされる可能性を確認してください。特定の項目を長期的にカスタマイズする場合は、アプリで可能であれば独立した項目として保存し、管理方法を明記します。元のサブスクリプションは引き続き元の取得先で管理します。同じサーバー情報を自動管理と手動管理の両方の対象にしないでください。更新後にどちらの値が正しいか分かりにくくなり、トラブル対応時に異なる項目をテストしてしまう可能性があります。

アプリの更新とサブスクリプションの更新も区別してください。前者はApp Storeで管理し、後者は利用者が用意した接続情報を取得します。アプリを更新しても、サブスクリプションの不足情報は補われません。サブスクリプションを更新しても、アプリ自体は変わりません。購入、アプリの再入手、システム要件については購入済みアプリの復元ガイドをご覧ください。接続や解析の問題はよくある質問で確認できます。

06 / ORGANIZATION

複数サブスクリプションの整理とポリシーの対応関係

複数のサブスクリプションを管理する際は、項目を1つの長いリストにまとめることより、どこから取得したか追跡できる状態を保つことが大切です。それぞれについて、どの取得先から更新するのか、どのサーバーがその配下にあるのか、現在使っている項目を誰が管理するのかを確認できるようにします。所属先が分からないと、同じ名前のサーバーが別の取得先から来ていることがあり、一方を更新してもう一方も更新されたと思い込む可能性があります。その後のテスト、削除、バックアップにも判断のずれが生じます。

まずグループに名前を付け、次に例外を識別

サブスクリプションには「日常用A」「テスト用B」のような、短く安定した備考を付けます。用途と自分で決めた識別子で区別し、完全なURLや認証情報は名前に含めないでください。手動で追加した項目には、ローカルで管理することを明記します。狭い画面でも名前の前半で区別できるようにし、すべての項目を同じ長い接頭辞で始めないようにします。プロトコルや地域の情報は絞り込みの手がかりになりますが、更新で変わることがあるため、取得元を示す情報の代わりにはなりません。

同じ名前でも重複とは限らず、名前が異なっても別の項目とは限りません。重複を確認するには、プロトコル、ホスト、ポート、認証情報、トランスポートのパラメータを総合的に比較します。表示名だけを比べて削除すると、誤削除につながります。異なるサブスクリプションに同じ接続先が含まれる場合は、両方の取得先との管理関係を残す必要があるか判断してください。取得先を残すことと、その配下のすべての項目を使うことは別です。ローカルのコピーを1つ削除しても、別のサブスクリプションが同じ情報を再度返さなくなるわけではありません。

リスト管理とルーティングの選択を分けて考える

サーバーリストで分かるのは「選択できる接続先」、Global Routingで分かるのは「リクエストの処理方法」です。Configを使う場合は、有効な設定のルールとポリシーも確認します。グループを整理した後、よく使うポリシーが特定の項目、現在の選択、または設定内で定義された別の対象のどれを参照しているかを確認してください。サーバーがリストの先頭にあるからといって、すべてのルールで自動的に使われるとは限りません。

表は管理する階層を区別するためのもので、個別の設定の確認に代わるものではありません。特にConfigでは、現在のサーバーが使えなくても、リクエストがDIRECTに一致していれば正常に処理される場合があります。反対に、リストでサーバーを切り替えても、特定のポリシーが参照する項目まで変わるとは限りません。整理後は、接続スイッチやリスト上の選択位置だけでなく、実際のリクエストと確認できる診断情報で経路を確かめてください。

小さな変更で管理しやすさを保つ

一度に整理するサブスクリプションは1つにし、まず備考と所属先を確認します。次に、重複と確認できた項目を整理し、最後に普段使うリクエストを再テストします。グループごとに利用できる状態を維持し、更新、名前の変更、削除、ルールの調整を同時に進めないでください。用途が分からない項目は、すぐに削除せず、確認待ちとして印を付けます。アプリに絞り込みや折りたたみ表示がある場合は活用し、未確認の情報を削除してリストを短くすることは避けましょう。

サブスクリプションの更新で名前や項目が再生成される場合、名前を条件にするポリシーも確認が必要です。地域名や用途名を含む自動選択条件は、名前の変更によって別の項目を選ぶことがあります。設定を保存する前に、ポリシーに利用可能な項目が残っていることと、削除済みの項目を参照していないことを確認してください。設定の参照方法を理解してから、広範囲の名前変更を行います。読みやすさのためだけに変更するなら、サブスクリプションの備考を変えるほうが影響を抑えられます。

サブスクリプションの数が多くても、接続品質が保証されるわけではありません。すべてを順番にテストする必要もありません。用途が明確な候補を少数選び、次の章の手順で条件をそろえて比較してください。普段使わない項目は元のグループに残し、必要になったときに確認できます。取得先との管理関係を保ちながら、接続前に大量の名前を毎回見分ける負担を減らせます。何度も全消去して作り直すより、後から経緯をたどりやすくなります。

07 / CONNECTIVITY TEST

レイテンシテストとリストの並べ替え

レイテンシテストの結果は、ある時点に特定の方法で測定した応答を示します。Webページの表示速度、継続的な通信性能、すべての接続先への到達性と同じではありません。テスト方法によって確認する接続段階が異なるため、比較する前に方法が同じか確認してください。1回の数値が低くても、その回の待ち時間が短かったことを示すだけです。実際のリクエストで追加の名前解決、TLSハンドシェイク、接続先サーバーの処理が必要な場合、体感は異なることがあります。

まずテスト条件をそろえる

テスト中にWi-Fiとモバイル回線を切り替えず、同じネットワーク環境を使います。デバイスで大量の通信が同時に行われていないことを確認し、同じ候補のサーバーにConnectivity Testまたは現在の画面にあるテスト機能を実行します。方法や接続先を選べる場合は、同じ設定にそろえてください。結果には数値だけでなく、テスト方法とネットワークの種類も記録します。そうすれば、次回変化があった際にサーバー側とテスト条件のどちらが変わったか判断できます。

TCP系のテストは、接続先ポートの応答を調べるのに近い方法ですが、プロトコル認証や接続先へのアクセスまで確認するとは限りません。実際のリクエストを含むテストでは、より多くの段階を確認できる場合がありますが、結果はテスト対象にも左右されます。ポートに到達できてもパスワードが正しいとは限らず、テスト対象に到達できてもすべてのWebサイトにアクセスできるとは限りません。アプリが提供する方法に沿って結果を解釈し、異なる方法の数値を同じ基準で並べて安定性を判断しないでください。

タイムアウト、変動、実際の使用感を分けて判断

タイムアウトしても、サーバーが恒久的に使えないとは限りません。現在のネットワーク、名前解決、パケットロス、テスト対象、サーバーの状態が関係する場合があります。まず少数の項目を再テストし、利用可能と分かっている項目と比較してください。候補がすべて同時に異常なら、デバイスのネットワークとテスト設定を優先して確認します。1つだけ異常が続く場合は、その項目のアドレス、ポート、認証情報を確認します。1回のタイムアウトで一括削除したり、1回の成功だけで設定に問題がないと判断したりしないでください。

同じ条件で間隔を空けて数回テストし、目立った変動が繰り返し発生するか確認するほうが、1回の最低値を追いかけるより実用的です。テストを頻繁に行うと余分なリクエストが発生するため、無制限に繰り返さないでください。その後、候補を選んで普段使うWebサイトにアクセスし、ページの読み込みや必要な操作を継続できるか確認します。実際の使用感は業務や用途に合わせて確かめてください。軽いページを1つ開いただけで、すべての用途に問題がないとは判断できません。

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

レイテンシ順に並べ替えると候補を探しやすくなりますが、結果は通常、テスト時点の表示であり、恒久的な優先順位ではありません。リストの先頭にある項目が選択中とは限らず、Config内のすべてのポリシーで使われるとも限りません。並べ替え後は、選択位置と所属グループを改めて確認してください。Configの自動選択を使っている場合は、テスト対象と選択ロジックを別に確認します。手動の並べ替えでポリシー設定を代用しないでください。

地域名やプロトコルも、判断の参考情報にとどまります。表示される地域は管理者が付けた名前の場合があり、リクエストの経路を完全に示すものではありません。あるネットワークで正常に動くプロトコルも、環境が変われば同じ結果になるとは限りません。名前から先に結論を出さず、実際に使うネットワークで比較してください。詳しくはレイテンシテスト・地域・プロトコルの選び方をご覧ください。比較可能なテスト条件を保つことが重要です。

診断情報で意図したポリシーが適用されているか確認

テストに問題がないのに接続先へアクセスできない場合は、まずGlobal Routingでリクエストに適用されたポリシーを確認します。以下の例では、例示ドメインにPROXYを使い、中国地域のIPアドレスに一致したリクエストにはDIRECT、それ以外にはPROXYを使います。ルールは記載順に評価されます。この例は動作の説明用であり、既存の設定を理解しないまま全体を置き換えるためのものではありません。リクエストごとに適用されるポリシーが異なれば、同じサーバーを選んでいてもアクセス結果が変わる場合があります。

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

診断時には、「テストが応答するか」「プロトコル接続を確立できるか」「ルールが想定したポリシーを選ぶか」「接続先から正常な応答があるか」を分けて記録します。こうすることで、項目の修正、サーバーの切り替え、ルールの調整のどれが必要か判断できます。すべてをレイテンシの高低だけで説明すると、認証エラー、ルールの誤一致、接続先自体の問題を見落とし、必要もないのに正常なサブスクリプション構成を壊すおそれがあります。

08 / BACKUP & REMOVE

削除・バックアップと復元後の確認

削除する前に、対象が単一のサーバー、サブスクリプション全体、Config内の設定ファイルのどれかを確認してください。影響範囲は異なります。サーバーを削除するとローカルのリストだけに影響する場合があります。サブスクリプションを削除すると管理用の取得先が失われ、設定ファイルを削除するとルーティングの動作が変わることがあります。アプリ内のローカル削除と、サーバー側の情報変更も区別してください。ローカルで削除しても、サブスクリプションURLや共有済みの認証情報は無効になりません。情報が漏えいした場合は、デバイスのリストを消すだけでなく、元の認証情報を変更する必要があります。

スクリーンショットだけでなく、階層ごとにバックアップ

第1層ではサブスクリプションの取得先と所属を示す備考を、第2層では独立した手動追加項目の必要な情報を、第3層では現在有効なルール設定と記録が必要な設定を保存します。アプリに書き出しやバックアップの機能がある場合は、どの範囲が含まれるかを確認してから、自分で管理できる安全な場所にファイルを保存してください。書き出し対象によってはサーバー情報だけ、または設定だけが含まれる場合があります。ファイルを作成できたからといって、すべての状態が保存されたと思わないでください。

スクリーンショットは選択状態や操作中の状況を記録するのに適していますが、復元用の唯一の資料には向きません。長いURLは全体が表示されないことがあり、非表示の認証情報もスクリーンショットでは保存されません。一方、画像内のQRコード、サブスクリプションのパラメータ、パスワードから接続情報が漏れるおそれもあります。バックアップでは復元可能な元データを優先して保存し、アクセス範囲を制限してください。問い合わせ用のスクリーンショットは別に作成し、機密情報を隠します。完全なバックアップをそのまま他人に送らないでください。

削除前に参照先を確認

削除対象が現在選択中のサーバーではなく、よく使うポリシーから固定参照されていないことを確認します。サブスクリプション内の項目を個別に削除しても、次回更新で再び表示される場合があります。サブスクリプションの管理を停止したい場合は、返された項目を1つずつ削除するのではなく、取得先自体を削除してください。手動追加した項目は、元のパラメータをバックアップに保存してから削除します。名前が似ている場合は、リスト上の位置だけで判断せず、編集画面を開いて確認してください。

Configファイルを削除する前に、現在有効なものを確認し、必要な内容を保存して、代わりに使える設定を用意してください。サーバーだけを削除しても、ルール内の参照先は自動で修正されません。反対に、ルール設定を削除してもサブスクリプションの取得先は解除されません。一括整理は「バックアップ、確認、少数ずつ削除、接続テスト」の順で進めます。作業のたびに確認済みの状態へ戻れるほうが、すべてを一度に消して不足情報を探すより影響を抑えられます。

復元後は階層ごとに確認

新しいデバイスへの移行や再インストール後は、まずApp Storeから購入済みアプリを入手します。操作方法は購入済みアプリの復元ガイドをご覧ください。アプリの購入履歴とサーバーデータは別のものです。アプリを再入手しても、接続情報がすべて自動的に戻るわけではありません。システム要件や購入の適用条件は、App Storeのページに記載された内容をご確認ください。データの復元時も、システムのバックアップにすべての項目が含まれるとは限らないため、実際の復元結果を確認します。

まずサブスクリプションまたは手動追加項目を1つ復元し、項目を照合して接続を確認してから、ほかのグループを復元します。サブスクリプションを再取得した後は、古いスクリーンショットと件数を比べるだけでなく、現在のリストを確認してください。次にルール設定を復元し、Global Routingの選択、現在のサーバー、ポリシーの参照先を確認します。最後に必要なOn Demandなどの設定を確認してください。初回接続では、システムの案内に従ってVPN構成を許可します。復元ファイルでシステムの権限確認を代用することはできません。

古いバックアップに含まれる取得先や認証情報が、すでに無効になっている場合があります。そのため、復元に失敗してもファイルが壊れているとは限りません。読み込みが完了するか、サブスクリプションを更新できるか、サーバーに接続できるかを分けて確認します。バックアップ内の名前が新しいリストと一致しないこともあるため、固定参照先を改めて確認してください。復元に成功したら現在の状態を記録し、古いバックアップと検証済みの新しいバックアップを明確に区別します。次回、確認前のデータを誤って使わないためです。

必要最小限のコピーを残し、使わないと確認できた機密情報は定期的に削除します。変更したルールや手動追加項目はバックアップに反映しますが、一時的なテストのたびに、見分けにくいコピーを大量に残す必要はありません。復元で問題が続く場合は、失敗した段階、実施した手順、機密情報を隠したエラー内容を添えてよくある質問をご覧ください。操作を最初から確認する場合は、使い方ガイドに戻り、手順に沿って確認します。