TTechclick ⚡ XP 0% All lessons
Zscaler · ZPA · Application SegmentsInteractive · L1 / L2 / L3

ZPA Application Segments — Define the App, or Nobody Gets In

In ZPA an app is not a server — it is an Application Segment: an FQDN plus the exact ports it uses. Get the domains, ports, Bypass Type and Health Reporting right and traffic flows; get them wrong and an authenticated user is silently blocked or your connector browns out. This lesson defines a private app the right way, end to end.

📅 2026-06-03 · ⏱ 14 min · 3 live demos · 4 infographics · 🏷 10-Q assessment + AI Tutor inline

⚡ Quick Answer

Define a ZPA Application Segment the right way: precise Domain Names plus explicit TCP/UDP ports (never 0-65535), Bypass Type Never vs Always, Health Reporting and the ~6,000-check ceiling, Double Encrypt cost, and the one-Segment-Group object chain behind authenticated-but-blocked. 5 infographics, 2 live demos, real console recreations and a 10-question assessment.

🎯 By the end you will be able to

Read as:

Pick where you want to start

1

The object chain

Why an authenticated user can still be blocked.

 2

Bypass & ports

Domains, explicit ports, and the Always trap.

 3

The 6,000-check trap

Wildcard + wide ports = connector brownout.

 4

Segment Group & rule

One group per segment; rules target groups.

🧠 Warm-up — 3 questions, no score

Just notice which ones make you pause. We answer all three inside the lesson.

1. An authenticated user cannot reach a new app, but their Okta login works fine. Where is the fault most likely to be?

Answered in The object chain.

2. You publish *.corp.local with a 0-65535 port range. What happens to the App Connector?

Answered in The 6,000-check trap.

3. An app shows zero ZPA logs while everything else logs fine. What do you check first?

Answered in Bypass & ports.

Most engineers think…

An Application Segment is just “the server’s address” — point it at the box and you are done.

Wrong. A segment is a tightly-scoped object — FQDN, EXPLICIT ports, Bypass Type, Health Reporting — and it must sit in exactly one Segment Group that a rule targets. Fluff the ports and the app is dead; pick Always bypass and ZPA goes blind; use a wildcard with wide ports and the connector browns out. Define the app precisely, or nobody gets in.

① The object chain — why "authenticated" still means "blocked"

You already met the high-level model in the ZPA Fundamentals lesson — the inside-out tunnel, the broker, the four components. This lesson goes one level deeper: the Application Segment, the object that actually defines a private app. Get it wrong and a perfectly authenticated user still reaches nothing — silently.

In ZPA an app is not "a server". It is a chain of objects, and every single link must be intact or the bottom default-deny wins with no error. The chain runs: IdP → Device Posture → Provisioning Key → App Connector Group → Server Group → Application Segment → Segment Group → Access Policy → Timeout Policy. No Application Segment, no access — full stop.

Figure 1 — Access is a chain: one missing link and an authenticated user gets nothing
Access in ZPA is a dependency chain from IdP through Application Segment and Segment Group to the Access Policy rule, and a missing Application Segment means an authenticated user is still default-denied. A vertical dependency stack. From the top: IdP and Device Posture prove who you are. Below them the infrastructure chain — Provisioning Key, App Connector Group, Server Group — builds the path to the servers. The Application Segment defines the app by FQDN and ports and is the keystone link. It must be placed in a Segment Group, which the Access Policy rule targets, and a Timeout Policy then governs reauthentication. A red note shows that if the Application Segment or its Segment Group is missing, an authenticated user falls through to the implicit default-deny. Identity proves WHO. The object chain proves WHAT you can reach. trusted infra link the keystone object missing = default-deny IdP (SAML/SCIM) proves who you are Device Posture proves device health Provisioning Key App Connector Groupdeploy in pairs Server GroupDynamic Discovery ⬢ APPLICATION SEGMENT — the keystone FQDN/IP + EXPLICIT TCP/UDP ports + Bypass Type + Health Reporting Segment Group — exactly ONE per segmentthe bundle the rule actually targets Access Policy ALLOWtargets the Segment Group Timeout Policyreauth, min-wins Drop the segment (or forget its Segment Group) and the user is authenticated but blocked. ZPA never errors on a missing link — it just default-denies. Walk the chain top-to-bottom to debug.
Read it top-down: identity proves who, the chain proves what. The lime block is the Application Segment — break it and every link below is unreachable.

Four segment flags freshers fluff

Tap each card — front is the field, back is the trap it hides. We unpack all four across this lesson.

🌐
Domain + Ports
tap to flip

Explicit FQDN + only the real ports. 0-65535 is the cardinal sin — it makes health checks explode. Exclude DNS port 53.

