Zscaler ZIA Architecture, Explained: How Traffic Actually Flows
.jpeg)
Zscaler ZIA is a cloud proxy architecture with three layers. A control plane holds your policy and user identity. Enforcement nodes in Zscaler data centers decrypt and inspect traffic. A logging layer stores the transaction records. Your traffic has to be forwarded to an enforcement node before any of it works, which is where most of the deployment effort goes.
What are the components of ZIA architecture?
| Layer | Zscaler's name | What it does |
|---|---|---|
| Control plane | Central Authority | Stores policy and configuration, authenticates users, tells enforcement nodes what to apply |
| Enforcement | ZIA Public Service Edges | Proxies the connection, decrypts SSL, applies policy, scans content |
| Logging | Nanolog | Stores and streams transaction logs for reporting and SIEM |
The enforcement layer is the one your users feel. Every request terminates there, gets inspected, and then gets a new connection out to the destination.
How does traffic get to Zscaler?
You have four main options, and most enterprises run more than one.
- Zscaler Client Connector. An agent on the laptop that tunnels traffic to the nearest enforcement node. This is how remote users are covered. More in our Client Connector guide.
- GRE tunnels. From an office router or firewall to Zscaler. Needs a static public IP.
- IPsec tunnels. Same idea, encrypted, for sites that can't use GRE.
- PAC files. A browser-level file that points web traffic at Zscaler. Simple, but browser-only.
Each method needs its own design, failover plan, and troubleshooting path. That's the hidden work in a ZIA rollout.
What happens to a single request?
- The user opens a site.
- The agent or tunnel forwards the request to a Zscaler data center.
- The enforcement node checks identity and policy with the control plane.
- It decrypts the session, inspects it, and logs it.
- It opens a new connection to the destination and relays the response back.
Steps 2 and 5 are the stopover. A cloud proxy typically adds 40 to 80 ms when the user is near a point of presence and 150 to 400 ms when they're far from one.
Where does ZIA's architecture break down?
- Distance. The detour is short in Virginia and long in places without a nearby data center.
- Shared fate. If the node or the path to it has a bad day, every user routed through it has one too. Then you choose: fail open and allow everything, or fail closed and block everything.
- China. Traffic has to cross the Great Firewall to reach inspection. Zscaler sells mainland coverage as a paid uplift.
- Complexity. Four forwarding methods means four things to design, monitor, and fix.
ZIA architecture vs on-device architecture
| Zscaler ZIA | dope.security | |
|---|---|---|
| Proxy location | Zscaler data center | The endpoint itself |
| Forwarding setup | Agent, GRE, IPsec, or PAC | Agent only, pushed through MDM |
| SSL decryption | In the cloud | On the device, data never leaves it |
| Path to destination | Via Zscaler | Direct |
| Policy updates | Cloud-side | Pushed to endpoints in seconds |
| Cloud outage behavior | Fail open or fail closed | Fallback mode enforces cached policy |
| Coverage | Any device that can forward traffic | Managed Mac and Windows |
dope.security collapses the enforcement layer into the endpoint. dope.endpoint is the proxy: an on-device HTTP/2 SSL proxy that handles URL filtering, Cloud Application Control, and a local URL category cache. It uses less than 100 MB of RAM and sends traffic straight to the destination. dope.cloud handles policy, categorization, malware verdicts, analytics, and agent auto-updates, and keeps a real-time connection to every endpoint.
Two details matter in practice. Policy changes push to endpoints in seconds instead of waiting on a polling cycle. And if an endpoint can't reach dope.cloud, it drops into Fallback Mode and keeps enforcing the policies cached on the device, so users stay protected instead of failing wide open.
Running at the OS level has a side benefit for AI tools. Policy applies to desktop apps as well as the browser, so Cloud Application Control can restrict Claude to your approved enterprise organization ID in both the web app and the desktop app, with no dependency on corporate network routing.
The trade-off: an agent only protects devices it's installed on. Guest Wi-Fi, IoT, and unmanaged devices need another control.
It deploys fast because there are no tunnels to build. A Fortune 100 company scaled from 900 to more than 18,000 devices in weeks, at about 3,000 devices per week, pushing the agent silently through Intune.
Frequently asked questions
Is Zscaler ZIA a forward proxy?
Yes. ZIA is a cloud-hosted forward proxy. It terminates the client connection, inspects the traffic, and opens a separate connection to the destination.
What is a ZIA Public Service Edge?
It's the enforcement node in a Zscaler data center that proxies and inspects your traffic. Older Zscaler material calls it a ZEN, short for Zscaler Enforcement Node.
What is the Zscaler Central Authority?
The control plane. It holds policy, configuration, and user identity, and directs the enforcement nodes.
Does ZIA need an agent?
Not always. Offices can forward traffic with GRE, IPsec, or PAC files. Remote users need Zscaler Client Connector.
How is on-device SWG architecture different?
The proxy runs on the laptop instead of in a data center, so there's nothing to forward traffic to and no detour.
Skip the stopover
See how Fly Direct works in dope.SWG, or book a 20-minute demo.
.jpeg)
.jpeg)
.jpeg)
