V2Ray 詳細設定
体系的な設定ガイド

設定の階層と変更の順序

詳細設定でよくある問題は、特定のパラメーターの誤りではなく、異なる階層の役割を混同してしまうことです。たとえば、サーバーの絞り込みはクライアントの一覧から選びやすい項目を決めるだけで、ブラウザーの通信がプロキシを通るかどうかを直接決めるものではありません。ルーティングルールはカーネルに入った接続を複数のアウトバウンドへ振り分けますが、システムプロキシに従わないアプリを取り込むことはできません。TUNは取り込み範囲を広げられますが、誤ったDNSサーバーや無効なノードを自動的に修正するわけでもありません。設定を入力、選択、取り込み、名前解決、判定、アウトバウンドの6層に分けると、トラブル対処の経路を大幅に短縮できます。

入力からアウトバウンドまでの完全な経路

入力層にはサブスクリプションURL、個別の共有リンク、手動設定が含まれます。クライアントがサブスクリプションを更新すると、リモートの内容がローカルのサーバー項目に変換されます。選択層は現在のアクティブサーバー、サーバーグループ、絞り込み結果を管理します。取り込み層は、どのアプリの通信をカーネルへ入れるかを決めます。システムプロキシは通常、システムプロキシ設定に従うプログラムを対象とし、TUNは仮想ネットワークインターフェースを通じてより広いIP通信を受け取ります。名前解決層がドメインをアドレスへ変換し、ルーティング層がドメイン、アドレス、ポート、プロトコルなどの条件でルールを照合します。最後に、プロキシ、直接接続、ブロック、自作アウトバウンドのいずれかで接続が完了します。

この経路には明確な順序があります。ブラウザーがシステムプロキシを利用していなければ、ルーティングルールを調整しても結果は変わりません。DNSがOS側ですでに解決されている場合、ドメインルールだけでは期待どおりに一致しないことがあります。ルーティングがプロキシアウトバウンドに一致しても、現在のサーバーが利用できなければ接続は失敗します。したがって変更のたびに、変更はどの層で起きたのか、また有効になったことを示す観察点は何かを確認してください。検証点と変更層を対応させて初めて、複数の項目を同時に変更して原因が分からなくなる事態を避けられます。

フォールバック可能な設定の基準を作る

詳細設定を始める前に、正常に接続できる基準設定を1つ保存してください。複雑である必要はありません。検証済みのサーバー、デフォルトルーティング、明確なDNS設定、現在使用しているシステムプロキシまたはTUNの状態を残します。その後は、一度に1つのテーマだけを変更します。たとえば、まず購読グループを設定し、サーバー選択に影響がないことを確認してからルーティングへ進みます。クライアントに設定のバックアップやエクスポート機能があれば、重要な段階でスナップショットを保存してください。画面の項目、ルールの順序、テスト結果を記録しておくと、記憶だけに頼らず復元できます。

基準設定の検証では、1つのWebページだけをテストしないでください。少なくとも、直接接続になる想定のドメイン、プロキシ経由になる想定のドメイン、純粋なIP接続、DNS問い合わせを1つずつ含めます。テスト結果から、「クライアントに入っていない」「入った後のルーティングが誤っている」「DNSの応答に問題がある」「選択したサーバーが利用できない」を区別できる必要があります。Windowsではタスクマネージャー、システムプロキシ設定、クライアントログを組み合わせて確認できます。macOSとLinuxでは現在のルート、プロキシ設定、名前解決の状態を確認します。Androidのv2rayNGまたはv2flyNGでは、接続ログ、仮想ネットワークの許可状態、対象アプリの動作を主な判断材料にします。

クライアントの画面名はバージョンやプラットフォームによって多少異なりますが、基本的な関係は変わりません。v2rayNはデスクトップ環境で優先的に使える管理クライアントで、サブスクリプション、ルーティング、アウトバウンドの一元管理に適しています。Androidではv2rayNGがXrayカーネル系を使い、v2flyNGはV2Flyカーネルを主な選択肢とします。プラットフォーム間で移行するときは、メニューの位置やすべてのフィールドが同じだと考えず、「設定の意図」を移行してください。まず対象プラットフォームが必要な機能に対応していることを確認し、層ごとに設定を再構築するほうが、大きな設定をそのままコピーするより互換性の境界を見つけやすくなります。

購読グループとサーバーの絞り込み

購読項目が増えたとき、使いやすさを左右するのは一覧の長さそのものではなく、現在の目的に合うサーバーを安定して見つけられるかどうかです。グループはサーバーの長期的な所属先を定義し、絞り込みはその時点の候補を狭めます。両者は分けて設計してください。グループは提供元、用途、管理範囲を表し、絞り込みは名前の一致条件を表します。絞り込み結果を恒久的な分類として扱うと、購読側の名前変更で機能しなくなりやすくなります。すべての項目を1つのグループに詰め込むと、更新、速度測定、トラブル対処が互いに干渉します。

提供元別か用途別か

提供元別のグループは最も管理しやすい方法です。各購読URLに1つのグループを割り当てれば、更新に失敗したときに出所を直接特定でき、他の項目に影響を与えずに特定の購読を取り消せます。用途別グループは、日常の閲覧、開発・テスト、臨時の予備など、安定した命名規則がある環境に向いています。実際には2段階で考えるとよいでしょう。下位層では提供元の境界を保ち、上位層では絞り込みやお気に入りで用途ごとの表示を作ります。これにより項目の出所を追跡しながら、日常の選択時に表示される情報量を減らせます。

