INSTALLATION · CONFIGURATION · ROUTING

COMPLETE HANDBOOK

V2Ray全プラットフォーム導入・設定ガイド

Windows、macOS、Android、Linuxを対象に、クライアントの選択とサブスクリプション登録から、システムプロキシ、TUN、ルーティング、ログ確認、安定運用まで解説します。

ダウンロードセンターへ まずはクイックチュートリアルを見る
v2rayN v2rayNG v2flyNG Xray · V2Fly

01 · PREPARE

読み方と共通の準備

クイックチュートリアルと本ガイドの使い分け

まず接続を一度確立できればよい場合は、先にクイックスタートガイドをお読みください。ガイドでは「クライアントをダウンロード、サブスクリプションを登録、ノードを選択、プロキシを有効化」という流れに沿って、初回操作を画面どおりに進められます。本ガイドは長期利用や問題の確認を想定し、ボタンの場所だけでなく、システムプロキシとTUNの適用範囲、サブスクリプション更新が失敗する理由、デスクトップとモバイルでバックグラウンド設定が異なる理由、ログのエラーを具体的な確認作業へ結び付ける方法も説明します。プラットフォームの権限、ルーティングの競合、ノードパラメータの不一致で困ったときは、上の目次から該当章へ直接移動できます。

本ページでは3種類のクライアントだけを扱います。デスクトップではWindows、macOS、Linuxに対応し、画面構成とサブスクリプション管理が比較的共通しているv2rayNを推奨します。AndroidではXrayコアを使用するv2rayNGを標準とし、V2Flyコアが必要な場合はv2flyNGを選択できます。クライアントはGUI、設定の整理、システムネットワークの取り込みを担当し、実際にプロトコルとルーティング規則を実行するのはコアです。この役割分担を理解すれば、トラブル対応時に原因がサブスクリプション、クライアント権限、コア設定、ローカルネットワークのどこにあるかを先に切り分けられ、削除と再インストールを繰り返さずに済みます。

開始前に確認する4つの情報

1つ目は、有効なサブスクリプションURLまたは単一ノードの共有情報です。サブスクリプションURLは通常サービス提供元が発行するもので、クライアントが読み取れるのはノードとグループだけです。有効期限を復元することはできません。コピー時は完全なURLを保持し、メッセージアプリが付けた句点、空白、改行を混ぜないでください。2つ目は正確なシステム時刻です。TLSハンドシェイクと証明書検証は時刻に依存するため、日付、タイムゾーン、分単位のずれが大きいと、すべてのノードが同時に失敗することがあります。OSの自動時刻と自動タイムゾーンを有効にし、設定前に一度同期してください。

3つ目はデバイスのアーキテクチャです。Windowsの一般的な端末はx64、macOSはApple SiliconとIntelを区別し、近年のAndroidスマートフォンは通常arm64を選びます。確認できない場合は汎用版を利用できます。Linuxはx64、arm64に加えて、ディストリビューションに応じてdebまたはrpmを選びます。4つ目は、直接インターネットへ接続できる代替手段を残すことです。初回設定でシステムプロキシ、TUN、複雑なルーティングを一度に有効にせず、まずサブスクリプションを登録してノードを選び、基本接続を確認してから機能を段階的に追加してください。異常が起きても、どの変更が通信に影響したかを特定しやすくなります。

項目 確認方法 よくある影響
サブスクリプションURL 取得元から完全にコピーし直し、先頭と末尾の文字を確認する 更新失敗、グループが空、ノードが変わらない
システム時刻 自動時刻と自動タイムゾーンを有効にして、すぐに同期する TLSハンドシェイク失敗、証明書時刻エラー
デバイスのアーキテクチャ システム情報またはデバイス情報で確認する インストールパッケージが起動しない、またはインストールできない
プロキシの適用範囲 まずシステムプロキシを使い、必要に応じてTUNを有効にする 一部のアプリがプロキシを使わない、またはルーティングが競合する

復旧可能な基準状態を先に作る

設定前に、現在のシステムプロキシ状態、クライアント内にあるサブスクリプション名、使用中のルーティングモードを記録します。デスクトップでは、システムプロキシや仮想NICのルーティングを変更する他のソフトをいったん完全に終了し、モバイルではシステム上ですでにVPN接続が有効になっていないか確認します。複数のツールが同時にシステムプロキシやデフォルトルートを管理すると、リクエストがローカルへ戻ったり、DNSの解決経路が混乱したり、画面上は接続済みでもアプリからアクセスできなくなったりします。基本接続を確認した後、本当に必要なソフトだけを一つずつ戻してください。

サブスクリプションとノードには通常、サーバーアドレス、ポート、ユーザー識別子、プロトコル、トランスポート方式、TLS、サーバー名などの項目が含まれます。これらはサーバー側と一致している必要があり、名前から推測したり「速そうな」項目へ勝手に変更したりしないでください。VMess、VLESS、Trojan、REALITYは異なる設定の組み合わせであり、すべての回線に共通する最適なプロトコルはありません。利用者側では、提供元の設定を完全に登録し、ローカルのプロキシモード、ルーティング規則、ログレベル、更新頻度だけを調整するのが最も安全です。

ダウンロードと権限に関する基本原則

クライアントの入口はダウンロードセンターにまとめています。ダウンロードページではプラットフォームごとに適切な形式を掲載し、アーキテクチャの選び方も説明しています。本ガイドでは具体的なバージョン番号を固定しません。画面の細部は更新で変わる一方、基本の順序は変わらないためです。インストールまたは展開、クライアント起動、サブスクリプショングループ作成、更新、ノード選択、コア起動、システム接続の有効化という流れです。システムがネットワーク拡張、ファイアウォール、VPN接続の許可を求めたら、対象と用途を確認してから判断してください。必要な権限を拒否した場合は、接続ボタンを何度も押すのではなく、システム設定から改めて許可します。

02 · WINDOWS

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

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

Windowsではv2rayNを第一候補にします。ダウンロードページにはデスクトップ版と従来のWPF版があります。デスクトップ版は新世代のクロスプラットフォームUIを採用し、異なるデスクトップOSでも似た操作感を求めるユーザーに適しています。WPF版はWindowsで長く使われてきた従来の画面で、メニュー配置が既存の解説と近いのが特徴です。どちらもサブスクリプション管理、ノード切り替え、システムプロキシ、ルーティング、ログ確認に対応します。いずれか一つを選び、同時起動は避けてください。システムプロキシ設定やローカル待受ポートを奪い合う可能性があります。

