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

Subscribe：サブスクリプションの保存と初回読み込み

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

サブスクリプションはサーバーリストを取得するための更新用URLで、個別サーバーのアドレスやConfig内のルールファイルとは異なります。操作を始める前に、保存した情報がサブスクリプションURL、単独の共有リンク、個別のサーバーパラメーターのどれに当たるか確認してください。https://で始まる文字列は、サブスクリプションの場合もあれば、説明用のWebページの場合もあります。接頭辞だけで用途を判断せず、情報に添えられた説明を確認してください。サブスクリプションURLにはアカウントを識別するパラメーターが含まれることがあります。コピー時はパスとクエリ文字列を含めてすべて保持し、公開の掲示板などには貼り付けないでください。

Homeの追加メニューからSubscribeを探します。画面によっては、先にAdd Serverを開き、TypeでSubscribeを選択します。選択したら、手元のサブスクリプションURLをURL欄に省略せず貼り付け、見分けやすい名前を付けて保存してください。この名前は参照元を識別するためのもので、リモート側のサーバー名、認証情報、更新権限は変わりません。初回読み込み時に追加オプションが表示された場合、用途を把握しているものを除き、まず初期値のままにしてください。URL末尾のパラメーターを、見た目を整えるために変更しないでください。

URLの保存とリストの取得を分けて確認する

保存が完了しただけでは、サブスクリプションがローカルに登録されたことしか分かりません。利用可能なリストを取得できたとは限りません。保存後、Homeにそのサブスクリプションに属するサーバーが表示されるか確認してください。自動取得されない場合は、該当項目の更新操作を実行します。結果は、サブスクリプション項目が残っているか、更新時にエラーが表示されたか、サーバーがリストに現れたかの順に確認しましょう。名前が表示されてもリストが空の場合、URLの保存は成功していても、ネットワークリクエスト、アカウント権限、応答内容に問題が残っている可能性があります。同じサブスクリプションを追加し直しても項目が重複するだけで、元のリクエストの問題は解決しません。

初回読み込みでは、コピー時の誤りもよくある原因です。URLの前後の空白、チャットアプリが挿入した改行、全角の句読点、画面に見えている部分だけの選択などにより、リクエスト内容が変わることがあります。コピーし直す際は、表示が途中で切れた文字列を見ながら手入力せず、元のテキストからURL全体を取得してください。URLに&、?、パーセントエンコードが含まれていても、不要な記号だと判断して削除しないでください。トラブルの記録には、リクエスト結果と問題が起きた段階だけを残します。スクリーンショットを共有する場合は、サブスクリプションURL全体とアカウント識別情報を隠してください。

リストを読み込んだら接続の基準を確認する

サーバーが表示されたら項目を1つ選び、Global Routingと現在のConfigを確認します。サーバーリストは「接続先」を、ルール設定は「どのトラフィックにその接続を使うか」を決めるため、それぞれ個別に確認が必要です。初回の検証では、確認済みのサーバー項目を1つ選び、使用するConfigも明確にして、複数の設定を同時に変更しないでください。Subscribeの更新に成功してもWebページを開けない場合、すぐにURLの誤りと判断せず、サーバー接続とルールを確認します。反対に、更新に失敗しても既存サーバーには接続できるなら、更新先が一時的に到達不能なだけかもしれません。

サブスクリプションを読み込んでも、すべての項目が現在のネットワークに適しているとは限らず、各項目のパラメーターが同じとも限りません。まずリストを取得し、次に接続をテストしてから、自動更新を有効にするか判断してください。これにより、「サブスクリプションのリクエスト失敗」「サーバーのハンドシェイク失敗」「ルールの不一致」を別々の問題として切り分けられます。初回接続がまだ完了していない場合は使い方ガイドに戻って順に確認してください。接続できていてGlobal Routingを調整したい場合は設定ガイドを参照し、ルールの問題を再読み込みで解決しようとしないでください。

Add Server：サーバー情報を手動入力

Typeを選び、アドレスと認証情報を入力する

