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

この記事の内容

自分の接続情報を持っているものの、どのリンクを読み込めばよいかわからないiPhone・iPadユーザー向けの記事です。共有リンク、サブスクリプションURL、ルール設定の違いを整理し、よく使われる4種類のリンクに含まれる認証情報や転送設定を確認したうえで、Homeで読み込み結果と更新方法を確認します。例として掲載する情報はすべて接続に使えないデモ用です。当サイトではサーバーやサブスクリプションを提供・販売・推奨していません。

1. 共有リンク・サブスクリプションURL・ルール設定の違い

Shadowrocketのサーバー情報、サブスクリプションの登録先、振り分けルールは、それぞれ異なる役割を持ちます。共有リンクには1台分の接続情報が含まれ、サブスクリプションURLは再取得できるリモートコンテンツを指し、ルール設定は接続リクエストの振り分け方法を決めます。どれもテキストやURLの形をとる場合がありますが、互いに置き換えることはできません。

種類	主な内容	読み込み後の確認項目
単体の共有リンク	プロトコル、サーバーアドレス、ポート、認証情報、任意の転送設定	Homeに表示される該当サーバーの編集内容
サーバーのサブスクリプションURL	リモートURLとアクセス認証情報。応答にはサーバー一覧が含まれる	Homeに登録したサブスクリプションと、その配下の項目
ルール設定	ルール、ポリシーなどの設定内容（ファイルによって異なる）	Configで実際に選択されている設定とルール

https://で始まるURLが、必ずサーバーのサブスクリプションとは限りません。ログインページ、ヘルプページ、ルール設定を指している場合もあります。URLの長さではなく、既存サービスの用途説明と応答内容で判断してください。サーバー一覧のサブスクリプションに、DNSや振り分けルールの設定まで含まれているとは限りません。読み込み後は、現在のGlobal Routingも確認しましょう。

2. ss://とvmess://：Base64でエンコードされる内容の違い

ss://：暗号化方式とパスワード、続いてアドレスとポートを確認

ss://はShadowsocksの共有リンクを示します。一般的なSIP002形式では、「暗号化方式:パスワード」をBase64でエンコードしたuserinfoに含め、サーバーアドレスとポートは外側に記載します。以前の形式では、接続情報全体がエンコードされていることもあります。すべてのss://リンクを同じ位置で機械的に分割しないようにしましょう。

デコード後のuserinfoの例：
aes-256-gcm:demo-password

対応するサーバー情報の例：
Server: example.com
Port: 8388
Method: aes-256-gcm
Password: demo-password

ここでの8388は説明用のポート番号であり、Shadowsocksで必須のポートではありません。実際のポートは、利用中のサービスの設定に合わせてください。リンクにはpluginクエリパラメータや、#以降のメモが含まれる場合もあります。メモは項目の識別に使うもので、アドレスの代わりにはなりません。サービスで追加のプラグイン設定が必要な場合、アドレス、パスワード、ポートだけでは接続できないことがあります。

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

一般的なvmess://共有リンクは、JSONオブジェクトをエンコードしてプレフィックスの後ろに配置します。以下はデコード後の読み取り例で、インポート欄にそのまま貼り付けられる完全なリンクではありません。実際の共有形式には複数のバリエーションがあるため、読み込み後に表示される項目を確認してください。

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

addとportはサーバーアドレスとポート、idは認証に使うUUIDです。
netがwsの場合は、WebSocketで通信します。pathとhostはその転送方式の設定項目です。
tlsとsniはTLS接続に影響します。ポートが443だからといって、TLSの設定がすべてそろっているとは限りません。
vはこの形式の共有JSONにおけるフォーマット項目で、Shadowrocketのバージョン番号ではありません。psは通常、表示用のメモです。

読み取り可能でも、確認できるのはテキスト構造だけ

Base64はエンコード方式であり、認証情報を保護する暗号化ではありません。構造を確認する場合はローカルで処理し、共有リンク全体をオンラインのデコードサイトに入力しないでください。読み込み後はプロトコル、ポート、転送設定を一つずつ確認してから接続テストを行いましょう。

3. vless://とtrojan://：URIで省略できない項目

vless://とtrojan://は、比較的読み取りやすいURI形式を使うことが一般的です。プレフィックスの後ろに認証情報、@の後ろにサーバーアドレスとポート、?の後ろにクエリパラメータ、#の後ろにメモが続きます。読み取りやすくても機密情報であることに変わりはないため、認証情報はパスワードと同様に扱ってください。

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

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

項目または位置	意味	確認方法
`@`より前	VLESSの例ではUUID、Trojanの例ではパスワードを使用	2種類の認証情報を取り違えない
`example.com:443`	サーバーアドレスとポート	ポートは利用中のサービスの設定に合わせる
`security=tls`	共有形式に含まれるTLS設定	読み込み後のTLS設定と証明書名を確認
`sni`	TLSハンドシェイクで使用するサーバー名	サービスで指定された名前と一致させ、アドレスに置き換えない
`type=ws`、`host`、`path`	WebSocket転送とリクエスト設定	パスの大文字・小文字、スラッシュ、Hostをすべて確認
`#Demo-VLESS`	表示用のメモ	メモを変更しても認証や転送の誤りは解消されない

