V2Ray設定ファイル完全ガイド

V2RayとXrayのメイン設定は、トラフィック処理パイプラインを表すJSONオブジェクトとして捉えられます。inboundsが接続を受け付け、ルーティングが行き先を判断し、outboundsが接続を実行します。DNSとポリシーのオブジェクトは、このパイプラインに名前解決やリソース制御を加えます。

トップレベルオブジェクトは実行手順の一覧ではない

設定ファイルの最外層は1つのJSONオブジェクトで構成され、一般的なキーにはlog、dns、inbounds、outbounds、routing、policy、statsがあります。これらのキーは、通常、本文中の記述順で実行順が決まるわけではありません。JSONオブジェクトはキー名で構造を表し、記述位置で処理の流れを表すものではないためです。順序が意味を持つ主な場所は配列です。たとえばrouting.rulesは先頭から順に照合され、最初に一致したルールがoutboundを決めます。複数のinboundsとoutboundsも、それぞれのtagを通じて他のオブジェクトから参照されます。

設定を読むときは、まずすべてのタグを記録し、その後に参照関係をたどって確認する方法が安全です。あるinboundのタグはルーティングルールのinboundTagで使われ、outboundのタグはoutboundTagから指定され、DNSサーバーもtagを介してルーティングルールと結び付く場合があります。タグは設定内部の識別子にすぎず、自動的にトラフィック分岐を発生させるものではありません。存在しないタグをルールに記述すると、起動時にエラーになる場合もあれば、該当経路の実行時にトラフィックの行き先がなくなる場合もあります。具体的な挙動はコアとフィールドの位置によって異なります。

