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

01 / Subscribe

Subscribe から追加・初回読み込み

まず手元の情報の種類を確認

サブスクリプションは、アクセスするとサーバー情報の一覧を取得できるURLです。単体のサーバーリンクは通常、1つの接続先を示します。Configは通信をどのルールに照合するかを決めます。いずれもリンクやファイルとして渡される場合がありますが、管理する対象は異なります。読み込む前に資料を確認し、サーバーのサブスクリプション、単体の共有リンク、Configファイルのどれに当たるかを確かめてください。ブラウザーで開けるからといって、Subscribeに入力できるとは限りません。ログイン画面や説明ページと、サブスクリプションの応答は別のデータです。

サブスクリプションURLはご利用のサービス提供元から入手してください。コピーする際は、疑問符以降のクエリパラメーターも含めて1行すべて取得します。これらのパラメーターが認証に使われている場合があり、削除するとドメインが正しくても空の一覧やエラーページが返ることがあります。チャットアプリを経由した場合は、末尾が欠けていないか、句点が付いていないか、改行が文字として混入していないか確認してください。実際のURLを検索欄や公開掲示板に貼らないでください。問い合わせる際は、エラーの種類と一部を伏せたドメインだけを伝えます。

Add Server で Subscribe を選択

1. Homeを開いて追加画面に進み、Add Serverを開きます。TypeでSubscribeを選択してください。
2. URLにサブスクリプションURLを全体入力し、見分けやすいメモを付けて保存します。
3. 初回のリクエストが完了したらHomeに戻り、該当するグループを開いてサーバー一覧が表示されることを確認します。
4. 一覧からサーバーを1つ選び、クイックスタートの手順に沿ってGlobal Routingと接続を確認してください。

サブスクリプション項目の保存と、サーバー情報の取得は別の段階です。Homeに名前が表示されても、ローカルに追加項目が保存されたことしか分からず、リモートの内容が解析されたとは限りません。初回の読み込み後は、グループが展開されているか、サーバー名がすべて表示されているか、件数が手元の資料と一致するかを確認します。一覧が空の場合は、まずリクエストの通知を確認してからURLを見直してください。同じ名前の項目をすぐに複数作ると、正しいURLが保存されたものと、失敗した項目を区別しにくくなります。

リクエスト、コンテンツ、接続の失敗を区別する

リクエストの失敗は、サブスクリプションの応答を取得できていない状態です。現在のネットワーク、名前解決、URLの有効性、アクセス権などが原因として考えられます。コンテンツの失敗は、応答を受信したもののサーバー一覧として認識できない状態です。接続の失敗は、サーバー情報を取得した後に発生します。この3段階を順に確認し、サーバー1台のタイムアウトをサブスクリプションの解析エラーと混同しないでください。応答がWebページの案内文なら、その内容に従ってアカウント状態やURLを確認します。ページ本文を設定として読み込まないでください。公開するトラブル画面では、サブスクリプションURL全体を隠してください。

初回の読み込みは、サブスクリプションURLに正常にアクセスできるネットワークで行うのがおすすめです。更新リクエストがすでに使えないサーバー経由で送られると、「接続を戻すには更新が必要だが、更新には接続が必要」という状態になることがあります。その場合は、使えない接続を一時的に無効にし、ローカルネットワークが利用できることを確認してから、サブスクリプションを再取得してください。サービス提供元からアクセス条件が案内されている場合は、その資料も確認します。設定をむやみに何度も切り替えず、失敗時の通知を記録しておくと、環境の問題か情報の問題かを切り分けやすくなります。

02 / Add Server

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

最初にTypeを選び、項目を順に入力

手動追加は、サーバーの設定一式をすでに持っていて、独立した項目として管理する場合に使います。Add Serverを開いたら、まずTypeを選択してください。プロトコルによって表示される項目と意味が異なるためです。似た種類を選び、ポートを変えながら接続を試す方法は避けてください。Shadowsocks、VMess、VLESS、Trojan、HTTP、SOCKS5、WireGuard、Hysteria2では、認証方式や通信方式が異なります。同じアドレスとポートでも、相互に置き換えられるわけではありません。

