V2Rayのプロトコルとコアの選び方

01 / プロトコル・伝送方式・セキュリティ

ひとつの設定名に、3つの階層が含まれることがある

クライアント一覧の「VLESS + TCP + REALITY」は、互いに置き換えられる3つのプロトコルではありません。VLESSはプロキシ要求の認証情報と接続先を扱い、TCPは基盤となる接続と伝送設定の一部、REALITYはセキュアなハンドシェイクを担います。同様に、VMessは複数の伝送方式と組み合わせられ、Trojanは通常TLSを利用します。各階層を分けて考えれば、サーバーから渡された項目をどこに入力するかがわかり、「VLESS対応」を「すべてのVLESS構成に対応」と誤解せずに済みます。

プロキシプロトコルは、クライアントがサーバーにどのような認証情報を提示し、どの接続先への要求をどのように包んで送るかを定めます。伝送設定は、データをどの接続方式で届けるかを決めます。たとえばTCPを直接使う方法や、WebSocket、gRPCなどを介する方法があります。セキュリティ設定は、接続先の認証、鍵のネゴシエーション、通信内容の保護を担います。これらには相互関係がありますが、どの組み合わせでも有効とは限りません。最終的な構成は、コアの実装やクライアントの画面で設定できる範囲にも左右されます。

アドレス、ポート、ホスト名を個別に確認する

「アドレス」には通常、接続先サーバーのドメイン名またはIPアドレスを指定し、「ポート」は接続するサービスを決めます。TLSのサーバー名は認証とハンドシェイクに使われ、WebSocketのHostやパスは伝送方式ごとのリクエスト処理に使われます。これらが接続先アドレスと同じとは限りません。設定の配布元が項目を分けている場合は、指定どおりに入力してください。すべてのドメイン名を接続先アドレスに統一すると、ネットワーク接続はできても、証明書の検証や伝送リクエストで失敗することがあります。

ローカルの待ち受けポートは、リモート側のポートとは別のものです。v2rayNでよく使われるローカルSOCKSポートには、ブラウザーなどのアプリが接続します。リモートサーバーの接続口ではありません。ローカルポートを変更してもサーバー側のプロトコルは変わらず、リモートポートを変更してもPC上のポート競合は解消しません。ログを読む際は、エラーがローカルの受け入れ、リモートへの接続、接続先へのアクセスのどの段階で起きたかを確認しましょう。それぞれ必要な設定が異なるため、手当たり次第に複数箇所を変更するのは避けてください。

ルーティングとDNSはプロトコルの優劣とは別

ルーティングは、リクエストを直接接続、プロキシ、遮断のどれに振り分けるかを決めます。DNSはドメイン名を接続に使えるアドレスに変換し、ルーティングの判定に使われることもあります。同じプロトコルでも、ルーティング設定が異なればアクセス結果は大きく変わります。サイトに直接接続できるのにプロキシ経由では失敗しても、プロトコルが原因とは限りません。名前解決の結果、接続先のアドレス種別、ルールの優先順位が異なる可能性もあります。まずリクエストがどの経路に振り分けられたかを確認してから、プロトコルを変更する意味があるか検討しましょう。

画面にあるドメイン名の解決方式、トラフィックの識別、接続の多重化も、それぞれ別の機能です。ドメイン名の解決方式は、名前解決のタイミングやアドレスとの照合方法に影響します。トラフィックの識別は、リクエストから接続先の情報を特定します。多重化は、複数のリクエストで接続を共有する方法を変えます。特定の用途で改善につながることもありますが、検証項目が増える原因にもなります。まずはクライアントの標準設定を使い、サーバーで必須の項目だけを設定してください。接続が安定してから、高度な設定をひとつずつ確認しましょう。

02 / VMessとVLESSの設計上の違い

VMess：認証とプロトコル内の保護

VMessはProject Vのエコシステムとともに発展し、既存の設定で広く使われているプロキシプロトコルです。認証とデータ保護の仕組みをプロトコル設計に含み、クライアントでは通常、ユーザーIDと対応するセキュリティ設定が必要です。現在は、メンテナンスされているコアが提供する有効な設定を使いましょう。古い解説にある項目を、そのまま現在の画面に当てはめることはできません。古いリンクをインポートできても、パーサーがリンク形式を認識しただけで、認証方式が現在のサーバーに適しているとは限りません。

