V2Ray設定上級ガイド

3層の設定モデルを先に作る

クイックスタートページでは、サブスクリプションの追加、サーバー選択、システムプロキシの有効化、接続確認までの基本手順を完了します。本ガイドでは、その後に必要となる複数購読の分離、複雑な振り分け、DNSの問い合わせ経路、TUNの取り込み範囲、カスタムアウトバウンドを扱います。変更前に、現在の設定を3層に分けてください。最外層はv2rayN、v2rayNG、v2flyNGの画面設定、中間層はクライアントが生成してXrayまたはV2Flyに渡す実行設定、最下層はOSのプロキシ、ルーティングテーブル、仮想NIC、名前解決の動作です。3つの層は相互に影響しますが、意味はそれぞれ異なります。

たとえばv2rayNの「システムプロキシを設定」は、システムプロキシに対応するアプリをローカルの待受ポートへ向けるだけで、ルーティングモードとは別物です。「中国本土をバイパス」はコアのルーティングルールで、リクエストがコアに入った後、directとproxyのどちらへ渡すかを決めます。TUNモードはOSのネットワーク層からより多くの接続を取り込むため、アプリがシステムプロキシを参照しなくても仮想NICで捕捉される場合があります。3つを1つのスイッチのように扱うと、ブラウザーは動くのにコマンドラインだけ失敗する、またはシステムプロキシを無効にしても通信がコアを通る、といった問題が起こりやすくなります。

調整するたびに変更は1つの層だけに限定します。まず動作中の設定を保存し、変更内容を記録してからコアを再起動し、ログを確認して固定したテストを実行します。テストには少なくとも、ドメイン名によるリクエスト、IPアドレスを直接指定するリクエスト、明確に直接接続すべき対象、明確にプロキシを通す対象を含めてください。ルーティング、DNS、TUNを一度に変更すると、ログから最終的な失敗箇所は分かっても、最初にずれた箇所を特定できません。

1つのリクエストが実際に通る経路を理解する

通常のシステムプロキシでは、アプリがまずv2rayNのHTTPまたはSOCKSインバウンドへ接続します。コアはリクエストの宛先を読み取り、必要に応じてドメインを解決してから、ルーティングルールによりアウトバウンドタグを照合します。directに一致した場合はローカルネットワークから直接接続し、proxyに一致した場合は現在のサーバーに対応するプロキシアウトバウンドへ渡し、blockに一致した場合はローカルでリクエストを終了します。TUNではもう1段階増え、OSがIPパケットを仮想NICへ送り、コアが接続先を復元してから、同じルーティングとアウトバウンドの流れに入ります。

ルーティングの照合は、コアから見えている情報に依存します。SOCKSインバウンドでは通常、元のドメイン名を渡せるため、コアはdomainやgeositeを直接照合できます。一部のプログラムは先に自分で名前解決を行い、宛先IPだけを送るため、コアにはIPしか見えず、ドメインルールが一致しないことがあります。トラフィック嗅探で一部の接続のハンドシェイクからドメイン名を復元できる場合もありますが、すべてのプロトコルに有効ではなく、DNS設定の誤りの代わりにもなりません。ルールが一致しないときは、まずログに記録された宛先がドメイン名かIPかを確認してください。

DNSも独立したモジュールではありません。ルーティングルールが宛先IPの解決を必要とする場合があり、DNSクエリ自体もアウトバウンドを選択する必要があります。TUNではシステムの問い合わせがコアに捕捉されることもあります。すべてのDNSリクエストを同じリモートリゾルバーへ送り、そのリゾルバーのドメインがプロキシ経由でしか解決できない構成にすると、起動時の依存関係が発生します。プロキシサーバーがまだ接続できないため、リゾルバーにもアクセスできない状態です。解決策はサーバーを何度も切り替えることではなく、起動経路用に直接アクセスできるリゾルバーを残し、どの問い合わせをdirect、どれをproxyへ送るか明確にすることです。

画面の状態ではなくログで層を特定する

画面に「接続済み」と表示されても、通常はコアプロセスが起動したことしか意味せず、すべてのリクエストが正しいアウトバウンドへ到達した証拠にはなりません。まず待受ポートが確立しているかを確認し、次にリクエストが対象インバウンドへ入ったか、続いてルーティング結果、最後にアウトバウンド接続エラーを確認します。テストリクエストがログにまったくない場合は、アプリのプロキシ、システムプロキシ、TUNの取り込み層に問題があります。インバウンド記録はあるのにルール結果が期待と違う場合は、宛先の識別またはルール順序を確認します。期待するアウトバウンドに一致してから接続に失敗する場合は、サーバー設定、ネットワーク到達性、時刻設定を確認してください。

• 現在操作している対象が、サブスクリプションの元エントリ、クライアント生成設定、システムのネットワーク設定のどれかを確認します。
• 変更前にクライアント設定をエクスポートするか、重要な項目を記録して、既知の状態へ戻せるようにします。
• テスト中はプロキシ設定を書き換える他のネットワークツールを停止し、ポートやルーティングテーブルの上書きを防ぎます。
• 同じ対象群で繰り返しテストし、まずルーティングの一致結果の変化を比較し、その後に最終的なアクセス結果を比較します。

デスクトップ版の高度な設定にはv2rayNを優先します。サブスクリプショングループ、ルーティング、DNS、TUNの入口が集約され、ログも比較しやすいためです。Androidではv2rayNGを使用でき、V2Flyコアが必要な場合はv2flyNGを選びます。3つのクライアントのダウンロード先と対応プラットフォームはクライアントダウンロードページで確認できます。画面の項目名は変更される場合がありますが、「インバウンド—ルーティング—DNS—アウトバウンド」というコアの流れは変わりません。以降の章もこの流れに沿って説明します。

提供元ごとにグループを作り、すべてのエントリを混在させない

サブスクリプショングループの第一の役割は提供元を示すことです。追加時は各URLに「仕事用」「モバイル予備」「テスト環境」など、後から追跡できる固定のメモを付け、「購読1」「新しいURL」のような名称は避けます。更新後もサーバーエントリと所属グループの関係を保ちます。同名エントリ、ルーティング結果の違い、特定の提供元の停止が発生しても、対象範囲をすぐ絞り込めます。

