Windows
v2rayNのデスクトップ版または従来のWPF版を選べます。デスクトップ版はクロスプラットフォームのUIを採用し、WPF版は従来のWindows操作に慣れたユーザーに適しています。どちらもサブスクリプション、システムプロキシ、ルーティングルール、TUNモードに対応します。
ダウンロードへクライアント選び、サブスクリプションの追加、ルーティングまでの手順を整理し、デスクトップとAndroidに対応。v2rayN・v2rayNG・v2flyNGの実際の設定項目に沿って解説します。
設定項目を実際の利用順に分けて説明します。まずサブスクリプションとノードを整理し、次に通信の取り込み範囲を決め、最後にルーティングと名前解決の方針を設定します。複数の項目を同時に変えて原因を追いにくくすることを避けられます。
サブスクリプショングループは、複数のノード提供元が混在して管理しづらくなる問題を解決します。v2rayNでは異なるサブスクリプションと自作設定を別グループに分け、指定した提供元だけを更新できます。v2rayNGは、モバイル端末でよく使う設定を少数に絞って管理する用途に向いています。追加後はグループ名、更新日時、プロトコル項目を確認し、別名やアドレスで絞り込みましょう。「サブスクリプションを更新」と「現在のノードを切り替える」は別の操作です。
実際の運用では、「普段使い」「一時テスト」「自作設定」など、分かりやすいグループを用意すると便利です。サブスクリプションを削除する前に、現在の接続がその設定を参照していないか確認してください。絞り込みは一覧の表示範囲だけを変え、サブスクリプションの内容は書き換えません。特定のノードを継続的に除外する場合は、クライアントのサーバーフィルターでキーワードを設定します。
サブスクリプション管理の解説を見る →ルーティングルールは単純な「全体」または「直接接続」の切り替えではなく、順番に照合される条件の集まりです。クライアントはドメイン、IP、ポート、インバウンドタグ、プロセス名に応じて、通信をプロキシ、直接接続、またはブロックのいずれかへ振り分けます。まずはLANやよく使う中国本土のサービスを直接接続にし、それ以外を現在のプロキシ方針で処理する構成が一般的です。ブロック対象のルールは意図が分かる位置に置きましょう。
ルールの順番は結果に直結します。範囲が狭く意図が明確な項目を前に置き、最終的なフォールバックルールを末尾に配置するのが基本です。変更後は再接続し、直接接続とプロキシの条件に一致する対象へそれぞれアクセスして確認してください。アプリによって挙動が異なる場合は、まずそのアプリがクライアントの取り込み範囲に入っているかを確認し、次にルール自体を点検します。
ルーティングルールの実践例を見る →システムプロキシは、システムのプロキシ設定を参照するプログラムにのみ適用されます。一部のコマンドラインツール、ゲームランチャー、独自のネットワークスタックを持つアプリは迂回することがあります。TUNモードでは仮想ネットワークインターフェースでより広い範囲の通信を受け取り、クライアントのコアでルーティングします。複数のアプリを一括して取り込みたい場合に適していますが、システムプロキシで足りる場合に無理に有効にする必要はありません。
有効にする前に、クライアントが仮想インターフェースの作成に必要なシステム権限を持っていることを確認し、同じネットワーク層を使用する可能性のあるツールを終了してください。接続後はまずウェブ閲覧を確認し、次に対象アプリを試します。ローカルデバイスへ接続できない場合は、LANのバイパス設定と厳格なルーティングを確認してください。クライアントを終了する前に通常の切断を行うと、システムのネットワーク状態を想定どおりに戻せます。
TUNモードの設定を見る →DNSは、ドメインを最初にどのアドレスへ解決するかを決めます。その後、ルーティングルールに基づいて出方向が選ばれます。名前解決の方針と振り分け先が一致しないと、ドメイン判定は正しくても接続先が想定と異なる場合があります。ローカル解決、リモート解決、クエリの照合条件を分け、ドメインベースのルーティングに必要なドメイン情報を保持できる構成にしましょう。
切り分ける際は、まずシステムとアプリのキャッシュを消去してからクライアントへ再接続します。一部のドメインだけに問題がある場合は、ドメインルールとDNSサーバーのグループを確認してください。すべてのドメインに影響する場合は、クエリ方針、待受アドレス、TUNのDNS取り込みを確認します。FakeDNSは特定の透過プロキシ構成に適していますが、マッピングの仕組みを理解せず既存の構成と置き換えるべきではありません。
DNS最適化の方法を見る →223.5.5.5
https+local://1.1.1.1/dns-query
UseIP
デスクトップではv2rayNを主な入口とし、Androidではv2rayNGとv2flyNGから選べます。ダウンロードページでは、システムのアーキテクチャとインストール形式も分けて案内します。
v2rayNのデスクトップ版または従来のWPF版を選べます。デスクトップ版はクロスプラットフォームのUIを採用し、WPF版は従来のWindows操作に慣れたユーザーに適しています。どちらもサブスクリプション、システムプロキシ、ルーティングルール、TUNモードに対応します。
ダウンロードへv2rayNのデスクトップクライアントを使い、プロセッサの種類に応じてApple SiliconまたはIntelのインストーラーを選択します。初回起動時はシステムのセキュリティ確認とネットワーク権限の許可が必要です。その後、サブスクリプションを追加してシステムプロキシを有効にします。
ダウンロードへXrayコアを搭載したv2rayNGを第一候補にし、V2Flyコアが必要ならv2flyNGを選べます。主流の端末では通常arm64を使用します。アーキテクチャが分からない場合は汎用インストーラーを選んでください。2つのクライアントはサブスクリプションの操作方法がよく似ています。
ダウンロードへv2rayNは主要なディストリビューション向けのパッケージを提供しています。システムのパッケージ管理方式に合わせてdebまたはrpmを選び、プロセッサのアーキテクチャもx64とarm64から選択します。インストール後は、他のデスクトップ環境と近い操作でサブスクリプションとルーティングを設定できます。
ダウンロードへクライアント名、コア名、プロトコル名はそれぞれ異なる階層に属します。関係を理解しておくと、ソフトウェアの選択、設定の読み解き、ログのトラブル対処で問題箇所を正確に特定できます。
Project Vは、組み合わせ可能なネットワークプロキシ機能を核とするオープンソースエコシステムを形成しました。一般的な設定にあるインバウンド、アウトバウンド、ルーティング、DNS、トランスポート方式、プロトコルパラメータは、このモジュール設計の考え方に基づいています。日常的に操作するのはGUIクライアントですが、接続、プロトコル、ルーティングを実際に処理するのはクライアントが呼び出すコアです。そのため、同じサブスクリプションでも異なるクライアントで似た項目が表示される一方、コアの機能やクライアント側の対応状況によって設定に差が出ることがあります。
ガイドを読む際は、まず問題がどの層で起きているかを切り分けます。サブスクリプションを追加できない場合は、クライアントの入力やサブスクリプション形式が原因であることが多く、プロトコルパラメータを認識できない場合はコアの対応状況が関係します。システムプロキシが対象アプリに効かない場合はOSのプロキシ機構を確認し、ルーティング結果が想定外ならルールの順番、名前解決、アウトバウンドタグを確認します。層ごとに調べる方が、何度も再インストールするより効果的です。
V2FlyコミュニティはV2Rayの中核機能を引き継ぎ、保守しています。設定構造はモジュールの組み合わせと互換性のある発展を重視します。Xrayは近い設定体系を基盤に、独自のコア実装と機能拡張を発展させました。どちらもGUIクライアントではなく、特定のプロトコルそのものでもありません。インバウンドの待受、アウトバウンド接続、ルール照合、DNSクエリ、トランスポートパラメータを実行する役割を担います。
基本設定の多くは2つのコア系統で対応づけて理解できますが、具体的な項目、対応範囲、初期動作はクライアントに統合されているコアを基準にしてください。他のクライアントから設定をコピーする場合、プロトコル名が同じというだけで判断せず、トランスポート方式、セキュリティパラメータ、サーバー名、パス、フィンガープリントの項目、ルーティングタグがそろっているかも確認します。
v2rayNはデスクトップ向けの主要な選択肢で、Windows、macOS、Linuxに対応し、サブスクリプショングループ、サーバーの絞り込み、システムプロキシ、ルーティングルール、DNS、TUN、ログ確認などをGUIで設定できます。v2rayNGはAndroid向けで、通常はXrayコアを搭載し、サブスクリプションや共有リンクでモバイル接続を管理できます。v2flyNGもAndroid向けですが、V2Flyコアを内蔵している点が異なり、このコア系統が必要な場合の選択肢になります。
3つのソフトウェアはいずれもオープンなコミュニティ協力によって継続的に保守され、コードや変更履歴を確認できます。クライアントのリリースとコアの更新は完全には同期しません。コアに機能が追加されても、GUI側ではパラメータの対応づけ、操作設計、プラットフォームテストが必要です。選ぶ際は、名称の似ているかどうかだけでなく、プラットフォーム、コア、必要な機能を基準にしてください。
オープンソースソフトウェアでは、ライセンスがコードの利用、変更、再配布の条件を定めます。一般ユーザーにとってライセンスは、ソフトウェアの出所が透明で協力の境界が明確であることを示します。二次開発や企業導入を行うチームは、各プロジェクトの具体的なライセンス本文を読み、自身の配布方法が条件に適合するか確認してください。クライアントや依存コンポーネントによってライセンスが異なる場合があるため、1つのコンポーネントの条項をソフトウェア全体にそのまま適用することはできません。
オープンソースであることは設定の確認に代わるものではありません。サブスクリプションを追加する前に、提供元と用途を確認してください。接続後はログで実際に使用されているインバウンド、アウトバウンド、ルーティングルールを確認します。システムのネットワーク権限については、OSの案内に従い、プロキシや仮想ネットワークの設定に必要な範囲だけをクライアントへ許可してください。
クライアントの更新は主にUI、プラットフォーム互換性、機能の入口を変えます。コアの更新はプロトコル実装、ルーティング、DNSなど低レイヤーの機能に影響します。サブスクリプションの更新はサーバー設定を置き換えたり追加したりします。3つは関連していますが、同じ操作ではありません。サブスクリプションを更新できない場合は、まずアドレス、ネットワーク、サブスクリプショングループを確認します。コアの起動に失敗する場合はログと設定項目を確認し、クライアントのUIに問題がある場合にソフトウェアの更新や設定移行を検討します。
更新前に現在のルーティングモード、DNS方針、TUNの状態を記録しておくと、挙動が変わった際に比較しやすくなります。複数のサブスクリプションを使っている場合は、グループごとに更新して結果を確認してください。クライアント、コア、すべてのサブスクリプションを同時に変更すると、トラブル対処の基準を失いやすくなります。上級設定の章では、カスタムアウトバウンド、FakeDNS、複数サブスクリプションのフィルタリングも解説しています。
上級設定マニュアルへ →DNSルーティング、接続速度、デスクトップOSの権限を中心に解説します。各記事では問題の層に応じた確認手順を示し、根拠がないまま複数の設定を同時に変更することを避けます。
DNSサーバーのグループ分け、クエリ方針、ルーティングとの連携を取り上げ、ドメインごとに適切な名前解決経路を使う方法と、キャッシュ削除・反映確認の手順を解説します。
記事を読む →速度の問題をノードの状態、回線の時間帯、ローカル設定の3層に分け、ルーティング、DNS、TUN、対象アプリを順番に確認して無駄な切り替えを減らします。
記事を読む →システム設定から初回起動の制限に対処し、ネットワーク権限の許可、システムプロキシの確認、クライアント接続のチェックまで行います。インストールの問題と設定の問題を切り分けます。
記事を読む →