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

情報の種類を確認して追加方法を選ぶ

サーバー一覧を取得するサブスクリプションURLを持っている場合は、まずSubscribeを探します。単一サーバーのAddress、Port、認証情報だけがある場合は、次章のAdd Serverを使います。違いは接続機能ではなく、情報の管理方法です。サブスクリプションは通常、1つのURLから複数のサーバー情報を取得し、あとから一覧を更新できます。手入力した情報は項目ごとに保存し、変更時も個別に確認します。単一サーバーの共有リンクをサブスクリプションURLとして入力したり、サブスクリプションのWebページURLをサーバーのAddressに入力したりすると、その後の問題切り分けが難しくなります。

Shadowrocketを開き、Configなどサーバー管理に関係する画面でSubscribeを探します。画面サイズやアプリ内の配置によって入口の位置は異なるため、現在の画面表示を確認してください。操作前に、コピーしたURLが完全か確認します。パス、クエリパラメーター、末尾の文字を欠かさないようにしてください。形式を確認するためのURLは、以下のようなダミー文字列で構いません。実際の情報は取得できません。実際のURLは機密情報として扱い、公開の掲示板やスクリーンショット、問い合わせ内容に貼り付けないでください。

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

保存後は3つの結果を個別に確認

Subscribeに手元のURLを入力し、現在の画面の案内に従って保存または更新します。まずサブスクリプションがリストに表示されるか、次に更新後にサーバー項目が作成されるか、最後にサーバーを選択して接続できるかを確認します。この3つは別々の状態です。サブスクリプション名が表示されても、内容を正しく解析できたとは限りません。サーバー名が表示されても、設定値が有効とは限りません。初回の取り込みでは、項目数と名前が手元の情報と一致するかを確認し、次に1件開いてType、Address、Portを照合してから接続をテストしてください。

リストが空の場合は、元のテキストに戻り、改行や前後の空白が入っていないか、URLの一部だけをコピーしていないか確認します。取得に失敗したという表示が出た場合は、デバイスからそのURLにアクセスできるか、また、そのURLを管理している既存の提供元が引き続き有効かを確認してください。すぐに削除と追加を繰り返すのは避けましょう。同じ名前の項目が重複し、見分けにくくなるおそれがあります。取得はできても解析できない場合は、「取得失敗」と「解析失敗」を別の手がかりとして記録します。前者はURLやネットワークへの到達性、後者は取得内容や形式に関係する可能性があります。詳しい確認手順はサブスクリプション更新失敗時の確認リストをご覧ください。

サブスクリプションとサーバー項目の関係

サブスクリプションは更新の入口で、サーバー項目は選択して使う結果です。更新後に項目の名前、順番、数が変わっても、それだけでアプリに手入力した設定が変更されたとは判断できません。まず同じサブスクリプション由来の変化かを確認し、次に現在選択中のサーバーがリストに残っているかを見ます。取得される内容は手元の情報によって決まり、Shadowrocketは受け取った内容を表示・管理します。手動で加えた変更を長期間残したい場合は、次回のサブスクリプション更新で上書きされる可能性があるかを事前に確認してください。更新で取得した項目が、常に固定されたローカルの下書きとして残るとは限りません。

初回は、内容を把握できるサブスクリプションを1つだけ追加するのがおすすめです。表示名を控え、更新前後の項目の変化を確認し、テスト結果を1回記録します。これは追加数を制限するためではなく、あとから確認できる基準を作るためです。複数のサブスクリプションを同時に追加してからリストが空になった場合、どのURLや更新が原因かを特定しにくくなります。すでに複数の項目がある場合は、複数のサブスクリプションを整理に進み、名前の付け方と確認順を決めてください。

手元の情報に合わせてTypeを選択

Add Serverは、単一サーバーの必要な情報がそろっている場合に使います。まず資料と一致するTypeを選び、そのTypeの画面に表示される項目を入力してください。プロトコルを曖昧な記憶で選び、異なるプロトコルの情報を無理に同じフォームへ入力するのは避けます。Shadowsocks、VMess、VLESS、Trojanなどはプロトコルの種類です。具体的な入力項目は、選択したTypeやアプリ内の設定によって異なります。最も確実なのは、手元の資料と現在のフォームを見比べ、項目名、形式、スイッチの状態を1つずつ照合することです。資料にない内容を推測で補わないでください。

