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

入力内容の用途を確認する

インポートする前に、お手元の完全なサブスクリプションURLを用意し、サービス提供元がShadowrocket用として案内していることを確認してください。URLのパス、クエリパラメーター、トークンは、取得する一覧を決めるために組み合わされている場合があります。ドメイン部分だけでは不十分なことがあります。ページタイトルやURLの長さだけで用途を判断せず、アカウント案内ページ、ログインページ、更新手続きページのURLをサブスクリプション欄に入力しないでください。ページにアクセスできることと、サブスクリプションとして解析できることは別です。

サーバー項目には接続に必要なプロトコルやパラメーターを保存し、サブスクリプションはリモートから項目を取得します。ConfigはルールやDNSなどの動作を制御します。これらは同時に存在できますが、互いに代用できるものではありません。インポート後にサーバー一覧が表示されても、取得と解析が完了したことを示すだけです。選択中のサーバーに接続できることや、ルールが想定どおりに通信を処理することまでは確認できません。

HomeからSubscribeを追加する

Homeで追加メニューを開き、Add Serverに進んで、TypeからSubscribeを選びます。実際のメニュー位置はアプリ内の表示をご確認ください。URL欄に完全なアドレスを貼り付け、見分けやすいメモを入力して保存します。サブスクリプションの取得や更新を求められた場合は、画面の案内に従ってください。操作中はネットワークに接続できることを確認し、処理を待つ間に同じURLを続けて追加しないようにしましょう。似た名前のグループが複数作成されるおそれがあります。

保存前に、URLの先頭や末尾に空白、改行、引用符、日本語の句読点が混ざっていないか確認してください。チャット上で折り返された長いURLも、コピーすれば欠けないとは限りません。スクリーンショットから文字を読み取る場合は、文字が誤認識されることがあります。特に「?」以降の内容、大文字・小文字を区別するトークン、パーセントエンコードを確認してください。URLはアクセス情報です。形式確認のために見知らぬウェブサイトへ貼り付けないでください。

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

以下は形式の例であり、実際に利用できるサブスクリプションではありません。実際のURLはご利用中のサービス提供元から入手してください。例では「?」以降のtokenがクエリパラメーターを示していますが、すべてのサブスクリプションで同じパラメーター名が使われるわけではありません。識別情報がパスに含まれるURLもあります。確認時は元の形式を維持し、見た目を整えるために一部を削除したり、例のパラメーターを独自に追加したりしないでください。

保存後に4項目を確認する

初回の取得が完了したら、サブスクリプショングループが表示されているか、サーバー項目が存在するか、プロトコルが手元の情報と一致するか、メモでグループを見分けられるかを順に確認してください。一覧が空の場合は、元のURLを残したままアプリのメッセージを確認し、サービス提供元が登録先を変更していないか問い合わせてください。すぐに各サーバーを編集したり、古い一覧を削除したりせず、インポートの失敗とサーバー接続の失敗を分けて対処しましょう。

一覧が正常に表示されても、見覚えのない名前が含まれている場合は、接続品質や所在地を示すものと決めつけず、サブスクリプションの案内と照らし合わせてください。メモはサブスクリプションの内容に応じて設定され、次回更新で変わることがあります。項目を追跡する必要がある場合は、表示順だけでなく、所属するサブスクリプションとプロトコルも記録してください。

[Check]

サブスクリプションのインポート、サーバーのテスト、実際のリクエストは、それぞれ別の確認段階です。順に確認し、いずれか一つでほかの確認を済ませたことにしないでください。

解析に失敗した場合は、まずURL全体と現在のネットワークを確認し、取得内容がサブスクリプションデータかどうかを確かめてください。リモートからログイン案内、エラーページ、空の内容が返された場合、リクエストに応答があってもサーバー一覧は作成できません。詳しくはサブスクリプションが空・解析に失敗する場合の確認方法をご覧ください。エラー文は残し、他の人に相談する際は完全なトークンを共有しないでください。

同じサブスクリプションがすでにある場合は、重複してインポートせず、既存の項目を更新してください。新しいURLを試す場合は、異なるメモを付けた一時グループを作り、元のグループを比較用に残しておきましょう。新しい一覧が完全で、実際のリクエストも成功することを確認してから、古い項目を削除するか判断してください。この順序なら、リモートの内容変更とアプリ内の操作を切り分けやすくなり、誤削除後に原因が分からなくなる事態を防げます。

Scan QR Codeですべてのページを読み取れるわけではない

Scan QR Codeを使う前に、QRコードがご自身のサーバー情報やサブスクリプションの案内に由来することを確認してください。QRコードには、サーバーの共有リンクが含まれている場合も、単なるウェブページのURLが含まれている場合もあります。スキャナーが内容を読み取れても、アプリがサーバー情報に変換できるとは限りません。スキャン後に一般的なウェブページが開いたり、解析できないというメッセージが表示されたりした場合は、元の案内で用途を確認してください。QRコードの横にサーバー名が書かれているだけで、インポート用だと判断しないでください。

