Remote Work VPN Comparison: Video Calls and Collaboration Tools Are Hit Hardest by Packet Loss

Why Calls Are More Sensitive to Packet Loss Than Video

On the same international route, 4K video may stream perfectly at night, yet a call the next morning keeps breaking up. The reason is not bandwidth — it is that the two kinds of traffic handle packet loss in completely different ways.

Video sites use HTTP over TCP. The player pre-loads a chunk of content into a buffer; if a packet is lost on the path, TCP retransmits it, and as long as the buffer has not run dry the viewer notices nothing. The whole point of buffering is to absorb network jitter.

Video calls take a different path. Tools such as Zoom, Teams and Google Meet are built on WebRTC: audio uses the Opus codec, video uses VP8 / VP9 / H.264 / AV1, and the media is wrapped in RTP, encrypted with SRTP and carried over UDP. UDP makes no delivery guarantee, and a real-time media stream will not stop and wait for a retransmission — by the time a packet made the round trip, that slice of audio would already be due to play. So conferencing apps simply drop what is lost and conceal it using the preceding audio. That is why 1% packet loss on the path sounds like a slight glitch every second or two.

Of the three metrics, the order of impact on a call is: packet loss > jitter > latency. Packet loss removes content outright; jitter leaves the receiver's buffer unable to keep up, which sounds like audio speeding up and slowing down; high latency makes people start talking over each other.

• 1% A rough packet-loss reference point: at this level, audio already sounds choppy and the picture starts to break into blocks
• 150ms The one-way latency ceiling recommended by ITU-T G.114; beyond it, conversations tend to turn into people talking over each other
• 20ms A typical Opus frame length; the receiver's jitter buffer adjusts on roughly this scale
• 0 How many times a UDP media stream waits for a retransmission: lost packets are skipped and concealed from the preceding audio

Comparing Network Requirements Across Three Remote-Work Scenarios

Remote work is not one scenario but a group of them. Three matter most: calls, file sync and remote desktop. Beyond those sit two kinds of traffic that are often overlooked — online documents and package-manager pulls. Each has different requirements for a route, and applying one standard to all of them always leaves something feeling awkward. Start by breaking your workday apart and seeing which category dominates.

Scenario	Typical tools and protocols	Most sensitive metric	Preferred route	Symptoms when it goes wrong
Video calls / voice	Zoom、Teams、Google Meet;WebRTC / SRTP over UDP	Packet loss, jitter	IEPL dedicated line first, relay second	Choppy audio, blocky video, people talking over each other
File sync / code repositories	Git, cloud drive clients, object storage; TCP + TLS	Bandwidth, round-trip time	Relay or direct	Progress bars that stall and restart, large files retransmitted again and again
Remote desktop / SSH	RDP、VNC、SSH;TCP	Round-trip time, packet loss	IEPL dedicated line or relay	Cursor drift, obvious input lag, windows redrawing in blocks
Online documents / whiteboards	WebSocket、HTTPS	Round-trip time	Relay or direct	Cursors out of sync, saves spinning endlessly
Package management / image pulls	npm、pip、Docker Registry;TCP	Bandwidth	Relay or direct	Pull timeouts, checksum failures and full re-downloads

The table shows a clear pattern: the more traffic depends on instant feedback, the less it tolerates packet loss and jitter; the more patient the traffic, the more it only cares about bandwidth and round-trip time. The first step in choosing a route is not comparing prices but working out which kinds of traffic you run every day.

How to Split Work Between IEPL, Relay and Direct Routes

The route type decides which exit your traffic takes onto international networks. Across the three common paths, cost and stability track each other closely: the more stable, the more expensive; the cheaper, the more it depends on the time of day.

Direct: lowest cost, first to suffer at peak hours

The client connects straight to an overseas node, and traffic leaves through the local broadband provider's international gateway over public internet routes. The upside is simple configuration and generous bandwidth; the downside is that international gateways congest most easily at peak hours, pushing up both packet loss and jitter. Direct routes suit traffic that can be retransmitted — file sync, package management, image pulls — and downloads that are not in a hurry.

Relay: handing the international leg to optimized routing

The client first connects to a nearby relay node, which then carries the traffic out along an optimized route. It is effectively treating the last mile and the international leg separately, and the international leg is more stable than a direct connection, with smaller latency swings. Relays suit remote desktop, online documents, browser-based collaboration and most everyday cross-border access.

IEPL dedicated line: a path built for real-time traffic

IEPL is an end-to-end Ethernet dedicated line: the international leg does not pass through public internet gateways, so packet loss and jitter stay very low and latency is steady. It suits real-time traffic such as video calls, voice calls and live streaming. The trade-off is the highest bandwidth cost, usually allocated per line, and it is not meant for large files — feed the dedicated bandwidth to cloud drive sync and there will be nothing left for calls.

Route type	Path taken	Best for	Trade-offs and cautions
Direct	Local gateway → public internet international routes → overseas node	File sync, package management, off-peak downloads	Noticeable packet loss and jitter at peak hours; not recommended for calls
Relay	Nearby relay node → optimized route → overseas node	Remote desktop, online documents, everyday browsing	More stable than direct, but the international leg can still feel congestion
IEPL dedicated line	End-to-end dedicated line; the international leg avoids public internet gateways	Video calls, voice calls, live streaming	High bandwidth cost, allocated per line; do not use it for large files

Split-Tunnel Rules: Call Traffic Should Not Take the Long Way Round

The goal of split tunneling is not whether a connection works but making each kind of traffic take the path it belongs on. Within one subscription, calls take the dedicated line, remote desktop takes the relay, large file sync takes direct — each path in its place, none squeezing out another.

