V2Ray 高度な設定ガイド

なぜ基準状態が必要なのか

v2rayNの実際の接続結果は、複数の設定が組み合わさって決まります。サブスクリプションはサーバー情報を提供し、クライアントは使用するサーバーを選択し、ルーティングはトラフィックの送信先アウトバウンドを決め、DNSはドメインの名前解決方法を決定します。システムプロキシやTUNは、どのアプリの通信をコアへ取り込むかを左右します。どこか一層を変更しただけでも、「ウェブページが開かない」「一部のアプリだけ有効になる」「サーバーを切り替えると結果が変わる」といった症状が現れます。ルーティング、DNS、取り込み方式を一度に変更すると、問題の原因を特定しにくくなります。

まずは最小限の動作基準を作ることをおすすめします。接続を確認できたサブスクリプショングループを1つだけ残し、設定が揃ったサーバーを1台選び、ルーティングはクライアント標準の基本モード、DNSは初期設定、取り込み方式はシステムプロキシにします。その後、普段使う一般的なウェブサイトへアクセスし、v2rayNのログに接続確立、名前解決、アウトバウンド選択の記録が出るか確認します。ここで複雑な動作を目指す必要はありません。クライアント、コア、サーバー、ローカルネットワークが一連の通信経路を形成できることを確認できれば十分です。

基準状態として記録すべきなのは、一時的なテスト結果の数値ではなく設定同士の関係です。現在のアクティブグループ、サーバーの別名、システムプロキシの状態、ルーティングモード名、DNSをクライアントが処理しているか、TUNが無効か、ログに残る最後の正常接続のおおよその時刻を記録できます。サーバーアドレスや認証情報などの機密情報は公開メモに書かないでください。移行が必要な場合は、クライアントの設定エクスポート機能を使い、ファイルを管理された場所に保存します。

一度に一つだけ変更する

基準状態から始め、各回で変更する設定テーマは1つだけにします。たとえば、まずサブスクリプショングループとフィルタリングを設定し、更新と選択が正常であることを確認してから、ルーティングルールへ進みます。ルーティングが安定したらDNSを調整し、最後にTUNやFakeDNSを有効にします。各段階で、クライアントログに継続的なエラーがないこと、想定したアプリが通信できること、取り込むべきでない通信が従来の経路で動作することを確認します。設定に失敗しても直前の変更だけを取り消せるため、全体を初期状態に戻す必要がありません。

トラブルシューティング中はログレベルを一時的に info まで上げ、ルーティングのマッチング詳細を確認するときだけ、さらに詳しいレベルを使います。詳細すぎるログを常用すると読みづらくなり、本当に重要なエラー行が大量の接続記録に埋もれる可能性があります。確認後は普段のレベルに戻し、テスト用に作った一時ルールを削除します。ログでは、後から繰り返されるエラーより最初のエラーのほうが有用なことが多く、後続の失敗は上流の問題による連鎖である場合があります。

ロールバック可能な作業用コピーを作る

大幅な変更を始める前に、v2rayNで現在の設定をエクスポートするか、既存のルーティング設定セットをコピーし、用途が分かる名前を付けます。たとえば「オフィス基本ルート」や「テスト-TUN-DNS」などです。名前には利用シーンを反映し、「新しい設定」「設定2」のような名前だけにしないでください。クライアントが複数のルーティング設定セットに対応している場合は、実験的な変更を加えていない基本セットを残します。サブスクリプションの更新はこのバックアップの代わりになりません。サブスクリプションに保存されるのは主にサーバー項目で、ローカルのルーティング、DNS、システムプロキシ、カスタムアウトバウンドまでは含まれないことがあります。

設定を検証するときは、「クライアントが通信を取り込んでいない」状態と「通信はクライアントに入ったがアウトバウンドで失敗した」状態を区別します。前者では通常、システムプロキシ、TUN、アプリ自身のプロキシ設定を確認します。後者ではサーバー、ルーティング、DNS、アウトバウンドチェーンを確認します。最も直接的な方法は、ログに対象ドメインや接続先が表示されるかを見ることです。関連する記録がまったくなければ取り込み層から調べ、表示された後に名前解決や接続エラーが出るならDNSとアウトバウンド層へ進みます。基本的な症状についてはヘルプセンターも参照し、アプリ自身の問題をコアの問題と誤認しないようにしてください。

一時的な状態ではなく取得元でグループを作る

v2rayNでは、手動で追加したサーバーと複数のサブスクリプションを同時に保存できます。安定した整理方法は、「1つのサブスクリプションにつき1グループ」とし、手動設定は「自作ノード」などの別グループに分けることです。こうすれば、ある取得元を更新したときに別の取得元の項目を誤って削除せずに済み、サーバー項目がサブスクリプション由来かローカル入力かもすぐ判断できます。同じ提供元が用途別の購読URLを用意している場合も、用途を名前に加えて別々に管理し、更新後にサーバーの別名から取得元を推測する方法は避けます。