Addressには通常、ホスト名またはアドレスのみを入力し、Webページのパスは含めません。Portには資料に記載されたサーバーポートを入力します。ホスト名の欄にコロンとポートを一緒に入れないでください。元の情報が共有リンク全体の場合は、クエリパラメーター内の通信設定を失わないよう、リンクから読み込む方法を優先してください。メモはローカルでの識別用であり、接続設定の誤りを直すものではありません。パスワードや識別情報ではなく、提供元、用途、プロトコルを組み合わせた名前がおすすめです。

認証、TLS、通信設定を分けて確認

Shadowsocksでは暗号化方式とパスワードを確認します。VMess、VLESSでは通常UUIDを識別情報として使います。Trojanではパスワードが必要で、TLSとSNIも資料に沿って確認します。HTTPやSOCKS5でユーザー名とパスワードが必要かどうかは、サーバーの設定によって異なります。入力欄が空でもよいからといって、省略しないでください。WireGuardの鍵、インターフェースアドレス、ピア情報は別の形式です。サブスクリプションのパスワードを秘密鍵の欄に入力してはいけません。不明な項目は元の資料を確認し、異なるプロトコルの欄を順に試す方法は避けてください。

TLSの設定は、該当する暗号化セッションを確立するかどうかを決めます。SNIはそのセッションで使用するサーバー名です。接続先アドレスが別の入口ドメインになっている場合もあります。資料で別々に記載されている場合は、それぞれ対応する欄に入力してください。証明書名の不一致やハンドシェイクの失敗が起きた場合は、SNI、システム時刻、元の資料を確認します。証明書の検証を無効にする方法を通常の対処として使わないでください。変更するパラメーターは1つずつにし、結果を記録しておくと、正しい設定まで壊すのを防げます。

通信方式とHost、Pathなどの設定は、組み合わせを正しくそろえる必要があります。パスの先頭や末尾の文字、クエリ部分を推測で追加・削除しないでください。日本語入力で全角記号、スマートクォート、空白が入った場合もパラメーターが変わります。保存前に各項目を資料と1行ずつ照合し、画像から読み取った数字、英字、ハイフンは特に注意して確認します。資料に任意項目がない場合は、プロトコルの初期設定を使い、別のサーバーの値で補わないでください。

独立した項目として保存し、変更範囲を把握

手動で追加した項目と、サブスクリプションから生成されたサーバーは分けて管理してください。サブスクリプション内のサーバーを直接変更すると、次回更新時にリモートの内容で上書きされる場合があります。ローカルの変更を継続して保持する必要がある場合は、コピーまたは独立追加した項目がサブスクリプションの管理対象から外れているか確認してください。保存後にテストし、接続して実際のリクエストも検証します。同じ設定がネットワークによって異なる動作をする場合は、それぞれのネットワーク条件を記録し、すぐにパスワードの誤りと決めつけないでください。

トラブルの共有に必要なのは、プロトコル、伏せ字にしたアドレス、ポート、通信方式、エラー内容です。認証情報を公開する必要はありません。Trojanの各項目の関係は、Trojanのパスワード、SNI、TLS設定の解説もご覧ください。サーバー側の設定については、元の資料を項目ごとに確認してください。メモを変更しても、クライアントが不足している項目を自動で推測することはありません。

03 / Import

QRコードとクリップボードから読み込む際の注意点

Scan QR Code は内容を読み取る機能

QRコードは文字情報を格納する方法であり、必ずサーバー情報が含まれているとは限りません。Scan QR Codeで読み取れるのは、単体のサーバー共有リンク、サブスクリプションURL、通常のWebページなどです。読み取り後は、クライアントがどの種類の項目を作成しようとしているか確認してから保存してください。Webページが開いただけなら、資料に戻ってQRコードの用途を確認します。内容をどのプロトコル欄にでも入力しないでください。QRコードに認証情報が含まれる場合、撮影、転送、写真の同期によって保存先が増える点にも注意してください。

Homeの追加メニューからScan QR Codeを選び、システムの案内に従ってカメラへのアクセスを許可します。QRコード全体が画面に収まるようにしてください。図柄の一部が隠れないようにし、反射や傾き、画面の拡大縮小によるぼけを避けて読み取ります。QRコードが同じ端末に表示されている場合は、読み取り画面に写真を選ぶ機能があるときのみ画像から読み込んでください。その機能がなければ、資料に記載されたテキストリンクを使います。認証情報を含む画像を外部の読み取りサイトにアップロードしないでください。

クリップボードから読み込む前に元のテキストを整える

