Zscaler Client Connector (ZCC) Troubleshooting Guide: ZIA, ZPA & SSL Inspection Fixes (2026)

Start here: isolate the failing path

Zscaler Client Connector troubleshooting starts by separating endpoint connectivity, ZIA internet access and ZPA private application access. Record the exact failure, confirm the effective forwarding profile, and correlate one reproduced request with the relevant service logs before changing a policy.

This guide is for helpdesk teams, network and SASE engineers, cloud administrators and SOC analysts. It covers practical checks for connection errors, PAC files, SSL/TLS inspection, identity and App Connector connectivity. For the architecture behind these checks, start with our ZIA vs ZPA architecture comparison.

1. What Client Connector does—and what to verify

Client Connector steers eligible traffic to the Zscaler services enabled for the user and device. ZIA applies internet security policies; ZPA provides policy-controlled access to private applications. ZDX can add experience telemetry where licensed and configured. A connected client is a starting point, not proof that a particular application is reachable.

For conventional ZPA application access, Client Connector can intercept a matching DNS request and return a synthetic address. This address represents a mapping, not the backend server’s actual address. Do not assume every deployment uses a fixed 100.64.0.0/16 range. Check the effective synthetic address configuration and any conflicts with other network software.

Also avoid the blanket claim that Client Connector never performs endpoint security functions: capabilities depend on enabled features. For this guide, distinguish endpoint steering from the ZIA service’s TLS inspection.

Zscaler reference: Understanding the Private Access architecture.

2. Define the scope before changing settings

Build a small comparison matrix: affected versus unaffected user, same device on another approved network, same application from another permitted device, and browser versus native client. Change one variable at a time.

• One user: compare identity, entitlements, posture and profile assignment.
• One device: inspect its build, certificate stores, network extensions/drivers and other security software.
• One branch or ISP: inspect DNS, egress controls, NAT and transport stability.
• One application: identify redirects, API hosts, authentication endpoints and secondary ports.
• Many users: check recent policy, certificate, IdP, network and application changes; review Zscaler service status for the affected cloud and service.

A successful test with protection disabled only narrows the investigation. It does not identify whether forwarding, inspection, policy or application compatibility caused the original failure.

3. Understand forwarding: Z-Tunnel, local proxy and PAC

Z-Tunnel 2.0 supports DTLS over UDP 443 and TLS over TCP 443. Primary transport and fallback behavior are configured; they are not universal defaults. Platform support also varies—for example, Zscaler documents TLS-only Z-Tunnel 2.0 support for iOS. Check the profile rather than assuming blocked UDP always produces a working TLS fallback.

Internet application → effective client forwarding → ZIA Service Edge → destination
Private application  → ZPA policy / Service Edge → App Connector → backend
Identity, DNS, device posture and local network health support both paths.

Zscaler reference: About Z-Tunnel 1.0 and Z-Tunnel 2.0 · Configuring forwarding profiles.

4. Follow a six-step troubleshooting workflow

1. Capture the symptom. Save the error text, destination, protocol, time and business impact.
2. Check local connectivity and identity. Confirm Wi-Fi/Ethernet access, captive portal completion, DNS, system time and the relevant ZIA/ZPA authentication state.
3. Confirm the effective path. Record network classification, app/forwarding profile and actual tunnel state. Use ip.zscaler.com as a browser proxy/egress check.
4. Correlate one request. Reproduce once and inspect ZIA web/firewall records or ZPA user activity for that user and destination. Allow for log ingestion delay.
5. Test the next failing hop. Investigate trust for a certificate error, the matched policy for a deny, or connector-to-application reachability for an appropriate ZPA connection error.
6. Apply and validate a narrow fix. Retest the original workflow, confirm logs show the intended path and remove temporary exceptions.

Zscaler reference: Zscaler proxy test documentation.

5. Connection status errors: checks before fixes

These are investigation branches, not one-to-one root causes. Use the exact status text for the affected build. Fail-open and fail-close behavior depends on policy; a driver or firewall error does not imply the same connectivity outcome for every tenant.

Zscaler reference: Client Connector connection status errors · Client Connector traffic forwarding runbook.

Useful Windows checks

The following PowerShell commands gather local evidence. The destination is illustrative; replace it with an approved endpoint from the incident or logs.

