V2Rayゼロから応用設定までのガイド

基本概念：クライアント、コア、プロトコル、ルーティング

まずGUIクライアントとプロキシコアを区別する

v2rayN、v2rayNG、v2flyNGは、まずGUIクライアントです。サブスクリプションの保存、ノードの表示、設定の生成、コアの起動、システムプロキシや仮想ネットワークインターフェースの切り替えを担当します。プロトコルのハンドシェイク、暗号化通信、DNSクエリ、ルールのマッチングを実際に実行するのは、クライアントが呼び出すコアです。v2rayNはデスクトップ環境でXrayまたはV2Fly関連のコアを利用でき、v2rayNGは主にXrayコアを採用し、v2flyNGはV2Flyコア向けの設定を扱います。「クライアントは起動しているのにウェブページを開けない」場合、ウィンドウの有無だけで判断せず、コアが起動しているか、待受ポートが作成されているか、システムの通信がそのポートに入っているかまで確認してください。

クライアント設定とノード設定も同じ階層ではありません。ノード設定には、リモートアドレス、ポート、ユーザー識別子、プロトコル、トランスポート方式、安全性に関するパラメータが含まれます。一方、クライアント設定にはローカル待受、システムプロキシ、DNS、ルーティング、ログも含まれます。サブスクリプションは通常、ノードとグループ情報を提供するだけで、ローカルネットワークのポリシーをすべて決めるわけではありません。取り込み後もプロキシモードを選択し、必要に応じてLANのバイパス、中国本土のドメインへの直接接続、リモートDNS、TUNを設定します。この2つの階層を分けて考えると、同じサブスクリプションが異なる端末で接続できても、ルーティング結果が完全には一致しない理由を説明できます。

プロトコル、トランスポート、安全性パラメータは組み合わせて一致させる

VMess、VLESS、Trojanはノードのプロトコル層、TCP、WebSocket、gRPCなどはトランスポート層、TLSとREALITYは接続の安全性および本人確認に関わる設定です。クライアントが接続を確立する際、これらのパラメータはサーバー側と一つずつ一致していなければなりません。VLESSの設定では、アドレスとポートが正しくても接続に成功するとは限りません。ユーザー識別子、フロー制御、トランスポート種別、サービス名、サーバー名、公開鍵、短いIDのいずれかが一致しないだけで、ハンドシェイク失敗、接続直後の切断、テスト遅延のタイムアウトとして現れることがあります。

REALITYノードでよく使われる項目には、サーバー名、フィンガープリント、公開鍵、短いID、フロー制御があります。サーバー名は単なるメモではなく、ハンドシェイクに使用されます。公開鍵はノード提供元から取得したものを使い、短いIDも提供された内容どおりに入力してください。Visionのフロー制御を使う場合は、プロトコル、トランスポート、安全性の組み合わせも一致させます。標準の共有リンクやサブスクリプションを取り込めば、通常はクライアントがこれらの項目を自動解析します。手入力は項目の出所を確認する場合に限り、別のノードのパラメータを現在のノードに組み合わせないでください。

インバウンド、アウトバウンド、ルーティングが通信経路を構成する

インバウンドは、クライアントがローカルで通信を受け取る場所を指します。たとえばローカルのSOCKSポート、HTTPポート、TUN仮想インターフェースなどです。アウトバウンドは、通信がクライアントを出た後の処理方式で、一般的なタグはプロキシ、直接接続、ブロックです。ルーティングルールは、各リクエストをどのアウトバウンドに渡すかを決めます。ブラウザがシステムプロキシを使う場合、リクエストはまずローカルのHTTPまたはSOCKSインバウンドに入り、ルーティングによって直接接続かプロキシかが判断されます。TUNを有効にすると、より多くのアプリの通信が仮想インターフェースからコアに入りますが、その後のルーティングとアウトバウンドの処理は変わりません。

ルーティングは通常、ドメイン、IP、ポート、ネットワーク種別、プロセス情報などでマッチングします。ルールには順序があり、先に一致したルールが実行されるため、「内容が正しい」だけでは不十分で、適切な位置にあることも確認が必要です。LANアドレスと予約済みアドレスは通常、先に直接接続へ回します。明示的にブロックする対象は直接接続ルールより前に置き、地域ドメインとIPルールはフォールバックのプロキシより前に配置します。最後に予測可能なデフォルトアウトバウンドを残し、未一致の通信が不明確な状態に入らないようにしてください。

観測できる結果から現在の階層を判断する

接続テストが成功しても、特定のテスト条件でクライアントが対象へ到達できたことしか示しません。すべてのアプリが使えるとは限りません。ブラウザは使えるのにコマンドラインが使えない場合は、まずプログラムがシステムプロキシを読み取っているか確認します。ドメインは開けないのに既知のIPへは応答がある場合、DNSを優先して確認してください。LAN機器に突然アクセスできなくなった場合は、ルーティングとTUNのバイパス設定を確認します。すべてのノードが同時に失敗した場合は、ローカルネットワーク、システム時刻、コアの起動、サブスクリプションのパラメータを先に確認し、ノードを一つずつ削除しないでください。

ログは、どの階層で問題が起きているかを確認する主要な手がかりです。起動ログでは、設定が受理されたか、ポートが使用中でないか、仮想インターフェースが作成されたかを確認します。接続ログでは、ドメイン、対象アドレス、マッチしたルール、アウトバウンドタグを確認します。エラーログは、名前解決失敗、ハンドシェイク失敗、タイムアウト、権限問題の特定に役立ちます。通常はログレベルをwarningにし、調査時だけ一時的にinfoへ切り替えてください。調査後は元に戻し、大量のファイルが長期間蓄積しないようにします。ログにはアクセス先ドメインやノードアドレスが含まれる場合があるため、共有前に問題と無関係な接続情報を削除してください。

クライアントを選び、インストールを完了する

