V2Rayをゼロから理解する：インストール・サブスクリプション・ルーティング・TUN

まずコア、クライアント、ノード、サブスクリプションを区別する

コアが接続を担い、クライアントが操作画面を提供する

V2Rayは特定の1つのインストーラーではなく、プロトコル、トランスポート、ルーティング、接続管理の機能を含む技術体系です。実際の利用では、コアが設定を読み込んでネットワーク接続を確立し、GUIクライアントがサブスクリプションの取り込み、ノード切り替え、システムプロキシ、ログ確認などを操作画面にまとめます。v2rayN、v2rayNG、v2flyNGはいずれもGUIクライアントで、対応するコアを呼び出して接続します。トラブル対処では、「画面の設定が反映されない」のか「コアの接続に失敗している」のかを分けて考えます。前者はクライアントの状態とシステムプロキシを、後者はノード情報、ネットワーク、コアのログを確認します。

ノードは接続パラメータの集合であり、サブスクリプションとは異なる

ノードには少なくともサーバーアドレス、ポート、プロトコル、認証情報が含まれます。プロトコルによってはトランスポート方式、TLS、サーバー名、パス、サービス名なども指定します。ノードは、どこへどのように接続するかを決める情報です。サブスクリプションは、ノードやグループ情報を一括配布するためのリンクです。クライアントがサブスクリプションを更新すると、リンクの応答を解析してノード一覧を作成します。更新したからといって全ノードが利用できるとは限らず、回線品質のテストの代わりにもなりません。ノード一覧が空の場合は、すぐにプロキシモードを切り替えるのではなく、まずサブスクリプションの解析に成功したか確認します。

システムプロキシとトラフィック転送は別の設定

コアが動作していることは、ローカルのプロキシポートが待ち受けていることを意味するだけで、アプリの通信が必ずそこを通るわけではありません。ブラウザーなどシステムのネットワーク設定に従うアプリは、通常「システムプロキシ」を通じてクライアントに接続します。システムプロキシを読み取らないアプリは、個別にプロキシを設定するか、TUNモードでネットワーク層から取り込む必要があります。接続完了を判断するには、クライアントのコアが動作していること、システムまたはアプリがローカルプロキシポートへ通信を渡していること、選択中のノードが目的地へ到達できることの3点を続けて確認します。トレイアイコンや1つのページが開くかどうかだけでは、問題の層を正確に特定できません。

プロトコル、トランスポート、ルーティングの役割

VMess、VLESS、Trojanなどは接続プロトコル層の名称で、TCP、WebSocket、gRPCなどはデータを運ぶトランスポート方式です。ルーティングルールは、リクエストを直接接続するか、プロキシするか、遮断するかを決めます。3者は組み合わせて使えますが、互いの代わりにはなりません。たとえば、ノードがVLESSだからといって、特定サイトの接続方法が決まるわけではありません。直接接続するかどうかは、クライアントが生成するルーティング設定で決まります。逆に、ルールが正確でも、サーバーアドレスや認証情報の誤りは直せません。問題が起きたら、設定を「接続パラメータ」「トランスポートパラメータ」「通信の行き先」の3グループに分けて確認すると、全体を盲目的に変更するより効率的です。

ログは検証できる事実であり、付加情報ではない

クライアントのログには通常、設定の読み込み、ポートの待ち受け、DNSクエリ、接続確立、失敗原因が記録されます。タイムアウトが出た場合は、まずネットワークの到達性、ノードの状態、回線を確認します。名前解決に失敗した場合は、ドメイン名とDNSを確認します。設定項目のエラーが出た場合は、ノード詳細に戻ってプロトコル、トランスポート、セキュリティ設定を確認します。ログの時系列も重要です。先に設定エラーが出ていれば、その後の接続失敗は連鎖的な結果にすぎないことがあります。これらを理解してから、クライアント選びとインストールに進むと、後の各スイッチの意味も明確になります。

プラットフォームとコアの要件でクライアントを選ぶ

デスクトップではまずv2rayNを選ぶ

Windows、macOS、Linuxのデスクトップ環境では、まずv2rayNを使います。サブスクリプション管理、ノード一覧、システムプロキシ、ルーティングルール、TUNモードを一貫した操作で扱えるため、初期設定からカスタムルーティングまで対応できます。Windowsではデスクトップ版とクラシックWPF版から選べます。デスクトップ版はクロスプラットフォームのUIを採用し、異なるデスクトップOSで似た操作感を求めるユーザーに向いています。クラシックWPF版は従来のWindowsデスクトップアプリに近い操作感です。目的は同じなので、両方を同時にインストールする必要はありません。どちらか1つを常用環境に選びます。

Androidでは2つのコア方針から選ぶ

