Shadowrocket ノード管理

01Subscribe：既存のサブスクリプションを追加

サブスクリプションURLとルール設定を区別する

Subscribeは、すでにお持ちのサブスクリプションURLからサーバー情報を取得する機能です。1つのサブスクリプションに複数のサーバー項目が含まれる場合があり、追加後は通常、取得元ごとにグループ化されます。以後の更新にも元のURLが必要です。単一のサーバーとは役割が異なります。サーバー項目には接続に必要なアドレス、ポート、認証情報が保存され、サブスクリプションにはそれらを取得するためのURLが保存されます。手元の情報がどちらなのか確認してから追加方法を選び、説明ページのURLをサブスクリプションURLとして登録しないようにしましょう。

Configで管理する設定ファイルには、主にルールや関連設定が含まれます。URLを使う点が同じでも、サーバーのサブスクリプションと同じものではありません。サーバーやリモートリソースを含む設定ファイルもあるため、実際の内容に基づいて用途を判断してください。サーバーのサブスクリプションを追加する場合は、TypeがSubscribeの追加方法を選びます。ルール設定ファイルの場合はConfigで用途を確認し、手当たり次第に追加方法を変えて試すことは避けてください。

項目を入力して追加する

Homeで追加メニューを開き、Add Serverに進みます。TypeをSubscribeに設定し、お持ちのサブスクリプションURLを入力して、取得元を判別しやすい名前を付けます。画面の構成はデバイスやアプリの状態によって異なる場合があります。追加メニューはTypeと項目名を目印に探してください。URLをコピーするときは、内容を最後まで選択できているか確認しましょう。特にクエリパラメーターがチャット画面の折り返しや末尾の句読点、選択範囲によって欠けていないか注意してください。画面上で2行に表示されても、URLに改行が含まれるとは限りません。

保存後、サブスクリプションのグループが表示されるか、グループ内にサーバー項目があるかを確認します。追加時にはサブスクリプションURLへアクセスし、返された内容を解析するため、「URLを保存できた」ことと「サーバーを追加できた」ことは別の結果です。グループはあるのに中身が空の場合は、更新時の通知や取得内容を確認してください。すぐにサーバーへ接続できないと判断せず、項目が取得できた後に認証情報と接続状況を確認しましょう。

1. アカウントページや説明ページではなく、ご自身のサブスクリプションURLをコピーしたことを確認します。
2. Subscribeを選び、URLと判別しやすい名前を入力して保存します。
3. グループとサーバー項目が作成されたか確認し、そのうち1台の設定を照合します。
4. サーバーを選択し、使い方ガイドに沿ってモードを選び、実際に接続できるか確認します。

インポート時の問題は取得・解析・接続に分けて確認する

サブスクリプションを取得できない場合は、まず現在のネットワークからURLにアクセスできるか、URLが有効かを確認します。ログイン画面、認証画面、エラーメッセージが返ってきても、URLを保存しただけでサーバーリストに変わるわけではありません。関係のない項目にアカウントのパスワードを入力したり、テストのためにサブスクリプションを見知らぬWebサイトへ渡したりしないでください。サブスクリプションURLにはアクセス情報が含まれることが多いため、機密情報として管理しましょう。問題を相談する際はエラーの種類だけを伝え、URL全体を公開しないでください。

取得できても利用可能な項目がない場合は、内容の形式と完全性を確認します。拡張子だけで判断せず、元の案内を見て、Shadowrocketが対応するサブスクリプション内容かを確認してください。一部の項目だけが欠けている場合は、グループ全体を削除せず、該当項目のプロトコルと設定項目を比較します。必要に応じて現在利用できる内容を残し、手動更新を1回行って、更新前後の違いを記録しましょう。続けて操作すると、最初の問題が分かりにくくなります。

インポート後はHomeに戻り、現在選択されているサーバーが追加したグループのものか確認します。サブスクリプションを表示しただけで、その中の項目が現在の接続先になるとは限りません。初めて使う場合は、まず動作が分かっている項目を1つだけテストし、アドレス、モード、認証手順が正しいことを確認してから、グループ全体を整理しましょう。これにより、インポート失敗、選択ミス、接続失敗を切り分けやすくなります。

02Add Server：サーバー設定を手入力

