Shadowrocketの共有リンク形式を解説：ss://・vmess://・vless://・trojan://とサブスクリプションの違い

この記事の要点

共有リンクは通常、1台のサーバー情報を記述します。サブスクリプションリンクはサーバー一覧の取得と更新に使います。サービス提供元から入手した設定情報やサブスクリプションをお持ちの方向けに、ShadowrocketのHome → Add Serverで選ぶ項目、4種類のリンク形式の見分け方、追加後の確認項目を説明します。例に登場するドメイン、パスワード、UUID、tokenはすべて架空の値で、実際の接続には使用できません。

1. まず確認：サーバー情報のリンクか、一覧取得用のリンクか

まず先頭部分を確認し、次に提供元の説明と照らし合わせます。リンクの長さだけでは、サブスクリプションかどうか判断できません。ss://、vmess://、vless://、trojan://は通常、接続に必要なパラメータを含む単体サーバー用の共有リンクです。https://で始まるURLはサブスクリプションの場合も、Webページやリモート設定ファイルの場合もあります。用途を必ず確認してください。

確認項目	単体サーバーの共有リンク	サブスクリプションリンク
主な内容	1台のサーバーのアドレス、ポート、認証情報、通信パラメータ	サーバー一覧を取得するURL。アクセス用tokenが含まれる場合もある
よくある先頭部分	`ss://`、`vmess://`、`vless://`、`trojan://`	`https://`。具体的な用途は提供元の説明で確認
追加先	クリップボードからの追加案内、またはHome → Add Serverで該当するTypeを選択	Home → Add Server → Type → Subscribe
その後の管理	パラメータが変わったら再度追加するか、編集する	元のサブスクリプション項目から一覧を更新

サブスクリプションはプロキシプロトコルの一種ではありません。また、URLがhttps://で始まるからといって、一覧に含まれるサーバーが特定のプロトコルだけとは限りません。レスポンスには、提供元が出力する形式に応じて、異なる種類のサーバー情報が複数含まれることがあります。サーバー情報が1件だけのサブスクリプションもあるため、追加後の件数からリンクの種類を判断することはできません。

2. 4種類の共有リンクで確認する項目

接頭辞の確認は最初のステップです。保存前にAdd Serverの各項目と実際の値を照合してください。アドレスとポートが正しくても、認証情報、TLS、通信パラメータが正しいとは限りません。以下の例は形式を確認するためのもので、実際に利用できるサービス情報ではありません。

ss://：Method、Password、アドレス、ポートを確認

Shadowsocksの共有リンクでは、暗号化方式とパスワードを組み合わせてBase64でエンコードし、サーバーのアドレスとポートを続けて記述する形式がよく使われます。以下の例では認証部分をデコードするとaes-128-gcm:testになります。ポートは8388ですが、すべてのShadowsocksサービスで固定されているわけではありません。

ss://[email protected]:8388#Example-SS

Home → Add Server → TypeでShadowsocksを選び、Address、Port、Method、Passwordを確認します。
#Example-SSは備考部分で、パスワードには含まれません。
元のリンクにpluginパラメータがある場合は、対応する拡張オプションも確認してください。アドレス、ポート、パスワードだけを残すのは避けてください。

vmess://：一般的な形式はJSONのBase64エンコード

VMessの共有リンクでは、JSONオブジェクトをエンコードしてvmess://の後ろに記述する形式がよく使われます。ユーザー名@アドレスの形式とは異なります。以下はデコード後の構造例で、コピーしてそのまま追加できる完全な共有リンクではありません。

{
  "v": "2",
  "ps": "Example-VMess",
  "add": "vmess.example.com",
  "port": "443",
  "id": "00000000-0000-4000-8000-000000000001",
  "aid": "0",
  "net": "ws",
  "type": "none",
  "host": "edge.example.com",
  "path": "/demo",
  "tls": "tls",
  "sni": "edge.example.com"
}

addとportは接続先、idはUUIDです。vはこの共有データの形式を示す項目で、アプリのバージョンではありません。
net=wsはWebSocketを示します。hostとpathは通信設定に対応する値であり、どちらもサーバーアドレスとして扱うものではありません。
tlsとsniはTLS設定と照合してください。ポートが443だからといって、値を独自に追加したり削除したりしないでください。