別の画面に表示されたQRコードを読み取る場合は、全体が読み取り範囲に入るようにし、反射や四隅の切れ、複数のQRコードが同時に映る状態を避けてください。長い内容を含むQRコードは細かくなる傾向があり、小さく表示すると読み取りにくくなる場合があります。何度も圧縮されたチャットのサムネイルではなく、元の鮮明な画像を使ってください。読み取りに失敗しても、それだけでサーバーが利用できなくなったとは判断できません。

システムからカメラへのアクセス許可を求められた場合は、操作に必要な範囲で許可してください。以前に拒否した場合は、システム設定でShadowrocketのカメラアクセス権を確認してから、もう一度スキャンします。権限の問題はサーバー認証とは関係ないため、サブスクリプションURLを変更する必要はありません。アプリ内にほかの画像読み取り機能がある場合も、現在の画面表示に従ってください。すべてのシステムやデバイスでボタンの位置が同じとは限りません。

クリップボードからは元の文字列をそのままインポート

共有リンクをコピーするときは、プロトコルの接頭辞からパラメーターとメモの末尾までを選択してください。メッセージ内の説明、番号、箇条書き、コードブロックはリンクに含まれません。アプリにクリップボードからのインポート機能がある場合は、コピー後にアプリ内で操作し、システムの案内に従って必要なアクセスを許可してください。システムの確認画面が表示されないからといって、コピーに失敗したとは限りません。また、用意したリンクを別の内容で上書きしないようにしてください。

複数のリンクをまとめてコピーした場合に一括インポートできるかどうかは、入力内容の認識方法によります。確認しやすくするため、初回は1件だけインポートし、結果を確認してから残りを処理してください。複数行のテキストに説明文、空行、ウェブページの記号が混ざっていると、一部の行が無視されることがあります。インポート後は実際の項目を一つずつ確認し、「インポート済み」という表示だけで、すべての情報が保存されたと判断しないでください。

システムからペーストの許可を求められた場合、拒否した後はアプリの用意した入口から操作し直し、権限の案内に注意してください。クリップボードの読み取りとサブスクリプションのネットワークリクエストは別の経路です。内容を読み取れない場合は入力段階の問題で、サブスクリプションの作成後に取得できない場合はリクエスト段階の問題です。失敗した段階を特定してから、正しいURLやサーバーパラメーターをむやみに変更しないようにしましょう。

インポート後は名前だけでなく項目を確認

共有リンクを1件インポートしたら、Type、アドレス、ポートに加え、必要なTLSや通信の項目を確認してください。メモが正しくても、読み取られたのが名前だけで、ほかのパラメーターがそろっているとは限りません。形式によってはメモがパーセントエンコードされています。名前にエンコードされた文字が表示されたり、見た目が異なったりしても、接続に影響するとは限りません。ただし、リンクのパラメーターを誤ってメモに入れていないか、メモがアドレス欄に残っていないか確認してください。

サブスクリプションのQRコードをインポートした後は、更新可能なサブスクリプション項目が作成されたのか、その時点の一覧にあったサーバー1台だけが保存されたのかも確認してください。判断の根拠は、QRコードの画像タイトルではなく、アプリに保存された項目の種類と更新メニューです。継続して更新する必要がある場合は、サーバー1台をコピーするより、正しいサブスクリプション項目を残すほうが適しています。通常、サーバーを1台だけインポートしても、サブスクリプションの更新関係は引き継がれません。

[Privacy]

QRコード、共有リンク、クリップボードの内容には完全な認証情報が含まれる場合があります。公開の読み取りサイトにアップロードしないでください。画面のスクリーンショットを共有する前に、QRコード、パスワード、クエリトークンを削除してください。

QRコードを何度も読み取ると、似た項目が複数作成されることがあります。整理する前に、所属するグループ、プロトコル、アドレスを比較し、どの項目が現在選択されているか確認してください。名前が同じでもパラメーターが異なる場合は、すぐに重複として削除しないでください。名前が違っても、アドレスが同じで認証や通信設定が異なる場合があります。判断できない場合は両方を残し、区別しやすい一時メモを付けて、テストの章に沿って個別に比較してください。

インポート後はクリップボードを通常のテキストに置き換えておくと、後で認証情報を誤って貼り付けるリスクを減らせます。ただし、すでに共有した情報を無効にできるわけではありません。完全なリンクが公開されたことがある場合は、利用中のサービスの管理画面で認証情報を変更し、アプリに保存した内容も更新してください。入力の手軽さは認証情報の管理の代わりにはなりません。元の共有情報は引き続き機密データとして扱ってください。