Add Serverではサーバー項目を1つ作成できます。画面を開いたら、まずTypeを選び、選択したプロトコルに必要な項目を入力します。同じ名前の項目でも、プロトコルによって意味が異なる場合があります。別の項目を参考にすべて入力してからTypeだけを変更しないでください。Addressには通常、ホスト名またはIPアドレスを入力し、Webページのパスは含めません。Portには該当ポートを入力し、アドレスとポートをまとめてAddress欄に入れないでください。名前は見分けやすいものにできますが、接続パラメーターは既存情報どおりに保持してください。英字の大文字・小文字、区切り記号、特殊文字も同様です。

認証項目はプロトコルと合わせて確認してください。ShadowsocksではMethodとPasswordを正しく組み合わせます。VMessとVLESSではUUIDがよく使われます。TrojanのPasswordは、別の識別子に似て見えてもUUID欄に入力しないでください。WireGuardでは鍵、アドレス、ピアのパラメーターが必要となるため、サーバーのドメイン名だけでは設定できません。必要な情報が足りない場合は、既存のサーバー情報を確認してください。プロトコルでよく使われる初期値を代わりに入力しないでください。画面上で項目が空欄でも、そのサーバーで省略できるとは限りません。

接続先アドレス、TLS、転送パラメーターを区別する

TLSのサーバー名、転送層のHost、実際に接続するAddressは、同じ場合も異なる場合もあります。それぞれ異なる段階で使われます。Addressは接続先の特定に、SNIはTLSハンドシェイクに、HostとPathはアプリケーション層の転送に使われる場合があります。いずれもドメイン名を入力できるからといって、1つにまとめないでください。Pathのスラッシュ、末尾の文字、大文字・小文字もサーバー側のルーティングに影響する場合があります。情報が共有リンク1つだけの場合は、次の章の方法で読み込んでから解析された項目を確認してください。リンクの見た目からパラメーターを推測するより確実です。

証明書やハンドシェイクのエラーが発生した場合は、まずシステム時刻、SNI、TLSの設定、サーバーポートを確認し、次に元の情報が変更されていないか確認してください。証明書検証のスキップを通常の修正方法として使わないでください。本人確認の条件が変わるため、一時的に接続できても入力ミスが解決したとは限りません。転送方式もサーバー側と一致させる必要があります。TLSを有効にしても、誤ったHost、Path、Typeは修正されません。影響を特定できるよう、確認済みの誤りを一度に1項目だけ直し、変更前の内容を記録してください。

保存後にサーバーを個別に確認する

保存したらHomeに戻り、リストにある同名の古い項目ではなく、作成したばかりのサーバーが選択されていることを確認します。次に接続をテストし、結果を名前解決の失敗、接続確立の失敗、認証失敗、接続後のアクセス異常に分けて記録します。エラーごとに確認する項目は異なります。ドメインを解決できない場合はAddress、接続がタイムアウトする場合はポートとネットワークへの到達性、認証に失敗する場合はPasswordまたはUUIDを確認します。接続後に一部のアクセスだけ失敗する場合は、Config、DNS、接続先サービスを確認してください。失敗結果が1つ出ただけで、すべてのパラメーターを書き直す必要はありません。

手動で追加した項目は、通常、サブスクリプションの更新では同期されません。リモート側のPasswordやアドレスが変更された場合は、元の情報を使って手動で更新するか、手元にあるサブスクリプションURLから再読み込みしてください。名前には「手動」「サブスクリプション」などを付けて区別すると便利ですが、Password、UUID、秘密鍵は書かないでください。リストのスクリーンショットに表示されるおそれがあります。VMessとVLESSの違いはプロトコルの項目解説を参照してください。目的は正確に入力することであり、プロトコル名からサーバーの実際の利用可否を推測することではありません。

QRコード・クリップボード：読み込む内容を確認する

Scan QR Codeは内容を読み取るための入口

QRコードはテキストを伝える手段であり、新しいプロキシプロトコルではありません。Scan QR Codeで読み取る内容は、個別サーバーの共有リンク、サブスクリプションURL、あるいは通常のWebページのURLかもしれません。スキャンする前に、QRコードが手元のサーバー情報に由来することを確認し、サーバーを1つ追加したいのか、更新可能なサブスクリプションを追加したいのかを明確にしてください。スキャン後に確認画面が表示されたら、Type、Address、URLなどの項目を確認してから保存します。カメラで読み取れたからといって、Shadowrocketに直接読み込める内容だとは限りません。

