Router and Side-Router V2Ray Core Deployment Guide: Choosing an Approach and Key Considerations

Quick overview

This guide is for users moving proxy functionality from a single device to a home gateway. The focus is not installing a particular management interface, but understanding which device handles each flow, how TCP and UDP reach the core, who handles DNS queries, and how to preserve a direct-connection fallback when things go wrong.

Define the gateway role before choosing where to deploy

Running the V2Ray core on a router usually means running Xray or V2Fly on a Linux gateway and using routing rules to send selected client traffic into the core. Xray and V2Fly handle connections, protocols, and routing; v2rayN, v2rayNG, and v2flyNG are client applications for end devices and should not be treated as router gateway solutions.

In a primary-router deployment, the device running the core also handles dial-up access, DHCP, NAT, firewalling, and the default gateway. Every client naturally passes through it, giving policies complete coverage, but a configuration mistake can affect the entire LAN. Before changing firewall, DNS, or core services, export the configuration and prepare a device that can access the management address over Ethernet.

A side-router deployment keeps the existing primary router and places another device on the same LAN. Clients can reach the side router through a manually configured gateway, DHCP-delivered settings, or policy routing on the primary router. This limits migration scope: TVs, work computers, and test devices can be switched in stages. The trade-off is a longer path, where incorrect gateway or return-path settings can easily create loops.

Deploy directly on the primary router

The default gateway, DHCP, DNS, and transparent proxy are centralized on one device, keeping policy entry points consistent without requiring changes on individual LAN clients.

Best for: simple network layouts and users comfortable maintaining firewall rules and startup services

Add devices to a side router in stages

Recommended

Keep the existing primary router and direct only test clients or selected devices to the side router. If something fails, restore the original gateway quickly.

Best for: first deployments, low-risk migration, and per-device control

Run client apps in parallel

Keep the router on a standard network while using v2rayN on computers and v2rayNG or v2flyNG on Android devices, with proxy status managed separately on each device.

Best for: small numbers of devices and independent node switching on each device

Bottom line: validate the path with a side router first

Start by changing the default gateway and DNS on one test client. Confirm that TCP, UDP, name resolution, and return traffic all work before expanding the rollout. This is easier to troubleshoot than changing the default gateway for the entire network at once.

Check the architecture, memory, and system capabilities first

The package must match the processor architecture. Common software routers use x86_64, while smaller ARM devices may use aarch64; similar names do not mean binaries are interchangeable. Run uname -m to confirm the architecture, then check whether the system supports nftables, policy routing, and TPROXY. Configuring a single SOCKS inbound port does not automatically take over LAN traffic.

The following baseline helps illustrate resource requirements: OpenWrt 23.05.5, Linux 5.15.167, a 4-core x86_64 processor, and 512 MB of available memory can handle rule matching and several-hundred-megabit forwarding for a typical home network. Large geosite and geoip datasets, along with verbose access logs, increase memory use and storage writes. On low-capacity flash devices, lower the log level and retain only a small number of rotated files.

512 MB

Recommended available memory

12345

Example transparent proxy port

1053

Example core DNS port

LAN DNS service port

Recommended approach: validate the control and forwarding planes separately

Gateway side

Start Xray or V2Fly as a system service
Listen for transparent inbound traffic on port 12345
Listen for local DNS inbound traffic on 127.0.0.1:1053
Keep the management address and LAN subnets on a direct connection

Client side

Pin the gateway address on one device first
Point DNS to the gateway that handles split routing
Test web browsing, downloads, and UDP applications separately
Record the exit address and latency before and after switching

A core that starts successfully only proves that the configuration syntax is valid. The gateway path is usable only when client traffic reaches the transparent inbound and completes its return path.

Transparent proxying must handle both inbound traffic and return traffic

The purpose of transparent proxying is to hand connections from clients that are unaware of the proxy to Xray or V2Fly. Common Linux entry methods are TPROXY and redirection. Redirection is easier for TCP, while TPROXY preserves the original destination and can cover UDP, but requires additional fwmark, policy-routing, and local-routing-table setup. The exact capabilities depend on the kernel modules and firewall framework.

A complete rule set should first exclude the router’s management addresses, LAN subnets, multicast addresses, node-server addresses, and connections created by the core process, then capture the TCP and UDP traffic that needs proxying. If the node server is not excluded, connections from the core to the node may re-enter the transparent inbound, causing timeouts, higher CPU usage, or repeated log entries for the same destination.

Create a transparent inbound with a fixed listening port, such as 12345, and enable TCP and UDP as required.
Create a policy-routing table that sends packets marked 0x1 to the local loopback interface.
Add direct-connection exclusions first in the firewall chain, then apply TPROXY and marks to the target traffic.
Configure the core’s routing rules so that LAN, management, and node addresses use the direct outbound.
After restarting the service, check listening ports, rule counters, and core logs instead of looking only at process status.

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

nft add rule inet proxy prerouting \
  meta l4proto { tcp, udp } \
  tproxy to :12345 meta mark set 0x1

Split DNS determines whether domain rules work consistently

Traffic routing without a DNS plan commonly leads to domain rules missing their matches, DNS results that do not match the exit path, or clients bypassing the gateway to query external DNS directly. Have managed clients send DNS to port 53 on the gateway, then let the local DNS service choose direct resolution or forwarding to the core’s local DNS inbound by domain category.