ダウンロード形式を選んだら、まず起動中の旧クライアントを終了します。インストーラーの場合はシステムの指示に従ってインストールします。展開版の場合は、一般ユーザーが読み書きできるディレクトリへ完全に展開し、圧縮ファイルのプレビュー画面から直接起動しないでください。パスはできるだけ短くし、頻繁に同期・削除される場所や実行権限が制限される場所は避けます。初回起動時にWindowsファイアウォールが通信許可を求めることがあります。信頼できるネットワーク環境で、用途に必要な範囲だけ許可してください。通常の単独利用では、パブリックネットワークからの着信を開放する必要はありません。

サブスクリプショングループを作成して更新する

サブスクリプショングループまたはサブスクリプション設定を開き、グループ名を追加して完全なURLを入力欄に貼り付けます。グループ名はローカルで識別するためだけのものなので、用途に合わせて付けられます。リモート側のサブスクリプションは変更されません。保存後、「現在のサブスクリプションを更新」または同等の更新コマンドを実行します。正常ならノード一覧に新しい項目が表示されます。変化がない場合は、連続して押し直すのではなく、ステータスバーとログを確認してください。HTTPステータス、証明書エラー、タイムアウトの情報は、画面の短い通知より原因を判断しやすいことが多いです。

更新に成功したら、ノードを一つ選んでアクティブサーバーに設定し、サービスを起動します。初回テストで全ノードを一度に測定する必要はありません。大量の接続を同時に作成し、本機のファイアウォール、ネットワークの揺らぎ、接続先の応答に影響されるためです。まず設定が完全なノードを一つ選び、システムプロキシを有効にして、ブラウザーで異なる2つのサイトへアクセスします。基本接続を確認した後、遅延測定や順番に切り替えるテストを行いましょう。遅延は測定時点の一部の経路を示すだけで、継続的な通信速度とは限りません。

システムプロキシモードの選び方

v2rayNがコアを起動すると、通常は本機でHTTPやSOCKSなどのポートを待ち受けます。ただし、待受ポートがあるだけで全アプリが自動的に使うわけではありません。「システムプロキシを自動設定」を有効にすると、システムプロキシ設定に従うブラウザーやデスクトップアプリがリクエストをクライアントへ渡します。システムプロキシを解除してもコアは動作し続ける場合がありますが、システムアプリは自動転送されなくなります。トラブル対応では「コアが動作中」と「システムプロキシが適用中」を分けて考え、トレイアイコンだけで全アプリにプロキシが効いていると判断しないでください。

独自のプロキシ設定を持つアプリは、Windowsのシステムプロキシを無視することがあります。その場合は、アプリ内にv2rayNが表示するローカルHTTPまたはSOCKSアドレスを入力します。ホストは通常ループバックアドレスで、ポートはクライアントの現在の設定に従います。他の端末のポートや、サーバー側のリモートポートをローカルプロキシポートとして入力しないでください。システムプロキシと手動プロキシの両方に対応するアプリでは、二重転送を避けるため片方だけを使います。

TUNモードと管理者権限

システムプロキシを読み取らないアプリ、コマンドラインツール、一部のゲームの通信まで取り込みたい場合は、TUNを検討できます。TUNは仮想ネットワークインターフェースとルーティング規則で通信を処理するため、適用範囲は通常システムプロキシより広く、権限、DNS、他の仮想NICの影響も受けやすくなります。初回有効化時には管理者権限やネットワークコンポーネントのインストールを求められることがあります。有効化後はブラウザーと普段使うアプリを確認し、LAN機器、社内ネットワーククライアント、仮想マシンの通信に影響がないか調べてください。

TUNを有効にしてシステム全体がインターネットへ接続できなくなった場合は、まずTUNを無効にし、通常のシステムプロキシが使えるか確認します。続いて、他のVPN、仮想マシンのブリッジ、コンテナネットワーク、セキュリティソフトのドライバーによる競合を調べます。異常な状態でMTU、DNS、ルーティング、ノードパラメータを同時に変更せず、一度に一項目だけ変更してください。v2rayNを終了する前にシステムプロキシを解除するか、クライアントの通常の終了コマンドを使うと、停止したポートを指すプロキシ設定が残るのを防げます。

netsh winhttp show proxy
ipconfig /flushdns
nslookup example.com

Windows特有の問題

ブラウザーは使えるのにストアアプリやコマンドラインが使えない場合、各アプリが異なるプロキシ情報源を参照している可能性があります。まず前述のコマンドでWinHTTPの状態を確認し、次にアプリ自身のプロキシ設定を調べます。クライアント終了後にすべてのWebページが開けなくなったら、Windowsのプロキシ設定で手動プロキシを無効にするか、v2rayNを再起動してシステムプロキシを解除します。ウイルス対策ソフトやセキュリティ機能がコアプロセスを遮断している場合は、ログに記録された実際のプロセスパスをもとに規則を確認し、再インストールを繰り返して権限問題を隠さないでください。よくあるエラーはトラブルシューティングで症状から検索できます。

03 · MACOS

macOS：v2rayNのインストール、権限、ネットワーク取り込み

チップのアーキテクチャを確認してインストールする

macOSでv2rayNを使う場合は、まず「このMacについて」またはシステム情報でチップの種類を確認します。Apple Silicon搭載機はarm64、Intel搭載機はx64のパッケージを選びます。アーキテクチャが合わないと、アプリが開かない、サポート対象外と表示される、互換レイヤーで動作してリソース使用量が異常になるなどの症状が出ます。ダウンロード後はパッケージ形式に従ってアプリを「アプリケーション」フォルダへ移し、そこから起動します。ダウンロードフォルダやマウントしたディスクイメージから長期間起動しないでください。更新、権限、設定保存に不整合が生じることがあります。

