V2Ray設定ファイルの構造を徹底解説：inbounds・outbounds・routing

まず設定の外側の構造を理解する

V2RayとXrayの実行設定には、通常JSONを使用します。最上位オブジェクトでよく使われるのは log、inbounds、outbounds、routing、dns です。リクエストの入口、経路の選択、出口を実際に決めるのは、inbounds・routing・outboundsの3つです。

1つの接続は、決まったデータの流れとして捉えられます。ブラウザーなどのアプリがまずローカルの待ち受けポートへ接続し、コアが宛先を識別して、ルーティング規則に従って送信先を選びます。サブスクリプションのノード情報は主にoutboundsへ入り、クライアントのルーティングモードがroutingを生成します。システムプロキシの設定は、アプリの通信をinboundsへ渡す役割を担います。

次のサンプルにはリモートノードを含めず、SOCKSリクエストをローカルから直接送信します。JSON構造、ポートの待ち受け、ルーティングの読み込みが正常かを確認するのに適しています。コアはこの設定を読み込んで実行できますが、リモートプロキシ機能は提供しません。

{
  "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": "direct",
      "protocol": "freedom"
    },
    {
      "tag": "blocked",
      "protocol": "blackhole"
    }
  ],
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

inbounds：ローカルアプリからコアへ入る場所

inbounds は配列なので、1つの設定で複数の入口を同時に待ち受けできます。たとえばSOCKSを10808、HTTPを10809で待ち受けます。システムプロキシは通常HTTPの入口を指定し、SOCKSに対応したアプリは127.0.0.1:10808へ直接接続できます。実際のポートはクライアントが生成する設定に依存するため、すべての環境が同じだとは限りません。

listen は待ち受け範囲を決めます。127.0.0.1ならローカルのプログラムだけが接続できます。LANアドレスや全アドレスで待ち受けると、アクセス可能な範囲が変わります。一般的なデスクトップ利用では、ローカル待ち受けのままで問題ありません。「接続が拒否されました」と表示されたら、まずコアが起動中か確認し、次にアプリのポートと実際のinboundポートが一致しているか確認します。

• tag：inboundの内部名で、routing内の inboundTag から参照できます。名前は自由に設定できますが、参照時は完全に一致させる必要があります。
• protocol：入口で使用するプロトコルを指定します。デスクトップクライアントではSOCKSまたはHTTPのinboundが生成されることが多く、TUNモードではクライアントが対応する仮想ネットワーク入口を構築します。
• settings：そのinboundプロトコル固有のパラメータを保存します。SOCKSの例にある udp: true は、UDPリクエストの処理を許可する設定です。
• sniffing：接続内容から宛先ドメインを復元し、ドメイン規則をマッチングに利用できるようにします。速度測定のスイッチではなく、リモートノードのプロトコルを直接変更する機能でもありません。

SOCKS入口を確認する際は、まずコアのログに「127.0.0.1:10808で待ち受け中」のような記録が出ているか確認し、次にSOCKS5対応ツールからそのアドレスへ接続します。ドメイン規則を使う場合は、テストツールがドメインの名前解決をプロキシ側へ渡すようにしてください。ローカルで先にIPへ解決すると、ドメインによるマッチング条件が失われることがあります。

outbounds：リモートプロトコルのパラメータと出口タグ

outbounds も配列です。通常、最初のoutboundがデフォルトの出口を担い、後続のoutboundを直結・ブロック・別ノードとして利用できます。各outboundは tag、protocol、settings、必要に応じて streamSettings で構成されます。routingにサーバーアドレスを直接記入するのではなく、outboundTag でここに定義したoutboundを選択します。

VLESSとVMessのアカウント情報は通常 settings.vnext に配置され、サーバーアドレス、ポート、ユーザー識別子などを含みます。TCP、WebSocket、TLSなどの転送・セキュリティパラメータは streamSettings にあります。2つの階層を混同しないでください。リモートアカウントが正しくても、転送経路が間違っていればハンドシェイクで接続に失敗します。

{
  "tag": "proxy-main",
  "protocol": "vless",
  "settings": {
    "vnext": [
      {
        "address": "edge.example.com",
        "port": 443,
        "users": [
          {
            "id": "00000000-0000-4000-8000-000000000001",
            "encryption": "none"
          }
        ]
      }
    ]
  },
  "streamSettings": {
    "network": "tcp",
    "security": "tls",
    "tlsSettings": {
      "serverName": "edge.example.com"
    }
  }
}

上記のアドレスとユーザー識別子は、項目の配置を示すための例にすぎず、実際のノード接続には使えません。実際の設定はサブスクリプションまたはサーバー側のパラメータから生成してください。手動で確認する場合は、まず protocol、次に address と port、続いてユーザー識別子、最後に network、TLSサーバー名、WebSocketパスを確認します。

freedom は宛先へ直接接続する機能で、一般的なタグはdirectです。blackhole はマッチした接続を終了させる機能で、一般的なタグはblockedです。どちらもリモートサーバーのパラメータを必要としません。設定にproxy・direct・blockedの3種類のoutboundを用意すると、routingでプロキシ、直結、ブロックを個別に実行できます。