基本項目と追加項目を確認

Addressは接続先サーバー、Portはそのサーバーが接続用に提供するポート、Remarkはリスト内で項目を見分けるためのメモです。Password、UUID、暗号化方式、TLS、SNIなどが表示されるか、どう組み合わせるかは、選択したTypeのフォームと手元の情報によって異なります。たとえばTrojanの情報ではPasswordとTLS関連項目、VMessやVLESSではUUIDや転送設定を確認することがあります。似た項目名が表示されても、異なるType間で設定一式をそのままコピーできるとは限りません。違いについては、Trojanの入力項目とVMessとVLESSの入力項目の違いをご覧ください。

手入力では、認証情報を公開せずに確認できる項目から進めます。まずType、次にAddressの文字列とPortの数値、続いてプロトコル固有の項目を確認し、最後にRemarkを入力します。保存後にその項目を開き直し、キーボードの自動置換、コピー時の空白、フォーム切り替えによって内容が変わっていないか確認してください。例にあるexample.com、443、your-passwordはすべてダミー値です。項目の形式を示すためのもので、手元の情報の代わりにはなりません。Password、UUID、秘密鍵などを公開スクリーンショットに含めないでください。

保存だけでは確認は完了しない

Add Serverの項目を保存できたことが示すのは、入力内容がフォームに受け付けられたということだけです。次にリストから項目を選び、必要に応じて接続状態やテスト結果を確認します。テストに失敗した場合は、まずTypeと各入力項目の対応を見直し、その後で追加の転送設定や認証情報が必要かを確認します。複数の項目を同時に変更しないでください。疑わしい項目を1つだけ変更して保存し、再テストすれば、どの変更が影響したかを判断できます。手元の資料を見ても判断できない場合は、元の項目のスクリーンショットや機密情報を除いたメモを残し、資料の管理元に問い合わせてください。推測を長期的に使う設定として保存するのは避けます。

手入力した項目は個別に管理でき、サブスクリプション内のサーバー設定を確認する際の参考にもなりますが、両者を同じ記録とみなさないでください。サブスクリプションを更新すると、その配下のサーバー項目が置き換わることがあります。手入力した項目は通常、自分で変更する必要があります。名前が似た項目がリストに並んでいる場合は、まず取得元とRemarkで区別してから、どちらを残すか決めます。次章ではQRコードとクリップボードからの取り込みを説明します。これらは入力方法を変えるものであり、この章で説明した項目の確認を省略できるわけではありません。

QRコードの内容を確認してから読み取る

QRコードの読み取りは、手元の情報をアプリに読み込ませる方法であり、独立したサーバープロトコルではありません。QRコードには単一サーバーの共有リンクが含まれる場合も、サブスクリプションURLが含まれる場合もあります。読み取り後の結果は、それぞれAdd ServerまたはSubscribeの手順で確認してください。ShadowrocketでScan QR Codeなどのスキャン入口を探す際は、現在のアプリに表示されている名前と位置を確認します。カメラで読み取る前に、QRコードが取り込みたい情報のものかを確かめてください。近くに印刷されたサーバー名だけで内容を判断してはいけません。読み取り後は、アプリが認識したType、アドレス、またはサブスクリプションを確認してから保存します。

同じiPhoneに表示したQRコードは、その端末のカメラで読み取りにくい場合があります。その場合は、現在のアプリに画像からの読み取りやクリップボードからの取り込み機能があるか確認してください。選択肢は画面によって異なるため、特定のボタン位置を固定の手順として考えないでください。別のデバイスに表示したQRコードなら、カメラで直接読み取れます。端末内の画像を使う場合は、画像が鮮明で全体が写っていることを確認し、アプリが現在提供している方法で読み取ります。認識に失敗した場合は、QRコードの端が切れていないか確認してください。また、内容がアプリで処理できるテキスト形式であり、単なるWebページへのリンクではないことも確かめます。

クリップボードからの入力では余分な文字に注意

クリップボードからの取り込みは、共有リンクやサブスクリプションURL全体をすでにコピーしている場合に便利です。コピーする際は対象の文字列だけを選び、説明文、引用符、箇条書き記号などを一緒に含めないようにします。アプリにクリップボードを認識する入口があれば、プレビューで内容を確認できます。適切な入口がない場合は、内容の種類に応じてSubscribeまたはAdd Serverの該当項目へ貼り付けます。コピーしただけで自動的に項目が作成されるとは限りません。貼り付け後の確認をせずに接続しないでください。メッセージ画面ではリンクが短縮表示されることがありますが、クリップボードに完全な文字列が入っているかは別途確認が必要です。

