Subscribe：サブスクリプションとサーバーの関連付け
サブスクリプションは、再取得できるリモートリソースのURLです。サーバー項目は、クライアントが接続時に使うパラメーター一式を指します。見た目が似ていても、両者を混同しないでください。サブスクリプションの更新では複数のサーバー情報が返されることがありますが、単一の共有リンクが示すのは通常1台のサーバーです。インポート前にどちらの情報かを確認すると、サブスクリプションURLをサーバーのアドレス欄に入力する間違いを防げます。また、更新後に項目が再表示される理由も把握できます。
情報の種類を確認してからSubscribeを開く
ご利用のサービス提供元からサブスクリプションを入手したら、クエリパラメーターを書き換えずに元の文字列を保管してください。サブスクリプションは通常URL形式ですが、ブラウザーで開けるかどうかだけでは判断できません。ログインページ、ヘルプページ、サブスクリプションのリソースが同じドメインを使うこともあります。サービス提供元の説明を確認し、そのURLがShadowrocket用のサブスクリプションなのか、アカウント管理用または一般的な案内ページなのかを見分けてください。
Homeの追加メニューからSubscribeに対応するサブスクリプションの種類を選択します。画面によってはAdd ServerのTypeにSubscribeが表示されます。画面を開いたら、URL欄に完全なアドレスを貼り付け、見分けやすいメモを入力して保存し、更新を実行してください。プラットフォームによってメニューの配置は異なります。ボタンが画面の決まった位置にあるかではなく、SubscribeとURLの用途を基準に判断してください。
メモには、リソースの出所や用途を「個人用／日常」「個人用／予備」のように記録すると便利です。完全なサブスクリプションURL、アカウントのパスワード、アクセス用の認証情報は記載しないでください。メモは一覧を整理するためのもので、サーバー側のパラメーターを代替するものではありません。メモを編集しても実際のサーバーアドレスは変わらず、期限切れの認証情報が有効になることもありません。
項目と更新結果を確認してインポートを完了する
サブスクリプションを保存したら、その配下にサーバー項目が表示されるか、更新時にエラーが出ていないかを確認します。サブスクリプション名が表示されただけでは、利用可能なサーバーを取得できたとは限りません。一覧が空の場合は、アドレスが完全か、現在のネットワークからリソースにアクセスできるか、サーバーがクライアントで認識可能なデータを返しているかを順に確認してください。まずエラー内容を記録し、再追加が必要か判断します。同じサブスクリプションを何度も登録しないようにしましょう。
サブスクリプション内のサーバー名は、通常リモートのデータによって決まります。更新後に名前、件数、並び順、接続パラメーターが変わっても、必ずしもクライアントが情報を失ったとは限りません。リモート側で古い項目が削除されたり、設定が変更されたりした可能性もあります。変更を追跡する場合は、更新前後のサブスクリプション名と項目名を記録して、どのサブスクリプションに属するかを比較してください。一覧の合計件数だけで更新の正常性を判断しないでください。
サブスクリプションのインポート後は、使用可能なサーバーを選び、接続を確認する必要があります。サブスクリプションはサーバー情報を提供し、Configのルールはトラフィックの処理方法を決定します。両者は別の役割です。サーバー情報があっても適切なGlobal Routingの設定がなければ、実際のアクセス経路が想定と異なる場合があります。ルールファイルがあっても接続できるサーバーがなければ、PROXY接続はできません。
| 情報の種類 | インポート後の主な項目 | その後の管理方法 |
|---|---|---|
| Subscribe URL | サブスクリプションとサーバー一覧 | 元のURLにリクエストして更新 |
| 単一の共有リンク | 独立したサーバー項目 | 再インポートまたは手動編集 |
| Shadowrocket .conf | Configファイル | ルールと設定内容を管理 |
サブスクリプションURLは認証情報として保管
サブスクリプションURLにはアカウントを特定できるパラメーターが含まれることがあります。機密情報として保管してください。チャット、スクリーンショット、問い合わせ文に貼り付ける前に、URL全体に含まれる認証情報とクエリパラメーターを隠してください。ドメインだけを隠しても意味がない場合があります。リソースへのアクセスに必要な情報が後半部分に含まれていることがあるためです。問い合わせでは、プロトコルの種類、エラーの分類、発生時の操作手順を伝えれば十分です。アクセス可能なサブスクリプションURLを公開する必要はありません。
URLが漏えいした可能性がある場合は、ご利用のサービス提供元にサブスクリプションの認証情報をリセットできるか確認し、クライアントに保存したURLを置き換えてください。ローカルのメモを編集したり、サーバー項目を1つ削除したりしても、古いURLは無効になりません。新しいURLに置き換えたら、まず更新し、1つの項目をテストしてください。新しいリソースが使えることを確認してから古いサブスクリプションを削除すれば、情報を確認する前に元の設定を失わずに済みます。
Add Server：プロトコルに応じたサーバーパラメーターの入力
手動追加は、サーバー情報一式が手元にある場合や、特定の項目を確認したい場合に適しています。Add Serverを開いたら、まずTypeを選び、該当する項目を入力してください。初期表示のフォームにすべての情報を入力してからプロトコルを切り替えるのは避けましょう。プロトコルごとに必須項目や選択肢が異なります。種類を切り替えた後は、入力済みの内容が引き続き適用できるかも確認してください。
アドレス、ポート、認証情報を個別に確認
Addressには通常、サーバーのドメイン名またはIPアドレスを入力します。Webページのパスやプロトコルのプレフィックスは含めないでください。Portはサーバー側の待ち受けポートと一致させます。管理画面のポートをプロキシ用ポートとして入力しないでください。IPv6の場合はフォームに用意されたアドレス欄とポート欄を使い、Webアドレスの形式を独自に当てはめないでください。元の情報が完全なリンク形式でしか提供されていない場合は、リンクからインポートしてください。
認証情報はプロトコルに応じて確認してください。Shadowsocksでは暗号化方式とパスワード、VMessとVLESSではそれぞれのユーザー識別子、Trojanでは認証情報が一般的です。長い文字列だからといって、どの項目に入力すべきか判断できるわけではありません。貼り付けた後、先頭や末尾の空白、改行、大文字・小文字を確認してください。特に画面上の自動折り返しを、元の認証情報に含まれる改行と取り違えないようにしましょう。
説明に「パスワード」と「アドレス」しか記載されていない場合、完全な接続に必要な情報が足りないことがあります。サーバー側で特定の転送方式、TLS、SNI、パス、その他のオプションが必要な場合もあります。その場合は、ご利用のサービス提供元から必要な情報を入手してください。スイッチを順に切り替えて、保存できそうな値を探すのは避けましょう。フォームに保存できても、入力形式が受け付けられただけであり、サーバーがそのパラメーターを認証したとは限りません。
| パラメーターのグループ | 確認する内容 | よくある取り違え |
|---|---|---|
| Address / Port | 接続先と待ち受けポート | WebページのURLをサーバーアドレスとして入力 |
| 認証パラメーター | パスワード、ユーザー識別子、鍵 | 別のプロトコル用の認証情報を入力 |
| TLS / SNI | 有効化の有無と検証名 | SNIをAddressとして入力 |
| 転送パラメーター | 転送方式、Host、パス | パスの入力漏れや大文字・小文字の変更 |
TLSと転送パラメーターは別の設定
TLSは接続の暗号化と関連する検証を担い、転送パラメーターはプロトコルデータをどのように伝送するかを指定します。TLSを有効にしても転送パスを省略できるわけではありません。Hostを入力しても、SNIが正しく設定されたことにはなりません。資料に記載されたAddress、Host、SNIが異なる場合は、それぞれ対応する項目に入力してください。「統一」するために、3つの欄を同じドメイン名に書き換えないでください。
証明書の検証に失敗した場合は、まず端末の時刻、SNI、サーバー証明書の状態、情報に変更がないかを確認してください。証明書検証の無効化を一般的な解決策として使わないでください。検証を回避すると接続先の誤りを見落とす可能性があり、サーバーの身元を確認する能力も低下します。特定のテスト環境を調査するために無効化が必要な場合は、変更内容を記録し、テスト終了後に元の検証設定に戻してください。
WireGuardなどのプロトコルは鍵やインターフェースのパラメーターが異なるため、一般的なユーザー名・パスワード用フォームを流用できません。秘密鍵は機密情報です。スクリーンショットや通常のメモに記載しないでください。ローカルアドレス、ピアの公開鍵、ルーティング範囲に関する項目は、一組の設定として確認してください。値を1つだけ置き換えると、ハンドシェイクは成功しても、トラフィックが想定した宛先に届かないことがあります。
保存後、まず必要最低限の確認を行う
手動で追加した項目には用途がわかるメモを付け、「手動」などの識別子を記載して、サブスクリプション由来の項目と区別しましょう。保存後はそのサーバーを選び、同じネットワーク環境で接続とアクセスを一度テストしてください。その間、ルールファイル、DNS、複数の転送オプションを同時に切り替えないでください。接続できない場合は元の情報に戻って各項目を比較し、「パラメーターの誤り」と「現在のネットワークから到達できない状態」を分けて調べましょう。
サブスクリプション内のサーバーを変更する場合は、まず独立した項目としてコピーしてテストする方法を検討してください。リモート管理されている項目を直接編集すると、次回の更新で元のパラメーターに戻され、ローカルの変更が失われることがあります。独立したコピーなら試験しやすい一方、サブスクリプションの新しいパラメーターは自動で反映されません。テストに成功した後も、管理方法を記録し、自動更新される項目と取り違えないようにしてください。
プラットフォームや画面の言語によって、項目名が多少異なることがあります。他のプロトコルのスクリーンショットをそのまま真似するのではなく、項目の用途とプロトコル情報を照らし合わせてください。よく使われる画面用語は画面表示の英語用語一覧をご覧ください。元の情報を保管し、一度に変更するパラメーターを1つに絞り、変更のたびに検証すると、何度も削除して再作成するより問題を特定しやすくなります。
QRコード・クリップボード：内容を確認してからインポート
QRコード、クリップボード、手入力は情報の入力方法が異なるだけで、サーバー自体の権限や機能は変わりません。QRコードには単一の共有リンク、サブスクリプションURL、通常のテキストなどが含まれる場合があります。クリップボードにもさまざまな内容が保存されます。インポート前に、サーバー、サブスクリプション、Configファイルのどれを取得する想定なのかを確認し、インポート後に結果が想定どおりか照合してください。
Scan QR Codeの読み取りと権限
Scan QR Codeを開くと、システムからカメラへのアクセス許可を求められることがあります。ご自身の情報をスキャンする準備ができている場合に限り、必要な権限を許可してください。以前に権限を拒否した場合は、システムのアプリ設定でカメラへのアクセスを確認できます。カメラが起動しないのは権限または端末側の問題であり、QRコード内のサーバーが無効だという意味ではありません。そのためにサブスクリプションを作り直す必要もありません。
スキャンする前に、QRコード全体が画面に収まり、読み取り用の余白が四辺に残っていることを確認してください。反射、遮蔽、目立つぼけを避けましょう。長いパラメーターを含むQRコードはパターンが細かくなり、縮小しすぎると読み取りに失敗しやすくなります。別の画面に表示されたコードを読む場合は、適度に拡大してください。周囲を切り取り、白黒のパターンだけにしないでください。
QRコードがこの端末内の画像にある場合は、画面に写真ライブラリから読み取る機能が用意されているときに限り、その機能を使ってください。該当する選択肢がない場合は、元のテキスト情報に戻り、リンクをコピーしてインポートできます。写真ライブラリで画像を見られることと、アプリがその画像を認識できることは別です。インポートに関係のないシステム権限を何度も許可しないでください。
クリップボードには情報を1件ずつ完全な状態で保存
ご利用のサービス提供元からリンクをコピーする際は、可能であれば提供元のコピー機能を使い、選択時に先頭や末尾が欠けないようにしてください。コピーしたらすぐにShadowrocketへ戻り、対応するクリップボードのインポート機能を使います。システムから貼り付けの許可を求められたら、実際にインポートするタイミングで許可してください。拒否して内容が読み取られなかったとしても、元のリンク形式が誤っているとは限りません。
チャットアプリ、メール、文書では、リンクの前後に引用符、箇条書き記号、説明文が付加されることがあります。インポート前に実際のリンクだけを残し、「こちらをクリック」などの見出しを一緒にコピーしないでください。長いアドレスが画面上で複数行に見えても、コピーすると1行の場合があります。元のテキストに実際に空白や改行が挿入されている場合は、文字を適当に削除せず、元の情報からコピーし直してください。
特に問題を調査しているときは、内容を明確に判別できる情報を1件ずつインポートしてください。複数のサブスクリプションURL、単一リンク、説明文をまとめて貼り付けると、一部しか解析されなかったり、想定と異なる項目が作成されたりすることがあります。一括処理の前に1件で形式を確認し、インポート後は成功メッセージだけでなく、件数と所属先も確認してください。
インポート後に3段階で確認
第1段階では、想定した種類の項目が作成されたかを確認します。サブスクリプションをインポートした場合は、URLが似たサーバー項目だけでなく、更新可能なサブスクリプションが表示されるはずです。第2段階では、パラメーターが揃っているか確認します。項目を開き、Type、Address、Portと必要な転送設定を確認してください。第3段階では接続を確認します。項目を選んでテストし、利用権限のあるサービスにアクセスしてください。
同じ情報を手入力すれば接続できるのに、QRコードからのインポートで失敗する場合は、すぐにQRコードが「無効」だと判断せず、双方の項目を比較してください。転送パラメーターが省略されている場合や、共有形式が現在のインポーターで対応していない場合があります。比較のために両方の項目を残す場合は、メモを変えて識別し、後のテストで別の項目を誤って選ばないようにしてください。
反対に、QRコードからインポートした項目は使えるのに手入力では接続できない場合は、入力漏れや特殊文字を確認してください。共有リンクにTLSやパスのオプションが含まれていても、画面上ではサーバー名しか見えないことがあります。名前とポートだけを比較して同じ設定だと判断せず、詳細を開いて各項目を確認してから重複を整理してください。
インポート後、不要になったクリップボードの内容を消去し、一時的に保存した認証情報のスクリーンショットも削除できます。情報が別の端末やクラウドに同期されている場合、この端末から消去してもすべてのコピーが削除されるわけではありません。読み取り時の問題を他の人に説明する際は、エラー表示、情報の種類、操作したメニューを伝えれば十分です。有効なQRコードや完全なリンクをそのまま送らないでください。
更新方法：タイミングを調整し、元に戻せる状態を保つ
サブスクリプションの更新はリモート情報を再取得する操作であり、ローカルの一覧が残っているか確認するだけではありません。リモートの内容が変わると、サーバーの追加、削除、変更に加えて、メモや並び順も更新されることがあります。適切な更新方法を決めるときは、情報の変更頻度、現在のネットワークからサブスクリプションにアクセスできるか、ローカルで保持したい手動変更があるかを考慮してください。更新回数を増やせば信頼性が上がるというわけではありません。
初回更新は手動で実行し、結果を確認する
サブスクリプションを初めて登録したら、まず手動で更新します。リクエストが成功するか、返された内容を解析できるか、項目が想定どおりかを確認してください。一連の動作が正常だと確認してから、画面に実際に表示される選択肢に従って自動更新を設定します。初回のインポートが完了する前に複数の自動処理を同時に有効にすると、一覧の変化が自分の操作によるものか、バックグラウンド更新によるものか判断しにくくなります。
更新前に、現在使えるサーバーの名前、所属するサブスクリプション、使用中のConfigファイルを記録してください。重要な手動変更は、独立したコピーとして保存するかローカルにバックアップしておきます。サブスクリプション内の項目はリモートの情報で管理されるため、更新後もローカルの変更が残るとは限りません。特定のパラメーターをサブスクリプションの値と異なる状態で使い続ける必要がある場合は、偶然上書きされないことに頼らず、独立した項目として管理してください。
自動更新の間隔は実際の必要性に応じて設定してください。情報が長期間安定しているなら、短い間隔で繰り返しリクエストする必要はありません。サーバー側の変更に対応している場合は、情報が更新されたことを確認してから手動で一度更新できます。頻繁な再試行はリモート側のレート制限を招き、同じエラー記録を増やすことがありますが、無効なURL、認証エラー、形式の不一致を解決するものではありません。
通信エラーと内容のエラーを分けて判断
リクエストがタイムアウトする場合は、現在のネットワークとサブスクリプションURLへの到達性を確認してください。内容は返っているのに解析できない場合は、ログインページ、エラーページ、別の形式に変わっていないかを確認します。画面に認証関連のエラーが表示された場合は、ご利用のサービス提供元にURLや認証情報がまだ有効か確認してください。この場合、ローカルのサーバーメモを変更してもサブスクリプションのリクエスト結果には通常影響しません。
サブスクリプションリソースへのアクセス経路とサーバーへの接続経路は、同じとは限りません。サーバーに接続できても、サブスクリプションURLにアクセスできるとは限りません。サブスクリプションを更新できても、含まれるすべてのサーバーに接続できるとは限りません。更新結果と接続テスト結果を別々に記録し、片方の成功だけで、もう片方に問題がないと判断しないでください。
調査では条件を一度に1つだけ変更してください。たとえば同じサブスクリプションURLを維持し、別の利用可能なネットワークに切り替えて再試行します。URL、DNS、Global Routing、複数のサーバーパラメーターを同時に変更すると、復旧しても原因を特定できません。更新によって既存の一覧が置き換わる場合は、多数の項目に影響する操作を行う前に、古い情報がバックアップされているか確認してください。
| 症状 | 優先して確認する項目 | いったん避ける操作 |
|---|---|---|
| リクエストがタイムアウトする | 現在のネットワークとリソースへの到達性 | サブスクリプションを何度も削除する |
| 内容を解析できない | 返された形式とエラーページの有無 | エンコード済みの本文を書き換える |
| 更新後に項目が減った | リモート側の変更とサブスクリプションの所属先 | 残りの一覧をすぐに全消去する |
| ローカルのパラメーターが元に戻った | サブスクリプションのデータで上書きされたか | 同じリモート項目を編集し続ける |
更新後に範囲を絞って動作確認
成功の表示が出た後、少なくともよく使う項目を1つと予備の項目を1つ確認し、プロトコル、アドレス、接続状態に問題がないかを調べてください。サーバー名が変わった場合は、ルールや選択履歴がその名前に依存していないかも確認します。一覧に表示されていても、以前固定で使っていた項目が残っているとは限りません。リモート側で項目名が変更されたり統合されたりした場合は特に注意してください。
更新に失敗しても古い項目で接続できる場合は、いったん以前の状態を維持して、サブスクリプションのリクエスト問題を先に調べてください。エラー表示を消すために一覧全体を空にしないでください。更新に成功した後で接続できなくなった場合は、更新前後のパラメーターを比較し、ご利用のサービス提供元に変更内容を確認します。古い名前に戻すだけでは、変更済みのサーバー認証情報は復元されません。
最後に、アプリの更新とサブスクリプションの更新を区別してください。前者はShadowrocket本体を更新し、後者はリモートのサーバー情報を更新します。アプリの入手方法とインストール手順はダウンロードページをご覧ください。サブスクリプションを更新してもクライアントは自動でアップグレードされません。また、クライアントを再インストールしても無効なサブスクリプションURLは自動で修復されません。それぞれ別の手順で確認し、記録してください。
複数サブスクリプションの整理：名前と所属先で重複を減らす
複数サブスクリプションの管理で大切なのは、すべてのサーバーを1つの長い一覧にまとめることではありません。各項目の出所、更新されるタイミング、独立したコピーがあるかを把握することです。まず所属先を整理し、それから並べ替えや削除を検討してください。名前だけで重複を判断すると用途の異なるサーバーを誤って削除することがあります。件数だけで整理できたかを判断すると、使用中の独立した設定まで消してしまうおそれがあります。
サブスクリプションと独立した項目に2段階の名前を付ける
サブスクリプション名には情報の出所と用途を、サーバーのメモには個々の接続先を記録します。この2段階の名前は互いに置き換えられません。すべてのサーバー名を同じサブスクリプション名にすると、項目ごとの差がわからなくなります。一方、サーバー側の名前だけでサブスクリプションの所属先を記録しないと、複数の一覧に同じ名前がある場合に、どのグループを更新または削除すべきか判断しにくくなります。
サブスクリプション名には「日常／個人」「テスト／個人」のように、用途とリソースグループを短く組み合わせられます。手動コピーには「手動」と付け、元のサブスクリプション名を記録してください。各項目に完全な日付や長い説明を書く必要はありません。パスワードやサブスクリプションの認証情報を名前に含めないでください。名前は項目を識別するためのものであり、機密情報の一覧になってはいけません。
1つのサブスクリプショングループの更新と確認を終えてから、次のグループに進んでください。サブスクリプションを1つ追加するたびに、同じURLがすでに登録されていないか、そこに含まれるサーバーを単独リンクとしてインポートしていないかを確認します。同じサブスクリプションを何度も追加して異なるメモを付けると、重複した出所でも名前は同じとは限りません。サブスクリプション自体に戻り、所属先とURLを比較してください。
サーバー名だけで重複を判断しない
名前が同じ2つの項目でも、アドレス、ポート、認証情報、転送パラメーターが異なる場合があります。名前が違っても、実際には同じ接続パラメーターを使っていることがあります。重複を整理する際は、まずプロトコルの種類と接続先アドレスを比較し、次にポート、認証情報、重要な転送設定を確認してください。認証情報の比較は端末内で行い、照合のために公開スプレッドシートやWebツールへアップロードしないでください。
接続パラメーターが同じでも、管理方法の違いを考慮してください。一方はサブスクリプション由来でリモート更新され、もう一方は独立した手動コピーで更新されません。削除する前に、どちらの管理方法を残すか決めてください。手動コピーに必要なローカル変更が含まれている場合、アドレスが同じだからといって削除してはいけません。古い一時的なテスト記録にすぎない場合は、サブスクリプション項目を検証してから整理できます。
サブスクリプション内のサーバーを削除しても、リモートの一覧にその項目が残っていれば、次回更新時に再表示されることがあります。これは重複整理の失敗ではなく、ローカルでの削除とリモート管理の範囲が異なるためです。画面にサブスクリプション単位の絞り込みや管理機能がある場合は、その機能に合わせて設定してください。該当する機能がない場合は、更新でリモートの項目が復元されることを前提とし、一覧の見た目を保つために何度も削除しないでください。
一度のテスト結果ではなく、利用目的ごとにグループ分けする
日常、予備、テストなど、実際の用途を基準に整理すると長期的に管理しやすくなります。1回の遅延測定結果はそのときのネットワーク状況を示すだけで、恒久的な分類基準にはなりません。測定が遅かった項目をすべて常用グループからすぐ移すと、ネットワークを変えるたびに整理し直すことになります。一覧全体を頻繁に作り直すより、検証済みの予備項目を少数残す方が管理しやすくなります。
画面に並べ替えや移動の機能がある場合は、よく使うサブスクリプションやサーバーをアクセスしやすい場所に配置できます。現在の画面で並び順をカスタマイズできない場合は、わかりやすいメモやグループ表示を使い、すべてのプラットフォームで同じ順番にすることにこだわる必要はありません。リモート更新で元の並び順が変わることもあります。「上から3番目」をサーバー識別の基準にしないでください。
整理する際は、明らかに重複したサブスクリプション、次に一時的なコピー、最後に長期間使っていないものの復元する可能性がある情報の順で処理してください。各回で対象を1種類に絞り、現在選択中のサーバーに影響がないか確認します。接続に必要な情報をグループごと削除しないでください。先に検証済みの項目へ切り替えてから整理するのが安全です。
整理後は、残した各サブスクリプションを更新できるか、よく使う各グループに利用可能な項目が少なくとも1つあるかを確認し、新しい管理状態を保存してください。グループをまとめて整理する方法や重複項目の例は、複数サブスクリプション管理の記事をご覧ください。長期的な管理では、一覧をできるだけ短くするより、所属先が明確で変更を追跡できることが重要です。
遅延テストと並べ替え：接続環境を踏まえて結果を確認
遅延テストは特定の測定方法における応答を確認するもので、アプリ全体の使い勝手をそのまま示すものではありません。数値が小さい項目でも、実際のアクセスでは帯域幅、パケットロス、認証、TLS、接続先サービスの応答に影響されることがあります。タイムアウトした項目も、測定対象と方法を踏まえて判断してください。まず何を測定しているかを明らかにし、その結果がサーバー選択に十分な根拠となるか検討しましょう。
ネットワーク、テスト方法、比較対象を揃える
Homeまたは関連するテスト画面からConnectivity Testを実行する際は、画面にどの測定方法が表示されているか確認してください。サーバーまでの特定の段階だけを確認する方法もあれば、プロキシ経由で特定の接続先へリクエストする方法もあります。同じ方法、同じネットワーク、近い時刻に取得した結果であれば直接比較できます。条件の異なる過去の結果を混ぜて並べ替えないでください。
まずよく使うサーバーを少数選んでテストし、測定対象に問題がないことを確認してから範囲を広げてください。長い一覧を一度にテストすると、端末のネットワーク状態や同時接続数の影響を受ける場合があります。すべての項目がほぼ同時にタイムアウトする場合は、各サーバーが無効だとすぐに判断せず、端末のネットワーク、測定対象、現在の設定を確認してください。既知の利用可能な項目を1つ基準として使うと、問題を特定しやすくなります。
1回の測定結果は一時的な変動の影響を受けやすいものです。候補となる項目を数回テストし、最小値だけでなく、結果が安定しているか、頻繁にタイムアウトしないかを確認してください。Wi-Fiやモバイルネットワークを切り替えた場合、以前の並び順は当てにならないことがあります。実際に利用する環境で改めて確認し、1回の測定結果をサーバー固有の固定値として扱わないでください。
サーバーへの接続と接続先へのアクセスを区別する
サーバーに接続できても、プロキシプロトコルの認証に成功したとは限りません。プロトコル認証に成功しても、接続先のWebサイトが正常に応答するとは限りません。調査では、ネットワーク到達性、プロトコルのハンドシェイク、接続先へのリクエストという3段階に分けて記録できます。どこかの段階で失敗した場合は、その段階に関係するパラメーターを優先して確認し、すべての失敗を「遅延が大きすぎる」と片付けないでください。
実際のアクセスを確認するには、Global Routingも確認してください。Configモードでは有効なルールに従ってポリシーが決まり、Proxyモードではプロキシ経由のトラフィックを直接確認しやすくなります。Directモードでは、サーバーのプロキシ接続が正常かどうかを検証できません。ここで示したモード名は画面上のConfig、Proxy、Directです。テスト後は日常利用するモードに戻し、一時的な設定をそのまま残さないようにしてください。
| Global Routing | 診断の目的 | 確認が必要な点 |
|---|---|---|
| Config | 実際のルールによる振り分けを確認 | 接続先がDIRECTまたはREJECTに一致することがある |
| Proxy | プロキシ接続経路を集中的に確認 | システムやConfigの例外設定の影響が残る |
| Direct | Direct接続時の動作を確認 | 選択中のサーバーが利用できる証明にはならない |
Configモードで接続先がDIRECTに一致する場合、アクセスに成功しても選択したサーバーが動作している証拠にはなりません。REJECTに一致して失敗しても、サーバー自体に到達できないとは限りません。現在のルール、接続記録、接続先ドメインを照合して、実際に適用されたポリシーを確認してください。関連するルールキーワードは用語集をご覧ください。特定の接続先のテスト結果だけを理由に、サブスクリプション全体をすぐに置き換えないでください。
並べ替えは候補を絞るために使う
テスト結果を並べ替えたら、結果が安定している項目をいくつか選び、実際に必要なサービスで確認してください。対話型のリクエスト、長時間のデータ転送、持続接続ではネットワークへの要求が異なるため、短いリクエストを1回テストしただけですべての用途を評価することはできません。サーバーのメモに記載された速度や用途も、クライアントが測定して確認した結果とは限りません。
日常の管理には、安定して使える候補を1つと、検証済みの予備を1つ残しておけば十分な場合が多くあります。予備に切り替えるときは、比較しやすいように同じConfigと同じ接続先サービスを使ってください。ルール、ネットワーク、サーバーを同時に変更するとアクセスが回復しても原因がわからなくなり、次に同じ問題が起きたときも再調査が必要になります。
テストは正常なのに接続後に一部のアプリで問題が起きる場合は、並べ替えを何度も繰り返すのではなく、DNS、ルールの照合、アプリに残っている接続、接続先サービスの制限を調べてください。アプリによっては以前確立した接続を再利用します。設定を変更した後は、新しい経路を確認するためにリクエストを再実行してください。比較の前にテスト対象への古いリクエストを終了し、キャッシュの結果を現在の設定によるものと誤認しないようにしましょう。
今回のネットワーク環境、テスト方法、選択した項目、最終的なアクセス結果を記録してください。すべての測定値を保存する必要はありません。「どの条件で使えたか、どの条件で失敗したか」が役立つ記録です。初回接続でよく止まる箇所は初心者向けFAQも参考にし、本章の手順に従って段階ごとに原因を調べてください。
削除とバックアップ：復元範囲を確認してから整理
削除は対象を最小限にし、バックアップは対象範囲を先に確認してください。サーバー、サブスクリプション、Configファイルは別々の項目です。どれか1つを削除しても、他の項目の管理を代替することは通常できません。整理する前に、削除したいのが画面上の項目、リモート情報のグループ全体、使わなくなったルールのどれなのか明確にしてください。個別の問題を「すべてやり直す」ことで解決しようとしないでください。
削除前に現在の接続への影響を確認
現在選択中のサーバーを削除する場合は、まず検証済みで残す項目に切り替え、接続が正常なことを確認してください。サブスクリプション全体を削除する場合は、配下に使用中の予備項目がないか、ルールや選択履歴が特定の名前に依存していないかを確認します。削除によって一覧が短くなるだけでなく、今後選択できる接続先も変わることがあります。依存関係を整理してから削除してください。
サブスクリプション内のサーバーを1つ削除しても、次回更新時に再表示されることがあります。サブスクリプションそのものを削除すると、その中のサーバーも一緒に削除される場合があります。影響範囲は画面に表示される確認内容を基準にしてください。実行前に確認メッセージをよく読み、ボタンの文言の長さから影響を推測しないでください。一時的に無効にしたいだけなら、削除するのではなく、選択先を切り替えるか、画面に用意された無効化機能を使ってください。
Configファイルの削除とサーバーの削除も分けて考えてください。現在使用中のルールファイルはDIRECT、PROXY、REJECTの照合に影響します。ファイルを削除または置き換えると、サーバーのパラメーターが変わっていなくてもアクセス動作が変化します。ルールファイルを整理する前に、日常利用で残すConfigを決め、自分で追加したローカルネットワークやドメインのルールがあるか記録してください。
バックアップはファイルの有無より対象の確認が重要
バックアップでは、サブスクリプションURL、独立したサーバー、現在のConfig、重要なローカル変更、再設定が必要な接続オプションを確認してください。エクスポート機能によって対象は異なります。単一のサーバー共有はConfig全体のバックアップを代替できません。また、ルールのみの.confファイルではすべてのサーバーを自動で復元できません。エクスポート後はファイルまたは内容の種類を確認し、保存できたというだけで復元情報がすべて揃ったと判断しないでください。
Settingsまたは対象の管理画面では、実際に表示されるエクスポート、バックアップ、共有機能のみを使用してください。完全なバックアップ機能がない場合は、復元に必要な項目を個別に保存し、簡単な一覧を作成します。それぞれの用途と復元順を記録すれば十分です。通常のメモにすべてのパスワードを平文で重複保存して、漏えいのリスクを増やさないでください。
バックアップにはサブスクリプションの認証情報、サーバーのパスワード、ユーザー識別子、秘密鍵が含まれることがあります。アクセス制限のある、ご自身で管理できる場所に保管してください。システムのクラウドストレージに同期する場合は、アカウントの保護状態と、ログイン中の他の端末も考慮します。バックアップをチャットに添付して放置したり、形式の確認を依頼するために有効な設定ファイル全体を送信したりしないでください。
順番に復元してから接続を確認
復元する際は、まずクライアントが正しい入手先のものか確認し、次にサブスクリプションと独立したサーバーをインポートします。その後Configを復元し、最後にGlobal Routingとその他の接続オプションを設定してください。iPhone / iPadで正規版を確認する際は、開発元がShadow Launch Technology Limitedであること、公式アイコン、アプリID 932747118を確認します。その他のプラットフォームの入手方法と当サイトのインストーラーは、正規版の確認セクションにまとめています。
サブスクリプションURLを復元したら一度更新し、リモートの情報が変わっていないか確認してください。古いバックアップ内のサーバーをインポートできても、認証情報や接続先アドレスがすでに無効になっている場合があります。古い項目が表示されるだけでは、復元が完了したとは言えません。独立したサーバーは各項目を個別に確認してください。サブスクリプション管理から外れたコピーが更新によって自動修復されることはありません。
復元後は、よく使う項目、予備の項目、現在のルール、実際の接続先へのアクセスを順に確認してください。On Demandを使っている場合は、自動接続が想定どおり動作するかも確認します。ただし、基本接続を確認する前に自動動作を同時に有効にしないでください。問題が見つかった場合は元のバックアップを残し、復元した情報を少しずつ調整します。比較に使える最後の状態を上書きしないようにしてください。
端末を買い替えた後も、過去の情報をすべて長期間残す必要はありません。新しい端末で更新、接続、日常使用するルールが正常に動くことを確認してから、古い端末の認証情報や一時的なエクスポートファイルを整理してください。古い端末を自分で管理できなくなった場合は、ご利用のサービス提供元に、無効化または更新が必要な認証情報がないか確認します。端末からアプリを削除しただけでは、以前コピーしたURLやバックアップまで無効になるとは限りません。
日常の管理は、変更前にバックアップし、変更時は1種類の項目だけを調整し、変更後にテストし、安定を確認してから整理する、という流れを基本にしてください。接続手順を最初から確認する場合はクイックスタートガイドに戻り、複数のリソースを整理する場合は本ページの複数サブスクリプションの章をご覧ください。復元手順を明確にしておけば、次回の更新やトラブル対応も管理しやすくなります。