V2Ray 設定ファイルリファレンス

本ページとチュートリアルの役割分担

本ページは V2Ray 設定ファイルの体系的なリファレンスマニュアルで、config.json をトップレベル構造から各機能セクションの書き方まで、フィールド単位で解説します。サイト内には別途クイックスタートガイドがあり、そちらのメインラインは「サブスクリプションをクライアントにインポートし、モードを選び、接続して、使えることを確認する」という一点だけを扱います。役割分担は明確です。チュートリアルは「次にどこをクリックするか」に答え、本ページは「このフィールドは何を意味し、どんな値を書けば有効で、間違えるとどうなるか」に答えます。すでに正常に接続でき、日常的に使うだけのユーザーは、本ページを読み通す必要はありません。

設定ファイルの経路内での位置づけ

3 つのクライアントはいずれもグラフィカルなフロントエンドにすぎず、実際に接続を確立するのは内蔵されたコアです。v2rayN デスクトップ版は Xray コアを内蔵し、v2rayNG は Xray、v2flyNG は V2Fly コアを使用します。画面上でチェックした項目——転送方式、TLS、多重化、分流スイッチ——は最終的に 1 つの JSON 設定に変換されます。コアは起動時にこの JSON を読み込み、inbounds に従ってローカルポートを待ち受け、outbounds に従ってトラフィックを送り出します。この変換関係を理解しておけば、トラブル時に「画面のオプション選択が間違っているのか、生成された設定自体に問題があるのか」をまず切り分けられます。

3 つのクライアントの手動編集サポート

v2rayN はノード編集ウィンドウに完全な JSON 編集入口を用意しています。サブスクリプションからインポートしたノードはまず内部構造に解析され、その後クライアントが現在の設定に従って設定を再生成します。v2rayNG はカスタム設定とサブスクリプションのインポートに対応していますが、モバイルで長い JSON を編集するのは不便なため、デスクトップで整えてからインポートするのが一般的です。v2flyNG と v2rayNG の設定フォーマットは同源で、違いはコアファミリーにあります。3 つのクライアントのダウンロード入口はクライアントの入手ページに、横断的な違いは比較レビューにまとめています。

推奨の読む順序

設定ファイルに初めて触れるユーザーは、まず第 2 章の構造概要を読んで「トップレベルにどんなセクションがあり、どの 2 つが必須か」という全体像をつかんでください。その後は必要に応じて各章へ飛べば十分です。日常利用で登場頻度が最も高いのは outbounds、routing、dns の 3 つです。outbounds はトラフィックの出口、routing はどのトラフィックをどのアウトバウンドへ送るか、dns はドメインをどこで解決するかを決めます。policy はチューニング項目で、デフォルト値のままでもほとんどの場面で十分です。メモリ使用量や接続の回収時間を制御したいときだけ詳しく見てください。

フィールドとコアバージョンの関係

設定フォーマットはコアのバージョン間で少しずつ進化しており、新しい転送方式や新しいセキュリティタイプは通常 Xray 側で先に実装され、V2Fly 側が後を追います。本ページの例は汎用フィールドを中心にしており、特定のバージョン番号には依存しません。あるフィールドが現在のクライアントで使えるかどうかを判断する最も確実な方法は実行ログを見ることです。コアが認識しないフィールドは起動ログでエラーになるか無視のヒントが出るのであって、黙って有効になることはありません。

サンプル値について

本ページのすべての設定スニペットで使われているドメイン、UUID、公開鍵は、明らかに置き換えが必要と分かるサンプル表記です。実際の設定にそのままコピーしないでください。ノードのパラメータはサービス提供元の情報に従ってください。ページ上部のセクションバーから任意の章へジャンプできます。各章は小節単位で展開し、表はフィールドの早見用、コードブロックは完全なスニペット用、背景色付きのヒントブロックはつまずきやすいポイント用です。

トップレベルにあるセクション

完全な設定ファイルは 1 つの JSON オブジェクトです。トップレベルでよく使われるセクションは 9 つあります。log はログ、inbounds はローカルの待ち受け入口、outbounds はトラフィックの出口、routing は分流ルール、dns は名前解決ポリシー、policy は接続とバッファのポリシー、stats と api はグラフィカルクライアントが動作状態を読み取るためのもの、reverse はリバースプロキシ用途です。このうち inbounds と outbounds は必須の 2 セクションです。インバウンドがなければアプリのトラフィックは入ってこられず、アウトバウンドがなければトラフィックを送り出せません。

以下の最小構成は必須項目とログセクションだけを残したもので、構造の理解には使えますが、直結のみでプロキシ機能はありません:

