Running Xray on a Router or Secondary Router: Deployment Options and Hardware Guide

Routers run the core, not a desktop client

v2rayN is a desktop client for managing configurations and connections. v2rayNG is an Android client that uses the Xray core, while v2flyNG uses the V2Fly core. These clients provide subscription management, configuration generation, and a user interface. Routers typically run the Xray or V2Fly command-line program directly, with startup handled by the firmware’s service manager. A desktop client’s “System Proxy” toggle does not enable proxying for every device on a router.

The core accepts inbound connections, applies routing rules, and establishes outbound connections. System forwarding, firewall rules, and policy routing determine which device traffic reaches the core. Starting the process alone—even if the logs show that it is listening—does not mean TVs, computers, or other devices on the same subnet are using the proxy.

• Explicit proxy settings: Enter the router’s address and SOCKS or HTTP port in a proxy-enabled app. Start with one app to keep the scope of changes small.
• Transparent proxying: Redirect selected traffic to the core using mechanisms such as redirection or TPROXY. This requires compatible system modules, firewall rules, and inbound settings.
• Per-device routing: Choose which devices or subnets to intercept, then let the core’s domain and IP rules determine the outbound route.

Primary router or secondary router: assess the impact of failure first

The primary router usually handles the internet connection, address assignment, default gateway, and firewall. Centralizing everything can make the traffic path more direct, but a core update, forwarding-rule change, or memory shortage could affect the entire LAN. A secondary router puts proxy functions on a separate device, preserving the primary router’s basic internet access. The tradeoff is that return traffic, address assignment, and DNS need more deliberate planning.

A secondary router with one network port can work, but you must account for return traffic: direct traffic may return to the device through the primary router, bypassing the secondary router. Decide whether source NAT is needed based on connection tracking, firewall rules, and return routes; don’t copy a generic rule without checking. Multiple network ports do not automatically solve configuration issues. Make sure you can explain the ingress, egress, and return path at every hop.

Choosing hardware: match the architecture, leave enough memory, and account for storage writes

Check the device’s system details before choosing a binary. A processor’s product name alone does not establish compatibility: check the ARM bitness and instruction set, or the MIPS endianness and build requirements. A 64-bit-capable processor does not mean the firmware has a 64-bit userland. Dynamically linked programs also depend on the system libraries and loader. If you see “cannot execute,” check compatibility before suspecting the node or subscription.

# Check system details and resources in the device terminal; command options vary by firmware
uname -m
uname -a
free -m
df -h
ip route show
ip -6 route show

When buying a device, use 512 MB or more as an initial screening point for a lightweight gateway, and reserve 1 GB or more for setups running several services. These are resource-planning guidelines, not minimum requirements or performance guarantees for the core. Existing devices with less memory may still work with a lean configuration, but reduce unnecessary rules and background services, and watch for processes being killed due to memory pressure. Swap space is not a substitute for insufficient memory.

Ports, DNS, and transparent proxying: test each part of the path separately

A working explicit proxy is a useful starting point, but it does not prove that transparent proxying is configured correctly. Start with a SOCKS inbound bound for testing only, verify outbound traffic with one app, then add gateway forwarding. The three ports below are examples of different roles, not universal defaults for any client or firmware. Use the configuration and system output to confirm the actual listening ports.

1. Check the listening address: If the service listens only on 127.0.0.1, other devices on the LAN cannot connect to it directly. If you need to offer a LAN proxy, bind to an appropriate address and restrict access with the firewall. Never expose proxy ports to the internet.
2. Exclude the proxy’s own traffic: Make sure interception rules do not recapture outbound connections opened by the core. Depending on the setup, exclude traffic by process, user, mark, or destination address, and ensure the server address remains reachable.
3. Handle TCP and UDP separately: A redirection method that supports TCP does not necessarily handle UDP. TPROXY also requires policy routing and the appropriate modules; adding a port-forwarding rule alone is not enough.
4. Plan the DNS bootstrap path: Decide how the server hostname is resolved before deciding where queries for other domains should go. If establishing the proxy requires resolving a hostname, but DNS can only work through that proxy, startup will get stuck in a dependency loop.
5. Test IPv6 separately: If you configure rules only for IPv4, IPv6 connections may take a different path. Decide whether to route IPv6 traffic and check the routes and DNS information advertised to client devices.

Migrate the connection settings; rebuild the router’s local configuration

A working node in a desktop client can be a reference for migration, but don’t copy the entire configuration to the router. A runtime configuration generated by v2rayN may contain local ports, file paths, or client-management fields. Subscription data may not be a core-ready JSON configuration either. Separate server connection parameters from local runtime settings, then rebuild the configuration to match the target core’s specification.

1. Record the connection details: Address, port, protocol, identity parameters, transport, and security layer. Check fields such as TLS serverName, WebSocket path and Host, and the REALITY server public key and shortId against your setup. These fields are not interchangeable.
2. Check the target core: Confirm that it supports the protocol, transport, and security-layer combination. Importing a subscription into one client only proves that client can handle it; it does not mean another core accepts the same configuration.
3. Rebuild the local configuration: Set the listening address, inbound ports, routing rules, and DNS. Update rule-file references to valid paths on the device. Check that the service user has permission to read the files and perform the required operations.
4. Validate before enabling: Use the core’s configuration test command to check fields and referenced files, then start it in the foreground and review the logs. A successful test only confirms that the configuration loads; you still need to test a real connection.
5. Add service management last: Let the firmware’s native service manager start and restart the core. Don’t configure multiple startup methods. Record the backup location, recovery steps, and how to stop the service.

# Assuming the executable is named xray and the configuration is stored at this path
# Check the help output to confirm which command options this build supports
xray help run
xray run -test -config /etc/xray/config.json

# After validating the configuration, start in the foreground and review the logs
xray run -config /etc/xray/config.json

When using V2Fly, check the help output for that specific build. Don’t assume Xray commands or fields are universal. Automatic subscription updates are not a built-in feature that comes with starting the core; they require a controlled workflow to fetch, convert, validate, and replace configurations. If an update fails, keep the last working configuration rather than overwriting it with an empty result.

Common issues: find the broken link before changing the configuration

Change one variable at a time. First confirm that the device itself can resolve names and make outbound connections. Then test the core connection, and finally check forwarding from the client device to the gateway. If you change DNS, routing rules, and protocols all at once, you’ll have a hard time finding the cause—even if service comes back—and won’t know whether the setup will survive a reboot.