v2rayNのインストールと設定ガイド

インストール前の準備とクライアント選び

まずプラットフォーム、プロセッサのアーキテクチャ、利用範囲を確認する

設定を始める前に、3つの点を確認します。端末のOS、プロセッサのアーキテクチャ、そしてクライアント経由でネットワークに接続する必要があるアプリです。プラットフォームによってインストールパッケージの形式が決まり、アーキテクチャによってバイナリが起動できるかが決まります。また、適用範囲によってシステムプロキシとTUNのどちらを選ぶべきかが変わります。デスクトップでは、Windows、macOS、Linuxに対応し、サブスクリプション管理、コア切り替え、ルール設定、システムプロキシを扱えるv2rayNが第一候補です。Androidではv2rayNGを推奨します。V2Flyコアの動作が明確に求められる場合や、既存のV2Fly設定との互換性を重視する場合はv2flyNGを選べます。

Windowsの一般的な端末はx64アーキテクチャです。macOSではApple SiliconとIntelを区別します。「システム情報」のハードウェア概要でチップまたはプロセッサ名を確認してください。Linuxではターミナルでuname -mを実行し、x86_64はx64、aarch64またはarm64はARM64に対応します。近年のAndroid端末は通常arm64ですが、アーキテクチャを確認できない場合や、インストール時に非対応と表示された場合は汎用パッケージを使用します。インストール先とアーキテクチャの説明はダウンロードページにまとめています。別プラットフォーム用のパッケージを流用しないでください。

クライアント、コア、ノード設定を区別する

GUIクライアント、プロキシコア、ノード設定は別々の層です。v2rayN、v2rayNG、v2flyNGは、画面表示、サブスクリプション、起動制御、システムネットワークの適用を担当します。XrayまたはV2Flyコアは、プロトコルの解析、送信接続の確立、ルーティング、DNS処理を担当します。ノード設定には、サーバーアドレス、ポート、ユーザー識別子、通信方式、TLS、REALITYなどの接続パラメータが含まれます。クライアントのインストールが完了しても、それだけで接続可能なサーバー設定が用意されるわけではありません。逆に、サブスクリプションにノードが含まれていても、コアがそのノードの全パラメータに対応しているとは限りません。

たとえば、REALITYやXTLS Visionのパラメータを含む設定は、通常、対応機能を備えたXrayコアで処理する必要があります。通常のVMess、VLESS、Trojan設定でも、アドレス、ポート、トランスポート層、セキュリティ層を正しく一致させなければなりません。「インポートは成功したのに接続できない」場合、すぐにシステムプロキシのモードを繰り返し変更するのは避けましょう。まず現在のクライアントが使用しているコアの種類を確認し、ノードの要件と照合します。2種類のコアの機能範囲については、XrayコアとV2Flyコアの違いも参照してください。

サブスクリプション情報を準備し、復旧用の設定を残す

初回設定の前に、有効なサブスクリプションURL、単一の共有リンク、QRコード、または設定ファイルを用意します。サブスクリプションは複数ノードの一元管理に、単一リンクは一時的な設定のインポートに、QRコードはデスクトップとAndroid端末間で少量の設定を渡す際に、ファイルは複雑なパラメータをまとめて保存する際に適しています。サブスクリプションURLは通常アクセス認証情報に相当するため、公開文書、スクリーンショット、複数人で共有するログに載せないでください。コピー時はすべての文字を保持し、チャットツールによる途中切れや前後の空白にも注意します。

システムプロキシ、TUN、DNS、カスタムルーティングを変更する前に、動作する基本設定を1つ保存しておくことをおすすめします。デスクトップでは現在の設定をエクスポートするか、元のルーティングモードを記録します。Androidでは設定を複製してから編集できます。トラブルシューティングでは、一度に1つの変数だけを変更します。まずノード単体を確認し、次にシステムへの適用を有効にし、最後にルーティングとDNSを調整します。最初からコア、ノード、ルーティング、TUNを同時に変更すると、失敗時に原因の層を特定しにくくなります。

Windows：v2rayNのインストールとシステムプロキシの適用

デスクトップ版または従来のWPF版を選ぶ

Windowsのダウンロード欄には、v2rayNのデスクトップ版と従来のWPF版があります。デスクトップ版は新世代のクロスプラットフォームUIを採用しており、新規インストールや複数のデスクトップOSで似た操作感を求める場合に適しています。WPF版はWindowsで長く使われてきた従来型のUIで、メニュー位置、トレイ操作、設定管理に慣れている環境に向いています。どちらもサブスクリプション、ノード、ルーティング、システムプロキシを扱いますが、同時に起動して同じローカルポートを奪い合わないでください。初回はどちらか一方だけを選び、動作確認後に移行するか判断します。

ダウンロード後、インストールパッケージの指示に従ってインストールします。展開型パッケージを使う場合は、現在のユーザーに書き込み権限がある固定フォルダーへ展開してください。圧縮ファイルのプレビュー画面から直接実行したり、頻繁に削除される一時フォルダーへ置いたりしないでください。プログラムは設定、ログ、コアファイルを保存します。フォルダーに書き込めないと、画面は開いてもサブスクリプションの更新やコアの起動に失敗することがあります。初回起動後はシステムトレイを確認してください。メインウィンドウを閉じても通常はトレイに収納されるだけで、終了したことにはなりません。完全に停止する場合は、トレイメニューから終了を実行します。

