Router and Bypass Gateway V2Ray Core Deployment Overview: Architecture Choices and Key Considerations

Running the V2Ray or Xray core on a router is usually not about adding another manually configured SOCKS proxy. The goal is to let a unified gateway identify traffic, apply routing rules, and handle DNS for devices on the local network. Deployment stability depends on the gateway’s position, Linux networking capabilities, core configuration, rule data, and hardware performance—not simply on whether the configuration file starts successfully.

Choose the gateway position first: main router or bypass gateway

Running on the main router means the device responsible for the WAN connection, NAT, DHCP, and firewall also runs the core. The path is shortest, clients do not need a new default gateway, and new devices on the LAN can enter the rule set automatically. The trade-off is that every network function is concentrated on one device: a core failure, bad rule, or lack of memory can affect the entire LAN.

A bypass gateway usually shares the main router’s subnet. The main router continues handling the WAN connection, while the bypass gateway forwards traffic and applies transparent proxying for selected devices. This makes separate restarts and rollbacks easier, and allows you to test with one computer or Android device before expanding coverage. However, a bypass gateway does not take over traffic automatically after being connected: the client default gateway, DHCP settings, and static routes must be configured explicitly.

Before choosing, map the actual traffic path. For example, if the bypass gateway is 192.168.1.2 and the main router is 192.168.1.1, the default gateway of managed devices should point to 192.168.1.2, while the bypass gateway’s default route should point to 192.168.1.1. If clients still use the main router as their default gateway, the bypass gateway’s transparent proxy rules will never see their traffic.

How to assess the core, firmware, and processor

“V2Ray support” on a router may only mean that the firmware can run a particular binary; it does not guarantee all the capabilities required for transparent proxying. At minimum, verify the processor architecture, that the system can execute the target core, that sufficient storage is available, that the service manager can start the process, and that the networking stack supports policy routing and transparent forwarding.

The V2Ray core works well with existing VMess, VLESS, and common transport configurations. Xray is more commonly used for VLESS, transparent proxying, and newer transport capabilities. Their configuration structures are similar, but fields are not universally interchangeable. A subscription URL also cannot normally be read directly by a router core as a configuration file; a management layer usually parses the subscription first and generates outbound settings in the core’s required format.

Processor performance cannot be judged by core count alone. Two quad-core devices can differ substantially because of clock speed, cache, encryption instructions, and thermal design. Memory is shared by the core, rule data, DNS cache, logs, and firmware services. Older devices with only 128 MB of RAM are more likely to reclaim memory or terminate the process after loading large GeoSite data.

Key configuration fields and the transparent entry point

A gateway configuration should include at least four sections: inbounds, outbounds, routing, and logging. The dokodemo-door inbound is commonly used for transparent proxying, with followRedirect enabled to receive the original destination after firewall redirection. Give outbounds clear tags such as proxy, direct, and block, then reference those tags in the routing rules.

The following is a structural example with real server addresses, credentials, and the complete DNS configuration omitted. It listens on 12345, accepts both TCP and UDP, and enables destination sniffing. In production, the outbound protocol and transport fields must match the node parameters.

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "transparent-in",
      "port": 12345,
      "protocol": "dokodemo-door",
      "settings": {
        "network": "tcp,udp",
        "followRedirect": true
      },
      "sniffing": {
        "enabled": true,
        "destOverride": ["http", "tls"]
      },
      "streamSettings": {
        "sockopt": {
          "tproxy": "tproxy"
        }
      }
    }
  ],
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vless",
      "settings": {
        "vnext": []
      }
    },
    {
      "tag": "direct",
      "protocol": "freedom"
    },
    {
      "tag": "block",
      "protocol": "blackhole"
    }
  ],
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": ["geoip:cn"],
        "outboundTag": "direct"
      }
    ]
  }
}

Place geoip:private near the top to keep LAN, loopback, and reserved addresses out of the proxy outbound. Domain rules usually match against sniffing or DNS results first; if there is no match, the destination IP is evaluated. Rules run from top to bottom, so an overly broad rule placed first can hide more precise direct or blocking rules later.

• inbounds: Define the transparent entry point’s listen address, port, network type, and redirection behavior.
• outbounds: Store proxy, direct, and block exits; their tags must exactly match the routing rules.
• routing: Select the traffic exit based on domains, IPs, ports, inbound tags, and other conditions.
• dns: Determine which server resolves domains and whether DNS queries go through the proxy.
• log: For the first deployment, use warning or temporarily switch to info; after stabilization, avoid excessive long-term logging.

Transparent proxying, policy routing, and DNS loops

Transparent proxying is not handled by the core alone. The firewall selects traffic and applies a mark, policy routing sends marked packets to the local transparent entry point, and the core reads the original destination before selecting an outbound. TCP can use REDIRECT or TPROXY; UDP generally requires TPROXY to preserve destination information. The exact commands depend on the firewall backend used by the firmware.