プラットフォームとコアの要件に合わせてクライアントを選ぶ

Windows、macOS、Linuxのデスクトップ環境では、まずv2rayNを選びます。サブスクリプション、ノード、システムプロキシ、ルーティング、DNS、TUN、ログを一つの画面で管理でき、基本接続から分流や仮想インターフェースの設定へ段階的に進めるのに適しています。Windowsではデスクトップ版とクラシックWPF版から選べます。デスクトップ版はクロスプラットフォームのUIを採用し、異なるデスクトップOSで似た操作手順を保ちたいユーザーに向いています。クラシックWPF版は従来のWindowsのメニュー構成とトレイ動作を残しており、既存の操作に慣れているユーザーに適しています。

Android端末では、ノード項目との互換性が比較的高いXray系のv2rayNGを優先します。V2Flyコアの設定が必要な場合はv2flyNGを選んでください。どちらもサブスクリプションの取り込み、ノード選択、ローカルVPNによる通信の取り込み、ログの確認に対応していますが、設定名や入口の位置は一部異なります。移行時はスクリーンショットのスイッチ状態だけを写すのではなく、標準ノードリンクを先にエクスポートするか、サブスクリプションを再登録し、ルーティング、DNS、アプリ別ポリシーを項目ごとに再構築してください。

インストール前にアーキテクチャと旧設定を確認する

ダウンロード前にクライアントページで対応するプラットフォームを選択します。macOSではApple SiliconとIntelを区別してください。Androidの近年の主流端末では通常arm64を選び、確認できない場合はユニバーサル版を使用します。Linuxではディストリビューションのパッケージ形式とプロセッサアーキテクチャを確認します。ファイル名に含まれるx64、arm64、deb、rpmが選択の基準であり、アプリ名だけで判断してはいけません。システムアーキテクチャが合わないと、インストーラーが実行を拒否する、対応していない形式だと表示される、起動直後に終了するといった症状が現れます。

旧版クライアントがある場合は、現在のサブスクリプションURL、サブスクリプショングループ、ルーティングルール、DNS設定、ローカルポートを先に記録します。クライアントに設定バックアップ機能があれば、個人のドキュメントフォルダーへ保存してください。ポータブル設定ディレクトリを使っている場合は、クライアントを完全に終了してからディレクトリ全体をコピーします。アップグレード時にクライアントの系統、コアの種類、主要設定を同時に変更すると、問題発生後に原因を特定しにくくなります。安全な順序は、設定を保持したままクライアントを更新し、基本接続を確認してからコアを更新したりルーティングを調整したりすることです。

デスクトップで初回起動を完了する

Windowsでインストール後にv2rayNを起動し、まずウィンドウ下部または設定ページでコアの状態を確認します。プログラムが通知領域にしか表示されない場合は、トレイアイコンからメイン画面を開いてください。システムのセキュリティ通知が表示されたら、実際に必要なネットワーク範囲に限ってアクセスを許可します。ポート競合は、旧インスタンスが終了していない、または別のプロキシプログラムが同じ待受ポートを使用している場合によく発生します。まず重複するプログラムを終了し、v2rayNのローカル待受設定でSOCKSとHTTPのポートが他のプロセスに使われていないことを確認してください。

macOSの初回起動では、アプリの実行、ネットワークアクセス、システムプロキシの変更について確認を求められる場合があります。許可したら、まず通常のシステムプロキシモードで検証し、すぐにTUNを有効にしないでください。Linuxでメイン画面は開けるのにトレイが表示されない場合は、デスクトップ環境がステータスアイコンに対応しているか確認します。トレイが一時的に見えなくても、メイン画面からサブスクリプションと接続を操作できます。Linuxでは、現在のユーザーに設定ディレクトリの読み書き権限があることも確認し、終了するたびに設定が保存できなくなる問題を防いでください。

モバイルで基本権限を設定する

Androidにv2rayNGまたはv2flyNGをインストールすると、初回接続時にVPN接続の確立を求められます。これは、システムがアプリの通信をクライアントに渡すために必要な権限です。システムのダイアログで許可するだけで構いません。厳しいバックグラウンド制限が有効な場合は、クライアントのバックグラウンド実行を許可してください。そうしないと、画面ロック後にコアが停止されることがあります。デュアルSIM、テザリング、仕事用プロファイルの環境ではネットワークインターフェースが変わるため、ネットワーク切り替え後に接続が途切れたら、いったん停止してから再接続します。

初回インストールでは3項目だけ確認します。クライアントが正常に開くこと、サブスクリプションまたは単一ノードを保存できること、接続後のログに起動エラーが繰り返し表示されないことです。この段階で大量のカスタムルールを取り込んだり、すべてのDNS項目を変更したりしないでください。まずデフォルトルーティングで再現可能な基本接続を確立し、その後の章でシステムプロキシ、分流、TUNを段階的に追加します。初回接続を早く完了したい場合は、クイックスタートの手順に移り、簡略化された流れで操作してください。

サブスクリプションを取り込み、ノードを管理する

サブスクリプションリンクと単一ノードリンクの違い

サブスクリプションリンクは、複数のノードと更新内容を継続的に取得するためのものです。単一ノードリンクは、1つの具体的な接続設定だけを表します。長期利用では、サブスクリプションの内容を手動ノードへ一つずつ変換するのではなく、サブスクリプショングループを作成するのが基本です。グループには更新先、メモ、フィルター、独立した更新方針を保存できます。ノードのアドレス、ポート、安全性パラメータが変わっても、サブスクリプションを更新するだけで済みます。手動ノードは一時的なテストや項目の確認には適していますが、多数のノードを管理する主な方法には向きません。