初回起動時に、入手元の確認、ネットワークアクセス、バックグラウンド項目の許可を求められることがあります。システム設定で対象アプリを見つけ、必要な許可を明示的に与えてください。アプリのウィンドウが表示されない場合は、まずDock、メニューバー、アクティビティモニタを確認し、すでにバックグラウンドで動いていないか調べます。複数のインスタンスを起動するとローカルポートが競合する可能性があります。システムに起動を阻止された場合も、端末全体のセキュリティ設定を変更せず、システムが用意する個別アプリの確認手順を利用してください。

サブスクリプション登録と基本接続

サブスクリプショングループ管理を開き、名前とURLを追加して保存し、更新を実行します。macOSとWindowsでサブスクリプションの内容は同じにできますが、システムプロキシ状態、TUN権限、LAN除外規則、ログレベルなどのローカル設定は自動共有されません。それぞれ設定が必要です。ノードが表示されたら一つ選び、コアを起動してからシステムプロキシを有効にします。ブラウザーでテストするときは新しいウィンドウを開き、古い接続、DNSキャッシュ、既存のHTTP/3セッションの影響を避けてください。

サブスクリプション更新時にドメイン名を解決できないと表示されたら、まずクライアントがシステム通信を取り込んでいない状態でDNSが正常か確認します。証明書またはハンドシェイクの失敗なら、システム時刻、URL、現在のネットワーク環境を確認してください。更新だけが失敗し、すでに登録済みのノードは接続できる場合、サブスクリプションへのアクセス経路とノード接続経路は別だということです。現在のノードはそのまま使い、サブスクリプション提供元を個別に確認すればよく、有効な設定を削除する必要はありません。

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

システムプロキシを有効にすると、macOSのネットワーク設定に従う多くのブラウザーやアプリがクライアントのローカルプロキシを使います。ターミナルのコマンドがシステムプロキシに従うかは、各コマンドラインツールの実装次第です。環境変数を読むもの、システムのネットワーク設定を読むもの、明示的な引数が必要なものがあります。ブラウザーが使えるからといって、ターミナルの通信も同じ経路に入っているとは限りません。現在のターミナルセッションだけにプロキシを設定する場合は、クライアント画面に表示された実際のポートを使ってください。

export HTTP_PROXY=http://127.0.0.1:v2rayNに表示されたHTTPポート
export HTTPS_PROXY=http://127.0.0.1:v2rayNに表示されたHTTPポート
export ALL_PROXY=socks5://127.0.0.1:v2rayNに表示されたSOCKSポート

scutil --proxy
dscacheutil -flushcache

上の例にある日本語のポート説明は、v2rayNに現在表示されている数字へ置き換えてください。設定は現在のターミナルセッションだけに有効です。不要になったらターミナルウィンドウを閉じるか、unset HTTP_PROXY HTTPS_PROXY ALL_PROXYで変数を消去します。クライアント停止中のコマンドが接続をどう扱うか理解していない限り、一時的な変数をすべてのターミナル起動ファイルへ永続的に書き込まないでください。システムプロキシとターミナルの環境変数が同時に存在しても必ずしも競合しませんが、トラブル対応の経路は増えます。

TUNとネットワーク拡張の権限

TUNモードはより深いネットワーク取り込みを行うため、初回有効化時にネットワーク拡張、VPN構成、システムパスワードの確認が発生することがあります。許可後はシステムのダイアログが消えたかではなく、クライアントの状態が本当に有効になったか確認してください。システム設定に複数のネットワークフィルターや企業管理構成があると、TUNを作成できない、作成直後に切断される、LANへの経路が変わるといった問題が起こります。まず同種のネットワーク取り込みソフトを停止してから、クライアントを再起動してテストします。

Wi-Fi、有線、テザリングを切り替えると、古いルートやDNSの状態が一時的に残ることがあります。「ネットワークを切り替えた直後から全ノードが失敗する」場合は、まずシステムがアドレス取得を終えるまで待ち、クライアントのコアを停止して再起動します。それでも異常ならTUNを無効にしてDNSを更新し、システムプロキシモードで基本接続を確認します。システムプロキシは正常でTUNだけ失敗する場合は、権限、仮想インターフェース、ルーティングの競合を重点的に確認し、リモートノードを先に変更しないでください。

スリープ、メニューバー、終了後の復旧

ノートパソコンが長時間のスリープから復帰すると、既存のTCP接続、ネットワークインターフェース、DNSの上流が変わっていることがあります。クライアント画面が動作中でも、古い接続を再利用できるとは限りません。いったん切断して再接続し、新しいリクエストをテストします。アプリのウィンドウを閉じてもメニューバーに残るのは、デスクトップクライアントでは一般的な動作です。完全に終了する場合は、アプリメニューの終了コマンドを使います。完全終了前にシステムプロキシを解除すると、停止したローカルポートへ通信が送られ続けるのを防げます。

LANプリンター、ファイル共有、開発機器の検出に影響がある場合は、ルーティング規則がプライベートアドレスをプロキシへ送っていないか確認します。一般的なプライベートネットワークやローカルドメインは、実際の環境に合わせて直接接続にしてください。見知らぬルーティング規則一式をそのままコピーしないでください。企業ネットワーク、家庭用ゲートウェイ、開発環境で使われるプライベートアドレス範囲は同じとは限りません。アクセスできない機器のアドレスを記録してから、正確な直接接続規則を追加するほうが、すべての通信を許可するより検証しやすくなります。

04 · ANDROID

Android：v2rayNGとv2flyNGの設定

クライアントとインストールパッケージの選び方

Androidでは、Xrayコアを使用し一般的なサブスクリプションやプロトコル設定に適したv2rayNGを標準とします。V2Flyコアが必要な場合はv2flyNGを選択できます。基本操作は似ていますが、設定データベース、コアの機能、一部メニューは完全には同じではないため、両方を同時に接続状態にしないでください。近年の主流スマートフォンは通常arm64パッケージを使います。デバイスのアーキテクチャを確認できない、またはarm64パッケージをインストールできない場合は、Androidダウンロードエリアから汎用版を選択してください。

システムによっては、インストール前に現在のブラウザーやファイルマネージャーからのアプリインストールを許可する必要があります。インストール後は、この一時的な許可を無効にできます。初回起動時にすべてのバックグラウンド権限を急いで与えず、サブスクリプション登録と基本接続を完了してから、端末のバッテリー設定に応じて項目ごとに調整してください。設定ミスとバックグラウンド制限を切り分けやすくなります。旧バージョンから移行する場合は、既存の設定が表示されるか確認してから再登録を判断し、重複ノードや重複グループが選択を妨げないようにします。

