V2Ray クライアント完全設定ガイド

基本概念とクライアントの選び方

クライアント、コア、ノード、サブスクリプションを分けて理解する

V2Rayの利用環境は4つのレイヤーに分けて考えられます。クライアントは画面、メニュー、サブスクリプション管理、システムへの取り込み機能を提供します。コアはプロトコルを解析し、外向きの接続を確立してルーティングルールを実行します。ノードは利用可能なサーバー接続パラメータのまとまりで、サブスクリプションはノードの一括配布と更新情報を提供するURLです。v2rayN、v2rayNG、v2flyNGはいずれもクライアントであり、プロトコルそのものではありません。XrayとV2Flyは代表的なコアの系統で、クライアントは設定に応じて適切なコアを呼び出し、実際の接続を行います。

レイヤー構造を理解すると、多くの障害を切り分けやすくなります。クライアントの画面が開くのは、画面レイヤーが正常だという意味にすぎません。サブスクリプション一覧にノードが表示されても、内容が解析されたことしか分かりません。ノードをアクティブサーバーに設定しても、アプリの通信がクライアントに渡ったとは限りません。コアが正常に起動し、ローカルの待受ポートが競合せず、システムプロキシまたはTUNが対象アプリを取り込んでいることまで確認する必要があります。どこか1つが止まると、最終的には「Webページが開かない」と表示されても、対処方法はまったく異なります。

3つのクライアントの選び方

Windows、macOS、Linuxのデスクトップ環境では、まずv2rayNを選ぶのがおすすめです。サブスクリプション、サーバー、ルーティングルール、システムプロキシ、TUNを一元管理でき、初回利用から複雑なルーティングまで対応できます。Windowsではデスクトップ版と従来のWPF版を選択できます。デスクトップ版はクロスプラットフォームのUIを採用し、異なるデスクトップOSでも近い操作手順を保ちやすい一方、WPF版はWindows向けで、より従来型のUIと依存関係を備えています。インストールパッケージは、現在の環境に合うものをWindowsダウンロードエリアから選択してください。

Android端末では、まずv2rayNGを使用するのがおすすめです。主にXrayコアを実行層として使い、一般的なプロトコルとルーティング設定を1つの画面で管理できます。V2Flyのコア体系を使う必要がある場合はv2flyNGを選択してください。サブスクリプションの導入、ノード選択、接続開始の流れは似ていますが、コアの機能と一部の設定項目は完全には一致しません。一方のクライアントから書き出した高度な設定が、もう一方でもそのまま読み込めると決めつけないでください。移行時は、プロトコル項目とルーティングルールを先に確認します。

プロトコル名とクライアント名は別物

VMess、VLESS、Trojanなどは接続プロトコルまたは認証方式を表し、REALITYやTLSなどの項目は通信の安全性やハンドシェイクの特徴を表します。TCP、WebSocket、gRPCはトランスポート層の設定です。クライアントはこれらの項目を、コアが実行できる設定に整理します。ノードを導入する際は、アドレス、ポート、ユーザーID、通信方式、暗号化またはセキュリティ設定の整合性を保つ必要があります。プロトコル名が同じだからといって、2つのノード設定が同等だとは限りません。

初心者の段階で、すべての項目を手入力する必要はありません。信頼できる方法は、まずサブスクリプションから導入し、提供元が管理する完全なパラメータを利用することです。その後、ノード情報とログの読み方を学びます。手動変更の前にはノードを複製し、元の設定を上書きしないようにしてください。各項目の意味をさらに理解したい場合は、用語集でプロトコル、コア、サブスクリプション、ルーティングの概念を確認できます。「画面で管理し、コアが実行し、ノードがパラメータを提供し、サブスクリプションが配布する」というモデルを持つことが、後のインストールとトラブル対処の基礎になります。

インストールと初回起動

ダウンロード前にOSとプロセッサアーキテクチャを確認する

インストールパッケージは、OS、プロセッサアーキテクチャ、クライアントのUI系統に一致している必要があります。Windowsの一般的な端末ではx64パッケージを使用します。macOSではApple SiliconかIntelかを先に確認してください。Linuxではディストリビューションのパッケージ形式に加え、x64とarm64も区別します。Androidの主流端末では通常arm64を優先し、アーキテクチャが不明な場合やインストールを拒否された場合のみ汎用パッケージを試します。すべての入口はダウンロードページにまとめています。他のプラットフォーム用ファイルを改名してインストールしないでください。

Windowsでは、デスクトップ版とWPF版のどちらを使うかも決める必要があります。macOSやLinuxと近い操作手順を望むならデスクトップ版、従来のWindows UIを前提にした操作や設定に慣れているならWPF版が向いています。どちらもv2rayNですが、実行環境、UIコンポーネント、一部メニューの位置が異なります。説明のスクリーンショットと現在の画面が違う場合は、機能がないと判断する前に使用中の系統を確認してください。

Windows、macOS、Linuxの起動ポイント

Windowsではインストール後、通常のユーザーディレクトリから起動し、設定ディレクトリに書き込み権限があることを確認します。ダブルクリックしても画面が表示されない場合は、必要な実行環境、深すぎるインストールパス、読み取り専用のディレクトリ、設定やログ作成を妨げる保護機能を順に確認してください。圧縮ファイルのプレビュー画面から直接実行せず、完全に解凍するかインストールを完了させてください。起動直後に終了する場合の切り分けは、ランタイムと権限の確認を参照してください。