VMessを理解するには、プロトコル内部のデータ保護と外側のTLSを区別する必要があります。内部に保護の仕組みがあっても、構成に応じて外側にTLSを使うことはできます。ただし、保護層を追加すれば必ず速く、安定するというわけではありません。各層でネゴシエーションや処理が必要になります。サーバーが求める組み合わせをクライアントでも使ってください。必要なセキュリティ層を無効にしたり、サーバーに設定されていない伝送方式を独自に追加したりしないようにしましょう。

VMessの認証では時刻が関係するため、端末の時刻が大きくずれている場合は優先して確認してください。まず自動時刻同期を有効にしてから接続し直し、いきなりユーザーIDを変更するのは避けましょう。セキュリティ設定には、クライアントとサーバーの両方が現在対応している値を使ってください。名称だけで互換性を判断するのは禁物です。古い設定に追加の識別子などが含まれる場合は、現在のパラメーターを提供元に確認し、値を試行錯誤して設定の不一致を取り繕わないようにしましょう。

VLESS：プロトコルを簡素化し、安全性は組み合わせで確保

VLESSはプロキシプロトコル自体の役割を絞り、必要な認証情報とリクエスト情報を扱いながら、通信の安全性を外部の仕組みに委ねる設計です。VMessと同じプロトコル内暗号化の仕組みは持たないため、「VLESSは軽量」を「どんな場合もセキュリティ設定は不要」と解釈してはいけません。一般的にはTLSやREALITYなどと組み合わせて使います。安全性をどこまで確保できるかは、プロトコル名ではなく設定全体で決まります。

VLESSの画面にあるユーザーID、暗号化の項目、フロー制御、セキュリティの種類は、それぞれ異なる役割を持ちます。設定によっては暗号化の項目がnoneと表示されますが、これは該当するプロトコル項目の値であり、接続全体が保護されないという意味ではありません。外側のセキュリティ設定も確認してください。フロー制御も、速度を自由に上げるスイッチではありません。サーバー、コア、現在の伝送方式のすべてが対応している場合に限って指定します。明確な値が提示されていない場合は、独自に追加しないでください。

REALITYとVisionは同じ設定説明に登場することがありますが、同義ではありません。REALITYはセキュリティ機構で、Visionは関連する実装で使われるフロー制御方式です。役割が異なります。VLESS対応の実装がREALITYに対応するとは限らず、特定のフロー制御との組み合わせに対応するとも限りません。画面に該当項目がない場合は、実行中のコアとクライアントの機能を確認してください。フロー制御の文字列をメモ欄やパスなど、無関係な入力欄に入れてはいけません。

どちらを選ぶか

既存のサービスを使う場合は、まずサーバーが実際に提供していて、現在もサポートされている構成を選びます。必要な項目がそろい安定して動作するVMess設定なら、VLESSのほうが新しいという理由だけで置き換える必要はありません。サーバーがVLESSとセキュリティ設定の組み合わせを提供しているなら、古い解説に合わせてVMessにする必要もありません。移行時はサーバー側の接続口、クライアントの設定項目、対応コアをまとめて準備します。元の設定も比較用に残し、接続先サイト、長時間接続、UDPの要件を個別に確認してください。

新しい構成を比較する場合は、同じネットワーク、同じ接続先、できるだけ近い伝送条件で試してください。VMessとVLESSで別々のサーバーや伝送方式を使うと、測定結果は主にサーバーの設置条件を反映し、プロトコルの違いとは言い切れません。実際の選定では、パラメーターを正確に配布できるか、クライアントにすべての項目を取り込めるか、問題をすぐ再現できるかを重視しましょう。理論上のわずかな処理負荷の差より、わかりやすく保守しやすい設定のほうが重要です。

03 / Trojan、Shadowsocks、REALITY

Trojan：TLSを使ったプロキシ接続

