top of page
Search

ZPA App Connector Unhealthy: journalctl Order That Finds the Real Fault

  • 3 days ago
  • 2 min read
Zscaler network security troubleshooting lab
Zscaler · Techclick CLI troubleshooting lab
Internal app is reachable on the LAN. Remote ZPA users get Application unreachable. Connector is yellow.

This is a live-ticket style lesson from Techclick Infosec. You will isolate the fault with CLI first, then prove the fix with one clean packet or log.

What you will be able to do

  • Name the first CLI command to run on Zscaler for this ticket

  • Separate the layer that is actually broken from the layer people blame

  • Apply one scoped fix instead of a global disable

  • Prove the ticket closed with a session, log, or counter

Quick answer

On the connector host, read zpa-connector logs, then DNS to the control plane, then the health of the published app port. Yellow is usually DNS, time, or the app port — not the ZPA cloud.

Why this ticket shows up

App Connector is a Linux service that builds outbound TLS to ZPA. If it cannot resolve control nodes, if NTP is wrong, or if the app port is closed, the application stays unpublished.

Symptoms operators actually see

  • Connector status yellow or disconnected

  • Only one application fails

  • New connector never goes green

  • Clock skew warnings

CLI first — copy this block

Run these on the Zscaler device or console named in the ticket. Do not skip the first show command — it tells you which later command matters.

sudo systemctl status zpa-connector
sudo journalctl -u zpa-connector -n 200 --no-pager
timedatectl
dig +short connector.private.zscaler.com
ss -lntp | grep -E '443|8443'
curl -vk https://<internal-app-fqdn>:<port> --max-time 5

How to read that output

service must be active. journalctl telling you TLS or DNS errors means the connector never reached ZPA. A green connector with a red app means the connector cannot open the published port.

Triage order

  1. Check service and last 200 log lines.

  2. Fix NTP if the clock is off by more than a minute.

  3. Prove DNS to the ZPA control FQDN.

  4. From the connector, curl the internal app port.

  5. Only then recreate the application segment.

Classic traps

What you see

Real cause

Fix

Rebuild ZPA policy

Connector cannot resolve control

Fix DNS first

Open inbound 443 to ZPA

Connector is outbound-only

Do not NAT inbound

App is up on LAN

Connector is in another subnet with no route

Test from the connector host

Proof the ticket is closed

  • systemctl is active

  • Connector is green

  • Remote user reaches the app once

Say this in an interview

I debug ZPA from the connector host outward. If the connector cannot curl the app, ZPA policy is irrelevant.

Need the full vendor lab, mock interview, and production runbooks? Techclick trains Palo Alto, Zscaler, F5, FortiGate, Check Point, Cisco ISE, Azure and routing with live CLI — start at https://www.techclick.in/

Comments

bottom of page