グループ名は安定していて短く、見分けやすいものにしてください。更新日や一時的な状態を長期的な名前に含めるのは避けます。更新日はログ情報であり、回線の状態は実際の接続テストで判断すべきです。複数の購読に同名サーバーがある場合は、取り込み時に提供元の接頭辞を加えるか、グループで出所を区別します。サーバー名にラベルを詰め込みすぎないでください。名前が複雑になるほど正規表現の誤一致が起こりやすく、購読元が命名規則を変更したときの互換性も低下します。

保守しやすい絞り込み式を作る

サーバーの絞り込みは通常、備考名に対するテキスト検索または正規表現で行います。まずは安定したキーワードを1つだけ指定し、必要に応じて同義の表記を追加してください。正方向の絞り込みは、大量の項目から特定地域、用途、回線識別子を選ぶのに適しています。反方向の絞り込みは、テスト項目、期限切れの印、明らかに対象外のアーキテクチャを除外するのに向いています。「何文字目」といった壊れやすい位置に依存せず、安定した単語全体や区切り文字を使うべきです。

よく使う絞り込みの考え方：

次のいずれかのキーワードを含む：
(オフィス|開発|予備)

名前の先頭にある提供元マーカーに一致：
^(提供元A|提供元B)[-_ ]

一時的または期限切れのマーカーを含む項目を除外：
^(?!.*(一時的|期限切れ)).*$

2つの条件を同時に要求：
^(?=.*開発)(?=.*TCP).*$

正規表現では、括弧がグループ、縦線が複数候補、ドットとアスタリスクの組み合わせが任意の長さの文字列を表します。先読みは条件の要求や除外に利用できます。式を入力する前に、クライアントの該当欄で正規表現モードが有効になっているか確認してください。通常のテキスト検索では、特殊記号がそのまま文字として扱われます。絞り込み後は一覧の先頭・末尾と境界にある名前を目視で確認し、同音語、略称、入れ子になった語を誤って含めていないか確認します。

絞り込み結果を接続品質の判断に使わないでください。名前は購読元が付けたラベルを示すだけで、リアルタイムの利用可能性や現在のネットワーク経路を証明するものではありません。候補を絞った後は、基本的な疎通だけでなく実際の接続テストを行います。実際の対象へアクセスしてハンドシェイク結果を確認してください。すべて失敗する場合は、まず絞り込みを解除して元の一覧が正常か確認し、「式に一致する項目がない」のか「一致した項目自体が接続できない」のかを切り分けます。

更新後も選択状態を安定させる

サブスクリプションの更新では、項目の追加、削除、名前変更が起こります。現在選択中のサーバーが削除された場合、クライアントが別の項目へ戻ることもあれば、使えなくなった古い参照を保持することもあります。更新後は、現在の選択が対象グループに属しているか確認し、実際の接続をもう一度実行してください。固定用途の設定で一覧の番号だけに依存するのは避けます。並び順が変われば、以前の1番目が別のサーバーになるためです。より安全なのは、固有で安定した命名規則を使うか、更新後にアクティブな項目を手動で確認する方法です。

絞り込み条件で突然一覧が空になったら、まず絞り込み前の元グループを確認します。元グループも空なら、問題はサブスクリプションの更新または解析にあります。元グループに項目があるのに絞り込み結果だけ空なら、名前の変更または式に問題があります。結果はあるのに接続できない場合に初めて、ノード、ネットワーク、DNS、転送設定を疑います。この3つの分岐を分けて処理すれば、一覧が空だからといってルーティングやTUNを誤って変更せずに済みます。初回選択と実際の接続テストの順序については、v2rayNの初回接続手順も参照してください。

グループルールが成熟したら、短い運用ルールとして文書化してください。各提供元にどの接頭辞を使うか、用途の絞り込みに許可するキーワード、一時的なラベルとして除外するもの、更新後に行う確認を定めます。この取り決めは複雑な式そのものより重要です。後から購読を追加しても同じ構造に入れられるからです。作成者にしか理解できないルールでは、名前の変化とともにグループがすぐに乱雑な一覧へ戻ってしまいます。

複数購読の管理と更新範囲

複数購読の目的は、より多くのURLをまとめて取り込むことではなく、提供元ごとに識別・停止・復元できる境界を保つことです。購読ごとに更新周期、命名方法、サーバーフィールドが異なる場合があります。すべての提供元を識別情報のない一覧へ混ぜると、重複項目、一括無効化、名前の衝突が起きたとき、どの入力を直すべきか判断できません。適切な複数購読構成では、まず提供元の分離を保証し、その後で統一的な絞り込みと日常の使いやすさを考えます。

提供元ごとに独立したライフサイクルを作る

新しい購読を追加するときは、用途、提供元識別子、想定する更新方法を記録してから初回更新を実行します。更新成功は、クライアントが内容を取得して解析できたことを示すだけです。サーバー数の変化、主要フィールド、少なくとも1つの実際の接続を確認してください。特定の提供元に一時的な異常がある場合は、すぐに削除せず、まずその提供元を無効化するか自動更新を一時停止します。停止なら既存の設定とトラブル対処の手掛かりを残せます。使用しないことを確認してから削除すれば、誤操作からの復元コストを抑えられます。

自動更新の間隔は、頻繁さだけを追求しないでください。更新が多すぎると不要なリクエストが増え、作業中に使用中の一覧が変化する可能性もあります。安定した提供元は、確認しやすい固定時間帯に更新するとよいでしょう。一時的な提供元は手動更新にしても構いません。起動時更新に対応している場合は、起動頻度とネットワーク環境を考慮します。端末が起動するたびに更新すると状態が頻繁に変わり、長期間再起動しなければ変更を見逃します。重要なのは統一された間隔ではなく、いつ更新され、更新後に検証したかを把握することです。

