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

URL・登録情報・サーバーを区別する

サブスクリプションURLはサーバー一覧を取得するためのリモートアドレス、サブスクリプション登録はShadowrocketに保存される取得元と更新設定、サーバー項目は解析後にHomeに表示される接続先です。この3つは別のものです。URLをコピーしただけでは登録されず、登録しても有効なサーバーを取得できたとは限りません。問題の切り分けでは、まずどの段階で起きているかを確認し、取得失敗をすべてのサーバーの障害と混同しないようにしましょう。

サブスクリプションにはアクセス情報が含まれていることがあります。一見すると通常のHTTPSリンクでも、所持者がサーバー情報を取得できる場合があります。操作前に、信頼できるローカル環境へ元のURLを保存し、ご自身がすでにお持ちのサブスクリプション情報であることを確認してください。URL全体を公開コメント、検索欄、スクリーンショットに載せないでください。例にあるexample.comは構造の説明用で、接続には使えません。実際にアクセスする必要もありません。

Add ServerからSubscribeを選ぶ

HomeからAdd Serverを開き、Typeを確認してSubscribeを選び、サブスクリプションURLとローカルで識別するための名前を入力します。画面によってはサブスクリプション管理とサーバー追加の入口が分かれている場合があります。配置が異なるときは、適当なプロキシプロトコルを選ぶのではなく、Subscribeに対応するサブスクリプションの種類を探してください。保存前にURLの先頭、クエリパラメーター、末尾の文字を確認します。コピー時に空白、改行、日本語の句読点が混入していないかも注意してください。

1. 入力したものがサブスクリプションURLであり、サービス案内ページ、アカウントページ、単一サーバーの共有リンクではないことを確認します。
2. 用途がわかる名前を付け、アカウント名、パスワード、アクセストークンをそのまま登録名に使わないでください。
3. サブスクリプションを保存し、現在の画面に表示される更新操作からサーバー一覧を取得します。
4. Homeに戻って該当するグループを開き、項目を1つ選択してプロトコルとアドレスが揃っているか確認します。

初回の取得に成功したら、まず簡単な確認を行います。グループ名が識別しやすいか、サーバーのプロトコルが手元の情報と一致するか、明らかな重複がないかを見てください。項目数は変化の発見には役立ちますが、接続品質の判断材料にはなりません。サブスクリプションの解析に成功しても、サーバーを選択して接続を確認する必要があります。逆に、特定のサーバーが一時的に使えなくても、サブスクリプションURL自体が更新できないとは限りません。

サブスクリプションの内容とConfigファイルを区別する

サーバーのサブスクリプションは主に「接続先の一覧」を取得するもので、Configファイルは主に「接続をどう振り分け、どの設定値を使うか」を定めるものです。ルールファイルのURLをSubscribeに入力したり、サーバーの共有リンクを完全な設定ファイルとして読み込んだりすると、一覧が空になったり解析エラーになったりすることがあります。拡張子だけで種類を判断せず、元の説明と取得内容をもとに、サーバー一覧、単一サーバー、設定セクションを含むファイルのどれなのか確認してください。

保存後にサーバーが表示されない場合は、まず取得操作をまだ実行していない可能性を確認し、次に返された内容がログインページやエラーメッセージではないか調べてください。ブラウザーでページを開けても、クライアントがサーバー情報を解析できるとは限りません。形式がわからないままURLを何度も変換しないでください。元の登録情報を残し、エラーメッセージからネットワークへの接続不可、認証情報の失効、形式の非対応を切り分けてから再入力するか判断します。

初回接続の設定が必要な場合は、クイックスタートガイドに戻り、Global Routingとシステム権限の手順を進めてください。この章では管理上の登録方法を説明しています。インポートの段階でDNS、ルール、複数の詳細設定を同時に変更することはおすすめしません。まず登録情報を更新できることを確認し、その後サーバーへの接続を確かめると、問題の発生箇所を特定しやすくなります。

Typeを選択してから対応する項目を入力する

手動追加は、サーバー情報一式をすでにお持ちの場合、サーバーを1件確認したい場合、またはインポート結果の違いを調べたい場合に適しています。HomeでAdd Serverを開き、まずTypeを選んでから、そのプロトコルに表示される項目を入力します。プロトコルごとに認証方式が異なるため、手元の情報に含まれる文字列を、名前の似た入力欄へ順番に入れることはできません。必須項目が不明な場合は、別のプロトコルの初期値で補わず、元の情報を確認してください。

