Shadowrocket 共有リンクの形式と使い方|ss://・vmess://・vless://・trojan://とサブスクリプションの違い

ss://・vmess://・vless://・trojan://の構造やエンコード方式、単体リンクとサブスクリプションの違い、読み込めない場合の確認方法を解説します。

この記事の要点

Shadowrocket の単体共有リンクには接続パラメータが記載され、サブスクリプションリンクは更新可能なリモートリストを参照します。利用中のサービス提供元から接続情報を入手し、読み込みや認識の問題を確認したい方に向けて、リンクの接頭辞による種類の見分け方、エンコード・アドレス・認証情報・転送パラメータの確認方法を解説します。読み込み成功と接続成功は分けて確認しましょう。

1. 単体共有リンクとサブスクリプション URL を見分ける

ss://、vmess://、vless://、trojan://は、単体の接続情報によく使われるプロトコルの接頭辞です。サーバーアドレス、ポート、認証情報、必要に応じて転送設定が含まれます。テキストを QR コードに変換しても受け渡し方法が変わるだけで、単体リンクがサブスクリプションに変わるわけではありません。

サブスクリプションは通常、https://で始まる URL です。Shadowrocket がその URL にアクセスし、サーバーからリストを取得して項目を解析します。リストの内容は更新されても、URL 自体は変わらない場合があります。HTTPS で始まるだけでサブスクリプションと判断することはできません。通常の Web ページやログイン画面、エラーページは接続リストではありません。

4種類
この記事で解説する接頭辞:ss / vmess / vless / trojan
1件
通常の単体共有リンクには1組の接続パラメータが記載されます
443
後述の TLS 例で使うポートです。すべてのサービス共通の固定ポートではありません

2. ss://:Base64 の対象範囲を見分ける

Shadowsocks でよく使われる SIP002 形式では、ss://の後にBase64でエンコードしたmethod:passwordを置き、@の後にサーバーアドレスとポートを記述します。以下の例では、エンコード部分のYWVzLTEyOC1nY206dGVzdAをデコードするとaes-128-gcm:testになります。

ss://[email protected]:8388#Demo%20SS

旧形式の一部では、method:password@host:port全体がエンコードされています。Base64 が見つかっても、@より前だけを機械的にデコードしないでください。リンクによってはpluginクエリパラメータも含まれます。プラグイン名とオプションも接続情報の一部なので、コピー時に「?」以降を切り落とさないようにしてください。

Base64 と URL のパーセントエンコードは別の処理です。Base64 には+、/、末尾の=が含まれる場合があり、URL-safe Base64 では使われる文字が異なります。+をすべて空白に置き換えたり、すべてのリンクに決まった数のイコールを補ったりしないでください。完全な元データを入手し、対応する形式の処理は読み込み機能に任せましょう。

3. vmess://:エンコードされたデータは通常 JSON

よく使われる VMess 共有形式は、vmess://にBase64でエンコードした JSON を続けたものです。前の形式と異なり、デコード結果は通常、「パスワードとアドレス」の1行ではなく、フィールド名を持つデータ群です。以下はデコード結果の例で、共有リンクとしてそのまま貼り付けられるテキストではありません。

{
  "v": "2",
  "ps": "Demo VMess",
  "add": "example.com",
  "port": "443",
  "id": "11111111-1111-4111-8111-111111111111",
  "aid": "0",
  "scy": "auto",
  "net": "ws",
  "type": "none",
  "host": "example.com",
  "path": "/demo",
  "tls": "tls",
  "sni": "example.com"
}
フィールド確認内容
add / port実際に接続するサーバーとポート。ポートは有効な数値である必要があり、全角コロンが混入していないか確認します。
id / aidUUID と Alter ID。サーバー側の情報に従って入力し、UUID を通常のパスワードのように任意に変更しないでください。
net / host / path転送方式と追加パラメータ。WebSocket のパスでは、スラッシュと大文字・小文字をそのまま保持します。
tls / sniTLS 設定とサーバー名。ポートが443という理由だけで、設定値を決めつけないでください。

例にあるvは共有形式のフィールドであり、Shadowrocket のアプリバージョンではありません。生成ツールによって出力されるフィールドの組み合わせは異なります。存在しないフィールドすべてに同じ既定値を使えるとは限りません。読み込み後は項目の詳細を開き、元の情報と UUID、転送方式、TLS、パスを照合してください。コメントとアドレスが正しくても、ほかのパラメータが正しいとは限りません。

4. vless:// と trojan://:構造は似ていても認証情報は異なる

どちらの共有形式も、@の後にアドレスとポートが記載され、疑問符以降のクエリパラメータでセキュリティ層や転送設定を表します。ただし、見た目が似ていても同じプロトコルではありません。VLESS の UUID と Trojan のパスワードを取り違えないでください。

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

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

ここで紹介した例は一般的な形式を扱ったもので、すべての転送方式の組み合わせを網羅するテンプレートではありません。元のリンクに追加パラメータがある場合は、全文を保持し、現在のクライアントが対応する設定に変換できるか確認してください。読み込み時にエラーが出なかったというだけで、理解できないパラメータを削除しないでください。また、SNI、システム時刻、証明書の設定を確認する代わりに、証明書検証を無効にしないでください。

5. Home で読み込んだ後、リストとルールを分けて管理する

