Short answer: to troubleshoot slow or failing traffic through Zscaler, test the path to the Zscaler service edge, not just to the final website. Find the edge with ip.zscaler.com, run an MTR over TCP 443 to it, and compare a test from the user's device with an outside-in test from our online MTR.
Step 1: find which Zscaler service edge you are using
From a device whose traffic goes through Zscaler Internet Access (ZIA), open https://ip.zscaler.com. It shows whether the request went through Zscaler and which data center (service edge) handled it. That edge, or your PAC file's gateway hostname, is the target to test.
Zscaler publishes its service edge IP ranges per cloud at config.zscaler.com. They're useful for firewall rules and for confirming that an IP in a traceroute or HAR file belongs to Zscaler.
Step 2: run MTR from the user's device
# Linux / macOS: TCP 443 to the service edge, 100 probes
sudo mtr -rwzbc 100 -T -P 443 <service-edge-or-gateway>
# Windows: built-in, ICMP only
pathping -q 100 <service-edge-or-gateway>On Windows, WinMTR or pathping are the usual choices. Run the test while the problem is happening and save the output for the case.
Step 3: run an outside-in MTR
Run the HardcoreDebug MTR to the same edge with TCP 443. If our server reaches the edge cleanly but the user's test shows loss, the problem is likely on the user's side (Wi-Fi, ISP or home router). If both show loss near the edge, include both reports in your Zscaler support case.
GRE and IPsec tunnels to ZIA
For locations that forward to Zscaler over GRE or IPsec, run the MTR from the tunnel's public source IP towards the tunnel destination (the Zscaler VIP). Loss on that path appears as tunnel flaps or slow browsing for the whole site. For a worked Palo Alto example, see IPsec tunnel between Palo Alto and Zscaler ZIA.
ZDX Cloud Path vs MTR
If you have Zscaler Digital Experience (ZDX), its Cloud Path probes trace hop by hop from the user's device using TCP, UDP or ICMP and report loss and latency per hop, so they give MTR-style data continuously. MTR is still useful for one-off tests, for users without ZDX, and for an outside view that doesn't depend on the client.
Reading the report
- Only loss that continues to the last hop is real. One noisy middle hop is normal.
- A latency jump at the hop that enters the Zscaler network, staying high to the end, can mean the user is connecting to a distant edge. Check
ip.zscaler.comfor the edge location. - If ICMP shows loss but TCP 443 doesn't, users are probably not affected.
Frequently asked questions
How do I run an MTR test to Zscaler?
Find the Zscaler service edge your traffic uses (open ip.zscaler.com from a client behind Zscaler), then run an MTR over TCP 443 to that edge or to your PAC/gateway hostname. Run it from the user's machine and from outside, for example with the HardcoreDebug online MTR, and compare.
Does Zscaler have a built-in MTR?
Zscaler Digital Experience (ZDX) Cloud Path probes give hop-by-hop loss and latency from the user's device. Without ZDX, use mtr, pathping or WinMTR on the client, or an online MTR for an outside view.
Should I use ICMP or TCP to test Zscaler?
Use TCP 443 where you can. It follows the same path as real proxied traffic, and some hops deprioritize ICMP, which shows loss that users never feel.
Why is my traceroute through Zscaler only one hop?
When Client Connector or a PAC file sends traffic to Zscaler, the destination's path is hidden behind the proxy. Trace to the Zscaler service edge itself to see the path from the user to Zscaler.