Run Xray on an OpenWrt Side Router: Transparent Proxy Setup and Configuration

Plan the side router's position and traffic flow

A side router is a network deployment role, not a proxy protocol. The main router handles the internet connection and DHCP, while the side router can serve as the gateway and DNS resolver for selected devices. Transparent proxy rules only work when traffic actually passes through the side router. Installing Xray on another device on the same LAN will not automatically intercept traffic from other clients.

This guide uses a single-interface side router on the same subnet: the main router is 192.168.10.1, OpenWrt is 192.168.10.2, and the test PC is 192.168.10.100. The side router's default route still points to the main router. First, manually set the test PC's IPv4 gateway and DNS to the side router; leave other devices on the existing network.

Single-interface forwarding also involves forwarding across the same interface, the return path, and ICMP redirects. The main router may send replies directly to the client, preventing the side router from seeing the full direct connection. Decide whether source NAT is needed by checking the return path and connection tracking; do not treat “enable NAT” as a mandatory step for every topology. During testing, also check whether the side router sends redirects that change the gateway choice for subsequent traffic.

Choose a core: verify node fields before setting up transparent proxying

v2rayN is a desktop client; Xray and V2Fly are proxy cores. OpenWrt can run a core directly as a process, with a service manager loading its JSON configuration—no desktop interface required. Subscription import, node switching, and transparent forwarding are separate capabilities. Installing the binary is only the start: you still need configuration generation, service startup, and firewall integration.

Before installation, check the CPU architecture, firmware package feeds, and available storage. OpenWrt 24.10.x uses firewall4 and nftables by default; commands written for older iptables versions cannot be mixed in as-is. TPROXY also requires the relevant kernel modules in the firmware. A successful package install or a running core does not mean packet interception is working.

ubus call system board
uname -m
xray version
nft list ruleset
ip rule show
ip route show table all

Record the actual core version, not just the package name. After an upgrade, test the configuration again—especially when nodes use REALITY, fingerprint, or specific transport fields. OpenWrt configuration paths depend on the package and init scripts; the examples below use /etc/xray/config.json.

How dokodemo-door, TPROXY, and policy routing fit together

dokodemo-door provides an inbound for receiving traffic. With followRedirect enabled, it can retrieve the original destination address through transparent proxying. It does not create nftables rules or set up policy routing for the system. Adding a port under inbounds alone will not send client traffic to it.

The Xray inbound snippet below listens on 12345 for TCP and UDP. It shows only the inbounds section; a working setup also needs valid outbounds, logging, and matching firewall rules. Listening on all IPv4 addresses supports local transparent delivery, so the firewall must restrict the source. Do not expose this port to the public internet.

{
  "inbounds": [
    {
      "tag": "transparent-in",
      "listen": "0.0.0.0",
      "port": 12345,
      "protocol": "dokodemo-door",
      "settings": {
        "network": "tcp,udp",
        "followRedirect": true
      },
      "streamSettings": {
        "sockopt": {
          "tproxy": "tproxy"
        }
      }
    }
  ]
}

0x1 and table 100 are examples only; check for conflicts with other policy routing rules before deployment. The proxy process's own connections need a separate, identifiable bypass condition—for example, set sockopt.mark on the outbound to a value different from the interception mark, then return early in the rules. Otherwise, connections to the proxy server may be intercepted again, creating a loop.

• Before interception, exclude the side router's own addresses, management subnets, broadcasts, multicast, and other destinations that should not be proxied.
• Handle proxy server addresses and proxy process traffic separately; include domain-based node address changes in your update strategy.
• PREROUTING mainly handles forwarded traffic. Traffic originating on the router involves OUTPUT, so the same TPROXY rule cannot simply be reused.
• REDIRECT is commonly used for TCP redirection. For UDP, changing only the inbound network while keeping a firewall rule that intercepts TCP only is not enough.

This guide does not provide a universal nftables script for every firmware. Add rules through a persistence mechanism supported by firewall4, and verify the chain hook, priority, and firewall zone permissions. A temporary command succeeding does not mean the rule will survive a firewall reload.

Validate routing and DNS routing separately

The firewall decides which packets enter the core; routing decides which outbound handles them. Neither replaces the other. Xray routing rules are evaluated in order: put clear exceptions such as direct LAN access first, then handle traffic that should be proxied. Unmatched traffic usually uses the first outbound, so review the order of outbounds as well.

This routing snippet assumes the existing configuration defines a direct outbound named direct and a valid node outbound named proxy. It sends other traffic from the transparent inbound to the proxy. This broad rule is useful for testing, but it is not a complete geolocation-based routing policy.

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": [
          "10.0.0.0/8",
          "172.16.0.0/12",
          "192.168.0.0/16",
          "127.0.0.0/8"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "inboundTag": ["transparent-in"],
        "outboundTag": "proxy"
      }
    ]
  }
}

