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

Subscribe：サブスクリプションとレコードの関係

サブスクリプションはサーバー情報を取得するためのリモートアドレスであり、個々のサーバーそのものではありません。Shadowrocketがそのアドレスにアクセスして応答内容を読み取り、認識できた項目をサーバーレコードとして表示します。そのため、サブスクリプションのアドレスにアクセスできること、リストが表示されること、サーバーに接続できることは、それぞれ別の確認事項です。リモートの内容は変わる場合があります。今回取り込んだ名前、件数、並び順だけでは、次回更新後の状態は判断できません。操作を始める前に、手元の情報がShadowrocket用のサブスクリプションアドレスなのか、紹介ページやアカウントページ、単一サーバーの共有リンクなのかを確認してください。

HomeからSubscribeを追加する

Homeの追加メニューからAdd Serverを開き、TypeでSubscribeを選択して、サブスクリプションURLと識別しやすい名前を入力します。アプリの画面変更により項目名や配置が異なる場合は、実際の表示に従ってください。操作対象は常にTypeがSubscribeのレコードです。URL欄にはアドレス全体を入力し、サーバーのAddress欄には入力しないでください。保存前に先頭、末尾、クエリパラメータを確認しましょう。コピー時に空白や改行、日本語の句読点、チャット内の説明文が混入していないかも確認してください。

名前は端末上で識別するためのものです。「個人用・通常利用」のように用途や取得元が分かる名前にし、URL全体は入力しないでください。認証パラメータを含むURLはアクセス情報に相当します。他人に渡ると、サーバー情報を読み取られる可能性があります。入力後に保存し、サブスクリプションの読み込み結果を確認してください。対象のレコードが表示されたか、明確なエラーが出ていないか、レコードの種類が想定どおりかを確認します。初回の取得結果は、利用中のネットワーク、URLの有効性、リモート側の応答に左右されます。保存しただけでは読み込みが成功したとは限りません。

追加方法・応答・内容を分けて確認

リストが空の場合は、まずサブスクリプションのレコードに戻り、URL全体が正しく入力されているかを確認します。そのうえで、リクエストの失敗と解析の失敗を切り分けてください。リクエストに失敗する場合は、端末のネットワーク、DNS、リモートへの到達性、認証状態を確認します。解析に失敗する場合は、Webページやログイン画面、エラーテキストが返っているか、応答形式が現在の取り込み方法に合っているかを確認します。リストが空だからといって、プロトコル項目をむやみに変更したり、最初に古いレコードをすべて削除したりしないでください。確認中も復旧できる状態を保つため、現在使えるレコードは残しておきましょう。

URLに長いクエリパラメータが含まれている場合、ドメインが同じかどうかだけでなく、手元の元データと一つずつ照合してください。リモートアドレスのパラメータは、アカウント、形式、アクセス権を区別している場合があります。1文字抜けただけでも応答が変わることがあります。サービス提供元に問い合わせる際は、エラーの種類、発生手順、ネットワーク環境を伝えれば十分です。スクリーンショットを共有する場合は、URL、認証パラメータ、サーバーの認証情報を隠してください。「取り込みに失敗した」と説明するために、サブスクリプションの内容全体を公開する必要はありません。

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

Subscribeはサーバーレコードをどこから取得するかを扱い、Configはルールや関連設定をどのように構成するかを扱います。サーバーリストがあるだけでは、用途に合ったルールが設定済みとは限りません。ルールファイルがあっても、利用可能なサーバーが入力されているとは限りません。取り込み後はHomeに戻り、実際に選択されているサーバーを確認してからGlobal Routingを確認してください。ルールに従って通信を処理する場合はConfigを使いますが、現在有効なConfigの内容も確認してください。モード名だけで、リクエストが必ず特定の経路を通ると判断しないでください。

最後に、リストに項目が表示されたことだけでなく、実際のWebリクエストで接続を確認してください。接続のオン・オフ、サーバーの選択、リクエスト経路の詳しい手順ははじめにをご覧ください。サブスクリプションの読み込みに成功してもアクセスできない場合は、テストと並べ替えの章で原因を段階的に確認します。Subscribeの取り込み問題とサーバー接続の問題を混同しないようにしましょう。

Add Server：入力項目を一つずつ確認