サブスクリプション、共有情報、QRコードの登録

クライアントのメニューからサブスクリプショングループ設定を開き、グループを作成して完全なURLを貼り付けます。保存後、メイン画面に戻ってサブスクリプションを更新します。提供元が単一の共有情報を渡している場合は、クリップボードから登録できます。QRコードは内容の出所が明確な場合だけ使用し、登録後にアドレス、ポート、プロトコル、サーバー名が完全か確認してください。カメラでの読み取りは入力方法にすぎず、設定の期限切れを判定したり、不足項目を自動修正したりするものではありません。

ノード一覧が表示されたら一つをタップして現在の設定にし、接続ボタンを押します。AndroidではシステムのVPN接続要求が表示されます。これは仮想ネットワークインターフェースをローカルに作成するために必要な確認です。許可すると、通常はステータスバーにシステムVPNの表示が現れます。まずブラウザーでテストし、その後よく使うアプリを確認してください。接続ボタンがすぐ未接続へ戻る場合は、直ちにログを確認します。設定の解析失敗、ポート競合、権限中断、コア起動失敗などの具体的な原因が表示されることが多いです。

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

モバイル端末のアプリ通信は通常、システムVPNインターフェースを通ってクライアントへ入ります。一部のアプリだけに適用したい場合は、アプリ別プロキシを有効にし、包含モードまたは除外モードを選択できます。包含モードは選択したアプリだけをクライアントへ通し、除外モードは選択したアプリをクライアントから迂回させます。アプリ一覧を変更したら、システムがルートを再構築できるよう、いったん切断して再接続してください。システムコンポーネント、ブラウザー内蔵ページ、アプリが呼び出す外部サービスは別プロセスの場合があるため、結果は実際のテストで判断します。

ルーティングモードは、クライアントに入ったリクエストをプロキシ、直接接続、遮断のどれにするか決めます。初回接続ではクライアントの基本規則を使い、出所不明の規則セットを複数同時に読み込まないでください。アプリのトップページは開くのに画像やログインだけ失敗する場合、そのアプリが複数のドメインを使い、規則が一部のリクエストしか対象にしていない可能性があります。ログで失敗したドメインを確認し、プロキシまたは直接接続の規則を追加するか判断します。アプリ全体を一つの経路へ固定するのは簡単ですが、規則の説明可能性は下がります。

バックグラウンド動作と省電力設定

スマートフォンOSによるバックグラウンド制限には大きな差があります。画面ロックから数分後に接続が切れる、アプリへ戻るとすぐ復旧する、バックグラウンドが整理されるとVPN表示が消える、といった現象が典型です。バッテリー最適化、バックグラウンド動作、自動起動、最近のタスクのロックを順に確認します。現在のクライアントに関係する設定だけを調整し、端末全体の省電力機能を無効にする必要はありません。サブスクリプションの自動更新も頻繁にしすぎないでください。モバイル通信での頻繁な起動、大きなグループの更新、速度測定は電池と通信量を消費します。

バックグラウンドでの電池消費については、v2rayNGの電池消費と省電力設定の確認をご覧ください。確認時はまずシステムのバッテリー統計を見て、画面表示中の利用、クライアント自身の動作、プロキシ対象アプリの通信活動を分けます。クライアントがVPNサービスを継続表示しているだけで、異常な電池消費とは限りません。大量の再試行、詳細ログの継続、頻繁なサブスクリプション更新、細かすぎるルーティング規則、ネットワーク信号の不安定さはいずれも起動回数を増やします。

Android特有のトラブル

接続後に一部のアプリだけ使えない場合は、まずアプリ別プロキシの一覧とプライベートDNS設定を確認します。プライベートDNSで特定のホスト名を指定すると、クライアントのDNSルーティングとの組み合わせで結果が変わることがあります。切り分けのため、一時的に自動へ戻してください。Wi-Fiとモバイル通信の切り替え後に接続が切れた場合は、システムの切り替え完了後に手動で再接続します。それでも復旧しなければ、まずシステムVPNを切断し、クライアントを強制停止してから再起動します。接続中にv2rayNGとv2flyNGを頻繁に切り替えないでください。

設定を登録した後に形式エラーが表示されたら、提供元からもう一度コピーし直し、余分に見える文字を手作業で削除しないでください。REALITY、TLS、トランスポートのパス、サーバー名などは相互に関連しており、一つの不一致でもハンドシェイクに失敗する可能性があります。すべてのノードが同時にタイムアウトする場合は、現在のネットワーク、システム時刻、サブスクリプションの有効性、DNSを優先して確認します。一つだけ失敗する場合は、そのノードのパラメータを同じグループの他のノードと比較します。範囲の大きい項目から小さい項目へ進めるほうが、コアを何度も変更するより効果的です。

05 · LINUX

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

deb、rpmとプロセッサアーキテクチャを選ぶ

Linuxデスクトップではv2rayNを使います。Debian、Ubuntuとその一般的な派生ディストリビューションは通常debを選び、Fedora、Rocky Linux、openSUSEなどrpm系のパッケージ管理を使うディストリビューションではrpmを選べます。デバイスのプロセッサに合わせてx64またはarm64も選択してください。特に開発ボード、ミニPC、クラウドデスクトップでは、ディストリビューション名だけでアーキテクチャを判断できません。ターミナルでuname -mを実行できます。一般的なx86_64はx64、aarch64はarm64に対応します。

GUIのソフトウェアインストーラーを使う場合は、パッケージをダブルクリックして依存関係を確認します。コマンドラインの場合は、ダウンロードディレクトリで実際のファイルに対してローカルインストールを実行してください。パッケージマネージャーは依存関係も同時に解決できるため、基盤のインストールコマンドを直接呼び出すより一般に安全です。以下のコマンドにあるファイル名は操作形式を示す例です。実行時はダウンロードページにある実際のファイル名を使用してください。

uname -m

cd ~/Downloads
sudo apt install ./v2rayN-linux-x64.deb

sudo dnf install ./v2rayN-linux-x64.rpm

