VMess
VMessはProject Vエコシステムのプロキシプロトコルです。ユーザー識別子などで認証し、プロトコル独自のデータ保護機能も備えています。インポート時は、ユーザーID、サーバーポート、トランスポート設定を確認してください。アドレスが同じかどうかだけでは不十分です。
古い設定では、過去の認証方式に関する項目が使われている場合があります。古い例に合わせてパラメーターを変更するのではなく、サーバー設定と現在のコアとの互換性を確認してください。
リファレンス / 用語と設定項目
V2Ray用語集
接続プロトコルから設定項目まで、6つのカテゴリに分けて解説します。まずクライアント、コア、プロトコル、安全機能を区別し、設定箇所を確認しましょう。名称が似ていても、項目を相互に置き換えられるとは限りません。
01 / PROTOCOL & TRANSPORT
プロトコルとトランスポート
プロトコルはプロキシ要求と認証の形式を定め、トランスポートはデータの運び方を定めます。別々の設定項目です。
VLESS
VLESSはUUIDでユーザーを識別する軽量プロキシプロトコルで、プロトコル自体はペイロードを暗号化しません。接続がトランスポート上で保護されるかどうかは、TLSやREALITYなどの安全機能と全体の構成によって決まります。
設定のencryption、flow、トランスポートの安全機能はそれぞれ役割が異なります。flowはサーバーとコアの両方が対応している必要があり、汎用オプションとして安易に有効化できません。
Trojan
Trojanは通常TLSと組み合わせるプロキシプロトコルです。認証には主にパスワードを使い、VMessやVLESSのユーザーIDとは異なります。ノードをインポートしたら、パスワード、接続先ポート、サーバー名、トランスポート設定を確認してください。
異なるプロトコルで同じアドレスとポートを指定しても、認証方式は同じではありません。プロトコルのプルダウンをTrojanに変更するだけでは、正しくプロトコルを変換できません。
トランスポート方式
トランスポート方式は、ネットワーク接続上でプロキシデータを運ぶ方法を定めます。一般的な設定にはTCP、WebSocket、gRPCなどがあります。パス、Host、サービス名は各方式固有の項目であり、別の方式の設定をそのまま流用できません。
クライアントの画面表示やJSONの値は、バージョンによって異なる場合があります。設定を確認する際は、streamSettings.networkと該当する方式の設定オブジェクトをあわせて確認し、通信する両端の互換性も確かめてください。
02 / CORE & CLIENT
コアとクライアント
GUIは設定を管理し、コアは接続を処理します。GUIでリンクをインポートできても、動作中のコアがすべての設定項目に対応しているとは限りません。
Xray
XrayはXrayプロジェクトが開発するプロキシコアで、プロトコル処理、ルーティング、名前解決などを担います。REALITYなどの機能が使えるかどうかは、実際のコアのバージョンとパラメーターの組み合わせによって異なります。
接続の問題を調べる際は、クライアントとコアのバージョンを個別に確認してください。GUIを更新した後も、クライアント情報やログで実際に起動しているコアを確認しましょう。
V2Fly
V2FlyはV2Rayの開発を引き継ぐコミュニティプロジェクトで、v2ray-coreを保守しています。Xrayとはエコシステム上のつながりがありますが、後続の開発で追加されたプロトコル拡張、設定形式、項目への対応状況は完全には共通していません。
コアを切り替えて設定を移行する場合は、各項目の対応状況を確認してください。ファイル名が同じconfig.jsonでも、内容をそのまま共用できるとは限りません。
GUIクライアント
GUIクライアントは、ノード管理、サブスクリプションのインポート、ルーティング編集、接続制御の画面を提供します。v2rayNはデスクトップ向け、v2rayNGとv2flyNGはAndroid向けです。後者はV2Flyコアを使う場合の選択肢です。
クライアントは画面上の設定から実行用設定を生成する場合があります。そのため、生成ファイルを直接編集しても、次回起動時に上書きされることがあります。クライアントが提供する設定画面やカスタム設定機能を使ってください。
TUNモード
TUNモードは仮想ネットワークインターフェースでトラフィックを受け取るため、通常はシステムプロキシの設定より多くのアプリを対象にできます。対象範囲はシステムのルーティング、権限、クライアントの実装によって異なります。一方、システムプロキシの影響を受けるのは、主に該当するプロキシ設定に従うアプリです。両者は同じものではありません。
TUNを有効にした後も、DNSと除外ルールを確認してください。接続できなくなった場合は、ノードを何度も切り替えるのではなく、仮想インターフェースの状態とルーティングの変化を調べましょう。
03 / CONFIG STRUCTURE
設定ファイルの構造
JSONのデータフローを把握しましょう。受信接続がリクエストを受け取り、ルーティングが接続先を選び、送信接続が通信を開始し、ポリシーが接続動作を制御します。
inbounds
inboundsは受信接続の配列で、コアがどこでトラフィックを受け取るかを定義します。一般的なローカルSOCKS受信接続では、listen、port、protocol、settingsを設定します。
127.0.0.1は通常、同じデバイスからの接続のみを許可します。待受範囲を変更する場合は、認証、ファイアウォール、実際の利用要件も考慮してください。受信接続のポートは、アプリがローカルプロキシに接続するためのもので、リモートサーバーのポートではありません。
outbounds
outboundsは送信接続の配列で、接続の送信方法を定義します。プロキシ接続、直接接続、ブロックする接続などを指定できます。各送信接続のtagは、ルーティングルールから参照するための識別子です。
たとえば、ルールのoutboundTagにdirectを指定する場合は、対応するtagを持つ送信接続が必要です。この名前は任意の識別子であり、指定するだけで直接接続が作成されるわけではありません。
streamSettings
streamSettingsは、トランスポート方式と安全機能を設定する項目で、主にプロキシの送信接続で使います。networkでトランスポート方式を、securityで安全機能を選び、各オブジェクトに対応するパラメーターを設定します。
このオブジェクトだけをコピーしても、ノード全体の設定にはなりません。認証情報とサーバーアドレスは通常、プロトコルのsettingsに記述します。項目名と利用できる組み合わせは、現在のコアのドキュメントで確認してください。
policy
policyはコアの接続ポリシー設定です。ユーザーレベルなどに応じて、ハンドシェイクのタイムアウト、接続のアイドル時間、統計動作を設定できます。ここでいう「ポリシー」は、「特定のサイトを特定の送信接続に振り分ける」ルーティングルールではありません。
接続が頻繁に切れる場合は、タイムアウト設定を確認してください。ただし、すべての値をむやみに大きくするのは避けましょう。まずログから、ハンドシェイク、トランスポート、アイドル状態のどの段階で切断されるかを特定し、関連項目を変更してください。
04 / ROUTING & DNS
ルーティングとDNS
ルーティングは接続先を決め、名前解決はドメイン名に対応するアドレスを調べます。振り分けの結果を確認する際は、両方の経路をあわせて確認してください。
ルーティングルール
ルーティングルールは、ドメイン名、IPアドレス、ポート、受信接続のタグなどの条件に応じて送信接続を選びます。この振り分けは一般にルーティングと呼ばれます。通常は上から順に評価され、最初に一致したルールで接続先が決まるため、具体的なルールを広範囲に適用するルールより前に配置してください。
通常、同じルール内の異なる条件項目はすべて満たす必要があります。同じ項目内の複数の値は、いずれかに一致すればよい候補として扱われます。どのルールにも一致しない場合の動作も明確に設定・確認し、一致したケースだけを調べて終わらせないでください。
ルーティングルールを見る →GeoIP
GeoIPはIPアドレスの集合に基づいてルーティングを判定するデータ分類方式で、geoip:privateのように記述します。実際の対象範囲は使用するデータファイルによって決まり、タグ自体がリアルタイムの位置情報検索を行うわけではありません。
接続先が最初にドメイン名で指定されている場合、IPルールに一致するかどうかは名前解決の方針にも左右されます。データベースやドメインの解決結果が変われば、同じルールでも判定結果が変わることがあります。
GeoSite
GeoSiteはドメイン名の集合に基づいてルーティングを判定するデータ分類方式で、geosite:cnのように記述します。GeoIPとの違いは照合対象で、GeoSiteはドメイン名、GeoIPはIPアドレスの集合を使います。
タグの有無や対象となるドメインは、データの提供元とバージョンによって異なります。使用前にクライアントが読み込むデータファイルを確認してください。特定のサイトだけを処理する場合は、分類全体に頼らず、より具体的なドメインルールを指定できます。
DNSとdomainStrategy
DNSはドメイン名をアドレスに解決します。routing.domainStrategyは、ルーティング判定中にドメイン名の解決を試みるタイミングを決めます。たとえばIPIfNonMatchでは、ドメイン名のルールに一致しなかった場合に、名前解決の結果を使ってIPルールとの照合を試みます。
この項目は「すべてのアプリがコアのDNSを使う」という意味ではありません。システム、ブラウザー、プロキシコアがそれぞれ名前解決を行う場合があります。送信接続内に同じ名前や似た名前の項目がある場合も、配置場所ごとに意味を確認してください。
DNS設定を見る →FakeDNS
FakeDNSは合成アドレスとドメイン名を対応付け、後続の接続で接続先のドメイン名を復元できるようにします。ここで使うアドレスは主に内部の対応付け用で、接続先サイトの実サーバーのグローバルIPアドレスではありません。
名前解決の入口、トラフィックの取り込み、ドメイン名の復元が連携する必要があります。設定オブジェクトを1つ追加するだけでは動作しない場合があります。モードの切り替え後も古いDNSキャッシュが使われている場合は、キャッシュと実際のトラフィック経路をあわせて確認してください。
DNSリーク
DNSリークとは、クエリが想定した名前解決の経路を通らず、別のリゾルバーに処理される現象です。経路が意図から外れた状態を指すため、リゾルバーの名称や所在地だけでは判断できません。
原因を調べる際は、システムDNS、ブラウザーの暗号化DNS、クライアントによるトラフィックの取り込み方法、コアのDNS送信接続をそれぞれ確認してください。Webページのリクエストがプロキシを通っていても、その前のドメイン名の問い合わせが同じ経路を通るとは限りません。
05 / SUBSCRIPTION & NODE
サブスクリプションとノード
サブスクリプションは設定の一覧を管理し、ノードは個々の接続設定を保存します。インポート成功と接続成功は、別々に確認する必要があります。
サブスクリプション
サブスクリプションは、URLからノード一覧を取得・更新する管理方式であり、プロキシプロトコルではありません。内容を利用可能なノード項目に変換するには、クライアントが該当するサブスクリプション形式に対応している必要があります。
更新時は通常、取得先の最新データを読み込み直します。手動で編集したノード設定が保持されるかどうかは、クライアントによって異なります。サブスクリプションURLにアクセス情報が含まれる場合があるため、スクリーンショットや公開ログ、共有テキストへの記載は避けてください。
ノード
ノードはクライアントに保存する接続設定の一式で、通常はサーバーアドレス、ポート、プロキシプロトコル、認証情報、トランスポート設定が含まれます。1つのノードが独立した物理サーバー1台に対応するとは限りません。表示名はプロトコルの認証には使われません。
アドレスを名前解決できても、確認できたのは名前解決の結果だけです。接続を確立するには、ポートに到達でき、認証が正しく、トランスポートと安全機能の設定が互換性を持つ必要があります。
共有リンクとQRコード
共有リンクはノードの設定をインポート可能なテキストに変換したもので、QRコードはそのテキストを伝える方法の1つです。サブスクリプションURLを含む場合もあります。QRコードでインポートしても別の接続プロトコルになるわけではなく、最終的にはクライアントの設定に変換されます。
リンクの拡張項目に対応する範囲はクライアントによって異なります。インポート後はトランスポート、安全機能、サーバー名を確認してください。QRコードに認証情報が含まれる場合があるため、共有前に内容と共有先を確かめましょう。
プロキシ経由の実測遅延
プロキシ経由でテスト対象にアクセスした際の所要時間を指します。名前解決、ハンドシェイク、応答待ち時間が含まれるかどうかは、クライアントの実装によって異なります。ポートへのTCP接続だけを測定する遅延とは別の指標です。
比較するときは、テスト対象と測定方法をそろえてください。遅延が低くても継続的なダウンロード速度が高いとは限らず、タイムアウトの原因がテスト対象のサイトや名前解決にある場合もあります。
06 / SECURITY LAYER
暗号化と安全機能
認証情報、証明書の検証、トランスポートの保護は、それぞれ異なる問題に対応します。ハンドシェイクエラーが発生したら、まずどの階層で起きているか特定してください。
TLS
TLSは通信を暗号化し、相手を認証します。証明書の検証では、信頼チェーン、有効期限、システム時刻、ドメイン名の一致が確認されます。サーバーに接続できても、証明書がクライアントの検証条件を満たすとは限りません。
証明書エラーが発生したら、まずシステム時刻、サーバー名、証明書の設定を確認してください。allowInsecureを有効にすると証明書の検証が緩和されます。あらゆるTLSエラーへの標準的な対処として使うべきではありません。
REALITY
REALITYはXrayエコシステムのトランスポート安全機能で、VLESSなどと組み合わせて使用されます。VLESSと同じ階層のプロキシプロトコルではありません。利用するには通信する両端のコアが対応し、認証とハンドシェイクのパラメーターが一致している必要があります。
クライアントでは通常、サーバー名や公開鍵、その他の検証パラメーター、short IDなどを設定します。実際の項目名はバージョンによって異なります。サーバーの秘密鍵をクライアントに入力したり、通常のTLS設定をそのままREALITY設定として扱ったりしないでください。
SNIとserverName
SNIはTLSハンドシェイクでサーバー名を通知する仕組みです。serverNameは、その名前や証明書の検証に関連するクライアント設定項目です。実際の接続先addressにはIPアドレスを指定し、サーバー名にはドメイン名を指定することもできます。
これら2つの項目は常に同じ値である必要はありませんが、サーバーの設定に合わせる必要があります。サーバー名はWebSocketのHostやHTTPリクエストヘッダーとも異なり、一方を変更しても他の項目には反映されません。
UUID
UUIDはVMessやVLESSなどで使われるユーザー識別子です。クライアントに設定する値はサーバー側の認証設定と一致させてください。UUIDはユーザーを識別するもので、トランスポートの暗号化方式ではなく、TLSやREALITYの設定を代替するものでもありません。
形式が正しくても、サーバー側で認証が許可されているとは限りません。UUIDを再生成した場合は、クライアントとサーバーの両方の設定を更新してください。公開ノードのスクリーンショットを共有する際は、ユーザー識別子やその他の認証情報を隠しましょう。