V2Ray core on Routers and Bypass Routers: Deployment Options and Hardware Requirements

Putting the proxy core on a router is not simply “moving it to another device.” It makes the gateway responsible for connections from every device on the local network. Endpoints no longer need individual system proxy settings, but the gateway must handle forwarding, DNS, route matching, connection tracking, and encryption at the same time. A configuration mistake can also affect the entire LAN instead of one computer.

Before deployment, distinguish between a main router and a bypass router. The main router directly provides the broadband uplink, DHCP, and default gateway, keeping the path short but potentially disrupting the whole network during core maintenance. A bypass router sits behind the existing main router. Usually, only selected devices point their default gateway or policy routes to it, making testing and rollback easier, but return paths and DNS routing require additional attention.

Main Router vs. Bypass Router: Define the Failure Boundary First

A main-router deployment typically follows this path: “endpoint → main-router transparent proxy entry point → V2Ray or Xray core → remote server.” The core, NAT, firewall, and DHCP all run on the same device. The topology is simple, and every endpoint uses the same policy point by default. The trade-off is that a core failure, incorrect firewall rule, or DNS mistake can immediately disrupt normal internet access.

A bypass-router deployment keeps the existing main router as the stable gateway. Devices that need proxying point their gateway to the bypass router, or the main router forwards selected devices there based on source addresses. After matching its rules, the bypass router sends direct or proxied traffic back to the main router. This design supports gradual migration and makes recovery easy: change the endpoint gateway back to the main router’s address.

A bypass router does not automatically take over traffic just because a device is connected through a switch. DHCP, a manual gateway, or a policy on the main router must explicitly send traffic to the bypass router. If the endpoint still uses the main router as its default gateway, the bypass router will not see those connections even when its core is running normally.

Firmware Environment: Starting the Core Is Only the Minimum

The router must first be able to run a Linux executable built for its architecture. Common architectures include x86_64, aarch64, armv7, and mipsle. Check the architecture reported by the system before downloading; do not rely on the processor brand alone. On 64-bit ARM, for example, the system may report aarch64; older devices in the same product family may run a 32-bit user space and require an armv7 build.

Linux 5.10 or later is recommended. Confirm that the system provides nftables or a complete set of iptables extensions. Transparent proxying requires policy routing, connection marks, TPROXY or REDIRECT, and related capabilities. A lightweight firmware may run the core while lacking transparent-forwarding modules, leaving only a SOCKS or HTTP inbound port for manual endpoint configuration.

• Filesystem: Reserve at least 40 MB of writable space for the core, geolocation rule files, configuration, and rotating logs. Leave additional room for both old and new versions during upgrades.
• Time synchronization: TLS, VLESS encrypted transport, and certificate verification depend on an accurate system clock. Complete NTP synchronization after boot before starting the proxy service.
• Process management: Use init or a service manager to start the core, restart it after failures, and write standard output to rotating logs instead of leaving it in an interactive terminal.
• DNS capability: Define how the listening address, caching service, and upstream servers relate to one another. Avoid having multiple processes compete for port 53 on the router itself.
• Rule handling: The firewall must exclude the LAN, multicast, broadcast, the router’s management addresses, and the remote server address to prevent proxy loops.

A subscription is not a universal native input format for a router core either. Clients or management layers usually parse the subscription URL and generate JSON configuration that the core can read. Simply placing a subscription URL in a V2Ray configuration will not make the core parse nodes or generate groups and routing rules. Router deployments need an additional configuration-management layer or manually maintained inbound, outbound, and routing objects.

Hardware Requirements: Sustained Throughput Matters More Than Core Count

Proxy traffic passes through a user-space core. Throughput depends on single-core performance, the encryption algorithm, the TLS implementation, memory bandwidth, and cooling. A low-frequency quad-core processor is not necessarily faster than a high-performance dual-core processor, because the handshake, encapsulation, and some encryption work for one connection cannot be spread evenly across every core. Memory pressure also rises sharply with complex domain rules and many connections.

The figures below are laboratory starting points, not performance guarantees. Test conditions: a 1 Gbps LAN, one remote route, eight concurrent downloads, and approximately 4,000 domain rules. Observe throughput and memory after 15 minutes of stable operation. Results vary with route latency, protocol combinations, and firmware build options.

The core itself may use only a few dozen MB when idle, but rule parsing, DNS caching, connection tracking, and logging add to the footprint. A 128 MB device may start reluctantly yet run out of memory when a subscription generates many outbounds, concurrent connections rise, or the system updates. 512 MB is a more realistic starting point for home traffic routing; if filtering, monitoring, and file services also run there, evaluate from 1 GB upward.

Protocol choice also affects CPU load. VMess includes encryption and authentication processing; VLESS is lighter by design, but combining it with TLS, REALITY, or other security layers still incurs handshake and encryption costs. Do not estimate speed from the protocol name alone. Compare CPU usage, sustained throughput, and time to first byte on the same node during the same test window.

Transparent Proxy Path: Entry, Marks, Routing, and DNS All Matter

The goal of transparent proxying is to let endpoints connect without entering a SOCKS address. For unified TCP and UDP interception, the firewall first selects connections that need proxying and sends them to a local transparent inbound port such as 12345. The core reads the original destination, matches routing rules by domain, IP, port, or protocol, then chooses a direct, blocked, or remote-proxy outbound.