サブスクリプションを登録し、使用ノードを選択する

サブスクリプショングループの管理画面で新しいサブスクリプションを追加し、識別しやすいメモと完全なURLを入力してから、現在のサブスクリプションまたはすべてのサブスクリプションを更新します。更新後、メインリストにノードが表示されます。変化がない場合は、表示中のグループが更新したグループと同じか確認し、ログでネットワーク要求の失敗、内容の解析失敗、空のレスポンスのどれかを確認します。同じサブスクリプションを何度も追加するとグループの複製が増え、更新先を間違えやすくなります。1つの提供元につき、分かりやすい名前のグループを1つだけ残すのが基本です。

ノードを選択したら、使用サーバーとして設定します。ノード一覧の「選択済み」とコアの「起動済み」は別の状態です。前者は使用する設定を指定するだけで、後者になって初めてローカルプロキシポートが待ち受けを開始します。サービス起動後は、下部のステータスバーとログを確認してください。正常ならローカル待ち受けが確立したことが表示されます。その後、クライアントの実接続テストを使うか、システムプロキシを明示的に使用するブラウザーでページを開きます。ノードの速度測定は比較の補助であり、実際の接続テストの代わりにはなりません。3種類の測定値の違いは遅延テストの数値の見方を参照してください。

システムプロキシの仕組み

Windowsのシステムプロキシは、システムプロキシ設定を参照するアプリに主に影響します。「システムプロキシを自動設定」を選ぶと、v2rayNはシステムプロキシをローカルの待ち受けポートへ向け、クライアントの状態に合わせて更新します。ブラウザーや多くのデスクトップアプリはこの設定を読み取りますが、一部のゲーム、コマンドラインツール、ストアアプリ、独自のネットワーク処理を行うソフトは無視することがあります。ブラウザーは使えるのに別のアプリが使えない場合は、まずそのアプリがシステムプロキシに対応しているか確認し、すぐにノードの問題と判断しないでください。

ルーティングモードは、ローカルプロキシポートに入った要求をプロキシ経由または直接接続のどちらへ振り分けるかを決めます。一般的な「LANと中国本土を回避」は、日常的なルールベースの振り分けに適しています。LANアドレスと直接接続ルールに一致する通信はリモートノードを経由せず、その他の要求はルールに従って処理されます。グローバルモードは、特定ドメインがルールで誤判定されているかを一時的に確認する用途に向いています。影響範囲を理解しないまま、長期的なトラブル解決策として使うのは避けてください。ルーティングを切り替えた後は、現在のノードに再接続してコアにルールを再読み込みさせます。

管理者権限、ポート競合、自動起動

通常のシステムプロキシでは、常に管理者として実行する必要はありません。ただし、ネットワークコンポーネントのインストール、特定のTUN実装の有効化、保護された設定の変更では、権限昇格を求められることがあります。該当する操作時だけ権限を確認してください。コアが起動直後に終了する場合は、ログに「address already in use」などのポート競合メッセージがないかを優先して確認します。別のv2rayN、他のプロキシクライアント、残ったコアプロセスが同じポートを使用していることがよくあります。重複しているプログラムを終了してから現在のクライアントを再起動し、複数のポートを無作為に変更して競合を隠そうとしないでください。

自動起動は固定端末に適していますが、基本設定が安定してから有効にします。「クライアントを自動起動」と「起動後に自動接続」を同時に有効にすると、ログイン直後にプロキシ状態が変更されます。サブスクリプション切れ、ネットワーク未接続、前回のノード停止などにより、起動直後からアクセスできなくなることがあります。まずクライアントだけを起動し、ネットワークが利用可能になってから接続する方が安全です。トレイから「システムプロキシを解除」できる経路も残してください。異常終了後もブラウザーがローカルポートへ接続しようとする場合は、Windowsのプロキシ設定でプロキシを無効にしてからv2rayNを再起動します。

ローカルポートが待ち受け中か確認：
netstat -ano | findstr LISTENING

プロセス識別子に対応するプログラムを確認：
tasklist /fi "PID eq プロセス識別子"

macOS：v2rayNのインストール、許可、プロキシ設定

チップの種類に合うパッケージを選ぶ

macOS用のv2rayNインストールパッケージには、Apple Silicon版とIntel版があります。「システム情報」を開き、ハードウェア概要の「チップ」または「プロセッサ」欄を確認します。Apple系チップならARM64、Intelならx64のパッケージを選んでください。アーキテクチャを間違えると、システムに起動を拒否されたり、互換レイヤー経由で動作して別の問題が起きたりします。インストール前にmacOSのダウンロード入口から対応ファイルを取得し、購入年だけでチップの種類を推測しないでください。

ディスクイメージを開いたら、アプリを「アプリケーション」フォルダーへドラッグし、そのフォルダーから起動します。ディスクイメージ内で直接実行すると、保存、アップグレード、権限管理に支障が出ます。初回起動時、システムはアプリの出所を確認し、許可を求めます。システム設定のアプリケーションセキュリティ画面で明示的に許可してください。許可は起動可否を解決するだけです。画面が開いてもコアが動かない場合は、クライアントログとコアファイルの状態を別々に確認します。