VLESSの例にあるencryption=noneは、プロトコル関連の設定を示しています。これだけで接続全体にTLSが使われていないとは判断できません。TLSの有無はsecurityと読み込み後の実際の設定で確認してください。同様に、443からわかるのはポート番号だけであり、証明書の検証、SNI、WebSocketのパスが正しいことまでは確認できません。

URL内の特殊文字はパーセントエンコードが必要な場合があります。例の%2Fdemoをデコードすると/demoになります。手作業で処理する場合は、何度もデコードしてリンクに再結合しないでください。また、パスワードに含まれる@や#を構造上の区切り文字として扱わないようにしましょう。IPv6アドレスをURIのホスト部分に指定する場合は、アドレス内のコロンとポートの区切りを混同しないよう、通常は角括弧で囲みます。

4. サブスクリプションURL：登録元を保持し、一覧を更新

サーバーのサブスクリプションには、以下の明らかなダミー値のようなHTTPS URLが使われます。読み込み時にShadowrocketがURLへアクセスして応答を解析し、選択可能なサーバー項目を作成します。応答は複数の共有リンクを含むテキストの場合もあれば、全体がエンコードされている場合もあります。サブスクリプションURLだけから、Shadowsocks、VMess、VLESS、Trojanのどれが使われているかを推測することはできません。

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

読み込み方法：手元の情報に合った追加方法を選ぶ

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

ss://、vmess://、vless://、trojan://から始まるリンクを、末尾までコピーします。
Homeの追加機能から読み込むか、リンクを表示したQRコードをスキャンして読み込みます。
追加された項目を開き、Type、アドレス、ポート、認証情報を確認します。
設定に変更があった場合は、再読み込みするか該当項目を手動で修正してください。

サーバーのサブスクリプションURLがある場合

Home → +の追加画面で、TypeにSubscribeを選択します。
URL欄に完全なアドレスを入力し、パス、クエリパラメータ、tokenを省略せずに残します。
保存して一覧を取得し、登録元の下に想定したサーバーが表示されるか確認します。
リモート側の変更を反映するには、同じ登録元を重複して追加せず、サブスクリプションを更新します。

QRコードやクリップボードは入力方法にすぎません。QRコードの内容が単体の共有リンクかサブスクリプションURLかによって、読み込み後の管理方法が決まります。

サブスクリプションを更新すると、リモートの登録元に再アクセスします。項目数、名前、アドレス、認証情報が変わる場合があります。更新に成功しても、選択中のサーバーに接続できるとは限らず、通信ルールが正しく設定されているとも限りません。更新前に、現在使っている項目を記録しておきましょう。サブスクリプション配下の項目に加えたローカル変更が維持されるとは限りません。次回の更新時に関連項目が再作成されることがあります。

応答がログインページの場合、HTTPリクエストに応答があっても、有効なサーバー一覧として扱うことはできません。
登録元でtokenが無効化されている場合、古いURLを何度貼り付けてもアクセス権は戻りません。利用中のサービスで現在有効なURLを確認してください。
リンクに&が含まれる場合は、その文字を表すHTMLエンティティではなく、実際のアドレスをコピーしたか確認してください。
サブスクリプションURL全体がアクセス認証情報として機能する場合があります。スクリーンショットを共有するときは、ドメインだけでなくパスとクエリパラメータも隠してください。

5. 読み込み後にHome・Config・Settingsで確認すること

Homeではサーバーの確認と選択を行い、読み込み結果を確かめます。Configではルール設定を管理し、Settingsにはアプリの設定があります。共有リンクにtype=wsが含まれているからといって、Configの振り分けルールと混同しないでください。プロトコルの転送方式はサーバーへの接続方法を決め、ルールはリクエストに適用するポリシーを決めます。両者は異なる役割です。

まずHomeで追加項目の編集画面を開き、Typeが元のリンクのプレフィックスと一致することを確認します。続いてサーバーアドレス、ポート、認証情報、TLSや転送設定を確認してください。
サブスクリプションを読み込んだ場合は、項目が想定した登録元に属しているか確認します。以前に追加した同名の単独項目と取り違えないようにしましょう。
Global Routingを確認します。普段どおりルールに従って使う場合は、Configが選択され、Config画面で想定した設定が選ばれているか確認してください。
利用する権限のあるサーバーを選択し、接続を開始します。システムのVPN設定を許可してから、実際のリクエストで動作を確認してください。
自動再接続の動作を確認する場合は、Settings → On Demandを確認します。これはサブスクリプションの更新設定ではなく、不足しているサーバー情報を補う機能でもありません。

Config：現在の設定に従って振り分け

Proxy：ルールの影響を一時的に切り分ける

