Why is Zscaler blocking a website?

Usually because of the site's URL category: a URL filtering rule blocks that category, or the site sits in a custom category that a block rule uses. Other common causes are a Cloud App Control rule, a security category such as malware or phishing, a site Zscaler hasn't classified yet, or file type, sandbox or DLP policy on a download.

How do I find which Zscaler rule blocked a URL?

Search the ZIA web logs (Web Insights) for the user and the host around the time it happened. The log entry shows the policy action, the URL category and the rule that decided it. Without the logs, look up the host's category, check which custom categories contain it, and walk your URL filtering rules from the top: ZIA applies the first rule that matches.

Why does an app fail behind Zscaler when the website works in a browser?

Most often the app pins its certificate, so it refuses the certificate Zscaler presents during SSL inspection. You'll see a connection or certificate error in the app and no block page. The fix is a narrow Do Not Inspect rule for that app's traffic. On office networks, apps that can't handle Zscaler's login prompt need an authentication exemption instead.

Is it safe to allow a site that Zscaler blocks?

Only after you know why it was blocked. A policy block, such as a category your company doesn't allow, is a business decision. A security block, such as malware or phishing, should stay. If the site is unknown, check it first or open it through browser isolation. When you do allow it, allow the exact host, not the whole domain or category, and review the exception later.

Why is Zscaler blocking this site? A troubleshooting runbook

By Ashu Arun Sethi, Zscaler-certified (Zscaler ACE), HuCortex · Updated 25 October 2026

Start with what the user actually sees, because a Zscaler block page, a certificate error and a login loop have different causes. Then find the rule that decided it: the host's URL category, any custom category that contains it, and the first URL filtering rule that matches. Fix it as narrowly as you can (one exact host, one app, one user group), activate, and retest.

Start with the symptom

"Zscaler is blocking it" covers several different problems. Ask for a screenshot and the exact address before touching policy.

What the user sees	Likely cause	Where to look
Zscaler block page naming a category	A URL filtering or Cloud App Control rule blocks that category	The category, then the rules that use it
Block page naming a security category (malware, phishing, suspicious)	Security protection, not policy	Treat it as a possible threat. Don't allow it to close the ticket
Caution page with a Continue button	A rule with the Caution action	Working as designed, unless the rule is too broad
Site opens in a read-only isolated browser	A rule with the Isolate action, often for unknown sites	The rule and its category
Browser works, but the app shows a connection or certificate error	SSL inspection on an app that pins its certificate	SSL inspection policy
Login prompt loops, or a background app fails only on the office network	Zscaler authentication the app can't complete	Authentication exemptions
Page loads but a download is blocked or held	File type control, sandbox or DLP	Those policies and their logs
Block page for a site nobody has heard of	The site isn't classified yet (Miscellaneous or Unknown)	Handling uncategorized URLs

The runbook

Get the exact host, the user and the time. app.example.com and example.com can be classified and handled differently, and the time lets you find the log entry.
Find the log entry. In the ZIA web logs (Web Insights), filter by the user and the host. The entry shows the policy action, the URL category and the rule that decided it. This is the fastest route when you have log access.
Check the category. Look up how Zscaler classifies the host, and check whether any of your own custom categories contain it. A forgotten entry like .example.com in an old block category catches every subdomain.
Walk the URL filtering rules from the top. ZIA applies the first rule that matches the user, location and category. A broad block rule above your allow rule wins.
Check the layers outside URL filtering. Cloud App Control is evaluated before URL filtering, so a cloud app rule can block an app whatever the URL rules say. SSL inspection, authentication, security protection, file type control, sandbox and DLP can each stop a request too.
Decide whether it should be allowed at all. A security block should stay. A policy block is a business decision, so check who owns that policy.
Fix it narrowly, activate, and retest with the user. ZIA changes aren't enforced until the configuration is activated.

Fix it without opening more than you need

Allow the exact host, not the whole domain and never the whole category. app.example.com is a fix; .example.com is a policy change.
Isolate when you're unsure. Browser isolation lets the user read the site while keeping its code off their device.
For certificate pinning, exempt only the app. A Do Not Inspect rule for that app's traffic fixes it; turning off inspection for the whole site removes your visibility for every browser too.
For authentication, exempt one host, not a broad category.
Write down why, with the ticket number, and review exceptions regularly. Allow lists only grow unless someone prunes them.

