Prove Zscaler is working — first tool + proof field

1. Why “is it working?” is five questions

Operators collapse five failures into one sentence. The laptop never reached Zscaler. The site GRE is down. Policy blocked the attachment. Access Policy never allowed the CRM. The hop between the Public Service Edge and Salesforce is dying. Those are five first clicks.

This page is the night-shift desk for proof. The factory taught the exchange. Lesson 13 teaches which log store to hunt. Here you learn the five tools you actually open, in order, when someone asks you to prove Zscaler is working.

Hero · five tiles, one ticket

2. Mental model — five proof tools

Memorise five named objects before you click. Each tool is allowed to prove one thing. Over-claiming a field is how you ship a bad change at 02:00.

3. Decision flow — ticket → first tool

Flowchart first. Do not open the policy editor until a diamond says so.

Path · pick the branch before the menu

4. How to choose — first tool + proof field

Print this next to the Admin Portal. If you cannot recite the proof field, you are not ready to change anything.

5. Runbook Side A → B → C

Side A proves the ZIA wire and the internet/SaaS transaction. Side B proves the private-app session. Side C proves the path the user felt. On a messy Sev-2, do them in this order until a field lights up.

Side A — Wire, Web, Tunnel (ZIA)

1. Prove the browser hit a Public Service Edge

   On the user’s device open https://ip.zscaler.com. Official article: Verifying a User’s Traffic is Being Forwarded to the Zscaler Service. If the page says the request did not come from a Zscaler IP, stop. There is no Policy Action to chase. Fix PAC / Z-Tunnel 2.0 / known-location GRE, then reload the page.

2. Open Web Insights, not the policy editor

   Path: Logs → Insights → Web Insights → Logs (About Insights; NSS mapping uses the same path. Older tenants may still say Analytics → Insights Logs → Web). Filter User + the UTC window on the ticket. Add URL or Cloud Application if you already know the destination.

3. Read the two columns that close a policy ticket

   Policy Action — Allowed, Blocked, or Cautioned. Blocked Policy Name — which policy took the action. Add URL Category and Cloud Application so you know what the engine thought it saw. Source: Web Insights Logs: Columns.

4. If Web is empty for a whole site, switch Insights type

   Same Insights family: Tunnel Insights → Logs. Filter Location + time. Read Log Type = Tunnel Event (status change) or Sample (bytes in the one-minute interval). Quote Tunnel Status, Tunnel Type, Tunnel Source IP, Tunnel Destination IP (the VIP), and Event Reason (PSK mismatch, DPD timeout, invalid proposal, lifetime expired). Source: Tunnel Insights Logs: Columns.

Side B — ZPA User Activity (private-app session)

1. Open User Activity, not Web Insights

   Path: Logs → Insights → Diagnostics. From Log Type, select User Activity. Official: Accessing User Activity Diagnostics. Filter Username + Application Segment + time. A private FQDN will not appear as a URL Category hit in ZIA.

2. Read Connection Status, then Policy, then Connector

   Session status codes appear on the User Activity Diagnostics page (Understanding Private Access Session Status Codes). LSS User Activity fields for the same session include ConnectionStatus, Policy, Connector, Application, Server, InternalReason.

3. If there is no User Activity row, switch to User Status

   Same Diagnostics page, Log Type = User Status. That answers “did Client Connector attach to a ZPA Service Edge?” Status codes include Authenticated, Authentication Failed, Disconnected. It does not answer “did CRM load.”

Path:            Logs → Insights → Diagnostics
Log Type:        User Activity
Username:        contractor@lab.example
Application:     CRM-Prod
Quote:           Connection Status + Policy + Connector + Server
If empty row:    Log Type = User Status  (Authenticated / Authentication Failed)

Side C — ZDX hop (the path the user felt)

1. Confirm the app is actually probed

   ZDX does not invent Cloud Path for every SaaS. If Salesforce has no Cloud Path probe, Hop View is empty and you cannot prove a hop. Inventory the top user-facing apps first (Help: Configuring Zscaler Managed / Hosted Probes).

2. Open Cloud Path → Hop View

   Official: Evaluating the Cloud Path. ZDX traces the end-to-end path and measures latency, packet loss, and jitter across hops. Hop View and Command Line View both exist; errors show as icons (Cloud Path Errors). Quote the hop, not the headline score.

3. Treat Score as a pointer

   Understanding the ZDX Score: 0 (lowest) to 100 (highest). Score uses Cloud Path probe metrics — end-to-end latency, packet loss, hops. A 42 versus peers at 81 is a gap. It is not a URL-rule change and it is not a tenant Sev-1 by itself.

6. Five tickets as full stories

These five land every quarter. Memorise first tool + proof field. Times and identities below are lab-only.

Journey · one amber hop is the ticket

ZEVD-01 — Prove the wire (ip.zscaler.com)

01:42 · P2. Priya on a hotel network. Client Connector icon looks green-ish on a phone photo. L1 already drafted a new URL Allow.

