Run Xray on a Router or Bypass Gateway: Setup and Configuration Guide

1. What Xray and the router each do

Xray is a proxy core that handles protocols, inbounds, outbounds, and routing rules—not a complete router operating system. Installing the executable only answers one question: can the program start? The OS and deployment setup still handle packet forwarding, DNS, firewall integration, and startup. v2rayN is a desktop client, and v2rayNG is an Android client that uses the Xray core. Neither client’s installer is a router service package.

Before deployment, note the CPU architecture, OS version, available memory, and free storage. Packages from a firmware package manager may also depend on specific system libraries; seeing ARM in a filename does not guarantee compatibility. The examples below use OpenWrt’s networking model. Available features depend on your device’s firmware and the packages you install.

• System layer: Interface addresses, default routes, IP forwarding, IPv6 routing, and firewall rules.
• Traffic interception layer: Send selected TCP or UDP traffic to a transparent proxy listener.
• Proxy core layer: inbounds accept connections, routing.rules match traffic, and outbounds define proxy or direct connections.
• DNS layer: Which DNS server clients use, how queries are routed, and whether upstream lookups are intercepted again.

2. Where the main-router and bypass-gateway setups differ

The main router usually handles the WAN connection, DHCP, NAT, and firewall. Running Xray there keeps traffic entry points in one place, but a bad rule can affect the entire LAN. A separate bypass gateway lets you route just one test device through it, but adds a forwarding hop and risks asymmetric return paths, duplicate DHCP servers, and incorrect gateway settings.

A bypass gateway does not necessarily need two network ports. A single port can send and receive traffic on the same LAN, but forwarding rules are still required. Two ports do not automatically provide proper isolation either: if both interfaces are bridged together, they may still be on the same Layer 2 network.

3. Gateways and return paths, using fixed IP addresses

The table below shows an example IPv4 topology. It is not a device default or a performance benchmark. First check that the addresses are unused, and exclude fixed addresses from the DHCP pool. Change settings on the test device only; leave other devices on the main router.

Set the device’s DNS to 192.168.10.2 only if the bypass gateway is actually providing DNS on port 53 at that address and accepts queries from the LAN. Installing Xray alone does not provide this service. When the main router and bypass gateway are on the same subnet, traffic to the main router’s management address will usually travel directly over Layer 2, not through the default gateway.

With a single-interface bypass gateway, direct forwarding can create an asymmetric path: the device sends traffic through the bypass gateway, but the main router replies directly to the device. This can affect stateful firewalls and connection tracking. Source NAT can make replies return through the bypass gateway, but it changes the source address seen upstream and is not a universal fix. Also check whether ICMP redirects cause devices to switch to the main router, and whether the firewall permits forwarding on the same interface.

• On the bypass gateway, check that the default route points to 192.168.10.1.
• Check that IPv4 forwarding is enabled and the forwarding chain allows traffic from the test device.
• Check proxy and direct traffic separately; a single webpage visit does not test every path.
• If IPv6 still uses the default route advertised by the main router, changing the IPv4 gateway will not redirect IPv6 traffic.

4. Transparent proxy entry points and Xray routing are separate layers

With an explicit proxy, an app connects directly to a SOCKS or HTTP endpoint. A transparent proxy uses network rules to send connections to the core. Adding a listener in Xray alone will not make LAN devices use it automatically. The 12345 port in this example is arbitrary; match it to the actual transparent proxy listener and firewall forwarding target.

OpenWrt 22.03 and later use firewall4 and nftables by default. When maintaining an older setup, identify the active firewall backend first. Do not append legacy iptables scripts to newer firmware and treat a successful command exit code as proof that deployment worked. Also exclude proxy connections originating from the core itself, management addresses, and essential local services from transparent interception to prevent loops.

5. Match DNS routing to the connection path