🔀
Bypass Type
tap to flip

Never = brokered + logged. Always = direct, ZPA logs nothing and looks broken. On Net = direct only on the corp network.

🔐
Double Encrypt
tap to flip

Inner TLS for plaintext protocols only. It counts double against the connector — 100 Mbps behaves like 200 Mbps.

📦
Segment Group
tap to flip

A segment lives in exactly one Segment Group, and rules target the group. Forget it and the rule cannot see the segment.

Priya at Infosys faces this

Priya's user authenticates perfectly through Okta — the login page loads, MFA passes — but a brand-new Oracle reporting app stays "application unreachable". Her first instinct is to blame the IdP.

Likely cause

It is not auth. The Oracle FQDN was never wrapped in an Application Segment, so ZCC has nothing to match and never even sends the request to ZPA — the default-deny at the bottom of the chain wins.

Diagnosis

Walk the chain, not the login. Check the segment exists, its FQDN matches, and it sits in a Segment Group the rule targets.

Applications ▸ Application Segments ▸ (search the FQDN)
Fix

Create the Application Segment for oracle-rpt.corp.internal on TCP 1521, link the Server Group, and assign it to a Segment Group that an ALLOW rule references.

Verify

The user's access log now shows an ALLOW against the new segment — proof the chain is whole, not just that login worked.

Quick check · Q1 of 10 · Remember

An App Connector needs to reach the ZPA cloud. Which single outbound port does it use (with optional UDP 443 for DTLS), and how many inbound ports must be opened?

Correct: b. The connector dials OUT on TCP 443 (UDP 443 for DTLS / Z-Tunnel 2.0) and accepts nothing inbound — the inside-out model is the whole security story. (a)/(c)/(d) re-expose the network or describe a VPN gateway, exactly what ZPA replaces.
👉 So far: identity proves who you are; the Application Segment proves what you can reach. Now let's open the actual segment form and define an app the right way.

② Defining the app — Domains, EXPLICIT ports, and the four flags that bite

This is the form where production goes right or wrong. An Application Segment has four decisions that students fluff: the Domain Names (FQDN, wildcard or IP), the TCP/UDP port ranges (never 0-65535), the Bypass Type, and Health Reporting. We will open the real console, then dig into each.

Here is the Add Application Segment screen — recreated so you recognise the live portal.

https://admin.private.zscaler.com  ·  Applications ▸ Application Segments ▸ Add
Applications ▸
Application Segments
Segment Groups
Server Groups
Infrastructure ▸
Policy ▸
Applications ▸ Application Segments ▸ Add Application Segment
Define a private app by its domains and the exact ports it uses. Wildcard + wide ports = connector brownout.
NameSAP-Finance-Prod
StatusEnabled ▾
1Health ReportingOn Access ▾  None / On Access / Continuous
2Bypass TypeNever ▾  Always = ZPA logs nothing!
Double EncryptOff  on = ~2× connector load
3Domain Names / IP Addressessap.corp.internal  not *.corp!
4TCP Port Ranges (From / To)8443 to 8443  never 0–65535
Server GroupsMumbai-DC-SG ▾
Segment GroupSG-SAP-Finance  exactly one
1 probing intensity per connector   2 whether ZPA ever sees the traffic   3 the FQDNs ZCC intercepts   4 the exact ports — a missed port is a dead app
🖥️ Recreated for clarity — your ZPA console matches this. Path: Applications ▸ Application Segments ▸ Add Application Segment. Pins ①②③④ mark the four fields where production breaks.

Domains + ports: scope it like a hotel keycard

Think of a hotel keycard coded for only your floor and your room — it will not open the gym or the manager's office. The Application Segment is that keycard: define just the FQDN and the exact ports the app uses, so a stolen card (a compromised connector) still cannot roam the building. Domain Names accept a precise FQDN (sap.corp.internal), an IP, or a wildcard (*.corp.internal). Port ranges must be the real ports — Zscaler even recommends excluding DNS port 53 from segment ranges. The cardinal sin is 0-65535: it tells the connector the app uses every port, which (with health checks on) becomes self-inflicted CPU death — covered in §4.

Bypass Type — the silent "ZPA looks broken" trap

Bypass Type decides whether ZPA ever sees the traffic. Never (the default) always brokers and logs the session. On Net brokers only when the device is off the corporate network (on-net it goes direct). Always means ZCC sends the traffic straight to the destination and never brokers it — so ZPA logs nothing, and the panicked admin assumes "ZPA is broken". It is the #1 silent trap. Reserve Always/On-Net only for split-tunnel exclusions you intend to skip.

