Zscaler Client Connector Logs analysieren: vom Export zum Befund

Jetzt das eigene Bündel prüfen? Kostenlosen Log Analyzer öffnen.

ZCC-Logs sind eine Goldgrube, aber mühsam zu lesen

Wenn ein Nutzer meldet, dass eine Anwendung nicht erreichbar ist oder die Anmeldung hängt, steht die Antwort oft schon in den Logs des Zscaler Client Connector (ZCC). Dort protokollieren mehrere Komponenten parallel: Tunnelaufbau, Dienststatus, Updates und weitere Abläufe verteilen sich auf Dateien wie ZSATunnel.log, ZSAService.log oder ZSAUpm.log.

Genau das macht die manuelle Auswertung mühsam. Ein exportiertes Log-Bundle enthält viele Dateien, rotierte Archive und Zehntausende Zeilen. Die relevanten Muster sind kryptisch, verteilen sich über mehrere Dateien und müssen zeitlich zueinander in Beziehung gesetzt werden. Im Helpdesk-Alltag fehlt dafür meist die Zeit, und die Erfahrung, welche Zeile auf welche Ursache deutet, ist ungleich verteilt.

Weg 1: Log-Bundle hochladen und auswerten lassen

Der Log Analyzer in CentaurNexus nimmt diesen Schritt ab. Der Ablauf für den Upload-Weg:

Zusätzlich fasst ein Überblick die Metadaten des Bundles zusammen: ZCC-Version, Betriebssystem, Z-Tunnel-Version, abgedeckter Zeitraum sowie die Zähler für Fehler und Warnungen. So ist auf einen Blick klar, welchen Client-Stand und welches Zeitfenster die Analyse überhaupt betrachtet.

Welche Störungsmuster erkannt werden

Die Auswertung sucht nach bekannten Mustern und ordnet sie Kategorien zu, unter anderem: Authentifizierungs-Schleifen und Login-Fehler, gestörte Z-Tunnel-Verbindungen, fehlgeschlagene DNS-Auflösung, PAC-Datei-Fehler, nicht erfüllte Geräte-Posture, SSL- und Zertifikatsfehler, lokale AV- oder Firewall-Blockaden der ZPA-Loopback-Pakete, erkannte Captive Portals und hängende ZCC-Upgrades.

Zu jeder Kategorie gehört eine Empfehlung, die den nächsten sinnvollen Prüfschritt benennt: etwa IdP- und SAML-Konfiguration samt Systemzeit bei Authentifizierungs-Schleifen, den Netzwerkpfad zum Service Edge bei Tunnelstörungen oder die Trust-Store-Kette bei Zertifikatsfehlern. Der Bearbeiter beginnt nicht bei Zeile eins, sondern beim wahrscheinlichsten Hebel.

Drei Fälle, Zeile für Zeile

Die folgenden Zeilen stammen aus dem anonymisierten Demo-Bündel, das der Log Analyzer mitbringt. Sie zeigen das Format, in dem der Client Connector wirklich schreibt: Datum, Zeit mit Mikrosekunden, Zeitzonen-Versatz, Prozess- und Thread-Kennung, dann eines von vier Kürzeln — ERR, WAR, INF oder DBG — und die Meldung. Ein „INFO", „ERROR" oder „WARN" gibt es dort nicht; wer danach sucht, findet nichts.

Fall 1: Die Richtlinie kommt nicht an

Symptom. Ein Gerät verhält sich, als hätte es alte Einstellungen: falsches Forwarding-Profil, fehlende Ausnahmen, ein Schalter, den so niemand mehr gesetzt hat.

Datei. ZSAUpm, geschrieben vom Policy Downloader (Kürzel ZPD).

2025-10-29 08:56:25.771190(+0100)[20002:30012] ERR ZPD: Failed to download UPM policy.

Befund. Die Auswertung führt das als fehlgeschlagenen Richtlinien-Download mit hoher Schwere. Die Einstellungen des Clients kommen aus genau diesem Download. Scheitert er, arbeitet das Gerät mit dem letzten bekannten Stand weiter, und meldet das niemandem.

Andere Erklärung. Ein einzelner Fehlversuch während eines Netzwechsels ist normal. Entscheidend ist, ob ein späterer Versuch gelingt. Im selben Bündel steht der ZIA-Zustand knapp drei Minuten später wieder auf TUNNEL_FORWARDING: dann war es eine Episode. Bleibt der Fehler über mehrere Zyklen stehen, war es keine.

Nächster Schritt. Das Zeitfenster festhalten und prüfen, ob dort auch ADAPTER_DOWN_ERROR oder SERVER_DOWN_ERROR stehen. Wiederholt sich der Fehler ohne solche Begleitzustände, gehört der Fall zum Zscaler-Support: mit dem Zeitfenster, nicht mit dem ganzen Bündel.

Fall 2: Der Systemproxy zeigt woanders hin

Symptom. Einzelne Ziele laufen am Tunnel vorbei oder landen auf einem fremden Proxy. Der Nutzer meldet „geht nicht", der Tunnel steht aber.

Datei. ZSAService.

2025-09-04 16:32:21.784349(+0200)[20005:30041] INF PAC URL should be: http://127.0.0.1:9000/systemproxy-1a2b3c4d.pac but its changed to: http://proxy.contoso.example:8080/corp.pac