設定をインポートしてコアを起動する

サブスクリプション管理の流れはWindowsとほぼ同じです。サブスクリプションのメモとURLを追加し、更新を実行し、対象グループでノードを選択してからサービスを起動します。macOSのクリップボードでは、リッチテキストページからコピーしたURLに改行が付くことがあります。貼り付け後にURLの前後を確認してください。QRコードは別端末から単一設定を渡すのに便利ですが、複数ノードには後から一括更新できるサブスクリプションが適しています。更新成功後もノード一覧が空なら、グループの絞り込みとサブスクリプションの内容形式を確認します。ログに解析エラーが出る場合は、未知のパラメータを手入力で補わず、提供元で形式を確認してください。

コアの起動後、HTTP、SOCKS、または混合プロキシポートがローカルで待ち受けます。クライアント画面では、使用ノード、コアの状態、システムプロキシの状態を別々に確認してください。ノードを選択してもシステム通信が適用されたとは限らず、システムプロキシを有効にしてもコアが待ち受けているとは限りません。最も多い異常状態は、システムプロキシがローカルポートを指したままクライアントが終了しているケースです。この場合、ブラウザーは存在しないサービスへの接続を繰り返します。クライアントを再起動するか、システムプロキシを無効にすれば基本的な通信を復旧できます。

システムプロキシとアプリごとの動作差

macOSのシステムプロキシはネットワークサービス単位で保存されます。たとえばWi-Fiと有線ネットワークで異なる設定を持てます。v2rayNが現在のシステムプロキシを変更すると、その設定に従うブラウザーやアプリがローカルポートへ要求を送ります。ターミナルツールがプロキシを使うかはツール次第です。環境変数を読むもの、システムネットワーク設定を読むもの、個別の引数が必要なものがあります。そのため「ブラウザーは正常だがターミナルの要求は直接接続」という状態も矛盾ではありません。ブラウザーと一般的なアプリだけならシステムプロキシが分かりやすく、対応しないプログラムまで対象にする場合はTUNを検討します。

Wi-Fiの切り替え、有線接続、テザリングの利用後は、現在のネットワークサービスのプロキシ状態を再確認します。スリープ復帰後にクライアントが動作中でも要求に失敗する場合は、現在のノードをいったん切断して再接続し、コアに基盤接続を再構築させます。ネットワークが変わるたびにサブスクリプションを削除する必要はありません。サブスクリプションは設定を保存するもので、変わるのは端末とサーバー間の経路だけです。社内ネットワーク、認証が必要なネットワーク、ログインページを必要とする公衆ネットワークでは、まず適用を解除して認証を完了し、その後プロキシサービスを起動します。

TUNの権限、DNS、終了時の復元

TUNは仮想ネットワークインターフェースを作成し、ルーティングを変更するため、システムプロキシより広い範囲を対象にします。初回有効化時にはシステムの許可が必要になることがあります。許可後も、仮想インターフェースが作成されたか、デフォルトルートが想定どおり変化したか、DNS要求をどの層が処理しているかを確認します。有効化後にすべての要求が失敗する場合は、まずTUNを無効にしてシステムプロキシが動作するか確認してください。これにより「ノードまたはコアの問題」と「仮想ネットワークの適用問題」をすばやく切り分けられます。

DNSの異常は、ドメインにアクセスできない一方で、宛先アドレスへの直接接続やクライアントの接続テストには反応がある、という形で現れます。まずクライアントのルーティングとDNSの標準設定を使い、複数のシステムDNSツールを同時に有効にしないでください。カスタム設定が必要な場合は、直接接続するドメインとプロキシ経由のドメインをそれぞれどのリゾルバーが処理するかを明確にし、解決結果とルーティング方向の衝突を避けます。クライアントを終了する前にシステムプロキシまたはTUNを無効にしてください。予期せず終了した場合は、システムのネットワーク設定で現在のサービスのプロキシ項目を確認し、ローカルポートを指したままの設定を解除します。

プロセッサのアーキテクチャを確認：
uname -m

現在のネットワークサービス一覧を確認：
networksetup -listallnetworkservices

Wi-FiのWebプロキシ状態を確認：
networksetup -getwebproxy Wi-Fi

Linux：v2rayN、デスクトッププロキシ、TUNの設定

ディストリビューション、アーキテクチャ、パッケージ形式を確認する

Linuxのダウンロード欄には、v2rayNのdebおよびrpmパッケージがあり、x64とARM64に分かれています。Debian、Ubuntuおよび一般的な派生ディストリビューションは通常debを、Fedora、Rocky Linux、AlmaLinuxなどrpm系のディストリビューションはrpmを使用します。uname -mでアーキテクチャを確認し、/etc/os-releaseでディストリビューション情報を確認してください。パッケージ形式とプロセッサアーキテクチャは両方とも一致させる必要があります。片方だけ合っていても、インストーラーのエラーやバイナリの実行不能につながります。