フィールド命名と構文のルール

JSON の構文は非常に厳格で、設定ファイルで最もよくある起動失敗は以下の項目に起因します。フィールド名は大文字小文字を区別するため、outbounds を outBounds と書いたり、streamSettings を streamsettings と書いたりすると解析に失敗します。標準の JSON ではコメントが許可されていないため、Web ページやメモから設定をコピーする際は、行内の二重スラッシュコメントやブロックコメントを必ず削除してください。末尾カンマも許可されず、配列やオブジェクトの最後の要素の後にカンマが 1 つあるだけでエラーになります。文字列は必ず二重引用符で囲み、一重引用符は使えません。ポートやタイムアウトなどの数値は引用符を付けずそのまま数字で書きます。ブール値は小文字の true と false のみです。

tag の役割

各インバウンド・アウトバウンドには tag フィールドを付けられます。tag は任意の文字列で、routing ルールは tag を通じて特定のインバウンドやアウトバウンドを参照します。たとえば「socks-in からのトラフィックは proxy アウトバウンドへ」といった具合です。tag には socks-in、http-in、proxy、direct、block のような読みやすい名前を推奨します。数か月後に設定を見返したときにも対応関係が分かるからです。同じ設定内で tag を重複させないでください。重複するとルールの参照先が曖昧になります。

読み込みと反映の仕組み

コアは起動時に設定を一度だけ読み込みます。設定を変更した後はコアの再起動かリロードのトリガーが必要ですが、グラフィカルクライアントでは通常ノード保存後に自動で行われます。設定エラーには 2 つの現れ方があります。1 つは解析失敗で、コアがそのまま終了し、ログにエラー箇所が示されます。もう 1 つはフィールドは有効でも意味が矛盾しているケースで、コアは起動できても接続動作が期待と異なります。たとえばルーティングルールの順序が逆になっていて分流が効かない、といった具合です。前者は特定しやすく、後者はログと照らし合わせながらセクション単位で切り分けるしかありません。

サブスクリプションとの関係

サブスクリプション内の各ノードは最終的にこのような設定へ展開されます。クライアントはノードごとに独立した outbounds エントリを生成し、さらにインバウンド・ルーティング・DNS の各セクションを補って、コアが読める完全なファイルに組み上げます。そのためサブスクリプション更新時には設定全体が再生成され、手動で変更したフィールドは上書きされます。この点は後半のクライアントの章で詳しく説明します。

設定ファイルの保存場所はクライアントによって異なります。デスクトップ版は通常プログラムディレクトリかユーザー設定ディレクトリの下にあり、Android 版はアプリ内部で管理されます。日常利用でパスを気にする必要はなく、バックアップや移行のために設定をエクスポートするときだけ探せば十分です。

インバウンドの役割

インバウンドはコアがローカルで何を待ち受けるかを記述するもので、アプリのトラフィックがコアに入る入口です。グラフィカルクライアントは通常 2 つを自動生成します。socks インバウンドはブラウザやシステムプロキシ用、http インバウンドは HTTP プロキシしか使えないプログラム用です。両者は別々のポートを待ち受けるので同時に存在できます。以下はスニッフィング設定を含む 2 インバウンド構成です:

フィールドごとの説明

sniffing が必要な理由

アプリが socks 経由で宛先アドレスを渡すとき、ドメインではなく IP が渡されることがあります。宛先が IP 形式で現れると、routing 内のドメインベースのルールはすべて無効になり、分流も当然ながら正確になりません。sniffing を有効にすると、コアは TLS ハンドシェイクの SNI や HTTP リクエストヘッダーの Host から実際のドメインを抽出し、そのドメインでルーティングルールを照合します。destOverride には上書きを許可するプロトコル種別を列挙します。よく使うのは http と tls です。routeOnly を true にすると、抽出したドメインはルーティング判定にのみ使われ、実際のリクエストの宛先アドレスは書き換えられません。元のリクエスト形式を保ちたい場面に適しています。デスクトップ版・モバイル版のクライアントはいずれもデフォルトでスニッフィングを有効にしています。

dokodemo-door の説明

dokodemo-door はもう 1 種類のインバウンドで、あるローカルポートで受け取ったトラフィックを指定した宛先へそのまま転送する役割を持ちます。LAN 内のデバイスや特定の固定ポートへのリクエストをコアに取り込む際によく使われます。グラフィカルクライアントに対応するスイッチはなく、手書き設定の範疇で、address と port を自分で指定する必要があります。

待ち受けアドレスのセキュリティ境界

