Windows
v2rayNでサブスクリプション、サーバー一覧、システムプロキシ、ルーティングルールを管理できます。ダウンロードセンターには新しいデスクトップ画面と従来のWPF画面を掲載しており、使い慣れた方を選択できます。
ダウンロードへクライアントのダウンロードと日本語設定ガイド
v2rayNデスクトップクライアント、Androidクライアント、日本語の設定手順をまとめています。サブスクリプションの読み込みからシステムプロキシ、ルーティング、コアの選択まで、実際の設定項目に沿って各手順の役割を説明します。
プラットフォーム
デスクトップではv2rayNを中心に利用し、Androidではv2rayNGとv2flyNGから選べます。ダウンロードセンターでは、CPUアーキテクチャ、インストール形式、クライアント画面別に入口を案内します。
v2rayNでサブスクリプション、サーバー一覧、システムプロキシ、ルーティングルールを管理できます。ダウンロードセンターには新しいデスクトップ画面と従来のWPF画面を掲載しており、使い慣れた方を選択できます。
ダウンロードへv2rayNのデスクトップ画面でサブスクリプション、プロキシ、ルーティング設定を管理します。ダウンロードセンターでは、Apple SiliconかIntelプロセッサかを確認してから対応パッケージを選んでください。
ダウンロードへv2rayNGはXrayコアを採用し、一般的なプロトコルやルーティング設定に適しています。v2flyNGはV2Flyコアを採用し、異なるコア環境の選択肢になります。主流の端末では通常、arm64アーキテクチャを優先します。
ダウンロードへv2rayNは主要なデスクトップディストリビューション向けのインストール形式を用意し、x64とarm64を区別しています。インストール後は統一画面でサブスクリプション、コア、ルーティング、システムプロキシを管理できます。
ダウンロードへコア設定
機能への入口を実際の設定順に整理しています。下のタブから、各設定の用途、操作手順、混同しやすい境界を確認できます。
サブスクリプション管理
サブスクリプション機能では、サービス側が提供するノード一覧をクライアントに読み込み、同じグループ内で更新、絞り込み、切り替えを行えます。初回追加時はリンクが完全か確認し、識別しやすいグループ名を設定してください。ノード変更が多いサブスクリプションには自動更新が便利ですが、間隔を短くしすぎないようにします。リクエストに失敗した場合は、リンクにまだアクセスできるか、更新リクエストに現在のプロキシが必要かを確認します。
v2rayNではサブスクリプショングループ設定ごとに更新動作を管理でき、すべてのグループに同じ方針を適用せずに済みます。手動変更したノードは上書き関係に注意が必要です。サブスクリプションを再更新すると、サービス側の内容でローカルコピーが置き換えられる場合があります。重要なカスタム設定は、サブスクリプションから生成された項目を直接書き換えず、別に保存するのが適切です。
ルーティング
ルーティングルールは、対象のリクエストを直接接続、プロキシ、遮断のどの出口へ送るかを決めます。一般的には、まず明確なLANや地域別ドメインの集合を処理し、どの条件にも一致しない通信をデフォルトの出口へ渡します。ルールは通常、上から順に一致判定されるため、具体的な条件を広い条件より前に置きます。変更後は設定を再読み込みし、古いルールで接続が処理され続けないようにします。
v2rayNのグラフィカル設定は一般的なルールの管理に適しています。複雑なケースでは、生成された設定のrouting部分も確認してください。geositeはドメイン集合、geoipはアドレス集合、networkはTCPまたはUDPの一致に使用します。ルーティングはシステムプロキシモードの代替ではありません。前者は通信をクライアントへ入れる処理、後者はコア内で出口を選ぶ処理を担います。
コア管理
グラフィカルクライアントは設定の入力、変換、管理を担い、プロトコル、トランスポート、ルーティングを実際に処理するのはコアです。XrayとV2Flyは共通のエコシステムを持ちますが、それぞれ機能と互換性の方針を維持しています。REALITY、XTLS、または特定のプロトコル拡張を使う場合は、選択したコアが該当フィールドに対応しているか確認してください。通常の設定でも、名称だけで互換性を判断してはいけません。
コアを切り替える前に現在の接続を停止し、クライアントがコアファイルを認識していることを確認してから設定を再起動します。切り替え後に起動に失敗した場合は、ノードを何度も変更するのではなく、まずログのフィールド解析メッセージを確認してください。Androidでは通常、クライアントの種類が主要なコアを決めます。v2rayNGはXray、v2flyNGはV2Flyを基盤とします。
プロキシの適用
システムプロキシを有効にすると、OSのプロキシ設定に従うアプリがクライアントの待受ポートへリクエストを渡します。これは通信をクライアントへ入れる仕組みであり、すべてのプログラムが自動的に接続されるわけではありません。一部のアプリは独自のネットワークスタックを使うか、システム設定を無視します。その場合はアプリ側のプロキシ設定を確認するか、プラットフォームに応じて別の適用方法を選びます。
グローバル、ルール、バイパスモードは、クライアントが受け取った通信をどう処理するかを表します。普段の閲覧では、明確な対象をルーティング条件で振り分けられるルールモードが適しています。診断時は一時的にモードを切り替え、問題がノード、ルール、システムプロキシの入口のどこにあるかを判断できます。クライアントを終了する前にシステムプロキシを元に戻すと、後続のアプリが古いポートを使い続ける状況を減らせます。
クイックスタート
最短の設定経路を完了してから、自動更新、ルーティングルール、コア調整を段階的に追加します。問題の箇所を切り分けやすくなります。
サブスクリプショングループ管理を開き、新しいグループを作成して完全なV2Rayサブスクリプションリンクを貼り付けます。複数のグループを使う場合もすぐ見つけられるよう、用途が分かる名前を付けてください。保存後に一度手動更新し、サーバー項目が正常に生成されることを確認します。リストが空の場合は、先にルーティングやコアを変更せず、サブスクリプションのリンク、アクセス条件、応答形式を確認します。
初回の読み込みでは、デフォルトの更新方針を維持し、「リンクを読み取れる、クライアントが解析できる、リストに内容がある」の3点だけを確認するのがおすすめです。自動更新間隔は接続成功後に設定できます。これにより、サブスクリプションの読み込み、プロキシ、定期タスクの問題を混同せずに済みます。
サーバー一覧から使用する項目を選び、アクティブ設定にしてからコアを起動します。次に、対象アプリに応じてシステムプロキシを有効にし、日常の通信にはまずルールモードを使います。システムプロキシはアプリのリクエストをクライアントへ送るかを決め、ルーティングルールはリクエストがコアに入った後の出口を決めます。両方を分けて確認してください。
特定のアプリが応答しない場合は、そのアプリがシステムプロキシに従うかを確認します。特定のドメインだけに問題がある場合は、ルールの一致順を確認してください。入口が有効か分からない段階でコア、サブスクリプション、ルールを次々に変更すると、ログの原因が複数の設定変更に埋もれてしまいます。
接続後はまずクライアントのログを確認し、設定がコアに読み込まれ、フィールド解析、ポート競合、ルーティング形式のエラーがないことを確認します。その後、システムプロキシに従うアプリでアクセスを検証し、直接接続ルールとプロキシルールが想定どおりかを個別に確認します。ログには設定処理の結果が記録されるため、画面の状態だけを見るより問題の特定に適しています。
基本接続が安定してから、サブスクリプションの自動更新や起動時自動起動などの長期設定を有効にします。変更は毎回1つだけにし、ルーティングやコアを変更した後は設定を再読み込みしてください。利用できる設定を独立したコピーとして残しておけば、新しいルールを追加した際も検証済みの基準へすぐ戻せます。
オープンソースエコシステム
クライアント、コア、設定形式はそれぞれ異なる層に属します。各自の役割を理解すると、プロトコルの互換性、機能差、更新の影響を判断しやすくなります。
Project Vは、設定駆動型のネットワークコアを基盤とする技術エコシステムを形成しました。コミュニティの保守方針が発展する中で、V2FlyはV2Rayコアと関連コンポーネントを引き継ぎ、Xrayは近い設定体系をもとに独自の機能分岐を発展させています。両者にはインバウンド、アウトバウンド、ルーティング、トランスポート、DNSなど多くの共通概念がありますが、すべてのフィールド、プロトコル拡張、動作が常に完全一致するわけではありません。
そのため、「V2Rayクライアント」は通常エコシステムの分類を示す総称であり、クライアント内部が特定の1つのコアだけを使うという意味ではありません。機能を判断するには、クライアントのグラフィカル管理機能、搭載コアの特性、サブスクリプションで使われるプロトコルフィールドを同時に確認する必要があります。クライアント名だけでは実際の互換性を十分に説明できません。
v2rayNは主にデスクトップでのサーバー一覧、サブスクリプショングループ、システムプロキシ、ルーティング設定、ログ確認、コア管理を担います。画面で設定を完了すると、クライアントがコアで読み込める実行設定に整理し、XrayまたはV2Flyが接続を処理します。画面に「起動済み」と表示されてもプロセスの状態を示すだけなので、プロトコルのハンドシェイク、DNSクエリ、ルール一致はコアのログと合わせて判断してください。
この階層設計により、設定管理とネットワーク処理を別々に発展させられます。クライアントの更新は画面、サブスクリプション解析、設定生成ロジックを変更する可能性があり、コアの更新はプロトコル対応、トランスポート実装、フィールド検証に影響する場合があります。更新後の異常を調べるときは、まずどの層で変化が起きたかを切り分け、その後に設定の復元、コアの切り替え、サブスクリプション内容の修正を判断します。
v2rayNはWindows、macOS、Linuxのデスクトップ環境向けで、複数のサブスクリプション管理、ルーティングルールの編集、システムプロキシの切り替え、詳細ログの確認が必要な場面に適しています。デスクトップごとにシステムプロキシの動作やインストール形式は異なりますが、クライアント内のサブスクリプション、サーバー、コアという概念は基本的に共通します。移行時は端末のパスとプラットフォーム権限を改めて確認してください。
v2rayNGはAndroid向けで、主にXrayコアを採用し、モバイルネットワークの切り替え、サブスクリプション更新、ルーティング、接続制御を中心に構成されています。v2flyNGもAndroid向けですが、コアの違いによって別の設定経路を提供します。どちらもオープンソースコミュニティが保守するグラフィカルクライアントです。選択時は名称を同じアプリの画面違いと単純に捉えず、サブスクリプションのプロトコル、必要なコア、設定の使い方で判断してください。
オープンソースプロジェクトでは、コミュニティがコードを確認し、実装を議論しながら機能を継続的に保守できます。一般ユーザーにとっては、設定の動作や問題の記録を技術コミュニティが分析でき、クライアントとコアが独立して修正をリリースできることが直接的な利点です。ただし、基本的なバージョン選択、権限管理、設定確認の代わりにはなりません。端末のプラットフォームと実際の用途に合う入口を選んでください。
更新時はまず機能変更を読み、現在の設定を保存してから、サブスクリプション解析、コア起動、システムプロキシの3つの基本工程を確認します。現在の設定が安定していて明確な機能要件がなければ、変更内容を把握してから更新しても構いません。新しいプロトコルフィールドが特定のコア機能に依存する場合は、クライアントの設定生成能力とコアの対応状況を同時に考慮する必要があります。サイト内のガイドはこの階層構造に沿って操作手順とトラブル解決の流れを整理しています。
よくある質問
問題がサブスクリプション、コア、システムプロキシ、ルーティングのどの層にあるかを先に判断し、該当する設定を確認します。
まずサブスクリプションリンクが完全で、現在もアクセスできるか確認します。次に更新リクエストにプロキシが必要か、返された内容がクライアントで解析できる形式かを確認してください。リストがまだ生成されていない段階では、システムプロキシモードの切り替えやルーティングルールの変更で解決できるとは限りません。クイックスタートガイドで読み込み順を確認できます。
まずコアのログで設定が正常に読み込まれたか確認し、次に対象アプリがシステムプロキシに従うかを確認します。他のアプリは接続できて特定のアプリだけ異常な場合は、そのアプリ独自のネットワーク設定を確認してください。すべてのアプリが接続できない場合は、システムプロキシのポートとクライアントの待受状態を確認します。詳しい手順は問題診断で症状から探せます。
システムプロキシはアプリのリクエストをクライアントへ渡すかを決めます。グローバルモードまたはルールモードは、クライアントが受け取ったリクエストの出口を決めます。具体的なルーティングルールは、ドメイン、アドレス、ネットワーク種別を照合します。3つは異なる処理段階にあるため、「アプリがクライアントに入っていない」問題と「出口の選択が想定と違う」問題を同一視しないでください。
特定のプロトコル拡張を使う場合、コアのログで未対応フィールドが示された場合、または機能のコア互換性を検証したい場合に切り替えを検討します。通常の接続問題では、まずサブスクリプション内容、時刻設定、システムプロキシ、ルーティングを確認してください。切り替え前に現在の接続を停止し、切り替え後に設定を再読み込みして、実際に動作しているコアとフィールド解析結果をログで確認します。
ガイド更新情報
記事では、トップページで扱いきれない設定の原理、選定基準、展開時の境界を補足しています。基本接続を完了した後の継続学習に適しています。
3種類の一般的な形式について、構造、クライアントの対応範囲、変換の境界を整理し、読み込みに失敗したときにどの層から確認すべきかを解説します。
続きを読む →メインルーターと旁路ルーターの接続方式を比較し、透過プロキシ、DNS処理、対象端末の範囲、性能上の制約を整理します。
続きを読む →2つのコアの保守方針を整理し、プロトコルの特性、設定フィールド、3種類のグラフィカルクライアントとの対応関係を解説します。
続きを読む →