プロトコルに応じて必要な項目を入力する

Add Serverは、サーバー1台分の設定情報をすでにお持ちの場合や、自動インポート後の各項目を確認したい場合に使います。まずTypeを選び、その種類で表示される項目を入力してください。あるプロトコルの項目をすべて入力してから、Typeの名前だけ変更するのは避けましょう。プロトコルによって認証方式や通信設定は異なり、種類を切り替えると項目が追加されたり、入力値の再確認が必要になったりすることがあります。入力前に元の情報を控え、照合できるようにしてください。

Addressには通常、サーバーのドメイン名またはIPアドレスを入力し、Portにはサーバーが実際に待ち受けているポートを指定します。ドメイン名にWebページのパスを付けたり、TLSを使うからといって一般的なポート番号を決めつけたりしないでください。サーバーアドレス、TLSのServer Name、トランスポート層のHostは、同じ場合もあれば用途が異なる場合もあります。元の情報にそれぞれ記載がある場合は個別に入力し、「同じ値にする」ために3つを同一の名前へ変更しないでください。

認証、TLS、トランスポートはそれぞれ別の層

Shadowsocksでは、サーバー側の暗号化方式とパスワードを一致させる必要があります。VMessやVLESSでは通常、UUIDと設定で指定された追加項目を確認します。TrojanではパスワードとTLS関連の情報が必要です。これらは互いに置き換えられません。画面上で保存できても、項目の基本的な入力チェックを通過しただけで、サーバーが認証を受け付けるとは限りません。接続直後に切断される場合は、暗号化方式やトランスポート設定を手当たり次第に変えるのではなく、元の設定情報と照合してください。

TLSの役割はプロキシプロトコルの認証とは異なります。Server Nameは通常、証明書名の検証やサーバー名表示に使われるため、メモとして入力する項目ではありません。証明書エラーが出た場合は、名前、デバイスの時刻、元の設定が一致しているかを確認してから、サーバー証明書の状態を確認してください。証明書の検証を無効にすると接続時の信頼性が変わるため、一般的なトラブル対処として行うべきではありません。元の情報で指定されていない項目は、アプリの初期設定のままにするか、意味を確認してから変更しましょう。

WebSocketなどのトランスポートを使用する場合、HostとPathもトランスポート設定の一部です。Pathのスラッシュ、大文字と小文字、クエリ部分はサーバー側のルーティングに影響することがあるため、メモのように書き換えてはいけません。元の情報にTLS、トランスポート方式、パスが記載されている場合は、項目ごとに対応させてください。Hysteria2やWireGuardなどにも固有のキーや接続設定があるため、別のプロトコルの手順を当てはめないでください。選択したTypeで必要とされ、元の情報に明記されている値だけを入力します。

保存後に設定を確認し、項目ごとにテストする

手入力した項目には、「手入力テスト」など用途を判別しやすい名前を付けましょう。名前にパスワードや完全なキーを含めないでください。保存後に編集画面を開き、Type、アドレス、ポートに誤りがないか、特にコピーした値の前後に空白がないかを確認します。修正する場合は一度に1種類の項目だけを変更し、理由を記録してください。ポート、TLS、トランスポート方式を同時に変えると、接続できても何が解決につながったのか分かりにくくなります。

自動インポートしたサーバーも編集画面で設定を確認できますが、サブスクリプション内の変更は次回更新で上書きされることがあります。ローカルで長期間調整する必要がある場合は、独立した項目として複製できるかを確認し、元の項目とテスト用の複製を名前で区別してください。動作を確認する前に、唯一利用できるサーバーを直接変更しないでください。すでにある情報を追加する別の方法については、サーバー情報を追加する4つの方法をご覧ください。

03QRコードとクリップボードからインポート

QRコードは情報を運ぶ手段であり、別の設定方式ではない

Scan QR CodeはQRコードに記録されたテキストを読み取ります。サーバーの共有リンクやサブスクリプションURLの場合もあれば、通常のWebページの場合もあります。読み取り後は認識された内容と追加対象を確認してください。QRコードを読み取れたからといって、サーバー設定が正しいとは限りません。QRコードに含まれるプロトコル、アドレス、認証情報は、Add Serverに手入力して保存する内容と対応しています。2つの方法の主な違いは入力方法であり、接続の仕組みではありません。