Androidではv2rayNGを第一候補とします。Xrayコアを使用し、幅広いプロトコルとトランスポートに対応したい場面に向いています。v2flyNGはv2flyコアを使用し、V2Fly系が必要な場合の選択肢になります。どちらもサブスクリプションの取り込み、ノード切り替え、ルーティング設定、ローカルVPNによる取り込みに対応しますが、設定項目やメニューの位置は異なる場合があります。接続できないからといって、2つのアプリを頻繁に乗り換えないでください。まずサブスクリプションが提供するプロトコルを現在のクライアントがサポートしているか確認し、ログを見てコアの方針を変える必要があるか判断します。

アーキテクチャとインストールパッケージの形式を一致させる

クライアント名を正しく選んだら、プロセッサのアーキテクチャとパッケージ形式も確認します。macOSでは「このMacについて」でチップの種類を確認し、Appleチップならarm64、Intelプロセッサならx64を選びます。Androidの近年の主流端末は通常arm64です。確認できない場合や特殊なアーキテクチャの場合はユニバーサル版を選べますが、パッケージの容量は大きくなりがちです。Linuxではx64とarm64だけでなく、パッケージ体系も区別します。Debian、Ubuntuなどはdeb、FedoraやRHEL系は通常rpmを使います。アーキテクチャが合わないと、インストーラーが起動しない、またはシステムに非対応と表示されることがあります。

機能の多さではなく実際の用途で選ぶ

クライアントを選ぶ前に、必要な操作を洗い出します。システムプロキシが必要か、システムプロキシを読まないアプリがあるか、ドメイン別ルーティングが必要か、LAN共有が必要かを確認します。通常のブラウザーや業務アプリなら、サブスクリプション、ノード切り替え、システムプロキシで十分です。より多くのアプリ通信を取り込む必要がある場合にTUNを検討し、通信先を細かく制御したい場合にカスタムルーティングへ進みます。機能が増えるほど設定層も増え、原因になり得る箇所も増えます。初回は最小限の構成を作り、機能を1つずつ追加して、その都度検証結果を残します。

クライアントを移行する前に設定の出所を残す

デバイスやクライアントを変更する前に、少なくともサブスクリプションの出所、現在のルーティングモード、カスタムルールを記録します。ノードがサブスクリプション由来なら、1つずつ手動でコピーする必要はありません。新しいクライアントでサブスクリプションを再び取り込み、その後ルーティングとプロキシモードを戻します。手動ノードは、プロトコル項目を完全に保存してください。サーバーとポートだけでは不十分です。認証情報を含む設定は管理された場所に保管し、公開ページへ貼り付けないでください。詳しくはクライアント比較で3種類のクライアントの適用範囲を整理しています。選択を決めてからインストールへ進みます。

インストールを完了し、元に戻せる初期設定を作る

インストール前に旧クライアントの取り込みを停止する

同じデバイスに複数のクライアントを残すことはできますが、システムプロキシやTUNを同時に取り込ませないでください。インストール前に旧クライアントを終了し、システムのネットワーク設定に残った手動プロキシアドレスがないか確認します。旧プログラムが異常終了すると、システムプロキシが停止済みのローカルポートを指したままになり、すべてのページに接続できなくなることがあります。その場合は、まずシステムの手動プロキシを無効にしてから新しいクライアントを起動します。目的は旧設定を削除することではなく、初回テストの通信入口を1つにして、新しいクライアントの問題か旧設定の残りかを判断しやすくすることです。

Windows：インストール形態と実行権限を確認する

Windowsでv2rayNを使う場合は、まずダウンロードセンターのWindowsセクションでデスクトップ版またはクラシックWPF版を選びます。インストール後はスタートメニューから起動し、初回実行時にメイン画面が開くこと、コアのディレクトリを読み取れること、ログにローカルポートの待ち受けが記録されることを確認します。通常のシステムプロキシ機能に管理者権限は常時必要ありません。システムネットワークドライバーやルーティングの変更が必要な機能を有効にした場合のみ、権限の昇格を求められることがあります。「常に管理者として実行」を万能な修復策にしないでください。ディレクトリ権限や設定パスの問題を隠してしまいます。

macOS：チップに合わせて選び、システム許可を確認する

macOSにv2rayNをインストールする際は、まずプロセッサの種類を確認し、対応するdmgを選びます。ディスクイメージを開いたら、アプリをシステムのアプリケーションフォルダへ移してください。読み取り専用イメージから長期間直接実行するのは避けます。初回起動時に出所の確認が表示されたら、システムのセキュリティ設定に従って許可します。システムプロキシとTUNでは必要な権限が異なります。システムプロキシは主に現在のネットワークサービスのプロキシ設定を変更し、TUNでは追加のネットワーク権限が必要になる場合があります。初期段階ではシステムプロキシだけを設定し、TUNは同時に有効にしません。まずサブスクリプションとノード接続が正常か確認します。

Linux：ディストリビューションに合わせ、デスクトップセッションを確認する

