V2Rayプロトコル
とコアの解説

VMessの認証とトランスポートの選択

VMessはProject Vのエコシステムで早くから使われているプロキシプロトコルです。ユーザー認証、リクエスト形式、データ保護に関する仕組みを備えています。長く使われてきたため、古いサブスクリプションや構築手順には今もVMessが使われています。VMessが現在も利用できることと、古い解説が今もそのまま通用することは別です。以前の設定にある認証方式や補助項目は、現在のコアに適さない場合があります。選ぶ際はサーバーの実装を確認し、解説の公開時期やノード名だけで互換性を判断しないでください。

ユーザーID、暗号化方式、時刻

「ユーザーID」には通常UUIDを入力します。これは認証に使う値で、自由に付けるメモ名ではありません。クライアントで新しいUUIDを生成しても、サーバーから自動的に許可されるわけではなく、サーバーのユーザー設定と一致させる必要があります。「暗号化方式」にもプロトコル上の意味があり、TLSのオン・オフと混同してはいけません。一般的な自動選択では実装が適切な方式を決めます。アルゴリズムを手動で指定する前に、双方が対応しているか確認してください。CPUのハードウェアアクセラレーションの有無も実際の負荷に影響するため、方式名だけで安定した速度順位を判断することはできません。

VMessの認証では時刻に関するチェックが行われるため、システム時刻が大きくずれていると認証に失敗することがあります。トラブル対処では、まずシステム時刻の自動同期を有効にし、日付・時刻・タイムゾーンが正しいか確認してください。タイムゾーンは表示方法に関係するもので、正確さが必要なのはシステム時刻そのものです。画面上の表示だけを変更して実際の時刻を直していなければ、問題は解消しません。時刻を確認する前にサブスクリプションを何度も作り直したり、暗号化方式を変更したりすると、原因の切り分けが難しくなります。

古い共有情報にはalterIdがよく見られます。現在一般的なVMess AEAD設定では、通常は値を0にするか、クライアントが所定の方法で処理します。値を大きくすれば安全性が増す調整項目ではありません。古い項目が残るサブスクリプションを使う場合は、サーバーが該当する認証方式を採用しているか、クライアントがその項目をどう解釈するか確認してください。何年も前の0以外の値をそのまま使うのは避けましょう。サーバーの説明とインポート結果が一致しない場合は、双方を勘で変更するのではなく、実際のサーバー設定と利用しているコアのドキュメントを基準にしてください。

WebSocketとTLSがよく組み合わされる理由

VMessは複数のトランスポートで通信できます。WebSocketとTLSの組み合わせは、リバースプロキシを使う構成でよく利用されます。クライアントがTLSハンドシェイクを完了し、正しいHTTP Upgradeリクエストを送ると、VMessのセッションが始まります。そのため、ポートに接続できてもパスが正しいとは限りません。WebSocketのpathとHostは構成に合わせる必要があり、リバースプロキシも対応するバックエンドへリクエストを転送しなければなりません。パスの入力ミス、末尾のスラッシュ、接続先サイトの選択間違いは、ハンドシェイク失敗や通常のWebページが返る原因になります。

この組み合わせではラッピングやハンドシェイクの手順が増えますが、アクセスのたびに毎回すべてのコストが発生するわけではありません。長時間接続の再利用、コネクションプール、アプリの通信方法、中間プロキシのタイムアウト設定によって結果は変わります。一方、TCP直結はラッピングが少ないからといって、あらゆる環境でページ表示が速くなるとは限りません。サーバーの場所、回線品質、DNSが異なる2つの構成を比べても、VMess自体の速度差を信頼できる形で判断することはできません。

既存の構成を維持するか移行するか

既存のVMess設定が、保守されているクライアントとサーバーで正常に動作しているなら、プロトコル名が古いというだけで移行する必要はありません。確認すべきなのは、古い認証方式が残っていないか、設定を安定してインポートできるか、トランスポートの設定が明確か、サーバーが継続して保守されているかです。VLESSへ移行するには、サーバー側で対応するインバウンドを作成し、新しい設定情報を用意する必要があります。クライアントのプルダウンメニューでVLESSを選ぶだけでは移行できません。両プロトコルは認証方式とリクエスト形式が異なるため、片側で名前を変更するだけの互換手段はありません。

