Shadowrocket 購読ガイド

01 · Subscribe：管理可能な購読を登録する

最初に、受け取った情報が購読URLかサーバー情報かを確認

始める前に、手元の情報が何に使うものか確認します。購読URLは複数のサーバー情報を取得するためのリモート入口で、通常はHTTPS形式です。一方、サーバー共有リンクには、1台分のサーバーのプロトコルやパラメーターが記載されています。どちらも長い文字列の場合がありますが、長さでは判別できません。付属の説明を確認し、Subscribe用か、サーバーを直接取り込むためのものかを判断してください。アカウント管理ページのURLを購読URLとして使ったり、サーバーのドメインだけを購読URL欄に入力したりしないでください。

Homeの右上にある追加ボタンからAdd Serverを開き、TypeでSubscribeを選択します。画面のレイアウトが変わる場合があるため、現在表示されている英語の項目名に従って操作してください。既存の購読URLをURL欄にすべて入力し、識別しやすいメモを付けます。メモには「個人用・日常利用」のように用途や管理対象を記載し、アクセス情報は含めないようにします。保存後にHomeへ戻り、購読とサーバー情報が表示されるか確認してください。URLだけが保存され、内容をまだ取得していない場合は、手動で更新します。

URLの前後にある空白や改行、チャットアプリによって置き換えられた記号は、取得エラーの原因になります。貼り付け後は、疑問符以降のパラメーターがすべて含まれているか、英数字や記号が置き換わっていないか、説明文が混入していないか確認してください。URL内のクエリパラメーターはアクセス認証に使われることがあるため、表示を短くする目的で削除しないでください。また、公開オンラインデコードサービスに入力しないでください。確認時は先頭、末尾、パラメーター名を照合すればよく、画面共有でURL全体を表示する必要はありません。

保存後に一覧と選択状態を確認する

購読内容を取り込んだら、まず想定したグループに追加されているか確認し、サーバー名、プロトコル、件数の変化が手元の情報と一致するかを見ます。名前はメモにすぎず、同じ名前でもポートや通信設定が異なる場合があります。初回の取り込みでは1件を選び、詳細画面で基本項目を確認してからHomeに戻り、現在の選択状態を確かめてください。一覧に表示されたからといって、接続に必要なConfigの選択やシステム許可の確認を省略しないでください。

Subscribeを使う利点は、リモートのサーバー集合とローカルの一覧を継続して管理できることです。各サーバーを個別に手入力するための機能ではありません。次回の更新で、集合内のサーバーが追加、削除、置き換えられることがあります。購読から取り込んだ項目を直接編集すると、次回更新時に変更内容がリモートの情報で上書きされる場合があります。一時的な検証では、まず元の値を記録してください。長期的に保持する必要がある独自設定は、アプリで対応している独立した項目として管理し、元の購読と連動して更新されないことを把握しておきましょう。

取り込みに失敗したら、段階ごとに原因を確認

保存時に拒否された場合は、まずURL欄と入力形式を確認します。保存できても取得に失敗する場合は、URLへのアクセス可否、認証の有効性、返された内容を確認してください。リモート側がログインページや案内ページ、空のテキストを返しても、ブラウザーではリクエストが成功したように表示されることがあります。しかし、それらは解析可能なサーバー情報とは限りません。「ページを開ける」ことだけを根拠に、アプリの解析エラーと判断しないでください。手元の情報からURLが本当に購読用か確認し、アプリに表示されたエラーメッセージと照合します。

トラブル対処では、一度に変更する条件を1つに絞ります。まず元のURLをコピーし直して更新し、それでも失敗する場合はWi-Fiとモバイル通信で結果を比較し、どの段階で発生したか記録してください。グループや選択状態の情報が失われるため、削除と再登録を何度も繰り返すのは避けましょう。以前の一覧がまだ使える場合はそのまま残し、リモート側の内容を確認してから更新してください。初回接続の手順ははじめにをご覧ください。エラーの状況から調べる場合はよくある質問もご利用ください。

02 · Add Server：各項目を確認して手動登録

最初にTypeを選択し、共通項目を入力する

Add Serverは、ユーザーが用意したサーバー情報1件を独立した項目として登録するときに使います。プロトコルによって必要なパラメーターが異なるため、まずTypeを選択してから項目を入力してください。初期状態のフォームにすべて入力してから、あとでプロトコルを切り替える方法は避けましょう。切り替え後に不要になる項目や、改めて確認が必要な必須項目があります。手元に購読URLしかない場合はSubscribeの手順に戻り、URLからサーバー情報を推測しないでください。