Linuxではディストリビューションに合わせてdebまたはrpmを選び、プロセッサのアーキテクチャも確認します。インストール後はデスクトップのアプリ一覧から起動します。画面が表示されない場合は、端末からアプリのコマンドを直接実行して起動エラーを確認します。デスクトップ環境によってシステムプロキシの読み取り方は完全には同じではありません。デスクトップのプロキシ設定に従うアプリもあれば、独自のネットワーク設定を使うアプリもあります。そのためLinuxでは「クライアントが動作中」と「すべてのアプリが取り込まれている」を同一視できません。初回確認では、システムプロキシに従うことが明確なブラウザーを選び、その後に個別設定が必要なアプリを扱います。

sudo apt install ./v2rayN-linux-x64.deb

# rpm系ディストリビューションでは対応するインストールパッケージを使用
sudo rpm -Uvh v2rayN-linux-x64.rpm

Android：動作中のローカルVPNは1つだけにする

Androidにv2rayNGまたはv2flyNGをインストールすると、初回接続時にローカルVPNの作成を求められます。これはシステムがアプリの通信をクライアントへ渡すために必要な手順です。同時にこの状態を保持できるアプリは1つだけなので、新しいクライアントを試す前に他のネットワークツールを切断します。サブスクリプションを取り込んだら、まずノードを1つ選び、ルーティングは初期設定のまま接続します。ステータスバーの接続アイコンはシステムの許可が成立したことを示すだけです。ログと実際のアクセスでノード接続を確認してください。

初回起動後に確認する5項目

1つ目は、クライアントのウィンドウとトレイメニューを正常に開けること。2つ目は、コア起動後に設定エラーがないこと。3つ目は、ローカルHTTP、SOCKS、混合プロキシのポートを記録し、他のプログラムと競合していないこと。4つ目は、スタートアップ起動が利用習慣に合っていることを確認し、不要なら無効にしておくこと。5つ目は、クライアント終了時にシステムプロキシが自動復元されるか確認することです。この5項目を終えてからサブスクリプションを取り込みます。インストール段階ですでにエラーが出ている場合は、そのまま設定を続けないでください。後のログに複数の問題が混ざり、トラブル対処の負担が大きくなります。

サブスクリプションを取り込み、ノードを更新し、解析結果を確認する

サブスクリプション名には判別できる出所を付ける

クライアントのサブスクリプション管理で新規登録するときは、「日常用回線」「テスト用回線」のように用途や出所が分かる名前を付けます。「サブスクリプション1」「新しいグループ」のような名前だけでは管理しにくくなります。名前は接続に影響しませんが、更新やトラブル対処の効率に直結します。リンクは完全にコピーし、前後に空白を入れないでください。Webページに表示されたテキストをサブスクリプションURLと取り違えないようにします。保存後に手動更新を1回実行し、通知とログを確認します。ノード一覧が実際に増えるか更新されて初めて、取り込み完了と判断できます。サブスクリプション情報を保存しただけでは、解析に成功したことになりません。

更新失敗は返却された段階で分類する

サブスクリプションの更新は、おおむね取得、デコード、解析、書き込みの4段階に分かれます。取得失敗はタイムアウト、ネットワークエラー、サーバーの異常応答として現れることが多く、まず現在のネットワークからURLへアクセスできるか確認します。デコード失敗は、返却内容がクライアントの想定形式ではないことを示します。リンクのコピー漏れ、サブスクリプションの期限切れ、サーバーが案内ページを返している可能性があります。解析失敗は、ノード項目の形式、文字コード、クライアントの対応範囲に関係します。書き込み失敗では、設定ディレクトリの権限、ディスク容量、既存設定の状態を確認します。段階を分けて調べると、更新ボタンを繰り返し押すより原因を見つけやすくなります。

更新前後のノードの変化を分けて確認する

サブスクリプションの更新によって、ノードが追加、削除、変更されることがあります。使用中のノードが削除されると、クライアントが別のノードへ切り替える場合もあれば、サブスクリプションとの関連を失った古い記録が残る場合もあります。更新後は、選択中のノードがまだ存在するか、カスタムグループが想定どおり維持されているか確認します。「古いノードを削除」や「サブスクリプションで上書き」のような項目がある場合、手動で追加したノードに影響しないか確認してから有効にします。手動ノードとサブスクリプションのノードは別グループで管理すると、更新時に出所を判断しやすくなります。

レイテンシテストで分かることは限られる

ノードのレイテンシテストは通常、対象アドレスが一定時間内に応答できるかを確認するもので、実際のダウンロード速度やすべてのサイトの品質を示すものではありません。特定の探測方式には応答しなくても実際のプロキシは動作するノードがあります。逆に、レイテンシが低くても回線混雑でスループットが落ちることがあります。まずクライアントのテストで明らかに到達できないノードを除外し、その後、同じWebページやファイルへアクセスして比較します。ローカルネットワークの条件は揃えてください。結果の変動が大きい場合は時間帯を変えて再試行し、すぐにプロトコル項目を変更しないでください。

サブスクリプションの更新頻度は変更の必要性に合わせる

