V2Ray 全プラットフォーム対応インストール・設定ガイド

01 / PREPARATION

共通準備：プラットフォーム、アーキテクチャ、設定ソース

クライアント、カーネル、サブスクリプションを区別する

V2Rayの利用経路は、グラフィカルクライアント、カーネル、サブスクリプションまたは共有リンクの3要素で構成されます。グラフィカルクライアントは、画面、システムプロキシの切り替え、ログ、設定を管理します。カーネルはプロトコルを解析し、アウトバウンド接続を確立してルーティングを実行します。サブスクリプションや共有リンクはノードのパラメータを提供します。v2rayNはWindows、macOS、Linux向けのデスクトップクライアントで、サブスクリプション、ルーティング、システムプロキシを一元管理できます。Androidでは v2rayNG または v2flyNG がよく使われます。前者は Xray カーネル系、後者は V2Fly カーネル系です。画面の流れは似ていますが、認識できるプロトコル拡張や高度なパラメータは完全には同じではありません。

クライアントだけで利用可能なノードが自動生成されることはありません。インストール後も、有効なサブスクリプションURL、単一ノードの共有リンク、またはサーバーパラメータの手入力が必要です。サブスクリプションURLは通常、複数のノードを返すため一括更新に便利です。一方、vmess://やvless://で始まる共有リンクは通常1つのノードを表します。両者を混同しないでください。サブスクリプションURLは「サブスクリプショングループ」や「サブスクリプション設定」に追加し、単一ノードのリンクはクリップボードからのインポート、QRコードのスキャン、または手動追加で登録します。詳しい違いは共有リンクとサブスクリプションURLの違いをご覧ください。

プロセッサーアーキテクチャとインストールパッケージの種類を確認する

ダウンロード前にデバイスのアーキテクチャを確認します。Windowsと多くのLinuxデスクトップPCは通常x64です。Appleチップ搭載Macはarm64、旧型のIntel Macはx64を使用します。近年の主流Android端末は通常arm64です。アーキテクチャを間違えると、インストーラーが起動しない、アプリに互換性がないと表示される、起動直後に終了するといった問題が起こります。Androidのアーキテクチャを判別できない場合は汎用パッケージを選べますが、サイズは通常大きくなります。arm64と確認できている場合は、arm64パッケージを直接選ぶ方が適しています。

プラットフォーム	推奨クライアント	一般的なアーキテクチャ	パッケージの選択
Windows	v2rayN	x64	デスクトップ版または従来のWPF版
macOS	v2rayN	arm64 / x64	チップに対応するDMG
Linux	v2rayN	x64 / arm64	debまたはrpm
Android	v2rayNG	arm64 / 汎用	対応アーキテクチャのインストールパッケージ

設定の境界を記録する

設定を始める前に、サブスクリプション名、現在選択中のノード、プロキシモード、TUNの有効・無効を記録しておくと便利です。後でネットワークに接続できなくなった場合、問題がサブスクリプションの解析、ノード接続、システムプロキシ、透過的なトラフィック制御のどこで起きたか判断できます。初回インストールでは、ルーティング、DNS、ポート、カーネルパラメータを同時に変更しないでください。まずは初期設定で検証可能な接続を1回確立し、その後でルーティング分岐やTUNを1項目ずつ有効にします。複数の変数を一度に変えると、ログと原因を結び付けにくくなります。

システム時刻とタイムゾーンが正しいことも確認します。一部のプロトコルでは、ハンドシェイクに時間の許容範囲が関係します。端末の時刻が大きくずれていると、見かけ上は接続タイムアウトだけが発生する場合があります。続いて、他のプロキシツールがリスニングポートを使用していないか確認します。一般的なローカルポートにはSOCKS、HTTP、混合プロキシ用がありますが、クライアントによって初期値は異なります。必ずクライアントの設定画面に表示される値を基準にし、他の端末のポートをそのまま使わないでください。ブラウザーや開発ツールだけでプロキシを使う場合は、クライアントが現在リッスンしているアドレスとポートを記録します。

設定の保存場所と機密情報を理解する

サブスクリプションURLやノードリンクにはアクセス用パラメータが含まれる場合があるため、アカウント認証情報と同様に扱ってください。完全なURLを公開ログ、スクリーンショット、公開掲示板に貼り付けないでください。トラブル対応では通常、プロトコル種別、通信方式、TLSの状態、サーバーポート、エラーメッセージだけを残し、サーバーアドレス、ユーザー識別子、サブスクリプションパラメータは隠せます。端末を移行する場合は、新しい端末でサブスクリプションを再登録するのが基本です。プラットフォームごとにパス、権限、システムプロキシの状態が異なるため、クライアントのデータディレクトリ全体を直接コピーしないでください。

準備段階の完了条件は「プログラムが起動した」ことではありません。クライアントとプラットフォームが一致し、サブスクリプションの出所が明確で、システム時刻が正しく、ポートに明らかな競合がなく、システムプロキシとTUNのどちらを使うか把握できていることが重要です。これらを確認してから各プラットフォームの章に進むと、インストール後に障害箇所を特定できない状況を大幅に減らせます。

02 / WINDOWS

Windows：v2rayNのインストール、システムプロキシ、TUN

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

Windowsでは v2rayN を推奨します。ダウンロードセンターにはデスクトップ版と従来のWPF版の両方があります。デスクトップ版は新世代のクロスプラットフォームUIを採用しており、新規インストールやmacOS、Linuxと操作感をそろえたいユーザーに適しています。従来のWPF版は実績のあるWindows向け画面構成を引き継いでおり、旧版のメニュー配置に慣れている環境や従来型のデスクトップ操作を必要とする場合に向いています。どちらもサブスクリプション管理、ノード選択、システムプロキシ、ルーティング設定に対応しており、同時にインストールする必要はありません。旧版の設定を引き続き使う場合は、先にサブスクリプションをエクスポートまたは記録してから、使用する版をインストールしてください。

Windowsのダウンロードページを開き、x64インストールパッケージを選択します。インストール前に旧クライアントを終了し、設定ファイルが使用中にならないようにします。インストーラーを使う場合は、ウィザードで現在のユーザーまたはシステムが許可する場所を選びます。直接実行する形式をダウンロードした場合は、書き込み権限のある固定ディレクトリに展開してください。長期間一時フォルダーに置くのは避けます。クライアントはサブスクリプション、ログ、ローカル設定を保存するため、ディレクトリが読み取り専用だと設定が反映されたように見えても再起動後に失われることがあります。

初回起動とサブスクリプションの追加

初回起動後は、まずサブスクリプション設定を開き、識別しやすいグループ名を作成してからURLを貼り付け、更新を実行します。更新後にノード一覧へ戻り、少なくとも1つの設定が解析されていることを確認します。一覧が空でも、すぐにシステムプロキシを有効にしないでください。まず更新結果を確認します。レスポンスが空、URLが無効、ネットワークリクエストが失敗、サブスクリプション形式に互換性がない、といった原因で「追加は成功したのにノードがない」状態になります。単一ノードの共有リンクを受け取った場合はリンク全体をコピーし、「クリップボードからインポート」のような入口を使います。サブスクリプションURL欄には貼り付けないでください。

