Does Zscaler Work in China? Why Backhauled SSE Struggles Behind the Great Firewall

If you run security for a company with people in China, you already know the pattern. A laptop that works perfectly in London or Austin turns sluggish the moment it lands in Shanghai. Pages hang. Uploads stall. The help desk fills with tickets that all say some version of "the internet is broken here." When the stack includes Zscaler, the cause is usually not a misconfiguration. It is the architecture. Zscaler inspects traffic by routing it through its global cloud, and getting that traffic in and out of China means crossing the Great Firewall to reach an enforcement node and back.

This is a specific, in-country problem that the broader complete guide to replacing Zscaler touches on but does not fully unpack, so it is worth its own look. The short version of the broader case lives in why teams are replacing Zscaler in 2026, where the backhaul tax is one of five recurring themes. In China, that tax is not a few milliseconds. It is the difference between a working laptop and a broken one.

Short answer: Zscaler struggles for users physically inside China because its cloud proxy model backhauls traffic across the Great Firewall to reach an enforcement node, which adds latency, packet loss, and connectivity failures. dope.security inspects traffic on the device and flies direct, so enforcement does not depend on crossing a controlled network boundary to reach a distant data center.

Why backhauling and the Great Firewall do not mix

The cloud proxy model has one defining move: send user traffic to a vendor enforcement node, inspect it there, then forward it on. Inside most countries that detour is invisible because a node is close by. China is different. The government tightly regulates and filters cross-border internet traffic, and it is especially aggressive toward encrypted connections and anything that looks like a tunnel back to foreign infrastructure. A backhauled SWG depends on exactly that kind of connection. Traffic has to leave China, cross the firewall to reach the inspection node, and come back, twice for every request and response.

The result is the trifecta of pain that anyone supporting China users recognizes: high latency, packet loss, and intermittent failures when the firewall throttles or drops the cross-border session. We laid out the regulatory and architectural reasons in detail in why Zscaler, Netskope, and Forcepoint struggle in China. None of it is a knock on the engineering. It is what happens when a model built on a distant inspection hub meets a network boundary built to interfere with distant hubs.

Local data centers are not a clean fix

The obvious counter is to put an inspection node inside China. In practice that is its own project. Operating infrastructure in-country means complying with Chinese data and licensing requirements, often through a local partner, and even then the cross-border traffic for users connecting to anything hosted outside China still has to cross the firewall. You have moved the problem, not removed it. For a mid-market or enterprise team that just wants laptops to work, standing up and maintaining a compliant in-country presence to prop up a backhaul model is a heavy answer to a question that an on-device model never asks.

How Fly Direct sidesteps the boundary

dope.security puts the inspection on the device. The agent decrypts TLS locally, applies your policy, and sends traffic straight to its destination. There is no enforcement node in the path, which means there is no mandatory cross-border round trip to a foreign data center just to apply a URL filter or a DLP rule. A laptop in China inspecting its own traffic locally and then connecting directly to where it is going avoids the single most fragile step in the backhaul model. This is the same on-device approach we describe in on-device TLS inspection, applied to the hardest geography for cloud proxies.

Requirement for China users	Zscaler (cloud proxy)	dope.security (endpoint SWG)
Crosses the Great Firewall to inspect	Yes, to reach a node	No, inspects on the device
Latency for in-country users	High, cross-border round trip	Minimal, local inspection
Exposure to firewall throttling and drops	Yes, depends on the tunnel	Low, no mandatory tunnel to a hub
Where plaintext is decrypted	In the vendor cloud	On the endpoint, stays local
In-country infrastructure required	Often, to reduce pain	None, agent runs on the laptop
Endpoint footprint	Connector and tunnels	Under 100 MB RAM

You keep the controls, you lose the detour