Addressにはサーバーのドメイン名またはIPアドレス、Portには指定されたポート番号を入力します。項目で完全なURLが明示的に求められていない限り、Addressにプロトコルの接頭辞、パス、ポート番号を含めないでください。ドメイン内のハイフンや数字はコピー時に間違いやすいため、注意して照合します。Portも一般的な慣例をもとに推測してはいけません。サーバー名やメモはローカルでの識別用に付けられます。通常は認証に使われないため、メモを変えてもAddress、パスワード、通信パラメーターの誤りは解消しません。

認証情報は選択したプロトコルに合わせる必要があります。プロトコルによってPasswordを使う場合もあれば、UUID、ユーザー名、キーなどの専用項目が必要な場合もあります。空白も入力値として扱われるため、特に文書の末尾からコピーしたときに改行が入っていないか確認してください。入力後は元の情報と各項目を照合してから保存し、テストします。情報が不足している場合は、必要な内容を確認してから続けてください。別のプロトコル用の項目を組み合わせて補わないでください。手動登録の目的は、既存情報を正確に再現することであり、接続するまで設定を手当たり次第に試すことではありません。

プロトコル項目と通信項目を分けて確認

プロトコルの認証情報と通信方式は、別々に確認する情報です。同じVLESSやVMessでも通信方式が異なる場合があります。Address、Port、UUIDがすべて同じでも、Path、Host、TLS関連の項目が不足すると接続できないことがあります。追加項目は、手元の情報で必要と確認できた場合にのみ入力してください。フォームに入力欄があるという理由で、値を推測して設定してはいけません。基本の認証情報、通信方式、証明書関連の設定の順に照合すると、変更を繰り返して混乱するのを防げます。

TLSのサーバー名は証明書の検証などに使われ、常にAddressと同じとは限りませんが、サーバーの設定に従う必要があります。証明書エラーが発生しても、まず検証を無効にして回避しないでください。ドメイン名、デバイスの時刻、証明書の有効性、手元の情報に記載された名前を確認しましょう。一見「接続できない」ように見えても、認証やハンドシェイクの段階で発生していることがあります。接続スイッチの状態だけでなく、正確なエラーメッセージを記録すると原因を特定しやすくなります。

あとから確認できる状態で保存する

保存前に「アドレスとポート、認証、通信方式、TLS、メモ」の順で確認することをおすすめします。保存後はHomeに戻ってこの項目を選び、選択状態を確認してからテストしてください。保存できたことと接続できることは別です。フォームの入力チェックでは一部の書式しか確認できず、リモートサーバーがリクエストを受け付けているかどうかまでは分かりません。取り込みと手動入力で結果が異なる場合は、詳細画面で項目ごとに比較し、特に初期値や共有リンクに含まれていない追加パラメーターを確認してください。

項目を試すときは、まず記録を複製するか元の値を保存し、1項目だけ変更して結果を記録します。複数の項目を同時に変えると、接続が回復しても原因を特定しにくくなります。購読で管理されているサーバーを長期的に修正する場合は、まずリモートの情報を更新する必要があるか確認してください。ローカルの変更は次回の更新時に上書きされることがあります。Hysteria2の通信方式についてはHysteria2のプロトコル解説をご覧ください。具体的な入力内容は、ユーザー自身が用意したサーバー情報に従ってください。

03 · Scan QR Codeとクリップボード：内容を確認してから保存

QRコードは入力方法を変えるだけ。内容の確認は必要

Scan QR Codeは、QRコードに含まれるテキストを読み取り、サーバー情報や購読情報として処理できるかアプリが判断する機能です。操作前に、QRコードがユーザー自身の手元にある情報に基づくものか確認し、1台分のサーバーか購読URLかを判断してください。見た目が似たQRコードでも中身は異なります。アカウントページ、通常のテキスト、サーバー共有リンクはいずれもQRコードにできます。「読み取り成功」は内容を読み込めたという意味であり、有効な設定を取得できたとは限りません。

Homeのスキャン機能からScan QR Codeを開き、システムの案内に従って必要なカメラへのアクセスを許可します。QRコード全体を読み取り枠に入れてください。アプリに詳細画面や取り込み確認が表示された場合は、Type、Address、Port、メモを確認してから進みます。すぐに何度も確定しないでください。QRコードが切れている、圧縮されている、反射で隠れている場合は読み取れないことがあります。まず画像を鮮明にし、カメラとの距離を調整してください。読み取りに失敗しても、サーバーが利用できないとは限りません。

