Can a Router Run the V2Ray Core Directly? A Practical Guide to Bypass-Router Deployment

Choose a Topology: Main Router or Dedicated Bypass Router

Running the core directly on a router means running a V2Ray or Xray process on the gateway device and using the firewall to send LAN traffic into it. Computers and Android devices do not need to enable v2rayN or v2rayNG separately; traffic can still be split according to gateway rules. This solves centralized device management, but it does not improve the node route, bandwidth, or latency by itself.

The main-router setup has the shortest path. Dial-up, DHCP, DNS, NAT, and transparent proxying all run on one device, reducing forwarding overhead and making the network layout easier to understand. However, a configuration mistake affects the entire home network. A core crash, DNS loop, or incorrect firewall rule can interrupt ordinary direct traffic as well.

The bypass-router setup moves proxying to a second device. The main router continues handling the uplink and basic networking, while the bypass router processes only selected clients. During testing, change the gateway on one test computer to the bypass router’s address first; after confirming stability, distribute it to more devices through DHCP. If the bypass router stops working, the main router can still restore ordinary network access.

Hardware Requirements: Enough RAM Does Not Mean Fast Forwarding

The core itself does not require much disk space or memory. What really affects performance is single-core speed, encryption workload, connection count, and cooling. A router advertised with gigabit Ethernet only promises the physical interface speed; it does not mean transparent proxying will still reach gigabit throughput. VMess, VLESS, and different transport combinations all consume CPU, while verbose logging and complex rules add further overhead.

Using OpenWrt 24.10.2 and Xray 25.6.8 as a deployment example, a single-connection download test on a quad-core ARM device reached about 936 Mbps direct, 612 Mbps with VLESS over TCP, and 438 Mbps with VMess over WebSocket. On a low-frequency dual-core device using the same route, the results were about 917 Mbps, 214 Mbps, and 156 Mbps. These figures are not universal benchmarks, but they show that port speed and proxied throughput are not directly equivalent.

• Check that the architecture matches the core binary. Common types include aarch64, armv7, and x86_64; binaries cannot be mixed.
• Make sure enough flash storage remains available. In addition to the core, leave room for Geo data, configuration backups, and log rotation.
• Run each load test for at least 15 minutes instead of checking only the instantaneous peak on a speed-test page. Throttling after the device heats up is closer to real home usage.
• Test TCP and UDP separately. A working webpage does not prove that video calls, games, or UDP-based DNS queries work correctly.

Config Delivery: A Subscription Link Is Not a Complete Core Config

v2rayN, v2rayNG, and v2flyNG are graphical clients that manage subscriptions, nodes, and runtime parameters. The V2Ray or Xray core reads structured configuration files; it does not automatically turn a typical subscription link into a complete transparent-proxy setup. A subscription containing only node details still lacks inbound ports, DNS, routing rules, log levels, and firewall integration.

A safer workflow is to validate the node parameters in a client first, then write the server address, port, user identifier, transport, and TLS-related fields into the router configuration. On desktop, open v2rayN “Settings” → “Parameter Settings” → “Core Type” to confirm the core family in use, then test connectivity with the same node. On Android, use v2rayNG to validate an Xray node and v2flyNG to validate a V2Fly configuration, but do not treat partial client-exported data as a complete transparent-proxy configuration for the router.

1. Confirm the Architecture

   Check the router’s system information for aarch64, armv7, or x86_64, and verify available flash storage and memory. Leave at least 80 MB of disk space and 256 MB of free memory whenever possible.

2. Validate the Node

   Connect to the same node in v2rayN, v2rayNG, or v2flyNG first. Record the address, port, user identifier, transport layer, TLS settings, and server name to rule out a node-side problem.

3. Choose the Core

   During desktop validation, open v2rayN “Settings” → “Parameter Settings” → “Core Type” and confirm whether the test uses Xray or V2Fly. Use the corresponding fields on the router rather than mixing core-specific features.

4. Generate the Config

   Set the inbound listener to the local address and a fixed port. For example, use 12345 for the transparent inbound and 10808 for a management SOCKS inbound, then add direct, proxy, and block outbounds.

5. Roll Out Gradually

   Have one test device use the bypass router as its gateway, then verify webpages, DNS, video, and UDP applications in order. After confirming that the logs show no connection loop, expand the gateway assignment through DHCP.

Transparent Proxy Essentials: Inbounds, Policy Routing, and DNS