重複項目と名前の衝突に対処する

異なる購読に同じサーバーが含まれることもあれば、名前だけが同じで実際のパラメーターが異なることもあります。備考名だけで重複と判断してはいけません。アドレス、ポート、プロトコル、転送方式、セキュリティ設定、サーバー識別子などの主要フィールドを比較します。名前が同じでも転送パラメーターが異なる2項目は、異なる入口を担っている可能性があります。名前が違っても接続フィールドが完全に同じなら、異なる提供元による重複公開かもしれません。重複を残すと選択時のノイズが増えますが、安易に統合すると更新元の情報を失う可能性があります。

安全な方法は、提供元ごとのグループを維持し、日常用途の表示では主要項目を1つだけ絞り込むかお気に入りにすることです。主要な提供元の更新に失敗しても、別の提供元へ戻って同種の設定を確認できます。名前を変更する場合は、クライアントのローカル備考機能を使い、購読内部の主要フィールドを直接変更しないでください。次回更新時にローカル名が保持されるかはクライアントのマージ方式によります。変更前に更新動作を確認し、上書きされる可能性がある手動名だけに重要な分類を依存させないでください。

更新失敗を層別に判断する

サブスクリプションの更新に失敗したら、まず取得失敗と解析失敗を区別します。取得失敗では、接続を確立できない、返却ステータスが異常、タイムアウトになるといった症状が出ます。サブスクリプションURLが完全か、現在のネットワークからアクセスできるか、システムプロキシがループを形成していないかを確認してください。解析失敗は、内容を取得できたもののクライアントが想定する形式ではない状態です。Webページの案内が返った、エンコード内容が変わった、購読タイプの選択が合っていない、といった可能性があります。返却形式を確認せずに何度も更新しないでください。リクエストを繰り返しても形式の問題は直りません。

サブスクリプションURLがプロキシ有効時にしかアクセスできない場合は、更新リクエストがどのアウトバウンドを通るかを明確にしてください。設定によっては、クライアント自身のサブスクリプション更新が現在のプロキシを経由します。アクティブなサーバーが無効だと、「新しい項目を取得するには更新が必要だが、更新には古い項目が必要」という循環が起こります。一時的に利用可能な提供元を選ぶ、サブスクリプション更新のプロキシ方針を調整する、直接接続できる環境で更新する、といった方法で対処します。変更後は元の方針へ戻し、理由を記録して次回の更新で同じ問題が起きないようにしてください。

サブスクリプション形式の違いも、複数提供元の統合に影響します。Base64リスト、個別の共有リンク、ネイティブJSON設定では、保持できる情報の範囲が異なります。変換時にルーティング、DNS、自作アウトバウンドなどの全体設定が失われることがあります。サーバー購読は主にサーバー項目の配布に使い、クライアント全体のルーティングとDNSはローカル設定で管理してください。個別の共有リンクだけでクライアント全体のポリシーを完全に表現できるとは考えないでください。形式の境界と変換されるフィールドについては、V2Rayサブスクリプション形式ガイドを参照してください。

成熟した複数購読構成は、3つの問いに答えられる必要があります。あるサーバーはどこから来たのか、ある提供元が失敗したときどの用途に影響するのか、復旧後にどう検証するのか、です。長期間停止している提供元は定期的に整理することをおすすめします。ただし整理前に必要な設定をエクスポートし、ルーティングルールやお気に入りがその名前に依存していないことを確認してください。端末間で移行するときは、まず提供元とグループ、次に用途別の絞り込み、最後にルーティングと自作アウトバウンドを移行します。基本項目が安定してから高度な設定を戻すことで、入力の問題と高度なポリシーの問題を明確に分離できます。

ルーティングルールの実践と一致順序

ルーティングルールは、カーネルに入った接続のアウトバウンドを選択するためのものです。一般的な条件には、ドメイン、宛先IP、ポート、ネットワーク種別、プロトコル、プロセス情報があります。結果には、プロキシ、直接接続、ブロック、自作アウトバウンドなどがあります。通常、ルールは決められた順番で照合され、実行可能なルールに一致すると下位のルールへ進みません。したがってルーティング設定の要点はルール数ではなく、条件が互いに適切に分離されているか、順序が明快か、デフォルトの通信が最終的にどこへ向かうかです。

結果を先に定義してから条件を書く

ルールを書く前に、期待する結果を列挙します。たとえば、LANとローカルアドレスは直接接続、明確な業務ドメインは指定プロキシ、特定の更新サービスは直接接続、それ以外はデフォルトプロキシとします。結果を明確にしてから、各通信種別に最も安定した判定条件を選びます。ドメインルールは読みやすい一方、カーネルがドメイン情報を取得できることが前提です。IPルールはアドレス範囲が安定した対象に適しています。ポートルールは範囲が広いため、通常は補助として使います。プロセスルールはプラットフォーム差があり、すべての端末へそのままコピーするのには向きません。

広い条件は具体的な条件の後ろに置きます。最初のルールですべてのTCPとUDPをプロキシへ送ると、後続のLAN直接接続ルールは機能しません。反対に、広すぎるドメインサフィックスの直接接続ルールを先に置くと、本来プロキシへ送るべきサブドメインが先に直接接続されることがあります。順序を調べるときは、対象ドメインだけを一時的に先頭へ置き、識別しやすいアウトバウンドを指定します。一致を確認したら他のルールを少しずつ戻し、どのルールが上書きしているかを確認します。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "full:docs.example.com",
          "domain:example.net"
        ],
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

