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

01 / 更新可能なリストを読み込む

Subscribeの追加先と管理対象

サブスクリプション、サーバー、Configを区別する

サブスクリプションは繰り返し取得できるサーバーリスト、サーバーは個別の接続情報、Configはリクエストに適用するルールと処理方針を定めるものです。互いに関連しますが、同じものではありません。サブスクリプションの更新に成功しても、リストを取得・解析できたことを示すだけで、選択したサーバーに接続できるとは限りません。サーバーに接続できても、現在のConfigが想定どおりに通信を振り分けているとは限りません。問題を調べる前に対象を特定し、ルールの問題をサブスクリプションの問題と取り違えないようにしましょう。

現在のサーバーと所属するサブスクリプションはHomeで確認し、Config関連の項目はConfigで管理します。本ガイドの手順では、ConfigからSubscribeの追加先を探します。利用中のプラットフォームでサブスクリプションの追加がHomeの「＋」に統合されている場合は、Add ServerでSubscribeタイプを選択してください。プラットフォームによって画面上の階層は異なることがあります。別の端末のボタン位置を頼りにせず、フォームのタイプとURL欄を確認してください。

追加前にリンクの用途を確認する

サブスクリプションURLは利用中のサービス提供元から入手してください。リンクに付属する説明を読み、Shadowrocket用のサーバーサブスクリプションなのか、アカウント管理ページ、説明ページ、Config全体なのかを確認します。ブラウザーで開けるURLでも、クライアントが応答内容をサーバーリストとして解析できるとは限りません。リンクに認証用のパラメーターが含まれている場合は、疑問符以降も削らずにコピーしてください。チャットアプリが付けた句読点を一緒に含めないよう注意します。

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

Subscribeフォームに識別しやすい名前と完全なURLを入力し、保存して更新を実行します。初回の読み込み中はネットワークを安定させ、完了後にHomeへ戻ってサーバー情報が表示されているか、件数が手元の情報と大きく食い違っていないか、名前が正しく読めるかを確認してください。成功の基準となる固定件数はありません。提供元がリストを変更すれば結果も変わるため、利用できる範囲と提供元の説明を基準に判断してください。

結果から失敗した段階を切り分ける

保存後にサーバーが表示されない場合は、クライアントがURLへ実際にリクエストしたかを確認します。名前は表示されるのにリストが空なら、取得失敗、応答内容が空、または形式を解析できない可能性があります。認証エラーが出た場合は、リンクが差し替えられていないか、有効期限が切れていないか、コピーが途中で欠けていないか確認してください。Webページが返された場合は、ログインページではなくサブスクリプション用のURLかを確認します。同じ失敗URLを繰り返し追加しても、空のグループが増えるだけで結果は変わりません。

一部のサーバーだけ表示されない場合は、欠落したサーバーのプロトコルやパラメーターが現在のプラットフォームに対応しているか、サブスクリプションが元から一部の情報のみを返しているかを確認します。まず正常に読み込めた情報を残し、失敗の内容を記録して、手元のサーバー情報と照合してください。リストを完全に見せるために、不明なパスワード、ポート、転送パラメーターを推測で補わないでください。各項目はサーバー側の情報と一致する必要があります。推測で作った情報は保存できても、接続できるとは限りません。

サーバー情報が表示されているのに接続結果がおかしい場合、すぐにサブスクリプションを削除して作り直す必要はありません。まずサーバーを1つ選び、後述の個別テストを実施してからGlobal Routingを確認します。「リストの取得」と「通信での利用」を分けて検証できます。初回の操作を順に進めたい場合は使い方ガイドをご覧ください。本ページの以降の章では、項目、更新、整理を個別に説明しているため、具体的な問題を確認する際に役立ちます。

02 / 個別のサーバー情報を確認する

Add Serverの手入力項目とプロトコル設定

まずTypeを選び、元の情報に沿って入力する

手入力は、サーバー情報をすべて把握しており、個別の情報を切り分けて調べたい場合に適しています。HomeでAdd Serverを開き、Typeを選択してから、そのタイプに表示される項目を入力してください。プロトコルを選ぶと後続のフォームが変わるため、初期表示のフォームにすべて入力してからタイプを切り替えないでください。保存前に各項目を元の情報と照合し、コピー時に空白や改行、全角コロンが混入していないか、ポートを誤ってアドレス欄に入力していないかを特に確認します。

