// ALL PLATFORM REFERENCE

v2rayN全プラットフォームのインストール・設定完全ガイド

Windows、macOS、Linux、Androidのダウンロード、インストール、サブスクリプション登録、システムプロキシ、TUN、ルーティング、ログ確認を解説。システム別の手順で、長期的に参照できる実用マニュアルです。

4プラットフォーム v2rayN / v2rayNG / v2flyNG サブスクリプション · ルーティング · TUN 2026-08-15更新

クライアントのインストーラーを選択まずはクイックスタートを見る

使い方ガイドでは、初回接続に適した最短手順を紹介します。本ページでは、プラットフォームごとの差異、パラメーターの意味、モードの適用範囲、トラブル対応の順序を詳しく説明します。基本設定が済んでいる場合は、目次から該当する章へ直接進めます。

// CONTENT MAP

章一覧

// 01 · PREPARE

共通の準備と設定上の注意点

クライアントをインストールする前に、プラットフォーム、CPUアーキテクチャ、サブスクリプションの入手元、通信を取り込む範囲を確認します。インストール失敗の多くはクライアント自体ではなく、インストーラーのアーキテクチャ違い、旧プロセスによるポート占有、システム時刻のずれ、サブスクリプションとサーバー側パラメーターの不一致が原因です。事前にこれらの変数を整理しておくと、4つのプラットフォームでの作業が明確になります。

クライアントとプラットフォームの対応

デスクトップでは v2rayN を共通して使用します。Windows、macOS、Linuxに対応し、サブスクリプショングループ、サーバー一覧、システムプロキシ、TUN、ルーティングルール、ログ確認などのGUI操作を提供します。Androidでは Xray カーネルを使用する v2rayNG が第一候補です。v2fly カーネルが必要な場合は v2flyNG を選択できます。2つのAndroidクライアントは画面構成や設定のインポート方法が近い一方、カーネルの機能、実験的な項目、設定の互換範囲が異なる場合があります。同じ高度な設定を完全に同等とみなして、そのまま移行しないでください。

インストーラーのアーキテクチャは、端末のCPUに合わせる必要があります。Windowsの一般的な端末では x64 を選択します。macOSでは Apple Silicon か Intel かを先に確認します。LinuxではCPUアーキテクチャに加えて、ディストリビューションに応じて deb または rpm を選びます。近年のAndroidスマートフォンは通常 arm64 ですが、確認できない場合は汎用版を選択します。本サイトのインストーラーページでは、プラットフォームとアーキテクチャ別に入口を分けているため、ファイル名の一覧から推測する必要はありません。

プラットフォーム	推奨クライアント	インストーラーの選び方	主な取り込み方式
Windows	v2rayN	x64デスクトップ版または従来型WPF版	システムプロキシ、TUN
macOS	v2rayN	Apple Silicon arm64またはIntel x64	システムプロキシ、TUN
Linux	v2rayN	deb / rpm と x64 / arm64	デスクトッププロキシ、環境変数、TUN
Android	v2rayNG	arm64または汎用版	システムVPNインターフェース

サブスクリプション、単一ノード、ローカル設定

サブスクリプションURLは、更新可能なリモートノード一覧です。クライアントにURLを保存すると、サブスクリプショングループごとにサーバー名、プロトコル、ポート、通信パラメーターを取得します。単一ノードのリンクは、一時的なインポートや特定パラメーターの検証に適しています。ローカルのJSON設定は、詳細なルーティング、複数のアウトバウンド、複雑なDNSポリシーに向いています。3つの方法は目的が異なります。日常利用ではサブスクリプショングループを優先して保持し、更新のたびに手入力を繰り返さないようにします。高度なルールを試す場合は、既存設定を独立したグループにコピーし、テスト変更が安定した設定を上書きしないようにします。

サブスクリプションURLには通常、アクセス用の認証情報が含まれるため、アカウント情報と同様に管理してください。完全なURLを公開ログ、スクリーンショット、オンライン変換ページに貼り付けないでください。V2Rayサブスクリプション変換を行う場合は、変換サービスの提供元と出力形式を確認し、変換後も protocol、security、network、flow、SNI、公钥などの重要フィールドが保持されているか確認します。変換で変わるのはクライアントが読み取る表現形式だけであり、サーバーとクライアント間のパラメーター差異が自動的に修正されるわけではありません。

接続前の環境チェック

まずシステムの日付、時刻、タイムゾーンを合わせます。TLSとREALITYのハンドシェイクは時間の許容範囲に依存するため、大きなずれがあるとノードが常にタイムアウトすることがあります。次に旧クライアントを終了し、ローカルプロキシポートが別のプロセスに占有されていないか確認します。さらにセキュリティソフトとシステムファイアウォールが、クライアントやカーネルによるローカル待ち受けと外部接続を許可しているか確認します。最後に、正常にアクセスできるサブスクリプションURLを用意し、アカウント状態、通信量、有効期限を確認します。ノード名が表示されるのはサブスクリプションの内容を読み取れたことを示すだけで、現在接続できるとは限りません。

接続確認は、カーネルが正常に起動したか、ローカルプロキシポートが待ち受けているか、アプリの通信がプロキシに入っているかの3段階に分けます。Webページが開くかどうかだけでは、どの層に問題があるか特定しにくいからです。ログに起動完了が表示されているのにブラウザーの通信がない場合は、システムプロキシまたはブラウザー独自のプロキシを確認します。ローカルポートが開かれていない場合は、設定の解析、ポート競合、カーネルファイルの権限を先に確認します。ハンドシェイク段階で失敗する場合は、サーバーパラメーターと端末の時刻を再確認します。

更新とバックアップの原則

クライアントを更新する前に、サブスクリプショングループ、カスタムルーティング、DNSルール、ローカル設定をエクスポートまたはバックアップします。デスクトップでは現在のシステムプロキシモードとローカル待ち受けポートも記録します。世代の異なる大規模なUI更新では旧設定を移行できることが多いものの、フィールドの初期値が変わる場合があります。初回起動後は主要設定をページごとに確認してください。Androidでは更新前にサブスクリプションURLが取得できることを確認し、アプリ内に展開済みの一時ノードだけに依存しないようにします。