macOSで初めて開くとき、アプリの入手元やネットワーク関連の権限を確認するよう求められる場合があります。システム設定の「プライバシーとセキュリティ」で明示的に許可し、クライアントを再起動してください。システムプロキシやTUNを有効にすると、管理者による確認が必要になることもあります。これはネットワーク設定を変更するために必要な操作です。詳しい手順はmacOSのインストールとネットワーク権限を参照してください。アプリは開くのにネットワーク設定を変更できない場合は、サブスクリプションを再導入する前に権限を確認します。

Linuxでは、まずディストリビューションに合うdebまたはrpmパッケージを選び、現在のデスクトップセッションがシステムプロキシのインターフェースを提供しているか確認します。インストール成功はプログラムファイルが配置されたことを示すだけで、トレイアイコン、自動起動、システムプロキシへの書き込みはデスクトップ環境にも左右されます。軽量なウィンドウマネージャーを使う場合は、ブラウザやターミナルでローカルプロキシを個別に指定する必要があるかもしれません。クライアントのログと設定ディレクトリは現在のユーザーが所有し、毎回権限昇格に頼らないようにしてください。

Androidのインストールとシステム接続の確認

Androidにv2rayNGまたはv2flyNGをインストールすると、初回接続時にシステムレベルの接続確認が表示されます。許可すると、通常はステータスバーにシステムが提供する接続状態の表示が出ます。この確認は、システムがクライアントによるローカルネットワークインターフェースの作成を許可したことを示すだけで、選択したノードが利用可能とは限りません。開始ボタンを押すとすぐ停止する場合は、アプリのログを開き、ノード項目、ドメイン解決、ポート到達性、コアの起動結果を確認してください。

システムの省電力機能は、画面消灯後にバックグラウンド動作を制限することがあります。長時間接続を維持する必要がある場合は、システムのアプリ管理で、実際の用途に応じたバックグラウンド動作を許可し、ネットワーク切り替え後に復旧できるか確認してください。電池管理の名称は端末によって異なります。判断基準はクライアントのプロセスがシステムに停止させられているかどうかであり、すべての権限を機械的に有効にすることではありません。前面表示中だけ使うなら、通常は既定の電池設定の方がリソースを節約できます。

初回起動後の基準チェック

メイン画面に入ったら、すぐに複数の高度な機能を有効にしないでください。クライアントが設定を保存できること、コアファイルを呼び出せること、ローカルポートが他のプログラムと競合していないこと、ログ画面に起動記録が出ることを順に確認します。デスクトップでは、LANに直接公開しないよう、まず既定のローカル待受アドレスを維持します。その後、設定またはサブスクリプションを1つ導入し、アクティブノードを選び、最後にシステムプロキシを有効にしてください。一度に変更する変数を1つに絞れば、異常が起きたとき原因を特定できます。

Windows:
netstat -ano | findstr LISTENING

macOS / Linux:
lsof -nP -iTCP -sTCP:LISTEN

上記のコマンドは、本機で待ち受けているポートを確認するためのものです。クライアントがポート競合を報告した場合は、まず設定でHTTP、SOCKS、APIなどのローカルポートを確認し、次にプロセス一覧から競合しているプログラムを特定します。正体の分からないシステムプロセスをむやみに終了しないでください。未使用のポートへクライアントを変更し、ブラウザ、ターミナル、その他の手動プロキシアプリのポートも合わせて変更する方が安全です。

サブスクリプションの導入とノード管理

サブスクリプションの役割と導入手順

サブスクリプションURLは、ノード設定を一括取得するために使われ、名称の調整、パラメータの更新、無効なノードの削除も担うことがあります。クライアントのインストールパッケージでも、固定された単一ノードでもありません。導入時はURL全体をコピーし、クライアントのサブスクリプショングループまたは設定画面で項目を追加します。識別しやすいメモを入力し、手動更新を1回実行してください。完了後はサーバー一覧に戻り、新しいノードが想定したグループに入り、更新ログに解析エラーがないことを確認します。

v2rayNでは通常、先にサブスクリプション項目を作成してから更新します。v2rayNGとv2flyNGでは入口の名称が少し異なる場合がありますが、考え方は同じです。URLにクエリパラメータや長いエンコード文字列が含まれる場合、末尾の文字を欠落させずにコピーしてください。チャットアプリで転送した後、途中で切れた表示テキストを使うのも避けます。サブスクリプションは機密性のある設定なので、使用するクライアントだけに保存し、スクリーンショット、公開ログ、共有ドキュメントには載せないでください。

更新成功、解析成功、ノード利用可能は別の結果

クライアントが取得完了と表示しても、サブスクリプションの内容をダウンロードできただけです。一覧にノードが表示されるのは、内容が認識されたことを示します。特定のノードで接続を確立できて初めて、現在のネットワーク、ノードパラメータ、コアの機能が条件を満たしたと判断できます。確認時は、ネットワーク要求が有効な内容を返したか、解析後にノードが生成されたか、アクティブノードの起動後に成功またはエラーの明確なログがあるかを確認します。3つを混同すると、ノード障害の際にサブスクリプションURLを何度も変更することになります。