First tool: on her browser, https://ip.zscaler.com.

If off-cloud: the page states the request did not come from a Zscaler IP, so she is not going through the Zscaler proxy service. Quote that sentence. Next check is forwarding — PAC returning DIRECT, Z-Tunnel down, or trusted-network disable — not Web Insights policy.

If on-cloud: the request arrived from a Zscaler IP. Now you are allowed to open Web Insights for her user and the failing URL. The My IP page is not Policy Action.

ZEVD-02 — Prove the SaaS transaction (Web Insights)

02:05 · P2. Outlook on the Web opens. Attachments fail after last night’s DLP ship. Someone wants “another Allow for outlook.office.com.”

First tool: Logs → Insights → Web Insights → Logs. Filter User = priya@lab.example, Cloud Application = Microsoft Exchange Online, last hour.

Proof field: page host Policy Action = Allowed; attachment host Policy Action = Blocked and Blocked Policy Name = DLP-PII-OWA-Attach. That name is the ticket. Change that one rule — or narrow its DLP engine — Activate, then re-read the same two columns.

ZEVD-03 — Prove the site tunnel (Tunnel Insights)

02:20 · P1. Pune branch: every desk lost internet after a 02:00 firewall change. Web Insights for that Location is empty. L1 wants a Force re-auth.

First tool: Logs → Insights → Tunnel Insights → Logs. Filter Location + 01:50–02:20 UTC. Look at Log Type = Tunnel Event, not just Sample.

Proof field: Tunnel Type = GRE (or IPSec IKEv2), Tunnel Status flipped, Event Reason = DPD timeout / PSK mismatch / invalid proposal, Tunnel Destination IP = the VIP you think you still allow. Simultaneous 02:00 death is almost never “everyone’s SAML cookie expired together” — cookies stagger.

ZEVD-04 — Prove the private-app session (User Activity)

02:40 · P2. Contractor cannot open crm.internal.example. Application Segment is Enabled. L1 wants the App Connectors restarted.

First tool: ZPA Logs → Insights → Diagnostics · Log Type User Activity. Filter username + CRM-Prod + last 30 minutes.

Proof field: Connection Status + Policy + Connector. Enabled is the object. User Activity is the decision. If the row is empty, switch Log Type to User Status — Authentication Failed means the device never built a ZPA session (token, posture, or Client Connector), so a Connector restart will not help.

ZEVD-05 — Prove the hop (ZDX Hop View)

03:00 · P3. Salesforce “the cloud is slow” for one laptop. Web Insights Policy Action is already Allowed. Someone typed Sev-1 in the channel.

First tool: ZDX → that user → Salesforce → Cloud Path → Hop View.

Proof field: the hop whose latency / packet loss jumped — often ISP → Public Service Edge, or Edge → Salesforce — plus the path-change time. Score 42 versus peers 81 is the pointer. It is not a URL Allow and it is not a tenant outage by itself.

7. Traps + close-the-ticket proof

Proof · named field, then Closed

Sources

• Zscaler Help — Verifying a User’s Traffic is Being Forwarded to the Zscaler Service (ip.zscaler.com My IP Address; IPv6 caveat)
• ip.zscaler.com — My IP Address (live check; off-cloud wording)
• Zscaler Help — About Insights (Logs → Insights)
• Zscaler Help — About Insights Logs (Web, Tunnel, and sibling types)
• Zscaler Help — Web Insights Logs: Columns (Policy Action, Blocked Policy Name, URL Category, Cloud Application)
• Zscaler Help — Web Insights Logs: Filters
• Zscaler Help — NSS Feed Output Format: Web Logs (maps fields to Logs → Insights → Web Insights → Logs)
• Zscaler Help — Tunnel Insights Logs: Columns (Tunnel Status, Tunnel Type, Event Reason, Log Type Sample / Phase 1 / Phase 2 / Tunnel Event)
• Zscaler Help — Tunnel Insights Logs: Filters
• Zscaler Help — Configuring GRE Tunnels (monitor in Tunnel Insights)
• Zscaler Help — Configuring an IPSec VPN Tunnel (Logs → Insights → Internet & SaaS — Tunnel Insights)
• Zscaler Help — Accessing User Activity Diagnostics (Logs → Insights → Diagnostics · Log Type: User Activity)
• Zscaler Help — Accessing User Status Diagnostics
• Zscaler Help — Understanding Private Access Session Status Codes
• Zscaler Help — Understanding User Activity Log Fields (LSS: ConnectionStatus, Policy, Connector, InternalReason)
• Zscaler Help — Evaluating the Cloud Path (Hop View; latency, packet loss, jitter)
• Zscaler Help — Cloud Path Errors
• Zscaler Help — Understanding the ZDX Score (0–100; latency, packet loss, hops)
• Zscaler Help — Evaluating User Details

Related: Blog 1 · Zscaler exchange factory · Lesson 13 · which log answers which ticket · ZIA authentication · ZIA GRE + IPSec · ZIA traffic flow · Zscaler practice dashboard