Addressには通常、サーバーのドメイン名またはアドレスを入力し、Portにはポート番号を別に入力します。Addressの先頭にWeb用のプロトコルを付けないでください。ドメイン名とWebページにアクセスするときのパスは別のものです。パスは該当する転送設定に入力します。IPv6では、共有リンク内の角括弧表記とフォームで求められる形式を区別してください。フォームでアドレスとポートが分かれている場合、「アドレス＋ポート」をまとめて貼り付けないようにします。名前は識別用であり、接続パラメーターを修正するものではありません。

似た項目でも相互に置き換えられるとは限らない

Shadowsocksでは暗号化方式とパスワードの両方を一致させる必要があります。パスワードが同じというだけで設定が正しいとは判断できません。VMessやVLESSではUUIDを使うことがありますが、同じUUIDを使うからといって両プロトコルを置き換えられるわけではありません。転送方式と関連項目も一致させる必要があります。Trojanの認証情報は対応するパスワード欄に入力します。HTTPとSOCKS5では、アカウント認証が有効かどうかを確認してください。提供されていない任意項目は、ほかのサーバー情報から設定をコピーせず、まず初期値のままにします。

TLSの有効・無効、SNI、Host、Pathにはそれぞれ異なる役割があります。Addressは接続先、SNIは暗号化ハンドシェイクで使うサーバー名、Hostはアプリケーション層のリクエスト情報、Pathは対応する転送経路を指定します。値が同じに見える場合でも、それを一般的なルールと考えることはできません。元の情報で値が異なる場合は、それぞれ個別に保ってください。フォームを整えるために無理に統一したり、Webページに表示された転送先ドメインをそのままSNIに入力したりしないでください。

Hysteria2やWireGuardなどでは、専用の認証情報や鍵が必要な場合があります。サブスクリプションから必要な情報が正しく提供されているか、サーバー側の設定一式を持っている場合に限り、追加してください。意味を確認できない項目は、まず元の情報に戻って内容を確認します。保存するためだけに適当な文字を入力しても、見た目が整った情報が作られるだけで、プロトコルの設定が正しい証明にはなりません。各プロトコルの基本的な違いはプロトコルの概要をご覧ください。

変更を最小限にして入力ミスを特定する

保存後はこのサーバーを選んでテストし、DNS、ルール、接続モードを同時に変更しないでください。テストに失敗した場合は、アドレスの名前解決、ポート接続、認証、転送パラメーターの順に確認します。アドレスの誤りは名前解決エラー、ポートやネットワークの問題は接続タイムアウト、認証やハンドシェイクの問題は個別のエラーとして現れることがあります。エラー表示は原因の範囲を絞る手がかりであり、項目ごとの確認に代わるものではありません。たとえば接続拒否は、ポートの誤りだけでなく、サーバー側が待ち受けていない場合にも発生します。

パラメーターを修正するときは、理由を説明できる項目を一度に1つだけ変更し、変更前後の値と結果を記録してください。手入力した情報には「手動」などの分かりやすい名前を付け、サブスクリプションから生成された項目と区別します。特定のパラメーターを検証するだけなら、まず情報を複製してコピー側を変更してください。有効性を確認してから、元の情報を残すか判断します。更新の動作が分からないままサブスクリプション配下の情報を直接変更すると、次回の更新で元に戻り、確認結果との比較ができなくなることがあります。

03 / 既存の情報から登録する

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

QRコードに何が含まれているかを確認する

QRコードはテキストを格納する方法であり、それ自体が独立したプロトコルではありません。個別サーバーの共有リンク、サブスクリプションURL、通常のWebページなどが含まれている場合があります。Scan QR Codeを開いたら、認識結果と保存対象を確認し、自分の情報と一致しているか確かめてください。スキャンの成功は画像内のテキストを読み取れたことを示すだけです。リンクが利用可能か、認証情報が有効かどうかまでは分かりません。スキャンの通知が表示されたことを、サーバーに接続できたことと混同しないでください。