プロキシで処理できるリクエストを、現在選択中のプロキシに送ります。Config使用時の動作との比較に使えます。サーバーのパスワード、TLS、転送設定の誤りは修正できず、ネットワーク全体のテストの代わりにもなりません。

適した用途：同じサーバーで、振り分けルールが原因かどうか一時的に確認する場合

Direct：直接接続で比較

リクエストを直接接続で処理します。この状態でWebページが開いても、読み込んだサーバーが使える証明にはなりません。リクエストがそのサーバーを経由していない可能性があるためです。

適した用途：ローカルネットワークの基本的な接続を短時間確認し、比較材料にする場合

ルール設定のDOMAIN-SUFFIXはドメインのサフィックスに一致します。GEOIPとIP-CIDRは、それぞれ該当するIP条件に使用されます。FINALは、先行するルールに一致しなかった場合のフォールバックを担います。これらは4種類の共有リンクのクエリパラメータではなく、サーバーを読み込んだだけで利用目的に応じて自動作成されるものでもありません。ルール設定については使い方ガイドまたはトラブルシューティングガイドをご覧ください。

6. 読み込み・更新でよくある質問

リンクをコピーしてもサーバーが表示されません。プロトコルが違うのでしょうか？

まず、コピーした内容がプロトコルのプレフィックスから始まり、「クリックして読み込み」などの説明文が混ざっていないこと、チャットアプリによって改行が挿入されていないことを確認します。Home → +に戻り、追加タイプを確認してください。単体の共有リンクはサーバー情報として扱い、HTTPSのサブスクリプションにはSubscribeを選びます。それでも認識されない場合は、元の完全なリンクを確認し、プレフィックスを自分で置き換えないでください。

QRコードを読み取れたのに、接続できないのはなぜですか？

スキャンに成功したことが示すのは、QRコードのテキストを読み取れたということだけです。Homeで該当項目を開き、ポートがすべて入力されているか確認してから、UUIDまたはパスワード、SNI、WebSocketのパスなどを確認してください。QRコードの内容が期限切れ、またはWebページのURLである可能性もあります。スキャン時の表示だけでサーバーの接続可否を判断しないでください。

遅延に数値が表示されるのにWebページが開かない場合は？

遅延の結果だけでは、認証、DNS、TLS、接続先サイトへのアクセス全体を確認できません。まず、確認済みのサーバーが選択されているか確かめ、Global Routing → ProxyとConfigで一時的に動作を比較します。Configだけで問題が起きる場合は、ルールの適用状況を確認します。両方とも失敗する場合は、表示名だけを変更するのではなく、認証、TLS、転送設定を確認してください。

サブスクリプション更新後に同じ名前の項目が表示されました。どれを削除すればよいですか？

まずHomeで単独項目とサブスクリプション配下の項目を区別し、アドレス、ポート、プロトコルを比較してください。名前が同じでも接続情報が同じとは限りません。古い単独項目が不要だと確認してから削除します。同じサブスクリプションを二重に追加していた場合は、有効性を確認した登録元を残しましょう。2つのリストを別々に更新する事態を避けられます。

サブスクリプションURLがタイムアウトします。ポートを443に変更できますか？

推測したポートで、既存の設定を置き換えないでください。HTTPSのサブスクリプションURLにアクセスするポートと、一覧にあるサーバーへの接続ポートは別のものです。まず現在のネットワークから登録元にアクセスできるか、URLが完全か、tokenが有効かを確認します。Webページから応答があっても、ログインページが返された場合は更新成功とは判断できません。

7. 最終確認：形式、登録元、実際の通信を確認

読み込み後は、「テキストが認識された」「サーバー情報が正しい」「リクエストが想定した経路で完了した」の3点をそれぞれ確認してください。これらは互いに代替できません。読み込み成功で作成されるのはローカルの記録です。更新成功で取得されるのはリモートの内容です。実際にアクセスできるかは、サーバーの状態、現在のネットワーク、DNS、ルーティング設定によって異なります。

リンクの種類：単体サーバーの共有リンク、更新可能なサブスクリプション、ルール設定のURLのどれかを確認します。
認証と転送：プロトコル、アドレス、ポート、パスワードまたはUUID、TLS、SNI、Host、pathなど、必要な設定を確認します。
登録元と更新：サブスクリプションの登録元が有効であること、単独項目を自動更新される項目と取り違えていないことを確認します。
ルーティングとテスト：Global Routingが現在の設定と一致していることを確認し、遅延の数値だけでなく実際のWebリクエストで動作を確かめます。
認証情報の保護：共有リンク全体、QRコード、token付きのサブスクリプションURLを公開しないでください。漏えいした場合は、利用中のサービスで該当する認証情報を対処してください。

次の手順：一度に変更するのは1つだけ

元のリンクを保管して読み込み項目を確認します。項目が正しければ接続を確認し、接続できてからルールを調整してください。ポート、TLS、Global Routingを同時に変更すると、接続が回復しても、どの変更が有効だったのか判断できません。