このガイドでは、インストール完了後にクライアントを起動し、サブスクリプションを登録してグループを更新し、ノードを選んでカーネルを起動し、その後にシステムプロキシまたはTUNを決め、最後にログと実際の通信を確認する、という順序で進めます。順序を固定すると、複数の変数を同時に変更せずに済みます。初回設定を10分ほどで終えたい場合はv2rayN使い方ガイドへ進み、各設定の意味を理解したい場合はプラットフォーム別の章を読み進めてください。

// 02 · WINDOWS

Windows：v2rayNのインストール、サブスクリプション、システム連携

Windowsは、v2rayNの機能を最も幅広く利用できるプラットフォームです。インストール時にデスクトップ版と従来型WPF版を選び、接続後は対象アプリの範囲に応じてシステムプロキシまたはTUNを設定します。2つはUIの実装が異なりますが、サブスクリプション、ノード、ルーティング、カーネルログの基本概念は共通しています。

デスクトップ版と従来型WPF版を選ぶ

デスクトップ版は新世代のクロスプラットフォームUIを採用し、異なるデスクトップOSで似た操作構成を使いたいユーザーに適しています。従来型WPF版は成熟したWindows向けの画面構成を引き継ぎ、従来のサーバー一覧、トレイメニュー、設定画面に慣れているユーザーに向いています。両方を同時に実行する必要はありません。比較テストを行う場合は、先に使っていたクライアントを終了し、システムプロキシが復元されているか確認してください。そうしないと、2つ目のクライアントが同じポートを引き継ぎ、ログと実際の通信の出所が分かりにくくなります。

Windowsのインストールページから対応するインストーラーを取得し、セットアップウィザードに従ってインストールします。初回起動時にネットワークアクセスやファイアウォールの確認が表示されたら、現在使用しているネットワークの種類でクライアントの通信を許可します。インストール先とユーザー設定フォルダーには、通常の読み書き権限が必要です。企業管理端末では、プロキシ設定、仮想NIC、ドライバーのインストールが制限される場合があります。このような制限は端末ポリシー側で対処する必要があり、クライアントを再インストールしても回避できません。

サブスクリプションを登録してグループを整理する

サブスクリプショングループの管理画面で、分かりやすい名前のグループを追加し、サブスクリプションURLを該当欄に入力して保存します。その後、現在のグループを更新します。更新に成功するとサーバー一覧にノードが表示されます。グループは存在するのに一覧が空の場合は、まずログでHTTPステータス、解析エラー、形式に関するメッセージを確認します。短時間に更新ボタンを連続して押さないでください。一部のサブスクリプションサービスでは、短時間のリクエスト回数が制限されます。更新前後でノード数が変わるのはサーバー側の一覧変更によるもので、クライアントが勝手にノードを作成したわけではありません。

サーバー一覧には、名前、アドレス、ポート、プロトコル、通信方式、セキュリティ層、サブスクリプショングループなどの主要列を残すと便利です。ノードを選ぶ際は、名前に含まれる地域や回線の説明だけを頼りにせず、実際に接続してハンドシェイクログを確認します。遅延テストで分かるのは、そのテスト方法におけるネットワーク到達性だけで、対象アプリのすべての通信経路を保証するものではありません。安定したノードを確認したら、アクティブサーバーに設定してからシステムプロキシまたはTUNを起動します。

単一ノードを手動で登録する場合は、クリップボードから標準の共有リンクを読み込むか、サーバー編集画面で各項目を入力します。REALITYノードでは、serverName、fingerprint、publicKey、shortId、flowに特に注意してください。共有リンクをインポートしても接続できない場合は、フィールドをサーバー側の情報と1つずつ比較し、セキュリティ設定を無作為に切り替えないでください。

システムプロキシモードの適用範囲

システムプロキシは、Windowsのプロキシ設定に従うブラウザーやデスクトップアプリに適しています。有効にすると、v2rayNがシステムプロキシをローカルの待ち受けアドレスとポートへ向け、アプリの通信をクライアント経由で転送します。通常は「システムプロキシを自動設定」などの状態を維持し、ブラウザーで確認します。システムプロキシを無視するプログラムでは、プログラム側でHTTPまたはSOCKSのアドレスを指定するか、TUNを使用します。

システムプロキシのルーティングモードによって、どの宛先をプロキシへ送るかが決まります。グローバルモードはノードが動作するか短時間で確認するのに便利ですが、複雑な分割ルーティングの最終設定には向きません。ルールモードでは、ドメイン、IP、geosite、geoipのルールに基づいて、直接接続、プロキシ、ブロックを選択します。モードを変更したら新しい接続を開始してください。既存の長時間接続が以前の経路を使い続ける場合があります。クライアントを終了する前にシステムプロキシを復元するのは良い習慣です。特にネットワークの切り替えやスリープ復帰を頻繁に行う端末では重要です。

TUNモードと権限

TUNは仮想ネットワークインターフェースを通じて、より広範な通信を取り込みます。システムプロキシを参照しないアプリ、コマンドラインツール、通信を一元的に分割したい場面に適しています。初回有効化では通常、管理者権限が必要で、仮想NICやネットワークコンポーネントのインストールが発生することがあります。有効にする前に、同種のネットワークツールを終了し、複数の仮想インターフェースが同時にデフォルトルートを変更しないようにします。有効化後はTUNの状態、DNSの待ち受け、ルーティングログを確認し、通信が実際に現在のカーネルへ入っていることを確認します。

TUNを有効にしても、すべての接続が自動的に利用可能になるわけではありません。LAN、仮想マシン、開発コンテナ、リモートデスクトップ、企業内ネットワークでは、特定のルートが必要な場合があります。有効化後にローカル端末へアクセスできなくなった場合は、プライベートアドレス帯を直接接続にし、厳密ルーティング、自動ルーティング、DNSハイジャックの設定を確認します。TUNを無効にしてもすぐにネットワークが戻らない場合は、まずクライアントを完全に終了し、現在のネットワークアダプターを無効化してから再度有効にします。原因を特定する前に、すべてのネットワーク設定を同時にリセットしないでください。

ログ、トレイ、起動動作