v2rayNで「サブスクリプショングループ」を開き、グループ名とサブスクリプションアドレスを追加して保存した後、「すべてのサブスクリプションを更新」または現在のグループを更新します。グループ名は提供元や用途を表すものにし、ノードの元のメモだけで区別しないでください。v2rayNGとv2flyNGでは、通常、サブスクリプション設定またはサイドメニューに入口があります。追加後は先に更新し、ノード一覧に戻って対象を選択します。サブスクリプションアドレスをコピーするときは、前後の空白、改行、チャットアプリが付けた説明文を含めないように注意してください。

更新に失敗したらリクエスト経路を確認する

サブスクリプションの更新失敗とノードの接続失敗は別の問題です。サブスクリプション更新では、クライアントがまずサブスクリプションアドレスへアクセスし、返された内容を解析します。ノード接続では、その後に解析されたサーバーパラメータを使用します。更新に失敗しても古いノードへ接続できるなら、既存設定はまだ使える可能性があります。サブスクリプションアドレスが完全か、システム時刻が正確か、現在のネットワークから更新先へアクセスできるか、サブスクリプショングループに誤った前置きプロキシが設定されていないかを確認してください。先に古いグループを削除すると、使える設定と比較用のサンプルを失うため避けてください。

サブスクリプションの更新に現在のプロキシが必要な場合は、保存済みで利用可能なノードに先に接続し、その後サブスクリプショングループで前置きプロキシを有効にします。サブスクリプションの入口へローカルネットワークから直接アクセスできる場合は、直接接続で更新したほうが切り分けやすくなります。返された内容を解析できない場合は、ログでHTTPリクエストの失敗、非対応の内容形式、特定ノードの項目異常のどれかを確認してください。1つのノードの解析失敗が、サブスクリプション全体の利用不能を意味するとは限りません。成功した項目は残し、異常な項目については提供元に確認します。

グループ、メモ、フィルターで一覧を整理する

複数のサブスクリプションがある場合は、各グループに安定した短い名前を付け、ノードのメモには「地域｜回線｜プロトコル」のように検索しやすい構造を残します。フィルターは表示や更新結果にだけ作用させ、ノードのプロトコル項目は変更しないでください。v2rayNではキーワードによる包含・除外でノードを絞り込めるため、重複項目を隠したり、特定プロトコルだけを残したりできます。ルールはできるだけ単純にし、安定したキーワードを1～2個使う程度にします。ノード名の一時的な文言に依存しすぎると、サブスクリプション側の名称変更で一覧が突然空になることがあります。

自動更新の間隔を短くしすぎる必要はありません。サブスクリプションの内容は通常、数分単位では変わらないため、頻繁なリクエストは失敗通知や一覧の更新を増やすだけです。日常利用では起動時に更新するか、実際の変更頻度に合わせて周期を設定します。更新後は、現在選択しているノードが残っているかを確認し、削除されていた場合だけ新しい項目を手動で選びます。より詳しいグループ運用はv2rayNで複数サブスクリプションを管理する方法を参照してください。

ノード選択を1回のテストだけに頼らない

遅延テストは、クライアントが指定された確認先へ到達できるかを素早く判断するためのものですが、実際のアプリ品質と同じではありません。テスト方法によってTCP接続、HTTP応答、実際の接続処理のいずれを測るかが異なり、結果を直接比較することはできません。ノードを選ぶときは、まずプロトコル項目がそろっていることを確認し、クライアントの疎通テストを実行してから、実際に必要なウェブページやアプリで検証します。1回のタイムアウトは、ローカルネットワークの揺らぎ、DNS、リモート側の帯域制限、テスト先の一時的な障害でも起こります。再テストし、ログと照合してください。

すべてのノードがタイムアウトする場合は、設定が明確なノードを1つ選んでサンプルにします。サーバーアドレスを解決できるか、ポートがローカルネットワークで遮断されていないか、システム時刻が大きくずれていないか、コアがノードのパラメータに対応しているかを確認します。同じグループの別ノードは正常で1つだけ失敗する場合は、プロトコル、トランスポート、安全性、メモ以外の実際の項目を比較します。すべてのサブスクリプションが同時に失敗する場合は、ローカルネットワーク、コアの起動、プロキシのループバックを重点的に確認し、ユーザー識別子を一つずつ変更しないでください。

{
  "protocol": "vless",
  "settings": {
    "vnext": [
      {
        "address": "example.com",
        "port": 443,
        "users": [
          {
            "id": "11111111-1111-4111-8111-111111111111",
            "encryption": "none",
            "flow": "xtls-rprx-vision"
          }
        ]
      }
    ]
  }
}

上の断片はVLESSアウトバウンドの項目階層を説明するためのもので、ドメインとユーザー識別子は例です。実際にサブスクリプションを使う場合は、クライアントが内容に基づいて完全な設定を生成します。例の項目で既存ノードを上書きしないでください。生成設定を確認する主な目的は、画面上のアドレス、ポート、ユーザー識別子、フロー制御が正しい階層に入っているかを確認することです。生成ファイル全体を長期的に手作業で管理することが目的ではありません。

システムプロキシとプロキシモードを選ぶ

システムプロキシはプロキシ対応アプリを取り込む

v2rayNはコアの起動後、ローカルでSOCKSとHTTPポートを待ち受けます。ただし、待受ポートがあるだけでは、すべてのアプリが自動的に取り込まれるわけではありません。「システムプロキシを自動設定」を有効にすると、OSのプロキシ設定を読み取るブラウザやデスクトップアプリがリクエストをv2rayNへ送信します。システムプロキシを無効にしてもコアは動作を続けられ、ローカルプロキシポートを手動指定したアプリは引き続き利用できます。この違いを理解すると、「クライアントは動いているのに一部のアプリしか接続できない」問題を切り分けやすくなります。

システムプロキシモードは、ブラウザ、オフィスソフト、システム設定に従う多くのアプリに適しています。影響範囲が明確で、クライアント終了後も元に戻しやすい方法です。システムプロキシを読み取らないコマンドラインツールは、そのツール自身でHTTPまたはSOCKSプロキシを設定し、すぐにTUNへ切り替えないでください。ローカルプロキシのアドレスには通常ループバックアドレスを使い、ポートはクライアントの現在の待受ポートと一致させます。リモートノードのポートをローカルプロキシポートに入力しないでください。