グループの第二の役割は更新を分離することです。サブスクリプションの更新では、リモートの内容を読み直し、そのグループのエントリを追加・変更・削除します。更新前にサーバーアドレス、ポート、トランスポートを手動変更していた場合、次回同期で上書きされることがあります。長期的に残すカスタムエントリは独立したローカル設定へ複製し、メモに提供元と用途を記録してください。「変更後は更新しない」という暗黙のルールに頼らないことが重要です。一時的な変更は元の値を記録し、テスト後に複製を削除します。

グループの第三の役割は一括操作の範囲を制御することです。テスト、選択項目のエクスポート、一括有効化や削除を行う前に、対象グループを限定します。複数購読では同じメモが異なる提供元に存在することがあり、表示名だけでは同じサーバー設定を共有しているか判断できません。グループ名には提供元を、エントリのメモには地域、プロトコル、用途を記載し、それぞれ別の情報を担わせてください。すべての属性を1つの長い名前に詰め込まないことが大切です。

フィルターは表示対象を絞り込むためだけに使う

サーバーフィルターは、エントリが多く命名が安定しているサブスクリプションに適しています。メモに含まれる語、正規表現、プロトコル種別、グループなどで絞り込めます。まずは単純な包含語でルールを作り、結果を確認してから正規表現へ進みます。正規表現では大文字・小文字、空白、ハイフン、全角文字の違いを明確にしてください。メモに「予備」または「テスト」を含むエントリを残すなら、予備|テストを使えます。除外する場合はクライアントの除外条件を使い、複雑な否定表現で全ロジックを再現しないでください。

フィルターと削除は意味が異なります。フィルター後のエントリはサブスクリプショングループに残りますが、現在のビューや候補一覧に表示されません。削除したエントリは、次回更新で再び現れる場合があります。長期的に不要な種類はグループのフィルター条件で除外し、特定のプロトコルや地域に一時的に集中したい場合は表示フィルターを使ってください。結果が空になったら、まずルールをすべて消して完全な一覧に戻し、条件を1つずつ追加します。サブスクリプションに本当にエントリがないのか、フィルター範囲が広すぎるのかを切り分けられます。

保持条件：
(予備|テスト).*(VLESS|Trojan)

除外条件：
期限切れ|メンテナンス|一時

説明：
用途を表す語を先に照合し、次にプロトコル語を照合する；
除外条件は独立して実行し、保持条件と複雑な1つの式にまとめない。

この例はフィルターの順序を示すもので、実際に照合する対象はサブスクリプションが提供するサーバーメモです。

更新前に復元できる状態を残す

更新前に、現在のサーバーがどのグループに属するかを確認し、利用可能なエントリのメモを記録します。更新直後に古いエントリを一括削除せず、追加・削除・パラメータの変化を確認してください。更新時に元のエントリを残す機能があれば、短期のトラブルシューティングで有効にします。安定した後に重複を整理します。古いエントリと新しいエントリを長期間同時に残すと選択が混乱し、自動選択が保守されていない設定を使い続ける可能性もあります。

サブスクリプションURLの読み込みに失敗したら、ネットワーク層に沿って確認します。まずURLが完全で前後に空白がないことを確認し、次に更新リクエストのプロキシ方式が直接接続、システムプロキシへの追従、現在のコア経由のどれかを確認します。最後に、返却内容がクライアントの認識できるサブスクリプション形式かを確認してください。ログインページ、エラーテキスト、空の内容が返ると、クライアントには「解析に失敗」としか表示されないことがあります。この場合、サーバーを切り替えても改善しないため、まずサブスクリプションリクエスト自体を確認します。

更新は成功したのに新しいエントリがない場合は、現在のグループ、フィルター条件、重複処理、プロトコル対応を順に確認します。メモが同じため重複と判定される場合や、現在のコアが対応するフィールドを認識できずインポートされない場合があります。v2rayNGは標準でXray設定を前提とし、v2flyNGはV2Flyコアを前提とします。サブスクリプションに特定コアの拡張が含まれる場合は、未知のフィールドを手動で削除するのではなく、クライアントとコアの対応を合わせてください。

安定したサーバー選択の流れを作る

サーバーテストは、テスト時刻・方法・対象における状態を示すだけで、プロトコルパラメータの確認には代わりません。まず必須フィールドの不足、アドレス解決不能、トランスポートの不一致があるエントリを除外してから接続テストを行います。選択後は実際のアプリリクエストでルーティングとDNSを検証し、クライアントのテスト結果だけを見ないでください。同じドメインを複数のエントリが共有している場合、DNSキャッシュや接続の再利用が短時間の結果に影響します。切り替え後は古い接続が終了するまで待つか、対象アプリを再起動します。

検証済みの基準エントリを1つ残すことを推奨します。ルーティング、DNS、TUN、カスタムアウトバウンドを変更した後は、必ず最初に基準エントリでテストします。基準エントリも失敗するなら、ローカル設定に原因がある可能性が高く、新しいエントリだけ失敗するなら、そのエントリのプロトコル、ポート、トランスポート、セキュリティ層、サーバー名を確認します。この比較により、ローカルルールの問題をサブスクリプションの問題と誤認せず、調査中に複数の変数を連続して変更することも避けられます。

サブスクリプションの形式とデスクトップ版・Android版の追加手順はV2RayサブスクリプションURLの追加ガイドで確認できます。本章の重点は追加後の管理です。提供元を追跡でき、更新から復元でき、フィルターを解除でき、選択に基準があること。この4点がそろって初めて、複数購読と複雑なルーティングを安定して運用できます。

先にアウトバウンドタグを決めてから照合条件を書く

ルーティングルールの結果は「許可」や「拒否」ではなく、リクエストを指定したアウトバウンドへ渡すことです。一般的なタグにはプロキシのproxy、直接接続のdirect、ブロックのblockがあります。実際のタグはクライアント生成時に異なる場合があるため、ルールをコピーする前に現在のアウトバウンド名を確認してください。存在しないタグを参照すると、コアが起動を拒否したり、ルールが期待どおりに機能しなかったりします。