クライアントを開くたびにサブスクリプションを連続更新する必要はありません。ノードの出所が明確で一覧が安定しているなら、ノードが使えないとき、設定変更の通知を受けたとき、メンテナンス期間に入ったときに手動更新します。自動更新の間隔を短くしすぎないでください。頻繁なリクエストでノード品質が上がるわけではなく、ログに同じ記録が増えるだけです。更新後に全体が利用できなくなった場合は、まずログを保存し、すべてのノードが置き換わったか確認します。そのうえでサブスクリプション解析失敗のチェックリストに沿って、リンク、返却内容、更新経路を確認します。

手動ノードは項目を完全に確認する

手動でノードを追加するときは、サーバーとポートだけを確認しないでください。プロトコル種別、ユーザー識別子、暗号化またはフロー制御、セキュリティ層、トランスポート方式、サーバー名、パス、サービス名を、提供元の設定と一致させます。空欄にも意味があります。空欄にすべき項目へ経験で初期値を入れないでください。ノードを変更する前に、戻せるよう記録をコピーしておき、変更は一度に1グループの項目だけにします。接続に成功してからノード名を付け、用途を表す名前にします。認証情報などの機密情報は名前に入れません。これでサブスクリプションとノードの準備が整い、次にどのアプリの通信をローカルプロキシへ送るかを決めます。

システムプロキシ、グローバルモード、アプリごとの差異を理解する

システムプロキシは多くのデスクトップアプリにとって最初の入口

v2rayNはコアを起動すると、ローカルでプロキシポートを待ち受けます。システムプロキシを有効にすると、OSのプロキシアドレスがそのポートを指すようになります。ブラウザー、オフィスソフト、一部のシステムコンポーネントはこの設定を読み取り、リクエストをクライアントへ渡します。システムプロキシを無効にしてもコアは動作できますが、システム設定に従うアプリは自動的にプロキシへ入りません。「クライアントは接続済みなのにブラウザーが変わらない」場合は、クライアントのトレイ状態とシステムのネットワーク設定を同時に確認し、プロキシアドレスがローカルを指し、ポートがクライアントの現在の設定と一致していることを確認します。

グローバルは接続強度ではなく通信選択の方針

グローバルモードは通常、クライアントに入った通信を現在のプロキシ出口へ優先的に送る設定です。LANや中国本土を迂回するルールモードでは、ドメイン名とIPの情報に基づいて直接接続またはプロキシを選びます。カスタムモードはユーザー定義のルールで照合します。グローバルモードでノードが速くなるわけでも、サブスクリプション項目の誤りが直るわけでもありません。分流判断を減らせるため、比較テストには適しています。ルールモードでは失敗しグローバルでは成功する場合、ノードは基本的に利用可能で、問題はルーティングまたはDNSにある可能性が高いです。両方で失敗するなら、ノードとネットワーク層へ戻って確認します。

アプリによってプロキシ設定の読み取り方は異なる

ブラウザーは通常システムプロキシに従いますが、アプリ内に独自のプロキシ設定を持つものもあります。コマンドラインツールの中には環境変数だけを読み取るものがあり、システムプロキシを無視して直接接続するプログラムもあります。そのため、1つのアプリの結果からデバイス全体を判断できません。テストでは、まずシステムプロキシに従うことが分かっているブラウザーを基準にし、その後ほかのアプリを1つずつ確認します。必要ならコマンドラインプログラムに一時的なプロキシ環境変数を設定します。ポートは例をそのまま使わず、クライアント画面に表示された実際の値へ置き換えてください。

# 現在のターミナルセッションでHTTPプロキシを使用
export HTTP_PROXY=http://127.0.0.1:10809
export HTTPS_PROXY=http://127.0.0.1:10809

# SOCKS5を使用し、ドメイン名をプロキシ側で解決
curl --proxy socks5h://127.0.0.1:10808 https://example.com/

ローカルポートの競合は待ち受け状態から確認する

コアの起動時にアドレスが使用中と表示される場合、別のプロセスが同じポートを待ち受けています。まず他のプロキシクライアントを終了してから再起動します。それでも競合する場合は、クライアント設定でローカルポートを変更し、そのポートを手動入力しているすべてのアプリも更新します。システムプロキシのポートだけを変更し、コアの待ち受けポートを変更しないのは避けてください。両者は一致させる必要があります。ポート番号自体が速度を決めるわけではないため、理由なく何度も変更しても意味はありません。LAN共有には待ち受けアドレスとファイアウォールも関係するため、本機のシステムプロキシとは分けて設定します。

クライアント終了時はシステム状態を戻す

クライアントを正常終了する前に、システムプロキシを無効にするか、終了時に復元する設定になっていることを確認します。プログラムを強制終了すると、プロキシ設定が残り、システムプロキシに従うアプリが停止済みのローカルポートへ接続し続けることがあります。典型的には、ネットワーク自体は正常なのに、ブラウザーがすぐにプロキシ接続エラーを表示します。システムのネットワーク設定で手動プロキシを無効にし、クライアントを再起動して確認します。この手順を日常のトラブル対処リストに加えると、「終了後にインターネットへ接続できない」問題をすばやく切り分けられます。