グローバル、ルール、直接接続モードは異なるルーティング方針に対応する

「グローバル」は通常、クライアントに入った通信を現在のプロキシアウトバウンドへ一律に送るモードです。ルーティングルールがアクセス障害の原因かを判断したり、ノード自体を短時間検証したりするのに適しています。ただし、LAN、プリンター、ローカル開発サービス、中国本土のリソースまでプロキシへ送られる可能性があるため、日常利用で必須ではありません。「ルール」モードはドメイン、IP、その他の条件に応じて直接接続かプロキシかを選び、長期利用ではこちらが一般的です。「直接接続」はクライアントに入ったリクエストを対象へ直接送るため、問題がプロキシ経路にあるか確認するのに使えます。

トラブルシューティングでは、一定の順序を決めておくと便利です。まずグローバルモードで対象をテストします。グローバルでは使えるのにルールモードで使えない場合は、ルーティングのマッチングを確認します。グローバルでも使えない場合は、ノード、DNS、コアを確認してください。直接接続が使えるからといってノードが正常とは限らず、ローカルネットワークから対象への直接経路が到達可能だと分かるだけです。テスト後は元のモードに戻し、ログで対象ドメインが想定したアウトバウンドタグを使用していることを確認します。

PACとシステムプロキシの例外範囲を明確にする

一部のデスクトップ環境では、PACスクリプトでどのリクエストをローカルプロキシへ送るか決められます。PACはリクエストがコアに到達する前に一度選択を行い、クライアントのルーティングはコアに入った後でもう一度アウトバウンドを決めます。両方を重ねると理解が難しくなります。細かなルーティングが必要な場合は、システムプロキシを一律クライアントへ向け、コアのルーティングで直接接続とプロキシを処理するほうが明快です。特定のアプリやドメインを完全にクライアントへ入れたくない場合に限り、システムプロキシの例外やPACを検討してください。

LANアドレスはバイパス範囲に追加します。一般的な範囲にはループバックアドレス、プライベートアドレス、ローカルドメインが含まれます。これにより、ルーターの管理画面、LAN上のファイルサービス、開発環境へアクセスするときにプロキシを経由しなくなります。LANサービスをドメイン名で利用する場合、先にDNSを使うことがあります。名前解決が正しくなければ、IPのバイパスを追加するだけでは解決しません。その場合はDNSのhosts、システムのhosts、ローカル名前解決サービスで同じ記録を維持してください。

通信が本当にクライアントへ入っているか検証する

ウェブページが開くかどうかだけで、システムプロキシの状態を判断しないでください。クライアントの接続ログを開き、以前キャッシュされていないドメインへアクセスして、新しい接続記録と対応するアウトバウンドが出るか確認します。ブラウザは正常なのにログに変化がない場合、ブラウザ独自のプロキシ、別のネットワーク拡張、キャッシュ済みの接続を使っている可能性があります。ログにリクエストがあるのにアウトバウンドがdirectならルーティングを確認し、proxyと表示された後にハンドシェイクが失敗するなら、ノード項目とリモート接続の階層へ戻ります。

コマンドライン環境では、直接接続での名前解決、システムプロキシの読み取り、明示的なプロキシを個別に検証できます。ツールによってシステムプロキシ環境変数への対応は異なるため、テストコマンドがどの経路を使うかを把握しておく必要があります。検証後は一時的な環境変数を削除し、後続のターミナルセッションで、すでに閉じたローカルポートへソフトウェア更新やパッケージ管理のリクエストを送らないようにします。日常設定の目的は、すべてのプログラムで同じ入口を使わせることではなく、アプリごとの入口を明確にし、確認・復元できる状態にすることです。

ルーティングとDNSを設定する

最小限のルーティングルールから始める

よくあるルーティング方針は、LANとプライベートアドレスを直接接続し、明確な中国本土のドメインとIPも直接接続し、それ以外の通信をプロキシへ送ることです。v2rayNでは、まず「中国本土をバイパス」などのプリセットルールを選び、実際のアプリに合わせてカスタムドメインを追加します。プリセットルールはGeoSiteとGeoIPのデータに依存します。前者はドメイン集合、後者は対象IPのアドレス範囲でマッチングします。ドメインルールは名前解決前に方針を決められますが、IPルールは通常、先に名前解決が必要です。両者は置き換えではなく、組み合わせて使います。

最小限のルールセットでは、まずプライベートアドレスを処理してLAN通信がリモートアウトバウンドへ入らないようにします。次に明示的なブロック対象、直接接続するドメインとIPを処理し、最後にプロキシをフォールバックとして設定します。ルールは多ければ正確になるとは限りません。重複するドメイン、古いルール、互いに上書きする式が多いと、ログの解釈が難しくなります。新しいルールはまず正確なドメイン1つで検証し、マッチすることを確認してから、サフィックスや分類タグへ広げてください。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": ["geoip:cn"],
        "outboundTag": "direct"
      }
    ]
  }
}

domainStrategyは、ドメインルールに一致しなかった場合に名前解決を続け、IPルールを試すかどうかを決めます。IPIfNonMatchは、ドメインルールに結果がない場合にIPを解決する動作で、GeoSiteとGeoIPを併用する一般的な構成に適しています。既存のIPだけで処理する設定では、一部のドメイン通信が想定したIPルールに入らないことがあります。すべてのドメインを先に解決すると、DNSの関与が増えます。方針を変更した後は、名前解決ログとルーティングログを同時に確認してください。

ドメインルールのマッチ範囲を理解する

