A readable finding from your ZCC log bundle - find and fix zsaupm, zsaservice and zsatunnel errors
The three Zscaler Client Connector Logs that matter: ZSAUpm.log records policy download and PAC retrieval, ZSATunnel.log the tunnel itself, ZSAService.log posture and service state. Drop in the bundle exported by the Zscaler Client Connector: you get a severity-sorted list of findings, each with the line it rests on and the next step to take. The analysis runs in your browser; the tool reads and classifies, it does not change anything on the device.
Your logs never leave your machine: unpacking and analysis run entirely in the browser, no data is transferred.Upload your log bundle
Easiest: drag in the ZIP file exported by ZCC directly. Individual .log/.txt files also work.
Result
Findings
Explore CentaurNexus in the product demo
Choose the relevant role in the demo launcher. The demo uses prepared sample data.
View product demoWhat a finding looks like
One case from the demo bundle you can load above: the same lines, the same finding. The highlighted line is the trigger; the two around it give it context.
Network adapter unavailable
The device had no usable network adapter for a moment. The tunnel did not drop because Zscaler was down.
How to read it: the state leaves TUNNEL_FORWARDING half a second before the error line and is back at CONNECTING a minute later. So the trigger sits on the endpoint — Wi-Fi, VPN, docking station — not with the service. Three cases, line by line walks through this one and two more.
Frequently asked questions
It unpacks the log bundle exported by the Zscaler Client Connector directly in your browser, parses the contained log files (e.g. ZSATunnel, ZSAService, ZSAUpm) and lists detected failure patterns by severity: tunnel connection failures, DNS failures, PAC file errors, authentication loops, posture failures, SSL certificate errors, AV/firewall interference, captive portal detection, and ZCC upgrade problems.
No. Unpacking and analysis run entirely in the browser (JavaScript); there is no server round trip. ZCC logs contain device names, user identifiers and internal hostnames - which is exactly why client-side processing here isn't an option, it's the requirement.
In the ZCC tray icon, use the gear menu "About" or "Advanced" and choose "Export Logs" or "Collect Logs". The Client Connector produces a ZIP archive with all relevant log files, which you drag and drop here.
No. The tool only analyzes the ZCC log files that live locally on the endpoint, which any user can export themselves. No access to the Zscaler admin console or OneAPI is required.
The Zscaler Client Connector is the lightweight agent that runs on a laptop or phone and forwards the device's traffic to the Zscaler cloud for ZIA, ZPA, and ZDX enforcement. It runs as a background service with a tray icon, and its local activity is what shows up in the ZSATunnel, ZSAService, and related log files this tool reads.
The Client Connector is the agent installed on end-user devices that sends traffic to Zscaler. The App Connector is a different, infrastructure-side component that organizations deploy near their private applications or data centers so Zscaler Private Access can reach them, and it only opens outbound connections, so no inbound firewall rule is needed for it. The two solve different problems even though people often just say “the Zscaler connector” for both.
The Client Connector needs outbound reachability to the Zscaler cloud enforcement nodes it is assigned to, and Zscaler publishes the current IP ranges and hostnames for allowlisting in its own configuration reference rather than as a fixed list, because the ranges can change and vary by cloud. If a connector cannot reach its assigned node, that typically shows up in the logs as a service-edge or connectivity failure, one of the patterns this analyzer looks for.
It is Zscaler's option for extending zero trust access to operational technology and industrial control environments, for cases where installing a standard endpoint agent on legacy OT equipment is not practical. It is a separate product line from the Client Connector covered on this page, aimed at plant and ICS networks rather than laptops.
It depends on the layer. The Client Connector keeps local log files on the device itself, which is what this tool reads. Administrators see policy and traffic logs inside the ZIA, ZPA, and ZDX admin portals, and for continuous, high-volume log access, Zscaler streams data out via NSS and LSS feeds to a SIEM or similar system.
Recurring sign-in prompts usually mean the tunnel was signed out, for example because a token expired, the device's system time drifted, or a session-duration policy forced re-authentication. This is a distinct, recognizable pattern in the ZCC logs, and this analyzer flags it separately from a genuine connectivity failure so you don't chase the wrong cause.
Each file covers a different part of the Client Connector: ZSATunnel logs the tunnel and its connection state, ZSAService covers the background service that keeps the client running, and ZSAUpm relates to the update and installation process. Knowing which component a log belongs to is the first step in reading it, which is why this tool sorts findings by failure pattern rather than leaving you to scroll through raw lines.
For a one-off case, such as troubleshooting a single user's device, manually exporting and analyzing the log bundle, as this tool does, is usually the fastest path. For continuous, tenant-wide log analysis, Zscaler's NSS and LSS feeds stream data out for ongoing processing, a separate setup from the local client logs this page covers.