Add Serverは、手元にある個別サーバーの情報を入力するときや、サブスクリプションとは別に少数のレコードを管理するときに使います。手入力する前に、アドレスとポートだけでなく、必要なパラメータ一式を用意してください。プロトコルによって認証、暗号化、トランスポート、TLSの要件は異なります。項目名が似ているからといって、前のレコードの値をそのまま使えるとは限りません。まず正しいTypeを選び、提示されたパラメータに沿って一つずつ入力してください。先にアドレスを入力してからプロトコルを変更するより確認しやすく、Typeの切り替えで追加された項目も見落としにくくなります。

基本項目と認証情報

Addressには接続先のサーバーを指定し、通常はドメイン名またはIPアドレスを入力します。Portにはサービスの待受ポートを数字で入力します。URLを指定する欄でない限り、AddressにWebページのパスや共有リンク全体を入力しないでください。PasswordやUUIDなどの認証項目は元の値を保ち、大文字・小文字、ハイフン、末尾の空白に注意します。Remarksは端末上の識別用で、認証には使われません。「用途－プロトコル－識別名」のように付けると、似たレコードを後から見分けやすくなります。

プロトコルの項目は相互に流用できない

Shadowsocksでは認証情報と暗号化方式を一致させる必要があります。VMessとVLESSでは通常、ユーザー識別子と対応するトランスポート設定も確認します。Trojanでは認証情報とTLSの要件、Hysteria2では固有の認証情報と接続パラメータを確認してください。WireGuardは鍵、アドレス、ピアなど、独自の設定構造を使用します。これらの名称はプロトコルの種類を示すもので、同じプロトコルのレコードなら追加項目も同じとは限りません。情報が足りない場合は元のパラメータを確認し、選択肢を切り替えて使える組み合わせを探さないでください。

TLSで使う名前、HTTP Host、サーバーのAddressは同じ場合も異なる場合もあります。すべてドメイン名だからといって同一の項目として扱わないでください。Addressは接続先を特定するためのものです。SNIは証明書の識別に関係し、トランスポートによってはHostやパスがサーバー側の入口との照合に使われます。サーバー情報にこれらの項目が明記されている場合は、その値を使ってください。接続できないときは、証明書の確認を弱めて名前の誤りを覆い隠すのではなく、項目を一つずつ照合します。パラメータの誤りと証明書の問題は別々に調べてください。

保存後は最小限の確認を行う

レコードを保存したらHomeに戻り、追加されたことと選択マークの位置を確認してください。名前の似たサーバーを複数登録している場合、一覧の名前だけでは取り違えることがあります。詳細を開き、アドレスの末尾、プロトコル、Remarksを確認しましょう。新しいレコードをテストしてから実際のリクエストを試してください。似たレコードを一度に大量に追加してからまとめて原因を調べるのは避けます。変更する項目は一度に一つにし、変更理由を記録しておくと、認証、トランスポート、端末のネットワークのどれが結果に影響したか判断できます。

手動で登録したレコードは通常、ユーザー自身で管理します。サブスクリプションの更新でパラメータが修正されるとは限りません。一方、サブスクリプションから作成されたレコードは編集できても、次回更新時にリモートの内容で再作成され、変更が残らないことがあります。個別に調整する必要がある場合は、保存の仕組みを確認してから、元のサブスクリプションとの関係が分かる名前で手動レコードを別に保存してください。同じ名前のレコードをバックアップ代わりにしないでください。バックアップには完全なパラメータと復元方法が必要で、リストに別のタイトルを残すだけでは不十分です。

同じネットワークでほかのレコードは正常なのに特定のレコードだけ失敗する場合は、まずそのレコードのプロトコルと認証情報を確認してください。すべてのレコードが同時に失敗する場合は、ネットワーク環境、接続状態、実際のリクエスト経路を確認します。対象を絞って調べるほうが、サーバーの追加や削除を繰り返すより効果的です。

QRコード・クリップボード：取り込み前に内容を確認

Scan QR Codeやクリップボードは入力方法にすぎず、入力内容の種類を決めるものではありません。QRコードには個別サーバーの共有リンク、サブスクリプションURL、あるいは一般的な説明文が含まれている場合があります。クリップボードにもタイトル、案内文、複数のアドレスが一緒にコピーされていることがあります。取り込み前に、定期的に更新するサブスクリプションなのか、個別のサーバーレコードなのかを確認し、適切な方法を選んでください。一般的なWebアドレスをサーバーとして取り込んだり、サーバーリンクをSubscribe URLとして入力したりすると、その後の動作が想定と異なります。

