Setting Up Xray/V2Ray on Routers and Bypass Routers: Architecture and Configuration

1. Choose an architecture: main router or bypass router

Xray and V2Ray are proxy kernels, not complete router operating systems. The host OS still handles forwarding, firewall rules, and service management. Firmware interfaces can generate configuration, but their options, rule files, and the installed kernel version must be compatible. A status of “running” in the UI alone isn't enough.

Choose a kernel that supports your node configuration. Xray and V2Fly's V2Ray differ in protocols, transports, and configuration fields. In particular, don't use a configuration that requires features such as REALITY with a kernel that doesn't support them. v2rayN is a desktop client; v2rayNG and v2flyNG are Android clients. They can help test a node, but they don't forward traffic on a router.

2. Plan your addresses: verify the gateway, DNS, and return path

These static IP addresses are examples, not universal defaults. Before deployment, check your actual subnet, DHCP pool, and existing devices to avoid conflicts. Assign the bypass router a fixed address outside the dynamic pool, or create a static lease for it on the main router.

With a single-interface bypass router on the same subnet, traffic to a LAN device may pass through the bypass router to the main router, then return directly to the client—creating an asymmetric path. Use firewall connection tracking to decide whether controlled source NAT is needed, or adjust the topology to keep paths symmetric. Also check whether ICMP redirects are causing clients to bypass the bypass router. Enabling NAT is not a universal fix.

3. Transparent proxying: a listening kernel doesn't mean traffic is being intercepted

With an explicit proxy, an application must connect to an HTTP or SOCKS proxy port. Transparent proxying intercepts matching traffic at the gateway and passes it to the kernel while preserving the destination address for routing decisions. Configuring a SOCKS inbound alone won't route ordinary app traffic through it—even if the device's gateway points to the bypass router.

1. Verify the outbound connection first: Test the same node in a client, then check the router's system time, certificate validation, server hostname resolution, and connection logs. A working desktop setup doesn't guarantee the router has the same network conditions.
2. Then verify the inbound: Check the listening address, protocol, and port. Make sure the firewall sends traffic to the correct transparent inbound, not an explicit proxy port.
3. Add interception last: Start by limiting it to the test device's source address, then expand the destination range gradually. TPROXY requires matching policy routing; firewall rules without the routing setup can still drop traffic.
4. Prevent proxy loops: The kernel's own outbound connections must not be intercepted again. Common approaches exclude traffic by mark, process identity, or destination address. Use the method that matches your setup.

Account for LAN management addresses, broadcast and multicast traffic, and other networks that should connect directly at both the firewall interception layer and the kernel routing layer. Exclusions for node server IPs must also account for changes in DNS results. On systems using nftables, don't run legacy iptables scripts alongside the existing rules. Duplicate interception or incorrect rule ordering can make failures difficult to reproduce.

4. DNS interception: connect the ports, routing rules, and bootstrap resolution

DNS interception involves three stages: client queries, local forwarding on the router, and upstream resolution. Pointing a client to the bypass router only covers requests that honor that setting. Apps with built-in encrypted DNS won't automatically use your resolver just because you intercept regular port 53 traffic; check browser and app settings separately.

• Listening ports: Standard DNS uses UDP and TCP port 53. If the system resolver already listens on port 53, another resolver can listen on port 5353 locally and receive forwarded queries from it. These ports are examples; use the values in your actual listener configuration.
• Domain-based routing: Choose appropriate upstreams for domains that should connect directly or through the proxy, and confirm that upstream traffic uses the intended outbound. Changing the upstream to a public resolver alone doesn't prove queries are going through the proxy.
• Bootstrap resolution: If the node server address is a hostname, a working DNS path must be available first. Don't rely on a proxy connection that hasn't been established yet to resolve the hostname needed to establish that connection.
• Avoid DNS loops: If local DNS forwards queries to the kernel, make sure the kernel doesn't send the same query back to the original local entry point. Check the address, port, and outbound tag at every step.
• Domain and IP matching: domainStrategy controls whether and when hostnames are resolved for routing decisions. It does not mean that all system DNS requests are intercepted. Verify the supported values and behavior for your kernel version.

If you use rule assets such as geosite or geoip, make sure the files match the paths referenced in your configuration and that updates succeed. Sniffing may help recover domain information for some connections, but it won't identify all traffic or replace proper DNS path design. When testing routing, check both domain match logs and the actual outbound tag.

# Run on a test device with dig installed; the domain is for connectivity testing only
dig @192.168.10.2 example.com A
dig @192.168.10.2 example.com AAAA
dig @192.168.10.2 example.com A +tcp

These three queries check IPv4 records, IPv6 records, and DNS over TCP, respectively. Getting an answer only confirms that the resolver responded. To find out which upstream handled the query and which outbound it used, check router logs or capture traffic with a restricted filter. After changing DNS settings, clear the client and router caches so old results don't mask the change.

5. Deployment order: test one device before changing DHCP

Router configuration isn't a matter of copying a desktop export file as-is. Listener addresses, file paths, user permissions, asset locations, and transparent inbounds will differ. A subscription URL isn't necessarily a kernel-ready configuration; whether it can be imported and how outbounds are generated depends on the management software.

1. Record the baseline: Back up network, DHCP, and firewall settings, and note the main router's management address. Confirm that the test device can resolve domains, open websites, and access LAN devices using its original gateway.
2. Check the runtime environment: Choose a kernel binary that matches the processor architecture, and check the system clock, writable storage, and service permissions. Rule assets and connection counts affect memory use; don't estimate runtime requirements from the package size.
3. Start the kernel independently: Check configuration syntax and startup logs, then test the node connection. Configuration validation commands vary between releases, so check the help provided with your binary first.
4. Limit the test scope: Set the gateway and DNS for 192.168.10.100 only, and intercept traffic from that source address alone. Test direct-access sites, proxied sites, and LAN services separately.
5. Plan for failures: Decide whether traffic should be blocked or selected connections allowed directly when the node is unavailable. Test DNS failures, kernel shutdowns, and device reboots—not just normal operation.
6. Expand to more devices last: Once the setup is stable, update DHCP. In OpenWrt, check the lease settings in LuCI under “Network” → “Interfaces” → “LAN” → “DHCP Server.” Field names vary by version. Existing clients must renew their leases to pick up the new settings.

6. Verify and troubleshoot: trace the path, not just the public IP

A changed public IP proves only that one request took a particular path. It doesn't prove that DNS, UDP, IPv6, or every app is routed correctly. Record results in both normal and failure conditions, and check the client, gateway, DNS, and kernel outbound separately.

# Run on a Linux router; requires the appropriate permissions to inspect
ip -4 route
ip -6 route
ip rule show
ss -lntup

These commands show IPv4 and IPv6 routes, policy routing rules, and listening ports. Minimal systems may require installing the relevant tools. Compare the output with your address plan; seeing a port in the output alone doesn't mean the setup is complete. Remove subscription URLs, credentials, and device identifiers before sharing logs.