listen を 127.0.0.1 にすると、このポートにアクセスできるのはローカルだけです。これがデフォルトの動作です。0.0.0.0 に変更すると、同じネットワーク上の他デバイスがこのマシンをプロキシとして直接指定できるようになります。プロキシを共有したい場面には適しますが、信頼できるネットワーク環境が前提です。グラフィカルクライアントでは通常「LAN からの接続を許可する」というオプションが対応します。有効にする前にこの点を確認してください。プロキシポート自体に認証がない場合、そのポートに到達できるデバイスは誰でもそのまま利用できます。

outbounds(アウトバウンド)

アウトバウンドの役割

アウトバウンドは、トラフィックがコアを離れた後の経路を決めます。outbounds は配列で、複数のエントリを持て、それぞれに独自の tag を付けられます。配列の先頭がデフォルトアウトバウンドで、どのルーティングルールにも一致しなかったトラフィックがここを通ります。以下は VLESS アウトバウンドの例で、転送層に TCP と REALITY を組み合わせています:

サーバーパラメータ

vnext 配列はリモートサーバーを記述し、各項目に address、port、users が含まれます。address にはドメインでも IP でも書けます。port はサーバー側の待ち受けポートです。users の id は身元識別子で、VMess と VLESS はいずれも UUID 形式を使います。VLESS の encryption フィールドは none 固定で、暗号化は転送層が担当します。VMess の alterId は新しいバージョンではデフォルト 0 です。古いノードで非ゼロ値が要求される場合、間違って記入すると接続に失敗します。flow は VLESS のフロー制御オプションで、転送層のセキュリティタイプと組み合わせて使います。tcp 転送と TLS または REALITY の組み合わせでは、xtls-rprx-vision が一般的な記述です。

転送層パラメータ

以下は WebSocket と TLS を組み合わせた転送層の記述です。上記の REALITY の例と同じ階層にあり、streamSettings のセクションごと置き換えるだけで使えます:

VMess アウトバウンドとの違い

VMess アウトバウンドの構造は VLESS と同じで、違いは users 内のフィールドにあります。VMess は alterId と security の 2 つのフィールドで暗号化方式を記述し、前者は新しいバージョンではデフォルト 0、後者は auto が一般的な記述です。転送層のパラメータは VLESS と完全に共通で、同じサーバーが両方のプロトコルを提供している場合、切り替え時に変更が必要なのは protocol と users の 2 か所だけです。VMess と VLESS の認証と転送依存における違いについては、プロトコル解説で 4 つの観点から比較しています。

mux 多重化

mux は多重化のスイッチです。有効にすると、コアは複数の接続を 1 本の下位接続にまとめ、ハンドシェイクの繰り返しを減らします。ネットワークが安定した回線では遅延を抑えられますが、その代わり個々の接続の品質が互いに影響し合い、大容量ファイルのダウンロードのような継続的な高スループットの場面ではかえって遅くなることがあります。クライアントではデフォルトで無効なので、必要に応じて有効にしてください。

freedom と blackhole

freedom は直結アウトバウンドで、受け取ったものをそのまま送り出します。ルーティングルールと組み合わせて中国本土のドメインやプライベートアドレスを処理するのによく使われます。sendThrough フィールドがあり、ローカルのどのアドレスから送信するかを指定できます。blackhole は破棄用アウトバウンドで、特定のトラフィックを遮断するために使い、返す内容も設定できます。どちらもサーバーパラメータは不要で、tag を 1 つ書くだけで使えます。

routing ルーティングルール

ルールの適用の仕組み

routing はどのトラフィックをどのアウトバウンドへ送るかを決めます。構造は domainStrategy と rules の 2 つで構成されます。ルールは上から順に照合され、最初に一致したルールが適用されて以降のルールは判定されません。つまりルールの順序は数よりも重要です。rules 配列の各項目はオブジェクトで、type は field 固定、残りのフィールドが一致条件と一致後の動作を記述します。

domainStrategy の 3 つの値

ルールの条件フィールド

ドメイン照合の 4 つのプレフィックス

以下はそのまま使える分流スニペットです。プライベートアドレスと中国本土のドメインは直結、UDP 443 ポートは遮断、残りのトラフィックはデフォルトアウトバウンドへ送ります。

順序を逆にしたときの典型的な結果

順序を逆にした例を挙げます。1 番目のルールに「すべてのトラフィックを proxy へ」、2 番目に「中国本土のドメインは直結」と書いた場合、1 番目ですべてのトラフィックが一致してしまうため、2 番目は永遠に判定されず、分流の効果はゼロです。正しい書き方は、具体的な条件を前に、広い条件を後ろに置き、最後にフォールバックルールを追加する形です。順序の問題を調べるときは、ログレベルを一時的に debug にすると、コアが接続ごとの一致結果を出力するので、どのルールに一致したかを直接確認できます。

