This guide is for users who have tested their nodes with v2rayN and want to route LAN devices through an OpenWrt bypass router. Start with one test device: set its gateway, then verify Xray outbound connectivity, DNS, and transparent forwarding separately. By the end, you’ll understand the roles of the main and bypass routers, when to use REDIRECT or TPROXY, and how to deploy in steps you can roll back. No one-size-fits-all firewall script is included.
1. Understand the Roles of the Main Router, Bypass Router, and Xray
Keep the main router responsible for the internet connection, the home network’s default gateway, and address assignment. The OpenWrt bypass router receives traffic from selected devices and decides whether to route it directly or send it through Xray. Xray handles proxy protocols and routing rules; starting the process alone does not turn the entire LAN into a transparent proxy network.
For a single-port bypass router on the same subnet, use these example addresses: main router 192.168.50.1, OpenWrt 192.168.50.2, and test computer 192.168.50.100. Replace them with addresses from your local subnet, and exclude the bypass router’s static address from the main router’s DHCP pool before deployment.
| Device | Example Setup | Primary Role |
|---|---|---|
| Main router | 192.168.50.1 | Connects to the internet, provides the existing DHCP service, and retains a management interface. |
| OpenWrt bypass router | 192.168.50.2 | Runs DNS and Xray, and applies forwarding and routing rules. |
| Test computer | 192.168.50.100 | Change its gateway and DNS first, without affecting other devices. |
| Bypass router’s default route | 192.168.50.1 | Allows the router itself and connections to proxy servers to reach the internet. |
When the test computer accesses an overseas service, the expected route is “computer → bypass router → Xray outbound → proxy server.” Direct traffic is forwarded to the main router. With a single-port setup, return traffic for direct connections may go straight from the main router to the computer, creating an asymmetric path. Don’t copy firewall rules designed for a dual-port gateway.
2. Choose What to Route Before Deciding on a Transparent Proxy
Start by identifying the problem you need to solve. If only a computer’s browser needs a proxy, sticking with v2rayN is often easier to maintain. If just a few SOCKS-compatible apps need the bypass router, configure them to connect to its proxy port explicitly. A transparent proxy suits devices that are difficult to configure individually, but requires extra firewall, policy routing, and DNS maintenance.
Transparent Proxy for One Device
RecommendedStart with one computer and limit the transparent rules by source address. Once websites, UDP apps, and LAN access all work, expand coverage one device at a time to keep the impact of failures small.
Best for: First-time bypass router setups and keeping the home network stable
Explicit Proxy Port
The app connects directly to the bypass router’s SOCKS inbound, without changing its default gateway. This can verify the node and Xray configuration, but it does not confirm that transparent forwarding works.
Best for: A small number of proxy-enabled apps and troubleshooting one layer at a time
Route All Devices by Default
Use DHCP to assign the bypass router as the gateway for multiple devices. Plan for lease renewals, IPv6, DNS, service restarts, and failure recovery in advance; you’ll also be taking on more ongoing maintenance.
Best for: After single-device testing, when you can maintain the network configuration long term
Bottom line: Keep the existing gateway and change one device first
For the first test, change only the test computer’s IPv4 gateway and DNS to 192.168.50.2. Don’t change the settings distributed by the main router to the whole network. If the bypass router becomes unreachable, set this computer back to obtain its network settings automatically to roll back.
3. Get the Core Running Before Connecting the Gateway and Firewall
The menu paths below refer to the common OpenWrt LuCI interface. Labels vary by firmware version, language, and installed packages. OpenWrt 23.05 and 24.10 commonly use firewall4 with nftables; don’t mix in transparent proxy scripts intended only for legacy iptables. Before installing anything, check the CPU architecture, available storage, and kernel module sources.
-
Back Up the Network Configuration
Go to “System” → “Backup / Flash Firmware” and create and download a configuration backup. Note the addresses of the main and bypass routers, and keep a way to connect directly to the main router for management. Don’t risk changing the gateway over your only remote session.
-
Set a Static Address
Go to “Network” → “Interfaces” → “LAN” → “Edit” and set the bypass router’s static address, netmask, and IPv4 gateway pointing to the main router. Under “DHCP Server” → “General Setup,” select “Ignore interface” to prevent duplicate address assignments. Save and apply only after checking the settings.
-
Verify Outbound Connectivity
Use an Xray build that matches your system architecture and prepare a working outbound configuration. First, test TCP with a SOCKS inbound that allows access only from the LAN test device. For UDP, the client, inbound, and remote outbound must all support it.
-
Configure DNS
Go to “Network” → “DHCP and DNS” → “General Settings” and check the DNS forwarder target. If your local resolver listens on
127.0.0.1:5353, LuCI commonly expects127.0.0.1#5353. Make sure the service is listening and isn’t forwarding queries back to dnsmasq. -
Connect the Test Device
Change the gateway and DNS in the test computer’s network settings, then add transparent proxy rules for that computer only. Check interface forwarding permissions, kernel forwarding settings, and the return path. Test direct and proxied destinations separately.
-
Test After Restarting
Once the current connection works, reload the firewall, restart Xray, and then reboot the bypass router. Check that the rules return, DNS works, and direct traffic behaves as expected when the core hasn’t started yet.
A subscription link is not a runnable Xray configuration. v2rayN parses subscriptions, selects nodes, and generates configuration; running the core directly requires complete inbound, outbound, DNS, and routing settings. For VMess and VLESS nodes, the transport, TLS, server name, and related parameters must match the server. Don’t copy just the server address and port.
# The paths below assume Xray is installed and its configuration file is at /etc/xray/config.json
xray version
xray run -test -config /etc/xray/config.json
# Check system architecture, routes, and listening services
ubus call system board
ip -4 route show
netstat -lnptu4. Understand REDIRECT, TPROXY, and Traffic Marks
A transparent proxy isn’t a single switch. The firewall first identifies traffic to intercept, Xray’s transparent inbound receives it, and routing rules determine the outbound path. REDIRECT is commonly used to redirect TCP traffic. TPROXY can handle TCP and UDP, but requires a matching transparent inbound, policy routing, and kernel support. You can’t substitute one for the other by simply changing a rule name.
| Method | Use Case | What to Check |
|---|---|---|
| REDIRECT | Commonly used for transparent TCP interception | Redirect port, original destination handling, and Xray transparent inbound settings. |
| TPROXY | Transparent interception of TCP and UDP | Transparent sockets, packet marks, policy routing, and the local routing table. |
| Explicit SOCKS | The app explicitly configures a proxy | Client proxy address, access controls, and UDP support. |
For example, if you assign 12345 to the transparent inbound, the firewall must send the target traffic to that port. It is not the remote port on the proxy server. TPROXY marks and policy routing tables must also be designed together; don’t overwrite marks used by multi-WAN, other tunnels, or policy routing services.
- Exclude LAN and special-purpose addresses first: Preserve access to router management, printers, storage devices, and broadcast traffic. Don’t send all of it to a remote server.
- Exclude connections to the proxy server: Xray’s connections to the server must not be caught by the transparent rules again, or they’ll create a loop. Depending on your setup, exclude them by outbound mark, process identity, or an explicit address set.
- Handle traffic from the router separately: Forwarded traffic usually passes through PREROUTING, while requests initiated by the router use OUTPUT. A working connection from the computer doesn’t mean the bypass router’s own subscription requests or upstream DNS can connect.
- Check the return path on the same subnet: Configure source NAT or routing as needed so return traffic meets connection tracking and firewall requirements. Don’t assume a single-port setup will have a symmetric path.
- Check offloading and redirects: During troubleshooting, check whether flow offloading bypasses the expected rules and whether ICMP redirects cause the test device to use the main router instead. Record the original values before changing them.
Use nft list ruleset to inspect the current rules and ip rule show to check policy routing, then inspect routes in custom tables. Don’t flush the entire nftables ruleset: that could also remove OpenWrt’s base firewall and remote management protections.
5. Treat DNS as a Separate Connection Path
When a site won’t load, first distinguish a DNS lookup failure from a successful lookup followed by a connection failure. Changing the gateway to the bypass router doesn’t mean DNS traffic now goes through it. Apps’ built-in encrypted DNS, browser Secure DNS, and DNS servers advertised over IPv6 can all take a different path.
The last two ports are configuration examples, not Xray defaults. Check existing listeners before using them. 5353 is also commonly used for multicast DNS, so make sure the bind address and process won’t conflict. A DNS service for the LAN typically listens on port 53; an internal upstream can bind to the loopback address only to avoid unnecessary exposure.
- Confirm the request arrives: On the computer, run
nslookup example.com 192.168.50.2and check whether the bypass router responds. This tests only the specified DNS server; it doesn’t show that every app uses it. - Confirm the upstream route: DNS upstreams that need to use the proxy must have a defined outbound path. Bootstrap lookups for the proxy server’s domain must not depend entirely on a proxy connection that hasn’t been established yet.
- Check for DNS loops: If dnsmasq forwards queries to a local resolver, that resolver must not send the same queries back to dnsmasq. A loop often causes long delays and timeouts.
- Align domain and IP-based rules: When routing by domain, be clear about how Xray obtains domain information. Sniffing won’t work for every app; if Xray receives only a destination IP, it may not be able to recover the original domain.
- Account for IPv6: If you intercept IPv4 only, devices may connect directly using the IPv6 default route advertised by the main router. First verify IPv4 on the test device, then design IPv6 routing and DNS separately instead of assuming the node has failed.
Bottom line: Record DNS and connection results separately
Test one layer at a time: record whether DNS returned an address, then check which outbound handled the request and whether the handshake succeeded. Don’t change the node, DNS upstream, and transparent rules all at once; even a successful test won’t tell you which change fixed it.
6. Troubleshoot by Symptom and Plan a Rollback
Have a local management address, a destination that should connect directly, and one that should use the proxy ready for testing. Check Xray access logs for the inbound, destination, and outbound tags, and compare them with system logs. You can temporarily increase log verbosity to troubleshoot, then restore an appropriate level. Logs may include destinations; remove addresses, credentials, and subscription details before sharing them.
Changed the gateway and now can’t even open the bypass router’s admin page?
Restore the computer’s original gateway through the main router, or set it to obtain network settings automatically. Make sure the computer and bypass router are on the same subnet, then open 192.168.50.2. Check for a static address conflict and verify that the management service is listening. Don’t reinstall Xray as a first step.
SOCKS works, but the transparent proxy doesn’t?
Check the test computer’s default route, the transparent inbound port, the matching firewall rule counters, and the TPROXY mark and policy route—in that order. If Xray isn’t receiving requests, troubleshoot the traffic path into the router instead of repeatedly changing remote node settings.
Websites load, but voice chat or games still won’t connect?
First check whether you deployed TCP REDIRECT only. Then verify the UDP transparent inbound, remote UDP support, and firewall rules. A browser loading successfully doesn’t prove that UDP is being intercepted or that every app follows the same route.
Why did it stop working after a power outage or reboot?
Check that the Xray service starts, the DNS upstream is ready in time, and the firewall rules return after a reload. Use logread to find startup errors, then test domain bootstrap resolution again. Don’t rely on rules run manually in a terminal that disappear at reboot.
Only consider changing DHCP settings after you’re ready to expand coverage. In common IPv4 DHCP options, option 3 specifies the default gateway and option 6 specifies DNS; they don’t have to point to the same device. After a change, clients must renew their leases, and existing connections may continue using the old route. Test with one device after renewing its lease before changing anything else.
- Keep the original gateway, DNS, DHCP, and firewall settings, and record every change.
- To roll back, restore the test device’s gateway and DNS first, then remove the interception rules added for this test.
- Keep OpenWrt’s base firewall intact; don’t replace a rollback with a global ruleset flush.
- Once direct connectivity is restored, decide whether to keep changing Xray and the resolver.
A successful bypass router setup isn’t about adding more rules; it’s about verifying each layer independently: the client sends traffic to the bypass router, the firewall intercepts only the intended traffic, DNS doesn’t loop, Xray outbound works, and the return path behaves as designed. Once that’s confirmed, move the tested node settings from the desktop client into your long-term configuration for easier maintenance.