完全一致のドメインは指定されたホストだけに一致します。ドメインサフィックスはサブドメインまで対象にできます。キーワード一致は範囲が広く、名前が似ているだけで用途の異なるドメインも一緒に含めるおそれがあります。まずは完全なドメイン、または明確な分類タグを使い、複数のサブドメインを対象にする必要があり、なおかつ構造が安定している場合にだけサフィックスを使ってください。コンテンツ配信ネットワークでは、同じサービスが複数のドメインを呼び出すことがあります。アドレスバーのメインドメインだけでルールを作らず、接続ログで実際のリクエスト群を確認してください。

ルーティングの判断は、クライアントがドメインを認識できることに依存します。アプリがIPへ直接接続する場合、ドメインルールには一致せず、IP、ポート、プロセスのルールだけが使えます。一部のDNSマッピング機能を有効にすると、コアがドメインと接続の対応を復元できる場合がありますが、DNSリクエストもクライアントが管理している必要があります。「同じウェブサイトが直接接続になったりプロキシになったりする」場合は、異なるサブドメイン、IPv4とIPv6の結果差、キャッシュされた名前解決結果、アプリ独自の名前解決経路を確認してください。

DNSとルーティングを1本の経路として設定する

DNSの役割はドメインをIPへ変換するだけではありません。後続のルーティングが一致するか、ローカルキャッシュや名前解決経路の影響を受けるかにも関わります。よくある構成は、中国本土のドメインにローカルまたは中国本土の名前解決サービスを使い、それ以外のドメインにはリモートDNSを使い、リモートDNSへのリクエストをプロキシアウトバウンド経由にする方法です。これにより、名前解決結果と実際のアクセス経路の不一致を減らせます。具体的なルールは、現在のコアが対応するDNS構造に合わせて設定し、システム、ブラウザ、クライアント、複数のネットワークツールで互いに競合する名前解決方針を同時に設定しないでください。

DNSを調査するときは、まず変数を減らします。ブラウザ独自のセキュアDNSを無効にしてクライアントDNSだけを残すか、クライアントのカスタムDNSを一時的に無効にしてシステムの名前解決だけをテストしてください。主な名前解決経路は一度に1つにします。ドメインへアクセスできない場合は、ログにクエリが出ているか、どのアドレスが返されたか、そのアドレスがどのルールに一致したかを確認します。名前解決は成功して接続だけ失敗するなら、問題はすでにトランスポート層にあります。クエリ記録がない場合は、アプリがクライアントのDNSを回避している可能性があります。

DNS漏れ、キャッシュ、IPv6経路を扱う

システムプロキシを使っていても、アプリの名前解決方法によってはシステムDNSを直接呼び出すことがあります。名前解決リクエストをクライアントで一元処理するには、クライアントのリモートDNS、DNSアウトバウンド、TUNによるDNS取り込みを利用します。確認方法には、ブラウザでの検査、システムコマンドによる問い合わせ、クライアントログの照合があります。詳しい手順はv2rayNのDNS漏れを検出・修正する方法を参照してください。判断時は最終的なIPだけでなく、名前解決サーバーとリクエスト経路に注目します。

キャッシュによって、変更が反映されていないように見えることがあります。クライアント、OS、ブラウザ、アプリはいずれもDNS結果を保存する可能性があります。ルールを変更したら、関連アプリを再起動するか対応するキャッシュを消去し、新しいドメインで接続を確立してください。IPv6が利用できる場合、ドメインはAレコードとAAAAレコードを同時に返すことがあります。ローカルのIPv6経路が不安定だと、アプリが接続に失敗するアドレスを優先する場合があります。まずシステムのIPv6接続が正常か確認し、その後、IPv6を維持・制限するか、専用ルーティングを作るか決めてください。DNSレコードを削除してネットワーク問題を長期的に隠すだけでは不十分です。

GeoIPとGeoSiteのデータを管理する

GeoIPとGeoSiteのデータは、アドレス割り当てやドメインの変化に合わせて更新されます。ルールを変更していないのに分流結果が徐々に想定から外れる場合は、現在のコアがデータファイルを読み取れるか、更新処理が完了しているか、カスタムファイルがクライアント管理版を上書きしていないかを確認します。データファイルとコアには互換性が必要です。更新後はコアを再起動し、ログで分類タグが読み込まれたことを確認してください。

データファイルを手動で置き換える前に、クライアントを終了して元ファイルをバックアップします。ファイルが使用中のままになるのを防ぐためです。置き換え後の起動ログでタグが存在しない、またはファイル形式が不正と報告された場合は、すぐにバックアップを戻し、補完ルールを追加し続けないでください。確認場所、更新入口、復元方法の詳細はGeoIPとGeoSiteデータの更新ガイドを参照してください。ルーティングデータベースは分類の根拠にすぎないため、最終的にはアクセスログで対象が想定したアウトバウンドに一致したか確認します。

TUNモードを有効にして調整する

TUNが必要な場面を明確にする

TUNモードは、仮想ネットワークインターフェースを通じてOSのIP通信を受け取ります。システムプロキシを読み取らないアプリ、一部のコマンドラインプログラム、通信を一元的に取り込みたい場面に適しています。通常、システムプロキシより対象範囲が広いため、LAN、ソフトウェア更新、バックグラウンドサービス、もともとプロキシを通らない通信までルーティングの対象になります。ブラウザと一般的なデスクトップアプリだけを使うなら、システムプロキシで十分なことが多いです。個別にプロキシを設定できないアプリがあると確認してからTUNを有効にすると、保守しやすくなります。

TUNはノードの接続性能を高めるスイッチではありません。ノード自体のハンドシェイク失敗、サブスクリプション項目の誤り、リモートへの到達不能は、TUNを有効にしても解決しません。むしろルーティングテーブル、DNS、権限の変数が増えます。正しい順序は、まずシステムプロキシモードで現在のノードを検証し、その後にTUNを有効にして、同じノードと基本ルーティングを維持することです。TUNを有効にした後すべてのアクセスが失敗しても、切り替え前後のログとシステムルートを比較すればよく、サブスクリプションを改めて疑う必要はありません。