初めてスキャン機能を使うとき、システムからカメラへのアクセス許可を求められる場合があります。許可しないとカメラで読み取れませんが、QRコード自体が壊れているわけではありません。必要に応じてシステム設定から権限を変更できます。QRコードが同じ端末の画面上にある場合は、現在の読み込み画面で写真からの読み込みに対応しているか確認してください。その項目がなければ、同じ情報に含まれるテキストリンクを使うほうが簡単です。読み取りの問題を解決するために、サブスクリプションの認証情報を含む画像を不明な読み取りサイトへアップロードしないでください。QRコードのスクリーンショットからもURLや認証情報を復元できるため、機密情報として扱ってください。

クリップボードから読み込む前に余分な文字を取り除く

クリップボードから読み込むときは、「こちらをクリック」「サーバー情報」などの説明文を含めず、リンク部分だけをコピーしてください。チャットのリンクには末尾の句点、括弧、改行が含まれることがあります。アプリに短縮表示されたリンクを長押ししてコピーすると、実際には説明ページのURLが取得される場合もあります。読み込みに反応がない場合は、まずコピーした文字列の先頭が想定した形式と一致しているか確認し、余分な文字が混ざっていないか調べてください。システムがペーストの許可を求めた場合は、自分の操作に応じて許可します。拒否後に再試行するときも、システムの権限状態を確認してください。

複数行のテキストが、一度に複数のサーバーとして認識されるとは限りません。読み込み結果が1件だけの場合、元のテキストに個別の共有リンクが複数含まれているか、それとも1つの長いリンクが画面上で折り返されているだけか確認してください。まず1件を読み込んで解析が正しいことを確かめてから、残りを処理できます。複数行を自分で1行につなげたり、各行にプロトコルの接頭辞を追加したりしないでください。一括読み込み後は、所属先と名前を1件ずつ確認します。同じテキストを複数回コピーすると重複項目が作成され、テスト時に別々のサーバーだと誤認する原因になります。

「読み取り・解析・保存」に分けてトラブルを切り分ける

スキャンしても内容を取得できない場合は読み取り段階の問題です。画像の鮮明さ、QRコードが完全に写っているか、権限を確認してください。テキストを取得できても形式が非対応と表示される場合は解析段階の問題です。リンクの種類と使用中の入口を確認します。項目は作成されたのに接続できない場合は、パラメーターとサーバーへの到達性を確認してください。3段階に分けることで、パラメーターを確認しないまま読み取り方法を何度も変えるのを防げます。QRコードの端が切れていたり、画像の圧縮で模様がぼやけていたりすると読み取りに影響します。低画質のスクリーンショットを撮り直すより、元画像を拡大するほうが有効です。

読み込み後も項目を確認してください。サーバーの種類、ホスト名、ポート、転送設定が元の情報と一致しているか、想定した場所に項目が表示されているかを確認します。サブスクリプションを読み込むつもりだったのにサーバーが1つだけ追加された場合は、QRコードが個別の共有リンクを含んでいなかったか確認してください。Subscribe項目が作成されてもリストが空の場合は、スキャンを続けず、サブスクリプションの更新を確認します。個別リンクとサブスクリプションURLの違いについては共有リンクとサブスクリプションリンクの解説も参照してください。

同じ情報をQRコードとクリップボードの両方から読み込んだ場合、通常は同じパラメーターになります。結果が異なる場合は、まず元のテキストが一致するか確認し、古いクリップボードの内容が混ざっていないか調べてください。名前だけで項目が同一か判断しないでください。名前は変更できますが、接続を決めるのはプロトコルの項目です。確認待ちの項目を1つ残し、検証後に重複を整理するほうが、現在使える項目をすぐに上書きするより安全です。

共有リンク：接頭辞、エンコード、Configとの違い

接頭辞は形式を見分ける手掛かり。パラメーターの確認は別途必要

ss://、vmess://、vless://、trojan://は、通常、個別サーバーの情報を表します。それぞれ異なる構造でアドレス、認証、転送情報を記述しているため、接頭辞を置き換えるだけでプロトコルを変換することはできません。HTTPまたはHTTPSのURLは、サブスクリプションの内容を指す場合も、通常のWebページを指す場合もあります。元の情報に添えられた説明と実際の応答内容を確認し、クリックできるURLというだけでSubscribeとして保存しないでください。形式によって実装上の取り決めが異なる場合があるため、接頭辞を認識できても、拡張項目がすべて保持されるとは限りません。