グループ名は短く明確にします。たとえば「仕事用購読」「モバイル予備」「自作ノード」などです。期限、特定時点の速度測定結果、現在使用中のサーバーをグループ名に含めないでください。これらは頻繁に変わるため、名前がすぐ実態と合わなくなります。サブスクリプションのメモには取得元と利用範囲を記し、更新時刻はクライアントの記録に任せます。複数デバイスで同じサーバー取得元を維持する場合は、パソコンとスマートフォンなど複数デバイスでV2Ray設定を同期する3つの方法を参照してください。サブスクリプション同期と単一ノードの受け渡しには違いがあります。

更新、整理、統合の違いを理解する

サブスクリプションを更新すると、クライアントは返された内容に基づいて対応するグループを更新します。古い項目を残すかどうかはクライアントの設定と更新方法によって異なるため、操作前に選択中のグループを確認してください。購読元からサーバーが削除されたのにローカルに古い記録が残る場合、更新時に保持設定が有効だったか、同名の項目が別グループに存在する可能性があります。このとき、同名サーバーをいきなり全体削除せず、グループ列を表示するかグループ表示に切り替えて、項目の実際の取得元を確認します。

「古いサーバーの整理」は、サブスクリプションの内容が大きく変わったときに適していますが、そのグループで手動変更したメモにも影響します。ローカルの変更を残す必要がある場合は、必要な項目を先に手動グループへコピーしてから、元の購読を更新します。複数のサブスクリプションを統合するとグループ数は減りますが、取得元の境界が失われます。更新に失敗したときに原因の購読を特定しにくくなり、同名サーバーの上書きも起こりやすくなります。上流側で統合済みの購読が提供されていない限り、クライアント側では複数の独立したグループを維持するほうが無難です。

フィルター式で一覧を絞り込む

サーバーフィルターは、「項目は多いが普段使う範囲は狭い」という問題を解決します。よくある方法は、別名のキーワードで残す、プロトコル名で絞る、キーワードで除外する、複数条件を組み合わせることです。フィルターは一覧表示や候補範囲だけを変更し、サーバー設定を修正したり、購読元の内容を変更したりするものではありません。フィルターを設定する前に、サーバー名が安定しているか確認してください。購読更新のたびに別名の形式が変わる場合、名前に依存するルールも合わせて保守する必要があります。

フィルター式は通常、通常のキーワードまたは正規表現に対応しています。通常のキーワードは保守しやすく、名前の構造が単純なサブスクリプションに適しています。正規表現は複数の固定語を同時に検索する場合に便利ですが、エスケープと大文字・小文字に注意が必要です。以下の式は、名前に「オフィス」または「予備」を含む項目を残し、「テスト」を含む項目を除外します。具体的な入力場所は、クライアントのサーバーフィルター設定に従ってください。

保持する式：
オフィス|予備

除外する式：
テスト

正規表現を使う場合は、まず単純な組み合わせから始め、最初から長い1行の式を書かないことをおすすめします。名前が「オフィス-上海-VLESS」「予備-東京-Trojan」の場合、^(オフィス|予備)- で固定プレフィックスに一致させられます。名前に括弧、プラス、ドットなど正規表現の特殊文字が含まれる場合は、エスケープが必要です。フィルター結果が空になったら、最初に除外条件を一時的に消してください。購読を再インポートするのではなく、項目が戻ったことを確認してから条件を少しずつ追加し、過剰に一致している箇所を特定します。

ルールは上から順に評価される

接続がXrayまたはV2Flyコアに入ると、ルーティングモジュールはドメイン、宛先IP、ポート、ネットワーク種別、インバウンドタグ、プロセス情報などの条件から一致するルールを探します。通常は最初に一致したルールがアウトバウンドを決め、それ以降のルールは評価されません。そのため、具体的な例外ルールは前に、範囲の広いフォールバックルールは後ろに置きます。たとえば、あるドメインだけプロキシ経由にし、所属するドメイン分類全体は標準で直結する場合、個別ドメインのルールを分類ルールより前に置きます。

よく使われるアウトバウンドタグには proxy、direct、block がありますが、実際の名前はクライアントが生成した設定によって異なります。カスタムルールでは、現在の設定に実在するアウトバウンドタグを使ってください。タグの表記が一致しないと、意図したアウトバウンドを参照できません。GUIの「プロキシ」「直結」「ブロック」は通常これらのタグに変換されます。完全なJSONをインポートする場合は、ルーティングルールとoutbounds配列内の tag の対応を自分で維持する必要があります。

ドメインルールとIPルールの役割

ドメインルールは、接続にドメイン情報が残っている場合に機能し、完全なドメイン名、サブドメインのサフィックス、内蔵ドメイン分類による振り分けに適しています。IPルールは、宛先がすでにアドレスへ解決されている場合や、LAN、予約アドレス範囲などを扱う場合に適しています。ドメインスニッフィングを有効にすると、当初IPしか持たない接続でもドメイン情報を再取得してドメインルーティングに参加できる場合があります。ただし、すべてのプロトコルやアプリでドメインを復元できるとは限らないため、重要なルールを単一の経路だけに依存させないでください。

