What are ZCC Logs?
ZCC Logs are the local log files of the Zscaler Client Connector (ZCC) on the endpoint. They document what the client does: user sign-in, fetching the profile and PAC file, building tunnels to the Zscaler services, and every error state along the way. That makes them the most important data source when a single device has connection problems that cannot be pinned down to either the Wi-Fi or the Zscaler cloud. The client comes with an export feature that bundles the logs into a package; the admin controls the level of detail through the log mode in the app profile.
ZCC Logs in detail
The Client Connector writes its logs continuously on the device. How detailed they are depends on the log mode: it is set per app profile, and the Client Connector Portal also has a global default in the platform settings. In normal operation, the mode stays lean; for targeted troubleshooting, it is temporarily raised so that details such as individual connection attempts become visible.
The logs reach evaluation by two routes from the device: the user or the helpdesk exports the log package directly from the app, or the admin turns on automatic submission of system info and logs. Typical findings in practice: authentication loops, failed tunnel setup, problems loading the PAC File, DNS errors, certificate messages from SSL Inspection, and failed posture checks.
Why ZCC Logs matter in Zscaler operations
With client problems, the question is rarely whether data exists, but who can read it. The raw log package is extensive and demands experience: which line is a genuine error, and which is just noise? Without that experience, every exported package ends up with a Zscaler specialist or in a support ticket, and a five-minute finding turns into a case that runs over several days.
There is also the data protection side: client logs contain personal data such as usernames and destinations visited. Export, sharing and retention therefore belong in a defined process with limited access and a clear deletion deadline. Get both right, and ZCC Logs become the fastest diagnostic route for individual devices: the finding emerges at the device, with nobody needing to search the Zscaler console. For how an uploaded log package turns into a severity-sorted list of findings in under three minutes, watch our video on this.
Common sources of error
- Log mode permanently on the highest level: the logs grow unnecessarily, and relevant errors get lost in the noise.
- Exporting with no time reference: if the problem happened days ago, the relevant section may already be overwritten. Reproduce first, then export.
- Passing on raw data unfiltered: without a first pass, the interpretation work lands with the next team, and the ticket takes longer.
- Ignoring data protection: sharing log packages containing personal data with no rules, or keeping them indefinitely.
ZCC Logs in practice: what CentaurNexus contributes
With Log Analyzer, the helpdesk evaluates exported ZCC log packages directly in CentaurNexus, with no Zscaler admin rights and no need to read raw lines. The package is uploaded, Log Analyzer sorts the findings by severity and translates them into plain language: tunnel errors, DNS problems, PAC errors, authentication loops, posture and SSL messages, each with a recommendation for the next step. That keeps first diagnosis at 1st Level, and only genuine special cases move on. For how that answers the question “Is it Zscaler or the Wi-Fi?” in minutes, see the guide Is it Zscaler or the Wi-Fi?.
Related terms
Frequently asked questions about ZCC Logs
The Zscaler Client Connector comes with an export feature that bundles the local logs into a package. The user or the helpdesk saves this package and passes it on for evaluation. Admins can also turn on automatic submission of system info and logs in the Client Connector Portal, so that findings arrive with no manual steps.
The logs document the lifecycle of the client connection: user sign-in, fetching the profile and PAC file, building tunnels to the Zscaler services, device state changes, and error states. Typical findings are authentication loops, failed tunnel setup, DNS problems, certificate errors from SSL Inspection, and posture checks that were not passed.
The log mode is set per app profile in the Client Connector Portal, and there is also a global default in the platform settings. In normal operation, a lean mode is enough; for targeted troubleshooting, a more detailed mode is turned on temporarily and then reset afterwards, so the logs stay compact and devices stay unburdened.
Yes, in two ways. Zscaler allows non-administrators to be given access to the client's log files too. And with an operations cockpit such as CentaurNexus, the helpdesk uploads the exported log package and gets the findings sorted by severity with plain-language explanations, with no access to the Zscaler admin portal at all.
Yes. Client logs contain personal data such as usernames, device names and destinations visited. The usual GDPR rules therefore apply to export, sharing and retention: collect only for a defined purpose, limit access, delete after analysis. Anyone sharing logs regularly should build pseudonymisation and clear retention periods into the process.
- Zscaler Help Portal: Configuring a Default Global Log Mode - help.zscaler.com
- Zscaler Help Portal: Client Connector documentation (log access, automatic log submission) - help.zscaler.com
Note: CentaurNexus is an independent product of SourcingBlox GmbH and not an offering of Zscaler, Inc. Product and brand names belong to their respective owners.