1つのルールでは、ドメイン、IP、ポート、インバウンドタグ、ネットワーク種別、プロトコルの特徴などで照合できます。ドメイン条件は特定サイトやgeosite分類に、IP条件はLAN、プライベートアドレス、geoip分類に適しています。インバウンドタグを使えば、異なるローカルポートやTUNの通信を別々のアウトバウンドへ送れます。関係のない条件を同じルールに詰め込まないでください。同一ルール内の異なるフィールドは通常、すべて満たす必要があるため、範囲が直感より狭くなります。

ルール一覧は順番に確認し、最初に一致した時点で照合を終えます。そのため、具体的なルールを分類ルールより前に置き、分類ルールを最終フォールバックより前に置きます。たとえばgeosite:cnに属するドメインをプロキシ経由にしたい場合、そのドメイン専用のproxyルールを先に書き、その後にgeosite:cnをdirectへ送るルールを書きます。順序が逆なら分類ルールが先に一致し、後の例外は実行されません。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "domain:internal.example"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "geosite:cn"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "geosite:geolocation-!cn"
        ],
        "outboundTag": "proxy"
      }
    ]
  }
}

これはコアのルーティング構造を示す例です。アウトバウンドタグはクライアント生成設定と一致させてください。

domainStrategyの影響を理解する

AsIsは、ルーティング段階で元の宛先を優先し、IPルールのためにドメインを積極的に解決しないことを示します。リクエストにドメイン名が含まれていればドメインルールを照合でき、IP宛先だけがそのままIPルールへ進みます。動作が単純で、主にドメイン分類を使う設定に適しています。一方、ドメインがどのルールにも一致しない場合、アプリがすでにIPへ解決していない限り、後続のgeoip条件で処理できません。

IPIfNonMatchは、まずドメインルールを試し、一致しなければドメインを解決してからIPルールを試す方式です。「ドメイン分類を優先し、IPの地理分類をフォールバックにする」構成に適しており、バランスのよい選択肢です。ただしルーティング段階の解決にはコアのDNS設定が使われるため、DNSが不完全だとルーティングルールが壊れたように見えます。ログに解決エラーが出る場合は、ドメイン例外を増やす前にDNSを修正してください。

IPOnDemandは、IPが必要になる可能性のあるルールに遭遇した時点で、より早く解決を開始します。複雑なルールでは問い合わせ回数が増え、ドメインだけで判断できるリクエストもDNS結果の影響を受けることがあります。IPを先に取得する明確な理由がない限り、「ルールが一致しない」問題を解決する汎用スイッチとして使わないでください。名前の印象ではなく、ルール構造に基づいて選択します。

説明しやすい階層でルールを整理する

ルールは5層に分けることを推奨します。第1層はgeoip:privateや内部ドメインなど、LANやローカルリソースを処理し、通常はdirectへ送ります。第2層は分類結果より優先する具体的な例外です。第3層は、インバウンドタグでブラウザ用ポートと開発ツール用ポートを分けるなど、プロトコルやアプリ固有のルールです。第4層はgeosite、geoipなどの広範囲な分類です。第5層は最終フォールバックで、一致しないリクエストをproxyとdirectのどちらへ送るか明示します。

ブロックルールは追跡可能な状態に保ちます。範囲の広い分類リストを直接追加すると、アプリが失敗した際に、リモート側の問題かローカルのblock一致か判断しにくくなります。まず明確なドメインから始め、ログにルーティング結果を残してください。UDP、LAN探索、時刻同期などのシステム通信は、「不要そう」という理由だけですべてブロックしないでください。TUNではこれらがネットワーク状態の判定やアプリ起動に影響することがあります。

ポートルールでは、宛先ポートとトランスポートプロトコルを同時に考慮します。53だけで照合するとTCPとUDPのDNSを同時に含む可能性があり、ネットワーク種別だけでUDPを照合すると他のリアルタイム通信も含まれます。DNSだけを個別に処理するなら、ポート、ネットワーク、インバウンドの送信元を同時に限定します。特定のアプリを決まったアウトバウンドへ送る場合は、専用のインバウンドポートを用意するか、クライアントが対応するプロセス照合を使い、増え続けるドメイン一覧でアプリの動作を推測しないでください。

geositeとgeoipの更新後に変化した動作を確認する

分類データベースは、同じルールの照合範囲に影響します。更新後に一部のドメインの経路が変わった場合は、まずデータファイルが現在のコアに読み込まれているかを確認し、次に分類名が存在するか、最後に具体的なドメインが新しい集合に含まれているかを確認します。同じルールを何度も追加して問題を覆い隠さないでください。最初の一致という原則は、ルールを重複させても変わりません。関連ファイルの役割、更新方法、ルール無効化の切り分けはgeoip.datとgeosite.datの更新方法で確認できます。

ルーティング設定が完了したら、説明付きのルール一覧としてエクスポートします。少なくともルール順、各層の目的、依存するアウトバウンドタグ、データベース分類を記録してください。クライアント画面のプリセットは素早い選択に便利ですが、カスタムルールを追加した後は実際に生成された設定を基準にします。これにより、クライアント更新、コア切り替え、端末移行の際に、差異が画面プリセットによるものかコアのフィールド変更によるものか判断できます。

システムDNS、コアDNS、アプリ独自の名前解決を分ける

システムDNSは、OSが一般アプリへ提供する名前解決の入口です。コアDNSはXrayまたはV2Fly設定内の解決モジュールで、主にルーティング判定、プロキシサーバーのアドレス解決、取り込まれたDNSリクエストを処理します。一部のブラウザーやアプリは独自の暗号化DNSを使用し、システム設定を迂回します。3つの経路が同時に存在するため、「DNSを変更した」という場合はどの層を変更したのか明確にしてください。

通常のシステムプロキシでは、アプリがドメインをSOCKSまたはHTTPプロキシへ渡せば、コアはドメインを見て自身の設定で処理できます。アプリが先にシステムDNSでIPを取得してからプロキシへ接続すると、コアにはIPしか見えない場合があります。TUNではシステムDNSの問い合わせを仮想NICで捕捉できますが、アプリ独自の暗号化DNSは通常のHTTPSリクエストとして動作し続けることがあります。解決結果の違いを調べるときは、まずアプリ内の独自解決を無効にし、システム標準の経路を基準にしてから、層ごとに戻します。

