V2Ray設定ファイルの構造を段階的に解説:inbounds、outbounds、routingの役割

まず全体像を確認：設定ファイルは1つのノードではない

V2Ray 5.xでは、JSONを使ってコアの動作を記述します。完全なクライアント設定には、通常サーバーアドレスやユーザーIDだけでなく、本機でトラフィックを受け取る入口、外部へ送る出口、DNSの動作、ログレベル、ルーティングルールも定義します。GUIクライアントに表示される「1つのノード」は、主にプロキシoutbound内のサーバーパラメータ群に対応するもので、実行設定全体と同じではありません。

設定を読むときは、まずプロトコルの細部を置いておき、データの流れを3段階で考えると分かりやすくなります。アプリがリクエストをローカル待受ポートへ渡し、inboundsが受信してリクエストを識別し、routingがドメイン、IP、ポート、プロトコルに応じて宛先を選び、最後にいずれかのoutbounds項目が送信します。inboundとoutboundはtagで名前を付け、ルーティングルールがその名前を参照します。

トップレベルの項目には固定された記述順序がなく、routingをoutboundsより前に書いても、JSONパーサーが実行結果を変えることはありません。ただし、配列内の順序には意味がある場合があります。ルーティングルールは通常上から順に照合され、どのルールにも一致しないトラフィックは先頭のoutboundに渡されます。そのため、読む際はtagと配列内の位置の両方を確認します。

inbounds：トラフィックは本機のどこから入るか

inboundsは配列で、各オブジェクトが1つのローカル入口を表します。デスクトップクライアントでは、SOCKSとHTTPのinboundを同時に作成する方法が一般的です。たとえばSOCKSを127.0.0.1:10808、HTTPを127.0.0.1:10809で待ち受けます。ブラウザー、コマンドラインツール、システムプロキシが対応するポートへリクエストを送ると、コアがその接続の処理を開始します。

listenは待受アドレスを決めます。127.0.0.1なら本機からの接続だけを受け付け、0.0.0.0ならすべてのネットワークインターフェースで待ち受けるため、LAN内の端末からそのポートへアクセスできる可能性があります。LANプロキシが明確に必要でない限り、デスクトップ用途ではループバックアドレスが適しています。portは他のプログラムが使用していない必要があり、重複するとログにbindやaddress already in useが表示されることがあります。

protocolは入口側のプロトコルを示すもので、リモートノードのプロトコルではありません。SOCKS inboundのリクエストをVLESSやVMess outboundへ渡すこともでき、両者のプロトコルを一致させる必要はありません。settingsには、そのinboundプロトコル固有のパラメータを保存します。SOCKS inboundでよく使われるudp: trueは、UDPリクエストの受信を許可する設定です。

sniffingは、接続内容から宛先ドメインを復元するために使います。アプリが先にドメインをIPへ解決し、その後ローカルプロキシへ接続する場合があります。コアにIPしか見えていなければ、ドメインで記述したルーティングルールに一致しません。嗅探を有効にしてdestOverrideを設定すると、コアは対応するHTTPやTLSトラフィックからドメインを識別し、routingの判定に渡せます。

{
  "tag": "socks-in",
  "listen": "127.0.0.1",
  "port": 10808,
  "protocol": "socks",
  "settings": {
    "auth": "noauth",
    "udp": true
  },
  "sniffing": {
    "enabled": true,
    "destOverride": ["http", "tls"]
  }
}

• tagは現在の設定内で一意であればよく、socks-inやlan-inなど読みやすい短い名前を使えます。
• システムプロキシは、システムプロキシ設定に対応したトラフィックだけをHTTPまたはSOCKS入口へ送ります。すべてのプログラムの通信を捕捉するわけではありません。
• ポートを変更した後は、呼び出し側も同じように変更する必要があります。コアの設定だけを変えてシステムプロキシを変えないと、接続がすぐ拒否されます。
• UDPが正常に動作するかどうかは、アプリ、inboundプロトコル、outboundプロトコル、サーバー設定にも左右されます。

outbounds：ノード、直接接続、ブロック用の出口

outboundsも配列です。プロキシノードは通常そのうちの1項目にすぎず、実際のクライアントは直接接続用とブロック用の出口も生成します。プロキシ出口はVMessやVLESSなどのプロトコルでリモートサービスへ接続し、freedomはコアから宛先へ直接アクセスさせ、blackholeはルールで選ばれた接続を終了させます。

