Router deployment is about more than copying a desktop configuration. The gateway, traffic interception, DNS, and core outbound route must work together. For users planning to route proxy traffic through a Linux or OpenWrt device, this guide compares main routers and bypass routers, then covers a single-device pilot, transparent proxy limitations, hardware requirements, and rollback procedures.
1. Where to Deploy: Main Router vs. Bypass Router
A main router typically handles internet access, DHCP, NAT, and firewall rules. Running the core on it provides direct access to all forwarded traffic, but updates, misconfigured rules, or limited resources can affect the entire local network. A bypass router is an additional forwarding device. Start by setting a few test devices to use it as their gateway to keep the trial contained.
Pilot with a Dedicated Bypass Router
RecommendedKeep the main router's existing internet connection and address assignments. Change the gateway only on test devices. If anything goes wrong, restore their original gateway; this is easier to troubleshoot and roll back than changing forwarding rules network-wide.
Best for: First-time deployments and home networks that need device-by-device testing
Run Directly on the Main Router
Handle network access, firewalling, and proxy traffic on one device. Rules are centralized, but check CPU, memory, and storage headroom, and keep a local management path available.
Best for: Networks managed by users comfortable with firewall rules
Use Client Apps on End Devices
Use v2rayN on desktop. On Android, choose v2rayNG or v2flyNG based on the node requirements. This avoids changing the local network gateway and gives you a baseline for testing nodes before router deployment.
Best for: A few devices that need a proxy, with no network changes planned
This guide uses a single-interface bypass router: the main router is 192.168.10.1/24, the bypass router is 192.168.10.2/24, and the test device is 192.168.10.100/24. Adjust these addresses for your subnet, and exclude the bypass router's address from the DHCP pool. These are example settings, not factory defaults.
Test device 192.168.10.100
Default gateway → bypass router 192.168.10.2
├─ Direct outbound → main router 192.168.10.1 → internet
└─ Proxy outbound → main router 192.168.10.1 → remote node
Bypass router default gateway: 192.168.10.1
Main router default gateway: ISP upstream2. Choose a Core: Check Protocols, Architecture, and Config Format
Xray and V2Fly are standalone proxy cores, not router operating systems. v2rayN, v2rayNG, and v2flyNG are client interfaces; v2rayNG uses the Xray core, while v2flyNG uses V2Fly. Router deployment requires the right Linux binary, configuration file, and service startup method—not a desktop client.
- Check the CPU architecture: Run
uname -m, then check the firmware's package architecture, bitness, and runtime environment. Don't choose a binary based only on a device label such as “ARM.” - Check the node protocol: Verify whether the node uses VMess or VLESS, along with its transport, TLS settings, and server requirements. For REALITY nodes, choose an Xray build that explicitly supports the required configuration; don't assume configuration fields are interchangeable between the two cores.
- Check the configuration version: V2Fly configuration formats vary by version, and Xray fields evolve over time. Check the version actually installed on the device; don't copy an entire JSON file from another core.
- Check subscription handling: A subscription URL is not a universally supported auto-updating core configuration. A panel or management script usually parses the subscription, generates the configuration, and schedules updates and reloads. With a bare core, you'll need to implement these steps separately.
3. Transparent Proxying: Policy Routing Matters as Much as Listening Ports
With an explicit proxy, an app sends connections to an HTTP or SOCKS listening port. A transparent proxy intercepts connections in the gateway's forwarding path and passes them to the core. A listening port alone won't capture local network traffic or establish a return path. Linux firewall rules, policy routing, and core inbound settings must all work together.
The ports and routing table ID above are examples, not defaults for any management interface. Before using routing table ID 100, make sure no other service is using it. Transparent inbound also requires the transparent socket options supported by the selected core and must match how the firewall delivers traffic.
| Method | How it works | Deployment notes |
|---|---|---|
| REDIRECT | Redirect connections to a local listening port | Commonly used for TCP; a TCP setup cannot be applied unchanged to UDP |
| TPROXY | Transparent sockets receive traffic and use marks and policy routing to deliver it locally | Supports TCP/UDP; requires compatible firmware kernel modules and firewall support |
| Explicit SOCKS proxy | The app connects directly to the proxy's listening address | Useful for initial core testing; the app must support and correctly use a proxy |
OpenWrt systems using firewall4 generally manage rules with nftables, so iptables commands in older guides may not work as written. A common TPROXY setup marks traffic, uses ip rule to select a dedicated routing table, then routes traffic locally to a transparent socket. Make sure the mark and mask don't conflict with existing multi-WAN or policy-routing services.
- Allow loopback, multicast, broadcast, local network management subnets, and any traffic the bypass router itself needs to send directly.
- Exclude the node server address and the core's own outbound traffic to avoid a proxy loop, where proxy connections get sent back through the proxy.
- Handle LAN-forwarded traffic separately from traffic originating on the router. PREROUTING rules don't automatically capture every local connection.
- Check whether software or hardware flow offloading bypasses the expected rules. During troubleshooting, disable relevant offloading and compare the results.
4. Gateway and DNS: Start with One Device, Then Expand
There is no universal bypass-router settings page. The steps below use common OpenWrt LuCI menus; labels may vary by version. Export your configuration and note the main router's management address before making changes. Don't change the management IP, DHCP, and firewall all at once unless you have an alternate way to access the device.
-
Set a Static Management Address
On the bypass router, go to “Network” → “Interfaces” → “LAN” → “Edit” → “General Settings.” Set the static address to
192.168.10.2, the netmask to255.255.255.0, and the upstream IPv4 gateway to192.168.10.1. -
Keep One DHCP Server
Keep address assignment on the main router. On the bypass router, go to “Network” → “Interfaces” → “LAN” → “Edit” → “DHCP Server” → “General Setup” and check “Ignore interface.” This prevents both devices from handing out conflicting settings.
-
Change the Gateway on One Device
In the test device's IPv4 settings, keep the existing address and netmask, and change only the gateway to
192.168.10.2. Confirm that IPv4 forwarding is enabled on the bypass router and that the firewall allows the required forwarding direction. -
Check the DNS Path
Point the test device's DNS to
192.168.10.2only after the bypass router has a reachable DNS service. Check UDP/TCP port 53, the upstream DNS route, and whether the node server's hostname resolves before the proxy starts. -
Expand and Verify
After the single-device setup is stable, if the main router also runs LuCI, go to “Network” → “Interfaces” → “LAN” → “Edit” → “DHCP Server” → “Advanced Settings.” Add
3,192.168.10.2to the DHCP options. To distribute DNS at the same time, also add6,192.168.10.2, then renew the devices' leases.
A single-interface bypass router on the same subnet can create an asymmetric path: a device sends direct traffic through the bypass router, but the main router replies directly to the device. This can affect connection tracking, statistics, and firewall decisions. Whether to apply source NAT to traffic forwarded by the bypass router depends on the topology. Source NAT can make the return path more predictable, but hides the original device address; it isn't a one-size-fits-all solution.
5. Hardware Requirements: Measure Your Workload, Not the Ethernet Port Speed
A gigabit Ethernet port indicates link negotiation capability, not that encrypted proxy traffic will reach the same speed. Single-core CPU performance, protocol and transport choices, memory pressure, cooling, and node performance all affect throughput. Small routers also need resources for Wi-Fi, connection tracking, and the firewall. For a bypass router, check network adapter drivers and virtualization overhead as well.
| Area | What to check | How to assess it |
|---|---|---|
| CPU and cooling | Use top to check per-core usage under sustained load for 10 minutes | If throughput plateaus while one core is maxed out, check CPU capacity and thermal throttling first |
| Available memory | Check free and kernel logs; take another snapshot during rule updates | Watch available memory, process exits, and out-of-memory kills |
| Storage space | Use df to check writable partitions and temporary directories | Leave room for program updates, rule files, and log rotation |
| Concurrent connections | Repeat the same task with 1 device, then 3 devices | Compare latency and error rates; don't record peak download speed alone |
Use the same wired device, node, and download target for all tests. Record three baselines in order: direct connection, proxy via an end-device client, and proxy via the bypass router. Repeat each test three times and record throughput, latency, CPU, and memory. If the node itself fluctuates significantly, don't attribute all differences to the bypass router. This is a testing method, not a performance guarantee for any specific device.
Conclusion: Find the Bottleneck Before Upgrading
If one bypass-router CPU core stays maxed out and an end-device client consistently performs better, upgrading CPU capacity may be the right first step. If both setups slow down, compare another time or node first; don't replace the whole device just because its Ethernet port has a lower rated speed.
6. Troubleshooting: Check Addressing, Forwarding, Inbound, and Outbound in Order
Being able to open the bypass router's management page only proves that its local network address is reachable; it doesn't confirm internet forwarding or proxy outbound traffic. First check the bypass router's default route, then confirm that the transparent inbound actually receives traffic, and finally use connection logs to see which outbound the routing rules selected. Debug logs may contain target hostnames and addresses. Restore the normal log level and configure rotation when troubleshooting is complete.
# Read-only diagnostic commands below; some minimal firmware builds may require installing the relevant tools first.
ip -4 addr show
ip -4 route show
ip -4 rule show
ip -4 route show table 100
sysctl net.ipv4.ip_forward
ss -lntup
nft list ruleset
free
df -hip -4 route show table 100 applies only if your setup actually uses the example table ID in this guide. If a management service uses a different routing table, check that table's actual ID. ss can confirm ports and processes, but a listening socket alone doesn't prove that transparent proxy rules are correct. When reviewing nft output, check the existing ruleset and match counters. Don't flush the entire firewall to “rule out interference.”
After switching the gateway to the bypass router, no websites load. What should I do?
First restore the test device's gateway to 192.168.10.1. Then check that the bypass router's default route points to the main router, net.ipv4.ip_forward is set to 1, and the forwarding firewall allows traffic. Get basic forwarding working before re-enabling traffic interception rules.
Websites load, but games or voice calls don't connect. Why?
Check whether the app relies on UDP, then verify that the transparent inbound, TPROXY rules, policy routing, and node outbound all support that traffic. If you have TCP redirection only, changing DNS won't add UDP interception.
Some domains don't follow the configured routing rules. Why?
First check whether DNS requests are handled by the expected resolver, then review rule order and the target information in the logs. An app's built-in encrypted DNS may bypass local port 53. Sniffing also can't guarantee that every hostname will be recovered, so test each app separately.
The setup stops working after a reboot. Does that mean the node is down?
Check in order that the core service started, transparent rules loaded, policy routes are present, and the system clock is synchronized. Add these steps to your firmware's service management process instead of running commands just once in an interactive shell.
7. Go Live and Roll Back: Include Gateway Settings in Routine Maintenance
A stable bypass router depends on startup order and failure handling as well as configuration files. An unsynchronized clock, DNS that isn't ready, or a failed rules download can disrupt startup. Before applying an update, validate the new configuration, then replace the current file. Don't treat a running process as proof that the network path is working.
- Save a recoverable configuration: Back up network, firewall, DNS, and core settings separately. Record the listening ports, marks, and routing table IDs in use.
- Test a cold boot: After restarting, check address assignment, node hostname resolution, direct and proxy paths, and confirm that the management interface is still reachable.
- Limit access: Expose management pages and proxy listeners only to the local network devices that need them. Never expose an unauthenticated proxy port to the internet.
- Plan how to roll back: First restore the gateway and DNS settings on devices or in DHCP, then remove interception rules, policy routes, and services. Stopping the core while leaving interception rules in place can send traffic to a port with no listener.
If only one or two devices need a proxy, end-device clients are usually easier to maintain. For network-wide traffic interception, proceed in stages: test one device, verify DNS, check UDP and IPv6, then roll out across the network. For parameter definitions, see the Terminology Guide. For the difference between connection scope and routing rules, see the User Guide.