全プラットフォームガイド · 導入 / トラフィック制御 / 接続確認

V2Ray 全プラットフォーム
導入と設定

デスクトップでは v2rayN、Androidではカーネルに応じて v2rayNG または v2flyNG を選びます。このページではOSごとの設定手順をまとめています。導入、移行、トラブル対処の際にご活用ください。初めて使う場合は、まず使い方ガイドで基本を確認し、必要な章に戻って設定を進めてください。

v2rayN をダウンロード 基本的な使い方を見る

共通の準備：設定元とトラフィック制御方式を確認する

クライアント、カーネル、ノードの役割

クライアントはサブスクリプションの保存、ノードの表示、設定の生成、接続の制御を担います。カーネルはプロトコルのハンドシェイク、ルーティングの判定、データ転送を処理します。ノードは実際に接続するリモートサーバーです。v2rayNやv2rayNGをインストールしても、利用可能なノードが自動で手に入るわけではありません。同じプロトコル名でも、アドレスや認証情報、通信パラメーターをそのまま置き換えられるとは限りません。作業を始める前に、利用権限のあるサブスクリプションURLまたはノード情報一式を用意し、OSに合ったクライアントを選びましょう。

デスクトップでは v2rayNを使うと、Windows、macOS、Linuxでほぼ共通の操作感を保てます。AndroidではXrayカーネルを採用した v2rayNGが第一候補です。V2Flyエコシステムの設定が必要な場合は、v2flyNGも検討してください。対応プロトコルは名称だけでなく、実際に使われるカーネルとクライアントの実装によって異なります。インポート前に設定の提供元へ共有形式、トランスポート、TLSの要件を確認し、カーネルが認識しない項目をネットワーク障害と誤認しないようにしましょう。

システムのアーキテクチャとインストール先を確認

Windowsでは「設定 → システム → 詳細情報」でシステムの種類を確認します。macOSではAppleメニューの「このMacについて」でチップを確認してください。Linuxでは「設定」の「システム情報」などでディストリビューションとプロセッサーのアーキテクチャを確認できます。Androidでは「設定 → デバイス情報」で機種を調べ、端末の仕様と照らし合わせます。インストーラーは端末に対応するものを選び、ファイルサイズだけで判断しないでください。各プラットフォームの配布ファイルはダウンロードページから選べます。まずOSを選び、対応するアーキテクチャとパッケージ形式を指定してください。

ユーザーディレクトリに書き込みできること、ディスク容量に余裕があること、システムの日付とタイムゾーンが正しいことも確認しましょう。証明書の検証には正確な時刻が必要で、時刻のずれは有効期間に制約のあるプロトコルにも影響します。旧クライアントがある場合は、ノードのグループ、ルーティングモード、待ち受けポート、サブスクリプションの更新方法を記録してください。旧ディレクトリのファイルを新しいインストール先へ一括コピーするのは避けましょう。画面やカーネルが異なると設定形式も変わることがあります。まずバックアップを取り、項目ごとに移行してください。

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

システムプロキシは、システム設定に従うアプリへローカルプロキシのアドレスを通知する方式です。すべてのアプリが利用するとは限りません。アプリごとのプロキシは、対象アプリの設定画面にアドレスとポートを個別に入力します。TUNは仮想ネットワークインターフェースで通信を受け付けるため、通常はより広い範囲を制御できますが、権限やルーティング、DNSの連携が必要です。これらはクライアントに通信を取り込む方法です。取り込んだ後の転送先は、クライアントの「グローバル」や「バイパス」などのルーティング設定で決まるため、混同しないでください。

方式設定場所主な制約
システムプロキシクライアントのシステムプロキシメニューアプリ側がシステム設定に従う必要がある
アプリごとのプロキシ対象アプリのネットワーク設定そのアプリだけに適用
TUNクライアントのTUN設定権限とルーティングの設定が必要

サブスクリプションと復元用の記録を準備

サブスクリプションは更新可能なノード情報の一覧であり、アカウントのログインページではありません。コピーする際はパスとクエリパラメーターを含むURL全体を保持し、空白や改行、文末の句読点が混ざらないようにしてください。アカウント情報を含むURLは機密情報です。公開スクリーンショットやオンラインデコードツール、共有ドキュメントに載せないでください。サブスクリプションごとに独立したグループを作り、更新、置き換え、削除はグループ単位で行うと、手動登録したノードとの混在を防ぎやすくなります。

初回設定ではトラフィック制御方式を一つだけ有効にし、変更前のシステムプロキシの状態を記録してください。接続を確認してからTUN、複雑なルール分岐、カスタムDNSを追加します。問題が起きた際に、どの段階まで戻せばよいか明確になります。組織の管理下にある端末では、ネットワーク設定の変更権限を事前に確認してください。システムプロキシを変更できない、または仮想インターフェースを作成できない場合は、端末の管理ルールに従い、権限制限をインストール失敗と誤認しないようにしましょう。

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

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