ノードを選択したら、まずクライアントの接続テストを実行するか、実際に1回接続します。テスト結果は対象とのハンドシェイク可否を判断するためのもので、すべてのウェブサイトがそのノードを使うことを示すものではありません。実際の検証ではシステムプロキシを有効にし、システムプロキシを利用するブラウザーのページにアクセスします。既に起動しているアプリはプロキシ状態をキャッシュし、システムプロキシを切り替えても古い接続を使い続けることがあります。その場合はアプリを完全に終了してから再起動してください。

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

システムプロキシは、Windowsのプロキシ設定に従うアプリに主に影響します。「システムプロキシを自動設定」など同等のモードを選ぶと、v2rayNはシステムプロキシをローカルのリスニングポートへ向けます。クライアントを終了する前にシステムプロキシを元に戻してください。戻さないと、クライアント終了後もローカルポートを指し続け、ブラウザーがネットワークに接続できなくなることがあります。通常の終了処理では自動的に戻りますが、プロセスの強制終了、異常シャットダウン、権限によるブロック時には設定が残る場合があります。

Windowsの「ネットワークとインターネット」のプロキシ設定で、プロキシの状態を確認できます。手動プロキシが127.0.0.1を指しているのに v2rayN が停止している場合は、スイッチをオフにしてから直接接続をテストします。システムプロキシはすべてのプログラムを強制的に制御するものではありません。一部のゲーム、コマンドラインプログラム、仮想マシン、独自のネットワークスタックを持つソフトウェアは無視することがあります。その場合は、アプリ内でHTTPまたはSOCKSプロキシを指定するか、TUNの利用を検討します。

TUNモードと権限

TUNは仮想ネットワークインターフェースを作成し、システムプロキシを参照しない通信もクライアントへ取り込みます。通常は管理者権限が必要で、初回のインターフェース作成時にシステム確認が表示されることがあります。先に仮想ネットワークアダプターを作成する他のツールを終了し、通常の方法で v2rayN を起動してからTUNを有効にします。複数の透過的なトラフィック制御ツールを同時に有効にしないでください。ルーティングテーブルやDNSが互いに上書きされる可能性があります。TUN起動後は、まず通常のウェブページをテストし、次にシステムプロキシに従わないアプリをテストします。すべてのネットワークが途切れた場合は、まずTUNを無効にして基本ネットワークを復旧します。

スタートアップ、ログ、よくあるブロック

起動時に実行する必要がある場合は、v2rayNのスタートアップ設定を有効にできます。ただし、「プログラムの自動起動」と「システムプロキシの自動有効化」は別物です。前者はクライアントプロセスの起動だけを保証し、後者は起動後にシステムプロキシを変更するかどうかを決めます。共有PCやネットワークを頻繁に切り替える端末では、クライアントだけを起動し、ノードを手動で確認してからプロキシを有効にする方が適しています。ノートPCがスリープから復帰した後にノードが使えない場合は、すぐに再インストールせず、まずノードを切り替えるかカーネルを再起動します。

起動失敗や突然終了が発生したら、まずインストール先に書き込み権限があること、旧プロセスが終了していること、ローカルポートが使用されていないことを確認します。次に、システムの実行環境とセキュリティポリシーを確認してください。ログに「address already in use」と表示される場合は、リスニングポートの競合が一般的な原因です。設定解析エラーが出る場合は、直近にインポートしたノードやカスタムルーティングを確認します。最初からすべての設定を削除するのではなく、先に設定ディレクトリをバックアップし、最近追加した設定を一時的に移動して再起動します。より詳しい起動トラブルの分岐はクライアントが開かない・突然終了する場合の対処をご覧ください。

Windows章の完了条件は、サブスクリプションを更新でき、ノードを選択でき、システムプロキシを有効にするとブラウザーが想定した経路を通り、無効にすると直接接続へ戻ることです。システムプロキシに従わないプログラムまで制御する必要がある場合にだけ、続けてTUNを有効にします。変更するたびに対応するログを少し残しておくと、ノードの問題、プロキシ設定の残留、ポート競合、仮想ネットワークアダプターの問題を切り分けやすくなります。

03 / MACOS

macOS：チップの選択、権限の許可、プロキシ制御

チップを確認して v2rayN をインストールする

macOSでは v2rayN デスクトップ版を使用します。ダウンロード前に「システム情報」または「このMacについて」を開き、プロセッサーまたはチップの欄を確認します。Appleチップと表示される場合はarm64 DMG、Intelプロセッサーと表示される場合はx64 DMGを選択します。インストールパッケージとチップのアーキテクチャが合わないと、起動できない、または互換変換レイヤーに依存して動作し、トラブル対応の変数が増える可能性があります。macOSのダウンロードページでチップに合うファイルを選び、DMGを開いてアプリを「アプリケーション」フォルダーへ移動します。

初回起動時にシステムにブロックされても、何度もダブルクリックしないでください。まず「プライバシーとセキュリティ」設定で最近ブロックされたアプリの記録を確認し、インストールした v2rayN と名前が一致することを確認してから「開く」を許可します。「アプリケーション」内のアプリを右クリックして「開く」を選び、明確な確認を一度表示させる方法もあります。許可が完了すれば、通常はLaunchpadや「アプリケーション」から起動できるようになります。具体的な画面の場所はシステムのマイナーアップデートで変わる場合があるため、詳しくはmacOSの初回起動とネットワーク権限をご覧ください。

サブスクリプションの追加とメニューバーの状態

クライアント起動後、まずメインウィンドウまたはメニューバーのアイコンが表示されていることを確認します。サブスクリプションを追加する際は、グループを作成し、URLを貼り付け、保存して更新します。その後、ノード一覧から設定を1つ選びます。URLをコピーしたのに貼り付けられない場合は、クリップボードに前後の空白、改行、チャットアプリが追加した説明文が含まれていないか確認してください。サブスクリプションURLは連続した1つの内容である必要があります。単一ノードのリンクはクリップボードからインポートし、プロトコル、ポート、通信方式、TLSなどの項目が完全に取り込まれているか確認します。

macOSでは、アプリのウィンドウを閉じてもプロセスが終了するとは限りません。ウィンドウの閉じるボタンを押した後も、v2rayNがメニューバーに常駐し、プロキシを維持することがあります。トラブル対応や再起動の準備では、メニューバーから終了し、その後アクティビティモニタで関連プロセスが終了したことを確認します。ウィンドウを閉じただけで別のアプリをインストールすると、2つのインスタンスが同じローカルポートを奪い合う可能性があります。

システムプロキシとネットワークサービス