Addressには通常、サーバーのドメイン名またはIPアドレスを入力し、Portには対応するポート番号を入力します。通常、アドレス欄にWebページのパスを追加する必要はなく、共有リンク全体を貼り付ける欄でもありません。ドメイン、ポート、認証情報をひとまとまりとして確認してください。同じドメインで複数のサービスを提供している場合があり、ポート番号が同じでもプロトコルが同じとは限りません。名前はローカルで識別しやすい短いものにし、「用途／プロトコル」のように付ける方法もあります。ただし、名前から実際のパラメーターを推測しないでください。

アドレス、TLS、転送の各項目を分けて確認する

接続先アドレス、TLSで使うサーバー名、転送層のHostは、それぞれ異なる値の場合があります。情報に複数の名前が明記されている場合は、該当する項目に個別に入力してください。「同じ値に揃える」ためにすべてAddressへ入力する必要はありません。TLSのサーバー名は証明書と接続処理に関係し、転送パスはリクエストのルーティングに使われることがあります。いずれかが一致しないと、ポートには到達できても通信に失敗する場合があります。

WebSocketなどの転送パラメーターを入力するときは、パス先頭のスラッシュ、大文字・小文字、元のクエリ部分を維持してください。パスに空白や特殊文字が含まれていても、見た目だけで削除しないでください。情報に追加のリクエストヘッダーが指定されていない場合、ネット上で見つけた値を独自に追加しないでください。トラブルシューティングでは元の値と項目ごとに照合し、現在の設定を記録してから1項目ずつ変更して確認します。複数箇所を同時に変更すると、原因を特定しにくくなります。

認証情報は元の値と完全に一致させる

Password、UUID、鍵は元の値を使用してください。全角文字、入力方式による文字の置き換え、コピー時に入る見えない改行に注意します。パスワード内のプラス記号、等号、スラッシュが余分な文字とは限らず、鍵の末尾に正当なパディング文字が付く場合もあります。エンコードされているように見える内容をすべてデコードしてから入力しないでください。通常、クライアントの項目にはその定義に沿った値を入力します。推測した「読みやすい形」ではありません。

WireGuardでは、ローカルインターフェースとリモートPeerのパラメーターを特に区別してください。秘密鍵はローカルの識別情報です。対向の公開鍵として使ったり、名前やエクスポートしたスクリーンショットに記載したりしないでください。UDPに依存する接続方式では、現在のネットワークが該当する通信を許可しているかも確認が必要です。項目を保存できたことは書式の確認が通ったという意味であり、ネットワーク経路や接続先の状態まで整っていることを示すものではありません。

保存後にHomeへ戻り、名前の似た古い登録ではなく、新しく作成した項目が選択されていることを確認します。まずその項目のテストを行い、次に接続をオンにして実際のリクエストを確認してください。古い項目は使えて新しい項目だけ失敗する場合は、両方のType、Address、Port、認証、転送の各項目を順に比較します。後から戻れる基準を失わないよう、古い項目をそのまま上書きしないでください。

手入力した項目とサブスクリプションから生成された項目は、分けて管理してください。サブスクリプション項目のローカル変更は、更新時に置き換えられる場合があります。長期間残したい変更は、クライアントの仕様を確認したうえで独立した項目として保存し、用途を明記してください。項目名の意味がわからない場合は用語集を参照し、日本語の説明を入力すべき英語のパラメーター値と取り違えないようにしてください。

Scan QR Codeで読み取るのはテキストデータ

QRコードはテキストを伝える手段であり、独立したプロキシプロトコルではありません。単一サーバーの共有リンク、サブスクリプションURL、通常のWebページのアドレスが含まれている場合があります。Scan QR Codeを使う前に、QRコードがご自身のサーバー情報に由来することを確認してください。読み取り後は解析結果を見て、追加されるものが単一サーバーかサブスクリプション登録かを判断します。「読み取れた」だけで内容が正しく、接続できるとは限りません。