スキャンする前に、QRコードがご自身のサーバー情報またはサブスクリプション資料のものか確認してください。認証情報を含む画面を公共のディスプレイに映すことも避けましょう。カメラで読み取る際は、システムの案内に従って必要なアクセス権を許可します。許可されていない場合は、スキャンを何度も押すのではなく、システム設定を確認してください。アプリに写真から読み取る方法がある場合は、保存したQRコード画像を選べます。コード全体と鮮明さを保ち、位置合わせ用の図形を切り取ったり、過度に圧縮した縮小画像を使ったりしないでください。

QRコードを読み取れない場合は、まず読み取り環境を整えます。コード全体が表示されているか、明るさが適切か、反射やぼけがないかを確認し、距離を調整して再度試してください。同じQRコードを読み取れず元のテキストが残っている場合は、テキストからインポートするか、設定を手入力しましょう。スクリーンショットを何度も撮ると情報がさらに欠けることがあります。1枚の画像に複数のQRコードがある場合は、1つずつ読み取ります。追加後は名前と取得元を確認し、重複追加を更新済みと誤認しないようにしてください。

クリップボードから追加する前にコピー範囲を確認する

クリップボードからのインポートは、サーバーの共有テキスト全体をすでにお持ちの場合に便利です。必要なリンクだけをコピーし、Shadowrocketに戻って現在の画面にあるクリップボードからのインポート方法を使います。システムから貼り付けの許可を求められた場合は、操作内容を確認して許可してください。通常の説明文、チャット内の引用符、リンク末尾の句点はプロトコル情報ではなく、混ざると読み取りに影響することがあります。チャット全体をコピーせず、アプリが付随する説明をすべて自動判別すると期待しないでください。

複数のリンクを含むテキストは、できるだけ1行に1つずつ記載し、元の文字列を保ってください。画面上の折り返しと実際の改行は異なります。長いリンクが画面上で自動的に折り返されるだけなら通常問題ありませんが、手動で改行すると1つの内容が分割されることがあります。最初の項目しか追加できない場合は、残りの項目も同じ対応形式か、項目間に余分な区切り文字がないか確認します。失敗した場合は、まず項目を1つだけでテストし、手順を確認してからまとめて処理してください。

インポート後の設定確認を省略しない

QRコードとクリップボードのどちらから追加した場合も、項目の編集画面を開き、Type、Address、Port、必要な認証項目を照合してください。名前はメモにすぎず、内容が正しい証拠にはなりません。同じ名前でもアドレスが異なる場合があり、名前が異なっていても同じアドレスを指すことがあります。読み取り結果がサブスクリプションの場合は、更新可能な取得元グループとして作成されたかを確認します。サーバー一覧を一度取得しただけでは、サブスクリプションとは限りません。継続して更新する情報には、正しいサブスクリプションの登録が必要です。

インポート後は、クリップボードの内容を機密情報を含まない通常のテキストに置き換えると、誤って貼り付けるリスクを減らせます。ただし、別のデバイスや履歴に複製が残っていないことまでは保証できません。複数デバイス間でクリップボードを同期する場合は、同期範囲にも注意してください。写真に保存したQRコードも適切に管理し、公開共有アルバムに入れないようにしましょう。スクリーンショットを削除すれば今後の拡散は抑えられますが、すでに漏えいした認証情報は元の管理方法に従って対処する必要があります。

今回の作業が自身の別デバイスへの情報移行だけであれば、まず移行先で設定を確認し、接続できることを検証してから、途中で使ったテキストや画像を整理してください。新しいデバイスで利用できると確認する前に、古いデバイスにある唯一の記録を削除しないでください。移行にはConfig、現在の選択項目、オンデマンド接続の設定も含まれます。「QRコードのインポートに成功」と表示されただけでは、すべての移行が完了したとは判断できません。確認手順は削除とバックアップをご覧ください。

04共有リンクの形式と設定の違い

先頭部分から内容を見分け、次の手順を判断する

