単体ノードの共有リンクには接続パラメータが保存され、サブスクリプションURLはノード一覧を再取得するための入口です。サービスとサブスクリプションをすでに利用していて、インポート形式を確認したい方向けに、リンクの種類、エンコード、アドレス、ポート、TLSの項目を順に確認し、インポート成功・接続成功・ルール適用の違いを説明します。ドメイン、パスワード、UUID、tokenはすべて説明用のダミー値で、実際の接続には使用できません。
[URI] パラメータリンクとサブスクリプションURLを区別する
Shadowrocketの単体ノードとサブスクリプショングループは、異なる種類のデータです。ss://、vmess://、vless://、trojan://で始まる共有リンクには、通常1つのノードの接続パラメータが含まれます。一方、https://で始まるサブスクリプションURLは、クライアントがサーバーにリクエストし、応答内容を読み込んでノード一覧を生成します。リンクの長さだけでは種類を判断できません。
共有リンクはパラメータのスナップショットです。インポート後にリモート側のアドレスやパスワードが変更されても、個別に保存したノードには自動反映されません。サブスクリプションURLは情報を取得する入口を保持しているため、更新すると最新の一覧を取得できます。ただし、常時プッシュされるわけではなく、一覧が変わるかどうかはサーバーの応答内容と更新の成否によります。
- 単体ノード：scheme、認証情報、サーバーアドレス、ポート、通信パラメータ、備考を確認し、ノードとしてインポートします。
- サブスクリプション：パスやクエリパラメータを含むURL全体を確認し、サブスクリプションの追加画面で保存してから、取得したノード一覧を確認します。
- 設定ファイル：設定やルールの管理に使います。共有リンク1行を完全な
.confファイルとして扱うことはできません。
[Encoding] Base64、パーセントエンコード、区切り文字
Base64はエンコードであり、暗号化ではありません。共有リンクを入手した人は、通常その中のパスワードやUUIDを復元できます。サブスクリプションURLのtokenも認証情報として管理してください。リンク全体、QRコード、デコード結果を不審なサイトに渡さないでください。トラブル対処では、項目の有無だけを記録し、機密情報は伏せてください。
| 記号・エンコード | 主な用途 | 確認方法 |
|---|---|---|
:// | schemeと後続部分を区切る | 半角記号をそのまま保ち、空白や改行を挿入しないでください。 |
@ | 認証情報とホスト部分を区切る | パスワードに含まれる文字としての@は、通常%40と記述します。 |
?と& | クエリパラメータを開始・区切りする | 元のリンクをコピーし、ウェブページのソースにある&をパラメータ区切り文字として扱わないようにしてください。 |
# | fragmentを開始する。備考によく使われる | 備考内の空白は%20にエンコードできます。サーバー認証には使われません。 |
Base64 | 認証情報、JSON、サブスクリプション本文を囲む | 標準とURL-safeの文字セットを区別し、URI全体をむやみにデコードしないでください。 |
標準Base64には+、/、末尾の=が含まれることがあります。URL-safe形式では-と_が使われ、実装によっては末尾のパディングが省略されます。パーセントエンコードは別の構文レイヤーを処理するもので、たとえば%2Fはスラッシュを表します。これらのエンコード方式は置き換えられません。また、すべての+を空白に変換しないでください。
[Check]形式に応じてエンコードされた部分を特定してから、1回だけデコードします。
%2Fを二重にエンコードして%252Fにしたり、リンク全体の区切り文字をすべてエンコードしたりすると、解析結果が変わります。
[Shadowsocks] ss://の認証情報とサーバー項目
一般的なSIP002形式では、暗号化方式とパスワードがuserinfoにエンコードされ、サーバーアドレスとポートは読み取れる形で記述されます。以下の例のBase64データはaes-128-gcm:testで、testは説明用のパスワードです。ポート8388も例示値であり、Shadowsocksで必須のポートではありません。
ss://[email protected]:8388#Demo%20SS- scheme：
ssはShadowsocksを指定します。インポート後に別のプロトコルへ変更しないでください。 - userinfo：デコードすると、暗号化方式
aes-128-gcmとパスワードtestが得られます。両者はコロンで区切られています。 - ホストとポート：
example.com:8388は接続先を表します。実際に使用する際は、利用中のサービスの設定と一致している必要があります。 - 備考：
Demo%20SSはDemo SSにデコードされます。ノードを識別するための表示名です。
旧形式の共有リンクでは、ホストとポートを含む部分全体がBase64エンコードされている場合もあります。そのため、すべてのss://リンクに読み取り可能な@example.comが含まれるとは限りません。pluginパラメータを含むリンクでは、プラグインとそのオプションも確認してください。Shadowsocksと判別できても、追加の通信パラメータがすべて揃っているとは限りません。IPv6リテラルアドレスでは、ポートとの区切りのコロンと混同しないよう、ホスト部分を角括弧で囲むのが一般的です。
[VMess] vmess://でよく使われるBase64 JSON
一般的なvmess://共有形式では、schemeの後にBase64エンコードされたJSONを配置します。以下はデコード後の例で、そのまま貼り付けてインポートできる完全なURIではありません。項目の役割を確認できるよう、値にはダミーのドメインとUUIDを使用しています。
{
"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。認証に使われるため、ノードの備考では代用できません。aid：Alter ID項目。この例では0です。値を適当に大きくするのではなく、利用中のサービス設定に合わせて確認してください。net、host、path：この例ではWebSocketを使用し、通信方式、関連するHost、パスをそれぞれ指定します。tlsとsni：TLSの有効状態と、TLSハンドシェイクで使用するサーバー名を示します。ノードの表示名とは異なります。
JSONのvは共有形式の項目であり、Shadowrocketのアプリバージョンではありません。psは備考で、パスワードではありません。エクスポートの実装によって項目の構成は異なるため、この例をすべてのVMessリンクに共通する唯一の形式と考えないでください。インポート後、プロトコルは正しいのにパスが失われている場合は、UUIDだけでなくノード編集画面で通信パラメータを確認してください。
[VLESS / Trojan] 読み取り可能なURIの認証情報とTLS
VLESSとTrojanで一般的な共有形式は、どちらも読み取り可能なURI構造を採用しています。ただし、@の前にある認証情報の意味は異なり、VLESSでは通常UUID、Trojanでは通常パスワードです。VLESS自体はTLSと同等の通信暗号化を提供しません。この例ではsecurity=tlsでTLSを指定しています。プロトコル名だけで接続のセキュリティ設定を判断することはできません。
vless://[email protected]:443?encryption=none&security=tls&type=ws&host=example.com&path=%2Fdemo&sni=example.com#Demo%20VLESS
trojan://demo%[email protected]:443?security=tls&type=tcp&sni=example.com#Demo%20Trojan認証項目と通信項目を分けて確認する
認証情報と接続先
- VLESSのUUID：この例では説明用の完全なUUIDを使用しています。
- Trojanのパスワード：
demo%40passはdemo@passにデコードされます。 - どちらの例も
example.com:443に接続します。ポートは固定値ではありません。
TLSと通信方式
sniはTLSハンドシェイクで使用するサーバー名です。type=wsの例では、Hostと/demoのパスも確認してください。type=tcpにWebSocketのパス設定をそのまま適用しないでください。
接続先アドレス、TLS SNI、WebSocket Hostはそれぞれ異なる役割を持つ場合があります。同じ値かどうかは既存の設定で確認し、ドメイン名を見ただけで一律に置き換えないでください。
VLESSの例にあるencryption=noneは、この例でTLSを無効にしているという意味ではありません。security=tlsとは別のレイヤーの設定です。Trojanの例ではパスワードに特殊文字が含まれるため、@をパーセントエンコードしています。リンクを「正常に見せる」ためにエンコードを削除しないでください。また、SNIや証明書名の不一致を隠す目的で証明書検証を無効にしないでください。
クエリパラメータの名前や拡張機能への対応は、共有形式の実装によって異なる場合があります。既存のリンクに追加項目がある場合は値をそのまま保ち、インポート後にShadowrocketのノード編集画面で対応する設定を1つずつ確認してください。ノード名が表示されているだけでは、すべてのパラメータが読み込まれたとは限りません。
[Subscribe] 単体ノードのインポートとサブスクリプションの更新
以下のサブスクリプションURLは構造を示すためのもので、実際に使えるサービスの入口ではありません。token=xxxxは明らかなダミー値です。実際のURLに含まれるtokenは公開しないでください。一般的なウェブページのURLもHTTPSで始まる場合があります。応答内容がサブスクリプションの解析要件を満たす場合にのみ、ノード一覧を生成できます。
https://example.com/sub?token=xxxx- すでに単体ノードのリンクがある場合：URI全体をコピーし、アプリ内のリンクインポート機能で読み込みます。インポート後、Homeからノードの編集画面を開き、種類、アドレス、ポート、通信パラメータを確認してください。
- すでにサブスクリプションURLがある場合：Home → Add Serverを開き、Subscribeを選択します。既存のサブスクリプションURLを入力して保存し、サブスクリプショングループとノード一覧を確認してください。
- 利用中のサービス設定が変更された場合：サブスクリプショングループは更新します。個別にインポートしたノードは、新しいリンクを再インポートするか、新しい設定に合わせて手動で変更してください。
- 更新前に手動変更した項目がある場合：残しておきたい設定を先に保存してください。サブスクリプションの更新で、サーバー管理のノードが再生成されることがあります。ローカルで変更した名前や項目が更新後も保持されるとは限りません。
サブスクリプションの応答は、複数の共有リンクを含む場合も、一覧全体をBase64エンコードした内容の場合もあります。応答全体のエンコードと、単体ノード内のエンコードは別々のレイヤーです。外側をデコードしても、中のvmess://にBase64 JSONが含まれていることがあります。サブスクリプション本文を1つのパスワード項目として扱わず、デコード済みのリンク一覧を再び1つのURIに連結しないでください。
要点：リモート設定が変更されたら、まずノードの取得元を確認
Subscribeグループの場合は、まず更新して取得した一覧を確認します。個別ノードの場合は、新しい共有リンクを使用してください。接続のオン・オフを何度切り替えても、個別URIの最新パラメータは再取得されません。
[Routing] インポート後に接続とルールを確認する
リンクのインポートで保存されるのは接続パラメータです。すべてのリクエストのルーティング方法が決まるわけではありません。Homeではノードと接続状態、Configでは設定、Settingsではアプリの設定を確認できます。トラブル対処では、まずHomeで選択中のノードを確認し、次にGlobal Routingを確認してください。ノードが一覧に表示されているだけで、リクエストが必ずそのノード経由になるとは限りません。
Global Routing → Config
推奨既存のルールを適用して接続する場合はConfigを選び、現在有効な設定を確認してください。通常、ルールは順番に照合され、最終的な接続先は一致したポリシーによって決まります。
適した用途：設定済みのルールによる通常の振り分けを確認する
Global Routing → Proxy
プロキシ経路を一時的に確認し、Configのルールで直結になった結果をノードの障害と誤認するのを防ぎます。確認後は元の利用モードに戻してください。
適した用途：ルールの影響を切り分け、選択中のノードの接続状態を確認する
Global Routing → Direct
直結経路を使用するため、インポートしたプロキシノードが使えることの確認にはなりません。直結でウェブページを開けることと、そのノードの認証が成功することは別です。
適した用途：ローカルネットワークから直接アクセスした場合と比較する
Global RoutingのSceneは、設定済みのシーンに照らして確認してください。ProxyやConfigと同じものではありません。以下はルールの順序を理解するための[Rule]の抜粋です。完全な設定ではなく、既存ファイルへの上書きにも使用しないでください。ドメインとIP範囲は説明用です。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYDOMAIN-SUFFIXはドメインのサフィックスで照合します。この行に一致すると、指定されたポリシーが適用されます。IP-CIDRはIP範囲で照合します。no-resolveを指定すると、このIPルールのためにドメイン名を積極的に解決することを避けます。GEOIPはIPアドレスの地域情報で照合するもので、共有リンクのプロトコル項目ではありません。FINALは、それ以前のルールに一致しなかった接続を処理します。単体ノードのURIがこの行を自動生成することはありません。
Settings → On Demandでは、条件に応じて接続を開始する動作を管理します。ノード認証の代わりにはならず、誤ったURIも修正しません。インポート結果を確認する場合は、まず接続が確立しているか、正しいノードが選択されているかを確認し、その後に自動接続の条件を確認してください。複数の項目を同時に変更しないようにします。
[Troubleshooting] 共有リンクの解析・更新でよくある質問
リンクをコピーしたのに、ノードがインポートされないのはなぜですか？
まず、先頭に完全なschemeがあるか確認します。コピーした内容に説明文、引用符、空白、チャットアプリが挿入した改行が含まれていないかも確認してください。完全なURIを1つだけコピーします。HTTPSのサブスクリプションURLが渡された場合は、単体ノードのパスワードとして貼り付けず、Subscribeから処理してください。
ノードは表示されたのに、接続できないのはなぜですか？
Homeで選択中のノードのアドレス、ポート、認証情報を確認し、TLS SNI、WebSocket Host、パスも確認してください。続いてGlobal Routingを確認します。Directモードでのアクセス結果では、プロキシノードの動作を検証できません。設定が利用中のサービス情報と一致している場合は、プロトコルをむやみに変更せず、サーバー側の状態を確認してください。
サブスクリプションの更新後に一覧が空になりました。以前のリンクはまだ使えますか？
まず元のサブスクリプションURLを保持し、tokenとクエリパラメータが完全か確認します。次に、ログイン画面やエラーページ、空の応答ではなく、ノード情報が返されているかを確認してください。以前のノードがまだ接続できるかは、サーバーが古い設定を引き続き受け入れるかどうかによります。一覧が空というだけでは判断できません。
サブスクリプション内のノードを1つ共有した場合、相手側でも自動更新されますか？
通常は更新されません。ノード単体を共有すると、その時点のパラメータのスナップショットが渡され、元のサブスクリプションとの更新関係は含まれません。リモートの一覧の変更を取得するには、対応するサブスクリプションURLを保存して更新する必要があります。共有する前に、認証情報を開示する権限があることも確認してください。
リンクの#以降にある名前を変更すると、接続に影響しますか？
この記事で扱うURI形式では、fragmentは備考に使われます。名前を変更しても、サーバーアドレス、パスワード、UUIDは変わりません。変更後にインポートできない場合は、前のパラメータを誤って削除していないか、備考の特殊文字が未エンコードの区切り文字になっていないか確認してください。
最後に「リンクの種類 → エンコードの完全性 → 認証項目 → 通信方式とTLS → 現在のルーティングモード」の順に確認します。一度に変更するのは1項目だけにし、元の値を記録してください。解析エラー、サーバーによる拒否、TLS検証エラー、ルールがプロキシを経由しない状態を切り分けられ、再インポートの繰り返しで原因を見失うのを防げます。