単体リンクとサブスクリプションでは管理対象が異なります。前者は通常、独立した項目として追加され、後者はリモートリストとの関連を維持します。サブスクリプションを更新すると、項目が同期・削除されたり再作成されたりする場合があります。そのため、サブスクリプション内の項目に加えたローカル変更が、サーバー側の設定として永続的に保存されるとは限りません。

  1. 利用中のサービス提供元から完全な元データを入手します。単体プロトコルリンク、QR コード、サブスクリプション URL のどれかを確認し、説明文や引用符、チャットメッセージ内の省略記号を含めないでください。
  2. 単体リンクはクライアントのクリップボード読み込み機能から、QR コードはスキャン機能から読み込みます。完了したらHomeに戻り、項目が追加されたことを確認してください。
  3. サブスクリプション URL はHome → + → Type → Subscribeから追加し、完全な URL と判別しやすいコメントを入力します。画面の配置はプラットフォームによって異なる場合があります。同じ名称のサブスクリプションタイプを選択してください。
  4. サブスクリプションの更新後、項目数とエラーメッセージを確認します。例の URL https://example.com/sub?token=xxxxはURLの構造を示すだけで、実際のリストを提供するものではありません。
  5. 項目の詳細でパラメータを確認し、使用する項目を選んで接続を開始します。ルール設定はConfigで別途管理してください。通常の接続先リストをルール設定一式と混同しないようにしましょう。

接続テストではGlobal Routingも確認してください。選択した項目をリクエストに使うかどうかに影響しますが、誤った共有リンクのパラメータを修正する機能ではありません。以下では Shadowrocket のルーティング設定を比較します。「おすすめ」は、日常的にルール設定を利用している場合を指します。

Config

おすすめ

現在の設定ルールに従って通信先を決定します。PROXY に一致しているかどうかは、リクエストログの実際の判定結果で確認してください。

適した用途:ルールを設定済みで、日常的な振り分けを確認したい場合

Proxy

クライアントが処理する通信にプロキシ経路を使用します。ルールに一致しないことによる影響を一時的に切り分けるのに便利です。

適した用途:読み込み済み項目の接続可否だけを確認したい場合

Direct

直結経路を使用します。この状態で Web ページを開けても、読み込んだ項目を経由するプロキシ接続が使えるとは限りません。

適した用途:ローカルネットワークの直接接続と比較したい場合

まとめ:一度に確認するのは1つの段階

まず項目のパラメータがすべてそろっていることを確認し、一時的に Proxy を使って接続を検証します。最後に Config に戻り、ルールへの一致を確認してください。こうすることで、解析エラー、接続エラー、通信の振り分け結果を切り分けられます。複数箇所を同時に変更して原因が分からなくなる事態も防げます。

6. 認識できない場合は、テキスト・エンコード・応答の順に確認する

「リンクを認識できない」と「接続がタイムアウトする」は異なる段階で発生します。前者はテキストやサブスクリプション内容の解析時、後者は通常、パラメータを取得して接続を開始した後に発生します。まずエラーが起きた手順を確認し、情報を再コピーするか、ネットワークやサーバー設定を確認するか判断してください。

リンクをコピーしたのに、読み込み可能な項目が追加されないのはなぜですか?

元のテキストをローカルのテキストエディタで確認し、先頭に完全なプロトコル接頭辞があること、末尾にチャット由来の句読点がないこと、本文が改行や空白で途切れていないことを確かめます。QR コードのスクリーンショットしかない場合は、画像ファイル名をコピーするのではなく、QR コードをスキャンしてください。

vmess://をデコードすると文字化けして見えます。どこを修正すればよいですか?

まず Base64 部分をすべてコピーできているか確認し、標準 Base64 と URL-safe Base64 を区別してください。文字列全体に URL デコードを繰り返し適用しないでください。一般的な JSON 形式なら、デコード後に add、port、id などのフィールドを確認できます。内容が不完全な場合は元のリンクを再取得し、UUID を推測で補わないでください。

サブスクリプション URL をブラウザで開けるのに、更新に失敗するのはなぜですか?

ブラウザで開くとログイン画面、認証画面、エラーページが表示されることがあり、リストが返されたとは限りません。クエリパラメータを含む URL 全体が保持されているか確認してください。応答が401または403の場合は、アクセス認証情報と権限をサービス提供元に確認します。404の場合は、パスが有効か確認してください。Web ページの本文を接続先リストとして貼り付けないでください。

読み込みには成功したのに接続できません。エンコードに問題がありますか?

まずサーバーアドレス、ポート、パスワードまたは UUID を確認し、次に TLS の SNI、WebSocket の Host とパスを確認してください。証明書関連のエラーが表示された場合は、システム時刻と証明書名を確認します。タイムアウトする場合は、ネットワークからの到達性とサービスの状態を確認してください。エンコードを解析できても、サーバー側でそのパラメータが受け入れられるとは限りません。

サブスクリプションを更新したら、手動で変更したコメントやパラメータが変わったのはなぜですか?

更新時にサーバー側のリストから項目が再作成されることがあります。まずサービス提供元の最新パラメータと照合し、変更がリモート側の内容によるものか確認してください。ローカルでの変更を保持する必要がある場合は、独立した項目とサブスクリプション項目を明確に区別し、複数のコピーから古い情報を誤って選ばないようにしてください。

確認後に問題を報告する際は、プロトコル名、失敗した段階、個人情報などを伏せたエラー情報だけを共有してください。サーバーアドレス、UUID、パスワード、サブスクリプショントークン、QR コードはアクセス権限に関わる可能性があります。構造を示す必要がある場合は、この記事の例のようにフィールド名を残し、実際の値を置き換えてください。完全な情報は、必要な場合に限り、管理された安全な経路で共有してください。

Shadowrocket をダウンロード