Why Some VPNs Make China Routing Worse, Not Better, for Business Traffic

When a service performs badly for users in China, “put it behind a VPN” comes up almost immediately. It’s the tool most people associate with China’s internet, so the suggestion feels natural.

For business traffic, it usually makes things worse. Not marginally worse either: adding a VPN hop to a China-facing production path frequently increases latency, adds packet loss, and introduces a failure mode that’s harder to diagnose than the problem it was meant to solve.

The reason comes down to a mismatch between what a VPN is built for and what a business needs, so it’s worth walking through what actually happens to your traffic.

Why people reach for a VPN in the first place

For an individual inside China trying to reach a blocked site, a VPN does something genuinely useful. It wraps traffic in an encrypted tunnel to a server outside the country, and the content filtering that would have blocked the destination can’t read what’s inside the tunnel.

That mental model gets carried into a different problem without much examination. Serving a service reliably to users inside China is not the same task as one person occasionally reaching a blocked website from inside China, and the tool that solves the second one isn’t designed for the first.

The distinction matters because the two use cases have opposite tolerances. A person circumventing a block will accept slow and unreliable, because slow beats blocked. A business serving thousands of users needs consistent and predictable, which is precisely what a VPN hop erodes.

What a VPN actually does to your route

Start with geometry. A VPN routes traffic through an intermediate server, which means the packet’s physical path gets longer, not shorter. If your server is in Tokyo, your user is in Shanghai, and the VPN endpoint is in Los Angeles, you’ve added a Pacific crossing in each direction to a route that didn’t need one.

Then there’s the quality of the infrastructure itself. General-purpose VPN providers aren’t buying premium carrier paths into China; they’re running on ordinary transit, often oversubscribed, because their product is measured on server count and price rather than on route quality to one specific country. Traffic that would otherwise ride a premium path like CTGNet, CUP, or CMIN2 instead rides whatever generic transit the VPN provider happens to have.

The third factor is the most consequential, and it works against tunnels from two directions at once. Older, widely deployed VPN protocols have recognizable handshake patterns that filtering infrastructure can match directly. Newer protocols that avoid that by looking like pure random data run into the opposite test: published research on how the Great Firewall identifies fully encrypted traffic found it applies fairly crude heuristics that exempt traffic resembling a recognized protocol and act on much of what’s left, which is exactly where a fully encrypted tunnel sits. The result isn’t a clean tunnel that gets through; it’s a tunnel that intermittently gets throttled, degraded, or reset, specifically because it’s identifiable as a VPN. Your traffic ends up worse off than unremarkable traffic on a good route would have been.

Where this actually bites business traffic

The workloads that suffer most are the ones with no tolerance for variance. API calls with client-side timeouts, database replication that falls behind and then has to catch up, payment callbacks that expect a response inside a fixed window, and real-time features like chat or live updates all degrade visibly when the path underneath them is inconsistent.

It also produces a support problem. When a VPN hop is in the path, intermittent failures come with no clear signal about where they originated, so your team spends time investigating an application that’s working correctly. Removing an unnecessary tunnel often does more for diagnosability than any amount of additional monitoring.

There’s a compounding effect worth naming too. Because the VPN adds latency, every retransmission costs more than it would on a direct route, so the packet loss the VPN introduced is more expensive to recover from than the same loss would have been without it.

When a VPN does make sense

None of this makes VPNs useless in a China context. It makes them the wrong tool for public service delivery.

A site-to-site VPN connecting your own offices or internal infrastructure is a reasonable use: the traffic volume is modest, the participants are known, and a private encrypted link between two of your own locations is exactly what the technology is for. Internal administrative access for your own team falls into the same category, as does an emergency fallback path you keep available but don’t route production traffic through.

The dividing line is whether the traffic belongs to your users or to your own operations. Internal, low-volume, and security-motivated points toward a VPN being fine. Public, continuous, and latency-sensitive points away from it.

What actually helps instead

For business traffic reaching mainland China, the thing that works is carrier-optimized routing that covers the carriers your users are actually on, which for any sizeable user base usually means all three rather than one. Keeping traffic on China Telecom’s, China Unicom’s, or China Mobile’s own premium backbone for a longer stretch of the path removes congested handoffs rather than adding an extra one.

Riven Cloud runs premium paths on all three: CTGNet on China Telecom (AS23764 and AS4809), CUP on China Unicom (AS9929 and AS10099), and CMIN2 on China Mobile (AS58807). Naming them matters because it’s what makes the claim checkable rather than aspirational.

The other half is verification. Every location has a public Looking Glass for ping, traceroute, and BGP lookups, so you can compare a real route against whatever you’re running today before changing anything. One caveat worth stating plainly: a Looking Glass reading reflects a single moment, not a guarantee of day-to-day performance, so test more than once and at more than one time of day.

Wrapping up

A VPN’s strength is getting an individual around a block. It was never designed to deliver consistent, low-latency service to a user base, and in China specifically it’s actively penalized by the filtering it’s meant to evade.

If users in China are having a bad time with your service, the productive move is checking whether your server’s route to their carrier is any good, not wrapping a bad route in a tunnel and hoping the encryption compensates.

Thanks for reading! Whether you’re testing through a tunnel or serving users directly, the carrier path underneath matters more than the software layered on top of it. If you’re looking for China routing you can verify yourself rather than take on faith, Riven Cloud runs KVM VPS in Tokyo and Singapore with all three named premium paths on every plan: CTGNet on China Telecom, CUP on China Unicom, and CMIN2 on China Mobile, each testable through a public Looking Glass before you buy.

Ready to see the numbers for your own traffic? Deploy a server or contact our team with questions.

Frequently asked questions about VPNs and China routing

Does a VPN always make China routing worse?

Not in every configuration, but for business traffic serving users in China it usually does. You’re adding physical distance, riding generic transit instead of a premium carrier path, and running a protocol that border filtering specifically looks for.

Why does China’s border filtering target VPN traffic specifically?

Older VPN protocols carry recognizable handshakes that can be matched directly. Newer ones that look like random data get caught by the inverse test, since traffic resembling no known protocol is itself treated as suspect. Either way the tunnel stands out from ordinary traffic, even when what’s inside it is entirely unremarkable.

Is a business VPN different from a consumer VPN in this context?

The underlying mechanics are the same. What differs is the expectation: a consumer tolerates instability because the alternative is no access, while a business serving users needs consistency that a tunneled path across an inspected border doesn’t reliably provide.

What should I use instead of a VPN for a China-facing service?

A carrier-optimized route on a named premium path, matched to the carrier your users actually use. CTGNet, CUP, and CMIN2 exist precisely because each of the three Chinese carriers runs a separate network with its own congestion points.

Is it ever appropriate to use a VPN alongside China-optimized hosting?

Yes, for internal use. Connecting your own offices, giving your team administrative access, or keeping a fallback path available are all reasonable. The distinction is that these are your own low-volume operational needs rather than the path your users’ traffic takes.

How can I tell if a VPN is actually hurting my China route’s performance?

Run the same traceroute and sustained ping test with and without the tunnel, at similar times of day, and compare latency, jitter, and loss. If the tunneled path is meaningfully worse across those three, you have your answer without needing to theorize about why.