{
  "log": {
    "loglevel": "warning"
  },
  "dns": {
    "servers": ["1.1.1.1", "localhost"]
  },
  "inbounds": [
    {
      "tag": "socks-in",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom"
    },
    {
      "tag": "blocked",
      "protocol": "blackhole"
    }
  ],
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

配列・オブジェクト・値の型

inbounds、outbounds、routing.rulesはいずれも配列なので角括弧を使います。単一のinbound、outbound、ルールはオブジェクトであり、波括弧を使います。ポートは数値で指定し、単位付きの文字列にはしません。真偽値はtrueまたはfalseだけです。フィールドの省略とnullは同じ意味ではありません。省略するとコアの既定動作が適用されますが、明示的な空値はフィールド定義が許可する場合にのみ意味を持ちます。起動失敗の多くはプロトコルの問題ではなく、括弧の閉じ忘れ、オブジェクト間のカンマ抜け、文字列での全角引用符の使用、配列であるべきフィールドを単一文字列にすることが原因です。

標準JSONではコメントを使用できず、最後のメンバーの後に末尾カンマを置くこともできません。Web上の例では説明のために//コメントを使うことがありますが、クライアントのコア設定へコピーする前に削除してください。v2rayN、v2rayNG、v2flyNGでは、グラフィカルな画面とは別に独自の設定層を管理している場合があります。画面上のノード、サブスクリプション、ルーティング設定は変換された後にコアへ渡されます。そのため手動編集の前に、編集対象がクライアント管理ファイル、生成済みの実行設定、独立したコアが読み込む設定のどれなのかを確認してください。ファイル名が似ているからといって、同じオブジェクトと判断してはいけません。

最小構成から段階的に複雑化する

設定を確認するときは、ローカルのinboundを1つ、明確に動作するoutboundを1つ、最小限のルーティングだけを残し、そこへDNS、スニッフィング、複数のトランスポート、統計ポリシーを段階的に追加してください。一度に複数のモジュールを追加すると、エラーの原因が互いに隠れてしまいます。たとえば接続失敗は、リモート側のパラメータ、誤ったDNS経路によるドメイン解決、または先行ルールが接続をblockedへ送ったことが原因かもしれません。最小化とは必要なセキュリティフィールドを削除することではなく、変数の連鎖を短くすることです。サーバー側が要求するアドレス、ポート、ユーザー識別子、トランスポート、セキュリティパラメータは維持し、通信に影響しない追加ルールだけを一時的に外します。

保存前に、文字コードがUTF-8であること、ファイルが1つのルートオブジェクトだけで構成されていること、キー名の大文字・小文字がフィールド定義と一致していることも確認してください。outboundTagとoutboundtagは別の名前です。プロトコル名も画面上の訳語から推測してはいけません。構造を確認したら、inbounds、outbounds、ルーティングの3部分を順に検証します。大きな設定でポートを何度も変更するより、結果を説明しやすくなります。

outboundは、ルーティングで選ばれた接続を目的地へ送ります。リモートのプロトコルサーバーへ接続することも、目的地へ直接アクセスすることも、接続を拒否することも、別のoutboundへ渡して処理を続けることもできます。

プロトコルフィールドは一体として確認する

リモートoutboundは通常、protocol、settings、streamSettingsで定義されます。VLESSを例にすると、サーバーアドレスとポートはvnext項目、ユーザー識別子はusersに入り、トランスポート方式、セキュリティ層、サーバー名はstreamSettingsに入ります。アドレス、ポート、ユーザー識別子だけを確認しても設定の一致は証明できません。クライアントとサーバーのトランスポート、TLS系セキュリティ設定、パス、ホスト名、関連する拡張パラメータも相互に対応している必要があります。

設定画面では、これらのフィールドが「アドレス」「ユーザー」「トランスポート」「セキュリティ」などのページに分かれていることがあります。一方、JSONでは隣接するオブジェクトにまとめられます。サブスクリプションのインポートに異常がある場合は、まずクライアントの詳細画面で各項目を確認し、ノードの表示名だけで判断しないでください。ノード名は通常、ローカルのメモにすぎず、プロトコルのハンドシェイクには関与しません。接続に影響するのは構造化されたフィールドです。手動でパラメータを移す場合、URIでエンコードされた文字列をそのままJSONの値として扱わないでください。また、画面で「デフォルト」を示す空欄を、勝手に"default"という文字列へ変換しないでください。

{
  "outbounds": [
    {
      "tag": "remote-vless",
      "protocol": "vless",
      "settings": {
        "vnext": [
          {
            "address": "server.example.com",
            "port": 443,
            "users": [
              {
                "id": "11111111-1111-4111-8111-111111111111",
                "encryption": "none"
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "ws",
        "security": "tls",
        "tlsSettings": {
          "serverName": "server.example.com"
        },
        "wsSettings": {
          "path": "/example-path",
          "headers": {
            "Host": "server.example.com"
          }
        }
      }
    },
    {
      "tag": "direct",
      "protocol": "freedom"
    },
    {
      "tag": "blocked",
      "protocol": "blackhole"
    }
  ]
}

directとblockedは明確な処理経路

freedom outboundは通常、目的地へ直接接続するために使われ、directというタグを付けることが多いです。blackholeはルールで選ばれた接続を終了するために使われ、blockedと名付けるのが一般的です。これらのタグは慣例的な名称にすぎないため変更できますが、ルーティング側の参照も同時に更新する必要があります。freedomをoutbounds配列に置くだけでローカルアドレスが自動的に直結されるわけではなく、該当するトラフィックをルールで指定する必要があります。同様に、blackholeを定義しただけではどのドメインも自動的に遮断されません。

どのルールにも一致しない場合、コアは通常、デフォルトoutboundを選択しますが、具体的な挙動は設定構造とコアの実装によって異なります。設定を読む人が暗黙の順序に依存しないよう、大規模な設定では重要なトラフィックに明示的なルールを記述し、用途が分かるoutboundタグを使うのが適切です。リモート、直接接続、ブロック用outboundの名称には、混同しやすい連番ではなく用途を反映させてください。名称が明確なら、ログのoutbound識別子も設定と対応付けやすくなります。

outboundチェーン・プロキシ設定・ループ

一部のコアでは、proxySettingsなどの仕組みにより、あるoutboundが別のoutboundを経由して接続を確立できます。明確に設計された多段出口には有効ですが、DNS、ハンドシェイク、障害切り分けの層が増えます。チェーンの各段には一意のタグを付け、AがBを指し、BがAを指すような循環を作らないでください。リモートサーバーのドメイン名をどう解決するかも別途検討が必要です。最初の接続を確立するためのDNS問い合わせが、まだ確立していないoutboundに依存すると、起動後もタイムアウトが続く循環が発生します。

チェーン構成を確認するときは、まず物理接続を最後に担当する単一のoutboundを単独で動作させ、そこから前段へ一層ずつ追加してください。ログに「接続が閉じられました」としか出ない場合は、outboundタグを手がかりに、どの層で失敗したかを判断します。リモート側の拒否、ドメイン解決の失敗、TLSサーバー名の不一致、ローカルルーティングによる誤ったoutbound選択は、いずれもアプリでページを開けないという同じ症状に見えることがあります。すべてのプロトコルパラメータを同時に置き換えるより、層ごとの検証の方が証拠を残せます。

デスクトップではv2rayNでノードとコア設定を管理するのが基本です。Androidでは、使用するコアに応じてv2rayNGまたはv2flyNGを選択できます。XrayとV2Flyの位置付けを比較したい場合は、XrayとV2Flyのコアの違いも参照してください。コアの系統によって対応フィールドの範囲が異なる場合があるため、複雑な設定を移行する前に、移行先クライアントで実際に有効なコアを確認してください。

DNS設定は、コアがドメイン名を解決するときにどのサーバーへ問い合わせるか、特定のドメインをどの解決経路へ優先的に送るかを決めます。OSのDNS、アプリ独自の名前解決、ルーティング段階の解決とは別の層です。

まず、誰が問い合わせを開始したかを区別する

アプリはシステム層で先に名前解決を行い、宛先IPだけをプロキシへ渡すことがあります。ドメイン名をそのままSOCKSやHTTP inboundへ渡すこともあり、独自の暗号化DNSを使うアプリもあります。トップレベルのdnsオブジェクトが直接制御できるのは、コアに入り、コア自身が実行する問い合わせだけです。設定を変更しても期待した変化がない場合は、inboundが受け取ったのがドメイン名かIPかを確認し、スニッフィングでドメイン名が復元されたかも確認してください。dns.serversを変更するだけで、すべてのシステムプログラムに独自の解決経路を強制できるわけではありません。

serversには単純なアドレスだけでなく、address、domains、expectIPs、skipFallbackなどを持つオブジェクトも指定できます。単純な配列は単一経路に適し、オブジェクト形式はドメインごとにサーバーを選ぶ場合に適しています。サーバー一覧は常に「1番目が失敗したら2番目を使う」という従来型の予備サーバーとして動作するわけではありません。ドメインの絞り込み、フォールバック設定、コアの実装が問い合わせ先を決めます。複雑なDNSを設計する前に、役割の明確な2台のサーバーで検証し、その後にドメイン範囲とフォールバック制限を追加してください。

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

hosts・domains・期待する結果

hostsは、特定の名前に静的な対応付けを提供します。少数の安定したローカルサービス名には適していますが、大規模で変動するドメイン一覧には向きません。静的マッピングは優先度が高いため、アドレス変更後に更新を忘れると、「特定の名前だけが古いアドレスを指し続ける」状態になります。確認時は、OSのhostsファイル、クライアント画面のホスト上書き項目、コア設定のdns.hostsを同時に調べ、複数の層が競合していないか確認してください。

サーバーオブジェクトのdomainsは、そのサーバーへ渡すドメインを絞り込みます。構文はルーティングのドメイン条件に近いものの、用途は異なります。前者はリゾルバーを選び、後者は接続先のoutboundを選びます。expectIPsは、返されるアドレスが想定範囲に入るかを制約するために使いますが、任意の応答を対象範囲へ書き換えるものではありません。制約が狭すぎると正常な応答も除外され、フォールバックへ進む可能性があります。skipFallbackは、そのサーバーがフォールバックに参加する方法に影響します。組み合わせる前に、「ドメイン選択—サーバー問い合わせ—結果確認—接続ルーティング」の4段階を整理してください。

DNS問い合わせでoutboundを選ぶ仕組み

DNSサーバーのアドレス自体も接続を確立する必要があります。サーバーをドメイン名で指定すると、まずリゾルバーのドメイン名をどう解決するかという問題が生じます。IPで指定すればこの層は省けますが、ネットワークのoutboundは依然としてルーティングで選ばれます。複雑な設定では、DNSトラフィックにタグを付け、ルーティングでそのタグやプロトコルに応じて特定のoutboundへ送ることがあります。この場合は循環を避けてください。リモートoutboundがドメイン解決に依存し、そのドメイン解決もまだ確立していないリモートoutbound経由を要求すると、循環が発生します。

説明可能な経路を作るには、まずリモートサーバーのアドレスに安定した基礎解決経路を用意し、その後で通常の対象ドメインをどう分岐するか決めます。domainStrategyとDNSルールを併用すると、IP条件を判定するためにルーティングが行う解決もDNSモジュールへ入ります。そのため、表面的にはルーティングの問題でも、実際にはDNSサーバーの選択やフォールバック結果が原因かもしれません。ログは最後のタイムアウトだけを切り取らず、問い合わせ、アドレス取得、outbound選択、接続先の順に時系列で確認してください。

キャッシュ・IPv4・IPv6の選択

queryStrategyは、問い合わせ結果として返すアドレスファミリーを制限または優先するために使います。対応範囲はコアによって異なります。アドレスファミリーを1種類に限定すると、ローカルネットワークの不完全な接続性を回避できる場合がありますが、本来到達可能な宛先まで除外する可能性があります。まずOSが対象のネットワークへ接続できるか確認し、そのうえで問い合わせを制限するか判断してください。クライアント、コア、システムリゾルバーのいずれも結果をキャッシュする可能性があるため、DNS変更直後の再試行で新しい問い合わせが発生するとは限りません。関連するクライアントプロセスを再起動し、接続を再確立する方法はありますが、キャッシュ削除を恒久的な設定解決策と考えないでください。

「ドメインでは接続できないが、直接IPなら接続できる」場合は、まず問い合わせがアドレスを返しているか確認し、次にそのアドレスがルーティングで想定したoutboundへ送られているかを調べます。「一部のドメインで断続的に失敗する」場合は、失敗時と成功時に選ばれたDNSサーバー、アドレスファミリー、outboundタグを比較してください。サーバーを変更するだけでは、リゾルバー経路の検証はできても、ルール条件の確認にはなりません。一般的なクライアントの接続手順と検証方法は、入門ガイドで順に確認できます。

リモートプロトコルは認証情報とリクエスト形式を定義し、streamSettingsはそれらのデータをネットワーク接続上でどう運ぶかを定義します。両端のプロトコルパラメータが正しくても、トランスポート層が一致しなければ接続は完了しません。

networkが後続の設定オブジェクトを決める

streamSettings.networkはトランスポートの種類を指定します。一般的な設定にはTCP、WebSocket、gRPC、mKCPなどがあります。ネットワーク種別を選んだら、WebSocketならwsSettings、gRPCなら対応するサービス名設定など、該当する設定オブジェクトを使います。別のトランスポート用フィールドを残しても自動的に組み合わされるわけではなく、かえって設定を読み違える原因になります。ノードを移行するときは、まず画面に表示されたトランスポート種別を確認し、その専用フィールドを展開して一つずつ照合してください。

トランスポート種別は、クライアント側だけで最適化できる項目ではありません。サーバーが待ち受けるトランスポート、パス、サービス名に合わせて、クライアントも同じ構造で接続する必要があります。エラーが出たときにTCP、WebSocket、gRPCを頻繁に切り替えると、通常は変数が増えるだけです。元の設定に基づいてトランスポートを固定し、アドレスが解決できるか、ポートへ到達できるかを確認してから、パス、ホストフィールド、セキュリティ層を確認する方が安全です。

{
  "streamSettings": {
    "network": "grpc",
    "security": "tls",
    "tlsSettings": {
      "serverName": "edge.example.com",
      "allowInsecure": false,
      "alpn": ["h2"]
    },
    "grpcSettings": {
      "serviceName": "example-service",
      "multiMode": false
    },
    "sockopt": {
      "tcpKeepAliveIdle": 100
    }
  }
}

WebSocketのパス・Host・TLS名

WebSocket設定のpathはHTTPハンドシェイクのパスです。先頭にスラッシュを付けるか、クエリ部分を含めるかも、サーバー側の入口と一致させる必要があります。headers.HostはWebSocketハンドシェイクのヘッダーであり、tlsSettings.serverNameはTLSサーバー名の検証に使われます。両者は同じ場合もありますが、構成によって異なる場合もあります。1つのフィールドとして同時に置き換えると、一方だけ成功して他方が失敗する可能性があります。

サーバーアドレスaddressは最初に接続するホストを決め、TLS名は証明書とハンドシェイクの対象名を決め、WebSocketのHostはHTTP層で処理されます。確認時は、接続確立の順序に沿って3つを理解してください。アドレスへのTCP接続は確立できるのにTLSが失敗する場合は、システム時刻、サーバー名、セキュリティパラメータを重点的に確認します。TLS成功後にWebSocketが拒否される場合は、パスとHostを確認します。証明書検証を安易に緩めることはエラーを見えにくくするため、通常の修復方法にしないでください。

gRPC・mKCP・トランスポート固有フィールド

gRPC設定では通常、正確なserviceNameが必要で、HTTP/2関連のネゴシエーションにも依存します。サービス名は設定値であり、ノードのメモではありません。URL形式のスラッシュを自分で追加することも避けてください。中間層が必要な接続方式に対応していない場合、ハンドシェイク直後に切断されることがあります。mKCPはUDPベースのトランスポートであり、双方のパラメータだけでなく、現在のネットワークがUDPを安定して運べるかにも依存します。TCPへ到達できても、UDP経路が利用できるとは限りません。

トランスポート固有パラメータが多い場合は、まずクライアントにノード情報から生成させた構造を使い、明確な要件がある箇所だけを変更してください。インターネット上の異なるコアや時期の例には、すでに変更されたフィールド名が含まれていることがあります。v2rayNは通常デスクトップ用コアの管理に対応し、v2rayNGはXrayのコア経路、v2flyNGはV2Flyのコアを対象とします。同じ名前のトランスポートでも基本概念は近い一方、拡張フィールドが完全に一致するとは限りません。対応範囲が不明な場合は、不要な拡張を削除し、サーバーが要求する基本フィールドを残してください。

security・TLS・Realityの階層

securityは有効にするセキュリティ層を決めます。対応する設定オブジェクトも一致していなければなりません。TLSパラメータはtlsSettingsに置き、Realityパラメータはコアが定める独立した設定オブジェクトを使います。security文字列だけを置き換えて、古いフィールドをすべて流用することはできません。サーバー名、公鍵関連パラメータ、短い識別子、フィンガープリントの選択は、特定のセキュリティ方式に固有のハンドシェイク条件です。同じ有効な設定から取得してください。

セキュリティ層のエラーとユーザー識別子のエラーは、画面上ではどちらも接続テスト失敗に見えることがあります。そのためログでは、DNS、TCP、TLS、プロトコル認証のどの段階で発生したかを区別する必要があります。サーバーポートに接続すらできないなら、サーバー名を変更しても意味がありません。TCP接続が確立しているのにセキュリティハンドシェイクが失敗する場合は、先にルーティングを変更しないでください。障害の層を特定してからパラメータを変更すれば、エラーの形だけを一時的に変えて根本原因を残すことを避けられます。