サーバーの共有リンクには、プロトコルに応じた接頭辞が使われることが多く、サブスクリプションURLにはHTTPSがよく使われます。接頭辞は内容の種類を判断する手がかりになりますが、リンク全体が有効であることを保証するものではありません。正しい接頭辞のリンクでも、認証情報、ポート、必要なトランスポート設定が欠けている場合があります。一方、HTTPSのURLが必ずサブスクリプションとは限らず、アカウントページや通常のファイルを指していることもあります。追加前に、手元の資料を確認し、サーバー、サーバー一覧、設定ファイルのどれに当たるのか判断してください。

これらの接頭辞は一般的な内容を見分けるためのもので、対応形式を網羅した一覧ではありません。同じプロトコルでも共有形式には複数の仕様があり、異なる方法でエンコードされることがあります。インポートできるかどうかは、内容全体とアプリが対応する設定の組み合わせによって決まり、プロトコル名だけでは判断できません。見慣れない形式は元のテキストを保ち、手元の資料にある項目説明を確認してから、Add Serverで各項目を照合してください。むやみに書き換えると、元の情報と比較できなくなるおそれがあります。

エンコード、クエリパラメーター、メモはそれぞれ役割が異なる

共有リンクの認証情報は、エンコードされた状態で含まれていることがあります。エンコードは暗号化ではなく、公開してよいという意味でもありません。リンクを読める人は、サーバーの認証情報を復元できる可能性があります。読みにくい文字列が含まれていても、空白を加えたり、大文字と小文字を変えたり、末尾の記号を削除したりしないでください。形式によってはこれらの文字が重要で、テキスト編集アプリの自動置換によって内容が変わることもあります。照合する場合は、スクリーンショットを見ながら入力し直すのではなく、元のプレーンテキストを使いましょう。

疑問符以降のクエリパラメーターには、トランスポート方式、TLS、その他の接続動作を決める情報が含まれることがあります。シャープ記号以降は通常メモに使われますが、解釈は形式の仕様によって異なります。パーセントエンコードは特殊文字を表すためのもので、文字化けとして削除してはいけません。日本語の名前が正しく表示されない場合は、まず問題がメモの部分だけか確認してください。アドレスと認証情報が正しければ、表示名を直すためにリンク全体を編集せず、インポート後に表示名だけを変更できます。

サーバー情報を追加してもルール設定は自動で完了しない

サーバーの追加で設定するのは主に「どこへ接続し、どう認証するか」です。ルール設定では「リクエストごとにどのポリシーを使うか」を決めます。両者は連携しますが、互いに置き換えることはできません。Config内のルールは通常上から順に照合され、一致したルールのポリシーが適用されます。FINALは、それ以前のルールに一致しなかった場合に使われます。以下は構造を理解するためのルール構文例です。サーバーの認証情報は含まず、既存の設定をそのまま置き換えられる完全なConfigではありません。

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

例にあるPROXY、DIRECT、REJECTはポリシーを表すキーワードです。DOMAIN-SUFFIXとDOMAINでは一致する範囲が異なるため、名前の印象だけで入れ替えないでください。GEOIPはIPアドレスの地域判定に関係し、Webページの言語による振り分けとは異なります。ルールはConfig内の正しいセクションに記述し、現在のGlobal Routingの選択とあわせて確認してください。ProxyまたはDirectの状態で使う場合も、Config内の1つのルールだけであらゆるアクセス結果を説明できるとは限りません。

ルールを詳しく調整する場合は、照合順序、FINAL、ポリシーの解説をご覧ください。この章のメンテナンスでは、情報を種類ごとに分けて保管します。元の共有テキストはサーバー設定の照合に、サブスクリプションURLは更新に、Configファイルはルールと関連設定に使います。3種類の情報に別々の名前を付けると、すべてを「共通リンク」としてまとめるより問題を特定しやすく、移行時の見落としも防げます。

05サブスクリプションの更新と結果確認

更新されるのは時刻表示だけでなく、取得元の内容

サブスクリプションを更新すると、保存済みのURLへ再度アクセスし、返された内容に基づいて関連するサーバー項目が更新されます。アドレス、ポート、認証情報、名前が変わったり、項目が追加・削除されたりすることがあります。単に表示を更新する操作ではありません。更新前に、現在使っているグループとサーバーを確認し、必要であれば判別に必要な情報を記録しましょう。接続の問題を調べている場合は、「更新を押した」と記録するだけでなく、更新前後の違いを残すことが役立ちます。