モバイルの接続状態はアプリのログと合わせて判断する

Androidクライアントは、システムが提供するローカルVPNインターフェースを通じて通信を取り込みます。接続をタップしたら、まずシステムの許可が成功したことを確認し、次にクライアントのログでノード接続が完了したか確認します。アプリによっては独自のDNS、ネットワーク高速化、プライベート接続設定を持ち、テスト結果に影響します。初回設定ではルーティングとDNSを初期値のままにし、ノードを1つだけ選んで検証します。基本接続が安定してから、必要に応じてアプリ別ポリシーやカスタムルーティングを追加してください。最初からノード、DNS、アプリルールを同時に変更しないことが重要です。

ドメイン名、IP、ルールの順序で通信先を制御する

ルーティングルールが扱うのは、すでにクライアントへ入った通信

ルーティングはアプリを自動的に取り込む機能ではありません。システムプロキシ、アプリのプロキシ、TUNを通じてコアへ入ったリクエストだけを処理します。各ルールには通常、照合条件と出口の動作が含まれます。条件はドメイン名、IP、ポート、プロトコル、送信元などで、動作は通常プロキシ、直接接続、遮断です。アプリが完全にクライアントを経由していなければ、どれほど正確なルールでも反映されません。分流を設定する前に、ログで対象リクエストが現れていることを確認し、その後どのルールと出口に一致したかを確認します。

ドメイン名ルールはサービスの範囲を表すのに適している

完全一致は指定したホスト名だけに適用され、サフィックスルールはドメインとそのサブドメインをまとめて対象にできます。domain:example.comを使う場合は、現在のクライアントまたはコアでの定義を確認してください。full:api.example.comなら単一ホストまで厳密に指定できます。geosite:系のルールは管理されたドメイン集合を参照し、サービスの一群を対象にするのに適しています。ルールの範囲が広いほど、誤照合の範囲も広がります。1つのサブドメインの問題を直すために、トップレベルドメイン全体とすべてのサブドメインを同じ出口へ送らないでください。

IPルールは名前解決の結果と宛先アドレスに依存する

IPルールでは、単一アドレスまたはCIDRネットワークを照合できます。たとえば192.168.0.0/16はプライベートネットワークの範囲を表します。LANアドレスは通常直接接続にし、プリンター、ルーターの管理画面、ファイル共有を遠隔の出口へ送らないようにします。ドメインリクエストがIPルールの対象になるかどうかは、コアが名前解決後の宛先IPを取得するか、現在のドメイン処理方針がどう設定されているかにも左右されます。IPルールだけを書いてDNSの流れを確認しないと、正しそうなルールが一度も一致しないことがあります。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "full:intranet.example.com",
          "domain:office.example.com"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "geosite:category-ads-all"
        ],
        "outboundTag": "block"
      }
    ]
  }
}

ルールの順序で競合時の優先順位が決まる

多くのルーティング実装は上から順に検索し、最初に一致した時点で比較を終えます。そのため、具体的なルールを広いルールより前に置きます。たとえば、ある業務用サブドメインを直接接続し、親ドメイン全体をプロキシする場合は、先に業務用サブドメインの直接接続、次に親ドメインのプロキシを記述します。逆の順序では、広いルールが先にリクエストを捕捉します。ルール変更後は保存できたかだけでなく、コアを再起動または再読み込みし、新しいルールが読み込まれたことをログで確認します。構文と照合優先順位についてはdomain、ip、geositeルールの書き方も参照してください。

DNSとルーティングは同じ目的に揃える

分流ではドメイン名の判定とIPの判定を同時に扱うことが多いため、DNSの結果が後続のルーティングに影響します。ドメイン名が想定と異なるアドレス範囲へ解決されると、IPルールが誤った出口へ送る可能性があります。トラブル対処では、ドメイン名、解決結果、一致したルール、最終出口の4点を記録し、DNSサーバーだけを置き換えないでください。複数のDNSグループに対応するクライアントでは、直接接続用とプロキシ用に異なる問い合わせ経路を設定できますが、各問い合わせがどの出口から送信されるかを先に理解します。基本設定が安定していない段階では、複数のルールを重ねるより初期DNSのままの方が検証しやすいことが多いです。

最小限のテストセットで分流を検証する

固定した3つのテスト対象を用意します。1つはLANアドレス、1つは直接接続を明示的に求めるドメイン、もう1つはプロキシを明示的に求めるドメインです。ルールを変更するたびにこの順でテストし、どの出口に一致したかを記録します。LANが失敗したらプライベートアドレスのルールを、ドメインの出口が想定と違えばルールの順序とドメイン形式を確認します。ログにリクエストがない場合は、通信の入口の層へ戻ります。ランダムなWebページだけをテスト対象にしないでください。ページは複数のドメインを同時に読み込むことがあり、メインページが開いてもすべてのリソースが同じ出口を通ったとは限りません。ルールモードを検証してから、TUNで取り込み範囲を広げる必要があるか判断します。