更新前に比較できる状態を残す

サブスクリプションの更新によって、サーバーの追加、削除、名前変更のほか、アドレス、ポート、認証情報が置き換わることがあります。実行前に対象のグループを確認し、現在選択している項目とそのサブスクリプションを記録してください。接続トラブルの対処中であれば、まず現象を記録してから更新することをおすすめします。そうしないと、更新後の一覧の変化と元からの問題が混ざり、どの操作で結果が変わったのか分かりにくくなります。

更新によって手動変更が必ず保持されるとは限りません。サブスクリプション管理下の項目はリモートの内容に基づくため、ローカルのメモ、並べ替え、各フィールドが保持されるかどうかは、実際の更新結果で確認してください。長期的に管理する個別の設定は、用途を記した手動項目として別に作成しましょう。更新前に古いグループを空にする必要もありません。以前の状態を残しておけば、取得に失敗したとき、アプリが元のデータを保持しているか確認できます。

手動更新と自動更新の役割

手動更新は、サービス提供元から設定変更の連絡があった場合、一覧が明らかに古い場合、初回インポート後に内容を再確認したい場合に適しています。該当するサブスクリプションを更新し、処理が完了するまで待ってから、表示メッセージとグループの内容を確認してください。短時間に何度もタップしても、リモートからエラーが返る問題は解決しません。複数回実行すると結果を対応付けにくくなります。一度失敗したら、ネットワーク、認証、解析のどの段階のエラーかを確認してから次の操作を決めましょう。

現在のアプリに自動更新の設定がある場合は、利用頻度に応じて有効にし、各オプションを確認してください。システムのバックグラウンド処理は、ネットワーク、デバイスの状態、システムの制約に左右されます。更新間隔を設定しても、毎回その時刻どおりにリクエストが完了するとは限りません。重要な変更を確認する場合は、バックグラウンド処理の予定時刻だけに頼らず、アプリで実際の一覧を確認し、必要であれば手動で更新してください。

サブスクリプションの更新に使われるネットワーク経路は、現在の接続状況、ルーティングモード、アプリの設定によって変わる場合があります。接続を有効にした状態では更新に失敗し、無効にすると成功する場合は、経路の違いを確認する必要があります。ただし、すぐに特定のサーバーが利用不能だと断定しないでください。同じ基本ネットワークで比較し、一度に変更する条件を一つに絞りましょう。ネットワークの切り替え、URLの変更、サブスクリプション全体の再インポートを同時に行わないでください。

失敗した段階に応じて対処し、診断の代わりに再作成しない

リクエスト段階の失敗では、接続できない、タイムアウトする、名前解決に問題があるといった症状がよく見られます。まずデバイスで現在のネットワークを正常に使えるか確認してください。認証・アクセス段階で失敗した場合は、URLの認証情報が完全か、リモート側で以前のURLが無効になっていないかを確認します。解析段階の失敗では、返された内容がサブスクリプションの形式に合っているかを確認してください。段階ごとに確認対象は異なります。すべてを「サーバーが使えない」とまとめないようにしましょう。

リモート側でサブスクリプションURLが変更された場合は、既存のサブスクリプションの該当欄を変更し、更新結果を確認してください。グループ名だけを変更してもリクエスト先は変わりません。また、サーバー1台の設定を変更してもサブスクリプション全体の入口は修復されません。変更前後のグループを比較用に一時的に残す場合は、どちらが古い記録か明確にしてください。古いグループを操作して、新しいURLが反映されていないと誤解しないようにしましょう。

[Update boundary]

更新成功のメッセージが表示されても、一覧に項目が増えるとは限りません。また、サーバーごとの接続成功を意味するものでもありません。リモート側に変更がなければ、更新後も一覧は変わらない場合があります。

更新後は、まずグループが存在するか、次に項目の内容が変わったかを確認し、最後に現在の選択項目を確認してください。リモートの一覧からサーバーが削除された場合、ローカルで以前選択していた項目を改めて確認する必要があります。接続スイッチがオンのままでも、更新前と同じ項目を経由しているとは限りません。ルールが名前付きの項目を参照している場合は、参照先が想定した項目に対応しているかも確認してください。

一覧の件数が変わったからといって、サービス品質が変わったとは限りません。リモート側で項目が分割、統合、改名された可能性があるため、実際のパラメーターと案内を確認してください。何度更新しても想定した内容が取得できない場合は、エラー文、操作順、確認済みの内容をまとめ、利用中のサービスの管理元に返却内容を確認しましょう。問い合わせには問題の説明だけを記載し、公開の場で完全なサブスクリプションURLを共有しないでください。

