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

この記事の概要

利用中のサービスとサブスクリプションがある場合は、受け取ったものが単体の共有リンクか、更新可能なサブスクリプションURLかを確認してから、適切な方法で取り込みましょう。この記事では、4種類のリンクに含まれる情報やエンコード、よくある誤解を解説し、Homeへの取り込み後に確認する手順と、ノードの設定・Configのルール・Global Routingの役割を整理します。例は形式の確認用であり、接続には使用できません。

まずリンクの先頭を確認：接続設定とサブスクリプションURLは別物

Shadowrocketでは、単体の共有リンクは通常、1つの接続設定を表します。使用するプロトコル、接続先サーバー、認証情報、TLSや特定の通信方式を使うかどうかなどが含まれます。ss://、vmess://、vless://、trojan://は、この記事で扱う4種類のschemeです。先頭が似ていても、内部のフィールドを相互に置き換えられるわけではありません。

サブスクリプションURLは通常、HTTPS形式です。ShadowrocketがURLにアクセスすると、サーバーからノード一覧を取得し、返された内容に基づいて項目を作成または更新します。URL自体からサーバーアドレスやポートが分かるとは限らず、それらの情報はレスポンス本文に含まれていることがよくあります。HTTPSのURLなら何でもサブスクリプションとして使えるわけではありません。アカウント管理、ログイン、説明の各ページは、サブスクリプションのインターフェースとは異なります。

4種類

この記事で扱うscheme：ss / vmess / vless / trojan

1件

単体リンクは通常、1つの接続設定を表す

443

後述の例に使うポートであり、すべてのノードの既定値ではありません

サブスクリプションは複数のノードを返す場合も、1件だけの場合もあるため、取り込み後の項目数だけで種類を判断できません。取り込み時にSubscribeタイプを使用したか、サブスクリプションの登録元が保存されているか、その登録元から再取得して更新できるかを確認するのが確実です。アプリの買い切り購入と通信サービスの契約は別のものです。アプリと、利用中のサービスの接続情報はそれぞれ管理します。

ss://：Shadowsocksの認証情報とエンコードの範囲

Shadowsocksの共有リンクは、エンコードされた認証情報、サーバーアドレス、ポートに、任意のクエリパラメーターや注釈を加えた形式が一般的です。認証情報には通常、暗号化方式とパスワードが含まれます。以下では、エンコード処理を表す記号としてBASE64URLを使用しています。コピーしてそのまま取り込める文字列ではありません。

ss://BASE64URL(method:password)@server.example:8388#Office
認証情報の例：aes-128-gcm:demo-password
サーバーの例：server.example
ポートの例：8388

methodはShadowsocksの暗号化方式を示します。サーバー側の設定と一致させる必要があり、名称が似ているからといって独自に置き換えてはいけません。
passwordは接続用の認証情報です。Base64やBase64URLはエンコード方式であり、暗号化による保護ではありません。デコードできる情報も機密情報として扱ってください。
通常、@の後ろにはサーバーとポートが続きます。ホスト部分にIPv6アドレスを指定する場合は、アドレス内のコロンとポート区切りの混同を避けるため、角括弧で囲みます。
#Officeは項目を見分けるための注釈です。注釈を変更しても、サーバーアドレス、パスワード、ポートの誤りは修正されません。
plugin=を含むリンクには、プラグインのパラメーターが含まれる場合もあります。基本情報を読み取れるからといって、現在の環境で拡張機能をすべて利用できるとは限りません。

過去の共有形式には、より長い接続情報全体をまとめてエンコードする方法もあります。そのため、目に見える「@」があるかどうかだけで判定することはできません。利用中のサービスから提供された元のリンクを保存し、インポート機能で解析したうえで、Homeの項目編集画面で結果を確認してください。認証情報をデコードした結果が明らかに途中で切れている場合は、不足しているパスワードを推測せず、元のリンクをコピーし直してください。