TrojanはTLSを使ったプロキシ接続方式で、一般的な設定ではパスワードでプロキシの認証を行い、TLSでサーバーの認証と通信の保護をします。ここには役割の異なる2つの仕組みがあります。パスワードはプロキシサービスがリクエストを受け入れるかを決め、証明書とサーバー名は接続先をクライアントが確認するために使います。パスワードが正しくても、証明書名が一致しなければ問題は解決しません。証明書の検証に成功しても、プロキシ認証に成功したとは限りません。ログを見て、どちらの段階で失敗したかを切り分けましょう。

Trojanの設定で一般的に必要なのは、サーバーアドレス、ポート、パスワード、TLSのサーバー名です。その他の項目は伝送方式や実装によって異なります。証明書の検証に失敗した場合は、サーバー名、端末の時刻、証明書チェーン、サーバー側の設定を先に確認してください。検証を無効にしたまま使い続けるのは避けましょう。検証をスキップすると接続先の認証範囲が変わり、通常の互換性調整とは異なります。一時的に接続できても、元の設定が修正されたことにはなりません。

Shadowsocks：方式名が互換性を左右する

Shadowsocksは比較的シンプルな暗号化プロキシとして開発され、一般にSSと略されます。暗号化方式やパスワードなどを指定して接続します。VMessの伝送モードではないため、インポート時は対応するプロトコルを選んでください。方式によって必要な鍵や対応状況が異なり、SSと書かれた設定がすべて互換というわけではありません。特に新しい方式は、クライアント画面に選択肢があるだけでなく、実行中のコアが実装しているかも確認が必要です。

AEAD方式では、クライアントとサーバーの方式名とパスワードを一致させてください。特定の新しい方式では、鍵の形式にも条件がある場合があります。古い解説にある非推奨の方式を、新規設定の標準として使うのは避けましょう。共有リンクにプラグインのパラメーターが含まれる場合は、現在のクライアントとコアが対応しているか別途確認します。アドレスとパスワードをインポートできても、追加条件を無視してはいけません。伝送用コンポーネントがなければ、プロトコルの項目が正しくても接続できません。

REALITY：独立したプロキシプロトコルではなく、セキュリティ機構

REALITYはXrayエコシステムのセキュリティ機構で、VLESSとの組み合わせが一般的です。VMessやTrojanのように単独で完全なプロキシプロトコルとして機能するものではありません。そのため、クライアントにREALITYのセキュリティ設定があっても、上位のプロトコルや接続先アドレス、認証情報が必要です。選定表にREALITYを載せているのは、よく使われる組み合わせの違いを比較するためであり、すべての名称が同じ階層に属するという意味ではありません。サーバー設定を読むときも、こうした階層の違いを保ってください。

REALITYでよく使われるクライアント側の項目には、サーバーの公開鍵、サーバー名、Short ID、クライアントフィンガープリントなどがあります。項目名や表示方法は実装によって異なる場合があります。公開鍵はサーバー側の鍵設定に対応する値を使い、独自の値を生成して置き換えてはいけません。Short IDもサーバーが受け付ける値の中から選ぶ必要があります。フィンガープリントは関連するハンドシェイクの動作に関わる設定で、変更すれば性能が向上するというものではありません。個々の項目が正しく見えても、設定全体が一致しているとは限りません。

略称ではなく、構成全体で比較する

Trojan、SS、REALITYと組み合わせたVLESSの接続負荷は、項目数だけでは判断できません。TLSセッションの再開、サーバーの実装、プロセッサーのアクセラレーション、ネットワークの往復時間、実際の通信内容が結果に影響します。項目が少なければ手動で確認しやすくなりますが、すべての用途に適しているとは限りません。UDPが必要なアプリでは、クライアントの受け入れ、プロトコルの接続先、サーバー側の転送経路がすべて必要な通信に対応しているか確認してください。説明に「UDP対応」と一言あるだけでは不十分です。

構成を選ぶ際は、まず既存サービスの対応範囲を確認し、次に設定配布で間違いが起きにくいかを考えます。複数の端末で同じ構成を使うなら、各端末が必要な項目をすべて設定できるか確認してください。どれか1台でも項目を捨てないとインポートできないなら、本当の意味で互換性があるとは言えません。検証済みの基本設定を残し、同じアプリで新しい構成を試すと、認証、セキュリティ、アプリの接続経路のどこに問題があるかを見分けやすくなります。失敗をすべてプロトコルの不安定さに結びつけないようにしましょう。

