First, the vocabulary

The rest of this article talks about GET requests, POST requests, CONNECT, SNI and responses as though everybody works with them daily. Plenty of people who have to understand ZIA policy do not, and the enforcement order makes very little sense without them.

So this section is a short primer on what actually happens when a browser opens an HTTPS page. None of it is Zscaler-specific — it is how the protocols work, and it would be equally true with any proxy, or with none at all. If it is already familiar, skip to the next section.

One request, eight stages

A user types an address and presses enter. To the user that is one action. To the network it is a sequence, and each step exposes something different to anything sitting in the path.

Resolving the name. Before anything can be sent, the hostname has to become an address. At this point the only information in play is the name being looked up and the answer that comes back.

Opening the transport. A TCP connection, or a QUIC session over UDP. What is visible is an address and a port — enough to know that something is talking to something, and nothing about what.

Reaching the destination. This step differs depending on how traffic is being forwarded, which is the subject of the next figure. In one arrangement the browser issues a CONNECT naming the destination. In the other it simply opens a connection, and the domain has to be learned elsewhere.

Beginning TLS. The client sends a ClientHello, and inside it the Server Name Indication — the SNI — which states which hostname the client wants. The SNI travels in the clear. This single fact is why a security platform can make domain-level decisions on encrypted traffic without decrypting anything, and a great deal of policy depends on it.

The server responds with its certificate. Historically this was another way to learn the destination name when no SNI was present. It is becoming less useful: under TLS 1.2 the certificate is sent in the clear, but under TLS 1.3 it is encrypted as part of the handshake. Treating it as a dependable fallback is increasingly optimistic.

The handshake completes, keys are agreed, and from here everything is encrypted.

The request, and then the response. This is where the method, the full URL, the headers and the body finally exist — and where an uploaded file or a downloaded document lives. On the wire they are indistinguishable from noise unless something is decrypting.

One caveat, since this article is careful about such things elsewhere: where Encrypted Client Hello is deployed, the SNI assumption in stage four no longer holds. It is not yet widespread, and it is worth watching.

Two ways traffic arrives, and two first questions

The third stage above is where a real difference appears, and it changes what the first usable piece of information is.

With an explicit proxy, the browser has been told there is a proxy and addresses it deliberately. For an HTTPS destination it issues a CONNECT request naming the host and port — CONNECT portal.example.com:443 — and asks the proxy to open a tunnel. The destination domain is therefore stated in the clear, in an ordinary HTTP request, before any TLS begins.

With transparent forwarding — a GRE or IPsec tunnel from a location, or a tunnel established by an endpoint client — the browser has no proxy configured. As far as it is concerned it is connecting straight to the destination. The steering happens underneath, and no CONNECT request is ever generated. What arrives is the TLS ClientHello, and the domain has to be read from the SNI.

Both paths end up able to make a domain-level decision. They simply learn the domain from a different place, at a slightly different moment, and that is enough to matter when you are reconstructing why something was allowed or blocked.

There is no such thing as an HTTP packet

This one clears up a confusion that turns up constantly in troubleshooting conversations, usually in the form of somebody asking to see “the HTTP packet”.

An HTTP message is a logical thing: a method, a URL, headers and possibly a body. It is what a policy wants to read, and it has no fixed size.

That message is carried inside TLS records, which encrypt it. One message can span several records, and one record can carry parts of more than one message.

Those records are carried inside TCP segments, or divided differently again by QUIC over UDP. And those in turn travel as IP packets, which is what is actually on the wire.

The important part is that none of these boundaries line up. A single HTTP request can be spread across many packets, and a single packet can contain the tail of one thing and the beginning of another.

GET, POST and the response are three different subjects

Finally, the distinction that matters most for everything that follows, because the enforcement order treats these three as genuinely different things.

A GET request asks for something. It carries a destination, a method, a URL and headers. What it does not carry is a body being uploaded, and nothing has been returned yet. There is no file to scan, because no file has arrived.

A POST request sends something. It carries everything a GET carries, plus an outbound body: form data, a submitted document, an uploaded file. This is the moment where content leaving the organization exists.

A response is what comes back: a status, headers, and an inbound body — a page, a document, a downloaded file. This is the moment where content arriving at the organization exists.

Hold on to that, because the next few sections are built on it. When the platform applies a different set of policies to each of the three, it is not being arbitrary. It is applying the policies that have something to read.

2. “Why is there no NOT?”

Here is an objection I have heard more than once, usually from somebody competent, usually about two weeks in.

Many ZIA policy criteria are expressed through combinations of AND between criterion families and OR within selected families. The exact selectors vary by policy. A policy may, for example, treat users, groups or departments as alternatives within one family while combining that result with locations, time and other criteria.

Where a policy does not expose an exclusion selector, the usual supported design is structural: place a narrow exception rule above the broader rule and let rule order determine which one matches first. Some policy types provide dedicated exception constructs, exclude options or alternative evaluation modes, so this should not be treated as a universal statement that every ZIA policy behaves identically.

What you are actually paying for

A service running globally and evaluating policy at scale has to favour constructs that remain predictable, supportable and understandable under operational pressure.

You are buying scale, speed and resilience. The trade-off is that not every appliance-era customization has a direct one-rule equivalent.

And the honest question underneath