Scan QR Codeで読み込むときの確認手順

Homeでスキャンの入口を探し、Scan QR Codeを使います。初めてカメラを使うときは、システムの案内に従ってアクセスを許可するかどうかを選んでください。カメラへのアクセス許可はQRコードの読み取りに使うもので、ネットワーク接続の許可とは別です。読み取るときはQRコード全体を枠内に収め、反射、傾きすぎ、画像のぼけを避けてください。内容を認識したら、サーバーの詳細、サブスクリプション情報、その他の案内のどれが表示されたかを確認します。確認画面がある場合は、保存前にプロトコル、Remarks、アドレスが手元の情報と一致しているか確認してください。

QRコードが同じ端末内の画像にある場合、現在のスキャン画面に写真から読み込む選択肢があれば、その画像を選べます。選択肢がない場合は、元の情報からテキストをコピーしてください。画面を何度も撮影する必要はありません。読み込みに失敗したら、まず画像の鮮明さ、端の欠け、圧縮、内容の長さを確認します。すぐにサーバーが使えないと判断しないでください。QRコードをまだ文字列として読み取れていない段階では、ネットワーク接続は関係しません。両者を分けて調べましょう。

必要なテキスト全体だけをクリップボードにコピー

コピー時は、完全なリンクを1件だけ選択するようにし、項目番号、引用符、末尾の句読点を含めないでください。Shadowrocketに戻ったときにクリップボードへのアクセスや取り込みの案内が表示されたら、コピー元を確認してから続けます。現在の画面に取り込みメニューがある場合は、そちらも使えます。貼り付けの許可を求められたときは、今回の操作に応じて選択してください。案内が表示されなくても、アプリの不具合とは限りません。クリップボードの内容が不完全、形式が認識されない、システムの権限や操作経路が異なるといった可能性があります。

取り込み後に新しいレコードが表示されない場合は、同じ項目がすでに存在していないか、テキストが説明文だけになっていないかを確認してください。案内を表示させようとして異なる内容を続けてコピーすると、元の情報が上書きされることがあります。複数の共有リンクを含むテキストを取り込む場合は、まず元データを別に保管してから、分けて取り込み結果を確認します。一括取り込みに成功しても、各項目のパラメータが正しいとは限りません。少なくともプロトコル、名前、所属グループを確認し、重要なレコードは一つずつ検証してください。

権限、保存、接続はそれぞれ別の手順

カメラ、写真、クリップボードへのアクセス許可と、初めてVPN構成を追加するときのシステム許可は、それぞれ用途が異なります。取り込みは端末にパラメータを追加する操作です。接続を有効にする際には、システムからVPN構成の追加を求められる場合があります。システム上部の表示だけ、またはHomeのスイッチだけで、取り込みが完了したと判断しないでください。保存後はレコードの場所を確認し、サーバーを選択してGlobal Routingを確認してから、実際のリクエストを送ります。こうすることで、エラーがどの段階で起きたのか切り分けやすくなります。

取り込み後は、クリップボードに機密情報が残っていれば削除し、QRコード画像もご自身の情報管理方法に従って扱ってください。復元用データを保管する場合は、公開アルバム、共有メモ、チャットグループではなく、保護された場所を使います。クリップボードのコピーを削除しても、すでに漏えいした認証情報は無効になりません。漏えいが疑われる場合は、該当サービスの管理画面で認証情報を変更し、クライアントのレコードも更新してください。

同じ情報でも入力方法によって結果が異なる場合は、QRコードの見た目ではなく、実際に認識されたテキストを比べてください。改行、エンコード、文字の欠落は、コピーや読み取りの過程で発生することがあります。「テキストを読み取れるか」「レコードとして解析できるか」「接続を確立できるか」の3段階に分けて確認しましょう。

共有リンク：プロトコル、エンコード、Configを見分ける

サーバーの共有リンクは、プロトコルの識別子に続いて、認証情報、接続先、ポート、追加パラメータを含む形式です。一方、Subscribe URLはリモートの情報を取得するためのアドレスです。どちらもリンク形式ですが、用途は異なります。形式を判断するときは、プロトコルの略称や名前だけで決めず、全体の構造を確認してください。一見普通のHTTPSアドレスでも、サブスクリプションの入口の場合もあれば単なるWebページの場合もあります。プロトコル付きのリンクも単一サーバーを表すだけかもしれず、「サブスクリプション」という名前が付いていても自動更新できるとは限りません。

