Running Xray on a router means handling the core, traffic interception, DNS, and recovery from failures. This guide is for users who can already connect to a node from a client and want to share the connection with multiple LAN devices. Compare a main router, bypass router, and desktop setup; then plan hardware, test one device, and troubleshoot in order. Starting the core alone does not proxy traffic for the entire network.
1. Xray Core vs. Router Traffic Interception
Xray is a proxy core that handles protocols, inbounds, outbounds, and routing rules. It is neither router firmware nor a tool that automatically configures your entire LAN. Copying the executable to a router and starting it only completes one part of the setup. Whether traffic from client devices reaches the core also depends on the gateway, system forwarding, firewall rules, and inbound configuration.
v2rayN is a desktop client, v2rayNG is an Android client that uses the Xray core, and v2flyNG uses the V2Fly core. Subscription management, node lists, and connection buttons from a client interface do not appear on a router just because you copied over the Xray executable. Subscription text also generally cannot be used directly as an Xray JSON configuration file.
- Explicit proxy settings: Enter the proxy address and port in an application. This clearly limits which traffic is proxied and is a good way to test a node without routing the entire LAN through it.
- Transparent proxy: Gateway rules send matching traffic to the core. Devices usually do not need individual proxy settings, but the router needs forwarding, return-path, and exclusion rules.
- DNS routing: Determines which resolver handles each DNS query and which route those queries take. It affects traffic routing, but is a separate function.
2. Where to Run It: Desktop, Bypass Router, or Main Router
Before choosing a setup, decide how many devices to cover and whether they should fall back to a direct connection if the proxy goes down. A bypass router is a network role, not a specific piece of software: another device handles gateway or policy-based forwarding for selected clients. It can be a dedicated mini PC or a virtual machine. For a VM, check virtual NICs, bridging, and host resource allocation as well.
Test on desktop first
RecommendedTest the same node on the same network with v2rayN first. Once you can reach the target service, move the setup to the gateway. If anything goes wrong, you can distinguish a node issue from a routing or interception issue.
Best for: first-time setup, one computer, or easy rollback
Dedicated bypass router
Keep dialing out and handling DHCP on the main router, and route only selected devices through the bypass router. This makes phased testing easier, but you still need to plan the default gateway, DNS, and return path. Connecting the cables alone does not activate the setup.
Best for: sharing rules across multiple devices while minimizing changes to the main router
Run on the main router
Dialing out, forwarding, DNS, and proxying all happen on one device, keeping the traffic path simple. But an upgrade, memory shortage, or incorrect firewall rule can also disrupt internet access for every device.
Best for: capable hardware, a maintenance window, and a recovery plan
On a single-NIC bypass router, inbound and outbound traffic may share the same interface, so verify the switching path and return traffic separately. Two NICs do not automatically mean better performance: unstable drivers or weak single-core CPU performance can still become bottlenecks under heavy concurrency or complex rules. Do not treat the advertised port speed as a guarantee of proxy throughput.
3. Hardware Requirements: Plan for Headroom
There is no minimum spec that works for every node and rule set. CPU architecture determines whether a binary can run; memory affects how many rules and connections you can support; writable storage is needed for installation, updates, and logs. The table below offers planning guidance, not official Xray minimum requirements or a promise of line-rate performance.
| Check | Planning guidance | How to verify |
|---|---|---|
| CPU and architecture | Prefer devices with a matching ARM64 or x86-64 build | Run uname -m, then check the system ABI and package architecture |
| System memory | Use 512 MiB as a starting point for a lightweight trial; consider 1 GiB or more for complex rules or additional services | Check available memory with free -m and review logs during peak usage |
| Writable storage | Reserve at least 256 MiB, plus space for update temporary files and data | Use df -h to check the actual installation partition, not just the flash storage's advertised capacity |
| Network interfaces | Choose based on broadband speed and whether the setup uses one or two interfaces | Test regular and proxied forwarding separately; compare CPU usage and packet loss |
| Cooling and power | Require stable operation under sustained load | Check temperatures, throttling, restarts, and network link drops |
On devices with limited flash storage, logs filling the partition may cause problems before the core's resource use does. Keep only necessary error logs during normal operation, temporarily increase verbosity when troubleshooting, and configure log rotation or use in-memory logs. If you use external storage, check mount order at boot so the service does not start before its configuration directory is available.
Bottom line: Test with a representative workload first
Choose a node you actually use and run it continuously for 30 minutes while browsing, streaming video, and making DNS queries. Record available memory, CPU usage, and temperature. If there is not enough headroom, reduce the rules and extra services before deciding whether to replace the hardware.
4. Trial a Bypass Router with One Client Device
The paths below use the common OpenWrt LuCI interface; wording and menus may vary slightly by version. This example uses 192.168.10.1 for the main router, 192.168.10.2 for the bypass router, and 192.168.10.100 for the test device. All use a /24 subnet prefix. These are example addresses; check your existing subnet and address assignments before using them.
-
Back up the current configuration
In LuCI, go to “System” → “Backup / Flash Firmware” and save a configuration backup. Note the current gateway and DNS settings. Keep one management device on the main router and confirm you can access its admin page over a wired connection.
-
Set a fixed management address
Go to “Network” → “Interfaces” → “LAN” → “Edit” → “General Settings” and set the bypass router's address to 192.168.10.2. For the single-NIC setup described here, set its upstream gateway to 192.168.10.1 and make sure the address is outside the DHCP pool.
-
Check address assignment
If the main router handles address assignment, go to “Network” → “Interfaces” → “LAN” → “Edit” → “DHCP Server” → “General Setup” on the bypass router and check “Ignore interface.” Also review IPv6 RA and DHCPv6 settings to avoid announcing an unplanned second gateway.
-
Validate the core configuration
Prepare an Xray build for the correct architecture and the configuration you intend to use. Test the configuration before starting the process. First verify outbound connectivity with explicit proxy settings, then configure forwarding, inbounds, and exclusion rules for your chosen interception method. Do not change DHCP for the whole network yet.
-
Switch the test device
Change the IPv4 gateway only on the test device to 192.168.10.2. If the bypass router provides a working DNS service, set the device's DNS to that address too. Test the local admin page, direct connections, and proxied traffic separately. Roll out to more devices in stages only after everything checks out.
These address settings establish only the basic topology; they are not a complete transparent proxy configuration. A single-NIC setup on the same subnet may create an asymmetric return path. Whether you need source NAT depends on your forwarding and interception method. Verify using packet captures, connection tracking, and the core's requirements. Do not paste firewall commands from an unknown source wholesale into a production gateway.
# The following commands are for inspection; adjust paths to match your installation
uname -m
free -m
df -h
ip route
xray version
xray run -test -config /etc/xray/config.json
# Check recent system logs on OpenWrt
logread | tail -n 80
# View existing rules on systems using nftables
nft list ruleset5. Transparent Proxying and DNS: Map Both Traffic Paths
Transparent interception typically involves two paths: which inbound receives application traffic and which resolver handles DNS queries. On Linux, REDIRECT and TPROXY are not interchangeable. REDIRECT is commonly used to redirect TCP; using TPROXY for TCP and UDP also requires coordination between kernel support, traffic marks, and policy routing. Adding a single redirect rule does not mean UDP will work.
Routing rules also need a clear match order and default route. For domain-based matching, consider whether the core can see the domain: the client may already have resolved it to an IP address, or the application may use its own encrypted DNS. Sniffing can provide extra information for supported traffic, but cannot recover the original domain for every connection.
The ports 10808 and 12345 are examples for this guide, not fixed defaults for every client or router configuration. Different port numbers are fine as long as the firewall's target port matches the actual inbound. For DNS on port 53, account for both UDP and TCP; handling only one transport is not enough.
- Exclude essential local traffic: Keep DHCP, required multicast and broadcast traffic, LAN management addresses, and the core's own connections out of the proxy.
- Prevent proxy loops: Connections to node servers must use the regular outbound route, not be sent back through the original inbound by transparent rules. If a node address is a domain, account for changing IPs and name resolution at startup.
- Separate DNS responsibilities: Use the local resolver for LAN hostnames, and route public domains to upstream resolvers according to policy. The resolver's own outbound path must also match your plan.
- Check IPv6 separately: If you configure interception only for IPv4, clients may still connect directly over IPv6. Deploy a complete dual-stack policy, or explicitly disable the relevant IPv6 advertisements and connectivity paths within the test scope.
- Restrict listening interfaces: DNS and proxy inbounds intended for LAN use should not be exposed directly to the WAN. Limit the listening address and allowed sources with firewall rules.
6. Common Issues: Check the Gateway, DNS, and Outbound Path in Order
Change only one thing at a time while troubleshooting. First confirm the client has the expected gateway, then check DNS resolution, and finally verify that connections use the intended outbound. Refreshing a page in a browser can involve cached data, connection reuse, and application-specific DNS, making it hard to identify the failing layer.
Changed the gateway, but traffic still uses the old route?
Check the client's actual routing table and IPv6 default route first. Rule out an old DHCP lease or an RA that still points to the main router. Then confirm that the bypass router is actually matching traffic against its interception rules. Changing the default gateway proves only that traffic passes through the bypass router, not that it reaches Xray.
Can reach IP addresses, but domains won't load?
On a test device with nslookup, run nslookup example.com 192.168.10.2 and check for a timeout. If the bypass router does not provide DNS, do not point the device's DNS at it. Then check the resolver's listening address, firewall rules for port 53, and upstream route.
Web pages work, but games or voice calls don't?
Check whether UDP reaches the intended inbound, whether the outbound supports the required forwarding, and whether policy routing is complete. Working TCP web traffic does not mean UDP works. Test with the specific application and review logs; a single TCP latency test cannot verify the entire path.
The whole network went offline after a reboot. What should you check first?
First restore the test device's gateway and DNS to their previous values, then sign in using the management device you kept on the main router. Check the startup order for the core, DNS service, and firewall rules, then review time synchronization and storage mounts. Re-enable interception only after the services are working; repeated reboots can obscure the cause.
Decide in advance what should happen if the core exits: allow selected traffic to connect directly, or block it. Either policy must be explicitly implemented and tested. During a maintenance window, stop the core and observe the clients, then confirm their behavior matches expectations. Automatic process restarts alone are not a complete fallback plan.
7. Verify the Setup and Weigh the Trade-offs Before Migrating
A router setup centralizes rule management and covers devices that are difficult to configure individually, but it also increases the impact of network failures. For a single computer, v2rayN usually makes it easier to switch nodes, inspect logs, and revert settings. On Android, you can first test an Xray node with v2rayNG. If you choose v2flyNG, separately confirm that the node's protocol is compatible with V2Fly.
- Feature checks: Test direct destinations, proxied destinations, LAN services, DNS, and UDP separately. One working webpage is not a substitute for checking everything.
- Performance checks: Compare desktop and router throughput using the same node at similar times. Record CPU, memory, and temperature to distinguish node congestion from a local bottleneck.
- Reboot checks: After restarting the bypass router, renew a client lease and verify that its address, rules, DNS, and outbound connectivity all recover—not just access to the admin page.
- Rollback checks: Document the exact steps to revert the gateway, DNS, and interception rules. Make sure the backup can be restored and keep a management path outside the test setup.
After verifying one device, roll out by device or address group. Do not replace the firmware, upgrade the core, switch nodes, and rewrite DNS policies all at once. Make changes separately so logs and comparison tests can show whether each step worked.