公式マニュアル · Subscribe / SERVER / Config

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

サブスクリプションの初回追加から更新、整理、テスト、移行まで、ボタンの順番ではなく管理作業ごとに確認できます。

このページは、すでに自分のサブスクリプションURLまたはサーバー情報をお持ちの方を対象としています。初めて使う場合は、まずクイックスタートガイドを読み、追加、Global Routingの選択、接続、動作確認の流れに沿って操作してください。項目の意味、更新時の上書き、複数サブスクリプションの管理で困ったときは、このガイドの該当セクションをご覧ください。画面の構成はアプリの更新に伴い変わることがあります。名称や利用できる項目は、端末に表示される内容をご確認ください。

01 / Subscribe

Subscribeから追加する方法と初回インポート

サブスクリプション、サーバー、Configの違い

サブスクリプションはサーバー一覧を繰り返し取得するためのURL、サーバー項目は実際の接続に使うパラメーター、ConfigはルールやDNSなどを設定するものです。連携して使えますが、同じ種類のファイルではありません。サブスクリプションを追加してサーバーが複数表示されても、現在のConfigが置き換わったわけではありません。Configをインポートしてルールが変わっても、サブスクリプションURLが保存されたとは限りません。作業を始める前に、手元の情報がどの種類か確認すれば、ConfigのURLをサーバー欄に入力したり、単体の共有リンクをサブスクリプションと誤認したりするのを防げます。

サブスクリプションURLにはアクセス認証情報が含まれることが多いため、URL全体を機密情報として扱ってください。コピーするときは元のテキストを使い、ページタイトルや説明、引用符、改行を一緒に選択しないようにします。チャットで転送されたURLは途中で切れている場合があります。省略表示を見ても、足りない部分を手入力で補わないでください。完全なURLか判断できない場合は、推測を繰り返さず、元のURLを改めて入手してください。サブスクリプションURLはご利用のサービス提供元から入手するものです。以降の手順では、URLをすでにお持ちであることを前提としています。

Add ServerでSubscribeを選択

Homeを開いて追加メニューに進み、Add ServerのTypeでSubscribeを選択して、完全なURLをURL欄に入力します。サブスクリプションを見分けやすい名前に設定してください。名前は端末内での管理用で、配信元の内容には影響しません。保存後、Homeに該当するサブスクリプショングループとサーバー一覧が表示されるか確認します。グループだけ表示されて選択できる項目がない場合は、取得が完了したかを確認し、返された内容を解析できるか調べてください。同じサブスクリプションを続けて追加して、確認の代わりにしないでください。

初回インポートでは、既存のサーバーと設定を残しておきます。すでに接続できる環境がある場合は、現在選択中の項目とGlobal Routingの状態を記録してから、新しいサブスクリプションを追加してください。保存できたら、新しく追加したサーバーを1つ選んで個別に動作確認します。接続とWebページの表示を確認してから、古い情報を整理しましょう。新しいURLの応答に問題があっても、元の項目に戻せるため、インポート、ルール、端末のネットワークを同時に調べずに済みます。

結果からインポートの問題を切り分ける

保存失敗、取得失敗、一覧が空の場合は、それぞれ別に対処します。保存できない場合は、URL欄に抜けがないか、空白が混じっていないか確認してください。取得に失敗した場合は、端末のネットワークとURLの有効性を確認します。取得が完了しても項目がない場合は、サーバーから返された内容の形式を確認してください。ブラウザーで説明ページが表示されても、それがクライアント用のサブスクリプションURLとは限りません。ログインページやエラー説明が表示される場合は、URLの用途を確認し、ページ本文をURL欄に貼り付けないでください。

項目数だけでインポートの成否を判断しないでください。サブスクリプションには、プロトコルや用途が異なる項目、名前が似ている項目が含まれることがあります。一部の項目は、未対応のパラメーターが原因で使えない場合もあります。まず名前、プロトコル、サーバーアドレス、ポートが手元の情報と一致するか確認してから、実際に接続してください。すべての項目で同じエラーが出る場合は、共通の配信元やインポート形式を確認します。1項目だけ失敗する場合は、その項目のパラメーターとサーバー側の状態を調べてください。

サブスクリプションのインポートが成功しただけでは、アカウントの状態、サーバー側の稼働状況、実際のアクセスまで確認できたことにはなりません。「URLから取得できる」「項目を解析できる」「サーバーに接続できる」「目的のWebサイトにアクセスできる」を分けて確認してください。サービス提供元に問い合わせる際は、この4段階に沿って状況を伝え、URL内の認証情報は隠すと、問題の特定に役立ちます。「サブスクリプションが使えない」とだけ伝えるより、原因を絞り込みやすくなります。