DNS設定の目的は、特定のリゾルバーの応答速度だけを追求することではありません。問い合わせが到達でき、現在のネットワークに適した結果が得られ、その結果に基づいてルーティングが一貫した判断をできることが重要です。ドメインルールがgeositeでアウトバウンドを決める一方、アプリが先に解決してIPだけを送ると、最終的にはgeoipまたはフォールバックルールで決まります。どちらも正常になり得ますが、設計意図と一致している必要があります。

ドメインごとに解決サーバーを明確に割り当てる

コアDNSには複数のサーバーを設定し、ドメイン分類に応じて選択できます。内部ドメインは内部ゾーンを認識できるリゾルバーへ、通常の直接接続用ドメインはローカルネットワークから到達できるリゾルバーへ送ります。プロキシ経由でアクセスするDNSサービスには対応するアウトバウンドを指定し、ルーティングルールがループを作らないようにします。すべてのサーバーを単純に並べて、コアが自動的に「最適」な結果を選ぶと期待しないでください。並列問い合わせ、フォールバック、期待するIPの扱いは、コアやフィールドの設定によって異なります。

{
  "dns": {
    "hosts": {
      "router.internal": "192.168.1.1"
    },
    "servers": [
      {
        "address": "223.5.5.5",
        "domains": [
          "geosite:cn"
        ],
        "expectIPs": [
          "geoip:cn"
        ]
      },
      {
        "address": "1.1.1.1",
        "domains": [
          "geosite:geolocation-!cn"
        ],
        "skipFallback": true
      },
      "localhost"
    ],
    "queryStrategy": "UseIP"
  }
}

この例は分類に応じた問い合わせ構造を示します。実際のアドレスとアウトバウンド経路は、現在のネットワーク環境に合わせて設定してください。

hostsは少数の内部名を固定したり、特定の解決結果を上書きしたりする用途に適しています。大規模なドメイン一覧の代わりにはならず、頻繁に変わる外部アドレスを保存する場所でもありません。domainsは解決サーバーが担当するドメイン集合を限定します。順序と優先順位はコアのルールと合わせて理解してください。expectIPsは返されたアドレスが想定する分類に合うか確認するために使えます。フォールバックの補助になりますが、分類データベースが古い場合や地域分散配信を使う対象では、条件が厳しすぎると利用可能な結果まで拒否することがあります。

IPv4とIPv6の問い合わせ方針を選ぶ

UseIPは通常、利用可能なIP種別の返却を許可しますが、具体的な動作はOSとコアの対応状況に左右されます。UseIPv4はIPv4の結果だけを要求または保持し、現在のネットワークでIPv6ルートが安定しない環境に適しています。UseIPv6はIPv6だけを使うため、ローカル、プロキシサーバー、宛先までの経路がすべて対応している必要があります。1回のIPv6接続失敗だけを理由に、IPv6全体を恒久的に無効化しないでください。ローカル出口、プロキシアウトバウンド、宛先サイトのどこで失敗したかを先に確認します。

デュアルスタック環境では、DNSがIPv6アドレスを返す一方、現在のアウトバウンドがIPv4接続しか確立できないことがあります。アプリがIPv6のタイムアウトを待ってからIPv4へ戻るため、初回表示が遅くなる場合があります。切り分けでは、コアDNSで一時的にUseIPv4を使って確認します。遅延が消えたら、システムのIPv6ルートとアウトバウンドの対応を調べ、変化がなければ原因はアドレスファミリーではありません。逆にIPv4を強制すると、IPv6しか提供しない内部リソースが使えなくなるため、内部ドメインには専用のサーバーとルールを用意するのが安全です。

DNSループと起動時の依存関係を避ける

プロキシサーバーのアドレスがドメイン名の場合、コアの起動時に先に解決する必要があります。唯一のDNSサーバーへ、まだ確立していないプロキシアウトバウンド経由でしかアクセスできないと、循環依存が発生します。サーバーアドレス用に直接アクセスできるブートストラップリゾルバーを用意するか、信頼できる前提で静的マッピングを設定してください。静的マッピングはアドレス変更を自分で管理する必要があるため、管理された環境に適し、動的サービスを単一IPへ長期間固定する用途には向きません。

DNSのルーティングルールでも循環が起こります。すべての53番ポートの通信を専用DNSアウトバウンドへ送り、その専用アウトバウンド自身が同じルールに捕捉される53番ポートのリクエストを生成するケースです。インバウンドタグ、宛先アドレス、専用アウトバウンドタグでルール範囲を狭め、コア自身の上流問い合わせがループから抜けられるようにします。TUNでは、仮想NICから出た問い合わせを同じインバウンドへ再リダイレクトしないことも重要です。

キャッシュを調べるときは、先に消去してから再現します。アプリのキャッシュ、システムDNSキャッシュ、コアキャッシュの順に消去し、問い合わせを1回だけ実行します。キャッシュを消さないと、解決サーバーを変更しても古い結果が使われ、誤判定につながります。設定が安定したら通常のキャッシュへ戻してください。完全に無効化すると問い合わせ量が増え、短時間のネットワーク変動が各接続へ直接影響します。

最後に「内部ドメイン、明確に直接接続するドメイン、明確にプロキシを通すドメイン、プロキシサーバーのドメイン」の4種類を個別にテストします。各問い合わせが想定したサーバーへ入り、ルーティングログでも最終アウトバウンドが一致するかを確認します。DNSが正常とは、すべてのドメインを同じサーバーが回答することではなく、各名称が説明可能な経路で接続可能な結果を得ることです。

TUNで解決する問題を明確にする

システムプロキシは、アプリがOSのプロキシ設定を自発的に参照することを前提とします。ブラウザーや一部のデスクトップアプリは対応していますが、コマンドラインツール、ゲームランチャー、独自のネットワークスタックを持つアプリは無視することがあります。TUNは仮想NICを作成してルートを調整し、より多くのIP通信をコアへ送り、ルーティングルールでdirect、proxy、blockを選択します。取り込み範囲は広がりますが、誤ったサーバー、ルーティング、DNS設定を自動修正するものではありません。