サブスクリプションの更新に失敗したら、まず端末自身のネットワークが使えることを確認し、次にシステムの日付と時刻に大きなずれがないか、URLが完全かを確認します。クライアントがすでに無効なプロキシを使って更新している場合は、一時的にシステムプロキシを無効にするか、サブスクリプション設定で更新時のプロキシ方針を変更します。更新後にノード数が変わらなくても、必ずしも失敗とは限りません。サーバー側の内容が変わらなければ一覧はそのままなので、更新時刻とログの結論を基準に判断してください。

グループ、名称、アクティブノード

複数のサブスクリプションを使う場合は、提供元ごとに分かりやすい名前を付け、すべてのノードを名前のない1つの一覧にまとめないようにします。グループには、更新時に提供元を識別する、障害時に素早く切り替える、整理時に他の設定を誤削除しないという3つの役割があります。ノードのメモには、サーバー側が示す地域や用途の情報を残し、「ノード1」「予備2」だけにしないでください。手動設定は別に置き、サブスクリプション更新で上書きされたり、リモート項目と混同されたりしないようにします。

アクティブノードは、現在のクライアントが主要な外向き接続を確立するために使う項目です。ノードを選択した後は、一覧でハイライトされているだけでなく、実際にアクティブサーバーとして設定されていることを確認します。画面によっては、ダブルクリック、コンテキストメニュー、専用コマンドで設定します。切り替え後はステータスバーとコアのログを見て、外向き設定が再読み込みされたことを確認してください。一覧の行を選んだだけでコアが再読み込みされていなければ、実際の通信は以前のノードを使い続ける可能性があります。

更新方針と設定の保持

自動更新は内容の変化が多いサブスクリプションに適していますが、間隔を短くしすぎないでください。頻繁な更新でノードの品質が上がるわけではなく、無意味な要求が増え、手動で切り分ける際に一覧がいつ変わったか分かりにくくなります。普段は適切な周期更新を設定し、使用前に1回手動更新する程度で十分です。接続障害が起きたら、まず現在の設定をテストしてから更新するか決めてください。ノード一覧とクライアント設定を同時に変えないことが重要です。

サブスクリプション更新では、同名ノードが置き換えられたり、リモート側で削除された項目が消えたりすることがあります。ノードの通信パラメータをローカルで変更した場合は、先に独立した設定として複製し、変更理由を記録してください。次回更新でリモート側の値に戻る可能性があるためです。クライアントを移行する前には、内蔵のバックアップまたはエクスポート機能でサブスクリプショングループ、ルーティング設定、各種オプションを保存します。ノードの共有テキストだけでは、クライアント全体の設定を網羅できません。

更新後にすべてのノードが同時に異常になった場合は、まずサブスクリプションの内容、クライアントのコア、ローカルネットワークを確認します。1つのノードだけが異常なら、その項目のパラメータまたはサーバー側の状態である可能性が高くなります。詳しい失敗パターンは、サイト内検索で「v2rayN サブスクリプション 更新失敗」と検索すると関連情報を確認できます。この章を終えた時点で、サブスクリプションを手動更新でき、ノードグループを整理し、アクティブノードを明確に切り替え、ログから取得結果と接続結果を区別できれば十分です。

システムプロキシとプロキシモード

ローカル待受とシステムプロキシの関係

コアが起動すると、本機にHTTPやSOCKSなどの待受ポートが作成されます。アプリがこれらのポートへ要求を渡すと、クライアントがルーティングルールに従って直結、プロキシ、ブロックのいずれかを選びます。システムプロキシは「システム設定に従うアプリへ、要求の送り先を伝える」仕組みであり、プロトコル接続そのものを担当するものではありません。クライアント終了後も古いプロキシアドレスが残っていると、ブラウザはローカルポートへ接続できずネットワークにアクセスできなくなることがあります。終了時はクライアントに通常の手順でシステム設定を復元させてください。

多くのデスクトップブラウザはシステムプロキシを読み取りますが、コマンドラインツール、一部の開発環境、ゲーム、独立したネットワークコンポーネントは無視することがあります。ブラウザで動作していても、すべてのアプリが取り込まれたとは限りません。逆に、ターミナルで動作しなくてもノードが異常とは限りません。アプリの種類に応じて、システムプロキシ、アプリ内の手動プロキシ、TUNを使い分けてください。系統別の確認はブラウザとターミナルのプロキシ対処を参照してください。

グローバル、ルール、直結モード

グローバルモードは通常、取り込み条件を満たす大部分の通信をプロキシ経由で外向き接続することを意味し、ノードとローカル待受が正常か短時間で確認するのに適しています。ルールモードでは、ドメイン、IP、ポート、プロセス、ルールセットなどに応じて出口を決めます。日常利用の中心となる方式です。直結モードでは、取り込まれた通信をローカルネットワークから直接送信し、比較テストや一時的なプロキシ停止に使います。モード名の翻訳はクライアントによって少し異なるため、実際の外向き動作を基準にしてください。

初回の切り分けでは、まずグローバルモードへ切り替えます。グローバルでは使えるのにルールモードで使えない場合、原因は多くがルーティングの照合またはDNS判定にあります。両方とも使えない場合は、ノード、コア、ローカルポートに戻って確認します。直結モードでも異常なら、システムプロキシの残留、アプリ固有の設定、ローカルネットワークが原因かもしれません。この比較で範囲を素早く絞れますが、日常的にグローバルモードでルール設計を代用するのはおすすめしません。

手動プロキシアプリへの入力方法