Shadowsocksの共有リンクでは、認証情報やより広い範囲の内容がエンコードされていることがあります。VMessではエンコードされたJSON形式、VLESSとTrojanではクエリパラメーターを含むURI形式がよく使われます。一般の利用者が重要視すべきなのは手動でデコードすることではなく、リンク全体をコピーし、対応する入口から読み込み、解析結果を確認することです。自分でデコードして再エンコードすると、特殊文字の変化、パディングの欠落、パーセントエンコードの二重処理につながることがあります。項目を確認する必要がある場合は、端末内で内容を見て手元の情報と比較し、リンク全体を見知らぬオンラインツールに渡さないでください。

名前、クエリパラメーター、エンコード文字にはそれぞれ役割がある

URIのクエリパラメーターには、転送方式、Path、Host、その他の接続設定が含まれることがあります。フラグメント部分は名前として使われることが多いものの、具体的な扱いは形式の仕様に従います。名前に日本語などが含まれる場合、元のリンクでパーセントエンコードされていても、読み込み後に読める文字で表示されるのは正常です。トラブル対応時に、パーセントエンコードされた部分をすべて日本語に置き換えて貼り直したり、パラメーター内の区切り記号を装飾だと判断したりしないでください。文書作成ソフトやチャットアプリを経由したリンクでは、半角引用符が置き換わっていないか、末尾に句読点が付いていないか、1行の内容に実際の改行が挿入されていないかを確認しましょう。

共有リンクには機密情報が含まれる場合があります。画面上では短い名前しか見えなくても、完全なリンクにはPassword、UUID、その他の認証情報が含まれている可能性があります。QRコードや共有機能も、内容を別の形で伝えるだけです。リンクを自分の別端末に送る場合は、送信経路と受信先を確認し、転送後は必要に応じて一時ファイルを削除してください。形式の問題を報告する際は、プロトコルの接頭辞、項目名、エラーメッセージだけを伝え、アドレスと認証情報はサンプル値に置き換えられます。名前の一部を隠しても、実際の接続情報は隠れません。

サーバーリンクとConfigのルールファイルは別物

サーバーを読み込んだ後、Global RoutingでConfigを選択している場合、現在のルールに従ってトラフィックの経路が決まります。以下はマッチ順序を説明するための実際のルール構文で、接続可能なサーバーパラメーターは含まず、サブスクリプションも作成しません。ルールは通常、上から順に照合され、最後のFINALがそれまで一致しなかったトラフィックを処理します。PROXYとDIRECTはポリシーを表す語で、サーバーのドメイン名ではありません。Configを編集する前に、元のファイルを保存し、使用中のポリシー名を確認してください。

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

ルールをSubscribeのURL欄に貼り付けても、サブスクリプションにはなりません。サーバーの共有リンクをルール行として書き込んでも、対応するポリシーは自動作成されません。サーバー、サブスクリプション、ルールを別々に管理することが、トラブル対応で重要な区別です。Config、Proxy、Directが実際のトラフィックに与える影響についてはGlobal Routingの3つのモードの解説を読み、サーバー設定と照らし合わせて確認してください。

更新設定：リクエスト結果とリストの変化

サブスクリプションの更新はアプリの更新でも、利用期間の延長でもない

Subscribeの更新は、保存済みのURLに再度リクエストし、返された内容に応じてサーバーリストを更新する操作です。アプリの更新にはならず、サービスアカウントの有効状態も変わりません。アプリの入手先と更新方法についてはダウンロードガイドを参照してください。サブスクリプションにアクセスできるかどうかは、元のURL、アカウント権限、ネットワーク状態によって異なります。この違いを理解しておけば、更新に失敗したときにアプリの再インストールから始めずに済みます。まずサブスクリプションにリクエストできるか、既存サーバーに接続できるかを記録し、確認する層を決めてください。