認識後は「何が取り込まれたか」を重点的に確認します。サーバーが1件表示された場合は、Type、Address、Port、認証項目、Remarkを確認します。サブスクリプションURLが表示された場合は、Subscribeとして保存されたかを確認し、更新後にサーバーリストを確認してください。QRコードとクリップボードは入力手段にすぎず、情報が完全かどうかを判断するものではありません。QRコードに複数行のテキストが含まれている場合、アプリが処理可能な一部だけを認識することがあります。期待と異なる結果になったら、認識済みの不完全な項目に推測で情報を追加するのではなく、元のテキストを確認してください。

取り込みに失敗した場合の手順

QRコードを読み取れない場合は、まず画像、明るさ、カメラのアクセス許可を確認し、その内容が手元のサブスクリプションURLまたはサーバー共有テキストであることを確かめます。クリップボードから取り込めない場合は、コピーした内容をデバイスの通常のテキスト入力欄に貼り付け、先頭と末尾の文字を確認します。空白、改行、説明文が含まれていないことを確認してから、アプリで再試行してください。テキスト自体が不完全なら、入口を変えても不足項目は補えません。内容が完全なのに認識されない場合は、次章の形式の見分け方を参考に、サブスクリプションURL、単一サーバーのリンク、手入力用の項目一覧のどれかを確認します。

取り込み後、すぐに何度もQRコードを読み取って同じ項目を追加しないでください。重複した項目は同じRemarkで表示されても、追加した時期が異なり、接続時にどちらを選んだのか判断しにくくなることがあります。新しい項目を開いて取得元を確認し、同じアドレスと設定がすでに登録されていないか調べます。既存のサブスクリプションを更新する場合は、同じQRコードを繰り返し読み取るのではなく、そのサブスクリプションの更新操作を使ってください。重複項目を削除する場合は、最終章に沿って保存と削除前の確認を行います。4つの追加方法の比較はサーバーを追加する4つの方法をご覧ください。

リンクが一覧を示すのか、単一の項目を示すのか確認

サブスクリプションURLは通常、アクセスするとサーバー一覧を取得できるWeb形式のURLです。アプリがそのURLにアクセスし、解析可能な一覧を取得します。一方、サーバー共有リンクは通常、単一サーバーの設定をテキストに含み、アプリが読み込んで項目を作成します。どちらもコピーでき、QRコードに含められますが、同じ項目に入力してはいけません。判別する際に、先頭がhttps://かどうかだけで判断しないでください。サブスクリプションURLの場合もあれば、説明ページのURLにすぎない場合もあります。手元の資料にある用途の説明と、Shadowrocketで取り込んだ後のプレビューを確認するのが確実です。Subscribeの項目として表示されるのか、単一サーバーのTypeと設定として表示されるのかを見ます。

共有リンクには、プロトコルを示す情報やエンコードされた認証情報が含まれていることがあります。Shadowsocks、VMess、VLESS、Trojanのリンク形式が使われる場合もありますが、画面上ですべての項目を読み取れるとは限りません。リンク末尾に表示名用のRemarkが付くこともありますが、認証項目と混同しないでください。「内容を理解する」ためにエンコードされた文字列の大文字・小文字、記号、パーセント記号を勝手に変更しないようにします。解析に影響するおそれがあります。取り込み後に項目を確認できる場合は、まずアプリ内で照合してください。設定を変更するときは、途中で切れた共有テキストから推測せず、手元の資料に明記された値を使います。

読みやすい例でサブスクリプションURLを確認

以下のURLは、ホスト名、パス、クエリパラメーターという構造を示すためのものです。いずれも例示であり、実際の内容ではありません。パスはURLの一部で、クエリパラメーターも取得内容に影響することがあるため、コピー時は文字列全体を保持してください。実際のサブスクリプションURLには識別情報が含まれることがあります。問題を説明する際は、URL全体を公開せず、「URLを開けるが解析結果が空」といった現象だけを伝えてください。形式確認用のダミー値では、実際のURLにアクセスできるかどうかも、接続できるかどうかも確認できません。

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