Windowsのダウンロード項目には、v2rayNのデスクトップ版と従来のWPF版があります。デスクトップ版はクロスプラットフォームのUIを採用し、WPF版は従来のWindows向けレイアウトを引き継いでいます。どちらも正しいノード設定と動作するカーネルが必要です。画面の違いがノード品質の違いを意味するわけではありません。初めてインストールする場合はデスクトップ版が手軽です。WPF版に慣れている場合は、設定をバックアップしてから切り替えるか検討してください。両方を同時に起動する必要はありません。

インストーラーを起動し、ウィザードに沿ってインストールします。初回起動時に実行環境が不足していると表示された場合は、配布パッケージの案内に従って必要なシステムコンポーネントを追加してください。他のソフトのディレクトリからランタイムを無作為にコピーするのは避けましょう。インストール後はメイン画面を開き、ログに起動エラーが繰り返し出ていないことを確認します。通常のシステムプロキシの設定に管理者権限は不要です。TUNやサービス、ネットワークインターフェースの管理が必要な場合に限り、クライアントの案内に従って権限を付与してください。

サブスクリプショングループにURLを追加

メイン画面で「サブスクリプショングループ → サブスクリプショングループ設定」を開き、グループ名とサブスクリプションURLを追加して保存します。メイン画面に戻り、「サブスクリプショングループ」メニューから「現在のサブスクリプションを更新（プロキシを使用しない）」を実行します。現在のネットワークからサーバーへ直接アクセスできる場合に適した方法です。既存のプロキシ経由でのみアクセスできる場合は、プロキシを使用する更新項目を選びます。メニューの表記は画面によって異なりますが、現在のグループとすべてのグループを区別し、他の接続元を誤って更新しないようにしてください。

更新後、該当グループにサーバー一覧が表示されるか確認します。一覧が空の場合は、まず更新ログを確認し、リクエストの失敗、ログインページの返却、内容の解析失敗を切り分けてください。共有リンクをコピーした場合は、「サーバー」メニューから「クリップボードから複数のURLをインポート」を選びます。QRコードは対応するスキャン機能を使います。サブスクリプションURL、単一ノードの共有リンク、カーネル用のJSONはそれぞれ形式が異なります。すべてを同じ入力欄に貼り付けないでください。形式の違いはサブスクリプションと共有リンクの形式比較をご覧ください。

使用するノードを選び、システムプロキシを有効にする

サーバー一覧からノードを選び、右クリックメニューの「アクティブサーバーに設定」または画面上の同等の操作で有効にします。まずログでカーネルが起動したことを確認し、次にタスクトレイアイコンを右クリックして「システムプロキシ」から「システムプロキシを自動設定」を選びます。Windowsの「設定 → ネットワークとインターネット → プロキシ」に戻り、手動プロキシのアドレスがクライアントの実際の待ち受け先を指しているか確認してください。ポート番号はv2rayNの設定とログを基準にし、他の端末の値をそのまま使わないでください。

ブラウザーにプロキシを個別制御する拡張機能がある場合は、システム設定を上書きしないよう、まず拡張機能のルールを無効にしてください。会社のネットワークで自動構成スクリプトを使っている場合は、スクリプトのURLを記録しておきます。システムプロキシを切り替えると、既存の接続経路に影響することがあります。使用を終えるときは、v2rayNのシステムプロキシメニューでプロキシを解除してから終了してください。プロセスを強制終了すると、システムが停止済みのローカルポートを参照したままになり、ブラウザー全体が接続できなくなることがあります。

TUNの権限、ポート、よくある競合

システムプロキシで接続できることを確認してから、メイン画面の「TUN」を有効にします。権限不足と表示された場合は、いったん終了し、必要に応じて管理者権限で起動してからアクティブノードを確認してください。TUNの作成に失敗した場合は、ログにある仮想インターフェース、ルーティング、権限の情報を確認します。クライアントを何度も再インストールする必要はありません。他のVPN、仮想マシンのネットワーク、セキュリティソフトがルートを変更している可能性もあります。まずトラフィック制御ツールを一つだけ有効にし、競合の原因を特定してから併用を検討しましょう。

ログにポートのバインド失敗が表示された場合は、「設定 → パラメーター設定」でローカルの待ち受けポートを確認し、同じポートを使っている古いプロセスを停止してください。「LANからの接続を許可」を有効にしても、ローカルのバインド問題は解決しません。この設定は接続を受け付ける範囲を変えます。リモートデスクトップでTUNを切り替える前に、復旧手段を用意してください。ルートの変更でセッションが切断されることがあります。最後にクライアントを一度再起動し、サブスクリプションが残っていること、アクティブノードが正しいこと、システムプロキシを解除すると元の状態に戻ることを確認します。

macOS：チップに合った選択、権限、プロキシの復元

チップに合ったv2rayNをインストール

Appleメニューの「このMacについて」を開きます。Appleチップ搭載と表示される場合はApple Silicon用、Intelプロセッサと表示される場合はIntel用のインストーラーを選んでください。各ファイルはmacOSのダウンロード項目から取得できます。ディスクイメージを開き、インストーラーの案内に従ってアプリを「アプリケーション」フォルダに移動し、その場所から起動します。一時的にマウントしたイメージから使い続けると、アップデートやパス参照、権限の記録が実際のインストール先と一致しないことがあります。

