DESKTOP
Windows
v2rayNでサブスクリプションのグループ、ノード選択、システムプロキシ、ルーティングルールを管理できます。ダウンロードページでは新世代のデスクトップUIと従来型WPF UIを用意しています。前者は複数のプラットフォームで同じ操作感を保ちたいユーザーに、後者は従来のWindowsメニューに慣れたユーザーに適しています。インストール後はまずシステムアーキテクチャを確認し、ガイドに沿って初回のサブスクリプション更新を行ってください。
ダウンロードページへCLIENT ROUTING / 日本語設定ドキュメント
v2rayN・v2rayNGのクライアント情報、サブスクリプション登録手順、ルーティングのトラブル対処をまとめ、デスクトップとモバイルの実際の画面に沿って設定手順を説明します。
LINK INSPECTION
クライアントの接続問題は、単一のスイッチが原因とは限りません。まず設定がクライアントに取り込まれているかを確認し、次にコアが起動できるか、ルーティングが適用されているか、システムの通信がローカルポートに届いているかを判断します。以下では実際の通信経路に沿って確認項目を分け、各項目に対応する画面操作を示します。
INPUT / SUBSCRIPTION
v2rayNのデスクトップ版とv2rayNGのAndroid版は、サブスクリプションURLと単一ノードの共有リンクに対応していますが、入口やグループの考え方、更新操作は完全には同じではありません。インポート後は、ノードが目的のグループに表示されているかを確認し、手動でサブスクリプションを一度更新してから、現在のサーバーとして使用するノードを選択します。URLをサブスクリプション設定に保存しただけでは、ノードがメインリストに追加されたことにはなりません。更新に失敗しても、クライアントを何度も削除するのではなく、URLの完全性、端末時刻、現在のネットワーク、ログの内容を順に確認してください。
このサイトのガイドでは、「サブスクリプションを保存」「グループを更新」「ノードを選択」を独立した手順として説明し、3つの操作を混同しないようにしています。ボタンの場所だけを示す簡単な説明と比べ、入力、解析、選択のどの段階で問題が起きたかを明確にでき、異なるクライアント間で設定を移行する際にも役立ちます。
CORE / PROTOCOL
GUIクライアントはサブスクリプション管理、システムプロキシ、ルーティング編集、ログ表示を担当し、プロトコルのハンドシェイク、転送、アウトバウンド接続を実際に処理するのはコアです。v2rayNはXrayとV2Flyのエコシステムにある設定構造を利用でき、v2rayNGは主にXrayコアを対象とし、v2flyNGはV2FlyベースのAndroid向け選択肢です。クライアントはまずプラットフォームと操作性で選び、続いてノードに必要なプロトコルと転送の組み合わせを対応するコアが処理できるか確認します。
VMess、VLESS、Trojan、Shadowsocksはプロトコル層の選択肢であり、TLS、WebSocket、gRPCなどはセキュリティまたは転送の組み合わせです。プロトコル名だけで設定が完全かどうかを判断することはできません。このサイトのドキュメントでは、アドレス、ポート、ユーザー識別子、転送方式、TLS、serverNameなどの関連フィールドをまとめて示し、1項目だけを変更しても接続できない状況を減らします。
MATCH / OUTBOUND
ルーティングはドメインを単純に2つへ分けることではありません。クライアントがルールの順序に従って宛先ドメイン、宛先IP、プロセス、ポートを確認し、最初に一致した通信をプロキシ、ダイレクト接続、またはブロックのアウトバウンドへ送る仕組みです。広すぎるルールは後続条件を上書きし、狭すぎるルールは同じサービスが使う別のドメインを取りこぼす可能性があります。編集後はルールセットが有効か、指定したアウトバウンド名が存在するかを確認し、ログでリクエストが最終的にどのルールへ一致したかを確認してください。
一般的な検証では、まず最小限のルールを残して基本接続を確認し、その後、LANのダイレクト接続、よく使うサービスのグループ、カスタムドメインを1つずつ追加します。これにより、どの条件グループが結果を変えたのかを特定できます。ブラウザーはアクセスできるのにターミナルのプログラムがアクセスできない場合は、そのプログラムがシステムプロキシを参照しているかも確認し、現象をすぐにルーティングルールの問題と決めつけないでください。
LOG / DIAGNOSIS
クライアントにタイムアウトと表示されても、規定時間内に接続が完了しなかったことしか分からず、サブスクリプションやノードが無効になったと直接証明するものではありません。まずコアが正常に起動したかを確認し、次にDNSが宛先アドレスを返したか、TCP接続、TLSハンドシェイク、プロトコル認証、ルーティング先を順に確認します。段階ごとに対処は異なります。システム時刻のずれは証明書の判定に影響し、serverNameの不一致はTLSに影響し、ポートの競合はローカルプロキシの待ち受けを妨げます。
このサイトのトラブル対処ドキュメントでは、「クライアント起動—ローカルポート—名前解決—リモートハンドシェイク—アプリ接続」の順に確認し、各段階の中止条件も示しています。1段階が正常だと確認してから次へ進めば、複数の設定を同時に変更して新たな変数を増やすことを避けられ、最後に使用できた設定へ戻すことも容易です。
PLATFORM ENTRY
プラットフォームごとにインストール形式と権限モデルが異なります。デスクトップではv2rayNを優先し、Androidではコアの要件に応じてv2rayNGまたはv2flyNGを選択できます。プラットフォーム別の入口からはダウンロードページの該当タブを直接開けます。トップページにはインストーラーへの直リンクを掲載していません。
DESKTOP
v2rayNでサブスクリプションのグループ、ノード選択、システムプロキシ、ルーティングルールを管理できます。ダウンロードページでは新世代のデスクトップUIと従来型WPF UIを用意しています。前者は複数のプラットフォームで同じ操作感を保ちたいユーザーに、後者は従来のWindowsメニューに慣れたユーザーに適しています。インストール後はまずシステムアーキテクチャを確認し、ガイドに沿って初回のサブスクリプション更新を行ってください。
ダウンロードページへDESKTOP
v2rayNのデスクトップ版は、プロセッサーのアーキテクチャに応じたインストール入口を用意しています。システム情報を開けば、Apple SiliconかIntelかを確認できます。アーキテクチャを間違えると、インストーラーが正常に起動しない場合があります。初回起動時にはシステムの案内に従ってアプリを確認し、クライアントで必要なシステムプロキシモードを明示的に有効にしてください。
ダウンロードページへMOBILE
v2rayNGはXrayプロトコルへの対応とアプリごとのプロキシを必要とするユーザーに適しており、v2flyNGはV2Flyコアを選びたい場合の候補です。初回接続時には、ローカルVPNサービスの許可を求められます。この許可はアプリの通信をクライアントに渡すためのものです。バックグラウンド切断を減らすには、システムの省電力設定を確認し、クライアントをバックグラウンド実行の許可リストに追加してください。
ダウンロードページへDESKTOP
v2rayNには、一般的なパッケージ体系に対応したデスクトップ用インストール入口があります。DebianやUbuntuなどではdeb、FedoraやRocky Linuxなどではrpmを選び、x64とarm64のアーキテクチャも区別してください。接続後、ブラウザーは使えるのにターミナルから使えない場合は、プロキシ環境変数を設定するか、適切な通信取り込み方式を利用します。
ダウンロードページへQUICK START
初回設定で、すべての高度な項目を同時に調整する必要はありません。まず最小限の通信経路を確立し、アプリの対象範囲に応じてルーティングと振り分けルールを追加すると、問題が設定、ノード、システムの通信入口のどこにあるかを早く判断できます。
STEP 01 / IMPORT
v2rayNで「サブスクリプショングループ」の管理画面を開き、サブスクリプション名と完全なURLを追加します。保存後にメイン画面へ戻り、更新を実行してください。v2rayNGではサブスクリプション設定を開き、URLを保存してメニューから更新を実行します。更新後はノード数と名前が変化したかを確認し、現在のサーバーとして使用するノードを選択します。リストが空の場合は、更新メッセージとログを先に確認してください。この時点では利用可能なリモート設定がないため、すぐにシステムプロキシ設定へ進まないでください。
STEP 02 / CONNECT
デスクトップでは、まず選択したノードを起動し、ログにローカルプロキシポートの待ち受けが表示されたことを確認してから、利用状況に応じてシステムプロキシを有効にします。ブラウザーやシステムプロキシを参照するデスクトップアプリだけなら、通常はシステムプロキシで十分です。ターミナルツール、特定のアプリ、システム設定を参照しないプログラムには、個別にプロキシ環境変数を設定するか、より包括的な接続方式を使用します。Androidではノードを選択して接続を開始し、システムに表示されるローカルVPNサービスの許可を完了してください。
STEP 03 / VERIFY
接続ボタンが起動済みと表示されても、クライアントの処理が始まったことしか分かりません。次に、実際に通信が必要なアプリを開き、リクエストがクライアントログに表示されるか、ルーティングルールが想定したアウトバウンドを選んだかを確認します。ログにリクエストがない場合は、システムプロキシ、アプリのプロキシ設定、Androidのアプリ別対象範囲を重点的に確認します。リクエストはあるのにハンドシェイクが失敗する場合は、端末時刻、アドレス、ポート、TLS、serverNameなどのノード項目を確認してください。
OPEN ECOSYSTEM
クライアント名、コア名、プロトコル名は同時に登場することが多いものの、それぞれ異なる階層に属します。3者の関係を理解すれば、プラットフォーム、ノード設定、必要な機能に合ったクライアントを選べます。
Project VはV2Rayエコシステムが形成される過程の基盤となったプロジェクトです。V2Ray Coreは、インバウンド、アウトバウンド、ルーティング、DNS、転送、ポリシーなどのモジュールを中心に、組み合わせ可能な設定方式を築いてきました。GUIクライアントはネットワーク機能そのものではなく、設定管理、システム接続、動作状態を操作可能な画面に整理する役割を担います。クライアントで確認できるサーバーアドレス、ポート、ユーザー識別子、転送方式、ルーティングルールは、最終的にコアが読み取れる設定へ変換されます。
この階層構造により、同じサブスクリプションを異なるクライアントへ登録できても、コアの対応範囲、フィールドのマッピング、クライアントの更新時期によって結果が異なる理由が分かります。トラブル対処では、画面で設定が保存されていないのか、サブスクリプションの解析が不完全なのか、コアが特定のプロトコルパラメーターを認識できないのかを区別し、すべてを「ノードが使えない」と判断しないことが重要です。
V2FlyはV2Ray Coreのコミュニティによる保守方針を引き継ぎ、モジュール化されたプロキシ機能、ルーティング、転送の組み合わせに取り組んでいます。Xrayは近い設定体系を基盤に、プロトコルと転送機能をさらに拡張しています。両者にはインバウンド、アウトバウンド、ルーティングルール、DNS、ポリシー設定など共通する概念が多くありますが、対応項目、フィールドの詳細、更新時期は完全には一致しません。サブスクリプションに特定のプロトコルや転送の組み合わせが含まれる場合は、対象クライアントが現在使用しているコアで各フィールドを処理できるか確認してください。
コアの違いがあるからといって、すべてのユーザーが複雑な設定を手動編集する必要はありません。多くの場合、クライアントがサブスクリプションの内容から設定を生成し、対応するコアを起動します。ログで未対応フィールドが示された場合、サブスクリプション変換でパラメーターが欠落した場合、またはカスタムルーティングを記述する場合に限り、コアと設定構造を詳しく確認します。このサイトの関連ガイドでは、どの手順がクライアント画面の操作で、どの判断にコアのログが必要かを明示しています。
LICENSE
v2rayN、v2rayNG、v2flyNGおよび関連コアは、オープンソースプロジェクトとして保守されています。オープンソースライセンスは、コードの利用、変更、再配布に関する基本的な範囲を定めます。コミュニティの参加者は、プロトコル互換性、プラットフォーム対応、UI機能、バグ修正について改善を提案できます。一般ユーザーにとってオープンソースであることの直接的な意義は、クライアントとコアの役割、設定構造、変更に関する議論が公開記録され、単一の閉じたインターフェースだけで挙動が決まらない点にあります。
MAINTENANCE
GUIクライアントとプロキシコアでは、リリースのタイミングが異なる場合があります。クライアントの更新は、通常、画面、サブスクリプション管理、システムプロキシ、プラットフォーム互換性に関係します。一方、コアの更新はプロトコル実装、転送の組み合わせ、ルーティング、DNSの動作に関係することが多いです。新しいプロトコルを認識できない場合は、クライアントが対応する設定を扱えるか、コアに必要な機能が含まれているかを両方確認してください。アップグレード前に既存のサブスクリプショングループとカスタムルーティングを記録しておくと、更新後に設定を項目ごとに復元できます。
SELECTION
デスクトップではv2rayNを優先すると、Windows、macOS、Linuxの設定を近い操作感で管理できます。Androidではv2rayNGが一般的で、V2Flyコアを使いたい場合はv2flyNGを選べます。選択時はクライアント名だけでなく、サブスクリプションのプロトコル、端末アーキテクチャ、システム権限、アプリ別プロキシの必要性も考慮してください。クライアント比較ページでは、3つの位置づけ、対応プラットフォーム、機能上の境界を説明しています。
COMMON CHECKS
以下では、初回インストールと日常利用でよく見られる4種類の症状を取り上げます。各項目ではまず確認の方向性を示し、詳しい手順はクイックスタート、よくある質問、またはトラブル対処ページから確認できます。
URLの保存で完了するのはサブスクリプションソースの登録だけで、サブスクリプションの更新を手動で実行する必要があります。更新後も空の場合は、まずURLに欠落した文字がないか確認し、次にシステム時刻、現在のネットワーク、更新ログを確認してください。エラーによっては、リクエスト失敗、解析失敗、返された内容の形式不一致が直接示されます。何度も登録し直すより、エラーが発生した段階に応じて対処する方が効果的です。
サブスクリプション登録手順を見る →まず、ブラウザーのリクエストがクライアントログに表示されているか確認します。リクエストがない場合は、システムプロキシが有効になっていない、ブラウザーが独自のプロキシ設定を使っている、ローカルの待ち受けポートとシステム設定が一致していない可能性があります。リクエストがある場合は、DNS、ルールの一致、リモートハンドシェイクを確認してください。2つのケースでは対処の方向が異なります。
インターネットに接続できない場合の対処を見る →多くのブラウザーはシステムプロキシを参照しますが、ターミナルのプログラムは独自の設定や環境変数に依存することが多いです。クライアントのローカルHTTPポートとSOCKSポートを確認し、ツールが対応する方法でプロキシ変数を設定してください。より多くのプログラムを対象にする場合は、システムに適した通信取り込みモードを検討します。ブラウザーで使えたからといって、すべてのアプリが接続済みだと判断しないでください。
システムプロキシの対処を見る →基本的な疎通テストで確認できるのはネットワーク条件の一部だけです。完全な接続には、プロトコル認証、TLS、serverName、転送方式、ルーティング先も関係します。実際のリクエストを発生させてコアのログを確認し、名前解決、接続、ハンドシェイク、認証のどの段階で失敗したかを特定してから、該当フィールドを確認してください。多数のノードを続けて切り替えるだけでは解決しません。
よくある質問を見る →RECENT NOTES
最近の記事では、プロトコルの比較、TLS証明書関連のエラー、Androidのバックグラウンド接続設定を扱っています。具体的な症状や設定作業を入口に、確認可能なフィールドと操作順を示します。
暗号化方式、転送オーバーヘッド、偽装性能、コア対応の4つの観点からプロトコルの違いを整理し、家庭用回線、モバイルネットワーク、性能に制約のある端末ごとの選択条件を説明します。プロトコル層とTLS、WebSocketなどの転送層設定を分けて判断できます。
記事を全文読む →TLSエラーでは、まず端末のシステム時刻を確認し、次にserverNameと証明書のドメインが一致しているかを確認します。その後、関連するセキュリティオプションとフィンガープリント設定を確認してください。ハンドシェイクの段階ごとに一般的なエラーを説明し、証明書の問題をノードの無効化と早合点しないための手順をまとめています。
記事を全文読む →初回接続時の許可の役割、システムの省電力設定がバックグラウンド接続に与える影響、アプリ別プロキシにおける「バイパス」と「プロキシのみ」の範囲の違いを説明します。アプリ切り替え後の切断や、バックグラウンドでしばらくすると停止する問題に役立ちます。
記事を全文読む →