domain:example.com は通常、そのドメインとサブドメインに一致し、full:api.example.com は完全一致のみ、regexp: は正規表現条件に使います。完全なドメイン名やサフィックスで表現できるルールに正規表現を使う必要はありません。IPルールではCIDRを使用でき、たとえば 192.168.0.0/16 はLANアドレスの範囲を表します。ルール中のドメイン例は構文説明用です。実際には制御対象のドメインへ置き換えてください。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "domain": [
          "full:api.example.com",
          "domain:assets.example.com"
        ],
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "protocol": [
          "bittorrent"
        ],
        "outboundTag": "direct"
      }
    ]
  }
}

domainStrategy は、ルーティング段階でドメインをIPへ解決するタイミングを決めます。AsIs はドメインを優先して保持し、IPルールのために自動解決しません。IPIfNonMatch はドメインルールに一致しない場合に解決してからIPルールを試します。IPOnDemand はIPが必要になりそうなルールに遭遇した時点で、より早く解決します。通常はクライアントのプリセットを使い、「より完全に見える」という理由だけで積極的な解決方式へ変更しないでください。DNSリクエストの発生タイミングが変わり、トラブルシューティングの経路が複雑になる可能性があります。

小規模なルールセットで順序を検証する

新しいルーティングセットを作るときは、まず3種類のルールだけにします。必ずプロキシを通す少数のドメイン、LANアドレスの直結、最後のデフォルトアウトバウンドです。保存して適用したら、ブラウザーで対象ドメインへアクセスし、ログで一致したアウトバウンドタグを確認します。検証後にドメイン分類、ポート、プロセスのルールを追加します。最初から数百のカスタムルールをインポートすると、個別の例外が前方の広範な条件に捕捉されやすく、内蔵データが現在のコアに適合しているかも判断しにくくなります。

ポートルールはネットワーク種別と組み合わせて考えます。たとえば 53 だけを指定すると、TCPとUDPのDNS通信に同時に影響する可能性があります。UDPだけを制御する場合は、ネットワーク条件も指定してください。プロセスルールは、クライアント、OSの権限、取り込み方式に依存し、プラットフォームによって利用できる機能が異なります。少数のアプリ例外を処理する用途に適しており、ドメインルールやIPルールに代わる主要な振り分け手段には向きません。アプリの更新で実行ファイル名が変わると、古いプロセスルールも機能しなくなります。

ウェブサイトが複数のリソースドメインを使う場合、メインドメインだけにルーティングを設定すると、本文は開くのに画像やAPIだけ失敗することがあります。その場合は開発者ツールやクライアントログで失敗したリソースのドメインを確認し、関連するサフィックスをルールへ追加します。すべての通信をプロキシへ送るよう、いきなり範囲を広げないでください。VMess、VLESS、Trojan、Shadowsocksの選び方についてはプロキシプロトコルの比較ガイドをご覧ください。プロトコルは接続方式を決め、ルーティングは接続をどのアウトバウンドへ送るかを決めます。両者を一つの設定として扱わないでください。

システムDNSとコアDNSを区別する

システムDNSは、OSと通常のアプリが標準で使う名前解決経路です。コアDNSは、XrayまたはV2Flyの設定にある名前解決モジュールで、主にクライアントへ入った接続、ルーティング判定、特定ドメインのポリシーに使われます。システムプロキシを有効にすると、アプリによってはシステム側で先に解決してから対象IPをプロキシへ渡し、別のアプリはドメインを保持したままプロキシ経由で問い合わせます。TUNを有効にすると、DNSリクエストがコアに横取りされることもあります。問い合わせ元を先に特定せずコアDNSだけを変更しても、実際の問題に影響しない場合があります。

調査では、ログに対象ドメインの名前解決記録が出ているか確認します。ブラウザーがすでにドメインをIPへ解決し、スニッフィングでも復元されていない場合、ルーティングからはアドレスしか見えず、ドメインルールに一致しない可能性があります。反対に、コアがドメインを受け取って解決しているなら、DNSサーバーの選択、問い合わせ種別、返されたアドレス、その後のルーティングを確認します。すべての解決失敗をサーバーのせいにしないでください。ドメインの入力ミス、システムキャッシュ、アプリ内蔵のセキュアDNS、ルーティングによるブロック、UDPの取り込み不足などでも似た症状が起こります。

DNSサーバーの役割を明確にする

保守しやすい設定は通常、少数のDNSサーバーだけを含み、それぞれの処理範囲が明確です。標準サーバーは一般的な問い合わせを処理し、指定サーバーは特定のドメインを処理し、必要な場合だけフォールバックを設定します。アドレスには従来のUDP DNSもHTTPSベースの問い合わせ先も使えますが、対応状況は現在のコアとクライアントの設定方式によって異なります。選択時は、同じ役割のアドレスを増やすより、現在のルーティングと互換性があり安定して接続できるサービスを優先してください。

