設定の順番に沿って、5つの基本機能を確認します。右側は設定画面の例です。実際のメニュー名はクライアントのバージョンによって異なる場合があります。
設定の流れ：グループを保存 → 設定を取得 → サーバーを選択
システムプロキシとルーティングプリセットは、別々の設定項目です。
まずプリセットを確認し、その後に例外を追加します。DNSの名前解決経路も確認してください。
まず通常のプロキシ接続を確認し、ネットワークに問題が起きたら設定を元に戻します。
現在のクライアントの対応状況を確認し、コアの名称だけで互換性を判断しないでください。
まず、3つの設定レイヤーを区別しましょう。サブスクリプションはサーバー情報の取得、システムプロキシやTUNはアプリの通信をクライアントに渡す役割、ルーティングは通信の出口を決める役割を担います。それぞれ連携しますが、互いに置き換えることはできません。サブスクリプションを更新しただけでは、プロキシが有効になったとは限りません。システムプロキシを有効にしても、サーバー設定の誤りは解決しません。この順に確認すると、関係のないメニューを行き来せずに済みます。
初めて使うときは既定の設定を維持し、まず動作を確認できる接続経路を1つだけ作りましょう。ウェブページにアクセスできることを確認してから、グループの追加、自動更新、ルーティングの例外、TUNを設定します。変更は一度に1種類に絞り、変更内容とテスト結果を記録してください。操作手順を順番に確認するにはサブスクリプションの追加ガイドを、各設定の関係を理解するには設定を基礎から学ぶ完全ガイドをご覧ください。
デスクトップではv2rayN、Androidではv2rayNGをまず確認しましょう。ダウンロードページでCPUアーキテクチャとパッケージ形式を確認してください。
v2rayNのデスクトップ版または従来のWPF版を選択できます。デスクトップ版はクロスプラットフォーム対応のUIを採用し、WPF版は従来の画面レイアウトを維持しています。選択の基準は操作感やOSとの適合性であり、異なるプロキシプロトコルという意味ではありません。ダウンロードページでインストール手順を確認し、OSとCPUが各ダウンロード項目の要件を満たしているか確認してください。
インストール後はクライアントを起動し、サブスクリプションを追加してアクティブサーバーを選んでから、システムプロキシを設定します。古いクライアントがバックグラウンドで動作している場合は、ローカルの待ち受けポートが競合しないよう、先に終了してください。既存の環境をアップグレードする場合は、サブスクリプションとカスタムルーティングをバックアップし、復元できる設定を残してから、普段使うアプリで動作を確認しましょう。
ダウンロード · Windowsv2rayNを選ぶ前に、システムの「このMacについて」を開いてチップ情報を確認してください。Apple Silicon搭載機はarm64、Intel搭載機はx64のダウンロード項目に対応します。外観や購入年だけでアーキテクチャを判断せず、異なるチップ向けのインストーラーを混用しないでください。
初回起動時は、システムの案内に従ってアプリの権限を設定します。起動がブロックされた場合は、表示内容とシステム要件を確認し、インストールのためにシステム保護を安易に無効化しないでください。サブスクリプションを追加したら、アクティブサーバーとシステムプロキシをそれぞれ確認します。ブラウザーは接続できるのにほかのアプリで問題がある場合は、そのアプリがシステムプロキシを利用しているかを確認してください。通信を取り込む必要がある場合は、TUNの説明を読み、必要な権限を確認してから設定します。
ダウンロード · macOSまずはXrayコアを使用するv2rayNGを選びましょう。V2Flyコアが必要な場合はv2flyNGを確認してください。比較的新しいスマートフォンの多くはarm64パッケージに対応しています。アーキテクチャがわからない場合は、端末情報とダウンロードページの説明を確認してから汎用パッケージを検討してください。2つのクライアントは別々に設定を管理するため、インストール後にサブスクリプションやルールが自動共有されるとは限りません。
サブスクリプションURLを貼り付けて更新したら、ノードを選択して接続を開始し、システムのVPN接続許可に応じてください。通常、システムVPNを利用できるアプリは同時に1つです。クライアントを切り替える前に、現在の接続を停止してください。バックグラウンドにすると切断される場合は、バッテリー最適化とバックグラウンド実行の制限を確認します。接続できない場合は、ノードの設定とログから原因を調べてください。
ダウンロード · Androidv2rayNを選ぶ際は、ディストリビューションのパッケージ形式とマシンのアーキテクチャを確認してください。deb形式のディストリビューションにはdebパッケージ、rpm形式にはrpmパッケージのダウンロード項目を選びます。arm64の端末では、ダウンロードページにある対応アーキテクチャの項目を選択してください。パッケージ形式が合っていても、すべての依存関係が満たされているとは限りません。インストール時のメッセージを一つずつ確認しましょう。
デスクトップ環境によって、システムプロキシの仕組みや権限管理方法が異なります。初回のテストでは、ブラウザーがクライアントのローカルプロキシを明示的に使うよう設定し、デスクトップ環境側のプロキシ設定も確認してください。TUNを有効にする場合は、必要な権限と既存の仮想ネットワークインターフェースとの競合を確認します。日常的なサブスクリプションやサーバーの管理はGUIクライアントだけで行えるため、最初からルーター環境を構築する必要はありません。
ダウンロード · Linuxインストーラーに含まれるのはクライアントであり、そのまま使えるサーバーのサブスクリプションは含まれません。サブスクリプションURLやサーバー情報は信頼できる提供元から入手し、利用地域の法令やネットワークサービスの規約に従って使用してください。
すべてのクライアントを見る →プロジェクト、コア、クライアント、サーバー設定の違いを整理してから、インストールや更新が必要なものを選びましょう。
役割の階層を示した図です。すべてのクライアントが図中の機能をすべて組み合わせて利用できるわけではありません。
V2Rayのコアの違いを読む →V2RayはProject Vのプロジェクト群から生まれ、関連するプロキシ技術やツールのエコシステムを指す言葉としても使われます。一般に「V2Rayクライアント」と検索した場合は、特定のインストーラーではなく、GUIを備えた設定管理ソフトを指すことが多いです。クライアントはサブスクリプション、サーバー、ルーティングなどの設定を操作画面にまとめ、コアに接続処理を実行させます。この関係を理解すれば、クライアントのダウンロード、サーバー設定、コアの更新を混同せずに済みます。
同じ共有リンクを複数のクライアントで読み込めても、すべての詳細設定を完全に引き継げるとは限りません。インポート前に、提供されたものがサブスクリプションURL、個別の共有リンク、標準設定ファイルのどれかを確認してください。それぞれ役割が異なります。初めて設定する場合はクライアントの画面に沿って操作し、接続できることを確認してからプロトコルやトランスポートの詳細を学ぶとよいでしょう。
V2FlyはV2Ray関連コアのコミュニティ開発を引き継いでいます。一方、Xrayは関連技術を基に発展した別系統のコアです。共通する概念やプロトコルの背景はありますが、機能、設定フィールド、開発の方向性は完全には一致しません。選ぶ際は、サーバー側で必要なプロトコルとトランスポートの組み合わせを確認し、クライアントが実際に対応しているコアを調べてください。名称が似ていても互換性があるとは限らず、速度の優劣を判断する根拠にもなりません。
特定の系統にしかない機能を含む設定には、その機能に対応したコアとクライアントの組み合わせが必要です。切り替え後に起動しない、フィールドを認識しない、ハンドシェイクに失敗するといった問題が起きたら、まずログに明示されたエラーを確認してください。使える設定を残してから試すほうが、コア、DNS、ルーティング、トランスポートを一度に変更するより原因を特定しやすくなります。
v2rayN、v2rayNG、v2flyNGはいずれもソースコードが公開され、無料で利用できるクライアントプロジェクトで、GPL-3.0ライセンスを採用しています。オープンソースライセンスは、コードの利用、改変、再配布に関する条件を定めるものであり、サーバーの利用規約に代わるものではありません。また、あらゆるサブスクリプションの提供元が信頼できることを保証するものでもありません。デスクトップ版とAndroid版では、画面、権限、ネットワークへの接続方法が異なります。ガイドを読むときはクライアント名を確認し、該当するメニューを参照してください。
v2rayNはデスクトップ向けで、サブスクリプション、サーバー、ルーティングをまとめて管理できます。v2rayNGはAndroid向けで、Xrayコアを使用します。v2flyNGはV2Flyコアを使うAndroid向けの選択肢です。プラットフォームと設定の互換性を優先し、機能名が多いという理由だけで複数のクライアントを同時に動かす必要はありません。移行するときは元の設定を残し、サブスクリプション、接続、ルーティングを一つずつ確認してください。
クライアントの更新は画面表示やプログラムの動作に、コアの更新はプロトコル処理や接続機能に影響します。サブスクリプションの更新ではサーバー情報を再取得します。それぞれ対象が異なるため、プログラムを更新しても期限切れのサブスクリプションは自動で直りません。サブスクリプションを更新しても、古いコアに新機能が追加されるわけではありません。日常のメンテナンスでは、エラーが発生した箇所に応じた操作を選び、「すべて更新」だけを解決策にしないようにしましょう。
アップグレード前に、カスタムルーティング、サブスクリプショングループ、重要な設定をバックアップし、変更内容を確認してください。アップグレード後は、以前使えていたサーバーで基本接続をテストしてから、LANへのアクセス、普段使うアプリ、DNSを確認します。サブスクリプションURLに含まれる認証情報はアカウント情報と同様に扱ってください。スクリーンショットやログを共有する場合は、URLのパラメーター、ユーザー識別情報、サーバー認証情報を隠しましょう。問題の記録には、エラーの種類と発生手順を残せば十分です。
URLを追加しただけでは取得先が保存されるだけです。「サブスクリプションを更新」を実行してサーバー情報を読み込みます。情報を取得したら、サーバーを選んでアクティブにし、システムプロキシなどの接続方法を使ってアプリの通信をクライアントに渡してください。一覧が空の場合は、更新時のエラーメッセージを確認します。サーバーが一覧にあるのに接続できない場合は、サーバー設定とローカルの接続方法を調べましょう。サブスクリプションの追加手順を順に確認してください。
いいえ。システムプロキシは、システム設定に従うアプリがクライアントにリクエストを渡すかどうかを決めます。ルーティングモードは、受け取ったリクエストをクライアントがどう送信するかを決めます。グローバルルーティングを選んでも、システムプロキシを参照しないアプリの通信はクライアントを経由しないことがあります。まず接続方法を確認し、次にルーティングを確認すれば、アプリ側のプロキシ設定の問題をノード障害と誤認しにくくなります。詳しい手順はプロキシ設定ガイドをご覧ください。
起動ボタンや一度の遅延測定だけで判断しないでください。まずクライアントの接続テストを実行し、対象のアプリから実際にアクセスできるか確認したうえで、出口IPアドレスとログも確認します。1つのテストに成功しても、すべてのアプリが同じネットワーク経路を使うとは限りません。ルーティングを有効にしている場合、宛先によって出口が異なることもあります。接続確認チェックリストに沿って、プロキシ対象と直接接続の対象を別々にテストしてください。
まず、すべての接続に失敗しているのか、一部のドメインだけに問題があるのかを確認してください。証明書エラー、認証失敗、サーバーへの到達不能は、通常DNSを変更しても解決しません。基本接続を確認してから、名前解決の結果、DNSリクエストの経路、ルーティングルールに矛盾がないか調べます。変更前に元の設定を記録し、一度に変更するのは1項目にとどめてください。詳しくはDNS設定の章をご覧ください。
初回接続から通信速度の診断、ルーターへの導入まで解説。現在の問題に合った記事を選び、設定を一度にすべて変更しないようにしましょう。
サブスクリプションの更新後に行う、ノード選択、実接続での速度測定、出口IPアドレスと実際のアクセスによる経路確認を解説します。TCPポートへの到達とリクエスト全体の成功を区別し、単一の遅延測定だけで接続全体を判断しないためのポイントも紹介します。
初回接続チェックリストを読む →メインルーターとサブルーターの役割の違いを整理し、透過プロキシ、DNSの振り分け、ゲートウェイ設定の連携を解説します。まず通信経路全体を把握してから、機器の権限や保守コストを検討しましょう。デスクトップクライアントがまだ接続できない場合は、先に基本設定を済ませると問題を特定しやすくなります。
構築の考え方を読む →ノードの負荷、回線品質、ローカル設定の3段階で原因を絞り込み、トランスポートの選択、Mux、DNS、ルーティングルールを確認します。条件をそろえてから結果を比較し、端末の回線切り替え、バックグラウンドのダウンロード、接続先サイトの状態による影響を抑えましょう。
段階的なトラブル対処法を読む →明確なエラーが表示されたら、まずクライアント名、操作手順、エラーメッセージを記録し、該当する記事を確認してください。問題を共有する際はサブスクリプションの認証情報を隠し、必要な設定の種類とエラーの状況だけを残しましょう。
すべての記事を見る →