TUNを有効にする前に、通常のシステムプロキシで基準サーバーへ接続でき、ドメイン解決が正常で、直接接続とプロキシのルールが期待どおりであることを確認します。これをせずにTUNへ切り替えると、仮想NIC、ルーティングテーブル、DNSリダイレクト、権限という変数が同時に増え、調査範囲が大きくなります。通常のプロキシ設定を1つ保存し、TUNに失敗したらTUNを無効にしてシステムネットワークを復元し、基本経路がまだ正常か確認してください。

v2rayNはWindows、macOS、Linux向けのデスクトップ版を提供していますが、仮想NICの作成、ルート変更、権限要求の方法はOSごとに異なります。画面上の基本概念は共通で、TUNインバウンド、スタック種別、自動ルートと厳格ルート、DNSの取り込みを設定し、コアが十分な権限で動作するようにします。各プラットフォームの導入先はWindowsダウンロード、macOSダウンロード、Linuxダウンロードで確認できます。

ネットワークスタックと自動ルーティングを選ぶ

TUN実装には複数のネットワークスタックがあります。システムスタックはOS本来の動作に近く、互換性の経路が分かりやすい方式です。ユーザー空間スタックは環境によってクロスプラットフォーム処理に便利ですが、特定プロトコル、フラグメント、ローカルネットワークで挙動が異なることがあります。明確な要件がなければ、まずクライアントが推奨する標準項目を使います。UDP、LAN、特定アプリに異常が出たら、MTU、DNS、ルーティングを同時に変更せず、スタックだけを切り替えて比較します。

自動ルーティングは、対象範囲のシステム通信を仮想NICへ送ります。有効化後は、デフォルトルート、LANルート、プロキシサーバーアドレスの例外経路を確認してください。プロキシサーバー自身の接続が同じTUNインバウンドへ再び入るとループになります。クライアントは通常、サーバーアドレスや必要なシステム通信を除外しますが、サーバーがドメイン名で解決結果が変わる場合は、実際のアドレスが誤って取り込まれていないかログで確認します。

厳格ルーティングは、TUNを迂回する経路を減らします。有効にすると、LAN、仮想マシン、コンテナ、企業ネットワークのクライアントに影響することがあります。まず厳格ルーティングを無効にして基本確認を完了し、その後、必要な取り込み範囲に応じて有効にします。有効化後にLANリソースだけ失敗する場合は、プライベートアドレスと対象サブネットをdirectへ送るルートを残し、より前のproxyルールに一致していないか確認します。

権限、ファイアウォール、残留ルートを処理する

仮想NICの作成やシステムルートの変更には、通常、権限の昇格が必要です。クライアント画面でTUNが有効と表示されても、システムに対応するインターフェースがなければ、まず権限要求が完了したかを確認し、その後コア起動ログを確認します。スイッチを何度もクリックしないでください。起動失敗でプロセスや一部のルートが残ることがあります。まずコアを停止し、クライアントを終了して、仮想インターフェースと関連プロセスの状態を確認してから再起動します。

ファイアウォールは、プログラムのパス、ネットワークインターフェースの種類、ネットワークプロファイルなどでアクセスを制御することがあります。クライアント更新やデスクトップ版と従来のWPF版の切り替え後は、プログラムパスが変わり、古いルールが一致しなくなる場合があります。「システムプロキシは正常だが、TUNには通信がまったくない」場合は、新しい仮想インターフェース経由の通信をコアプロセスが許可されているか確認します。「一部のアプリは正常だが、別のアプリはすぐ失敗する」場合は、特定の物理インターフェースへのバインドや、現在のスタックが対応しない方式を使っていないか確認します。

異常終了後、システムにDNSやルート設定が一時的に残ることがあります。まずTUNを正常に無効化し、次にクライアントを終了して、DNSの自動取得とデフォルトルートを復元します。クライアントプロセスが停止したことを確認してから、システムネットワークをリセットしてください。コアが動作中に仮想NICを直接削除すると、クライアントが無効なインターフェースを保持し、派生エラーが増えます。

症状からTUNの問題範囲を絞る

有効化後にすべてのネットワークが直ちに切断されたら、デフォルトルート、コアの待受、プロキシサーバーのループ取り込みを確認します。ドメインだけ失敗してIPが正常なら、DNSの取り込みと上流問い合わせのアウトバウンドを重点的に確認します。小さなウェブリソースは正常で大きなリソースが停止するなら、他の設定を変えずにMTUが高すぎないかを試します。UDPだけ異常なら、サーバーのプロトコル、TUNスタック、ルーティングルールがUDPを許可しているかを確認し、先にDNSを変更しないでください。

TUNを無効にしてもネットワークが異常な場合は、仮想NICが消えたか、システムDNSが復元されたか、デフォルトルートが物理ネットワークを向いているかを確認します。クライアントのコアを再起動するだけではOSの設定は復元されません。まずクライアントの停止または復元操作を実行してください。復元後、クライアントを経由しない基本ネットワーク通信でシステム状態を確認し、最後に通常のプロキシモードを再び有効にします。

TUNが安定してから、プロセスルール、厳格ルーティング、FakeDNSを設定します。項目を1つ追加するたびに、「ドメインリクエスト、IPリクエスト、直接接続対象、プロキシ対象、LANリソース」の5種類を繰り返しテストします。TUNの目的は取り込み範囲を広げることであり、すべての通信を単一のアウトバウンドへ強制することではありません。最終経路はルーティングルールが決めるため、直接接続するネットワーク、DNSアウトバウンド、サーバーのループ除外を明確にします。

「仮のアドレスを返し、本来のドメインを保持する」流れを理解する