Figure 2 — Bypass Type decides whether ZPA ever sees the packet
Bypass Type Never brokers and logs every session through ZPA, while Bypass Type Always sends traffic direct so ZPA sees nothing and logs nothing — the silent broken-looking trap. A side-by-side decision contrast. On the left, Bypass Type Never: the ZCC client sends the request through the ZPA broker, which checks policy, brokers the session and writes an access log — the healthy, visible path. On the right, Bypass Type Always: ZCC sends the request directly to the destination, completely skipping the ZPA broker, so no policy is applied and no log is ever written, which makes ZPA appear broken even though it is working as configured. brokered + logged direct, ZPA blind Bypass Type = Never (default) ZCC clientuser request ZPA brokerpolicy + broker App reached✓ access log written You can SEE it in the logs. Bypass Type = Always ZCC clientuser request ZPA brokerskipped entirely Direct to destination✖ no log, no policy "ZPA is broken!" — but it is not. No logs for an app does NOT mean ZPA failed — check Bypass Type FIRST. Never = always brokered + logged · On Net = brokered only off the corporate network · Always = direct, zero ZPA visibility. Reserve Always / On Net for deliberate split-tunnel exclusions — never as a default.
Same user, same app. Flip Bypass Type to Always and the broker is bypassed — so there is nothing to log. Always check this before assuming ZPA failed.

▶ Watch a segment get brokered — then flip Bypass to Always

Press Play for the healthy Never path, then Break it to see what happens the instant Bypass Type is set to Always.

① MATCHZCC matches the app FQDN against the segment and its explicit port (8443)
▼
② BROKERBypass Type = Never → ZCC routes up the Z-Tunnel to the broker, which checks Access Policy
▼
③ STITCHPolicy passes → broker stitches the M-Tunnel to the connector serving the Server Group
▼
④ LOGConnector proxies to the app server; an access log is written — you can prove it worked
Press Play to step through the healthy Never path. Then press Break it.
Quick check · Q2 of 10 · Apply

A connector VM was cloned and now stays Disconnected, with the connector log saying certificate is not yet valid; restarting the service changes nothing. Which fix is correct?

Correct: c. "Certificate is not yet valid" means the VM clock is skewed from UTC, so the cert's notBefore lies in the connector's future and the mTLS handshake is rejected — classic on cloned VMs with no NTP yet. Fix NTP and re-enrol. (a)/(b)/(d) do not touch the clock, which is the actual root cause.

Pause & Predict

An admin swears ZPA is down because one app produces zero session logs — yet every other app logs fine and the connector is green. What is the very first segment setting you check, and why? Type your guess.

Answer: Bypass Type. If it is set to Always, ZCC sends that app direct and never brokers it, so ZPA has nothing to log. Set it back to Never and the logs reappear instantly. "No logs for one app" is the Always signature — not a ZPA outage.
👉 So far: scope the domain + explicit ports, and keep Bypass on Never unless you mean to skip ZPA. Next — Double Encrypt, and why turning it on can quietly halve a connector.

③ Double Encrypt & Health Reporting — the cost knobs

Two segment options trade safety/visibility for connector capacity. Misjudge either and you brown out a connector. Know exactly what each costs.

Double Encrypt — a second TLS layer that counts double

Double Encrypt adds an inner TLS layer inside the microtunnel, in memory at the Service Edge, so even the broker cannot read the payload. Use it only for genuinely plaintext protocols crossing ZPA — HTTP, FTP, Telnet, RDP-without-TLS. Skip it for HTTPS, SSH or RDP-with-TLS, which are already end-to-end encrypted. The catch is capacity: double-encrypted traffic counts double against the App Connector, so 100 Mbps of Double-Encrypt behaves like 200 Mbps of normal load. Enable it carelessly across a busy segment and you silently halve a connector's headroom.

When to actually turn Double Encrypt on

Ask one question: "is this protocol already encrypted end-to-end?" If yes (HTTPS/SSH/RDP-TLS), leave Double Encrypt off — you would pay ~2× connector load for nothing. If no (Telnet, FTP, legacy HTTP, plain RDP) and the data is sensitive, turn it on and size the connector for double the throughput of that segment. Scope it per-segment, never blanket-on.

Quick check · Q3 of 10 · Apply

An authenticated user can open the app in the browser, but ZPA shows no session logs at all for it, and the admin assumes ZPA is broken. Which segment setting is the cause to revert?

Correct: a. Bypass Type = Always makes ZCC send the traffic direct, skipping the broker, so there is nothing for ZPA to log — set it back to Never. (b) Health Reporting governs probes, not session logs; (c) Double Encrypt is about payload secrecy; (d) wide ports cause health-check load, not log suppression.

Health Reporting — and the ~6,000-check ceiling