The commands below show the core relationship between Linux policy routing and TPROXY. They are not a complete script that can be applied to every firmware. Before running them, verify that the required modules are present and exclude the gateway itself, LAN addresses, core outbound connections, and management ports; otherwise, traffic loops are likely.

ip rule add fwmark 1 table 100
ip route add local 0.0.0.0/0 dev lo table 100

iptables -t mangle -N V2RAY
iptables -t mangle -A V2RAY -d 0.0.0.0/8 -j RETURN
iptables -t mangle -A V2RAY -d 10.0.0.0/8 -j RETURN
iptables -t mangle -A V2RAY -d 127.0.0.0/8 -j RETURN
iptables -t mangle -A V2RAY -d 172.16.0.0/12 -j RETURN
iptables -t mangle -A V2RAY -d 192.168.0.0/16 -j RETURN
iptables -t mangle -A V2RAY -p tcp -j TPROXY --on-port 12345 --tproxy-mark 1
iptables -t mangle -A V2RAY -p udp -j TPROXY --on-port 12345 --tproxy-mark 1

The bypass gateway must also enable IPv4 forwarding. Check it with sysctl net.ipv4.ip_forward; only a return value of 1 confirms that it is enabled. If IPv6 is used, design separate IPv6 routing and firewall rules. When handling IPv4 only, make sure clients cannot bypass the gateway through an unmanaged IPv6 default route.

1. Use ip route first to confirm that the bypass gateway’s default route points to the main router.
2. Use ip rule to check whether mark 1 queries routing table 100.
3. Use firewall counters to confirm that test traffic is actually entering the custom chain.
4. Check that 12345 is being listened to by the target core and that both TCP and UDP are included.
5. Finally, inspect the core logs to distinguish “no traffic entered” from “the outbound connection failed.”

The most common DNS problem is a loop between the query path and the proxy path. For example, LAN devices use the bypass gateway as DNS, while the bypass gateway sends queries to an address that is intercepted again by transparent rules, causing timeouts or repeated connections. Give the DNS outbound an explicit tag, or exclude the local DNS process and upstream address in the firewall.

Identify performance bottlenecks with sustained load

Router throughput depends on the protocol, transport layer, encryption workload, connection count, and cooling. A webpage loading occasionally does not prove that performance is sufficient, and a short speed test may hide the issue behind burst CPU frequency. A better method is to sustain traffic for 10 minutes with a fixed node and network setup while recording throughput, CPU, memory, temperature, and packet loss.

One laboratory reference setup used a quad-core ARM Cortex-A53 at 1.5 GHz, 1 GB of RAM, a gigabit Ethernet port, and a 300 Mbps WAN connection. Direct throughput measured about 286 Mbps. With a single VLESS over TCP with TLS outbound enabled, sustained throughput was about 126 Mbps, CPU peaked at 91%, and device temperature rose from 54°C to 72°C. This only indicates a compute bottleneck in that hardware combination; it is not a substitute for testing the actual device.

If one CPU core stays near full utilization while the network port is not busy, the bottleneck is likely protocol processing or encryption. If CPU usage is low but packet loss rises, check the network driver, soft IRQs, and queueing. If speed declines gradually after several minutes, check temperature and throttling. Many short-lived connections also increase conntrack and memory pressure, so their behavior differs from a single-connection speed test.

A gigabit home network does not mean the gateway must deliver gigabit proxy throughput. It should at least cover the actual WAN speed while retaining about 20% compute headroom. If a 300 Mbps connection can sustain only 126 Mbps in testing, adding more rules will not fix the hardware bottleneck. Reduce the managed scope, use a more capable bypass gateway, or run high-load endpoints with standalone clients.

Pre-launch checks and common fixes

After deployment, do not rely only on the core status showing “running.” Complete validation should cover direct domains, proxied domains, LAN addresses, DNS queries, TCP, UDP, and recovery after a gateway restart. Also check configuration-file permissions, system time, and rule-data locations: certificate validation requires accurate time, while missing GeoIP or GeoSite files prevent the related rules from loading as expected.

• The client can reach both the main router and bypass gateway management addresses, and private-network traffic does not enter the proxy.
• Direct-connection rules for mainland China and proxy rules match their expected outbound tags separately.
• Only the planned DNS service listens on port 53; there is no duplicate binding.
• The transparent entry port 12345 is not exposed on the WAN interface.
• After a restart, the core, policy routes, and firewall rules recover in the correct order.
• Stopping the core has a clear fallback strategy so that all traffic is not sent to a dead port.

Keep both a bootable minimal configuration and the currently running configuration. Change only one variable at a time—for example, the core, rule data, or DNS upstream—and run the same validation set after each change. Reliable router deployment comes from observability, rollback, and repeatability, not from writing a large rule set once and never checking it again.