There are usually three ways to split traffic: by domain and IP range, by process name (desktop clients) or by app (mobile). Grouping by domain is the least work, since conferencing and collaboration tools use fairly stable domains and cost the least to maintain.

# Split-tunnel policy sketch: field names follow the config format of your client
groups:
  meeting:                        # call traffic → IEPL dedicated line
    - DOMAIN-SUFFIX,zoom.us
    - DOMAIN-SUFFIX,teams.microsoft.com
    - DOMAIN-SUFFIX,meet.google.com
  interactive:                    # remote desktop / online documents → relay
    - DOMAIN-SUFFIX,notion.so
    - IP-CIDR,198.51.100.0/24     # example range from the docs; replace it with your own remote desktop address
  bulk:                           # file sync / package management → direct
    - DOMAIN-SUFFIX,github.com
    - DOMAIN-SUFFIX,registry.npmjs.org
    - DOMAIN-SUFFIX,pypi.org

Once the rules are written, verify two things: that the conferencing domains really do match the call group, and that mainland China domains have not been misclassified into the proxy group — routing mainland China traffic over international lines only makes the dedicated line more crowded. If your client offers only Global and Rule modes with no custom policy groups, fall back to this: put the conferencing app in a mode of its own, switch to it before a call and switch back afterwards.

Client and DNS: What to Verify After Subscription Import

A subscription link does more than save you from entering nodes by hand. The node list, route changes and split-tunnel rules all update with the subscription, so when the service adjusts a route, the next subscription fetch syncs the client — no need to edit settings device by device. Most clients support scheduled auto-updates; set them to once a day.

At the protocol level, the common types clients support include Shadowsocks, VMess, Trojan, VLESS, Hysteria2 and TUIC. For remote work, the protocol is not the first consideration: switching protocols on the same server will not make packet loss and jitter disappear. Hysteria2 and TUIC are built on QUIC and bring their own congestion control and retransmission strategies to lossy networks, so they feel better when conditions are poor — but they still run over the public internet and cannot replace a dedicated line. What really decides call quality is the route type and the exit path.

Client differences across platforms directly affect whether split tunneling works:

• Windows / macOS: TUN mode and per-process splitting let the conferencing client, the browser and the cloud drive each use their own policy group;
• iOS / iPadOS: runs through a system VPN profile; the first time you enable it, an "Allow Configuration" prompt appears and you must tap Allow; the system only lets one VPN configuration be active at a time;
• Android: uses VpnService and supports per-app splitting; battery optimization can kill the client, so add it to the whitelist;
• Router / side router: hardware video endpoints in meeting rooms and devices that cannot run a client are covered by a side router.

A DNS leak means traffic goes through the proxy but domain lookups still leave from the local network. Besides exposing your lookup history, it also hands split-tunnel rules IPs that do not match. Turn on "Use proxy DNS" in the client or specify DoH / DoT, then run a DNS leak test page to confirm that the lookup exit and the proxy exit are in the same region.

• ✅ After importing the subscription, confirm the node list refreshes properly before joining a call
• ✅ Open a DNS leak test page and confirm the lookup exit and the proxy exit are in the same region
• ✅ Put the conferencing app in its own policy group in the client instead of letting it follow the global mode
• ✅ Before a call, use the client's route latency display to confirm the current route is usable
• ❌ Do not switch nodes, edit split-tunnel rules or update the subscription during a call
• ❌ Do not run large file sync in global mode; the sync job will eat into the dedicated line's bandwidth

When a Call Stutters, Troubleshoot in This Order

Once a call is already stuttering, overhauling the config mid-call only makes things messier. Work through the five steps below; each one rules out a category of cause.

1. First work out whether it is the network or the device. Open Task Manager or Activity Monitor to check CPU and memory use, pause any cloud drive sync and downloads, then reproduce the problem. Device-side stutter and route-side dropouts do not look the same.
2. Confirm which route is in use. In the client, check which policy group and node type the call traffic hits; if it lands on a direct node, switch to the dedicated line and try again.
3. Compare the same call on two different routes. If the dropouts disappear, packet loss was the bottleneck; if it still stutters, the problem lies with the device, the far end or the conferencing app itself.
4. Check split tunneling and DNS. Confirm the conferencing domains hit the call group and that the lookup exit matches the proxy exit.
5. Only then look at MTU. If handshakes work and small files transfer but the media stream keeps breaking up, a mismatched MTU may be dropping large packets; lower the client's MTU one step from the default (1400, for example) and test again.

Call Stutter and Route Choice: Common Questions

Conclusion: A Workable Route Combination

Boil the above down to one line: real-time traffic takes the dedicated line, interactive traffic takes a relay, bulk traffic takes direct or relay, and split-tunnel rules lock the three in place. Whether a call stutters depends on packet loss and jitter; how fast files move depends on bandwidth and round-trip time. Solve the two problems with two paths instead of expecting one route to do both.

For usage, a rough guide: if calls and document collaboration dominate and volume is modest, the monthly ¥9.9 / 60GB tier is enough; for all-day online use with frequent sync, look at ¥18 / 250GB; with several devices and heavy file traffic, consider ¥28 / 500GB. If your usage is uneven and you would rather not reset on a cycle, data packs start at ¥158 / 300GB — use them until they run out, they never expire — and work well as a top-up.

Take VPNEM as an example: 110+ countries and 210+ routes, unlimited simultaneous devices on a subscription, no email address required, and a 60-day refund window; payment via Alipay, WeChat and USDT. Get split tunneling and routing working on one subscription first, then adjust the tier to your actual usage — steadier than buying a large plan up front.