GUIクライアントにはデスクトップセッション、通知領域、いくつかのランタイムライブラリが必要です。サーバー環境ではパッケージをインストールできても、v2rayNの画面を表示できるとは限りません。本ガイドはデスクトップ環境を備えたLinux端末を対象とします。WaylandとX11ではトレイの実装が異なる場合があります。ウィンドウを閉じた後にトレイアイコンが見つからなければ、アプリメニューから再度開くか、デスクトップ環境でステータスアイコンが有効か確認してください。トレイに表示されないからといって複数回起動しないでください。重複起動はポート競合の原因になります。

システムのパッケージマネージャーでインストールする

ターミナルでダウンロードディレクトリに移動したら、パッケージマネージャーでローカルファイルをインストールできます。直接展開するよりも依存関係の処理やアンインストールが容易です。以下のワイルドカード指定は、ダウンロードディレクトリに対応アーキテクチャのv2rayNパッケージが1つだけあることを前提とします。複数ある場合は実際のファイル名を指定し、古いパッケージを選ばないようにしてください。依存関係を満たせないと表示された場合は、まずディストリビューションのパッケージソースを更新し、システムバージョンが現在もサポート対象か確認してから再度インストールします。

システムとアーキテクチャを確認：
cat /etc/os-release
uname -m

DebianまたはUbuntu系にインストール：
cd ~/Downloads
sudo apt install ./v2rayN*.deb

Fedoraまたはrpm互換ディストリビューションにインストール：
cd ~/Downloads
sudo dnf install ./v2rayN*.rpm

インストール完了後、デスクトップのアプリメニューからv2rayNを起動します。ターミナル起動時に共有ライブラリ不足が表示された場合は、ディストリビューションのパッケージマネージャーで依存関係を補ってください。不明な場所から単一のライブラリをコピーしてシステムディレクトリを上書きしないでください。プログラムは起動するのにコアを実行できない場合は、コアファイルに実行権限があるか、データディレクトリに書き込めるか、セキュリティポリシーが子プロセスを阻止していないかを確認します。アップグレード時は実行中のクライアントを終了してから新しいパッケージをインストールし、旧プロセスによるファイルやポートの占有を避けます。

サブスクリプションを登録し、デスクトップのシステムプロキシを設定する

サブスクリプションの追加、グループ更新、ノード選択、コア起動の順序は他のデスクトップOSと同じです。Linuxで異なるのは、すべてのデスクトップ環境が同じインターフェースをシステムプロキシに使うわけではない点です。GNOME、KDEなどではプロキシ設定の保存方式が異なり、v2rayNが現在のデスクトッププロキシへ自動書き込みできるかは環境の対応状況に左右されます。有効化後はデスクトップのネットワーク設定で、プロキシアドレスが本機を指し、ポートがクライアントのステータスバーと一致しているか確認してください。

多くのターミナルプログラムはデスクトッププロキシを自動的に読み取りません。現在のターミナルセッションのツールだけにローカルHTTPプロキシを使わせる場合は、環境変数を設定できます。ポートはクライアントに実際に表示されている値を使用してください。環境変数は現在のshellとその子プロセスにのみ有効で、ターミナルを閉じると無効になります。検証には適していますが、ポートが固定されていることを確認する前に全体の起動ファイルへ書き込まないでください。

現在のターミナルセッションにローカルプロキシを設定：
export http_proxy=http://127.0.0.1:10809
export https_proxy=http://127.0.0.1:10809

テスト後に解除：
unset http_proxy
unset https_proxy

TUN、権限、ネットワークマネージャーの境界

TUNモードは仮想ネットワークインターフェース、ルーティングテーブル、適切な権限に依存します。有効化前に/dev/net/tunが存在することを確認し、デフォルトルートを変更する他のネットワークツールを同時に実行しないでください。クライアントが権限不足を示した場合は、クライアントが用意するローカル許可手順に従います。デスクトップセッション全体をrootで常時実行しないでください。許可の目的は必要なネットワーク操作を認めることであり、すべてのクライアントファイルに最高権限を与えることではありません。

LinuxのDNSは、systemd-resolved、NetworkManager、デスクトップのネットワークマネージャー、その他のローカルサービスが管理している場合があります。TUN起動後に名前解決が異常になったら、まずip routeでルートが作成されたか確認し、次にresolvectl statusで現在のDNS管理元を確認します。コマンドがない場合は、ディストリビューションで使われているネットワークマネージャーを確認してください。トラブルシューティングでは、まずシステムプロキシモードに戻してノードを検証し、ノードが正常になってからTUNだけを有効にします。これにより、デスクトッププロキシ、コア接続、システムルーティングの問題を混同せずに済みます。

Android：v2rayNGとv2flyNGの設定

クライアントの選択とインストールアーキテクチャ

Androidではv2rayNGを第一候補とします。Xrayコアを使用し、VLESS、VMess、Trojan、REALITYなど一般的な設定に適しています。v2flyNGはV2Flyコアを使用し、対応するコアの動作が必要な場合の選択肢です。2つのクライアントを同じ端末にインストールすることはできますが、同時にVPNサービスを確立できるアプリは1つだけです。切り替える前に現在の接続を切断し、ステータスバーに古いサービスが残ったまま新しいクライアントが適用権限を取得できなくなるのを防ぎます。

