Zscaler doesn't work at your China sites. Here's why, and what does.

Somewhere in your environment there's a site, or two, or three, where the secure web gateway "never really worked." Usually it's in China. Sometimes it's a plant, sometimes a sourcing office, sometimes a team of eight people who've been told to just use the local network and hope.

Nobody wrote it down as a policy exception. It just became the way things are. The SWG vendor's answer was some combination of a local PoP, a dedicated tunnel, and a support ticket that closed without a fix.

Here's why it keeps happening, and why the fix isn't another tunnel.

The detour is the problem

Zscaler ZIA, like every cloud-proxy SWG, works by routing your traffic to one of its data centers before it reaches the internet. (If the proxy model is new to you, secure web gateway vs proxy covers the basics.) The agent on the laptop forwards every request to the nearest Zscaler node, which decrypts it, inspects it, re-encrypts it, and sends it on.

That model assumes the path from the laptop to the data center is fast and open. Inside China it's neither.

Cross-border traffic is subject to inspection, throttling, and unpredictable routing at the national gateway. A tunnel to a proxy node outside the country is exactly the kind of traffic that gets slowed or dropped. A proxy node inside the country has to comply with local requirements and still has to reach the global internet through the same gateway. Either way, your users' every request now depends on the one network path that's least reliable.

The result is what your China team already knows: pages time out, SaaS apps hang, the agent flips into some fallback mode, and eventually someone turns it off. The "three sites where it never worked" aren't an edge case. They're the architecture doing what it was designed to do, in a place it wasn't designed for.

Why a local PoP doesn't fix it

The usual vendor answer is to add capacity closer to the user. It helps at the margin and fails at the core.

The detour still exists. Traffic still leaves the device, goes to a data center, and comes back. Whether that data center is in Hong Kong or Shanghai, you've added a hop that has to cross the same contested network path twice.

The outage exposure still exists. When a cloud-proxy data center degrades, traffic fails over to another region, often one that's already congested. In China, "fail over to another region" means "fail over across the border."

And the data residency question gets harder, not easier. Your traffic is now being decrypted and inspected in infrastructure you don't control, in a jurisdiction with its own rules about what can be inspected and stored.

Here's the difference for a user sitting in a China office.

What changes when inspection is on the device

dope.security does the same SSL inspection, URL filtering, cloud app control, and DLP that a proxy does. It just does it on the laptop, before the traffic ever leaves. There's no data center to reach, so there's no tunnel to throttle, no cross-border hop to drop, and no regional node to fail over from.

For a user in a China office, that means three things.

The security policy is the same policy as everywhere else. Same categories, same cloud app controls, same DLP on uploads. Not a watered-down "China profile."

Browsing is as fast as the local network allows. The agent adds no detour. It's under 100 MB of RAM and up to 4x faster than a legacy proxy because it isn't routing anything anywhere.

Decrypted traffic stays on the device. Only transaction metadata goes to the cloud for logging and analytics. Nothing is decrypted in a third-party data center, in any jurisdiction.

One of our customers running across restricted regions put it plainly: dope.security is the only SWG and CASB that works for them in China. That's not a tuning achievement. It's a consequence of not having a stopover. The broader case for that architecture is in endpoint-based SWG vs cloud proxy SWG, and the Zscaler-specific comparison is on Zscaler vs dope.security.

What to actually test

If you've got a China site, don't take anyone's word for it, including ours. Put the agent on three machines there and run the same checks you'd run anywhere:

Load a handful of your core SaaS apps with SSL inspection on and time them against the current setup.

Push a policy change from the console and confirm it lands on the China devices within a minute.

Upload a file containing test PII to a personal cloud drive and confirm DLP catches it.

Confirm events from those devices arrive in your SIEM in real time.

If it works on those three laptops, it works on the site. There's no regional capacity to provision, no tunnel to stand up, and no second architecture to maintain for the "difficult" locations.

The sites you've been ignoring are the easiest ones to fix

Teams tend to leave the China problem for last because it feels like the hardest one. It's usually the opposite. The sites where the proxy never worked are the clearest demonstration of why the detour was always the issue, and they're the fastest places to see the difference.

Start there. If the gateway works in the place your current one never did, the rest of the fleet is easy. The three-week pilot checklist has the rest of the test plan, and if a renewal is the forcing function, the 90-day Zscaler switch plan is where to go next.

Try it on your China devices today. Sign in at dope.security with your corporate account, or book a 20-minute call and tell us where the proxy fails.