同じ端末に異なるアーキテクチャのパッケージを重複してインストールしないでください。パッケージマネージャーが依存関係の不足を報告したら、まずディストリビューションのソフトウェアソースを更新し、通常のシステム更新を完了してから再インストールします。システムバージョンのサポートが終了している場合、システムライブラリを無理に置き換えると他のデスクトップアプリに影響する可能性があります。保守中のディストリビューションへ先にアップグレードするほうが適切です。インストール後はアプリメニューからv2rayNを起動し、ログでコアと設定ディレクトリを正常に読み取れることを確認します。

サブスクリプション登録とデスクトップ環境の違い

サブスクリプショングループの作成、URLの貼り付け、ノード更新、アクティブサーバーの選択という流れは他のデスクトップと同じです。Linuxで異なるのは主にデスクトッププロキシ設定です。GNOME、KDE、軽量デスクトップ、ウィンドウマネージャーのみの環境ではプロキシの読み取り方が異なり、デスクトップ設定を使うアプリ、環境変数を読むアプリ、独自のプロキシ設定を持つブラウザーがあります。v2rayNのシステムプロキシを有効にしたら、ブラウザー、ターミナル、必要なデスクトップアプリを個別にテストしてください。

ブラウザーは正常なのにターミナルのコマンドが直接接続する場合、コマンドラインツールがデスクトッププロキシを読み取っていません。ツールのドキュメントに従って、現在のセッションにHTTP、HTTPS、SOCKSプロキシを設定できます。ポートはv2rayNの画面に合わせてください。クライアントが動作していなければ、環境変数は待受のないローカルポートを指します。そのため、すべてのShell起動スクリプトへ無条件に書き込むことは推奨しません。サーバーやGUIのない環境は本ガイドの主な対象ではなく、ここではGUIクライアントとローカルデスクトップセッションを前提とします。

TUN、権限、DNS

TUNモードは仮想インターフェースを作成してルーティングを変更するため、通常は管理者権限、システム機能、ネットワーク管理サービスが関係します。デスクトッププロキシを読み取らないアプリも対象にできますが、コンテナネットワーク、仮想マシンのブリッジ、企業VPN、カスタムファイアウォール規則の影響を受けやすくなります。初回テストでは追加のネットワーク層を停止し、v2rayNのTUNだけで動作することを確認してから、一つずつ戻してください。インターフェースの作成に失敗した場合は、クライアントログとシステムログにある権限情報を確認し、システム全体のディレクトリ権限を無条件に緩めないでください。

LinuxのDNSは、systemd-resolved、NetworkManager、デスクトップのネットワークサービス、ローカルリゾルバーなどが管理している場合があります。ドメイン名は失敗するのに既知のアドレスへは応答がある場合、名前解決の経路を確認します。resolvectl statusで現在のDNS上流と各インターフェースの状態を確認し、resolvectl query example.comで解決をテストできます。このコマンドがない場合は、ディストリビューションが使うネットワークサービスに応じた同等のツールを利用してください。変更前に元の設定を記録し、トラブル対応後に復元できるようにします。

ip address
ip route
resolvectl status
resolvectl query example.com
ss -lntup

ポート競合とセッション起動

クライアントがコア起動時にポート競合を報告したら、ss -lntupでローカルの待受プロセスを調べます。よくある原因は、旧インスタンスが終了していない、別のプロキシツールが同じポートを使っている、デスクトップセッションの復元後にプロセスがバックグラウンドに残っていることです。まず旧プロセスを通常の方法で終了し、クライアントを再起動します。正体の分からないシステムサービスを無闇に終了しないでください。ローカルポートを変更した場合、そのポートを手動設定しているブラウザー、開発ツール、環境変数も更新が必要です。

ログイン時に起動する設定にした場合は、クライアントの起動がユーザーのデスクトップネットワークサービスより後になっているか確認し、異常終了後にシステムプロキシを復元できるか検証します。共有PCでは、個人のサブスクリプションを全ユーザーが読める設定ディレクトリへ保存しないでください。設定ファイルやログにはサーバーアドレス、サブスクリプション要求情報、実行エラーが含まれる可能性があるため、現在のユーザーディレクトリに限定し、不要な古いログを定期的に削除します。トラブル対応後はログレベルをデバッグから情報または警告へ戻し、ディスクへの書き込みを減らしてください。

ディストリビューション更新後の確認

システムのメジャーアップデートで、GUIライブラリ、ネットワークサービス、ファイアウォールのバックエンド、カーネルモジュールが変わることがあります。更新後にシステムプロキシは使えるのにTUNだけ失敗する場合は、仮想インターフェースの権限とルーティングサービスを再確認します。クライアントが起動しない場合は、一度ターミナルから起動して不足ライブラリや表示サービスのエラーを読み取ります。デスクトップランチャーが反応しないことを、すぐノードの問題と決めつけないでください。基本環境を修復してから、サブスクリプションと接続を確認します。安定運用のため、正常に動作したプロキシモード、DNS方針、カスタムルーティングを記録し、システム更新後に同じチェックリストで一つずつ検証してください。

06 · SUBSCRIPTION

サブスクリプション、ノード、プロトコルパラメータの管理

サブスクリプションとは何か、クライアントが保存するもの

サブスクリプションは、リモートURLが返す設定の集合です。クライアントは更新後、その中のノードをローカルグループへ保存します。リアルタイムの接続経路ではなく、ネットワーク要求のたびにURLへアクセスするものでもありません。ノード接続の可否は、登録後のサーバーアドレス、ポート、ユーザー識別子、プロトコル、トランスポート、暗号化、TLSパラメータに左右されます。更新に失敗しても、古いノードは通常残ります。使い続けられるかどうかは更新ボタンではなく、サーバー側の状態で決まります。

提供元や用途ごとにグループを作り、すべてのURLを一つの名前へまとめないことをおすすめします。グループを整理すれば、個別に更新、削除、変更確認ができ、同じグループのノードが同時に失敗した原因が同一サブスクリプションにあるか判断しやすくなります。URLを変更するときは、まず新しいグループを追加して更新に成功したことを確認してから旧グループを削除し、コピーミスで利用可能な設定を失わないようにします。更新時に古いノードを削除する機能がある場合は、グループ単位の置き換えか全体削除かを理解してから使ってください。

更新失敗時の固定チェック手順