Homeから画面に表示されているスキャン機能を開き、初回はシステムの案内に従ってカメラへのアクセスを許可します。以前に拒否した場合は、システム設定でShadowrocketのカメラ権限を確認してから、もう一度スキャンしてください。権限に問題がないのに読み取れない場合は、コード全体が画面に収まっているか、ピントが合っているか、反射で模様が隠れていないかを確認します。QRコードの周囲には元の余白を残してください。中央だけを切り抜いたり、模様を小さく圧縮したりしないでください。

QRコードが同じ端末の画面に表示されている場合は、現在の画面に明示された画像認識機能を優先してください。該当する入口がなければ、元の情報に戻ってテキストをコピーし、クリップボードからインポートします。認証情報を含む画像をオンラインの読み取りサイトへアップロードしないでください。チャットアプリで圧縮した画像では細部が失われることがあります。元画像または元のリンクを使い、何度もスクリーンショットを撮って文字情報が復元できなくなるのを避けてください。

クリップボードからインポートする前にコピー範囲を確認する

コピーするのは対象のリンクだけにし、「アドレス：」、引用符、番号、コードブロック、説明文を含めないでください。長いリンクは表示上、自動的に折り返されることがあります。見た目の改行が実際の改行とは限りません。コピー結果に実際の空行が含まれていたら、元のテキストに戻って範囲を確認し、複数の断片を推測でつなぎ合わせないでください。複数のサーバーリンクは通常1行ずつ記載し、インポート前に各行のプロトコル接頭辞が揃っているか確認します。

1. 転送時に途中で切れた表示テキストではなく、元の情報から元リンクをコピーしてください。
2. Shadowrocketに戻り、現在の画面にあるクリップボードからのインポート機能を使います。
3. 貼り付けを許可するかシステムに確認された場合は、今回の操作でクリップボードを読み取る必要があるときだけ許可してください。
4. 解析された種類と追加先を確認してから保存し、Homeの一覧を確認します。

クリップボードにリンクがあっても、クライアントが自動でインポートするとは限りません。システムの貼り付け権限、画面上の操作入口、現在の内容形式によって読み取り結果は変わります。通知が表示されない場合は、異なる内容を次々にコピーして試さないでください。まずクリップボードに元のリンクが残っていることを確認し、明示されたインポート操作で読み込みます。完了後、認証情報を含まない普通のテキストをコピーしておけば、機密リンクがクリップボードに長時間残るのを避けられます。

読み取り失敗と接続失敗を分けて対処する

スキャン後に保存できる項目が表示されない場合は、内容の認識または形式の解析段階で問題が起きている可能性があります。案内ページを読み取っていないか、プロトコル接頭辞が欠けていないか、リンクが途中で切れていないか、現在の形式が対応しているかを確認してください。この段階で接続をオン・オフしてもインポートの問題は解決しません。元のテキストを保存し、次章の形式説明と構造を比較してください。パスワードを変えたり、パラメーターを無作為に削除したりしないでください。

項目の追加には成功したものの接続に失敗する場合、少なくともインポート時に登録情報は作成されています。次に項目の不足、選択状態、ネットワーク環境を確認してください。QRコードからのインポートと手入力の結果は比較材料になります。同じ情報を手入力すると使えるのにQRコード経由では使えない場合は、転送、TLS、追加パラメーターを重点的に確認します。どちらも使えない場合はインポート方法を変え続けず、接続先情報と現在のネットワークを確認してください。

QRコードを繰り返し読み取ると、重複した項目が追加される場合があります。同じ名前なら上書きされるとは限らず、統合されるかどうかはインポートの仕様によります。初回インポート後に、所属グループと名前を記録してから次の操作へ進んでください。追加された内容がわからない場合は、それ以上のインポートを止め、一覧でプロトコルとアドレスを確認します。そのうえで複数サブスクリプションの整理を参考にし、以前使えていた項目を誤って削除しないようにしてください。

インポート後はGlobal Routingを選択し、システムのVPN構成を許可する必要もあります。これらの案内はQRコード自体とは関係ありません。初めて権限の確認画面が表示された場合は、VPN構成の追加確認についてをご覧ください。システム権限の設定が終わっていないからといって、QRコードの内容が無効だと判断したり、同じ情報をまとめて再インポートしたりしないでください。

単一サーバーのリンクとサブスクリプションURLは別のもの

