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

Add Server：プロトコルに合わせて項目を入力

Typeを選んでからアドレスと認証情報を入力

手動追加は、サーバーのパラメータ一式が手元にあり、個別に管理したい場合に適しています。Add Serverを開いたら、まずTypeを選び、選択したプロトコルに表示される項目に入力してください。認証方式はプロトコルごとに異なります。あるプロトコルのパスワード、識別子、通信パラメータを別のプロトコルに流用しないでください。プロトコル名が似ていても、項目をそのまま置き換えられるとは限りません。

通常、ホスト欄にはドメイン名またはアドレスを、ポート欄には該当する数値を入力します。URLを明示的に求める項目でない限り、ホストの前にURLスキームを付けたり、パス、ポート、クエリパラメータをホスト欄にまとめて入力したりしないでください。情報をコピーする際は区切り位置を確認します。特にコロンを含むアドレスでは、アドレスとポートをひと続きにすると、解析結果が想定と異なることがあります。

認証パラメータと通信パラメータを分けて確認する

Shadowsocksでは暗号化方式とパスワードを確認します。VMessとVLESSでは、それぞれの識別子と通信設定を確認します。TrojanではパスワードとTLSの要件を確認してください。Hysteria2とWireGuardにもそれぞれ固有のパラメータがあり、サーバーのドメイン名だけでは入力を完了できません。項目が足りない場合は、手元のパラメータ説明を確認してください。任意の値でフォームを埋めないでください。

パスワードや識別子は省略せずにコピーしてください。不要に見える記号も自動で削除せず、名前欄を認証情報として使わないでください。入力欄で文字が隠れる場合は、安全な環境で保存前に文字数と先頭・末尾を確認します。画面を撮影して記録する場合は、中央の数文字だけでなく認証情報全体を隠してください。一部が残っているだけでも、実際の認証情報を特定される可能性があります。

TLS、SNI、Host、パスはそれぞれ別の項目です。接続先アドレスはサーバーの特定に使われ、SNIはTLSの名前交渉に関係し、Hostとパスは上位層の通信リクエストに使われる場合があります。既存の設定で値が似ていても、別々の項目として保持してください。特に、テストを通すために証明書の検証を安易に無効化しないでください。セキュリティ上の境界が変わり、名前や証明書の設定ミスが見えにくくなります。

WebSocketなどの通信方式でパスを入力し忘れたり、Hostを誤入力したりすると、アドレスには到達しても接続が完了しないことがあります。問題を切り分ける際は、まずサーバーのプロトコル、次に認証情報、最後に通信レイヤーの項目を確認してください。誤りが確認できた値を一度に1つだけ変更し、比較できるよう元のパラメータも残しておきます。続けて複数項目を試すと、どの変更が影響したのか分からなくなります。

手動登録の管理範囲を明確にする

名前は項目を見分けるためのものであり、接続プロトコルの一部ではありません。用途、場所、管理方法などを記載できますが、パスワードは含めないでください。手動登録とサブスクリプションから作成された項目には、区別しやすい命名方法を使うと便利です。たとえば、自分で管理する項目であることを明記します。サブスクリプション更新後に似た名前が表示されても、どの記録を確認すべきか分かり、2つを同じものと誤認しにくくなります。

保存前と保存後の両方で、Type、ホスト、ポート、認証、通信の5項目を確認してください。通常、保存できたことが示すのは、クライアントが入力内容を受け付けたということだけです。サーバーがパラメータの正しさを確認したわけではありません。続いて接続をテストし、目的のアクセスが想定どおりか確認します。一部のサイトだけ失敗する場合は、すべてのサーバー項目をすぐに再入力せず、まず通信の振り分けと名前解決の経路を確認してください。

サブスクリプション内の項目を手動で変更しても、次回更新時に再生成された内容で置き換えられる場合があります。個別のパラメータを長期間保持したい場合は、現在の操作がサブスクリプション内の項目の編集なのか、独立した手動登録の作成なのかを確認してください。独立して管理する場合は、以後のサーバー変更に合わせてパラメータを更新する必要があります。サブスクリプションの更新で手動の複製も自動管理されるとは限りません。

プロトコル項目の意味が分からない場合は、まず用語集で用語を確認してから、手元のサーバー情報をもとに入力してください。本ガイドでは、プロトコルの推測、項目の無作為な組み合わせ、証明書設定の繰り返し変更による解決は推奨していません。手動追加を安定して利用するには、完全で対応関係が明確な、現在も有効なパラメータが必要です。

共有リンク：形式とエンコードを確認する

プレフィックスで解析方式を見分ける。パラメータの正しさは別途確認