更新を習慣にする前に、まず手動で更新し、URLからリストを正常に取得できることを確認します。そのうえで、現在の画面にある設定を見て自動更新するか判断してください。更新頻度は、単に多くすればよいわけではありません。サーバーリストに変化がない場合、頻繁にリクエストしても接続は改善せず、トラブルの切り分けが難しくなることがあります。長期間使用していない場合、情報が変更されたと分かっている場合、現在の項目が広く使えなくなった場合は、まず手動で1回更新します。端末のスリープ、バックグラウンド制限、ネットワーク切り替えが定期実行に影響することもあるため、「自動更新を設定した」からといって、常に厳密な時刻に実行されるとは限りません。

エラーが発生した段階に沿って確認する

リクエストがタイムアウトする場合は、現在のネットワークとサブスクリプションのドメインに到達できるかを確認します。認証エラーやアクセス権限エラーの場合は、URL全体とアカウントの状態を確認してください。応答を解析できない場合は、サーバーリストではなく説明ページ、ログインページ、その他の応答を取得していないか確認します。内容があるかどうかだけで判断しないでください。ブラウザーでWebページが表示されても、Shadowrocketが解析できる形式のサブスクリプションを取得したとは限りません。読み込み後の初回更新でエラーが出た場合は、オプション設定を何度も変更するより、元の情報からURL全体をコピーし直すほうが有効です。

更新リクエストが、既存のプロキシ接続に依存する場合もあります。現在のネットワークからサブスクリプションの接続先にアクセスできず、既存サーバーには接続できる場合、条件を管理したうえで接続前後の結果を比較できます。ただし、すべてのプラットフォームでサブスクリプションのリクエストが同じ経路を通るとは限りません。意味のある比較を行うため、接続の有無、Global Routingのモード、選択中のサーバーを記録してください。複数の設定を何度も切り替えて結果を記録しないと、たまたま復旧しただけなのに無関係な設定が効いたと思い込むおそれがあります。

更新後に所属、件数、選択状態を確認する

更新後にサーバーリストの項目が増減したり、名前が変わったりしても、必ずしもローカルデータの破損とは限りません。返された内容が変更された可能性があります。まず、変化が該当するサブスクリプションのグループ内だけで起きているかを確認し、次に選択中のサーバーがまだ存在するかを確認してください。古い項目が置き換わると、覚えていた名前だけでは同じ接続先を特定できない場合があります。重要な操作の前に、選択中の項目名とプロトコルを記録してもかまいませんが、パラメーター全体は公開しないでください。並び順は更新やソートで変わる可能性があるため、リスト内の位置でサーバーを覚えないようにしましょう。

更新後にリストが空になった場合は、連続して再試行せず、エラーメッセージを保存して既存の接続に影響があるか確認してください。古い内容がどう扱われるかは、読み込みや更新の手順によって異なる場合があります。失敗時にすべての項目が必ず残るとも、空のリストがリモート側にサーバーがないことを示すとも限りません。まずリクエストの応答が有効かを確認し、バックアップからの復元や再読み込みを判断します。ほかのサブスクリプションが正常で1つだけ異常なら、そのサブスクリプションとリクエスト条件に問題を絞り、すべての参照元を同時に削除しないでください。

サブスクリプションから作成された項目を手動で変更する場合は、次回の更新で変更が上書きされる可能性も考慮してください。一時的な修正が必要で、画面が対応している場合は、理由を記録した独立のコピーを作成し、サブスクリプションURLの内容は変更しないでください。元の情報に戻した後は一時的なコピーを削除し、古いパラメーターを正式な設定だと誤認しないようにします。コピーと複数のサブスクリプションの名前の付け方は、次の章の整理手順を参照してください。

複数のサブスクリプションを整理：所属、名前、ルールとの関係

まず参照元ごとに分け、次にグループ内の項目を見分ける

複数のサブスクリプションがある場合、最初に行うのは全サーバーを1か所に並べることではなく、各項目がどのサブスクリプションに属するか追跡できるようにすることです。用途や独自の番号などを使って、各サブスクリプションに短く安定した名前を付けます。サーバー名は更新後に照合しやすいよう、なるべく元の情報を保持してください。2つのサブスクリプションに同名のサーバーがあっても、所属グループと実際のパラメーターを確認し、名前だけで片方を削除しないでください。別の参照元に同じ名前があるからといって、接続先や認証情報が同一とは限りません。