手元の資料がAddress、Port、Passwordなどの項目別一覧で、共有リンクやサブスクリプションURLがない場合は、Add Serverに手入力します。反対に、完全なサブスクリプションURLがある場合は、URLをAddressとPortに分解する必要はありません。サブスクリプションのWebページがあるホストは、その配下にある各サーバーのAddressではありません。この2種類のアドレスを区別することが重要です。サブスクリプションのホストをサーバー項目に入力すると、見た目は完成していても意図どおりに動作しないことがあります。

対応形式と解析の範囲

手元の情報によってエンコード形式や項目の組み合わせは異なります。実際に認識できる形式は、現在のShadowrocketでの取り込み結果を確認してください。アプリがTypeを認識しても、転送設定、TLS、認証情報などの追加項目がそろっているかを確認する必要があります。同じプロトコルの共有リンクでも、転送設定が同じとは限りません。取り込み後に項目が不足している場合は、まず元のテキストが完全か確認し、次に資料に不足項目が記載されているかを確認します。別のサーバーの項目を流用して補わないでください。リンクを解析できない場合は、エラーメッセージと機密情報を除いた形式の情報を残し、「テキストの欠落」「取り込み方法の誤り」「現在の形式でサポートされていない項目」の順に確認できるようにします。

手元の情報を共有・転送するときは、リンクにサーバー項目を再現できる情報が含まれている場合があることに注意してください。QRコード、クリップボードの履歴、完全なURLが写ったスクリーンショットを公開すると、認証情報も漏れるおそれがあります。2つの項目が同じかを確認する場合は、Type、Remark、資格情報を含まない項目を端末内で比較します。問題を他の人に説明する場合は、example.comやyour-passwordのような明らかなダミー値を使ってください。元のテキストを公開せずに、問題がSubscribe、共有リンクの解析、Add Serverへの手入力のどこで起きたかを伝えられます。

更新するとサブスクリプションの内容を再取得

Subscribeで更新すると、そのURLが現在返す情報をアプリが再取得します。すべてのサーバーを「高速化」したり、誤った設定を自動修正したりする機能ではありません。更新後は、取得内容によってリストの名前、項目数、設定が変わることがあります。元のサブスクリプションに一時的にアクセスできない場合は、まずアプリの表示と既存リストの状態を確認してください。元のサーバーが恒久的に使えなくなったと決めつけないでください。更新前に現在選択中の項目とサブスクリプション名を記録します。更新後に想定した変化と実際の結果を照らし合わせてから接続をテストすれば、内容が本当に変わったのか、端末での選択状態だけが変わったのかを区別できます。

安定して使えている項目について、接続に問題が起きたとき最初に何度も更新する必要はありません。サーバー1件だけ接続できない場合は、その項目のテスト結果と実際の接続状態を確認します。同じサブスクリプション内の複数項目で異常が起きた場合は、サブスクリプションURLと今回の取得内容を確認してください。手元の情報に変更通知があった場合は、該当するSubscribeだけを更新し、すべてをまとめて更新しないようにします。こうすることで、リストの変化をどの項目、どの操作に結び付けるか追跡しやすくなります。

エラーを取得失敗と解析失敗に分ける

取得に失敗した場合は、サブスクリプションURLが完全か、デバイスの現在のネットワークからアクセスできるか、元のURLがまだ有効かを確認します。解析に失敗したり、更新後にリストが空になったりした場合は、取得内容がアプリで解析できるサーバー情報か、説明ページのURLをサブスクリプションURLとして使っていないか、元のテキストに改行が追加されたり一部が欠けたりしていないかを確認します。更新成功と表示されても期待した項目がない場合は、どのサブスクリプションを表示しているか、同じ名前の項目がないか、並べ替えやフィルターで表示位置が変わっていないかも確認してください。原因が分かるまでは元の項目を削除せず、1つの原因候補ずつ調べます。

自動更新の設定が現在の画面にある場合は、使い方に合わせて設定してください。すべてのサブスクリプションに同じ更新間隔が必要とは限りません。頻繁に更新するとリストの変化を追跡しにくくなります。反対に、更新結果を長期間確認しないと、手元の情報と一致しない古い項目を使い続けることがあります。どのサブスクリプションを定期的に確認するか、どれを情報に変更があったときだけ手動更新するかを記録し、更新後は完了表示だけでなく項目数、名前、重要な設定を確認してください。更新にはデバイスのネットワーク接続が必要です。オフラインのとき、過去のテスト結果で今回の取得成功を判断することはできません。

