A bypass router setup should first establish basic forwarding, then add the core and transparent proxying. This guide is for readers who can access the OpenWrt admin panel and use SSH. Using a sample LAN, it explains how the gateway, DNS, policy routing, and outbound rules work together. By the end, you can plan a single-device trial, distinguish configuration issues from traffic interception problems, and keep a recovery path if connectivity fails.
Bypass Router Architecture: Check Gateway and DNS Separately
Starting V2Ray on OpenWrt alone does not make LAN devices use the proxy. The core handles connections delivered to its inbound; the operating system routes device traffic to it. Transparent proxying also requires firewall rules, policy routing, and the corresponding listening port. If any of these three layers is missing, the process may run normally without handling any traffic.
This guide uses a single-interface bypass router as an example: the main router is 192.168.10.1, OpenWrt is 192.168.10.2, and the test PC is 192.168.10.100. All devices use the subnet mask 255.255.255.0. These addresses are examples only. Replace them with your own subnet before deployment, and make sure the bypass router's address is outside the DHCP pool.
| Device | Example settings | Role |
|---|---|---|
| Main router | 192.168.10.1 | Connects to the upstream network and continues providing DHCP during the initial setup. |
| OpenWrt | 192.168.10.2, with upstream gateway 192.168.10.1 | Forwards test-device traffic and runs the core and local DNS service. |
| Test PC | Set both gateway and DNS to 192.168.10.2 initially | Verify the traffic path without changing other devices. |
| Other devices | Continue using the gateway and DNS assigned by the main router | Keep the normal internet path and limit the impact of testing. |
The gateway determines the next hop for packets; DNS determines how domain names are resolved. They are separate settings. Changing DNS alone usually won't route regular web connections through the bypass router. Changing the gateway alone doesn't guarantee that devices will use its DNS policy. Browser Secure DNS, apps with their own resolvers, and the IPv6 default route can also create alternate paths.
Choosing a Core: Check the Node Configuration
OpenWrt runs a core process, not a desktop client interface. v2rayN manages desktop configurations, while v2rayNG and v2flyNG manage Android configurations; their menus don't map directly to router settings. Server address, port, identity fields, transport, TLS, and service name must be translated into a configuration supported by the chosen core.
V2Fly Core
RecommendedThis guide focuses on the V2Fly V2Ray 5.x command line. If you already have a compatible VMess or similar configuration, start with the corresponding core to reduce migration variables. Still verify transport fields against the version in use.
Best for: verifying the bypass router path with an existing compatible configuration
Xray Core
If a node explicitly requires REALITY or XTLS Vision, use an Xray version that supports those features. Simply renaming the executable to v2ray doesn't make all configuration fields and command-line options interchangeable.
Best for: nodes that explicitly depend on Xray-specific settings
Bottom Line: Verify the Complete Node Configuration
Document the protocol, transport, security layer, and core version before choosing which core to deploy. Seeing “VLESS” or “VMess” alone isn't enough to determine whether the full node configuration is compatible.
Before installation, check the CPU architecture, available storage, and OpenWrt package sources. Run uname -m to check the architecture, but note that packages also depend on the distribution ABI and other dependencies. Don't mix package sources from different OpenWrt branches. A subscription URL isn't a native core configuration; use a tool that explicitly supports its format to parse it, then test the updated configuration before putting it into service.
- Record the output of
v2ray versionand system details fromcat /etc/openwrt_releaseto make issues easier to reproduce. - Store node credentials only in a restricted configuration file—for example, set its permissions to
600. Remove credentials and subscription URLs before sharing logs. - If you use domain or geolocation rules, make sure the required data files exist and their paths match the current core configuration.
- Manage the process with OpenWrt's procd service manager, keeping startup logs and restart policies. Running a process in the foreground over SSH once doesn't make it start on boot.
Deployment Order: Forward Traffic First, Then Intercept One Device
Don't change DHCP, DNS, and firewall settings for the entire network at once. Back up your configuration first, then change settings on just one test PC. The menu paths below use a typical LuCI interface; labels may vary by translation or version. Verify the fields on screen rather than relying on button positions.
-
Back Up Your Settings
Go to “System” → “Backup / Flash Firmware” → “Generate archive” and save the current configuration. Note the PC's original gateway and DNS, and keep a way to access the OpenWrt admin address directly.
-
Set a Static Address
Go to “Network” → “Interfaces” → “LAN” → “Edit” and confirm the static address is the example
192.168.10.2/24, with upstream IPv4 gateway192.168.10.1. Check for a second DHCP server to prevent two devices from assigning addresses at the same time. -
Verify Forwarding
Leave transparent proxying disabled for now; change only the test PC's gateway to the bypass router. Go to “Network” → “Firewall” and check forwarding policies for the relevant zones and any required source NAT. Confirm that a regular direct connection works.
-
Test the Core
Prepare a complete configuration and run
v2ray test -c /etc/v2ray/config.json. If it passes, run the core in the foreground and inspect the logs; then hand it over to the configured procd service. Commands differ in older versions, so checkv2ray helpfirst. -
Limit Traffic Interception
Match traffic from the test PC at
192.168.10.100only, then configure the transparent inbound, policy routing, and firewall. Once direct connections, proxy traffic, and DNS all behave as expected, consider distributing the bypass router gateway through DHCP.
# V2Fly V2Ray 5.x configuration check and foreground run example
v2ray version
v2ray test -c /etc/v2ray/config.json
v2ray run -c /etc/v2ray/config.json
# Check system status in a separate SSH session
ip -4 route show
ip -4 rule show
ss -lntup
logread -e v2rayTransparent Proxying: Inbound, Marks, and Policy Routing
Transparent proxying doesn't mean exposing the system proxy port. In common setups, REDIRECT is mainly used for TCP redirection. TPROXY can handle TCP and UDP, but requires kernel modules, transparent socket support, packet marks, and policy routing to work together. Configure the inbound to match the mechanism used by the firewall.
OpenWrt 22.03 switched its default firewall stack to firewall4 and nftables. Commands from older iptables tutorials aren't a reliable guide to current setups. First check which firewall the system actually uses and confirm that the required TPROXY support is available. A command succeeding doesn't prove that a rule matched the intended traffic.
These are planning values, not measured results or universal requirements. TPROXY rules send selected connections to the 12345 inbound and set a mark. The corresponding ip rule sends marked packets to a separate routing table, which needs a local delivery route. Check the mark, mask, and table ID as a set, and make sure they don't conflict with existing policies.
| Layer to check | What to verify | What happens if it's missing |
|---|---|---|
| Traffic entry | Source address, LAN interface, and TCP/UDP match criteria | The core logs no connections, or traffic from other devices is intercepted by mistake. |
| Exclusions | LAN traffic, management addresses, broadcast and multicast, and node server addresses | The admin page becomes unreachable, LAN services break, or proxy traffic loops. |
| Transparent inbound | Listening address and port, original destination lookup, and TPROXY socket options | Traffic reaches the router, but no process is available to accept it. |
| Policy routing | Packet mark, rule priority, and local delivery route | Packets are forwarded or dropped, and the inbound still receives no requests. |
| Core outbound | Server settings, DNS, and the order of direct/proxy rules | The inbound logs requests, but outbound connections fail. |
Initially, intercept only traffic forwarded from the LAN. Don't immediately intercept the router's own OUTPUT traffic. Connections the core makes to remote servers are new local connections; sending them back to the transparent inbound creates a loop. If you later need to intercept local traffic, use a separate outbound mark or process exclusion, and account for changes to the IP addresses resolved from node domains.
- Run
nft list rulesetto inspect rule order and counters and see whether traffic is actually matching. - Run
ip -4 rule showandip -4 route show table 100to check the example policy routing path. - During troubleshooting, check whether flow offloading affects what you see. Hardware or software offloading may cause later packets to bypass the expected processing path.
- Use a firewall4-supported persistent method to maintain custom rules. Rules added temporarily in a shell may be lost when the firewall restarts.
DNS and Traffic Routing: Make the Resolution Path Clear
Plan DNS as a separate service. Devices query port 53 on the bypass router, and a local resolver such as dnsmasq forwards requests to the appropriate upstream. The DNS module in a V2Ray configuration isn't automatically a DNS service exposed to the LAN; configure a listening service or forwarding path separately.
One design that's easy to check is to have the local DNS service listen on LAN port 53 and forward selected queries to a resolver already running locally at 127.0.0.1:1053. These ports are examples; confirm that a service is actually listening. If the downstream resolver sends queries back to 192.168.10.2:53, you'll create a DNS forwarding loop.
- Keep local names local: Resolve LAN hostnames and internal domains locally instead of sending everything to a remote server.
- Resolve node domains first: The server address must be resolved before the proxy can connect. Don't make your only DNS path depend on a proxy that isn't running yet.
- Put specific rules first: In the core's routing rules, handle LAN traffic, explicitly direct domains, and selected proxy domains before setting the default outbound.
- Test UDP separately: Working TCP websites don't prove that UDP is being intercepted. Check DNS, real-time communications, and QUIC connections separately.
- Plan IPv6 separately: If you intercept IPv4 only, IPv6 connections may use a different default route. You can temporarily disable IPv6 on the test device during setup; a production configuration should include matching routing, DNS, and firewall policies.
# Run this from a test PC with nslookup installed
nslookup example.com 192.168.10.2
# Check listeners and routing policies on OpenWrt
ss -lnup
ip -6 route show
nft list rulesetBottom Line: Verify the Path in Logs, Not by Guessing from Speed Tests
Test one destination that should connect directly and one that should use the proxy. Compare DNS logs, rule counters, and core outbound tags. A website loading proves only that a connection completed, not that it used the expected outbound.
After transparent interception, traffic may contain only the destination IP. If routing depends on domain names, make clear where that domain information comes from; core sniffing can identify data in some protocols, but it can't recover domain names for every app. DNS responses, domain rules, and actual connections should agree. See the DNS configuration guide for related fields, but don't treat desktop client settings as OpenWrt firewall rules.
Common Issues: Troubleshoot One Layer at a Time
Nothing works after changing the gateway. What should I check first?
First restore the test PC's gateway to the main router and confirm the upstream connection works. Then disable transparent interception and test basic forwarding through the bypass router. Check LAN forwarding policies, the upstream default route, and the return path. Don't start by switching nodes.
The core is running. Why are there no connection logs?
Check that the PC's actual gateway is 192.168.10.2, then inspect the nftables rule counters. If counters increase but the inbound has no logs, check the 12345 listener and the mark-to-routing-table mapping. Also make sure the browser isn't still using an explicit proxy.
IP connections work, but domain names time out. Why?
Run nslookup example.com 192.168.10.2. Check whether port 53 is listening, DNS requests from the LAN to the router are allowed, and the upstream resolver is reachable. If forwarding through 1053, confirm that a service is actually listening on that port.
Web pages load, but games and some apps don't. Why?
Check whether you've configured only TCP redirection and whether the node and outbound support the UDP traffic required. Check the IPv6 default route and related rules. Don't mask missing interception by permanently blocking a protocol; first confirm which transport the app actually uses.
The proxy stops working after the firewall restarts. What should I do?
Compare nft list ruleset and ip rule show before and after the restart. Custom rules, policy routing, and the core service all need persistence and an appropriate startup order. Also check that another configuration isn't adding the same mark a second time.
When sharing logs, keep only timestamps, inbound and outbound tags, and error types. A timeout could mean the server is unreachable, DNS failed, or the return path is broken; use ss -lntup to find the process listening on a port. Don't share only a screenshot of the last “connection failed” line, and never publish a full subscription URL or identity fields.
Verify and Roll Back Before Expanding to the Whole Network
A bypass router centralizes management, but it can also increase the scope of an outage. A single-device trial should cover reboots, DNS lookups, LAN access, direct and proxied outbound traffic, UDP, and IPv6. Until these checks pass, leave DHCP on the main router as it is and don't rush to move every device to the bypass gateway.
- Test after reboot: Restart OpenWrt and confirm that the core service, DNS, transparent rules, and policy routing all come back without duplicate rules.
- Test LAN access: Open the main router's admin page and access file shares and other local services. Confirm that LAN exclusion rules don't block them.
- Test failure behavior: Stop the core and observe what happens to intercepted connections. Unless you've explicitly designed a fail-open path, proxied traffic will usually fail; don't assume it will switch to a direct connection automatically.
- Test rollback: Restore the test device's original gateway and DNS, then remove custom interception rules and policy routes. Stopping the core while leaving redirection rules in place can still cut off internet access.
- Expand only after testing: Once you distribute the bypass gateway and DNS through the main router's DHCP settings, renew client leases and check the addresses they actually receive. Devices with static settings need to be handled separately.