整理するときは、サブスクリプション項目、その配下のサーバー、手動で追加した項目の順に確認できます。更新によって管理されるものと、独立して作成したものを見分けてから、名前の変更や削除を判断してください。名前には用途と管理方法を記し、機密情報は含めないようにします。たとえば「手動テスト」なら項目の種類が分かりますが、Password、UUID、サブスクリプションのパラメーター全体はリストの名前に書かないでください。画面にカスタムグループ機能がない場合は、分かりやすい名前と別途の記録で所属を管理できます。すべてのプラットフォームに同じ整理メニューがあるとは限りません。

表示名ではなくパラメーターで重複を判断する

重複かどうかを判断するには、少なくともプロトコル、アドレス、ポート、認証、転送設定を照合してください。同じドメインに接続する項目でも、ポートや転送方式が異なることがあります。名前が異なっていても、同じ情報を2回読み込んだだけかもしれません。まず重要な項目を比較してから、残す方を決めましょう。サブスクリプションから作成された項目の場合は、サーバー項目だけを削除するより、重複したサブスクリプションの参照元を整理してください。そうしないと、次の更新で同じ項目が再び作成され、毎回手動で削除することになります。

リストを整えるためだけに、古い項目を一度にすべて削除しないでください。重複と確認できた項目に印を付け、現在利用できるサーバーを残したまま、サブスクリプションを1回更新して接続を確認してから整理します。重複かどうか判断できない項目は、すぐに削除せず個別にテストしてください。同じサブスクリプションを2回読み込んだ場合は、URL全体が一致しているか確認し、名前だけが異なるのか判断します。クエリパラメーターによって取得内容が変わる場合があるため、ドメインとパスだけを比べて同じものと決めつけないでください。

サーバーの選択とルールのポリシーは分けて管理する

Homeで選択したサーバーとConfig内のポリシー参照は関係しますが、リストの整理はルールの変更とは別の操作です。Global RoutingがProxyの場合、選択したプロキシを使った接続結果を直接確認しやすくなります。Configの場合、対象トラフィックがルールによってDIRECTになることがあるため、Webページを開けても、今回の接続で選択中のサーバーが使われたとは限りません。整理後に特定のサーバーを検証する場合は、条件を明確にしたテストを行い、終了後は通常のモードに戻してください。トラブル対応用の設定をそのままにしないようにしましょう。

Configで特定のサーバー名やポリシーグループ名を使っている場合は、名前を変更する前に関連箇所を確認し、変更後に検証してください。リスト上で名前を変えても、Config内の文字列参照が自動更新されるとは限りません。項目が多い場合は「サブスクリプション1つ、変更1グループ、検証1回」の順で進めます。1つのグループが終わってから次に進めば、問題が起きた範囲を特定しやすくなります。Configルールの詳しい設定は設定ページを参照してください。リストを整理するためにConfig全体を作り直す必要はありません。

複数の端末を使う場合は、サブスクリプションの名前付けルールをそろえると便利ですが、リストの並び順が同じとは限りません。並び順、テスト結果のキャッシュ、最後に選択した項目は端末ごとに異なる可能性があります。移行後は所属と選択中の項目を改めて確認してください。管理用の簡単なリストには、サブスクリプション名、管理方法、用途だけを記録し、URL全体はアクセスを制限したバックアップに保存します。リストの構成を把握でき、特定の端末で問題が起きたときに復元する範囲も見つけやすくなります。

遅延テストと並べ替え：結果を理解して選ぶ

Connectivity Testで確認できるのは限定的な項目

Connectivity Testは、現在のテスト条件における接続状況を確認する機能です。結果は端末のネットワーク、テスト方法、接続先アドレス、サーバーのハンドシェイク、一時的な負荷などに左右されます。ダウンロード速度と同じものではなく、すべてのアプリでアクセスできることを保証するものでもありません。テスト方法によって測定段階が異なり、接続確立の状態を主に測るものもあれば、実際のリクエストまで含むものもあります。比較する前に、各項目で同じテスト方法を使い、ネットワーク条件も近いことを確認してください。異なる時間やネットワークで得た結果を、そのまま安定した性能の順位として扱わないでください。