基本プロキシが安定してからTUNモードを有効にする

TUNはシステムプロキシを読まないアプリの通信に対応する

TUNモードは仮想ネットワークインターフェースでより多くのシステム通信を受け取り、コアにルーティングと転送を実行させます。システムプロキシに従わないデスクトップアプリ、通信を統一して取り込みたいコマンドラインツール、アプリごとのプロキシ設定を減らしたい場面に適しています。TUNはノードを高速化するスイッチではなく、プロトコル性能を高めるものでもありません。基本のノード接続が不安定なままTUNを有効にすると、仮想NIC、DNS、ルーティングテーブルという3つの変数が増えるだけです。そのため、まず通常のシステムプロキシでサブスクリプション、ノード、ルールモードが正常に動くことを確認します。

有効化する前に現在のネットワーク基準を記録する

開始前に、現在のネットワークアダプター、DNSの取得方法、クライアントのローカルポート、システムプロキシの状態を記録し、仮想NICを作成する可能性のある他のプログラムを終了します。その後v2rayNでTUNを有効にし、システムの指示に従って必要な権限を許可し、コアの再読み込みを待ちます。起動後は、ログに仮想インターフェースの作成、ルートの追加、DNS初期化が記録されているか確認します。スイッチがオンになっていても、ログにインターフェース作成失敗と出ている場合は、ノード項目を変更せず、まず権限またはドライバーの問題を解決します。

厳格ルーティングと自動ルーティングの範囲を理解する

自動ルーティングは、取り込みに適したシステム通信をTUNへ送ります。厳格ルーティングは、仮想インターフェースを迂回する経路をさらに制限します。具体的なスイッチ名はクライアントの画面によって異なる場合がありますが、原則は同じです。まず必要最小限の項目だけを有効にし、ブラウザー、コマンドライン、対象アプリを確認します。漏れた通信がある場合に限って制限を追加します。企業ネットワーク、仮想マシン、コンテナ、多数のNICがある環境では、自動生成されたルートが既存のネットワークと重複することがあります。その場合は、すぐにグローバルプロキシへ切り替えず、まずルーティングテーブルを確認します。

DNSの異常はTUNのトラブル対処で最初に確認する

TUNを有効にした後、IPアドレスにはアクセスできるのにドメイン名へアクセスできない場合は、まずDNSを確認します。クライアントのDNSモジュールが起動しているか、問い合わせが想定した入口に入っているかを確認し、ローカルのセキュリティソフトによる遮断も調べます。一部のドメインだけ失敗するなら、解決結果と一致したルールを記録します。すべてのドメインが失敗するなら、DNSの待ち受けポート、システムDNSの向き先、ポート競合を確認します。複数のDNS取り込み機能を同時に有効にしないでください。問い合わせがシステム、クライアント、他のネットワークプログラムの間を循環することがあります。

LANと複数NICの環境では直接接続経路を残す

TUNを有効にした後も、プリンター、ネットワークストレージ、ルーターの管理画面などのプライベートアドレスはローカルNICから直接接続する必要があります。ルーティングにプライベートアドレス範囲が含まれているか確認し、現在のLANが一般的でないカスタムネットワークを使っていないか調べます。有線、無線、仮想NICを同時に接続している場合は、デフォルトルートが実際にどのNICから送信されるかも確認します。ネットワークを切り替えて異常が出た場合は、まずTUNを無効にし、仮想インターフェースとルートが削除されるのを待ってから、ネットワークへ再接続しクライアントを起動します。

長期間有効にする必要があるか判断する

日常的に使うアプリがすべてシステムプロキシを安定して読み取れるなら、設定を複雑にするためだけにTUNを常時有効にする必要はありません。プロキシに従わない特定のアプリまで取り込みたい場合に、TUNの価値が生まれます。安定動作の基準は、再起動後に自動復元できること、ネットワーク切り替え後にルートを再構築できること、LANへアクセスできること、DNSエラーが継続しないこと、クライアント終了後にシステムネットワークが元へ戻ることです。これらを満たしてからTUNをスタートアップに加えます。それまでは、より単純なシステムプロキシを日常の構成として残します。

更新、バックアップ、速度テスト、層別トラブル対処の流れを整える

メンテナンスを定期作業とイベント対応に分ける

定期メンテナンスでは、クライアントの更新、サブスクリプションの状態、カスタムルール、古い設定を確認します。イベント対応は、ノード全体が使えなくなったとき、ネットワーク環境が変わったとき、システムをアップグレードした後に実施します。毎日設定を消去したり、クライアントを再インストールしたりする必要はありません。通常は、まずサブスクリプションを更新してノードの変化を確認し、その後、再現可能な接続テストを少数実行します。クライアントをアップグレードする前に現在の設定を記録し、アップグレード後はコアの起動、システムプロキシ、よく使うノードを確認してからTUNや複雑なルーティングを戻します。