単一サーバーの共有リンクは、接続パラメーター一式をテキストにまとめたものです。一般的な接頭辞にはss://、vmess://、vless://、trojan://、hysteria2://などがあります。一方、サブスクリプションURLは通常、サーバー一覧を取得するためのHTTPS URLで、複数のサーバー情報が返される場合があります。種類を見分けるときは、まず元の資料に書かれた用途を確認し、次にリンクの構造を見てください。どちらもコピーできるからといって、同じ項目に入力できるとは限りません。

プロトコル接頭辞は形式を見分ける手がかりですが、完全な解析には後続の認証情報、アドレス、ポート、パラメーターも関係します。プロトコルやエクスポート方法によってエンコードの形式が異なります。特にVMessの共有情報はエンコードされた構造で保存されることが多く、WebサイトのURLのように「ユーザー名、パスワード、ドメイン」に分けることはできません。慣れない形式は、まずクライアントからインポートし、解析後の項目を元情報と照合してください。

構造を確認するための例です。接続には使えません。

以下は架空の構造例です。サーバーアドレスにはexample.comを使い、認証情報も実際のものではありません。ユーザー名または認証部分、ホストとポート、クエリパラメーター、フラグメント部分の名前は、それぞれ異なる役割を持ちます。実際の情報に追加項目が含まれている場合、例にないからといって削除しないでください。また、この例からすべてのサーバーに適用できる転送設定を推測しないでください。

trojan://[email protected]:443?security=tls&sni=example.com#personal-reference
https://example.com/sub?token=xxxx

リンク内の疑問符以降はクエリパラメーターで、パラメーター同士は通常&で区切られます。シャープ記号以降のフラグメントは名前の記載などに使われます。特殊文字を含む項目はパーセントエンコードされている場合があるため、見た目が似ている文字列でも、読みやすい表記と元のエンコードをそのまま置き換えられるとは限りません。認証情報自体に区切り文字が含まれる場合、むやみにデコードしたり組み直したりすると項目の境界が変わり、保存されたパスワード、パス、名前が元の値と異なることがあります。

Base64はテキストのエンコード方式であり、情報を秘匿する手段でも、利用可能かどうかを検証する方法でもありません。パスワードが読めないリンクにも、完全な認証情報が含まれていることがあります。エンコード済みの共有情報を公開してよい技術ログと考えないでください。また、形式を理解しないまま何度もエンコードしないでください。再エンコードすると、クライアントが元のサーバー情報ではなく通常のテキストとして読み込む場合があります。

サーバーのパラメーターと通信ルールは別のもの

共有リンクは通常、接続先を伝えるもので、現在のConfigにあるルール、DNS、その他の設定を必ずしも含みません。サーバーをインポートできても、特定のドメインへの通信をプロキシ経由にするかどうかは、Global Routingと現在のルールファイルによって変わります。以下の.confの例は、順番に評価されるルール構造を示しています。PROXYはポリシーのキーワードであり、サブスクリプションのグループ名ではありません。サーバーの認証情報も含みません。

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

例にあるFINAL,PROXYは、それまでのルールに一致しなかった通信に後続のポリシーを指定します。新しいサーバーを作成する機能でも、無効な認証情報を修復する機能でもありません。この断片は形式の説明用です。バックアップを取らず、内容を理解しないまま設定全体を置き換えないでください。.confの各セクションを詳しく確認する場合は、設定ファイルのセクション解説を参照し、[General]など既存の設定との関係を保ってください。

共有前にエクスポート対象を確認する

ご自身の別の端末へ移行するときは、共有するものが単一サーバー、特定のサブスクリプションURL、完全な設定のどれなのかを先に確認してください。単一サーバーのエクスポートにはサブスクリプションの更新関係が含まれない場合があり、設定のエクスポートにはローカルのサーバー一覧が含まれないこともあります。エクスポート結果を確認して対象範囲を把握してください。ファイル名だけで完全なバックアップが取れたと判断せず、復元を試す前に元の端末から登録情報を削除しないでください。

解析エラーが表示されたら、元のテキストを保存して、接頭辞、文字の境界、エスケープの状態を確認し、インポート後の項目と照合してください。異なるプロトコルのリンクを1行に連結したり、拡張子を変更してリンクを「設定ファイルにする」ことはできません。トラブルの相談に必要な情報を共有する場合は、認証情報を含まないプロトコル名、エラーが起きた段階、必要最小限の項目構造にとどめてください。リンク全体やQRコードは、管理された環境から出さないでください。