The path a device uses for DNS queries is separate from the path it uses to connect to an IP address. Changing the gateway to the bypass gateway does not automatically intercept encrypted DNS built into a browser. Pointing DNS at the bypass gateway does not change the default gateway either. During testing, identify which devices use system DNS and which apps resolve names independently.

• Listener: Confirm a service is listening at 192.168.10.2:53 and that both TCP and UDP queries can reach it.
• Upstream: Identify where the local resolver sends queries. If it uses a proxy, make sure the proxy connection does not depend on the same DNS path that is not yet working.
• Rules: domainStrategy controls how routing uses DNS results when matching traffic; it is not a switch for intercepting LAN DNS.
• Domain information: Transparent traffic may not include a domain name that can be matched, and sniffing cannot reliably recover names from every encrypted connection.
• Cache: After changing DNS routing, test a new connection first. Then clear client and local resolver caches if needed so stale records do not affect the results.

If the required tools are installed, run the two commands below on the test device to check standard UDP and TCP queries. A response confirms only that the DNS endpoint is reachable; check resolver logs to verify the query took the expected upstream path.

dig @192.168.10.2 example.com A
dig +tcp @192.168.10.2 example.com A

Plan IPv6 as well. Devices may receive an IPv6 default gateway and DNS server through router advertisements, and apps may prefer AAAA records. Until IPv6 traffic interception is configured, control and document the IPv6 path on test devices. IPv4 success alone does not mean the whole network is covered.

6. Roll out one device at a time

The interface paths below are based on the standard Chinese-language LuCI interface in OpenWrt 23.05. Customized firmware may use different menu names. Changing network addresses can disconnect your management session, so prepare a wired connection and record the main router’s address, existing DHCP settings, and a configuration backup first.

1. Record the current configuration

   Go to “System” → “Backup / Flash Firmware” and create a configuration backup. Note the test device’s current gateway and DNS, and confirm you can access the main router directly at 192.168.10.1.

2. Set a fixed address for the bypass gateway

   Go to “Network” → “Interfaces” → “LAN” → “Edit” → “General Setup”. Set the static address to 192.168.10.2/24 and the IPv4 gateway to 192.168.10.1, as shown. Save and apply, then sign in again using the new address.

3. Prevent duplicate address assignments

   On the bypass gateway, go to “Network” → “Interfaces” → “LAN” → “Edit” → “DHCP Server” → “General Setup” and check “Ignore interface”. During same-subnet testing, keep the main router as the only DHCP server.

4. Check the Xray listener

   First validate the Xray configuration and node connection, then enable the planned transparent interception rules. Check the listening port, forwarding policy, DNS service, and exclusions for traffic originating from the core. Do not copy another device’s entire firewall command set.

5. Change the test device only

   Set the test device’s gateway to 192.168.10.2. Once DNS is confirmed to work, point DNS to the same address. Test websites, UDP apps, LAN file sharing, and router management access separately.

6. Expand only after testing

   Restart the bypass gateway and test again. Confirm services start in the right order, rules are restored, and DNS is ready before considering DHCP option 3 for the gateway and option 6 for DNS. Devices with existing leases need to renew them; then check the values they actually received.

7. Troubleshoot symptoms without changing multiple layers at once

Use a consistent troubleshooting order: device addresses and routes, bypass gateway forwarding, DNS, Xray listener, then proxy outbound. Change one thing at a time and record logs before and after. The commands below are read-only checks for Linux gateways; some minimal firmware builds may require installing the relevant tools.

ip -4 route
ip -6 route
ip rule show
sysctl net.ipv4.ip_forward
ss -lntup
nft list ruleset

Before rollout, confirm three recovery steps: you can restore the device’s original gateway, the main router’s management page remains accessible, and stopping the bypass gateway service will not leave interception rules pointing to an inactive port. CPU architecture, node protocol, and network conditions vary widely, so advertised bandwidth cannot predict proxy throughput. Expand coverage based on real workload tests, resource usage, and connection logs.