アプリがドメインを問い合わせると、FakeDNSは実際のIPをすぐに返さず、専用のアドレスプールから一時アドレスを割り当て、「一時アドレス—元のドメイン」のマッピングを保存します。アプリがその一時アドレスへ接続すると、TUNインバウンドが接続を捕捉し、コアがマッピングから元のドメインを復元して、ドメインルーティングと実際のリモート接続を実行します。これにより、アプリがIPパケットしか送らなくても、コアはgeositeや具体的なドメインルールでアウトバウンドを判断できます。

一時アドレスはローカルのマッピング範囲内でのみ意味を持ち、LANや実際の外部ネットワークへ送ってはいけません。TUNが接続を取り込まず、ルーティングテーブルが物理NICへ送ると、アプリは直接失敗します。そのためFakeDNSはDNSの取り込みとTUNルーティングと同時に有効にする必要があります。DNS設定だけにFakeDNSサーバーを追加し、返却アドレスの接続をコアへ入れないと、「名前解決はできるが接続はすべて失敗する」という典型的な状態になります。

FakeDNSが主に解決するのはドメイン情報の喪失であり、サーバーへの接続能力を高めたり、上流の実際の解決を代替したりするものではありません。コアがドメインを復元した後も、アウトバウンド方式に応じて実際の宛先を解決するか、ドメインをリモートへ渡す必要があります。上流DNSに到達できない、ルーティングタグが誤っている、サーバーが対象接続に対応していない、といった問題をFakeDNSで修正することはできません。

アドレスプールを設計し、実ネットワークとの重複を避ける

アドレスプールには、現在のLAN、企業ネットワーク、仮想マシン、コンテナのネットワークと重複しない専用の予約範囲を使います。一時アドレスが実在する内部サブネットと重なると、内部リソースへのアクセスがFakeDNSマッピングと誤認されたり、外部ドメインの一時接続が実際の内部ネットワークへ送られたりします。有効化前にシステムのルーティングテーブルを確認し、物理ネットワーク、VPN、仮想マシン、コンテナが使うサブネットを記録して、競合しない範囲を選びます。

アドレスプールの大きさは、同時に維持できるマッピング数を決めます。一般的なデスクトップ利用で、むやみに範囲を広げる必要はありません。広すぎると既存ネットワークと重複しやすくなります。マッピングには有効期間があり、アプリがキャッシュした一時アドレスはその期間内に認識され続ける必要があります。アプリがDNSを長くキャッシュし、コア再起動後にマッピングが消えると、古い接続が一時的に失敗することがあります。その場合はアプリのDNSキャッシュを消して再問い合わせすればよく、古い一時アドレスをhostsへ書き込まないでください。

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

例のアドレス範囲は基準を示すためのものです。有効化前に、現在の端末とネットワークが同じ範囲を使用していないことを必ず確認してください。

FakeDNSへ送るドメインを決める

すべての問い合わせを一度にFakeDNSへ切り替えることは推奨しません。内部ドメイン、LAN機器名、ローカルDNSの回答が必要なゾーンは実際の解決を残します。まず、ドメインルーティングが必要でTUNに取り込まれる外部ドメインだけをFakeDNSへ送ります。その他の問い合わせは対応するリゾルバーで処理します。分類範囲が明確であるほど、問題がマッピング、実際の解決、ルーティングルールのどこにあるか判断しやすくなります。

一部のアプリはDNS結果を比較したり、直接接続のUDPセッションを確立したり、アドレスをシステム外の別端末へ渡したりします。このような処理は一時アドレスに適さない場合があります。通常のTUNでは正常でFakeDNSを有効にすると失敗するアプリがある場合、まずそのアプリが使用するドメインに実際の解決を行う例外を設定し、すぐにFakeDNS全体を無効化しないでください。例外が有効になってから、対象アプリのドメイン集合を広げる必要があるか判断します。

FakeDNSとトラフィック嗅探は併用できますが、役割は異なります。FakeDNSは問い合わせ段階でマッピングを作り、取り込まれたDNSリクエストに適しています。嗅探は接続内容からドメインを復元し、マッピングがないもののハンドシェイクにドメインが含まれる通信に適しています。同時に有効にする場合は、ログでドメインの復元元を確認してください。復元されたドメインやルール結果に問題があるときは、どちらか一方を無効にしてテストし、どの経路で最終ドメインが得られたかを切り分けます。

マッピングの流れに沿って失敗を切り分ける

最初に、アプリの問い合わせがコアDNSへ入っているかを確認します。取り込まれていなければ通常の実IPが返され、FakeDNSマッピングは作成されません。次に、返却アドレスが設定したアドレスプールに属するかを確認します。続いて接続を開始し、TUNが一時アドレスを捕捉しているかを確認します。その後、コアがマッピングからドメインを復元できるかを確認し、最後に復元されたドメインがどのルーティングルールに一致したかを確認します。この5段階を順に検証すれば、停止箇所を正確に特定できます。

一時アドレスが返るのに接続ログがない場合は、システムルートまたはTUNの取り込みに問題があります。接続ログはあるのにドメインを復元できない場合は、コア再起動でマッピングが失われていないか、アプリが古いアドレスをキャッシュしていないかを確認します。ドメインが正しく復元されるのに誤ったアウトバウンドへ進む場合は、ルーティングルールの順序へ戻ります。正しいアウトバウンドに一致しても失敗する場合は、実際のDNSとアウトバウンド接続を調べ、FakeDNSをさらに変更しないでください。

設定後は、初回問い合わせ、再問い合わせ、コア再起動後の古いキャッシュ、LAN名を個別にテストします。初回と再問い合わせではマッピングの再利用を確認し、再起動テストではアプリキャッシュの復元動作を確認し、LANテストでは実際の解決例外を検証します。FakeDNSが安定している状態とは、ドメイン振り分けを説明でき、内部リソースに影響せず、再起動後も再問い合わせで復旧できることです。すべてのDNS結果が一時アドレスになることではありません。

各サブスクリプションの役割を定義する

2つ目のサブスクリプションを追加する前に、それが何を解決するのかを明確にします。仕事環境、端末用途、プロトコル対応、予備関係などで分けられますが、「エントリが増えるから」という理由だけで提供元を追加しないでください。各サブスクリプションには固有のメモ、明確な更新方法、独立したフィルター条件を設定します。2つの提供元に同名エントリが多い場合は、名前の先頭に短いグループ識別子を加え、ログや現在のサーバー欄から提供元を判別できるようにします。