v2rayNのメインログでは、設定生成、カーネル起動、ローカルポート、エラー情報を確認できます。トラブル対応では、まず古いログを消去してから問題を再現し、前回のノードのエラーを今回の結果と混同しないようにします。主な確認項目は、ポート占有、設定フィールドの解析失敗、DNSリクエスト失敗、接続タイムアウト、ハンドシェイク中断です。ログでカーネルが正常に起動している場合は、次にシステムプロキシとルーティングを確認します。カーネルが繰り返し終了する場合は、設定ファイルと権限に戻って確認します。

トレイメニューでは通常、システムプロキシ、現在のサーバー、アプリの終了をすばやく切り替えられます。メインウィンドウを閉じてもプロセスが終了するとは限らないため、バージョン変更やポート確認の際はトレイから明示的に終了します。スタートアップを有効にする前に、デフォルトノード、サブスクリプションの更新動作、取り込みモードが想定どおりか確認します。家庭、職場、モバイルホットスポットを頻繁に切り替える端末では、ログイン後に現在のネットワークに合わないルーティングをそのまま使わないよう、取り込みモードを手動で確認する手順を残しておくことをおすすめします。

// 03 · MACOS

macOS：チップの選択、権限、プロキシ設定

macOS版のv2rayNは他のデスクトップ版と主要機能を共有しますが、インストーラーはCPUアーキテクチャに合わせる必要があります。初回起動では、アプリの確認、ネットワーク設定、TUN権限も関係します。まずシステム側の許可を処理してからノードやプロトコルの問題を確認すると、無駄な再インストールを減らせます。

CPUを確認してインストールする

「システム情報」または「このMacについて」を開き、チップ名を確認します。Appleチップと表示された場合は arm64 インストーラー、Intelプロセッサと表示された場合は x64 インストーラーを選択します。アーキテクチャを間違えるとアプリが起動しない、または互換変換を介して動作しても不安定になることがあります。macOSのインストールページから対応するDMGをダウンロードし、開いたウィンドウの案内に従ってアプリを「アプリケーション」フォルダーへ移動してから、そのフォルダーから起動します。

初回起動時には、システムがアプリの入手元やネットワークアクセスの確認を求める場合があります。システム設定のセキュリティ案内に従って確認を完了し、アプリを異なる場所へ何度もコピーしないでください。複数のコピーがあると、設定場所、自動起動項目、現在実行中のバージョンを判断しにくくなります。更新後も古い画面が表示される場合は、アクティビティモニタで旧プロセスが終了していることを確認し、「アプリケーション」フォルダーから新しいコピーを起動します。

サブスクリプションの登録とサーバー選択

サブスクリプション管理を開き、グループを新規作成してURLを保存し、グループを更新します。ノードが表示されたら、まず設定内容が明確なサーバーをアクティブノードに選びます。更新に失敗する場合は、現在のネットワークからURLへアクセスできるか、URLが完全にコピーされているか、システムの日付が正確かを確認します。サブスクリプションリンクに特殊文字が含まれている場合は、完全な形で貼り付け、クエリパラメーターを自分で削除・変更しないでください。

macOSでのノードパラメーター確認はWindowsと同じです。VLESSではユーザー識別子、暗号化フィールド、トランスポート層、flowを確認します。REALITYではserverName、fingerprint、publicKey、shortIdも確認します。WebSocketやgRPCでは、パス、ホスト名、serviceNameを一致させる必要があります。ある端末でノードが使えても、それはサーバー全体へ到達できることを示すだけで、現在の端末へのインポート結果にフィールド漏れがないとは限りません。

システムプロキシとアプリの違い

システムプロキシを有効にすると、v2rayNは現在のネットワークサービスのプロキシ設定を変更します。多くのブラウザーやシステムのネットワークフレームワークに従うアプリは、この設定を自動的に使用します。コマンドラインプログラム、開発ツール、一部のクロスプラットフォームアプリは独自のプロキシ環境変数を参照するか、システムプロキシを完全に迂回する場合があります。取り込み状況を判断する際はクライアントログも確認します。対象アプリで新しいリクエストを発生させてもログに接続記録がなければ、通信はまだv2rayNに入っていません。

ターミナルの一時的なプロキシは、v2rayNのローカルHTTP待ち受けポートを明示的に指定できます。ポートはクライアントの設定画面に表示される値を使用してください。以下の例では、環境変数の書き方を示すため、一般的なローカルアドレスを使います。

export HTTP_PROXY=http://127.0.0.1:10809
export HTTPS_PROXY=http://127.0.0.1:10809
export ALL_PROXY=socks5://127.0.0.1:10808

# 現在のターミナルセッション終了後は保持されません
unset HTTP_PROXY HTTPS_PROXY ALL_PROXY

ポートを確認しないまま、例をshell設定へ長期間書き込まないでください。後からクライアントのポートを変更すると、古い環境変数によってターミナルが使えないポートへ接続し続けることになります。継続的に使用する場合は、ポート変更の記録とv2rayNの設定を同期させ、クライアント終了時にはプロキシ環境変数を明示的に解除します。

TUN、DNS、システムの許可

TUNモードは、システムプロキシに従わないアプリの通信を取り込むのに適しています。初回有効化では、システムが管理者の認証やネットワーク拡張の許可を求める場合があります。許可した後は、メニューバーのネットワーク状態とv2rayNのログを確認し、仮想インターフェースが作成されていることを確認します。ルーティングやDNSを変更する別のツールも動作している場合は、先に終了し、取り込み役を1つだけにします。複数のツールが同時にデフォルトルートを書き換えると、Webページが時々開く、LANが切断される、DNSリクエストがループするといった現象が起こります。

DNS設定はルーティングポリシーと合わせて理解する必要があります。ドメインを先に解決してからIPで照合する場合と、ドメインルールを直接照合する場合では、結果が異なることがあります。FakeDNSを使う場合は、対象アプリやLANサービスがこのマッピング方式に適しているか確認してください。アドレスマッピングの保持とTUNの適用範囲については、FakeDNS仮想DNSマッピングの仕組みも参照できます。LANプリンター、ファイル共有、開発端末の検出に問題がある場合は、まずプライベートアドレスとローカルドメインを直接接続にし、高度なDNS機能を一時的に無効にして比較します。

スリープ、ネットワーク切り替え、終了後の復元