例では、full:は完全なドメイン一致、domain:は通常そのドメインとサブドメインを含む一致、geoip:privateはプライベートアドレス範囲の識別に使います。最後のネットワークルールがデフォルト出口を担うため、具体的なルールの後ろに置く必要があります。例のドメインは構造の説明用です。実際の設定では制御したい対象へ置き換えてください。クライアントがGUIのルーティングエディターを使う場合は、同じ条件を対応するフィールドへ分けて入力し、完全なJSONを受け付けない欄へそのまま貼り付けないでください。

ドメイン方針と名前解決のタイミングを理解する

domainStrategyは、ドメインルールに一致しなかったとき、IPを解決してIPルールを試すかどうかを決めます。AsIsは元のドメインを保持して照合する傾向があり、ルーティングのために積極的な名前解決は行いません。IPIfNonMatchはドメインルールに一致しなかった場合に解決し、IPの確認を続けます。カーネルによっては、さらに積極的な名前解決方針もあります。積極的な方針ほどIPルールの対象範囲は広がりますが、DNS問い合わせが増え、名前解決の経路がルーティング結果へ直接影響しやすくなります。

アプリが自分でドメインを解決し、宛先IPだけをカーネルへ渡す場合、ドメインルールは元の名前を取得できません。TUNのスニッフィング、FakeDNS、アプリプロキシ方式によって、ドメイン情報が見えるかどうかは変わります。「ドメインルールは正しいのに一致しない」ときは、まずログで対象がドメインとIPのどちらとして表示されているかを確認してください。そのうえで名前解決方針の変更、適切なスニッフィングの有効化、IP条件の追加を判断します。ドメインサフィックスをむやみに増やしても、カーネルがドメインを取得できない問題は解決しません。

最小限のルールセットを作り、段階的に拡張する

まずは、プライベートアドレスを直接接続、少数の明確な対象を必要に応じて振り分け、それ以外をデフォルトアウトバウンドへ送る3段構成から始めることをおすすめします。安定したら、更新サービス、開発環境、特定プロセスのルールを追加します。ルールを1組追加するたびに、正方向と反方向のテストを用意してください。つまり、一致すべき対象と、一見似ているものの一致してはいけない対象を1つずつテストします。たとえばdomain:example.netを設定したら、ルートドメイン、1つのサブドメイン、名前に似た文字列を含む別ドメインを同時に確認します。

ルーティングのトラブル対処では、接続ログの対象、ヒットしたルール、アウトバウンドラベルを優先して確認します。ログに接続失敗しか表示されずルール情報がない場合は、テスト中だけクライアントのログレベルを一時的に上げ、終了後に戻してください。正しいアウトバウンドに一致しているのに失敗するなら、問題はすでにルーティング層の外にあります。サーバー、DNS、転送接続を確認してください。対象がログにまったく現れない場合は、システムプロキシ、TUN、アプリ独自のプロキシ設定を先に確認します。

システムプロキシ、グローバルモード、ルールベースの振り分けは、それぞれ異なる次元を制御します。システムプロキシは一部のアプリがリクエストをクライアントへ渡すかどうかを決め、ルーティングモードはカーネルが接続を受け取った後の出口を決めます。両者の関係を再確認する場合は、V2Rayのシステムプロキシの選び方を参照してください。ネットワークによってルールの結果が変動するときは、DNSが返すアドレスも確認します。IP範囲に依存するルールは、名前解決結果の変化によって別の出口に一致することがあるためです。

DNS設定の最適化と名前解決経路

DNS設定で重要なのは、サーバーアドレスを単純に置き換えることではありません。誰が問い合わせを開始し、どのアウトバウンドを通り、どの層が返却結果を使うのかを明確にすることです。OS、ブラウザー、クライアントカーネル、リモートサーバーが名前解決に関与する場合があります。同じドメインが複数の層で重複して解決されると、得られるアドレスが変わり、ルーティング判定も変化します。DNSを最適化する前に問い合わせ経路を図にし、ローカル解決、カーネル解決、リモート解決の境界を明確にしてください。

システムDNSとカーネルDNSを区別する

システムDNSは、クライアントに取り込まれていない通常のプログラムに使われ、アプリがプロキシへ入る前に解決を完了することもあります。カーネルDNSは、ルーティング、TUN、カーネル自身の接続に使われます。システムプロキシモードでは、ドメインプロキシに対応するアプリがドメインを直接プロキシカーネルへ渡す場合もあれば、ローカルで先に解決する場合もあります。動作はアプリとプロキシ方式によって異なります。TUNモードではDNS通信を捕捉できる機会が増えますが、DNSハイジャック、ルーティング、除外項目を正しく設定する必要があります。

診断時にOSのDNSだけを変更してWebページを確認するのは避けてください。システムの問い合わせとクライアントログを分けて確認します。Windowsではipconfig /flushdnsでシステムキャッシュを消去し、nslookupまたはPowerShellで問い合わせます。macOSではscutil --dnsでリゾルバーの順序を確認できます。Linuxでは環境に応じてresolvectl statusで現在の上流を確認します。キャッシュ消去は古い結果を切り分けるためのもので、恒久的な解決策ではありません。

Windows:
ipconfig /flushdns
nslookup docs.example.com

macOS:
scutil --dns
dscacheutil -q host -a name docs.example.com

Linux:
resolvectl status
resolvectl query docs.example.com

ドメイン別にDNSサーバーを選ぶ

