自分で用意したサービスの設定やサブスクリプションを、Shadowrocketで見分けて読み込みたい方向けの記事です。単体リンクの接続情報とサブスクリプションURLを区別し、エンコード、認証、通信方式の各項目を確認したうえで、読み込み・更新・接続それぞれの失敗を切り分けます。本文のドメイン、パスワード、UUID、tokenはすべて説明用の架空の値であり、実際の接続には使えません。
1. まず違いを確認：共有リンクは接続情報、サブスクリプションURLは更新先
Shadowrocketは、共有リンクの情報を解析して接続項目として登録できます。ss://、vmess://、vless://、trojan://で始まるテキストには、通常、サーバーのプロトコル、アドレス、ポート、認証情報が記載されています。形式によってはTLS、通信方式、備考も含まれます。ブラウザーで開く一般的なWebページのURLではありません。
サブスクリプションURLは通常、HTTPSアドレスです。クライアントがそのアドレスにリクエストを送り、応答に含まれる対応済みの接続項目を該当するサブスクリプションに追加します。接続情報をすべてURL内に記述するのではなく、リストを繰り返し取得するための入口です。https://で始まるだけでは、サブスクリプションとは限りません。ログインページ、エラーページ、通常の案内ページの場合もあります。
| 確認項目 | 単体の共有リンク | サブスクリプションURL |
|---|---|---|
| 主な内容 | 1件分の接続情報 | 接続リストを取得するリモートアドレス |
| 読み込み方法 | 主にテキストを端末内で解析 | アドレスにリクエストを送り、応答を解析 |
| その後の変更 | 元の共有テキストは自動では変わらない | 更新時にリモートリストの変更を取得できる |
| 機密情報 | パスワード、UUID、サーバー情報 | URL内のtokenと取得した設定 |
単体の共有リンクは、完全な.conf設定ファイルとは異なります。サーバーを1件読み込んでも、Config内の[Rule]や[Host]などが同時に置き換わるわけではありません。サーバー設定は接続先を決め、ルールはリクエストごとの処理方針を決めます。それぞれ分けて確認してください。
2. ss://：Shadowsocksの認証情報のエンコードを確認
ss://は、Shadowsocksの共有リンクでよく使われるプレフィックスです。一般的なSIP002形式では、暗号化方式とパスワードをmethod:passwordの形にしてBase64URLでエンコードし、@の前に配置します。サーバーアドレスとポートはそのまま読めます。以下の認証部分をデコードするとaes-128-gcm:passwordになります。パスワードは説明用です。
ss://[email protected]:8388#Demo-SSss://：Shadowsocksの共有リンク形式として解析することを示します。YWVzLTEyOC1nY206cGFzc3dvcmQ：エンコードされた暗号化方式とパスワードです。例では末尾のBase64パディングを省略しています。example.com:8388：サーバーアドレスとポートです。読み込み時に、慣例的な別の番号へ変更しないでください。#Demo-SS：備考部分です。接続パスワードではなく、サーバーの地域が変わることもありません。
古い形式の共有リンクには、サーバーアドレスを含む長い文字列全体をBase64エンコードしたものもあります。そのため、@の有無だけで形式を判断することはできません。プラグインのパラメーターを含むリンクには、クエリ文字列が付く場合もあります。元の設定でプラグインや追加の通信パラメーターが必要な場合、リンクを短くするために削除しないでください。
3. vmess://：JSONに戻して各項目を確認
一般的なvmess://共有形式では、JSONテキストをBase64エンコードしてプレフィックスの後ろに付けます。デコード結果は、WebページのHTMLではなく、構造が整った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 | サーバーアドレスとポート | HTTP HostやSNIと混同しない |
id / aid | UUIDとalterId | 認証パラメーターが既存のサーバー設定と一致していること |
net / path | WebSocket通信とリクエストパス | /demoの大文字・小文字とスラッシュも設定の一部です |
host / sni | HTTP HostとTLS Server Name | 同じ値の場合もありますが、役割は異なります |
ps / v | 備考と共有形式の識別情報 | vはShadowrocketのバージョン番号ではありません |
VMessの共有情報は、生成元によって項目が異なる場合があります。特定の項目の有無だけで、サービスが必ず使えるとは判断できません。読み込み後にその項目の編集画面を開き、認証、通信方式、TLSの設定が正しく認識されているか確認してください。名前が表示されても、クライアントが一部の情報を読み取れたことしか示さず、サーバーがその設定を受け入れるとは限りません。
4. vless://とtrojan://：URIの項目が読めても通信内容が平文とは限らない
この2種類のリンクでは、内容を読み取りやすいURI形式がよく使われます。@の前に認証情報、後ろにサーバーがあり、クエリパラメーターで通信方式やセキュリティ設定を指定します。リンクの項目が読みやすいかどうかと、実際の接続でTLSを使うかどうかは別の問題です。以下の例はどちらも架空の認証情報と予約済みの例示用ドメインを使っています。
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&type=tcp&sni=example.com#Demo-Trojan- VLESSの例ではUUIDで認証します。
encryption=noneはプロトコルの項目を示すもので、クエリパラメーターで指定されたTLSを無効にする意味ではありません。 - Trojanの例では、
demo-passwordがパスワード、sni=example.comがTLS Server Nameの指定です。 type=wsとtype=tcpは異なる通信方式を表します。プレフィックスだけを書き換えて相互に変換することはできません。path=%2Fdemoは/demoに戻ります。パーセントエンコードはURI内の特殊文字を表す方法であり、パスワードを安全に暗号化するものではありません。
パスワードに@、#、?などの区切り文字が含まれる場合、リンク生成側で正しくパーセントエンコードする必要があります。手作業で組み立ててエンコードを忘れると、クライアントがパスワードの一部をサーバー、クエリパラメーター、備考として認識することがあります。また、エンコード済みの%2Fを%252Fに二重エンコードすると、パスが元の値と異なる場合があります。
確認方法：プレフィックスで互換性を推測せず、読み込み後に項目を照合
まずサーバー、ポート、認証を確認し、次に通信方式とTLSを確認します。追加のセキュリティパラメーターや特定の通信方式が含まれるリンクは、クライアントの実際の解析結果とサーバー側の要件を基準にしてください。不明な項目を削除したり、証明書の検証を無効にしたりしてリンクを「修復」しようとしないでください。
5. サブスクリプションの読み込みと更新：取得元を保ち、ローカル編集をリモート設定と混同しない
以下は、明らかに架空のサブスクリプションURLです。アドレスの形式を示すための例で、パスはサブスクリプションのエンドポイントを指定し、クエリパラメーターのtokenはアクセス権の確認に使われることがあります。実際のサブスクリプションのパス、パラメーター名、応答形式は、利用中のサービス提供元によって異なります。
https://example.com/sub?token=xxxxサブスクリプションの応答は、対応する共有リンクのテキスト一覧の場合もあれば、そのテキストをBase64エンコードした形式の場合もあります。正常なステータスが返っても、内容がログインページなら有効な接続リストとして読み込めません。QRコードも文字列を別の形で記録したものです。読み取った内容が単体の共有リンクかサブスクリプションURLかは、実際に格納されたデータで判断します。
- 手元にあるサブスクリプションURLを省略せずにコピーし、チャットの文章に含まれる句点、引用符、改行が混ざらないようにしてください。元のtokenをそのまま保ち、勝手に補ったり変更したりしないでください。
- Homeで右上の
+をタップして項目の追加画面を開き、Type → Subscribeを選択します。URLにアドレスを入力し、Remarksに取得元を記入して保存してください。 - 初回の取得後、Homeに戻り、該当するサブスクリプションとその項目を確認します。項目の編集画面を開き、種類、アドレス、ポート、認証情報が空欄でないことを確認してください。
- 更新する場合は、Homeで該当するサブスクリプションの更新操作を実行します。更新後は、まず項目リストに変化があるか確認し、その後に接続をテストしてください。「更新成功」は、リスト内のすべてのサーバーが利用できるという意味ではありません。
管理方法：リモートサブスクリプションとローカルのテスト用コピーを分ける
リモートサブスクリプションを維持する
- 元のURLと取得元のメモを保存する。
- 更新操作でリストの追加・削除や設定変更を反映する。
- 更新前に、残しておきたい独自の変更を記録する。
テスト用項目を別に管理する
- 変更を試す場合は、内容が分かる備考を付けた項目を別に作成する。
- 比較しやすいよう、一度に変更するパラメーターは1つにする。
- テスト後、Homeで現在選択されている項目を確認する。
サブスクリプションの更新で取得元の項目が上書きまたは再作成される場合があります。一時的な編集内容が長期間保持されることを前提にしないでください。
6. 読み込み後：Global Routingで接続とルールの問題を切り分ける
Homeでは接続項目と現在の選択を管理し、Configでは設定ファイルを扱い、Settingsではクライアントの設定を変更します。単体リンクを読み込んだ後もWebページにアクセスできないからといって、すぐにリンク形式の誤りとは判断できません。リクエストが読み込んだばかりの項目を使っていない場合や、現在のルールで別のポリシーに振り分けられている場合もあります。まずHomeで現在の選択を記録し、Global Routingを確認してください。
Config
ルール現在の設定にあるルールに基づいてポリシーを決定します。既存のルール設定を日常的に使う場合は、Homeで選択中の項目だけでなく、適用されたルールと、そのルールが参照するポリシーも確認してください。
適しているケース：ルール設定が用意されており、ルールに基づいてリクエストを処理したい場合。
Proxy
クライアントが処理するリクエストをプロキシ経由で処理し、現在の接続を一時的に比較する際に使えます。端末上のすべての通信が無条件に対象になるわけではありません。テスト後は元の状態に戻してください。
適しているケース：ルールによる振り分けがテスト結果に影響しているか、短時間で切り分けたい場合。
Direct
直接接続で処理するため、読み込んだばかりのプロキシサーバーを検証する用途には適しません。この状態でWebページを開けても、共有リンクの認証情報が正しいとは限りません。
適しているケース：現在のネットワークで直接接続した場合の状態を比較したい場合。
Global Routingには、シーンを切り替えるSceneもあります。動作を確認する際は、既存のシーン設定もあわせて確認してください。Sceneは新しいプロトコルではなく、サーバー認証の代わりにもなりません。自動接続の条件を設定している場合は、Settings → On Demandも確認し、自動再接続を読み込みが保存されなかった現象と取り違えないようにしてください。
- まず「解析」を確認：項目の編集画面で正しいサーバー、ポート、プロトコルが読み取れているか。
- 次に「接続」を確認：ネットワークが利用できる状態で、現在選択中の項目を使って対象へのリクエストをテストする。
- 最後に「ルーティング」を確認：Configを元に戻し、リクエストに実際に適用されたルールとポリシーを確認する。
7. よくある質問：失敗した段階を確認し、リンクを何度も書き換えない
ss://をコピーしたのに、読み込めないのはなぜですか？
まずテキストがss://で始まっているか、チャットアプリによって改行、空白、省略記号が挿入されていないかを確認し、エンコードされた内容が欠けていないか照合してください。画面に表示された短縮プレビューだけをコピーしないようにしましょう。読み込み後に項目が存在するのに接続できない場合は、認証とネットワークを確認します。Base64のデコード方法を何度も変えて試す必要はありません。
ブラウザーではサブスクリプションURLを開けるのに、リストが空なのはなぜですか？
開けることから分かるのは、何らかの応答を取得できたということだけです。利用中のサービス提供元が案内したサブスクリプションURLか、アカウント管理ページではないかを確認してください。tokenが完全か、認証を再取得する必要があるかも確認します。ログインページやエラーメッセージが返る場合は、まずURLとアクセス権の問題を解決してください。ページの内容を共有リンクのプレフィックスに書き換えて、無理に読み込ませることはできません。
サブスクリプションの更新がタイムアウトしました。項目をすべて追加し直す必要はありますか？
まず現在の設定を残し、今のネットワークからサブスクリプションURLにアクセスできるか確認してください。そのURLへのアクセスに、すでに利用できる接続が必要な場合は、Settings → SubscribeでUpdate via Proxyを確認してから、Homeに戻って更新を再試行します。認証エラーやtokenの失効はネットワークタイムアウトとは異なります。アクセス経路を切り替えても、有効な認証を再取得する代わりにはなりません。
vmess://をvless://に書き換えれば、プロトコルを変換できますか？
できません。VMessの一般的な共有情報はJSONをエンコードした形式ですが、VLESSの共有リンクはUUID、サーバー、クエリパラメーターを直接含む形式が一般的です。認証方法とプロトコルの動作も異なります。利用中のサービス提供元から該当プロトコルの完全な設定を入手し、Homeで新しい項目を追加して各パラメーターを確認してください。先頭の数文字を書き換えるだけでは変換できません。
リンクのスクリーンショットを人に送って調べてもらう場合、パスワードを隠せば十分ですか？
十分ではありません。UUID、サブスクリプションtoken、QRコード、エンコード済みの認証情報もアクセスに使われる可能性があります。問い合わせる際は、完全なリンクを削除し、プロトコル、ポート、通信方式、どの段階でエラーになったかを文章で伝えてください。実際の認証情報が漏えいした場合は、元のサービスの管理画面などから該当情報を変更または取り消し、クライアントに保存した内容も更新してください。
確認する順番を決めておきましょう。元のテキストが完全か、形式が正しく解析されたか、リモートへのリクエストが成功したか、認証が一致しているか、ルールが想定どおりのポリシーを適用しているかを順に確認します。一度に変更する条件は1つにし、変更前後の状況を記録すると、サブスクリプションの再作成、プロトコルの切り替え、ルールの変更を同時に行うより原因を特定しやすくなります。