ノートPCがスリープから復帰したり、無線ネットワークを切り替えたりすると、既存の接続、DNSキャッシュ、デフォルトルートが無効になっていることがあります。その場合は、現在の接続を停止してからノードを選び直し、再起動します。システムプロキシの向き先が正しいのに通信がない場合は、クライアントを再インストールするよりカーネルを再起動する方が効果的です。会社のネットワークから家庭のネットワークへ切り替えた場合は、社内ネットワーク向けに設定した直接接続ルールが現在の用途にも合っているか確認します。

v2rayNを終了する前に、システムプロキシまたはTUNを無効にし、通常のネットワーク経路へ戻します。プロセスを強制終了した後にネットワーク異常が起きた場合は、システムのネットワーク設定を開き、現在のネットワークサービスのHTTP、HTTPS、SOCKSプロキシがローカルポートを指したままになっていないか確認します。残った設定を確認してから無効にし、ネットワークサービス全体を削除しないでください。アプリが起動すること、カーネルが動作すること、システムプロキシが復元することが、macOSでのインストール完了後に確認すべき3つの独立した項目です。

// 04 · LINUX

Linux：パッケージのインストール、デスクトッププロキシ、TUN

Linux版v2rayNはデスクトップ環境を対象としています。インストール時にはディストリビューションのパッケージ体系とCPUアーキテクチャを確認し、起動後はデスクトップのシステムプロキシ、ターミナルの環境変数、TUNという3つの通信入口を区別します。ディストリビューションによってメニュー名は異なりますが、トラブル対応の考え方は共通です。

deb、rpm、CPUアーキテクチャを選ぶ

Debian、Ubuntuおよび一般的な派生システムでは通常 deb を使用し、Fedora、Rocky Linux、AlmaLinuxなどでは rpm を使用します。一般的なデスクトップ向けx86-64 CPUでは x64 を選び、arm64端末では対応するアーキテクチャを選択します。以下のコマンドでアーキテクチャとシステム情報を確認できます。

uname -m
cat /etc/os-release

x86_64はx64、aarch64は通常arm64に対応します。確認後、Linuxのインストールページからパッケージを選択します。ディストリビューションのデスクトップ画面だけでパッケージ形式を判断したり、異なるアーキテクチャのパッケージを現在のシステムへ強制インストールしたりしないでください。パッケージマネージャーで依存関係の問題が報告された場合は、まずディストリビューションのソフトウェアリポジトリのメタデータを更新し、その後パッケージマネージャーに依存関係を処理させます。

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

ダウンロード先のディレクトリで、debはapt、rpmはdnfにインストールさせます。実際のファイル名はダウンロード結果に合わせてください。以下のコマンドでは、現在のディレクトリにある明示的なパッケージファイルをインストールします。

# Debian / Ubuntu 系
sudo apt update
sudo apt install ./v2rayN-linux-x64.deb

# Fedora / Rocky Linux 系
sudo dnf install ./v2rayN-linux-x64.rpm

ファイルを解凍するだけでなくパッケージマネージャーを使うと、デスクトップエントリー、依存関係、アンインストール情報を一貫して管理できます。インストール後はアプリケーションメニューからv2rayNを起動します。ターミナルで表示環境が見つからない場合、現在のセッションがグラフィカルデスクトップではない可能性があります。v2rayNはGUIクライアントであり、デスクトップでの起動方法をそのままヘッドレスサーバーのサービスとして扱わないでください。リモートデスクトップ環境では、現在のユーザーにグラフィカルセッションとユーザー設定ディレクトリへの書き込み権限があることも確認します。

アプリ起動後すぐに終了する場合は、ターミナルから一度起動して標準エラーを読み取り、ユーザーログディレクトリも確認します。よくある原因は、グラフィックライブラリの不足、インストーラーのアーキテクチャ違い、設定ディレクトリの権限異常、旧プロセスの残留です。権限問題を避けるために、クライアント全体を管理者権限で常用しないでください。ユーザー設定ファイルの所有者が変わり、TUN以外にも不要な権限範囲が広がります。

サブスクリプション管理とデスクトップのシステムプロキシ

サブスクリプショングループを作成し、URLを貼り付けて保存してから更新します。ノード一覧が生成されたらアクティブサーバーを選び、まずカーネルだけを起動してTUNは有効にせず、v2rayNのログでローカルHTTPとSOCKSの待ち受けが確立したことを確認します。その後、v2rayNでシステムプロキシを設定します。GNOME、KDEなどのデスクトップ環境ではシステムプロキシの保存方式が異なり、デスクトッププロキシを読むアプリもあれば環境変数だけを読むアプリもあります。1つのブラウザーの結果だけでシステム全体を判断しないでください。

デスクトッププロキシを有効にしたら、システム設定でHTTP、HTTPS、SOCKSがローカルを指しているか確認できます。ターミナルツールでは、必要に応じて現在の待ち受けポートを環境変数へ設定します。デスクトップメニューから起動したGUIプログラムは、ターミナルの環境変数を引き継がない場合があります。同じターミナルから起動したプログラムは通常引き継ぎます。トラブル対応では、アプリがどのセッションから起動されたかを記録し、環境変数が正しく見えても実際のプロセスが読んでいない事態を避けます。

TUN、権限付与、ルーティング

LinuxのTUNでは、仮想インターフェースの作成、ルートの追加、DNSの処理が必要で、関連操作にはシステム権限が必要です。クライアントが提供する権限付与フローを優先し、プログラム全体に永続的な管理者権限を安易に与えないでください。有効化前に、他のVPNインターフェース、コンテナネットワーク、仮想マシンのブリッジ、ポリシールーティングがないか確認します。開発用ワークステーションのネットワーク構成は一般的なデスクトップより複雑なことが多く、自動ルーティングがコンテナからホストへのアクセス、LANサービスの検出、リモート保守接続に影響する場合があります。

TUNを有効にした後、ip addressとip routeでインターフェースとルートの変化を確認し、v2rayNのログと合わせて通信がカーネルへ届いているか判断します。

ip address
ip route
ss -lntup | grep -E '10808|10809'