複雑な環境では、ドメインごとに異なるDNSサーバーを選べます。LAN内のドメインはローカルリゾルバー、パブリックドメインは通常の上流、特定の対象はプロキシアウトバウンド経由で問い合わせます。DNSを振り分けることで、内部名を解決できる状態を保ち、外部問い合わせの経路をルーティングの意図に合わせられます。設定では具体的なドメインルールを先に置き、デフォルトサーバーを後ろに置いて、デフォルト項目による先取りを防ぎます。LANのリゾルバーには明確なアドレス範囲も設定し、誤ってプロキシ経由でアクセスされないようにします。

{
  "dns": {
    "hosts": {
      "router.internal": "192.168.1.1"
    },
    "servers": [
      {
        "address": "192.168.1.1",
        "domains": [
          "domain:internal"
        ],
        "skipFallback": true
      },
      "1.1.1.1",
      "8.8.8.8"
    ],
    "queryStrategy": "UseIP"
  }
}

hostsは少数の固定マッピングに適しており、頻繁に変わる大規模なドメイン集合の管理には向きません。domainsを持つサーバーは一致する範囲だけを処理し、skipFallbackは失敗時に他の候補へ進むかどうかを制御します。queryStrategyは問い合わせるアドレス族の傾向を決めるため、IPv4またはIPv6接続が現在のネットワークで安定しているかを考慮して選択します。対応するアドレス族が利用できないのに、その種類だけを強制すると、ドメインは見えるのに接続が常にタイムアウトすることがあります。

キャッシュ、フォールバック、問い合わせループ

DNSキャッシュは重複問い合わせを減らしますが、設定変更後も古い結果が残ります。DNSサーバー、ドメインルール、FakeDNSを変更したら、OSキャッシュ、ブラウザーキャッシュ、カーネルキャッシュを同時に考慮してください。プロキシを停止して再起動しても、すべての層が消去されるとは限りません。テストでは、これまで問い合わせていないサブドメインを使うか、プラットフォームに応じて関連キャッシュを消去します。消去直後だけ正常で再び異常になる場合は、複数のリゾルバーが異なる結果を順番に返していないか確認します。

フォールバックの境界は明確にしてください。デフォルトサーバーが失敗したときに予備へ切り替えると可用性は上がりますが、サーバーごとに異なる振り分け意図がある場合、無条件のフォールバックで内部ドメインが不適切な上流へ送られたり、ルーティングと合わないアドレスが返されたりします。内部ドメインは通常、パブリック上流へのフォールバックを禁止します。一般的なパブリックドメインには順序を指定した候補を設定できます。フォールバックの発生を判断するときは、最終アドレスだけでなく、ログに記録された実際の問い合わせサーバーも確認してください。

問い合わせループは、DNSリクエストがプロキシへルーティングされ、プロキシサーバーのドメイン自体も同じプロキシDNSを必要とするときに起こりやすくなります。対策は、サーバーアドレスの起動経路を用意することです。既知のIPを優先する、サーバードメイン専用に直接アクセス可能なリゾルバーを指定する、該当DNSリクエストを現在のプロキシに依存しないアウトバウンドへ送る、といった方法があります。変更時には最小限の直接接続による名前解決能力を残してください。そうしないとクライアントは起動段階でプロキシサーバーのアドレスを取得できません。

接続速度が遅くなったり、一部のドメインで断続的に失敗したりするとき、DNSは原因の1つにすぎません。サーバーの状態、ネットワーク回線、プロキシモード、ローカルリソースの使用率も同時に確認し、すべての変動を名前解決のせいにしないでください。V2Rayの速度低下を層別に診断する手順に沿って、まず障害層を特定してからDNSを調整します。設定最適化の基準は、経路を説明でき、結果を再現できることです。上流サーバーをできるだけ多く並べることではありません。

TUNモードの取り込み範囲と除外項目

TUNモードは仮想ネットワークインターフェースでシステム通信を受け取るため、システムプロキシに従わないアプリ、独自のネットワークスタックを使うアプリ、より多くのUDP通信を処理する必要があるプログラムに適しています。TUNが変えるのは通信をクライアントへ入れる方法であり、購読の選択、DNS、ルーティングを自動的に置き換えるものではありません。TUNを有効にすると、これまでログに現れなかったアプリがカーネルで処理されるようになり、誤ったルーティングやDNSの問題も目立ちます。使用前に通常のプロキシモードで安定接続できることを確認し、その後で取り込み範囲を広げてください。

システムプロキシとTUNの選択

日常の閲覧やシステムプロキシ設定に従うデスクトップアプリでは、通常はまずシステムプロキシを使います。設定が簡単で、影響範囲も管理しやすいためです。アプリがシステムプロキシを無視する、特定のUDP接続を取り込む必要がある、アプリごとの差異をまとめて処理したい、といった場合にTUNを検討します。Webサイトが開けないというだけで、すぐTUNへ切り替えないでください。原因がサーバーの利用不能や誤ったルーティングなら、取り込み方式を変えることで新しい変数が増えるだけです。対象リクエストがすでにクライアントログに現れているかを先に確認し、現れているなら問題は通常、取り込み層にはありません。

TUNは仮想インターフェースを作成し、システムルートを調整するため、Windows、macOS、Linuxでは異なる権限やネットワークコンポーネントが関係します。v2rayNの画面にはプラットフォームに応じた入口が表示されるため、権限に関する案内はシステムの指示に従って完了してください。Androidではv2rayNGとv2flyNGがシステムの仮想ネットワーク許可を通じて通信を取り込み、デスクトップとは動作や設定入口が異なります。プラットフォーム間で参照するときは、取り込み対象、DNSの流れ、除外ルールを比較し、端末名やインターフェース番号をそのまま移さないでください。