routing：規則は順番にマッチし、名前から動作を判断しない

routing.rules は順序を持つ規則配列です。コアは最初の規則から順に確認し、マッチするとその規則の outboundTag を使います。通常、後続の規則で結果が上書きされることはありません。そのため、より具体的な規則を前に置き、広範なフォールバック規則を後ろに置きます。

type: "field" はフィールド条件によるマッチングを示します。よく使う条件には domain、ip、port、network、inboundTag、protocol があります。同じ規則に異なる種類の条件を複数入れた場合は、通常すべてを満たす必要があります。同じフィールド内の複数の値は、いずれか1つに一致すればマッチします。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "domain": ["domain:example.net"],
        "outboundTag": "blocked"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy-main"
      }
    ]
  }
}

domainStrategy: "AsIs" は主にリクエストに含まれるドメインまたはIPをそのまま処理します。IPIfNonMatch はドメイン規則にマッチしなかった場合にIPを解決し、IP規則で判定します。DNS設定とsniffingの結果を考慮して選択し、単に名前解決の回数が多い選択肢を速いと判断しないでください。

最後の network: "tcp,udp" は広範なフォールバックです。これを1番目に移すと、ほとんどのTCP・UDPリクエストがproxy-mainに直接マッチし、後続のプライベートアドレス直結規則が機能しなくなります。「規則はあるのに振り分けが効かない」よくある原因です。

クライアントが生成する設定はどこを変更するか

v2rayN 7.xは、ノード、ルーティング、コアのオプションから実行設定を生成します。実行時ファイルを直接編集しても現在のプロセスでしか有効にならず、ノード切り替え、サブスクリプション更新、コア再起動で再生成される場合があります。長く保持したい変更は、できるだけクライアントの該当画面から行ってください。

基本設定は「設定」→「パラメータ設定」から確認できます。ノードのパラメータは「サーバー」一覧で対象を選び、編集画面を開いて調整します。ルーティング関連は「設定」→「ルーティング設定」で管理してください。小さなバージョン差でメニュー名が少し異なる場合がありますが、変更対象はinbound、ノードoutbound、ルーティング規則の3層です。

1. 現在動作している設定をコピーするか、クライアント設定をエクスポートして、戻せる基準を残します。
2. 一度に変更する項目は1つにします。たとえば待ち受けポートだけを変更し、保存後すぐにコアを再起動します。
3. まずJSONを読み込めることを確認し、次にローカルポート、最後に特定ドメインのルーティング結果をテストします。
4. ルーティングを変更したら、対象ドメイン、マッチした規則、最終的なoutboundTagを記録します。
5. サブスクリプション更新後はカスタム設定を再確認し、クライアントがサブスクリプションの項目でローカル設定を上書きしていないか確認します。

v2rayNGでXrayコアを使う場合も、対応する実行設定が生成され、項目の考え方はデスクトップ版と近いものになります。v2flyNGでv2flyコアを使う場合は、そのコアが実際に対応しているプロトコルと項目を基準にしてください。Xrayの拡張パラメータをv2flyコアの設定へそのままコピーできない場合があります。未知の項目エラーが出たら、まずコアの系統を確認します。

読み込み失敗とルーティング異常の切り分け手順

設定の問題は、JSONを解析できない、コアは起動するがinboundが使えない、コアとinboundは正常だがルーティング結果が想定と違う、の3種類に分けられます。この順で確認すれば、構文エラーをノード障害と誤認せずに済みます。

ポートテストに成功したら、次にリモートハンドシェイクのログを確認します。VLESSとVMessでは、アドレス、ポート、ユーザー識別子、転送方式、セキュリティ層が一つの組み合わせとして一致している必要があります。1項目だけ変更するとTCP接続は成功しても、その後TLS、WebSocket、プロトコル認証の段階で切断されることがあります。

routingを確認するときは、ウェブページが開くかどうかだけを見ないでください。コアのアクセスログを開き、対象ドメインまたはIPに対応するoutboundTagを確認するほうが確実です。規則を変更したら既存の接続を閉じてリクエストをやり直してください。確立済みの長時間接続は新しいoutboundへ自動で切り替わりません。

• ステップ1：JSONの解析に成功し、コアが起動時に終了していないことを確認します。
• ステップ2：127.0.0.1とinboundポートが待ち受け中で、アプリのプロキシアドレスが完全に一致していることを確認します。
• ステップ3：リモートoutboundのプロトコル、ポート、ユーザーパラメータ、転送パラメータが一致していることを確認します。
• ステップ4：対象リクエストが想定した規則にマッチし、存在するoutboundTagが選択されていることを確認します。
• ステップ5：接続を作り直し、古いセッションやキャッシュ結果がテストへ与える影響を除外します。

設定を理解するうえで重要なのは、すべての項目を暗記することではなく、階層を明確に保つことです。inboundsは「通信がどのように入るか」、outboundsは「通信がどこから出るか」、routingは「このリクエストがどの出口を選ぶか」を決めます。エラーが発生したら、実際のリクエストの流れに沿って各層を確認すると、問題を1つのポート、1つの規則、または1組のプロトコルパラメータまで絞り込めます。