初回起動がシステムにブロックされた場合は、ファイルの入手元とインストール手順を確認してから、「システム設定 → プライバシーとセキュリティ」に表示される案内を確認します。正規のアプリだと確認できた場合に限り、システムが用意する一回限りの許可機能を使ってください。システム全体のセキュリティ機能を無効にする必要はありません。アプリが破損している、または実行できないと表示された場合は、チップに合ったインストーラーを再取得し、配布パッケージのシステム要件を満たしているか確認してください。ノード設定の変更では解決できないエラーです。

サブスクリプションを追加し、アクティブサーバーを確認

v2rayNで「サブスクリプショングループ → サブスクリプショングループ設定」を開き、新しいグループを作ってURLを保存し、現在のサブスクリプションを更新します。まだプロキシを設定していない場合は、まずプロキシを使わずに更新してください。利用可能な接続がすでにあり、サブスクリプションの接続元がその経路を必要とする場合に限り、プロキシ経由で更新します。完了後はログのリクエスト結果と解析結果を確認し、サーバー一覧に想定した内容が表示されるか確かめてください。グループ名はローカルのメモであり、サーバーから返されるノードの内容には影響しません。

ノードを選んでアクティブサーバーに設定し、カーネルが正常に起動するか確認します。別のパソコンへ移行する場合は、プログラムのフォルダー全体をコピーするより、サブスクリプションを再登録する方法をおすすめします。デスクトップ版の設定にはOS固有のパス、ウィンドウの状態、カーネルファイルの場所が含まれることがあり、他のOSでそのまま使えるとは限りません。手動登録したノードは、ポート、認証情報、TLS、SNI、トランスポートパスを個別に確認してください。表示名が同じでも、設定内容が同じとは限りません。

現在のネットワークサービスのプロキシ状態を確認

クライアントでシステムプロキシを有効にした後、「システム設定 → ネットワーク」を開き、現在使用中のWi-FiまたはEthernetサービスを選択して「詳細 → プロキシ」を確認します。Webプロキシ、安全なWebプロキシ、SOCKSプロキシの設定がクライアントの内容と一致しているか確認してください。OSのバージョンによって画面の項目名は多少異なります。重要なのは、接続中のネットワークサービスを確認することです。未接続のインターフェースを見ても意味がありません。アドレスとポートは実際の待ち受け先に合わせ、プロトコルの種類も一致させてください。

Wi-Fiの切り替え、有線接続、ネットワークロケーションの変更後にブラウザーの動作が変わった場合は、現在のサービスのプロキシ設定を再確認してください。アプリによっては独自のネットワーク設定を保持し、システムプロキシに従わないことがあります。アプリ内で「システムプロキシを使用」が選ばれているか確認しましょう。ブラウザー拡張機能がプロキシを制御していないかも確認してください。影響を調べるために閲覧データをすべて削除する必要はありません。クリーンな設定で試すか、拡張機能を一時的に無効にした状態と比較してください。

TUN、スリープ、終了後の復元

システムプロキシに従わないアプリも制御する必要がある場合は、TUNを試します。クライアントの案内に従って必要な権限を付与し、有効にした後はログでインターフェースとルートが作成されたか確認してください。切り替えても通信できない場合は、まずTUNをオフにし、通常のシステムプロキシが機能するか確認します。その後、権限、他のVPN、DNS設定を調べてください。システムプロキシとTUNの設定を一度に何度も切り替えると、実際にどの経路が変わったのか判断しにくくなります。

スリープから復帰すると、ネットワークインターフェースが再作成されることがあります。復帰後に接続できない場合は、まずネットワークが復旧しているか確かめてから、接続を再起動するかトラフィック制御方式を再度有効にします。特定のWi-Fiだけで失敗する場合は、認証ページが必要なネットワークか確認し、必要ならプロキシを一時停止して通常の認証を済ませてください。通常、サブスクリプションやノード設定を削除する必要はありません。重複したグループを作る前に、ネットワーク復帰時の問題かどうか切り分けましょう。

Android：サブスクリプションの追加とVPNによる通信制御

v2rayNGとv2flyNGの選び方

Androidのダウンロード項目では、Xrayカーネルを使う v2rayNGを第一候補にしてください。V2Flyエコシステムの設定が必要な場合は、v2flyNGを選択肢に加えます。比較的新しい一般的なスマートフォンでは通常arm64を選びます。端末のアーキテクチャが分からない場合は、汎用版を検討してください。汎用版は幅広いアーキテクチャに対応しますが、OSのバージョンやハードウェアの互換要件を回避できるわけではありません。対応するノード形式はアプリによって異なります。どちらもQRコードを読み取れるからといって、すべてのプロトコルが共通で使えるとは限りません。