ルートテーブル、MTU、ネットワークループ

TUNを有効にすると、クライアントはシステムルートを追加または調整し、対象通信を仮想インターフェースへ入れます。デフォルトルート、物理NICのルート、仮想インターフェースの優先順位が衝突すると、接続の折り返し、LANへの到達不能、クライアント自身のサーバー通信が再びTUNへ入るといった問題が起こります。トラブル対処ではまずシステムのルートテーブルを確認し、プロキシサーバーのアドレス、LANアドレス、DNS上流への経路を確認します。プロキシサーバーへの接続は物理ネットワークインターフェースから送信できなければならず、同じTUNに再び取り込まれてはいけません。

MTUは、インターフェース上の1つのネットワークパケットが持てる最大サイズを決めます。大きすぎると経路によっては断片化やパケット損失が起こり、小さなリクエストは正常でも大きなページやファイル転送が止まることがあります。小さすぎるとパケット数とオーバーヘッドが増えます。ハンドシェイクは正常なのに継続的な転送だけが異常な場合はMTUを確認項目にできますが、根拠なく変更しないでください。まず異なるネットワーク、対象、プロトコルでの挙動を比較し、その後に少しずつ調整して結果を記録します。

ネットワークループは、アプリ独自のプロキシとTUNが同時に有効な場合にも起こります。あるプログラムがローカルプロキシポートを手動設定すると、接続がローカルプロキシへ入り、そのプロキシアウトバウンドがTUNに捕捉され、除外ルールが不完全なら再び取り込まれます。対処では入口を1つに決めます。アプリにローカルプロキシを使わせてクライアントプロセスを除外するか、アプリの手動プロキシを解除してTUNに直接取り込ませます。クライアントのコアプロセス、更新リクエスト、必要なローカル待受アドレスは通常、明示的に除外する必要があります。

LANと重要プロセスを除外する

LANプリンター、ファイル共有、ルーター管理、ローカル開発サービスは通常、直接接続のままにします。ルーティング層ではプライベートアドレスのルールで直接接続を指定でき、TUN層には迂回アドレスやアプリ一覧が用意されている場合があります。2層のルールは一致させてください。TUNが取り込み前にアドレス範囲を除外すると、カーネルルーティングには接続が見えません。TUNが取り込んだ後にカーネルで直接接続する場合は、ログで一致結果を観察できます。どちらを選ぶかは、対象通信を記録・制御する必要があるかで決まります。

プロセス除外は、クライアント自身のループや明確に取り込みたくないアプリへの対処に適しています。ただしプロセス名はランチャー、子プロセス、プラットフォームによって変わることがあります。メインプログラムだけを除外しても、作成されたネットワークサービスまで対象外になるとは限りません。まずアドレスとルーティングの境界で対処し、プロセス除外は補助として使うほうが安定します。アプリ更新後に取り込み動作が変わったら、古い名前がまだ有効だと決めつけず、実際にネットワーク接続を開始したプロセスを再確認してください。

TUNの障害は、「インターフェースが作成されたか、ルートが書き込まれたか、DNSが想定経路に入ったか、対象がルールに一致したか、アウトバウンドが接続できるか」の順に確認します。TUNを無効にするとすぐ復旧するなら、問題は仮想インターフェース、ルーティング、DNSの取り込みに集中しています。無効にしても異常が続く場合は、システムプロキシが残っていないか、クライアントプロセスが動き続けていないか、OSのルートが復元されているかを確認します。必要ならクライアントを終了してから物理ネットワークへ再接続し、クリーンな状態で基本ネットワークを検証します。

FakeDNSのマッピング原理と適用範囲

FakeDNSの基本動作は、クライアントがドメイン問い合わせを受けたときに実際の宛先アドレスをすぐアプリへ返さず、専用アドレスプールから一時的なマッピングアドレスを割り当てることです。アプリがそのアドレスへ接続すると、カーネルがマッピングテーブルから元のドメインを復元し、ドメインルーティングとリモート名前解決を実行します。アプリがIP接続だけを開始しても、カーネルがドメイン情報を保持できるのが特徴です。主にTUN環境でのドメイン情報の喪失やローカルでの先行解決を解決するもので、すべての接続速度を向上させる汎用スイッチではありません。

1回の問い合わせと接続が完了するまで

アプリはまずDNSへservice.example.comを問い合わせます。FakeDNSはアドレスプールからマッピングアドレスを返し、「マッピングアドレスが元のドメインに対応する」ことを記録します。アプリがそのアドレスへ接続すると、TUNが通信をカーネルへ渡し、カーネルがテーブルを参照してドメインを復元し、ドメインルールでアウトバウンドを選びます。プロキシプロトコルとサーバーがリモート名前解決に対応していれば、実際のDNS問い合わせは後続の経路で実行できます。マッピングテーブルには容量と有効期間があり、期限切れの古いアドレスが同じ関係を無期限に保持することはありません。

この処理では、DNS問い合わせと後続の接続が同じカーネルへ入る必要があります。ブラウザー独自の暗号化DNSで問い合わせが迂回され、接続だけがTUNへ入ると、カーネルには実際のIPしか見えずFakeDNSは関与しません。逆にDNSがマッピングアドレスを返しても、接続がTUNを迂回して物理ネットワークへ直接送られると、そのアドレスはインターネット上で正しく応答されません。有効化前に問い合わせと接続の経路が一致していることを確認してください。そうしないと、ドメイン解決でアドレスは得られるのに、すべての接続が即座に失敗することがあります。