別の画面に表示されたQRコードをスキャンする場合は、コード全体が読み取り範囲に入るようにし、反射や遮蔽、過度な拡大を避けてください。カメラの権限を求められた場合は、スキャン機能を使うときにシステムの案内に従って許可します。拒否した場合は、システムのアプリ権限設定を確認してください。QRコードの画像をすでに持っている場合は、現在の画面に画像認識機能があれば利用してください。画像を読み込む機能がないプラットフォームでは、画像を何度も調整するより元のテキストを読み込むほうが簡単です。

認識結果がサブスクリプションURLなら、サーバーのAddressではなくSubscribeのソースとして保存します。個別サーバーが認識された場合は、保存後にType、Address、Port、認証項目を確認してください。通常、QRコードに含まれるのはコード化された内容です。画面にほかの説明があるからといって、そのすべてが読み込まれたとは限りません。QRコードの下にパスワード、メモ、転送要件が別記されている場合、コードの内容に含まれていない可能性があるので注意してください。

クリップボードから読み込む際は区切りと文字コードを保つ

クリップボードからの読み込みは、完全な共有リンクをコピー済みの場合に適しています。まず元のメッセージからリンクそのものをコピーし、Homeまたは追加メニューに表示されるクリップボードの読み込み機能を使います。貼り付けの許可を求められた場合は、直前にコピーした内容であることを確認してから許可してください。想定した情報が表示されない場合は、別の操作でクリップボードの内容が上書きされていないか確認します。読み込みに失敗しても、すぐにプロトコル非対応と判断しないでください。実際には見出しや説明文しか残っていない可能性もあります。

チャットアプリでは長いリンクが折り返して表示されることがありますが、見た目の改行が実際の改行とは限りません。コピーした後、表示上の折り返しとテキストに含まれる改行を区別してください。実際に改行や空白が挿入されていると、プロトコルの解析が途中で止まることがあります。先頭のプロトコル部分が欠けていないか、末尾に日本語の句点が付いていないか、リッチテキストでリンクが表示名に置き換わっていないかも確認します。コピー内容を確認できない場合は、途中で切れた部分を推測して補わず、元のテキストからコピーし直してください。

複数のテキストをまとめて読み込む場合は、現在の画面が複数件に対応しているか確認してから、構造が分かりやすい内容を使います。見出し、説明、複数のリンクを含むメッセージ全体を貼り付けると、誤認識されたり、最初の1件だけ処理されたりすることがあります。まず1件だけ読み込んで項目を確認し、その後で残りを処理してください。同じ情報をすでに読み込んでいる場合は、再度実行する前にリストを確認します。重複した情報をサブスクリプション更新による追加と取り違えにくくなり、その後のテストや並べ替えも分かりやすくなります。

読み込み後に3点を確認する

1つ目は情報のタイプです。Subscribeが個別サーバーになっていないか、個別サーバーが通常のURLとして保存されていないか確認します。2つ目は重要項目で、特にパスワード、UUID、SNI、転送パスを照合します。3つ目は所属先で、情報が想定したグループに入り、別のサブスクリプションに混ざっていないことを確認してください。この3点を確認してから接続をテストすると、テキストの認識と実際の通信を分けて調べられます。問題が読み込みにあるのか、サーバー自体にあるのかを判断しやすくなります。

スキャン後に見覚えのないドメインや元の情報と異なるパラメーターが表示された場合は、保存を中止して元の内容を確認してください。サブスクリプションURLはアクセス認証情報の一部となるため、公開グループに転送したり、公開の認識サイトに送信したりしないでください。「QRコードは認識されるが保存すると空になる」などの状況を伝えるだけで調査できる場合があり、内容全体を他人に渡す必要はありません。画像を共有する場合はQRコード本体を隠してください。周囲の文字だけを隠しても、コード内のリンクは読み取られる可能性があります。

4種類の読み込み方法と適切な入口は、サブスクリプションの読み込み方法もご覧ください。読み込み後の件数が合わない場合は、本ページの第1章に戻ってサブスクリプションの対象を確認します。1件だけ失敗する場合は、第2章で項目を確認してください。同じ画像を何度もスキャンして重複を増やさないようにしましょう。

04 / テキストの構造を見分ける

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

プロトコルのプレフィックスだけでは全体を判断できない