更新によって変わるのはリモート項目のローカルコピー

サブスクリプションを更新すると、リモートの内容が再取得され、それに応じてローカルに生成されたサーバー一覧が更新されます。接続のオン・オフや遅延テストとは別の操作です。接続をオンにしてもサブスクリプションが更新された証拠にはならず、テストに成功しても最新のパラメーターを取得できたとは限りません。更新前に対象のサブスクリプショングループを確認し、現在選択中の項目を記録してください。更新後に削除や名前変更が起きると、誤って別のサーバーを選ぶことがあります。

サブスクリプションを初めて設定したとき、元情報にサーバー項目の変更が記載されているとき、一覧に明らかな古さが見られるときは、手動で更新できます。頻繁な更新をあらゆる問題の解決策と考えないでください。取得内容に変化がなければ、同じリクエストを繰り返してもサーバーの経路状態は改善しません。自動更新を使うかどうかは、現在の画面に表示される設定と必要性に応じて決めてください。前面・バックグラウンドやネットワーク環境によって、システム上の制限を受ける場合があることも把握しておきましょう。

リクエスト、レスポンス、解析、接続の4段階で切り分ける

更新がいつまでも終わらない場合は、まず端末から既知のネットワークリソースへ正常にアクセスできるか確認し、次にサブスクリプションのドメイン名を解決できるか確認してください。サブスクリプションのサーバーと、実際に接続するプロキシサーバーではアドレスが異なることがあります。一方に接続できても、もう一方に接続できるとは限りません。画面に更新リクエストのルート設定がある場合は、現在のネットワーク環境に合っているか確認してください。更新のたびに、選択中のプロキシサーバーを必ず経由するとは限りません。

すぐに解析エラーが返る場合は、取得した内容が本当にサブスクリプションデータか確認してください。アカウントのログイン画面、アクセス認証画面、エラー説明は通常、サーバー一覧としてそのまま使えません。ブラウザーに「ページを開けました」と表示されても、レスポンスの形式が適切とは限りません。エラーページを保存して再インポートしたり、複雑に見える認証パラメーターをURLから削除してエラーを回避したりしないでください。

更新後は通知だけでなく、実際の変更内容を確認する

更新後は、グループに項目が残っているか、以前選択していたサーバーがまだあるか、名前やプロトコルが変わっていないか確認してください。サーバー数の減少はリモート一覧の変更による可能性があり、数だけで異常とは判断できません。同様に、数が増えても品質の向上を示すわけではありません。追加または残存した項目のパラメーターが妥当か確認し、テストと実際のアクセスを行って、更新後に使える状態か確かめてください。

サブスクリプションから生成されたサーバーは、リモートの情報と一致するように管理するのが基本です。項目のパスワード、転送パス、TLS名を手動で変更した場合、後の更新で上書きされることがあります。ローカルでの検証内容を残す場合は、変更点を記録して独立した項目として保存し、元のサブスクリプションに自動追従しないことを明記してください。ローカルの変更を残すために更新を長期間止め、リモートの情報が変わる可能性を見落とさないようにしましょう。

元のURLに含まれる認証情報が漏れた可能性がある場合、ローカルのサブスクリプションを削除しても古いURLは無効になりません。ご自身が利用できるアカウント管理手段で、関連するアクセス情報を変更できるか確認し、新しいURLをサブスクリプション登録に反映してください。変更後に古いリンクがどう扱われるか確認し、古いURLを含むスクリーンショット、一時ファイル、他の端末のクリップボードも整理して、古い情報が再利用されないようにします。

更新と接続の問題が重なっているときは、一度に変える条件を1つにします。まず現在のネットワークでサブスクリプションのリクエストを確認し、次に更新後の項目を1つ選んで接続をテストし、最後にConfigとDNSを確認してください。接続済みなのにWebページを開けない場合は、接続済みなのにアクセスできない場合のチェックリストもご覧ください。すべての問題をサブスクリプションの更新に結びつけないでください。

グループ名で用途と管理方法を示す