Get-Date -Format o
Get-NetIPConfiguration
Get-DnsClientServerAddress
Get-Service | Where-Object { $_.DisplayName -match 'Zscaler' }
Resolve-DnsName portal.example.com
Test-NetConnection portal.example.com -Port 443
w32tm /query /status

A successful TCP test does not validate UDP/DTLS, TLS trust, application authentication or HTTP behavior. A failed ping alone does not establish an outage.

6. ZIA, DNS and PAC: prove which rule applies

PAC files are not interchangeable. The Forwarding Profile PAC directs traffic toward or away from Client Connector in the applicable mode; the App Profile PAC governs cloud proxy selection for traffic processed through that path. Their roles depend on the configured forwarding method.

1. Record the actual network classification and effective profile, then verify PAC download success, content and update time.
2. Determine whether the failing process honors the system proxy, its own proxy settings or neither. Packet-based coverage must be checked independently.
3. Evaluate the precise hostname and relevant rule order. Reduce unnecessary synchronous DNS lookups, but do not introduce broad private-domain bypasses as a shortcut.
4. Check IPv4/IPv6 behavior and whether application DNS resolution differs from browser or diagnostic-tool resolution.

Zscaler reference: Best practices for PAC files.

A PAC DIRECT result is not a universal “bypass Zscaler” instruction. Traffic may still match packet-based forwarding. Z-Tunnel 2.0 domain bypass behavior depends on client version and listener/redirection settings. Current Windows configurations can apply relevant App Profile PAC bypasses without a Forwarding Profile PAC. Use the documented combination for your release, and validate it in logs.

Zscaler reference: Z-Tunnel 2.0 bypass configuration.

On trusted corporate networks, confirm how endpoint forwarding coexists with branch GRE/IPsec and VPN routing. GRE itself is not encryption. Avoid describing overlapping forwarding as automatic “double encryption,” or setting the trusted-network action to None without validating the intended security design.

7. Fix SSL/TLS inspection and certificate trust safely

When ZIA inspects HTTPS, the client sees a certificate chain issued through the configured inspection CA. First establish which certificate is actually presented, then inspect its issuer, subject/SAN, validity dates and chain. A trust error, hostname mismatch, expired origin certificate and pinned application need different remedies.

Applications using certificate pinning can be incompatible with inspection. Confirm the application’s requirements and the actual TLS failure before introducing a Do Not Inspect rule. An inspection exception changes decryption behavior; a forwarding bypass changes the traffic path.

Zscaler reference: Deploying SSL inspection.

Example: trust an approved CA in the affected runtime

This POSIX shell example assumes an administrator has installed a verified PEM bundle at the path shown. Preserve the public roots needed by the application. These settings are tool-specific, not universal; use only the setting relevant to the failing runtime. Scope Git configuration to the intended repository and record any existing value before changing it.

# Examples: choose the setting appropriate to the affected tool.
export REQUESTS_CA_BUNDLE="/etc/company/approved-ca-bundle.pem"
export NODE_EXTRA_CA_CERTS="/etc/company/inspection-root.pem"
export AWS_CA_BUNDLE="/etc/company/approved-ca-bundle.pem"
git config --local http.sslCAInfo "/etc/company/approved-ca-bundle.pem"

Run the Git example inside the affected repository. Check its TLS backend: Git using Windows Schannel can use the Windows certificate store and may ignore http.sslCAInfo unless configured otherwise. Node.js reads NODE_EXTRA_CA_CERTS at process startup, so restart the affected process after setting it.

Retest with certificate verification enabled. Do not use curl -k, verify=False or a global verification-disable setting as the production fix. A custom-CA path valid on a host may not exist inside a container or remote development environment.

Runtime references: Requests CA verification · Node.js extra CA certificates · AWS CLI environment settings · Git TLS configuration.

8. ZPA application failures and verified status codes

Start with the exact application FQDN, protocol and port. Confirm that they match the intended Application Segment, that access policy permits this user/device, and that the segment maps through the intended Server Group and App Connector Groups. A healthy Private Access status does not prove application-specific authorization.

Match the complete code to the current reference. A generic policy denial or unavailable-connector symptom should be investigated through the matched rule, posture results and connector selection; do not invent an “exact” code for it.

Zscaler reference: Private Access session status codes.

