リンクを受け取ったら、まず単一の接続設定を保存するものか、設定一覧を取得するためのリモートURLかを確認しましょう。初めての設定インポート、端末の移行、サブスクリプション更新のトラブルに役立つよう、vmess://・vless://・HTTPSサブスクリプションの見分け方から、主要フィールドの確認、クライアントへのインポート、接続テストまで順に解説します。
共有リンクとサブスクリプションURL:設定を保存するか、一覧を取得するか
vmess:// と vless:// は、通常1件分の設定を共有する形式です。クライアントはリンクからサーバーアドレス、ポート、認証情報、通信方式などを読み取り、ローカル設定として保存します。共有リンクを2つコピーすれば2件まとめてインポートできますが、それだけでは更新可能なサブスクリプションにはなりません。
サブスクリプションURLは通常HTTPSのURLです。クライアントがアクセスし、サーバーから設定一覧を取得して解析・更新します。URLにアカウントのトークンが含まれる場合があります。パスにsubがあるか、特定の拡張子で終わるかは、判定の基準になりません。一般的なWebページや単一のJSONファイルのURLも、サブスクリプションとして使えるとは限りません。
サブスクリプションURL
おすすめ継続的に管理する設定一覧です。更新操作で一覧を再取得します。サーバー側でアドレスやポートが変更されたり、設定が追加・削除されたりした場合、変更を反映するにはクライアントで正常に更新する必要があります。
適した用途:提供元からサブスクリプションURLが案内されており、設定を継続的に同期したい場合。
単一の共有リンク
インポート時点の設定を保存します。リンクの内容が同じなら、再インポートしてもサーバー側で後から変更された設定は通常反映されません。
適した用途:一時的なテスト、個別設定の確認、少数の既知の設定の移行。
ここでのおすすめは、信頼できるサブスクリプションの提供元があることが前提です。サブスクリプションは接続プロトコルではなく、掲載されたすべての設定が使える保証もありません。VMessとVLESSは接続プロトコル、サブスクリプションは設定の配布・更新方法であり、役割が異なります。
vmess://:デコードしてアドレス・通信方式・TLSを確認
一般的なVMess共有形式は、vmess://の後ろにBase64でエンコードされたJSONが続きます。Base64は単なるエンコード方式で、UUIDなどの接続情報を隠すものではありません。ツールによって形式が異なるため、任意のBase64文字列をVMess設定とみなすことはできません。
以下は、一般的な共有リンクをデコードした構造の例です。ドメインとUUIDはフィールドの説明用で、実際に接続できるサービスを示すものではありません。これらの短いキーは共有形式のフィールドであり、そのまま貼り付けて使える完全なコア設定ではありません。
{
"v": "2",
"ps": "VMessのサンプル",
"add": "edge.example.org",
"port": "443",
"id": "123e4567-e89b-42d3-a456-426614174000",
"aid": "0",
"scy": "auto",
"net": "ws",
"type": "none",
"host": "edge.example.org",
"path": "/gateway",
"tls": "tls",
"sni": "edge.example.org"
}
addとport:接続先のサーバーアドレスとポートです。ポートはサーバー側の待ち受け設定と一致させます。例で443が使われていても、すべての設定を443に変更してはいけません。id:VMessユーザーのUUIDです。aidは旧形式との互換性のためのフィールドです。現在のVMess AEAD設定では通常0を使うため、理由なく別の値に変更しないでください。net、host、path:例ではWebSocketを使用しています。hostはリクエストのHost、pathはパスを表し、サーバーまたはリバースプロキシの設定と一致させる必要があります。tlsとsni:TLSとサーバー名を指定します。接続先アドレス、リクエストのHost、TLSのサーバー名は同じ場合もあれば、サーバー側の設計によって異なる場合もあります。ps:通常は表示用のメモです。メモを変更しても、アドレスやUUID、通信設定の誤りは解決しません。
デコードして各フィールドを理解できても、クライアントがすべての組み合わせに対応しているとは限りません。GUIクライアントは共有形式を解析して設定を生成し、コアが接続を実行します。トラブルの切り分けでは、インポート結果と現在のコアの対応状況を両方確認してください。
vless://:クエリパラメーターで通信方式とセキュリティ層を確認
VLESSの共有リンクは、一般にURI形式です。UUIDの後に@が続き、その後にサーバーアドレスとポート番号が並びます。クエリパラメーターは疑問符の後、備考はハッシュ記号の後に記述されます。以下はVLESS、WebSocket、TLSを組み合わせた構造例で、実際の接続には使用できません。
vless://[email protected]:443?encryption=none&security=tls&type=ws&host=edge.example.org&path=%2Fgateway&sni=edge.example.org#VLESS-WS-TLS
| フィールド | 値の例 | 確認ポイント |
|---|---|---|
encryption | none | TLSが無効という意味ではありません。外側のセキュリティ設定とは別のフィールドです。 |
security | tls | この例はTLSを使用しています。名前だけを変更しても、サーバーをREALITYに切り替えることはできません。 |
type | ws | 通信方式はサーバー側の設定と一致させる必要があります。 |
path | %2Fgateway | URIデコード後は/gatewayになります。二重にエンコードしないでください。 |
sni | edge.example.org | TLSハンドシェイクで使用するサーバー名です。サーバー側の指定に従って設定してください。 |
REALITY設定を使う場合は、提供元の情報をもとにpbk、sid、fpなどのパラメーターも確認してください。flow=xtls-rprx-visionを使うかどうかは、サーバー側の設定と通信方式の組み合わせによります。上記のWebSocket例にVisionフィールドを追加しただけで、プロトコルをアップグレードしたことにはなりません。
要点:インポート後に各項目を確認し、プロトコルは安易に変更しない
まずアドレス、ポート、UUID、通信方式、セキュリティ層の5項目を照合してください。提供元の設定がすべてそろっており、クライアントが該当する組み合わせに対応していることを確認してから接続テストに進みます。TLS、REALITY、通信方式をむやみに切り替えると、設定の不整合が生じます。
v2rayN・v2rayNG:リンクの種類に合わせてインポート
以下では、一般的な日本語メニュー名を使って説明します。バージョンによってボタンの位置や表記は異なる場合があります。「クリップボードからインポート」「サブスクリプショングループ設定」「サブスクリプションを更新」などの機能名を目印にしてください。インポート、設定の選択、接続の開始、プロキシの有効化はそれぞれ別の操作です。リストに設定が表示されただけで完了と判断しないでください。
両方のクライアントでインポート:単一リンクとリモートサブスクリプションを見分ける
デスクトップ版:v2rayN
- 単一リンク:内容をすべてコピーし、メイン画面で「サーバー」→「クリップボードからURLを一括インポート」を選択します。このショートカットに対応したバージョンでは、Ctrl+Vも使えます。
- サブスクリプションURL:「サブスクリプショングループ」→「サブスクリプショングループ設定」を開き、グループを追加してメモとURLを入力します。保存後、「サブスクリプションを更新」を実行してください。
- 更新後、使う設定を選択し、右クリックメニューから「アクティブサーバーに設定」を選びます。その後、必要に応じてシステムプロキシを設定してください。
Android版:v2rayNG
- 単一リンク:内容をすべてコピーし、右上の「+」→「クリップボードからインポート」をタップします。
- サブスクリプションURL:サイドメニューから「サブスクリプショングループ設定」を開き、「+」をタップしてメモとURLを追加します。保存したらメイン画面に戻り、「サブスクリプションを更新」を実行してください。
- 使う設定を選択して接続ボタンをタップします。初回接続時はシステムの案内に従ってVPN接続を許可し、接続状態とログを確認してください。
同じサブスクリプションを両方の端末に追加できますが、更新スケジュール、選択中の設定、ローカルのルーティング設定は自動で同期されません。
v2rayNGはXrayコア、v2flyNGはv2flyコアを使用します。画面が似ていたり、同じサブスクリプションを使ったりしても、対応するプロトコル拡張が同じとは限りません。特にVLESSの特定のセキュリティ設定とフロー制御を組み合わせる場合は、実際のコアの対応状況を確認してください。リンクを認識できるだけで利用可能とは判断できません。
- インポート前に、クリップボードに説明文や引用符が混ざっていないか、改行が挿入されていないか、リンク末尾に日本語の句読点が付いていないか確認してください。
- インポート後は編集画面を開き、メモの名前だけでなく、サーバー、ポート、通信方式、TLS設定を確認してください。
- サブスクリプションの更新後、対象グループに設定が表示されることを確認し、その中から1件を選んで使用してください。
- 起動後は実際にアプリから接続先へアクセスしてテストし、ログも確認して接続とルーティングの状態を判断してください。
サブスクリプションの更新とポートの確認:2つの通信経路を分けて考える
サブスクリプションの更新は「クライアントからサブスクリプションサーバーへアクセスする」経路を使います。通常の通信は「アプリからローカルプロキシへアクセスし、コアがリモートサーバーに接続する」経路を使います。一方が使えても、もう一方も使えるとは限りません。サブスクリプションの取得に成功したのは、今回の取得と解析が完了したという意味であり、一覧内のすべてのサーバーに接続できる保証ではありません。
これらの数値は確認箇所を説明するための例であり、すべての環境の初期値ではありません。リモートポートは設定の提供元に確認してください。ローカルポートは、v2rayNの「設定」→「パラメーター設定」に表示される待ち受け設定を基準にします。ローカルSOCKSインバウンドが実際に127.0.0.1:10808で待ち受けている場合は、ターミナルで次のようにプロキシを明示してコマンドを実行できます。
curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 --head https://example.com/
ここでのsocks5hは、接続先ドメインの名前解決をプロキシ側で行う指定です。10秒と20秒は、それぞれこのコマンドの接続タイムアウトと全体のタイムアウトです。失敗した場合はエラー内容を記録し、1回の所要時間だけで判断しないでください。ブラウザーがシステムプロキシを参照しているか、ターミナルでプロキシを明示しているかは、別々に確認する必要があります。
- ローカルポートに接続できない場合:コアが起動しているか、待ち受けポートが正しいか、ポートが競合していないかを確認してください。
- ローカルプロキシには接続できるが、リモート側のハンドシェイクに失敗する場合:アドレス、UUID、TLSサーバー名、通信パス、システム時刻を確認してください。
- サブスクリプションの更新だけがタイムアウトする場合:サブスクリプションのドメインにアクセスできるか確認してください。バージョンに「プロキシ経由で更新」オプションがある場合は、利用可能な接続がある状態で試してください。
- 更新後に設定が減った場合:選択したグループが正しいか、サブスクリプションの内容が変わっていないか、ログに形式の解析エラーがないか確認してください。
インポート・更新時によくある質問
HTTPSのURLをコピーしたのに、有効な設定がないと表示されるのはなぜ?
コピーしたものがアカウント管理ページではなく、サブスクリプションのURLか確認してください。URLを「サブスクリプショングループ設定」のURL欄に入力し、更新を実行します。リモートURLを単一のVMessまたはVLESSリンクとして扱わないでください。それでも失敗する場合は、ログにログインページ、アクセス拒否、未対応のコンテンツ形式などが表示されていないか確認します。調査中もトークンを公開しないでください。
単一リンクのインポートには成功したのに、サブスクリプションを更新しても変化がないのはなぜ?
単一リンクに保存されるのはローカルの設定スナップショットで、サブスクリプションの提供元は含まれません。実際のサブスクリプションURLを別途追加し、該当グループを更新してください。共有リンクをサブスクリプションURL欄に入力したり、メモを変更すれば新しいサーバー設定を取得できると期待したりしないでください。
サブスクリプションの更新後、手動で変更した設定が元に戻るのはなぜ?
サブスクリプションの更新時に、グループ内の設定が再生成または上書きされることがあります。動作はクライアントのバージョンや更新方法によって異なります。手動変更を長期的に保持する場合は、設定を独立したローカルグループに複製し、両方の設定の出所を確認してください。次回、誤った設定を選ばないよう注意が必要です。
共有リンクをオンラインのデコードサイトに貼り付けて確認してもよい?
リンクにはUUID、サブスクリプショントークン、サーバー情報が含まれることがあります。まずクライアントの編集画面で確認するか、信頼できるオフラインツールを使ってください。リンク全文、QRコード、情報を隠していないログを公開の掲示板に投稿しないでください。認証情報が漏えいした場合は、提供元の管理画面で再発行し、両方の端末の設定を更新してください。
端末を移行する前の最終チェック
共有リンクには通常接続設定が含まれ、サブスクリプションは通常設定一覧を管理します。システムプロキシ、アプリごとのルール、DNS、ルーティング、ローカルのインバウンドポート、ログレベルまで一緒に移行されるとは限りません。同じ提供元から2台の端末に設定をインポートして動作が異なる場合は、リモート側の問題と判断する前に、これらのローカル設定を比較してください。