A clear layout is: LAN clients query port 53 on the gateway; dnsmasq handles local domains and DHCP hostnames; queries that need core processing are forwarded to 127.0.0.1:1053; Xray or V2Fly then selects an outbound according to the DNS rules. Do not point the upstream for port 1053 back to port 53, or a recursive loop will form.

Check item	Recommended setting	Symptom
Client DNS	Port 53 on the gateway’s LAN address	Domain rules fail intermittently or the exit path is inconsistent
Core DNS inbound	Listen only on 127.0.0.1:1053	The port is exposed to the LAN or called directly by other devices
Cache location	Clearly assign primary caching to dnsmasq or the core	Old addresses are still returned after rule changes
IPv6 queries	Enable or disable them together with IPv6 routing and proxy policies	Clients prefer an IPv6 exit that is not covered by policy

In a typical OpenWrt management interface, check the DHCP and DNS parameters sent to clients under “Network” → “Interfaces” → “LAN” → “DHCP Server” → “Advanced Settings.” Names may vary slightly between system versions. After making changes, have the test client renew its lease and use a system DNS lookup command to confirm the actual DNS server instead of inferring it from the interface settings.

Bottom line: validate DNS and transparent proxying together

During testing, record DNS results, the matched routing rules, and the actual exit path together. Checking only whether a webpage opens will not reveal DNS bypasses, stale caches, or IPv6 traffic that was never captured.

Separate core load from network quality when testing performance

Gateway performance is not determined by core count alone. Encryption algorithms, connection volume, rule-set size, log level, NIC drivers, and hardware interrupt distribution all affect throughput. After enabling transparent proxying, hardware acceleration or flow offloading may bypass firewall rules. If some connections escape policy control, disable the relevant offload features and test again.

One reference test used a 4-core N5105, 8 GB of memory, a gigabit wired LAN, and a 500 Mbps downstream line, with both the test client and gateway connected by Ethernet. Using the same node and time window, direct forwarding through the primary router measured 438 Mbps, while forwarding through a side router on the same subnet measured 421 Mbps. During sustained transfer, the core process used about 118% in single-core terms and total gateway CPU usage was about 34%. These figures illustrate the method only and do not replace a test on your own line.

First measure LAN throughput without the proxy to rule out NIC negotiation and cabling issues.
Then measure direct internet speed and record latency, packet loss, and download/upload baselines.
After enabling transparent proxying, repeat the test with the same client, node, and target.
Run the test for at least 5 minutes while monitoring CPU, memory, temperature, and connection count.
Test TCP downloads, short-lived web connections, and UDP-dependent applications separately; do not use one result to judge everything.

If speed drops without high CPU usage, check node quality, MTU, DNS, and the return path first. If one core stays near full utilization while others remain mostly idle, the bottleneck may be single-connection processing or interrupt distribution. The extra forwarding hop in a side-router setup does not normally cause a major speed loss by itself; double NAT, 100 Mbps ports, or a wireless backhaul deserve earlier investigation.

Common deployment issues and rollback methods

Gateway services should follow an explicit startup order: bring up network interfaces and system time, start the core, then enable transparent proxy rules after the core is listening successfully. When a node uses a domain name, unsynchronized time or unavailable DNS can cause the first connection to fail. Configure a restart delay in the service manager to prevent a bad configuration from triggering rapid repeated restarts.

Prepare the rollback plan before deployment. For a primary-router setup, keep the LAN management address, a wired login method, and a firewall configuration without transparent proxying. For a side-router setup, change the test client’s default gateway and DNS back to the primary router. Do not rely on a proxy path that may already be broken to perform recovery.

The core is running—why are clients still connecting directly?

First check that port 12345 is listening, then see whether the nftables rule counters are increasing. Counters that remain at zero usually mean the client’s gateway does not point to this device, or packets are not passing through the expected prerouting chain.

Why can’t LAN devices be reached as soon as the side router is enabled?

Check that the LAN subnet is excluded from transparent rules and that the side router has not configured the same subnet on two interfaces. During testing, keep a single LAN address and avoid duplicate DHCP services or asymmetric return paths.

Web browsing works, but some UDP applications time out?

Confirm that UDP is enabled on the transparent inbound, that policy routing also covers UDP, and that the firewall is not matching TCP only. Then check the MTU and whether the node protocol supports the current transport, and use core logs to locate rejected destination ports.

Why do old results still match after changing domain rules?

Clear the client, local DNS service, and core DNS caches in that order, then query again. If dnsmasq uses port 53 and the core uses port 1053, also confirm that neither forwards back to the other and creates a loop.

How should you choose between Xray and V2Fly?

Choose the core according to the protocols used by your nodes. Xray is generally the choice for VLESS, XTLS, or REALITY configurations; V2Fly remains suitable for existing VMess configurations maintained on V2Fly. Before migrating, verify the same configuration in a client app.

The post-deployment checklist should cover automatic service recovery after a gateway reboot, local exclusions surviving subscription or configuration updates, non-looping DNS queries, direct connections to node servers, direct access to LAN management addresses, and a predefined way to restore normal networking after the core is disabled. Only after these checks pass should you bring more clients under gateway policy.