Direct-Run Xray on a Bypass Router: Share One Proxy Path Across Your Home Network

Define the bypass router’s role in the network first

Running Xray directly on a bypass router is not simply a matter of copying a desktop client to another device. It moves the proxy entry point from one computer into the LAN forwarding path: endpoints still make ordinary TCP, UDP, and DNS requests, while the gateway or bypass router identifies the traffic, sends it to an Xray inbound, applies routing rules, and forwards it through either a direct or proxy outbound. TVs, tablets, computers, and other LAN devices do not need separate node configurations. As long as their traffic actually passes through the bypass router, they can share the same proxy path and split-routing rules.

Two topologies are common. In the first, the bypass router becomes the default gateway for selected devices. The main router continues to handle the uplink, Wi-Fi access, and DHCP, while some endpoints point their gateway to the bypass router through a static setting or DHCP option. In the second, the main router remains the default gateway and policy routing forwards selected traffic to the bypass router. The first offers a clearer path and makes packet-flow debugging easier; the second requires fewer endpoint changes but depends on the main router having sufficiently capable policy-routing support.

Before deployment, map the actual path instead of writing the configuration first. Record at least four items: the main router’s address, the bypass router’s address, the LAN subnet, and the upstream DNS addresses. Confirm that the bypass router has one fixed LAN address and will not receive a different DHCP lease after a reboot. If the LAN contains multiple subnets or a guest network, note which subnets may reach the bypass router and which must remain isolated.

Where to place the core, configuration, and runtime directories

The minimum direct-run setup consists of the Xray executable, the main configuration, geo-rule data, runtime logs, and service management. There is no single correct directory layout, but responsibilities should be separated. Place the executable in the system program directory, configuration in persistent storage, rule data in a suitable read-only data directory, and logs somewhere that supports rotation. Do not keep the only copy of the configuration in a temporary directory: firmware upgrades, reboots, or cleanup jobs may remove it.

/etc/xray/
├── config.json
├── conf.d/
│   ├── 10-inbounds.json
│   ├── 20-outbounds.json
│   ├── 30-dns.json
│   └── 40-routing.json
/usr/share/xray/
├── geoip.dat
└── geosite.dat
/var/log/xray/
├── access.log
└── error.log

A single configuration file is best for initial validation because the load order is obvious and syntax troubleshooting has one entry point. Split configurations are easier to maintain long term, allowing inbound, outbound, DNS, and routing sections to be managed separately. Confirm that the startup method supports loading a directory and understand how arrays and objects are merged across files. Never assume that every filename is loaded automatically; the core reads only the location specified by its startup arguments.

Keep at least two outbound types: one proxy outbound and one direct outbound. The proxy outbound’s protocol, address, port, user identifier, transport, security layer, server name, flow, and related parameters must match the server side. VMess and VLESS are different protocols; changing only the address does not make their fields interchangeable. If the configuration comes from a subscription, first verify the target node in the desktop client, then convert its parameters into an Xray configuration. A subscription URL is not a complete gateway policy that Xray can execute directly. It usually supplies node details, but does not define LAN exceptions, DNS paths, or transparent inbound rules for the bypass router.

Service management should meet three conditions: start after the system network is initialized, restart when the process exits, and retain readable logs when the configuration is invalid. After editing the configuration, run the core’s configuration test before reloading the service, so one syntax error does not interrupt the entire home-network path. Use warning or info logging during deployment; once stable, avoid retaining excessively detailed access logs indefinitely, as they can cause continuous writes to flash storage.

Transparent Proxying: REDIRECT, TPROXY, and TUN

The goal of transparent proxying is to let endpoints connect without manually entering an HTTP or SOCKS proxy address. The gateway intercepts connections with firewall and policy-routing rules and sends them to an Xray transparent inbound. Each method has different requirements for protocol support, kernel capabilities, and maintenance effort. Choose based on the traffic you actually need; there is no need to layer all three together.

REDIRECT: A simplified TCP-first path

REDIRECT rewrites the destination of TCP connections in the gateway firewall so they enter a local listening port. Its configuration is relatively straightforward and works well for first validating a TCP gateway path. Its limitation is that it primarily handles TCP, making it less capable for UDP, real-time communications, and scenarios that depend on the original destination. If the home network only needs a few specified devices to access web services, start here. If you need broader TCP and UDP interception, evaluate TPROXY or TUN.

TPROXY: Policy routing that preserves the original destination

TPROXY can preserve the original destination address while intercepting TCP and UDP, typically working with packet marks, a dedicated routing table, and local routing. The firewall marks matching packets, policy routing sends them back to the local transparent inbound, and Xray reads the original destination before selecting an outbound. It suits gateway environments with the required kernel modules and a need for precise control over source devices and destination subnets.