共有リンク全体をコピーしてShadowrocketに戻り、画面に表示されたクリップボード読み込み機能を使います。貼り付け許可を求められたら、今回の操作に応じて許可してください。コピー元にタイトルや説明、複数のリンクが含まれている場合、クライアントがどの内容を認識できるか確認します。複数項目の読み込みに失敗した場合は、完全なリンクを1つだけコピーして検証すると、形式が非対応なのか説明文が混入したのかを切り分けられます。実際にコピーされた内容を確認せず、許可を何度も求めないでください。

1. 自分の資料からリンクを1つ全体コピーし、プロトコルの先頭部分と末尾のメモが含まれているか確認します。
2. クリップボードの読み込み画面を開き、プレビューや結果の通知から作成される項目の種類を確認します。
3. 保存後にHomeで新しい項目を探し、プロトコル、アドレス、所属グループを確認します。
4. 完了後は一時的なコピー内容を消去し、次回貼り付け時に認証情報を誤送信しないようにします。

チャットアプリでは長いリンクが折りたたまれて表示されることがあります。画面上で1行に見えても、全体がコピーされたとは限りません。エディターによっては、半角の引用符が曲がった引用符に置き換わったり、リンクの途中に改行が挿入されたりします。その場合は元のテキストに戻り、「リンクをコピー」または「原文をコピー」を使ってやり直してください。テキスト経由で渡す必要がある場合は、プレーンテキストを保持できるローカルツールを使い、一般公開の共有機能を有効にしないでください。自分の情報のみを扱い、他者の認証情報を保存しないでください。

読み込み後も項目を確認

読み込みに成功したということは、解析機能が認識可能な構造を見つけたというだけで、すべての項目がサーバーの要件を満たすとは限りません。保存後はType、アドレス、ポート、TLSや通信方式に関する設定を確認してください。メモに記載された用途と各項目が合っているかも確認します。画像を切り抜いたQRコードや、読み取った文字、何度も転送された画像の場合は、特に元の設定と照合してください。QRコードとテキストリンクから異なる項目が作られた場合は、同じ接続先を示しているか確認できるまで接続を保留します。

QRコードの再読み取りやリンクの再貼り付けによって、独立した項目が複数作成されることも、既存の項目が更新されることもあります。動作は入口や内容によって異なります。名前だけで上書き済みと判断せず、一覧に戻って提供元、グループ、項目の詳細を確認してください。複数項目を読み込む前に既存のグループを記録し、読み込み後は追加内容を確認してから、失敗した中間項目を削除します。安定して使えている項目がある場合は、新しい項目の動作を確認するまで残しておき、比較用の基準を誤って失わないようにしてください。

カメラへのアクセス許可の失敗、貼り付けの許可拒否、内容の解析失敗は別の問題です。前の2つはシステム設定のアクセス許可を確認し、解析失敗ではリンクの種類、エンコード、内容が完全かを確認します。権限を追加しても、誤った形式が有効なサーバー情報に変わることはありません。読み取り画面は正常でもQRコードを認識できない場合は、画面の反射を抑え、元のQRコードを拡大するか、テキスト情報を使ってください。QRコード内の欠けた認証文字を推測して補わず、自分の完全な資料を再取得してください。

04 / URI

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

リンクの長さではなく構造で判断

共有リンクは通常、プロトコルの接頭辞、認証情報、接続先アドレス、ポート、クエリパラメーター、メモなどで構成されます。プロトコルごとに形式は異なります。項目を直接読めるもの、エンコードされているもの、複数のパラメーターをまとめてからエンコードするものがあります。あるプロトコルのリンクでユーザー名がある位置を、別のプロトコルにも機械的に当てはめないでください。「文字化けしているように見える」からといって、エンコード部分を削除するのも避けてください。プロトコルの接頭辞を確認し、対応する読み込み機能を使います。手動での解析は、情報の構造確認に限ってください。

サブスクリプションURLには通常HTTPまたはHTTPSが使われ、リクエスト時にサーバーから一覧が返されます。URLがWebページのリンクに見えても、Configファイルとは限りません。判断材料は応答の種類と資料の用途です。サブスクリプションURLを通常のHTTPプロキシとして追加すると、サーバー一覧の取得先を接続先として扱うため、誤った項目になります。同様に、ConfigファイルをSubscribeに指定しても、ルールがサーバー情報に変換されるわけではありません。

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