インストーラーを開くと、ファイル管理アプリやブラウザーからのアプリインストールを許可するよう求められることがあります。必要な提供元だけを今回のインストール用に許可し、インストール後はシステム設定から取り消せます。既存アプリと競合すると表示された場合は、同じアプリの更新かどうか、インストール元が一致しているかを先に確認してください。すぐに旧アプリをアンインストールしないでください。アンインストールすると、ローカルノード、アプリごとのルール、サブスクリプショングループが削除されることがあります。設定をバックアップしてから競合に対処しましょう。

サブスクリプションの追加とクリップボードからのインポート

v2rayNGでは、サイドメニューから「サブスクリプショングループ設定」を開き、追加画面でメモとサブスクリプションURL全体を入力して保存します。メイン画面に戻り、メニューから「サブスクリプションを更新」を実行してください。単一の共有リンクを追加する場合は、メイン画面の追加メニューから「クリップボードからインポート」を選びます。QRコードはスキャン機能を使ってください。v2flyNGではメニューの配置が異なる場合があります。「サブスクリプショングループ設定」と更新操作を探し、他のクライアントのボタン位置を共通の基準と考えないようにしましょう。

更新してもノードが表示されない場合は、コピーしたものがアカウント管理ページではなく、実際のサブスクリプションURLか確認してください。接続元によっては追加のリクエスト条件が必要な形式を返すことがあり、モバイルクライアントでは認識できない場合もあります。ログを開き、ネットワーク接続の失敗か形式の解析エラーかを確認したうえで、設定の提供元に対応形式を問い合わせてください。サブスクリプションURL全体を公開の相談用スクリーンショットに載せてはいけません。ノードアドレスを隠しても、クエリパラメーターに含まれるアカウント情報を第三者に利用されるおそれがあります。

接続を開始し、システムVPNの許可を確認

メイン画面でノードを選び、選択状態を確認してから右下の接続ボタンをタップします。初回接続時はAndroidのVPN接続リクエストが表示されます。許可すると、クライアントが端末内の通信制御インターフェースを作成できるようになります。この許可は端末の通信をクライアントに渡すためのもので、リモートノードへの接続成功を示すものではありません。システムにVPNアイコンが表示されても、通信制御サービスが動作中だと分かるだけです。ログと実際の通信を確認し、リモートとのハンドシェイクやルーティングが正常か判断してください。

同じユーザー環境で他のVPNアプリを使っている場合、システムの通信制御機能を取り合うことがあります。クライアントを起動した際に別の接続が停止した場合は、両方がVPNサービスを使用していないか確認してください。アプリごとに通信を分ける場合は、クライアントの「設定 → アプリごとのプロキシ」でモードを選び、「選択したアプリをプロキシ経由にする」のか「選択したアプリを除外する」のかをよく確認します。対象アプリの一覧を変更した後は接続を再確立し、対象アプリを開いて動作を確認してください。チェックの有無だけで適用方向を判断してはいけません。

バックグラウンド制限とネットワークの切り替え

バックグラウンドに移ると頻繁に切断される場合は、Androidの「設定 → アプリ → v2rayNG → バッテリー」でバックグラウンド制限を確認します。メーカーによっては「バッテリーの最適化」「バックグラウンド管理」「自動起動管理」などに項目があります。必要に応じてバックグラウンドでの実行を許可し、画面ロック後にシステムがサービスを停止しないようにしてください。すべてのアプリを無制限にする必要はありません。接続を維持したいクライアントだけを変更し、電池と通信量への影響も確認しましょう。

Wi-Fiとモバイルデータを切り替えると、ローカルアドレス、ルーティング、名前解決の環境が変わります。切り替え後に接続が止まった場合は、接続をいったん停止して再開し、ノードのアドレスを再解決できるか確認してください。特定のアプリだけ失敗する場合は、アプリごとのルール、アプリ独自のプロキシ設定、バックグラウンド通信の権限を確認します。すべてのアプリが同時に失敗する場合は、アクティブノードと基本ネットワークを調べましょう。接続アイコンは表示されているのにログへ新しいリクエストが出ない場合、すぐにプロトコルを変更するのではなく、通信がサービスに届いているか確認します。

別のスマートフォンに移行する場合は、まずサブスクリプションを追加し直し、その後アプリごとのルールを個別に復元してください。アプリの一覧は新しい端末にインストールされたソフトに依存するため、古い一覧をそのまま使うと対象アプリが漏れることがあります。QRコードや共有リンクで移行できるのは該当ノードだけで、サブスクリプションの更新先、DNS、ルーティング設定まで含まれるとは限りません。複数端末での設定はノードと設定の同期方法をご覧ください。

Linux：パッケージ形式、デスクトッププロキシ、権限

ディストリビューションとアーキテクチャに合ったパッケージを選ぶ

Linuxデスクトップでは v2rayNを使用します。まずシステム情報でディストリビューションとプロセッサーのアーキテクチャを確認し、Linuxのダウンロード項目からパッケージを選んでください。Debian系では通常deb、RPM系のパッケージ管理を使うディストリビューションではrpmを選びます。拡張子を書き換えて相互に使える圧縮ファイルではありません。一般的なデスクトップCPUにはx64、ARM端末には対応するarm64のパッケージを選びます。ディストリビューション、アーキテクチャ、デスクトップ環境のすべてが一致している必要があります。

