Bypass router setup with the V2Ray core: running Xray directly on a router or Linux mini PC

1. How traffic flows through a primary router and bypass router

The primary router provides internet access and typically handles the WAN connection, address assignment, and NAT. A bypass router adds a forwarding device to the existing LAN: selected devices send traffic to it first, and it decides whether to route traffic directly or through a proxy. Simply connecting a bypass router to the network does not make it handle other devices' traffic. You must direct traffic explicitly through device gateway settings, DHCP options, or policy-based routing on the primary router.

In this example, the primary router is 192.168.10.1/24, the Linux mini PC is 192.168.10.2/24, and the test computer is 192.168.10.100/24. These are private addresses for illustration. Adjust them to match your network, and reserve the mini PC's address on the primary router to avoid conflicts with DHCP assignments.

2. Check your environment before running Xray

V2Ray is often used as a catch-all term for this type of proxy software, but Xray and V2Fly are separate core projects with different capabilities. This guide uses Xray. v2rayN is a desktop client, v2rayNG uses the Xray core, and v2flyNG uses the V2Fly core. Their subscription management and interface settings do not configure transparent proxying on Linux.

On a router, first check the CPU architecture and system C library requirements. On a Linux mini PC, check the service manager, firewall framework, and binary paths. An executable built for one architecture cannot simply be copied to another. Avoid layering a second set of rules on a device that already uses its own management scripts.

# Check the architecture, kernel, and current network status
uname -m
uname -r
ip -br address
ip route
timedatectl status

# The commands below assume Xray is installed at this path
/usr/local/bin/xray version
/usr/local/bin/xray run -test -config /etc/xray/config.json

# Check the ports used in this guide
ss -lntup | grep -E ':(53|10808|12345)\b'

These numbers are configuration choices, not performance test results. If a port is already in use, update both the core configuration and firewall rules. Keep the system clock accurate as well: TLS handshakes depend on certificate validity periods, so an incorrect clock can cause connection failures that look like routing problems.

3. Connect a test device in five steps

Work from the application layer down to the network layer. First prove that the core can connect outbound, then verify that the device's traffic reaches the bypass router, and only then configure the transparent entry point. Changing the gateway, DNS, and firewall all at once makes it difficult to identify which layer failed.

1. Record the original settings

   Record the test computer's current IP address, gateway, and DNS settings. Save the mini PC's ip route output and back up /etc/xray/config.json. If you're administering it remotely, keep a local management path available.

2. Verify outbound connectivity

   In /etc/xray/config.json, configure a SOCKS listener on 127.0.0.1:10808 and a verified proxy outbound. Test the configuration first, then make a request to the destination from the mini PC.

3. Set the gateway

   On the Windows test computer, open Settings → Network & Internet → select the active network adapter → IP assignment → Edit, then choose Manual IPv4. For this example, use 192.168.10.100 as the IP address, 255.255.255.0 as the subnet mask, and 192.168.10.2 as the gateway. The field locations may vary slightly by Windows version.

4. Add TCP interception

   Add a transparent entry point on port 12345. Configure the firewall to match only traffic from the test computer and the actual LAN interface. Start with TCP, keep destinations on the local network direct, and don't add UDP or intercept traffic from the mini PC itself yet.

5. Configure DNS

   Once the mini PC's DNS service can answer queries, set the test computer's DNS to 192.168.10.2. Verify UDP 53, TCP 53, and name resolution, then reconnect the network adapter and check that the settings took effect.

The mini PC's default route must point to the primary router, not to itself. With a single network interface on the same subnet, directly forwarded traffic may go from the primary router straight back to the device, creating an asymmetric path. Decide whether to use restricted SNAT based on return-path and stateful firewall requirements. SNAT hides the original device's address; it is not a universal fix to enable casually.

4. How transparent proxying and the firewall work together

Transparent proxying has two parts: the firewall sends matching packets to a local entry point, and Xray reads the original destination and selects an outbound. Listening on a port alone does not intercept device traffic. A redirect without a corresponding listener does not provide a working proxy either.

Here is a minimal configuration for validating direct connections. It provides a local SOCKS listener and a TCP transparent entry point, but its only outbound is freedom, so all requests still connect directly. It includes no proxy nodes, DNS service, or firewall rules. Do not mistake it for a complete proxy setup.

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": false
      }
    },
    {
      "tag": "lan-tcp",
      "listen": "0.0.0.0",
      "port": 12345,
      "protocol": "dokodemo-door",
      "settings": {
        "network": "tcp",
        "followRedirect": true
      }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    }
  ]
}