02 / Add Server

Add Serverの手入力項目とプロトコルの確認

Typeを決めてから共通項目を入力する

手動追加は、完全なサーバーパラメーターをすでに持っている場合、特定項目を確認したい場合、独立したテスト用コピーを作る場合に適しています。Add Serverを開いたら、最初にTypeを選択し、サーバーアドレス、ポート、認証情報を入力してください。後続の項目はプロトコルによって意味が異なるため、あるプロトコルの項目を入力してから、気軽にTypeを切り替えないでください。切り替えた後は、認証方式、トランスポート、TLS設定を含め、すべての項目を確認します。以前の入力値が残っていると、新しい項目の設定を誤る原因になります。

サーバーアドレスにはホスト名またはIPアドレスを入力し、Webページのパスやクエリパラメーターは含めません。ポート欄には該当する数値だけを入力し、コロンやプロトコルの接頭辞は付けないでください。名前は項目の識別に使うもので、認証には使われません。名前にプロトコルやトランスポート方式を書いても、その機能が自動で有効になるわけではありません。手元の情報に名前、アドレス、ポートしかなく、選択したプロトコルで必要な認証項目が不足している場合は、別のサーバーのパスワードを流用せず、元のパラメーターを確認してください。

プロトコルの項目は入れ替え可能なメモではない

Type確認する項目よくある混同
Shadowsocks暗号化方式、パスワード暗号化方式はサーバー側の設定と一致させる
VMess / VLESSUUID、トランスポート設定、TLSUUIDだけから他の項目を推測しない
Trojanパスワード、TLS、サーバー名接続先のアドレスとTLSサーバー名は異なる場合がある
HTTP / SOCKS5認証要件、ユーザー名、パスワード認証を有効にするかはサーバー側の要件による
WireGuard鍵、アドレス、Peer、ルーティングパラメーター通常のパスワードを入力する接続方式ではない
Hysteria2認証、TLS、サーバー指定のパラメーター他のプロトコルのトランスポート設定を流用しない

Shadowsocksでは暗号化方式とパスワードの両方が認証に関わるため、片方だけ変更しても接続できない場合があります。VMessとVLESSはどちらもUUIDを使うことがありますが、同じプロトコルではありません。名前の置き換えだけで変換することはできません。Trojanの認証情報も、他のプロトコルの項目から推測できません。サービス提供元が案内する完全なパラメーターを使い、項目が記載されていない場合はデフォルト要件を確認してください。インターネット上の別の設定例をもとに、見た目だけ整った設定を補わないでください。

TLSを有効にする場合は、「どこに接続するか」と「どの名前を検証するか」を区別してください。接続アドレスは接続先を特定し、サーバー名はTLSハンドシェイクや証明書の検証に使われます。両者は一致することも、環境に応じて別々に設定することもあります。証明書エラーが出た場合は、名前、端末の時刻、サーバー側の証明書の状態を確認してください。検証を無効にする方法を一般的な解決策として使わないでください。Hostやパスなどトランスポートの項目も、1つずつ元の情報と照合します。大文字・小文字、スラッシュ、エンコードの違いが結果に影響する場合があります。

保存後の確認と変更の範囲

保存後に項目をもう一度開き、Type、アドレス、ポート、認証、トランスポートの設定がすべて保持されているか確認してからテストします。変更は一度に1種類に絞り、変更前の状態を記録してください。たとえば、まずポートを修正してテストし、その後にTLSを確認します。すべての項目を同時に置き換えると、接続が回復しても原因を特定できず、次回同じ問題が起きたときに最初から調べ直すことになります。

サブスクリプションから作成された項目と手動で追加した項目では、管理方法が異なります。サブスクリプションの項目名やパラメーターを直接変更すると、次回の更新で新しい内容に上書きされる場合があります。ローカルの変更を維持したい場合は、画面上で可能であれば独立したコピーを作成し、手動管理であることが分かるようにしてください。コピーはサブスクリプションに連動して更新されません。配信元がパラメーターを変更した場合は、自分で確認する必要があります。名前やバックアップの記録にも、この管理上の違いを明記してください。

WireGuardなど、関連する項目が複数あるプロトコルは、完全な情報がない状態で一般的な設定例を組み合わせないでください。鍵や認証情報を、トラブル時のスクリーンショット、公開メモ、共有名に含めないようにします。項目について相談するときは、項目名、入力の有無、エラーの内容だけを伝えてください。元の値を照合する必要がある場合は、サービス提供元との既存の信頼できる連絡手段を使い、接続情報全体を公開ページに投稿しないでください。

03 / Scan QR Code

QRコードとクリップボードから追加するときの確認手順