共有リンクは通常、プロトコルのプレフィックスで始まり、その後にアドレス、認証情報、転送パラメーター、メモなどが続きます。プロトコルごとにエンコード方式が異なるため、同じプレフィックスでもパラメーターの表現が違う場合があります。プレフィックスを確認すれば適切な読み込み先を選びやすくなりますが、先頭を見るだけでリンク全体が正しいとは判断できません。読み込み後に項目を確認し、クライアントが認識した内容が元の情報と一致しているか確かめてください。パラメーターが無視されると、見た目上は情報が追加されても、想定どおりに接続できないことがあります。

リンク内のクエリパラメーターは、転送方式、暗号化接続、追加設定などを表すことがあります。#以降はメモとして使われる場合があります。メモ内の日本語、空白、特殊文字はパーセントエンコードされていることがあり、認証情報にBase64が使われる場合もあります。読みやすくするために手動でデコードしてから貼り戻したり、すでにエンコード済みの部分を再度エンコードしたりしないでください。同じ文字でも位置によって意味が異なる場合があるため、不要な置換でリンク全体の構造が変わることがあります。

サブスクリプション、共有リンク、ルールを混同しない

サブスクリプションURLは更新可能なコンテンツを取得するためのものです。個別の共有リンクは通常、1台のサーバーを記述し、Configは接続先以外の動作を定めます。HTTPSで始まるアドレスを受け取った場合は、Subscribeとして追加するのではなく、元の説明を確認して何が返されるか判断してください。セクション名やルール行を含むテキストも、複数のサーバーリンクとして読み込まないでください。それぞれを組み合わせて使うことはできますが、保存場所と更新方法は異なります。誤った入口を選んでも、内容が別の種類の管理対象に自動変換されることはありません。

[General]
bypass-system = true

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,example,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY

この内容は構文を説明するためのルール例であり、サーバーの認証情報は含みません。DOMAIN-SUFFIXはドメインのサフィックス、IP-CIDRはIPアドレスの範囲、FINALはそれまでに一致しなかったリクエストを処理します。ルールは通常、上から順に評価され、最初に一致したルールが処理方法を決めます。そのため、広い範囲を対象とするルールより具体的なルールを先に配置してください。例にあるPROXYを利用するには、使用可能なプロキシの選択先が必要です。ポリシー名を記述しただけでサーバーが自動追加されるわけではありません。

Global RoutingのConfig、Proxy、Directは、それぞれConfig、Proxy、Directに対応します。Configを使う場合は現在のConfigのルールを確認します。Proxyを使う場合は選択中のサーバーが動作するかを先に確認してください。Directでは、リストにサーバーがあるだけでリクエストが自動的にそのサーバーへ送られることはありません。サブスクリプションが利用可能かテストするときは、現在のモードも一緒に記録してください。同じリストでもモードが異なればアクセス結果が大きく変わることがあります。

共有前に認証情報の公開範囲を確認する

サーバーの共有リンクには完全なパスワードやUUIDが含まれることがあり、サブスクリプションURLにはリストを継続取得する権限がある場合があります。QRコードにしたり、表示名を短くしたり、エンコードしたりしても、機密性は変わりません。自分の端末間で情報を移す場合は管理された方法を使い、受け取り側が信頼できることを確認してください。問い合わせの際は、プロトコル、エラー表示、情報を伏せた項目を伝え、接続可能な情報一式を公開画像に載せないでください。

同じリンクを別の入口から読み込んだ結果、項目に違いがある場合は、元のテキストと2つの解析結果を残して比較します。まず途中で切れていないか、エスケープやエンコードが変わっていないかを確認し、関連するパラメーターが現在のプラットフォームで認識されているか調べてください。項目が欠けているからといって、必ずしもリンクが無効とは限りません。意味の分からないクエリパラメーターを安易に削除しないでください。保存できる長いリンクを無理に作るより、変更の理由を説明できることが重要です。判断できない場合は元の情報に戻り、形式を確認してください。

05 / リストの変更を管理する

サブスクリプションの更新設定と失敗時の復旧

更新は範囲を確認してから行う