システムプロキシを有効にすると、クライアントは現在のネットワークサービスのプロキシ設定を変更します。macOSにはWi-Fi、有線ネットワーク、その他のネットワークサービスを同時に登録できます。ネットワークを切り替えた際は、現在アクティブなサービスにプロキシが適用されているか確認してください。Wi-Fiでは正常なのに有線接続で使えない場合は、まずシステムプロキシを一度切り替えます。すぐにノードの故障と判断しないでください。ブラウザーや多くのデスクトップアプリはシステムプロキシを読み取りますが、コマンドラインツールが設定に従うかどうかはツール次第です。必要に応じて、現在のターミナルセッションでプロキシ環境変数を設定します。

export HTTP_PROXY="http://127.0.0.1:ローカルHTTPポート"
export HTTPS_PROXY="http://127.0.0.1:ローカルHTTPポート"
export ALL_PROXY="socks5://127.0.0.1:ローカルSOCKSポート"

# 現在のターミナルで直接接続に戻す
unset HTTP_PROXY HTTPS_PROXY ALL_PROXY

上記のポートは、v2rayNの設定画面に実際に表示されるリスニングポートへ置き換えてください。環境変数は、現在のターミナルから起動し、これらの変数を読み取るプログラムにだけ影響します。システムプロキシの代わりにはならず、他のターミナルウィンドウを自動的に上書きすることもありません。コマンドラインの接続を調べるときは、まずenvを実行して古いプロキシ変数が残っていないか確認します。クライアントのポートが変わったのにターミナルが古いポートを指していることは、「ブラウザーは正常だがコマンドラインだけ失敗する」よくある原因です。

TUN、ネットワーク拡張、権限

TUNを有効にすると、システムからローカル管理者の認証情報の入力やネットワーク拡張の追加確認を求められることがあります。許可はシステムのダイアログと設定画面で行ってください。許可を拒否してもシステムプロキシは正常に動作する場合がありますが、TUNは作成できません。有効化後は、システムのネットワーク設定で新しいネットワークインターフェースや関連状態を確認できます。この段階でインターフェースを手動削除しないでください。まず v2rayN でTUNを無効にしてクライアントを終了し、その後に残った項目を処理します。

企業ネットワーク、ゲストWi-Fi、ウェブ認証が必要なホットスポットでは、先にネットワークへログインしてからTUNを有効にします。そうしないと、認証ページがプロキシやDNSの制御によってブロックされる可能性があります。ネットワーク切り替え後に接続済みと表示されるのにデータ通信がない場合は、「TUNを無効化—直接接続の復旧を確認—サブスクリプションを再更新—再度有効化」の順で対処します。基礎ネットワークが確立していない状態でノードを何度も変更するのを避けられます。

スリープ復帰とプロキシ設定の残留

Macがスリープから復帰した後、Wi-Fiをローミングした後、またはホットスポットを切り替えた後は、既存の接続が無効になっていることがあります。まずクライアントログでアウトバウンド接続が再確立されているか確認してからアクセスをテストします。システムプロキシが有効なままローカルカーネルが復旧していないと、アプリはリスナーのないポートへ通信を送り続けます。まずシステムプロキシを無効にし、直接接続が正常であることを確認してからクライアントを再起動し、再度有効にします。強制終了後に全体がネットワークへ接続できなくなった場合も、現在のネットワークサービスのプロキシ詳細でHTTP、HTTPS、SOCKSが選択されたままになっていないか確認してください。

ログイン後に自動実行する場合は、クライアントのスタートアップ機能またはシステムのログイン項目を使いますが、重複登録は避けてください。システムのログイン項目とクライアント内蔵の自動起動を同時に設定すると、短時間に2つのプロセスが起動する可能性があります。安定した構成では起動入口を1つだけ残し、システムプロキシを自動変更するかどうかを明確にします。macOS章の確認順は、システム権限の確認、サブスクリプション更新成功、メニューバーの状態確認、システムプロキシのオン・オフ、ネットワーク切り替え後の復旧です。TUNは独立した層として検証し、初回インストールと同時に処理しません。

04 / LINUX

Linux：deb、rpm、デスクトッププロキシ、自動起動

ディストリビューションのパッケージ形式を選ぶ

Linuxデスクトップでは v2rayN を使用します。Debian、Ubuntuおよび一般的な派生システムではdeb、Fedora、Rocky Linux、openSUSEなどrpm系のパッケージ管理を採用する環境ではrpmを選択します。一般的なデスクトップx64プロセッサーならx64、arm64デバイスなら対応するarm64パッケージを使います。パッケージ形式とアーキテクチャは同時に一致させる必要があり、デスクトップ環境の名前だけでは形式を判断できません。ターミナルで次のコマンドを実行し、アーキテクチャとディストリビューション情報を確認できます。

uname -m
cat /etc/os-release

x86_64は通常x64、aarch64は通常arm64に対応します。ディストリビューション情報のIDとID_LIKEは、パッケージ管理体系の判別に役立ちます。Linuxのダウンロードページで対応するファイルを選択してください。ソフトウェアパッケージを圧縮ファイルのように直接展開して実行せず、システムのパッケージマネージャーでインストールします。デスクトップランチャー、依存関係、アンインストール情報も同時に登録できます。

debまたはrpmをインストールする

ターミナルでダウンロード先のディレクトリへ移動したら、システムのパッケージマネージャーでインストールできます。ファイル名はダウンロードした内容によって異なります。コマンド入力では先頭の数文字を入力してTabで補完すると、手入力によるミスを防げます。以下のコマンドのファイル名は、現在のディレクトリにダウンロード済みのパッケージを表しています。

# Debian / Ubuntu 系
sudo apt install ./v2rayN-downloaded-package.deb

# Fedora 系
sudo dnf install ./v2rayN-downloaded-package.rpm

apt install ./ファイル.debまたはdnf install ./ファイル.rpmを使うと、低レベルの展開コマンドを直接呼び出すより依存関係を処理しやすくなります。インストール後はデスクトップアプリ一覧から v2rayN を起動します。入口が見つからない場合は、まずターミナルでアプリの起動コマンドを入力し、不足ライブラリ、表示サービス、権限エラーがないか確認してからデスクトップアプリデータベースを更新します。不足依存関係を解決するために、出所不明のランタイムをまとめてインストールしないでください。パッケージマネージャーが示す具体的なパッケージ名に基づいて処理します。

デスクトッププロキシと環境変数

GNOMEやKDEなどのデスクトップ環境にはネットワークプロキシ設定がありますが、設定場所や自動適用範囲は異なります。v2rayNのシステムプロキシ機能はデスクトップのプロキシ設定とできるだけ連携します。検証時は、まずデスクトップのシステム設定でプロキシモードが変わっているか確認してからブラウザーでテストします。ターミナルでHTTP_PROXYを設定するだけでは、デスクトップ全体のプロキシが有効になったことにはなりません。逆に、デスクトッププロキシが有効でも、すべてのコマンドラインツールが読み取るとは限りません。