複数のサブスクリプションを管理している場合は、まず取得元ごとの区分を明確にし、すべてのサーバーを一つの一覧にまとめるのは避けましょう。グループ名には個人の用途、管理方法、使用場面を表す名前を付けられます。たとえば「日常／サブスクリプション」「仕事／手入力」「一時／確認待ち」などです。アカウント名やアクセス先を名前に含める必要はありません。見た目を揃えることより、どこで更新するか、どの項目をローカルで変更できるか判断しやすいことが大切です。

サブスクリプション側の名前とサーバー側の名前を区別してください。前者は更新入口を見つけるため、後者は接続先を選ぶために使います。名前が似ていても、同じ対象とは限りません。リモートサブスクリプションの更新でサーバー名が書き換わる場合があるため、ローカルの整理をサーバー名が変わらないことだけに頼らないでください。長期的に残す必要がある説明は、管理されたローカルの記録にグループとの対応関係を保存してください。

名前だけで重複かどうか判断しない

同じ名前でもアドレス、ポート、認証情報が異なる場合があり、名前が違っても同じ接続先を指すことがあります。重複を確認するときは、少なくともプロトコル、アドレス、ポート、主要な転送パラメーターを比較し、同じサブスクリプションから取得したものかも確認してください。認証情報が含まれている場合があるため、重複整理の相談に一覧全体を公開しないでください。比較結果を記録するなら、ローカルのグループ名と認証情報を含まない識別情報だけにします。

異なるサブスクリプションに似た項目があっても、どちらかを削除すべきとは限りません。更新間隔、認証の範囲、利用条件が異なる場合があり、現在のパラメーターが同じでも今後ずっと同じとは限りません。選択時の煩雑さを減らすだけなら、取得元との関係を壊さず、クライアントに備わっているグループ分けや絞り込みを使う方法を優先してください。用途、バックアップ状態、更新時の動作を把握してから整理するかどうかを決めましょう。

サーバーグループとルールのポリシーは別のもの

Homeのグループはサーバーを整理するためのもので、Configのルールは通信の処理方法を決めます。サーバーを別の名前のグループへ移動しても、特定のドメインが自動的にそのサーバーを経由するわけではありません。設定で名前を使ってポリシーやグループを参照している場合は、名前を変更した後にConfig内の参照も確認してください。具体的な関連付けは現在の設定内容によって異なります。グループ名の日本語表示だけから通信の動作を判断しないでください。

Global Routingで使う3つの状態も、それぞれ区別して理解してください。Configは現在の設定ルールに従って処理します。Proxyは対象となる通信をプロキシポリシー経由にします。Directは通信を直接処理します。サーバー一覧を整理するついでに状態を切り替え、戻し忘れないようにしてください。整理前と異なる条件でテストすることになり、グループの変更がサーバー品質に影響したと誤解する可能性があります。

少しずつ整理し、元に戻せるよう記録する

整理を始める前に、現在のグループ、選択中のサーバー、接続できる状態かどうかを記録し、重複が明らかなものを一組ずつ処理してください。ひとまとまりの作業ごとに、更新入口が残っているか、選択状態が変わっていないかを確認し、実際のリクエストをテストします。一度に大量の削除、名前変更、サブスクリプション更新、Configの置き換えを行わないでください。複数の操作を重ねると、問題が起きても原因を特定しにくくなります。

用途がまだわからない項目は、リストを短くするために急いで削除せず、ローカルのメモを付けて残しておく方法があります。整理する場合は、明らかに使えず復元可能な一時項目から対応し、次に独立した手入力項目、最後にサブスクリプショングループを検討してください。サブスクリプション内のサーバーを1件削除しても、次回の更新で再び表示されることがあります。これはリモートの一覧とローカルコピーの関係によるもので、削除が実行されなかったとは限りません。

整理後は、機密情報を含まない管理メモに「自動更新されるグループ」「独立して管理する項目」「Configから参照される名前」を記録してください。パスワードや完全なURLを記載する必要はありませんが、端末の変更や復元後に管理関係を再構築するのに役立ちます。画面上の用語はHome、Config、Settingsの用語解説と合わせて確認し、誤った階層で一括操作しないようにしてください。

テスト結果は特定の条件下の状態を示す

