A desktop client connects successfully, but switching to a router leaves some devices offline? Check traffic interception, DNS, and the return path before changing nodes. This guide compares desktop clients, cores, main-router deployments, and bypass gateways, with steps for testing one device, checking DNS, and rolling back safely. Addresses and ports are examples, not software defaults.
Understand the Roles of Clients, Cores, and Gateways
Adding a subscription URL to a router does not complete a gateway setup. v2rayN is a desktop GUI client that manages nodes, generates configuration, and launches a core. A router typically runs a V2Ray or Xray core built for its operating system and processor architecture, with a service manager and firewall rules handling traffic forwarding. Desktop installers cannot simply be copied to a router and run.
V2Ray and Xray differ in configuration and features. VMess and VLESS are proxy protocols; WebSocket and similar options are transport methods. The protocol, transport, and security settings used by a node must match the selected core. A subscription importing successfully in v2rayN does not mean the router's conversion tool and core support every field.
- Node connection: Handles authentication, encryption, and the connection to the server. Test one node before routing traffic for the whole network.
- Traffic entry: Explicit HTTP/SOCKS proxies accept requests only from apps configured to use them. Transparent proxying requires additional traffic redirection or policy-based routing.
- Gateway: Handles device next hops, DNS, IPv4/IPv6, and firewall rules. Starting a listening port alone will not automatically route LAN traffic.
Choose an Architecture with a Reliable Rollback Path
If only one or two devices at home need a proxy, start with a desktop or Android client to make troubleshooting easier. Use v2rayN on desktop; v2rayNG uses the Xray core, while v2flyNG uses the V2Fly core—both are for Android. A gateway adds maintenance overhead, so consider one only when multiple devices need shared policies or some devices cannot be configured to use a proxy.
Test a Bypass Gateway with One Device
RecommendedKeep dialing, Wi-Fi, and DHCP on the main router, and run the core on a separate device. Manually point one test computer's gateway to the bypass gateway. Expand only after confirming that the connection and DNS work. This is a recommended migration sequence, not a claim that bypass gateways are always faster.
Best for: Home networks with a stable main router that need a gradual rollout and an easy rollback.
Run the Core on the Main Router
Dialing, forwarding, DNS, and proxying all run on one device, giving you a more direct path and centralized policies. But a core upgrade, bad rule, or exhausted resources can take the whole household offline. Keep a configuration backup and a way to manage the router locally.
Best for: Users with capable hardware and experience maintaining firewalls and system services.
Keep Using Client Apps on Devices
Choose nodes and routing independently on each device without changing the home's default gateway. Updates and troubleshooting stay contained to one device, but configurations need separate maintenance. Apps that ignore system proxy settings require separate handling.
Best for: Users with few devices who travel often or need app-specific routing.
Plan Your Addresses: A Bypass Gateway Doesn't Work by Plugging It In
For a single-interface bypass gateway on the same subnet, use this example: the main router is 192.168.10.1/24, the bypass gateway has a static address of 192.168.10.2/24, and the test computer is 192.168.10.100/24. The bypass gateway's own default route still points to the main router, while the test computer's default gateway points to the bypass gateway. This example does not cover every dual-interface or multi-VLAN setup.
| Device | Example setting | What to check |
|---|---|---|
| Main router | 192.168.10.1 | Continue providing internet access and DHCP. |
| Bypass gateway | 192.168.10.2 | Use a static address outside the dynamic pool, or create a DHCP reservation. |
| Test computer | 192.168.10.100 | Manually set the default gateway to 192.168.10.2 first. |
| Test computer DNS | 192.168.10.2 | Set this only after the bypass gateway is providing a reachable DNS service. |
A single-interface bypass gateway on the same subnet can create an asymmetric path: the computer sends traffic to the bypass gateway, direct traffic exits through the main router, but replies may return straight from the main router to the computer. This may not cause an immediate outage, but can affect connection tracking, traffic accounting, or firewall policies. Whether you need source NAT, a separate subnet, or additional routes depends on your topology. Don't blindly apply a NAT rule to the entire network.
- Keep only one intended DHCP server to prevent devices from receiving different gateways at random.
- On the bypass gateway, check IPv4 forwarding, firewall forwarding permissions, and the return path. With policy-based routing, also check that reverse-path filtering is not dropping packets.
- Don't point the bypass gateway's default route to itself, and don't configure the main router and bypass gateway to use each other as their default route.
Roll Out in Stages: Start with an Explicit Proxy, Then Route Traffic
First confirm that the core can connect; then confirm that the gateway can route traffic. Separating these checks makes it easier to find the cause when node settings, firewall rules, and DNS fail at the same time. This process leaves the main router unchanged, so a failed test requires only restoring the test computer's network settings.
-
Record the Current Settings
In Windows, open Settings → Network & Internet → Properties for the active connection, and note the IP address, gateway, and DNS settings. The editing path may vary by Windows version. Take a screenshot before changing the test computer.
-
Check the Runtime Environment
On the router, run
uname -mto identify the processor architecture, then check the firmware's package repositories, runtime libraries, and kernel version. Use a deployment method supported by that system, and note the version of the core actually installed—not just the version shown in the management interface. -
Test One Node
Start an HTTP/SOCKS entry point for testing only. In this example, choose
10808manually and restrict access to trusted LAN devices, then send an explicit proxy request from the computer. Check the logs for authentication failures, handshake failures, or port conflicts. -
Route One Computer Through the Gateway
Configure the transparent entry point and forwarding rules for your core and firewall, then set the test computer's gateway to
192.168.10.2. Before testing, turn off the computer's system proxy and TUN to avoid false positives from requests still going through a client on the device. -
Adjust DHCP Last
Consider distributing settings network-wide only after the single-device test is stable. In standard OpenWrt LuCI, configure the IPv4 gateway and DNS under Network → Interfaces → LAN → Edit → DHCP Server → Advanced Settings → DHCP-Options. Firmware menus may use different names, so verify the actual fields.
If the main router distributes the settings in this example, DHCP option 3,192.168.10.2 sets the IPv4 default gateway, and 6,192.168.10.2 sets DNS. After making changes, renew the test device's lease and verify the values it receives. Don't distribute these settings network-wide before DNS works on the bypass gateway, and remember that IPv4 DHCP options do not configure IPv6.
# Example: The bypass gateway has an HTTP/SOCKS mixed entry point configured on 10808
# Use curl.exe in Windows Terminal; use curl on other systems
curl.exe --proxy socks5h://192.168.10.2:10808 --connect-timeout 10 -I https://example.com/
# Check whether the DNS service on the bypass gateway responds
nslookup example.com 192.168.10.2socks5h sends the destination hostname to the proxy for resolution. This tests only the explicit proxy path; it does not verify the computer's regular DNS requests or transparent proxy setup. Then test a regular browser and the apps you use with the device proxy turned off.
Check DNS, IPv6, and UDP as Separate Paths
If some websites load while others keep spinning, first check where their DNS queries are going. Apps may use system DNS or enable Secure DNS and resolve names themselves over HTTPS; the bypass gateway's domain-routing rules may not see the same queries. Don't assume every app follows the same resolution path just because you see one DNS server address.
- Prevent DNS loops: If the system resolver sends queries to the core and the core's upstream points back to that resolver, queries may be forwarded in a loop. Map the actual path from device to local resolver to upstream, and keep a working initial resolution path for the node server's hostname.
- Test both record types: Query A and AAAA records, and check the actual IPv4 and IPv6 exit paths. A device may still receive an IPv6 default route from the main router, so changing only its IPv4 gateway does not mean all connections pass through the bypass gateway.
- Check UDP support: Voice calls, games, and apps using QUIC may rely on UDP. Confirm that the node, core entry point, and transparent forwarding setup all support the required traffic; a single TCP website test is not enough.
- Define rule boundaries: Explicitly handle the gateway's management address, LAN subnets, multicast and broadcast traffic, and connections to the proxy server. This prevents the core's own outbound traffic from being sent back through its entry point.
Compare Performance: Single-Core Speed, Memory, and Failure Impact
A gigabit Ethernet port does not guarantee gigabit speeds through an encrypted proxy. Throughput depends on single-core CPU performance, protocol and transport overhead, concurrent connections, log writes, and cooling. A main router also handles dialing, firewall rules, and Wi-Fi management; a heavily loaded proxy can increase latency for other devices. A bypass gateway moves the processing load, but does not eliminate forwarding bottlenecks on the main router.
| Metric | How to check | What to look for |
|---|---|---|
| CPU and temperature | Transfer data continuously for 10 minutes and check per-core usage and device temperature. | If one core stays maxed out, the total CPU percentage can be misleading. |
| Available memory | Check free, process usage, and system logs. | Distinguish cache from available memory, and watch for processes exiting due to low memory. |
| Latency and stability | Run a test at idle and another during a download; monitor for at least 30 minutes. | These are suggested test durations, not measured results from this guide. |
| Recovery after reboot | With someone available to restore service locally, reboot the core and gateway separately. | Confirm that services start automatically, rules are restored, and DNS starts in the right order. |
When running the core on the main router, check whether hardware flow offloading is compatible with the transparent proxy rules: some offload paths can bypass the required processing chain. Don't enable every option just to improve speed test results. With a bypass gateway, also check what happens if it loses power. If DHCP has assigned it as the network-wide default gateway, devices will not automatically fall back to the main router.
During maintenance, save the core configuration, service startup settings, firewall rules, and DHCP settings. Before upgrading, record a version you can roll back to. Test subscription conversion, domain policies, and UDP on a test device before expanding the rollout. A successful subscription update means only that configuration data was retrieved; it does not guarantee that every node will run on the current core.
Troubleshoot by Symptom and Keep Desktop Clients in Their Role
Changed the bypass gateway and now the computer is completely offline?
Restore the gateway to 192.168.10.1 first and confirm the original network works. Then check whether you can reach 192.168.10.2, whether the bypass gateway itself can access the internet, and whether forwarding is enabled. If domains stop resolving after a DNS change but the gateway is reachable, test DNS separately instead of immediately reinstalling the core.
Explicit proxy works, but nothing loads when you turn it off?
This means the node and explicit entry point are basically working. Next, check the transparent entry point, firewall rule counters, and policy routing. First verify the computer's actual default gateway, then check whether requests match the intended rules. Don't keep changing node authentication settings that have already been verified.
The computer works, but your phone won't use the bypass gateway on the same Wi-Fi?
Check the gateway and DNS settings the phone received, reconnect to Wi-Fi to renew its lease, and check its IPv6 routes and app-specific DNS settings. If v2rayNG or v2flyNG is still running on the phone, pause the connection before testing the gateway path so the two sets of rules don't interfere with troubleshooting.
Can you still use v2rayN if you have a bypass gateway at home?
Yes, but be clear about which device handles what. For everyday use, let the desktop use the gateway. To test a node independently, select Automatically configure system proxy under System Proxy in v2rayN. Also check whether the gateway will proxy the node connection again. If needed, add a clear direct-connection rule to avoid an unintended double proxy.
Don't judge success by whether websites load. Also check LAN file sharing, printing, voice calls, and the apps you use; test DNS and IPv6 paths; and confirm that restoring automatic network settings returns the device to its original connection. If you're unfamiliar with system forwarding rules, keeping client apps on devices and limiting the gateway rollout to a controlled test is usually easier to maintain than replacing the whole home's internet gateway.