新しい環境を構築し、XrayのVLESS + REALITY構成が必要な機能に合う場合は、その方式に沿って設定できます。既存のVMessサーバーを引き続き使う場合は、プロトコルとトランスポートをそろえてください。「インポートはできたが接続できない」ときは、元の共有情報と編集画面を見比べ、暗号化方式、トランスポート、セキュリティ層、パスを確認してからログを調べます。一般的なトラブル対処はよくある質問をご覧ください。ローカルのシステムプロキシの問題をVMessの互換性と取り違えないようにしましょう。

TrojanとShadowsocksの違い

TrojanとShadowsocksもよく使われる選択肢ですが、設計上の重点は異なります。Trojanの一般的な構成はTLS通信とパスワード認証を中心としており、証明書とサーバー名が重要な設定項目です。Shadowsocksは比較的シンプルなプロキシ転送と認証付き暗号化を特徴とし、複数世代の暗号化方式が実装されています。「パスワードだけで使える」からといって、セキュリティ層まで同じとは限りません。また、SSと表示されたノードがすべて同じアルゴリズムや機能の実装だと考えるのも誤りです。

Trojan：パスワードだけでなく証明書とサーバー名も確認

v2rayNまたはv2rayNGにTrojanを追加する場合、通常はアドレス、ポート、パスワード、TLS関連の設定が必要です。パスワードはそのまま入力し、記号が日本語入力などで置き換わっていないか確認してください。メモ名は認証には使われません。サーバー名は構成要件と証明書検証に合わせます。アドレスにIPを使い、検証にはドメイン名を使う構成もありますが、サーバー側がそのように設定されていることが前提です。証明書名が一致しない場合は、パスワードの長さではなくSNIとサーバー証明書を確認してください。

Trojanの初回接続では通常、TCP接続とTLSハンドシェイクが行われます。短いリクエストを大量に送る場合は、接続の再利用が使い心地に影響します。長時間のデータ転送では、通信速度とサーバーリソースがより重要になります。TLSは広く使われている成熟したセキュリティ基盤ですが、実際の性能は実装、証明書の構成、中間プロキシ、ハンドシェイクの再開機能にも左右されます。TLSを使うから必ず遅いとは言えません。また、設定項目が少なく見えても、トラブル対処で確認するのがパスワードだけとは限りません。

Shadowsocks：暗号化方式を正確に一致させる

Shadowsocksの主な設定項目は、サーバー、ポート、パスワード、暗号化方式です。新しいAEAD方式と従来のストリーム方式は異なる世代の設計であり、AEAD方式は暗号化に加えてデータの認証も行います。サーバーが指定した方式をクライアントと実行中のコアがサポートしている必要があります。プルダウンにある似た名前の方式を同等と考えてはいけません。方式を間違えると、パスワードが正しくても正常に通信できません。古い設定をインポートできても、共有情報の形式を認識しただけで、現在のコアが該当するアルゴリズムを受け付けるとは限りません。

AEAD 2022などの方式では、鍵の形式が明確に指定される場合があり、一般的なテキストパスワードと同じ感覚で入力することはできません。複数ユーザー用の鍵など、拡張形式を使う構成では、共有情報を完全な状態で保持する必要があります。そのような設定では、まずサーバー側の方式とクライアントの対応範囲を確認し、鍵を一字ずつ正確にコピーしてください。区切り記号を含む文字列を途中で切ったり、サブスクリプション変換ツールに従来型のパスワードとして再解釈させたりすると、意味が変わるおそれがあります。鍵の形式はプロトコル上の要件であり、自由に選べる表示形式ではありません。

基本的なShadowsocks設定のTCP・UDP対応も、クライアントの接続方式とあわせて判断してください。サーバーがUDPを許可していても、システムのHTTPプロキシ経由でクライアントに接続するアプリが、透過的なUDP転送を利用できるとは限りません。共有リンクによってはプラグイン項目を含むものもあります。当サイトで紹介するクライアントやコアがその拡張に対応していない場合、サーバーとパスワードだけを残しても同等の設定にはなりません。双方が対応する完全な構成を用意してもらい、認識できない項目を削除したまま使い続けるのは避けてください。