プレフィックスは種類の目安であり、有効性の証明ではない

よく使われるプロトコル共有リンクのプレフィックスには、ss://、vmess://、vless://、trojan://があります。プレフィックスは解析方法の目安になりますが、後続の項目がすべてそろっているとは限りません。また、現在のクライアントが拡張パラメータをすべて受け付けることを保証するものでもありません。形式によっては内容がエンコードされてリンクに含まれ、別の形式ではクエリパラメータでトランスポートやTLSを指定します。まず手元の情報をそのまま取り込み、詳細画面で解析結果を確認してください。記憶を頼りに有効なレコードを組み立てるのは避けましょう。

エンコードされた長い文字列は、安全な暗号化を意味するものではありません。認証情報や設定を転送しやすいテキストに変換しただけの場合があり、リンクを入手した人が内容を復元できる可能性があります。リンク末尾のRemarksは表示用であることが多く、変更しても認証情報は変わりません。クエリパラメータの文字にも構文上の意味があります。区切り文字が消えたり、誤った形式に変換されたりすると、別の項目として読み取られる場合があります。リンク全体を一括置換で「整理」したり、意味が分からないパラメータを不要と決めつけて削除したりしないでください。

ルールファイルとサーバーリンクの違い

ShadowrocketのConfigファイルはセクションごとに構成されます。以下は実際のルール構文を示す例で、サーバーの認証情報を含まず、個人用Config全体でもありません。ルールは上から順に評価され、FINALは最後に置いて、それまでのルールに一致しなかったリクエストを処理します。例のPROXYとDIRECTはルールの処理方法を示すもので、PasswordやサブスクリプションURLの代わりにはなりません。サーバーを取り込んだ後も、現在のConfigを確認してください。ルールのテキストをAdd Serverのアドレス欄に貼り付けないでください。

[General]
bypass-system = true

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

Configモードでは、実際のリクエストは現在のConfigのルールに従って処理されます。ProxyモードとDirectモードでは処理方法が異なります。そのため、サーバーをテストする前にGlobal Routingを確認してください。リクエストが実際にはDirectで処理されていると、選択したサーバーの接続確認ができたと誤解するおそれがあります。3つのモードについて詳しくはGlobal Routingの選び方をご覧ください。こうした関係を理解すると、「レコードを正しく解析できたか」と「想定どおりの経路でリクエストされたか」を区別しやすくなります。

形式が一致しない場合は元データを保管する

形式を認識できない、項目が不足している、取り込み後のパラメータが明らかにおかしい場合は、手元の元データに戻り、対応する形式を確認してください。認証情報を含むリンクを、正体の分からない変換サイトにアップロードしないでください。また、エラーを消すためだけにTLS、パス、その他のトランスポート項目を削除しないでください。日本語の引用符、改行、文字の欠落がないかを手元で確認することはできますが、パラメータの変更には必ず根拠が必要です。保存できたからといって、その項目の組み合わせで接続できるとは限りません。

形式の問題をサービス提供元に伝える場合は、プロトコルの種類、取り込み方法、エラーが発生した段階、不足している項目を説明し、リンク全体は公開しないでください。比較用に元データのコピーを残すと役立ちますが、認証情報として保管してください。クライアントが現時点で特定の情報を解釈できないと分かった場合は、対応するパラメータの説明を確認してから、手入力するか再度取り込むかを決めましょう。不完全なテキストから接続方法を推測しないでください。

サブスクリプションの更新：結果を確認してから方法を調整

サブスクリプションの更新は、リモートアドレスに再度リクエストを送り、応答を処理する操作です。アプリ自体のアップデートではありません。アプリのアップデートはApp Storeで行い、サーバーリストの更新はSubscribeのレコードとリモートの内容に基づいて行います。対象も失敗原因も復旧方法も異なります。サブスクリプションを更新すると、名前の変更、新しいレコードの追加、パラメータの変更、既存レコードの削除が起きる場合があります。更新前に、現在使っているサーバーとその所属先を確認しておくと、更新後に変更点を正確に照合できます。

手動更新で基準を確認する