The difficult part of TPROXY is not the node fields but closing the forwarding loop. Traffic that Xray generates to reach a proxy server must not be captured by the transparent rules and sent back into the Xray transparent inbound. Also exclude LAN addresses, multicast, broadcast, loopback, link-local addresses, and management ports that should not be proxied. The proxy server’s own address must be direct as well; otherwise packets connecting to the remote server will re-enter the same inbound.

TUN: Unified interception through a virtual network interface

TUN receives Layer 3 traffic through a virtual network interface, after which Xray sends connections to the appropriate outbound. It can reduce some firewall-redirection complexity and provide more consistent TCP and UDP handling. But TUN does not complete gateway deployment automatically: the system still has to route target traffic to the virtual interface and handle DNS, MTU, LAN bypasses, and traffic generated by the core itself. On limited hardware, TUN’s protocol-stack processing and concurrent connections can increase CPU and memory pressure.

Choose among the three methods in sequence: use REDIRECT when validating a small amount of TCP traffic; consider TPROXY when you need to preserve the original destination and handle TCP and UDP precisely; consider TUN when virtual-interface support is mature and you want unified interception. Once you choose a primary path, keep the rules single-purpose. Avoid having the same packet captured by TUN routing and then redirected by the firewall into TPROXY.

DNS is a critical part of bypass-router deployment

Many cases where a node works but websites do not open are not outbound connection failures; the DNS path is simply out of sync with the routing policy. An endpoint sends a domain to a resolver and receives an address before establishing a connection. If DNS bypasses the bypass router, Xray may see only the destination IP and lose the domain information needed for domain rules. If every query is incorrectly forced through one path, queries may time out, return results unsuitable for the current exit, or loop back on themselves.

First decide who provides DNS to LAN endpoints. The main router can continue answering while forwarding upstream queries to the bypass router, or selected endpoints can use the bypass router’s address directly. Either way, keep one clear default path on the LAN where possible. When an endpoint receives both the main router and bypass router as DNS servers, it is not guaranteed to use them in the listed order. Queries may switch between resolvers, producing different results for the same domain.

Next, distinguish local domains from public domains. Router management names, home-device names, and private LAN zones should go to a resolver that knows the local records, not to the public internet. Public domains can be sent to direct or proxy DNS according to the rules. If Xray routing needs domain information, ensure that the transparent inbound can obtain the domain or that DNS responses have a reliable association with the core’s cache.

domainStrategy determines how routing matches domains and IP addresses. When relying solely on domain rules, there is no need to resolve every connection again. Consider on-demand resolution only when geoip rules need to participate in decisions for domain-based connections. Excessive resolution adds DNS round trips and may turn traffic that should be handled by domain rules into premature IP-based matches. Decide whether the design prioritizes domains or IPs first, then choose the strategy; do not treat multiple strategy names as performance switches to toggle repeatedly.

FakeDNS is useful in some TUN interception scenarios. It returns reserved addresses to endpoints and stores a mapping between each virtual address and its domain, allowing later connections to recover the original domain. This requires both DNS queries and connections to pass through the same mapping state. Enable it cautiously when some LAN devices bypass the bypass router, applications need to reach real IP addresses directly, or the bypass router reboots frequently. For a standard gateway deployment, start with real DNS resolution, stabilize the basic path, and then evaluate virtual mapping.

Start traffic splitting with LAN exceptions

The first rule of a bypass router should be preserving LAN reachability. Private, loopback, link-local, multicast, and broadcast addresses must not be sent to a remote proxy. Printers, storage devices, TV casting, and router-management pages all depend on direct local access. If these exceptions are missed, the obvious symptoms are that internet access works while device discovery, file sharing, or management pages fail.

The second layer decides whether traffic goes direct or through a proxy based on its destination. Rule order matters: Xray routing normally applies the first match from top to bottom. Put specific rules first, broad rules later, and finish with an explicit fallback. An easy-to-follow three-part structure is: direct for LAN and reserved addresses; direct for domains and addresses known to require it; proxy everything else. When using geosite and geoip data, make sure the rule files are in a location the core can read, then revalidate the core rules after updates.

The third layer splits traffic by source device. The bypass router can decide whether to intercept based on source address—for example, send only a test computer and a TV through the transparent proxy while leaving other devices on the original gateway path. Source-based policies depend on stable addresses, so reserve leases in DHCP instead of relying on addresses assigned by chance. Roll out by group rather than taking over the entire LAN at once: add one test device, verify TCP, UDP, DNS, and LAN access, then expand gradually.

Port rules should only supplement the design. Common web ports do not cover every application, and modern apps may switch between TCP and UDP. Treating “proxy only these ports” as a complete split-routing plan often produces pages that load while media or calls fail. A more reliable combination evaluates the source device, destination domain, destination address, and protocol together, with a clear fallback for traffic that cannot be identified.

Prevent loops, outages, and performance bottlenecks