QRコードが同じデバイスに保存されている場合は、アプリに写真ライブラリから読み込む機能が表示されているときに利用できます。その機能がない場合は、繰り返し探す必要はありません。手元の情報にある元の共有テキストをクリップボードから取り込む方法がより簡単です。認証情報を含む画像を公開認識サービスにアップロードしたり、読み取りのためにQRコード全体を公開ページに表示したりしないでください。QRコード内の情報は、多くの場合、平文の認証情報と同じアクセス権を持ちます。

クリップボードへのコピーではテキスト全体を保つ

コピーするのは、完全な共有リンク1件または明確な購読URL1件だけにします。タイトル、番号、引用符、説明文を一緒にコピーしないでください。Shadowrocketに戻り、画面に表示されるクリップボードからの取り込みまたは追加機能を使います。システムから貼り付けの許可を求められた場合は、今コピーした情報を読み取る操作であることを確認してください。取り込みの案内が表示されない場合は、追加手順に該当する機能があるか確認します。エンコードされた文字列全体をAddress欄に貼り付けないでください。

長いリンクは表示上、自動的に折り返されることがありますが、見た目の改行が実際の改行とは限りません。よくある原因は、コピー時の途中切れや空白の挿入、リンクの表示タイトルだけをコピーして実際のURLを取得できていないことです。取り込みに失敗したら、元の情報からもう一度コピーしてください。意味が分からないエンコード部分を手作業で削除しないでください。文書からコピーする場合は通常のテキストとして選択し、スマート句読点によって英語の引用符、プラス記号、スラッシュなどが別の文字に置き換わらないようにします。

一度に複数の内容を取り込む場合は、現在の形式をアプリがどう処理するか先に確認してください。複数行の共有テキストと、購読から返されるエンコード済みのサーバー集合は別のものです。「サーバーが複数ある」というだけで同じ方法を使わないでください。まず照合できる項目を1件取り込み、内容が正しいことを確認してから残りを処理します。完了後は新しい項目の所属先をすぐに確認し、既存の同名項目に紛れて、次回の選択時に古い設定を誤って使わないようにしてください。

読み取り、解析、接続を分けて確認する

この手順は3段階に分けて確認できます。1つ目はテキスト全体を読み取れたか、2つ目は正しい項目として解析されたか、3つ目は想定した接続を確立できるかです。QRコードを読み取っても反応がない場合は主に1段階目、「未対応の内容」と表示される場合は主に2段階目、項目が表示されているのにリクエストが失敗する場合は3段階目です。段階を分けて調べると、PortやTLSの項目を確認せずに何度も読み取りをやり直す事態を防げます。

解析に成功したら、新しい項目の詳細を開き、手元の情報と照合します。名前が文字化けしている場合は、メモの文字コードが原因のこともあれば、リンクが二重にエンコードされている可能性もあります。名前だけで判断せず、認証情報や通信項目も確認してください。QRコードからの取り込みとクリップボードからの取り込みで同じ項目になり、どちらでも接続できない場合は、入力方法を変え続けるのではなく、元のパラメーター、サーバーの状態、ローカルネットワークを確認します。項目は1件残せば十分です。重複して取り込んでも接続しやすくなるわけではありません。

操作後は、クリップボードの機密情報を通常のテキストで上書きし、デバイスのプライバシー設定に従ってクリップボードへのアクセスを管理できます。取り込み中に画面を共有したりスクリーンショットを送信したりした場合は、QRコード全体や認証パラメーターが写っていないか確認してください。誤って取り込んだ項目を削除する場合は、現在使用中の項目でないことを確かめてから、本ページの削除とバックアップをご覧ください。初回接続ではGlobal Routingの選択とシステム許可も必要です。手順ははじめにで順番に説明しています。

04 · 共有リンクの形式：サーバー、購読、Configを区別する

プロトコルの接頭辞によって、後続のテキストの解釈方法が決まる

サーバー1台分の共有リンクには、通常、ss://、vmess://、vless://、trojan://などのプロトコル接頭辞が付いています。これらは通常のウェブURLではなく、後続のサーバー情報をアプリがどう解釈するかを示します。プロトコルごとにエンコード方式やパラメーターの形式が異なります。複数の項目をエンコードして格納する形式もあれば、認証情報、アドレス、クエリパラメーターを分けて表現する形式もあります。接頭辞を置き換えて、別のプロトコルのリンクに変換しないでください。