手動プロキシが必要なアプリには、クライアントが実際に待ち受けているアドレスとポートを入力します。本機のアプリでは通常 127.0.0.1 を使い、プロトコル種別とポートを一致させてください。SOCKSポートをHTTPプロキシ専用の欄に入力してはいけません。クライアントが既定ポートから変更されている場合は、すべての手動設定も更新します。LAN上の端末は、自身の 127.0.0.1 からデスクトップクライアントを指すことはできません。クライアントを実行している端末のLANアドレスを使い、LAN共有を明示的に有効にしてください。

HTTPプロキシ環境変数の例：
set HTTP_PROXY=http://127.0.0.1:10809
set HTTPS_PROXY=http://127.0.0.1:10809

macOS / Linuxの現在のターミナルセッション：
export HTTP_PROXY=http://127.0.0.1:10809
export HTTPS_PROXY=http://127.0.0.1:10809

これらの変数は、それを読み取るプログラムと現在のスコープにだけ影響します。ターミナルを閉じた後も保持されるかどうかは、シェルの設定ファイルに書き込んだかで決まります。トラブル対処では、まず一時設定で試し、動作を確認してから永続化を判断してください。削除時は各OSに対応する変数の削除方法を使い、クライアント終了後もターミナルが閉じたローカルポートへ要求し続ける事態を避けます。SOCKSプロキシでは、アプリがプロキシ経由でドメインを解決するかどうかも関係するため、アプリ固有の項目を確認してください。

LAN共有の範囲と注意点

LAN共有を有効にすると、クライアントの待受ポートへ同じネットワーク内の他の端末からアクセスできるようになります。有効化する前に、待受アドレス、システムファイアウォール、現在のネットワーク環境を確認してください。信頼できる家庭内ネットワークと公共ネットワークでは異なる方針を採用し、公共ネットワークで一時テストのために待受範囲を広げるべきではありません。共有する端末には、クライアントを実行しているPCのLANアドレスと対応ポートを入力します。PCがスリープしたり、ネットワークを切り替えたり、アドレスが変わったりすると共有接続は切断されます。

LAN共有はローカルプロキシの入口を提供するだけで、他の端末のシステムネットワーク設定を自動変更するものではありません。各端末でアプリプロキシまたはシステムプロキシを個別に設定する必要があります。同じネットワークの端末からポートへ接続できない場合は、まずホスト上で待受を確認し、次にファイアウォールの受信規則と端末間通信の可否を確認します。ポートに接続できても目的地へ到達できない場合は、クライアントのログとルーティング結果を確認してください。ポート到達性と外向き接続の成功を混同しないことが重要です。

ログで通信がクライアントに入ったか確認する

プロキシが有効か確認する最も直接的な方法は、Webページの結果だけで判断せず、クライアントの接続ログを見ることです。キャッシュされていない新しい要求を発生させ、ログに対応するドメイン、宛先アドレス、インバウンド種別、最終的なアウトバウンドが表示されるか確認します。記録がまったくなければ、アプリの通信はクライアントに入っていません。記録はあるのに直結されていれば、ルールが直結に一致しています。プロキシへ入った後に接続が失敗するなら、ノードまたはリモート側のハンドシェイクを確認します。ログによって「取り込まれていない」と「取り込み後に失敗した」を別の経路として扱えます。

ルーティングとルール設計

ルーティングルールが解決する問題

ルーティングは、通信がクライアントに入った後、宛先の特徴に基づいてどの出口を使うかを決めます。一般的な出口はプロキシ、直結、ブロックです。ルールではドメイン、IP、ポート、ネットワーク種別、プロセス、定義済みルールセットなどを照合できます。目的はルールを増やすことではなく、一般的な通信に安定した、説明可能な結果を与えることです。ルールが過度に重複すると、保守コストが上がり、照合順序も判断しにくくなります。

基本的なルールは、まず明確な境界を定めます。本機とLANアドレスは直結し、プロキシが必要なドメインまたはルールセットはプロキシへ、それ以外は予測可能な最終ルールへ送ります。最終ルールは重要です。前の条件に一致しなかった要求はすべてここに到達するためです。既定の出口が明確でなければ、同じルールでもクライアントやバージョンの設定によって結果が変わることがあります。

ルールの順序と最初の一致

多くのルーティングシステムはルールを順番に確認し、最初に一致した結果を採用します。範囲が具体的なルールは、より広いルールより前に置いてください。例えば、特定のサブドメインをプロキシへ送り、ドメイン全体は通常直結する場合、サブドメインのルールを先に記述します。ポート、プロセス、ドメイン条件を組み合わせるときは、すべてを同時に満たす必要があるのか、いずれかでよいのかも確認します。ルールの文面だけでなく、クライアントが項目の関係をどう実装しているかを確認してください。

ルールを変更したら設定を再読み込みし、ログで一致した項目を確認します。要求が誤った出口へ進む場合は、まず実際のドメインと解決先アドレスを記録し、どのルールに一致したかを確認してください。すぐに広いルールを追加すると、既存の条件を隠してしまう可能性があります。まずは正確なルール1つで検証し、方向性が正しいと確認してから、ドメインサフィックス、IP範囲、ルールセットへ拡張します。

ドメイン照合とIP照合の違い