権限、インターフェース、アドレス範囲を事前に確認する

仮想ネットワークインターフェースの作成やルート変更には、通常システム権限が必要です。v2rayNで権限不足が表示された場合は、クライアントとOSが案内する方法で許可し、起動ボタンを何度も押さないでください。ほかの仮想ネットワークツールがあると、インターフェース間のルート競合、DNSの二重取り込み、デフォルトルートの切り替えが起きることがあります。調査中はシステムネットワークを変更する他のプログラムを終了し、v2rayNだけを残してTUNインターフェースを再作成します。

TUNが使用する仮想アドレス範囲は、現在のLAN、企業ネットワーク、他の仮想インターフェースと重複させないでください。重複すると、一部のアドレスにアクセスできない、LAN機器と通信できない、リクエストがループするといった症状が出ます。まず本機の既存ルートを確認し、クライアントのデフォルトで、他と競合しないアドレス範囲を選びます。Windowsではシステムのネットワーク画面からアダプターとルートを確認できます。macOSとLinuxではシステムのネットワークツールを使います。重要なのは、デフォルトルート、LANのサブネット、TUNのサブネットがそれぞれ正しいインターフェースを向いていることです。

ip route
ip route get 1.1.1.1
resolvectl status

これらのLinuxコマンドは、ルーティングテーブルの確認、指定した対象を経由するインターフェースの確認、現在のDNS状態の確認に使います。他のデスクトップOSでは、対応するシステムネットワークツールを使用してください。コマンド結果は主にTUNの有効化前後を比較するために使います。デフォルトの通信が仮想インターフェースへ入っているか、LANのサブネットが物理インターフェースから直接接続されているか、DNSサーバーが想定した入口へ切り替わったかを確認します。

自動ルート、厳格ルート、バイパス項目を設定する

自動ルートを使うと、クライアントが通信をTUNへ向けるシステムルートを作成します。通常はまずデフォルト値を使ってください。厳格ルートは迂回通信への制限を強めるため、基本的なTUNが正常だと確認してから試します。厳格な方針を有効にすると、ローカルサービス、仮想マシン、コンテナ、LAN検出に影響する場合があります。そのため、先にプライベートアドレスとローカルインターフェースのバイパスを設定します。すべてのプライベートアドレスをプロキシアウトバウンドへ送ると、ルーター、プリンター、ローカル開発サービスにアクセスできなくなるため注意してください。

プロセス単位のバイパスや包含設定でTUNの対象範囲を狭められますが、プロセス名、子プロセス、システムサービスの関係は実際に検証する必要があります。アプリがランチャーから別プロセスとして起動されることも、ネットワーク処理をシステムコンポーネントへ渡すこともあります。メインプログラム名を追加するだけでは、リクエスト全体を対象にできない場合があります。最初は通常のルーティングルールで検証し、アプリ単位の制御が本当に必要な場合に、ログを見ながらプロセスを1つずつ追加し、デフォルトアウトバウンドをフォールバックとして残してください。

TUNでDNSとMTUを調整する

TUN環境では、DNSをクライアントで一元的に処理し、ドメイン、マッピングアドレス、実際の接続の対応を保つのが望ましい方法です。一般的には、システムDNSをクライアントが提供するローカル入口へ向け、コアがドメインルールに基づいてローカルまたはリモートの名前解決を選択します。システムが別のDNSも同時に使っていると、解決結果がコアに入らない、ドメインルールと関連付かない、検査結果が一致しないことがあります。TUNへ切り替えた後は、まずDNSの状態を確認してからウェブテストを行ってください。

一部のネットワークでは、ウェブページの読み込みは始まるのに、大容量ファイルや特定のリクエストだけが止まることがあります。これはMTUが原因かもしれません。TUNのカプセル化で追加のオーバーヘッドが発生し、経路上の機器が断片化を正しく処理できない場合があります。調査時は、クライアントが対応する範囲内でMTUを段階的に下げ、一度に1段階だけ変更して同じ対象で再テストします。極端に小さい値を直接設定しないでください。MTUが小さすぎると、断片化と処理の負荷が増えます。特定のネットワークだけで異常が起きる場合は、ほかのWi-Fiや有線ネットワークとも比較してください。

元に戻せる終了手順を確立する

クライアントを通常終了する前にTUNを無効にし、仮想インターフェース、ルート、DNSの変更をクライアントに取り消させます。異常終了やクラッシュの後にネットワークが使えなくなった場合は、まずクライアントを再起動し、TUNを一度正常にオン・オフしてクリーンアップ処理を実行します。それでも戻らなければ、システムプロキシ、デフォルトルート、DNSを確認してください。残留状態が分からないまま複数のネットワークツールを続けてインストールすると、ルートの出所がさらに分かりにくくなります。

安定したTUN設定には4つの条件があります。有効化後も基本アクセスが正常であること、LANへ到達できること、DNSリクエストが想定した経路に入ること、無効化後にシステムネットワークが完全に復元することです。この4項目を確認してから、厳格ルート、プロセスルール、複雑なDNSを追加します。TUNのよくある問題はクイックスタートページで基本接続の確認順を見直し、この章と組み合わせてシステム取り込みの階層を特定してください。

日常のメンテナンス、バックアップ、トラブルシューティング

クライアント、コア、サブスクリプション、ルールを分けて更新する

v2rayNのGUIクライアント、プロキシコア、サブスクリプションの内容、GeoIP・GeoSiteデータは、4つの独立した更新対象です。一度に1つだけ更新し、基本接続と分流を確認してから次へ進みます。これにより、設定の互換性問題が起きてもすぐに元へ戻せます。クライアント更新は主にUIと設定生成方式を変え、コア更新はプロトコル実装やパラメータ対応を変えることがあります。サブスクリプション更新はノードを変え、ルーティングデータベース更新は分類結果を変えます。それぞれ症状が異なります。