HTTPS形式のアドレスも、見た目だけでは用途を判断できません。購読URLや設定ファイルのURLの場合もあれば、単なるウェブページの場合もあります。取り込む前に、手元の情報から対象を確認してください。サーバー共有情報はサーバーの取り込み手順へ、購読URLはSubscribeへ、ルール設定はConfigへ進みます。Configのテキストをサーバー一覧として解析したり、サーバー購読を設定ファイルとして読み込んだりすると、ネットワーク接続ではなく、内容の解析段階でエラーになります。

共有リンクでは、#以降がメモ、?以降が追加パラメーターとして使われることがありますが、意味は形式の仕様に従います。メモを変えても認証エラーは通常解消しませんが、クエリパラメーターは通信方式、Path、TLSの動作に影響する場合があります。リンクを短くするために後半を削除したり、エンコード文字を読みやすそうな文字に置き換えたりしないでください。パーセントエンコード、Base64、通常のテキストが混在する場合、誤って二重にデコードすると実際の項目値が変わることがあります。

.confの役割と範囲を理解する

Shadowrocketの.confには、ルールやその他の設定を含めることができます。以下は[Rule]の一部を示したもので、ドメインは構文の説明用です。利用可能なサーバー情報ではなく、単独で接続を完了できる設定でもありません。ここで示しているのはリクエストの処理方法であり、サーバー認証情報の取得元ではありません。既存の設定を利用する場合は、まず元のファイルを保管し、ルールとその他の設定の関係を確認してください。3行だけをコピーして、使用中の設定全体を置き換えないでください。

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

DOMAIN-SUFFIXはドメインのサフィックスで照合し、GEOIPは接続先IPの地理的な分類で照合し、FINALは最終的な処理方法を指定します。ルールは通常、上から順番に確認されるため、個別条件と最終条件の位置が結果に影響します。PROXYとDIRECTはルール内の処理キーワードなので、日本語に置き換えないでください。ここにあるexample.comは照合対象の例にすぎず、サーバー項目に入力する値ではありません。

Global RoutingのConfig、Proxy、Directは、リクエスト全体をどのように処理するかを決めます。Configでは現在の設定ルールを確認します。Proxyでは、ウェブページにアクセスできたことだけで、特定ドメインのルールが正しいとは判断できません。Directでも、プロキシサーバーが利用可能だとは確認できません。購読の管理とルール設定は分けて確認します。まず現在のサーバー項目、次にルーティング方式、最後にリクエストが想定どおり処理されたかを確認してください。

共有前に対象範囲と機密情報を確認する

サーバー1件のエクスポートと設定全体のエクスポートでは、含まれる情報の範囲が異なります。1件のサーバー情報には認証情報が含まれる場合があり、設定ファイルにはカスタムルール、DNS設定、リモートURL、その他の個人設定が含まれることがあります。送信前に、相手が必要としている情報を確認してください。項目名の確認には値を隠したスクリーンショット、ルールの説明には必要最小限の抜粋を使えばよく、アカウントに関わる情報全体を送る必要はありません。メモが一般的な内容に見えても、リンク本文が直接アクセスに使える場合があります。

複数デバイス間で整理する場合、アプリの共有機能を使ったら、受信側で取り込み結果を確認してください。リンクを生成しただけでは移行は完了しません。追加設定がローカルConfigや購読との関係に依存する場合があり、1件の共有情報だけでは背景となる情報をすべて引き継げないことがあります。購読の項目から単独のサーバー情報を共有した場合、元の購読による更新が引き継がれるかどうかは、取り込み後のグループと入口を確認してください。「パラメーターが同じ」ことと「管理関係が同じ」ことを混同しないようにしましょう。

形式を認識できない場合は、元のテキストを保管し、アプリがその形式に対応しているか確認してください。公開変換サービスに貼り付けないでください。手元の情報から、現在の取り込み方法に適した形式を取得できます。また、必要な項目がすべて分かっている場合はAdd Serverから手動登録できます。プロトコルの拡張パラメーターは、現在のアプリ画面と元のサーバー情報に従ってください。このマニュアルでは、エンコードされたテキストを変更して認証項目を推測したり、不足情報から認証情報を復元したりする方法は案内していません。

05 · 更新方法：取得成功と内容の変化を区別する