04 / V2Fly、Xray、クライアントの関係

クライアントの画面と実行コアは別

Project Vはこのエコシステムを理解するうえでの背景であり、V2FlyとXrayはそれぞれ別のコアプロジェクトです。GUIクライアントはサブスクリプション管理、設定編集、システム連携、プロセスの起動を担当し、コアはプロトコル、伝送方式、ルーティング、接続処理を実行します。v2rayNの画面が表示されていても、製品名だけでは今回の接続に使われているコアはわかりません。機能の違いを調べるときは、クライアントの関連設定や起動ログで、実際に動いているコアを確認してください。

V2FlyはV2Ray関連の実装やエコシステムを引き継いで発展し、Xrayは関連コードを基盤に分岐して、独自の機能開発を進めています。共通する概念や設定方法もありますが、同じプログラムの別名ではありません。REALITYやVisionなどの機能を使う場合は、通常Xrayの対応状況を確認する必要があります。V2Fly独自の伝送方式や設定の変更も別途確認してください。機能を利用できるかどうかは、最終的に各コアの実装とクライアントの対応状況で決まります。

3つのクライアントの使い分け

PCではv2rayNを優先して使います。Windows、macOS、Linux向けのダウンロードはダウンロードページにまとめていますが、画面やシステム連携の機能はOSによって異なる場合があります。コア関連の設定を管理できますが、すべてのプロトコルで自由にコアを切り替えられるわけではありません。AndroidではXrayコアを使うv2rayNGと、V2Flyコアを採用するv2flyNGが選択肢です。クライアント名を速度のランクと見なすのではなく、サーバー設定に合うものを選んでください。

コアを変更する前に、現在使える設定を複製し、ルーティング、DNS、待ち受けポート、起動オプションを記録してください。そのうえでコアまたは関連する設定だけを切り替え、ログで正常に起動することを確認してから接続を試します。別のコアが高度な項目を拒否した場合は、エラー行を削除して起動させるのではなく、そのコアでの設定方法を調べてください。削除した項目が重要なルーティングやセキュリティを担っていることがあります。起動できても設定の意味が保たれているとは限りません。

JSONの構造が似ていても、そのまま置き換えられるとは限らない

どちらの設定にも受け入れ、接続先、ルーティング、DNSの項目があるとしても、構成が似ているとわかるだけです。項目の値、伝送方式の名称、既定の動作、拡張機能は異なる場合があります。GUIクライアントは実行用の設定を生成する際に、ローカルの待ち受け、タグ、OS固有の項目を追加することもあるため、手動で保存した断片と実際の設定が一致するとは限りません。トラブルシューティングでは、クライアントの設定表示やログ機能を使い、コアに渡された内容を確認してください。

以下は、対応するコアでルーティング設定に使うルールオブジェクトの例です。プライベートアドレスに一致した通信を、directというタグの接続先へ振り分けます。実行設定全体ではありません。このルールを機能させるには、対応する接続先のタグとルールデータがすでに必要です。項目の関係を理解するための例であり、クライアントが生成した設定全体をそのまま上書きしないでください。GUIを使う場合は、ルーティング編集画面で同等のルールを設定し、生成結果を確認する方法が安全です。

{
  "type": "field",
  "ip": ["geoip:private"],
  "outboundTag": "direct"
}

ルールファイルも互換性に関わります。設定にgeosite:やgeoip:というプレフィックスがあっても、参照先のデータが存在するとは限らず、データ内に指定したタグが含まれていないこともあります。コアの変更、ディレクトリの移行、バックアップの復元後は、クライアントが参照しているデータの保存先と更新結果を確認してください。詳しくはGeoIP・GeoSiteルールファイルの更新方法を参照してください。ルールの読み込み失敗をプロキシ認証の失敗と混同しないようにしましょう。

05 / 接続速度とリソース使用量の比較方法

速度を測定可能な段階に分ける