サブスクリプションを初めて設定するときは、まず手動更新を1回行い、結果を確認してください。Homeの該当するサブスクリプションレコード、または関連する操作メニューから更新し、完了後に所属するサーバーリストを確認します。画面の項目名や場所はアプリの現在の表示に従ってください。個別サーバーのテストをサブスクリプションの更新と取り違えないようにしましょう。正常に更新できたかどうかは、明確なエラーがないこと、リストを解析できること、重要なレコードの項目が想定どおりであることから確認します。更新操作が終わっただけでは、各サーバーに接続できるとは限りません。

更新状態や日時が表示される場合は、今回の確認に役立つ手がかりとして使えます。ただし、それだけでリモートの内容が変わったかどうかを判断しないでください。既知のレコードを1、2件選び、名前、プロトコル、アドレスが手元の情報と一致するか確認します。リモートのリストは内容に変更がなくても正常に取得されることがあります。反対に、Webエラーが返ってきた場合は、有効なサーバーリストを取得できたとは限りません。異常があれば最初のエラー状況を記録し、連続して更新を実行して手がかりを失わないようにしましょう。

自動更新は復旧しやすさを考慮して設定

現在のSubscribe設定に自動更新や間隔の項目がある場合は、利用頻度とネットワーク環境に合わせて設定してください。まず手動更新が安定して動くことを確認します。自動更新では、無効なアドレス、誤った認証情報、非対応の形式は修正されません。条件に応じてリクエストを繰り返すだけです。設定した間隔どおりにバックグラウンドで必ず実行されるとも限りません。端末の状態、システムのスケジュール、アプリの実行条件などが実行時刻に影響します。重要な利用の前には、リモートの変更が同期済みと決めつけず、結果を自分で確認してください。

モバイル通信とWi-Fiでは接続できるかどうかが異なる場合があります。更新に失敗したら、使用中のネットワーク、接続スイッチの状態、エラーの種類を記録してください。更新リクエストが必ず選択中のサーバーを経由するとは限りません。実際の経路はアプリの設定とネットワーク状態に左右されるため、確認できる結果をもとに判断してください。ネットワークを切り替えて成功した場合は、元のネットワークにおける名前解決やアクセス条件を調べます。すぐにすべてのサブスクリプションを作り直す必要はありません。原因を把握しやすくするため、一度に変更する条件は一つにしましょう。

更新後の名前の変化とローカル編集

リモートのサブスクリプションは通常、そこから生成されたレコードのパラメータ元です。名前や項目を端末上で変更しても、次回更新時に上書きされる場合があります。特別な用途のレコードを個別に残したい場合は、別に管理し、リモート側の修正が自動で反映されないことを明確にしてください。リモートからサーバーが削除されると、端末のリストからも消えることがあります。これは手動削除とは理由が異なります。更新後に以前選択していたレコードが見つからない場合は、実際の選択状態を改めて確認してください。Homeのスイッチがオンのままでも、以前と同じサーバーを使っているとは限りません。

サブスクリプションアドレスの問題とサーバーの問題は分けて考えてください。サブスクリプションの取得に失敗しても、保存済みのサーバーに接続できるなら、リストの取得経路だけに問題がある可能性があります。リストの更新には成功しても、すべてのサーバーに接続できない場合は、認証状態、サーバー側の変更、端末のネットワークを確認してください。リモート側でサブスクリプションアドレスが実際に変更された場合は、正しいSubscribeレコードを編集して新しい結果を確認します。安定して動作することを確かめてから古い項目を整理してください。名前が同じだけで、2つのレコードが完全に同じだと判断しないでください。

更新後にWebページが正常に表示されない一方で遅延値が表示される場合は、DNS名前解決の失敗を調べるを参照してください。「リストの取得」「接続の確立」「ドメインの名前解決」「Webリクエスト」を分けて記録すると、問題の段階を取り違えて更新を繰り返すのを防げます。自動更新は、更新頻度を高めることではなく、安定して確認しやすい管理に役立ててください。

複数のサブスクリプションを整理：取得元と用途を明確にする

複数のサブスクリプションを管理する場合は、各サーバーがどのサブスクリプションから作成されたのか、自動更新の対象か、現在選択している理由は何かを把握することが重要です。数が増えると、似た名前、重複した取り込み、ローカル編集によって取得元が分かりにくくなります。整理の目的はリストを短く見せることではなく、更新、テスト、復元の対象を明確にすることです。整理を始める前に元の情報を保管し、現在使っているレコードを確認してください。取得元を見分けられない状態で、似た名前の項目を一括削除しないでください。