更新前に、現在利用できるノード、コアの種類、システムプロキシモード、TUNの状態、カスタムルーティングを記録します。重要な設定をバックアップし、直近で正常動作を確認した設定のコピーを残してください。更新後は元のノードと元のモードで先にテストし、古い設定をすぐに整理しないでください。起動ログに解析エラーがなく、接続ログが正常だと確認してから、古いバックアップを削除します。自動更新はサブスクリプションや通常のデータに適していますが、クライアント系統の切り替えや大規模なルール変更は手動で計画してください。

「入口—名前解決—ルーティング—通信」の順で調査する

1段階目は入口です。プログラムがシステムプロキシを読み取っているか、通信がTUNに入っているかを確認します。2段階目は名前解決です。ドメインからアドレスを取得できるか、DNSリクエストが想定した経路を通っているかを確認します。3段階目はルーティングです。対象がdirect、proxy、blockのどれに一致したかを確認します。4段階目は通信です。ノードのプロトコル、ポート、安全性パラメータ、リモートの応答を確認します。順序を固定すれば、DNSの問題で何度もノードを替えたり、ノードのハンドシェイク失敗時にルーティングを闇雲に変更したりせずに済みます。

ブラウザは使えるのに他のアプリが使えない場合は、まずアプリの入口を確認します。すべてのドメインに失敗して既知のIPへは接続できる場合は、DNSを確認します。ルールモードで失敗し、グローバルモードで正常なら、ルーティングを確認します。すべてのノードが突然失敗した場合は、ローカルネットワーク、システム時刻、コアプロセス、サブスクリプションの変更を確認します。単一ノードの失敗なら、そのノードの項目を同じグループの正常なノードと比較してください。調査時は既知の正常なサンプルを1つ残すほうが、大量のノードを同時にテストするより有効です。

ログレベルと時系列を正しく使う

日常はログレベルをwarningに保ち、起動失敗、名前解決異常、接続エラーを目立たせます。ルーティングのマッチングを確認する必要があるときだけinfoへ一時的に切り替え、対象へのアクセスを1回再現して該当時間帯をすぐ保存します。ログが多すぎる場合は、まず接続を停止して現在の表示を消し、再起動後に1つのテストだけ実行します。起動、DNS、ルーティング、接続の記録を時系列で追えるため、大量のバックグラウンドリクエストから対象を探す必要がなくなります。

エラーメッセージは前後の文脈と合わせて解釈します。timeoutは、規定時間内に想定した応答を受け取れなかったことを示し、DNS、TCP接続、プロトコルのハンドシェイクで発生する可能性があります。connection refusedは、対象が現在のポートを明確に拒否したことを示します。name resolution failedは名前解決層を指します。設定解析エラーには通常、項目のパスや型が示されます。ログを共有して問題を相談するときは、エラー前後の必要な行だけを残し、サブスクリプションアドレス、ノードの認証情報、問題と無関係なアクセス記録を削除してください。

システム時刻、ポート、バックグラウンド状態を管理する

TLSやREALITYなどの接続は、正確なシステム時刻に依存します。端末の時刻が大きくずれていると、証明書の有効期間の判定やハンドシェイクに失敗することがあるため、システムの自動時刻同期を有効にしてください。ポートについては、ローカルのSOCKS、HTTP、APIの待受が他のプログラムと競合しないようにします。ポートを変更したら、アプリ内で手動設定したプロキシも合わせて変更します。クライアントを重複起動すると、画面が2つ表示されてもポートを確保できるのは1つだけの場合があります。プロセス一覧とログで確認してください。

モバイル端末ではバックグラウンド制限に、デスクトップOSではスリープ復帰、ネットワーク切り替え、トレイ終了に注意します。有線からWi-Fiへ、家庭のネットワークからモバイルホットスポットへ切り替えた後は、古い接続やDNSキャッシュが残ることがあります。異常が起きたら現在の接続を停止し、古いセッションが解放されるのを待ってから再接続します。TUNを長期利用する場合は、OSのメジャーアップデート後に仮想インターフェースの権限と終了後の復元手順を必ず再確認してください。

シンプルで復元しやすいバックアップ構成を作る

バックアップには少なくとも、サブスクリプショングループ、手動ノード、カスタムルーティング、DNS設定、クライアントの基本設定を含めます。ファイル名には日付と用途を使い、「デスクトップ基本ルール」「TUN安定設定」のようにします。ただし、サブスクリプションアドレスやノード識別子をファイル名に書かないでください。バックアップ後は実際にインポートまたは復元できるか検証します。不完全なデータベースファイルを1つコピーしただけでは、復元できるとは限りません。プラットフォームをまたいで移行する場合は、標準サブスクリプションとルールの考え方を優先し、すべてのGUI設定ファイルがそのまま共通利用できるとは考えないでください。

複雑な障害が起きたときは、修正ルールを重ね続けるより最小構成へ戻すほうが早いことが多いです。TUNを無効にしてシステムプロキシを使い、DNSは一時的にデフォルトへ戻し、既知の設定を1つ選び、グローバルモードを有効にします。接続を確認したら、ルーティング、DNS、TUNを順番に戻し、各段階で同じ対象を再テストしてください。DNSに関する問題は中国本土・海外の分流名前解決設定を、Linuxのインストールと自動起動はv2rayNのLinuxインストールガイドを参照してください。

動作する設定から保守できる設定へ

まず最小限の基準設定を固定する

応用設定の出発点は、ルールを増やすことではありません。安定して再現できる最小限の基準設定を保存することです。基準設定には、利用可能なサブスクリプショングループ、検証済みのノード、システムプロキシの入口、シンプルなプライベートアドレスの直接接続ルール、明確なデフォルトアウトバウンド、確認可能なログを含めます。すべてのアプリを対象にする必要はありませんが、リクエストがどこから入り、どのように名前解決され、どのルールに一致し、どのアウトバウンドを使うかを説明できなければなりません。