最後のコマンドのポートは一般的な例にすぎないため、実際にはクライアントが現在待ち受けているポートへ置き換えます。TUNインターフェースは存在するのにドメインを解決できない場合は、DNSの待ち受け、システムリゾルバー、ディストリビューションが使用するネットワーク管理サービスを確認します。IP接続は正常でドメインだけ失敗する場合はDNSに絞って確認します。すべての宛先でログが出ない場合は、デフォルトルートが仮想インターフェースへ入っているかを確認します。LANだけ失敗する場合は、プライベートアドレスの直接接続ルールを追加します。

更新、アンインストール、設定ディレクトリ

新しいパッケージで更新する前にv2rayNを終了し、サブスクリプション、カスタムルーティング、DNS設定をバックアップします。同じパッケージマネージャーで新しいパッケージをインストールすれば、通常はユーザー設定が引き継がれます。更新後の初回起動では、ローカルポートと取り込みモードを確認します。旧プロセスが終了していないと、設定ロックやポート占有によって新しいプログラムが正常に起動しない場合があります。システムモニターやプロセス一覧で確認してから、旧プロセスを終了するか判断してください。

パッケージのアンインストールとユーザー設定の削除は別の操作です。パッケージマネージャーでアプリを削除しても、ユーザーディレクトリの設定は残り、後から復元できる場合があります。トラブル対応の最初から設定ディレクトリ全体を削除するのはおすすめしません。問題の特定に役立つログやルールも同時に失われるためです。より安全なのは、設定をエクスポートしてプログラムを終了し、現在の設定ディレクトリの名前を変更してから、クリーンな環境で比較する方法です。クリーンな環境で使える場合は、サブスクリプションとルールを少しずつ戻すことで、異常を引き起こした箇所を特定できます。

// 05 · ANDROID

Android：v2rayNGのインポート、接続、アプリ別ルーティング

Androidでは Xray カーネルを使用する v2rayNG を第一候補とし、v2fly カーネルが必要な場合は v2flyNG を選択します。モバイル端末はシステムVPNインターフェースで通信を取り込むため、デスクトップのシステムプロキシは使用しません。権限、バッテリー設定、バックグラウンド制限、アプリ別ルーティングが、デスクトップとの大きな違いです。

arm64または汎用インストーラーを選ぶ

近年の主流Androidスマートフォンでは通常 arm64 を選択します。端末のアーキテクチャを確認できない場合やarm64パッケージをインストールできない場合は、汎用版を使用します。v2rayNGとv2flyNGにはそれぞれ対応する入口があり、詳しい順序とアーキテクチャの説明はAndroidのインストールページで確認できます。同じ端末でクライアントを切り替える際は、まず現在の接続を停止し、システムVPNインターフェースが別のアプリに占有されたままにならないようにします。

初回起動後、接続時にVPN接続の作成を求められます。システムが現在の通信を渡せるこの種の接続は1つだけなので、別のVPNアプリによって許可が上書きされたり、接続がすぐ切断されたりすることがあります。接続をタップしても状態アイコンが表示されない場合は、システムの許可が完了しているか、端末管理ポリシーによる制限がないか確認します。

サブスクリプションと共有リンクのインポート

サブスクリプション設定を開き、グループ名とURLを追加して保存し、更新を実行します。モバイルネットワークで更新に失敗した場合は、安定した無線ネットワークへ切り替えて再度試します。どちらのネットワークでも失敗する場合は、URL、アカウント状態、ログを確認します。更新に成功したらメイン一覧へ戻り、ノードを選んで接続ボタンをタップします。更新中にアプリを頻繁に切り替えたり、バックグラウンドを削除したりしないでください。ダウンロードや解析が中断される可能性があります。

単一ノードは、クリップボードにある標準の共有リンクからインポートするか、信頼できる提供元のQRコードを読み取って登録できます。インポート後は編集画面を開き、サーバーアドレス、ポート、ユーザー識別子、通信方式、セキュリティ層、SNIを確認します。QRコードは単なるエンコード手段であり、パラメーターの一致を判断してくれるものではありません。REALITYノードではfingerprint、publicKey、shortId、flowも確認します。フィールドが欠けていると、クライアントは設定を保存できてもハンドシェイクに失敗します。

サブスクリプションの更新では通常、グループ内のリモートノードが置き換えられます。長期的に保持したい手動変更は独立したグループへコピーし、次回更新で上書きされないようにします。ノード名は識別用であり、名前を変更しても接続パラメーターは変わりません。一覧が長い場合は、複数の提供元を同じ階層に混在させず、サブスクリプショングループごとに管理します。

ルーティングモードとアプリ別ルーティング

接続前に適切なルーティングモードを選択します。グローバルモードは現在のノードを確認するのに便利です。ルールモードはドメインとIPに基づいてプロキシまたは直接接続を選びます。カスタム設定は、詳細なDNS、複数のアウトバウンド、特定のルール順序が必要なユーザーに適しています。初回設定では、まず簡単なモードで接続を確認し、その後ルールを段階的に追加してください。最初から複雑なDNS、アプリ別ルーティング、複数のルートを同時に有効にすると、異常の原因を特定しにくくなります。

アプリ別ルーティングでは、v2rayNGへ送るアプリ、または明確に直接接続したいアプリを指定できます。設定時は、システムコンポーネント、ブラウザー、対象アプリの呼び出し関係に注意してください。たとえば、アプリがログイン処理のため外部ブラウザーを呼び出す場合、両者の経路が異なるとコールバックに失敗することがあります。アプリ一覧を変更したら、切断して再接続し、新しいルールでシステムVPNインターフェースを構築します。

LAN端末、画面共有、印刷、ファイル転送では、通常プライベートアドレスを直接接続にする必要があります。接続後にLAN機能が使えなくなった場合は、まずLANまたはプライベートアドレスのバイパスルールを確認し、DNSがローカルドメインをリモートへ問い合わせていないか確認します。ルールの順序も重要です。より具体的な直接接続ルールを、先に一致する広範なプロキシルールより前に置きます。

バッテリー最適化とバックグラウンドの安定性

端末によっては、画面消灯、低バッテリー、長時間のバックグラウンド動作中にv2rayNGを制限します。接続アイコンは表示されているのに通信が止まり、アプリを開き直すと復旧するのが典型的な症状です。システムのバッテリー設定で、必要な範囲でクライアントを実行できるようにし、バックグラウンドデータが制限されていないことを確認します。メーカーによってメニュー名は異なりますが、接続中にシステムがクライアントやカーネルプロセスを停止しないことが目的です。