1. 通常のネットワークとシステム時刻を確認する。2. URLを完全にコピーし直す。3. サブスクリプション要求ログのステータスを確認する。4. 現在のクライアントでシステムプロキシを無効にするか、更新に使う経路を切り替えて再試行する。5. 提供元が追加認証を求めていないか確認する。先にノードのプロトコルを変更しないでください。サブスクリプション要求は通常のHTTPS通信であり、ノード内部のVMess、VLESS、Trojanパラメータとは別の層だからです。詳しい手順はインストール・設定に関する疑問をご覧ください。

ログにタイムアウトと出る場合は、DNS、現在のネットワーク、サブスクリプションサービスへの到達性を確認します。証明書の時刻異常なら、まずシステム時計を同期してください。未認証またはアクセス拒否なら、提供元でURLと状態を確認します。返された内容を解析できない場合は、WebページのURL、ログインURLをコピーした、または途中のアプリで内容が切れた可能性があります。短時間に何度も再試行するとサービス制限にかかるほか、ログが積み重なって読みづらくなります。一度に一項目だけ変更して更新し、結果を記録してください。

ノードの各項目の関係

完全なノードには通常、アドレス、ポート、ユーザー識別子、プロトコル、セキュリティ方式、トランスポート形式、TLS設定、サーバー名、パスなどが含まれます。同じプロトコル名でも設定をそのまま交換できるとは限りません。たとえば同じVLESSでも、TLS、REALITY、WebSocket、gRPCなどの利用有無やトランスポートによって、必要な項目が変わります。サーバー名は証明書やハンドシェイクの確認に使われ、パスはサービスの入口を区別する場合があります。手動編集では提供元のパラメータを必ず基準にし、別ノードの有効そうな項目をつなぎ合わせないでください。

項目 役割 確認ポイント
アドレスとポート リモート接続先を指定する ドメイン名を解決できるか、ポートが完全か
ユーザー識別子 サーバー側で設定を識別するために使う コピーが完全か、現在のノードに属するか
トランスポート方式 接続の伝送形式を定める パス、サービス名などの追加項目が一致しているか
TLSとサーバー名 暗号化ハンドシェイクと名前検証に関係する システム時刻、名前の綴り、スイッチの状態
REALITYパラメータ 対応するプロトコルのハンドシェイク設定を構成する 公開鍵、短い識別子、フィンガープリントなどが一式で登録されているか

VMess、VLESS、Trojan、REALITY

プロトコルはサーバー側の設定とサブスクリプション内容を基準に選びます。VMessには独自のユーザー認証とセキュリティパラメータがあります。VLESSは比較的軽い構成で、TLSやREALITYなどと組み合わせて使われることが多い方式です。Trojanは認証方式とTLS設定をサーバー側と一致させる必要があります。REALITYは通常、特定のハンドシェイク構成の一部として使われ、任意のノードで単独有効にすれば速度が上がる機能ではありません。クライアントがプロトコルに対応していることは、解析・実行できるという意味であり、任意のサーバーがその設定を受け入れることを意味しません。

サブスクリプションから登録するときは、できるだけ項目をそのまま保持します。サーバー側の変更を明確に把握している場合だけ、該当項目を手動で変更してください。接続に失敗したら、同じサブスクリプション内で使えるノードと使えないノードの違いを比較します。すべて同じドメインでポートだけが違うなら、ポートとリモート側の状態を確認します。特定のトランスポートだけが失敗するなら、パス、サービス名、TLSを確認します。TLSを使うノードがすべて同時に失敗するなら、時刻とネットワーク環境を確認してください。コアの関係とプロトコル対応範囲はXrayとV2Flyコアの違いで解説しています。

速度測定、並べ替え、更新頻度

ノードの速度測定には、基本的な疎通確認、接続遅延、実際のダウンロードテストがあります。疎通確認は「リクエストを確立できるか」を示し、遅延測定はその時点でのテスト先との往復時間を表します。実際のダウンロードは回線負荷、接続先、本機のネットワークに大きく左右されます。一度の遅延結果だけで永久に並べ替えたり、モバイル通信で頻繁に一括測定したりしないでください。実際のアクセスで確認したノードをいくつか残し、変動時にグループ内で切り替えるほうが実用的です。

サブスクリプションの自動更新頻度は、提供元の変更速度とデバイスの使い方で決まります。常時稼働するデスクトップでは適切な定期更新を設定できますが、モバイルではバックグラウンド起動と通信量をより重視します。更新後に現在のノードが削除されると、再起動まで古い設定を保持するクライアントもあれば、すぐ再選択を求めるクライアントもあります。重要な作業の前には手動更新してノードを一つ確認するほうが、使用中に頻繁な自動変更を行うより制御しやすくなります。

07 · ROUTING

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

4つの経路を混同しない

通信経路を理解することがルーティング設定の基本です。第1層はアプリがリクエストをクライアントへ渡すかどうかです。ブラウザーはシステムプロキシを読み、ターミナルツールは環境変数を読み、Androidアプリは通常システムVPNインターフェースを経由します。第2層はHTTP、SOCKS、TUNなどのクライアント側入口です。第3層ではルーティング規則がプロキシ、直接接続、遮断を決めます。第4層が選択したリモートノードとプロトコルです。Webページが開かないときは、この4層に沿って順に確認し、すぐノードの故障と決めつけないでください。

システムプロキシはOSのプロキシ設定に従うアプリに適しており、設定が簡単で適用範囲も明確です。TUNはより広い範囲を取り込め、プロキシ設定のないアプリにも使えますが、ルーティングとDNSの経路を変更し、他の仮想ネットワークとも競合しやすくなります。手動プロキシは特定の開発ツールやブラウザーだけに適用したい場合に向いています。3方式を状況に応じて組み合わせることはできますが、初回設定では主要な取り込み方式を一つだけ有効にしてください。同じリクエストが二重転送されたり、アプリごとにまったく異なる経路になったりするためです。

直接接続、プロキシ、遮断の規則

ルーティング規則は通常、ドメイン、IP、ポート、ネットワーク種別、アプリのプロセスなどで照合します。上から順に、またはクライアントが定めた優先順位で処理され、最初に明確に一致した規則が通信先を決めることが多いです。直接接続はLAN機器、プリンター、ゲートウェイ、ローカルネットワークを使いたいサービスに適しています。プロキシは現在のノードを経由させるリクエストに使い、遮断は特定のドメインやプロトコルを拒否するために使えます。未一致の通信が不明確な動作にならないよう、最後にデフォルトの出口を設定してください。

