OpenWrt Bypass Router Setup: Run Xray or V2Fly for Transparent Proxying

1. Main Router or Bypass Router: Map the Traffic Path First

Transparent proxying only works when traffic actually passes through the device running the core. Having an OpenWrt device on the same LAN does not automatically route other devices through it. If the main router is the default gateway, it can intercept traffic along the forwarding path. If a bypass router is simply connected to the switch, clients generally need to use it as their default gateway, or the main router must use policy routing to send selected traffic to it.

With a single-NIC bypass router, the main router and client are often on the same subnet. Traffic may reach the bypass router on the outbound path, but the main router may send return traffic directly to the client. Whether source NAT is needed depends on the return path, stateful firewall, and connection tracking; enabling NAT is not a universal fix. Forwarding through the same interface can also trigger ICMP redirects, so check that clients are not bypassing the intended gateway as a result.

2. Plan Addresses and Ports: Avoid Running Two DHCP Servers

This guide uses a clearly defined example network: main router 192.168.10.1, bypass router 192.168.10.2, test computer 192.168.10.100, and subnet mask 255.255.255.0. These are example values, not factory defaults. Before using them, make sure the addresses are available and exclude the bypass router’s address from the DHCP pool.

Ports must match the actual listening configuration. Here, 1053 represents an optional local DNS resolver, and 12345 represents the transparent proxy inbound listener. Installing a core does not automatically create either listener. dnsmasq usually serves clients on port 53; do not let another process compete for port 53 on the same address.

3. Xray or V2Fly: Choose a Core That Supports Your Protocol

V2Ray is a common name for the project and its ecosystem, but deployment requires choosing a specific core. Xray and V2Fly are not interchangeable names, and the same configuration is not guaranteed to work with both. If your existing connection requires REALITY or XTLS Vision, check that the relevant Xray version supports it. For VMess and other connections, confirm compatibility with the server settings, transport, and core version you choose.

• Verify the connection on desktop: First, confirm the connection works in v2rayN and record the protocol, address, port, user ID, TLS settings, transport, and related fields. A working desktop client does not mean the router configuration is correct.
• Compare Android clients: v2rayNG uses the Xray core, while v2flyNG uses the V2Fly core. A client’s saved subscription and the core’s runtime configuration are different types of files.
• Know what subscriptions contain: A subscription may be a set of encoded share links or a format specific to a client. A standalone core typically reads its own configuration file; it will not automatically turn an arbitrary subscription URL into a runnable configuration.
• Match the platform: Choose a build based on the OpenWrt package architecture and processor information. A device advertised as “64-bit” is not necessarily able to run a given binary; instruction set and build compatibility matter too.

cat /etc/openwrt_release
ubus call system board
uname -m

# Check the version of the installed core
xray version
v2ray version

Prefer packages from a software feed that matches your firmware version and architecture. OpenWrt 22.03 and later use firewall4 and nftables by default, so older iptables-based guides should not be assumed to apply. Package management tools can also vary by firmware version; check which tool your system uses, and do not mix feeds from different releases.

4. OpenWrt Setup: Configure the Network, Core, and Forwarding Separately

The menu paths below refer to a typical Chinese-language LuCI interface; field names may vary by firmware and translation. Back up the current configuration before making changes, and keep one device able to access the main router directly. For the first test, do not change the DHCP gateway for the entire LAN or replace all firewall rules over a remote connection.

1. Back Up the Configuration

   Go to “System” → “Backup / Flash Firmware” → “Generate archive” and save the current configuration. Note the main router’s address, DHCP range, and bypass router cabling, and prepare a direct management path in advance.

2. Set a Static Address

   Go to “Network” → “Interfaces” → “LAN” → “Edit” → “General Settings” and set the static address to 192.168.10.2, the subnet mask to 255.255.255.0, and the gateway to 192.168.10.1. Confirm that the management address is reachable before changing DHCP.

3. Verify the Core

   Install Xray or V2Fly for the matching architecture and create a configuration in the corresponding format. Check the syntax, then start a temporary explicit proxy listener and test the connection. Do not intercept all traffic yet.

4. Configure Forwarding

   Set up the transparent listener, traffic marks, and any required policy routing for the firewall backend in use. Start by limiting the source to 192.168.10.100, and exclude the bypass router itself, the core’s outbound traffic, and management subnets.

5. Connect the Test Device

   Set the test computer’s default gateway and DNS to 192.168.10.2, and disable its system proxy. Test direct IP access, a proxy destination, and domain resolution separately so a desktop client cannot mask routing problems.

6. Enable Startup

   After testing succeeds, configure the procd service and persistent firewall rules. Check the service status under “System” → “Startup,” then reboot and verify that both the rules and process come back up.