# 現在のshellセッションにのみ設定
export http_proxy="http://127.0.0.1:ローカルHTTPポート"
export https_proxy="http://127.0.0.1:ローカルHTTPポート"
export all_proxy="socks5://127.0.0.1:ローカルSOCKSポート"

# 現在のセッションをクリア
unset http_proxy https_proxy all_proxy

ローカルリスナーが初期状態でループバックアドレスだけにバインドされている場合、接続できるのは同じ端末のプログラムだけです。同じLAN上の他の端末からこのポートを使うには、LAN接続を明示的に許可し、リスニングアドレスを変更して、ファイアウォールも設定する必要があります。これはサービスの公開範囲を広げるため、初回インストールに必須ではありません。明確な理由がなければ、ループバックでのリッスンを維持してください。

TUN、権限、ルーティング

LinuxのTUNには/dev/net/tunが必要で、インターフェースの作成、ルートの変更、DNS処理に必要な権限も求められます。デスクトップクライアントは許可ダイアログから権限を申請する場合もあれば、インストール済みの権限管理コンポーネントに依存する場合もあります。有効化に失敗したら、まずTUNデバイスの存在を確認し、ログにある「permission denied」「operation not permitted」やルート追加失敗を確認します。グラフィカルクライアント全体を常時rootで実行しないでください。ユーザーディレクトリ内の設定ファイルの所有者が変わり、通常のユーザーで設定を保存できなくなる可能性があります。

仮想マシン、コンテナのデスクトップ、制限された企業環境ではTUNが無効化されていることがあります。その場合もシステムプロキシは利用できるため、まず動作するシステムプロキシ構成を維持します。TUNを有効にした後、ドメイン名だけ失敗して直接アドレスへの接続が正常ならDNSを重点的に確認します。すべての通信が直ちに途切れる場合は、デフォルトルート、ポリシールーティング、他の仮想ネットワークソフトウェアとの競合を確認します。TUNを無効にした後は、仮想インターフェースと追加ルートが削除されたことを確認してから次のテストに進みます。

ログイン時の自動起動とデスクトップセッション

グラフィカルクライアントは、ユーザーのデスクトップセッションが確立してから起動する必要があります。まずは v2rayN 内蔵の自動起動設定を使うことを推奨します。デスクトップ環境で正しく処理できない場合は、ユーザー単位のsystemdサービスを使用できますが、グラフィカルセッションとネットワークの準備完了を待ち、現在のユーザーとして実行してください。詳しい手順はLinuxのインストールと起動時自動実行設定をご覧ください。自動起動を設定したら、実際にログアウトして再ログインし、動作を確認します。サービスコマンドを1回実行しただけで成功と判断しないでください。

自動起動に失敗した場合は、システム全体のサービス一覧ではなくユーザー単位のログを確認します。よくある原因には、更新後のプログラムパス変更、表示環境変数が利用できない、デスクトップのキーリングがまだ解除されていない、ネットワークアドレスがまだ取得できていない、といったものがあります。外出先でネットワークを頻繁に切り替える端末では、クライアントは自動起動してもTUNを直ちに強制有効化しない設定がおすすめです。ネットワーク認証とデスクトップセッションが完了してから、現在のネットワーク環境を確認してプロキシを有効にします。

アンインストール、アップグレード、設定の保持

アップグレードでは、現在のディストリビューションとアーキテクチャに一致する新しいパッケージを上書きインストールします。インストール前にクライアントを正常終了し、カーネルプロセスや設定ファイルが使用中にならないようにします。パッケージマネージャーでアンインストールしても、ユーザーのホームディレクトリにある設定がすべて自動削除されるとは限りません。そのため再インストール後も以前のサブスクリプションが表示されることがあります。完全に新しい設定で検証したい場合は、先にユーザー設定ディレクトリをバックアップしてから旧ディレクトリの名前を変更します。直接削除しないため、サブスクリプションやルーティングルールをいつでも戻せます。

Linux章の完了条件は、システムパッケージマネージャーが v2rayN を認識し、デスクトップランチャーから起動でき、サブスクリプションとノードが現在のユーザーディレクトリに保存され、デスクトッププロキシから直接接続へ戻せ、TUN無効化後にルーティングテーブルが正常になることです。問題がターミナルツールだけで起きるなら環境変数、グラフィカルアプリだけならデスクトッププロキシ、システム全体に影響するならTUN、DNS、ルーティングを優先して確認します。

05 / ANDROID

Android：v2rayNG、v2flyNG、システムVPNによる制御

クライアントとアーキテクチャを選ぶ

Androidでは v2rayNG を推奨します。V2Fly カーネル系を使う必要がある場合は v2flyNG を選択できます。どちらのクライアントにもarm64版と汎用版があります。2015年以降の主流スマートフォンは通常arm64ですが、最終的には端末情報を確認してください。arm64と明確に分かっている場合はarm64版、確認できない場合は汎用版を選びます。2つのクライアントを同時に接続状態にしないでください。この種のVPNセッションは通常、同時に1つしかアクティブにできません。

Androidのダウンロードページからインストールパッケージを入手すると、システムが現在のブラウザーまたはファイルマネージャーによるアプリのインストール許可を求める場合があります。許可は、インストールパッケージを開くために実際に使うアプリにだけ与えてください。インストール完了後は、この提供元の許可を無効にできます。インストールできない場合は、まず同名アプリが別の署名元から入っていないか、空き容量が十分か、ダウンロードファイルが端末に完全に保存されているかを確認します。エラー表示を隠すためにインストールを何度も繰り返さないでください。

サブスクリプションと単一ノードリンクを追加する

v2rayNG または v2flyNG を開いたら、サブスクリプションURLをサブスクリプショングループに追加してから更新します。更新後、設定一覧からノードを選択します。単一ノードの共有リンクはクリップボードへコピーし、クリップボードからのインポート機能を使います。QRコードはクライアントのスキャン入口から読み取り、システムの要求に応じてカメラ権限を許可します。インポート後に重複項目が表示される場合は、クリップボードから複数回インポートしたか、同じサブスクリプションを複数のグループへ追加した可能性があります。出所が明確な1つだけを残してください。

モバイル端末では、長いリンクをコピーするとクリップボードの内容が途中で切れることがあります。インポートに失敗したら、まず内容をローカルのテキストエディターへ貼り付け、先頭のプロトコル、末尾のパラメータ、中間の文字列が連続しているか確認します。エンコードされた共有リンクをメッセージアプリ内で手編集しないでください。1文字変わるだけで解析に失敗する可能性があります。サブスクリプションを更新してもノードが変わらない場合は、現在表示しているのが対象のサブスクリプショングループか、更新メッセージが出ているかを確認します。「サーバー側の内容に変更がない」ことをクライアントの故障と誤認しないようにしてください。

初回接続とシステム確認

