Run Xray on a Router or Bypass Router: Hardware, Transparent Proxying & Traffic Routing

1. Choose Hardware: Check the Architecture and Available Memory First

Xray is a core engine for handling connections, protocols, and routing—not router firmware, and it doesn't include a general-purpose router management interface. A device running Linux can't necessarily run any Xray binary: the CPU architecture, instruction set, system environment, and writable storage must all match. Before downloading, check the architecture with uname -m, then use free -m and df -h to check available memory and storage.

These are deployment budget recommendations, not minimum operating requirements or throughput guarantees. Resource needs vary with concurrent connections, rule-set size, encryption overhead, and log volume. The wireless speed printed on a device's packaging is not a measure of proxy throughput.

2. Main Router vs. Bypass Router: Map the Traffic Path First

The main router typically handles the WAN connection, NAT, DHCP, and the default gateway. A bypass router is an additional forwarding device on the local network; plugging it in doesn't automatically route traffic from every device through it. Devices must send the relevant traffic to the bypass router, or the main router must forward it there using policy-based routing, before Xray can process the connections.

• Running Xray on the main router: Device traffic already passes through the router, so interception is centralized. However, a mistake in the core, firewall, or routing configuration can affect the entire network.
• Bypass router on the same subnet: For example, the main router is 192.168.10.1, the bypass router is 192.168.10.2, and the test device is 192.168.10.100, all with subnet mask 255.255.255.0. Set the test device's default gateway to the bypass router; keep the bypass router's upstream gateway set to the main router.
• Separate downstream subnet: Use two interfaces or VLANs on the bypass router to place test devices on a separate subnet. The path is usually easier to understand, but you'll need to configure forwarding, firewall rules, and either a return route or source NAT.

On a same-subnet setup, also consider whether return traffic bypasses the bypass router and whether ICMP redirects change the device's route. Whether to use source NAT depends on the topology and connection-tracking requirements; “a bypass router must use NAT” is not a universal rule. Start with one device and use ip route or your system's route viewer to confirm its default gateway.

3. Transparent Proxying: Traffic Interception Is Not a Proxy Protocol

Transparent proxying describes how traffic is intercepted; it isn't a replacement for protocols such as VLESS or VMess. Devices don't need to enter an application proxy address: the gateway redirects traffic or uses policy-based routing to send it to the core. Support for TCP, UDP, and IPv6 depends on the Linux network configuration, inbound settings, proxy outbound, and server working together.

A common Linux approach for transparent proxying with Xray uses a dokodemo-door inbound with followRedirect to read the original destination. TPROXY also requires the corresponding streamSettings.sockopt.tproxy setting. Adding these JSON fields alone won't create firewall rules or policy routes, or enable system forwarding.

OpenWrt 22.03 and later generally use firewall4 and nftables. Older iptables guides written for firewall3 can't be applied as-is; check the firmware, modules, and compatibility layer in use. The TUN toggle in desktop v2rayN is not a single field you can copy directly into a router's Xray configuration. See the TUN configuration guide for details.

4. Configuration and Services: Test an Explicit Proxy First

The startup command determines which configuration file is used, not its filename. /etc/xray/config.json is a common convention, but a package or management interface may use a different directory or generate runtime files under /var. Changes to generated files are often overwritten the next time settings are saved or the system restarts, so first find out where the configuration comes from.

1. Record Network Settings

   In OpenWrt LuCI, go to Network → Interfaces and note the LAN address, upstream gateway, and interface names. Export a configuration backup under System → Backup / Flash Firmware. Don't change the DHCP settings distributed to the whole network yet.

2. Check the Startup Command

   Run xray version to verify that the core runs. On a system using systemd, check ExecStart in systemctl cat xray. On OpenWrt, inspect /etc/init.d/xray and the configuration it reads to confirm the actual file path.

3. Validate the Configuration

   If the configuration is at this common path, run xray run -test -config /etc/xray/config.json. Fix syntax errors, unknown fields, and rule-file read errors before starting the service. A successful configuration test doesn't mean the remote node is reachable.

4. Test Locally

   Start with the SOCKS inbound listening only on 127.0.0.1:10808. Test the connection with curl --proxy socks5h://127.0.0.1:10808 https://example.com/ and check the logs to see which outbound was selected. A page loading successfully alone doesn't prove that traffic used the proxy.