The commands below use the agreed configuration locations for illustration. Run only the set for the core you installed, and make sure the file path matches the service startup arguments. The V2Fly example uses the v5 command format. For older versions, check the built-in help instead of copying the arguments as-is.

# Check the Xray configuration
xray run -test -config /etc/xray/config.json

# Check the V2Fly v5 configuration
v2ray test -c /etc/v2ray/config.json

# OpenWrt service logs
logread

A successful configuration check only means the file can be parsed; it does not prove the remote server is reachable. For production, also check process permissions, log output, listening addresses, system time, and certificate validation. If the router reboots before its clock is synchronized, TLS connections may fail, so include time synchronization in your post-startup checks.

5. Transparent Proxying: Firewall Interception and Core Routing Are Separate Layers

OpenWrt determines which packets reach the core; the core then decides whether incoming connections use the direct or proxy outbound. Core routing rules alone do not send client traffic into the core without a transparent listener. Likewise, firewall forwarding without a correctly configured outbound cannot establish a proxy connection.

For Xray, a transparent listener can use dokodemo-door with followRedirect and matching socket settings; the fields must be combined for the specific mode in use. TPROXY is commonly paired with a dedicated routing table that sends packets with a specified mark to the loopback device as local traffic. Mark values and routing table IDs are local choices; make sure they do not conflict with an existing VPN, policy route, or other service.

• First exclude router management addresses, LAN destinations, multicast, and broadcast traffic. Do not send all device discovery and management traffic through a remote proxy.
• When the firewall should intercept traffic from the test device only, match on its source IP. Expand to clearly defined device groups gradually; do not start by matching the entire LAN.
• The core’s own outbound connections must bypass the transparent listener, or they can loop back into the proxy.
• Check flow offloading during testing. Some fast-forwarding paths may bypass the intended processing for subsequent packets. Rule out this interference first, then decide whether to re-enable it.

6. DNS and IPv6: Traffic Can Bypass Routing Even with the Right Gateway

After pointing client DNS to the bypass router, check where the bypass router sends queries and whether that path matches your routing goals. It is easier to troubleshoot when domains meant for direct access use an appropriate resolver, while proxy domains are resolved through the intended channel, rather than sending all queries through the same outbound. Avoid forwarding dnsmasq queries to the core while the core sends its own DNS queries back to dnsmasq, creating a resolution loop.

1. Define the listener path. Clients query 192.168.10.2:53. If you configure a separate local DNS service, dnsmasq can forward queries to 127.0.0.1:1053. That service must actually support the DNS queries you need; a regular proxy port is not a substitute.
2. Check forwarding settings. Under “Network” → “DHCP and DNS,” check DNS forwarding and upstream resolver settings, and confirm that the resolver provided by your ISP is not being used unexpectedly. Record the current values before changing them so you can roll back.
3. Distinguish the core’s DNS features. Whether the core’s built-in DNS is used for routing decisions and whether it provides a DNS inbound that LAN clients can access are separate questions. The presence of a DNS field in the configuration does not mean client DNS is being intercepted.
4. Check encrypted DNS. A browser’s secure DNS setting or an app’s built-in resolver can bypass the client’s DNS settings. For testing, use a consistent resolution path first, then decide how to handle it through device settings or routing policies.
5. Check IPv6 separately. After changing the IPv4 gateway to the bypass router, a client may still connect directly upstream using IPv6 routes advertised by the main router. Set up corresponding IPv6 forwarding and DNS policies, or temporarily disable IPv6 on the test device to isolate the problem.

FakeDNS returns synthetic addresses, which the core then maps back to the original domain. It is not a “turn it on to prevent leaks” switch: the address range, client cache, transparent listener, and routing logic must work together. For a first deployment, verify regular DNS and TCP/UDP forwarding before considering FakeDNS. This keeps address-mapping issues separate from gateway problems.

7. Troubleshooting and Rollback: Check Addresses, DNS, and Forwarding in Order

When a connection fails, check the basic network before changing protocols. Confirm that the test computer can reach the bypass router’s management address, the bypass router can reach the main router, and the core’s explicit proxy works. Once all three are confirmed, focus on transparent interception and DNS. Some test tools come from optional packages; if a command is missing, check whether it is installed before concluding the network is broken.

# Check addresses, routes, and policy rules on the bypass router
ip addr show
ip route show
ip rule show

# Inspect the active rules on a system using firewall4
nft list ruleset

# Check a specified DNS server from a test client with nslookup
nslookup example.com 192.168.10.2

A successful bypass-router deployment is not just a core process marked “running.” The network path must be understandable, verifiable, and reversible. First verify the protocol connection, then confirm traffic reaches the core, and finally confirm that direct and proxied traffic leave through the right outbound. Desktop and Android clients are useful for verifying connection settings; OpenWrt also requires managing the firewall, gateway, DNS, and service lifecycle.