QRコードはテキストを別の形で記録したもの

Scan QR CodeはQRコードに記録されたテキストを読み取る機能で、内容が用途に適しているかを自動判定するものではありません。QRコードには、単体のサーバー共有リンク、サブスクリプションURL、通常のWebページのURLが含まれている場合があります。読み取る前に、自分が利用しているサーバー情報に由来するものか確認してください。読み取り後は、サーバー編集画面、サブスクリプション編集画面、その他の案内のどれが表示されたかを確認します。QRコードを読み取れたからといって、接続に必要な情報がすべて含まれているとは限りません。

カメラで読み取る場合は、システムの案内に従って必要な権限を許可し、QRコード全体が画面に収まるようにします。端が切れたり、強く反射したり、画面がちらついたりしないようにしてください。まず距離とピントを調整し、設定を何度も切り替えないでください。画像から読み取る場合は、元の鮮明な画像を使います。チャットアプリで圧縮された小さな画像では、情報量の多いコードを認識できないことがあります。画像が表示できても、読み取りに必要な細部まで鮮明とは限りません。

読み取り後も保存内容を確認する

QRコードの読み取り後、Type、サーバーアドレス、ポート、名前が適切か確認して保存し、Homeに項目が表示されることを確認してください。QRコードがサブスクリプションを表す場合は、同名のサーバー項目が1つ作成されただけではなく、該当するグループが追加されたかを確認します。QRコード自体は更新されません。更新できるのは、中に保存されたサブスクリプションURLです。固定のサーバーパラメーターを含むQRコードは、サーバー側の変更があっても自動では更新されません。

同じQRコードを繰り返し読み取ると、項目が重複する場合があります。読み取り後すぐに結果が見つからない場合は、一覧に戻り、該当するグループを展開して並び順を確認してから再試行してください。「新しい項目が一覧の先頭にない」ことだけで保存失敗と判断しないでください。同じ名前のサーバーがすでにある場合は、アドレス、ポート、プロトコルも照合します。同名の項目が重複している場合もあれば、別の項目の場合もあるため、パラメーターを確認してください。

クリップボードから追加するときは元の形式を保つ

手元の資料から共有リンクをコピーしたら、クライアントに戻り、実際の画面に表示されるクリップボードからのインポート方法を使います。システムからペーストの許可を求められた場合は、今回の操作に応じて選択してください。内容を認識できない場合は、Webページに表示されたタイトルや短縮表示ではなく、完全なリンクをコピーしたか確認します。認証情報を含むリンクの途中に空白を入れたり、見やすくするために改行したりしないでください。

複数のリンクをまとめてコピーする場合は、元の行区切りを保ちます。番号、箇条書き、日本語の説明、コードブロックまで一緒にコピーされると、一部を認識できないことがあります。まず1件だけインポートして形式を確認し、その後、画面が対応する方法で残りを処理するのが確実です。一部だけインポートできた場合は、成功した範囲と失敗した範囲を記録し、成功した項目が重複しないよう、テキスト全体を何度も読み込まないでください。

QRコードの読み取り失敗とインポート失敗では、確認する点が異なります。前者は権限、画像の鮮明さ、コードの欠けを確認し、後者は読み取ったテキストの種類とパラメーターの不足を確認します。同じリンクをコピーすればインポートできるのに、QRコードでは読み取れない場合は、画像の品質に問題がある可能性が高いでしょう。どちらの方法でも解析できない場合は、元の資料に戻ってリンク形式を確認してください。読み取り方法を変えても、リンクから欠けた文字は補えません。

認証情報が複数の媒体に広がらないようにする

QRコードの画像にもクリップボードのテキストにも、認証情報全体が含まれている場合があります。通常の操作説明用スクリーンショットと同じように扱わないでください。操作手順を見せるために、実際のQRコードを公開アルバムや掲示板に載せないでください。インポート後は、機密情報を含まないテキストでクリップボードの内容を置き換え、画像はご自身の情報管理方法に沿って保管してください。ある場所から削除しても、ほかの端末に同期されたコピーまで消えたとは限りません。実際の同期範囲も確認してください。

インポートメニューが見つからない場合は、固定のボタン位置を別の画面のスクリーンショットから推測せず、現在Homeにいるかを確認して端末の追加メニューを探してください。認識できない内容は照合用に元のコピーを保管しますが、エンコードを何度も変更して試さないでください。接続までの流れを初めて確認する場合は、クイックスタートガイドに戻ってください。QRコードは情報を入力する手段にすぎず、その後もサーバーの選択、設定の確認、アクセスの検証が必要です。

04 / URI & Config

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

リンクに含まれる情報を見分ける