メインのサブスクリプションは日常の選択に使い、予備はメイン提供元の更新失敗時や特定環境でのみ有効にし、テスト用は自動選択の対象外にします。役割をグループメモに書いておけば、一括更新や整理の判断基準になります。すべての購読を常時有効にして混在表示すると、古いエントリ、重複エントリ、テスト設定を誤って選ぶ可能性が増え、パラメータ変更の提供元も分からなくなります。

サブスクリプションごとにプロトコルフィールドやコア拡張が異なる場合があります。インポートに成功しても、現在のコアで完全に動作するとは限りません。XrayとV2Flyの機能差はXrayコアとV2Flyコアの違いで確認できます。v2rayNはデスクトップで主な設定管理を担い、Androidではコアの要件に応じてv2rayNGまたはv2flyNGを使います。クライアント間で移行するときは、標準の共有URLまたは対応するサブスクリプション形式を移行し、クライアント固有の設定がそのまま交換できるとは考えないでください。

更新順序と失敗時の復元を決める

一括更新は「予備—テスト—メイン」の順で実行します。先にメイン以外のグループを更新し、サブスクリプション形式の変更、フィルターの無効化、重複処理の異常を早期に発見します。インポート構造が正常だと確認してからメイングループを更新します。更新中は現在接続中のエントリを変えず、新しい一覧を確認してから切り替え、更新と接続切り替えを同時に行わないでください。

サブスクリプションの更新に失敗しても、すぐにグループを削除して追加し直さないでください。まず返却エラーを記録し、リクエスト経路とURLの有効性を確認してから、個別に更新します。削除と再作成では、グループのフィルター、更新方針、ローカルメモが失われ、古いエントリと新しいエントリの対応関係も消えます。再作成が必要な場合は、先にグループ設定をエクスポートするか重要項目を記録し、新しいグループには一時的な名前を付けて検証後に置き換えます。

更新結果について4点を確認します。エントリの構成が妥当か、現在のエントリが残っているか、フィルター後に選択可能な項目があるか、プロトコルフィールドを現在のコアが認識できるかを確認してください。購読内容は変化するため、固定の件数には依存しません。重要なのは数ではなく構造の比較です。更新後に一覧が突然空になったら、まずフィルターを無効にします。一覧はあるのにすべて起動できない場合は、コア互換性と共有フィールドの変更を確認します。

重複エントリとローカルコピーを処理する

重複判定をメモだけで行わないでください。同じ名前でも異なるアドレスやプロトコルの場合があり、名前が違っても同じサーバーを指すことがあります。整理前に少なくともアドレス、ポート、プロトコル、トランスポート、セキュリティ設定、サーバー名を比較します。クライアントの自動重複排除が一部のフィールドしか対象にしない場合、機能的に同じエントリが残ることがあります。逆に名前だけで手動削除すると、用途の異なる設定を誤って消す可能性があります。

サブスクリプションのエントリを変更する必要がある場合は、ローカルコピーを作り、メモに「ローカルテスト」と提供元グループ名を加えます。コピーはサブスクリプション更新の対象外となり、トランスポートパラメータ、ルーティング方針、コアの違いを比較するために使えます。テスト後は有効な変更を保守可能な設定元へ反映するか、説明の明確なローカルエントリとして残します。追跡できないコピーを大量にためないでください。数回更新すると元の設定から離れてしまいます。

ローカルのルーティング、DNS、TUN設定は通常クライアント単位の設定であり、各サーバーエントリへ複製すべきではありません。サーバー接続パラメータとローカルネットワーク方針を分けると、購読を切り替えてもルーティングの動作がリセットされず、問題がサーバー側かローカル方針か判断しやすくなります。特定サーバー専用のアウトバウンド経路が必要な場合だけ、カスタム設定で明確に参照します。

移行時は説明できる設定だけを持ち出す

移行前に、サブスクリプションURL、グループメモ、フィルター式、現在のサーバー、ルーティング、DNS設定、TUNオプションを一覧化します。まず新しい端末で購読を追加して基本接続を確認し、次にフィルターとルーティング、最後にDNS、TUN、FakeDNSを移行します。生成設定全体を異なるシステムへ直接上書きしないでください。インバウンドの待受アドレス、仮想NIC、ファイルパス、権限要件が異なる可能性があります。

移行後の最初のテストでは、同じ基準サーバーと同じ対象群を使います。サーバー接続は正常なのにルールだけ異なる場合は、ルーティング順序と分類データベースを比較します。ドメイン動作が異なる場合は、システムDNS、コアDNS、アプリ設定を比較します。TUNだけ異常なら、新しいシステムの権限、ルート、ファイアウォールを確認します。層ごとに移行すると手順は増えますが、各段階に明確な復元ポイントを持てます。

複数購読の管理が完了したら、各グループの役割、フィルターの意味、移行順序を記録したテキストの設定説明を残すことを推奨します。サーバーの機密フィールドを保存する必要はなく、構造だけを記述します。こうすれば、クライアント画面が変わったり再インストールしたりしても、古い画面位置の記憶に頼らず役割に沿って復元できます。

最小限のアウトバウンド集合から始める

保守しやすい設定には、少なくともメインプロキシ、直接接続、ブロックのアウトバウンドが必要です。メインプロキシは現在のサーバー接続を担い、directはコアがローカルネットワークから対象へ接続し、blockは明確に不要なリクエストを終了します。まず3つが動作することを確認してから、予備プロキシ、特定インターフェースへの直接接続、チェーンアウトバウンドを追加します。アウトバウンドが増えるほど、ルーティングタグ、DNS経路、ログの判断が複雑になります。

各アウトバウンドには一意で安定したtagを設定します。タグは画面上の名前ではなく、ルーティングルール、DNS問い合わせ、他のアウトバウンドをつなぐ参照点です。proxy-main、proxy-backup、direct-workのように、小文字の英字とハイフンを使うことを推奨します。タグを変更したら、設定内のすべての参照を検索してください。1箇所でも漏れると、コアが起動できなかったり、通信がフォールバックへ流れたりします。