ドメインルールは、ルーティング段階でクライアントが宛先ドメインを認識できることに依存します。アプリがローカルで名前解決を済ませ、IPだけをプロキシへ渡す場合、ドメイン条件を使えないことがあります。一方、IPルールは解決結果とアドレスの所属に依存するため、動的アドレスを使うコンテンツサービスでは頻繁に変化する可能性があります。ルーターのドメイン方針、DNS設定、インバウンドプロトコルが、見える情報に共同で影響します。ドメインルールが機能しないときは、綴りだけを確認しても不十分です。

ドメインサフィックスルールは、構造が安定した複数のサブドメインをまとめて扱うのに適しています。完全なドメインルールは、例外を正確に指定する場合に向いています。IP範囲ルールでは正しいCIDR表記を使い、プレフィックス長が範囲を決めることに注意してください。範囲を広くしすぎると、無関係な通信まで一致します。LANのプライベートアドレスは通常直結し、内部サービスが外部経路へ回らないようにします。ポートルールはプロトコル境界が明確なサービスに適していますが、現代のアプリは複数ポートを使うこともあるため、1つのポートだけで全通信を判断しないでください。

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

この例では、一般的な項目構造として、プライベートアドレスを直結し、指定したテストドメインをプロキシへ送っています。実際のクライアントではグラフィカルな画面が設定を生成する場合があり、アウトバウンドのラベルも既存の名称と一致させる必要があります。例に使った予約済みテストドメインは構文説明専用です。断片を完全な設定へ統合する前に、現在のルールをエクスポートまたはバックアップし、JSONのカンマ、括弧、配列の階層が正しいことを確認してください。

DNSとルーティングを同時に確認する理由

DNSはドメインからアドレスを得る方法を決め、ルーティングは要求の出口を決めます。DNS検索と後続の接続が異なる経路を使うと、あるネットワークに適した解決結果を得た後、実際の接続だけ別のネットワークから送信されることがあります。ルールモードで異常がありグローバルモードでは正常な場合は、ドメイン方針、DNSサーバー、キャッシュ結果、プロキシ側で名前解決しているかを確認します。設定を切り替えた直後は、古いキャッシュが短時間判断に影響する場合もあります。

DNS、ルーティングルール、プロキシモードを同時に大きく変更しないでください。まず既定のDNSを維持し、正確なドメインルールでルーティングを検証する方が安全です。ルーティングが機能すると確認してから、名前解決の要件に応じてDNSを調整します。問題が起きたら、元のドメイン、解決先アドレス、一致したルール、最終アウトバウンドの4項目を記録します。4つがそろえば、解決、照合、接続のどの段階に問題があるか判断しやすくなります。

保守しやすいルール階層を作る

長期運用するルールは4層に分けられます。最初に優先処理が必要な例外、次にLANと本機のサービス、その後に主要ドメインまたはルールセット、最後に既定の出口を置きます。各カスタムルールには、明確な名前と用途を付けてください。短期テスト用のルールは問題解決後すぐ削除し、半年後も通信に影響し続ける状態を避けます。チームや複数端末で使う場合は、最終設定ファイルだけでなく、ルールを変更した理由も記録します。

ルールが増えたら、重複する条件、後ろに置かれていて決して一致しないルール、無効になったドメインを定期的に確認します。特定のアプリに問題がある場合は、ルール全体を並べ替えるのではなく、そのアプリ向けの最小テストルールを作ります。ルーティングを理解できている目安は、ルール表が長いことではありません。ある要求がなぜ直結、プロキシ、ブロックのいずれになったのかをログで説明し、変更後に期待どおりか検証できることです。

TUNモードと全通信の取り込み

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

システムプロキシは、アプリがOSの設定を自発的に読み取ることに依存します。一方、TUNは仮想ネットワークインターフェースを通じて、より広い範囲のIP通信を受け取ります。システムプロキシを無視するアプリ、独立したネットワークコンポーネント、統一して処理したいデスクトップ通信では、TUNの方が幅広く取り込めます。ただし対象範囲が広がる分、設定も複雑になります。DNS、ルーティングテーブル、仮想NICの権限、他のネットワークソフトが結果に関わることがあります。システムプロキシで解決できる場面では、最初からTUNを有効にする必要はありません。

TUNは「高速化」するスイッチではなく、通信がクライアントに入る方法を変える機能です。ノードの品質、プロトコルのハンドシェイク、リモート経路が、TUNを有効にしただけで改善することはありません。システムプロキシでノード接続に失敗しているなら、すぐTUNへ切り替えると新しい変数が増えるだけです。まずシステムプロキシでノードとコアを検証し、取り込めないアプリがある場合にTUNを有効にするのが適切です。

有効化前の準備

TUNを有効にする前に、ルーティングテーブルを変更したり仮想NICを作成したりする他のネットワークツールを停止します。現在のDNSとシステムプロキシの状態を記録し、クライアントに仮想インターフェースを作成する権限があることも確認してください。Windowsでは仮想NICドライバーと管理者権限、macOSではネットワーク拡張機能や関連するシステム確認、LinuxではTUNデバイスへのアクセスとルート書き込み条件を確認します。権限不足は通常、起動ログにインターフェース作成またはルート設定の失敗として明確に現れます。

初回テストではルールを単純に保ち、検証済みのアクティブノードを優先して使います。起動後は、仮想インターフェースが作成されたか、既定またはポリシールートが想定どおり書き込まれたか、DNS検索が設定した経路に入ったかを確認します。スイッチは有効なのにインターフェースが存在しない場合は権限とドライバーを確認し、インターフェースはあるのに通信がない場合はルーティングテーブルを確認します。通信は入るのにドメインだけ失敗する場合はDNSを確認します。