サーバー共有リンクは通常、プロトコルを示す文字列から始まり、接続パラメーターをテキストにまとめています。サブスクリプションURLは通常、ネットワーク上でアクセスできるURLで、応答内容にサーバー一覧が含まれています。Configは別の種類の設定情報です。拡張子やWebページのタイトルだけで用途を判断しないでください。元の資料の説明、インポート後に表示される画面、最終的に作成されるデータを合わせて確認します。「どれもリンクだから同じ欄に入れられる」と考えないようにしてください。

一般的な共有形式では、認証情報、ホスト、ポート、トランスポート設定、名前が異なる箇所に記載されています。Base64でエンコードする形式もあれば、URIパラメーターを使う形式もあります。同じプロトコルでも表記が異なることがあります。エンコードはデータの表現方法であり、認証情報を保護する仕組みではありません。テキスト上ではパスワードが見えなくても、リンク全体を機密情報として保管し、公開例やトラブル時のスクリーンショットに使わないでください。

エンコード、名前、パラメーターを安易に書き換えない

リンク内のパーセントエンコードは特殊文字を表し、クエリパラメーターの区切り記号や等号は構造を示します。チャットアプリで自動的に改行されても、見た目上折り返されているだけの場合があります。一方、手動で改行を加えるとリンクが切れることがあります。見た目が似ている全角記号をURLに使ったり、簡略化のためにクエリパラメーターを削除したりしないでください。備考用の名前は通常表示に使うもので、認証やトランスポートの問題を解決するものではありません。

コピーしたリンクをインポートできない場合は、まず元のテキストと先頭、末尾、文字数、引用符の有無を照合し、形式が対応しているか確認してください。リンク全体をいったんデコードし、編集してから再エンコードする方法を通常の手順にしないでください。エンコードの層を誤ると、さらに壊れるおそれがあります。項目を確認する必要がある場合は、まず編集画面にインポートして1つずつ確認します。解析自体ができない場合は、サービス提供元に形式と完全性を確認し、認証情報を自分で作り足さないでください。

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

Config内のルールは、どのリクエストにどのポリシーを適用するかを指定します。以下はルールを上から順に照合する構文例で、接続可能なサーバー情報は含みません。使用前に現在の設定内容を確認し、断片だけでファイル全体を上書きしないでください。ルール内のPROXYは、利用可能なサーバーまたはポリシーの選択と組み合わせて動作します。キーワードを記述しただけでは接続先は作成されず、未インポートの認証パラメーターも補われません。

[General]
bypass-system = true
dns-server = system

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

DOMAIN-SUFFIXはドメインのサフィックス、IP-CIDRはIPアドレスの範囲に一致し、GEOIPは該当する地域データを使います。FINALは、それまでのルールに一致しなかったリクエストを処理します。ルールは記載順に評価され、先に一致した結果によって後続ルールの評価が変わります。この例にある地域ルールは構文の説明用です。現在のネットワークやアクセス要件に合うか、実際の設定に照らして判断してください。すべてのユーザーに当てはまる決まった答えとして扱わないでください。

Global Routing主な意味確認する点
Config現在のConfigに基づいてポリシーを適用現在のConfig、ルールの順序、照合結果
Proxyプロキシ経由で通信を処理選択中のサーバーとアプリに設定された例外
Direct直接接続で通信を処理端末自体のネットワーク接続状況

インポート後のアクセス経路が想定と異なる場合は、サブスクリプションが間違っていると判断する前に、Global Routingと現在のConfigを確認してください。サーバー一覧が正しくても、ルールによって接続先がDIRECTになっていることがあります。ルールが正しくても、選択中のサーバーに接続できない場合があります。この2つを分けて確認してください。3つのモードの詳しい違いは、Global RoutingのConfig、Proxy、Directについてをご覧ください。

共有する前に、単体のサーバー、サブスクリプション全体のURL、Configファイルのどれを渡すのか確認してください。それぞれ含まれる権限の範囲と、その後の管理責任が異なります。ルールの一部を送るだけなのに、認証情報全体まで書き出さないでください。ルールだけを含むファイルを、復元に必要な情報がすべてそろったものとして説明しないでください。内容の種類を明記すれば、受け取る側も適切な読み込み方法と、追加で必要な情報を判断できます。

05 / Update

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

更新は再取得であり、項目ごとの修正ではない

サブスクリプションを更新すると、保存済みのURLに再度アクセスし、返された内容に基づいて該当するサーバー一覧を更新します。現在選択中のサーバーだけを確認する操作でも、アプリ自体の更新でもありません。配信元が名前、パラメーター、順序、項目数を変更することがあるため、更新後に一覧が変わる場合があります。アプリの更新はApp Storeで行い、サブスクリプション一覧の更新はクライアント内で行います。目的が異なるため、混同しないでください。

