What is the Zscaler Block Page?
The Zscaler Block Page is the notice page the Zscaler service shows a user when it blocks access to a website, file, or internet application. It appears for policy violations such as a blocked URL category, detected malware, a DLP violation on upload, or a faulty server certificate. Zscaler documentation calls it a Block Notification, part of the End User Notifications (EUN). It matters twice over for operations: it is the most common point where users actually see Zscaler, and it is the first source for diagnosis when a "page doesn't work" ticket comes in.
Zscaler Block Page in detail
Whether the page appears at all depends on the protocol: for HTTP, documentation says it always shows. For HTTPS, it needs active SSL inspection; without it, the user sees only a 403 error or a refused connection instead of the explanatory page. This detail accounts for many confusing tickets where "nothing shows" and yet a policy is applying.
The page's content is configurable: you can display the reason for the block, company name, and logo, plus a custom message and contact fields for IT support with email, phone, and a link to the internal policy. Anyone who wants more control redirects to a self-hosted page through custom configuration; Zscaler then passes along details such as the URL, URL category, the triggering policy, and the reason as parameters. Four block types can be configured separately: URL categorisation, security violation, web DLP, and IdP proxy.
Why the Block Page matters in Zscaler operations
Every block page is a potential ticket. A bare page with no reason and no contact generates calls along the lines of "the internet is broken"; a well-configured page answers half the questions itself: what got blocked, why, and who the user can turn to. The built-in review path for miscategorised URLs also channels appeals into an orderly process instead of onto the phone.
For the helpdesk, the page also doubles as evidence: block type and reason narrow down the triggering policy before anyone even looks at a view. And knowing about the HTTPS special case belongs in every first-line diagnostic runbook, so a bare connection error does not get blamed on the Wi-Fi or the website too quickly.
Common sources of error
- Block page set up with no reason and no contact: users never find out what is stopping them, so they call instead of reading.
- HTTPS special case unknown: a 403 or a refused connection does not get recognised as a policy block.
- No defined review path for miscategorisation: appeals end up scattered across inboxes instead of in the intended review process.
- Block notifications never rehearsed with the team: the helpdesk sees the pages live for the first time during an actual incident.
Block Page in practice: what CentaurNexus contributes
When a user reports a block page, CentaurNexus answers the core question, "why exactly is this blocked?", without Zscaler admin rights. The 360° user search shows the status across ZIA, ZPA, and ZDX for a name or email on one page, including the policy view that explains the block. With Service Tunnel Check, users can test in advance, on their own, whether their problem is even related to Zscaler, which filters out false alarms before the first ticket is even raised. That turns the block page from a ticket trigger into the starting point for a short, evidence-backed answer. The article below shows how users can resolve such cases themselves, with no ticket at all: Zscaler self-service right in the browser.
Related terms
Frequently asked questions about the Zscaler Block Page
Because a company policy has stopped the access: for example a blocked URL category, malware detected in a file, a DLP rule triggered on upload, a used-up time quota, or a faulty server certificate. If the display of the reason is switched on, the specific cause appears right there on the page.
For HTTPS connections, Zscaler can only show the block page if SSL inspection is active. Without inspection, documentation says the service instead returns a 403 error, or the connection gets refused. For the helpdesk, that means a bare connection error can still be a policy block, just without the explanatory page.
Yes. The default page can be extended with the reason, company name, logo, and a custom message, plus contact fields for IT support such as email, phone, and a policy link. Alternatively, a custom configuration redirects to an externally hosted page, to which Zscaler passes details such as URL, category, and reason as parameters.
Zscaler provides a review path for this: users can trigger a review straight from the block page if a URL seems miscategorised, sent either to Zscaler or to an internal address. In parallel, the helpdesk checks which policy applied and, if needed, requests a recategorisation or a documented exception.
Documentation distinguishes four configurable block notifications: URL categorisation, security violation, web DLP violation, and IdP proxy. There are also related notice pages, such as the caution warning, which allows access with just a warning, and the quarantine notice shown during a file analysis. All of them use the same base settings for reason, name, and logo.
- Zscaler Help Portal: Configuring Block Notifications - help.zscaler.com
- Zscaler Help Portal: Understanding Browser-Based End User Notifications - help.zscaler.com
Note: CentaurNexus is an independent product of SourcingBlox GmbH and not an offering of Zscaler, Inc. Product and brand names belong to their respective owners.