ノードを選択して接続をタップすると、AndroidにVPN接続作成のシステム確認ダイアログが表示されます。この確認を完了して初めて、ステータスバーに接続アイコンが表示されます。クライアント画面でノードが選択済みでも、システム通信がプロキシへ入っているとは限りません。初回検証では、まず初期状態のルーティングとDNSを維持し、接続後にブラウザーでテストします。ブラウザーが正常なら、他のアプリも確認します。接続アイコンが表示されるのにすべてのアプリが使えない場合は、まず接続を切り、モバイルデータまたはWi-Fi自体が利用できることを確認します。

Wi-Fiからモバイル通信へ切り替えると、既存の接続を再確立する必要がある場合があります。システムの省電力設定によっては、画面ロック後にバックグラウンドプロセスが制限され、接続アイコンは表示されたままでもカーネルが通信を停止することがあります。システムのバッテリー設定で、クライアントに必要なバックグラウンド動作を許可し、一括クリーナーがプロセスを強制終了しないようにします。メーカーによって設定名は異なりますが、接続中にクライアントがフォアグラウンドサービスとネットワーク通信を維持できることが目標です。

アプリごとのプロキシとバイパスルール

Androidクライアントには通常、アプリごとのプロキシ機能があります。指定したアプリだけをプロキシに通すことも、選択したアプリをプロキシから除外することもできます。2つの論理は逆方向なので、設定前に現在のモードを確認してください。初回は全アプリを対象にして基本接続を検証し、その後で絞り込むことをおすすめします。「選択したアプリのみプロキシ」を有効にしたのにブラウザーを選択し忘れると、ノードがまったく機能しないように見えます。「選択したアプリをバイパス」では、選択したアプリが直接接続します。

システムコンポーネント、ダウンロードマネージャー、アプリ内ブラウザーは、異なるプロセスからリクエストを送ることがあります。メインアプリだけを選択しても、呼び出されるすべてのシステムサービスが対象になるとは限りません。ログインページは開くのにダウンロードだけ失敗する場合は、一時的にアプリごとの制限を無効にして比較します。原因がアプリの選別にあると確認してから関連コンポーネントを少しずつ追加し、すぐにノードのプロトコルやDNSを変更しないでください。

オンデマンド接続、常時接続、LANアクセス

システム設定の「常時接続VPN」は、ネットワーク復旧後にクライアント接続を維持しようとします。同じクライアントを安定して長期間使う端末に適しています。「VPNを使用しない接続をブロック」を有効にすると制御範囲は広がりますが、ノードが使えない、またはクライアントが起動していない場合に端末が完全にオフラインになる可能性があります。初回インストールでは、この2つを同時に有効にしないでください。まずサブスクリプション更新、ノード切り替え、切断後の復旧が正常であることを確認します。

プリンター、キャスト端末、ルーター管理画面、その他のLANサービスへアクセスするには、LANをバイパスするルールを有効にする必要がある場合があります。代表的なプライベートアドレスは10.0.0.0/8、172.16.0.0/12、192.168.0.0/16です。プロキシを有効にするとインターネットには接続できるのにLAN機器が見つからない場合は、ルーティングによってプライベートアドレスまでリモートのアウトバウンドへ送られていないか確認します。未知のアドレス範囲全体を安易に直接接続へ設定せず、実際のLAN範囲に合わせてください。

ログ、バッテリー消費、バックグラウンドのトラブル

モバイル端末のトラブル対応では、まずクライアントログの時刻が直前の操作と一致しているか確認します。接続タイムアウト、DNS解決失敗、設定解析失敗、システムによるサービス停止はそれぞれ別の原因です。バックグラウンドから戻った直後に切断される場合は、バッテリー最適化を重点的に確認します。ノードを切り替えても古いノードが表示される場合は、いったん切断してから再接続します。特定のアプリだけ失敗する場合は、アプリごとの設定や、そのアプリがプライベートDNSまたは特殊なネットワークスタックを使っていないか確認してください。

接続を継続するとフォアグラウンドサービスが動作し、通常のネットワーク通信とバッテリー消費が発生します。消費電力が明らかに多い場合は、ノードの頻繁な再接続、電波が弱いことによるネットワーク切り替え、ログレベルが高すぎることを順に確認します。ログを長時間、最も詳細なレベルに設定しないでください。トラブル対応が終わったら通常レベルへ戻します。Android章の完了条件は、システム接続の確認が完了し、ブラウザーで検証でき、切断後に直接接続へ戻り、ネットワーク切り替え後に再接続でき、アプリごとのルールとバックグラウンド設定が実際の利用範囲に合っていることです。

06 / SUBSCRIPTION AND ROUTING

サブスクリプション管理、ノード選択、ルーティング分岐

サブスクリプション更新の全体像

サブスクリプションの更新は、単に「リストを1つダウンロードする」処理ではありません。クライアントはまずURLへリクエストを送り、返された内容を読み込み、対応形式としてノードを解析し、指定されたグループへ保存します。問題はどの段階でも起こります。リクエスト段階はネットワークやURLの状態、解析段階は形式やカーネルの対応状況、保存段階は設定ディレクトリの権限やグループ設定の影響を受けます。更新後は、メッセージ、グループ名、ノード数の変化を同時に確認し、ボタンを押せたかだけで成功と判断しないでください。

同じサブスクリプションを複数のグループに重複登録しないでください。重複すると似た名前のノードが増え、現在の選択がどの更新元に由来するのか分かりにくくなります。用途や出所ごとに安定したグループを作成し、名前にバージョンや日付を記録する必要はありません。更新時刻はクライアントの状態やログで確認できます。サブスクリプションを削除する前に、「このサブスクリプションのノードも同時に削除」のような項目が選択されていないか確認し、出所を失った古い設定を残さないようにします。URLが変わった場合は、複数の一時グループを作らず、元のグループを編集して更新してください。

ノードパラメータと互換性の境界

ノードをインポートできるかどうかは、クライアントとカーネルがプロトコル、トランスポート層、追加パラメータを認識できるかで決まります。VMess、VLESSなどのプロトコルは接続の一部だけを定義します。実際の設定にはTCP、WebSocket、gRPC、TLS、REALITY、サービス名、パス、サーバー名などが含まれる場合があります。インポートには成功したのに接続できない場合は、コピーやサブスクリプション変換の過程で重要な項目が失われていないか確認します。クライアント間で移行する場合は、元のサブスクリプションを再インポートするのが安全です。あるクライアントが生成した内部設定ファイルを別のプラットフォームへ直接渡さないでください。

ノード名は識別しやすくするためのラベルにすぎず、実際の回線品質を示すものではありません。テストではノードを1つ選び、実際に接続してログと合わせて判断します。1回の遅延テスト失敗は、対象がプローブに応答しない、現在のネットワークでパケットロスがある、プロトコルのハンドシェイクが完了していない、といった原因でも起こります。逆に、1回低い遅延が表示されても継続的な通信の安定性は保証されません。トラブル対応の目的は「接続を確立できるか、ドメイン名を解決できるか、リクエストが正しいアウトバウンドへ入るか」を確認することであり、特定の数値を追い求めることではありません。