画面に表示されるサブスクリプションの操作メニューから更新する前に、対象が特定のサブスクリプションか、すべてのサブスクリプションか確認してください。配信元を1つずつ調べる場合は、ほかのグループを比較用に残し、対象だけを更新するのがおすすめです。更新時刻、前後で項目が変わったか、エラーの内容を記録します。これらは今回の操作結果を把握するための情報であり、URL全体を公開する必要はありません。更新後は、現在選択中の項目がまだ存在するかも確認してください。

手動更新と自動更新の使い分け

手動更新は、初回インポート後、配信元から変更の案内があったとき、一覧が明らかに古いとき、問題を確認したいときに適しています。自動更新は、安定して使えることを確認済みで、配信元の一覧変更を反映させたいサブスクリプションに向いています。設定できる間隔や項目は、アプリの画面に表示される内容をご確認ください。間隔を短くしても無効なURLは修復されず、配信元へのリクエストが増える可能性があります。明確な変更がないときに、接続維持のため何度も更新する必要はありません。

端末のロック状態、システムのバックグラウンド処理、現在のネットワーク、アプリの動作状況によって、自動更新の実行時刻は変わることがあります。更新間隔を設定しても、毎回その時刻どおりに取得が完了するとは限りません。一覧が変わらない場合は、実際に取得が行われたかを確認してから、配信元が新しい内容を返したかを調べます。必要であればアプリを前面にして手動更新を1回行い、結果を確認してください。自動更新がオンというだけで、更新が完了したと判断しないでください。

リクエスト、応答、解析の段階ごとに確認する

リクエストを完了できない場合は、まず端末のネットワークが正常かを確認し、次にURLが完全で有効かを調べます。既存の接続可能な項目をすぐ削除したり、DNS、Global Routing、サブスクリプションURLを何度も変更したりしないでください。現在の設定を残し、条件を1つずつ変えて結果を記録します。あるネットワークでは失敗し、別のネットワークでは成功する場合は原因を絞る手がかりになりますが、エラー内容も合わせて確認してください。これだけで配信元が無効になったと決めつけないでください。

HTTPステータスエラーが明示された場合は、ステータスと発生時刻を記録してください。認証に関する応答があれば、URL内の認証情報とアカウント権限を確認します。リクエスト頻度が高すぎる場合は、短時間での再試行をやめてください。配信元のサーバーエラーは、該当するサーバー側での確認が必要です。ステータスコードは特定段階の結果を示すもので、端末内のサーバーパラメーターが誤っている証拠とは限りません。問い合わせる際は、クエリパラメーター内の機密情報を隠し、状況が分かる範囲のエラー情報を残してください。

リクエストには成功しても解析に失敗する場合は、応答内容がログインページ、メンテナンス案内、空の応答に変わっていないか確認します。URLを開けても、応答内容がサーバー一覧とは限りません。名前が残ったまま項目が空になっていても、すべてのサーバーが同時に故障したとは限りません。URLの有効期限や利用権限が変わっている場合は、サービス提供元の最新情報と照合してください。古いページ本文をコピーしたり、エンコードを変更したりして形式の問題を回避しないでください。

更新後の確認とローカルでの変更

更新が成功したら、少なくとも選択中の項目、プロトコル、実際のアクセスを1つ確認してください。利用中のサーバーが配信元から削除されていた場合は、代わりの項目を明示的に選択します。元と同じ名前の項目が自動で選ばれるとは限りません。ローカルで名前やパラメーターを変更していた場合は、それらが上書きされたか確認します。長期的に残す変更は、手動管理であることが分かる独立したコピーに保存してください。そのコピーはサブスクリプションに連動して更新されない点に注意が必要です。

一度失敗しただけで、すべてのサブスクリプションをすぐ作り直す必要はありません。既存の利用可能な一覧を残し、適切な間隔をあけて再試行し、サービス提供元が案内する状況を確認してください。サブスクリプションの取得に失敗しても、既存サーバーには接続できる場合、それぞれの結果を分けて記録します。一覧の更新に成功しても接続できない場合は、接続テストと実際の接続確認に進んでください。取得と利用を分けて説明すれば、誤った段階で同じ操作を繰り返さずに済みます。

06 / Groups

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

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

複数のサブスクリプションを管理するときは、一覧を短くすることよりも、「このサーバーを更新するのはどのサブスクリプションか」を分かるようにすることが大切です。各サブスクリプションを別のグループに保ち、用途や資料に基づく名前を付けます。アクセス認証情報を名前に含めないでください。手動追加した項目と、サブスクリプションから生成された項目も区別できるようにします。そうすれば、パラメーター変更時に特定のサブスクリプションだけを更新するか、個別の項目を編集するかを正確に選べます。