vless://：UUIDだけでなく通信方式とTLSの設定も確認

VLESSでは、パラメータをURI形式で表す方法がよく使われます。以下の例ではUUIDを@の前に置き、クエリ部分でTCP通信とTLSの設定を指定しています。encryption=noneは、接続全体でTLSを使わないという意味ではありません。

vless://[email protected]:443?encryption=none&security=tls&type=tcp&sni=vless.example.com#Example-VLESS

Add ServerでVLESSを選び、まずUUID、Address、Portを確認します。
続けて通信方式とTLS Server Nameを確認します。元のリンクにflowなどの項目がある場合は、記載されたパラメータに従い、例を参考に独自の値を追加しないでください。
同じvless://で始まるリンクでも、通信方式の組み合わせは異なります。すべてのVLESSリンクにTCPの例を当てはめないでください。

trojan://：PasswordとTLS Server Nameを分けて確認

Trojanのリンクでは、通常@の前にパスワードが含まれます。パスワードにURIの予約文字が含まれる場合は、正しくパーセントエンコードする必要があります。エンコード済みの文字列を手動でもう一度エンコードすると、実際の認証情報が変わってしまいます。

trojan://[email protected]:443?security=tls&type=tcp&sni=trojan.example.com#Example-Trojan

Add ServerでTrojanを選び、Password、Address、Port、TLS設定をそれぞれ確認します。
sniはTLSハンドシェイクで使うサーバー名です。接続先のAddressと必ずしも一致するとは限りません。
接続エラーを避けるために、証明書の検証をむやみに無効にしないでください。まずサーバー名、端末の日時、元のパラメータを確認します。

3. Homeで追加先を選ぶ方法

サブスクリプションをお持ちの場合は、Subscribeの項目として登録した状態を保ちます。共有リンクが1件だけの場合は、まずアプリのクリップボード認識を試してください。以下ではAdd Serverの用途を比較します。「おすすめ」はサブスクリプションをすでにお持ちの場合に限った案内で、プロトコルの性能順を示すものではありません。

Type → Subscribe

Type → VLESSなど、使用するプロトコルを選択

サーバーごとの実際のプロトコルに合わせて、Address、Port、認証項目を入力します。ここではVLESSを例にしていますが、ほかのプロトコルでは対応するTypeを選択してください。

対象：サーバーの設定情報が一式そろっている場合、または共有リンクを自動認識できない場合

結論：今後も更新する場合は、元のサブスクリプション項目を維持

資料にサブスクリプションアドレスと明記されている場合は、Type → Subscribeで元のURLを保存します。最初に取得したサーバー情報をサブスクリプションそのものとして扱わないでください。独立した項目になり、後から元の一覧を更新しても引き継げません。

手順：手元の情報に合わせて選択

共有リンクが1件ある場合

ss://などの接頭辞から、リンク全体をコピーします。チャット上の引用符や説明文は含めません。
Shadowrocketを開き、クリップボードからの追加案内が表示されたら、案内に従って確認します。システムがペーストの許可を求めた場合は、必要に応じて許可してください。
案内が表示されない場合は、Home → Add Serverで該当するTypeを選び、元のパラメータを確認しながら手動で入力します。
保存後に項目の編集画面を開き、アドレス、ポート、認証、通信方式、TLSを確認します。

サブスクリプションアドレスがある場合

Home → Add Server → Type → Subscribeの順に進みます。
URLにサブスクリプションアドレス全体を入力します。以下は架空の例です。
保存して一覧の取得を待ち、Homeに戻ってサブスクリプションのグループと項目を確認します。
次回以降は元のサブスクリプション項目から更新し、同じサブスクリプションを繰り返し追加しないようにします。

どちらの手順でも、最後に保存された項目を確認します。「保存しました」という表示だけで接続可能と判断しないでください。

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

上記のHTTPSアドレスは文字列の例にすぎず、アクセスしたり追加したりしないでください。実際の操作では、お持ちのサブスクリプションURL全体を使用し、クエリパラメータもそのまま残します。チャットツールでリンクが折り返されている場合は、空白、改行、末尾の句読点が混入していないか先に確認してください。

4. サブスクリプションの更新と接続テストを分けて確認

