ZIA war-room command ladder — first tool + one proof field

1. Why a ZIA ticket is five commands

Operators collapse five ZIA failures into one sentence. The laptop never reached a Public Service Edge. The PAC returned DIRECT on hotel Wi-Fi. The branch GRE peer died at 02:00. URL Filtering blocked the attachment host. SSL/TLS Inspection broke a pinned banking app. Those are five first clicks, not one “check Zscaler.”

This page is the night-shift command desk for ZIA only. The evidence desk maps five proof tools across ZIA, ZPA, and ZDX. Here you stay inside Internet & SaaS: wire, PAC/location, site tunnel, Web verdict, SSL exemption. You do not open ZPA Diagnostics or ZDX Hop View until a ZIA field says the problem is not here.

Hero · five tiles, one ticket

2. Mental model — the command ladder

Memorise five named rungs before you click. Each rung is allowed to prove one thing. Climbing two rungs at once is how you Activate a URL Allow on a dead GRE.

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 Activate.

5. Runbook Side A → B → C

Side A proves the wire and who the session is (PAC / Location). Side B proves the site tunnel and the Web verdict. Side C proves the SSL/TLS decision and writes a scoped exemption. On a messy Sev-2, do them in this order until a field lights up.

Side A — Wire, PAC, Location

Primary sources: Verifying a User’s Traffic is Being Forwarded to the Zscaler Service; Identifying the PAC File on a Device Using Browsers; About Locations.

1. Prove the browser hit a Public Service Edge

   On the user’s device open https://ip.zscaler.com. 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. Identify the PAC the browser is actually using

   Official browser path (Chrome-family): Settings → System → Open your computer’s proxy settings, or Help’s Identifying the PAC File article (Menu → Settings → Browser / Network → Change Proxy Settings → Proxies). Quote the PAC URL. Current Admin path for the hosted file: Infrastructure → Internet & SaaS → Traffic Forwarding → Hosted PAC Files. Older tenants still say Administration → Hosted PAC Files.

3. Read PROXY vs DIRECT, then Location

   A PAC is a FindProxyForURL(url, host) file. If the failing host returns DIRECT, ZIA never saw it — Web Insights will be empty for that URL. If it returns PROXY and My IP is still off-cloud, the proxy host/port is wrong or 80/443/9400/9443 is blocked. Then open Infrastructure → Locations → Location Management → Legacy Locations. A session with no static IP / GRE / IPSec / dedicated proxy-port bind lands as unknown / Road Warrior and takes a different policy stack than Pune-GRE.

4. Only then ask whether the other desk is a different Location

   Same Salesforce, two users: one on GRE Location, one on PAC unknown. That is not “Zscaler is flaky.” That is two policy scopes. Quote Location name from the Web row once the wire is up — do not merge them with a tenant-wide Allow.

Device:          user’s browser, not yours
Wire:            https://ip.zscaler.com  → Zscaler IP yes / official off-cloud sentence
PAC URL:         (from OS / browser proxy)  e.g. https://pac.zscalerthree.net/lab.example/pune-pilot-v2.pac
PAC return:      PROXY ${GATEWAY}:80  |  DIRECT
Location:        Pune-GRE-01  |  unknown / Road Warrior
If IPv6-first:   do not rip tunnel from My IP alone — confirm a Web row same minute

Side B — Tunnel Insights + Web Insights Policy Action

Primary sources: Tunnel Insights Logs: Columns; About Insights Logs; Web Insights Logs: Columns.

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

   Path: Logs → Insights → Tunnel Insights → Logs. Filter Location + time. Read Log Type = Tunnel Event (status change), not only Sample (bytes in the one-minute interval). Quote Tunnel Status, Tunnel Type, Tunnel Source IP, Tunnel Destination IP (the VIP), and Event Reason.

2. Memorise the official Event Reason list

   Help lists: Lifetime expired, PSK not found, PSK mismatch, Invalid proposal, DPD timeout, Timeout, Org excluded from DC. Those are firewall / IKE / VIP problems. They are not URL categories.