サーバー共有リンクには、プロトコルと接続パラメータが所定のテキスト形式で含まれます。よく使われるプレフィックスは ss://、vmess://、vless://、trojan://、hysteria2:// ですが、形式ごとに内部構造は異なります。プレフィックスから分かるのは種類の目安です。認証情報が有効か、サーバーに到達できるか、すべての拡張パラメータが対応しているかまでは判断できません。

サブスクリプションURLは通常のURL形式で、サーバー一覧を返すために使われます。単一の共有リンクは、1つの接続先を直接記述します。どちらも長く、認証情報を含む場合があるため、長さだけでは区別できません。情報の説明とプレフィックスを確認し、Subscribeか単一項目の読み込みかを選んでください。長いテキストをすべてサブスクリプションとして扱わないでください。

エンコードは暗号化ではない。任意に書き換えない

共有形式によっては構造化データをBase64でエンコードし、別の形式ではクエリ文字列にパラメータを格納します。エンコードは主にテキストを転送しやすくするためのもので、認証情報を秘匿する仕組みではありません。エンコードを元に戻せる人は、アドレス、パスワード、識別子を読み取れる可能性があります。意味の分からない文字列を、安全に匿名化されたテキストだと思い込まないでください。

クエリパラメータ内のパーセントエンコード、大文字・小文字、特殊記号は原文のまま保ってください。繰り返しデコードすると、パスワードやパスの一部だった文字が区切り文字に変わる場合があります。再エンコードによってサーバーに想定外の値が送られることもあります。形式の仕様と各項目の意味が明確でない限り、ほかのツールで変換してからクライアントに読み込ませないでください。

リンク末尾のフラグメント部分は名前に使われることがありますが、具体的な扱いは形式によって異なります。日本語の名前がエンコード後に長くなっても、リンクの破損とは限りません。一方、チャットアプリがリンクを2つに分けたり、通常の記号を全角文字に置き換えたりすると、解析に影響することがあります。文字化けが起きたら、認証項目を書き換える前に元のテキストと照合してください。

Configとサーバー共有リンクは別のもの

Configでは、ドメインやアドレスに適用するポリシーを決められますが、ルールだけではサーバーのパラメータ一式が含まれていない場合があります。ルールのテキストを単一サーバーの読み込み入口に貼り付けても、接続先は作成されません。同様に、サーバー共有リンクを読み込んでも、あらゆる用途に適したルールファイルが自動で作成されるわけではありません。サーバーと通信の振り分けは別々に確認してください。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY

これはルールの照合順を説明するためのShadowrocket .confルール例であり、完全な設定ではありません。ルールは上から順に判定され、まず指定したドメインサフィックスを処理し、次に該当するアドレス範囲を処理します。最後に、それまで一致しなかった接続をFINALが処理します。例にあるドメインは説明用の架空値です。自分の設定に適用する前に、対象のポリシーと既存項目との関係を確認してください。

Global RoutingでConfigを選択している場合は、現在のConfig内のルールを確認してください。ProxyとDirectでは通信の処理方法が異なります。読み込みに成功してもアクセス経路が想定と違う場合は、現在のモードを確認してからルールを調べます。サーバー共有リンクの形式が整っているだけで、通信の振り分けも正しいと判断しないでください。モードの説明はGlobal Routingの3つのモードの違いをご覧ください。

形式の問題を安全に報告する

解析に失敗した状況を伝える場合は、プロトコルのプレフィックス、失敗した手順、未対応パラメータの案内が表示されたかを共有できます。リンク全体を公開したり、実際のエンコード内容を公開デコードサイトに送ったりしないでください。説明用のテキストが必要な場合は、架空のアドレスと架空の認証情報で新たに作成し、有効なリンクから名前だけを変更して使い回さないでください。

元の情報を再度エクスポートできる場合は、同じ項目の完全なテキストを取得し、ローカルで読み込んだ結果と比較してください。読み込みを成功させるために、クエリパラメータをすべて削除しないでください。削除した部分が通信方式、TLS、認証に関わる場合があります。項目が作成されても、それは解析できたことを示すだけです。最終的に正しいパラメータで接続を確認してください。

複数サブスクリプションの整理：管理元と参照関係を保つ

まずグループの意味を決めてから並べ替える

複数のサブスクリプションを利用する場合は、各記録を誰が管理しているか、どのサブスクリプションに属するか、更新によってどの項目が影響を受けるかを見分けられることが重要です。すべてのサーバー名を似たものに変更してから、元のグループを思い出そうとしないでください。まず各サブスクリプションに変わりにくい別名を付け、用途や自分が理解しやすい分類で命名します。表示される名前に認証情報やアカウント情報は含めないでください。

