V2Ray config.json Explained: inbounds, outbounds, and routing

1. How requests flow through config.json

config.json is the configuration file read by the core. It is not a subscription link or a client settings file. Subscriptions typically provide node details; the client uses node, routing, and local listener settings to generate the core config. Understanding this distinction helps you decide whether to make a change in node settings, routing settings, or a custom config.

inbounds defines where requests enter, outbounds defines how they leave, and routing selects the route for each request. A browser must send its traffic to a local proxy port before routing rules can handle it. Changing routing alone won't route every app through the proxy.

This article uses the JSON config format commonly found in V2Ray. V2Fly and Xray share some fields, but supported protocols, options, and command-line arguments vary by core. v2rayNG uses the Xray core, while v2flyNG uses the V2Fly core. On desktop, check which core v2rayN is actually using rather than relying on the client name alone.

2. Complete config: two inbounds, direct connection, and blocking

Here’s a complete example config for learning: a SOCKS listener at 127.0.0.1:10808 and an HTTP listener at 127.0.0.1:10809. Requests to example.org and its subdomains are blocked; all other requests go direct by default. There is no remote proxy node, so this config cannot be used as a remote proxy.

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "socks-in",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      }
    },
    {
      "tag": "http-in",
      "listen": "127.0.0.1",
      "port": 10809,
      "protocol": "http",
      "settings": {}
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "blocked",
      "protocol": "blackhole",
      "settings": {}
    }
  ],
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": [
          "domain:example.org"
        ],
        "outboundTag": "blocked"
      },
      {
        "type": "field",
        "ip": [
          "10.0.0.0/8",
          "172.16.0.0/12",
          "192.168.0.0/16",
          "127.0.0.0/8",
          "::1/128"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "inboundTag": [
          "http-in"
        ],
        "outboundTag": "direct"
      }
    ]
  }
}

This is strict JSON: keys and strings use double quotes, with no comments or trailing commas. Arrays can contain multiple objects, but each object must follow the field definitions for its protocol. Don’t treat a “node name” shown in the UI as a core config key, or add a top-level subscription field arbitrarily; subscription management is a client feature.

3. inbounds: listen address, port, and inbound tag

listen is the local bind address, not the remote node address. port is the local port apps connect to, not the server port. Setting the listener to 127.0.0.1 accepts connections only from the local IPv4 loopback interface. Listening on all network interfaces expands access and affects LAN security; it isn't a general fix for connection failures.

tag is an identifier used within the config. A routing rule can reference the inbound tag socks-in with inboundTag. The tag doesn't determine the protocol or create an outbound with the same name. Use a unique, stable tag for each inbound and outbound, and update every reference when renaming one.

In this example, udp: true only allows UDP on the SOCKS inbound. The app must support SOCKS UDP ASSOCIATE, and the outbound route must carry that traffic. Enabling this option doesn't send all system UDP traffic through the core, nor does a regular HTTP system proxy capture game traffic.

4. outbounds: protocol implementation and default route

In this example, freedom means direct connection and blackhole means block; direct and blocked are user-defined tags. Renaming direct to office-direct won't change its behavior, but you must also update every outboundTag that references it.

If no routing rule matches, the core uses the first item in the outbounds array. In this example, direct is first, so traffic that doesn't match a blocking rule or a rule for a specific inbound still goes direct. Move the blocking outbound to the first position, and many unmatched requests will be blocked. That's a change to the default route, not a node that suddenly stopped working.

5. routing: rule order, condition combinations, and DNS resolution

routing.rules are checked from top to bottom in array order. The first matching rule determines the outbound; the core doesn't continue looking for a “more specific” match. Put specific exceptions first and broader rules later. If the first rule matches all TCP and UDP traffic, later domain rules will never take effect.

1. Check the destination domain first. If a request targets example.org or one of its subdomains, the first rule selects blocked. domain: matches the domain and its subdomains; use full: to match one exact domain.
2. Next, check the destination IP. The private and loopback addresses listed in this example go through direct. This matches IP ranges; it doesn't necessarily apply just because a domain might resolve to a private address.
3. Then check the inbound. The third rule matches requests from http-in and routes them direct. Requests already matched by the domain-blocking rule won't reach this one.
4. Finally, use the default outbound. Requests from socks-in that don't match either of the first two rules use the first array entry, direct.