Compare normal application resolution on the endpoint with resolution from the connector’s network. Synthetic client addresses can be expected. A query sent directly to a chosen DNS server may test a different path from the application’s resolver. Test the authorized service port rather than relying on ICMP reachability to a synthetic address.

9. App Connector health, DNS and backend reachability

Check connector state, recent upgrades, resource use and the relevant group assignments. Separate cloud connectivity from the connector-to-backend path. An online connector can still lack access to a particular application.

For an authorized administrator on a supported systemd-based connector host, these are read-only checks. The example application and DNS addresses must be replaced with the approved targets. Use existing tools; do not alter the connector image just to add diagnostics.

systemctl status zpa-connector --no-pager
journalctl -u zpa-connector -n 100 --no-pager
getent ahosts erp.corp.example
dig +short erp.corp.example @10.10.1.53
nc -vz -w 5 erp.corp.example 8443

Run the application request from the connector’s network when permitted. A successful socket test establishes reachability, not a working login or backend dependency. Compare DNS answers, firewall events and application logs at the same timestamp.

Protect the connector-to-ZPA cloud TLS path from intermediary SSL interception. Zscaler documents pinned certificates on that path; use the current domain/IP requirements for your actual ZPA cloud when configuring inspection exceptions. A provisioning key is an enrollment mechanism, not a pinned TLS certificate.

Zscaler reference: Troubleshooting App Connectors · App Connector troubleshooting runbook.

For resilience, deploy redundant connectors across suitable failure domains and verify each can reach the applications it serves. Do not reboot every connector simultaneously or treat redundancy as a substitute for backend health checks.

10. Authentication loops, group changes and device posture

Separate authentication from provisioning and authorization. A successful IdP sign-in does not prove the expected group, device posture or access policy is in effect.

1. Correlate the sign-in. Check the exact application, user, time, result and conditional access decision in the IdP logs. Confirm system time and service assignment.
2. Inspect the redirect path. Verify the configured entity ID, reply/ACS URL and signing certificate against the tenant configuration. Check whether login dependencies are blocked or mistakenly treated as private applications.
3. Validate identity data. Inspect current SAML attributes and SCIM provisioning/group state separately. Reauthentication can refresh a session; it does not force a failed provisioning job to synchronize.
4. Check posture results. Compare the effective posture evaluation with the rule that allowed or denied the request.

For Kerberos or other integrated authentication over private access, map the actual domain-controller, DNS and application dependencies. Do not equate Kerberos, LDAP and SMB ports or apply one broad port list to every application. Validate the authentication design with the IAM team.

If login dependencies need an exception, scope it to the required flow under the organization’s authentication design rather than bypassing all IdP traffic indiscriminately.

11. Collect logs, packet captures and experience evidence

1. Preserve the initial evidence. Export existing client logs and record the current status before restarting or clearing anything.
2. Prepare one reproduction. If authorized, select the appropriate log mode and start packet capture through the available Troubleshoot controls.
3. Reproduce and timestamp. Record the FQDN, port, error and time zone. Stop capture promptly and export the relevant bundle.
4. Restore normal logging. Revert temporary diagnostic settings and share logs through the approved support channel.

Capture availability, file names and capture layers vary by OS, release and administrator settings. Do not assume every platform produces Windows LWF pre/post-tunnel captures. Protect bundles because they can contain user identities, hostnames, network information and application data.

Zscaler reference: Client Connector troubleshooting tools by operating system.

Correlate with service-side records and, where available, ZDX measurements for the same user and time. Intermediate-hop loss alone does not establish application packet loss: routers may deprioritize diagnostic probes. Check end-to-end impact and application timings before assigning blame.

For SIEM work, distinguish ZIA NSS/Cloud NSS from ZPA LSS. Verify ingestion, timestamps and field mappings before treating an absent event as proof of bypass. Our Microsoft Sentinel and KQL tutorial provides background on investigation queries.

Zscaler reference: About ZPA Log Streaming Service · About Cloud NSS feeds.

Escalation checklist

• Impact, affected/unaffected examples, first observed time and recent changes.
• OS/build, client build, cloud, effective profiles and service status.
• Destination FQDN/IP, protocol, port and timestamp with time zone.
• Exact client error and matching ZIA/ZPA records, including rule or session details.
• Relevant logs/captures, comparison tests, temporary changes and rollback state.

12. Worked example: SaaS works, private ERP times out