DNSサーバー自体をドメイン名で指定すると、「DNSサーバーのドメインを先に解決する」という起動時の依存関係が発生します。一般的な解決策は、host マッピングを用意する、直接接続できるアドレスを使う、そのサーバーのドメイン解決用にブートストラップDNSを指定することです。カスタムアウトバウンドがある場合は、DNS問い合わせが直結かプロキシ経由かも確認します。問い合わせ経路と対象ドメインの通信経路は異なっていても構いませんが、その違いは明確な設計結果であるべきです。

{
  "dns": {
    "hosts": {
      "router.local": "192.168.1.1"
    },
    "servers": [
      {
        "address": "https://dns.example/dns-query",
        "domains": [
          "domain:example.com"
        ],
        "skipFallback": true
      },
      "1.1.1.1"
    ],
    "queryStrategy": "UseIP"
  }
}

例の hosts はローカルのドメイン固定マッピングに使い、domains を持つサーバーは一致する範囲だけを処理し、最後の項目を通常の問い合わせ経路にします。skipFallback は、そのサーバーに一致する問い合わせをフォールバック判定へ進ませないことを示し、結果の取得元を確定させたいドメインに適しています。例の dns.example は構造の説明用です。実際の設定では利用可能なサービスへ置き換えてください。ドメイン別の解決が不要なら、単純なサーバー一覧を使えます。設定が短いほど問題を特定しやすくなります。

問い合わせ種別とキャッシュを理解する

queryStrategy はIPv4、IPv6、または両方を問い合わせるかを制御します。ネットワーク環境に利用可能なIPv6経路がない場合、IPv6アドレスが返されても接続できず、待機後にフォールバックすることがあります。この場合は、ルーティングルールでIPv6をあちこち除外するのではなく、実際のネットワーク能力に応じてIPv4のみを問い合わせる設定を選べます。反対に、システムとアウトバウンドの両方でIPv6が安定して使えるなら、デュアルスタックを維持するほうが自然です。変更後は接続を作り直し、アプリ自身のキャッシュも消去して、古い結果に判断を左右されないようにします。

DNSキャッシュは重複した問い合わせを減らせますが、設定を変更しても新しい結果がすぐに現れないことがあります。v2rayNでコアを再起動すると、通常はコア側の状態が消去されますが、ブラウザーやOSにはキャッシュが残る場合があります。検証には、以前アクセスしていないサブドメインを使うか、キャッシュの有効期限が切れるまで待ちます。長時間開いた同じページを何度も更新して判断しないでください。ブラウザーが接続や解決結果を再利用したり、バックグラウンドサービスがリクエストを処理したりする可能性があります。

システムプロキシとTUNの取り込み範囲

システムプロキシは、OSのプロキシ設定に従うブラウザーやデスクトップアプリに適しています。設定が簡単で、無効化後の復旧も分かりやすい一方、一部のプログラムはシステムプロキシを無視し、UDP通信の処理能力もアプリに左右されます。TUNモードは仮想ネットワークインターフェースでより広い範囲のIP通信を受け取るため、コマンドラインツール、独自のネットワークスタックを持つアプリ、TCPとUDPをまとめて処理したい場面でよく使われます。取り込み範囲を広げると、LANアクセス、開発環境、仮想マシン、その他のネットワークツールとの関係も複雑になります。

TUNを有効にする前に、同じサーバーがシステムプロキシモードで正常に動作し、ルーティングルールがプロキシ、直結、ブロックを正しく区別できることを確認します。そうしないと、TUNによって既存の設定ミスがより多くのプログラムへ影響します。初回テストでは、仮想NICを作成したりデフォルトルートを変更したりする他のソフトを停止し、LANのサブネットとデフォルトゲートウェイを記録して、v2rayNでは基本的なTUN設定だけを有効にします。成功後、他のネットワークコンポーネントを一つずつ戻し、ルート競合が起きないか確認します。

仮想インターフェース、ルート、厳格モードを理解する

TUNを起動すると、クライアントは仮想インターフェースを作成し、システムルートを通じて対象通信をそのインターフェースへ送ります。自動ルートは必要なルート項目を書き込み、厳格ルートは仮想インターフェースを迂回する通信をできるだけ減らします。厳格モードは経路の一貫性維持に役立ちますが、LAN探索、コンテナネットワーク、特殊な仮想NICに影響することがあります。有効化後にプリンター、ルーター管理画面、開発機器へアクセスできなくなった場合は、まずLANアドレス用の直結ルールを残し、その後で厳格さを下げる必要があるか判断します。