{
  "dns": {
    "servers": [
      "fakedns",
      "1.1.1.1"
    ]
  },
  "fakedns": [
    {
      "ipPool": "198.18.0.0/15",
      "poolSize": 65535
    }
  ]
}

198.18.0.0/15はベンチマークやマッピング用途でよく使われる予約アドレス範囲で、実際のLANアドレスと重複させてはいけません。poolSizeは割り当て可能なマッピング数を制御しますが、対応方式は使用するカーネルとクライアントが生成する設定によって異なります。GUIクライアントにFakeDNSの項目がある場合は、必要なDNS、スニッフィング、ルーティングの関係も同時に生成できるため、まず画面から設定してください。部分的なJSONを直接挿入する場合は、最終設定に重複フィールドや相互上書きがないことを確認します。

アドレスプールの衝突と迂回接続

アドレスプールを選ぶときは、企業ネットワーク、仮想マシン、コンテナ、その他のネットワークソフトが同じ範囲を使用していないか確認します。アドレスが衝突すると、システムがマッピング通信を誤ったインターフェースへ送ったり、実際の内部アドレスをFakeDNSの結果と判断したりします。有効化前にルートテーブルを確認し、そのネットワークに既存のより具体的なルートがないことを確かめてください。衝突を避けられない場合は、カーネルが対応する別の予約範囲を選び、TUNルートと除外設定も合わせて更新します。

アプリによってはDNSアドレスを長時間キャッシュし、ネットワーク切り替え後も古いマッピングを使い続けます。クライアントの再起動後にマッピングテーブルが変わっても、アプリが古いアドレスを保持していると、そのアプリだけ失敗することがあります。対象アプリも同時に再起動するか、DNSキャッシュを消去してください。FakeDNSのオン・オフを頻繁に切り替えるとキャッシュ状態の判断が難しくなるため、テスト中は設定を固定し、問い合わせ、接続、再起動の一連の検証を終えてから継続使用を判断します。

LANドメイン、プリンター検出、デバイスブロードキャスト、実際のIPを必要とするアプリは、通常FakeDNSに入れるのに適していません。内部ドメインはLANのDNSへ渡し、ドメインルールでマッピングを回避できます。プライベートアドレスは直接接続のままにしてください。返却アドレスによるアクセス制御や証明書バインディングに依存するプログラムでは、マッピングが動作を壊さないことも確認します。FakeDNSは、TUN内でパブリックドメイン情報を復元する必要がある一般的なTCP・UDP接続に適しています。

スニッフィングとドメインルーティングの連携

スニッフィングは一部のアプリケーション層プロトコルから対象ドメインを復元し、FakeDNSはDNSマッピングからドメインを復元します。両者は単純な代替関係ではありません。スニッフィングはプロトコル内容を識別できることが前提で、暗号化通信や非標準通信では機能しない場合があります。FakeDNSは問い合わせと接続の両方がカーネルを通ることを必要とします。通信種別に応じて組み合わせられますが、すべての対象をスニッフィング結果で強制的に上書きしないでください。ログでは、元の対象、スニッフィング対象、FakeDNSのマッピング対象を区別できる必要があります。

FakeDNSを検証するときは、まず未キャッシュのドメインを問い合わせ、返されたアドレスがマッピングプール内にあることを確認します。続いてすぐそのドメインへ接続し、ログで元の名前が復元され、想定したドメインルールに一致するか確認します。最後にLANドメインをテストし、内部DNSが実際のアドレスを返していることを確認します。3段階すべてが通って初めて、マッピング、復元、除外の関係が完成していると判断できます。予約アドレスが表示されたというだけでは不十分です。後続の接続がTUNに捕捉されていない可能性があるためです。

FakeDNSを有効にするかどうかは、実際の問題に基づいて判断します。通常のDNSとドメインルーティングが安定し、アプリがドメインをクライアントへ渡せるなら、設定を複雑にするために切り替える必要はありません。TUN環境で多くの接続がIPとしてしか表示されず、ドメイン振り分けが安定しない場合にFakeDNSを検討します。導入前にブラウザー、日常アプリ、LANリソース、ネットワーク切り替えをテストし、無効化したときの復旧策も残してください。

自作アウトバウンド、チェーン接続、全体検証

アウトバウンドは、ルーティング判定後に実行される接続先です。基本設定には通常、プロキシ、直接接続、ブロックの3種類が含まれます。詳細な環境では、インターフェース別の直接接続、指定DNSアウトバウンド、チェーンプロキシ、通信種別ごとの独立した接続パラメーターが必要になることもあります。自作アウトバウンドの価値は層を増やすことではなく、ネットワーク経路を明確に表現することです。追加する各アウトバウンドには、固有のラベル、それを呼び出す明確なルーティングルール、単独で検証できる対象を用意してください。

安定して読みやすいラベルを使う

アウトバウンドラベルは、ルーティングルール、DNS設定、チェーン関係から参照されます。ラベルはproxy-main、direct-lan、dns-directのように、短く安定した英字または数字の組み合わせにします。サーバー名に合わせて変化する説明文は避けてください。ラベルを変更したら、すべての参照先を確認します。表記が一致しないと、設定の読み込み時にエラーになることが多く、場合によってはルールがデフォルトアウトバウンドへフォールバックします。GUIクライアントが自動生成するラベルはむやみに上書きせず、ユーザーによる拡張が許可されたフィールドを先に確認してください。

{
  "outbounds": [
    {
      "protocol": "freedom",
      "tag": "direct-lan",
      "settings": {
        "domainStrategy": "UseIP"
      }
    },
    {
      "protocol": "blackhole",
      "tag": "blocked"
    }
  ],
  "routing": {
    "rules": [
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct-lan"
      },
      {
        "type": "field",
        "domain": [
          "domain:blocked.example"
        ],
        "outboundTag": "blocked"
      }
    ]
  }
}