テスト前に、普段の利用状況に近いネットワークを選び、大量のデータ転送を一時停止して影響を減らしてください。モバイル通信からWi-Fiに切り替えた直後なら、システムのネットワーク状態が安定してからテストを始めます。一括テストでは短時間に多くの接続が発生します。項目数が多いときはグループごとに実行し、一度に大量の接続を発生させてローカルネットワークやリモート側の応答に影響を与えないようにしてください。初回にタイムアウトした項目をすぐに削除せず、再テストして同じグループ内の項目と比較します。

失敗を個別、グループ全体、全体の3段階に分ける

1つだけ失敗する場合は、その項目のプロトコル、ポート、認証、転送設定を確認します。1つのサブスクリプション内で複数の項目が同時に失敗する場合は、更新の有無、アカウント状態の変化、共通するネットワーク条件を確認してください。すべての項目が失敗する場合は、端末のネットワーク接続、DNS、接続権限、現在のテスト設定を確認します。このように段階を分けるほうが、サーバーを次々に切り替えるより効果的です。テストが失敗しても実際のアクセスは正常な場合、サーバーパラメーターをすべて変更するのではなく、テスト先自体に到達できるかを確認してください。

テストに成功しても実際のアクセスに失敗する場合は、選択したサーバーを経由しているか確認してください。Config内のルールによって対象への直接接続が選ばれていたり、DNSの名前解決に別の問題があったりする可能性があります。現在の設定を記録したうえでProxyとDirectの結果を比較し、その後Configに戻すこともできます。比較の目的は問題の範囲を絞ることで、ルーティングの設定を恒久的に変えることではありません。接続スイッチがオンでも、それは実行状態の一部にすぎません。ハンドシェイクが完了したか、接続先へのリクエストが成功したかは、実際のアクセス結果で確認してください。

並べ替えは状態を確認する手段であり、自動で保守方針を決めるものではない

テスト結果による並べ替えは、詳しく確認する項目を見つけるのに役立ちますが、先頭に表示された項目がすべての用途に適しているとは限りません。遅延が小さいことは、ある段階の応答時間が短いことを示すだけです。長時間のデータ転送では帯域幅、混雑状況、接続先サービスも影響します。選ぶ際は、複数回のテストで安定しているか、実際にアクセスできるか、日常利用でどうかを合わせて判断してください。一度だけの最小値を追いかけないようにしましょう。並べ替えた後は選択状態を確認してください。表示順が変わっただけで、クライアントが先頭の項目に自動切り替えされたとは限りません。

空欄、タイムアウト、失敗といった結果も、固定の数値として単純に扱わないでください。空欄は未テストを示す場合があり、失敗は一時的なネットワーク問題かもしれません。古い結果は別のネットワークで得られた可能性もあります。比較が必要なら同じ条件で再テストし、記録には環境を記載してください。古い結果に長期的な意味を持たせないようにしましょう。サブスクリプション更新後に追加された項目も再テストしてください。見慣れたグループに入っているからといって、以前のテストを通過済みだと考えないでください。

テスト結果を記録するときは、数値を並べるより現象を記録してください。たとえば「同じネットワークで続けてハンドシェイクエラーが発生」「サブスクリプションの更新は成功したが、ある項目がタイムアウト」「Directは正常でProxyは失敗」といった記録は、次の確認箇所を絞るのに役立ちます。公開して問題を報告する際は、アドレス、認証項目、アカウント識別情報を削除し、モード、プロトコル、エラーが起きた段階だけを記載してください。初回接続の確認手順全体が必要な場合は使い方ガイドの検証手順に戻り、サーバー項目を確認しやすい基準状態に戻してください。

削除とバックアップ：復元できる管理状態を保つ

サーバー、サブスクリプション、Configの削除を区別する

削除する前に対象を確認してください。サーバーを1つ削除すると、通常は1組の接続パラメーターが対象になります。サブスクリプション項目を削除すると、以後の更新との関連に影響し、そこから作成された内容も削除される場合があります。Configの削除はルールと関連設定が対象で、サーバーの削除とは異なります。確認画面や関連項目の扱いはプラットフォームによって異なる場合があるため、記憶で操作せず、実際に表示されたメッセージを読んでください。特に複数のサブスクリプションに同名の項目がある場合は、操作前に所属を確認し、利用中の参照元を誤って削除しないようにしましょう。