日常用、一時確認用、手動コピーなど、変わりにくい情報を名前に使いましょう。ネットワーク状況で変化するテスト値を、長期間使う名前に含めないでください。更新時に配信元のサーバー名へ戻る場合があります。ローカルの説明を残したい場合は、画面が対応していれば備考機能を使うか、自分の管理記録に記載してください。サブスクリプション内の手動並べ替えだけを用途の識別方法にしないでください。

名前だけで重複と判断しない

同じ名前でも、アドレス、ポート、認証、トランスポート設定が異なる場合があります。名前が違っていても、実際には同じ接続パラメーターを指している場合があります。整理する前にType、アドレス、ポート、認証方式、TLS、トランスポートの設定を照合してください。同じホストに接続する項目でも、認証情報が違えば権限が異なる場合があります。アドレスが同じだからといって、一方を削除してよいとは限りません。

重複が生じる主な原因には、QRコードの繰り返し読み取り、同じ共有リンクの複数回貼り付け、同じサブスクリプションの重複追加、テスト用の手動コピーがあります。まず、インポート操作が原因か、配信元の一覧に含まれているのかを見分けてください。端末上で何度も追加して生じた重複は整理できます。一方、配信元の一覧に似た項目が含まれている場合、次回更新で再び表示されることがあります。その場合、1つずつ削除しても継続的な解決にはなりません。

並べ替えは現在の作業に合わせる

整理するときは、まずグループを分けたままにして、その範囲内で名前やテスト結果を確認します。遅延順は今回の比較に、名前順は特定項目の検索に、手動順は小規模な一覧の管理に適しています。並べ替えた後は、選択中の項目を確認してください。「一覧の先頭」という位置だけを覚えておかないようにします。配信元の更新や絞り込み条件の変更により、同じ位置が別のサーバーになることがあります。

項目が多い場合は、まず現在使用中のサブスクリプションだけを確認し、ほかのグループはそのままにしておきます。1つのグループの命名、照合、動作確認を終えてから次に進めば、一括整理で手がかりが同時に変わるのを防げます。画面が検索やグループの折りたたみに対応していれば、表示範囲を絞るために使ってください。これらは通常表示を変える操作で、削除とは異なります。内容を削除する前に、対象範囲を確認してください。

ローカルの管理記録は必要最小限に

サブスクリプションの表示名、自動更新の有無、手動コピーの有無、最後に実際の内容を確認した結果を記録しておくと便利です。記録に認証情報全体を重ねて保存する必要はありません。元の情報をどこで確認できるか分かれば十分です。元のURLを保存する必要がある場合は、自分で管理できる保護された場所に保管し、通常の操作記録とは分けてください。名前、更新日時、テスト値は、復元に必要な元の情報の代わりにはなりません。

整理する前に、Configがサーバー名やポリシーグループを使って対象を参照しているか確認してください。削除や名前の変更により、既存の参照が想定どおり機能しなくなる場合があります。特に、手動で管理しているポリシー選択に注意してください。サブスクリプショングループとConfig内のポリシーグループは別のものです。前者は情報の入手元を管理し、後者は接続ポリシーを決めます。サーバーをサブスクリプショングループに追加しても、自動でルールの接続先になるわけではありません。現在の設定を確認してください。

複数項目を削除する前に、復元できる情報を確保し、重複と確認済みの項目を少数選んで試してください。Homeに戻って残りの項目と選択中の項目を確認してから、整理範囲を広げるか決めます。操作が単体項目とグループ全体のどちらに影響するか画面で確認できない場合は、いったんキャンセルしてください。整理の目的は曖昧さを減らすことであり、すべてのサブスクリプションを出所不明の長いサーバー一覧に統合することではありません。

複数のサブスクリプションを整理する具体的な手順は、複数サブスクリプションのグループ分け、並べ替え、重複項目の整理をご覧ください。整理後は、日常利用の経路を1つ明確にし、元の資料を確認できる記録を残しておくと、固定の一覧位置に頼るより、更新や端末移行後の復元に役立ちます。

07 / Connectivity Test

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

まず何を測るテストか確認する

Connectivity Testでは、選択したテスト方式での応答を確認できます。テスト方式によって対象となる段階が異なります。主にサーバーまでの接続を測るものもあれば、指定したテスト先へのリクエストまで確認するものもあります。結果は現在の設定を踏まえて解釈してください。1つの数値を、すべてのWebサイトの表示速度と同じものとして扱わないでください。テスト先、端末のネットワーク、実施時刻が異なる結果を、そのまま比較することもできません。