MTUは、仮想インターフェースが扱えるパケットサイズを示します。大きすぎると経路によってはフラグメント化やパケット損失が発生し、小さすぎるとパケット数とオーバーヘッドが増えます。明確な根拠がない場合はクライアントの初期値を使います。典型的なMTU問題では、接続は確立するものの特定ページの読み込みが止まる、アップロードに失敗する、一部プロトコルだけ異常になるといった症状が出ます。調査時は数値を少しずつ下げて同じテストを繰り返せますが、毎回変更する段階は1つだけにし、サーバーやDNSが原因でないことも確認してください。

症状からTUN起動問題を切り分ける

TUNでインターフェースを作成できない場合は、まずログに権限、インターフェース名の競合、ドライバーコンポーネントの問題が示されていないか確認します。Windowsでは必要な権限を持つ方法で起動する必要がある場合があります。macOSとLinuxでは、クライアントによる仮想インターフェースの作成がシステムで許可されているか確認します。ログに権限不足が明記されている場合、サーバーを何度も切り替えないでください。サーバーはインターフェースの作成に影響しません。クライアントを再インストールする前に、ダウンロードページから対象プラットフォーム向けのバージョンを取得していることも確認してください。

TUNは起動するのにすべての接続が失敗する場合は、デフォルトルートが仮想インターフェースを指しているか、コアが通信を受け取っているか、DNSが利用可能か、プロキシアウトバウンドが誤って再びTUNへ入りループしていないかを確認します。クライアントは通常、自身の接続に除外または保護の仕組みを設定します。独自の起動方法、外部コア、複雑なルーティングによってこの関係が崩れることがあります。ログに同じ接続の繰り返しや、宛先がローカルの仮想アドレスになっている記録が大量に出る場合は、ループバックを優先して疑い、ルーティングルールをさらに増やさないでください。

LANだけに接続できない場合は、geoip:private または明示したプライベートネットワーク範囲が直結になっているか確認し、LAN共有設定で待ち受け範囲が変わっていないかも確認します。よくあるプライベートネットワークには 10.0.0.0/8、172.16.0.0/12、192.168.0.0/16 があります。企業や実験室のネットワークでは別のアドレス範囲を使うこともあるため、実際の環境に応じて追加してください。ローカルサービスをドメイン名で利用する場合はローカルDNSにも依存するため、IPの直結設定だけでは不十分です。

TUNを無効にしてもネットワークがすぐ復旧しない場合は、まずクライアントからコアを正常に停止し、次に仮想インターフェースとシステムのデフォルトルートが解除されたか確認し、最後に現在のネットワークへ再接続します。プロセスを直接終了するとクリーンアップが間に合わないことがあるため、日常的な終了方法にはしないでください。問題が続く場合はヘルプセンターで「クライアント終了後もネットワークに異常がある」場合の手順に沿って、システムプロキシ、仮想インターフェース、DNSを順に確認します。ブラウザーだけを再起動する方法に頼らないでください。

FakeDNSの動作

通常のDNS問い合わせでは、対象サーバーの実アドレスが返され、アプリはそのアドレスへ接続します。接続がコアに入った時点でIPしか残っていない場合、ドメインルーティングではスニッフィングに頼って元の名前を復元する必要があります。FakeDNSは専用アドレスプールから仮想アドレスを返し、コア内部に「ドメイン—仮想アドレス」の対応を保存します。アプリがその仮想アドレスへ接続すると、コアは対応表からドメインを復元し、ドメインルーティングと実際の名前解決を行います。重要なのはサーバー性能を高めることではなく、ドメインのコンテキストを保持することです。

FakeDNSは通常TUNモードと併用します。TUNがアプリから仮想アドレスへ向かう接続を受け取り、コアへ戻せるためです。FakeDNSだけを有効にしてDNSリクエストを正しく横取りできていない場合、アプリは別の解決経路から実アドレスを取得する可能性があります。DNSだけを横取りしても仮想アドレスの通信がコアに入らなければ、解決は成功するのに接続できない状態になります。DNSの問い合わせ入口、FakeDNSアドレスプール、TUNルート、コアのマッピングが一つの閉じた経路を形成する必要があります。

アドレスプールとマッピング容量

FakeDNSのアドレスプールには、ローカルLAN、企業ネットワーク、コンテナネットワーク、他の仮想インターフェースと競合しない予約範囲を選びます。クライアントのプリセットは通常、よくある状況を考慮しています。明確な競合がない限り、独自に変更しないことをおすすめします。競合すると、実在する社内ネットワークの一部へ接続できなくなったり、システムが仮想アドレスを誤ったインターフェースへ送ったりします。調査時はシステムのルーティングテーブルを確認し、FakeDNSのアドレスプールと既存ネットワークのルート範囲を比較します。

マッピング容量は、同時に保持できるドメイン記録の数を決めます。容量が小さすぎると古いマッピングが頻繁に置き換わり、多数のドメインを読み込む複雑なページで不整合が起きやすくなります。大きすぎても明確な利点はありません。通常はクライアントの初期値で十分です。アプリが古いDNS結果を長時間再利用すると、コアのマッピングが消去されても無効な仮想アドレスへ接続し続けることがあります。その場合はウェブページを何度も更新するのではなく、アプリの接続とコアを同時に再起動します。