名前は用途を示し、認証情報は含めない

サブスクリプション名には、「個人用」「一時確認」のように用途が分かる、変更されにくい名前を付けます。手動で登録したレコードには「手動」と付けると見分けやすくなります。サーバーのRemarksにはプロトコルや用途の説明を加えられますが、完全な認証情報や、その時点の遅延値は記載しないでください。遅延は時間、ネットワーク、テスト方法によって変わり、すぐに古くなります。名前はレコードを識別するためのもので、現在の性能を判断するためのものではありません。同じ用途には一貫した命名を使えば十分で、複雑な番号体系は必要ありません。

リモートの名前が頻繁に変わる場合は、ローカルで名前を編集しても更新後に上書きされる可能性があります。保存の動作を確認してから、その編集に頼るかを決めてください。より確実に管理するには、サブスクリプションの用途、主なレコードの見分け方、必要なメンテナンスを短く記録しておきます。パスワードを複製する必要はなく、保護された元データを特定できれば十分です。機密URLを含むスクリーンショットだけを取得元の記録として残さないでください。復元に使いにくいうえ、トラブル対応で共有したときに情報が漏れるおそれがあります。

重複した取り込みと、正当な類似レコードを見分ける

名前が同じでも同じサーバーとは限りません。アドレスが同じでも同じサービスとは限りません。ポート、プロトコル、認証情報、TLS、トランスポートのパスが異なる場合があります。反対に、同じ共有リンクをQRコードとクリップボードの両方から取り込むと、見分けにくい重複項目ができることもあります。整理するときは、まずプロトコルと接続パラメータを比較し、次に所属するサブスクリプションを確認してください。表示名だけを頼りにしないでください。判断できない場合は、すぐに統合せず、目印を付けて経過を見ます。テストとバックアップを終えてから削除するほうが、元に戻しやすくなります。

同じアドレスに接続する複数のレコードでも、異なるネットワーク条件向けに設定されている場合があります。地域名やタグだけで判断せず、ご自身の用途に合わせて検証してください。名前に含まれる地理的な表現は、実際の通信の出口や固定された回線情報を保証するものではありません。このガイドでは、それを根拠にサーバーを評価しません。残すかどうかは、ご自身の要件、パラメータの完全性、テスト結果に基づいて判断してください。確認できる事実とラベルの文字列を分けて考えると、リモート側の名前が変わるたびにリストを作り直すのを避けられます。

整理してもルールの選択は変わらない

リストの並べ替え、Remarksの変更、表示順の調整は通常、管理上の操作です。それだけでルールが変わったとは判断できません。実際のリクエストには、現在のサーバー選択、Global Routing、Configを確認する必要があります。Configが特定の名前やポリシー参照を使っている場合は、名前を変更する前に参照先を確認してください。サーバーの整理とConfigのメンテナンスは別々に進めます。まずリスト上のレコードを確認し、次にルールとの関連を確認してください。一度の操作で名前、ルール、接続パラメータを同時に変更しないようにしましょう。

更新後の簡易確認用に、各サブスクリプションから検証済みの代表的なレコードを1件記録できます。ただし、これは確認用のサンプルであり、リスト全体が検証済みという意味ではありません。複数のサブスクリプションすべてで自動更新を有効にする必要もありません。それぞれの用途を明確にしてから、更新の頻度を決めてください。一時的なテストが終わったら、正式に使う項目とトラブル対応で残ったコピーを後から取り違えないよう、早めに整理しましょう。

リストの整理後は、実際のリクエストを送り、選択中のサーバーが以前と同じか確認してから管理記録を更新してください。画面上の用語が分からない場合は、Home、Config、Data、Settingsの画面ガイドをご覧ください。似たサーバーを長いリストで記憶に頼って管理するより、各操作の対象を明確にするほうが確実です。

遅延テストと並べ替え：数値から分かること、分からないこと

Connectivity Testは、特定のテスト条件で応答を確認する機能です。結果は、サーバーがあらゆる用途で使えることを証明するものではありません。テスト方法によって、接続の確立を確認する場合もあれば、特定のリクエストへの応答を確認する場合もあります。テスト先、タイムアウトの条件、ネットワーク状態も数値に影響します。数値が小さくても、ダウンロード速度が高いことや、すべてのWebページを開けることを意味しません。サーバーを比較する場合は、同じ方法と環境でテストしてから結果を見てください。時間やネットワークの異なる2つの数値を、そのまま順位付けに使うのは適切ではありません。