Health Reporting has three modes. None = no active probing. On Access = the connector checks reachability only when a user actually requests the app. Continuous = each connector probes every FQDN+port combination on a cycle (~20 checks/sec). ZPA enforces a hard ceiling of roughly 6,000 health-check targets per App Connector. Combine a wildcard FQDN with a wide port range under Continuous and you blow straight past it — the connector pegs CPU, the health cycle stretches past 10 minutes, and brokering randomly picks connectors. We will do the math next.

Rahul at TCS faces this

Rahul publishes a legacy Telnet jump host through ZPA and ticks Double Encrypt "to be safe". Within a day the Mumbai connector is at 90% CPU and users on three other segments report lag.

Likely cause

Double Encrypt counts double against connector capacity. Enabling it on a busy segment silently halved that connector's effective throughput, starving the other segments it serves.

Diagnosis

Check which segments on that connector have Double Encrypt on and estimate their throughput × 2.

Applications ▸ Application Segments ▸ (segment) ▸ Double Encrypt
Fix

Keep Double Encrypt on only for the truly-plaintext Telnet segment, move it to a dedicated connector group sized for 2× its load, and leave the HTTPS/SSH segments with it off.

Verify (L2/L3)

Connector CPU drops back under ~60% and the other segments recover; the Telnet flow still shows the inner TLS layer in a capture.

👉 So far: Double Encrypt is ~2× load — scope it; Health Reporting Continuous probes everything. Now the math that turns a wildcard into a connector brownout.

④ The 6,000-check explosion — wildcard + wide ports = brownout

This is the single most important number in this lesson. In Continuous health mode the probe count is roughly (FQDNs × IPs-per-DNS) × (TCP ports + UDP ports). An explicit segment stays tiny; a wildcard with all ports explodes into tens of thousands of probes and starves the connector.