The fear in leaving a cloud proxy is losing inspection depth. You do not. dope.security decrypts and inspects SSL on the device, so you keep full URL filtering and decrypted content visibility. Dopamine DLP intercepts file uploads and AI prompts and classifies them through zero-retention APIs under US Patent 12,464,023, so a sensitive file does not leave on the way to a personal Drive whether the user is in Boston or Beijing. Cloud Application Control restricts SaaS access to your corporate tenants, so people use the enterprise ChatGPT or Microsoft 365 account and not a personal one. All of it runs through one console, dope.console, and the agent runs in under 100 MB of RAM. The controls are the same. The geography stops being a problem. And because policy is still centralized in one console even though inspection is decentralized to each device, you do not trade away management simplicity to gain the in-country performance. You set policy once and it pushes to every agent in seconds, in Shanghai exactly as in San Francisco.

Speed and privacy come along for free

Removing the detour is not only a China story. dope.security runs 4x faster than legacy proxy SWGs everywhere, because there is no round trip to an enforcement node on any request. On-device decryption is also the cleaner data-residency position: traffic is inspected where the data already lives instead of being routed through a third-party data center to be read, which matters under China's data sovereignty rules and matters to any privacy-conscious organization. The full economic and architectural picture is in the no-backhaul Zscaler replacement case, and the line-item side shows up in Zscaler pricing in 2026.

What the China problem really tells you about your architecture

China is the extreme case, but it is a useful one because it exposes an assumption the rest of the year hides. A backhauled SWG assumes the path between a user and a vendor inspection node is always cheap, reliable, and politically unremarkable. Most of the time, inside most countries, that assumption holds well enough that nobody questions it. China removes the assumption entirely. The path is expensive, unreliable, and actively interfered with, and suddenly the architecture that felt invisible becomes the whole problem.

If your model breaks the moment the network path gets hostile, the model was always carrying that fragility, you just were not paying for it yet. Travelers hitting congested links, users on bad hotel Wi-Fi, and teams in other restricted or distant regions all pay smaller versions of the same tax. Solving for China by inspecting on the device happens to solve for all of them, because none of them depend on a clean path to a distant hub anymore. That is the quiet benefit of removing the detour: you stop having a list of geographies and network conditions where security and usability are in tension.

Proof it deploys without a forwarding project

Because the agent is the gateway, there is no tunnel mesh to build before users in any region are protected. A Fortune 100 company runs the dope.security agent on more than 18,000 devices, and Greylock Partners, a distributed device-first firm, went from first proposal to signed contract in 27 days after leaving a legacy DNS-and-proxy setup, detailed in the Greylock customer story. When enforcement lives on the device, a laptop is protected the same way whether it boots up in New York or Nanjing, with no node proximity to engineer.

Does Zscaler work in China?

Does Zscaler work in China? It can be made to function, but users in China commonly experience high latency, packet loss, and intermittent failures because the cloud proxy model backhauls traffic across the Great Firewall to reach an inspection node. Many teams stand up in-country infrastructure to reduce the pain, which adds cost and complexity.

Why is a cloud proxy SWG slow in China? Because inspection happens at a node outside the user's immediate network, traffic has to cross the controlled cross-border boundary to be inspected and come back, and the firewall throttles or drops exactly that kind of encrypted cross-border session.

What is the best SWG for users in China? An agent-based endpoint SWG that inspects on the device, like dope.security, because it does not depend on crossing the firewall to reach a distant enforcement node. Traffic flies direct after local inspection.

Do I lose DLP or AI governance by switching? No. dope.security includes Dopamine DLP and three-layer AI governance through Cloud Application Control, all on the device and under one console.

The bottom line

The question is not really whether Zscaler can be coaxed into working in China. It is whether your security model should depend on getting traffic across one of the most restrictive network boundaries in the world just to inspect it. Backhauling makes the Great Firewall your problem on every request. Inspecting on the device makes it irrelevant, because nothing has to leave the country and come back to enforce policy. If you support users in China and the cross-border detour is your daily tax, an agent-based gateway removes the cause rather than nursing the symptom. Read the complete guide to replacing Zscaler, compare the field in the Zscaler alternatives comparison, see how Fly Direct secure web gateway inspects on the device, and book a 20-minute demo.