Within a rule, different condition fields generally need to match together. For example, specifying both inboundTag and domain means the domain must come through the specified inbound. Multiple entries in a domain array are alternatives. Mistaking an “or” condition for a rule that combines multiple fields is a common reason traffic doesn't route as expected.

domainStrategy sits inside routing and controls how domains are handled during route matching. AsIs doesn't resolve domains just to match IP rules; IPIfNonMatch tries resolving a domain after it fails to match; IPOnDemand triggers resolution when a rule requires IP information. It isn't a switch that sends all DNS traffic through a proxy.

6. Add a proxy outbound: confirm the upstream, then update references

A remote proxy requires valid server details. The address, port, identity, and transport security settings for VMess, VLESS, and other outbound protocols must match the server; changing only the protocol name doesn't convert a config. For an existing node, import it through the client and inspect the generated config rather than manually combining protocol fields from different cores.

To demonstrate adding an outbound and referencing it, the example below uses a local SOCKS upstream. It assumes another independent service is listening at 127.0.0.1:10810 and requires no authentication. Add this object to the outbounds array. It's a config snippet, not a complete file.

{
  "tag": "proxy",
  "protocol": "socks",
  "settings": {
    "servers": [
      {
        "address": "127.0.0.1",
        "port": 10810
      }
    ]
  }
}

• Adding this object alone won't change existing traffic. A rule must reference proxy through outboundTag, or you must move it to the first position in the outbound array to handle unmatched traffic.
• To route all unmatched requests through the upstream, put proxy first in the outbound array and keep any necessary direct-connection exceptions. Adjust the example's existing direct rule for http-in as needed.
• Don't point the upstream port back to your own 10808; that can create a loop. Even on a different port, the upstream must not send the same request back to this instance.
• SOCKS doesn't provide transport encryption. This loopback upstream is only for illustrating config structure; when connecting to a remote server, choose a transport appropriate to the protocol and network boundaries.

7. Validate the config and find v2rayN's save location

Validation has three layers: whether the JSON parses, whether the core accepts the fields, and whether real requests follow the intended rules. None can replace the others. Valid JSON doesn't guarantee referenced tags exist, and a successful core startup doesn't mean the system proxy points to the right port.

1. Back up the original file. Keep a copy that starts successfully. Change one category at a time, such as ports or routing, so you can roll back easily.
2. Check with the matching core. Run the help command for the bundled core first to confirm the config test options for that version. Use the same core that will run the config; don't rely on results from a different core.
3. Check the startup logs. If the logs report a listener failure, check the address or port. If config loading fails, check field types and protocol settings. You can temporarily set loglevel to info while troubleshooting, then restore it afterward.
4. Run two specific tests. Test the direct outbound first, then the blocking rule. Specify the port explicitly to avoid interference from another app's proxy settings.

curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 5 https://example.com/
curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 5 https://example.org/
curl --proxy http://127.0.0.1:10809 --connect-timeout 5 https://example.com/

socks5h sends the target hostname to the proxy for resolution, making it useful for testing this example's domain rules. If the destination is reachable from the public internet, the first and third requests should attempt to connect through the direct outbound, while the second should be blocked. Exact errors depend on the core and curl version; don't infer which rule matched from an error code alone—check the logs too. On Windows, run curl.exe explicitly if a terminal alias intercepts the command.

In v2rayN, check local listener ports under Settings → Parameter Settings, then review the active routing config under Settings → Routing Settings. Group names and labels may vary by version, so follow the current UI. The config used to run a regular node is often regenerated by the client. Direct edits to a generated file may be overwritten when you switch nodes, update subscriptions, or restart the core.

8. Common config questions

When looking up field definitions, use the JSON reference to check the listener, outbound, and routing sections. For troubleshooting, follow the same sequence: is the app using the proxy, is the inbound listening, does a rule match, and can the outbound connect? Test one layer at a time to find the cause more easily than changing DNS, ports, and protocol settings all at once.