「接続が速い」には、クライアントの起動、初回のハンドシェイク、Webページの最初の応答、継続的なダウンロード速度などが含まれますが、それぞれ別の指標です。コアの起動時間は設定の規模、ルールの読み込み、端末の性能に左右されます。初回接続は名前解決、ネットワークの往復時間、セキュリティハンドシェイクの影響を受けます。継続的な通信には、帯域幅、輻輳、接続先のサービス、サーバーの負荷も関係します。どの段階を測定するのか明確にしてから比較すれば、結果を適切に解釈できます。

セキュリティハンドシェイクによって初回接続時の処理が増えることはありますが、「TLSを使うと必ず遅い」とは言えません。セッション再開、接続の多重化、アプリの長時間接続によって、繰り返し発生する負荷が減ることがあります。一方、クライアントの接続テストが速くても、複数のドメインやアドレスへの名前解決、複数の接続を必要とする複雑なWebページが速いとは限りません。テストボタンの結果は、接続全体ではなく一部の目安として捉えてください。

CPU使用率は通信量とアイドル時の状態を合わせて見る

暗号化方式、CPUの命令セット対応、メモリコピー、カプセル化の層数は、CPU負荷に影響します。同じプロトコルでも端末によって相対的な結果が異なるため、あらゆる端末に当てはまるリソース使用率の順位は付けられません。負荷を確認するときは、アイドル時と継続的な通信時を分け、できるだけ同程度の通信速度で比べてください。通信量が多い構成のCPU使用率が高くても、効率が悪いとは限りません。アイドル時に異常な高負荷が続く場合は、詳しく調べる必要があります。

メモリ使用量は、接続数、ルーティングデータ、DNSキャッシュ、ログのバッファーにも左右されます。起動直後としばらく実行した後の数値は、そのまま比較できません。OSのタスク管理ツールによっても集計方法が異なる場合があります。メモリが増え続けるときは、接続数が蓄積していないか、アプリが再接続を繰り返していないか、ログの詳細度が高すぎないかを確認してください。1回のスクリーンショットだけで、特定のコアのほうが省メモリだと断定するのは困難です。

一度の速度測定ではなく、条件をそろえて比較する

条件をそろえて比較するには、同じ端末、同じ接続ネットワーク、同じ接続先、できるだけ近い時間帯を使います。構成全体を記録し、地域の異なるサーバーを同じプロトコルのランキングに混ぜないでください。まず固定したページを開く、同じファイルを同期する、同じ用途の接続を維持するといった実際の操作を比べ、その後でクライアントの接続テストも行います。順番を入れ替えながら複数回試すと、キャッシュ、バックグラウンド更新、一時的なネットワーク変化による偏りを抑えられます。

多重化は独立した条件として検証してください。用途によっては接続確立の負荷が減る一方、通信間の影響が変わることがあります。伝送方式やフロー制御との組み合わせに固有の制約がある場合もあります。多重化、フィンガープリント、DNS、ドメイン名の解決方式を同時に変更し、結果をどれかひとつの設定の効果と見なさないでください。変更のたびに記録を残し、効果が初回アクセスと長時間接続のどちらに現れたかを書けば、その設定を継続して使う価値を判断できます。

PCでは、システムプロキシとTUNの接続方式の違いにも注意が必要です。接続方式が異なる2回のテストでは、コアを経由する通信の範囲、DNSの動作、バックグラウンド負荷も変わる可能性があります。性能についての結論は、特定の端末、接続方式、サーバー設定を組み合わせた条件に限定してください。特定のプロトコルが常に優れていると一般化することはできません。まず正しい動作と長期的な安定性を確保し、使い勝手に影響する箇所だけを小規模に調整しましょう。

06 / Androidの電池消費とバックグラウンド接続

電池消費はプロトコルだけでは決まらない

Android端末では、v2rayNGやv2flyNGがシステムのVPNインターフェース経由で通信を受け取ることがよくあります。このインターフェースを経由する処理の一部が、システムの電池使用量でクライアントに計上される場合があります。そのため、クライアントの消費割合が高くても、コアが何もせず動いているとは限りません。画面の使用時間、実際の通信、バックグラウンドアプリ、待機時間も合わせて確認してください。大容量ファイルの同期、動画再生、長時間のアイドル状態は負荷が異なるため、電池画面の割合だけで比較することはできません。