内容を確認しながら手動で更新する

購読の更新では、入口に再度リクエストを送り、返されたサーバー情報を対応する集合に反映します。すべてのサーバーを個別に修復したり、無効になった認証を復旧したりする機能ではありません。実行前に、現在使っている購読グループと選択中のサーバーを記録し、必要に応じて使用中のConfigも控えておきます。これにより、一覧の順番や名前が変わったり項目が削除されたりしても、更新による変化を確認できます。表示が変わっただけで、クライアント全体の設定が失われたと誤解せずに済みます。

Homeで対象の購読を見つけ、現在の画面にある更新操作を使います。画面によって、グループメニュー、編集画面、購読管理欄などに操作が配置されている場合があります。サーバーを1件ずつ編集するのではなく、Subscribeの項目を対象にしてください。リクエストが完了するまで待ち、結果の表示と一覧の変化を確認します。処理中に何度もタップしないでください。複数の購読がある場合は、まず内容が分かっている1つを更新し、結果を確認してからほかの購読を更新すると、問題のある入口を特定しやすくなります。

更新が成功しても項目が変わらない場合は、リモートの内容がローカルと同じだっただけかもしれません。項目数が増えても、接続品質が改善したとは限りません。「リクエスト完了」「内容を解析できた」「変化が想定どおり」「現在の選択が有効」の4点を分けて確認してください。更新後は普段使う項目の詳細を開き、プロトコルや主要パラメーターが変わっていないか確認してからテストします。選択中の項目が削除された場合は、新しい一覧から選び直してください。接続スイッチがオンのままでも、以前の選択が有効とは限りません。

自動更新とリクエスト経路

自動で管理したい場合は、Settingsで購読関連の自動更新項目を確認し、「アプリ起動時に更新」など、現在の画面に表示される説明に従って設定します。自動更新を有効にする前に、手動更新で入口が有効なことを確認してください。自動更新で変わるのは実行タイミングであり、バックグラウンドで毎回ネットワークリクエストが完了する保証はありません。デバイスのネットワーク、アプリの実行状態、システムのスケジュールが結果に影響します。重要な変更後は、スイッチの状態だけに頼らず購読一覧を確認してください。

更新リクエスト自体にもネットワーク経路が必要です。特定の接続条件でしか入口にアクセスできない場合は、既存の設定から実際の経路を確認してください。すぐにGlobal Routing全体を別の方式へ切り替えないでください。特に、以前のサーバーがすでに利用できない場合、更新リクエストがその接続に依存していると、新しい一覧を取得できない状態が続くことがあります。調査時は切り替え前後のルーティング方式とネットワーク環境を記録し、毎回1つの条件だけ変更してください。更新のために普段使うルールを恒久的に崩さないようにしましょう。

失敗時の状態を残し、登録し直す操作を繰り返さない

更新エラーが発生したら、元の購読と以前の項目を残し、エラーメッセージとそのときのネットワーク環境を記録します。古い一覧が残っている場合は、すぐに削除する必要はありません。削除してもリモートの返却内容は変わらず、比較の基準として使える項目を失う可能性があります。認証パラメーターがすべて含まれているか、入口に変更があったかを確認してから、URLの置き換えが必要か判断してください。既存URLの置き換えと2つ目の購読の追加では管理結果が異なります。元の集合を修正するのか、独立した集合を作るのか明確にしてから操作しましょう。

更新後に多くの項目が変化した場合は、別の購読URLを使っていないか、用途の異なるURLをコピーしていないか確認してください。メモが同じでもURLが異なることがあるため、名前だけで判断しないでください。リモート側でサーバー情報が変更された場合、以前の項目を引き続き利用できるかは実際のサーバー状態によります。古い項目を残すのは比較のためであり、現在も有効だという意味ではありません。新しい情報と照合し、無効な古い項目を継続管理する集合に戻さないようにしてください。

日常の管理では、必要なときに手動で確認し、自動更新は補助として使い、問題が起きたら失敗時の情報を一通り記録する方法がおすすめです。短時間に何度もリクエストしても形式の問題は解消せず、エラー情報が混在する原因にもなります。操作手順と原因別の確認方法は購読の手動更新と自動更新の解説をご覧ください。解析には成功するが速度が遅い場合は、テストと並べ替えへ進み、購読形式の問題として扱わないようにしてください。

06 · 複数購読の整理：所属先とルールを分かりやすく保つ