Endpoint 192.168.1.20
  → Default gateway 192.168.1.2
  → Exclude LAN and remote server addresses
  → TPROXY entry point 0.0.0.0:12345
  → fwmark 0x1 / policy routing table 100
  → V2Ray or Xray route matching
  → direct or proxy outbound

The key to policy routing is sending marked packets back to the local transparent inbound instead of forwarding them along the default route. A common setup uses the mark 0x1 and a separate routing table 100. Exact commands depend on the nftables or iptables version and the firmware’s packaging; do not mix two rule sets and then remove only half of one.

DNS determines whether domain rules can match. If endpoints query external DNS directly, the gateway may see only the destination IP and cannot classify traffic reliably by domain. Have DHCP advertise the bypass-router address as DNS, then let a local caching service listen on port 53 and forward selected requests to the core’s DNS inbound, such as 127.0.0.1:1053. Also prevent the core’s own remote-domain lookups from re-entering its transparent rules.

1. Verify Network Parameters

   Record the main-router address, bypass-router address, DHCP range, and remote server IP. In this example, the main router is 192.168.1.1 and the bypass router is 192.168.1.2; they must not share an address.

2. Start with a Manual Entry Point

   First have the core listen for a SOCKS inbound on 127.0.0.1:10808. Manually configure proxying on one computer to verify the node, protocol, and time synchronization without changing the firewall for the entire network.

3. Add the Transparent Entry

   Add a transparent inbound on 12345, enable original-destination preservation, and create a TPROXY or REDIRECT rule for the test endpoint only.

4. Lock Down the DNS Path

   Confirm that only one service occupies port 53 on the LAN. Put the core’s DNS listener on 127.0.0.1:1053, then verify domain-based routing and direct-resolution results.

5. Expand the Interception Scope

   Watch logs, CPU, memory, and connection counts for 30 minutes. After confirming there are no loops or dropouts, expand from one test address to a selected device group, and only then consider taking over the entire network.

Deployment and Acceptance: Increase Scope One Device at a Time

Do not enable global transparent forwarding first. A safer sequence is to validate the core configuration, verify the manual proxy entry, and then intercept traffic from one test endpoint. Keep a separate checkpoint at every step so you can identify whether a problem comes from the node, core configuration, firewall, DNS, or the bypass router’s return path.

1. Check the system architecture, writable space, and time. The environment must report the current time correctly and retain at least 40 MB of free space.
2. After starting the core, inspect the first 30 log lines. Confirm that the configuration loaded, inbound ports are listening, and outbound domains resolve.
3. From the test computer, connect to the bypass router’s 10808 SOCKS port. Visit one direct target and one proxied target to confirm that the basic node works.
4. Assign the test computer the fixed address 192.168.1.20. Make the transparent rule match only that source address so other devices remain unaffected.
5. Run four tests: TCP web access, UDP DNS queries, sustained downloading, and resume after idle. Watch the logs for connection loops, port conflicts, and resolution timeouts.
6. Record direct throughput with proxying disabled and proxied throughput with it enabled. If a 500 Mbps connection stabilizes at only 120 Mbps while one core is fully loaded, treat it as a hardware bottleneck rather than continuing to stack routing rules.

Four Data Sets to Record During Acceptance Testing

• Time to first byte: Access the same target 10 times and record the median instead of focusing on the single fastest result.
• Sustained throughput: Test for at least 15 minutes and record results at the start, after 5 minutes, and after 15 minutes.
• Resource usage: Record the single-core peak, total memory, connection-tracking count, and device-temperature changes.
• Recovery time: After stopping the core, directly connected devices should recover according to the runbook. For a bypass-router setup, change the gateway back to 192.168.1.1 to verify recovery.

Do not leave logging at debug level permanently. Increase verbosity temporarily during validation, then switch back to warning or error and configure log rotation. Router flash storage has limited space and write endurance; logging every connection continuously creates needless writes and may fill the root filesystem.

When to Switch Back to v2rayN, v2rayNG, or v2flyNG

Gateway deployment is not right for every network. If only one desktop computer needs proxying, v2rayN is often more direct: subscription updates, node testing, the system proxy, TUN, and logs are handled in one interface. In v2rayN 7.x, for example, open “Settings” → “Parameters” → “Core type” to check the selected core, then choose a compatible core for the node’s protocol.

Android endpoints can use v2rayNG or v2flyNG according to core requirements. v2rayNG uses the Xray core and suits configurations that need its protocol support; v2flyNG uses the v2fly core and suits connections based on V2Ray-compatible protocols. Endpoint clients can switch nodes independently without reloading the network-wide firewall, making it easier to isolate a problem to one device.

Choose based on the failure scope and maintenance frequency. If TVs, gaming devices, workstations, and other endpoints need shared rules and the gateway has enough performance, a bypass router is a safer starting point. If you frequently switch subscriptions, compare nodes, or inspect detailed logs—or only a few devices need proxying—desktop and Android clients provide a clearer setup.

Whether you choose the main router or a bypass router, make “direct access can be restored” part of the deployment plan. Keep the original gateway address, DNS settings, firewall backup, and service-stop commands, then expand interception one device at a time. The value of router proxying is centralized management; if centralization also magnifies failures, reduce the scope instead of adding more rule complexity.