安定性テストでは、前面でのブラウジング、画面消灯後の復帰、無線ネットワークとモバイルネットワークの切り替えを少なくとも確認します。ネットワーク切り替えでは、ローカルアドレス、DNS、デフォルトルートが変わるため、短時間の再接続は正常な復旧過程です。切り替えのたびに復旧できない場合は、いったん切断して再接続し、ログがDNS、ハンドシェイク、システムVPNの確立のどこで止まっているか確認します。ステータスバーのアイコンだけで接続品質を判断しないでください。アイコンはインターフェースの存在を示すだけで、対象ノードのハンドシェイク完了を意味しません。

v2rayNGとv2flyNGの使い分け

v2rayNGは Xray カーネルの機能と関連プロトコル設定に適しており、Androidでの第一候補です。v2flyNGは v2fly カーネルを使用し、特定の設定要件がある場合の選択肢になります。クライアントを切り替える前に、サブスクリプションURLをエクスポートまたは保存し、2つがアプリ内部のデータベースを共有すると決めつけないでください。同じサブスクリプションを使えば基本的なノード一覧は近くなることが多いものの、高度な設定フィールド、実験機能、初期動作は異なる場合があります。

比較時はノード、ネットワーク、ルーティングモードを同じにし、毎回1つの変数だけを変更します。v2rayNGでは接続できるのにv2flyNGでは接続できない場合は、まず後者が現在処理していないフィールドを設定で使用していないか確認します。逆の場合はインポート結果と初期設定を確認します。目的はカーネルを何度も切り替えることではなく、サブスクリプション形式、プロトコルパラメーター、クライアント機能が一致しているか確認することです。

// 06 · ROUTING

サブスクリプション、システムプロキシ、TUN、ルーティングルール

4つのプラットフォームで画面は異なりますが、基本的なデータの流れは同じです。アプリがまずローカルプロキシまたは仮想インターフェースへリクエストを渡し、カーネルがルーティングルールに従ってアウトバウンドを選び、ノードのプロトコルで接続を確立します。この順序を理解すれば、システムプロキシ、TUN、DNS、サブスクリプションを別々のスイッチとして考える必要はありません。

サブスクリプション更新で変わるもの

サブスクリプション更新で主に変わるのは、サーバー一覧と接続パラメーターです。通常、すべてのローカル設定が自動的に書き換えられるわけではありません。クライアントはリモートノードを対応するグループへ配置し、ローカルルーティング、システムプロキシモード、一部のUI設定を保持することが多いです。サブスクリプション形式によって、グループ、タグ、高度なフィールドの表現力は異なります。変換後にフィールドが失われたり、名前が変わったりすることもあります。形式を変更した後は、一覧が表示されたことだけでなく、少なくとも1つのノードでプロトコル、セキュリティ層、通信方式、flowを確認してください。

複数のサブスクリプション提供元はグループを分けて保存します。グループ分けは更新を便利にするだけでなく、同名ノードの出所を追跡しやすくします。サブスクリプショングループを削除する前に、現在のアクティブサーバーがそのグループに属していないか確認します。更新後に現在のノードが削除された場合、クライアントが古いキャッシュを保持することもあれば、再選択を求めることもあります。接続が突然使えなくなったら、まず現在のサブスクリプションを更新し、残っているノードを選んでから、より複雑なネットワーク問題を確認します。

システムプロキシとTUNの選択

システムプロキシは、アプリがプロキシアドレスを読み取ってローカルポートへ接続する方式です。範囲が明確でシステムルーティングへの影響が小さく、ブラウザーや標準的なデスクトップアプリに適しています。TUNはネットワーク層から通信を取り込むため対象範囲が広く、プロキシ設定に対応しないプログラムや一元的な分割ルーティングに向いています。「より強力だから」という理由で両方を重ねて使う必要はありません。多くの場合はどちらか1つを主要な入口にすれば十分で、併用するとループや二重取り込みの判断が複雑になります。

項目	システムプロキシ	TUN
取り込み範囲	システムまたはアプリのプロキシ設定に従う通信	仮想インターフェースに入り、ルーティングに一致する通信
システムへの影響	主にプロキシ設定を変更	仮想インターフェース、ルート、DNSに関係
適した場面	ブラウザー、一般的なデスクトップアプリ、個別設定したコマンドラインツール	プロキシを読まないアプリ、一元的な分割ルーティング、アプリ単位の取り込み
確認ポイント	ローカルポート、アプリのプロキシ、システムプロキシの残留設定	権限、デフォルトルート、プライベートネットワーク、DNS、インターフェースの競合

ルーティングの照合順序

ルーティングルールは通常、上から順に照合され、一致すると直接接続、プロキシ、ブロックのいずれかのアウトバウンドを選択します。具体的なドメイン、特定のネットワーク帯、保持すべきLANルールは、広範なルールより前に置きます。一般的な構成は、プライベートアドレスを直接接続にし、明確なドメイン集合を必要に応じて分割し、残りの通信をデフォルトのアウトバウンドへ送る形です。ルールが多いほど正確になるわけではありません。重複する集合や条件の交差があると、実際の一致結果を予測しにくくなります。

domainStrategyは、ドメインルールに直接一致しない場合にIPを追加で解決するかどうかを決めます。IPIfNonMatchは、ドメインルールに結果がない場合に解決を行い、IPルールも試す設定です。ドメイン照合とIPデータベースを両立できます。IPルールだけに依存すると、DNSが結果へ与える影響が大きくなります。以下はXrayのルート設定へ統合できるルーティングオブジェクトの例です。アウトバウンドのタグは、現在の設定で実際に定義されているものと一致させてください。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "geosite:cn"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

例の最後のルールはフォールバック用なので、具体的なルールの後ろに置きます。広告のブロック、開発環境のドメイン、特定サービスの直接接続を含める場合は、フォールバックルールより前に配置します。geositeとgeoipの組み合わせ、照合順序、3段構成のテンプレートについては、ルーティングルールの分割実践を参照してください。

DNS、FakeDNS、漏洩経路