ルーティングルールのマッチング

ルーティングルールは通常、ドメイン、アドレス、ポート、ネットワーク種別、プロセス情報などに基づいて通信を判定し、プロキシ、直接接続、ブロックのいずれかのアウトバウンドへ送ります。ルールの順序は重要です。より具体的な条件を一般的なルールより前に置き、最後にデフォルトのアウトバウンドを設定します。広範なルールが先に一致すると、その後の詳細なルールは適用されません。変更前に現在のルーティングモードを記録し、変更後は直接接続すべき対象とプロキシを使うべき対象を1つずつテストして、両方が想定どおりか確認します。

ドメインルールとアドレスルールは、異なる段階を処理します。アプリはまずドメイン名をリクエストし、DNSがアドレスを返した後、カーネルが解析結果に基づいてアドレスルールを適用することがあります。ドメイン名スニッフィングを有効にすると、カーネルが通信から宛先ドメインを復元し、追加のルーティング分岐に利用する場合もあります。スニッフィングは多ければよいわけではありません。一部の非標準プロトコル、暗号化接続、LANサービスには適さないことがあります。初回設定ではクライアントの初期値を維持し、明確な問題がある場合だけ調整してください。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "domain:example.com"
        ],
        "outboundTag": "proxy"
      }
    ]
  }
}

上記の例はルール構造を示しています。プライベートアドレスは直接接続のアウトバウンドへ、指定した例示ドメインはプロキシのアウトバウンドへ送ります。実際の利用では、outboundTagが現在の設定に存在するアウトバウンドのタグと一致している必要があります。クライアントによってタグ名が異なる場合、コピーしただけではルールが対象のアウトバウンドを見つけられません。グラフィカルクライアントには通常、ルーティングのプリセット画面があります。まず画面上で変更し、生成される結果を明確に理解している場合だけ基礎JSONを編集してください。

システムプロキシ、PAC、グローバルルーティング

システムプロキシは、システム設定に従うアプリをローカルポートへ送り、ルーティングルールは通信がカーネルに入った後で使用するアウトバウンドを決めます。この2つの層を混同しないでください。アプリがローカルプロキシに入っていなければ、カーネルのルーティングをどれだけ詳しく設定しても適用されません。アプリがプロキシに入っていても、ルールによって直接接続へ送られれば「クライアントは有効なのに対象は直接接続される」状態になります。PACや自動設定スクリプトはシステムプロキシ層で先に振り分けを行うため、トラブル対応ではPACが対象を選ばなかったのか、カーネルルーティングが直接接続を選んだのかを確認します。

シンプルで安定した構成が必要なら、システムプロキシでブラウザーの通信をまとめてクライアントへ送り、カーネルのルーティングで直接接続とプロキシを振り分けます。より多くのアプリを制御する必要がある場合にTUNを使います。複数のPAC、自作のブラウザープロキシ拡張、システムプロキシを同時に有効にしないでください。判断層が増え、同じドメインでもアプリごとに経路が変わる原因になります。入口を1つにすると、ログからリクエストの流れを正確に確認できます。

サブスクリプション更新後の安全な変更手順

サブスクリプションを更新すると、古いノードが削除されたり、新しいノードが追加されたり、名前が変わったりすることがあります。更新前に使用していたノードが削除されると、クライアントが別の設定へ切り替える場合も、無効な参照を残す場合もあります。更新後は、現在選択中の項目がまだ存在することを確認してから再接続します。カスタムルーティングが特定のノードタグをアウトバウンドとして参照している場合は、更新によってタグが変わっていないかも確認します。グループ内のノードが多い場合は、表示名に依存するより、分かりやすいサブスクリプショングループと固定のルーティング先を使う方が安定します。

推奨する変更順序は、現在のノードとルーティングモードを記録する、サブスクリプションを更新する、解析結果を確認する、ノードを選択する、初期ルーティングでテストする、カスタムルールを戻す、です。更新直後に失敗した場合は、更新前から残っているノードへ戻して比較します。サブスクリプションやルーティングの問題は用語集でも確認できます。プロトコル、アウトバウンド、ルーティング分岐、DNSなどの概念を整理し、画面上のラベルを同じ設定層だと誤解しないようにしてください。

07 / TUN AND DNS

TUN、DNS、システムネットワークの境界

TUNが必要になる場面

TUNは仮想ネットワークインターフェースでシステム通信を受け取り、システムプロキシを読み取らないプログラムまで制御する機能です。ブラウザーや通常のデスクトップアプリがシステムプロキシで正常に動作しているなら、「設定を完全にする」ためだけにTUNを強制有効化する必要はありません。ゲームランチャー、一部のコマンドラインツール、独自のネットワークスタックを持つアプリ、通信を一元的に制御したい場面がTUNを検討する主な理由です。TUNを使うと、ルーティング、DNS、権限、仮想インターフェースという4つの変数が増え、対応範囲が広がる一方でトラブル対応の経路も長くなります。

有効化する前に、デフォルトルートを変更したり仮想ネットワークアダプターを作成したりする他のツールを終了し、システムプロキシの状態を記録します。多くの場合、TUNとシステムプロキシで同じ通信を重複して処理する必要はありません。同時に有効にするかどうかはクライアントの実装によって異なるため、判断できない場合は初期設定に従ってください。有効化したら、通常のドメイン、LANアドレス、システムプロキシに従わないプログラムの3種類をすぐに検証します。どの種類に異常があったかを個別に記録し、「ウェブページが開くか」だけで結果をまとめないでください。

厳格ルーティングと通信ループ

TUNでは、クライアント自身がサーバーへ接続する通信まで再びTUNへ送り返すと、ループが発生します。グラフィカルクライアントは通常、カーネルプロセス、サーバーアドレス、特定のインターフェースを自動的に除外します。手動でルーティングを変更する場合は、このような除外ルールを必ず残してください。典型的なループの症状は、TUN有効化後にログで接続が高速に繰り返され、通信量カウンターが異常に増えるのに、どのリクエストも完了しないことです。その場合はまずTUNを無効にし、ノードを切り替え続けないでください。ネットワークを復旧してから除外ルートを確認します。

厳格ルーティングは通信のバイパスを減らしますが、仮想マシン、コンテナ、LAN検出、企業内ネットワークに影響することがあります。有効化後にLAN機器が見えなくなった場合は、プライベートアドレスが直接接続になっているか、マルチキャストとブロードキャストが制御対象になっていないか、現在のインターフェースの優先順位が適切かを確認します。Windowsの仮想ネットワークアダプター、macOSのネットワーク拡張、Linuxのポリシールーティングは実装が異なるため、あるプラットフォームから出力したルーティングテーブルを別のプラットフォームへそのまま適用しないでください。

DNSリクエストが通る経路