設定項目の数ではなく、既存の構成に合わせて選ぶ

サーバー側で適切に保守されたTrojan設定が提供され、クライアントがトランスポートとTLSの設定に完全対応しているなら、項目を減らすためだけに別のプロトコルへ変更する必要はありません。Shadowsocksを使う場合は、方式と鍵の形式を正確に確認し、特に世代間の違いに注意してください。どちらも、セキュリティチェックを無効にしたり、不明な項目を削除したりして「互換性を高める」方法は避けましょう。エラーが消えても設定の意味が変わってしまうより、エラーを残したほうがトラブル対処に役立ちます。

実際に選ぶ際は、管理の手間も考慮します。証明書を確実に更新できるか、鍵の変更をサブスクリプションにも反映できるか、利用するコアが必要な拡張に対応しているかを確認してください。既存サーバーに接続する初心者にとって最も重要なのは、自分でプロトコルを再設定することではなく、現在の構成に合わせることです。パスワードやサブスクリプションの内容が漏れた可能性がある場合は、サーバー側で無効化して新しい情報を配布してください。ローカルのメモ名を変更するだけでは不十分です。クライアントのログや共有リンクに機密情報が含まれる場合もあるため、問い合わせる前に認証情報と完全なサブスクリプションURLを削除してください。

接続負荷、リソース、モバイルの電池消費

「最速のプロトコル」を比べるには、まず何を測るかを決める必要があります。初回接続では名前解決、接続確立、セキュリティハンドシェイクが関係します。Webページの表示には、接続先、コネクション再利用、リソース数も影響します。継続的なダウンロードではスループット、パケットロス、サーバー容量が重要です。音声通話やリアルタイムアプリではジッターとUDP経路が問題になります。これらの指標は別々に変化することがあります。クライアントに表示される1つの遅延測定だけでは、すべてのアプリの性能を表せません。サーバーが異なる2つの数値から、プロトコル自体の速度差を導くこともできません。

ハンドシェイクの負荷と継続通信は分けて考える

DNS、TCP接続、TLSなどのセキュリティハンドシェイクは、通信開始前の待ち時間になります。WebSocketやgRPCなどのトランスポートにも、それぞれ接続確立の手順があります。一方、コネクション再利用やハンドシェイクの再開によって、繰り返し発生する負荷を抑えられる場合があります。ネットワークの再送が必要になると、失敗時のコストは大きくなることもあります。短い接続を頻繁に確立するアプリでは、不要な往復を減らす価値があります。長時間維持されるデータ通信では、初回のハンドシェイクが全体の所要時間に占める割合は小さくなります。テストではこの違いを保ち、長時間のダウンロードだけで短時間接続の使い心地を判断しないでください。

CPU負荷は暗号化アルゴリズム、CPU命令、データコピー、実装の最適化に左右されます。デスクトップPCで負荷が小さいアルゴリズムでも、異なるアーキテクチャのスマートフォンでは同じとは限りません。メモリ使用量も接続数、バッファー、ルーティングデータ、DNSキャッシュ、ログの量などに影響され、プロトコルだけで決まるわけではありません。クライアントの使用量が増えた場合は、ルールのダウンロード、大量の接続の維持、詳細ログの出力が行われていないか先に確認し、プロトコル変更が必要かどうかを判断してください。

モバイルでは暗号化の負荷だけを比較できない

スマートフォンの電池を消費する主な要因には、無線モジュールの起動、電波が弱い場合の再送、バックグラウンド接続、頻繁な再接続、ほかのアプリの動作があります。プロトコルの暗号化も計算資源を使いますが、主な原因とは限りません。接続が安定して無線の起動回数が少ない構成は、理論上の処理が軽くても何度も再接続する構成より省電力になる場合があります。モバイル回線とWi-Fiでは消費電力の条件も異なります。ネットワークや画面の明るさが違う状態で電池の減りを比べても、XrayやV2Flyが原因とは判断できません。