システムのソフトウェアインストーラーでパッケージを開き、依存関係の表示を確認して、ディストリビューションの通常の手順でインストールします。不足している依存関係が報告された場合は、まずシステムのパッケージリポジトリが利用できるか確認してください。他の端末から動的ライブラリをコピーしてプログラムのディレクトリに置くのは避けましょう。インストール後はアプリメニューから v2rayNを起動し、画面とログが正常に表示されるか確認します。GUIのないリモート環境は、ここで扱うデスクトップクライアントの手順とは異なります。デスクトップのシステムプロキシ設定をバックグラウンドサービスに流用しないでください。

サブスクリプションの追加と設定ディレクトリの権限

「サブスクリプショングループ → サブスクリプショングループ設定」でURLを追加して保存し、現在のサブスクリプションを更新した後、一覧からアクティブサーバーを設定します。初回起動は一般ユーザーで行い、そのユーザーが管理できる場所に設定を書き込んでください。管理者権限で起動したことがあり、その後保存できない、または更新に失敗する場合は、設定ディレクトリの所有者とアクセス権を確認します。ディレクトリ権限の問題を隠すため、GUIアプリ全体を常に高い権限で実行するのは避けてください。

更新に失敗した場合は、ログに記録されたリクエストエラーを確認します。基本ネットワークが使えていてもサブスクリプションにアクセスできないことがあり、必ずしもクライアントのインストール不良とは限りません。URLの期限切れ、ノード一覧以外の内容の返却、既存プロキシ経由での更新が必要といった原因が考えられます。インポート後もトランスポートやTLSの項目が認識されているか確認してください。デスクトップアプリが起動できるのは画面が動作している証拠にすぎません。カーネルの起動、設定の生成、リモートとのハンドシェイクはそれぞれ個別に確認し、まとめて「インストール成功」と判断しないでください。

GNOME、KDE、アプリごとのプロキシ設定の違い

GNOMEデスクトップでは通常「設定 → ネットワーク → ネットワークプロキシ」で手動プロキシを設定します。KDE Plasmaでは通常「システム設定 → ネットワーク → プロキシ」で確認できます。項目名や分類はデスクトップ環境のバージョンによって異なります。プロキシのプロトコル、アドレス、ポートをv2rayNの実際の待ち受け設定に合わせてください。HTTPとSOCKSは、ポート番号が近いという理由だけで置き換えられません。クライアントによるシステムプロキシの自動設定が反映されない場合は、まずデスクトップのプロキシ画面を確認し、それから手動設定を検討します。

デスクトップのプロキシ設定がターミナルのプログラムに適用されるとは限らず、環境変数が起動済みのGUIアプリに影響するとも限りません。アプリからリクエストが記録されない場合は、アプリ独自のネットワーク設定やプロキシ対応状況を確認してください。隔離環境で実行するアプリは独立したネットワークを使うことがあり、コンテナ内のループバックアドレスをホスト側と同じものと考えてはいけません。ホストのプロキシに接続する場合は、ネットワークの境界とアクセス制御を明確にし、待ち受け先をすべてのインターフェースに安易に広げないでください。

TUNと既存のネットワークツールを併用する

TUNを有効にする前に、通常のプロキシで通信できることを確認し、クライアントの案内に沿って仮想インターフェースと権限を設定します。ディストリビューションによって権限管理の方法が異なるため、実際のエラーと配布パッケージの説明を基準にしてください。インターフェースの作成失敗、権限不足、ルート追加失敗がログに出た場合は、該当する段階の問題から解決します。デスクトップセッション全体を管理者アカウントで実行したり、関係のないアプリにネットワーク管理権限を与えたりしないでください。

仮想マシン、コンテナネットワーク、他のVPNを使うと、ルーティングが複雑になります。TUNを有効にした後、LAN内の端末に接続できなくなった場合は、プライベートアドレスが想定どおり直接接続されているか、ネットワーク範囲が重複していないか確認してください。ルーティングルールを変更する前に元の設定を保存し、一度に変更する条件は一つにします。DNSサービスをシステムのネットワーク管理ツールが管理している場合、名前解決ファイルを手動で変更しても自動で上書きされることがあります。まず実際に使われているDNS管理方法を確認し、クライアントとシステムのどちらでドメインを解決するか決めましょう。

終了前にTUNをオフにし、デスクトップのプロキシ設定を元に戻してから、通常のブラウザーで直接接続できることを確認します。ターミナルだけに問題がある場合は、現在のセッションにプロキシ環境変数が残っていないか調べてください。すべてのアプリに影響する場合は、システムプロキシとルーティングを確認します。アップデート前にサブスクリプションとカスタムルールをバックアップし、更新後は以前と同じシンプルな設定で動作を確認してください。同時にカーネルを変更し、DNSを調整し、新しいルートを追加すると比較できる基準が失われます。

ルーティングとDNS：通信の入口と出口を分けて確認