{
  "dns": {
    "servers": [
      {
        "address": "fakedns",
        "domains": [
          "geosite:geolocation-!cn"
        ]
      },
      "1.1.1.1"
    ],
    "fakedns": [
      {
        "ipPool": "198.18.0.0/15",
        "poolSize": 65535
      }
    ]
  }
}

この例はFakeDNSの一般的な構造を示します。指定したドメイン分類には仮想解決を使い、それ以外の問い合わせは通常のDNSへ渡します。198.18.0.0/15 はこの種のマッピングによく使われるアドレス範囲ですが、適切かどうかはローカルネットワークを基準に判断してください。コアによって設定形式が異なり、fakedns の配置階層も変わります。v2rayNがGUIから関連フィールドを自動生成する場合もあります。断片を設定全体に直接上書きせず、クライアントが出力した現在の構造と照合してください。

優先的な有効化に向かない場面

ローカルDNSから社内アドレスを返す業務システム、LAN機器名、ドメイン別の名前解決環境では、FakeDNSの使用に注意が必要です。これらのドメインは通常、ローカルDNSへ渡して直結にし、仮想アドレスを返さないようにします。指定ドメインルール、ドメインサフィックス、ローカルhostsマッピングでFakeDNSを迂回できます。社内ドメインに安定したサフィックスがない場合は、まず実際の問い合わせ記録を集め、広すぎる除外条件ではなく明確なリストを作成してください。

DNSの返却アドレスを検証するアプリ、内蔵DNSを直接使うアプリ、キャッシュ期間が長いアプリ、接続中に対象アドレスを再比較するアプリがあります。こうしたアプリではFakeDNSとの連携が不安定になることがあります。特定のアプリだけに異常がある場合は、TUN全体を無効にするのではなく、関連ドメインに通常の名前解決を指定してください。ドメイン範囲で原因を特定できない場合は、FakeDNSを使わない基準状態へ戻し、仮想マッピングが原因か確認します。

FakeDNSとドメインスニッフィングは補完関係にありますが、無条件に両方を有効にしないでください。FakeDNSは管理対象のDNS問い合わせに対応を保持し、スニッフィングはマッピングを経由しなかったもののプロトコルからドメインを復元できる接続を処理します。スニッフィングを有効にする場合は、対象の上書き設定に注意してください。コアがスニッフィングしたドメインで元の宛先を置き換えると、ルーティング結果が変わる可能性があります。まずFakeDNSで主要なTUN通信を処理し、ログでIPしか表示されない接続が残る場合にだけスニッフィングの有効化を検討します。

ログでマッピング経路を検証する

検証には、まだキャッシュされていないドメインを選びます。DNSリクエストでFakeDNSが仮想アドレスを返すか確認し、その直後の接続記録に元のドメインが表示されるか確認します。続いてルーティングが一致したアウトバウンドタグと、実際の接続の成否を確認します。DNS記録だけがあり後続の接続がない場合、仮想アドレスがTUNに取り込まれていないか、アプリがすぐに接続を開始していない可能性があります。接続はあるのにドメインを復元できない場合は、マッピングが消去されていないか、同じコアインスタンスからのリクエストかを確認します。

各サブスクリプションに用途と優先度を定義する

複数のサブスクリプションがあるからといって、すべてのサーバーを一つの候補プールへ混ぜる必要はありません。より管理しやすい方法は、各購読に日常用、仕事用の予備、特定デバイス用、テスト用などの用途を定義し、別々のグループを作ることです。普段の選択は現在の用途のグループ内だけで行い、取得元を切り替えるときにグループを変更します。これにより同名サーバーの混乱を避け、自動選択が取得元をまたいで切り替わることによる結果の変化も減らせます。

サブスクリプション名には安定した情報を含め、サーバー数や更新時刻に依存させないでください。「用途—取得元の略称」の形式にし、メモには対応デバイス、自動更新の可否、特殊なルーティングパラメータの有無を記します。購読URLにアクセストークンが含まれる場合は、クライアントの購読設定だけに保存し、スクリーンショット、公開ログ、共有ドキュメントへコピーしないでください。自分の別デバイスへ渡す場合は管理された方法を使い、使用しなくなったデバイスから古い設定を削除します。

更新時刻をずらし、失敗時の状態を残す

すべてのサブスクリプションを同時に更新すると手順は減りますが、1つの取得元が失敗したときにログへ複数のリクエストが混在しやすくなります。初回設定やトラブルシューティング中は、1件ずつ更新することをおすすめします。グループを選択して更新し、返された内容を解析できることを確認してから次のグループを処理します。安定後は定期更新を使えますが、間隔を短くしすぎないでください。購読内容は通常、数分単位では変わらないため、頻繁すぎる更新はリクエストと一覧の再構築を増やすだけです。