モバイル通信では、無線モジュールが複数の動作状態を切り替えます。小さなリクエストの頻発、接続の再試行、過剰なキープアライブは、端末が低電力状態に移行しにくくなる原因です。プロトコルの暗号化に必要なCPU処理は、消費電力の一部にすぎません。電波が弱かったり、接続が頻繁に途切れたりする場合は、再接続の負荷がさらに大きくなることもあります。プロトコルの影響を調べる前に、ネットワークが安定しているか、アプリがバックグラウンドでリクエストを続けていないか確認してください。

キープアライブとバックグラウンド制限のバランス

キープアライブは、必要な接続を維持したり、切断をすばやく検出したりするために使われますが、タイムアウトの挙動はネットワークによって異なります。すべての間隔を短くすると端末の復帰が増える可能性があり、完全に無効にすると長時間接続が切れやすくなる場合があります。明確な問題がなければ、クライアントとサーバー設定の適切な初期値を使ってください。変更が必要な場合は関連項目をひとつずつ調整し、待機中、画面ロック解除後、ネットワーク切り替え後の接続回復を確認します。画面表示中のアクセスだけで判断しないようにしましょう。

システムの電池最適化やメーカー独自のバックグラウンド管理によって、クライアントのプロセスが終了することがあります。その場合、画面ロック後に切断される、ロック解除後に再接続する、サービスの状態と通知が一致しないといった症状が現れます。クライアントにバックグラウンド実行が許可されているか、システムの関連通知に対応済みか確認してください。バックグラウンド権限を許可しても、すべてのアプリを常時オンラインにする必要はありません。必要に応じてアプリごとのプロキシを設定できますが、対象アプリを除外すると通信経路が変わることを理解しておきましょう。クライアントの処理負荷だけが下がるわけではありません。

アイドル時、使用中、ネットワーク切り替え時を分けて観察

まず、動作確認済みの設定を使い、画面消灯中の待機、特定アプリの利用中、Wi-Fiとモバイルネットワークを切り替えた後の復旧をそれぞれ観察してください。各段階の時間と使い方をできるだけそろえ、再接続の通知やエラーログの有無を記録します。テスト中はアップデートのインストール、写真の同期、連続した速度測定を避けてください。こうした追加負荷があると電池消費を比較できず、本来のバックグラウンド動作を見落とすおそれがあります。

画面表示中のアクセスは正常なのに、待機中の電池消費が明らかに多い場合は、認証や名前解決の失敗、接続先への到達不能、キープアライブの再試行が繰り返されていないか確認します。処理が失敗し続けると、端末は同じ動作を繰り返す可能性があります。プロトコルの項目を変更する前に、原因を取り除きましょう。ログは問題を再現できる範囲の短い時間だけ記録し、調査後は通常の詳細度に戻してください。詳細ログを継続すると処理や書き込みが増え、共有すべきでない接続情報が記録されることもあります。

特定のアプリを使うときだけ電池消費が多い場合は、そのアプリの通信量や接続動作を比較し、プロキシ経由になったことで再試行が増えていないか確認してください。アプリごとにプロキシを設定する際は、ブラウザーから外部アプリを開く動作、アカウントへのログイン、システムコンポーネントとの連携も考慮します。一部の通信だけプロキシ経由にすると、アプリの処理経路が一致しなくなる場合があります。アプリを除外した後にクライアントの電池使用割合が下がっても、省電力になったとは限りません。処理が別の項目に計上されただけの可能性があります。

v2rayNGとv2flyNGを比較する必要がある場合は、両方が完全に対応するサーバー構成を使い、複数のVPN接続サービスを同時に実行しないでください。一方でREALITYを使い、もう一方では別のサーバーを使うと、結果からコア単独の電力効率を比較できません。詳しい確認手順はv2rayNGの電池消費とバックグラウンド動作のトラブルシューティングを参照してください。モバイル端末では、使用量に関係なく電池使用割合を最小化することより、必要な通信を安定して行えることを目指しましょう。

07 / 共有リンク、サブスクリプション、設定の互換性

サブスクリプションは設定の配布方法であり、プロトコルではない