vmess://：一般的なペイロードはBase64エンコードされたJSON

一般的なVMess共有リンクはvmess://で始まり、その後にBase64エンコードされたJSONが続きます。よくあるVLESS URIのように、ユーザー情報@ホスト:ポートが直接表示される形式ではありません。以下はデコード後のフィールド例です。予約済みの例示用ドメインとデモ用UUIDを使っており、実際のサービスには対応していません。

{
  "v": "2",
  "ps": "Office",
  "add": "server.example",
  "port": "443",
  "id": "00000000-0000-4000-8000-000000000000",
  "aid": "0",
  "scy": "auto",
  "net": "ws",
  "type": "none",
  "host": "edge.example",
  "path": "/demo",
  "tls": "tls",
  "sni": "edge.example"
}

フィールド	用途	確認ポイント
`add / port`	接続先アドレスとポート	接続先となるネットワーク上の終点を指定
`id / aid`	ユーザー識別子と過去の互換性パラメーター	元の値を維持し、むやみに書き換えない
`net / path`	通信方式と関連パス	`ws`の場合はパスを確認
`host / sni`	通信のHostとTLSのサーバー名	役割が異なり、接続先アドレスとも異なる場合がある
`ps / v`	注釈と共有形式の識別情報	`v`はアプリのバージョン番号ではありません

add、host、sniを、相互に置き換え可能な3つのサーバーアドレスとして扱うことはできません。前者は接続先を指定します。この例のWebSocketでは、hostはリクエストのHost、sniはTLSのサーバー名ネゴシエーションに使用されます。実際のサービスでは、3つの値が同じ場合も異なる場合もあります。取り込み後にアドレスとUUIDだけが残り、通信パスやTLS設定が失われると、項目を保存できても接続できないことがあります。

vless://とtrojan://：見た目は似ていても認証フィールドは異なる

VLESSとTrojanの一般的な共有リンクは、どちらも標準的なURIに近い形式です。認証情報は@の前、サーバーとポートはその後ろにあり、疑問符の後ろに追加パラメーター、#の後ろに注釈が続きます。見た目が似ていても、schemeの先頭だけを書き換えてプロトコルを変換できるわけではありません。

vless://[email protected]:443?encryption=none&security=tls&type=ws&host=edge.example&path=%2Fdemo&sni=edge.example#Office

trojan://[email protected]:443?security=tls&type=tcp&sni=edge.example#Office

フィールドの確認方法：認証方式ごとにチェック

VLESS共有リンク

通常、@の前にはUUIDが入ります。
encryption=noneはTLSを無効にするという意味ではありません。
security、type、flowなどのパラメーターは、リンクの提供元に照らして確認してください。
WebSocketの場合は、hostとpathも確認してください。

Trojan共有リンク

通常、@の前にはパスワードが入ります。
一般的な構成ではTLSを使用します。サーバー名と証明書を確認してください。
特殊文字を含むパスワードは、正しくURIエンコードする必要があります。
通信方式の拡張は、提供元のパラメーターと実際の対応状況を確認してください。

プロトコル、認証情報、通信方式、TLSパラメーターは一組の設定です。schemeやポートだけを置き換えて変換しないでください。

例の%2Fdemoをデコードすると/demoになります。パーセントエンコードは、予約文字によってURIの構造が変わるのを防ぐために使います。たとえば、パスワードに含まれる#をそのまま記述すると、注釈の開始位置として認識される場合があります。コピーする際は元のエンコードを維持してください。通常、インポート機能がフィールドごとに処理します。何度も手動でデコードして貼り付けると、区切りが崩れることがあります。

ポート443は、サーバー側で選択できる待ち受けポートの一例にすぎません。ポート番号からプロトコルを推測したり、すべてのTLS接続を443に変更したりしないでください。証明書の検証に失敗した場合は、まずデバイスの日時、SNI、提供元のパラメーターを確認します。証明書検証を無効にすることを、通常の対処方法にしないでください。