Figure 3 — Explicit FQDN+ports stays safe; wildcard + all ports smashes the ceiling
An explicit FQDN with a few ports produces a handful of health checks well under the six-thousand ceiling, while a wildcard FQDN with a zero to sixty-five-thousand port range produces tens of thousands of probes that smash the ceiling and brown out the connector. A threshold gauge comparison. On the left, a well-scoped segment: one FQDN times three ports equals three health checks, sitting far below the six-thousand-target ceiling, with the connector healthy. On the right, a wildcard segment: roughly forty resolved hosts times about sixty-five thousand ports equals millions of probe attempts, far above the six-thousand ceiling, which pegs connector CPU, stretches the health cycle past ten minutes and makes brokering pick connectors at random. The arithmetic formula checks equal FQDNs times IPs per DNS times TCP plus UDP ports is shown across the top. checks ≈ (FQDNs × IPs-per-DNS) × (TCP ports + UDP ports) under ceiling — safe over ceiling — brownout ~6,000-target ceiling ~20 checks/sec per connector Explicit FQDN + 3 ports sap.corp.internal · 443, 1521, 3389 3 checks 1 host × 3 ports = 3 connector idle & happy Wildcard + 0–65535 ports *.corp.local · all TCP & UDP ports millions of probe attempts ~40 hosts × ~65,534 ports = far past 6,000 What blowing the ceiling does • connector CPU pegged even at idle • health cycle > 10 minutes • brokering picks connectors at random • stale brokering & dropped sessions Fix: explicit FQDNs + only real ports The ceiling is per-connector. Scope the segment, or the connector pays for your shortcut.
The arithmetic is brutal: 3 checks vs millions. Explicit FQDNs and only the real ports keep you safely under the per-connector ceiling.
On the App Connector VM — see the live health-check load
sudo zpa-connector troubleshoot health
dig +short sap.corp.internal
nc -vz 172.16.8.20 8443
cat /opt/zscaler/var/health/check_count
Expected output
[health]  mode: ON_ACCESS   targets: 3   cpu: 11%   cycle: 4s
172.16.8.20
Connection to 172.16.8.20 8443 port [tcp/*] succeeded!
active_targets=3  ceiling=6000  headroom=5997

If active_targets creeps toward 6,000 (or CPU is pegged with a long cycle), you have a wildcard or wide-port segment somewhere on this connector. Find it, make the FQDNs explicit, and trim the ports to what the app truly uses.

Anjali at HDFC faces this

Anjali publishes *.corp.local with a 0–65535 port range "so nothing gets missed". By morning the connector CPU is pegged at idle, the health cycle takes 12 minutes, and brokering jumps between connectors randomly.

Likely cause

A wildcard FQDN with every port makes each connector probe ~65,534 ports per resolved IP under Continuous health — tens of thousands of targets, far past the ~6,000 ceiling.

Diagnosis

Inspect the segment's Domain Names and port range; count resolved IPs × ports.

Applications ▸ Application Segments ▸ (segment) ▸ Domain Names / TCP Port Ranges
Fix

Rebuild the segment with explicit FQDNs and only the real ports — 443, 1521, 3389 — and assign only the connector group in the app's home datacenter so distant connectors stop probing it.

Verify

Health-check count drops back under the ceiling, connector CPU settles, and brokering becomes stable on the local group.

Real CVE — CVE-2025-54982 (Zscaler SAML signature not verified)

Disclosed 2025-08-05 (CVSS 9.6 Critical, CWE-347): Zscaler's server-side SAML SP failed to verify incoming SAML responses against the configured IdP's public key, so an attacker could forge a SAML assertion naming themselves as any user, receive a valid access token, register a rogue device and gain full authentication bypass into both ZIA and ZPA — reaching every private app behind the tunnel. It was fully patched server-side across all clouds — no customer action required, with no evidence of in-the-wild exploitation. The lesson for segment design: your beautifully-scoped Application Segments are only as trustworthy as the identity feeding them. Confirm your SAML IdP configuration is current. (Pair with CVE-2025-54983 on the ZCC side — update ZCC to 4.6.0.216+ / 4.7.0.47+.)

Pause & Predict

You have one FQDN that resolves to 5 IPs, and you set a TCP range of 1000 ports plus a UDP range of 1000 ports under Continuous health. Roughly how many health-check targets is that, and are you safe? Type your guess.

Answer: ~10,000 targets: (1 FQDN × 5 IPs) × (1000 TCP + 1000 UDP) = 5 × 2000. That is well over the ~6,000 ceiling — the connector will brown out. Cut to the handful of ports the app truly uses, or switch to On-Access health.
👉 So far: explicit FQDNs + real ports keep you under the ceiling; the IdP it all trusts must be patched. Last — the Segment Group rule, where "authenticated but blocked" actually happens.

⑤ Segment Group & the Access rule — where "authenticated but blocked" happens

One hard rule of cardinality: an Application Segment belongs to exactly ONE Segment Group. And Access Policy rules target the group, never a bare segment. So the most common silent failure on Earth is: connector green, segment enabled, ALLOW rule present — yet the segment was never placed in the group the rule references. Result: default-deny, no error.

Here is the Add Access Policy Rule screen, proving the rule targets a Segment Group.

https://admin.private.zscaler.com  ·  Policy ▸ Access Policy ▸ Add Rule
Add Access Policy Rule — Allow-Finance-SAP
ActionALLOW ▾   (or Deny / Require Approval)
Rule Order3  — narrow DENY rules go above this
1Application (target)Segment Group: SG-SAP-Finance  a group, not a bare segment
2Criteria · SCIM GroupFinance AND
3Criteria · Device PostureCompliant-Win ▾
Select IdPOkta-Prod
Access TypeZPA Client (ZCC)
🖥️ Recreated for clarity — your ZPA console matches this. Path: Policy ▸ Access Policy ▸ Add Rule. Pin ① is the whole point: the rule targets the Segment Group, so a segment outside the group is invisible to the rule and default-denied.

▶ Walk the object chain — then break the Segment Group link

Press Play for a healthy grant, then Break it to see the classic silent failure when the segment is never added to its Segment Group.

① SEGMENTThe app lives in an Application Segment with the right FQDN and explicit port
▼
② GROUPThe segment is placed in SG-SAP-Finance — its one and only Segment Group
▼
③ RULEThe ALLOW rule targets that Segment Group — SCIM=Finance AND posture compliant
▼
④ GRANTChain intact → access granted to the SAP app, logged against the rule
Press Play to watch the chain grant access. Then press Break it.
Quick check · Q4 of 10 · Apply

You must publish 100 Mbps of plaintext Telnet through ZPA with Double Encrypt enabled. What connector-capacity load does that flow create?

Correct: d. Double Encrypt adds a second in-memory TLS layer and counts double against the App Connector, so 100 Mbps of double-encrypted traffic behaves like ~200 Mbps of load — size the connector accordingly. (a)/(b)/(c) all understate the real cost.

Vikram at Flipkart faces this

Vikram enables a new payments dashboard segment, the connector is green, and an ALLOW rule exists — yet it goes live for absolutely nobody, with no error anywhere in the UI.

Likely cause

The new Application Segment was never placed in a Segment Group, so the ALLOW rule (which targets the group) cannot see it → default-deny.

Diagnosis

Open the segment and confirm its Segment Group field is populated and the group lists the segment as a member.

Applications ▸ Application Segments ▸ (segment) ▸ Segment Group
Fix

Assign the segment to the exact Segment Group the rule references (each segment lives in exactly one), then retest. Walk the whole chain if it still fails.

Verify

The segment now appears in the group's member list and the user's access log shows an ALLOW against the correct rule.

Sneha at Wipro faces this

Sneha's on-prem users hit latency hairpinning to a far Zscaler PoP for a local finance app in the same datacenter. She is asked to cut the round-trip without losing zero-trust.

Likely cause

The Public Service Edge brokers the session in a Zscaler cloud PoP, so a same-building app hairpins out and back — 2–4 extra hops of latency.

Diagnosis

Confirm the brokering edge is a remote Public Service Edge, not local, for that segment's users.

Infrastructure ▸ Service Edges (Public vs Private)
Fix

Deploy a Private Service Edge in the datacenter so on-prem users broker locally, and set a stricter 4-hour idle Timeout on the finance segment group. Trade-off: a PSE is a licensed add-on you must host and patch.

Verify (L2/L3)

Latency for local-DC users drops sharply and the access log shows brokering via the PSE, not the far PoP.

Pause & Predict

Two Timeout Policy rules match the same user — one says Reauth Idle 24h, the other says 8h. What is the effective reauth interval, and why? Type your guess.

Answer: 8 hours. When multiple Timeout rules match, the effective value is the minimum across them — the stricter rule wins. That is exactly why teams set tighter idle timeouts (e.g. 4h) on sensitive finance segment groups versus 12h on standard apps. Timeout Policy also runs after Access Policy, so passing access never exempts you from reauth.

Figure 4 — Bypass Type as a decision tree: does ZPA ever see this packet?
A decision tree for Bypass Type: Never always brokers and logs, On Net brokers only when the device is off the corporate network, and Always sends traffic direct so ZPA never sees or logs it. A decision tree starting from a packet leaving ZCC. The first amber diamond asks what the segment's Bypass Type is. The Never branch leads to a green outcome where the packet is brokered through ZPA and an access log is written. The On Net branch leads to a second amber diamond asking whether the device is on the corporate network: if yes the packet goes direct and is not logged, if no it is brokered and logged. The Always branch leads straight to a red outcome where the packet goes direct to the destination and ZPA logs nothing, which is the silent broken-looking trap. A packet leaves ZCC — does ZPA ever see it? decision brokered & logged Bypass Type? per segment Never Brokered through ZPA ✓ access log written On Net On corp net? No Brokered & logged off-net uses ZPA Yes Direct on-net not logged Always Direct to destination ✖ ZPA logs NOTHING — looks broken "No logs" = check Bypass Type, not a ZPA outage. Default to Never. Use On Net / Always only for deliberate split-tunnel skips.
Follow the branches: only Never (and off-net On-Net) is brokered and logged. Always is direct — ZPA is blind by design, which is exactly why it "looks broken".

⑥ Public vs Private Service Edge & the revision card

One last design lever your segments inherit. The Service Edge brokers every session, and where it lives changes latency and data residency for the apps your segments define.

Figure 5 — Public vs Private Service Edge + the App Segment one-card cheat-sheet
A one-glance Application Segment revision card pairing the Public-versus-Private Service Edge trade-off with the core segment rules: explicit FQDN plus real ports, Bypass Type semantics, Double Encrypt cost, the six-thousand-check ceiling, and the one-Segment-Group cardinality rule. A summary card in three columns. Column one contrasts the Public Service Edge, which is zero-hardware but hairpins local traffic to a Zscaler PoP, against the Private Service Edge, which brokers locally for low latency and data residency but must be hosted, patched and licensed. Column two lists the segment golden rules: use explicit FQDNs and only the real ports never zero to sixty-five-thousand, default Bypass Type to Never because Always logs nothing, enable Double Encrypt only for plaintext protocols at roughly two times connector load, and keep wildcard plus wide ports away from the six-thousand-target health-check ceiling. Column three states the cardinality and policy rules: a segment belongs to exactly one Segment Group, rules target Segment Groups not bare segments, and the effective Timeout is the minimum across matching rules. Application Segments on one card Public vs Private Edge Public Service Edge zero hardware, default but hairpins local apps to a PoP +2–4 hops for same-DC apps Private Service Edge (PSE) customer-hosted broker low latency for local apps data residency / DR licensed; you host + patch it Choose PSE when… latency-sensitive local-DC app compliance / sovereignty cloud-event resilience Else: Public is simpler + cheaper Segment golden rules Domains + ports explicit FQDN + only real ports NEVER 0–65535 · exclude DNS 53 Bypass Type Never = brokered + logged Always = direct, ZERO logs Double Encrypt plaintext protocols only ~2× connector load Health Reporting None / On Access / Continuous ~6,000 targets/connector ceiling Wildcard + all ports = brownout Chain & cardinality Segment Group a segment lives in EXACTLY one Access Policy targets GROUPS, not bare segments segment not in group = default-deny Server Group Dynamic Discovery resolves FQDNs Timeout Policy min idle 10 min · min-wins Golden rule Define the app tight: explicit FQDN + real ports, Never bypass, one Segment Group — or nobody gets in.
Your last-minute revision card — the Public/Private trade-off, the segment golden rules, and the cardinality that makes "authenticated but blocked" happen.
Prove the segment works — from the access log, not the config screen

Never trust "the connector is green" or "the segment is enabled" as proof. Confirm it the right way: the user's access log shows an ALLOW against the expected rule and the expected Application Segment, and the session reaches the app (not APP_NOT_REACHABLE). If Bypass Type is Always you will see no log at all — that is the tell. Green is tunnel health; the access log is access truth.

👉 You can now define an Application Segment the right way, avoid the Always-bypass and 6,000-check traps, and explain why a segment must live in exactly one Segment Group. Lock it in below, then go hands-on in the App Connector lab.

🤖 Ask the AI Tutor

Tap any question — instant, scoped to this lesson. No login, no waiting.

Pre-curated from Zscaler docs + community Q&A, scoped to this lesson. For a live prod issue, paste your export into chat.techclick.in.

📝 Wrap-up assessment — six more

You've answered 4 inline. Six left. 70% (7 of 10) marks the lesson complete on your profile. Tap Submit all answers at the end.

Q5 · Analyze

A connector's CPU is pegged even at idle, the health cycle takes 12 minutes, and brokering picks connectors at random. The culprit segment is *.corp.local with a TCP range of 0-65535. What is the root cause?

Correct: b. A wildcard FQDN with a 0–65535 port range makes each connector probe ~65,534 ports per resolved IP, blowing past the ~6,000-target health-check ceiling — that is exactly what pegs CPU, stretches the cycle and randomises brokering. Fix with explicit FQDNs + only the real ports. (a) doubles load but does not create the probe explosion; (c)/(d) cause different symptoms.
Q6 · Analyze

A user matches two Timeout Policy rules: one sets Reauth Idle to 24h, the other to 8h. What is the effective reauth interval, and why?

Correct: c. When multiple Timeout rules match, ZPA applies the MINIMUM value — the stricter 8h wins. That is why sensitive segment groups get tighter idle timeouts. Timeout Policy also runs after Access Policy, so a granted session is still subject to reauth.
Q7 · Analyze

All App Connectors disconnect instantly after an SSL-inspection appliance is inserted in their egress path, and never reconnect; logs show TLS validation errors. What specifically breaks?

Correct: d. The connector pins the Service Edge cert, so any re-signed certificate from an inline inspection appliance is rejected regardless of trust. The permanent fix is to bypass all ZPA cloud domains (*.zpath.net, *.zscaler.com, *.zpa.net) before TLS termination. (a)/(b)/(c) do not produce instant TLS-validation disconnects.
Q8 · Analyze

A broad ALLOW rule sits at order 1 and a specific DENY rule for contractors sits at order 5. The DENY never fires and contractors keep getting in. What ZPA evaluation behavior explains this?

Correct: a. ZPA Access Policy is first-match, top-down with an implicit default-deny at the bottom. A broad ALLOW above a narrow DENY shadows it — reorder the DENY above the ALLOW. (b)/(c)/(d) misstate how the engine evaluates.
Q9 · Evaluate

A latency-sensitive app in your own datacenter suffers because traffic hairpins out to a far Zscaler PoP and back. Which design choice best fixes it, and what is the trade-off?

Correct: b. A Private Service Edge brokers sessions locally, removing the cloud round-trip for on-prem users and keeping traffic in-region — at the cost of hosting, patching and licensing it. (a) destroys zero-trust visibility; (c) causes a health-check brownout; (d) adds ~2× load, slowing things down.
Q10 · Evaluate

Given CVE-2025-54982 (Zscaler's SAML SP failed to verify the IdP signature, allowing forged assertions and full ZIA+ZPA auth bypass), which conclusion about ZPA's trust dependencies is best supported?

Correct: c. Your carefully-scoped segments only matter for a correctly-verified identity; the CVE showed the SAML trust sits upstream of all per-app control. It was patched server-side across all clouds with no customer action, but the lesson stands — confirm your IdP configuration. (a) overstates; (b)/(d) describe remediations that never applied.
Lesson complete — saved to your profile.
Almost! You need 70% (7 of 10) — re-read the path that tripped you up and tap "Try again".

🧠 In your own words

Type one line: why does an Application Segment need EXPLICIT ports instead of 0-65535? Then compare to the expert version.

Expert version: Because in Continuous health mode each App Connector probes every FQDN+port combination, and ZPA enforces a ~6,000-target ceiling per connector. A 0-65535 range tells the connector to probe ~65,534 ports per resolved IP, which instantly blows past the ceiling — pegging CPU, stretching the health cycle and randomising brokering. Listing only the real ports keeps the check count tiny and the connector healthy, and it also tightens the app like a keycard so a compromised connector cannot roam every port.

🗣 Teach a friend

Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary.

📖 Glossary

Application Segment
The object that defines a private app by its FQDN/IP plus TCP/UDP port ranges, with flags like Bypass Type, Health Reporting and Double Encrypt. No segment = nobody can reach the app.
Domain Names / IP Addresses
The FQDN, wildcard or IP that ZCC intercepts for a segment. Scope precisely — a wildcard plus wide ports causes a health-check brownout.
TCP / UDP Port Ranges
The exact ports a segment uses. Always explicit — never 0–65535. Zscaler recommends excluding DNS port 53 from segment ranges.
Bypass Type
Per-segment setting (Never / Always / On Net) that decides whether ZCC routes traffic through ZPA. Never = brokered + logged; Always = direct and ZPA logs nothing; On Net = direct only on the corporate network.
Health Reporting
Per-segment probing mode: None (no probes), On Access (probe on user request), Continuous (probe every FQDN+port on a cycle, ~20/sec). Continuous can hit the ~6,000-target ceiling.
6,000-check ceiling
The ~6,000 health-check targets per App Connector that ZPA enforces in Continuous mode. checks ≈ (FQDNs × IPs-per-DNS) × (TCP+UDP ports); wildcard + wide ports blows past it.
Double Encrypt
An optional inner TLS layer for plaintext protocols (HTTP/FTP/Telnet/RDP-no-TLS); it counts double against connector capacity, so 100 Mbps behaves like 200 Mbps.
Segment Group
A container that bundles Application Segments. A segment belongs to exactly ONE Segment Group, and Access Policy rules target the group, never a bare segment.
Server Group
Links app destinations to App Connector Groups. With Dynamic Discovery on, it resolves FQDNs at request time instead of using a static IP list.
Access Policy first-match
Rules evaluate top-down and the first match wins, with an implicit default-deny at the bottom — so narrow DENY rules must sit above broad ALLOW rules.
Timeout Policy
Rules that force reauthentication. Reauth Idle Timeout minimum is 10 minutes (or Never); the effective value is the minimum across all matching rules, applied after Access Policy.
Service Edge
The broker that stitches the ZCC-side and connector-side tunnels. Public = multi-tenant Zscaler cloud; Private (PSE) = customer-hosted for low latency and data residency.
App Connector
A lightweight outbound-only Linux VM inside your network that dials out to the Zscaler cloud and proxies user sessions to private apps — zero inbound ports.

📚 Sources

  1. Zscaler Help — Configuring Application Segments (Name, Status, Health Reporting, Bypass Type, Double Encrypt, Domain Names/IPs, TCP/UDP Port Ranges, Segment Group, Server Groups; exclude DNS port 53). help.zscaler.com/zpa
  2. Zscaler Help — About Connector Provisioning Keys + About Timeout Policy (provisioning-key enrolment to /opt/zscaler/var/provision_key mode 644; Reauth Idle min 10 min, minimum-wins). help.zscaler.com/zpa
  3. Community deep-dive — Zscaler app-segment ports and wildcard flow (Continuous health probes every FQDN+port; ~6,000-target ceiling; wildcard + 0-65535 = high CPU and erratic brokering). cordero.me
  4. Practitioner reviews — ZPA pros/cons (256-rule cap, 48 connector-groups-per-rule cap, "Connected but no traffic", NTP non-negotiable, latency tax fixed by Private Service Edge). peerspot.com / r/Zscaler
  5. NVD — CVE-2025-54982, Zscaler SAML SP signature not verified (CWE-347, CVSS 9.6) → forged SAML assertion → full ZIA+ZPA auth bypass; patched server-side, no customer action. nvd.nist.gov
  6. Community control-channel evidence + Zscaler Cyber Academy ZDTA blueprint — connector outbound TCP/UDP 443 (DTLS Z-Tunnel 2.0), systemd zpa-connector, and ZPA exam objectives (segments, first-match Access Policy, SAML/SCIM). nathancatania.com / zscaler.com

What's next?

You can now define a private app the right way. Next, go deeper on the rule that gates it: first-match ordering, AND/OR criteria and device posture in the ZPA Access Policy.

Next · ZPA Access Policy — first-match, AND/OR, posture → Practice on exam.techclick.in →