ドメインへアクセスするとき、アプリはシステムDNS、ブラウザー内蔵の名前解決、暗号化DNS、クライアントが制御するDNSのいずれかを使う場合があります。クライアントログにドメインリクエストがないからといって、アプリがネットワークを使っていないとは限りません。アプリ自身が名前解決を完了している可能性があります。逆に、アドレスを解決できてもアウトバウンド接続が成功するとは限りません。トラブル対応では、まずドメインが妥当なアドレスへ解決されるかを確認し、次にそのアドレスへの接続をどのアウトバウンドが処理しているかを確認します。

TUNを有効にすると、クライアントがシステムDNSを制御し、設定されたサーバーへリクエストを転送する場合があります。すべてのドメインに失敗するのにアドレスを直接指定すればアクセスできる場合は、DNSのリスニングポート、上流への到達性、ポート競合を重点的に確認します。一部のドメインだけ解決に失敗する場合は、分岐DNS、キャッシュ、ドメインルールを確認します。DNSを変更した後は、関連する接続を再起動するかシステムキャッシュを消去してください。古い結果がアプリで使われ続けることがあります。

症状	優先して確認する項目	比較方法
すべてのドメインに失敗	DNSリスナー、上流DNS、ポート使用状況	TUNを無効にしてシステムの名前解決を確認
LANドメインだけ失敗	ローカルDNS、プライベートドメインルール	LANアドレスへ直接アクセス
解決成功後に接続タイムアウト	ノード、アウトバウンド、ルーティングルール	接続段階のログを確認
ノード切り替え後も古い結果を使う	システムとアプリのDNSキャッシュ	アプリを再起動して再接続

Fake DNSとドメインマッピング

一部のTUN設定ではFake DNSを使用します。まずアプリへ内部マッピング用のアドレスを返し、クライアントが接続を受け取った時点で元のドメイン名を復元します。ドメイン情報を保持してルーティングを実行しやすい方式ですが、マッピングのアドレス範囲、ルーティング、クライアントの状態が一致していなければなりません。クライアント終了後もマッピングがシステムやアプリにキャッシュされていると、一時的にアクセスできないことがあります。その場合はTUNを無効にし、システムDNSを復元して関連キャッシュを消去してから再接続します。

Fake DNSを他のローカルDNSサービスと安易に重ねて使わないでください。システム内に広告ブロックDNS、ローカル開発用の名前解決、コンテナDNSがある場合は、まずリクエスト経路を整理します。どのサービスがローカルポートをリッスンし、どれが上流で、どのコンポーネントがドメインルールを担当するのかを確認してください。2つのサービスが同じポートを奪い合うと起動に失敗し、互いに転送し合うループがあると継続的なタイムアウトになります。安定した構成では、システム入口を1つに明確化し、そこから後続サービスへ転送します。

LAN、ホットスポット、仮想環境

TUNを有効にした後、NAS、プリンター、ルーター管理画面にアクセスできない場合は、通常プライベートアドレスのルーティングまたはローカルDNSが原因です。まず機器のアドレスへ直接アクセスします。アドレスには到達できるのにホスト名で到達できない場合は、ローカルDNSを確認します。アドレスにも到達できない場合は、プライベートネットワークが誤ってプロキシへ送られていないか確認してください。テザリング中の他の端末の通信がTUNに入るかどうかは、システムの転送機能とクライアントの能力に依存します。本端末の接続状態だけから判断しないでください。

仮想マシンやコンテナには、独立したブリッジ、DNS、ルーティングがあることが多いです。ホストOSのシステムプロキシが仮想環境へ自動的に引き継がれるとは限らず、TUNもインターフェースの優先順位によって一部の通信しか制御できない場合があります。トラブル対応では、ホストOSと仮想環境それぞれでデフォルトルートとDNSを確認します。コンテナ内部の接続失敗をノードの問題と決めつけないでください。開発ツールだけにプロキシを使わせたい場合は、TUNの制御範囲を広げるより、ツールや環境にローカルプロキシアドレスを明示する方が保守しやすいことがあります。

安定した起動・終了の順序

有効化の順序は、基礎ネットワークが使えることを確認する、クライアントを起動する、サブスクリプションを更新してノードを選ぶ、システムプロキシを検証する、TUNを有効にする、です。終了時は、まずTUNを停止し、仮想インターフェースと追加ルートが消えたことを確認してからシステムプロキシを戻し、最後にクライアントを終了します。異常再起動後にネットワークが使えない場合は逆順で残留状態を確認します。システムプロキシがローカルを指していないか、仮想インターフェースが残っていないか、DNSが停止したリスニングポートを指していないかを確認してください。

この章の確認基準は、TUNのオン・オフ前後でネットワーク状態を予測でき、LANの範囲が明確で、DNSの入口が1つだけになり、クライアント終了後にシステムが復旧することです。システムプロキシで実際に使うアプリをカバーできるなら、よりシンプルな設定を維持できます。制御範囲が広いほど、その端末に適しているとは限りません。

08 / TROUBLESHOOTING

よくある設定問題と層別トラブル対応

まず障害の層を切り分ける

効果的なトラブル対応には、まず問題がどの層にあるかを判断する必要があります。第1層は端末の基礎ネットワークで、クライアントを終了すると正常に直接接続できる状態です。第2層はサブスクリプションと設定で、クライアントがノードを解析できる必要があります。第3層はカーネル接続で、ログにアウトバウンドの確立または明確なエラーが表示されます。第4層はシステム制御で、アプリの通信がローカルプロキシまたはTUNに入る必要があります。第5層はルーティングとDNSで、リクエストが想定したアウトバウンドへ送られる必要があります。前の層を飛ばして高度なパラメータを変更すると、症状が複雑になりがちです。

一度に変更する変数は1つだけにし、変更前後の結果を記録します。たとえばノードに接続できない場合は、同じネットワーク上でまず別のノードへ切り替えます。すべて失敗するならサブスクリプションとネットワークを確認し、1つだけ失敗するならそのノードの設定が原因である可能性が高くなります。ブラウザーは失敗するのにクライアントのテストは成功する場合はシステムプロキシを確認します。システムプロキシが正常で特定の独立アプリだけ失敗する場合は、アプリのプロキシ設定やTUNを確認します。このような比較は、何度も再インストールするより多くの情報をもたらします。

サブスクリプションの更新に失敗する

サブスクリプションの更新に失敗したら、まずURLが完全で前後に空白がなく、単一ノードのインポート入口ではなくサブスクリプション設定へ追加されていることを確認します。次に、更新メッセージがネットワークリクエスト失敗、空のレスポンス、解析失敗のどれなのかを確認します。リクエスト失敗なら基礎ネットワーク復旧後に再試行します。空のレスポンスならサブスクリプションの提供元の状態を確認します。解析失敗なら、クライアントが返却形式に対応しているか確認してください。サブスクリプションURLを共有リンクへ書き換えたり、不要に見えるクエリパラメータを手動で削除したりしないでください。