単体リンクとサブスクリプション：取り込み方法と更新動作をそれぞれ確認

単体リンクを取り込むと、通常は接続設定がローカルに保存されます。その後サーバー側でパスワード、アドレス、通信パラメーターが変更されても、名前が同じというだけで古い項目が自動更新されることはありません。一方、サブスクリプションには再アクセスできる配信元が保存され、更新時に一覧を取得し直せます。ただし、毎回の取得成功を保証するものではなく、サービスの有効期限やアカウント状態の確認に代わるものでもありません。

サブスクリプションURLの形式例：
https://example.com/sub?token=xxxx

明らかなダミーURLです。「アドレス＋クエリ形式の認証情報」という構造のみを示しています。

単体リンクを取り込む：信頼できる提供元からリンク全体をコピーしてHomeに戻り、アプリのクリップボード取り込み機能を使います。クリップボードへのアクセスを求められた場合は、今回の取り込みに必要なときだけ許可してください。取り込み機能が表示されない場合は、Home右上の追加メニューを開き、既存の設定情報を使って項目を作成します。
サブスクリプションを取り込む：Home → 右上の+を開き、TypeでSubscribeを選択します。自分のサブスクリプションURLをURLに入力し、注釈を追加して保存してください。アカウントのログインページをURLに入力しないでください。
取り込み結果を確認する：サブスクリプションのグループ、ノードの種類、項目数が利用中のサービスの説明と一致するか確認します。注釈だけを見るのではなく、項目の編集画面でアドレス、ポート、通信設定を確認してください。
その後の更新：Homeでサブスクリプション項目の操作を開き、更新を実行します。自動更新を設定する場合は、Settings → Subscribeで更新設定を確認してください。アプリ起動時の更新は、システムが継続的に定期取得することを意味しません。また、単体リンクの項目がサブスクリプションに変わるわけでもありません。

提供元の情報を残してからローカルの項目を調整
サブスクリプションの更新によって、管理対象のノード情報が置き換わったり、一覧の順序や名前が変わったりすることがあります。サブスクリプションのノードをローカルで変更する前に、変更理由を記録し、元の設定情報を残してください。重要なカスタム項目は別に管理すると、更新による変更を手動設定の消失と誤認せずに済みます。

HTTPSは通信に所定の保護が使われることを示すだけで、返される内容がノード一覧であることを保証しません。更新後にログインページ、エラーページ、互換性のない形式のテキストが表示された場合は、元のサブスクリプションURL、有効期限、レスポンスの内容を確認してください。サブスクリプションのtokenはアクセス用の認証情報です。トラブルシューティングのために、URL全体を公開チャットやスクリーンショットに載せないでください。

取り込み後：まずノードを検証し、次にGlobal RoutingとConfigを確認

「リンクを解析できる」「項目を保存できる」「接続を確立できる」「目的のリクエストに適切なポリシーが適用される」は、それぞれ別の結果です。ノードの共有リンクが設定するのは主に接続情報であり、取り込みに成功しても、個人の用途に合ったConfigが自動作成されるわけではありません。Homeでは接続項目と接続状態を管理し、Configではルール設定を管理します。Settingsではアプリの動作を調整します。

Global Routing → Config

Global Routing → Proxy

Proxyモードを使い、振り分けルールが原因で対象のリクエストがプロキシ経由になっていないかを切り分けます。確認範囲を絞るための方法であり、不足しているUUID、パスワード、SNI、通信パスを補うものではありません。

適した用途：ノードの接続性やルールの影響を短時間で確認

Global Routing → Direct

Directモードで対象にアクセスすると、現在のネットワークから直接接続した場合の結果を確認できます。この方法だけでは、選択したプロキシノードが正常に動作しているとは判断できません。

適した用途：現在のネットワークとプロキシ経由の接続結果を比較