trojan://[email protected]:443?security=tls&sni=example.com#Personal-Trojan

上記は構造を説明するための例です。ドメイン、パスワード、サブスクリプションのパラメーターはいずれも説明用のダミーで、接続には使えません。1つ目は一覧の取得に使われるURL、2つ目は単体のTrojan共有リンクの構成を示します。実際の情報には追加パラメーターが含まれる場合があります。例に合わせるために削除・変更しないでください。リンク内のシャープ記号以降は通常メモを示し、疑問符以降は通常パラメーターを示します。ただし対応範囲はプロトコルとクライアントの解析結果によって異なります。

エンコードは暗号化ではなく、メモは認証情報ではない

パーセントエンコードは一部の特殊文字を表すために使われます。共有リンクの形式によってはBase64エンコードも使われます。エンコードされたテキストからパスワードやサーバー情報を復元できる場合があるため、匿名化したものとして公開しないでください。パスワードに特殊記号が含まれる場合は、適切なエクスポートまたはエンコード処理が必要です。区切り文字を含むパスワードをリンクに直接連結すると、解析される範囲が変わることがあります。読み込み後に項目がずれている場合は、エスケープ文字を次々に追加せず、元の共有リンクから読み込み直してください。

メモとサーバーの識別情報は別々に考えてください。同じメモの2つのリンクが、異なるアドレスや認証情報を示すことがあります。同じサーバーが異なるメモで一覧に複数回表示される場合もあります。比較する際は、シャープ記号以降の名前だけではなく実際の項目を確認してください。形式の問題を他の人に説明する場合は、ダミーのドメインとパスワードを使った構成例を作ります。メモを「テスト」に変更しただけでは、機密情報は削除されません。

Configはルールを管理するもので、サーバー情報の代わりにはならない

Configは、リクエストをどの順序でポリシーに照合するかを決めます。Global RoutingのConfigモードではルールが使われ、ProxyモードとDirectモードは異なる全体処理に使用されます。サーバーを正常に読み込めたのに通信経路が想定と異なる場合は、現在のモードと有効なConfigを確認してください。同じサーバーを再度読み込む必要はありません。以下はルールの順序を理解するための例です。まず指定ドメインに照合し、次に地域ルールを確認し、最後にどのルールにも該当しないリクエストをFINALで処理します。

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

この内容はサブスクリプションでも、単独で接続できるサーバー情報でもありません。PROXYは該当するプロキシポリシーを示しますが、実際に使えるかどうかは選択中のサーバーとConfigの内容によります。DIRECTは対象のリクエストを直接接続することを示します。ルールは上から順に評価され、先に一致すると通常は後続のルールを検索しません。サーバー情報とルールは別々にバックアップし、別々にテストしてください。変更は一度にどちらか一方に絞ると、接続先と通信の振り分けのどちらに問題があるか判断しやすくなります。

DOMAIN-SUFFIX、GEOIP、FINALなどのルールキーワードや画面用語については、用語集をご覧ください。リンクの読み込みに失敗したときは、まず対象の種類を判断し、次に構造、最後に各項目を確認します。形式の誤りを無関係なルールの変更で直そうとしないでください。読み込み後に名前が正常に表示されても、認証情報が正しいとは限りません。

05 / Update

サブスクリプションの更新方法と失敗時の対処

更新されるのは提供元の内容で、遅延の数値だけではない

サブスクリプションを更新すると、提供元に再度リクエストを送り、その応答に基づいて管理対象のサーバーが更新されます。アドレス、ポート、認証、通信設定、名前が変わる場合があります。これは一覧の遅延を再テストする操作とは異なります。テストで確認できるのは、現在保存済みの項目だけです。リモート側で変更された新しい設定は取得できません。複数のサーバーが同時に使えなくなった場合は、まず情報の更新が必要かを確認してからネットワークを調べてください。古い項目を繰り返しテストして、提供元の変更が反映されたと思い込まないようにします。

更新手順を決めるときは、結果を確認できる状態で手動更新を一度行ってください。更新前に、どのサブスクリプション、どのサーバーを使っているか、ローカルで変更した項目があるかを確認します。更新後は、提供元のグループ、選択中の項目、実際の接続をチェックしてください。自動更新の設定が画面にある場合は、管理方法に合わせて有効にします。すべてのプラットフォームで同じ時刻にバックグラウンド更新されるとは限りません。システムのバックグラウンド制限、ネットワーク状態、クライアントの起動状況などが、実際のリクエスト時刻に影響します。