バックアップでは再生成できない内容を優先する

サブスクリプションのノードは通常再取得できます。本当にバックアップすべきなのは、手動ノード、カスタムルーティング、DNS設定、グループ構成、LAN共有のパラメータです。バックアップファイルは管理されたディレクトリに保存してください。接続情報が含まれる可能性があります。復元時は新しい設定をすべて直接上書きせず、まずクライアントの設定構造に互換性があるか確認してから、種類ごとに取り込みます。デバイスを変えるだけなら、クライアントを再インストールしてサブスクリプションを取り込み、ルールを手動で戻すのが優先です。旧システムのパス、ポート競合、ネットワークインターフェース情報まで持ち込まずに済みます。

速度の問題はノード、回線、ローカルの3層で確認する

第1層では、同じサブスクリプション内の少数のノードを切り替え、問題が特定のノードだけか判断します。第2層では、同じノードを異なる時間帯にテストし、回線混雑に時間帯の傾向があるか確認します。第3層では、ローカルネットワーク、プロキシモード、DNS、TUN、セキュリティソフトを確認します。テスト中は対象サイト、ファイル、デバイスを揃え、ノードを変えるのと同時にWi-Fiを切り替えないでください。すべてのノードが遅い場合は、まずローカルネットワークとサブスクリプション全体の状態を確認します。1つのノードだけ遅いなら、クライアントを再インストールする必要はありません。詳しい手順はV2Rayの速度低下を層別に確認する方法を参照してください。

ログ収集は問題が発生した時刻を含める

トラブル対処用のログには、少なくともコアの起動、問題の再現、テストの停止という3段階を含めます。最後のエラー1行だけでは、その前に発生した設定読み込みの失敗を見落としがちです。再現前に古いログを整理するか現在時刻を記録し、サブスクリプションを1回更新する、ノードを1つ接続する、固定ドメインへアクセスするなど、単一の操作を実行します。ログを共有する前に、サーバーアドレス、ユーザー識別子、サブスクリプション内容などの機密情報を削除してください。ただし、エラーの種類、時系列、コンポーネント名は残します。これで問題を説明しながら、接続パラメータを漏らさずに済みます。

よくある現象と最初の確認ポイント

クライアントが開かない場合は、まずパッケージのアーキテクチャ、実行環境、設定ディレクトリを確認します。サブスクリプションの更新に失敗する場合は、まずリンクの取得と解析ログを確認します。ノードがすべてタイムアウトする場合は、まずローカルネットワークとサブスクリプションの状態を確認します。ブラウザーにプロキシ接続エラーが表示される場合は、まずコアの待ち受けとシステムプロキシのポートを確認します。特定のドメインだけ異常な場合は、まずDNSの結果とルーティングの一致を確認します。TUNを有効にして全体がオフラインになった場合は、まずTUNを無効にし、仮想インターフェースとデフォルトルートを確認します。現象別の回答はトラブル対処で探せます。

LAN共有では境界を個別に管理する

LAN接続を許可すると、ローカルプロキシポートは現在のデバイス以外にもサービスを提供します。待ち受けアドレス、システムファイアウォール、ルーターのネットワーク分離、接続先デバイスのプロキシアドレスを確認し、信頼できるLAN内だけで使用してください。PCのIPアドレスが変わったら、スマートフォンやテレビに設定したプロキシアドレスも更新します。共有に失敗した場合は、まず別のデバイスからPCのLANアドレスへ到達できるか確認し、次にポートの許可、最後にクライアントが外部接続を許可しているかを確認します。詳しい手順はv2rayNのLAN共有手順を参照してください。

メンテナンスの目標は既知の動作基準を残すこと

大きな変更を行う前に、正常に動作するノード、デフォルトルート、システムプロキシの組み合わせを1つ残します。変更後、短時間で原因を特定できない場合は基準へ戻し、項目を1つずつやり直します。サブスクリプション、DNS、ルーティング、TUN、ローカルポートを一度にすべて置き換えないでください。接続が戻っても、どの変更が効いたのか分からなくなります。再現可能なメンテナンス手順は、頻繁な再インストールより信頼性が高く、明確な状態を基礎に応用設定へ進めます。

安定した基準からカスタムルールと複数デバイス管理へ進む

応用設定の出発点は現在の設定を説明できること

基本利用を終えても、すぐに大規模なルールセットを取り込む必要はありません。まず5つの質問に答えられることを確認します。現在のノードはどのプロトコルとトランスポート方式を使っているか、アプリの通信はどのようにクライアントへ入るか、DNSクエリはどの経路を通るか、対象リクエストはどのルールに一致するか、最終的にどの出口を使うか、です。1つでも分からない状態でルールを増やすと、不確実性が広がります。応用設定の目的は設定項目を増やすことではなく、異なる通信を明確で検証可能な条件に基づいて、想定した出口へ送ることです。