更新後に接続状態を誤判定しないための確認

まず更新前に使っていた項目を探します。リストに残っている場合は、Type、Address、Port、必要な追加項目に変更がないか確認します。名前が変わった場合は、Remarkだけに頼らず、所属するサブスクリプションと設定項目で探してください。次に、利用可能な接続またはテストを実行し、必要であればHomeで現在選択中のサーバーとGlobal Routingの状態を確認します。Global RoutingのConfig、Proxy、Directは、それぞれ設定に従う、プロキシを使う、直接接続する状態を示します。ルーティング状態が異なると、テストや普段のアクセス結果も異なる場合があります。サーバー設定、ルールの経路、接続先サービスへの到達性のどれを確認しているのかを明確にし、すべてを「更新失敗」としてまとめないでください。

更新後の結果が予想と大きく異なる場合は、サブスクリプションの表示名、更新時のメッセージ、項目数の変化、対象項目のTypeなど、変化を説明できる機密情報を含まない情報を保存します。現在の状態を何度も上書きしたり、URLを公開して質問したりしないでください。5段階の確認リストに沿って原因を絞り込みます。具体的なURLや認証情報は、その情報の管理元にだけ確認してください。サブスクリプションを追加し直す前に、削除とバックアップの章を読み、既存情報を別途保存しているか確認します。

名前は用途の記録に使い、設定項目の代わりにしない

Subscribe、手入力したサーバー、QRコードから追加した項目が混在すると、問題になりやすいのは件数の多さではなく、項目同士の関係を見分けにくいことです。まず各サブスクリプションに判別しやすい表示名を付け、手入力項目のRemarkはそれと区別できるようにします。名前には用途や取得元の種類を記して構いませんが、Password、UUID、完全なサブスクリプションURLなどの機密情報は含めないでください。また、「高速」「常に使える」といった内容を恒久的なメモとして残さないようにします。テスト結果は変わる一方、Remarkは長期間リストに残り、古い判断につながるおそれがあります。

整理するときは、まずサブスクリプション項目を確認し、次にその下にあるサーバー項目を見て、最後に個別に手入力した項目を確認します。2つの項目のRemarkが同じでも、すぐに片方を削除しないでください。それぞれを開き、Type、Address、Port、サブスクリプション由来かどうかを確認します。同じサーバーが異なる方法で2件登録されている場合もあれば、名前だけが同じで設定が異なる場合もあります。サブスクリプション更新後はリストの順番が変わることがあるため、「先頭が前回の項目」といった覚え方に頼ると選び間違えやすくなります。並べ替えやフィルターを頻繁に使う場合は、現在の表示順が何に基づくか把握してください。

リストの項目と現在使用中の項目を区別する

サーバーがリストに保存されていても、Homeでその項目が選択されているとは限りません。接続を確認する際は、まず選択中の項目を特定し、どのサブスクリプション由来か、または手入力したものかを確認してから、Global Routingを見ます。Configでは設定ルールに従って通信を処理します。Proxyでは対応するプロキシの状態で処理し、Directでは直接接続します。以下の比較は問題を整理するためのもので、実際の通信は現在の設定とアプリ画面に従います。ルーティング状態を記録しておくと、Directでの結果を特定サーバーの影響と誤認せずに済みます。

サブスクリプションの更新後に似た項目が多数追加された場合は、まずサブスクリプションごとに確認してから並べ替えを検討します。遅延の数値や名前だけでは項目を特定できません。同じ名前でもAddressが異なる場合があり、遅延はテスト時のネットワーク状況で変わります。「サブスクリプションの表示名 → サーバーのTypeと機密情報を含まないアドレス情報 → 現在の選択状態 → テスト結果」のように、決まった確認順を作ると便利です。リストの順番が変わっても確認対象を見つけ直せます。使わなくなった項目は、現在のConfigで選択されていないか確認してから削除してください。

Configとサブスクリプションのサーバーリストを区別