サブスクリプションの別名はローカルでの管理上の関係を示すもので、サーバーの品質を評価するものではありません。仕事用、テスト用、管理担当などで区別できますが、一度のテスト結果を恒久的な評価として名前に含めないでください。テスト結果は時間やネットワークによって変わりますが、名前は長期間使われることがあります。一時的な状態を名前にすると、無効になった情報をもとに後から選択するおそれがあります。

手動登録とサブスクリプションから作成された項目は、見分けられる状態に保つのがおすすめです。サブスクリプション内のサーバーを独立して変更するために複製する場合は、自分で管理する項目だと分かる名前を付け、元のパラメータを安全に記録してください。そうしないと、更新後に一方だけが変わり、もう一方が古い値のままになります。同じサーバーが時々使えなくなるように見えても、実際には2つの項目のパラメータが異なっている可能性があります。

重複を削除する前に接続情報を比べる

同じ名前でも重複とは限らず、同じホストでも接続方法が1つとは限りません。見分ける際は、プロトコル、ホスト、ポート、認証情報、通信パラメータを比較し、必要に応じてTLS名とパスも確認します。名前が同じでも、ポートや認証情報が異なる場合があります。名前だけを基準に一括削除すると、必要な独立項目まで消すおそれがあります。

逆に、名前が違っていても接続パラメータ一式が同じことがあります。このような重複は、複数回の読み込み、手動コピー、複数サブスクリプションに同じ項目が含まれることなどが原因です。まず日常的に使う記録として残すものを決めてから、不要なコピーを整理します。一覧を短くするためだけにグループ全体をすぐ削除しないでください。グループは更新と管理の単位として必要な場合があります。

サーバーの選択とルールの参照先を合わせて確認

Homeで現在選択しているサーバーは、Config内のポリシーやルールから参照される場合があります。しかし、ハイライトされている位置だけを見ても、すべての接続が最終的にどこを通るかは分かりません。ルールが特定のポリシーを指定し、ポリシーが別の選択を使うこともあります。一覧を整理した後は、よく使うConfigが名前を変更または削除した項目を参照していないか確認し、実際にアクセスして検証してください。

Global RoutingのConfigモードでは、ルールの照合順で接続の処理方法が決まります。Proxyは接続をプロキシ経由で処理し、Directは直接接続します。3つのモードはサブスクリプショングループのフィルターではなく、重複したサーバーを自動で統合する機能もありません。管理時はモード、現在の選択、Config名をあわせて記録すると、整理前後の動作の違いを説明しやすくなります。

重要な接続を管理している場合、サブスクリプションの名前変更、項目の一括削除、ルールの書き換えを同時に行わないでください。まず1つのグループを整理し、更新とテストを終えてから次に進みます。変更範囲を1つずつにすれば、想定と異なる結果になっても、どの操作を戻せばよいか明確です。一度にすべて整理すると、名前の参照関係、パラメータの変更、ネットワークの変動のどれが原因か判別しにくくなります。

認証情報を漏らさず簡潔に記録する

管理記録には、サブスクリプションの別名、用途、自動更新の有無、直近の確認結果、手動コピーの有無を記載できます。サブスクリプションURL全体を記録する必要はなく、通常のメモにパスワードをコピーしてはいけません。複数のデバイスで照合する必要がある場合は、両方で機密情報を含まない同じ別名を使って対象を管理してください。有効な認証情報をチャットで送るのは避けます。

iPhoneとiPadの一覧が一致しているかは、実際に各デバイスで確認してください。アプリが同じ購入アカウントを使うからといって、すべてのサブスクリプション、現在の選択、Configが自動的に完全同期されるとは限りません。購入の復元が扱うのはアプリの利用資格であり、サーバー情報やConfigの復元は別の手順です。機種変更前に、本ページの削除とバックアップの章に沿って、それぞれ確認してください。

整理後は、よく使うConfigとサーバーを選んで動作を確認し、更新操作が正しいサブスクリプションを対象にしているかも確認します。一覧をできるだけ短くすることより、管理範囲を明確に保つことが重要です。サブスクリプションの読み込みに失敗したとき、影響を受ける項目と独立して使える手動登録をすぐに見分けられれば、変更範囲を広げずに問題を調べられます。

削除とバックアップ：復元を確認してから整理する

まず削除対象の種類を確認する

整理する前に、単一サーバー、サブスクリプション全体、Configファイルを区別してください。単一サーバーを削除すると、ローカル一覧だけが変わる場合があります。サブスクリプションから作成された項目は、次回更新時に再び表示されることもあります。サブスクリプションを削除すると、その登録に関係する管理情報と項目に影響します。Configを削除すると、通信の振り分け設定に影響します。これらの操作は互いに代用できず、どれか1つをすべてのデータをリセットする方法として使わないでください。