Illustrative scenario: users can open public SaaS sites, but https://erp.corp.example:8443 times out. The following is a diagnostic example, not a reported customer incident or performance benchmark.

1. Record the complete URL, timestamp and affected users. Confirm Private Access authentication, then check the ERP segment includes TCP 8443.
2. Find the matching ZPA user activity record. It reports AST_MT_SETUP_TIMEOUT_CANNOT_CONN_TO_SERVER and identifies the selected connector.
3. From the connector’s network, resolve the ERP hostname and test TCP 8443. Compare the DNS answer with the application owner’s current server address.
4. The owner confirms a recent migration. The connector still receives the old address, and the new subnet also needs the intended access rule.
5. Correct the DNS record and narrowly scoped network rule through change control, account for cache/TTL behavior, then repeat the original user workflow.

Validate a successful application response and the expected ZPA session across the relevant connectors. Avoid adding a broad forwarding or inspection bypass: neither addresses the stale backend mapping in this example.

13. Turn incident fixes into reliable operations

Track recurring failures by layer: endpoint, identity, forwarding, inspection, ZPA connector or backend. Use that record to prioritize certificate deployment, application inventory and change coordination.

• Keep an owner, reason, scope and review date for every exception.
• Test profile and PAC changes on a small pilot group before broad deployment.
• Monitor connector health and application reachability from the connector tier.
• Preserve a tested rollback plan for client, policy and certificate changes.
• Coordinate application migrations with DNS, segment and firewall updates.

Where internal teams need deployment or operational support, contact Cyberseal Infosec Solutions to discuss the required scope. Confirm current services and commercial terms directly.

14. Practice with controlled troubleshooting labs

Use an authorized test tenant and test applications. Give each exercise an expected result, evidence requirement and rollback.

• Forwarding: compare a browser proxy test with the effective profile and service logs; explain why they answer different questions.
• PAC: pilot a narrow test-host change using the documented method for your forwarding mode; confirm both browser and native-client behavior.
• Trust: reproduce a test-runtime CA error and resolve it while keeping verification enabled.
• ZPA: compare endpoint synthetic resolution with connector-side backend resolution and test the defined application port.
• Diagnostics: collect one short reproduction and explain which evidence identifies the failing hop.

15. A 30-day learning roadmap

Pair this plan with our Zscaler training roadmap. The goal is a repeatable investigation method; mastery depends on practice and access to suitable environments.

16. Interview scenarios worth practicing

What does a successful ip.zscaler.com check establish?

The browser request’s Zscaler proxy/egress path. Confirm the client transport and other applications separately.

Why can a browser work while a CLI fails?

The CLI may use different proxy settings, trust roots, DNS behavior or destinations.

Does a PAC DIRECT result always bypass ZIA?

No. Interpret it in the effective forwarding context and confirm packet-based coverage.

Does a connected ZPA client prove ERP access?

No. Application definition, policy, connector selection and backend reachability still need validation.

What distinguishes a server timeout from a Service Edge timeout?

The full session status code and related fields identify which connection path to investigate.

What belongs in an escalation?

A precise reproduction, synchronized evidence, configuration/build details, comparison tests and change history.

For broader preparation, see our Zscaler interview questions and answers.

17. Frequently asked questions

How do I troubleshoot Zscaler Client Connector not connecting?

Check local network access and captive portal completion, record the exact service error, confirm authentication and the effective profile, then correlate logs with the failing cloud connection. Test the required destination and transport rather than assuming a general internet test proves connectivity.

Why is ZPA connected but my private application unavailable?

The user may lack application-specific access, the FQDN/port may not match the segment, or the selected connector may not reach the backend. Use the corresponding user activity record to select the next test.

Should I disable SSL inspection to fix certificate errors?

First validate the origin certificate and the application’s trust store. Use an approved CA configuration where supported. Consider a narrow inspection exception only for a confirmed requirement, with ownership and review.

Does turning off Internet Security also turn off Private Access?

ZIA and ZPA have separate service states. Check both explicitly; available user controls and resulting behavior depend on administrator policy and deployment design.

Which Client Connector version should I install?

Use the supported release approved for your platform and tenant, after reviewing relevant known issues and testing a pilot. A single “latest version” number is not appropriate for every operating system and release track.

Zscaler reference: Client Connector release summary: 2026.