更新は成功したのにノードが増えない場合は、現在表示しているグループ、フィルター条件、重複処理の設定を確認します。サブスクリプションによっては、元のグループへ追加するのではなく内容を上書きします。サーバー側のノードに変更がなければ、一覧が変わらないのは自然です。古いノードは使えるのに新しいノードだけ見当たらない場合は、一時グループを作って更新結果を比較できます。確認後は一時グループを統合または削除し、長期的な重複を避けてください。

ノードを選択しても接続できない

まずシステム時刻、現在のネットワーク、ノードパラメータを確認します。ログのタイムアウトは通常、接続が完了していないことを示し、アドレスに到達できない、ネットワークでパケットロスがある、サーバーが応答しないといった原因が考えられます。接続拒否は通常、対象アドレスには到達できるものの、そのポートが接続を受け付けていないことを示します。設定解析エラーはパラメータ構造に問題があることを意味します。TLS、サーバー名、通信パス、サービス名などはノードの提供元と一致させる必要があり、経験だけでよくある値に変更しないでください。

同じノードが一方のプラットフォームでは使えるのに別のプラットフォームでは失敗する場合は、ノード名ではなく両端のプロトコル項目とカーネルの対応能力を比較します。クライアント内部のJSONをコピーするより、元のサブスクリプションから再インポートする方が通常は確実です。v2rayNG がある拡張項目をインポートできても v2flyNG が認識できない場合は、カーネルの方向に応じて互換性のあるクライアントを選びます。項目を空欄にして無理に接続しないでください。

クライアントは接続中なのにアプリに変化がない

これは通常、システム制御層の問題です。デスクトップではシステムプロキシがクライアントの現在のリスニングポートを指しているか、AndroidではシステムVPNの確認が完了しているかを確認します。次に、アプリがシステムプロキシを読み取るか、接続前から長時間の接続を確立していないかを確認します。アプリを完全に終了して再起動すると、接続キャッシュを除外できます。ブラウザーにプロキシ拡張機能を追加している場合は、システム設定を上書きしないよう一時的に無効にします。

コマンドラインプログラムではプロキシ環境変数を確認します。ゲームや独立したネットワークスタックを持つアプリではTUNが必要になることがあります。1つのアプリがシステムプロキシを無視したからといって、ノードが使えないと判断しないでください。まず、システムプロキシに明確に従うブラウザーを基準として、基準アプリが正常であることを確認してから制御範囲を広げます。

クライアント終了後にネットワークへ接続できない

最も一般的な原因は、システムプロキシが停止済みのローカルポートを指し続けていることです。WindowsとmacOSではシステムネットワーク設定から手動プロキシまたは自動プロキシ設定を無効にします。Linuxではデスクトッププロキシとターミナルの環境変数を確認し、Androidではシステムの接続状態と常時接続設定を確認します。TUNを使っていた場合は、仮想インターフェース、デフォルトルート、DNSが復旧していることも確認してください。完了後はまず直接接続を検証し、その後クライアントを再起動します。

プロセスを強制終了すると、正常終了よりも設定が残りやすくなります。普段はクライアントのメニューからシステムプロキシとTUNを無効にしてから終了してください。再起動のたびに同じ状態が起きる場合は、自動起動項目が重複していないか、別のネットワークツールがログイン時にプロキシを書き込んでいないか確認します。複数のプログラムに同じシステムプロキシのスイッチを管理させないでください。

ポート競合とカーネル起動失敗

ログにポートが使用中と表示されたら、まず他のプロキシクライアントを終了し、v2rayN、v2rayNG、v2flyNGが重複起動していないことを確認します。前回の異常終了でカーネルプロセスが残っている可能性もあります。不要な古いプロセスを終了してから再起動します。リスニングポートを変更する必要がある場合は、ブラウザー、ターミナルの環境変数、そのポートに依存する他のツールも同時に更新してください。クライアントだけポートを変更し、アプリが古い値へ接続し続ける状態を避けます。

# Linuxで指定ポートのリスニングプロセスを確認
ss -lntp

# Windows PowerShellでTCPリスナーを確認
Get-NetTCPConnection -State Listen

# macOSでTCPリスナーを確認
lsof -nP -iTCP -sTCP:LISTEN

用途を確認できないシステムプロセスを終了しないでください。コマンドの結果は、ポートとプロセスの対応関係を調べるために使い、古いクライアントを終了するか新しいクライアントのポートを変更するかを判断します。リスニングアドレスが127.0.0.1なら本端末からのみアクセスできます。すべてのインターフェースでリッスンしている場合は、LANアクセス設定とファイアウォールも確認してください。

TUN有効化後にネットワーク全体が途切れる

直ちにTUNを無効にして基礎ネットワークが復旧することを確認し、その後、権限、仮想インターフェース、ルーティング、DNSの順に確認します。権限不足は通常、インターフェース作成時にエラーになります。ルーティング競合はインターフェース作成後に通信経路を誤らせます。DNSの問題はドメイン名の失敗として現れることが多いです。仮想マシン、コンテナネットワーク、その他の仮想ネットワークアダプター用ツールを同時に使っている場合は、まず1つを一時停止して比較します。

Androidでは別のVPN設定がシステムに残っていないかも確認します。デスクトップでは複数のクライアントが同時に自動起動していないか確認します。復旧テストで機能を一度にすべて再度有効にしないでください。まずノード接続、次にシステムプロキシ、最後にTUNの順で確認します。各層を通過してから次へ進むことで、どの段階で問題が発生したか特定できます。

ログの整理と追加の参照先

問題を報告する前に、OS、クライアント名、インストールパッケージのアーキテクチャ、システムプロキシとTUNのどちらを使っているか、発生時刻、直近の変更を記録します。ログは障害の前後に関係する部分だけを抜き出し、サブスクリプションURL、ユーザー識別子、サーバーアドレスなどの機密情報を隠してください。「サブスクリプション更新は成功、ノード選択後にシステムプロキシを有効化、ブラウザーのリクエストがタイムアウト、システムプロキシを無効にすると直接接続は復旧」のように再現手順を記述すると、「使えない」より原因を特定しやすくなります。

判断できない場合はよくある質問で、基礎知識、インストールと設定、利用方法、トラブル対応の分類から確認を続けてください。初心者はV2Ray初心者の10の疑問も参照し、カーネル、サブスクリプション、プロキシモードの基本的な関係を確認できます。トラブル対応が終わったら、一時的に変更したログレベル、テストポート、仮のルーティングを元に戻し、検証済みの安定した設定を1つ残してください。

設定全体の最終確認では、4つの状態を確認します。クライアント起動後にサブスクリプションを更新できること、ノード接続後に対象アプリが想定どおりプロキシを通ること、システムプロキシまたはTUNを無効にすると直接接続へ戻ること、端末の再起動やネットワーク切り替え後に再接続できることです。この4項目を満たせば、インストール、設定、システム制御、復旧経路が一通り完成しています。