プロキシoutboundはさらに2層に分けて考えられます。settingsはプロトコルの認証情報やサーバーポートを記述します。たとえばVMessのアドレス、ポート、ユーザーID、セキュリティパラメータなどです。streamSettingsはTCP、WebSocket、TLS、Realityなど、下位のトランスポートとセキュリティ層を記述します。プロトコル項目が正しくても、トランスポート経路、SNI、セキュリティ層が一致しなければ接続は失敗します。

outboundのtagは、設定を調査する際に最も重要な索引です。ルーティングルールに"outboundTag": "direct"とあれば、outboundsに戻ってtagがdirectのオブジェクトを探します。存在しないtagをルールが参照すると、コアは通常起動時に設定エラーを報告し、出口を自動的に推測することはありません。

サブスクリプションで提供されるのは通常ノードの接続パラメータであり、ローカルポート、ログレベル、すべての振り分けルールまで決めるものではありません。v2rayN、v2rayNG、v2flyNGはサブスクリプションをインポートすると、ノード項目とクライアント固有の設定を統合し、コアへ渡す実行設定を生成します。そのため、同じサブスクリプションでもクライアントによって生成される完全なJSONは異なる場合があります。

routing：リクエストを順番に指定の出口へ渡す

routing.rulesはルールの配列です。よく使うタイプはfieldで、domain、ip、port、network、protocol、inboundTagなどの条件で照合できます。ルール自体はデータを転送せず、outboundTagによって処理を担当するoutboundを指定します。

ルールの順序によって結果が変わります。1つ目のルールが特定のドメインをプロキシへ送り、2つ目がより広いドメイン集合を直接接続へ送る場合、そのドメインは1つ目に一致した時点で照合を終了します。より具体的なブロックまたは強制プロキシのルールを前に置き、対象範囲の広い直接接続ルールや最終フォールバックルールを後ろに置きます。

domainStrategyは、ルーターがドメインのIPアドレスをいつ解決するかを決めます。AsIsは元のドメインを優先して照合し、IPルールのために自動で解決しません。IPIfNonMatchはまずドメインルールを確認し、一致しなければIPを解決してIPルールを試します。IPOnDemandはIPが必要になりそうなルールに遭遇した時点で、より早く解決を開始します。どれを選ぶかはルール設計によって決まり、積極的な設定ほどよいわけではありません。

どのルールにも一致しない場合、V2Rayは通常、先頭のoutboundを使用します。暗黙の順序に依存しないように、TCPとUDPをカバーするフォールバックルールを末尾に追加し、対象のoutboundTagを明示するとよいでしょう。こうすればoutboundsの順序を変更しても、デフォルトの通信方向が意図せず変わることはありません。

{
  "domainStrategy": "IPIfNonMatch",
  "rules": [
    {
      "type": "field",
      "protocol": ["bittorrent"],
      "outboundTag": "block"
    },
    {
      "type": "field",
      "ip": ["geoip:private"],
      "outboundTag": "direct"
    },
    {
      "type": "field",
      "domain": ["geosite:cn"],
      "outboundTag": "direct"
    },
    {
      "type": "field",
      "network": "tcp,udp",
      "outboundTag": "proxy"
    }
  ]
}

読みやすい最小クライアント設定

以下の例では、ログ、1つのSOCKS inbound、3つのoutbound、4つのルーティングルールを同じファイルにまとめています。例のアドレスとユーザーIDは構造を示すためだけのもので、実際のノードとしては使用できません。設定ファイルは標準JSONで記述し、キー名と文字列には二重引用符を使います。末尾に余分なカンマを残したり、コメントを直接挿入したりすることはできません。