更新に失敗しても、現在のグループをすぐ削除して追加し直さないでください。ネットワーク接続、URLの無効化、レスポンス形式のエラー、空の内容のどれに該当するか確認します。URLへアクセスできるのに解析に失敗する場合は、購読形式がクライアントの想定と異なる可能性があります。現在使用中のプロキシ経由だけで更新に失敗する場合は、更新に使うアウトバウンドを一時的に切り替えます。サブスクリプションの更新と通常のウェブアクセスでは設定が異なることがあるため、ログでリクエストが直結とプロキシのどちらから送信されたか確認してください。

更新結果が空だった場合は、クライアントの保持ポリシーが重要です。空のレスポンスで既存サーバーを直接上書きせず、取得元が復旧したことを確認してから更新するのが安全です。クライアントがすでにグループを空にしてしまった場合は、記憶で各サーバーを作り直すのではなく、設定バックアップから復元します。更新成功後も、プロトコル、アドレス、ポート、転送方式、セキュリティ層のフィールドが揃っているかを確認してください。サーバー名が表示されただけでは、すべてのフィールドで接続できるとは限りません。

重複項目と名前の競合に対処する

異なるサブスクリプションに同じサーバーが含まれ、別名も完全に一致することがあります。名前だけで重複排除すると設定の異なる項目を誤って削除する可能性があり、アドレスとポートだけで排除するとプロトコルやユーザー識別子の違いを見落とします。上流の内容関係を明確に把握していない限り、グループをまたいだ自動統合はおすすめしません。一覧の重複が多すぎる場合は、元の購読構造を壊さずグループ表示で非表示にできます。

統合した候補セットが本当に必要なら、元のグループを残したまま、よく使う項目だけを手動の厳選グループへコピーします。厳選グループは購読更新を自動継承しないため、上流の変更後に毎回確認が必要です。少数のサーバーを長期的に安定利用するには適していますが、すべてのサブスクリプションのミラーとしては不向きです。サーバーフィールドが変更されても古いコピーは自動修正されないため、手動グループで見落とされやすい保守コストになります。

自動選択と手動選択の使い分け

自動選択は、設定と用途が揃った候補セットに限定します。プロトコル、用途、取得元がまったく異なるサーバーを同じ自動選択セットへ入れると、選択が変わったときに接続能力とルーティング結果が同時に変わる可能性があります。高度な設定では、まずサーバーを手動で固定し、DNS、ルーティング、TUNを検証してから自動選択を有効にするほうが安全です。障害発生時に「アクティブサーバーがたまたま変わった」という変数を除外できます。

一度の遅延測定を長期的な順位付けの根拠にしないでください。ネットワーク経路は時間や接続状態で変わり、テストリクエストへの応答が速いサーバーがすべての用途に適しているとは限りません。接続の安定性、プロトコルフィールドの完全性、対象アプリの動作、切り替え後に既存接続の再確立が必要かどうかを同時に確認します。クライアント画面のグループ、サーバー一覧、ログの場所についてはv2rayNメイン画面の機能エリア早見表をご覧ください。

アウトバウンドはプロトコル、設定、タグで構成される

コアの各アウトバウンドには、少なくともプロトコル種別、プロトコル設定、ルーティングから参照するタグが含まれます。v2rayNは選択したサーバーから主要なプロキシアウトバウンドを生成し、通常は直結とブロックのアウトバウンドも生成します。カスタムアウトバウンドは、ローカルのSOCKSサービスへ接続したり、特殊な直結動作を指定したり、チェーン接続の一部として使ったりできます。用途にかかわらず、タグは一意で安定していなければなりません。ルーティングルール、DNSサーバー、他のアウトバウンドがタグを参照するためです。

カスタムアウトバウンドを追加する前に、通信経路を図にします。どのインバウンドが通信を受け、どのルールに一致し、カスタムアウトバウンドがどこへ接続し、そのアウトバウンド自身が別のプロキシを必要とするかを整理します。経路を1〜2文で説明できないなら、設定はすでに複雑すぎる可能性があります。チェーン接続は障害箇所を増やします。どこか一段でDNS、認証、待ち受けアドレス、ネットワークに問題があるだけで、最終接続は失敗します。末端だけを見るのではなく、各段階を個別に検証してください。

{
  "outbounds": [
    {
      "tag": "local-socks",
      "protocol": "socks",
      "settings": {
        "servers": [
          {
            "address": "127.0.0.1",
            "port": 1081
          }
        ]
      }
    },
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ]
}

この例では、ローカルの 127.0.0.1:1081 にあるSOCKSサービスを local-socks として定義し、直結とブロックのアウトバウンドを残します。使用前に、そのポートでサービスが実際に待ち受けており、接続がv2rayNの現在のインバウンドへ戻ってループしないことを確認してください。例には認証フィールドがありません。ローカルサービスに認証が必要な場合は、コアが対応するSOCKSサーバー構造に従って追加し、実際の認証情報を公開文書やスクリーンショットに表示しないでください。

