Run Xray on a Router or Secondary Gateway: Deployment Options and Hardware Requirements

Running Xray directly: the core, management interface, and traffic entry point

Xray is a core that handles proxy connections—not router firmware or a desktop app with full subscription management. On a desktop, v2rayN manages configurations and launches the core. On a router, firmware services or an administrator must handle configuration generation, process supervision, and traffic forwarding. Copying an executable to the device won't create a management web interface.

Also distinguish between a device using a proxy itself and other devices routing traffic through it. The first requires only an app configured to connect to a SOCKS or HTTP inbound. The second also involves IP forwarding, firewall rules, policy routing, and DNS. A subscription URL is not native Xray JSON configuration and can't be loaded directly by the core.

• Explicit proxy: Applications connect directly to a SOCKS or HTTP inbound. Useful for testing nodes, certificates, and remote connectivity without changing the whole LAN.
• Transparent proxying: The gateway uses firewall rules and policy routing to send selected traffic to the core. Check TCP, UDP, and IPv6 separately; a working webpage in a browser isn't enough.
• Configuration management: Converts node settings into a core configuration, then validates, starts, and reloads the service. The management component must support fields compatible with the installed core version.

Main router or secondary gateway: start with the impact of a failure

The main router typically handles the internet connection, DHCP, NAT, and default gateway. Running Xray there provides a direct traffic path, but a single faulty firewall reload could affect every device. A secondary gateway moves the proxy service to another machine, making it easier to restart or roll back independently. Simply plugging it into the same switch, however, won't route traffic through it automatically.

These addresses are examples, not values to copy blindly. Choose a secondary gateway address outside the DHCP pool and make sure no other device is using it. A single-port device can act as a secondary gateway, but test the return path, forwarding rules, and main router behavior together.

Main router LAN: 192.168.10.1/24
Secondary gateway LAN: 192.168.10.2/24
Secondary gateway default gateway: 192.168.10.1
Test computer: 192.168.10.50/24
Test computer default gateway: 192.168.10.2

Outbound path: test computer → secondary gateway → main router → internet
Other devices: keep 192.168.10.1 as the default gateway

On a secondary gateway in the same subnet, the main router may send replies directly back to the test computer. Whether to use source NAT depends on connection tracking and the actual topology; don't copy a global NAT rule blindly. During testing, also check whether ICMP redirects change the computer's subsequent path, which can make traffic bypass the secondary gateway after initially working.

Hardware requirements: architecture, available memory, and persistent storage

Before downloading, confirm the CPU architecture, bitness, and system ABI. “ARM” alone isn't enough to choose a package; check the specific architecture and instruction set. For MIPS devices, verify endianness and build requirements in particular. A device that can boot the firmware may still be incompatible with the Xray build's kernel or runtime requirements.

The memory and storage figures above are practical starting points for maintainability, not official minimums or throughput guarantees. Rule data, concurrent connections, logs, and firmware services all use resources. For an existing low-memory device, check available memory and peak usage. When buying new hardware, don't choose based only on whether the binary fits.

Don't judge performance by the network port's rated speed alone. Proxy encryption and protocol handling mainly use CPU, so standard NAT throughput isn't a reliable measure of Xray throughput. During sustained tests, monitor CPU usage, temperature, and latency. Hardware flow offloading that normally works well can also bypass transparent proxy rules; temporarily disable the relevant acceleration and compare results when troubleshooting.

Deployment sequence: test one connection before switching a test device's gateway

The steps below use an OpenWrt network managed independently from Xray, which runs as a standalone service. LuCI menu names vary slightly by version and theme. Native Xray doesn't provide a LuCI menu, so check the configuration and start the core from a terminal. Don't install multiple components that modify the firewall just to look for a setting that isn't there.

1. Back up the network configuration

   In LuCI, go to “System” → “Backup / Flash Firmware” and create a configuration backup. Note the main router's management address, LAN address, and DHCP range. Keep a computer available that can access the main router directly.

2. Set a static address

   On the secondary gateway, go to “Network” → “Interfaces” → “LAN” → “Edit” → “General Settings” and set a static address, such as 192.168.10.2. If only one device will provide DHCP, go to “DHCP Server” → “General Setup” on the same page and check “Ignore interface” so both devices don't assign addresses.

3. Check the configuration

   After confirming the core is executable, validate the configuration file first. Enter the remote address, port, authentication, and TLS settings provided by your service. A successful validation means the configuration can be loaded; it doesn't confirm that the remote server is reachable.

4. Test the proxy

   Start with a SOCKS inbound listening on 127.0.0.1:10808 and test it on the router itself. To test directly from a computer, bind to a specific LAN address and allow access only from the test computer. Never expose the proxy port to the WAN.

5. Switch one device's gateway

   Once the proxy works, configure the firmware's transparent proxy entry point, forwarding, and policy routing. In the test computer's IPv4 network settings, set the default gateway to 192.168.10.2. Set DNS separately; don't change the DHCP settings for the whole network yet.

This example assumes the executable is installed at /usr/bin/xray and the configuration is at /etc/xray/config.json. If you installed a firmware package, use its actual file paths. Some minimal firmware builds don't include curl, so check that it's available first.

/usr/bin/xray version
/usr/bin/xray run -test -config /etc/xray/config.json

curl --proxy socks5h://127.0.0.1:10808 \
  --connect-timeout 10 --max-time 20 \
  -I https://example.com/

socks5h sends the destination hostname to the proxy for resolution, helping separate local DNS interference from proxy connection issues. This test covers only this explicit proxy connection. It doesn't show that transparent proxying handles other apps, or that UDP and IPv6 work correctly.

Transparent proxying and DNS: four checks that are easy to miss

Changing the default gateway only sends IP packets to another machine. Firewall matching and policy routing determine whether traffic reaches Xray; DNS requests are handled according to the combined behavior of the client DNS settings, router forwarder, and core DNS rules. Test each layer separately.

• Prevent routing loops: Outbound connections from the core to remote servers must not be sent back to the proxy inbound. Depending on the forwarding setup, this may require process or routing marks, or excluding destination addresses.
• Keep LAN access working: The main router's management page, printers, and local subnets usually need direct access. Don't redirect every private address and then try to fix the results with scattered exceptions.
• Handle UDP separately: Successful TCP redirection doesn't mean UDP works. Transparent UDP forwarding usually requires the right TPROXY and policy-routing support. Check DNS on port 53 separately from other UDP applications.
• Check IPv6: Changing only the IPv4 gateway may leave clients using the main router's IPv6 default route, learned through router advertisements. Configure the corresponding IPv6 policies, or temporarily disable IPv6 in a controlled test to compare results.

If the test computer still uses 192.168.10.1 for DNS, the main router may continue resolving queries. Even after changing DNS to 192.168.10.2, confirm that the secondary gateway is listening for queries and forwarding them to the intended upstream. Browser-based encrypted DNS may bypass system DNS, so one test page can't confirm that DNS is routed correctly for the whole network.

Common issues and rollback: restore connectivity before troubleshooting rules

Keep at least four records when validating the setup: whether the explicit proxy works, whether transparent TCP works, the actual DNS path, and whether direct access is restored when the service stops. Before expanding the rollout, test sleep and wake, DHCP lease renewal, and router reboot on one device to confirm the configuration persists.

If only one or two devices need a proxy, using v2rayN on desktop or choosing v2rayNG or v2flyNG on Android based on core requirements is usually easier to troubleshoot. Consider a gateway deployment when you need to manage multiple devices centrally. For more on configuration fields, see the Protocol and Core Reference. Start by identifying where traffic enters the proxy rather than configuring the entire home network at once.