V2Ray Configuration File Explained: inbounds, outbounds, and routing

Understand the outer configuration structure first

V2Ray and Xray typically use JSON for runtime configuration. The most common top-level objects are log, inbounds, outbounds, routing, and dns. The three sections that determine how requests enter, which path they take, and where they leave are inbounds, routing, and outbounds.

Think of a connection as a fixed data chain: a browser or another app first connects to a local listening port, the core identifies the destination, and routing rules select an outbound. Subscription nodes mainly populate outbounds, the client's routing mode generally generates routing, and system proxy settings tell apps to send traffic to inbounds.

The example below contains no remote node; it sends SOCKS requests directly from the local machine. Use it to verify JSON structure, port listening, and routing initialization. The core can load and run this configuration, but it does not provide remote proxy access.

{
  "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: where local apps enter the core

inbounds is an array, so one configuration can listen on multiple entry points at once. For example, SOCKS can listen on 10808 and HTTP on 10809. System proxy settings usually point to the HTTP entry, while apps that support SOCKS can connect directly to 127.0.0.1:10808. The actual ports come from the client-generated configuration; do not assume every installation uses the same values.

listen controls the listening scope. With 127.0.0.1, only programs on the same machine can connect. Using a LAN address or listening on all interfaces changes who can access the port. For typical desktop use, keep it bound to localhost. If you see “connection refused,” first confirm that the core is running, then verify that the app's port matches the inbound port.

• tag: The inbound's internal name, referenced by inboundTag in routing. You may choose the name, but every reference must match it exactly.
• protocol: Specifies the entry protocol. Desktop clients commonly generate SOCKS or HTTP inbounds; TUN mode creates the corresponding virtual network entry through the client.
• settings: Stores parameters for that inbound protocol. In the SOCKS example, udp: true allows UDP requests to be handled.
• sniffing: Recovers the destination domain from connection content so domain rules can participate in matching. It is not a speed-test switch and does not directly change the remote node protocol.

To verify the SOCKS entry, first check whether the core log contains a line such as “listening on 127.0.0.1:10808,” then connect to that address with a SOCKS5-capable tool. When using domain rules, have the tool resolve domains through the proxy instead of resolving them locally first, or the domain-matching condition may be lost.

outbounds: remote protocol settings and exit tags

outbounds is also an array. The first outbound usually serves as the default exit; later entries can provide direct connections, blocking, or other nodes. Each outbound consists of tag, protocol, settings, and optional streamSettings. routing does not contain server addresses directly; it selects one of these outbounds through outboundTag.

VLESS and VMess account details usually go under settings.vnext, including the server address, port, and user ID. Transport and security parameters such as TCP, WebSocket, and TLS belong in streamSettings. Do not mix the two layers: even with valid remote credentials, an incorrect transport path will still fail during the handshake.

{
  "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"
    }
  }
}

The address and user ID above only demonstrate where fields belong; they cannot be used to connect to a real node. Real configurations should come from a subscription or server-side parameters. When checking manually, start with protocol, then review address and port, verify the user ID, and finally check network, the TLS server name, and the WebSocket path.

freedom connects directly to the destination; direct is a commonly used tag. blackhole terminates matched connections; blocked is a common tag. Neither requires remote server parameters. Keeping proxy, direct, and blocked outbounds together lets routing handle proxying, direct connections, and blocking separately.

routing: rules match in order, not by name

routing.rules is an ordered array. The core checks rules from top to bottom and, after a match, uses that rule's outboundTag; later rules normally do not override the result. Put specific rules first and broad fallback rules last.

type: "field" matches requests by field conditions. Common conditions include domain, ip, port, network, inboundTag, and protocol. Multiple condition types in one rule generally must all match; multiple values within the same field match any one of those values.

{
  "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" mainly uses the domain or IP already present in the request; IPIfNonMatch tries to resolve the domain to an IP when no domain rule matches, then lets IP rules participate. Choose a strategy based on your DNS settings and sniffing results, rather than assuming the option that performs more lookups is faster.

The final network: "tcp,udp" rule is a broad fallback. If moved to the top, most TCP and UDP requests will match proxy-main immediately, making the later private-address direct rule ineffective. This is a common reason for traffic splitting to fail even though all the rules appear to be present.

Where to edit client-generated configurations

v2rayN 7.x generates its runtime configuration from the selected node, routing settings, and core options. Direct edits to a runtime file may last only for the current process; switching nodes, updating a subscription, or restarting the core can regenerate it. For changes that should persist, make them through the corresponding client settings whenever possible.

To view basic options, go to “Settings” → “Parameter Settings.” To adjust node parameters, select a target in the “Servers” list and open its editor. Maintain routing-related settings under “Settings” → “Routing Settings.” Menu names may vary slightly between minor releases, but the targets remain the same three layers: inbounds, node outbounds, and routing rules.

1. Back up the currently working configuration or export the client settings to keep a rollback baseline.
2. Change one field at a time—for example, adjust only the listening port—then restart the core immediately after saving.
3. First confirm that the JSON loads, then test the local port, and finally test the routing result for a specific domain.
4. When changing routing, record the destination domain, the matching rule, and the final outboundTag.
5. After a subscription update, review your custom settings again to confirm the client has not overwritten local changes with subscription fields.

When v2rayNG uses the Xray core, it also generates a corresponding runtime configuration, with a structure similar to the desktop client. When v2flyNG uses the v2fly core, follow the protocols and fields actually supported by that core. Some Xray extension parameters cannot be copied directly into a v2fly core configuration; if you see an unknown-field error, first confirm which core family is running.

Troubleshooting order for load failures and routing issues

Configuration problems fall into three groups: invalid JSON, a core that starts but has an unusable inbound, and a core with working inbounds whose routing results are unexpected. Checking them in this order helps prevent syntax errors from being mistaken for node failures.

After the port test passes, inspect the remote handshake logs. The VLESS or VMess address, port, user ID, transport, and security layer must form a complete combination. Changing only one field may allow the TCP connection to open before it fails during TLS, WebSocket, or protocol authentication.

When verifying routing, do not rely only on whether a webpage opens. A more reliable approach is to enable the core access log and confirm the outboundTag selected for the destination domain or IP. After changing rules, close existing connections and make a new request, because an established long-lived connection will not automatically switch to a new outbound.

• Step 1: Confirm that the JSON parsed successfully and the core did not exit during startup.
• Step 2: Confirm that 127.0.0.1 and the inbound port are listening, and that the app's proxy address matches exactly.
• Step 3: Confirm that the remote outbound protocol, port, user parameters, and transport parameters match.
• Step 4: Confirm that the request matched the intended rule and selected an outboundTag that exists.
• Step 5: Establish a new connection to eliminate interference from old sessions and cached results.

The key to understanding a configuration is not memorizing every field, but keeping the layers clear: inbounds determine “how traffic enters,” outbounds determine “where traffic leaves,” and routing determines “which exit this request uses.” When errors occur, follow the actual request path layer by layer; the issue usually narrows down to one port, one rule, or one set of protocol parameters.