まず命名とグループの規則を整える

サブスクリプション名、ノードの備考、アウトバウンドのタグ、ルール名は意味を揃えます。たとえばノードグループを「出所—地域—用途」で命名し、出口の用途をproxy、direct、blockで表します。カスタムルールには対象と動作を明記します。命名規則はログの読みやすさを直接改善し、移行時の判断コストも減らします。名前に完全な認証情報やサブスクリプションURLを含めないでください。複数デバイスでルールを共有する場合は、デバイス固有のパスとローカルポートを含まない共通版を1つ保管し、各デバイスでローカル差分だけを補います。

カスタムルールにはテスト、公開、ロールバックの手順を設ける

ルールを追加する前に、「業務用サブドメインは直接接続し、それ以外の同一ドメインのサービスはデフォルト方針で処理する」のように期待する結果を書き出します。次に最小限のルールを追加し、ログで一致を確認してからドメインやネットワークの範囲を広げます。日常設定へ反映する前に、LAN、直接接続の対象、プロキシ対象、DNSを少なくともテストします。順序を変更する場合は、以前の順序のコピーを残します。異常が出たら、直近の変更へ戻し、パッチを重ね続けないでください。長期運用では、無効になった項目や、より広いルールに覆われた項目を削除します。

{
  "rules": [
    {
      "name": "private-network-direct",
      "match": [
        "geoip:private"
      ],
      "action": "direct"
    },
    {
      "name": "office-domain-direct",
      "match": [
        "full:portal.example.com",
        "domain:corp.example.com"
      ],
      "action": "direct"
    }
  ]
}

上の断片はルール設計の方法を示すもので、クライアント設定をそのまま置き換えられる完全なファイルではありません。実際の項目は、使用中のコアのルーティング構造とクライアントのエクスポート形式に合わせてください。取り込む前に、タグ名が既存のアウトバウンドと一致しているか確認します。一致していないと、ルールが照合されても対応する出口を見つけられません。

複数デバイスの管理では共通設定とデバイス差分を分ける

Windows、macOS、Linux、Androidは同じサブスクリプションの出所を使えますが、システムプロキシ、TUNの権限、インストールパッケージのアーキテクチャ、LANインターフェースはデバイスごとに異なります。無理にコピーしないでください。共有するのはサブスクリプショングループ、コアのルーティング方針、テスト対象です。デバイス固有なのは、ローカルポート、スタートアップ起動、システム権限、アプリの取り込み方法です。移行時はまず共通部分を戻し、その後デバイスごとに設定します。これにより論理的な一貫性を保ちながら、あるプラットフォームのネットワークインターフェース設定を別のプラットフォームへ持ち込まずに済みます。

高度なDNS設定は観測できる結果を中心に設計する

初期DNSが明確に名前解決の失敗、出口の不一致、特定ドメインの汚染を引き起こしている場合に限り、問い合わせ経路を分けます。設計前に、対象ドメインをどのDNSグループが解決するか、問い合わせがどの出口を通るか、その結果がどのルーティングに使われるかを記録します。キャッシュ、予備問い合わせ、ドメイン別ルーティングを追加したら、初回問い合わせとキャッシュヒットの結果を分けて確認します。設定後に断続的な失敗が出た場合は、まず単一経路へ簡略化し、その後項目を1つずつ戻します。DNS設定でドメインルーティングや到達不能なノードを修復することはできません。

学習ルートを3つのサイクルに固定する

1つ目は接続です。プロトコル項目を理解し、単一ノードの安定性を確認します。2つ目は取り込みです。システムプロキシ、アプリのプロキシ、TUNの境界を把握します。3つ目は分流です。ドメイン名、IP、DNS、ルールの順序を理解します。各サイクルは「基準を作る—1項目追加—結果を確認—戻し方を記録」の順で実行します。新しい問題が起きたら、まずどのサイクルに属するか判断し、該当する章へ戻ります。最初から再インストールする必要はありません。すぐに操作したい場合ははじめにへ、クライアントとプラットフォームの要件はダウンロードセンターへ、具体的な異常はトラブル対処で現象別に確認できます。

最終設定は再現できるほどシンプルにする

成熟した設定は、ルールが最も多いものではありません。別のデバイスでも記録を見ながら再構築できるものです。サブスクリプションの出所、クライアントを選んだ理由、プロキシの入口、ルーティングの目的、TUNを使う条件、メンテナンス周期の6項目を文書化します。用途を説明できないスイッチやルールは削除し、サブスクリプションとカスタム設定がまだ一致しているか定期的に確認します。これで、基本概念から応用管理までの流れが完成します。まず接続を成立させ、次に通信を取り込み、その後に行き先を制御し、最後にログ、バックアップ、基準によって長期的に保守できる設定にします。