グローバルプロキシでも端末の全通信を制御できるとは限らない

まずリクエストがクライアントに届いているかを確認し、その後でどの出口へ転送されるかを調べます。システムプロキシが影響するのはプロキシ設定に従うアプリだけです。ルーティングメニューで「グローバル」を選んでも、クライアントに届いていない通信は取り込まれません。一方、TUNを有効にしていても、ルーティングルールでLANや指定ドメインを直接接続できます。「グローバルプロキシが効かない」ときは、トラフィック制御方式、アクティブルート、対象アプリをあわせて記録してください。モード名だけで判断してはいけません。

v2rayNではメイン画面のルーティング選択からプリセットを切り替え、「設定 → ルーティング設定」でルールを確認できます。Androidクライアントでは「設定」のルーティング関連項目を開いてください。画面によってプリセット名が異なる場合があるため、展開して実際の判定条件を確認します。ルールは通常上から順に評価されるため、先にある広い条件が後の具体的な条件に優先することがあります。すべての通信に一致するルールの後ろに例外ドメインを追加しても、期待した結果にならないのが一般的です。

ドメインルールとアウトバウンドタグを確認

以下はカーネル設定におけるルーティング構造の一部で、フィールドの関係を説明する例です。このままでは起動できる完全な設定ではありません。利用可能なgeositeデータが必要であり、完全な設定内にdirectというタグのアウトバウンドが存在する必要があります。プロキシ出口は実際のノード設定で定義してください。クライアントは完全な設定を独自に生成します。編集前に、ルーティングルールの入力欄かカスタム設定ファイルかを確認し、この断片をサブスクリプションURLやノード共有リンクの入力欄へ貼り付けないようにしましょう。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      }
    ]
  }
}

geosite:cnはドメイン集合の参照であり、中国国内のすべてのアドレスをリアルタイムに地理判定するものではありません。集合の内容はデータファイルに依存し、対象ドメインのコンテンツが別名や別のリソースドメインから読み込まれることもあります。outboundTagは既存のアウトバウンドタグと一致させる必要があります。適当な名前を入力するだけでは使えません。まず少数の明確なドメインでルールが適用されるか確認し、その後で集合に広げてください。Webページの表示言語を基準にルールの正否を判断しないでください。

システムDNSとカーネルDNSの違い

DNSはドメイン名をアドレスに変換しますが、名前解決のリクエストはシステム、アプリ、カーネル、リモートプロキシのいずれから送られる場合もあります。アプリが先に名前解決を行い、IPアドレスを送信すると、クライアントから元のドメイン名を確認できないことがあります。アプリがドメイン名をプロキシに渡せば、その後の経路で解決できます。ブラウザーの暗号化DNSによって解決経路が変わることもあります。そのため「DNSを変更する」だけでは内容が曖昧です。システムのネットワーク設定、ブラウザー設定、クライアントが生成するカーネルDNSのどれを変更するのか明確にしてください。

v2rayNの「設定 → DNS設定」やAndroidクライアントの「設定」でローカルDNS、リモートDNSを確認する場合は、まず既定の設定を残して基準となる動作を確認し、変更する名前解決経路を一つに絞ります。まだ確立していないプロキシに依存するリモートDNSを使い、ノードのドメイン名もそのDNSで解決しようとすると、起動に必要な処理が循環することがあります。ノードアドレスを最初に解決できる経路を確保してください。すべてのDNSリクエストをプロキシ経由にすればよいわけではありません。

LAN、IPv6、接続確認の範囲

LAN内の端末、プリンター、ローカルサービスは通常、直接接続が必要です。接続後に外部サイトは開けるのにルーターの管理画面にアクセスできない場合は、すべてのルールを無効にするのではなく、プライベートアドレスのルーティングとローカルDNSを確認してください。IPv6も個別に確認が必要です。システムにIPv6アドレスが割り当てられていても、現在のノード、TUN、DNSの経路が同様に対応しているとは限りません。IPv4で接続できたからといって、デュアルスタック環境のすべての通信が同じルールで処理されるとは限りません。

複雑な問題では、まずクライアントのプリセットに戻してから、カスタムルールを一つずつ追加します。対象ドメイン、実際の名前解決結果、適用された出口、エラーが発生した段階を記録すると、DNSアドレスを何度も切り替えるより原因を特定しやすくなります。UDPを使うアプリだけ失敗する場合は、Webプロキシの設定だけを変えるのではなく、ノードのプロトコル、トランスポート、トラフィック制御方式がその通信に対応するか確認してください。まとめて確認できる質問はよくある質問をご覧ください。トラブル記録にはフィールド名だけを残し、個人情報は公開しないでください。

接続確認：ログ、速度測定、デバイス間の移行

基本ネットワーク、カーネル、リクエストの順に確認