Help desk checklist

Screenshot, exact address, user and time collected
Symptom matched to a cause (block page, certificate error, login loop, download)
Category and deciding rule found
Security block? Escalate, don't allow
Narrowest fix chosen, approved by the policy owner, activated
User retested, ticket records the change and how to undo it

Doing this with Zmate

With Zmate, the whole runbook happens in your Slack channel, and whoever picks up the ticket can do it without knowing the Zscaler consoles.

Ask why. /zmate why app.example.com answers in seconds: which of your categories contain the host (and the entry that matched), how Zscaler classifies it, any security alert, and the URL filtering rules that decide it, in the order Zscaler applies them. Anyone in the channel can ask, on the free Starter plan.
Check an unknown site. For a site Zscaler hasn't classified, /zmate investigate-url gives a trust score with the reasons behind it and a recommendation, with Allow, Isolate and Block buttons on the card. /zmate scan-url opens the page in an isolated browser and sends you a screenshot privately.
Fix it narrowly. Each change shows exactly what will happen and waits for a Zmate admin to approve it, and it's live as soon as they do:
- /zmate url-allow app.example.com allows that exact host, nothing broader.
- /zmate url-isolate app.example.com lets people read it through browser isolation.
- /zmate cert-pin app.example.com fixes an app that pins its certificate. The app works again, and browsers visiting the same host are still inspected.
- /zmate auth-exempt add app.example.com for an app that can't handle the login prompt.
The last two also need a 6-digit code from the admin's phone.
Undo in one line. url-unallow, url-unisolate, cert-unpin and auth-exempt remove reverse each fix, and the channel keeps the record of who asked and who approved.
Keep exceptions honest. /zmate allowed lists every site your team has allowed or isolated through Zmate, flags any that Zscaler has since classified or marked as risky, and offers a button to remove or block it. A daily check posts any newly flagged ones to the channel.

Example, with a made-up host (replies shortened):

/zmate why app.example-crm.com

🔎 Why: app.example-crm.com
Your categories: none of your custom categories contain it
Zscaler's classification: MISCELLANEOUS_OR_UNKNOWN

URL filtering rules that use these categories (ZIA applies
the first rule that matches the user):
• 4  Block unknown sites: BLOCK  ·  via MISCELLANEOUS_OR_UNKNOWN

/zmate url-allow app.example-crm.com
   (an admin approves)
✅ URL allowed: app.example-crm.com
Run /zmate url-unallow app.example-crm.com to reverse.

Asking questions is free on Starter. Changes need Pro. Zmate connects through Zscaler's official APIs, with access your team grants and can withdraw at any time, and it doesn't use AI.

Start free with Zmate

FAQ

Why is Zscaler blocking a website?: Usually because of the site's URL category: a URL filtering rule blocks that category, or the site sits in a custom category that a block rule uses. Other common causes are a Cloud App Control rule, a security category such as malware or phishing, a site Zscaler hasn't classified yet, or file type, sandbox or DLP policy on a download.
How do I find which Zscaler rule blocked a URL?: Search the ZIA web logs (Web Insights) for the user and the host around the time it happened. The log entry shows the policy action, the URL category and the rule that decided it. Without the logs, look up the host's category, check which custom categories contain it, and walk your URL filtering rules from the top: ZIA applies the first rule that matches.
Why does an app fail behind Zscaler when the website works in a browser?: Most often the app pins its certificate, so it refuses the certificate Zscaler presents during SSL inspection. You'll see a connection or certificate error in the app and no block page. The fix is a narrow Do Not Inspect rule for that app's traffic. On office networks, apps that can't handle Zscaler's login prompt need an authentication exemption instead.
Is it safe to allow a site that Zscaler blocks?: Only after you know why it was blocked. A policy block, such as a category your company doesn't allow, is a business decision. A security block, such as malware or phishing, should stay. If the site is unknown, check it first or open it through browser isolation. When you do allow it, allow the exact host, not the whole domain or category, and review the exception later.