IPIfNonMatch does not mean “resolve every domain before routing.” When the original destination is a domain and an existing rule matches, a DNS lookup for routing may not be triggered. If a transparent connection carries only a destination IP, domain rules will not get a domain automatically. Consider sniffing if needed, but it cannot identify every encrypted protocol and is no substitute for DNS planning.

• Client query path: The test PC should send queries to 192.168.10.2:53. dnsmasq then selects an upstream according to your plan. Avoid forwarding queries back and forth between upstreams, which can create a loop.
• Node hostname resolution: Node addresses must resolve before the proxy is up. Do not make the first lookup for a node depend entirely on a proxy connection that is not yet available.
• DNS and connection egress: Keep remote DNS resolution aligned with the eventual egress where possible, so DNS does not return an address that is unreachable through the chosen route.
• App-specific DNS: Encrypted DNS in a browser does not use regular port 53. Record its settings during testing, or you may mistakenly conclude that side router DNS is not working.
• IPv6 path: Check AAAA records, the IPv6 default route, and IPv6 interception together. Configuring IPv4 alone does not mean IPv6 traffic also goes through the proxy.

Deploy in five steps: start with one client, then expand

Keep a working management path before changing the traffic entry point. The menus below follow the common LuCI layout in OpenWrt 24.10.x; themes and translations may differ slightly. Back up the configuration before changing addresses, and note the main router's address so you can restore the test PC's original gateway.

1. Back up the network

   Go to “System” → “Backup / Flash Firmware” and create a configuration backup. Note the current LAN address, DHCP settings, and firewall zones. Do not replace the entire ruleset over a remote connection.

2. Set a fixed address for the side router

   Go to “Network” → “Interfaces” → “LAN” → “Edit” → “General Settings” and verify the static address 192.168.10.2, subnet mask 255.255.255.0, and IPv4 gateway 192.168.10.1. Under “DHCP Server” → “General Setup,” make sure the side router is not handing out duplicate addresses.

3. Verify the core

   Complete the outbound configuration using an existing working node, then run a configuration test. Confirm the service log looks normal and check that port 12345 is listening. Do not change the network-wide gateway or enable interception for all clients yet.

4. Intercept one client

   Set the test PC's gateway and DNS to 192.168.10.2, and limit the interception rule to source 192.168.10.100. Test TCP first, then UDP. Check nftables counters, inbound records, and outbound tags at each layer.

5. Make it persistent and retest

   Check the DNS forwarding target under “Network” → “DHCP and DNS” → “General Settings.” From the local console, reload the firewall and reboot the device; retest the rules, policy routing, and service startup. Expand the DHCP gateway settings only after all checks pass.

xray run -test -config /etc/xray/config.json
ss -lnptu
logread | grep -i xray
nft list ruleset
ip rule show
ip route show table 100
nslookup example.com 192.168.10.2

These commands are for checking status. If ss is not installed on your firmware, install the appropriate diagnostic tool or use an existing socket inspection command. A passing configuration test only means the core accepts the configuration; it does not prove the remote node is reachable. A successful DNS query only confirms that this query returned a result, not that web requests used the intended outbound.

Troubleshoot DNS works, sites won't load, and UDP failures

Troubleshoot in the order packets travel. First confirm the test PC's gateway, then check interception counters, core logs, and finally the remote connection. Avoid changing DNS, nodes, and firewall rules in the same test cycle; even if access starts working again, you will not know which change fixed it.

For a consistent performance check, run the same HTTPS request 10 times and record the number of successes, connection time, and CPU usage during downloads. Then compare single-connection and multi-connection results. This is a suggested measurement method, not a benchmark performed for this guide. A router's rated Ethernet speed does not indicate encrypted proxy throughput; CPU, cooling, MTU, and the node connection can all be bottlenecks.

How to split roles between a side router and desktop clients

A side router works well for consistent home network policies; desktop clients are better for connecting independently when devices leave the LAN. The same subscription can be used on different devices, but subscription text is not a configuration file that a core can run directly. The side router still needs generated node outbounds, routing rules, and an update mechanism. Make sure importing new nodes does not overwrite the transparent inbound or anti-loop settings.

A deployment is not complete just because “the process is still running.” The client must use the right gateway, interception rules must match, DNS routing must be clear, outbound selection must follow the rules, and the setup must still work after a reboot. Keep the original gateway and a configuration backup so devices can return to the main router during side router maintenance, without letting a node update disrupt the entire LAN.