If you want every device at home on the same accelerated route, a router VPN is hard to avoid. Phones, laptops and tablets can each run their own app. Smart TVs, game consoles, TV boxes and some smart home gear either have no client available or won't let you change network settings, which makes handling them one by one a chore.
Start by deciding what whole-home acceleration actually solves
A router setup moves acceleration from each device up to the home's exit point. Every device connected to that router automatically uses the same route, with no per-device configuration — a new device works the moment it joins the Wi-Fi. The term "router VPN" doesn't mean the router itself encrypts traffic; it means the router handles forwarding and encryption on behalf of every device in the house.
This route isn't for everyone. Check the two lists below against your own situation.
- ✅ Two or more devices at home that can't run a client, such as a TV, game console or TV box
- ✅ Lots of devices — installing a client on each one and updating subscriptions one by one takes too much time
- ✅ You already own a router that supports third-party firmware, or you're willing to add a secondary gateway device
- ✅ You can live with the one-off hassle of changing your network configuration
- ❌ You only have a laptop and a phone, and just a couple of devices need the accelerated route
- ❌ Your router is an ISP modem/router combo that can't be flashed, and you don't want to add another device
- ❌ You need completely different routes for different devices but don't want to write rules
- ❌ You don't want to touch network settings at all — you just want something that works with one click
If three or more items in the second list apply to you, per-device clients are usually less trouble, and you can skip the rest of this article.
Three paths: router plugin, secondary gateway, per-device client
There are three ways to put your whole home on an accelerated route. They differ in complexity, coverage and who is responsible for performance — start with the comparison table.
| Approach | What you change | Coverage | Difficulty | Performance handled by |
|---|---|---|---|---|
| Router plugin | Flash third-party firmware, install a proxy plugin | Every device connected to that router | Medium-high | Router CPU |
| Secondary gateway | Add a device that runs the proxy; point clients' gateway at it | Devices whose gateway you set manually | Medium | Secondary gateway CPU |
| Per-device client | Install the VPNBu client on each device | Devices with the client installed | Low | The device's own CPU |
Router plugin: configure once, works house-wide
Flash third-party firmware such as OpenWrt or Merlin onto the router, install a proxy plugin like OpenClash or PassWall, paste in the subscription link from your provider, and a single update pulls the full node list. From then on, everything connected to that router — TVs and game consoles included — follows the rules automatically.
The barrier is twofold. First, hardware: not every router can be flashed, and models with too little flash or RAM can't hold a plugin with its own core — force it and the router reboots constantly under memory pressure. Second, risk: a slip during flashing can brick the device, and some brands void the warranty once you flash. Before you start, confirm your exact model has mature firmware and community support.
Secondary gateway: leave the main router alone, add one hop
The main router stays on stock firmware and keeps handling dial-up, Wi-Fi and DHCP; a separate device (an old laptop, a mini PC, an ARM board — anything works) runs the proxy. Point the client's gateway and DNS at that secondary gateway and traffic detours through it.
The upside is that your main router stays untouched, so its stability is unaffected. The cost is an extra hop: data goes from the client to the main router, to the secondary gateway, back to the main router, and then out. If the secondary gateway goes down, every device pointed at it loses connectivity — so either accept that risk or keep a switchable configuration on the main router.
Per-device client: lowest barrier, limited coverage
Install a VPNBu client on every device that supports one, import the subscription, and pick rule mode. No router changes, encryption runs on the device's own CPU, and client updates are independent. The trade-off is clear: devices that can't run a client — your TV and game console — stay exactly as they were.
You can mix all three: hand the TV and game console to the router or secondary gateway, keep clients on laptops and phones, and nothing conflicts. A VPNBu account allows unlimited simultaneous connections, so mixing doesn't require extra accounts.
Where the performance cost lands: CPU, forwarding path, Wi-Fi
Once your whole home runs through the accelerated route, the usual outcome is that wired speeds hold up while Wi-Fi gets noticeably slower. The cause is usually one of three things.
One: CPU encryption. Traffic has to be encrypted to travel through the tunnel, and encryption costs CPU. x86 platforms generally have AES hardware instructions, so encryption is nearly free; only some ARM routers have an AES instruction set, and older models have to grind through it on a single core. Without hardware acceleration, stream ciphers like ChaCha20 usually cost less CPU than AES. The check is simple: look up your router's CPU model and see whether it supports AES instructions.
Two: a longer forwarding path. Without a proxy, packets are forwarded straight through the kernel; with one, traffic passes through a user-space proxy process, adding several copies between kernel space and user space. Once the connection count climbs, a single core can saturate, and speed starts swinging up and down.
Three: the Wi-Fi bottleneck itself. Most homes share one Wi-Fi band, and a router's wireless throughput is already lower than its wired ports. Acceleration doesn't make Wi-Fi faster — it addresses whether the outbound route is stable, not how fast the link inside your home is.
One more easily overlooked point: the NAT session table. BitTorrent downloads and many concurrent devices can pile up connections in an instant, and a router short on memory will simply drop the connection. This has nothing to do with acceleration, but it's often mistaken for a problem with the route.
To judge whether your router can keep up, run a wired speed test first: once without the proxy and once with it, then compare throughput. If the gap is within what you can accept, consider going whole-home.
Split routing and DNS: how to configure rule mode
When a proxy runs on the router, the mode you choose matters more than the node you pick. There are four common ones.
- Global mode: all traffic goes through the accelerated route. It's the simplest to configure, but sites in mainland China also take the long way around, so latency actually goes up, and some streaming sites throttle because the exit is overseas.
- Rule mode (split routing): decisions are made by domain and IP — traffic matching the rules goes through the accelerated route, everything else connects directly. Plugins usually ship with rule sets like mainland domain lists and GeoIP CN, and you can add your own.
- Direct mode: nothing goes through the accelerated route. Useful for troubleshooting.
- fake-ip mode: the client hands the app a fake IP and matches rules by domain instead, saving one DNS round trip and speeding up first connections. The side effect is that a few scenarios depending on real IPs — some games and LAN device discovery — need those domains added to the direct list.
DNS leaks are another common problem. The symptom: traffic really does go through the accelerated route, but DNS queries still go to your local ISP. The result can be resolving to a mainland CDN node, or the query itself being visible to an intermediary. Detection isn't complicated: once connected, open a DNS leak test page and check whether the resolver's location and your exit IP are in the same region. The fix is to let the proxy client handle DNS centrally — enable DNS hijacking or fake-ip in the plugin, or specify a trusted DNS and force it through the tunnel.
Before you change DNS hijacking on the router, take a screenshot of the original configuration. Get it wrong and every device in the house fails to resolve domains, leaving a factory reset as the only way back.
Choosing a protocol on a router
The protocol determines encryption overhead and UDP support. On a device with limited compute like a router, the differences between protocols are far more pronounced than on a PC.
| Protocol | Transport | Key traits | Watch out for on a router |
|---|---|---|---|
| Shadowsocks | TCP / UDP | Lightweight, low encryption overhead | Widest plugin support; the first choice for older routers |
| VMess | TCP / WebSocket / gRPC, etc. | Requires client and server clocks to be in sync | If the router's clock drifts, it simply won't connect |
| VLESS | Relies on TLS at the transport layer | One less encryption layer than VMess; often paired with Reality | Requires a recent enough TLS library in the firmware |
| Trojan | TLS | Traffic looks like standard HTTPS | Handshake overhead is a bit higher, more noticeable on weak CPUs |
| Hysteria2 | QUIC(UDP) | Performs well on lossy links | Depends on UDP forwarding; some kernels support it incompletely |
| TUIC | QUIC(UDP) | Multiplexing, fast handshake | Again, confirm the router forwards UDP properly first |
A sensible order: if the router's CPU is weak with no AES hardware acceleration, favor protocols with low encryption overhead; if the firmware handles UDP forwarding poorly, avoid QUIC-based protocols for now; if you're unsure, start with the client's default and switch once it's running.
No protocol is universally better — only a better match for your device. A protocol that flies on a PC may not reach even half its speed on an older ARM router, and the reason lies in CPU encryption and UDP forwarding capability.
Preparation and step-by-step setup
Taking the router plugin path as an example, the full process looks like this:
- Confirm your router model. Check the official community or firmware support lists to confirm firmware exists, and verify that flash and RAM are enough for the plugin.
- Back up the stock configuration. Export a config file and note down your broadband credentials and Wi-Fi settings so you can roll back at any time.
- Flash the firmware and restore networking. Confirm normal internet access first, then touch proxy-related settings.
- Install the proxy plugin. Install it from the firmware's software sources, and make sure the plugin version matches the core version.
- Import the subscription link. Paste the subscription URL from your provider into the plugin, run one update, and confirm the node list came through.
- Choose the run mode and DNS mode. Start with rule mode plus fake-ip, then adjust after a few days of observation.
- Verify device by device. Test each type of device once: check the exit IP, check where DNS resolves, and run your most common scenario.
When choosing a service, here are a few points you can verify directly: coverage across 100+ countries / 240+ routes, with IEPL dedicated lines, relay and direct routes; unlimited simultaneous connections per account, so one is enough for the whole home; subscriptions from ¥9.9/month with 60GB, and data packs that last until used up and never expire; Alipay / WeChat / USDT accepted; no email address required to sign up — just a username and password.
Clients cover Windows / macOS / iOS / Android / Linux. For devices the router can't reach, install a client on the device itself — both use the same account, so there's no separate management.
The 60-day no-questions-asked refund matters especially for a router setup. Flashing firmware, tuning split routing and testing routes all take time, and sometimes you have to switch approaches once or twice before you find what suits your home — a way out makes it easier to start.
The value of a router setup is covering devices that can't run a client, not being more advanced. If you have few devices and can install clients one by one, do that; if the TV and game console are must-haves, then consider flashing firmware or adding a secondary gateway.