01 · Subscribeから追加する
サブスクリプションと個別サーバーの違い
Subscribeは、データを再取得できる登録先を保存します。Add Serverは、手動で入力したサーバー情報を個別に保存します。どちらも最終的にはHomeの一覧にサーバーが表示されますが、管理方法は異なります。サブスクリプション内の項目は通常、取得したデータに基づいて管理されます。手動登録した項目は、必要に応じて個別に編集します。まず、手元の情報がどちらに当たるか確認してください。クライアントが読み込み、定期的に更新するリンクならSubscribeを使います。アドレス、ポート、認証情報、プロトコル設定だけがある場合は、次章のAdd Serverで登録します。どちらも一覧に表示されるからといって、サーバー共有リンクをサブスクリプションのURL欄に入力しないでください。
ShadowrocketのHomeで追加画面を開き、サブスクリプションの追加方法としてSubscribeを選択して、手元にある完全なリンクを該当するURL欄に入力します。画面の状態によって追加画面の位置や項目の並びは異なることがあります。入力欄にテキストを貼り付けられるだけで判断せず、種類がSubscribeになっていることを確認してください。保存したら一覧に戻り、読み込みと解析が終わるまで待ちます。初めて登録する前に、元のリンクを一時的にメモアプリへコピーして、先頭や末尾が欠けていないか、前後に空白や改行が混入していないか確認しておくと安心です。
保存できても、解析できたとは限りません
読み込みには、URLの保存、ネットワーク経由での応答取得、応答内容からShadowrocketが認識できるサーバー項目への変換、という少なくとも3つの段階があります。一覧にサブスクリプション名が表示されても、確認できるのは最初の段階だけです。名前はあるのにサーバーが表示されない場合は、後の2段階も確認してください。まず同じネットワーク環境で元のリンクが有効かを調べ、次に、そのリンクがログイン画面やエラーページ、個別の共有テキストではなく、アプリに対応したサブスクリプションデータを返すか確認します。URLのクエリパラメーターを根拠なく変更しないでください。パラメーターがデータの一部である場合があり、1文字削除しただけで別の応答になることがあります。
登録後に項目が表示されても見分けにくい場合は、まずサブスクリプションに自分で識別しやすい名前を付け、その後で一覧を整理してください。名前は端末上で管理するための目印にすぎず、サーバーアドレスを修正したり、サーバー側のデータ確認の代わりになったりするものではありません。初めて使う場合は、まず内容を把握しているサブスクリプションを1つだけ読み込み、サーバー項目が表示されるか、どの登録元の項目か判別できるか、必要に応じて更新できるかを確認してから次を追加するのがおすすめです。解析に失敗した際、原因を特定しやすくなり、複数の登録元や重複項目を何度も確認せずに済みます。
サブスクリプションは変化するリモートデータです。現在表示されているサーバー数が今後も変わらないとは限りません。次回の更新で項目が増減したり、名前が変わったりすることがあります。特定のアドレスを個別に継続管理したい場合は、もともとサブスクリプションで管理されている項目かを確認してから、手動登録するか判断してください。また、アプリの購入とデータの読み込みを混同しないようにしましょう。App Storeで行うのはアプリの入手、Subscribeで行うのは手元にあるデータの読み込みです。アプリの正規性を確認する場合は、正規アプリを確認する3つのポイントで開発者、アイコン、アプリIDをご確認ください。
02 · Add Serverで手動入力する
手元の情報どおりにプロトコルを選ぶ
個別のサーバー情報だけをお持ちの場合は、Homeの追加画面でAdd Serverを選び、手元の情報に記載されたプロトコルに従って入力します。プロトコルの選択は、同じ数値に別のラベルを付けるだけではありません。Shadowsocks、VMess、VLESS、Trojan、HTTP、SOCKS5、WireGuard、Hysteria2では、項目の構成、認証方法、通信要件がそれぞれ異なります。プロトコルの記載がない場合は、情報の提供元に確認してください。ポートやアドレスだけから確実に判断することはできません。入力時は、パスワード、識別子、ホスト名、パスなどの大文字・小文字、句読点、特殊文字を含め、元の情報をそのまま保持してください。見やすくするために独自に書き換えないでください。
AddressにはサーバーのドメインまたはIPアドレス、Portには該当サービスのポートを入力します。両方をセットで確認してください。通常、アドレス欄にWebページのパスを付ける必要はありません。また、ポート欄にプロトコルの接頭辞は入力しません。完全な形式の共有リンクがある場合は、後述のリンク読み込みを利用できるか先に確認すると、エンコードされた文字列から項目を推測せずに済みます。入力後に保存し、一覧に戻って想定した場所に登録されたか確認してください。保存操作で確認できるのは入力内容が記録されたことだけで、サーバーが接続を受け付けることを保証するものではありません。
認証、TLS、通信設定
認証項目はプロトコルによって異なります。Shadowsocksでは対応する暗号化方式とパスワード、VMessやVLESSでは一般的に識別子と通信方式、TrojanではパスワードとTLS関連設定が重要です。WireGuardはInterfaceとPeerの情報をそれぞれまとめて入力します。TLSを使う場合、SNIで指定するサーバー名とAddressが異なることがあります。安易に置き換えないでください。Allow Insecureは証明書の検証に関係する設定です。まず証明書の名前や有効期間、入力情報を確認し、接続エラーの初期対応として検証方法を変更しないでください。
| 情報の種類 | 入力時のポイント | 主な確認項目 |
|---|---|---|
| アドレスとポート | Address、Port、プロトコルの種類 | ドメインのつづり、ポート番号、情報が有効か |
| 認証情報 | パスワード、識別子、鍵 | 大文字・小文字、コピー時に混入した空白 |
| TLS情報 | SNI、証明書関連の設定 | 名前と証明書が一致しているか |
| 通信設定 | Path、Hostなどプロトコル固有の項目 | 先頭のスラッシュ、指定された表記 |
入力項目が多い場合は、2段階に分けて確認します。まず、プロトコル、アドレス、ポート、認証情報が元の資料と一字一句一致しているかを確認し、次にTLS、通信設定、追加オプションを確認します。これにより、基本項目の誤りと詳細設定の不一致を切り分けやすくなります。複数の項目を続けて変更してすぐテストすると、結果が変わってもどの項目が影響したか分からなくなります。鍵を含む設定を公開の掲示板などに貼り付けないでください。問題を説明する際は、項目の種類、エラーが表示された場所、操作時の状況だけを伝えましょう。
一覧にサブスクリプション由来の項目と手動登録した項目の両方がある場合は、まず手動登録の用途が分かるようにしておきます。サブスクリプションを更新しても、手動登録した情報は自動で修正されません。サーバー設定が変わった場合は、該当する項目を編集してください。逆に、手動入力時の方法をサブスクリプション由来の項目にそのまま適用しないでください。サブスクリプションの内容によっては、次回の更新時に項目が再設定されます。Trojanの各設定項目とWireGuardの情報については、Trojanの設定項目ガイドとWireGuardの設定ガイドをご覧ください。
03 · Scan QR Code・クリップボードから読み込む
読み込む前にQRコードの内容を確認
QRコードを使えば項目を一つずつ入力せずに済みますが、コードはテキストを別の形で表したものです。まず、個別サーバーの共有リンク、サブスクリプションURL、その他のテキストのどれが含まれているかを確認し、読み込み後に何が表示されるべきか判断してください。QRコードで情報が提供されている場合は、追加画面でScan QR Codeを選び、カメラの使用を許可してコード全体を読み取り枠に収めます。認識結果が表示されたら、プロトコルや主な項目を確認してください。コードがぼやけている、隠れている、背景とのコントラストが低い場合は、情報の提供元に鮮明な元のコードを表示してもらいましょう。コードの横にある説明文からアドレスを推測して組み立てないでください。
読み込んだ直後に、新しい項目を接続先として選ばないでください。まず読み込み結果の種類、名前、Address、Portが想定どおりか確認します。Subscribeを読み込んだ場合は、静的なサーバー項目ではなく、更新できるサブスクリプションとして追加されたか確認してください。テキストを認識できないとアプリに表示された場合、原因はカメラの権限だけでなく、QRコードに含まれる内容にもある可能性があります。端末に保存済みの画像を使う場合は、まず画像を読み取れる状態か確認し、画面に実際に表示されている読み込み方法を使ってください。ブラウザーの縮小表示を、元画像全体の代わりとして扱わないでください。
クリップボードから読み込む際は前後の文字を確認
クリップボードからの読み込みは、完全な共有テキストを手元にお持ちの場合に便利です。コピーする範囲はプロトコルの接頭辞から最後の文字までとし、チャットの引用符、番号、説明文を含めないでください。Shadowrocketに戻り、追加メニューからクリップボードに対応する読み込み操作を選び、プレビューの内容を確認します。クリップボードへのアクセス許可を求めるシステムの通知は、コピーした内容を読み込むために表示されます。自分で読み込み操作を開始したことを確認してから、許可するか判断してください。貼り付けた後に空の項目が表示された場合は、元の資料に戻り、クリップボードにリンクが保存されているか確認しましょう。
QRコードとクリップボードは入力方法にすぎず、情報の正確性や有効性を確認するものではありません。同じコードを何度も読み込んだり、同じテキストを繰り返し貼り付けたりすると、一覧に見分けにくい重複項目が残ることがあります。読み込み前に既存の名前を検索し、読み込み後にプロトコル、アドレス、ポートなどを比較してください。テキストに認証情報が含まれる場合は、共有端末の他の入力欄へ何度も貼り付けないようにしましょう。操作後、プライバシー上必要であればクリップボードを一般的なテキストで上書きできます。ただし、元の情報を保管している唯一の場所まで削除しないでください。
「QRコードは認識されるが接続できない」場合は、2つの段階を分けて確認してください。認識できたということは、クライアントがテキストを読み取れたというだけで、ポートが開いていること、認証が正しいこと、サーバーに到達できることを示すものではありません。まず読み込み後の項目を確認し、次に後述のConnectivity Testを使って原因を調べます。別の端末でも同じ情報が必要な場合は、一覧のスクリーンショットから隠れた項目を手入力するのではなく、自分で保管している元の情報を使ってください。端末間で移す場合は特に、サブスクリプションURL全体がそろっているか確認してください。画面によっては読みやすさのためにテキストの一部が省略表示されることがあり、その表示をバックアップとして使うことはできません。
05 · Subscribeの更新方法とトラブル対処
手動更新と自動更新を使い分ける
サブスクリプションは一度読み込めば変わらない端末内の一覧ではありません。手動更新は最新データを確認したいときに自分で読み込みを開始する方法です。自動更新は設定に従って、適切なタイミングで読み込みを試みます。どちらを使うかは、利用頻度やデータの変化に合わせて決めましょう。更新間隔は短ければよいというものではありません。頻繁にリクエストしても、誤ったリンクが正しくなるわけではなく、リモートデータが毎回変わる保証もありません。問題を調べる場合は、自動更新を何度も待つより、手動で1回更新し、前後の一覧の違いを記録するほうが原因を判断しやすくなります。
確認は「登録先の状態」と「サーバー項目の状態」に分けるのがおすすめです。登録先の状態では、URL全体が正しいか、リクエストが成功したか、データを解析できたかを確認します。サーバー項目の状態では、更新後の名前や数、必要な項目が手元の情報と一致しているかを確認します。更新に失敗しても古い項目がHomeに残っている場合、更新データを取得できたとは限りません。画面には以前保存した情報が表示されていることがあります。まずエラー表示を確認し、現在のネットワークと元のURLを調べてください。以前の項目が見えているからといって、更新結果を無視しないでください。
一覧が空になる、減る、重複する場合
一覧が空になった場合は、続けて何度も更新するのを止めてください。正しいSubscribeの項目を選択しているか確認し、リンクの先頭、クエリ部分、末尾を見直します。応答が説明文ではなく、解析可能なデータであることも確認してください。項目が減っても、クライアントが誤って削除したとは限りません。リモート側のデータが変わった可能性もあります。手元に保存した前回の記録と現在の結果を比較し、具体的に消えた名前を特定してから元の情報を確認してください。更新後に重複項目が表示される場合は、同じURLを複数回登録していないか、手動登録とサブスクリプション由来の項目を両方残していないか確認しましょう。
サブスクリプションURLを変更するときは、既存のSubscribeを編集するのか、別の項目として新規登録するのかを明確にしてください。既存項目の編集なら管理場所をそのまま保てますが、編集前に古いURL全体を保存しておき、貼り付けミスが見つかった場合に戻せるようにしましょう。新規登録なら異なるURLを並べて確認できますが、一覧に重複が生じる可能性があります。どちらにするかは比較の必要性に応じて決め、問題の調査中に正常に使える唯一の登録先を削除しないようにしてください。更新の失敗は、プロトコル項目に原因があるとは限りません。データ取得前のDNSやネットワーク状態、URLの応答も読み込みに影響します。
特定のサブスクリプションだけで問題が繰り返し、同じ端末上の他のサブスクリプションは更新できる場合は、その項目のURLと応答内容を優先して確認します。複数の登録先で同時に問題が起きる場合は、まず現在のネットワーク状態を調べてから、それぞれ手動で1回ずつ更新してください。共通のネットワーク問題を複数のリンクの問題と誤認しにくくなります。リンク形式、エンコード、更新タイミングを詳しく確認するには、サブスクリプションの読み込み失敗・サーバー一覧が空になる場合の対処法をご覧ください。問題を調べた後で自動更新を設定し、定期的に結果を確認します。自動更新の設定だけでは、実際の一覧内容を確認したことにはなりません。
06 · 複数のサブスクリプションと手動登録を整理する
管理目的が分かる名前を付ける
Homeに複数のSubscribeや手動登録項目が並ぶ場合、まず「どこから追加した項目か」「どの方法で更新するのか」を明確にします。用途や情報の種類に合わせて、サブスクリプションの登録先に見分けやすい名前を付けましょう。サーバー名だけで登録元を判断しないでください。サーバー名は更新時に変わることがありますが、登録先の名前は管理の手がかりとして使えます。手動登録の項目にも識別しやすいメモを付けられます。ただし、スクリーンショットや画面共有で漏れるおそれがあるため、パスワードやサブスクリプションURL全体を表示名に入れないでください。
整理するときの基本単位は一覧にある似た名前の項目ではなく、登録元です。同じサブスクリプションに複数のサーバーが含まれることもあれば、異なる2つのサブスクリプションに似た名前の項目が含まれることもあります。重複を判断する際は、少なくともプロトコル、Address、Port、主要な通信設定を比較し、それぞれの登録元も確認してください。表示名が同じという理由だけで削除すると、必要な別項目まで消してしまうことがあります。完全に一致するように見える項目が2つある場合は、片方を残してテストし、もう片方の登録元を記録してから、重複の理由を確認しましょう。
変更の順序を記録しておく
サブスクリプションを追加したら、まず新しい登録先からデータを読み込めるか確認し、その後で古い登録先を整理します。大規模な整理を行う前には、自分が正当に保有している元のリンクと手動設定を保存してください。この順序にすれば、誤って削除した場合の再設定の手間を減らせます。不要になった項目は、「一覧で一時的に選ばない」ことと「登録先を削除する」ことを区別してください。前者なら後で確認を続けられますが、後者ではその端末から更新する手段を失う場合があります。保持するかどうかは、1回のConnectivity Testの結果だけでなく、現在の情報が必要かどうかに基づいて判断しましょう。
サブスクリプションと手動登録を併用する場合は、変更の対象がどちらかを特に注意して確認してください。サブスクリプション由来の項目は、次回の更新で変更される可能性があるため、元のサブスクリプションデータを優先して確認します。手動登録はAdd Serverの編集画面で管理します。サブスクリプション内のサーバー項目を一時的に比較したい場合は、変更前の項目と変更の目的を記録しておき、更新後に端末上の変更とサブスクリプションデータの変更を区別できるようにしてください。記録は簡単でかまいません。登録先の名前、操作前の状態、変更した項目、操作後の結果を記載します。
サブスクリプションが複数あると、一覧の項目数だけで状況を判断しにくくなります。数が増える原因には、登録先の追加、サブスクリプション内容の変更、重複登録があります。数が減る原因には、登録先の削除、更新結果の変化、表示範囲の変更があります。原因を調べるときは登録先ごとに確認し、合計数だけから推測しないでください。特定の項目だけを使う場合は、登録元が分かるサーバーを選び、Global RoutingがConfig、Proxy、Directのどれになっているか確認します。ルーティングの状態とサーバーの選択を混同しないようにしてください。
複数の端末で同じ情報を使う場合、名前の付け方を統一しておくと比較しやすくなります。ただし、各端末のローカル一覧が自動で同期されるわけではありません。1台で情報を追加・削除した後は、各端末のSubscribe、手動登録項目、Configの選択状態をそれぞれ確認してください。対応デバイスとシステム要件はApp Storeの掲載内容をご確認ください。本章ではiPhoneとiPadでの情報管理方法を説明しています。一覧の並べ替えを端末間バックアップとして扱わないでください。次章では、並べ替えではなくテスト結果を参考に接続先を選ぶ方法を説明します。
07 · Connectivity Test、遅延、並べ替え
テスト結果から分かること
Connectivity Testでは、現在のネットワーク環境でサーバー項目への接続テストが完了するかを確認できます。長期的なサービス品質を保証するものではなく、すべてのアプリのリクエストが想定したルールで処理されることを証明するものでもありません。テスト前に、対象の項目がどのSubscribeまたは手動登録に属しているか、端末がどのネットワークに接続しているかを確認してください。ネットワーク環境が変われば結果も変わることがあります。成功・失敗のどちらであっても、その時点のテスト条件に対する結果です。サブスクリプションURLを更新できるかの判断には使わず、Subscribeに戻って確認してください。
遅延の数値は比較に役立ちますが、比較する前にテスト条件をできるだけそろえてください。異なる時間帯やネットワークで測った結果をまとめて固定の順位にしないでください。また、数値が小さい項目だけを見て、接続の安定性を見落とさないようにしましょう。ある項目のテストに問題が表示されたら、まず同じ項目をもう一度テストし、次に状態が分かっている別の項目と比較します。すべての項目で同時に問題が起きる場合は、端末のネットワークと現在の設定を確認してください。1つの項目だけで問題が続く場合は、該当項目のAddress、Port、認証情報、通信設定を見直します。
並べ替えは検索に使い、検証の代わりにしない
遅延順に並べ替えると、多数の項目から現在のテスト結果が良好なものをすばやく見つけられます。ただし、並べ替えた後も項目の登録元を確認してください。サーバー名が似ていることがあり、テスト結果もネットワークによって変わるため、表示位置だけで選ぶと誤選択につながります。まずサブスクリプションの名前や手動登録のメモで候補を絞り、次にテスト状態と遅延を確認するのがおすすめです。よく使う項目は、過去の並べ替え結果のスクリーンショットを保存するより、定期的に再テストするほうが参考になります。撮影時刻やネットワーク条件が分からないと、スクリーンショットの数値から判断できることは限られます。
サーバーのテストに成功しても実際のリクエストが想定どおりにならない場合は、接続とルーティングを分けて確認してください。まずHomeで実際に選択されているサーバーと接続状態を確認し、次にGlobal Routingを見ます。Configは現在のConfigのルールに従って処理し、ProxyとDirectはルーティング方法を比較するために使います。Configでは、対象の通信がDIRECTに一致することがあります。その場合、サーバーのテストに成功していても、対象の通信が選択したサーバーを経由しているとは限りません。ルールを詳しく確認する場合は、DOMAIN-SUFFIX、GEOIP、IP-CIDRなどのキーワードとポリシーを確認し、通信がどのルールに一致するかを調べてください。
| 確認できた状況 | まず確認すること | 次に確認すること |
|---|---|---|
| すべての項目でテストに問題がある | 端末のネットワークと現在の接続状態 | サブスクリプションの更新と設定を個別に確認 |
| 特定の項目だけで問題が続く | 該当項目の登録元と設定 | 認証、TLS、通信設定 |
| テストは正常だがリクエスト結果が異なる | 実際の選択項目とGlobal Routing | Configで一致するルール |
調査中は、一度に変更する条件を1つに絞ってください。まずサーバーを固定してルーティング方法を比較し、次にルーティング方法を固定してサーバーを比較し、最後に個別のConfigを確認します。これにより、問題がデータ、接続、ルールのどこにあるかを判断しやすくなります。複数の項目を続けて切り替えると、接続が戻っても、どの操作が影響したか分かりません。詳しくはよくある質問・トラブル対処をご覧ください。DNSの名前解決経路に関する問題は、DNS設定ガイドをご確認ください。テストと並べ替えは診断のための手段です。最終的には実際のリクエストと現在のルールに照らして結果を判断してください。
08 · 削除、移行、データのバックアップ
削除する対象と影響を確認する
一覧を整理するときは、削除するものが手動登録したサーバー1件なのか、サブスクリプションから追加された項目なのか、Subscribeの登録先全体なのかを確認してください。個別項目の削除と登録先の削除では影響が異なります。登録先を削除すると、そのURLから一連の項目を更新する手段を端末上で失う場合があります。一時的に使えないサーバーだけを整理したい場合も、まずサブスクリプションに含まれているか確認しましょう。サブスクリプション由来であれば、次回の更新で再び追加されることがあり、個別に削除しても目的に合わない場合があります。登録元を確認してから削除するか判断してください。
整理は、確認、保存、削除、再確認の4段階に分けるのがおすすめです。確認では名前と主要な項目を調べ、似た項目を取り違えないようにします。保存では、自分が保有している元のサブスクリプションURL、手動登録の設定、今後も使うConfigテキストを保管します。削除は一度に1種類の項目だけにし、最後にHomeへ戻って、残した登録先を想定どおり更新できるか、必要なサーバーが残っているか確認します。まだ必要かどうか判断できない項目は、元の情報が1つしかない場合、削除しないでください。一覧を整理することは大切ですが、再構築に必要な情報を失ってまで行うものではありません。
再構築できる情報をバックアップする
バックアップは一覧のスクリーンショットを保存するだけではありません。スクリーンショットではURL全体、パスワード、鍵、パスなどの項目が見えないことがあり、手動登録かSubscribe由来かも分からない場合があります。より確実に管理するには、自分が保有する元のサブスクリプションリンク、手動登録したサーバーの全設定、引き続き使うConfigの内容をそれぞれ保存し、用途も記録します。機密情報はアクセス権を自分で管理できる場所に保管してください。問題を説明するスクリーンショットを共有する前に、認証情報やパラメーター付きURLが画面に表示されていないか確認しましょう。
別のiPhoneまたはiPadで設定を再構築する場合は、まずApp StoreからShadowrocketを入手し、アプリが正規のものか確認します。その後、情報の種類に応じて復元してください。サブスクリプションURLはSubscribe、個別サーバーの設定はAdd Server、Configの内容は設定ファイルの手順に沿って確認します。復元後は項目数だけでなく、サブスクリプションを更新できるか、手動設定に漏れがないか、Global Routingと必要なConfigが正しく選択されているかも確認してください。購入済みアプリの復元はApp Storeの購入記録に関する問題であり、サーバー情報を再構築できるかとは別の問題です。購入済みアプリについては購入済みアプリの復元方法をご覧ください。
情報を使わなくなった場合も、削除前に、関連する設定がほかの場所から参照されていないか確認してください。たとえばConfigのルールが特定のポリシー名を参照している場合、参照先の情報を削除しても、ルール自体が正しくなるわけではありません。先に参照関係を確認してから、不要な項目を整理します。逆に、一時的にサーバーを切り替えるだけなら、古い項目を削除する必要はありません。登録元を明確にして元の情報を保管しておけば、後から接続結果やサブスクリプションの変更を比較しやすくなります。
このガイドでは、読み込みから整理まで、管理の一連の手順を説明しました。初回設定ははじめての設定ガイドに沿って進めてください。一覧が空になる、設定が一致しない、ルールの適用結果が分かりにくいといった場合は、該当する章に戻って項目ごとに確認します。Shadowrocketの入手先はApp Storeです。開発者はShadow Launch Technology Limited、アプリIDは932747118です。対応デバイスとシステム要件はApp Storeの掲載内容をご確認ください。アプリの買い切りと接続サービスの契約は別です。サーバー情報はご自身で管理し、内容を確認してください。