厳格ルーティング、自動ルーティング、バイパス範囲

自動ルーティングは通常、取り込む必要があるシステムルートをクライアントが生成し、手動設定を減らします。厳格ルーティングは仮想インターフェースを迂回する可能性を抑えますが、LANサービス、仮想マシン、コンテナ、企業ネットワークの方針と衝突することがあります。厳格な方針を有効にする前に、プリンター、ファイル共有、開発サービス、ローカル管理ページへの直結が必要か確認し、プライベートアドレスには明確なバイパスまたは直結ルールを設定します。

LANアクセスに異常があっても、すぐにTUN設定をすべて無効にしないでください。まずプライベートアドレスが誤ってプロキシへ送られていないか、LANドメインが不適切なDNSで解決されていないか、システムファイアウォールが仮想インターフェースを別ネットワークとして扱っていないかを確認します。仮想マシンとコンテナでは、ホストのNAT、ブリッジネットワーク、独立インターフェースのどれを使っているかも確認してください。ネットワーク構成によって、通信がホストのTUNを通るかどうかは異なります。

よくある競合の特定方法

TUNを有効にした後に完全にネットワークへ接続できなくなったら、まずTUNを停止して基本ネットワークが復旧することを確認し、起動ログで最後に成功した手順を確認します。停止後も異常が続く場合は、クライアントがシステムDNS、既定ルート、システムプロキシを復元したか確認してください。IPにはアクセスできるのにドメインへアクセスできない場合はDNS、LANだけ使えない場合はプライベートアドレスのルート、特定アプリだけ失敗する場合はプロセス固有のネットワークスタック、IPv4とIPv6の選択、特定インターフェースへのバインドを確認します。

システムのスリープ、ネットワーク切り替え、クライアントの異常終了により、仮想インターフェースの状態と実際の接続が一致しなくなることがあります。復旧後はまず接続を停止し、インターフェースとルートの削除が完了するまで待ってから再起動します。スイッチを短時間に何度も切り替えないでください。システムのネットワークサービスが変更を適用する時間が必要です。再起動のたびに再現する場合は、起動前後のルーティングテーブルとログを保存し、何度も無作為に再試行するのではなく、固定した失敗手順を探します。

Windowsでルーティングを確認：
route print

macOSで既定ルートを確認：
route -n get default

Linuxでルーティングを確認：
ip route

これらのコマンドはシステムルートを確認するもので、ネットワークを変更しません。TUNの有効化前後を比較する際は、既定ルート、仮想インターフェースに対応するルート、プライベートネットワークの経路を確認します。必要なインターフェースとネットワーク範囲だけを記録し、ログを共有する前にサブスクリプションURL、ノード認証情報、ローカル端末の識別情報を削除してください。この章を終えれば、問題がインターフェース未作成、ルート未取り込み、DNS不一致、ルールの出口間違いのどれか判断できるようになります。

日常の保守、バックアップ、トラブル対処

安定した更新サイクルを作る

クライアント、コア、サブスクリプションは、それぞれ別の更新対象です。クライアントの更新は画面、設定移行、システム連携を変える可能性があります。コアの更新はプロトコル実装やルーティング動作に影響することがあります。サブスクリプションの更新は主にノード内容を変えます。日常の保守では別々に記録し、障害発生時にすべてのコンポーネントを一度に更新しないでください。一度に変更するレイヤーを1つにし、起動、接続、ルーティングを確認してから次へ進めば、再発時に原因を特定できます。

クライアントを更新する前に、画面に表示される変更内容を読み、現在のOSとインストール系統に適合していることを確認します。更新後は古い設定のバックアップをすぐ削除せず、サブスクリプション一覧、アクティブノード、ルーティングルール、ローカルポート、システムプロキシ、TUNを検証してください。新しい画面が既定設定を再生成した場合は、ポートとアウトバウンドのラベルを重点的に確認します。手動プロキシアプリやカスタムルールが古い値を参照している可能性があるためです。

ノードだけでなく、何をバックアップするか

完全なバックアップには少なくとも、サブスクリプショングループ、手動ノード、カスタムルーティング、DNS設定、ポート設定、クライアント共通オプションを含めます。単一ノードの共有テキストには通常、システムプロキシモード、ウィンドウ設定、自動更新計画、すべてのルーティングルールは含まれません。クライアントが提供するバックアップまたはエクスポート機能を優先し、バックアップは管理された場所に保存してください。復元時は、設定ファイルが同時に書き込まれないよう、実行中のコアを先に停止します。

バックアップは「ファイルが存在するか」ではなく「復元できるか」で判断します。バックアップ後、メイン設定に影響しない環境で内容の構造を確認し、サブスクリプションとルーティングのファイルが実際に含まれていることを確認できます。プラットフォームをまたいで移行する場合、システムパス、権限、UI系統に関係するすべてのファイルをそのまま上書きしないでください。共通設定を導入した後、システムプロキシ、起動時実行、TUN権限を個別に再構築する方が安全です。

ログを読む順序

ログは最後の1行だけでなく、最初に現れた明確なエラーから読みます。コアの起動に失敗すると、その後にポート使用不可、接続拒否、状態停止などの派生情報が連続して出ることが多いためです。設定読み込み、待受ポート、DNS初期化、外向き接続の確立の中から、最初に失敗した地点を見つけ、それが構文、ポート、権限、ネットワークのどれかを判断します。サイト内記事ログから設定エラーを特定するでは、よくあるエラーの入口と対処方法を説明しています。