名前には用途を記し、識別子として扱わない

複数の購読を利用している場合は、各入口の管理上の役割を明確にしてから、その中のサーバーを整理します。購読のメモには「個人用」「一時テスト」のように用途、デバイス、管理対象を記載できますが、認証パラメーター全体は含めないでください。サーバー名はリモート側で設定され、更新時に変わることがあるため、変更されない識別子として扱わないようにします。確認すべきなのは、所属する購読、プロトコル、アドレス、接続に必要なパラメーターの対応関係です。

整理の前に、現在の購読URL、手動で追加した項目、スキャンやクリップボードから取り込んだ項目を一覧にします。同じ名前のサーバーが重複しているとは限らず、名前が異なっていても同じアドレスを指す場合があります。名前だけを見てまとめて削除しないでください。詳細を開いてAddress、Port、Type、通信パラメーターを比較し、本当に不要か判断します。認証情報が異なる項目は、手元の情報から使わないことが確認できない限り、それぞれ残してください。

同じ購読を複数回取り込んでも、通常は管理対象が重複するだけで、より完全な集合になるわけではありません。残す項目は、現在の選択状態、メモ、Configからの参照関係を見て決めます。一覧の上にあるものを機械的に残さないでください。削除する前に、残す予定の集合で該当項目を選び、動作を確認してから重複分を処理します。こうすることで、同じ名前の項目が複数ある場合でも、使用中の唯一の有効な項目を誤って削除しにくくなります。整理と更新は分けて行い、変更の原因を確認できるようにしてください。

購読のグループとルーティング方法は別のもの

Homeの購読グループは「どの入口でサーバーを管理するか」を整理します。Configのルールは「リクエストをどのように処理するか」を決めます。サーバーを別々の購読に分けても、ウェブサイトごとに自動で使い分けられるわけではありません。Configでポリシーグループや特定の名前を参照している場合は、実際にどのようにサーバーを選ぶかも確認してください。一覧の表示順を変えても、ルールの照合条件は変わりません。

この関係を確認するときは、まずGlobal Routingを確認します。Configを選択している場合は、有効なConfigを確認してから関連ルールとポリシーを調べます。Proxyではプロキシ経由の処理がテスト対象です。Directでは直接接続の結果が表示されます。購読を整理する間に、記録を残さずルーティング方式を切り替えないでください。同じサーバーのテスト結果が異なるリクエスト経路によるものか分からなくなり、整理の判断を比較できなくなります。

少しずつ整理して、長期的に分かりやすく保つ

「所属先を確認、重複を照合、メモを統一、選択状態を検証、不要な項目を整理」の順に、1つの購読ずつ作業することをおすすめします。1つのグループが終わったらHomeに戻って一覧を確認し、次のグループを整理してください。アプリに絞り込み、折りたたみ、並べ替え機能がある場合は、まず表示を整理して作業しやすくします。急いでデータを削除する必要はありません。非表示や折りたたみは見える範囲を変えるだけですが、削除は保持する内容を変える操作です。まとめて操作する前に、現在のグループだけが対象か、全項目が対象かを確認してください。

長期的に残す手動登録の項目には、Subscribeの更新に依存しないことが分かる命名ルールを使います。古くなりやすいテスト用の数字ではなく、用途をメモに記載してください。2件のパラメーターを一時的に比較する場合は、ローカルのメモに「元の設定」「テスト用」のように関係を記し、検証後は整理します。購読から取り込んだ項目を記録なしで長期的に変更すると、次回更新で上書きされたり、あとで調査する人がリモートの元情報だと誤解したりする可能性があります。

整理が終わったら、選択中の項目とConfigの参照先を改めて確認します。Configが項目名を使っている場合、名前の変更や項目の削除が次の選択に影響することがあります。一覧が整っただけで完了と判断しないでください。更新で名前が変わる集合では、固定の表示名だけに頼らないことも重要です。ルールと方式の詳しい説明はプロキシモードをご覧ください。一覧の管理に問題がなく、特定のウェブサイトの処理方法だけが想定と異なる場合は、購読グループではなくルールを確認します。

07 · Connectivity Test：テスト、並べ替え、実際のリクエスト

最初にテスト対象を確認する