まず少数をテストし、実際のリクエストを確認する

Homeで使用する予定の少数のレコードをテストし、正常な結果、タイムアウト、明確なエラーのどれが表示されるかを確認します。テスト後に1件を選択し、Global Routingと現在のConfigを確認してから、用途が分かっているWebページを開いてください。実際の確認では、DNSの名前解決、接続の確立、ページ内容の読み込みまで確認します。ページタイトルが表示されただけでは不十分です。リストのテストだけを行い、実際に選択されている項目を確認しないと、テストしたレコードと使用中のレコードが異なる可能性があります。

一括テストは明らかな異常を素早く見つけるのに役立ちます。ただし、多数のリクエストを同時に送ると、端末のネットワークや接続先に一時的な負荷がかかり、結果に影響する場合があります。リストが大きい場合は、サブスクリプションや用途ごとに分け、結果が安定してから次をテストしてください。一度の一括テストでタイムアウトしたからといって、すべてのサーバーが恒久的に使えなくなったとは限りません。まず既知のレコードを1件だけ再テストし、次に別のネットワーク環境で比較してください。サーバーの変更、DNSの変更、ルールの変更、再取り込みを同時に行わず、再テスト時は条件を一つずつ変えます。

並べ替えは表示方法であり、サーバーの選択ではない

現在の画面でテスト結果による並べ替えができる場合は、今回の結果を確認するために利用できます。ただし、並べ替え後も選択マークを確認してください。画面の順番が変わっても、設定と状態から明確に確認できない限り、先頭のレコードに自動で切り替わったとは限りません。テストの数値も時間とともに古くなります。Wi-Fiからモバイル通信に切り替えれば、以前の順番が現在の状況を反映しなくなる場合があります。一度の並び順に頼らず、現在のテスト結果、実際のリクエスト、用途を踏まえて選択してください。

名前、遅延、安定性はそれぞれ異なる情報を表します。名前は情報の提供元またはユーザーが設定するもの、遅延は1回のテスト結果、安定性は複数の利用時間帯にわたって確認するものです。たまたま最小だった数値を固定のRemarksに記録し、長期的な判断材料にしないでください。特定のレコードが不安定な場合は、接続開始、Webページの名前解決、通信中のどの段階で失敗したかを記録すると、「遅い」とだけ記録するより役立ちます。サーバー側の負荷、ネットワークの変動、Configの違いも切り分けやすくなります。

失敗した段階ごとに原因を調べる

サブスクリプションの更新は正常なのにテストが広く失敗する場合は、サーバーの選択、認証情報、ネットワークへの到達性を確認してください。テスト結果が表示されてもWebページを開けない場合は、DNS、ルールの経路、アプリが実際に送信したリクエストを確認します。Webページを開けても大容量ファイルの速度が出ない場合は、その段階で継続的な通信と異なるネットワーク環境を調べてください。テスト結果が示すのは、対応する条件下で起きたことだけです。それ以外の問題まで自動的に解決したとは限りません。段階ごとに記録すると、あらゆる現象をサーバーの不具合と決めつけずに済みます。

トラブルシューティングでは、経路を切り分けるためにGlobal Routingのモードを一時的に選択できます。テスト後は通常の設定に戻し、復元後のリクエスト動作も確認してください。一時的な検証設定をそのまま長期利用しないようにしましょう。モードの説明は機能ガイド、よくある問題はトラブル対処をご覧ください。

速度を比較するときは、同じ接続先、近い時間帯、同じネットワークを使い、ほかの大容量通信は同時に行わないようにしてください。それでも結果が大きく変わる場合は、変動の範囲と条件を記録すれば十分です。固定値を求める必要はありません。段階ごとの確認方法は速度低下の段階別チェックをご覧ください。テストの目的は問題の範囲を絞ることであり、サーバーに恒久的な有効・無効の評価を付けることではありません。

削除とバックアップ：端末内の削除と認証情報の失効を区別

削除する前に対象を明確にしてください。個別のサーバー、サブスクリプションから生成されたレコード、Subscribe全体、現在のConfigでは、復元に必要な情報が異なります。誤って削除しても、更新すれば必ず戻るとは限りません。端末上のレコードを削除しても、リモートのアクセス認証情報は自動で無効になりません。漏えいへの対応が目的なら、該当サービスの管理画面で認証情報を変更または失効させてください。「端末から削除すること」と「古い認証情報を無効にすること」を別の操作として扱うと、必要な対処が完了したか確認できます。