手動更新は、情報に変更があったと分かったとき、既存の項目に問題が見つかったとき、インポート結果を確認したいときに適しています。自動更新は日常のメンテナンスに便利ですが、有効化の方法や間隔の選択肢は現在のSubscribe設定画面で確認してください。すべてのデバイスで決まった時刻にバックグラウンド更新されるとは限りません。システムのスケジュール、ネットワーク環境、アプリの状態が実行時刻に影響することがあります。最新の結果を確認する必要がある場合は、実際の更新結果を確認してください。

リクエスト、解析、置き換えの3段階で結果を確認する

リクエストに失敗した場合は、まずURLが完全か、アクセス情報が有効か、現在のネットワークから取得できるかを確認します。サーバーへの接続失敗とサブスクリプションURLへのアクセス失敗は別の問題であり、同じネットワーク経路を使うとは限りません。以前から使えているサーバーが残っている場合は、そのままにしてください。リクエストに一度失敗しただけでグループを削除して作り直すのは避けましょう。作り直してもURLの失効は解決せず、利用可能な記録や問題を調べる手がかりを失うおそれがあります。

リクエストが成功しても、返された内容を解析できるか確認が必要です。エラーページも通常のWebページとして返される場合があるため、URLを開けるだけではサブスクリプションが有効とは言えません。更新後にグループが空になったり、想定と大きく異なる内容になったりした場合は、続けて更新せず、元のURLと用途を再確認してください。調査の際、返されたテキスト全体を公開する必要はありません。サーバー情報、Webページの案内、空の応答のどれかを説明し、アクセス情報を漏らさないようにしましょう。

内容が置き換わった後は、現在選択されている項目を改めて確認します。名前が変更または削除された場合、以前の選択が同じサーバーを指しているとは限りません。同じ名前の項目でも内部の設定が変わっていることがあります。まずよく使う項目を1つ選び、アドレスとプロトコルを確認してからテストと実際のアクセスを行いましょう。1つだけ異常がある場合はその項目に絞って調べます。グループ全体に問題がある場合は、サブスクリプションの取得、アカウントの状態、共通設定を確認してください。

ローカルの変更とサブスクリプションの管理を分ける

サブスクリプション内で手動編集した名前や接続設定は、更新時に取得元の内容で上書きされることがあります。変更が保持されるかどうかは、実際の更新結果を確認してください。ローカルの変更を長期間残す必要がある場合は、記憶に頼らず、変更した項目と理由を記録し、ローカルでの個別変更であることを明確にします。アプリで独立したコピーを作れる場合はテスト用に利用できますが、サブスクリプション内の元項目とは別の名前にしてください。次回の更新後にテスト用のコピーを選び、古い設定を現在の設定と誤認するのを防げます。

更新頻度は実際に情報が変わる頻度に合わせましょう。短時間に何度もリクエストしても、誤った内容が正しくなるわけではなく、結果を比較しにくくなることがあります。更新に失敗したら、まずメッセージを読み、ネットワークとURLを確認してから再試行するか判断してください。問題を調べるために自動更新を一時停止する場合は、その設定を記録し、原因が分かった後で元に戻しましょう。一時的な設定を放置すると、以後更新されていないことに気付かないおそれがあります。

更新後のサーバー一覧は、ルール設定の更新履歴ではありません。Configが独立したリモートルールや他のリソースを参照している場合は、それぞれの方法で管理してください。Subscribeを更新しても、これらのリソースが同期されるとは限りません。最終確認では、サーバーの内容が想定どおりか、現在の選択項目が有効か、Global RoutingとConfigが目的に合っているかを確認します。3つを確認することで、「サブスクリプションの管理完了」と「現在接続できる状態」を正確に区別できます。

06複数のサブスクリプションを分類して整理

取得元ごとに分け、用途が分かる名前を付ける

複数のサブスクリプションを管理する場合は、まず取得元を明確に分けましょう。それぞれに識別しやすい名前を付け、どこから更新される内容なのかを分かるようにします。すべてのサーバーを出所の分からない一覧にまとめないでください。名前にはデバイスでの用途や独自の分類を含められますが、パスワード、アクセストークン、サブスクリプションURL全体は含めないでください。時間がたってから見ても、どこで管理する内容なのか分かる名前にしましょう。