Connectivity Testの結果は、選択したテスト方法に沿って解釈する必要があります。方法によって、サーバーのアドレスとポートへの到達性を確認する場合もあれば、プロキシ経由で指定したリクエストを行う場合もあります。確認できる範囲は同じではありません。基本的なネットワークテストに成功しても、プロトコル認証、TLSハンドシェイク、対象ウェブサイトへのアクセスまで成功したとは限りません。テスト前に現在の画面で方法と関連設定を確認し、表示結果を正しく解釈してください。どの数値も接続品質全体を示すものだと考えないでください。

テスト条件はできるだけそろえます。同じデバイス、同じネットワーク、同じテスト方法を使い、購読の更新や大量の通信を同時に行わないようにします。Wi-Fiとモバイル通信で別々の項目を測ると、結果にはローカルネットワークの違いが含まれます。一括テストは同時実行の影響も受けるため、一覧上のわずかな差に実用的な意味があるとは限りません。まず明らかに失敗している項目や、継続して異常な結果になる項目を探し、候補を絞って再確認してください。

タイムアウトが表示された場合は、どのテストで発生したか確認します。サーバーポートに到達できない、プロトコル認証に失敗する、テスト対象にアクセスできないなど、異なる原因が同じように失敗して見えることがあります。テスト方法を確認せずに、タイムアウトした項目をすべて削除しないでください。パラメーターを照合した項目を1件選び、基本的な接続テストと実際のリクエストをそれぞれ確認して、エラーメッセージを比較します。テスト対象を次々に変えるよりも、どの段階で失敗したかを判断しやすくなります。

並べ替えは確認に使う機能であり、将来の性能を保証するものではない

テスト結果で並べ替えると候補を絞りやすくなりますが、表示される順番は現在の条件での一度の測定結果です。ネットワーク負荷、接続先のサイト、接続の再利用、テストのタイミングによって結果は変わります。先頭の項目がすべてのリクエストで最適とは限りません。一度測定した低い遅延値を固定メモにしたり、安定した通信速度の証拠とみなしたりしないでください。長期的に使う場合は、複数回の結果が安定しているか、実際のアプリ内のリクエストが想定どおりかを確認することが重要です。

並べ替えた後も、選択中のサーバーを手動で確認してください。表示順を変えても選択項目が変わるとは限りません。まとめてテストを実行しても、クライアントが最良の結果を自動選択するわけではありません。使用中のConfigにポリシーグループや別の選択ロジックがある場合は、その動作も確認してください。操作後はHomeに戻って選択中の項目を確認し、実際のリクエストを1回送信します。表示順だけでサーバーが切り替わったと判断しないでください。

実際のリクエストで確認を完了する

テストが成功したら、実際に必要なリクエストを1つ選んで確認し、Global Routingと現在のConfigも確認してください。通常のブラウジングはできるのに特定のアプリで問題がある場合は、サーバー項目をすぐに一括変更せず、対象ドメイン、DNS、ルールの照合、アプリ固有の接続動作を確認します。既存の接続が以前の経路を使い続けている場合があります。サーバーを切り替えた後は新しいリクエストで変化を確認し、以前の接続結果を新しい選択の結果と取り違えないようにしてください。

実際のアクセスが遅い場合は、サーバー、通信経路、ローカルネットワーク、接続先サービスを段階ごとに比較します。まず同じネットワーク上で別の既存項目を試し、条件が許せばWi-Fiとモバイル通信を比較してください。その際、接続先を同じにして、毎回1つの条件だけ変更します。ドメイン関連のリクエストだけが失敗する場合はDNSとルールを確認し、すべての接続が不安定ならローカルネットワークから確認します。段階別の詳しい方法は速度が遅いときの段階別トラブル対処をご覧ください。

相談時にはプロトコル、テスト方法、失敗した段階、現在のGlobal Routing、ネットワーク環境を記録し、Password、UUID、購読URL全体は含めないでください。DNSの問題はDNS設定の解説をご覧ください。1回のテスト結果に合わせるために、名前解決、ルール、サーバーを同時に変更しないでください。テストで確認する内容を1つに絞ると、次の調整の根拠になります。結果が一致しない場合は、制御できる条件で少数回繰り返す方が、一括テストを何度も実行するより有効です。

08 · 削除とバックアップ：復元を確認してから整理

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

手動登録したサーバー1件の削除、購読入口の削除、Configの削除は、それぞれ異なる操作です。サーバー1件を削除すると通常はその項目に影響します。購読を削除すると、管理対象の集合も削除される場合があります。Configを削除すると、ルールや関連設定に影響します。操作前に確認画面を読み、対象範囲を把握してください。近くに表示されているからといって、同じ方法で復元できるとは限りません。また、「編集画面を閉じる」ことが削除の取り消しになるとも限りません。