サブスクリプションの更新とは、クライアントがソースに再度リクエストし、応答を解析して関連情報を更新する処理です。すべての項目を再テストすることでも、Shadowrocketアプリを更新することでもありません。提供元がサーバーを追加、削除、改名する場合があり、クライアントは既存情報との照合方法に従って処理します。更新前に、サブスクリプション由来の情報と自分で変更した情報を把握してください。特にメモ、選択中の項目、ルール参照に使う名前を確認しておくと、更新後の変化が正常か判断しやすくなります。

初めて使う場合は、まず手動更新を実行し、安定して情報を取得できることを確認してから、現在のプラットフォームで利用できる自動更新設定を検討します。自動更新の間隔は短ければよいというものではありません。頻繁にリクエストしても誤ったURLは直らず、提供元のリクエスト制限にかかる可能性があります。自動更新機能がない場合は、必要に応じて手動で更新してください。どちらの方法でも、重要な用途の前に確認する時間を確保します。接続を維持する必要がある最中に、ソースの変更と大量更新を同時に行わないでください。

更新前後に確認する4項目

更新前にソース名、選択中のサーバー、手動変更の有無、現在のネットワーク状態を記録します。更新後は成功の表示を確認し、リストに大きな変化がないか、選択中の項目が残っているかを確認してから、個別の接続テストを実行してください。件数の変化だけですぐに異常と判断する必要はありませんが、突然空になったり、名前が大量に異常表示されたりした場合は、操作をいったん止めます。元のソースと既存のバックアップを残しておくほうが、すぐに削除して作り直すより、変化がサーバー側か端末側かを判断しやすくなります。

サブスクリプションの項目を直接変更している場合、更新によって変更が上書きされることがあります。長期的に残す必要のある修正は、用途を明記した独立の手動情報として作成し、元のサブスクリプションを比較用に残す方法が適しています。特定の更新でメモが上書きされなかったからといって、すべての項目が保持されるとは限りません。項目やプラットフォームによって動作が異なる場合があるため、多数の情報を一度に試すのではなく、管理された更新を1回行って実際の結果を確認してください。

取得、認証、解析の順に切り分ける

更新がタイムアウトした場合は、まず端末のネットワークが使えることを確認し、次にサブスクリプションのリクエストが無効になったプロキシ経路に依存していないかを調べます。サブスクリプションの取得経路と通常のWeb閲覧の経路は異なる場合があります。現在のプラットフォームで関連設定を確認してください。管理できる環境でネットワークを切り替えて再試行することはできますが、ネットワーク、ルール、ソースURLを同時に変更しないでください。成功しても、何が結果を変えたのか分からず、次の失敗を再現しにくくなります。

認証エラーやアクセス拒否が発生した場合は、URL全体が正しいか、認証パラメーターがリセットされていないか、ソースが現在も自分のアカウントで利用できるかを確認します。リクエスト頻度が高すぎるという表示が出た場合は、繰り返し更新せず、しばらく待ってから提供元の案内に従ってください。ログインページ、案内ページ、空の内容が返されると、クライアントでは解析エラーとして表示されることがあります。これはサーバーリスト内の個別項目がタイムアウトする問題とは異なります。サブスクリプションのリクエストを調べる必要があり、個別サーバーのポートを変更しても解決しません。

以前は更新できていたソースが解析できなくなった場合は、応答形式が変更されていないか、新しくコピーしたリンクが別用途のURLを指していないか確認します。Webページをローカルファイルに保存しても、有効なサーバーリストになるわけではありません。また、別の形式から項目を適当に組み合わせないでください。エラーの原文、発生時のネットワーク環境、すべてのソースで失敗するかどうかを記録しておくと、再インストールを繰り返すより役立つことがあります。1つのソースだけが失敗している場合は、そのソースを優先して確認し、すべてのサブスクリプションを削除する必要はありません。

更新後にConfigの参照先を確認する

サーバー名が変わると、名前で識別・選択する方法に影響することがあります。カスタムポリシーを使っている場合は、参照関係も確認してください。更新後に情報は表示されるのにアクセス先が突然変わった場合は、リスト上部の名前だけでなく、選択中の項目とConfigも確認します。長期利用するルールでは依存関係を明記し、復元可能なConfigのコピーを残してください。サブスクリプションとルールを別々に管理すると、更新1回で複数箇所が変わるリスクを減らせます。