サーバーのメモとサブスクリプション名は役割が異なります。サブスクリプション名はグループの取得元を示し、サーバーのメモは個々の項目を見分けるために使います。用途を先に書き、その後に元の識別しやすい名前を残すなど、簡潔で安定した命名がおすすめです。一時的なテスト結果を長期的な名前に含めないでください。ネットワークの状態は変化しますが、名前は事実として受け取られやすいためです。取得元が付けた名前は次回の更新で戻る可能性があるため、ローカルでの名称変更だけを唯一の識別方法にしないでください。

重複項目は名前だけでなく設定内容を比較する

同じ名前のサーバーが重複しているとは限らず、名前が異なっていても別の接続先とは限りません。整理するかどうか判断する際は、認証情報の機密性を保ちながら、プロトコル、アドレス、ポート、主要なトランスポート設定を比較してください。サブスクリプション由来の項目と手入力した項目は、現在の設定が同じでも管理方法が異なります。前者は継続的に更新される可能性がありますが、後者にはローカルで保存した設定が残ります。削除前に、残したい名前だけでなく、維持したい管理方法を確認してください。

長期間使っていないグループがある場合は、現在選択されている項目が含まれていないか、Config内のポリシーグループが名前を参照していないかを確認してください。名前の一致に依存する設定では、名前の変更や削除が次の選択に影響することがあります。画面上の並べ替えは項目を探しやすくするだけで、ルールの優先順位を変更する方法ではありません。上から順に実行されるルールはConfigの内容に属し、Homeでサーバーが上や下に表示されることとは別の概念です。

複数デバイスでは、見た目の統一より内容を把握できることを重視する

iPhoneとiPadで同じ情報を管理する場合は、取得元の名前をそろえるとデバイス間で照合しやすくなります。ただし、一方のデバイスにあるサーバー、選択状態、Configが、もう一方にもすべて自動で反映されるとは限りません。同期の有無と範囲は、アプリの実際の設定を確認してください。2台で同じ名前が表示されていても、インポートした内容と現在の設定をそれぞれ確認しましょう。同じメモは、設定や接続状態が一致している証拠にはなりません。

サブスクリプションの整理は少しずつ進めましょう。取得元を1つ選び、名前付け、重複確認、テスト、バックアップを終えてから次に進みます。複数のグループを一度に削除し、名前を変え、Configを切り替えると、後から接続に問題が起きた際に元の状態を特定しにくくなります。使わなくなる情報は、まず取得元と用途を記録し、現在の接続に依存していないことを確認してから削除してください。一時的に使わない状態と完全に廃止した状態は、管理記録で区別しましょう。

管理記録に秘密情報をすべて残す必要はありません。通常は、グループ名、インポート方法、Configの用途、変更理由、確認結果を記録すれば問題の調査に役立ちます。サーバーの認証情報やサブスクリプションURL全体は保護された場所に保管し、公開メモと一緒にしないでください。他の人に問題を説明する場合は、「サブスクリプションの更新後に同じ名前の項目ができた」「手入力したコピーでは接続できる」などの情報で十分です。グループ全体のエクスポートを送らないでください。

整理後は一覧の見た目だけでなく、実際の利用状況を確認しましょう。意図したサーバーが選択されているか、Global Routingが正しいか、必要なWebページを開けるかを確認し、必要に応じて接続履歴も見ます。整理後に問題が起きた場合は、まず直前の変更を元に戻してください。すぐにDNSやすべてのルールを変更しないでください。各作業を記録し、確認できる状態にしておくと、日常の整理が際限のない接続トラブルの調査に発展するのを防げます。

07Connectivity Test、遅延、並べ替え

テスト結果から分かるのは、実際に測定した内容だけ

Connectivity Testはサーバー関連の接続状況を確認するための機能ですが、結果は選択したテスト方法に応じて判断する必要があります。方法によって、接続を確立できるか、プロキシ経由でリクエストできるか、指定されたテスト先へアクセスできるかなど、確認する層が異なります。テスト項目と選択肢はアプリの画面で確認してください。時間が表示されても、そのテストで所定の処理が完了したことを示すだけです。すべてのWebサイト、プロトコル、長時間の通信が正常だとは判断できません。