設定の構文エラーには、項目名や行・列の位置が含まれることがあります。ポート競合では待受アドレスが示され、権限問題は書き込みディレクトリ、インターフェース作成、システムネットワーク設定の変更時に発生しやすくなります。ノードのハンドシェイク失敗は、外向き接続の段階に現れることが多いです。ログにドメイン解決失敗が出た場合は、クライアント自身の解決、プロキシ側の解決、システムによる解決を区別します。エラーを1行だけ切り取らず、前後の初期化コンテキストも残してください。

症状からトラブル対処ツリーを作る

クライアントが起動しない場合は、実行環境、インストールパス、ディレクトリ権限、破損した設定を確認します。クライアントは起動するがコアに失敗する場合は、ポート競合、設定項目、コアのログを確認します。コアは起動するのにWebの記録がない場合は、システムプロキシ、アプリ設定、TUNによる取り込みを確認します。ログに要求があるのに出口が違う場合は、ルーティングの一致とDNSを確認します。要求がプロキシに入った後で接続に失敗する場合は、同じグループの別ノードと比較し、ノードパラメータと現在のネットワークを確認します。

1つのアプリだけが異常な場合、クライアント全体をリセットしないでください。まず、そのアプリがシステムプロキシに従うか、DNSをキャッシュするか、独立したネットワークコンポーネントを使うか、独自のプロキシが設定されているかを確認します。1つのノードだけが異常なら、すべてのサブスクリプションを削除しないでください。同じグループの別ノードに切り替えれば、単一ノードの問題かクライアントの問題かを区別できます。すべてのノードが同時に異常な場合に、サブスクリプションの変化、コアの状態、ローカルネットワーク、システム時刻を確認します。

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

クライアントを終了する前に、通常の手順でコアを停止し、システムネットワーク設定を復元させてください。プロセスを直接終了すると、システムプロキシのアドレス、仮想インターフェース、一時ルートが残ることがあります。終了後にネットワークへ接続できなくなった場合は、まずシステムプロキシがローカルポートを指したままになっていないか確認し、次にTUNインターフェースとDNSを確認します。状態を確認する前に複数のネットワークコンポーネントを同時にリセットしないでください。どの操作で復旧したのか分からなくなります。

端末がスリープから復帰した後や、有線と無線のネットワークを切り替えた後は、元のノード接続、DNSキャッシュ、LANアドレスが無効になることがあります。まずクライアントが自動再接続するかを観察し、新しい要求を送ってログを確認します。状態が古い接続のままなら、コアを停止して再起動してください。復帰失敗が続く場合は、ネットワーク切り替え前後のインターフェースとルートの差分を記録し、同時に有効にする自動ネットワーク機能を減らします。

適切な保守の基準には、復元可能な設定バックアップ、明確なサブスクリプションの提供元とグループ、分離して行うクライアントとコアの更新、すぐ開けるログの入口、システムプロキシとTUNの復元方法が含まれます。これらが整っていれば、多くの問題は現在のインストール環境で特定でき、再インストールを最初の選択肢にする必要はありません。

応用設定と長期的な学習ルート

動くだけでなく、動作を説明できる状態へ

応用段階の目標は、スイッチを増やすことではありません。アプリから外向き接続まで、1つの要求がたどる完全な経路を説明できることです。アプリはシステムプロキシ、手動プロキシ、TUNのいずれかでクライアントに入ります。インバウンドではドメインが保持されるか、宛先IPが得られます。DNSは設定した経路で解決され、ルーティングルールが直結、プロキシ、ブロックの出口を選び、コアがノードのプロトコルに従って外向き接続を確立します。ログには各段階の結果が記録されます。この経路が明確なら、複雑な問題も限られた手順に分解できます。

まず日常的に使うアプリを1つ観察対象にし、システムプロキシモードでインバウンド種別、ドメイン、一致ルール、アウトバウンドを記録します。その後TUNへ切り替え、経路の変化を比較します。実験中はノードを変えず、ネットワークの揺らぎをモードの違いと誤認しないようにしてください。大量のルールを一度に導入するより、完全な比較を1回行う方が確かな理解につながります。

インバウンド、アウトバウンド、ラベルを理解する

インバウンドは、ローカルHTTP、SOCKS、TUNなど、クライアントが通信を受け取る方法を定義します。アウトバウンドは、プロキシノード、直結、ブロックなど、通信が最終的に外へ出る方法を定義します。ラベルは、ルーティングルールからこれらの対象を参照するために使います。カスタム設定でよくあるミスは、ルール内のアウトバウンドラベルと実際の設定が一致しないこと、または複数のインバウンドが同じポートを待ち受けることです。生成された設定を読むときは、まずインバウンド一覧とアウトバウンド一覧を見つけ、その後にルーティングが両者をどう接続しているか確認します。

グラフィカルなクライアントは、一部のラベルとポートを自動管理します。完全な設定を手動編集した後に画面から保存すると、関連項目が再生成されることがあるため、「クライアントが管理する設定」と「ユーザー定義の断片」を分けて考えてください。画面で完了できる一般的な設定は、まず画面から行います。より細かい条件を表現する必要がある場合に限りカスタム設定を編集し、変更前のバージョンを保存してください。コアの起動に失敗した場合は、設定エラーをログから特定する方法を参照できます。