AndroidでVPNインターフェース経由の通信を受け付ける場合、クライアントはパケットの読み取りと転送も担います。デスクトップのTUNでも仮想ネットワークインターフェース、ルーティング、DNSの処理が加わります。これらは通信を受け入れる範囲や処理経路を変えるもので、サーバープロトコルをアップグレードする機能ではありません。システムプロキシで対象アプリをカバーできているなら、TUNを有効にしても速度が改善するとは限りません。対象アプリがシステムプロキシに従わない場合は、TUNによって通信を取り込める可能性があります。詳しい設定はv2rayNのTUNモード設定をご覧ください。

Mux、キープアライブ、UDPの実際の制約

マルチプレクスは、複数の論理リクエストを少数の通信接続で共有し、特定の短時間接続で確立コストを減らす仕組みです。一方、共有接続で混雑やパケットロスが起きると、複数のリクエストに影響が及ぶこともあります。一部のプロトコルやフロー制御との組み合わせにはMuxの制約があるため、常に有効にするものではありません。キープアライブにもトレードオフがあります。間隔が短すぎるとバックグラウンド通信が増え、長すぎると一部のネットワークでアイドル状態の接続を維持できない場合があります。まず互換性のある既定値を使い、具体的な問題を確認してから調整してください。

リアルタイムアプリでUDPを使う場合は、ローカルの通信受け入れ、コアの転送、サーバー、接続先ネットワークを含む経路全体が対応しているか確認してください。UDPをプロキシ経由にしても、ジッターが下がるとは限りません。サーバー経由で遠回りしたり、回線が混雑したりすると使い心地が悪化することもあります。DNSの名前解決方法は接続先IPとルーティングに影響するため、テスト中は条件をそろえてください。FakeDNSはドメイン名の対応付けやキャッシュの動作に関係するもので、汎用の高速化機能ではありません。仕組みの詳細はFakeDNSの利用場面に関するメモをご覧ください。

比較では毎回1つの条件だけを変え、起動、最初のリクエスト、継続通信、待機時の状態を別々に記録してください。最良の結果だけを残さず、複数回測定します。同じサーバーと条件を用意できない場合は、「現在使っている2つの設定で体感に差があった」と記録し、プロトコルの順位に結び付けないでください。日常利用では小さな測定差より、接続の安定性、必要機能への対応、問題発生時の復旧のしやすさが重要です。まず互換性を確認し、その後に性能を比較する理由もここにあります。

用途に応じたプロトコルとコアの選び方

選ぶ際はプロトコルの順位ではなく、必要な条件から考えます。端末のプラットフォーム、サーバーが実際に提供する構成、プロキシ経由にしたいアプリの種類、UDPの必要性を確認してください。そのうえで必要な項目をすべて設定できるクライアントとコアを選び、最後に管理の手間や動作を比較します。サーバー側の協力がなければ、通常はプロトコルを自由に変更できず、提供された設定の中から選ぶことになります。クライアントのプロトコル選択メニューは設定の入口であり、接続先サーバーを自動的に別のプロトコルへ変換する機能ではありません。

デスクトップとAndroidの選び方

デスクトップではv2rayNを第一候補としておすすめします。まずダウンロードページでOSとプロセッサーのアーキテクチャに合ったものを選び、必要なプロトコルに対応するコアを確認してください。Windowsデスクトップ版と従来のWPF版の違いはGUIと実行環境に関するもので、接続先のプロトコルの違いではありません。macOSとLinuxでも、アーキテクチャとシステム要件を確認する必要があります。一般的なブラウザーがシステムプロキシを利用できるなら、まずTUNを使わず少ない条件で動作を確認し、必要に応じて通信を取り込む範囲を広げてください。

Androidではサーバーの対応状況に合わせてv2rayNGを優先してください。特にXray関連機能が必要な場合に適しています。サーバーが明確にV2Fly経路を必要としていて、設定が対応範囲内ならv2flyNGも選択肢になります。初回起動時はシステムのVPN接続を許可し、ほかのVPNが同じ接続枠を使用していないか確認してください。その後、バックグラウンドでの動作制限とネットワーク切り替え時の挙動を調べます。アプリをバックグラウンドにすると切断する場合でも、すぐにプロトコルが原因と決めつけないでください。システムの省電力設定、バックグラウンド権限、電波状況をそれぞれ確認しましょう。

