クライアント一覧 / 設定項目ガイド
OSに合わせてオープンソースクライアントを選び、サブスクリプションのインポートから config.json の項目まで、設定と読み込みの流れを確認できます。
まずOSを選び、プロセッサのアーキテクチャとインストール形式を確認します。デスクトップではv2rayN、Androidではv2rayNGが主な選択肢です。V2Flyコアが必要な場合はv2flyNGを検討してください。
v2rayNにはDesktop版と従来のWPF版があります。Desktop版はクロスプラットフォームのUIを採用し、WPF版はおなじみのデスクトップ操作画面を維持しています。どちらもOSとプロセッサの要件を確認してからインストーラーを選びましょう。ファイルサイズだけで対応状況を判断しないでください。
初回インストール後は、サブスクリプションまたは接続情報をインポートし、設定を選んでコアを起動してからシステムプロキシを設定します。システムプロキシが適用されるのは、システム設定に従うアプリです。すべてのプログラムの通信が自動的にルーティングされるわけではありません。より多くのアプリを対象にする場合は、TUNの説明も確認してください。
v2rayNはApple SiliconとIntelでダウンロード先が異なります。システムの「このMacについて」でチップまたはプロセッサ情報を確認し、対応するアーキテクチャを選んでください。チップとインストーラーのアーキテクチャを一致させる必要があります。外観や製造年だけで判断しないでください。
インストール後、まずクライアントを起動して設定をインポートし、次にシステムのネットワークプロキシを確認します。一部のアプリだけ接続できる場合は、アプリがシステムプロキシに従うか、ルーティングで想定した出力先が選ばれているか、ドメイン名が正しい経路で解決されているかを個別に確認してください。再インストールを繰り返す必要はありません。
v2rayNGはXrayコア、v2flyNGはV2Flyコアを使用します。対応するコアの動作が必要な設定では、それぞれを選択してください。比較的新しい端末では通常arm64を選びます。プロセッサのアーキテクチャが分からない場合は、汎用パッケージの対応範囲を確認してください。設定の互換性は、どちらのクライアントでも項目ごとに確認が必要です。
接続を開始すると、システムからVPN接続の許可を求められます。これはAndroidクライアントが通信を扱うためのシステム機能であり、サーバーへの接続が確立したことを意味するものではありません。初回接続時はクライアントのログを確認し、アプリごとのプロキシ設定もチェックしてください。同じシステム機能を使うアプリが競合する場合があります。
v2rayNには、各種ディストリビューションに対応したパッケージがあります。Debian・Ubuntu系では通常deb、Fedoraなどではrpmを使います。プロセッサはx64とarm64を区別してください。パッケージ形式はインストール方法、アーキテクチャは実行ファイルの互換性に関わるため、両方の確認が必要です。
デスクトップ環境、システムプロキシ、自動起動はそれぞれ別の設定です。まずGUIから手動で接続できることを確認し、その後にログイン時の自動起動を設定しましょう。プログラムは起動するのにアプリが接続できない場合は、デスクトップのプロキシ設定とアプリ側のプロキシ設定を確認してから、権限や依存関係を調べてください。
クライアントはローカルの設定と接続を管理します。実際に接続するには、有効なサーバー情報が別途必要です。プログラムをダウンロードしてインストールしても、サブスクリプションやリモートアカウントは自動作成されません。
クライアント一覧を見る →画面上の操作から、実際の設定内容を確認します。以下はデータの流れを説明する一部の例です。クライアントの管理項目とコアの設定項目を分けて解説しており、接続設定全体を示すものではありません。
サブスクリプションのインポートでは、接続情報をまとめて保存します。更新URLはクライアントが管理するデータであり、共通のconfig.jsonにあるトップレベル項目ではありません。v2rayN、v2rayNG、v2flyNGではメニューや保存方法が異なりますが、インポート後はプロトコル、アドレス、通信設定を確認してください。以下は項目を選択した後に併用できるローカルSOCKSインバウンドの例で、サブスクリプションファイルではありません。待ち受けをループバックアドレスに限定すると、ローカルアプリの通信を指定ポート経由でコアに渡せます。サブスクリプションを更新しても、自分で管理するルーティングルールは上書きされません。
{
"inbounds": [
{
"tag": "local-socks",
"listen": "127.0.0.1",
"port": 10808,
"protocol": "socks",
"settings": {
"udp": true
}
}
]
}ルーティングでは、接続先ごとに異なる出力先を選択します。リモート接続のパラメータを定義し直す機能ではありません。ルールは上から順に照合されるため、具体的なルールを広範なルールより前に配置してください。この例では、プライベートアドレスの出力先にdirectというタグを指定しています。このタグはoutboundsにも存在する必要があります。v2rayNでは画面からルーティングを管理できますが、Androidクライアントではプリセットやカスタム設定の方法が異なります。変更後は設定を再読み込みし、ログで宛先アドレスと出力タグを確認してください。ドメイン名がまだ解決されていない場合、IPアドレスだけを指定したルールでは期待どおりにならないことがあります。
{
"routing": {
"domainStrategy": "IPIfNonMatch",
"rules": [
{
"type": "field",
"ip": ["geoip:private"],
"outboundTag": "direct"
}
]
},
"outbounds": [
{
"tag": "direct",
"protocol": "freedom",
"settings": {}
}
]
}TUNは仮想ネットワークインターフェースで通信を受け取り、通常はシステムプロキシに従わないアプリへの対応に使います。v2rayNの実装や権限、使用コンポーネントは環境によって異なります。AndroidクライアントはシステムのVPNインターフェースを使うため、デスクトップの設定をそのまま適用することはできません。すべてのコアで共通して使える、汎用V2Ray設定のトップレベルtunスイッチはありません。以下は通信を取り込んだ後に使えるdirectとblockの出力例で、仮想ネットワークインターフェースを作成するものではありません。有効にする前に、他の通信取り込みソフトとの競合がないか確認し、システムのネットワーク設定を元に戻す方法も用意してください。
{
"outbounds": [
{
"tag": "direct",
"protocol": "freedom",
"settings": {}
},
{
"tag": "block",
"protocol": "blackhole",
"settings": {}
}
]
}DNSを設定する際は、問い合わせ元、問い合わせに使う接続経路、名前解決の結果をルーティングにどう使うかを確認してください。コアのdnsセクションを設定しても、すべてのアプリのシステムDNSが自動で置き換わるわけではありません。この例ではlocalhostを使ってローカルの名前解決経路を呼び出しています。サーバー一覧の構造を示す例であり、あらゆるネットワーク環境に適用できる設定ではありません。v2rayNやAndroidクライアントには、リモートDNS、仮想アドレス、通信取り込みに関する追加設定がある場合があります。変更時は実際に生成された設定を確認してください。ドメイン名では接続できずIPアドレスでは到達できる場合、まず名前解決とルーティングのどちらに問題があるか切り分けましょう。
{
"dns": {
"servers": [
"localhost"
]
}
}複数コアの切り替えはクライアントの機能であり、config.jsonに共通の切り替え項目があるわけではありません。v2rayNでは対応状況に応じてコアを選択できます。v2rayNGはXray、v2flyNGはV2Flyを使用します。設定構造が似ていても、プロトコル、通信方式、拡張項目のすべてに互換性があるとは限りません。切り替える前にサーバー側の要件を確認してください。以下のpolicy例はユーザー単位のポリシー設定です。実際に適用されるかは、対象ユーザーが該当するlevelを使用しているかによります。移行時は動作中の設定を残し、項目ごとにテストしてください。コアとルーティングを同時に変更するのは避けましょう。
{
"policy": {
"levels": {
"0": {
"handshake": 4,
"connIdle": 300
}
}
}
}プロジェクトのエコシステム、通信コア、GUIクライアントを区別して理解しましょう。プロトコルは通信する両端で合意して使います。クライアントは設定をコアに渡して実行します。名称が似ていても、設定をそのまま置き換えられるとは限りません。
プロトコル名は設定要件を確認する手がかりです。どのコアでも任意のプロトコルと通信方式を組み合わせて使えるという意味ではありません。
Project Vは、V2Rayの技術的な背景を知るための出発点です。プロキシコアはインバウンド、アウトバウンド、ルーティングを組み合わせて通信を処理し、GUIクライアントはサブスクリプション一覧やシステムプロキシ、設定画面を提供します。V2FlyはV2Ray関連の開発を引き継ぎ、Xrayは独自に発展したコアの系統です。共通する概念もありますが、その後の機能や設定の進化は完全には一致していません。資料を読む際は、タイトルにV2Rayとあるかだけでなく、対象のコアも確認してください。
VMess、VLESS、Trojanは接続プロトコル、TCPやWebSocketは通信方式、TLSは通信のセキュリティ設定に関するものです。それぞれのレイヤーを組み合わせて考える必要があり、プロトコル名だけでは設定全体を表せません。コアを選ぶ前に、サーバーから指定されたプロトコル、通信方式、セキュリティ設定、拡張要件を確認し、クライアントが対応する項目を生成できるか調べてください。互換性に問題がある場合は、クライアントのインストール失敗と決めつけず、該当する設定項目を特定しましょう。
v2rayN、v2rayNG、v2flyNGはいずれもオープンソースのGUIクライアントで、各クライアントプロジェクトはGPL-3.0ライセンスを採用しています。コア、ルールデータ、同梱コンポーネントにはそれぞれ別のライセンスが適用される場合があり、クライアントのライセンス表記だけで依存関係全体を説明することはできません。オープンソースなら実装を読んで設定を理解できますが、サーバーの提供元、サブスクリプションの利用権限、システム権限の確認に代わるものではありません。サブスクリプションURLに認証情報が含まれることがあるため、スクリーンショットやログを共有する前に機密情報を削除してください。
クライアント、コア、サブスクリプション、ルールデータの更新はそれぞれ別の操作です。クライアントの更新は画面や設定生成方法、コアの更新は項目の対応状況や接続動作、サブスクリプションの更新は接続情報、ルールの更新は照合対象に影響します。環境を変更する前に、動作中の設定とカスタムルールを保存し、一度に変更するのは一つの要素にしましょう。完了後に設定を再読み込みし、ドメイン名の解決、直接接続、プロキシ接続をそれぞれテストすると、変更の影響を特定しやすくなります。
インストール後は、まずクライアントが起動することを確認し、次にサブスクリプションの各項目に必要なパラメータが揃っているか、ローカルプロキシが有効か、ルーティングとDNSが正しいかを順に確認します。ログのエラーは発生箇所によって対処が異なります。待ち受けに失敗した場合はポートの使用状況、ハンドシェイクに失敗した場合は接続先のプロトコルとセキュリティ設定、ドメイン名の解決に失敗した場合はDNSの経路を確認してください。すべての設定を一度に変えるより、段階ごとに確認するほうが、動作中の状態を保ちやすくなります。
用語を確認するには用語集、画面に沿って操作するには入門ガイド、項目の階層やJSON構造を確認するには設定項目ガイドを参照してください。例にあるポート、タグ、ポリシーは構造を示すものです。実際に使う前に、端末の設定とサーバー情報に合わせてください。
具体的な疑問に沿って解説します。まず設定の構造を理解し、次に名前解決の経路とプラットフォームごとの導入を確認してください。記事中の設定例は、使用するクライアントとコアに合わせて判断する必要があります。
Debian、Ubuntu、Fedora系ディストリビューションへのデスクトップ版の導入方法を解説します。パッケージ形式やアーキテクチャの選び方、自動起動、よくある依存関係の問題を紹介。ソフトウェアのインストール、デスクトップでの起動、ネットワークプロキシを分けて確認します。
記事を読む →トップレベルの構造をもとに、インバウンドの待ち受け、アウトバウンドの接続、ルーティングタグの関係を解説します。JSONの例を見ながらクライアントが生成する設定を確認し、ローカルの待ち受け設定とサーバーへの接続設定を区別できます。
記事を読む →dnsセクションのservers、domains、expectIPs項目を解説し、ローカル・リモートの名前解決とルーティングの関係を紹介します。まず問い合わせ経路を確認し、名前解決の結果が想定どおりかを判断してください。
記事を読む →技術ノートでは個別の問題を解説しています。項目の全体構造と用途は設定ガイドをご覧ください。
記事一覧を見る →