テスト前に端末自体が正常にネットワークへ接続できることを確認し、現在の接続モードと選択中のサーバーを確認してください。複数のサーバーを比較する場合は、できるだけ同じネットワーク、テスト方式、テスト先を使い、近い時刻に実施します。ネットワークを切り替えながら数値を比較したり、Wi-Fiでの結果と別のネットワークでの結果を同じ一覧に混ぜて安定性を判断したりしないでください。条件をそろえるほど、比較の意味が明確になります。

数値、タイムアウト、変動から分かること

数値が小さい場合、そのテストでは応答が速かったことを示しますが、大容量の転送、長時間の接続、特定のアプリで優れているとは限りません。タイムアウトは、今回の条件と待ち時間の範囲内でテストが完了しなかったことを示します。サーバー、テスト先、名前解決、ネットワーク経路などが原因となる可能性があります。一部の項目だけ失敗した場合は、成功した項目と比較して原因を調べます。すべて失敗した場合は共通の条件を先に確認し、すべてのサーバーパラメーターをすぐに再入力しないでください。

一度だけの異常値は再テストしますが、短い間隔で何度もテストする必要はありません。一時的なネットワークの混雑、端末の接続切り替え、サーバー側の負荷などにより、結果が変動することがあります。条件が安定した後に再テストし、結果が継続して同じか確認してください。日常利用では、1回だけの最小値より、実際のリクエストが安定して完了するかのほうが参考になります。テスト結果は選択の材料の1つであり、ほかの項目を自動的に除外する唯一の基準ではありません。

実際のアクセスを段階ごとに確認する

サーバーを選んで接続スイッチをオンにし、システムの案内に従ってVPN構成を許可してから、使い慣れた一般的なWebページやアプリで動作を確認します。システムに接続中と表示されても、端末上で該当する接続状態が成立したことを示すにすぎません。サーバー側の認証、ルールの適用、接続先からの応答まですべて正常とは限りません。クライアントの接続状態、エラー表示、実際のリクエスト結果をそれぞれ確認してください。スイッチがオンのままであることだけを、接続が完全に使える証拠としないでください。

Global RoutingがConfigの場合、テスト先がルールによってDIRECTで接続されることがあります。そのため、Webページが開けても、選択したサーバーを経由した証明にはなりません。現在のConfigにある関連ルールと接続記録を確認し、テスト先に適用されたポリシーを確かめてください。比較のため一時的にモードを変更する場合は、元の値を記録し、テスト後に戻します。問題を調べるために一時変更した設定を、そのままにしないでください。

接続テストが正常でもWebページを開けない場合は、ドメインの名前解決、サーバー認証、ルールの経路、接続先からの応答を切り分けます。同じサーバーで別の一般的な接続先を試し、端末のネットワークと照らし合わせて、範囲を少しずつ絞ってください。DNSの問題は名前解決設定を確認し、サブスクリプションを繰り返し更新して対処しないでください。詳しくは接続テストは正常なのにWebページが開かない場合のDNS確認をご覧ください。サブスクリプションの再作成やConfigの上書きを同時に行わないようにしましょう。

並べ替え後も選択中の項目を確認する

テスト結果による並べ替えで変わるのは表示順であり、実際に使用するサーバーとは限りません。並べ替え後は、選択中のマークがどの項目に付いているか確認してから接続してください。サブスクリプションの更新、グループの切り替え、再テストによって項目の位置が変わることがあります。「先頭」や「3番目」だけで固定のサーバーを示さないでください。問題を記録するときは、位置ではなく機密情報を除いた名前やTypeを使うと、状況を再現しやすくなります。

特定のアプリだけ失敗する場合は、サブスクリプション全体の問題と決めつけず、そのアプリに関係するルール、ドメイン、接続記録を確認してください。特定のサーバーだけ失敗する場合は、その項目のパラメーターとサーバー側の状態を調べます。比較テストでは条件を一度に1つだけ変え、時刻、テスト方式、エラーの種類、結果を記録してください。こうした記録は、継続的な障害と一時的な変動を見分けるのに役立ち、確認済みの設定を繰り返し変更することも防げます。

08 / Backup & Restore

削除、バックアップ、新しい端末での復元手順

削除する項目と影響範囲を確認する

単体のサーバー、サブスクリプショングループ、Configの削除は、それぞれ異なる操作です。サブスクリプション内のサーバー項目を削除しても、次回の更新で再び表示されることがあります。サブスクリプションを削除すると、一覧を再取得するためのURLが端末から失われる場合があります。Configを削除すると、ルールや関連設定に影響します。実行前に確認画面を読み、対象と範囲を把握してください。接続問題への最初の対処として一覧を消去したり、元の情報がないまま複数項目を削除したりしないでください。