データの流れとしては、アプリがまず127.0.0.1:10808へ接続します。コアがルーティングを確認し、BitTorrentの通信はblockへ、プライベートアドレスと指定されたドメイン集合はdirectへ、それ以外のTCPとUDPリクエストはproxyへ送ります。proxyはVMess、WebSocket、TLSを使い、例示サーバーの443ポートへ接続します。

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "socks-in",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      },
      "sniffing": {
        "enabled": true,
        "destOverride": ["http", "tls"]
      }
    }
  ],
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vmess",
      "settings": {
        "vnext": [
          {
            "address": "server.example.com",
            "port": 443,
            "users": [
              {
                "id": "00000000-0000-4000-8000-000000000000",
                "alterId": 0,
                "security": "auto"
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "ws",
        "security": "tls",
        "tlsSettings": {
          "serverName": "server.example.com"
        },
        "wsSettings": {
          "path": "/v2ray"
        }
      }
    },
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ],
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "protocol": ["bittorrent"],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

1. まずJSONの構文を確認します。特に二重引用符、カンマ、角括弧が正しく対応しているかを見ます。
2. すべてのtagが一意で、routingが参照するoutboundTagが実際に存在するか確認します。
3. inboundポートが使用中でないことを確認し、システムプロキシまたはアプリを同じポートへ向けます。
4. プロキシoutboundのプロトコル、サーバーポート、トランスポート方式、セキュリティ層が対応しているか確認します。
5. 最後にルールの順序を確認し、フォールバックルールがより具体的なルールの後ろにあることを確認します。

GUIクライアントとコアJSONの対応関係

v2rayN、v2rayNG、v2flyNGはいずれも、よく使う項目をフォームに分けて表示します。ノード編集画面のアドレス、ポート、ユーザーID、トランスポート方式、セキュリティ設定は主にプロキシoutboundへ対応します。ローカルSOCKSポートやLAN接続の許可などはinboundsへ、ルーティングモード、ルールセット、カスタムルールはroutingへ対応します。

v2rayNを例にすると、ローカルポートや基本動作は通常「設定」→「パラメータ設定」から変更し、ノードのパラメータはサーバー編集画面で変更します。クライアントがコアを起動すると、ノード、全般設定、ルーティング設定を実行設定にまとめます。一時的に生成されたコアJSONを直接編集しても、次回のノード切り替え、サブスクリプション更新、コア再起動で再生成される場合があります。

Androidのv2rayNGとv2flyNGも似た層構造を採用していますが、使用するコアは異なります。v2rayNGはXrayコア、v2flyNGはv2flyコアを使用します。一部の高度な項目やデフォルト値には差があるため、あるクライアントが出力した完全な設定を、別のクライアントの画面設定ファイルとしてそのまま使うことはできません。

ログの順序に沿って起動失敗と振り分けミスを調べる

設定の問題は、起動段階と実行段階に分けられます。起動段階の失敗は、JSON構文、項目の型、ポートの重複、無効なtagなどが原因であることが多く、コアがinboundの待受を開始する前に停止することもあります。実行段階で発生する問題は、ノードパラメータ、DNS、ルールの一致、対象ネットワークに関係することが多くなります。

問題調査では、一度に複数の区画を変更しないでください。まずloglevelをwarningから一時的にinfoへ変更し、問題を1回再現して時刻を記録します。inboundが待ち受けていないのか、ルールが誤った出口を選んだのか、proxy outboundの接続に失敗したのかを確認してから、該当する区画を変更します。解決後はwarningに戻すと、通常のログ量を減らせます。

• JSON解析エラーが表示される：エラー行付近のカンマ、二重引用符、配列とオブジェクトの閉じ記号を確認します。
• コアは起動したがポートが待受状態にならない：listen、port、ポートの使用状況を確認し、同じアドレスとポートを2つのinboundで使っていないか確認します。
• アプリがすぐに接続拒否を表示する：アプリのプロキシアドレスが127.0.0.1で、ポートが実際のinboundと一致しているか確認します。
• ノードには接続できるが振り分けが誤っている：routing.rulesを上から下へ確認し、宛先が最初に一致したルールを特定します。
• ドメインルールにまったく一致しない：sniffingが有効か、DNSが想定した結果を返しているか、ルールがドメイン条件とIP条件のどちらを使っているか確認します。
• 一部のUDPアプリだけが失敗する：SOCKS inboundがUDPを許可しているか確認し、outboundプロトコル、サーバー、ネットワークがその通信に対応しているか調べます。

{
  "log": {
    "loglevel": "info"
  }
}

ログのinbound tag、宛先アドレス、outbound tagをつなげると、通信経路全体を追跡できます。たとえばリクエストがsocks-inから入り、宛先が特定のドメインとして表示され、最終的にdirectが選ばれた場合、その接続にはノード自体が関与していません。プロキシを通す想定なら、VMessやVLESSの認証パラメータを繰り返し変更するのではなく、routingを確認します。

反対に、ログですでにルールがproxyを選んだことが示され、その後にTLSハンドシェイクや接続タイムアウトが発生するなら、ルーティングの役割はほぼ完了しています。この場合は、プロキシoutboundのアドレス、ポート、SNI、トランスポート経路、システム時刻、リモート側への到達性を確認します。