まず、データを管理しているものを確認する

個別に手入力したレコードは、元のパラメータや、以前に保存した有効なエクスポートデータから復元します。名前だけでは認証やトランスポートを再設定できません。サブスクリプションから生成されたレコードを単独で削除した場合、後の更新で再び表示されるかどうかは、更新とリストの処理方法によります。リモートにそのレコードが残っていれば、リストに再追加される可能性があります。リモートのリスト内容を長期的に変えたい場合は、端末で同じサーバーを繰り返し削除するのではなく、該当するサブスクリプションの管理方法を確認してください。

Subscribe全体を削除する前に、所属するレコードが不要であることと、元のURLを保管していることを確認してください。削除後に関連する端末内のデータが必ず特定の形で残る、または消えるとは限りません。現在の確認画面を読み、Homeに戻って実際の状態を確かめてください。削除対象のサーバーを現在使っている場合は、明確に利用できる別のレコードに切り替え、実際のリクエストを確認してから削除します。結果が想定と異なっても、接続先と復元の手段を同時に失わずに済みます。

項目と関連情報を復元できるようにバックアップ

バックアップには、サブスクリプションの元データ、個別サーバーのパラメータ、必要なConfig、それぞれの用途と関連性を含めてください。現在の画面に共有、書き出し、バックアップ機能がある場合は、実際に対応している範囲を確認して使います。機能名だけからすべてのデータが含まれると判断しないでください。書き出した後、ファイルやテキストに必要な項目が含まれているかを確認します。特に、個別の共有リンクと全体のバックアップを区別してください。Configファイルにすべてのサーバー認証情報が含まれているとも限りません。

バックアップは適切なアクセス保護のある場所に保管し、公開共有フォルダ、グループチャット、管理されていないメモは避けてください。バックアップファイルには、サブスクリプションURL、Password、UUID、鍵が含まれる場合があり、認証情報として扱う必要があります。問題を説明するために機密情報を伏せたコピーを作ることはできますが、正式な復元データの代わりにはなりません。用途を明記して別々に保管してください。機種変更の際に、重要な項目を削除したテキストを完全なバックアップと取り違えるのを防げます。

機種変更・再インストール時は、アプリを復元してからデータを戻す

機種変更後は、まずApp Storeの購入済み項目からShadowrocketを確認して入手し、その後にご自身のサブスクリプションやサーバー情報を復元してください。アプリの購入記録とアプリ内の設定データは別のものです。アプリを再入手しても、各レコードが自動的に復元されるわけではありません。購入対象、デバイスとの互換性、システム要件はApp Storeの掲載内容をご確認ください。アプリの入手手順は購入済み項目の復元方法をご覧ください。データを戻した後も、サーバーの選択、現在のConfig、システムの接続許可を改めて確認してください。

復元を確認するときは、まず代表的なデータを少数取り込み、パラメータを照合して実際に接続してから、残りを復元します。バックアップを読み取れると確認できる前に、古い端末のレコードを削除しないでください。サブスクリプションを再取得できても、ローカルのRemarks、個別レコード、Configの変更まで戻ったとは限りません。事前に用意した復元チェックリストに沿って一つずつ確認してください。元データがあり、形式を読み取れ、必要な項目がそろっていて、動作確認まで済んで初めて、バックアップとして復元に使えます。

整理が終わったら、現在の接続、既定の選択、Configが想定どおりか確認してから、古いバックアップを処分してください。新しいバックアップの復元を確認するまでは、復元可能な古いコピーを一つ残します。古い認証情報が無効になったこと、または不要になったことを確認した後、ご自身のセキュリティ管理方針に沿って削除してください。「何を削除し、何を残し、どう復元するか」を記録しておくと、削除した日付だけを記録するより役立ちます。次の機種変更やトラブル対応でも、必要な情報をすぐに見つけられます。

このページでは管理作業ごとに手順を説明しています。接続を最初から設定する場合ははじめにをご覧ください。問題の分類が難しい場合は、機密情報を伏せたエラー表示と発生手順を保存し、トラブル対処を参照してください。原因を調べずに一括削除で対処しないでください。