Transparent proxying is not just opening a SOCKS port. A SOCKS port requires an application to connect actively, while a router intercepts traffic originally addressed to arbitrary destinations. The firewall must mark and redirect connections first; policy routing then sends the marked packets to the local transparent inbound, where the core uses the original destination to decide between proxying and direct access.

TCP can use redirect or TPROXY, while UDP generally needs TPROXY to preserve the destination information. If you handle TCP only, webpages may work while games, real-time calls, and some DNS requests bypass interception or fail. Recent OpenWrt releases generally use firewall4 and nftables. Commands from older iptables tutorials cannot be copied verbatim: the concepts are similar, but the syntax and attachment points differ.

{
  "inbounds": [
    {
      "tag": "transparent-in",
      "listen": "0.0.0.0",
      "port": 12345,
      "protocol": "dokodemo-door",
      "settings": {
        "network": "tcp,udp",
        "followRedirect": true
      },
      "streamSettings": {
        "sockopt": {
          "tproxy": "tproxy"
        }
      }
    }
  ],
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

The configuration above shows only the key structure on the core side. It does not include the node outbound and cannot replace firewall rules. Port 12345 must match the nftables redirect target. Exclude LAN addresses, multicast, router management addresses, and DHCP traffic first; otherwise, opening the gateway’s management page may send traffic back into the proxy.

Map the DNS Data Path Separately

• LAN devices typically send queries to the gateway’s port 53, and the gateway’s local resolver decides which upstream to use.
• If the core listens for DNS on port 1053, configure the local resolver to forward selected domains to 127.0.0.1:1053. Do not send 1053 back to port 53 and create a loop.
• Domains in mainland China and LAN domains can use local resolution. Domains that require proxying should use a remote resolver, with the corresponding connections sent through the proxy outbound.
• During troubleshooting, record the queried domain, returned address, and actual outbound. Seeing “DNS returned a result” is not enough to determine whether traffic splitting is correct.

Traffic Splitting: Exclude the LAN Before Choosing the Proxy Scope

Router traffic splitting requires both core rules and firewall rules. The firewall decides which traffic enters the core; the core decides which outbound handles it afterward. Changing only one layer leads to two common problems: LAN traffic that should stay direct gets intercepted, or the core has proxy rules but traffic never reaches the transparent inbound.

The minimum rule set should first keep basic networking functional, then add domain categories. Private, loopback, link-local, multicast, and required connections initiated by the router itself should bypass the transparent entry. Proxy outbound connections must also be excluded; otherwise, the core’s connection to the node server is captured again, creating a traffic loop and quickly exhausting CPU.

1. First exclude LAN ranges such as 192.168.1.0/24, along with the fixed addresses of the main router, bypass router, and network storage devices.
2. Exclude the node server address so proxy outbound traffic does not re-enter port 12345. Update the rule whenever the node address changes.
3. Keep UDP ports 67 and 68 for DHCP, along with traffic needed for LAN discovery and management.
4. Then add domain or address rules for traffic that needs proxying. Unmatched traffic should follow the planned direct policy rather than being blocked by default.
5. Finally, test router updates, LAN device-to-device access, ordinary webpages, video, and UDP applications.

Preflight Checks: Logs, Fallbacks, and Troubleshooting

Before taking over the whole network, prepare a management path that does not depend on the proxy. The simplest approach is to keep a fixed management address on the main router and have a computer ready to enter its IP, gateway, and DNS manually. Even if DHCP or the bypass router fails, you can access the main router directly and restore the configuration.

Use info while debugging, then lower the log level to warning once the setup is stable. Long-term debug logging creates heavy writes and is hard on small flash storage. Focus on port usage, DNS timeouts, routing loops, failed outbound handshakes, and repeated process restarts—not every individual connection record.

Whether deployment is worthwhile depends on the number of devices and your willingness to maintain it. With only one or two computers and Android devices, using v2rayN, v2rayNG, or v2flyNG separately is more straightforward and limits the blast radius. A bypass router becomes clearly valuable when you need centralized management for TVs, gaming devices, or other clients that cannot configure a proxy on their own.

In production, make rollback the first principle: validate the node before running the core; test through a local SOCKS inbound before intercepting transparent traffic; take over one device before changing DHCP. As long as topology, DNS, and policy routing are validated separately, running the core directly on a router is not mysterious—but it does add a full layer of network maintenance beyond a standard client.