クライアントが現在のサーバーから自動生成するプロキシアウトバウンドは、サーバー切り替え後に変わる場合があります。カスタムルールがクライアントの固定論理タグを参照するなら、切り替え後もタグが存在することを確認します。手動で作成したアウトバウンドを直接参照する場合は、そのアウトバウンドを独立して保存してください。生成設定全体をコピーして現在のサーバーを固定しないでください。購読の切り替えや更新が機能しなくなります。

{
  "outbounds": [
    {
      "tag": "proxy-main",
      "protocol": "vless",
      "settings": {
        "vnext": [
          {
            "address": "server.example",
            "port": 443,
            "users": [
              {
                "id": "00000000-0000-4000-8000-000000000000",
                "encryption": "none"
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "tcp",
        "security": "tls",
        "tlsSettings": {
          "serverName": "server.example"
        }
      }
    },
    {
      "tag": "direct",
      "protocol": "freedom"
    },
    {
      "tag": "block",
      "protocol": "blackhole"
    }
  ]
}

例のアドレスと識別子は構造を示すためだけのものです。実際の接続パラメータには有効な設定を使用してください。

directアウトバウンドの範囲を明確にする

directはコアを迂回するという意味ではなく、リクエストがコアに入った後、freedomアウトバウンドがローカルネットワークから接続することを示します。そのためコアDNS、アドレスファミリー方針、アウトバウンドのバインド設定の影響を受けます。LAN、内部ドメイン、明確に直接接続する分類は通常directへ送りますが、ルール順序が正しいことを確認してください。TUNがdirect通信を取り込む場合は、そのアウトバウンド接続がシステムルートによって再びTUNへ送られないようにします。

複数NIC環境では、特定のdirectアウトバウンドに送信インターフェースや送信元アドレスを指定し、仕事用ネットワークと通常ネットワークを分けられます。設定前にインターフェース名が安定していることを確認し、対象サブネットへそのインターフェースから到達できるか検証します。スリープ、ネットワーク切り替え、インターフェース再作成後は、バインド名が無効になる場合があります。「標準directは正常だがカスタムdirectは失敗する」場合は、まずバインドを外して基準状態へ戻し、インターフェースと送信元アドレスを確認してください。対象ルーティングを先に変更しないでください。

ブロックアウトバウンドは、明確に一致した通信だけを受け取るようにします。blockの一致は通常、リモートのタイムアウトではなく、ローカルですぐ失敗する形で現れます。ログにblockへの到達が記録されているなら、サーバーを調べ続ける必要はありません。切り分けやすいようにブロックルールをまとめ、目的を記載し、複数のプリセットやカスタム一覧へ分散させないでください。

プロキシチェーンは慎重に使う

チェーンアウトバウンドでは、1つのプロキシアウトバウンドが別のアウトバウンドを通じて接続を確立します。明確なネットワーク構成がある場合に有効ですが、接続層が1つ以上増えます。各層でサーバー解決、ルーティング、トランスポート、エラー処理が必要です。設定前に各アウトバウンドを単独で検証してから参照関係を作り、チェーンが失敗したら最外層の接続からログを確認して、リクエストが実際にどの層へ到達したかを確認します。

アウトバウンドの参照ではループを避けます。proxy-aがproxy-b経由で接続し、proxy-bもproxy-a経由なら、どちらも基本接続を確立できません。より見つけにくいループはルーティングで発生します。proxy-bのサーバーアドレスがルールによってproxy-aへ送られ、proxy-aもproxy-bに依存するケースです。チェーン内のサーバーアドレスには優先度の高いルールを設定し、directまたは前段のどのアウトバウンドを通るか明示します。

チェーン設定ではDNSも考慮します。各サーバーのドメインをどの層が解決し、問い合わせがどのアウトバウンドを通り、結果がTUNに取り込まれるかを事前に決めてください。最も安定する方法は、直接解決できる入口サーバーで第1層を確立し、その後の接続を確立済みのアウトバウンドへ通すことです。最下層の接続を最上層のDNS経路に依存させないでください。

タグで設定全体を一周検証する

カスタムアウトバウンドの設定が完了したら、すべてのタグと参照元を一覧化します。各ルーティングルールが参照するアウトバウンドが存在し、各チェーン参照が単独で確立可能な前段アウトバウンドを指し、DNS専用アウトバウンドが自身に依存せず、TUNの除外経路がプロキシサーバー接続をカバーしていることを確認します。その後、どのルールからも参照されていないアウトバウンドを確認します。未参照だから必ず誤りとは限りませんが、古い設定の残骸や、想定したルールがまだ作られていない可能性があります。

• メインプロキシアウトバウンドで明確にプロキシを通すドメインをテストし、ログでタグを確認します。
• directでLANと明確に直接接続する対象をテストし、TUNインバウンドへ戻っていないことを確認します。
• 一時的な具体的ルールで予備アウトバウンドをテストし、完了後に一時ルールを削除します。
• 明確にブロックする対象へアクセスし、ログにローカルのblock一致が表示されることを確認します。
• コア再起動後にもう一度テストし、古い接続やキャッシュだけで正常に見えていないかを確認します。

設定が起動できない場合は、まずJSON構造を確認し、次にタグの重複、未知のアウトバウンド参照、プロトコル必須フィールドを調べます。起動できるのに経路が誤っている場合は、最初に一致したルーティング項目を確認します。経路は正しいのに接続できない場合は、対象アウトバウンド自体を調べます。起動エラー、ルーティングエラー、接続エラーを同じ変更で処理しないでください。

これで、サブスクリプション、フィルター、ルーティング、DNS、TUN、FakeDNS、アウトバウンドが一つの流れとしてつながります。新しいルールを追加するときは、リクエストの入口から経路に沿って層ごとに判断し、最終エラーから設定全体を推測しないでください。基本環境を作り直す必要がある場合は使い方ガイドに戻って基本手順を実行し、クライアントやデスクトップ版を変更する場合はV2Rayクライアントダウンロードページを開きます。設定後は構造説明と動作する基準設定を残し、次回の調整では変数を1つだけ変更してください。