5. Intercept Traffic for One Device

   Once the explicit proxy and the actual node both work, enable transparent rules for one test device. Test DNS, TCP, UDP, and IPv6 separately, confirm the management interface remains accessible, and only then expand the source address range.

The example below is a direct-connection baseline to help explain the configuration structure, not a ready-to-use configuration for a working proxy node. It has no remote server settings or transparent inbound; every connection received by SOCKS goes direct through freedom. If the service already has a working configuration, don't overwrite it.

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    }
  ]
}

A subscription URL is not an Xray startup parameter. Client subscriptions may contain Base64-encoded share links or use a format specific to a management tool. Only JSON that follows Xray's configuration structure can be loaded as a configuration file. If you use a subscription manager, check the outbounds, tags, and rule files it generates—manual edits may be overwritten by the next update.

5. DNS and Traffic Routing: Check Both Paths

Reliable traffic routing requires knowing both where a connection is going and how its domain name is resolved. Xray evaluates routing.rules from top to bottom, and each rule's outboundTag must point to an existing outbound tag. If no rule matches, the first outbound is typically used. Write down the expected results for domain rules, IP rules, and the default outbound before translating them into configuration.

These ports serve different purposes and aren't interchangeable. 12345 is an illustrative value for planning, not a system default that takes effect automatically. The firewall's redirect target must match the port the core listens on. Don't expose an unauthenticated SOCKS port to the public internet; if local network access is needed later, restrict the listening address and firewall sources.

• Local network and management addresses: Define the direct-connection range first to prevent traffic to the router's admin page, network storage, or printers from being sent through a remote outbound.
• Domain rules: Transparent connections may include only the destination IP. Sniffing can help identify domains for some protocols, but it can't recover every domain or decrypt traffic.
• Resolution strategy: routing.domainStrategy controls how domains are resolved for routing matches; it isn't a global DNS server switch. Built-in DNS, outbound resolution, and device DNS are separate stages.
• DNS service path: A device may query the router's dnsmasq first, which then forwards requests to another resolver. Adding dns to Xray alone won't automatically send device DNS requests to it.
• IPv6 path: If only IPv4 transparent rules are configured, devices may still reach the internet through the main router's IPv6 default route. Test AAAA resolution, the IPv6 gateway, and interception coverage separately.

For a VLESS node, the remote address, port, user ID, transport, and security settings must match the server; running it on a router doesn't change those requirements. VMess and VLESS are proxy protocols; TCP and WebSocket are transport-related options. The protocol name alone doesn't determine device throughput. See the routing configuration reference and glossary for field definitions.

6. Troubleshooting: Narrow Down the Cause by Symptom

Keep one management device off the bypass router while troubleshooting. Compare results using the original gateway and the bypass-router gateway, then check DNS, core logs, and firewall counters. Don't change the MTU, protocol, DNS, and routing rules all at once, or it will be hard to tell which change made a difference.

7. Deployment Checklist: Expand from One Device to the Whole Network

For devices across your home network to work without separate clients, their traffic must actually pass through the configured gateway, with consistent DNS, IPv4, and IPv6 policies. Devices using a separate network, manual routes, or custom encrypted DNS may follow a different path; verify each device category separately.

• Basic connectivity: Test local network management pages, commonly used direct-access sites, and destinations that should use the proxy. Confirm the outbound direction in the logs.
• Protocol coverage: Test TCP, the UDP applications you actually use, and IPv6 separately instead of relying on a single browser speed test.
• Performance checks: Compare direct and proxied connections to the same destinations at the same time. Record CPU usage, available memory, and connection counts; don't treat a one-time peak as sustained throughput.
• Recovery after reboot: Restart the bypass router and check the service, DNS, policy routing, and firewall rules again. Confirm that nothing depends on temporary commands.
• Rollback plan: Stop the Xray service and confirm that the management device can still reach the main router. Make sure you know how other devices can restore their original gateway and DNS settings.

If you haven't confirmed that the node works yet, test it first on desktop v2rayN or Android v2rayNG to separate node issues from gateway issues. v2rayNG uses the Xray core, while v2flyNG uses the V2Fly core; check their capabilities and configuration formats separately. After the single-device test succeeds, transfer the relevant connection settings and routing intent to the router environment instead of copying the entire client data directory.