利用状況に応じて更新頻度を決める

適切な更新頻度は、情報が変わる頻度と利用場面に基づいて決めます。更新回数を増やせばよいわけではありません。長期間安定している提供元は、使う前や変更通知を受け取った後に確認すれば十分です。出張、ネットワークの切り替え、端末の移行前には、事前に更新して動作を確認できます。短時間に何度もリクエストしても、無効なURLは直らず、提供元のアクセス制限に達する可能性もあります。バックグラウンドでの動作が画面上で明確でない場合は、未確認の自動更新を前提にせず、手動で確認して結果を検証してください。

1. 更新前に使用中の提供元と項目を記録し、必要なら独立したローカル設定をバックアップします。
2. サブスクリプションを1つだけ更新し、リクエストの通知とグループの変化を確認します。ルールは同時に変更しないでください。
3. 元の選択項目が残っているか確認し、新しい設定を確認してからテストします。
4. 接続を再確立し、実際のリクエストを検証します。正常に動作してから次の提供元を更新してください。

サブスクリプションから生成された項目への手動変更は、次回以降の更新で上書きされる場合があります。名前、並べ替え、グループが保持されるかどうかも、実際の結果で確認してください。長期的に保持する変更は、独立して管理する項目に記録し、更新のたびにローカル設定が残ると期待しないでください。提供元から削除されたサーバーがローカルのキャッシュに表示されていても、引き続き使えるとは限りません。使い慣れた名前を残すために、認証情報や接続先の変更を見落とさないようにします。

4つの段階に分けて失敗を確認

第1段階では、ローカルネットワークからリクエストを送信できるか確認します。第2段階では、サブスクリプションのドメインを名前解決し、接続できるかを確認します。第3段階では、提供元が有効な内容を返しているか確認します。第4段階では、その内容を現在の読み込み機能で解析できるか確認します。各段階で必要な根拠は異なります。接続エラーと認証情報の無効を示す通知を混同しないでください。権限に関する通知が出た場合は、自分のサブスクリプションURLとアカウント状態を再確認します。通常のWebページが返る場合は、サーバー用サブスクリプションではなく管理ページをコピーしていないか確認してください。

更新後に一覧が突然空になった場合は、削除操作を止めてください。グループが折りたたまれていないか、フィルターで項目が隠れていないかを確認し、更新が完了したか、提供元が本当に空の結果を返したかを調べます。単なる表示上の問題なら、再読み込みすると重複が作られる可能性があります。提供元の内容自体が変わっている場合、古いキャッシュを戻しても使えるとは限りません。更新前の必要な情報を記録しておくと比較に役立ちますが、すべてのサーバーパスワードやアクセストークンが含まれる可能性があるため、元の応答を公開しないでください。

更新が成功しても接続できない場合は、サーバーとネットワークの段階で確認します。更新後の項目を1つ選び、プロトコル設定を確認してから、同じ提供元の別の項目もテストしてください。1つだけに影響するなら、サブスクリプション全体を作り直す必要は通常ありません。すべての提供元が同時に失敗する場合は、現在のネットワークとシステム時刻も確認します。サーバーのタイムアウトと接続失敗の対処も参照し、決まった順序で状況を確認してください。複数の画面を行き来して設定を何度もリセットするのは避けましょう。

06 / Organization

複数サブスクリプションのグループ分け、命名、重複項目の整理

提供元ごとにグループ化し、用途が分かる名前を付ける

自分のサブスクリプションを複数管理する場合は、すべてを長い一覧にまとめず、まず提供元ごとの区別を保ちます。各提供元には一貫性があり分かりやすい名前を付け、手動で追加した項目も別に識別できるようにします。そうすることで、更新失敗、設定変更、削除が必要な場合に影響範囲を判断しやすくなります。名前には用途や管理方法を記載できますが、サブスクリプションURL全体、アカウントの識別情報、パスワードは含めないでください。こうした情報が一覧のスクリーンショットに写ると、通常のトラブル資料と一緒に漏れる可能性があります。