近年の端末の多くはarm64パッケージを選べます。アーキテクチャを確認できない場合や、arm64パッケージのインストール時に非対応と表示された場合は、汎用版を使用します。インストール後の初回起動では、必要なネットワーク接続の許可を与えます。通知権限の有効化は接続状態の確認しやすさに影響しますが、ノードパラメータの正しさを決めるものではありません。システムがVPN接続の確立を求めて表示する確認ダイアログは、AndroidがローカルVPNインターフェースを通じてアプリの通信をクライアントに渡す標準的な手順です。

サブスクリプション、クリップボード、QRコードからのインポート

サブスクリプションを登録する際は、サブスクリプショングループに名前と完全なURLを追加して更新します。システムによってはアプリのバックグラウンドからのクリップボード読み取りが制限されるため、クリップボードからのインポートに失敗した場合は、追加画面で手動貼り付けを試します。QRコードは単一の共有設定のインポートに適しています。スキャン前に信頼できる提供元のQRコードか確認し、インポート後にプロトコル、アドレス、ポート、トランスポートパラメータが完全か確認してください。QRコードがぼやけていたり欠けていたりしても、サブスクリプションURLからのインポートには影響しません。

サブスクリプションの更新が成功したら、ノード一覧から設定を1つ選び、メイン画面に戻ります。複数のグループがある場合は、現在のノードが更新したグループに属しているか確認してください。ノードのメモは識別用で、接続には使われません。接続を決めるのは、アドレス、ポート、ユーザー識別子、プロトコル、トランスポート層、セキュリティ層、サーバー名などのパラメータです。手動編集時は先頭の数項目だけを比較しないでください。特にWebSocketパス、gRPCサービス名、TLSサーバー名、REALITY公開鍵、短い識別子のいずれかが欠けると、ハンドシェイクで接続に失敗することがあります。

VPNサービス、アプリごとのプロキシ、バックグラウンド制限

接続ボタンをタップすると、v2rayNGまたはv2flyNGがローカルVPNサービスを起動します。デスクトップのシステムプロキシとは異なり、アプリの通信はシステムの仮想ネットワークインターフェースに入り、クライアントがルールに従って直接接続またはプロキシ接続へ振り分けます。ステータスバーにVPNアイコンが表示されても、インターフェースが作成されたことを示すだけで、リモートノードが利用可能とは限りません。接続後はクライアントログを確認するか、対象サービスへ実際にアクセスして検証します。すぐに切断される場合は、設定の解析とコアの起動ログを重点的に確認してください。

アプリごとのプロキシでは、どのアプリをクライアントに通すかを制限できます。ホワイトリストモードは選択したアプリだけを処理し、ブラックリストモードは除外していないアプリを処理します。設定を誤ると、ブラウザーは使えるのに対象アプリがプロキシを経由しない、またはシステムコンポーネントまで意図せず対象になって異常が出ることがあります。初回接続では複雑なアプリ別ルールを使わず、基本接続を確認してから1つずつ追加してください。アプリ一覧を変更した後は再接続してVPNルートを再構築します。

Androidの省電力機能はバックグラウンドプロセスを制限します。画面消灯後しばらくして接続が切れ、アプリに戻ると復旧する場合は、システムのバッテリー設定でクライアントのバックグラウンド実行を許可し、強制休止リストから除外します。設定名はメーカーによって異なりますが、ロック画面後にクライアントプロセスが終了していないかが判断材料です。常駐通知はシステムとユーザーが接続状態を把握する助けになります。切断時にアプリを強制停止せず、クライアント内で切断をタップしてVPNインターフェースとルートを正常に解放してください。

アプリ別ルール、LAN、DNS

LAN内の機器へアクセスするには、プライベートアドレス帯を直接接続にする必要があります。家庭用ルーター、プリンター、ストレージ機器は通常192.168.0.0/16、10.0.0.0/8、172.16.0.0/12のいずれかにあります。グローバルプロキシを有効にしてこれらの機器へ接続できなくなった場合は、各機器にリモートルールを追加するのではなく、LANの直接接続ルールを含むルーティングモードへ変更します。モバイル通信とWi-Fiを切り替えると基盤接続が変わるため、クライアントの再接続が必要になることがあります。これはネットワーク経路の再構築であり、サブスクリプションの再登録は不要です。

AndroidのプライベートDNS、クライアントのDNS設定、ノードのドメイン解決は互いに影響することがあります。「アドレス形式では接続できるが、ドメイン形式では失敗する」場合は、まずクライアントのDNSを標準設定に戻し、追加のシステムDNS設定を一時的に無効にして比較します。一部のドメインだけ方向を誤る場合は、ルーティングルールがドメインに対して照合しているのか、解決後のアドレスに対して照合しているのかを確認します。プライベートDNS、クライアントDNS、ルーティングモード、ノードのセキュリティパラメータを同時に変更すると比較できなくなるため避けてください。

サブスクリプション、ノード、複数端末の設定管理

サブスクリプション更新はクライアント更新ではない