限定した対象だけをカスタムアウトバウンドへ送る

新しいアウトバウンドを作成しても、すぐにグローバルのデフォルトにはしないでください。まずテストドメインだけに一致するルーティングルールを作り、outboundTag で新しいタグを指定します。ログにルールの一致が表示されたことを確認し、ローカルのSOCKSサービスが接続を受け取るか確認します。テストに成功したら、範囲を少しずつ広げます。ルールに一致しない場合は条件または順序の問題です。一致するのにローカルサービスへ接続されない場合は、アウトバウンドのアドレス、ポート、ループを確認します。ローカルサービスが接続を受け取るのに最終的に失敗する場合は、次の経路を調べます。

{
  "type": "field",
  "domain": [
    "full:test.example.com"
  ],
  "outboundTag": "local-socks"
}

アウトバウンドタグの名前を変更したら、すべての参照箇所も同期して更新する必要があります。見落としやすい箇所には、ルーティングルール、DNSサーバーの outboundTag、プロキシチェーンの proxySettings、クライアント画面に保存されたカスタムテンプレートがあります。コアの起動時に「タグが見つからない」と表示されたら、outbounds配列だけでなく生成された設定全体を検索します。クライアントが起動のたびに設定を再生成する場合、一時的なJSONを直接編集しても次回の設定適用で失われます。長期利用する設定は、クライアントが提供するカスタム設定の入口を優先してください。

設定ファイルの検証方法

保存前にJSON構文を確認します。オブジェクトと配列の括弧が対応しているか、最後のメンバーの後に余分なカンマがないか、文字列が二重引用符で囲まれているかを確認してください。構文が正しくても、ファイルを解析できることしか意味しません。現在のコアがフィールドに対応しているかも確認が必要です。起動後はログの冒頭で設定の読み込み結果を確認します。コアがすぐ終了する場合、最初のエラーにフィールドのパスやタグ名が示されることが多くあります。1つのエラーを修正して再読み込みしてください。後続のエラーは、前のエラーに隠れていた結果かもしれません。

設定が起動できたら、「インバウンド—ルーティング—アウトバウンド—対象」の順に検証します。まずテスト接続が想定したインバウンドに入ることを確認し、次にルーティングが対象タグに一致すること、続いてアウトバウンドが確立すること、最後にアプリの動作を確認します。DNS関連のアウトバウンドでは、名前解決リクエストがそのタグを使っているかも個別に確認します。ブラウザーのページが開くかだけを唯一の判断材料にしないでください。キャッシュ、接続の再利用、アプリのフォールバックが設定問題を隠すことがあります。

長期的なメンテナンスコストを抑える

長期利用できる高度な設定は、3つの問いに答えられる必要があります。各カスタムルールがなぜ存在するのか、どのグループまたはアウトバウンドに依存するのか、失敗時にどう戻すのかです。ルール名やローカルの説明に用途を記録し、接続に関する機密情報は記録しないことをおすすめします。定期的に、使わなくなったサブスクリプション、重複サーバー、無効なフィルター語、期限切れのドメイン例外、参照されていないアウトバウンドタグを確認します。削除前にまず無効化して様子を見て、隠れた依存関係がないことを確認してから完全に整理します。

クライアントとコアを更新した後、すべての古い設定をすぐに調整し直さないでください。まず元の設定で基本接続を確認し、画面に追加・変更された項目を確認します。特にTUN、DNS、ルーティングデータ、設定生成方式を重点的に見ます。問題が起きた場合は、本章の冒頭で作成した基準状態から段階的に戻します。v2rayNはデスクトッププラットフォームの第一候補です。Androidではコアの要件に応じてv2rayNGまたはv2flyNGを選択できます。3つのクライアントの入口とプラットフォーム別の説明はクライアントダウンロードページにまとめています。

特定の問題が1台のデバイスだけで発生する場合は、取り込み方式、システムDNS、LANサブネット、アプリのプロキシ動作を比較し、最初からサブスクリプションの内容が違うと決めつけないでください。複数デバイスに同じ購読をインポートしても、サーバーの取得元が近くなるだけで、ローカルルーティング、TUN権限、システムプロキシ、DNSキャッシュは同期されません。デバイス側の変数を一覧にして一つずつ比較するほうが、購読を何度もインポートするより効果的です。

高度な設定の目的は、設定ファイルを際限なく長くすることではなく、通信経路を実際の要件に合わせることです。クライアントのプリセットで解決できる問題には、まずプリセットを使います。ログとテストで不足する範囲が明確になった場合だけ、対象を絞ったルールを追加します。変更範囲を小さく保ち、タグの意味を明確にし、検証手順を固定すれば、サブスクリプション、ネットワーク環境、利用シーンが変わっても、調整すべき層をすぐに見つけられます。