グループ名には、長期間変わりにくい情報を使います。一時的な遅延を名前に入れると、ネットワークが変わったときに実態と合わなくなります。現在の並び順を番号にすると、更新後に混乱する場合があります。短い提供元名、用途、プロトコルを使って識別し、元の資料との対応関係も保つ方法が適しています。クライアントで変更できる表示情報に制限がある場合は、その範囲に従ってください。表示を統一するためにサーバーの認証項目を変更しないでください。

重複を確認してから残す項目を決める

名前が同じでも重複とは限らず、アドレスが同じでも重複とは限りません。同じ接続先でも、ポート、プロトコル、認証、通信方式、SNIが異なる場合があります。同じ提供元に、異なるネットワーク条件向けの接続先が複数含まれることもあります。整理する前に、重要な設定と提供元との関係を比較してから削除を検討してください。メモだけが異なる2つの項目でも、片方がサブスクリプション管理下、もう片方が独立したコピーである可能性があります。削除後の管理方法が変わるため、どちらに当たるか確認してください。

複数項目の整理は2段階に分けて行います。第1段階では、重複の可能性がある項目を記録して印を付けるだけにし、すぐには削除しません。第2段階でグループごとに、現在の接続、代替項目、バックアップの状況を確認してから削除します。サブスクリプションから読み込んだサーバーは、次回更新時に提供元から再度返され、手動で削除した項目が再作成されることがあります。そのため、手動削除を繰り返しても変更が維持されるとは限りません。画面にフィルターや整理機能がある場合は、表示だけを変えるのか実際のデータを変更するのか確認してから使ってください。

サブスクリプションの管理とルールポリシーを分ける

提供元ごとのグループはサーバーの読み込み元を示し、ルールポリシーはリクエストの処理方法を示します。両者が1対1で対応するとは限りません。2つのサブスクリプションを別々のグループに分けても、ドメインごとに異なる通信先が自動で割り当てられるわけではありません。ルールで通信を振り分ける場合は、Configと対応するポリシーの設定を確認してください。グループ名からルーティングを推測しないでください。まずサーバー情報を正しく保ち、その後でルールを調整すると、「一覧を整理したら通信が変わった」といった原因を追いにくい問題を減らせます。

提供元を更新した後は、使用中の項目が想定したグループに属しているか再確認します。リモート側で同じ名前が再利用される場合は、切り替える前に詳細を確認してください。見慣れた名前を変わらない識別情報だと思い込まないようにします。一時的に残す古い項目には用途や確認事項を記録できますが、期限切れのコピーを現在の提供元の項目と長期間混在させないでください。管理記録には、なぜ残すのか、どの条件で再確認するかを記載します。意味の分からない星印だけを付けて終わらせないでください。

サブスクリプションが複数あっても、すべての項目を同時にテストする必要はありません。各提供元から代表的な項目を少数選び、読み込みと更新の関係が正常か確認してから、用途に応じて他の項目を調べます。提供元が増えたら、操作の履歴を追えることが重要です。どれを更新したか、どれを変更したか、どれを削除する予定かを記録してください。一度に1つのグループだけを扱い、確認が終わってから次に進むと、一括操作による誤削除を防ぎやすくなり、問題発生時も直前に確認できた状態へ戻しやすくなります。

複数サブスクリプションのグループ分けと整理手順は、複数サブスクリプションの管理ガイドをご覧ください。整理の目的は識別の手間と管理上の曖昧さを減らすことであり、一覧をできるだけ短くすることではありません。用途が分からない項目は、すぐ消して再読み込みするより、まず記録して動作を確認するほうが経緯を保ちやすくなります。

07 / Connectivity Test

遅延テスト、並べ替え、実際の接続確認

テスト結果が示すのは、そのテストで確認した内容のみ

遅延テストの結果は、その時点のネットワークとテスト方法の両方に左右されます。サーバーの恒久的な性能を示す数値ではありません。TCP接続、プロキシ経由のリクエスト、実際のサービスへのアクセスでは、確認する段階が異なるため、数値をそのまま比較できません。始める前にクライアントのテスト設定を確認し、同じネットワーク、近い時間帯、同じ方法で項目を比較してください。一覧に小さい数値が表示されても、認証、TLS、名前解決、接続先サイトへのアクセスがすべて成功したとは限りません。