It is worth asking of each customisation: how much of this is a real requirement, and how much is a technical flourish?

Some exclusions exist because a regulator demands them. Others exist because somebody could build them elegantly, and nobody asked whether two supported rules would have been sufficient.

The truthful answer is that it needs to be validated. That is comfortable in a lab and less comfortable in production, where undocumented behaviour is difficult to support when the original designer is no longer available.

Two rules in a supported construct that anybody can read are not necessarily a compromise. Quite often they are the more maintainable design.

4. Three transactions, three orders

There is not one web-policy sequence. Zscaler documents three separate enforcement orders, with different policies and lengths, depending on whether the web module evaluates an HTTP GET request, HTTP POST request, or the response.

GET request: Custom Malicious URLs, Cloud App Control, URL Filtering, Security Exceptions, Browser Control, Country-Based Blocking, IPS Signature Detection, Suspicious Content Protection, P2P Control and Bandwidth Control.

At this stage ZIA evaluates the outbound request to retrieve a resource. Controls that operate on uploaded or returned files appear in the POST or response sequences instead.

POST request: Custom Malicious URLs, Cloud App Control, URL Filtering, Security Exceptions, Browser Control, Country-Based Blocking, Malicious URL Block, IPS Signature Detection, Suspicious Content Protection, Malware Protection, File Type Control, Data Loss Prevention, P2P Control and Bandwidth Control.

Response: Security Exceptions, IPS Signature Detection, Suspicious Content Protection, Sandbox for known malicious files, Malware Protection, File Type Control, Sandbox for unknown files, AI/ML-based Content Categorization and Bandwidth Control.

A blocking violation stops the policies that follow

Zscaler’s documentation provides a worked example in which File Type Control blocks an outbound PDF before DLP can evaluate the sensitive data inside it. File Type Control appears at position eleven in the POST sequence, before DLP at position twelve.

The file is blocked, but DLP is not triggered and its configured auditor notification is not generated. The immediate security objective is met, while the expected DLP event and compliance notification are not produced.

What Security Exceptions actually does

Security Exceptions is an allowlist configured in the Security Exceptions tab of Malware Protection or Advanced Threat Protection. For a matching URL, the Public Service Edge skips the relevant Malware Protection, Advanced Threat Protection and Sandbox checks identified by the documentation.

It is a targeted exemption from threat controls, not a universal allowlist that overrides every access policy.

6. SSL inspection: the switch that moves everything else

SSL/TLS Inspection determines whether ZIA can expose the HTTP request, headers and payload needed by downstream content controls. It therefore has a wider policy effect than the act of decryption alone.

Inspect. ZIA decrypts the traffic, evaluates the applicable request or response policy sequence against the information now available, and re-encrypts traffic allowed to continue. Which controls run still depends on transaction type, enabled policies, configuration and content.

Do Not Inspect and Evaluate Other Policies. The traffic remains encrypted. ZIA continues evaluating controls that can operate on visible information. During CONNECT or SNI evaluation, the enforcement documentation identifies the four domain-based checks described above.

Do Not Inspect and Bypass Other Policies. The service bypasses the other web policies for matching traffic. This broad exception should have the narrowest practical scope, a documented owner and a review date.

The absence of a URL Filtering block does not by itself prove that URL Filtering evaluated a transaction. A higher-order SSL/TLS bypass may have prevented downstream evaluation.

Two behaviours around the block page

If SSL/TLS Inspection is disabled but Show EUN for Blocked Traffic is enabled, the Public Service Edge performs inspection on the first HTTPS transaction so it can return an end-user notification.

When the destination domain is known to contain an advanced threat, the connection terminates without an EUN. A block on the CONNECT host header returns HTTP 403; a block on SNI resets the connection.

8. Specific match before rule order

Rule order is a dominant pattern across ZIA policy configuration, and the web enforcement chain stops after a policy blocks a transaction. URL category specificity introduces a separate decision before the relevant URL Filtering rule is selected.

Custom Category 1 contains .example.com. Custom Category 2 contains abc.example.com. A URL Filtering rule blocks everything in Custom Category 1 for a given location.

A request to abc.example.com is not blocked by that rule, because the exact domain matches Custom Category 2, which is not blocked in the example.

A more specific category can therefore create an exception to the coverage expected from a wildcard category. The policy list may appear correctly ordered because the category candidate was resolved before rule order became decisive.

10. Management does not come free

ZIA is not a product you understand once at project level and then simply hand over. It requires operational ownership after go-live.

The platform. Rules drift and exceptions accumulate. Policy needs scheduled review, owners and expiry or review dates for exceptions.

Role separation. The service desk may need to read logs without editing URL categories. Administrative access should be scoped deliberately.

Support capability. Blocked sites, held files and certificate failures need an owned first-line process that can identify the relevant module and policy sequence.

Training. The service desk needs policy and logging basics; administrators need the sequence and interaction model; somebody must own the platform as a whole.

Every product has a learning curve. This one moved where the effort goes.

The operational benefit is substantial: no appliance capacity planning, hardware refresh or local patching cycle. But the effort does not disappear. It moves from keeping infrastructure alive to understanding and governing the service.

And the help is there, if you go and get it

Documentation, courses, certifications, reference architectures, deployment guides and troubleshooting runbooks exist. The organization still has to invest the time to use them.