Configにはルール設定が保存されている場合があります。ルール設定とSubscribeのサーバーリストは別の情報です。ルール内のPROXYやDIRECTなどはポリシーのキーワードであり、サブスクリプション名ではありません。以下の例は、ドメイン、地域、最終的な通信がどのようにマッチするかを示すもので、構文の確認用です。使用可能なサーバー情報は含まれておらず、SubscribeのURL欄に貼り付けるものでもありません。ルールが指定するポリシーと現在利用できるサーバーが一致しない場合は、サブスクリプションの更新を繰り返すのではなく、Configとサーバーの選択を分けて確認します。

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

複数のサブスクリプションを管理する目的は、リストの項目数をできるだけ減らすことではなく、更新やテストの対象を毎回特定できるようにすることです。まず、項目と取得元を見分けられる名前を残し、実際の利用状況に応じて整理します。DOMAIN-SUFFIX、GEOIP、FINALについて詳しく知りたい場合は、用語集をご覧ください。初めてGlobal Routingを選択する手順はクイックスタートで確認できます。

テスト対象を把握してから実行

遅延テストは通常、現在のネットワーク環境でサーバーがどの程度応答するかを確認するためのものです。Connectivity Testなどの診断機能は、画面の説明からテスト対象を確認してください。数値が表示されても、すべてのWebサイトやルール経路で同じ応答になるとは限らず、日常的な接続確認が完了したわけでもありません。テスト前にデバイスがネットワークに接続できることと、対象のサーバー項目が正しく取り込まれていることを確認し、現在のネットワーク環境を記録します。条件が異なる時間に同じ項目をテストして結果が変わっても、テスト条件の変化による可能性があり、サブスクリプションの内容が変更されたとは限りません。

まず、項目を照合済みのサーバーを少数選んでテストし、数値、失敗メッセージ、待機状態のどれが表示されるか確認します。数値は同じ条件で同時に行ったテスト同士を比べるための参考情報です。失敗メッセージは、Type、Address、Port、認証情報、ネットワークへの到達性と合わせて判断します。遅延が低いというだけでその後の確認を省略したり、1回タイムアウトしただけで項目を削除したりしないでください。テストのリクエストは、実際のアクセスとは異なる接続先や経路を使う場合があります。特にConfigのルールを使う場合は、サーバーへの接続をテストしているのか、ルール経由の接続先をテストしているのかを確認します。

並べ替えは表示方法であり、情報の変更ではない

遅延や別の条件で並べ替えると項目を探しやすくなりますが、通常変わるのはリスト上の表示順であり、情報自体の固定順ではありません。サブスクリプションの更新、並べ替え条件の変更、再テストによって項目の位置は変わります。確認するときはサブスクリプションとの関係や設定項目を使って特定し、「3番目のサーバー」だけを手がかりにしないでください。テストに失敗した項目が末尾に移動しても、サブスクリプションから消えたとは限りません。まずフィルターと並べ替えの状態を確認し、本当に項目がなくなったのか判断します。

2つのサーバーを比較する場合は、同じネットワーク、近い時間帯にテストし、Typeと取得元も確認してください。テスト結果は次に確認する対象を決める参考になりますが、設定項目の照合に代わるものではありません。テストでは到達可能と表示されても実際のアクセスが想定と異なる場合は、Homeでその項目が選択されているか確認し、Global RoutingがConfig、Proxy、Directのどれかを見ます。Configの場合は、ルールがどのポリシーにマッチするかも確認してください。反対に、実際の利用に問題がなく単独テストで数値が表示されない場合も、すでに正常に動作している設定をすぐ変更せず、テストの対象と表示内容を確認します。

サーバーの診断からルールの診断へ

サーバーの設定項目と接続状態を確認したうえで、ルールを調べます。以下は設定内でよく使われるマッチ形式の例です。DOMAINは指定したドメイン、DOMAIN-SUFFIXはドメインの末尾、IP-CIDRはIPアドレス範囲にマッチし、FINALは前のルールにマッチしなかった通信を処理します。ルール例にあるexample.comとIPアドレス範囲は構文の確認用です。PROXYが想定どおりに動くかどうかは、現在のConfigとサーバー選択によります。ルールの断片を遅延テストの接続先一覧として扱わないでください。

[Rule]
DOMAIN,example.com,PROXY
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT
FINAL,PROXY