freedomはローカルから直接接続を確立し、blackholeは一致した通信を拒否します。ブロックルールは明確な対象に限定し、広すぎる条件で通常のサービスへ影響を与えないようにします。例ではアウトバウンドとルーティングの参照関係だけを示し、サーバー設定は含めていません。自作アウトバウンドをv2rayNへ追加する場合は、現在の設定テンプレートがどのように統合されるかを先に確認してください。画面によっては保存時にコア設定を再生成するため、生成ファイルを手動編集してもサーバー切り替え後に上書きされることがあります。

チェーン接続の依存関係

チェーン接続は、あるプロキシアウトバウンドが別のアウトバウンドを通じて下位接続を確立する構成です。中継経路が必要な環境には有効ですが、層を増やすほど障害点も増えます。設定前に、前段アウトバウンドと対象アウトバウンドがそれぞれ単独で動作することを確認し、その後でチェーンを構成してください。前段が失敗すると、後段のログにはハンドシェイクのタイムアウトだけが現れることがあります。後段のパラメーターが誤っていても、前段は正常接続に見える場合があります。トラブル対処では、経路を分解して各区間を個別にテストできなければなりません。

チェーン設定ではループも防ぐ必要があります。アウトバウンドAがアウトバウンドBを通じて接続し、アウトバウンドBがルーティングルールによって再びAへ送られると、完了できない循環が発生します。チェーン関係を作るときは、サーバーアドレスの名前解決と接続がどの下位出口を使うかを明確にし、必要なアドレスにはチェーンに依存しない起動ルールを用意します。DNSも、まだ確立していない最終アウトバウンドに依存させないでください。そうしないと起動時にどの層のサーバーも解決できません。

サーバー一覧にある複数の通常項目を、自動的なチェーン接続と誤解しないでください。クライアントで現在のサーバーを切り替える動作は、通常は主要プロキシアウトバウンドを変更するだけです。明示的にプロキシ転送関係を設定した場合にのみ、通信は複数のアウトバウンドを順番に通ります。経路が長いほど接続品質が高いとは限りません。実際の効果は各区間のネットワーク経路、プロトコルのオーバーヘッド、障害復旧方法に左右されます。明確な要件がなければ、単独で検証できるプロキシアウトバウンドのほうが管理しやすくなります。

ネットワークインターフェースまたはアドレス族で直接接続する

複数のNICを持つ端末では、有線、無線、仮想ネットワーク、企業ネットワークに同時接続していることがあります。自作の直接接続アウトバウンドを使うと、特定の通信を指定したローカルアドレスやインターフェースから送信できます。設定前にインターフェース名とローカルアドレスが安定しているか確認してください。自動割り当てアドレスが変わると、固定したバインドが機能しなくなることがあります。LinuxとmacOSではシステムルートやポリシールーティングでインターフェースを制御することが多く、Windowsではインターフェースメトリックとクライアントのアウトバウンドバインドを同時に確認する必要があります。

アドレス族の方針もアウトバウンドの境界に含まれます。IPv4接続だけが安定しているネットワークでは、自作アウトバウンドで到達不能なIPv6を強制しないでください。逆の場合も同様です。DNSが返すアドレス族、ルーティングルール、アウトバウンドの接続方針は一致させる必要があります。ドメインに複数のアドレスがあり、一部のネットワークだけで失敗する場合は、アドレス族ごとにテストし、サーバーだけを交換しないでください。変更後は、直接接続とプロキシアウトバウンドが同じ方針を使っているかも確認します。同じドメインが出口によって異なる動作をするのを防ぐためです。

保存、再読み込み、最終受け入れ確認

自作アウトバウンドを設定したら、まずカーネルが設定を読み込めることを確認します。構文エラー、未知のラベル、未対応フィールドは通常、起動ログに表示されます。読み込みに成功しても経路が正しいとは限りません。各アウトバウンドに明確なテスト対象を割り当てます。LANアドレスで直接接続、指定ドメインで主要プロキシ、ブロック対象で拒否ルール、自作チェーンでは各層を順番に確認します。対象、ヒットしたルール、アウトバウンドラベル、結果を記録し、再現可能な受け入れ確認表を作成します。

GUIクライアントは、サーバー切り替え、サブスクリプション更新、ルーティング方式の変更時に実行設定を再生成することがあります。自作内容を保存したら、クライアント再起動、テスト購読の更新、サーバー切り替え、ルーティングの再読み込みを一通り実行し、拡張設定が残っているか確認してください。上書きされる場合は、クライアントが対応する自作設定の入口、テンプレート、統合機能を使い、実行用の一時ファイルを繰り返し編集しないでください。長期的に使う設定は、クライアントが認識する永続化された場所に保存します。

完全な詳細設定では、「入力を追跡できる、ルールを説明できる、DNSを観察できる、取り込みを元に戻せる、アウトバウンドを個別にテストできる」状態を保ちます。接続に異常が出たら、まずリクエストがどの層で止まっているかを特定し、その層のログとシステム状態を確認してください。最小環境を再構築する必要がある場合は、クイックスタートの基本手順へ戻って基本接続を確立し、章ごとに高度な機能を復元します。クライアントのインストールやプラットフォーム選択の問題はインストーラーページで確認できます。最小の基準から層ごとに戻す方法は、購読、ルーティング、DNS、TUNを同時に再構築するより、確実な結論に到達しやすくなります。