06 / 所属先を明確にする

複数サブスクリプションの整理とローカル変更の扱い

名前には場所だけでなく所属先も示す

複数のサブスクリプションを管理する場合は、まずソースに安定した区別しやすい名前を付けます。用途や情報の所属先を基準に整理し、URL全体をタイトルに入れたり、メモにパスワードや認証パラメーターを書いたりする必要はありません。サーバーのメモには個別情報を識別するため、元の名前を残して短い説明を追加できます。ソース名とサーバー名は異なる階層の情報です。役割を分けると、失敗範囲の確認、重複の整理、グループ全体の削除が正確になります。

最初からすべてのソースをまとめず、まず個別に更新できるか、リストのおおよその範囲、独立した手入力情報の有無を確認してから表示順を決めます。複数のソースに同じ名前があっても、同じサーバーとは限りません。名前が異なっていても、アドレスや認証情報が違うとは限りません。重複かどうかは、所属先、プロトコル、アドレス、ポート、重要なパラメーターを照合して判断します。リストの1行だけを見て一括削除したり、名前をそろえるために認証情報を変更したりしないでください。

提供元が管理する情報とローカルで管理する情報を区別する

サブスクリプションから作られた情報は提供元の更新に任せ、手動で作成した情報は明確に把握している独立した情報として管理します。テストのためにサブスクリプション内の項目を一時変更する場合は、複製するか、用途が分かる名前を付けたコピーを作成し、変更理由を記録してください。元の情報を比較用に残せるため、次回の更新でテスト用の設定が上書きされるのを避けられます。テストが終わったら不要なコピーを整理してください。実際に使える情報と混ざると、見かけ上はリストが充実していても管理しにくくなります。

グループ、お気に入り、並べ替えなどの機能は、現在のプラットフォームで実際に利用できるものを基準にしてください。独立したお気に入り機能がない場合は、分かりやすいメモと所属先で整理できます。存在しない管理階層を想定する必要はありません。また、リストの表示順をポリシーの優先順位と混同しないでください。サーバーを最上部に移動しても、Configが自動でそのサーバーを選ぶとは限りません。リクエスト先を決めるのは現在の選択、Global Routing、Config内のポリシーです。それぞれ確認してください。

重複を整理する前に差異を確認する

同じアドレスとポートでも、プロトコル、認証、転送パラメーターが異なる場合があるため、その2項目だけで完全な重複と判断できません。逆に、同じ共有リンクを繰り返し読み込むと、メモが異なるため複数項目に見えることがあります。整理するときは、まず重要項目を比較し、同じソースに属するかを確認してください。重複と確認できたら、更新が可能で所属先が明確な項目を優先して残します。手動修正がある場合は、自分の管理記録に理由を記載してから、どちらを削除するか決めてください。

ソースを一時的に更新できなくても、既存のサーバーが使える場合は、すぐに削除せず現状を記録して残すことができます。ソースを使わなくなった場合は、Configがその名前を参照していないか、現在の接続がそのグループに依存していないか確認します。整理は元に戻せる状態で行い、「一時的な失敗」「重複」「本当に不要」の3つを同じ扱いにしないでください。全件を一度に選択するより時間はかかりますが、グループごとに処理すれば変更の経緯を説明しやすくなります。

リストの見た目ではなく、デバイス間でルールをそろえる

同じサブスクリプションでも、プラットフォームの機能、表示方法、ローカルの手動項目の違いにより、デバイスごとにリストが異なる場合があります。管理では、ソースが正しいこと、重要なパラメーターが一致していること、選択方法が明確であることを目標にし、各端末で行数や順序まで完全にそろえる必要はありません。移行後は元のソース、個別のサーバー情報、Configの順に確認してください。移行先でプロトコル項目に違いがある場合は、現在の画面と元の情報を照合します。別の端末のスクリーンショットを唯一のフォーム基準にしないでください。

07 / テスト結果を読み解く

Connectivity Test、遅延、並べ替え

テストでどの段階まで確認したかを把握する