Connectivity Testは、特定のテスト方法と現在のネットワーク環境でサーバーの状態を確認する機能です。表示された時間が短くても、すべてのWebサイトにアクセスできることや、通信速度が速いことを示すわけではありません。タイムアウトは、今回のテストが想定した条件内で完了しなかったことを示します。認証情報が永久に無効になったとは限りません。結果を評価する際は、テスト方法、ネットワーク環境、テスト時にサーバーが混雑していたかどうかも確認してください。

テスト方法によって確認できる接続段階は異なります。ポートへの到達だけを確認するテストでは、プロキシ認証、TLS、ドメイン名の解決、宛先へのリクエストがすべて成功するかまでは確認できません。プロキシ経由のリクエストを使うテストでも、結果が反映するのはその時点の宛先と経路です。現在の画面でテスト方法や接続先を選べる場合は、何を使っているかを確認してから結果を比較してください。異なる方法で得た数値を並べて結論を出さないでください。

まず1件で確認し、その後に範囲を絞ってテストする

新しくインポートしたサブスクリプションでは、まずパラメーターが揃っている項目を1つ選んでテストし、クライアントとネットワークが正常であることを確認します。その後、比較が必要なグループをまとめてテストしてください。大規模な一覧全体を一度にテストすると、多数のリクエストが同時に発生し、端末のネットワーク、接続先の制限、テスト対象の影響を受けやすくなります。失敗を繰り返す場合は並列数を増やすのではなく、まず対象を1項目に絞ってください。

1. 同じネットワーク環境を保ち、通信量の大きい処理が結果に影響していないか確認する。
2. テスト方法を明確にし、比較するサーバーを少数に絞る。
3. 異常な結果は時間を置いて再テストし、1回のタイムアウトだけで項目を削除しない。
4. 候補のサーバーを選択して接続し、実際に必要なコンテンツへアクセスできるか確認する。

Wi-FiとCellularではネットワーク経路が異なる場合があります。一方で接続できても、もう一方でも接続できるとは限りません。ネットワークを切り替えたら改めて確認し、以前のテスト結果から現在の状態を判断しないでください。すべての項目で同時に異常が起きる場合は、ローカルネットワーク、システム時刻、テスト対象、DNSを先に確認します。複数の独立した接続先が同時に失敗するなら、サーバーのパラメーターを個別に変更するより、共通するローカル環境を優先して調べる価値があります。

並べ替えは一時的な表示であり、自動選択を保証するものではない

テスト結果で並べ替えると候補のサーバーを見つけやすくなりますが、すべてのルールのポリシーが自動で変わるわけではなく、一覧の先頭が選択される保証もありません。並べ替えた後は選択マークを確認し、現在のGlobal RoutingとConfigも確認してください。ルールが特定のポリシーやサーバー名を参照している場合、実際の接続ではテストした項目が使われないことがあります。現在の設定に照らして判断してください。

サーバーを比較する際は、できるだけ近い時間、同じネットワーク、同じテスト方法で確認し、実際の用途でも検証してください。大容量ファイルのダウンロード、短時間のWebリクエスト、長時間接続では経路に求められる条件が異なります。遅延の数値だけですべての使用感は判断できません。サーバーの名前に記載された地域や用途もテストの代わりにはなりません。名前は識別情報であり、実際の通信経路は現在の状態から確認してください。

接続後に失敗する場合は、実際のリクエストを追って確認する

テストでは接続可能なのにWebページを開けない場合は、現在のリクエストで実際に選択中のサーバーが使われているかを確認し、Global Routing、DNS、ルールとの一致を調べてください。トラブルシューティング中に異なる状態で一時的に比較してもかまいませんが、一度に変更する条件は1つにし、確認後は元の設定に戻します。特定のページを開くためだけにルール全体を恒久的に置き換えたり、すべての失敗を遅延の高さのせいにしたりしないでください。

トラブルシューティングの記録には、ネットワークの種類、テスト方法、対象を選択していたか、エラーが起きた段階を残せば十分です。サーバーの完全なアドレスや認証情報を公開する必要はありません。ルールと接続のどちらに問題があるかを切り分ける場合は、サーバー、Global Routing、DNS、ルールの確認方法をご覧ください。管理の基準となるのは、並べ替え結果や単独の数値ではなく、再現できる確認手順です。

削除前に対象の階層と関連項目を確認する