DNSはドメインをアドレスへ変換し、ドメインルールとIPルールの適用順にも影響します。システムプロキシモードでは、アプリが自分でドメインを解決する場合もあれば、ドメインをプロキシへ渡す場合もあります。SOCKSの使い方によって、名前解決がローカルとリモートのどちらで行われるかも変わります。TUNモードではDNSを一元的に処理することが多いものの、ブラウザーのセキュアDNS、アプリ内蔵の名前解決、LANの名前解決サービスにも注意が必要です。トラブル対応では、まずリクエストを誰が解決しているかを明確にし、その後でどのDNSサーバーを使うかを検討します。

FakeDNSは予約済みアドレスを使ってドメインとの対応を作り、後続の接続でカーネルが元のドメインを復元します。一部の名前解決の往復を減らし、TUNでドメイン情報を保持するのに役立ちますが、すべてのアプリに適しているわけではありません。実際のIP、LAN検出、特定のP2P処理、独自に解決結果を検証するアプリでは異常が起きる可能性があります。有効化前に通常のDNS設定を1つ保存し、問題が起きたらすぐ比較できるようにします。ルーティングとノードを同時に変更しないでください。

REALITYと通信パラメーターの確認

REALITY設定はVLESSノードでよく使われます。クライアント側では、サーバーアドレス、ポート、ユーザー識別子、serverName、fingerprint、publicKey、shortId、flowを正確に保存する必要があります。xtls-rprx-visionはサーバー側の設定およびノードのプロトコルと一致させます。networkは通常サーバー側で決まるため、接続に失敗したからといってtcp、WebSocket、gRPCを無作為に切り替えないでください。

ハンドシェイクに失敗した場合は、まずフィールドを確認し、次にシステム時刻と基本的な到達性を確認します。ログでサーバーのポートへの接続は確立しているのに、その後セキュアハンドシェイクで終了している場合、ローカルプロキシとネットワーク入口はおおむね正常です。SNI、公钥、shortId、フィンガープリント、flowを重点的に確認します。サーバーのポートに到達できない場合は、アドレス、ポート、現在のネットワーク、ノードの状態を優先して確認します。クライアント設定を何度も変更するより、層ごとに判断する方が効果的です。

設定変更後の確認

サブスクリプション、ルーティング、DNSを変更するたびに、まず接続を停止してからカーネルを再起動します。ログを消去し、直接接続されるはずの宛先、プロキシを通るはずの宛先、LAN上の宛先をそれぞれ1つずつテストします。3つが想定したアウトバウンドタグに一致しているか確認します。1つのWebページだけでは分割ルーティング全体を検証できません。複数のドメイン、接続の再利用、キャッシュが含まれる可能性があるためです。

確認が終わったら、現在のクライアント、サブスクリプショングループ、アクティブノード、取り込み方式、カスタムルールを記録します。デスクトップとAndroidで同じサブスクリプションを使う場合、サーバーパラメーターは共有できますが、システムプロキシ、TUN、アプリ別ルーティングは端末ごとに設定する必要があります。ノード設定と端末の取り込み設定を分けて管理することが、複数プラットフォームで安定させる鍵です。

// 07 · TROUBLESHOOTING

設定のよくある問題と固定した確認手順

トラブル対応の基本は、まず失敗した層を特定し、該当する変数を確認することです。推奨する順序は、システム時刻とネットワーク、サブスクリプションとノード、カーネル起動、ローカル待ち受け、通信の取り込み、DNS、ルーティングルールです。順序を固定すれば、大半の問題でクライアントを再インストールする必要はありません。

手順1：基本ネットワーク、時刻、サブスクリプション状態を確認

まずクライアントによる取り込みを無効にした状態で、現在のネットワークから通常のサイトへ正常に接続できることを確認し、日付、時刻、タイムゾーンを合わせます。会社のネットワーク、公衆無線LAN、モバイルホットスポットではポートポリシーが異なるため、同じノードが一方のネットワークでは使えて、別のネットワークではタイムアウトすることもあります。続いて、サブスクリプションの有効性、アカウントの期限、利用可能な通信量を確認し、サブスクリプションを一度更新します。

サブスクリプションの更新自体に失敗する場合、問題はノード接続より前の段階にあります。ログのHTTPステータス、タイムアウト、名前解決に関する情報を確認し、URLが完全で現在のネットワークからアクセスできることを確認します。この段階でノードのプロトコルフィールドを変更しないでください。クライアントが新しい設定を取得できていないためです。ノード一覧は更新できるのにすべて接続に失敗する場合は、次の手順へ進みます。

手順2：ノードパラメーターとサーバーへの到達性を確認

設定内容が明確なノードを1つ選び、アドレス、ポート、プロトコル、ユーザー識別子、セキュリティ層、通信方式を順番に確認します。REALITYではserverName、fingerprint、publicKey、shortId、flowも確認します。WebSocketではpathとhost、gRPCではserviceNameを確認します。サブスクリプション変換後は、特に高度なフィールドが保持されているか注意してください。

ログのタイムアウトは、制限時間内に現在の処理が完了しなかったことを示すだけで、原因が1つに決まるわけではありません。サーバーアドレスへ接続する前のタイムアウトなら、名前解決、ポート到達性、現在のネットワーク制限が考えられます。TCP確立後のハンドシェイクタイムアウトでは、セキュリティ層とサーバー状態を重点的に確認します。すぐに接続が閉じられる場合は、パラメーター不一致やサーバー側の拒否が考えられます。ノードのタイムアウトを確認する6ステップに沿って確認してください。

手順3：カーネルの起動とローカルポートを確認

ログを消去し、接続を停止してから、もう一度起動します。まず設定の読み込みとカーネル起動の結果を探し、次にローカルHTTP、SOCKS、TUNの待ち受けが確立しているか確認します。アドレスが使用中と表示された場合は、他のクライアントを終了するか、競合しているポートを変更します。ウィンドウを閉じてもバックグラウンドプロセスが終了するとは限らないため、トレイ、アクティビティモニタ、システムモニター、アプリ一覧を確認します。

設定の解析エラーでは、フィールドの型、未知のオプション、JSON構造上の位置が明確に示されることが多いです。カスタムJSONでエラーが出た場合は、まずクライアントが生成した基本設定へ戻し、カスタム部分を少しずつ統合します。JSONにはコメントを追加できず、配列やオブジェクトの末尾に余分なカンマを残すこともできません。カーネルが継続して動作してから、システムプロキシと通信の取り込みを確認します。