{
  "type": "field",
  "domain": [
    "domain:intranet.example",
    "full:printer.lan"
  ],
  "outboundTag": "direct"
}

上の構成はドメインを直接接続する基本的な意味を示したものです。実際の登録場所とタグ名は、クライアントのルーティングエディターに従ってください。domain:は通常、指定ドメインとその範囲に一致し、full:は完全な名前の一致に使われます。規則の構文は現在のコアバージョンとクライアントの生成方式から切り離して使えないため、設定全体を既存ファイルへ上書きしないでください。GUIで規則を生成できる場合は、まず画面上で追加して検証し、JSONの階層やタグの綴り間違いを減らします。

LAN、プライベートアドレス、共有

家庭用ゲートウェイ、ネットワークストレージ、プリンター、開発機器は通常プライベートアドレスを使います。グローバルプロキシやTUNを有効にして機器へアクセスできなくなった場合は、プライベートアドレスが誤ってリモートへ送られていないか確認します。一般的な範囲は10.0.0.0/8、172.16.0.0/12、192.168.0.0/16ですが、実際の環境ではローカルドメインや他の内部アドレスも使われます。直接接続規則を追加した後は、アドレス、ドメイン、機器検出を個別にテストしてください。ブロードキャストとユニキャストでは動作が異なります。

LAN機器に本機のプロキシを使わせる機能は別にあります。有効にすると、クライアントはループバック以外のアドレスでも待ち受けます。開始前に現在のネットワークが信頼できるか確認し、ファイアウォールで必要なネットワーク範囲とポートだけを許可してください。クライアントに表示されるローカルプロキシポートは、リモートノードのポートではありません。他の端末で手動設定する場合は、クライアントを実行しているPCのLANアドレスとローカル待受ポートを使います。PCのスリープ、アドレス変更、クライアント終了で共有は自然に途切れるため、管理なしの恒久的なゲートウェイには向きません。

DNS経路と漏洩と決めつけないための確認

DNSはドメイン名を最初にどのアドレスへ解決するかを決め、その後ルーティングが接続を処理します。ドメイン規則が名前解決前に一致するのか、解決結果を使って判断するのかは、クライアントとコアの設定によって異なります。よくある異常には、ドメイン名は失敗するのにアドレスへは到達できる、ネットワークに適さない結果へ解決される、TUN有効化後に解決がタイムアウトする、切り替え前の記録がシステムキャッシュに残る、といったものがあります。トラブル対応ではまずシステムツールで解決をテストし、次にクライアントのDNSログを確認します。複数のパブリックDNSを同時に交換しないでください。

ブラウザー自身がセキュアDNSを有効にし、システムの解決経路を一部迂回することがあります。システムコマンドとブラウザーで結果が異なる場合は、ブラウザーのネットワーク設定を確認します。AndroidのプライベートDNS、macOSのネットワークサービス、Windowsのキャッシュ、Linuxのローカルリゾルバーも、それぞれ異なる層を形成します。切り分けでは一時的にシステムの自動DNSへ戻し、ブラウザー独自の解決を無効にして、クライアントの標準設定をテストできます。基本経路を確認してから、カスタム設定を一つずつ戻してください。

TUNのMTU、仮想NIC、競合

TUNは仮想インターフェースで通信を受け取ります。ネットワークによってはパケットサイズ、フラグメント、UDP経路に敏感で、通常のWebページは開くのに大容量ファイル、動画、特定アプリだけが止まることがあります。MTUも要因の一つですが、根拠がないまま極端な値へ変更しないでください。まずTUNでのみ発生する問題か確認し、システムプロキシで比較テストします。特定のネットワークだけで起こるなら、ネットワーク種別、失敗アプリ、ログのタイムアウト箇所を記録してから、小さな範囲で調整します。

仮想マシン、コンテナ、企業VPN、ゲームの高速化ツール、セキュリティフィルターソフトは、仮想インターフェースを作成したりルーティングを変更したりすることがあります。競合時に最も有効なのは、単一変数の環境を作ることです。v2rayNまたはAndroidクライアントだけを残して通信を取り込み、動作を確認してから他のソフトを一つずつ有効にします。項目を戻すたびにDNS、ブラウザー、LAN、対象アプリをテストしてください。デフォルトルートやDNSを本当に競合させているコンポーネントを特定でき、複数のツールをすべて自動起動にして偶発的な障害を待つ必要がなくなります。

08 · TROUBLESHOOTING

接続トラブル、ログの読み方、日常メンテナンス

まず影響範囲で分類する

トラブル対応の最初にノードを変えるのではなく、影響範囲を判断します。すべてのノードとアプリが失敗するなら、本機のネットワーク、システム時刻、クライアントのコア、DNS、サブスクリプションを優先して確認します。一つのノードだけなら、アドレス、ポート、プロトコルパラメータを重点的に確認します。一つのアプリだけなら、システムプロキシを読むか、アプリ別規則で除外されていないか、独自DNSを使っていないかを調べます。TUNを有効にしたときだけ失敗するなら、権限、仮想インターフェース、ルーティング競合を先に確認します。範囲を正しく判断すれば、確認項目は大幅に減ります。

次に比較対象を作ります。TUNを無効にしてシステムプロキシでテストし、カスタムルーティングを解除してクライアントの基本規則でテストします。同じグループ内の既知の正常ノードを一つ残し、失敗ノードと比較します。Wi-Fiから別の正常なネットワークへ切り替えたときは、「まだだめ」とだけ言わず、結果を記録してください。比較テストの価値は、障害の層を特定できることにあります。固定手順の詳細はノードのタイムアウト対処ガイドでも確認できます。

ログレベルとキーワード

通常利用では情報または警告レベルで十分です。トラブル対応が必要なときだけ一時的にデバッグへ切り替え、問題を一度再現したら、重要な部分を保存してすぐ元のレベルへ戻します。ログは接続ボタンを押す、またはリクエストを開始する数秒前から読み、最後の1行だけを切り出さないでください。前段の設定読み込み、DNS問い合わせ、接続先が、後続のtimeoutやrejectedの原因を示すことがよくあります。ログにはサーバーアドレス、ドメイン、ローカルパスが含まれる可能性があるため、共有前に個人のサブスクリプションURLや識別情報を削除してください。