geosite と geoip のデータ

geosite:cn、geoip:private といった記法は、クライアント内蔵またはダウンロードしたルールデータファイルに依存します。データには更新サイクルがあり、新しく登場したドメインはまだ収録されていないことがあります。その場合、一部のサイトで分流結果が期待と異なります。グラフィカルクライアントは通常、ルーティング設定にデータ更新の入口があるので、定期的に一度更新すれば十分です。プライベートアドレス帯のデータはほとんど変化しないため、頻繁な更新は不要です。

balancer の概要

balancer は複数のアウトバウンド間でトラフィックを分散するためのもので、ルール内では balancerTag で参照します。事前に balancer セクションを定義し、selector で tag のプレフィックスによりアウトバウンドを選び、分散戦略を指定する必要があります。一般ユーザーが使う機会はほとんどなく、等価なノードを複数運用する場合にのみ必要になります。

dns 設定

dns セクションを書く場合と書かない場合の違い

dns セクションはコアがドメインをどう解決するかを決めます。このセクションを書かない場合、コアは解決をシステムに任せます。書いた場合は、設定内のサーバーリストとポリシーに従ってコア自身がクエリを発行します。書く価値は 3 つあります。解決結果が中間経路で妨害されるのを防ぐ、ドメインベースの分流がより正確になる、余分な解決の往復を 1 回減らせる。以下はよく使うフィールドの完全な記述です:

hosts の用途

hosts は静的マッピングで、ドメインを固定 IP に直接向け、解決のステップを省けます。適するのは 2 つの場面です。ノードのドメインが既知で安定しており、解決をスキップしたい場合。テスト環境で特定のドメインを指定アドレスに固定したい場合。記法は domain:、full:、keyword: プレフィックスに対応し、ルーティングルールのドメイン記法と完全に同じなので、別途覚える必要はありません。

queryStrategy の選び方

queryStrategy は優先して解決するアドレスファミリーを制御します。UseIP は制限なしで、サーバーが返した順序に従います。UseIPv4 と UseIPv6 はそれぞれ対応するアドレスファミリーのみを保持します。IPv4 の出口しかない環境で UseIPv4 を書くと、IPv6 アドレスが解決された後に接続できずリトライする事態を避けられ、失敗の往復を 1 回減らせます。逆に、ローカルネットワークがすでに IPv6 中心なら、UseIPv6 を書くことで不要なデュアルスタックのクエリを減らせます。

ルーティングとの連携

DNS クエリはコア自身が発行し、outbounds のプロキシ経路を通りません。そのため解決専用のルーティングルールを書く必要はありません。注意すべきは、解決結果がルーティングに影響することです。IPIfNonMatch を有効にしていると、ドメインはまず IP に解決されてから IP ルールで照合されるため、解決結果が不正確だと IP ルールも連動して不正確になります。これが dns セクションと routing セクションを合わせて見るべき理由です。

モードごとに誰が解決するか

デスクトップ版でシステムプロキシを使う場合、ドメイン解決は引き続き OS が行い、コアの dns セクションはコア自身が解決する必要があるときだけ機能します。TUN モードを有効にすると、コアが DNS リクエストを含むすべてのトラフィックを引き受けます。Android の v2rayNG は VpnService 経由で動作するため、同様に DNS クエリを引き受けます。つまり同じ dns 設定でも、クライアントやモードによって実際に影響する範囲は異なります。効果を判断する前に、現在どのモードなのかを確認してください。

policy ポリシー

policy を書く必要があるとき

policy は接続のライフサイクルとバッファサイズを制御するチューニング項目です。デフォルト値のままで通常利用には十分ですが、書く典型的な場面は 3 つあります。メモリ使用量を下げる、アイドル接続の回収を早める、インバウンドごとに異なる制限を設ける。以下はよくある記述です:

levels の使い方

levels のキーはレベル番号で、0 がデフォルトレベルです。インバウンドの settings やユーザー設定で level フィールドを指定すると、特定のインバウンドやユーザーを特定のレベルに割り当て、入口ごとに制限をかけられます。日常利用では 0 の段だけ変更すれば十分で、入口ごとに異なるレベルを割り当てるのはマルチユーザー環境での方法です。

system セクション