サブスクリプションの取得に成功したことは、一覧を取得できたことを示すだけで、すべてのサーバーに接続できることを意味しません。反対に、既存のサーバーが使えても、サブスクリプションURLが有効とは限りません。サブスクリプションへのアクセスとプロキシ接続では、異なるリクエストと認証情報が使われます。

まず一覧に変化があるか確認します。Homeで登録済みのサブスクリプションを更新し、エラーの有無と項目が表示されたかを確認してください。接続のオン／オフだけで更新結果を判断しないでください。
次に、どのネットワーク経路で更新するか確認します。現在のネットワークからサブスクリプションURLにアクセスできない場合は、利用可能な接続があることを確認したうえで、Settings → Subscribe → Update via Proxyを確認します。この設定で変わるのはサブスクリプション更新時のアクセス経路であり、無効なtokenが修正されるわけではありません。
サーバーを1つ選んで確認します。Homeに戻って項目を選び、Connectivity Testで結果を確認してください。テストに成功しても、対象のWebページ、認証、すべての通信方式が正常とは限りません。実際にアクセスして確認する必要があります。
最後にルーティングを確認します。Home → Global Routingで現在のモードを確認してください。Directではサーバーを経由したリクエストは行われません。Proxyはルールの影響を一時的に切り分ける際に使えます。Configでは現在の設定ルールに従って通信が処理されます。テスト後は必要な元のモードに戻してください。

5. 追加エラー、項目の変更、リンクのプライバシーに関するQ&A

元のリンクが完全かを確認してから、形式、各項目、ネットワークの順に調べます。パスワードを変更したり、クエリパラメータを削除したりするのは避けてください。解析できていたリンクが認証できない項目に変わるおそれがあります。

リンクをコピーしてアプリを開いても、追加の案内が表示されない場合は？

まず、コピーした内容がプロトコルの接頭辞から始まり、引用符、説明文、改行が含まれていないことを確認します。システムからペーストの許可を求められた場合は、必要に応じて許可してください。それでも案内が表示されない場合は、Home → Add Serverで該当するTypeを選び、提供元の完全な設定情報を使って手動で入力します。共有リンク全体をAddressに入力しないでください。

サブスクリプションURLをブラウザで開けるのに、追加後の一覧が空なのはなぜ？

開いたページがサーバー一覧のレスポンスであり、ログイン画面、エラーページ、説明ページではないことを確認してください。Homeに戻り、Subscribe項目のURLが完全か、特にtokenのクエリパラメータを確認します。返された内容が対応するサブスクリプション形式でない場合は、Webページの内容を1行ずつサーバーとして追加するのではなく、元の提供元に出力形式を確認してください。

リンクの#以降、sni、pathは削除してもよい？

#以降は通常、備考として使われます。sniとpathはTLSやWebSocketの接続に直接影響する場合があります。Homeで項目の編集画面を開き、それぞれを確認して元のパラメータを保ってください。リンクを短くするためにクエリ部分を一律に削除しないでください。

サブスクリプション更新後、自分で変更したサーバー項目は維持される？

サブスクリプション内の項目に加えた変更が、今後も維持されるとは限りません。次回の更新で項目が再生成されたり、値が上書きされたりすることがあります。問題を調べる際は変更内容を記録し、必要であれば別の独立した項目を作ってテストしてから、元のサブスクリプションを更新して確認してください。独立した項目は、元のサブスクリプションに合わせて自動更新されません。

Base64でエンコードされたリンクを、そのまま他人に送って調査を依頼してもよい？

内容全体を公開しないでください。Base64はエンコード方式であり、情報を保護するものではありません。共有リンクにはPasswordやUUID、サブスクリプションURLにはアクセス用tokenが含まれる場合があります。問い合わせる際は、機密情報を伏せた項目名、エラーの状況、メニューの操作経路だけを伝えてください。認証情報が漏えいした場合は、元の提供元の管理画面で該当する情報を変更してください。

最後に「情報の種類を確認 → 正しい追加先を選択 → 項目を確認 → 更新と接続を分けてテスト」の順で確認します。これにより、解析エラー、サブスクリプションへのアクセス失敗、サーバー認証エラー、ルーティングの問題を切り分けられます。問題のないパラメータを誤った箇所で何度も変更するのを防げます。