既存サーバー、新規構築、リアルタイムアプリ

既存サーバーを使う場合は、元のプロトコルとトランスポートを維持して、まず設定全体が正しくインポートされるか確認するのが最も確実です。VMess + WebSocket + TLSが正常に動いているなら、名称を変えるだけのために移行する必要はありません。Trojanでは証明書、サーバー名、パスワードを適切に保守し、Shadowsocksでは方式と鍵の形式を正確に合わせます。VLESS + REALITYが必要な場合は、組み合わせ全体に対応するXray経路を選び、フロー制御とハンドシェイク項目にはサーバーから提供された値を使います。他の設定から項目を流用しないでください。

新規構築では、運用できる範囲から構成を選ぶとよいでしょう。証明書とサーバー名を管理できるか、リバースプロキシを使う必要があるか、利用する端末すべてが同じセキュリティ方式に対応しているか、サブスクリプションツールが必要な項目をすべて出力できるかを確認します。こうした項目をチェックリストにするほうが、理論上の処理負荷だけを追うより役立ちます。音声通話などUDPを使うアプリが必要なら、端から端までUDPとルーティングを確認してください。Webページが開けるだけでテストを終わらせてはいけません。アプリの地域設定、接続先の回線、サーバーの場所も使用感に影響します。

最小限の設定で、元に戻せる基準を作る

初回の動作確認では、サーバーを1つだけ使い、ルーティングを明確にし、互換性のある既定値を使います。まずコアが起動するか、次にリクエストがローカルポートへ届くかを確かめ、その後サーバーとのハンドシェイクと接続先へのアクセスを確認してください。以下のJSONは、ネイティブ設定のroutingオブジェクトにおける最小限のルール構造を示す例です。プライベートアドレスをdirectという名前のアウトバウンドへ送ります。完全な接続設定ではありません。使用前に該当タグの直接接続アウトバウンドが存在することと、既存ルールの順序を確認してください。GUIクライアントを使う場合は、同様の設定をルーティング画面から行う方法を優先してください。

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

このルールからは、プロトコルとは別の要素もリクエストの経路を変えることがわかります。ノードに変更がなくても、ルーティングによってノードを経由するかどうかが変わります。ルールは実装のマッチング方式に従って処理されます。先に広い条件が一致すると、後にある細かいルールが適用されない場合があります。実際の運用では地域データファイルが利用できるかも確認してください。例をそのまま使うためにroutingオブジェクト全体を置き換えるのではなく、既存ルールを理解してから条件を明示して追加し、ローカルネットワークと接続先ネットワークへのアクセスを個別に確認しましょう。

問題が起きたら、根拠を見ながら元に戻す

コアが起動しない場合は、設定の生成とポートの使用状況を確認します。ハンドシェイクに失敗する場合は、認証情報、セキュリティ層、時刻を確認してください。接続が確立しているのにアプリが応答しない場合は、ローカルの通信受け入れ、DNS、ルーティングを調べます。ローカルポートの競合については、ポート使用中エラーと待ち受けポートの変更メモをご覧ください。一度に変更するのは1項目だけにし、直前に使えていた状態を保存します。元に戻すときは、すべてのプロトコル項目を入力し直すのではなく、追加した高度な機能を先に無効にしてください。

選んだ構成は、クライアント、コア、プロキシプロトコル、トランスポート、セキュリティ層、通信の取り込み方式、ルーティングを1行にまとめて記録できます。端末を変える際に項目ごとに確認でき、問題が起きたときも変更点を正確に伝えられます。プロトコル選択の目的は複雑な名前を選ぶことではなく、サーバーの機能、クライアントの実装、実際のアプリの要件を一致させることです。基準となる構成を作った後で、性能の章の方法に沿って条件をそろえて比較してください。日常的な操作はクイックスタートガイドへ、具体的な疑問はよくある質問をご覧ください。