How traffic flows in Zscaler Internet Access (ZIA) — end to end

What ZIA actually is

Zscaler Internet Access is a cloud-delivered Secure Web Gateway (SWG) — a full forward proxy that also bundles a cloud firewall, DNS security, sandboxing, threat protection, and data loss prevention (DLP). It's the "internet and SaaS" pillar of Zscaler's Security Service Edge (SSE) platform, the Zero Trust Exchange. Its sibling, ZPA, handles private apps.

Instead of buying boxes and stacking them in your data center, you forward traffic to Zscaler's globally distributed cloud — 150+ data centers worldwide — where those security functions run as a service. The defining idea is inline inspection: ZIA is a proxy, not a passive tap. It terminates each connection, examines it, and re-originates it to the destination on the user's behalf. The user never talks to the internet directly — Zscaler does it for them, and nothing reaches the web uninspected. Understand that one detour, hop by hop, and the rest of the platform falls into place.

The journey at a glance

Every step below is a checkpoint a single HTTPS request passes through, in order, on its way out to the internet and back. Forwarding is just the on-ramp; the inspection is where the value is.

Step 1 — Getting traffic to Zscaler (forwarding methods)

Nothing can be inspected until it reaches a Zscaler data center. ZIA supports several forwarding methods, chosen by whether you're steering a roaming laptop, a whole office, or a cloud workload. Most organizations mix and match — but in this lesson they're all just the on-ramp onto the same inspection journey.

• Zscaler Client Connector (ZCC) — a lightweight agent on laptops and phones; the standard for roaming users. It builds a tunnel (the "Z-Tunnel") to the nearest data center. Z-Tunnel 1.0 behaves like a classic proxy, forwarding web traffic (ports 80/443) via HTTP CONNECT — web only. Z-Tunnel 2.0 uses DTLS (UDP/443) or TLS (TCP/443) and carries all ports and protocols — TCP, UDP, ICMP — a true full tunnel and the modern default when you also want the cloud firewall to see non-web traffic.
• PAC files — a Proxy Auto-Config script tells the browser which requests to send to Zscaler and which to send direct. Lightweight and clientless, but browser-scoped — often a fallback alongside the other methods.
• GRE tunnels — Zscaler's recommended method for offices with a static public IP. Low overhead, up to ~1 Gbps per tunnel; deploy two (primary + backup) to the nearest data centers.
• IPSec tunnels — like GRE but encrypted and NAT-friendly (no static IP needed). Each tunnel caps around ~400 Mbps per public source IP, so large sites scale out with multiple tunnels.
• Cloud Connector — a virtual appliance that forwards cloud workload traffic (AWS, Azure, GCP) into ZIA without an endpoint agent.

Step 2 — Reaching the closest Service Edge

Traffic lands on a Zscaler Service Edge — the full-proxy node that does the actual inspection. (You'll see it called the Public Service Edge, formerly the ZEN, or Zscaler Enforcement Node.) These run active-active across 150+ data centers.

The goal is to land each user on the closest, best-performing edge — not just the nearest by map. Zscaler steers traffic using geolocation and real-time latency and load: Client Connector continuously probes candidate edges and fails over to a faster one if it's consistently quicker. So a user in Mumbai hits a Mumbai edge while a colleague in Frankfurt hits one near them — no global backhaul. Crucially, the edge inspects packet data in memory and forwards or drops it; user traffic isn't written to disk.

Step 3 — DNS resolution with DNS Control

When the user requests example.com, DNS happens inside the flow rather than on the local network. With DNS Control, the Service Edge can either resolve the name itself — applying DNS-layer policy, blocking known-malicious domains with geographic context for fast answers — or pass the query through the proxy while hiding the user's real IP. Either way, DNS becomes a policy enforcement point, not just plumbing.

Step 4 — SSL/TLS inspection (the man-in-the-middle step)

Nearly all web traffic is encrypted, so a proxy that can't read TLS is blind. ZIA performs full SSL/TLS inspection by acting as a controlled man-in-the-middle. It's the linchpin every downstream control depends on:

1. The Service Edge terminates the user's TLS session and presents a certificate it dynamically generates and signs with the Zscaler (or your organization's) intermediate CA.
2. It opens a separate, validated TLS session to the real destination.
3. Now sitting between two encrypted legs, it sees the plaintext in the middle — inspects it, then re-encrypts on each side.

For the browser to trust those on-the-fly certificates, the Zscaler root CA must be installed on endpoints (typically pushed via MDM/GPO). Without decryption, malware hiding inside HTTPS and data leaving over TLS would pass invisibly.

Step 5 — Policy enforcement: one scan, many engines (SSMA)

With the traffic decrypted, the Service Edge runs it through ZIA's policy engines. Thanks to Single Scan, Multi-Action (SSMA), the content is scanned once in shared memory while every engine evaluates it in parallel — so adding more security checks doesn't stack up latency. The layers:

If any layer says "block," the request stops and the user gets a notification page instead of the site. Because of SSMA, turning on the fifth engine costs essentially nothing in extra latency over turning on the first.

Step 6 — Egress and the inspected return path

There's no separate return tunnel. The Service Edge holds the destination-side connection, so the server's response comes back to the same edge, is inspected on the way in (malware scanning, sandboxing, DLP on downloads), re-encrypted on the user-facing session, and delivered down the existing tunnel. Inspection is bidirectional — the reply is policed just as thoroughly as the request. The user simply sees a normal HTTPS page load; the entire round trip is invisible.

🔑 Lock in the key terms — tap to flip

The flow at a glance

Reading the journey as a single line: a request is forwarded into Zscaler, lands on the closest Service Edge, is resolved through DNS Control, decrypted with the Zscaler CA, scanned once by the SSMA engines, re-encrypted, and egressed to the internet — then the reply comes back through the same edge, is inspected inbound, and delivered.

  USER / BRANCH          ZSCALER CLOUD · CLOSEST SERVICE EDGE (former ZEN)        INTERNET
  +-----------+  forward  +----------------------------------------------+  egress  +-----------+
  | Endpoint  | ========> | 1. DNS Control                               | =======> | Internet  |
  | ZCC / PAC |  Z-Tunnel | 2. SSL/TLS decrypt (MITM, Zscaler CA)        |  new TLS | / SaaS    |
  | GRE/IPSec |           | 3. SSMA: Firewall|URL|Threat|Sandbox|DLP     | <======= | example.. |
  +-----------+ <======== | 4. Re-encrypt -> egress                      | inspect  +-----------+
        inspected, re-encrypted reply   (inspected in memory; not on disk)   reply

How this differs from hub-and-spoke backhauling

Legacy networks backhaul branch traffic over MPLS/VPN to a central data center, run it through a stack of appliances, then hairpin it out to the internet — and back again. That "trombone" effect is slow, expensive, and hard to scale:

• Latency — a user two miles from a SaaS app is forced through HQ thousands of miles away.
• Cost — expensive MPLS circuits plus appliance refresh cycles.
• Scaling — capacity is bounded by the biggest box you bought.

ZIA flips the model. Each user and office connects to the nearest cloud edge and breaks out to the internet locally, while every connection — HQ, branch, or coffee shop — gets identical inline inspection. Security scales elastically in the cloud and follows the user's identity, not their network location. Local breakout, global policy.

Things that quietly break the flow