共有リンクは通常、ひとつの接続設定を表し、サブスクリプションは複数の設定をまとめて配布・更新するために使います。サブスクリプションのURLだけでプロキシプロトコルが決まるわけではなく、すべてのクライアントが内容を読み取れる保証もありません。内容はリンクの一覧、エンコードされた一覧、特定形式の設定ファイルなどさまざまです。外側の形式を解析できるのはインポートの第一段階にすぎません。各設定のプロトコル、セキュリティ、伝送方式も個別に確認してください。

VMessの共有リンクは、エンコードされた構造化データでパラメーターを表す形式が一般的です。VLESSやTrojanなどは、アドレスとクエリパラメーターの組み合わせで表現されることが多く、SSリンクには独自のユーザー情報のエンコード形式があります。拡張パラメーターへの対応はクライアントごとに異なり、同じ名前の項目でも別の形式への変換が必要な場合があります。手動でコピーする場合は、ドメイン名とポートだけでなくリンク全体を保持してください。QRコードに設定全体が含まれている場合も、読み取り結果が途中で切れていないか確認しましょう。

インポート後は、重要な設定項目を確認する

インポートが終わったら編集画面を開き、プロトコルの種類、アドレス、ポート、認証情報を確認します。続けてセキュリティの種類、サーバー名、伝送方式、パス、サービス名を確認してください。REALITYを使う場合は、公開鍵、Short ID、フィンガープリント、フロー制御が保持されているかも確認します。設定名が正しく表示されても、名前を認識できただけかもしれません。パラメーターがすべて読み込まれたかどうかとは関係ありません。別の端末から初めて設定を移行するときは、特に確認が重要です。

URL内の特殊文字はパーセントエンコードが必要な場合があります。パスワード、パス、ホスト名の記号が誤って区切られると、解析結果が変わります。エンコード文字を手当たり次第に置き換えてリンクを「修正」するのではなく、元の完全な内容をコピーし直すか、クライアントが対応するファイル形式でインポートしてください。チャットアプリで転送する際は、改行、自動で追加される句読点、リンクの切り詰めにも注意が必要です。手入力は、各パラメーターが明確で、ひとつずつ照合できる場合に限ってください。

形式変換で設定の意味が失われることがある

サブスクリプションの形式を変換する作業は、ファイルの拡張子を変えるだけではありません。変換先の形式が、特定のフロー制御、フィンガープリント、DNSの動作、ルーティングルールを表現できないことがあります。変換ツールが異なる初期値を使う場合もあります。その結果、設定が起動しても、元の通信経路やセキュリティ条件が保たれているとは限りません。変換が必要な場合は、まず対象のクライアントで使える機能を確認し、変換前後の重要な項目をひとつずつ比較してください。設定の件数が同じかどうかだけで判断しないようにしましょう。

実行用の設定全体と、単一の共有リンクも同じものではありません。実行用の設定には、ローカルの受け入れ、複数の接続先、ルーティング、DNSが含まれることがあります。一方、共有リンクは通常、ひとつのリモート接続だけを対象とします。設定全体を別の端末に移すと、適さない待ち受けアドレスやプラットフォーム固有の項目が含まれる可能性があります。単一の接続だけを共有すると、元の設定が依存していたルーティングルールが抜けることがあります。移行先に合わせてエクスポート方法を選び、新しい端末で再設定が必要な項目を明確にしてください。

サブスクリプション更新前に、配布元の設定とローカル編集を区別する

サブスクリプションの更新では、配布元の内容が基準になります。サブスクリプションの項目をローカルで編集しても、次回の更新で上書きされる場合があります。実際の動作はクライアントによって異なります。長期間保持する変更は、クライアントが対応する方法で独立した設定や別グループにコピーし、用途を記録してください。テスト用の項目を普段使うサブスクリプションに混在させると、更新後にどの項目がサーバー側と同期しているのかわかりにくくなります。変更前に復元可能なバックアップを残しておけば、記憶を頼りに項目を作り直さずに済みます。

サブスクリプションのURLやエクスポートした認証情報によって、サービスへのアクセスが可能になる場合があります。機密情報として扱ってください。トラブルシューティング用のスクリーンショットでは、サブスクリプションのURL全体、ユーザーID、パスワードなどを隠します。公開鍵は秘密鍵と同じではありませんが、ほかの設定情報と一緒に公開する必要はありません。更新に失敗したときは、URLへのアクセス、内容の解析、インポート後の接続のどの段階で失敗したかを切り分けましょう。基本操作の流れは、サブスクリプションのインポートと接続のガイドに沿って確認できます。