基準設定に機能を追加するときは、小さく変更します。まずGeoSiteとGeoIPの分流を追加して検証し、次にリモートDNSを追加して検証し、その後にTUNを検証します。プロセスルール、厳格ルート、複雑なドメイン範囲は最後に検討してください。各段階で設定のスナップショットとテスト対象を保存します。テスト対象には、通常のウェブページ、LANサービス、プロキシが必要なドメイン、直接接続するドメイン、システムプロキシを読み取らないアプリを含め、変更が単一の場面だけを解決していないことを確認します。

生成設定を理解してからカスタマイズする

v2rayNなどのクライアントは、GUIの設定をコアの設定へ変換します。応用設定を行うユーザーは、生成結果のinbounds、outbounds、routing、dns、logを確認できるようにしてください。ただし、一時的に生成されたファイルを直接編集して長期運用するのは避けます。クライアントの再起動やノード切り替えで再生成される可能性があるためです。正しい方法は、クライアントが提供するカスタム設定、ルーティングルール、プリセットの入口で変更し、生成結果で想定した項目に反映されたことを確認することです。

設定を確認するときは、まずタグの対応関係を追跡します。ルーティングルールのoutboundTagは実際のアウトバウンドタグに対応していなければなりません。DNSサーバーでアウトバウンドを指定する場合も、対応するタグが存在する必要があります。インバウンドタグはルールの適用範囲を制限するために使えます。項目名が正しくてもタグの綴りが一致しないと、コアが起動を拒否したり、想定外の経路を使ったりすることがあります。配列の順序も重要で、特にルーティングルール、DNSサーバーの選択、ドメインのマッチリストでは注意が必要です。

{
  "dns": {
    "servers": [
      {
        "address": "https://dns.example/dns-query",
        "domains": ["geosite:cn"],
        "skipFallback": true
      },
      {
        "address": "https://resolver.example/dns-query",
        "domains": ["geosite:geolocation-!cn"]
      }
    ],
    "queryStrategy": "UseIP"
  }
}

この断片は、ドメイン集合に応じてDNSサーバーを選ぶ構造を示すもので、例のドメインは項目を説明するためだけに使っています。実際の設定では、現在のコアが対応する記法か確認し、名前解決サービスに正しいアウトバウンドを割り当ててください。skipFallbackは、マッチしたサーバーが失敗したときのフォールバック動作に影響します。結果を理解しないまま一括で有効にしないでください。DNS設定後も、ルーティングと合わせて、名前解決リクエストと対象接続が一貫した経路を使っているか確認します。

ネットワーク環境ごとに設定の境界を作る

家庭、職場、公共のネットワーク、モバイルホットスポットでは、DNS、IPv6、LANのサブネット、ポートの到達性が異なる場合があります。強い前提を置いた1組のルールですべての環境を覆わないでください。ネットワークを頻繁に切り替える場合は、「システムプロキシ基本」「TUN取り込み」「LAN保持」など、取り込み範囲を表す名前で複数の設定を用意します。切り替え後は、クライアントを起動する前に現在のデフォルトルートとDNSを確認し、古いインターフェースの残留による問題を減らします。

職場のネットワークでは内部ドメインやプライベートDNSが使われることがあり、これらのリクエストはローカルの名前解決経路に残し、内部アドレスへ直接接続する必要があります。家庭内のストレージ、プリンター、メディア機器も同様にプライベートサブネットのバイパスが必要です。公共ネットワークではログイン認証ページが表示されることがあります。ネットワーク接続後、まずローカル認証を完了してからプロキシやTUNを起動してください。認証ページが開けない場合は、システムプロキシとTUNを一時的に無効にし、認証後に元の設定へ戻します。

主観ではなくテストマトリクスで判断する

保守しやすい設定には、固定したテストマトリクスが必要です。変更のたびに、クライアントが起動するか、サブスクリプションを更新できるか、既知のノードへ接続できるか、直接接続するドメインがdirectになるか、プロキシ対象のドメインがproxyになるか、LANアドレスへ到達できるか、DNSが想定したサーバーを使うか、TUN無効化後にネットワークが復元するかを順番に確認します。結果は「成功、失敗、未テスト」で記録し、「ネットワーク正常」とだけ書かないでください。

回帰が発生した場合は、最初に失敗した項目に応じて該当する階層へ戻ります。クライアントが起動しないならウェブテストを行わず、DNSを確認できていないならルーティングを評価しません。LANの通信に失敗したら、プライベートアドレスルールとインターフェースを確認します。TUNを無効にしても復元しない場合は、まずシステムネットワークを処理してください。テスト順序を固定すれば、クライアント、コア、データファイルを更新したときも同じ手順で再確認でき、記憶に頼らずに済みます。

長期的な学習ルートを作る

このガイドを読み終えたら、まず接続ログと生成設定を理解し、次にドメイン方針、DNSアウトバウンド、TUNルーティング、プロトコルパラメータを深掘りします。プロトコルは項目間の関係を中心に学びます。VLESSのユーザー識別子とフロー制御、REALITYのサーバー名と公開鍵、トランスポート層のサービス名とパスを、実際のノード設定と結び付けて理解してください。大量の設定断片を集めることから始めないでください。クライアントのバージョン、コアの能力、サーバー側の条件から切り離された断片は、そのまま再利用しにくいものです。

日常のメンテナンスでは、説明可能な状態を重視します。現在のノードがどのグループに由来するか、システムプロキシまたはTUNが有効か、主なDNS経路は何か、デフォルトアウトバウンドは何か、基準設定へ戻す方法を把握してください。設定が複雑になるほど、暗黙の状態を減らす必要があります。具体的な問題が起きたら、まず該当する章へ戻り、サイト内の記事とクイックスタートページのよくある質問を確認し、階層に沿ってログと再現手順を集めます。