Connectivity Testの前に、サブスクリプション情報が正しいことを確認してください。古い設定をテストしても、現在の提供元が使えるかどうかは分かりません。更新に失敗した後も、古い一覧のタイムアウトを新しい情報の無効を示すものとして扱わないでください。まず1つの項目を選んでテストし、その結果を見てからグループ全体をテストすると、一括リクエストによる待ち時間や結果の混在を避けられます。テスト中は、大容量ファイルの転送などネットワークを大きく使用する操作を一時停止し、各項目の測定条件をできるだけそろえてください。

対象範囲から問題の段階を判断

サーバー1台だけがタイムアウトする場合は、その項目のアドレス、ポート、プロトコル設定を確認します。同じ提供元の複数項目が失敗する場合は、サブスクリプション情報が更新済みか、提供元で変更があったかを調べます。異なる提供元のすべてが失敗する場合は、まずローカルネットワーク、システム時刻、現在の接続状態を確認してください。ネットワークを切り替えて復旧した場合は、両方のネットワークの違いを記録し、すぐにすべての認証情報を書き換えないでください。単一の遅延値より、障害がどこまで及んでいるかのほうが重要です。次に調べるのがクライアントの項目、提供元の情報、ローカル環境のどれかを判断できます。

並べ替えは項目を見つけやすくするためのもので、選択基準の代わりではありません。テスト後は、同じ条件の項目を測定結果で並べ替え、上位の候補を優先して検証できます。未テスト、失敗、数値が取得できた項目は、それぞれ別の状態として扱ってください。異なるプロトコル、テスト方法、時刻で得られた結果を同じ一覧に混ぜ、特定の項目が常に優れていると判断するのは適切ではありません。条件を記録する場合は、ネットワークとテスト方法を併記し、状況が分からない数値だけのスクリーンショットを保存しないでください。

テスト後もルーティングと実際のリクエストを確認

サーバーを選択して接続し、現在のGlobal Routingのモードを確認してください。Configモードはルールに沿って処理し、Proxyモードはプロキシ経由の経路確認に使います。Directモードは、サーバー経由のプロキシ接続が使えることの証明にはなりません。Configモードで対象のリクエストがルールによりDIRECTへ振り分けられた場合、そのサイトが開けてもサーバーが正常に動作しているとは判断できません。通常利用するアクセス先を使い、接続ログから実際の処理経路も確認してください。画面上部のスイッチだけで判断しないでください。

実際のリクエストが失敗した場合は、接続ログのエラー種類とルールの適用結果を確認してから次の手順を決めます。名前解決エラー、TLSハンドシェイク失敗、認証エラー、接続先による拒否では、必要な対処が異なります。「ブラウザーが読み込み中のまま」というだけでサーバーのタイムアウトと判断しないでください。また、1つの接続先で失敗したからといってサブスクリプション全体を削除しないでください。別の通常の利用先で比較し、特定のドメイン、プロトコル、ネットワークだけに影響するかを確認して範囲を絞ります。

断続的な問題では、テストを続けて実行するより、比較できる少数の記録を残すほうが有効です。ネットワーク、サーバー、Global Routingのモードなど、変更する要素は一度に1つにしてください。その後の動作を確認します。DNS、ルール、認証情報を同時に変更すると、何が改善につながったのか分からなくなります。テスト画面のタイムアウトは、サーバーが恒久的に削除されたことを意味しません。削除前に更新状況と別ネットワークでの再確認を行ってください。長期間使っていない、失効が疑われる項目は、すぐ削除せず確認待ちとして記録してから整理します。

エラーの詳しい切り分け方法は、サーバーのタイムアウト、プロトコル設定、システム時刻の確認をご覧ください。動作を確認してから、必要なOn Demand条件を設定してください。自動接続は接続のタイミングを変更するだけです。誤った設定を修正するものではなく、手動で接続を一度確認する代わりにもなりません。

08 / Backup

削除とバックアップ、新端末への復元手順

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

単体のサーバー、サブスクリプション全体、Configは別々の対象です。独立したサーバーを削除すると、通常はそのローカル項目だけに影響します。サブスクリプション項目を削除すると、そこから管理されているサーバーにも影響する場合があります。Configを削除すると、ルールとポリシーの設定に影響します。操作前に確認メッセージを読み、現在の接続が削除予定の項目に依存していないか確認してください。サーバー1台の失敗を解消するためにサブスクリプションを削除したり、一覧の表示を直すためにConfigをすべて消したりしないでください。局所的な問題の確認基準を失うことになります。