system セクションは統計のスイッチを制御します。statsInboundUplink と statsInboundDownlink を有効にすると、コアがインバウンド方向の上り・下りトラフィックを集計し、グラフィカルクライアントの速度表示はこのデータに依存します。statsOutboundUplink と statsOutboundDownlink はアウトバウンド方向に対応します。統計を無効にするとわずかなオーバーヘッドを節約できますが、その代わり画面上のトラフィック数値が更新されなくなります。

チューニングのトレードオフ

connIdle を小さくするとアイドル接続が早く回収され、メモリ使用量も下がりますが、その代わり再び使うときに接続を張り直す必要があり、体感ではハンドシェイクの遅延が 1 回増えます。bufferSize は大きくすると高帯域の場面で役立ち、小さくするとメモリを節約できます。handshake、uplinkOnly、downlinkOnly は通常調整不要で、ネットワーク品質が悪くハンドシェイクが頻繁にタイムアウトする環境でのみ handshake を緩めることを検討してください。

モバイルでの特殊事情

モバイルでバックグラウンド接続がシステムに回収されるのは、通常 policy とは関係なく、省電力ポリシーが働いているためです。関連する対処法はv2rayNG の使用ポイントで説明しています。チューニングの前提は安定した基準を持つことです。デフォルト設定を 1 つ保存しておき、変更後は項目ごとに比較して、効果が本当にあると確認できたものだけ残すことをおすすめします。ネット上で流れているパラメータの組み合わせは特定のハードウェアや場面を前提にしたものが多く、そのまま真似しても改善につながらないことがあります。

クライアントでの設定生成と手動編集

サブスクリプションが設定に展開される仕組み

サブスクリプション URL が返すのはエンコードされたテキストで、クライアントはダウンロード後に 1 行ずつ解析します。各行が 1 つのノードの完全なパラメータを記述しており、そのパラメータを outbounds の 1 エントリに変換します。サブスクリプション内のノード数は outbounds 配列の長さに対応し、サブスクリプション更新時には設定全体が再生成されます。この流れを理解すれば、画面で変更したノードが更新後に元に戻る理由も分かります。

共有リンクのパラメータと設定フィールドの対応

v2rayN の編集入口

v2rayN のノードリストの右クリックメニューに編集入口があり、ウィンドウは基本フィールドと転送フィールドでグループ分けされています。クライアント画面に露出していないフィールドを変更したい場合は、パラメータ設定から完全な設定の編集入口を開けます。注意すべきは、サブスクリプション更新がノードリストをサブスクリプション単位で丸ごと置き換える点です。手動で変更したノードは次回更新で上書きされます。長期的に残したい調整は、独立したノードとして別途保存するか、先にエクスポートしてバックアップすることをおすすめします。

v2rayNG の設定ソース

v2rayNG のノードの入手元は 3 つあります。QR コードのスキャン、クリップボードからの共有リンクのインポート、サブスクリプションのインポートです。モバイルで長い JSON を編集するのは不便なので、デスクトップで整えてからインポートするのが一般的です。アプリごとのプロキシは設定でアプリ単位にチェックを入れますが、これはどのアプリのトラフィックを VpnService に通すかだけを決めるもので、JSON 設定自体とは関係ありません。つまり、アプリごとのプロキシのルールは config.json には現れません。

v2flyNG の位置づけ

v2flyNG と v2rayNG の設定フォーマットは同源で、違いはコアファミリーにあります。同じノードのパラメータはどちらでも使えます。あるコアバージョンが特定の転送方式への対応で差がある場合、代替クライアントを比較対象として使えます。3 つのクライアントのプラットフォームとバージョンの入口はクライアントの入手ページにあります。

手動で設定を変更する価値があるケース

手動変更に値する場面は 3 つあります。クライアント画面に露出していないフィールドを使いたい場合(カスタムルーティングルールや bufferSize など)。アプリ単位やポート単位で個別に分流したい場合。トラブル調査で最小構成を使って再現したい場合。前の 2 つはデスクトップで行い、変更後にエクスポートしてモバイルへ同期することをおすすめします。3 つ目の場面では、手書きの設定は短ければ短いほどよく、問題の再現に必要なセクションだけを残してください。

サブスクリプションフォーマットの詳細

サブスクリプションにはよくある 3 つの形態があります。base64 エンコードされたリンクリスト、ネイティブな JSON 設定、単一の共有リンクです。3 者の違いと変換時にフィールドが欠落しやすい箇所は、サブスクリプションフォーマット解説で項目ごとに比較しています。インポートに失敗したときは、まずサブスクリプションがどの形態を返しているかを確認し、それからどの入口でインポートするかを決めてください。