What Is Zscaler Client Connector? A Plain-English Guide
.jpeg)
Quick answer: Zscaler Client Connector is the endpoint agent that forwards a device's traffic into the Zscaler cloud. It runs on Windows, macOS, Linux, iOS, and Android, authenticates the user against your identity provider, and then decides, per network and per application, whether to send traffic to Zscaler Internet Access (ZIA) for internet and SaaS inspection or to Zscaler Private Access (ZPA) for internal applications. It was previously called Zscaler App, or Z App, and admins manage it from the Zscaler Client Connector Portal.
New here? If you're new to this category generally, start with what a secure web gateway is, then come back.
What Zscaler Client Connector actually does
Think of Zscaler Client Connector as a traffic director that lives on the laptop.
Zscaler's architecture is cloud-first. Policy, inspection, and logging happen in Zscaler's own data centers, which Zscaler calls Service Edges (the older name, ZEN, for Zscaler Enforcement Node, still shows up in documentation and in support tickets). For any of that to apply to a user, the user's traffic has to get there.
Client Connector is how it gets there. Without it, a device only reaches Zscaler if you've configured a GRE or IPSec tunnel from the office router, or a PAC file in the browser. Neither of those follows a person to an airport lounge.
So the agent does four jobs. It identifies the user. It figures out what network the device is on. It decides which traffic to forward and where. And it maintains the tunnel that carries it.
How Zscaler Client Connector authenticates a user
Enrollment starts with identity. The agent sends the user to your identity provider (Okta, Entra ID, Ping, whatever you run) over SAML, the IdP authenticates them, and Zscaler issues the device a token tied to that user.
This matters more than it sounds. Every policy Zscaler enforces afterward is attached to that identity, including group and department membership synced from your directory. If enrollment fails, the user doesn't get "no policy," they usually get a very blunt default policy, which is why a broken IdP integration shows up as mass complaints rather than silence.
Admins can configure whether users are allowed to log out of the app at all, and whether logging out or uninstalling requires a password. Most enterprises lock both.
Trusted networks and forwarding profiles
Here's the concept that trips up most new Zscaler admins, so it's worth slowing down.
A trusted network is a definition you write that tells the agent "this is a corporate network." Zscaler evaluates it using signals like the DNS servers the device received, DNS search domains, and whether a specific internal hostname resolves to an expected address. You can define several.
A forwarding profile then says what the agent should do in each of three situations: on a trusted network, off a trusted network, and connected to a VPN that reaches a trusted network. For each, you pick a forwarding method.
The common forwarding methods:
- Tunnel (Z-Tunnel 1.0). Forwards web traffic on ports 80 and 443 to the Zscaler cloud. Lightweight, widely deployed, but it only handles HTTP and HTTPS.
- Tunnel with Local Proxy. Similar, but the agent presents a local proxy and sets the system proxy settings, which helps applications that respect proxy configuration.
- Packet Filter Based / Z-Tunnel 2.0. Carries all ports and protocols, not just web, using a DTLS or TLS tunnel. This is what you need for non-web traffic.
- Enforce Proxy. Uses the system proxy configuration you've already set.
- None. The agent doesn't forward that category of traffic at all.
A typical setup forwards everything when the user is off network, and forwards nothing when the user is in an office where a GRE or IPSec tunnel already carries traffic to Zscaler. That avoids double-tunneling the same packets.
App profiles and PAC files
An app profile bundles the settings that apply to a group of users: which forwarding profile to use, which PAC files to apply, whether ZPA is enabled, logging behavior, notification behavior, and update policy.
PAC files still do real work here. Zscaler uses two kinds. The forwarding PAC tells the agent what to send to Zscaler and what to let go direct. The application PAC (or proxy PAC) tells Zscaler which Service Edge node to use. Most bypass lists you'll ever write end up in one of these two files.
Update policy deserves a mention. You can pin the agent to a specific version, allow automatic updates, or stage rollouts by group. Pinning is common in regulated environments and is also a frequent root cause of "it works on my machine" support tickets when two groups run different builds.
How ZIA and ZPA fit together
ZIA and ZPA are separate products that share the same agent.
ZIA handles outbound internet and SaaS. Traffic goes from the device, through the tunnel, to a Zscaler Service Edge, where URL filtering, SSL inspection, antivirus, sandboxing, CASB, and DLP policies run. Then the Service Edge makes the request to the destination on the user's behalf and sends the response back down the tunnel.
ZPA handles private applications. Instead of a VPN putting the device on your network, the agent creates a microtunnel to a ZPA Service Edge, which brokers a connection to an App Connector you've deployed next to the application. The user reaches the app. The user never reaches the network.
The agent decides which path a request takes using ZPA's application segments and the forwarding PAC. Overlap between the two, for example an internal hostname that also resolves publicly, is a classic source of confusing behavior.
What SSL inspection requires
Zscaler can only apply meaningful policy to encrypted traffic if it decrypts it, and roughly 95% of web traffic is encrypted. Decryption means Zscaler presents its own certificate to the client, so the Zscaler root certificate has to be trusted on every device. You either push Zscaler's certificate through MDM or use your own intermediate CA.
Two things then need attention. First, applications with their own certificate stores (many developer tools, some VPN clients, several installers) will fail until you add the certificate to that store or bypass the app. Second, certificate-pinned applications reject any substituted certificate by design, so Zscaler can't inspect them at all. Microsoft 365, WebEx, and Dropbox are the commonly cited examples, and the standard practice is to bypass them.
System requirements at a high level
Client Connector runs on Windows, macOS, Linux, iOS, and Android. A few practical points:
- Installation needs administrative rights, so real deployments go through Intune, Jamf, Workspace ONE, or similar.
- macOS requires approving a system extension and granting the app the permissions macOS asks for. Push those approvals by MDM configuration profile ahead of the install, or every user gets a scary prompt.
- The Zscaler root certificate has to be in the trusted store before SSL inspection turns on, not after.
- Reachability to Zscaler's cloud on the relevant ports is required, which is why guest Wi-Fi with captive portals causes so much trouble.
- Zscaler Digital Experience (ZDX) telemetry ships in the same agent when licensed.
For the Zscaler Client Connector download itself, pull binaries from your own Zscaler tenant's admin portal rather than a third-party mirror, since the installer is tied to your cloud instance.
What admins configure day to day
In the Zscaler Client Connector Portal, the recurring work is:
- App profiles per user group.
- Forwarding profiles and trusted network definitions.
- PAC files and bypass lists.
- Agent version and update rings.
- Logout, disable, and uninstall password enforcement.
- Notification text users see when something is blocked.
- Device posture rules, if you're gating ZPA access on posture.
- Log collection settings for support cases.
The architectural tradeoff, honestly
Now the part that isn't in the documentation.
Client Connector is a very capable forwarder, and that's exactly what it is: a forwarder. Every request it handles travels to a Service Edge node before it reaches its destination. That detour is the architecture, not a bug, and it has consequences you can measure.
Measured cloud-proxy latency runs roughly 40 to 80 ms when a user sits near a point of presence and 150 to 400 ms when they don't. Gartner has cited a 10-20% throughput drop on cloud proxies as inspection modules stack, so enabling more policy costs more performance. China Premium and Plus are paid uplifts for users in restricted geographies. And cert-pinned applications, including some of the ones your company uses most, can't be inspected at all.
There's also a dependency question. On October 25, 2022, a Zscaler outage produced 100% packet loss. When the inspection point is the only path to the internet, its availability becomes your availability.
What an on-device agent does differently
The alternative isn't going back to a firewall. It's moving the proxy to where the traffic already is.
dope.security runs an SSL proxy on the endpoint itself in dope.SWG. It decrypts, inspects, and applies policy locally, then the request goes straight to its destination. We call it Fly Direct, because the traffic doesn't make a pit stop. URL filtering, SSL inspection, Cloud App Control, anti-malware, analytics, and Dopamine DLP all run on the device, in under 100 MB of RAM, with up to 4x the performance of legacy proxy SWGs.
Because there's no node in the middle, there's no distance penalty and no paid uplift for China. Policy pushes instantly to all devices regardless of location, and fallback mode keeps cached policies enforcing if connectivity drops. Pricing is public at $60 per device per year.
Greylock Partners took 27 days from first proposal to signed contract. Another customer migrated 2,000 machines off Cisco Umbrella in two days.
If you want to see the difference on your own traffic, book a 20-minute demo at calendly.com/dopesecurity/demo, or start a free trial with Google or Microsoft sign-in.
Frequently Asked Questions
What is Zscaler Client Connector?
Zscaler Client Connector is Zscaler's endpoint agent, formerly called Zscaler App. It authenticates the user against your identity provider and forwards device traffic into the Zscaler cloud, sending internet and SaaS traffic to Zscaler Internet Access and private application traffic to Zscaler Private Access.
Is Zscaler Client Connector a VPN?
Not in the traditional sense. It builds tunnels, but for ZIA it forwards traffic to an inspection node rather than placing the device on a corporate network. For ZPA it brokers per-application microtunnels, so the user reaches a specific application without being given network-level access.
What is the difference between Z-Tunnel 1.0 and 2.0?
Z-Tunnel 1.0 forwards only HTTP and HTTPS traffic on ports 80 and 443. Z-Tunnel 2.0 uses a DTLS or TLS tunnel and carries all ports and protocols, which is what you need when non-web applications must be inspected or routed through Zscaler.
Where do I get the Zscaler Client Connector download?
Download the installer from your own organization's Zscaler admin portal, because packages are tied to your cloud instance and enrollment settings. In production, deploy it through Intune, Jamf, or Workspace ONE rather than having users install it manually, since installation requires administrative rights.
Why does Zscaler need a root certificate installed?
Because SSL inspection requires decrypting traffic. Zscaler presents its own certificate to the client, so devices must trust the Zscaler root or your intermediate CA. Applications with their own certificate stores need the certificate added separately, and certificate-pinned apps reject substitution entirely.
Which applications can Zscaler Client Connector not inspect?
Certificate-pinned applications reject any substituted certificate, so they can't be inspected. Microsoft 365, WebEx, and Dropbox are the most commonly cited examples, and standard practice is to add them to a bypass list rather than attempt inspection.
Does Zscaler Client Connector add latency?
Yes, because every request forwards to a Service Edge node before reaching its destination. Measured cloud-proxy latency runs roughly 40 to 80 ms near a point of presence and 150 to 400 ms when users are far from one, and Gartner has cited a 10-20% throughput drop as inspection modules stack.
What's the alternative to a forwarding agent like Zscaler Client Connector?
An on-device agent that inspects locally instead of forwarding. dope.security runs the SSL proxy on the endpoint, so traffic goes straight to its destination with no intermediate node, delivering up to 4x the performance of legacy proxy SWGs in under 100 MB of RAM at $60 per device per year.
.jpeg)
.jpeg)
