VMess
Project Vエコシステムのプロキシプロトコルです。ユーザーの識別にUUIDを使用し、独自のデータ保護機能を備えています。現在一般的な設定ではAEADを採用しており、古いチュートリアルにあるalterIdをむやみに増やす必要はありません。現在の設定では通常0にします。認証に失敗した場合は、UUIDと通信パラメーターに加え、端末の時刻も確認してください。
"protocol": "vmess"
V2RAY / TERMINOLOGY
V2Ray用語集
プロトコル、コア、設定項目、診断指標を解説します。設定がどの階層に属するかを確認し、通信の取り込み方式、プロキシプロトコル、通信保護の仕組みを混同しないようにしましょう。
このページでは、よく使われる30の用語を解説します。まず用語の意味を確認し、使用中のクライアントとコアのバージョンに照らし合わせてください。同じ名前のスイッチでも生成される設定が異なる場合があります。また、項目の例はそのまま接続に使える完全な設定ファイルではありません。
01 / PROTOCOLS
プロトコルと通信方式
プロキシプロトコルは認証とデータ交換の方式を定め、通信方式は接続を運びます。TLSやREALITYなどは通信を保護します。設定時は、それぞれの階層を分けて確認してください。
VLESS
UUID認証を使用する軽量なプロキシプロトコルです。VMessの別の暗号化方式と考えるべきではありません。一般的な構成ではTLSやREALITYなどの外部の仕組みで通信を保護するため、セキュリティ層と通信層のパラメーターを両方確認してください。一部の新機能はコアのバージョンに依存するため、リンクのプレフィックスだけでクライアントの互換性を判断することはできません。
"protocol": "vless"
Trojan
通常はTLS接続上で動作するプロキシプロトコルで、パスワードによる認証を使用します。パスワードは認証に使い、証明書検証はTLS接続先の身元確認に使います。互いに代用できるものではありません。証明書エラーが発生した場合は、検証を無効にするのではなく、サーバー名、証明書の有効期限、端末の時刻を確認してください。
"protocol": "trojan"
Shadowsocks
所定の暗号方式と鍵でプロキシ通信を保護するプロトコルです。ノードには通常、サーバーアドレス、ポート、暗号方式、パスワードが含まれます。暗号方式によって鍵の形式やコアの対応状況が異なるため、従来の方式と2022シリーズのパラメーターを混在させないでください。同じプロトコル名でも、すべてのバージョンのクライアントでノードを読み込めるとは限りません。
"protocol": "shadowsocks"
REALITY
Xrayエコシステムの通信保護機能で、VLESSと組み合わせて使われることがよくあります。単独のプロキシプロトコルではありません。クライアント側では通常、サーバー名、公開鍵、shortId、フィンガープリントなどのパラメーターを確認します。項目名は使用中のコアの形式に従ってください。通常のTLSとは異なるため、セキュリティ方式の名称を置き換えるだけでは設定できません。
"security": "reality"
XTLS Vision
XrayでVLESSと組み合わせて使われることの多いフロー制御方式です。条件に合うTLS通信の処理を最適化し、不要な再カプセル化や暗号化の負荷を抑えます。flowで指定するもので、通信プロトコルの名称ではありません。また、すべての通信が高速になるとは限りません。クライアントとサーバーで互換性のあるフロー制御、セキュリティ層、通信方式を使用してください。
"flow": "xtls-rprx-vision"
02 / CORE & CLIENT
コアとクライアント
画面は管理を担い、コアは処理を実行します。機能が使えるか確認するには、クライアントの対応状況と実際に起動しているコアの両方を確認してください。
Project V
V2Rayを中心に形成された、モジュール型ネットワークプロキシのプロジェクトおよびエコシステムです。接続、通信、ルーティングなどの機能を組み合わせて使う考え方が特徴です。V2Ray、V2Fly、Xray、GUIクライアントはそれぞれ異なる階層に属するため、同じソフトウェアの別名として扱うべきではありません。チュートリアルを読む際は、エコシステムの概要、コアの設定、画面の操作のどれを扱っているか確認してください。
Xrayコア
V2Rayのコードを基盤に開発されたプロキシコアで、接続の確立、プロトコル処理、ルーティング、DNSなどを担います。REALITYやVisionなどの設定では、Xrayの具体的な対応状況を確認してください。クライアントの画面に項目が表示されていても、実際に同梱または選択されているコアがその機能を実行できるとは限りません。
V2Fly
V2Ray関連のコア実装を継続的に保守しているコミュニティプロジェクトで、Project Vエコシステムの重要な構成要素です。V2FlyとXrayには共通の技術的背景がありますが、その後の機能、リリースサイクル、設定形式にはそれぞれ違いがあります。設定を移行する際は、移行先のコアのドキュメントを確認してください。一方の独自項目を、もう一方にそのまま追加することはできません。
GUIクライアント
ノード一覧、サブスクリプション更新、ルーティング設定、実行ログなどの画面を備えたアプリです。v2rayN、v2rayNG、v2flyNGなどがあります。クライアントは通常、設定を生成してコアを呼び出すため、画面上の名称がJSONの項目名と完全に一致するとは限りません。アプリを選ぶ際は、OSとノードに必要な機能を確認してから、クライアントのダウンロードページで該当する項目を選んでください。
03 / CONFIGURATION
設定構造
設定は通常、「通信を受け取る」「出口を選ぶ」「接続を確立する」の順に見ると理解しやすくなります。項目の名前を覚えるだけでなく、どの階層に属するかを把握することが大切です。
JSON設定
オブジェクト、配列、キーと値でコアの実行パラメーターを記述するテキスト形式です。キー名と文字列は二重引用符で囲み、真偽値はtrueまたはfalseと記述します。厳密なJSONではコメントや末尾の余分なカンマは使えません。一部のツールが寛容に解析できても、それを一般的なルールと考えないでください。構文が正しいことを確認した後も、項目が使用中のコアと設定バージョンに対応しているか確認が必要です。
inbounds（受信設定）
アプリからの通信をコアがどのように受け取るかを定義します。一般的には、待ち受けアドレス、ポート、SOCKSやHTTPなどの接続プロトコルを指定します。ローカルの待ち受けポートとリモートサーバーのポートは、それぞれ役割が異なります。通常は自分の端末だけで使う場合、ループバックアドレスにバインドします。LANに公開する前に、アクセス制御と端末のファイアウォール設定を確認してください。
"listen": "127.0.0.1"
outbounds（送信設定）
コアが外部へ接続する方法を定義します。プロキシ、直接接続、ブロックなどの出口を設定できます。outboundのtagはルーティングから参照するためのラベルであり、プロトコル名ではありません。proxyというタグを付けただけでは、プロキシ接続は作成されません。ルールを調べる際は、参照先のタグとoutboundのタグが完全に一致しているか確認してください。
"outboundTag": "proxy"
policy（ポリシー）
接続タイムアウト、ユーザーレベルに応じた制限、一部の統計機能など、実行時のポリシーを定義します。対象となる項目はコアによって異なります。ここでいうポリシーは、特定のサイトの出口を選ぶ設定ではありません。出口の選択はroutingで行います。タイムアウトを変更する前に、ログから失敗した処理を確認してください。待ち時間をむやみに延ばしても、認証やルーティングの問題は解決しません。
04 / ROUTING & DNS
ルーティングとDNS
トラフィック分岐には、判定可能な宛先情報が必要です。ドメイン、名前解決の結果、通信の取り込み経路が一致しない場合、ルールが正しくても適用されないことがあります。
routing（ルーティングルール）
ドメイン、IP、ポート、ネットワークの種類、inboundsのタグなどの条件に応じて、接続に使用するoutboundを選びます。一般的なルールはリストの順に照合され、最初に一致した有効なルールで出口が決まります。同じルール内の複数の条件は、通常すべて満たす必要があります。問題を調べる際は、まずルールの順序を確認し、次にoutboundTagを照合してください。ドメインの綴りだけを確認しても不十分です。
"type": "field"
GeoIPとGeoSite
GeoIPはIPアドレスのリストで分類し、GeoSiteはドメインのリストで分類します。ルーティングルールの重複を減らすためによく使われます。分類名、収録内容、更新状況は、実際に読み込まれているデータファイルによって異なります。名前だけで対象をすべて網羅していると判断しないでください。ドメインのリストとアドレスのリストは互換ではありません。ルールに一致しない場合は、名前解決の結果とデータの取得元をそれぞれ確認してください。
"ip": ["geoip:private"]
トラフィック分岐
ルールに応じて、通信ごとに異なる出口を使い分ける機能です。たとえば、指定したドメインにはプロキシを使い、LAN内のアドレスには直接接続します。システムプロキシは一部のアプリの通信をクライアントに送るかどうかを決め、トラフィック分岐はクライアントに入った通信の経路を決めます。両者は別の設定です。クライアントに表示されるモード名はルール設定の入口にすぎないため、生成されたルーティング設定も確認してください。
DNSとdomainStrategy
DNSはドメイン名をアドレスに変換し、ルーティングのdomainStrategyはルールを判定する際にいつ名前解決を試みるかを決めます。IPIfNonMatchは通常、ドメイン名がルールに一致しなかった後、解決したIPでの照合を試みます。IPOnDemandは、IPルールに遭遇したときに名前解決を行うことがあります。ほかの設定階層にある同名の項目は意味が異なる場合があるため、含まれるオブジェクトと合わせて確認してください。
"domainStrategy": "IPIfNonMatch"
FakeDNS
アプリにはマッピングアドレスを返し、コアがそのアドレスから元のドメイン名を復元して、後続の処理やルーティング判定に使用します。このアドレスは対象サイトの実際のアドレスではないため、DNSリクエスト、通信の取り込み、inboundsでの識別を連携させる必要があります。該当する通信を取り込まずに設定だけ有効にすると、アプリがマッピングアドレスを受け取っても接続できないことがあります。
DNSリーク
DNSの問い合わせが想定した経路を通らずに送信される状態です。たとえば、クライアントで処理する想定でも、システムやブラウザーが別途名前解決する場合があります。システムDNS、ブラウザーの暗号化DNS、アプリのキャッシュ、クライアント内蔵の名前解決を個別に確認してください。検査ページを一度見るだけでは十分ではありません。想定から外れた問い合わせかどうかは、明確なネットワークポリシーに基づいて判断してください。
TUNモード
仮想ネットワークインターフェースとルーティング設定を使ってIP通信を取り込む方式です。システムプロキシ設定に従わないアプリの通信を扱う場合に適しています。TUNはプロキシプロトコルではなく、リモートノードやDNSの設定に代わるものでもありません。実装によっては、クライアントが呼び出す追加コンポーネントが必要です。有効にした後、LANへの接続に問題が起きた場合は、ルーティングの除外設定、権限、DNSの取り込み設定を確認してください。
05 / SUBSCRIPTIONS
サブスクリプションとノード
サブスクリプションは設定情報を取得する入口、ノードは接続パラメーター、共有リンクはパラメーターをテキスト化したものです。インポートに成功しても、接続できることが確認されたわけではありません。
サブスクリプションURL
ノードや設定情報を取得するためのURLで、クライアントから更新して最新の内容を読み込みます。レスポンスはエンコードされた共有リンクの一覧、ネイティブ設定、その他の形式の場合があります。インポート先の形式と一致しているか確認してください。アクセス認証情報が含まれる場合があるため、機密情報として管理し、スクリーンショット、ログ、公開の質問からも隠してください。
ノード
クライアント上で表示される、リモート接続パラメーターのまとまりです。通常、サーバーアドレス、ポート、認証情報、通信のセキュリティ設定などが含まれます。ノード名は提供元またはユーザーが設定するもので、名前に含まれる地域や回線の表記は性能測定の結果ではありません。接続を調べる際は、表示名だけを比べるのではなく、実際のアドレスとパラメーターを確認してください。
共有リンクとBase64
共有リンクは、単一ノードのパラメーターをインポート可能なテキストで表現したものです。たとえば、vmess://やvless://で始まります。一般的なVMess共有形式では、パラメーターのオブジェクトをBase64でエンコードします。VLESSリンクでは通常、アドレスとクエリパラメーターで設定を表現します。Base64はエンコード方式にすぎず、暗号化による保護はありません。デコードできても、項目が互換性を持つとは限りません。
サブスクリプション変換
異なるサブスクリプション形式や設定形式を解析し、項目を対応付ける処理です。ファイル拡張子を変更するだけではありません。変換先の形式で表現できないオプションは失われることがあり、変換先のコアが対応していない機能も追加されません。変換後は、セキュリティ層、flow、サーバー名、通信パラメーターを個別に確認してください。機密情報を扱う場合は、ローカルでの変換を優先しましょう。
06 / MEASUREMENT
速度測定と診断
数値を比較する前に、テストが通信経路のどこまでを測定しているか確認しましょう。ポートへの接続、プロキシ経由のリクエスト成功、継続的なダウンロード速度は、それぞれ異なる指標です。
システムプロキシ
OSがアプリ向けに提供するプロキシの接続設定です。通常は、クライアントがローカルで待ち受けるHTTPまたはSOCKSのアドレスを指定します。この設定に従うアプリだけがプロキシを使うため、システムプロキシを有効にしてもすべての通信が取り込まれるわけではありません。クライアントを終了した後にブラウザーが接続できなくなった場合は、停止したポートを参照するプロキシ設定が残っていないか確認してください。
遅延とTCPing
遅延を示す際は、どの処理を測定したかを明確にする必要があります。一般的なpingは通常ICMPの往復時間を測定し、TCPingは通常、対象ポートへのTCP接続確立にかかる時間を測定します。TCPingの成功が示すのは、テスト条件下でポートに接続できたことだけです。プロキシ認証やTLSパラメーターが正しい証明にはなりません。特定の測定に応答がなくても、すべての接続方法が使えないとは限りません。
実接続遅延
プロキシ経由でテスト先にリクエストを送信し、応答までにかかった時間を測定します。単純なポート接続テストより、実際のアクセスに近い範囲を測定できるのが一般的です。DNS、ハンドシェイク、接続の再利用、サーバー応答、テスト先の影響を受けます。計測方法はクライアントの実装によって異なります。ノードを比較する際は、同じテスト先を近い時間帯に使い、実際のアプリからのリクエストも合わせて確認してください。
ダウンロード速度とスループット
テストデータを転送し、単位時間あたりに受信できる実効データ量を推定します。1回のリクエストで応答を待つ時間とは別の指標です。テスト元の容量、回線の混雑、端末の性能、同時接続の方法が結果に影響します。低遅延でもスループットが高いとは限りません。速度測定では通信量を消費するため、まず接続と遅延を確認し、候補を絞ってからダウンロードテストを行いましょう。
sniffing（通信の識別）
接続の初期データからプロトコルやドメインの手掛かりを特定し、ルーティングなどの後続処理に利用します。たとえば、読み取り可能なHTTPのホスト名やTLSハンドシェイクの情報を確認します。通信を完全に復号する機能ではなく、すべてのアプリの通信から宛先ドメインを特定できるわけでもありません。宛先を書き換えるのか、ルーティングだけに使うのか、FakeDNSと組み合わせるのかは、個別のオプションを確認してください。全体のスイッチだけを見て判断しないようにしましょう。
"sniffing": {"enabled": true}