サーバーの削除、サブスクリプション登録の削除、Configファイルの削除、システムVPN構成の削除は、それぞれ異なる操作です。前の2つはローカルのサーバー管理に影響し、Configはルールや設定内容に影響し、システムVPN構成はシステムの接続許可や関連設定に影響します。操作前に、現在の画面で対象名と確認メッセージを読んでください。「接続できない」ことを、すべての登録を消去する必要があるという意味に捉えないでください。

サブスクリプション内のサーバーを1件削除しても、次回の更新時に再び表示されることがあります。サブスクリプション登録全体を削除すると、生成された項目も同時に削除される場合があります。対象の範囲は確認画面で確かめてください。削除前に選択中のサーバーを記録し、Configから名前で参照されていないか確認します。参照先がなくなった場合、問題が起きるのはポリシー選択の段階かもしれません。リモートのサーバー自体が停止したとは限りません。

バックアップでは異なるデータ層を保存する

復元に必要な内容は、通常1つの.confファイルだけではありません。サブスクリプションURL、独立して手入力したサーバー、設定ファイルと選択状態、ローカルの上書き設定、必要な操作メモが保存されているか、それぞれ確認してください。エクスポートの入口がすべてのデータを含むと思い込まず、現在の画面に表示される対象範囲を確認してから、出力内容を検証します。ファイルを開けても、復元に必要な認証情報が含まれているとは限りません。

バックアップファイル、共有リンク、QRコードには同じレベルの機密情報が含まれている場合があります。アクセスを管理できる場所に保管してください。端末に備わっているファイル同期機能を使う場合も、保存先のアカウントと共有範囲を確認し、公開共有フォルダーにバックアップを置かないでください。トラブル対応のために一時的に作成したエクスポートファイルも適切に管理し、確認後に不要になったコピーを削除して、古い認証情報が複数の場所に残らないようにします。

取得元、項目、設定、接続の順に復元する

新しい端末で復元する場合は、まず全プラットフォームのダウンロードガイドからShadowrocketを入手し、バックアップの内容に沿ってサブスクリプションの取得元と独立したサーバーを再登録します。次にConfigを復元し、設定内で参照されている名前が存在するか確認してください。最後にGlobal Routingを設定し、サーバーを選択してシステムの許可を完了します。この順序なら、「データが復元されていない」ことと「接続条件が整っていない」ことを切り分けやすくなります。

iPhone / iPadでアプリを入手することと、サーバー情報を復元することは別です。クライアントを再入手しても、サブスクリプションURLやローカルのパラメーターが復元されるわけではありません。iPhone / iPad版はApp Storeで$2.99の買い切り、Mac / Windows / Android / Linux版は無料です。アプリの入手方法と購入済み項目の説明はダウンロードページをご覧ください。アプリの買い切りと接続サービスの契約は別です。アプリを復元しても、新しいサーバー情報は作成されません。

復元後はまず項目を1つ選んでテストし、実際のリクエストでも確認してください。正常に使えることを確かめてから、古い端末の登録を削除します。端末間の移行ではローカル設定、システム権限、バックグラウンド動作が異なる場合があります。サーバー名が同じというだけで移行完了と判断しないでください。新しい端末で失敗し、古い端末では使える場合は、重要な項目、Config、Global Routing、ネットワーク環境を比較し、古い端末は復旧用の基準として残してください。

誤削除と認証情報の失効では対処方法が異なる

ローカルの項目を誤って削除した場合は、保存済みのサブスクリプションURL、サーバーの共有情報、バックアップファイルからの復元を優先してください。サブスクリプション内の項目だけを削除した場合は、取得元の登録が残っていることを確認してから、通常の手順で更新を試します。取り消し機能が必ずあるとは限りません。データの状態がわからないまま複数の古いバックアップを何度もインポートしないでください。重複した登録や異なるパラメーターが混在し、かえって復元が難しくなることがあります。

認証情報が変更または失効している場合、古いバックアップで復元できるのは古いパラメーターだけです。リモート側の認証を復元することはできません。ご自身がすでにお持ちの有効な情報を確認し、サブスクリプションURLや認証情報を更新してから接続を再確認してください。漏えいしたリンクを無効にするには、ローカルで削除するだけでなく、リモート側の認証情報を処理する必要があります。復元できることを確認したバックアップと、機密情報を含まない管理メモを残しておけば、次回の更新や移行を確実に進められます。