遅延の結果は特定の時点で実行したテストの値であり、サーバー全体の品質を恒久的に評価するものではありません。テストによってはポート接続だけを確認し、別のテストではプロキシ経由で特定の宛先にアクセスします。テスト方式、宛先、現在のネットワーク、同時実行数はすべて結果に影響します。Connectivity Testやリストのテスト機能を使う前に、現在のプラットフォームで利用できる方式と設定を確認してください。条件が近い場合に限り結果を比較できます。方式の異なるテスト値を同じ基準で並べ替えると、誤った結論につながることがあります。

ポートに接続できても、認証が成功するとは限らず、Webサイトにプロキシ経由でアクセスできるとも限りません。反対に、テスト対象が応答しなくても、すべてのアクセスが利用できないとは限りません。「テスト結果はあるがWebページを開けない」場合は、認証、TLS、転送設定、DNS、ルールを続けて確認します。「テストは失敗するが実際のアクセスは正常」な場合は、テスト対象とそのアクセス経路を確認してください。1つの記号だけを見て情報を削除せず、テストがどの段階まで確認したのかを把握します。

比較条件をそろえる

正常に動作することが分かっている情報を1つ選び、同じネットワーク、近い時間帯にほかの候補をテストします。テスト中は、大量のダウンロードや同期など、結果に影響する作業をなるべく止めてください。複数をまとめてテストすると候補を絞れますが、同時実行数が多いとローカルネットワークやサーバーに負荷がかかります。明らかに異常な結果が出たら、候補を絞って個別に再テストしてください。一度のテストで遅延が低くても、そのときの宛先への応答が速かったことを示すだけで、継続的な通信速度が高いとは限りません。

Wi-Fiとモバイルネットワークを切り替えると、接続経路や名前解決環境が変わるため、以前の順位が当てはまらなくなることがあります。固定の「最速」リストを毎日保存するより、用途が明確な候補を少数残し、利用環境が変わったときに再確認してください。テスト条件を記録する場合は、ネットワークの種類、テスト方式、概況を記載すれば十分です。公開記録に完全なアドレスや認証情報を記載する必要はありません。単発の結果より、再現できる現象のほうが原因の特定に役立ちます。

並べ替えと実際の選択は別

遅延順に並べ替えても表示順が変わるだけで、現在のサーバーが切り替わったとは限りません。並べ替え後はHomeに戻り、選択中の情報を確認してからアクセスをテストします。Configでポリシーグループなどを使っている場合は、最終的にどの項目が選ばれるかも確認してください。リストの先頭、現在選択中の項目、ルールが使うポリシーは、別々の対象であることがあります。この違いを見落とすと、「速いサーバーを選んだのに変化しない」と誤解することがあります。

ルールによる振り分けをテストするときは、まずProxyで選択したサーバーの基本接続を確認し、その後Configに戻ってルールへの一致を確認します。Directは直接接続とプロキシ接続を見分けるために使えますが、Directで成功してもサーバーが利用可能な証拠にはなりません。切り替えるたびに現在のモードを確認し、テスト後に元の設定へ戻すのを忘れないようにしてください。Global Routingと診断項目について詳しくは機能ガイドをご覧ください。初回接続に失敗した場合はガイドのトラブルシューティング手順も確認できます。

必要な情報だけ残して診断の手がかりを記録する

さらに調べる必要がある場合は、すべての情報で失敗したのか一部だけか、更新と接続のどちらで発生したか、特定のネットワークでのみ起きるかを記録し、個人情報を伏せたエラーの原文を残します。「接続できない」とだけ書いたり、問題を証明するために共有リンク全体を公開したりしないでください。同じ情報が別の端末で正常に動作する場合は、すぐにすべての設定をリセットせず、両端末に保存されたパラメーターと現在のモードを比較します。まず差分を確認してから1項目ずつ変更すると、結果の原因を特定しやすくなります。

08 / 復元可能なメンテナンス手順

削除、バックアップ、別端末への復元

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

サーバー1件、サブスクリプションソース1つ、Configの削除では影響が異なります。サーバー情報を削除しても、サブスクリプションの管理対象であれば次回の更新で再び表示される場合があります。ソースを削除した際に関連情報も削除されるかは、確認画面の内容に従ってください。Configを削除すると、サーバーリストが残っていてもルールの動作が変わる可能性があります。操作前に対象名と確認内容を読み、すべての削除ボタンが同じ「削除」を意味すると考えないでください。特に現在の接続がその情報に依存している場合は、すぐに削除しないよう注意します。