3. When the wire is up, open Web Insights — not the policy editor

   Path: Logs → Insights → Web Insights → Logs (About Insights. 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.

4. 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. That name is the change — not a second Allow for the marketing hostname.

Tunnel path:     Logs → Insights → Tunnel Insights → Logs
Log Type:        Tunnel Event   (not only Sample)
Quote:           Tunnel Status + Tunnel Type + Event Reason + Location + VIP
Web path:        Logs → Insights → Web Insights → Logs
Filters:         User + UTC window + Cloud Application or URL
Quote:           Policy Action + Blocked Policy Name + URL Category
Empty Web:       do not Activate a Cloud App rule — go back to Side A or Tunnel Event

Side C — SSL exemption (Inspect vs Do Not Inspect)

Primary sources: About SSL/TLS Inspection Policy; Configuring SSL/TLS Inspection Policy; Certificate Pinning and SSL/TLS Inspection; Web Insights Logs: Columns (SSL/TLS Policy Reason).

1. Confirm the failure is TLS, not URL policy

   If Policy Action is already Allowed and the user still sees a certificate error, pinning failure, or a reset, stay on the same Web row and read SSL/TLS Policy Reason. Help documents reasons such as Inspected, Blocked, N/A, Not inspected because of failed client SSL handshake, and Not inspected because of Zscaler best practices. The SSL Policy Reason runbook is the official next hop when that column is “not inspected due to SSL policy rules.”

2. Open the SSL/TLS Inspection policy, not URL Filtering

   Path: Policies → Common Configuration → SSL/TLS Inspection → SSL/TLS Inspection Policy. Rule actions in Help are Inspect, Do Not Inspect, or Block. Do not “fix” a pin by adding a URL Allow — the bytes never decrypted, or the client rejected the intermediate CA.

3. Write a scoped Do Not Inspect — and choose Evaluate vs Bypass

   For certificate-pinned apps, Help’s instruction is to exempt the application from SSL/TLS Inspection. Action = Do Not Inspect. Then choose Evaluate Other Policies (URL Filtering and Cloud App Control still run on what ZIA can see without decrypt) or Bypass Other Policies (Help: bypasses web policies — URL Filtering and Cloud App Control — for that TLS traffic). Bypass is louder than people think. Scope the rule to Cloud Application / URL / destination + a pilot group, not the org.

4. Leave Zscaler-Recommended Exemptions alone unless you meant to

   The predefined Zscaler-Recommended Exemptions rule is enabled by default. Traffic matching it shows SSL/TLS Policy Reason = Not inspected because of Zscaler best practices. That is not your missing Salesforce Allow. Do not disable the recommended rule to “make inspect 100%” on a Sev-2.

5. Prove the exemption on the same user, same host, next minute

   Activate. Re-read Web Insights: SSL/TLS Policy Reason should show the not-inspected / policy-rule reason you intended, and the user should load the pinned app. If the row still says Inspected, a higher-priority Inspect rule is winning — Help also documents “Inspected despite a Do Not Inspect action.”

6. Five tickets as full stories

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

ZIACC-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 for salesforce.com.

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.

ZIACC-02 — Prove PAC / Location (one user, two paths)

01:55 · P2. Hotel Priya is off-cloud. Desk Amit on Pune-GRE opens the same Salesforce. Someone wants to “fix the PAC for the company.”

First tool: identify the PAC URL on Priya’s browser (Help: Identifying the PAC File on a Device Using Browsers). Compare it to Hosted PAC Files. Then open Legacy Locations for Pune-GRE-01.

Proof field: her PAC returns DIRECT for the Salesforce host (or the PAC URL is yesterday’s file), or she is Road Warrior while Amit is Location = Pune-GRE-01. Those are two different ZIA identities. A tenant-wide URL Allow does not put her on the wire.

ZIACC-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.

ZIACC-04 — Prove the SaaS transaction (Web Insights Policy Action)

02:40 · P2. Salesforce login opens. Content / attachment host fails after last night’s URL Filtering ship. Someone wants “another Allow for salesforce.com.”

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

Proof field: login host Policy Action = Allowed; content host Policy Action = Blocked and Blocked Policy Name = URL-Sales-Attach-Pilot. That name is the ticket. Change that one rule — or narrow its URL category — Activate, then re-read the same two columns.

ZIACC-05 — Prove the SSL exemption (SSL/TLS Policy Reason)

03:05 · P2. Corporate banking app dies after the inspect rollout. Salesforce (inspected) is fine. Web Insights Policy Action on the bank host is Allowed or the row shows a handshake failure. L1 wants SSL Inspection disabled for the tenant.

First tool: same Web row → SSL/TLS Policy Reason, then Policies → Common Configuration → SSL/TLS Inspection.

Proof field: Inspected (client rejected the intermediate CA / pin) or Not inspected because of failed client SSL handshake. Help on pinning: exempt the application. Add a scoped Do Not Inspect with Evaluate Other Policies for the pilot group. Leave Zscaler-Recommended Exemptions enabled.

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)
• Zscaler Help — Identifying the PAC File on a Device Using Browsers
• Zscaler Help — Understanding PAC Files
• Zscaler Help — Writing a PAC File (FindProxyForURL)
• Zscaler Help — Using Custom PAC Files to Forward Traffic to Internet & SaaS (Infrastructure → Internet & SaaS → Traffic Forwarding → Hosted PAC Files)
• Zscaler Help — Using Default PAC Files to Forward Traffic to Internet & SaaS
• Zscaler Help — Forwarding Traffic Based on User’s Location Using PAC Files
• Zscaler Help — Choosing Traffic Forwarding Methods
• Zscaler Help — About Locations
• Zscaler Help — Configuring Locations (Legacy Locations; static IP / GRE / VPN credential)
• Zscaler Help — Understanding Sublocations
• Zscaler Help — About Insights (Logs → Insights)
• Zscaler Help — About Insights Logs
• Zscaler Help — Web Insights Logs: Columns (Policy Action, Blocked Policy Name, SSL/TLS Policy Reason)
• Zscaler Help — Web Insights Logs: Filters
• Zscaler Help — Tunnel Insights Logs: Columns (Tunnel Status, Tunnel Type, Event Reason)
• Zscaler Help — Tunnel Insights Logs: Filters
• Zscaler Help — About SSL/TLS Inspection Policy (Zscaler-Recommended Exemptions; best-practices reason)
• Zscaler Help — Configuring SSL/TLS Inspection Policy (Inspect / Do Not Inspect / Block; Evaluate vs Bypass Other Policies)
• Zscaler Help — Certificate Pinning and SSL/TLS Inspection
• Zscaler Help — Best Practices for Testing and Rolling Out SSL/TLS Inspection
• Zscaler Help — SSL Policy Reason Runbook
• Zscaler Help — Policy Reasons

Related: Prove Zscaler is working — evidence desk