問題が特定の接続先だけで起きる場合は、まずその接続先に適用されたルールを確認し、次に対応するポリシーと現在のサーバーを見ます。複数の接続先で失敗する場合は、サーバーへの接続、サブスクリプションの更新、デバイスのネットワーク状態を確認してください。このように局所から全体へ順に調べるほうが、サーバー変更、サブスクリプション更新、ルールの書き直しを同時に行うより原因を特定しやすくなります。テストと並べ替えは管理のための機能であり、修復操作ではありません。次に確認する層を見極めるためのもので、元の設定項目やルールの確認に代わるものではありません。症状別の情報はトラブルシューティングをご覧ください。

削除する対象の種類を確認

リストを整理する前に、サブスクリプション項目、サブスクリプションから作成されたサーバー項目、手入力したサーバー、Configのルール設定を区別します。どれかを削除すると、その後の更新や現在の選択状態に影響することがあります。名前が似ているという理由だけで複数項目をまとめて削除しないでください。サブスクリプションを削除する場合は、サーバー項目の更新元としてまだ使われていないか確認します。サーバーを1件削除する場合は、現在選択中か、次回のサブスクリプション更新で再表示されないか確認してください。Configを削除する場合は、残しておきたいカスタムルールがないか先に調べます。画面に表示される削除対象と確認メッセージを正確に読んでください。

安全に進めるには、まず対象項目の取得元と機密情報を含まない設定を確認し、次に現在の接続がその項目に依存しているかを調べ、最後に元の情報を自分で保管していることを確かめます。サブスクリプションURL、サーバーの認証情報、ルールファイルはそれぞれ役割が異なります。リストのスクリーンショットだけでは設定を再作成できない場合があります。一方、完全な機密情報が写ったスクリーンショットを公開するのも適切ではありません。バックアップは自分で管理できる場所に保存してください。名前や用途を記録するメモには、機密情報を除いた文字列を使います。復元に必要な完全な情報は、機密性に応じて適切に保管してください。

サブスクリプション、手入力項目、ルールを個別に保存

サブスクリプションを再作成するには、少なくとも手元にある完全なサブスクリプションURLと、それを見分けるための名前を保存します。手入力した項目を再作成するには、Typeに応じた必須項目と追加設定を保存します。カスタムルール設定は内容を別に保存してください。サブスクリプションURLを保存すれば手入力したサーバーもすべて残る、または共有リンク1つで以前のルールファイルまで復元できると考えないでください。アプリにExport、共有、Import from Cloud JSONなどの入口がある場合は、まず画面の説明を読み、どの種類の情報が対象かを確認してから使うか判断します。名前だけを見て、各入口が扱う範囲を推測しないでください。

バックアップを実行したら、既存の項目を変更せずに内容を確認します。サブスクリプションと手入力項目を見分けられるか、テキストが途中で切れていないか、ルールの改行と順番が保たれているかを確認してください。認証情報を含むファイルやテキストのバックアップ確認に、公開コメントやスクリーンショットを使わないでください。自分用の確認メモだけが必要な場合は、サブスクリプション名、サーバーのType、機密情報を含まないRemark、操作日を記録したメモを別途作成できます。整理には役立ちますが、完全な復元情報の代わりにはなりません。

削除後に再取り込みが必要か確認

削除後はリストに対象項目が確かになくなったか、現在選択中の項目が変わったか、ほかのサブスクリプションを従来どおり更新できるか確認します。サブスクリプションから作成されたサーバー項目を削除しても、サブスクリプション自体が残っていれば、次回更新時に再び追加されることがあります。サブスクリプションを削除した場合は、それを使った更新方法も改めて確認してください。作り直す場合は、SubscribeまたはAdd Serverの章に沿って適切な方法を選び、QRコード、クリップボード、手入力から同じ項目を重複して作成しないでください。

デバイスを変更したり、アプリを再入手したりする場合は、まず購入済みアプリの復元方法に沿ってApp Storeの購入履歴を確認し、その後にサブスクリプションや設定情報を確認します。ShadowrocketをiPhoneやiPadで入手する方法とシステム要件は、App Storeのページに記載された内容をご確認ください。アプリの購入状態とサーバー情報の保存は別のものです。アプリの買い切り購入と通信サービスの契約は別で、購入済みアプリを復元しても、手動で保存したサーバーの設定項目がすべて自動で再作成されるわけではありません。不明な点がある場合は、アプリ、サブスクリプション、サーバー項目、ルール設定のどれが不足しているか確認してから、該当する情報を復元してください。