サブスクリプションの更新に失敗したとき、ローカルに残る唯一の記録をすぐに削除しないでください。利用できるサーバーが残っているか、元のサブスクリプションURLが安全に保存されているか、既存のパラメータを再取得できるかを確認します。削除してもリモート側の認証情報は無効にならず、ネットワークリクエストの問題も解決しません。記録が不要であり、復元方法も確認できた場合に整理してください。

重複した項目を整理する前に、ルールやポリシーがその名前を参照していないか確認してください。削除後にサーバー一覧が整理されても、その名前に依存するConfigは調整が必要になる場合があります。まず不要な項目を1つだけ整理し、よく使うConfigが引き続き動作するかを確認してから、範囲を広げてください。一括削除はバックアップと参照関係を確認済みの場合に行うもので、原因を探るための操作ではありません。

バックアップでは異なる種類のデータを対象にする

バックアップ前に、保持するデータを一覧にします。サブスクリプションURL、独立した手動サーバー、Configファイル、利用に関係する設定などです。サブスクリプションURLからリモート側の現在の一覧を再取得できる場合がありますが、過去に存在した項目や、ローカルで変更した名前・手動編集が復元されるとは限りません。サブスクリプションURLだけを保存しても、独立したサーバーやカスタムConfigの確認には代わりません。

現在のアプリにあるエクスポートまたは共有の入口を使う場合は、実際にどの範囲がエクスポートされるかを確認してから、自分で管理できる安全な保存先を選んでください。単一サーバーだけを共有する入口は、完全なバックアップとして使えません。Configファイルをエクスポートする場合も、復元に必要なサーバーとの関係が含まれているか確認します。ファイル名だけを見てバックアップ範囲を判断しないでください。

エクスポートできたかより復元できるかを確認する

エクスポート後は、ファイルが存在して読み取れること、機種変更後も保存先にアクセスできることを確認します。重要な内容は管理された状態で2つ目のコピーを保管できますが、どちらも用途とアクセス範囲を明確にしてください。初期化する予定の古いデバイスにしかファイルが残っていなければ、エクスポートが完了しても機種変更後の復元に使えるバックアップにはなりません。

復元先のデバイスで、まずShadowrocketをApp Storeから正規に入手したことを確認してから、データの種類ごとに読み込みます。アプリの購入済み復元とサーバー情報の復元は別の手順です。前者は購入資格、後者は接続データを扱います。iPhoneとiPadのシステム要件、互換性、ユニバーサル購入についてはApp Storeページの記載に従ってください。手順は購入済みアプリの復元方法をご覧ください。

復元先のデバイスにすでにデータがある場合は、まず現在の状態をバックアップしてください。古い情報を読み込んで上書きや重複が起きた際に、見分けにくくなるのを防げます。サブスクリプション1つ、または手動サーバー1つから復元し、パラメータが正しいことを確認してからConfigやその他の記録を復元できます。読み込み後は、一覧に項目が表示されたからといってすぐに古いデバイスを消去せず、現在の選択、Global Routing、よく使うルールを確認してください。

実際に接続して目的のサイトにアクセスできることを少なくとも1回確認し、その後サブスクリプションを更新できるかも確認します。古いサーバーパラメータで現在接続できても、サブスクリプションの認証情報が有効とは限りません。逆に、サブスクリプションを更新できても、カスタムルールが正しく復元されたとは限りません。読み込み、接続、通信の振り分けを個別に確認して、重要な利用状態が新しいデバイスに復元できたと判断してください。

認証情報の漏えいとローカルデータの削除は別々に対応する

完全なサブスクリプションURL、QRコード、バックアップが公開されたことがある場合は、利用中のサービスの管理方法を通じて関連する認証情報を変更または無効化し、ローカルの記録を更新してください。チャットのメッセージを削除したり、クリップボードを消去したり、サーバーを削除したりするだけでは、コピー済みの内容が使えなくなるとは限りません。変更後は古いバックアップや他のデバイスも確認し、後から復元した際に無効になったURLを再び読み込まないようにしてください。

継続的な管理では、まず現在の状態を記録し、サブスクリプションを1つ更新して、よく使う接続を確認します。その後、重複項目を整理し、最後にバックアップを更新するという順序が有効です。変更範囲が明確になり、後から確認しやすくなります。初回接続をもう一度確認する場合は使い方ガイドへ、項目の意味を確認する場合は用語集をご覧ください。データを繰り返し消去するのではなく、問題の段階を分けて確認してください。