The router VPN trade-off comes down to moving who provides the international exit from each device to one machine that stays on all the time. Once it has moved, set-top boxes, game consoles and smart TVs — hardware that cannot install a client — travel the same international routes; the cost is that if that machine fails, the whole home goes down with it. The four steps below cover whether to do it, how to place the modem and router, primary versus sidecar, and how to check your own work; the final section lists the cases where you should leave the router alone.
Short answer: only worth touching the router if the device list includes hardware that cannot run a client; in every other case, per-device connections are simpler.
First, decide: which homes should put acceleration on the router
The test is not how many devices you own, it is whether any of them cannot run a client. VPNEH's official apps cover Windows, macOS, iOS, Android and Linux, with no cap on the number of devices, so phones, tablets and laptops can each install their own copy — no router required. The cases that genuinely call for one are the three below:
- Set-top boxes, game consoles and smart TVs in the living room: closed systems that cannot install a third-party client, so an upstream gateway has to carry their traffic.
- Always-on hardware such as a NAS, IP cameras or a printer that should reach international services over the same route.
- A busy household where you would rather not teach every device how to connect and switch routes — configure once and everyone is covered.
Conversely, if the house has one or two phones and a laptop, or you travel often and need to switch routes on different networks, the router approach adds more complexity than it returns — per-device clients are faster and far easier to troubleshoot.
Modem and router placement: settle the topology first, then configure
This is where many people get stuck: the proxy core is installed, but speeds do not improve, or some apps cannot connect. The cause is usually not the route but two layers of NAT stacked on the network.
The ISP's modem ships in router mode by default, dialing in and handing out addresses itself; put another router behind it and you get two layers of address translation. Ordinary browsing barely notices, but reconnects, multiplayer sessions and port forwarding suffer, and troubleshooting gains an invisible extra hop.
The standard fix is to make the modem a pure media converter: switch it to bridge mode and let the router dial out over PPPoE. The router then faces the upstream directly, the forwarding path is as short as it gets, and the proxy core's position in the traffic flow is unambiguous. Bridging usually needs the ISP to cooperate, and procedures vary by region — whether it can be done, and how, depends on what your local installer says.
If bridging is not possible, fall back to this: run the proxy on the router you actually control, and make it the only address-assignment point in the house — turn off the modem's built-in Wi-Fi so every device joins the router's network. At least then split-routing rules apply in exactly one place, with no mismatch where the phone goes through the proxy and the TV does not.
Primary router setup: one box handles dial-up, forwarding and split routing
In a primary-router setup the router dials out itself, the proxy core runs on the same box, and TProxy or TUN mode provides transparent proxying that takes over LAN traffic directly.
The flow runs roughly like this: import the subscription link into the proxy core → the core pulls the route list → split-routing rules decide direct or proxied by domain and GeoIP → LAN traffic is forwarded into the core → it leaves through the selected route.
The upsides are straightforward:
- A single NAT layer, the shortest path, and fewer points of latency or failure.
- Every device in the house is covered automatically — no per-device setup, guests on the Wi-Fi included.
- DNS can share the same split-routing logic as the proxy, reducing the chances of domain lookups leaking onto the local link.
The costs are just as clear:
- The CPU has to handle address translation and encryption at the same time. Encrypted protocols are not cheap, and on an underpowered router the bottleneck shows up in the router, not the route.
- Many home firmwares enable hardware offload by default, which can interfere with transparent proxying — some traffic ends up skipping the proxy. If rules that are clearly written do not take effect, turn off hardware offload and test again.
- If that router reboots or its firmware misbehaves, the whole house goes offline. If anyone depends on the network for work, keep a fallback path ready.
Sidecar router setup: leave the main router alone and point the gateway at it
A sidecar setup keeps the existing main router and adds a second device running the proxy core; the main router's DHCP hands out the sidecar as default gateway and DNS, so traffic detours through it automatically.
A few configuration points are non-negotiable:
- Turn off DHCP on the sidecar; address assignment stays with the main router, otherwise the two DHCP servers fight.
- Keep the sidecar on the same subnet as the main router and connect it with one cable to a LAN port — a single-arm setup is enough.
- Devices with a manually assigned static IP will not pick up the new gateway; point their gateway and DNS at the sidecar by hand.
- Allow forwarding from the LAN on the sidecar, and confirm the firewall is not dropping transparent-proxy traffic.
The big advantage of a sidecar is that it rolls back: if something breaks, set the gateway handed out by the main router's DHCP back to itself and the whole house is online again in under a minute, with no rewiring. The change footprint is small, and existing dial-up and Wi-Fi coverage are untouched.
The cost is an extra forwarding hop — all traffic detours through the sidecar, whose network port and CPU become the new bottleneck — plus one more always-on device to think about when it loses power, reboots or updates.
Choosing between the two: one table
| Comparison | Primary router takeover | Sidecar router |
|---|---|---|
| Topology | Router dials out directly and is the home's only exit | Attached to a LAN port on the main router, single-arm |
| Scope of change | Modem bridged + full router reconfiguration | Only the gateway and DNS handed out by the main router's DHCP |
| Impact of failure | A router fault takes the whole house offline | Point the gateway back at the main router and you are back |
| Performance bottleneck | Router CPU and wireless chip | Sidecar network port and CPU, plus one extra hop |
| Split routing | Transparent proxy + domain / GeoIP rules | Same, with rules centralised on the sidecar |
| Best for | A single capable flashable router and the shortest possible path | Leaving the existing network alone and keeping rollback on hand |
Bottom line: if you have one capable flashable router and want the shortest path, take primary-router takeover; if you would rather not touch the existing network, or availability matters most, go with a sidecar. Neither is better in the abstract — it is a question of how much change you are willing to take on.
Routes and protocols: the three things router setups overlook most
Protocols: can the router keep up?
Shadowsocks, VMess, Trojan and VLESS are the common TCP-based options: Shadowsocks is lightweight with little overhead; VMess depends on time sync, and a large clock skew on the device means it simply will not connect; Trojan runs over standard TLS, usually on port 443; VLESS has a leaner structure and suits hardware with limited performance.
Hysteria2 and TUIC are built on QUIC and run over UDP, which pays off on high-latency, lossy links; but they demand more UDP forwarding capability and CPU from the router, and some networks rate-limit UDP. On a modest router, prefer the TCP-based protocols; only consider UDP-based ones when the sidecar has performance to spare.
Route types: IEPL, relay and direct
- Direct: the nearest entry point and the shortest path, and the most exposed to public-network congestion at peak hours.
- Relay: enters through a third location before forwarding, sidestepping congested segments at the cost of one extra hop.
- IEPL: travels a dedicated circuit rather than the public internet, so latency and jitter stay steadier — a good fit for always-on devices that are sensitive to stability.
Not every device behind the router has to use the same route. Grouping by purpose is more practical: set-top boxes and consoles on IEPL, phones and laptops on auto-select, so you can see at a glance what is using what. VPNEH currently covers 90+ countries and 190+ routes, so you can pick an exit by region.
Data: shared across the whole home, and used up faster
There are three monthly tiers: ¥9.9/month with 60GB, ¥18/month with 250GB and ¥28/month with 500GB. Data resets every month on your activation date, and mid-cycle upgrades are prorated against the remaining days. With every device in the house on the same connection, consumption climbs noticeably faster than on a single machine — HD video on a set-top box is the big one.
If you only need a large amount of data occasionally, top-up packs fit better: ¥158/300GB, ¥358/1000GB and ¥658/3000GB, valid until used up, never expiring and never reset by the monthly cycle. Router setups usually pair with a monthly plan because they are always on; leave the packs for occasional large transfers.
After deployment: five steps to confirm it really works
Connecting is not the same as working. Router setups are especially prone to looking fine while half the traffic never reaches the proxy — check each of the five points below:
- ✅ Gateway: check the default gateway on a computer. It should point at the device running the proxy; if it points at the modem or main router, traffic is not going through the proxy at all.
- ✅ Exit: open an IP lookup page. The exit region should match the route you selected, not your local ISP.
- ✅ DNS: check whether domain lookups also go through the proxy. If your local ISP still resolves them, you have a DNS leak and the split-routing rules need a DNS section.
- ✅ Split routing: domestic sites should go direct and international sites through the proxy. If everything goes through the proxy, the rules are not taking effect — or hardware offload is stealing the traffic.
- ✅ Rollback: stop the proxy core or unplug the sidecar. The network should fall back to a direct connection rather than going dark. Confirm the rollback path before committing to long-term use.
- ❌ Assuming it works because the client says Connected — that only means the core is running, not that traffic actually goes through the proxy.
Common pitfalls: with transparent proxying and hardware offload both on, some traffic slips past the rules; with DNS left to the ISP and the proxy handling only TCP, domain lookups still travel over the local link. Skip these two checks and every route change afterwards feels like it works sometimes and not others.
When to skip the router and connect each device separately
- Few devices: one or two phones and a laptop, each with its own client, take minutes to set up and never touch the firmware.
- Frequent movement: business trips, cafés, office networks — a client on each device is more flexible, and there is no risk of forgetting to switch back at home.
- Fine-grained control: different devices on different countries, different apps on different routes — per-app rules in a client are far easier to tune than router rules.
- Old or locked-down router: forcing transparent proxying onto it is a poor trade in both performance and stability; better to spend the budget on the devices that run the clients.
One more case is easy to overlook: a single router that handles dial-up, Wi-Fi and proxying all at once. Any one of those failing means rebooting the whole box, and troubleshooting gets expensive. In that situation, moving the proxy to a sidecar — or simply going back to per-device clients — is the steadier choice.
The trade-off: a router setup solves how devices that cannot run a client reach international routes, not how to go faster. In a household with a simple device mix, running the VPNEH client on each device with auto-select across 90+ countries and 190+ routes is already enough; wait until a set-top box or console shows up in the living room before touching the router.
Cost of trying: creating an account takes only a username and password — no email address required. A full refund, no questions asked, is available within 14 days of your first payment; there is no cap on devices, and Alipay, WeChat Pay and USDT are accepted. Get the routes and split-routing rules working first, then decide whether to keep this topology at home long term.
To pick an exit by region, start with the route list; to compare data tiers, see plans.