使用中の項目を削除する前に、すでに検証済みの別の項目を選び、現在のConfigで想定どおり動作することを確認してください。ポリシーからの参照や固定名との関連付けがある場合は、それらを変更する必要がないかも確認します。購読内の項目をローカルで削除しても、リモートの内容に残っている場合は次回更新で再表示されることがあります。表示を整理したいだけなら、削除を恒久的な除外方法として使わず、アプリに表示整理の機能がないか確認してください。

重複する購読を整理するときは、まず入口と所属先を比較し、残す必要があるローカル情報をバックアップします。グループ名が同じでも内容が完全に一致するとは限らず、似たURLでも認証パラメーターが異なる場合があります。使わなくなった古い入口を削除する前に、新しい入口で更新と実際の接続テストが完了したことを確認してください。削除対象と代替先を簡単に記録しておくと、デバイスの変更や復元時に迷いにくくなります。

バックアップは情報の種類ごとに保存する

バックアップでは、購読URLとメモ、独立したサーバー情報、使用中のConfig、必要なローカル設定の4種類を確認します。アプリの購入履歴は、これらの情報の代わりにはなりません。App StoreからShadowrocketを再取得しても、個人設定がすべて復元されるわけではありません。エクスポートできる範囲は、現在のアプリに用意されているバックアップ機能によって異なります。実際に何が含まれるか確認し、ファイル名だけを見て全データが保存されたと判断しないでください。

現在の画面にDataなどのバックアップ機能がある場合は、画面の案内に従ってエクスポートし、必要な項目が含まれているか確認します。個別に保存する必要がある場合は、元の購読情報、独立したConfigファイル、手動入力した項目と選択関係をそれぞれ保管してください。機密情報を公開ノートや誰でも共有できるフォルダーに保存しないでください。バックアップファイルもアクセス情報として扱い、適切な保護ができるユーザー自身の管理下に保存します。

バックアップには、現在使用中のConfig、Global Routingの選択、よく使う項目の所属先、購読の自動更新やOn Demandが有効かどうかなど、利用状況も記録してください。これらは個別の共有リンクに含まれない場合があります。On Demandは条件に応じて接続を確立する動作に関係するため、移行後に条件とシステム許可を改めて確認してください。サーバーとルールの検証が済む前にOn Demandだけに頼らないでください。バックアップでは、取り込み可能なテキストだけでなく、管理上の関係が分かる情報も保存します。

復元手順とバックアップの有効性

復元時は、まずShadowrocketがApp Storeから正しく取得されていることを確認します。購入済みアプリの復元と再インストールについては購入済みアプリの復元をご覧ください。次に「購読と独立した項目を取り込む、Configを復元する、ローカル設定を確認する、現在の項目を選ぶ、実際のリクエストを検証する」の順に進めます。購読を使う場合は、最初にバックアップの内容を確認し、更新するタイミングを決めてください。すぐに更新すると一覧が変わり、以前のデバイスとの項目比較が難しくなることがあります。

バックアップファイルを保存できても、すべてを完全に復元できるとは限りません。適切なタイミングで制御された確認を行い、アプリがファイルを読み込めるか、必要な項目がそろっているか、Configが存在するか、機密情報が欠けていないかを確認します。自分の別のデバイスで試す場合は、そのデバイスにある設定を上書きしないようにしてください。まず元の状態を保管してから復元します。完了後は項目数が同じかだけで判断せず、主要項目と実際のリクエストを確認してください。

購読URLや認証情報が後から変更された場合、以前のバックアップには古い値が残っていることがあります。重要な変更が完了し、利用できることを確認してからバックアップを更新し、現在のコピーと過去のコピーを区別して保管してください。過去の情報を残しても、古いサーバーが引き続き利用できるとは限りません。購読URLや認証情報全体が漏えいした場合、ローカルの項目を削除するだけでは、すでに漏れたアクセス情報を無効化できません。既存アカウントの管理方法に従って該当する認証情報を処理し、クライアントとバックアップを更新してください。

接続手順を最初から確認する場合ははじめにへ、具体的なエラーから調べる場合はよくある質問をご覧ください。日常の管理で設定全体を頻繁に作り直す必要はありません。入口、項目、操作履歴を分かりやすく保つと、次に問題が発生したときも原因の段階を判断しやすくなります。