テスト結果は現在のネットワーク、テスト先、サーバーの状態、測定時刻に左右されます。サーバー同士を比較する際は、できるだけ同じテスト方法とネットワーク条件を使い、異なるデバイス、時間、テスト先の結果を混ぜて並べ替えないでください。一度の異常が継続的な障害を意味するとは限らないため、時間をおいて再テストし、実際の利用状況と照らし合わせましょう。反対に、一度成功しても頻繁な切断が解消したとは限りません。問題が繰り返し起きるかどうかを記録してください。

接続、認証、名前解決、ルールの順に原因を調べる

基本的な接続も確立できない場合は、まずアドレスとポートを確認し、現在のネットワークからサーバーへ到達できるか確認します。トランスポート接続はできるのにプロキシのリクエストに失敗する場合は、認証、TLS、トランスポート設定を確認してください。プロキシのリクエストは成功するのに一部のドメインが開けない場合は、サブスクリプション全体を入れ替えるのではなく、DNSとルールを確認します。この順序で一度に1つの層を調べると、サーバー、ドメインの名前解決、ルーティングの問題を混同せずに済みます。

テストが正常でもWebページが開けない場合は、実際のリクエストに適用されるポリシーを確認してください。Global RoutingがConfigの場合、ルールが上から順に照合され、リクエストに適用するポリシーが決まります。ProxyとDirectは全体のルーティング方式を切り替えるもので、サーバーのテスト結果だけからWebページの経路は判断できません。まず現在の方式を確認し、リクエストが想定したサーバーを使っているかを見ます。接続履歴がある場合は、ドメイン、ポリシー、エラーをあわせて確認し、遅延の数値だけに注目しないでください。

並べ替えは項目を探すためのもので、長期的な品質評価ではない

テスト結果で並べ替えると、今回応答が速かった項目を選びやすい位置に移動できますが、この順番を安定した品質ランキングと捉えないでください。応答時間、継続的な通信速度、接続の安定性は別の指標であり、適したアクセス先も異なる場合があります。テストに失敗した項目は、すぐ削除するのではなく、設定不足や一時的な到達不能がないか確認してください。サブスクリプション内の項目は、次回の更新で接続情報が変わることもあります。

1つの項目を検証する場合は、それを選択して実際にアクセスできるか確認します。システム上の接続状態を確認し、目的のWebページを開いて、期待どおりの結果になるかを見てください。一部のページだけに問題がある場合は、サーバーとモードを変えずに、開けるドメインと開けないドメインを比較します。一度に1つの条件だけ変更すれば、サーバー変更、ルール、名前解決、アクセス先の違いのどれが結果に影響したか判断できます。

テストを記録する際は、利用したネットワーク、テスト方法、現在のサーバー、Global Routing、再現できる現象など、必要な情報を残します。エラーメッセージに含まれるドメイン名や設定値が機密情報を示す場合があるため、共有前に隠してください。特定のアクセス先だけに問題がある場合は、まとめて実行したテスト結果でそのアクセス先の確認を代用しないでください。ネットワーク全体が使えない場合は、まずデバイス自体がインターネットに接続できることを確認してから、Shadowrocketのサーバーと設定を調べます。

並べ替え後は現在の選択も確認してください。リストの位置が変わっても、アプリが自動的に先頭の項目へ切り替わるとは限りません。作業の最後に、どの取得元の項目を使い、どのモードを選び、一時的な変更を元に戻したかを明確にしておきましょう。次回問題が起きたとき、前回のテストで何が変わったかを推測せず、確認済みの状態から調べられます。初回の詳しい確認手順は使い方ガイドをご覧ください。

08削除、バックアップ、デバイス移行後の復元

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

サーバー1台、Subscribeのグループ1つ、Configファイル1つでは、削除の影響範囲が異なります。単一のサーバーは接続項目に、サブスクリプショングループは一連の項目と更新元に、設定ファイルはルールや関連設定に関係します。操作前に確認メッセージをよく読み、現在の接続がその項目に依存していないか確認してください。画面上ではいずれも削除操作でも、結果は同じではありません。特に問題の調査中に、ルール設定までまとめて削除しないよう注意しましょう。