最小構成で実験する

新しいルールをテストするときは、検証済みのノード1つ、取り込み方式1つ、正確なルール1つ、明確な対象1つという最小条件から始めます。要求が想定どおり一致することを確認してから、ドメインサフィックス、ルールセット、プロセス条件へ段階的に広げます。最小構成でも動かない場合、DNSやルーティング項目を増やすほど確認範囲が広がるだけです。実験ごとに変更項目、期待する結果、実際のログ、戻し方を記録してください。

{
  "type": "field",
  "domain": [
    "full:api.example.test"
  ],
  "network": "tcp",
  "outboundTag": "proxy"
}

このルールは、指定したテストドメインのTCP通信だけに一致し、proxyという名前のアウトバウンドへ渡します。実際に使う前に、アウトバウンドラベルが存在すること、クライアントのコアが該当項目に対応していること、より広いルールより前に配置されていることを確認してください。検証に成功し、サブドメインも対象にする必要がある場合は、サフィックスルールへ明示的に変更します。最初から範囲の広い条件を使わないでください。

性能は再現可能な比較で判断する

接続体験は、ローカルネットワーク、ノードの経路、プロトコル設定、DNS、同時接続数、アプリの動作によって決まります。設定が性能を改善したか判断するには、ノードと対象を固定し、変更前後を分けてテストし、接続確立と継続通信を複数回観察します。1回だけのページ表示速度はキャッシュの影響を受けやすく、安定した結論には使えません。クライアント画面の瞬間的な状態も、その時点の条件を示すだけで、長期的な評価には適しません。

接続確立が遅い場合は、DNS待ち、TCP接続、TLSまたはプロトコルのハンドシェイクを分けて確認します。確立後の通信が不安定なら、パケットロス、ネットワーク切り替え、ノードの経路を観察します。ルールモードだけ遅い場合はDNSとルールセットを確認し、TUNだけ遅い場合は仮想インターフェース、MTU、二重の取り込みが起きていないかを確認します。症状ごとに該当レイヤーは異なるため、すべてをクライアントの問題と決めつけると原因を見失います。

複数端末の設定をそろえる方法

デスクトップとAndroidで同じサブスクリプションの提供元を使うことはできますが、クライアントのすべての設定が自動同期されるとは限りません。サブスクリプションが解決するのはノード配布であり、ルーティングルール、DNS、システムプロキシ、TUNは個別設定が必要な場合があります。複数端末を管理するときは、まずプライベートアドレスは直結、指定ドメインはプロキシ、それ以外は既定の出口というように共通方針を定め、各クライアントの機能に合わせて実装します。特定プラットフォームのパスやプロセス名に依存するルールを、別のプラットフォームへそのままコピーしないでください。

v2rayN、v2rayNG、v2flyNGでは、メニュー構成とコア体系が異なります。移行時は、まずプロトコル項目が完全か比較し、その後にルーティングとDNSを再構築します。デスクトップのLAN共有、ターミナル環境変数、起動時実行はAndroidの設定には含まれません。Androidのシステム接続許可やバックグラウンド電池設定も、デスクトップ設定で代用できません。設定ファイルを一字一句そろえるより、方針を一致させる方が現実的です。

おすすめの学習順序

第1段階では、サブスクリプション、アクティブノード、システムプロキシ、ログを習得します。第2段階では、グローバルとルールモードの比較方法を身につけます。第3段階では、正確なドメインルールを記述し、最初の一致を説明できるようにします。第4段階ではDNSとルーティングの関係を理解します。第5段階でTUNを有効にし、仮想インターフェースとシステムルートを分析します。最後に完全な設定構造、ラベル参照、複数端末の方針を学びます。各段階で、動作する基準設定を1つ保存してください。

新しい用語は用語集で確認し、初回接続の手順をやり直す場合はクイックスタートガイドに戻ってください。3つのクライアントの位置づけを比較する場合は、クライアント比較を参照します。システムの問題は対応するプラットフォームの記事を優先して読み、起動直後の終了、システムプロキシが効かない問題、コア設定エラーにはそれぞれ独立した対処手順があります。知識をレイヤーごとに整理すれば、障害のたびに断片的な情報を最初から検索せずに済みます。

ガイド完了後のスキルチェックリスト

全章を終えたら、プラットフォームに合うクライアントとインストールパッケージを選び、サブスクリプションを自分で導入・更新し、アクティブノードを明確に設定できるようになります。さらに、システムプロキシとTUNを区別し、ログで通信がクライアントに入ったか判断し、例外、プライベートアドレス、主要ルール、既定の出口を含むルーティング階層を設計し、更新前に設定をバックアップできます。より重要なのは、異常を実行環境、コア、ノード、取り込み、DNS、ルーティング、システムネットワークのいずれかのレイヤーに分類できることです。

次に接続異常が起きたら、まず現場を保全し、5つの質問に答えてください。クライアントは安定して動作しているか、コアは正常に待ち受けているか、アプリの通信は入っているか、ルーティングはどの出口を選んだか、外向き接続はどの段階で失敗したか。この5つの答えがあれば、次の対応をほぼ決められます。クライアントを再インストールする場合はダウンロードページで現在のプラットフォームを選択してください。インストール済みで操作に不慣れな場合は、クイックガイドに戻り、最小限の動作設定を作り直します。