Befund. Die PAC-URL wurde von außen überschrieben, hohe Schwere. Der Client erwartet seine eigene, lokal ausgelieferte PAC-Datei; im System steht eine andere. Beachtenswert: Das Kürzel ist INF, nicht ERR. Der Befund hängt an der Aussage der Zeile, nicht an ihrem Schweregrad, deshalb übersieht ihn, wer nur nach Fehlern filtert.

Andere Erklärung. Eine PAC-Datei, die sauber gelesen wird, ist nicht automatisch die richtige. Im selben Bündel steht Pac parse success! — eine Erfolgsmeldung, kein Freispruch. Auch ein Gruppenrichtlinien-Objekt oder ein zweites Sicherheitsprodukt kann die Systemproxy-Einstellung berechtigt setzen.

Nächster Schritt. Die tatsächlich eingetragene PAC-Datei gegen zwei Adressen prüfen: eine, die direkt gehen soll, und eine, die über den Tunnel läuft. Das geht ohne Tenant im kostenlosen PAC-Tester. Weicht das Ergebnis von der Absicht ab, liegt es an der Datei, nicht am Client.

Fall 3: Der Tunnel bricht, und die Ursache steht davor

Symptom. Verbindungen brechen für Minuten weg, danach ist alles wieder da. Der Nutzer meldet „Zscaler war weg".

Datei. ZSAUpm.

2025-10-29 08:56:02.110477(+0100)[20002:30012] ERR ZUIfaceChangeMonitor::getAdapterDetails: Failed to get interface info

Befund. Netzwerkadapter nicht verfügbar, hohe Schwere. Die Zeile steht eine halbe Sekunde nach dem Zustandswechsel ZIA: TUNNEL_FORWARDING → ADAPTER_DOWN_ERROR. Der Tunnel ist nicht weggebrochen, weil Zscaler ausgefallen wäre, sondern weil das Gerät für einen Moment keinen brauchbaren Netzwerkadapter hatte.

Andere Erklärung. Nicht jede Zeile, die nach Netzproblem aussieht, ist eins. checkTunTcpEchoServerUpImpl und isUdpEchoServerUpImpl sind der produkteigene Erreichbarkeitstest, und Sending NXDOMAIN … name: wpad. ist gewollte WPAD-Unterdrückung. Beides gehört zum Normalbetrieb und ist kein Ausfall.

Nächster Schritt. Den Zustandsverlauf im selben Zeitfenster lesen. Führt der Weg über ADAPTER_DOWN_ERROR und endet wieder bei TUNNEL_FORWARDING, war es ein lokaler Netzwechsel: WLAN, VPN, Dockingstation. Steht dort FIREWALL_BLOCK_ERROR oder SERVER_DOWN_ERROR, verlässt der Fall das Endgerät.

Mit dem CentaurNexusAgent entfallen Export und Upload, er arbeitet mit derselben Regelbasis wie die Auswertung hier. Wer es ohne Tenant nachvollziehen will: Der kostenlose Log Analyzer bringt genau das Bündel mit, aus dem diese drei Zeilen stammen.

Weg 2: Mit dem CentaurNexusAgent entfallen Export und Upload

Auf Geräten mit dem CentaurNexusAgent geht derselbe Vorgang ohne Zutun des Nutzers. Der CentaurNexusAgent wertet die ZCC-Logs direkt auf dem Gerät aus und überträgt ausschließlich strukturierte Befunde. Kein Export, keine ZIP, kein Upload, keine Wartezeit im Ticket. Wie sich ein solcher Befund direkt im Supportkontext öffnet, zeigt unser rund zweieinhalbminütiges Video zu diesem Weg.

Öffnet ein berechtigter Bearbeiter im Unified Support Center den betroffenen Nutzer, erscheinen die Client-Log-Befunde inline im selben Arbeitskontext, in derselben Befund-Ansicht wie beim Upload-Weg. Jeder Befund trägt sein Zeitfenster sowie Erst- und Letztauftreten; auch eine Störung, die vor Stunden auftrat, bleibt damit nachvollziehbar, ohne dass der Nutzer sie reproduzieren muss. Ein Klick öffnet dieselben Befunde in der vollständigen Log-Analyzer-Ansicht.

Datenschutz in beiden Arbeitswegen

Auch der Upload-Weg ist auf Datensparsamkeit ausgelegt: Die Logs werden nur im Arbeitsspeicher ausgewertet und nicht gespeichert. Personenbezogene Angaben in Beispielzeilen werden gemäß Tenant-Einstellung obfuskiert, und jeder Abruf wird auditiert.

Der Zugriff auf Befunde ist rollenbezogen abgesichert. Ihn erhält nur, wer den Log Analyzer oder ein Support-Center nutzen darf, und ein auf Domänen gescopter Administrator sieht ausschließlich Nutzer seiner eigenen Domäne. Damit bleibt die Log-Analyse ein kontrollierter Arbeitsweg und wird nicht zum Nebeneingang für breite Einsichtsrechte.

Zscaler bleibt Kernanbieter

Der Zscaler Client Connector bleibt die maßgebliche Client-Software und Quelle der Logdaten. CentaurNexus ergänzt den unterstützten Ablauf um Auswertung, Einordnung und Fix-Empfehlungen in einem gemeinsamen Arbeitskontext für Helpdesk und Administration. Die Befunde verweisen bewusst zurück auf die Zscaler-Seite des Problems, etwa Posture-Profile, PAC-Dateien oder die Tunnel-Konfiguration, damit die Korrektur dort stattfindet, wo sie hingehört.