サブスクリプション更新、クライアント更新、コア更新は別々の作業です。サブスクリプション更新では既存URLからノード一覧を再取得し、ノードの追加、削除、変更が起こることがあります。クライアント更新はGUIと管理ロジックを更新し、コア更新はプロトコル実装と接続動作に影響します。トラブルシューティングでは、どの層を変更したかを必ず記録してください。サブスクリプション更新後に特定のノードが使えなくなった場合は、まずノードパラメータを比較するか、同じサブスクリプション内の別ノードを試します。コア更新後に複数の設定が同時に異常になった場合は、コアログと設定の互換性を確認します。

サブスクリプションは提供元ごとにグループ化し、分かりやすいメモを付けます。複数の提供元を追跡できない1つのリストにまとめたり、「デフォルト」「テスト」のように区別しにくい名前で複製を増やしたりしないでください。更新前に対象グループを確認し、更新後にノード数とメモが想定どおりか確認します。更新によってサーバー側で削除されたノードが消えることもあるため、サブスクリプション内のノードを手動変更しても次回更新で上書きされる場合があります。長期保存したい個別設定はローカルの独立設定へ複製してから編集します。

4つのインポート方法の使い分け

サブスクリプションURLは複数ノードと継続管理に、共有リンクは単一ノードの迅速な受け渡しに、QRコードは近くの端末へ少量の設定を移す際に、設定ファイルは入出力、ルーティング、DNSを含む比較的完全な構成の受け渡しに適しています。共有リンクは通常、単一の送信ノードだけを記述し、クライアント全体のルーティングポリシーまでは含みません。デスクトップからAndroidへコピーするとノードパラメータは保持できますが、システムプロキシ、アプリ別プロキシ、TUNなどのプラットフォーム設定は自動移行されません。

設定ファイルをインポートする際は、「クライアントのバックアップ」と「コア設定」を区別します。クライアントのバックアップにはグループ、UI設定、ローカルパスなどが含まれることがあり、同じクライアント体系でのみ適しています。コアのJSONは入出力やルーティングなどの基盤構造を記述しますが、GUIクライアントがすべてのカスタムフィールドを受け入れるとは限りません。インポートエラーが出たら、まずファイルの種類を判断し、任意のJSONをノードファイルとして扱わないでください。複数端末で同期する3つの一般的な方法と選び方はV2Ray設定を複数端末で同期する3つの方法を参照してください。

ノードパラメータの依存関係を理解する

プロトコルの項目だけで判断することはできません。VLESSとVMessにはサーバーアドレス、ポート、ユーザー識別子が必要で、Trojanはパスワード形式の認証情報を使います。トランスポート層にはTCP、WebSocket、gRPCなどがあり、セキュリティ層にはTLSやREALITYがあります。TLSでは通常、サーバー名が証明書検証に使われます。WebSocketではパスとリクエストホストをサーバー側と一致させ、gRPCではサービス名を一致させる必要があります。REALITY設定には公開鍵、サーバー名、短い識別子なども必要です。プロトコル名だけを変更し、合わないトランスポートパラメータを残しても、動作する設定にはなりません。

ノードのメモ、グループ名、速度測定の並び順はクライアント管理用の情報であり、プロトコルのハンドシェイクには関与しません。アドレスにはドメインまたはネットワークアドレスを指定できます。ドメインは先に解決されるため、DNSの問題は実際にサーバーへ接続する前に発生します。接続ログでドメイン解決失敗が表示されたら、まずDNSを確認します。接続拒否やタイムアウトなら、アドレス、ポート、ネットワーク経路を確認します。TLSまたはREALITYのハンドシェイク後に失敗する場合は、セキュリティ層のパラメータを重点的に確認します。ログを段階ごとに読む方が、漠然と「別のモードに変更する」より効果的です。

安全な保存と更新の進め方

サブスクリプションURLや共有リンクには、アクセスに必要な完全な情報が含まれることがあります。管理下にあるパスワードマネージャーや端末の安全なストレージに保存し、公開メモ、フォーラム投稿、画面録画、完全なログには書かないでください。他人にトラブルシューティング情報を渡す場合は、プロトコル、トランスポート、エラーの段階を残しても、サーバーアドレス、ユーザー識別子、パスワード、公開鍵関連の設定、サブスクリプションURLは隠します。クライアントログに宛先アドレスが記録されることもあるため、共有前に内容を確認してください。

更新頻度は実際の利用状況に合わせます。サブスクリプションを頻繁に更新しても接続品質は向上せず、サーバー側の一時的な異常時に現在の一覧が上書きされるおそれがあります。クライアントの定期更新を使うか、ノードが無効になったときや設定変更の通知を受けたときに手動更新してください。更新後は元の選択をいったん保持し、新しい一覧が使えることを確認してから切り替えます。同じサブスクリプションを複数端末で使う場合、すべてを同時に更新する必要はありませんが、削除済みの古いパラメータを長期間使い続けないようにします。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      }
    ]
  }
}

システムプロキシ、TUN、ルーティング、DNS

システムプロキシとTUNの本質的な違い

システムプロキシはOSにローカルプロキシアドレスを公開する仕組みで、その設定を自発的に読み取るアプリだけがクライアントへ要求を渡します。設定が簡単で影響範囲も分かりやすく、ブラウザーや一般的なデスクトップアプリに適しています。TUNは仮想ネットワークインターフェースでより広い範囲の通信を受け取り、コアが直接接続またはプロキシ接続を判断します。システムプロキシに対応しないプログラムも対象にできますが、ルーティングテーブル、DNS、権限、仮想インターフェースが関わるため、切り分ける層が増えます。