ログの表示 よくある意味 優先する対応
timeout 指定時間内に名前解決、接続、ハンドシェイクが完了しなかった どの段階でタイムアウトしたかを切り分け、ネットワークと接続先を確認する
connection refused 接続先アドレスには到達したが、該当ポートが接続を拒否した アドレス、ポート、リモートサービスの状態を確認する
invalid user ユーザー識別子または認証設定が一致しない 設定を再登録し、項目を自分でつなぎ合わせない
TLS handshake failed TLSパラメータ、名前、時刻、経路が一致しない 時刻、サーバー名、サブスクリプションの元パラメータを確認する
address already in use ローカルの待受ポートがすでに使用されている 旧インスタンスを終了するか、ローカル待受ポートを変更する

timeout自体は原因ではなく、ある処理の待機が終了したことを示します。その前にある接続先アドレス、ネットワーク種別、段階を確認してください。名前解決前のタイムアウトならDNS、TCP接続確立時ならネットワークとポート、ハンドシェイク時ならプロトコルとTLSパラメータを調べます。rejectedはルーティングによる遮断、リモート側の拒否、ローカルポリシーなどが原因になり得るため、前後のログと合わせて判断します。詳しい例はv2rayNの実行ログの読み方をご覧ください。

接続済みなのにWebページが開かない

クライアントに接続済みと表示されても、コアまたは仮想インターフェースが起動したことを示すだけで、接続先のリクエストが成功したとは限りません。まずシステムプロキシまたはTUNが実際に有効か確認し、ブラウザーに独自のプロキシ設定がないか調べます。古いキャッシュや既存接続を避けるため、まだ開いていない通常のページを試してください。続いてDNSをテストします。ドメイン名だけ失敗し他のリクエストが正常なら解決を確認し、すべてのリクエストがタイムアウトするなら現在のノード、デフォルトのルーティング出口、ローカルファイアウォールを調べます。

一部のWebページだけ異常な場合は、ログで関連ドメインがどの出口を通ったか確認します。Webページは通常、メインドメイン、静的リソース、ログインAPI、画像ドメインへ同時にリクエストするため、規則によって経路が分かれることがあります。一時的に単純な基本ルーティングへ切り替え、分流が原因か検証します。基本ルーティングが正常なら、カスタム規則を一つずつ戻します。すべてのシステムセキュリティ機能を無効にして試すのではなく、遮断された具体的なプロセス、ポート、インターフェースを特定してください。

終了後のネットワーク切断とプロキシ残留

デスクトップクライアントが異常終了すると、システムプロキシが本機のポートを指したまま、コアだけが待受を停止することがあります。その結果、システムプロキシに従うすべてのアプリが接続できなくなります。復旧するには、クライアントを再起動してシステムプロキシを正常に解除するか、OSのネットワーク設定で手動プロキシを無効にします。WindowsではユーザーのシステムプロキシとWinHTTPを分けて確認し、macOSではシステムのネットワーク設定、Linuxではデスクトッププロキシとターミナルの環境変数を確認します。

TUNの異常終了後にルーティングがすぐ戻らない場合は、まずネットワーク接続または端末を再起動し、仮想インターフェースが残っていないか確認します。具体的な経路項目の出所を理解している場合だけ手動削除し、正常なゲートウェイを誤って消さないでください。モバイルではシステムVPN設定からアクティブな接続を切断し、クライアントを強制停止します。通常のネットワークを復元してからクライアントを再起動し、システムが異常なルーティング状態のままサブスクリプションを登録しないでください。

設定のバックアップと更新メンテナンス

長期利用では、クライアントが提供する設定エクスポートファイルをバックアップするか、サブスクリプションの提供元を記録します。ただし、個人のURLを含むファイルを公開共有場所へ置かないでください。端末を変更する場合は、新しい端末にクライアントを再インストールしてサブスクリプションを登録し、その後このガイドに従ってシステムプロキシ、TUN、ルーティングを設定します。古い設定ディレクトリ全体を直接コピーすると、旧ポート、旧パス、キャッシュ、新しいプラットフォームに適さない設定まで持ち込む可能性があります。移行後は、サブスクリプション更新、ノード接続、DNS、LAN、普段使うアプリを一つずつ確認してください。

クライアントを更新する前に通常の方法で終了し、現在使える重要な設定を記録します。更新後はいきなりルーティングとノードを同時に変更せず、まず元のサブスクリプションを読み込めるか、コアが起動するか、システムプロキシが動作するかを確認し、その後TUNをテストします。新しいバージョンでメニューの位置が変わった場合は、固定スクリーンショットに頼らず機能名から探してください。v2rayN、v2rayNG、v2flyNGの基本操作は、常にグループ、ノード、コア、ルーティング、ログを中心に構成されています。

再現可能な最終トラブル対応手順

接続できないときは、次の順序を固定して実行します。本機がクライアントなしで正常にインターネットへ接続できることを確認する。システム時刻を同期する。他のネットワーク取り込みソフトを停止する。サブスクリプションを更新できるか確認する。設定が完全な既知のノードを一つ選ぶ。システムプロキシ、またはモバイルの基本接続だけを有効にする。ブラウザーで新しいリクエストを行う。起動からリクエスト失敗までの完全なログを確認する。失敗段階に応じてDNS、ポート、プロトコル、権限を調べる。最後にTUN、カスタムルーティング、バックグラウンド自動化を戻す。各手順の結果を記録してください。

それでも原因を特定できない場合は、OS、クライアント名、取り込み方式、影響範囲、ログのキーワード、実施済みの確認項目を整理し、トラブルシューティングページで分類ごとに照合します。「どのプラットフォームで、どのモードを使い、すべてのノードか一つのノードか、すべてのアプリか一つのアプリか」を明確に説明するほうが、接続失敗のスクリーンショット一枚だけを示すより効果的です。体系的なトラブル対応の目的は、設定を一度に大量に試すことではなく、一回ごとに一層を除外し、最終的に検証と復元ができる設定を残すことです。