手順4：アプリの通信がクライアントへ入っているか確認

ノードを起動したら対象アプリを開き、新しいリクエストを発生させながらアクセスログを確認します。記録がまったくない場合、通信はクライアントに到達していません。デスクトップではシステムプロキシが有効か、アプリが独自プロキシを使っていないか、ターミナルに正しい環境変数が設定されているかを確認します。AndroidではシステムVPNの許可とアプリ別ルーティングを確認します。TUNでは仮想インターフェースとデフォルトルートを確認します。

ログに接続記録があるのに対象アプリの動作が異常な場合、入口は確立しています。次にアウトバウンド、DNS、ルーティングを確認します。ブラウザーが古い接続を再利用することがあるため、テスト前に該当タブを閉じるかブラウザーを再起動します。アプリによっては独自のDNSやプロキシ設定を持つため、システム設定だけを根拠に判断しないでください。

手順5：DNSとルーティングの問題を分けて確認

ドメインでは失敗するのに直接IP接続が使える場合は、通常DNSを確認します。名前解決リクエストがカーネルへ入っているか、どのサーバーを使っているか、ブラウザーのセキュアDNSに迂回されていないか、FakeDNSが現在のアプリに適しているかを確認します。DNSがアドレスを返すのに誤ったアウトバウンドへ進む場合は、domainStrategy、ルール順、geositeとgeoipのデータ照合を確認します。

一部のサイトだけ失敗する場合は、失敗したドメインと一致したルールを記録し、すぐにグローバルモードへ切り替えて常用しないでください。グローバルモードはノード全体が動作することを確認する用途には使えますが、最終的にはルールモードへ戻し、具体的な条件を修正します。LANで失敗する場合は、まずプライベートアドレスの直接接続を確認します。ローカルドメインの名前解決に失敗する場合は、システムの検索ドメインとローカルDNSが上書きされていないか確認します。

現象	優先して確認	次の対応
サブスクリプションを更新できない	URLの完全性、アカウント状態、現在のネットワーク、ログの状態	ネットワークを切り替えて比較し、ノードのフィールドは変更しない
カーネル起動直後に終了する	設定解析、ポート占有、ファイル権限	基本設定へ戻して再起動
ブラウザーのログがない	システムプロキシ、アプリ独自のプロキシ、ローカルポート	新しい接続を作成してアクセスログを確認
TUN後にLANが使えない	プライベートネットワーク、オートルート、DNS、他の仮想インターフェース	直接接続ルールを追加して個別にテスト
REALITYのハンドシェイクに失敗	時刻、SNI、公開鍵、shortId、フィンガープリント、flow	各フィールドをサーバー設定と比較
ネットワーク切り替え後に通信が止まる	古い接続、デフォルトルート、バックグラウンド制限	カーネルを停止して接続を再確立

プラットフォーム固有の復旧操作

Windowsでは強制終了後、システムプロキシが本機の使用不能なポートを指していないか確認し、旧プロセスが終了していることを確認します。TUNのネットワークが戻らない場合は、まずクライアントを終了してから現在のネットワークアダプターを再度有効にします。macOSでは現在のネットワークサービスのプロキシ項目と仮想ネットワークの許可を確認し、ネットワーク設定全体を削除しないでください。Linuxでは仮想インターフェース、デフォルトルート、DNSサービス、プロセスの待ち受けを確認し、リモート端末では管理用の戻り経路を先に確保します。AndroidではシステムVPNが旧アプリに占有されていないか、バッテリー設定がバックグラウンドを停止していないか、ネットワーク切り替え後に再接続が完了しているかを確認します。

これらの復旧操作で処理できるのは、システムの取り込み設定が残っている問題だけです。ノードパラメーターは修正できません。通常のネットワークへ戻してもクライアントが接続できない場合は、ログの確認手順へ戻ります。再インストールを繰り返すと一部の状況情報は消えますが、サブスクリプション状態、サーバーパラメーター、現在のネットワーク条件は変わりません。アプリファイルの破損やアップグレード移行の異常を確認した場合に限って再インストールしてください。

有効なログを整理する方法

トラブル対応の記録を提出または保存する際は、プラットフォーム、クライアント名、取り込み方式、プロトコル種別、発生時刻、操作手順、関連するエラー行を含めます。サブスクリプションURL、ユーザー識別子、公開鍵以外の認証情報、完全な共有リンクは伏せてください。ログは古い記録を消去してから問題を一度完全に再現し、その範囲を切り出します。複数のノードや起動記録を混在させないでください。

有効な説明は、たとえば「Windowsでv2rayNを使用し、システムプロキシモード。サブスクリプションの更新とカーネルの待ち受けは成功。ブラウザーのリクエストはログに表示されるが、アクティブノードを選択するとREALITYのハンドシェイクに失敗する」という形です。この説明なら、サブスクリプション、カーネル、通信入口の3層をすでに切り分けられます。「使えない」とだけ書かれていると、どこから確認すべきか判断できません。よくある質問は疑問解決で確認できます。基本知識、インストールと設定、使い方、トラブル対応に分けて整理しています。

切り戻せる安定設定を作る

問題が解決したら、現在のサブスクリプショングループ、アクティブノード、ルーティングモード、DNSポリシー、ローカルポート、プラットフォームの権限を記録します。カスタム設定は基準用に別保存し、以後の変更はコピーから始めます。デスクトップでは更新前に設定をバックアップし、Androidではサブスクリプションの入手元と重要なノードパラメーターを保存します。安定設定の価値は永遠に変えないことではなく、実験のたびに検証済みの状態へすばやく戻せることにあります。

完全な受け入れ確認では、起動、サブスクリプション更新、ノードのハンドシェイク、システムへの取り込み、直接接続ルール、プロキシルール、LANアクセス、ネットワーク切り替えを確認します。4つのプラットフォームでボタンの位置は異なりますが、判断の流れは同じです。まずデータの入手元、次にカーネル、続いて通信入口、最後にDNSとアウトバウンドを確認します。この順序で管理すれば、設定が大きくなっても問題の層を特定できます。