サブスクリプション内の項目を削除しても、取得元の一覧に残っている場合、次回更新時に再び表示されることがあります。独立したローカル項目には同じ復元元がありません。特定の項目を長期間除外したい場合は、何度も削除を繰り返すのではなく、アプリにある絞り込みや管理方法を確認してください。グループ削除後の復元には通常、元のサブスクリプションURLと有効なアクセス手段が必要です。サーバー名だけを覚えていても、元のサブスクリプションとの関係は復元できません。

取得元、設定項目、Configごとにバックアップを確認する

バックアップには、実際に復元したい対象を含めてください。サブスクリプションURLがあればサーバーを再取得できます。独立したサーバーには設定一式を、Configにはファイルと関連する依存情報を保存する必要があります。現在選択されている項目、Global Routing、On Demandなどの設定も、必要に応じて記録してください。アプリの書き出し、共有、バックアップ機能に含まれる範囲は、画面の説明と出力内容で確認します。どの方法でも状態がすべて保存されるとは限りません。

1. 既存のサブスクリプションの取得元を一覧にし、元のURLを保護された記録から取り出せることを確認します。
2. 手入力したサーバーに完全な設定情報が別途あるか確認し、サブスクリプション由来の項目と区別します。
3. 移行するConfigを保存し、リモートリソースを引き続き取得できるか確認します。
4. 現在のモード、選択中の項目、必要なオンデマンド接続設定を記録します。
5. 移行先での復元と確認が終わってから、古いデバイスや一時的なエクスポートファイルを整理します。

エクスポートした内容には、パスワード、UUID、秘密鍵、サブスクリプションのアクセス情報が含まれる場合があります。保存場所を保護し、アクセスできる人を制限してください。公開リンクの共有ストレージ、グループチャットのファイル、公開メモに接続情報全体を保存しないでください。システムのファイル保存やデバイスバックアップを利用する場合も、アカウントとデバイスのアクセス保護を確認します。バックアップの目的は復元できるようにすることで、複製を増やすことではありません。複数の場所に分散し、新旧を判別できないファイルは、誤用や情報漏えいのリスクを高めます。

アプリの復元と接続情報の復元は別の作業

機種変更や再インストール後は、まずApp Storeから購入済みのShadowrocketを復元し、その後サブスクリプションと設定を戻します。アプリの購入記録とサーバー情報は別のものです。アプリを再入手しても、接続情報がすべて復元されるわけではありません。購入済みアプリの再ダウンロード手順は購入済みアプリの復元方法をご覧ください。システム要件、購入の適用条件、互換性はApp Storeページの記載を確認してください。別のデバイスの状態から判断しないでください。

新しいデバイスで復元する際は、まず取得元を1つ、またはサーバーを1台だけ追加し、設定を確認して接続をテストしてから、他の情報を復元します。Configを戻した後は、現在選択中の設定になっているか、ルールが参照する名前、リソース、サーバーとの関連が保たれているかを確認してください。古いデバイスでローカルの個別変更をしていた場合は、管理記録を見ながら1つずつ反映します。テスト用のコピーをすべてインポートしてから正しい設定を推測するのではなく、少しずつ復元すると見落としを特定しやすくなります。

削除前に復元と動作確認を完了する

移行完了の基準は、インポート数が一致することではなく、実際に利用できることです。少なくとも、現在のサーバーに接続できること、よく使うアクセス先が開けること、Global Routingが目的に合っていること、On Demandが意図どおりに設定されていることを確認します。新しいデバイスでは接続の許可を改めて求められる場合があります。システムの確認画面を読んでから操作してください。確認が終わる前に、古いデバイスにある唯一の独立した設定を消したり、スクリーンショットの名前だけをバックアップの代わりにしたりしないでください。

サブスクリプションURL全体やサーバーの認証情報を誤って送信した場合、メッセージやローカルファイルを削除しても、すでに共有されたコピーは無効になりません。元のアカウントまたはサーバーの管理方法で認証情報に対処し、デバイスに保存した情報を更新してから、接続を再確認してください。必要な変更履歴は残しつつ、古い秘密情報をトラブル対処メモに書き続けないようにしましょう。今後のバックアップも整理し、復元時に無効または漏えい済みの内容を再び読み込まないようにしてください。