まずトラフィック制御を停止し、端末が現在のネットワークで許可されている通常のWebサイトに接続できることを確認します。ホテル、学校、ゲスト用ネットワークでは先に認証が必要な場合があります。ネットワークに未接続の状態をノードのタイムアウトと誤認しないでください。次にクライアントを起動してノードを一つアクティブにし、カーネルが正常に動作するか確認します。最後に対象アプリを一つだけ開いてリクエストを送り、ログに該当する接続が記録されるか確認してください。この順序で基本ネットワーク、設定生成、プロキシ転送の各段階を分けられるため、一度に多くの設定を変えずに済みます。

ログに対象のリクエストがない場合は、まず通信を取り込む入口を確認します。システムプロキシが他のツールに上書きされていないか、アプリが独自のプロキシを使っていないか、アプリごとの一覧で対象が逆に選択されていないかを調べてください。リクエストが記録されているのにハンドシェイクが失敗する場合は、ノード情報、システム時刻、TLS、ネットワークへの到達性を確認します。転送が成功しているのにページが完全に表示されない場合は、ページ内の他のリソースドメインに適用されたルールと名前解決を調べましょう。Webページの読み込みでは複数の接続が発生するため、トップページの見出しが表示されたことだけで、すべてのリソースが正常とは判断できません。

ポート確認、実接続、ダウンロード速度測定を区別

TCPingのようなテストで主に確認できるのは、対象ポートへの接続確立です。プロキシプロトコル全体が使えることを示すものではありません。実接続の遅延測定では、プロキシのハンドシェイクとテスト先へのリクエストも行うため、実際の利用経路に近い結果が得られます。ダウンロード速度測定は一定時間内の転送量を確認します。それぞれ測定対象が異なるので、同じ数値として比較しないでください。ポートに接続できても実接続が失敗する場合は、ポートテストだけでノードを正常と判断せず、認証情報、トランスポート、TLSを確認します。

速度測定の結果は、ローカルネットワーク、テスト先、ノードの出口、同時利用による負荷に左右されます。端末や時刻、測定先が異なる結果を直接比較することはできません。影響を抑えるため、候補ノードを一度に少数だけ測り、他の大容量通信を止めてください。実際に使うノードを選ぶ際は、対象アプリからリクエストが継続して完了することを優先し、そのうえで遅延と転送速度を確認します。仕組みはTCPing、実接続の遅延、ダウンロード速度測定の違いをご覧ください。一度の測定結果が長期的な品質を保証するわけではありません。

最後の一行だけでなく、エラーが起きた段階を読む

ポートのバインドエラーは通常ローカルの起動時に発生します。接続タイムアウトはネットワーク接続やその後のハンドシェイクで発生する場合があります。証明書エラーはホスト名、システム時刻、検証要件をあわせて確認してください。エラーの前後数行も読み、そのとき有効だったノードと出口を特定します。長時間保存されたログには古い接続エラーが混在することがあります。切り替え後のテストでは時刻を記録し、前のノードの失敗を現在のノードの問題と取り違えないようにしましょう。

問い合わせに必要な記録には、クライアント名、OS、トラフィック制御方式、エラーのキーワード、再現手順を残してください。サブスクリプションURL、認証情報、機密性の高いドメイン、アカウント情報は削除します。見やすいスクリーンショットを作るために設定ファイル全体を公開する必要はありません。通常は関連するフィールドとエラー部分だけで十分です。ノードのタイムアウトが再現する場合は、システム時刻、ポート、TLS、ルーティングの確認手順に沿って記録してください。確認した項目には結果を記載し、「全部試した」だけで済ませないようにしましょう。

サブスクリプションの同期とローカル設定の移行

複数端末で同じノードを使う場合は、各端末に利用権限のある同じサブスクリプションを追加し、それぞれで更新する方法が確実です。同期されるのはサーバーから返されるノード一覧であり、アクティブノード、システムプロキシ、TUN、アプリごとの一覧、カスタムDNSは自動で同期されません。パソコンとスマートフォンではネットワーク環境が異なるため、適切なルーティングも違うことがあります。ノードの接続元を共通にしつつ、各端末で通信制御方式を個別に確認すればよく、すべてのスイッチを同じにする必要はありません。

手動でのノード共有は単一設定の一時的な移行に、完全なバックアップはローカルの管理方法の保存に適しています。用途は異なります。バックアップを復元する前に現在の設定を保存し、ファイルパスとプラットフォーム依存の項目を確認してください。クライアントやカーネルを変更した場合は、まず少数のノードをインポートしてテストし、プロトコル項目が揃っていることを確認してからすべてのグループを移行します。サブスクリプションの更新で接続元が管理するノードは上書きされる場合があります。手動で変更する前に別のコピーを保存してください。古いバックアップを復元しても、すでに無効になったリモートアカウントは復元されません。

よくある設定トラブル：原因の範囲を絞る

サブスクリプションは更新できるのに、ノードへ接続できないのはなぜ？

サブスクリプションサーバーとノードサーバーは別のアドレスである場合があります。更新に成功したことから分かるのは、クライアントが設定を取得して解析できたことだけです。ノードのポート、アカウント、トランスポートが使えるとは限りません。まず一覧で想定したノードが実際に有効になっているか確認し、実接続のテストとログの確認を行います。すべてのノードが失敗する場合は、基本ネットワーク、システム時刻、カーネルの起動、共通のルーティング設定を優先して調べてください。一部のノードだけ失敗する場合は、そのノードのアドレス、アカウントの状態、サーバー側のパラメーターを確認します。クライアントを何度も再インストールする必要はありません。