Shadowrocket自体のアップデートはApp Storeで確認し、App Storeから行ってください。サブスクリプションを更新してもアプリはアップデートされません。アップデートの要否、互換性、システム要件はApp Storeの掲載内容をご確認ください。正規の入手先とアプリIDの確認方法は正規版の確認方法をご覧ください。一覧が空になる問題は、サブスクリプションのリクエストと解析の流れに沿って対処してください。

測定対象とテスト方法を確認

Connectivity Testまたは一覧のテスト機能を使う前に、アプリが使用するテスト方法と対象を確認してください。サーバーのポートへの接続を測定する方法もあれば、プロキシ経由でテスト対象にアクセスする過程を含む方法もあり、結果の意味は異なります。方法、対象、基本ネットワーク、実施時刻が近い場合に限り数値を比較できます。異なるモードの結果をそのまま順位付けしないでください。

テスト値は1回または複数回の測定結果であり、その後のリクエストが毎回同じ結果になることを示すものではありません。現在のネットワーク負荷、Wi-Fiの電波状態、サーバーの状態、名前解決、接続先からの応答が結果に影響します。一度値が高くてもすぐに項目を削除する必要はありません。値が低くても、あらゆる用途に適しているとは限りません。ネットワークを変えずに少数回テストを繰り返し、結果に一貫性があるか確認してから切り替えを判断してください。

タイムアウトや失敗も、テスト方法を踏まえて解釈する必要があります。テスト対象にアクセスできない場合、複数のサーバーで同時に失敗することがあります。プロトコルの項目に誤りがある場合は、該当する項目だけに問題が出ることもあります。テストに失敗しても、サーバーアドレスにまったくアクセスできないとは限りません。テストに成功しても、特定のサービスへのリクエストが成功するとは限りません。テスト機能は原因を探る手がかりとして使い、実際のリクエストで確認してください。

再現できる確認手順を作る

最初に基本ネットワークが正常か確認し、ネットワークへのログインが未完了、電波が不安定といった問題を除外します。次に選択中の項目とプロトコルのパラメーターを確認し、似た名前の古い項目をテストしていないか確かめます。3番目に、同じ方法でテストを実行し、結果が出るまで待ちます。4番目にGlobal Routingと現在のConfigを確認し、最後に確認したい接続先へアクセスします。各段階で何を確認したか説明できるようにしてください。

すべての項目が同時に失敗した場合は、基本ネットワーク、共通のテスト対象、共通設定を優先して確認してください。特定のサブスクリプションだけ失敗する場合は、直前に更新したか、認証情報が変更されたかを確認します。1台だけ失敗する場合は、そのアドレス、ポート、TLS、通信パラメーターを確認してください。アプリの再インストールやすべてのサブスクリプションの削除から始めるより、このように対象を絞るほうが記録を残しやすく、正しく設定済みの項目を作り直す必要もありません。

実際のリクエストを比較するために一時的にモードを変える場合は、元の状態を記録し、確認後に戻してください。一度成功させるために、理解していないモードをそのまま使い続けないでください。特にConfigでは、対象のリクエストにDIRECTや別のポリシーが適用されることがあります。その場合、サーバー一覧で遅延が短く表示されても、そのリクエストが該当サーバーを使用している証明にはなりません。

並べ替えは表示方法。選択中の項目は別途確認

遅延順に並べ替えると、現在のテストで応答の速い項目を見つけやすくなります。ただし、並べ替えは自動選択や継続的な状態確認と同じではありません。並べ替え後に選択中のマークを確認し、一覧の先頭が使用中だと決めつけないでください。一部の項目だけテストされた場合は、未測定、タイムアウト、測定済みの結果を同じものとして扱わず、結果がどの範囲をカバーしているか確認してください。

一括テスト中は、サブスクリプションの更新や項目の移動を同時に行わないようにしてください。一覧が変わると、テストした対象と名前・位置を対応付けにくくなります。まずテストを完了し、比較する項目を記録してから更新や整理を行いましょう。再テストではネットワークと方法をそろえてください。そうすれば、変化が新しいパラメーターによるものか、デバイスのネットワークが切り替わったためかを判断しやすくなります。

[Evidence]

遅延の数値だけでなく、テスト方法、基本ネットワーク、選択した項目、実際のエラーを記録すると、トラブルの原因を調べやすくなります。記録を共有する際は、認証情報を削除してください。

実際に使う際は、遅延と通信速度も区別してください。応答時間が短くても、大容量ファイルの転送が速いとは限らず、長時間の接続が安定するとも限りません。テスト対象、ネットワーク、用途によって条件が異なるため、本ページでは一律の合格値を設けていません。結果が大きく変動する場合は、まず条件をそろえて再現を確認してください。高頻度で一括テストを行うと、不要なリクエストが増える可能性があります。次に、失敗した段階に応じて、パラメーター、サブスクリプション、ルールの各章を確認しましょう。