ソースを一時的に使わないだけなら、現在のプラットフォームに適切な無効化や表示管理の機能があるか確認してください。機能がなければ用途を明記して残しておけばよく、リストを短くするためにすぐ削除する必要はありません。削除する場合は、有効な元の情報と復元方法を引き続き利用できることを先に確認します。削除しても認証権限が取り消されるわけではありません。リンクが流出した場合は、端末から削除しても別の端末で利用される可能性があります。元のサービスの管理方法に従って、該当する認証情報をリセットしてください。

バックアップは少なくとも3つの層に分ける

第1層は再取得できるサブスクリプションソース、第2層は独立した手動情報とその完全なパラメーター、第3層はConfig、ルール、必要な選択関係です。サブスクリプションURLだけでは手動情報やルールを復元できるとは限りません。ルールだけを書き出しても、サーバーのパスワードは補えません。現在のプラットフォームにあるエクスポートやバックアップ機能を使う場合は説明を読み、対象に含まれる情報を確認してください。書き出し後は、ファイルが実際に存在するか、内容を識別できる名前か、移行先プラットフォームの対応する入口で読み込めるかを確認します。

バックアップファイルにはパスワード、UUID、鍵、サブスクリプションの認証パラメーターが含まれる場合があります。適切なアクセス保護がある、自分で管理できる場所に保存してください。拡張子が一般的に見えるからといって、公開してよい説明文書として扱わないでください。公開画像、業務ファイル、一時的な転送ファイルと一緒に保管するのも避けましょう。自分の端末間で移す場合は、受け取り先を確認し、転送後に内容が完全かを確かめてから、不要な一時コピーを削除します。認証情報が長期間あちこちに残るのを防げます。

ソース、サーバー情報、Configの順に復元する

別の端末に移行する場合は、まずアプリを入手して初回起動を済ませてからバックアップを読み込みます。iPhone / iPad版はApp Storeで2.99米ドルの買い切り、Mac / Windows / Android / Linux版は無料です。プラットフォームの選び方とインストール手順はダウンロードガイドをご覧ください。サブスクリプションを復元するためだけに、すべての設定をすぐに上書きする必要はありません。移行先にすでにあるデータを残す必要があるか確認し、独立した手動情報を誤って上書きして別の情報を失わないようにしてください。

復元後はソース名を確認し、1つずつ手動更新してURLが有効か確かめます。次に独立したサーバー情報の重要項目を確認し、最後にConfigとポリシーの選択を確認してください。古いバックアップで過去のローカル状態を戻せても、リモートサービスが古い認証情報を受け付けることや、変更済みのサーバーが引き続き存在することまでは保証されません。復元成功の基準は、リストが以前と同じに見えることではありません。ソースを更新でき、必要な情報に接続でき、ルールの動作が現在の要件に合っていることです。

範囲を限定してバックアップを検証する

重要な変更を行う前に、用途を明記したバックアップを1つ作成し、内容を1グループだけ変更してください。可能であれば、現在の作業に影響しない方法で読み込み結果を検証し、端末を失ってから初めて復元を試すことは避けましょう。現在のプラットフォームで個別に検証しにくい場合は、書き出し範囲、ファイルが読めること、元の情報がそろっていることを少なくとも確認し、自分が理解できる復元手順を残します。バックアップの価値は必要な情報を戻せることにあり、ファイル数が多ければよいわけではありません。

長期的なメンテナンスでは「バックアップ、変更、更新、テスト、記録」の順に進めます。目的が明確な問題を一度に1つだけ扱い、成功したら簡潔に記録し、失敗したら最後に確認できた状態へ戻してください。クライアントアプリの買い切り購入と接続サービスの契約は別です。アプリの入手記録もサーバー情報のバックアップにはなりません。本ページの目次に戻るときは、対象に応じて章を選んでください。ソースの問題はSubscribeと更新、個別接続は項目とテスト、移行と削除は本章で確認できます。

ガイドの先頭へ戻る ↑ クイックスタートガイドを見る →