モードはアプリの要件に応じて選びます。ブラウザー、オフィスソフト、明確にプロキシ対応しているツールだけなら、まずシステムプロキシを使います。システムプロキシを無視するプログラムがある、またはより多くの通信を統一的に処理したい場合にTUNを有効にします。AndroidクライアントはシステムVPNサービスで通信を適用するため、デスクトップのTUNに似た面がありますが、権限とルーティングはモバイルOSが管理します。複数のクライアントにシステムプロキシの変更や仮想インターフェースの作成を同時にさせないでください。通信がループしたり、誤転送されたり、予測できない出口へ流れたりする可能性があります。

ルーティングルールの照合方法

ルーティングルールは通常、ドメイン、ネットワークアドレス、ポート、プロトコル、入 inboundタグなどで要求を照合し、プロキシ、直接接続、ブロックのいずれかへ送ります。ルールに順序がある場合、先に一致した要求は後ろの汎用ルールへ進みません。そのためカスタムルールは具体的な条件から広い条件へ並べ、最後にデフォルトの出口を置きます。LANとプライベートアドレスは通常、ルーター、プリンター、ローカルサービスへのアクセスがリモートノードを経由しないよう、先に直接接続へ振り分けます。

ドメイン照合とネットワークアドレス照合は異なる段階で行われます。domain:、full:、ルールセットを使う場合、コアは要求中のドメインに基づいて方向を決められます。アプリがネットワークアドレスへ直接アクセスする場合、ドメインルールは適用されません。ポリシーによってはドメインを先に解決し、その結果のアドレスで照合します。domainStrategyの変更はこの処理に影響するため、まず現在のルールの出所を理解し、汎用的な高速化スイッチとして扱わないでください。

DNSとルーティングの連携が必要

DNSはドメインを接続可能なアドレスへ変換し、ルーティングはDNS要求とその後の接続をどの出口へ送るかを決めます。両者が一致しないと、現在の出口に適さないアドレスへ解決されたり、DNS要求自体が誤った経路で遮断されたりします。よくある症状は、ノード接続テストには反応があるのにWebサイトのドメインが開けない、特定のドメインだけ何度もタイムアウトする、ネットワークアドレスへ切り替えると状況が変わる、TUN有効化後にすべてのドメインが同時に使えなくなる、といったものです。

DNSを切り分けるときは、まずクライアントの標準設定に戻し、ノードと基本ルーティングが動作することを確認します。その後、OS上に他のDNSツールがないか、ブラウザーのセキュアDNSや企業ネットワークのポリシーが影響していないかを確認します。主な制御層は一度に1つだけ残してください。カスタム設定が必要な場合は、直接接続するドメインにローカルから到達できるリゾルバーを使い、プロキシ方向のドメインはクライアントの方式で処理できます。ただし具体的なルールは現在のコアの機能に合わせる必要があります。出所不明のDNS設定を大量にコピーしないでください。待ち受けアドレス、送信タグ、ルーティングタグが本機の設定と一致しない可能性があります。

通信が実際にどこへ向かっているか確認する

振り分けの確認はクライアントのアイコンだけでは不十分です。まずコアのログに対象ドメインまたはアドレスと、選択された送信タグが出ているか確認します。次に現在のルーティングルールと照合し、想定した条件に一致しているか確認します。ログに対象要求がまったくない場合、アプリがクライアントに入っていません。システムプロキシ、環境変数、アプリ別プロキシ、TUNの適用層に戻って確認します。ログに要求はあるが方向が間違っている場合は、ルールの順序を修正します。方向が正しいのに接続できない場合は、ノードとネットワーク経路を確認します。

グローバルモードへの一時的な切り替えは比較検証に使えます。同じノードがグローバルモードでは使えるのにルールモードでは使えない場合、問題は通常ルーティングまたはDNSにあります。どちらのモードでも使えない場合は、ノード、コア、基本ネットワークを優先して確認します。比較後は元のモードに戻し、現在のノードへ再接続してください。グローバルモードを長期的な解決策にすると、ルールの誤りを隠し、本来直接接続すべきLANや一般的な要求の経路まで変えてしまいます。

設定管理とよくあるトラブルシューティング

段階的な切り分け手順を作る

トラブルは「基本ネットワーク、クライアントプロセス、コア起動、ノード接続、通信の適用、ルーティングとDNS、対象アプリ」の順に層ごとに確認します。まず端末自体が現在のネットワークへ接続でき、認証が必要なネットワークへのログインを完了しているか確認します。次にクライアントがシステムによって終了させられていないこと、コアプロセスがローカルで待ち受けていることを確認します。その後ノード接続を検証し、最後にシステムプロキシ、TUN、アプリ別ルール、対象プログラムの動作を確認します。各層を通過してから次へ進むことで、ノードが無効なときにDNSを何度も変更したり、アプリがプロキシに入っていないのにノードを盲目的に切り替えたりするのを防げます。

