Remote work VPN: how to choose routes for video calls that stay smooth

Why meetings stutter: packet loss and jitter, not bandwidth

A video meeting is a real-time two-way stream. The encoder produces a frame roughly every 20 milliseconds, and the receiver lines frames up in a jitter buffer of tens to hundreds of milliseconds before playing them out. Lose a packet along the way and there is no time to retransmit, so the player falls back to the previous frame — you get a blocky patch or a frozen instant. When losses come in a burst, audio drops out first. The whole process is extremely sensitive to delay variation and barely cares about peak bandwidth.

Bandwidth is the easiest requirement to satisfy. A 1080p group meeting needs roughly 2.5–4 Mbps upstream, and 1080p screen sharing roughly 1.5–2.5 Mbps. Most office connections offer more upstream than that, so when bandwidth looks fine but meetings still stutter, the problem almost always sits with the other three metrics.

The figures in the table are typical observed ranges for orientation, not vendor promises; real-world results also depend on the encoder and the meeting app's degradation strategy.

How the three route types really differ at peak hours

Route type describes the physical path packets take from your computer to the target server; the protocol used to encapsulate them is a separate matter. The protocol (Shadowsocks, VMess, Trojan, VLESS, Hysteria2, TUIC) determines the handshake, loss resilience and UDP support; the path determines how congested the route gets between 8 and 11 p.m. Keep the two apart, and you won't mistake a newer protocol for a more stable route.

Direct: shortest path, but a shared exit with everyone else

The client connects straight to an overseas server and traffic crosses public international gateways. The path is the shortest and latency is usually the lowest, but public gateways are shared infrastructure, so packet loss and jitter both climb at peak hours. Best for bandwidth-hungry, latency-tolerant work such as overnight large-file syncs or pulling container images.

Relay: stable entry point, bottleneck on the outbound leg

Traffic first reaches a relay entry point in mainland China, then leaves through the relay server. That adds a hop, but the in-country leg runs over a controlled link with a stable entry point; the bottleneck shifts to the outbound segment, where peak-hour stability depends on the relay operator's exit capacity. Most office workloads can treat this as the default route.

IEPL: a point-to-point link that skips public gateways

International Ethernet Private Line is a point-to-point link that does not share public gateways, so bandwidth and packet loss stay essentially flat at peak hours. It costs more, so coverage is usually limited to core regions. Workloads that are sensitive to loss and jitter — video meetings, remote desktop — belong on this class of route first.

At the protocol level, QUIC-based Hysteria2 and TUIC handle lossy conditions more gracefully: no head-of-line blocking, plus forward error correction. The trade-off is that UDP is throttled or even blocked on some networks, and in that case Trojan or VLESS + TLS is the safer fallback. But no protocol choice can rescue a physical path that is already congested — pick the route first, then tune the protocol.

Choosing a route by office workload

A single subscription usually includes several routes, and which one to pick depends on what you do most. Below are the trade-offs for four common office scenarios — the criteria are not the same for each.

Video meetings: Zoom / Teams / Meet

Priority is packet loss, then jitter, and bandwidth last. Choose an IEPL dedicated line and confirm the client has UDP forwarding enabled. Avoid routes with automatic load balancing that switch nodes mid-session: a switch means the connection is rebuilt, and the meeting drops for several seconds.

Remote desktop / SSH / databases

These interactive workloads are the most RTT-sensitive and need very little bandwidth — under 5 Mbps is usually plenty. Choose a dedicated-line entry point that is physically close with stable RTT; don't pick a far-away node just because it advertises more bandwidth, since the detour costs more in latency than it gains in throughput.

File sync / code repos / cloud drives

This traffic runs over TCP, where retransmission covers packet loss, so the experience depends mainly on bandwidth. Relay or direct routes are fine here — save the dedicated line for meetings and remote desktop. Splitting route capacity by workload pays off better than making everyone share one path.

VoIP / live chat support

Bandwidth needs are lower than for video meetings, but jitter is just as damaging. The criteria are the same as for meetings: look at peak-hour latency variation first, bandwidth second.

Split routing and client settings

Split routing exists to keep scarce dedicated-line bandwidth for meetings instead of squeezing all traffic onto one path. The basic idea has three parts: domains and IPs in mainland China go direct, meeting and collaboration domains use the route, and everything else takes the default exit.

# Split routing example (matched by domain and region, evaluated top to bottom)
DOMAIN-SUFFIX,zoom.us,PROXY
DOMAIN-SUFFIX,teams.microsoft.com,PROXY
DOMAIN-SUFFIX,slack.com,PROXY
DOMAIN-SUFFIX,meet.google.com,PROXY
DOMAIN-SUFFIX,github.com,PROXY
GEOIP,CN,DIRECT
MATCH,PROXY

Rules are matched from top to bottom and the first hit wins, so specific domains must come before GEOIP. Meeting apps connect not only to their main domain but also to a batch of CDN and signalling domains — with only a zoom.us rule, video may come through while screen sharing still goes direct. When that happens, it is simpler to route the whole meeting app process over the dedicated line; desktop clients generally support per-process routing.

Subscription links and import

On every platform you paste the subscription link into the client, and the node list refreshes automatically on update — no manual entry, node by node. Treat the subscription link like account credentials and never post it publicly. There is no limit on simultaneous devices, but bandwidth on a single route is shared across all of them, so when several devices are in meetings at once, move non-meeting downloads to another route.

Client differences by platform

• Windows: TUN mode can take over all traffic, including meeting clients that ignore the system proxy; the first launch requires installing a virtual network adapter driver.
• macOS: the connection is established through a system network extension, so the first connection needs to be approved in System Settings, and some permissions must be confirmed manually.
• iOS: uses Network Extension, and the system will prompt you to allow the VPN configuration; background operation is limited by the OS, so for long meetings plug in and turn off Low Power Mode.
• Android: you need to grant VPN permission and add the client to the battery optimisation allowlist, otherwise the system may reclaim it when the screen is off and the meeting drops mid-session.
• Linux: use the command-line client with a system proxy or TUN; split routing takes effect differently across desktop environments, so test it once before you rely on it.

Switching strategy and a pre-flight checklist

Even the most stable route has maintenance windows. The low-effort approach is a primary and a backup: an IEPL dedicated line as primary, a relay route as backup. Switch to the primary ten minutes before an important meeting and run the steps below. You can compare route coverage in the route list, and confirm the exit really changed with the exit IP lookup.

1. Open the client and confirm the current route is the dedicated line, not a backup node left over from the last switch.
2. Use the exit IP lookup to confirm traffic is really going through the route — the city shown should match where the node is located.
3. Run a loopback test inside the meeting client and check packet loss and latency in its statistics panel.
4. Confirm UDP forwarding is on, and that the meeting app isn't being missed by the split-routing rules.
5. Don't switch nodes or update the subscription during a meeting — both rebuild the connection.

• ✅ Switch and run the checks ten minutes before the meeting, not after you have joined.
• ✅ The mobile client is on the battery allowlist, so the connection survives screen-off.
• ✅ Meeting domains go over the dedicated line, and UDP forwarding is enabled.
• ✅ The backup route works, and you know how to switch back in one click.
• ❌ Treating node count as the only selection criterion: more nodes doesn't mean a better path.
• ❌ Updating the subscription or switching nodes mid-meeting.
• ❌ Watching only the peak download figure from a speed test: that is a one-off number, unrelated to packet loss and jitter during a meeting.