• Isolate entry points: Port 12345 listens on all IPv4 interfaces only to receive redirected LAN traffic. The firewall must restrict trusted sources and block WAN access. Port 10808 remains available only locally.
• Exclude destination addresses: Do not redirect local management addresses, LAN subnets, loopback, link-local, multicast, or broadcast destinations through the standard proxy. Explicitly exclude any other internal subnets in use.
• Exclude proxy servers: Keep proxy outbound server addresses reachable. If you later intercept traffic from the device itself, also exclude Xray's outbound traffic by process identity or packet mark to prevent proxy loops.
• Limit interception: Initially match only traffic arriving on the LAN interface from 192.168.10.100. Do not start by processing all sources, all protocols, or the entire OUTPUT chain.

TPROXY is not simply REDIRECT with a different name. It generally requires packet marks to select a dedicated routing table, a local-delivery route in that table, and the corresponding transparent socket option on the core listener. Make sure the mark value, routing table ID, and firewall priority do not conflict with existing system rules. This guide does not provide a network-wide ruleset detached from the device's environment.

5. Validate DNS interception separately

The gateway and DNS are separate settings. Changing a device's gateway to the bypass router does not guarantee that it will use that router for DNS. The device may continue querying the primary router or use encrypted DNS in its browser. Redirecting traditional port 53 traffic does not automatically intercept DNS over HTTPS.

First set up a resolver on the mini PC that serves only trusted LAN clients, then configure its upstream path explicitly. Xray's dns field handles resolution inside the core; it does not mean a general-purpose DNS service is listening on the LAN address. Validate core resolution, device queries, and routing rules separately.

Traffic reaching a transparent entry point often contains only the destination IP. If you want to route by domain, consider how domain information will be obtained. Sniffing can extract information from some HTTP or TLS traffic, but it cannot identify every connection. Enabling sniffing also does not standardize browser DNS behavior. Design IP- and domain-based rules around the capabilities of the actual entry point.

6. Forwarding, return paths, and startup order

Packets on the bypass router that aren't captured by the transparent entry point still need normal forwarding. Linux IPv4 forwarding, FORWARD-chain allow rules, and the upstream return path must all be in place. Enabling forwarding does not allow every packet through, and it is not a reason to set the firewall to allow everything.

# Check whether IPv4 forwarding is enabled
sysctl net.ipv4.ip_forward

# Check reverse path filtering; decide whether to adjust it based on the topology
sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.default.rp_filter

# Inspect firewall rules and policy routing; do not flush rules during a remote session
sudo nft list ruleset
ip rule show
ip route show table all

# Only for systemd environments with xray.service already created
systemctl status xray --no-pager
journalctl -u xray -n 80 --no-pager

Strict reverse path filtering can drop packets with policy routing or asymmetric return paths, but don't disable it globally as soon as the network goes down. First confirm which interface receives the packet and where the reverse route points, then decide whether an appropriate setting is needed on the relevant interface. Use nftables or iptables in keeping with the system's existing management approach to avoid scripts overwriting each other's rules.

• Startup dependencies: The core needs network access. If the DNS upstream uses a proxy outbound, make sure resolving the proxy server's hostname does not depend on the proxy that has yet to start.
• Persistence: Forwarding settings and firewall rules applied interactively may disappear after a reboot. Save them in system configuration files and through the existing firewall service rather than relying on terminal history.
• Failure behavior: If the core stops while redirection rules remain active, traffic may be sent to a port with no listener. Decide whether a failure should stop connectivity or remove interception and restore direct access.
• Resource monitoring: Monitor CPU, memory, connection counts, and log growth, not just the time it takes to open a page once. Router storage is limited, so avoid keeping detailed access logs for long periods.

7. Common issues and recovery steps

When troubleshooting, use one device, one destination, and one protocol at a time. First check whether explicit SOCKS works, then test transparent TCP, and finally check DNS and UDP. Don't assume every timeout is a node issue: traffic may never reach Xray, or it may leave the core successfully and then be dropped by the firewall on the return path.

To inspect traffic, run tcpdump -ni eth0 host 192.168.10.100 on the mini PC. Replace eth0 with the actual interface name. Packet captures may contain domain names and communication metadata, so keep the capture narrow, run it briefly, and redact sensitive information before sharing. Combining rule counters with listener logs makes it easier to find the break in the path than relying on browser errors alone.

A bypass router is useful for centrally handling traffic from selected devices, not for reducing network configuration work. A stable setup must document the entry point, outbound path, DNS, return path, and reboot behavior. If you only need a proxy on one computer or Android device, validating the node and protocol in a client is usually easier to troubleshoot than intercepting network traffic. For basic terms, see the glossary. For connection issues, see connection troubleshooting in Advanced Usage.