サブスクリプション内のサーバーを削除しても、提供元にその項目が残っていれば次回更新後に再表示されることがあります。これは必ずしも削除に失敗したという意味ではなく、提供元の内容からローカル項目が再生成された可能性があります。提供元全体を使わなくなる場合は、バックアップと代替接続を確認してから該当する項目を削除してください。一部の項目だけを一時的に非表示にしたい場合は、表示上の整理機能が使えるか確認します。削除前に管理関係を記録しておくほうが、削除後に名前だけで元のグループを推測するより確実です。

復元に必要な範囲を考えてバックアップ

バックアップでは、少なくとも3点を確認します。サブスクリプションを再取得できるか、独立したサーバーを復元できるか、ルールを復元できるかです。サブスクリプションURLだけを保存しても、手動で追加した項目やローカルのConfigは戻せない場合があります。ルールファイルをエクスポートしても、サーバーの認証情報が含まれるとは限りません。エクスポート機能を使う際は、実際に含まれる対象を確認してください。「ファイルが作成された」だけで、すべての情報が保存されたとは限りません。バックアップファイルには機密情報が含まれることがあるため、自分で管理する安全な場所に保存し、公開や不用意な転送を避けてください。

1. 現在使用中のサブスクリプション提供元と必要な管理情報を記録し、完全な認証情報は保護された場所に保存します。
2. 独立したサーバーとConfigをバックアップし、エクスポート対象とファイルの読み取り可否を確認します。
3. 現在のGlobal Routingモードと、再確認が必要なOn Demand条件を記録します。
4. 旧端末をまだ使えるうちに復元手順を確認し、成功してから古い情報を整理します。

iCloud同期を使う場合は、自分の端末とアカウント、実際に同期される対象が条件を満たしているか確認してください。ローカル情報がすべて自動で同期されると思い込まないでください。同期は端末間で状態を共有する仕組みで、バックアップは復元可能なコピーを保つものです。用途が異なり、誤って削除した内容が同期によって他の端末にも反映される場合があります。そのため、まとめて削除する前、グループを作り直す前、端末を移行する前に、対象が分かる独立したバックアップも保存してください。何が含まれているか記録しておくと、復元時にファイルを選び間違えにくくなります。

情報を復元してからルールと自動接続を確認

新しい端末では、まずクライアントを入手し、サブスクリプションを1つ、または独立したサーバーを少数復元して基本接続を確認します。その後Configを復元し、最後にOn Demandを確認してください。すべての情報を一度に読み込んで自動接続をすぐ有効にすると、ルールの誤り、認証情報の失効、システムの起動条件が重なり、原因を切り分けにくくなります。新しい端末では、システムのVPN関連の許可を表示に従って設定してください。旧端末で正常に接続できても、許可状態がそのまま移行されるとは限りません。移行が終わるまでは、旧端末を比較用に残しておきます。

復元したサブスクリプションは再更新し、独立した項目は設定を再確認し、ルールは参照先のポリシーが現在も存在するか検証してください。名前が同じでも同じ項目とは限りません。移行後のConfigが存在しないグループを参照している場合は、関係を修正してから実際のリクエストをテストします。バックアップの成否はファイル数ではなく、明確な手順に沿って使える状態を再構築できるかで判断します。一度実際に復元した結果を記録しておくと、次回の端末移行で同じ作業をやり直さずに済みます。

クライアントの入手について、iPhone / iPad版はApp Storeで$2.99の買い切り、Mac（Appleシリコン・Intel）、Windows、Android、Linux版は無料です。インストールとシステムの許可設定はダウンロードページの説明をご確認ください。他のプラットフォームのインストーラーは、当サイトの/dl/shadowrocket/から入手できます。iPhone / iPad版の購入済みアプリの復元とシステム要件については、ダウンロードページの該当項目をご覧ください。App Storeの購入履歴とサブスクリプションの認証情報は別々に管理してください。

新しい端末での確認が終わったら、自分の端末管理手順に従って、旧端末のサブスクリプション、サーバー、エクスポートファイル、QRコード画像、クリップボードの一時データを整理します。認証情報が漏えいした場合は、情報の管理元が案内する方法で変更してください。ローカルファイルを削除しただけでは、漏えいしたURLや鍵は無効になりません。詳しい移行確認についてはConfigのバックアップと端末移行を参照してください。普段の操作は使い方ガイドに戻り、接続の手順を確認します。