クライアントからサブスクリプションを削除しても、通常は端末内の保存内容が変わるだけで、サーバー側のアクセス権が取り消されるわけではありません。実際のURLや認証情報が漏えいした場合は、サービス提供元が用意する管理方法で該当する情報を失効または変更し、端末側の記録も更新してください。QRコードの画像、サーバー項目、書き出したファイルを1つ削除しただけでは、すでに第三者が取得した認証情報は無効になりません。漏えいへの対処と一覧の整理は分けて行ってください。

種類の異なるデータを分けてバックアップする

復元用の情報は、サブスクリプションの元のURL、手動サーバーのパラメーター、現在のConfigに分けて管理してください。サブスクリプションからは、その時点で配信元が提供する一覧を再取得できますが、以前手動で変更した名前やパラメーターまで復元できるとは限りません。Configにルールを保存できても、サーバーやサブスクリプションの情報がすべて含まれるとは限りません。データを書き出したら、ファイル名だけで完全なバックアップと判断せず、実際に何が含まれているか確認してください。

アプリに用意された書き出しや共有機能で情報を保存する場合は、保存先とアクセス権限を確認してください。認証情報を含む書き出しファイルは、自分で管理できる保護された場所に置き、通常の添付ファイルとしてチャットに長期間残さないでください。バックアップ名には端末名や用途を記録し、パスワード全体は含めないようにします。保存後にファイルを開けることと、内容の種類が正しいことを確認し、復元手順も一緒に保管してください。判別できないファイルだけが残るのを防げます。

新しい端末では、まずアプリを入手してから情報を復元する

新しいiPhoneまたはiPadで、まずApp StoreからShadowrocketを入手してください。購入済みアプリ、Apple Account、購入対象範囲の確認については、購入済みアプリの復元ガイドをご覧ください。システム要件はApp Storeの製品ページをご確認ください。購入済みアプリの復元で処理できるのはアプリの入手であり、端末内のサーバーパラメーターすべてが自動で戻るわけではありません。アプリを開けることを確認したら、手元のバックアップに基づいてサブスクリプション、手動項目、Configを復元してください。すべてが一度に戻ると思い込まないようにしましょう。

アプリにiCloud関連の同期機能がある場合は、両方の端末で実際の同期対象と完了状態を確認してください。システムアカウントにサインインしているだけでは、アプリのすべてのデータが同期されたとは限りません。Configが表示されても、手動サーバーがすべて復元されたとは判断できません。新しい端末での確認が終わるまで古い端末を残し、情報の出所と内容が一致することを確かめる前に、手動インポートと同期の再実行を繰り返さないでください。重複や判別しにくいコピーが生じる可能性があります。

新しい端末では、まず既存のサブスクリプションを復元して一覧を取得し、次に個別管理が必要な手動項目を復元します。その後Configをインポートして選択し、最後にGlobal Routingを確認してください。Configが特定の名前やポリシーグループを参照している場合は、該当項目が実際に存在するか照合します。接続を確立したら一般的なサイトへのアクセスを確認し、重要なアプリに適用されるルールも確認してください。復元の完了は、一覧が以前と似ていることではなく、使える状態で元の設定どおりに動くことです。

動作確認を終えてから古い情報を整理する

端末移行後は、新しい端末の動作確認が完了するまで、古い端末と元のバックアップを比較用に残してください。新しい端末でサブスクリプションを更新でき、手動項目を使え、Configが正しく適用されることを確認してから、古い情報の扱いを決めます。古い端末も使い続ける場合は、削除前に同期削除の影響を確認してください。一方の端末で行った整理が、ほかの端末にも反映される場合があります。移行中にすべての名前、ルール、サブスクリプションURLを一度に変更すると、差異の原因を特定しにくくなります。

特にサブスクリプションURLの変更、認証情報の手動修正、Configの変更後は、バックアップが現在の設定と対応しているか定期的に確認してください。テストのたびに重複したコピーを大量に残す必要はありませんが、明確に復元できる基準のバックアップと、必要な変更記録は保管しましょう。古い認証情報が無効になった場合は、関連するバックアップも整理対象です。次回の復元時に古いパラメーターを誤って使い、過去の問題を端末に持ち込まないようにしてください。

端末移行の詳しい手順は、新しい端末へのConfig移行と復元をご覧ください。接続手順を最初から確認する場合は、クイックスタートガイドに戻ってください。購入先を再確認する場合は、正規品を確認する3つのポイントをご覧ください。管理手順の最後には、情報の入手元、更新対象、実際の動作を確認し、復元できる個人用バックアップを保管してください。