VMess
プロトコルとトランスポート · プロキシプロトコルVMess は Project V エコシステムのプロキシプロトコルで、接続設定にはユーザー情報やサーバーアドレスなどが含まれます。TCP や WebSocket と同じものではなく、同じプロトコルでも異なるトランスポート方式を組み合わせられます。読み込み後に接続できない場合は、アドレスやポートだけでなく、認証情報、トランスポート設定、端末の時刻も確認してください。
設定用語ガイド
V2Ray 用語集
設定シーンに合わせて用語を確認できます。まずプロトコル、コア、クライアントを区別し、サブスクリプション、プロキシモード、ルーティングルールの関係を理解しましょう。
プロトコルとトランスポート
プロトコルは通信方法を定め、トランスポート方式とセキュリティ層は接続の運び方と保護方法を決めます。それぞれ個別に確認しましょう。
VLESS
プロトコルとトランスポート · プロキシプロトコルVLESS は軽量なプロキシプロトコルで、単体では通信を暗号化しません。通常は TLS や REALITY などのセキュリティ機能と組み合わせて使います。ユーザーID、フロー制御、安全性に関する設定はサーバー側と一致させる必要があります。既存設定のプロトコル名を VLESS に変えるだけでは、プロトコルを変換できません。
Trojan
プロトコルとトランスポート · TLSと認証Trojan は通常、TLS で接続を保護し、パスワードで認証します。サーバーアドレス、パスワード、サーバー名、証明書の検証設定はいずれも接続結果に影響することがあります。証明書エラーが発生した場合は、まずサーバー名と端末の時刻を確認しましょう。証明書検証の無効化を常用の解決策にするのは避けてください。
REALITY
プロトコルとトランスポート · トランスポートセキュリティREALITY は Xray エコシステムのトランスポートセキュリティ機能です。VMess や VLESS と並ぶ独立したプロキシプロトコルではなく、一般的な設定では VLESS と組み合わせて使います。公開鍵、ショートID、サーバー名などを正確に一致させる必要があります。クライアントに設定項目が表示されていても、実際に使用するコアがその組み合わせに対応しているとは限りません。
コアとエコシステム
クライアントは操作画面を提供し、実際の通信はコアが処理します。対応状況はソフトウェア名だけで判断せず、現在動作しているコンポーネントを確認してください。
プロキシコア
コアとエコシステム · 実行コンポーネントコアは設定を解析し、接続を確立して、DNSとルーティングを処理します。GUIクライアントは設定の読み込み、編集、起動を担います。画面上で起動できても、コアが正常に動作しているとは限りません。問題を調べる際は、画面のエラーとコアの実行ログを分けて確認し、使用中のコアが現在のプロトコルやトランスポート設定に対応しているか調べましょう。
Xray
コアとエコシステム · プロキシコアXray は V2Ray と技術的な系譜を共有するコアプロジェクトで、独自のプロトコルやトランスポート機能を発展させています。v2rayNG は Xray コアを使用し、v2rayN でも対応する接続の処理に利用できます。実際に使える機能はコアのバージョンやクライアントの実装によって異なるため、あるバージョンの対応状況をすべてのリリースに当てはめないでください。
V2Fly
コアとエコシステム · V2RayコミュニティプロジェクトV2Fly は V2Ray の開発を引き継ぐコミュニティプロジェクトで、コアと関連技術のエコシステムを維持しています。v2flyNG はこのコアを採用しています。V2Fly と Xray には技術的なつながりがありますが、対応機能は完全には一致しません。どちらを使うかは、既存設定で必要なプロトコルやトランスポート機能に基づいて判断し、設定ファイルを自由に入れ替えられるものと考えないでください。
sing-box
コアとエコシステム · 独立系プロキシプラットフォームsing-box は独立したプロキシプラットフォーム兼コアプロジェクトで、v2rayN の一部機能から実行できます。Xray とは設定形式、ルールの記述方法、機能の実装が異なるため、設定ファイルをそのまま共用することはできません。GUIでコアを切り替える際は、現在の接続設定やルーティング設定をクライアントが正しく引き継げるか確認してください。
クライアント機能
まず通信をクライアントに取り込む方法を確認し、次に取り込んだ通信の処理ルールを確認しましょう。システムプロキシ、PAC、TUNはそれぞれ異なる階層の機能です。
システムプロキシ
クライアント機能 · アプリのプロキシ接続先システムプロキシは、OS にプロキシの接続先を登録し、システム設定に従うアプリからクライアントへリクエストを渡せるようにします。独自のネットワーク設定を使うアプリもあるため、システムプロキシを有効にしても全通信が対象になるわけではありません。クライアント終了後もブラウザーが停止済みのローカルプロキシポートを参照している場合は、システムプロキシ設定に残った項目を削除してください。
TUN モード
クライアント機能 · 仮想ネットワークインターフェースTUN モードは仮想ネットワークインターフェースで通信を受け取り、プロキシコンポーネントに渡して処理します。システムプロキシ設定に従わないアプリも対象にしたい場合に適しています。追加の権限やルーティング、DNS設定が必要になることがあり、システムプロキシの対象を単純に広げるスイッチではありません。ほかの仮想ネットワークツールと併用する際は、ルーティングの競合に注意してください。
PAC モード
クライアント機能 · 自動プロキシ設定PAC は自動プロキシ設定に対応するアプリに対し、スクリプトで直接接続にするかプロキシを使うかを判断します。判定はリクエスト先のアドレスやホスト名に基づくことが一般的です。プロキシに渡された接続だけが、その後クライアントのコアルーティング処理に進みます。そのため、PACによる直接接続の判定と、コアのルールによる直接接続の判定は別の段階です。問題を調べる際は、それぞれ個別に確認してください。
コアの切り替え
クライアント機能 · 互換性の選択コアの切り替えとは、クライアントが実際に使用する実行コンポーネントを変更することで、サーバーやサブスクリプションの提供元を変更することではありません。切り替える前に、プロトコル、セキュリティ機能、DNS、ルール形式が移行先のコアに対応しているか確認しましょう。切り替え後に設定が動かなくなったら、まず動作確認済みの組み合わせに戻してログを確認してください。複数の項目を同時に変更すると、原因を特定しにくくなります。
サブスクリプションとノード
サブスクリプションは設定の更新元、ノードは個々の接続設定です。設定の提供元を管理することと、使用する接続先を選ぶことは別の作業です。
サブスクリプション
サブスクリプションとノード · 一括更新の入口サブスクリプションでは、1つのURLから複数の設定を取得し、その後の更新で提供元の追加・削除や設定変更を反映できます。URLにアクセス情報が含まれる場合があるため、パスワードと同様に保管し、スクリーンショットやログを共有する際は隠してください。更新に失敗しても、それだけで読み込み済みの接続がすべて無効になったとは限りません。
ノード
サブスクリプションとノード · 個別の接続設定ノードは、クライアントで個々の接続設定を指す際によく使われる呼び方です。通常、サーバーアドレス、ポート、認証情報、プロトコル、トランスポートの設定を含みます。表示名はメモにすぎず、サーバーの場所や回線の特性を正確に示すとは限りません。接続できるかどうかは実際の接続テストとログで確認し、名前の説明だけで判断しないでください。
共有リンク
サブスクリプションとノード · 個別設定の読み込み共有リンクは通常、vmess:// や vless:// などのプロトコルスキームで始まり、1件分の接続設定を格納しています。クリップボードからの読み込みに便利ですが、サブスクリプションのように提供元の変更を継続して同期するものではありません。コピーする際は内容をすべて保持してください。チャットアプリによる途中切れ、余分な空白、誤ったエスケープがあると、読み込みに失敗することがあります。
サブスクリプショングループ
サブスクリプションとノード · 提供元の管理サブスクリプショングループを使うと、提供元ごとにURLや読み込んだ設定を整理でき、個別の更新、名前の変更、検索がしやすくなります。グループ自体に負荷分散機能はなく、現在の接続に障害が起きても自動で切り替わるわけではありません。読み込んだ項目を手動で変更する前に、次回の更新で変更が上書きされるか確認してください。長期間保持したい変更は、別途保存するのがおすすめです。
ルーティング
ルールが接続先を決めます。ドメインデータ、IPデータ、デフォルトの出力先は組み合わせて使うもので、相互に置き換えることはできません。
ルーティングルール
ルーティング · 条件との照合と出力先ルーティングルールは、ドメイン、IP、ポートなどの条件に基づき、接続の出力先として直接接続、プロキシなどを選択します。一般的な設定では上から順に照合するため、先に広い条件のルールがあると、後続の詳細なルールが適用されない場合があります。どのルールにも一致しない場合はデフォルトの出力先が使われるため、特定サイトの経路を調べる際は、ルールの順序とフォールバック設定の両方を確認してください。
GeoIP
ルーティング · IPアドレス範囲データGeoIP はルーティングにおいて、通常、カテゴリ別に整理されたIPアドレス範囲データを指し、ルールによる宛先の判定に使われます。単一のIPアドレスだけで、Webサイトの運営元やすべてのアクセス経路を正確に推定することはできません。CDNを利用するサイトではIPアドレスが変わることがあり、実際に解決されたアドレスやデータセットの更新状況によってルールの結果も変わります。
GeoSite
ルーティング · ドメイン分類データGeoSite はカテゴリ別に整理されたドメイン照合データで、関連するドメイン群を同じ出力先に振り分ける際に使えます。分類の範囲は使用するデータセットによって異なり、Webサイトのリアルタイムな状態を検知するものではありません。1つのページが複数の異なるドメインを利用する場合があるため、メインのドメインにルールが一致しても、画像、ログイン、メディアの通信が同じ経路を通るとは限りません。
ルーティング
ルーティング · 条件に応じた経路選択ルーティングでは、ルールに応じて接続ごとに異なる経路を使います。たとえば、LAN内のアドレスは直接接続し、指定したドメインにはプロキシを使います。速度測定後にノードを選ぶ機能とは異なり、すべての接続が自動的に高速化するわけではありません。まず明確なデフォルトの方針を設定し、例外を少しずつ追加したうえで、アクセス結果とログからルールの適用状況を確認しましょう。
ネットワークの基礎
テスト結果が示すのは、特定の経路と条件での状態です。接続、名前解決、スループットをそれぞれ確認し、1つの指標だけで全体を判断しないようにしましょう。
レイテンシ
ネットワークの基礎 · 応答時間レイテンシはテスト要求を送ってから応答を受け取るまでの時間ですが、測定ツールによって対象となる経路は異なります。ICMPによる測定、TCP接続の確立、プロキシ経由のWebアクセスは同じ指標ではありません。レイテンシが低くてもダウンロード速度が速いとは限らず、継続的な転送速度は帯域幅、混雑状況、サーバー負荷、接続先の状態にも左右されます。
実接続レイテンシ
ネットワークの基礎 · プロキシ経由のリクエストテスト実接続レイテンシは通常、選択したプロキシ設定でテスト先に実際のリクエストを送り、応答までの時間を測定した値です。具体的な計測範囲は実装によって異なります。単にポートへ接続できるか調べるより実際の利用状況に近い指標ですが、テスト先の状態にも左右されます。タイムアウトの原因はDNS、認証、ハンドシェイク、接続先への到達不能などが考えられるため、ログも併せて確認してください。
FakeDNS
ネットワークの基礎 · 合成アドレスのマッピングFakeDNS はドメイン名に合成IPアドレスを返し、ドメイン名とIPアドレスの対応関係を保持します。これにより、後続の接続でプロキシコンポーネントが元のドメイン名を復元できます。合成アドレスはWebサイトの実サーバーのアドレスではなく、連携するコンポーネントで処理する必要があります。DNSクエリと接続トラフィックが異なる経路を通るとマッピングを利用できず、名前解決は成功してもアクセスに失敗することがあります。
DNS漏れ
ネットワークの基礎 · 想定と異なるDNS経路DNS漏れとは一般に、接続はプロキシ経由なのにDNSクエリは従来のリゾルバーに送られるなど、ドメイン名の問い合わせが想定した経路で処理されない状態を指します。システムDNS、クライアントのDNS、ブラウザー内蔵の暗号化DNSはそれぞれ個別に動作する場合があるため、分けて確認してください。重要なのはクエリが実際にどこを通るかであり、ローカルで名前解決するものをすべて異常とみなす必要はありません。