Global RoutingにはSceneも含まれます。設定したシーンの条件に応じてポリシーを適用するため、固定のProxyやConfigとして扱わないでください。Settings → On Demandはオンデマンド接続の動作を制御するもので、ノードのプロトコルでもサブスクリプションの更新スイッチでもありません。トラブルシューティング中は、接続のトリガー条件とテスト対象をそろえ、ネットワークの切り替えと自動起動によってテスト条件が同時に変わらないようにしてください。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
FINAL,DIRECT

以下はルール構文の例であり、完全な設定ではありません。DOMAIN-SUFFIXはドメインのサフィックス、IP-CIDRはIPアドレスの範囲、GEOIPはIPの地理データベース上の分類に一致し、FINALはそれ以前のルールに一致しなかったリクエストを処理します。ルールの順序によって結果が変わります。ノードの設定が正しくても、対象のリクエストがDIRECTに一致すれば、そのプロキシ経路は使われません。同じリンクを繰り返し取り込み直すより、リクエスト履歴で一致したルールと最終的なポリシーを確認するほうが効果的です。

よくある質問：解析・認証・通信・更新を分けて確認

ss://をコピーしたのに、ノードが取り込まれないのはなぜですか？

まず、プレフィックス、エンコード文字列、サーバー、ポートがすべて含まれているか確認します。リンクの外側に付いた引用符や説明文は削除しますが、リンク内部の文字は変更しないでください。チャットの書式によって空白や改行が挿入されたり、一部が省略されたりすることがあります。元の提供元から完全なテキストをコピーし直して、Homeで取り込んでください。それでも失敗する場合は、提供元の共有形式や拡張機能が対応しているか確認します。

VMessの取り込みには成功したのに接続できません。UUIDが間違っていますか？

必ずしもそうとは限りません。アドレスとポート、UUID、通信方式、WebSocketのHostとPath、TLS、SNIに加えて、デバイスの日時も順に確認してください。項目を保存できたのは入力が受け付けられたというだけで、サーバー側の認証や通信のハンドシェイクに成功したことを示すものではありません。原因を特定できなくならないよう、確認済みの相違点を一度に1つずつ修正してください。

VLESSのencryption=noneはTLSを使わないという意味ですか？

いいえ。この2つのパラメーターは異なる設定を表します。同じリンク内のsecurityを確認し、取り込み後の項目でTLS関連のオプションを確認してください。encryption=noneだけを見てTLSを無効にしないでください。通信方式とセキュリティの各パラメーターは、利用中のサービス設定に合わせる必要があります。

サブスクリプションの更新に成功したのに、選択中のノードが使えないのはなぜですか？

更新の成功は、サブスクリプションの内容を取得して処理できたことを示すもので、一覧内のすべてのノードが接続できることを保証しません。まずHomeで選択中の項目と接続状態を確認し、利用中のサービスの有効期限、ノード設定、Global Routingを確認してください。更新に失敗した場合は、URL、アクセス用認証情報、ネットワークへの到達性、レスポンス形式を調べます。この2つの現象を混同しないでください。

リンクのスクリーンショットを誰かに送って確認してもらってもよいですか？

まず、パスワード、UUID、サブスクリプションのtoken、QRコード全体を隠してください。QRコードは多くの場合、元のリンクを別の形で表したもので、認証情報を隠すものではありません。問題の確認には、プロトコル名、情報を伏せたパラメーター名、エラーメッセージ、試した手順を伝えます。実際の認証情報を確認する必要がある場合は、利用中のサービス提供元が指定する信頼できる連絡手段を使ってください。

最終確認の順序は、リンクの種類を見分ける → 元の全文を保存する → 対応する方法で取り込む → 認証情報と通信フィールドを確認する → 接続を検証する → ルールと更新動作を確認する、です。この記事で扱う4種類のschemeは、Shadowrocketの対応機能の全一覧ではありません。また、ほかのプロトコルも同じURIフィールドを使うとは限りません。既存の設定情報と実際の対応状況は、それぞれ確認してください。