VMess
V2Rayエコシステムで使われるプロキシプロトコル。ユーザーIDで認証し、独自のデータ保護機能も備えています。設定時はユーザーID、プロトコルのオプション、下位の通信方式を個別に確認してください。サーバーアドレスだけでは接続できません。古い解説にある互換用パラメーターが現在の実装で使えるとは限らないため、接続エラーが発生したら、まずコアのバージョンとサーバー側の要件を確認しましょう。
用語リファレンス / CONCEPT REFERENCE
V2Ray用語集
プロトコル、コア、設定、ルーティングの役割を整理。用語がどの階層に属するかを確認してから、クライアント設定やJSONの項目と照らし合わせましょう。
01 / PROTOCOL & TRANSPORT
プロトコルと通信方式
プロキシプロトコルは認証やデータ形式を定め、通信方式は接続を運び、セキュリティ層は通信を保護します。1つのノードにこれらの設定が含まれることもありますが、名前が似ていても互換性があるとは限りません。
VLESS
シンプルな認証構造が特徴のプロキシプロトコル。プロトコル自体にデータを暗号化する機能はなく、TLSやREALITYと組み合わせて使われます。VLESS、通信方式、セキュリティ層はそれぞれ別の設定項目です。いずれかを選んでも、ほかの設定が自動で補われるわけではありません。特定のフロー制御オプションを使う場合は、クライアントとサーバーのコアがどちらも対応しているか確認してください。
Trojan
通常はTLS接続上で利用する、パスワード認証方式のプロキシプロトコル。接続の成否はパスワードだけでなく、ポート、サーバー名、証明書の検証にも左右されます。証明書エラーは、名前の一致、信頼チェーン、端末の時刻を確認して対処し、安易に検証を無効にしないでください。
Shadowsocks
所定の暗号方式と認証情報を使ってプロキシ通信を行うプロトコル群。仕様や暗号方式によって、鍵の形式や実装バージョンの要件が異なるため、インポート後に方式名を確認してください。VMessやVLESSとは別のプロトコルで、表示名を変更するだけでは変換できません。
TLS
通信を暗号化し、完全性と相手の正当性を保護するセキュリティプロトコル。プロキシプロトコルそのものとは異なります。通常、クライアントには正しいサーバー名が必要で、証明書が信頼できるか検証します。SNIはハンドシェイク時に接続先名を伝えるための情報です。実際の接続先アドレスとは異なる場合もありますが、サーバーの構成に合っている必要があります。
REALITY
Xrayエコシステムの通信保護方式で、VLESSと組み合わせた接続設定によく使われます。サーバーから提供された情報に基づき、公開鍵、サーバー名、その他の接続パラメーターを設定してください。通常のTLSの設定をそのまま適用できるとは限りません。リンクを読み込めてもコアが実行できるとは限らないため、現在のコアの対応状況を確認しましょう。
02 / CORE & CLIENT
コアとクライアント
クライアントの画面は設定を管理し、コアは接続を実行します。システムプロキシとTUNはクライアントに通信を取り込む方法であり、特定のリモートプロキシプロトコルではありません。
Project V
ネットワークプロキシや通信ツールをめぐるプロジェクト群を指す概念で、V2Rayはその主要な構成要素のひとつです。特定のGUIクライアントを指す名称ではなく、エコシステム内のすべての実装が同じ機能を持つわけでもありません。資料を読む際は、プロジェクトの背景、具体的なコア、クライアントの画面のどれについて述べているかを確認しましょう。
V2Fly
V2Ray関連のコア実装を開発するコミュニティプロジェクト。コアはプロトコル処理、インバウンドでの接続受け付け、アウトバウンドへの接続、ルーティング、DNSなどを担います。v2flyNGはこのコアファミリーを使うAndroidクライアントです。設定を比較するときは具体的なバージョンを確認し、ファイル名が同じという理由だけで項目の互換性を判断しないでください。
Xray
V2Rayと歴史的なつながりを持つ独立したコアプロジェクトで、プロトコル対応状況や設定の詳細は独自に発展しています。v2rayNGはXrayコアを使用します。v2rayNで利用できる機能は、選択したコアを確認してください。Xrayの資料に記載された機能が、別のコアでも同じ設定で使えるとは限りません。
GUIクライアント
サブスクリプション管理、ノード選択、各種設定の画面を備え、通常は設定を生成して下位のコアを呼び出すアプリです。v2rayN、v2rayNG、v2flyNGはクライアントの名称であり、プロトコル名ではありません。トラブル時はクライアントとコアのバージョンを分けて記録しましょう。画面の選択肢と実際の接続機能は、異なる部分が決めている場合があります。
システムプロキシ
OSがアプリに提供するプロキシ設定で、通常はクライアントのローカル待ち受けアドレスとポートを指定します。この設定に従うアプリだけが該当する入口を使います。コマンドラインツールや独自のネットワーク設定を持つアプリは、別の経路を使う場合があります。システムプロキシを有効にするのは入口の設定であり、コアに入った後のアウトバウンドを決めるものではありません。
TUNモード
仮想ネットワークインターフェースでIPパケットを受け取る接続方式。システムプロキシに従わない一部のアプリの通信も取り込めます。実際の適用範囲は、クライアントの実装、OSの権限、ルーティング、除外ルールによって異なります。有効にした後はDNSの処理やローカルネットワークへのアクセスも確認してください。問題が起きたら、ほかのネットワークツールとルートが競合していないか調べましょう。
03 / CONFIGURATION STRUCTURE
設定ファイルの構成
「接続を受け付ける → ルールを照合する → 出口を選ぶ」の順で読むと、問題の箇所を特定しやすくなります。以下の名称はよく使われるJSONの項目です。詳しい例はJSON設定ガイドをご覧ください。
JSON設定
オブジェクト、配列、キーと値でコアの動作を記述する設定形式です。文字列とフィールド名は二重引用符で囲みます。構文を解析できても、現在のコアが設定項目を受け付けるとは限りません。クライアントが自動生成した実行用設定は、次回の保存時に上書きされることがあります。変更前に、設定を永続化するための方法を確認してください。
ログ
動作状況やエラーを記録する設定項目です。設定の解析エラー、ハンドシェイクの失敗、接続タイムアウトなどの調査に使います。ログレベルを上げると情報量が増え、切り分けに役立つ一方で記録も増えます。障害の発生時刻と照らし合わせて確認しましょう。ログを共有する前に、サブスクリプションURLや認証情報、不要なアクセス情報を削除してください。
インバウンド
コアが接続を受け付ける入口。通常は待ち受けアドレス、ポート、受け付けるプロトコル、タグを指定します。ローカルのSOCKSプロキシやHTTPプロキシのポートは、よく使われるインバウンドです。アプリがここに接続すると、コアがリクエストを処理します。ループバックアドレスで待ち受ける場合と、すべてのネットワークインターフェースで待ち受ける場合では、アクセス可能な範囲が異なります。LANからのアクセスを許可する前に、ファイアウォールと認証設定を確認してください。
アウトバウンド
コアがリクエストを処理する際の出口。リモートプロキシへの接続、直接接続、通信の遮断などを指定します。ルーティングルールからアウトバウンドをタグで参照するため、タグはルール内の指定と一致させてください。どのルールにも一致しないリクエストの処理方法も確認が必要です。クライアントの一覧に表示される順番が、生成される設定のデフォルト出口とは限りません。
トラフィック検出
一部の接続の初期データからプロトコルや接続先ドメインを判別し、ルーティングに必要な情報を補う機能です。任意の暗号化データを復号できるわけではなく、すべての接続からドメインを特定できるわけでもありません。ルーティングにだけ使うのか、接続先にも影響するのかは、個別のオプションを確認してください。検出を有効にすれば、あらゆるドメインルールの問題が解決するわけではありません。
ポリシー
接続タイムアウト、ユーザーレベルごとの動作、一部の統計機能などを設定する項目です。ドメインによるトラフィック振り分けルールではありません。「ポリシー」という言葉はクライアントの別のメニューにも使われるため、対応する設定項目を確認してください。タイムアウトを変更すると接続を維持・終了するタイミングは変わりますが、回線の容量やサーバーの応答速度が直接改善するわけではありません。
04 / ROUTING & DNS
ルーティングとDNS
トラフィックの振り分けには照合に使える情報が必要で、DNSはドメイン名の解決方法を決めます。この設定を確認するときは、ルールの内容だけでなく、リクエストがドメイン名とIPアドレスのどちらを持ってコアに入るかも確認してください。
ルーティングルールとトラフィック振り分け
ドメイン、IPアドレス、ポート、プロトコル、インバウンドのタグなどの条件に応じて、アウトバウンドを選ぶルール群です。トラフィック振り分けとは、この選択処理を指します。通常は設定順に照合されるため、広い条件に上書きされる可能性があるルールより前に、個別の例外を置いてください。クライアントの「中国本土をバイパス」などのモード名は、通常はルールのプリセット名であり、VMessのようなプロトコルではありません。
GeoIP
地域や用途ごとにまとめたIPアドレスのリスト。ルーティングでは、リストのタグを使って複数のアドレスをまとめて照合できます。これはデータセット上の分類であり、サーバーの実際の所在地やサービスの所属先をリアルタイムで測定した結果ではありません。Webサイトが複数のアドレスを使う場合や、アドレスが変わった場合は照合結果も変わることがあります。実際の接続先とデータの更新時期を確認してください。
GeoSite
サービス、用途などのカテゴリごとにまとめたドメインのリスト。ドメインルールを個別に管理する手間を減らせます。リストの名称や内容は使用するデータファイルによって異なり、どのコア環境にも同じ分類が含まれるとは限りません。コアが接続先のIPアドレスしか取得できない場合、ドメインリストを直接照合できないことがあります。インバウンドの情報やトラフィック検出の設定も確認してください。
ドメイン解決ポリシー
特定の設定項目でドメイン解決をどう扱うかを指定するオプション。同じ名前のフィールドでも、設定場所によって意味が異なる場合があります。ルーティングのIPIfNonMatchは通常、まず手元の情報でルールを照合し、一致しなければドメインを解決してIPルールへの一致を試みる設定です。すべてのアプリのDNSリクエストを特定のDNSサーバーに一括転送する機能ではありません。
FakeDNS
アプリに合成IPアドレスを返し、そのアドレスと元のドメイン名の対応関係を管理します。後続の接続は、この対応関係を復元できる処理経路を通る必要があります。合成IPアドレスは、接続先サイトの実際のアドレスではありません。DNS問い合わせと接続が別の経路を通るとアプリが接続できない場合があるため、DNSの取り込み、アドレスプール、ルーティングの設定をまとめて確認してください。
DNSリーク
ドメインの名前解決が、想定したポリシーとは別の経路で行われる現象です。まず、どのDNSリゾルバーと経路を使う想定なのかを明確にしてください。OSのリゾルバー、ブラウザー独自の名前解決、アプリ内蔵の名前解決が使われる場合があります。テストページに表示されるDNSサーバーの地域は手がかりにはなりますが、すべてのアプリの問い合わせが同じポリシーに従うことの証明にはなりません。
05 / SUBSCRIPTION & NODE
サブスクリプションとノード
サブスクリプションは接続パラメーターを配布し、ノードはパラメーターを記録します。テスト結果は特定の条件下での通信状況を示します。それぞれを分けて確認し、1回の速度測定だけで設定の正しさを判断しないでください。
サブスクリプション
クライアントが1つのURLから複数の接続設定を取得・更新する仕組み。形式や内容は、提供元とクライアントの両方によって異なります。更新してもルーティング、DNS、ローカル設定が同期されるとは限らず、手動で変更したノードが次回の更新で上書きされる場合もあります。サブスクリプションURLに認証情報が含まれることがあるため、認証情報と同様に安全に保管してください。
ノード
クライアントに保存される接続パラメーターのセット。通常はアドレス、ポート、プロトコル、認証、通信方式などを含みます。1つのノード設定が独立した1台のサーバーに対応するとは限らず、同じアドレスで複数の異なる設定を使うこともできます。名称に含まれる地域や回線の情報は説明にすぎないため、実際の接続結果と設定内容を確認してください。
共有リンク
接続パラメーターをテキストリンクにまとめた共有形式。クライアントはクリップボードやQRコードから読み込めます。インポートに成功しても、すべてのパラメーターに対応しているとは限らず、サーバーが現在利用できるとも限りません。共有リンクには認証情報が含まれることがあります。スクリーンショット、ログ、公開の質問などでリンク全体を表示しないでください。
サブスクリプション変換
サブスクリプションやノードの形式を別の形式に変換する処理。フィールドの対応付けや、非対応パラメーターの扱いが必要になることがあります。変換しても、変換先のクライアントに元からないプロトコル対応が追加されるわけではなく、一部の設定の意味が失われることもあります。変換サービスを利用すると、元のデータが別の事業者に渡る可能性があります。取り扱い方法とアクセス範囲を事前に確認してください。
遅延
特定のテスト方法で測定した応答時間。テスト先、ネットワークの階層、タイムアウト条件を踏まえて判断してください。ICMPの応答確認、TCP接続の確立、プロキシ経由のリクエストでは、測定している内容が異なります。数値をそのまま比較することはできません。遅延が小さくてもダウンロードが速いとは限りません。通信速度は回線容量、混雑状況、サーバー負荷にも左右されます。
実接続遅延
クライアントから指定したプロキシを経由してテスト先に接続し、測定した応答時間です。サーバーのポート確認だけの場合より、実際のリクエスト経路に近い測定です。DNS、TLSハンドシェイク、応答の受信が測定に含まれるかは、クライアントの現在の実装によって異なります。テストに成功しても、その時点で対象に接続できたことを示すだけです。タイムアウトの原因がテスト先やローカル設定にある場合もあり、ノードの故障とは限りません。
用語から設定手順を確認
リクエストがクライアントに届いているか不明な場合は、システムプロキシとインバウンドを確認します。リクエストは届いているのに想定した出口を使わない場合は、ルーティングルールとアウトバウンドのタグを確認してください。ドメイン名とIPアドレスで結果が異なる場合は、ドメイン解決ポリシーとDNSを調べます。一度に変更するのは関連する設定だけにし、問題を再現できるテスト条件を保ってください。