The main risk in transparent proxying is a traffic loop. Traffic Xray generates to connect to a proxy server must not be sent back into the Xray transparent inbound. Common approaches include bypassing traffic by process user, bypassing by packet mark, or adding the proxy server’s address to the direct set. The choice depends on the host firewall’s capabilities, but the result must be verifiable: logs should not show the same destination connection being established repeatedly, and the connection-tracking table should not grow rapidly.

The bypass router’s own system services also need explicit policies. Time synchronization, software updates, and upstream DNS queries originate locally, so decide separately whether each should use the proxy. The safest starting point is to keep the router’s own traffic direct and intercept only forwarded traffic. Once the rules are stable, add proxy paths for specific local services if needed. Transparently intercepting all locally generated traffic creates startup dependencies: services may wait on one another while the clock, DNS, or Xray is not ready.

MTU problems often appear as small pages loading while large files or specific sites stall. Transparent paths, tunnels, and upstream networks all add encapsulation overhead. If the handshake succeeds but transfers hang on larger packets, inspect the path MTU and TCP MSS before changing the node protocol. Adjust from the network interface and the actual path, and avoid shrinking the value repeatedly in multiple places.

Advertised port speed does not equal transparent-proxy throughput. Encryption, rule matching, connection tracking, the TUN stack, and log writes all consume resources. During testing, monitor per-core CPU usage, available memory, connection count, and temperature together. If one core is saturated for long periods, adding rules or concurrent connections will not increase speed. Low-power hardware is better served by concise rules, limited logging, and stable protocol parameters.

Bring the deployment online in a fixed order

Bypass-router deployment is best validated layer by layer, with each layer answering one question. Skip intermediate steps and every “cannot connect” report may involve the gateway, DNS, firewall, Xray, and remote node at once, causing troubleshooting costs to rise quickly.

1. Verify basic routing. Disable transparent rules, have the test endpoint use the bypass router as its gateway, and confirm access to the main router, LAN devices, and the internet.
2. Verify the core’s outbound. Use Xray’s explicit SOCKS or HTTP inbound for a single-device test, confirming that the proxy-node parameters match the server side.
3. Enable one transparent entry point. Intercept only the test endpoint first and confirm that packet counters correspond to Xray access logs.
4. Add LAN exceptions. Check that the router-management page, file sharing, device discovery, and other local services remain available.
5. Connect DNS. Confirm that the endpoint’s actual query address, the bypass router’s upstream query, and the connection’s outbound are consistent.
6. Test TCP and UDP. Verify web pages, downloads, media, and real-time connections separately instead of judging success from a single webpage.
7. Simulate a reboot. Restart the bypass router and check that its address, policy routes, firewall rules, and Xray service recover in the correct order.
8. Expand device coverage gradually. Add one group of fixed-address devices at a time, and keep one management device outside the bypass-router path as a recovery entry point.

Logs should also be read in layers. If Xray receives no connection, check the endpoint gateway, firewall hits, and policy routing first. If it receives a connection but creates no outbound, inspect routing tags and rule order. If the outbound is established but times out, check node parameters, remote reachability, and system time. If domains fail while direct IP access works, return to the DNS path. A fixed sequence is more effective than randomly changing protocols, security layers, and routing fields.

Choosing between a bypass-router core and a desktop client

The main value of running the core on a bypass router is centralized management. When multiple devices share nodes, DNS, and routing rules, only one gateway configuration needs maintenance. LAN devices that cannot easily set an explicit proxy can also use a consistent path through the default gateway. The trade-off is a wider failure radius: an issue with the bypass-router service, DNS, or forwarding rules may affect many devices at once. This is closer to operating network infrastructure than performing an ordinary client installation.

v2rayN is better suited to everyday use and node verification on a single Windows, macOS, or Linux desktop. Its graphical interface makes it easy to import subscriptions, switch servers, inspect logs, and adjust the system proxy. When each computer needs its own node selection or frequently moves between networks, a desktop client has clearer boundaries. On Android devices, choose v2rayNG or v2flyNG according to the core requirements and manage the connection locally.

The two approaches can coexist. The bypass router can handle fixed devices and baseline split routing, while the desktop keeps v2rayN for node testing or temporary policies. Avoid double interception: if v2rayN has the system proxy or TUN enabled while the default gateway also uses transparent proxying, the same connection may pass through two forwarding layers. When testing a node, temporarily bypass the computer from the router’s transparent rules or disable local interception so only one effective path remains.

If only one or two computers need a proxy, a desktop client is usually easier to maintain. If the home network has multiple fixed devices and you can already manage DHCP, static routes, the firewall, and DNS, consider moving a stable node to the bypass router. A successful deployment is not one where “all traffic goes through the proxy”; it is one where the path is explainable, the LAN remains reachable, DNS and split routing agree, and everything recovers automatically after a reboot.