サブスクリプションから作成されたサーバーは、次回更新時に再び表示されることがあります。そのため「長期的に1項目を削除する」ことと「一時的にリストを短くする」ことは別の目的です。項目を一時的に使わないだけなら、サブスクリプション全体を削除する必要はありません。重複したサブスクリプションを残さないと決めた場合は、もう一方が正常に更新できることを確認してから、重複した参照元を削除してください。手動項目を削除する前には、元のパラメーターを再取得できるか確認します。再読み込みできるサブスクリプションURLがない場合もあります。整理後に接続をテストし、削除済みの項目が選択されたままになっていないか確認してください。

情報の種類ごとにバックアップ項目を確認する

完全に復元するには、リストのスクリーンショットだけでは不十分です。少なくともサブスクリプションURL、手動で追加したサーバーパラメーター、Configファイル、必要なカスタム設定を分けて保存してください。サブスクリプションURLからサーバーリストを再取得できても、ローカルで変更した名前や並び順までは戻らない場合があります。ルールファイルから通信の振り分けを復元できても、すべてのサーバー認証情報が含まれるとは限りません。スクリーンショットは画面の確認には便利ですが、長いPassword、鍵、非表示項目を確実に復元する用途には向きません。各バックアップが何を保存するかを確認してから、移行に十分か判断してください。

現在の画面にエクスポートやバックアップ機能がある場合は、使用前に実際の出力範囲を読み、生成ファイルに機密情報が含まれるか確認してください。ファイル名に「バックアップ」とあるだけで、すべてのデータが保存されたと決めつけないでください。Password、UUID、サブスクリプションのトークン、WireGuardの秘密鍵を含む情報は、アクセス制限があり暗号化して保存できる場所に保管します。公開アルバム、共有ダウンロードフォルダー、他人が読める文書には残さないでください。日常確認用の管理リストと、認証情報を含む完全なバックアップは分けて保存するのがおすすめです。

依存関係の順に復元して段階的に確認する

別の端末へ移行する場合は、まず各プラットフォームに対応した入手先からShadowrocketを入手し、サブスクリプションと手動サーバーを復元します。次にConfigを復元し、最後にGlobal Routing、DNS、オンデマンド接続などの設定を確認します。読み込み後すぐにすべての自動動作を有効にせず、まず確認済みの項目を1つ手動で接続し、続いてルールを検証してください。iPhone / iPadのシステム要件はApp Storeの掲載内容を確認してください。その他のプラットフォームの入手先とインストール時の許可手順はインストールガイドをご覧ください。バックアップの手順中にインストール修復を繰り返す必要はありません。

サブスクリプションを復元したら、改めて更新してください。サーバーを復元したら、接続テストを行います。Configを復元したら、現在の選択状態を確認してください。以前の端末に保存された遅延結果、並び順、最近使った項目は、新しい端末で有効なテスト結果として扱えません。復元後に一部の内容しか表示されない場合は、すべてをアプリの異常と決めつける前に、バックアップの範囲と読み込み形式を確認してください。認証情報がすでに変更されている場合は、現在の情報を優先してください。古いバックアップは過去の状態を確認する手掛かりにはなりますが、今も接続権限があるとは限りません。

サブスクリプションURLや認証情報が意図せず公開された場合、ローカルの項目を削除するだけでは、漏えいした情報は無効になりません。元のアカウント管理方法に従って該当する認証情報を無効化または変更し、クライアントに保存した内容も更新してください。その後、古いバックアップや一時コピーを削除します。日常の管理が終わったら、どのサブスクリプションを処理したか、どの手動項目を残したか、どのモードで検証したかを簡潔に記録します。認証情報は記録に含めないでください。複雑なログでなくても、次回の更新や移行時に現在の状態を把握するのに役立ちます。

このページの管理手順はここまでです。内容を見分けて適切な入口から読み込み、接続を確認します。必要に応じて更新し、所属と名前を整理して混同を防ぎ、復元を確認したバックアップで状態を保管してください。最初から操作する場合はクイックスタートガイドを、ルールが接続に与える影響を確認する場合は設定ガイドを参照してください。個別の共有リンクの形式についてはリンク形式の記事で確認できます。