ログが主な判断材料です。起動時の設定解析エラーは、通常フィールドまたは形式の問題を示します。待ち受け失敗はポート競合や権限不足が原因になりがちです。ドメイン解決エラーは接続先へ到達する前の問題です。接続タイムアウトはアドレス、ポート、経路、リモート側の状態が関係することがあります。TLS、REALITY、WebSocket、gRPCなどのハンドシェイクエラーでは、該当するセキュリティ層とトランスポート層のパラメータを確認してください。最後の1行だけでなく、エラーが発生した段階を記録する方が有用です。

サブスクリプションの更新失敗、またはノードが表示されない

サブスクリプションの更新に失敗したら、まず設定画面でURLが完全か、空白や改行が入っていないかを確認し、更新ログのレスポンス状態と解析結果を確認します。現在のネットワークからサブスクリプションURLへアクセスできない場合は、基本ネットワークとDNSを確認します。内容を取得できても解析に失敗するなら、内容形式がクライアントの想定と一致していません。通常のWebページURLをサブスクリプションURLとして使ったり、理解できないエンコード内容を手動で変更したりしないでください。

ログに更新成功と表示されても一覧にノードがない場合は、現在のグループフィルター、検索欄、サブスクリプショングループの選択を確認します。古い検索キーワードによって新しいノードがすべて隠れていることがあります。ノードが表示された直後に消える場合は、再更新時にサーバーが新しい一覧を返し、古い項目を削除した可能性があります。手動で保持したい設定はローカルグループへ複製し、サブスクリプション同期による上書きを防ぎます。複数端末で結果が違う場合は、最終更新時刻と使用中のクライアント・コアを比較し、ノードのメモだけで判断しないでください。

接続成功と表示されるのにアプリが使えない

クライアントに接続済みと表示されても、対象アプリが必ずプロキシに入るとは限りません。デスクトップのシステムプロキシモードでは、まずシステムプロキシに従うブラウザーで確認します。コマンドラインツールでは環境変数または独自のプロキシ引数を確認し、Androidではアプリ別プロキシの一覧を確認します。TUNモードでは仮想インターフェースとルーティングを確認します。ログに対象アプリの要求がまったくなければ、問題は適用層にあります。ログに要求がありプロキシ出口へ進んでいるなら、対象ドメインの解決、ノードの経路、アプリのプロトコルを確認します。

一部のWebサイトだけ異常な場合は、一時的にグローバルモードで比較します。グローバルモードで正常なら、ルール照合とDNSを確認します。それでも異常なら、同じサブスクリプション内の別ノードを試して、ノードとローカル設定を切り分けます。速度が遅い場合は、ノード自体、中継経路、ローカル設定の3層に分けて対処し、複数の「最適化」項目を同時に有効にしないでください。段階的な方法はV2Rayの速度低下を層別に切り分ける方法を参照してください。

起動失敗、ポート競合、残ったプロキシ

コアが起動直後に停止する場合は、まずローカルポートの使用状況を確認します。他のプロキシクライアントと重複するv2rayNを終了し、古いコアプロセスが残っていないか確認します。ポートを変更する場合は、システムプロキシや環境変数で参照しているポートも同時に更新します。一方だけ変えると、システムが古いアドレスへ接続し続けます。権限エラーでは、プログラムフォルダーに書き込めるか、コアファイルを実行できるか、TUN操作に必要な許可を得ているかを確認します。設定ディレクトリを読み取り専用媒体や自動的に元へ戻る一時領域に置かないでください。

クライアントが異常終了した後も、システムプロキシがローカルの待ち受けポートを指し続けることがあります。典型的には、システムプロキシに従うすべてのプログラムが使えなくなり、プロキシを無効にすると直ちに復旧します。この場合はOSのネットワーク設定でプロキシを解除するか、クライアントを再度開いて「システムプロキシを解除」を実行します。TUNが残っている場合は、仮想インターフェースとルートが解放されたか確認し、必要ならクライアントを正常起動してから切断します。端末の再起動で一時状態を消せることもありますが、復旧後は異常終了の原因をログから引き続き確認してください。

クライアント、コア、設定を更新する順序

管理時に3種類の更新を同時に行わないでください。まず現在使えるノード、ルーティングモード、適用方式を記録し、クライアントだけを更新して起動を確認します。続いて必要に応じてコアを更新し、既存ノードを検証します。最後にサブスクリプションを更新します。どの段階で問題が起きたか明確になり、直前の状態へ戻って確認できます。クライアントを更新する前には正常終了し、Androidでは更新前にVPNサービスを切断します。デスクトップで複数バージョンを退避用に残す場合は、それぞれ別ディレクトリを使用し、同時に起動するインスタンスは1つだけにします。

失効したローカル複製、重複サブスクリプション、長期間使わないカスタムルールは定期的に整理します。ルールが増えるほど優先順位の衝突を判断しにくくなります。安定した設定は説明可能な状態に保ちます。各サブスクリプションの提供元、現在のコアを選んだ理由、システムプロキシまたはTUNを有効にした理由、直接接続を担当するルールを把握しておきます。初回インストールと基本設定はv2rayN初回インストール設定ガイドでも確認できます。最短手順をもう一度進めるだけなら、クイックスタートガイドへ戻ってください。