08 / 用途に応じた選び方と段階的なトラブルシューティング

まず対応範囲を確認し、その後に使い勝手を比べる

選択肢は、次の3点から絞り込めます。サーバーが提供する構成一式、使用する端末がその構成に対応しているか、実際の用途に必要な通信機能です。PCではv2rayNを優先し、実際に動作するコアを確認してください。AndroidでサーバーがXray固有の機能を必要とする場合は、そのパラメーターを設定できるv2rayNGを選びます。V2Fly関連の設定を使う場合は、v2flyNGの対応範囲を確認しましょう。クライアントは機能の対応状況で選ぶものであり、名称に順位を付けるものではありません。

Web閲覧やオフィス作業では、設定をわかりやすく配布でき、証明書や鍵を明確に管理でき、更新後に復元しやすい構成を優先してください。安定して動作している設定を比較用に残し、新しい構成は上書きせずに個別にテストします。複数の端末でサービスを共有する場合は、どの端末でも必要な項目をすべて設定できる構成を選んでください。一部の端末で重要な項目を省略しなければインポートできない場合は、不足を正常な互換性と見なさず、全端末で使える設定を選び直しましょう。

リアルタイム通信、ゲーム、その他のUDP通信では、アプリの通信がクライアントに届くか、ローカルの接続方式が必要なリクエストを扱えるか、プロトコルの接続先が対応しているか、サーバーが許可して正しく転送するかを、通信経路全体で確認します。ブラウザーでWebページを開けても、UDPが使えるとは限りません。TUNも、すべての通信を正常にする万能なスイッチではありません。通信を取り込む範囲を変える機能であり、ルーティング、名前解決、リモート側の機能に依存します。

接続できない場合は、通信経路に沿って原因を探す

最初にコアが起動できるか確認します。ログに不明な項目、不明なプロトコル、ルールの読み込み失敗が表示された場合は、設定の構文、実装の対応状況、ルールデータを先に確認し、リモート側のパスワードはまだ変更しないでください。次にリモートサーバーへ接続できるか確認します。アドレスを解決できない、タイムアウトする、接続を拒否されるといった症状は、それぞれ異なる原因を示します。最後にセキュリティハンドシェイクとプロキシ認証を確認します。サーバー名、端末の時刻、証明書、公開鍵、Short ID、認証情報を、ログに応じてひとつずつ確認してください。

4番目に、リクエストが想定した接続先へ振り分けられているかを確認します。クライアントが動作中でも、アプリがシステムプロキシを使っていなかったり、ルールによって直接接続に振り分けられたりすると、期待どおりに動かないことがあります。ローカルの待ち受けアドレスとポートを確認し、アプリ独自のプロキシ設定がないか調べたうえで、接続先ドメインに適用されたルールを確認してください。ドメイン名でのアクセスだけが失敗し、IPアドレスでのアクセス条件が異なる場合は、DNSとドメイン名の解決方式をさらに調べます。関係のない問題を解決するために証明書の検証を無効にしてはいけません。

問題に応じたガイドを参照

ローカルポートを起動できない場合は、ローカルポートの競合に関するトラブルシューティングで原因を特定し、変更後はそのポートに依存するアプリも更新してください。初回インストールや保存先の問題は、初回インストールのチェックリストを参照します。これらはローカルの実行環境の問題であり、通常はプロトコルを変えても解決しません。ドメイン名の解決や振り分けが原因なら、DNSの振り分けと名前解決ガイドを確認してください。同じ接続設定を何度も作り直すのは避けましょう。

問題を記録するときは、端末のOS、クライアント名、実際のコア、プロトコル構成、接続方式、個人情報を除いたエラーの概要を残し、画面ロック後だけ、特定のアプリだけ、特定の接続先だけなど発生条件も記載してください。変更する項目は毎回ひとつにし、元に戻せるかも記録します。このような記録があれば、一時的なネットワーク変化と再現性のある設定ミスを区別でき、すでに確認した箇所を何度も調べることも避けられます。不要な再インストールや移行も減らせます。