サブスクリプションに含まれる項目が、現在のクライアントやカーネルの対応範囲を超えている場合もあります。インポートできても、すべての拡張項目が反映されるとは限りません。特にトランスポート、TLS、固有のセキュリティパラメーターに注意してください。認識できない項目を削除して保存しただけで互換性があると考えないでください。提供元の要件を確認し、対応するクライアントとカーネルを選びます。サブスクリプション更新後に手動ノードが置き換わる場合は、同じ接続元のグループで何度も編集せず、別のグループに保存してください。

ポートには接続できるのにTLSや実接続が失敗する

TLSの確認は、システム時刻、サーバー名、証明書の要件から始めます。接続先アドレスと検証に使うサーバー名は異なる場合があります。SNIに、アクセスしたいWebサイトのドメインを適当に入力してはいけません。ノードの元の設定に沿って項目を確認し、アドレスの見た目から推測しないでください。サーバーが指定する場合は、トランスポートパスやHostなどの項目も正確に合わせます。ポートと認証情報だけを確認していると、ハンドシェイク失敗の本当の原因を見落とすことがあります。

証明書検証を無効にすることを一般的な修正方法にしないでください。接続のセキュリティ境界が変わるうえ、設定ミスを隠すだけの場合もあります。時刻が正しいのに名前の不一致が出る場合は、古い設定をインポートしていないか、誤ったサーバーに接続していないか、現在のネットワークに認証ページが割り込んでいないかを確認します。元の設定に誤りがある場合は、正しい情報を入手してから再試行してください。複数の設定を続けて切り替えるとログを比較できなくなります。元の設定を残し、一項目ずつ確認する方法が効果的です。

接続後にWebサイトとLANの動作が異なる

ブラウザーは使えるのに他のアプリが使えない場合は、ノードをすぐ変更せず、そのアプリがシステムプロキシに従うか確認してください。TUNを有効にした後でLANだけに問題が出た場合は、プライベートネットワークへの直接接続とローカルDNSを確認します。特定のWebサイトだけ失敗し、他は正常な場合は、リソースドメインに異なるルールが適用されていないか、アプリが古い名前解決結果をキャッシュしていないか調べてください。対象アプリを再起動して再確認しても構いませんが、すべての設定を消したり、サブスクリプションをすべて削除したりする必要はありません。

外部への接続とLANの両方に問題がある場合は、TUNをオフにし、シンプルなシステムプロキシ設定と比較してください。シンプルなモードで動作するなら、問題をTUNの権限、ルーティング、DNS、他のネットワークツールとの競合に絞れます。リモートで端末を操作している場合は特に注意が必要です。デフォルトルートの切り替えで管理接続が切断されることがあります。全端末の通信に影響する設定を変更する前に、ローカルで復旧する手段を用意するか、既存のセッションを維持してください。復旧できない環境でネットワーク設定を複数同時に変更しないでください。

クライアントを終了した後もインターネットに接続できないのはなぜ？

まずシステムがクライアントのローカル待ち受けポートを参照したままになっていないか確認します。Windowsではネットワークのプロキシ設定、macOSでは現在のネットワークサービスのプロキシ画面、Linuxではデスクトップのプロキシ設定とアプリの環境を確認してください。クライアント停止後はそのポートにサービスがありません。プロキシ設定に従うアプリは接続できなくなります。クライアントを再起動してシステムプロキシを解除するか、元のネットワーク設定の記録を残したうえで手動で復元します。組織で使っているプロキシスクリプトまで一緒に削除しないでください。

AndroidではVPNが停止しているか、システムの「VPN」設定で「常時接続」や「VPNを使用しない接続をブロック」が有効になっていないか確認します。通信をブロックする設定が有効だと、サービス停止後も通常の接続が制限されることがあります。実際の利用方法に合わせて設定を戻し、基本ネットワークを確認してください。パソコンに仮想インターフェースやルートの問題が残っている場合は、他のネットワークツールを通常の手順で終了してからネットワーク接続を再起動します。一つのクライアントの問題に対処するために、すべてのネットワークアダプターを無作為に削除しないでください。

シンプルな設定に戻すタイミング

ログ、プロキシの状態、実際のアプリの動作に食い違いがある場合は、まず現在の状態を保存し、ノード一つ、通信制御の入口一つ、デフォルトルートに戻してください。この基準で動作することを確認したら、DNS、ルール分岐、アプリごとの設定、TUNを順番に戻します。基本的な操作手順は使い方ガイドを、クライアントの選び方はクライアント比較をご覧ください。さらに調べる場合は、「ソフトが使えない」といった曖昧な説明ではなく、「サブスクリプションのリクエストに失敗」「TLSハンドシェイクに失敗」のように問題が発生した段階を明確にすると、原因を特定しやすくなります。