A business system that will not load at all, and one that loads for everyone except the handful of requests a single rule keeps eating, land on the help desk looking like the same ticket. They are not the same fault, and they do not get fixed the same way. Here is how to tell them apart fast, the exact log filters and menu paths to check at each stage, and the root causes that account for most of these tickets.
By the AtlasCommTech engineering team — 13 years of carrier & enterprise network deployments · Updated July 2026
Both look like the same blank page to whoever filed the ticket — the difference only shows up once you go looking for it.
A web application sitting behind a WAF can become unreachable for reasons that have nothing to do with its security rules at all — a broken path to the origin server, an SSL negotiation the client's browser can't complete, or the WAF itself running hot. It can also become unreachable, or partly unreachable, because one of its own protection rules is doing exactly what it was configured to do: blocking a request that looks like an attack but is not one. Treating the second problem as the first, or the other way round, wastes the first twenty minutes of almost every one of these tickets.
What follows is the fault tree this note is built on, the checks for each branch with the exact log filters and menu paths to use, the root causes that show up again and again once you're past the first few checks, and a handful of real FAQ answers pulled from actual field cases.
WAF-related inaccessibility splits into exactly two shapes: the site is genuinely down, or the rule set is stopping traffic that should be allowed through.
Placing the symptom on this tree first saves a lot of backtracking later — it tells you which of the sections below actually applies to what you're looking at.
Diagram labels are kept in English for engineering clarity.
Whether the site is genuinely down is answered by the same operational checks you'd run for any web service — CPU, connectivity, the TLS handshake. Whether a rule is responsible only shows up in three specific logs, and only if the rule was configured to write to them in the first place, which is exactly the trap the next section is built around.
Three different places to look, three different fixes — and one setting that decides whether you'll even see a log entry for what just happened.
Before touching any rule, rule out the causes that have nothing to do with WAF security policy at all.
Status > System Overview -- CPU / memory usage at the time of the fault
Status > Historical Data -- filter: Web Traffic / Web Connections / New Web Connections / Web Requests
System > System Maintenance > Packet Capture
interfaces: Lo, business (protect)
match: the failing GET/POST -- compare client-to-WAF vs WAF-to-origin
// origin sends RST -> server is refusing the request, not a WAF issue
// WAF sends RST to client -> block is happening on the WAF side, check Branch B
System > System Maintenance > Running Mode Switch
bridge passthrough / physical passthrough -- confirms whether the WAF is the variableIf the client actually sees a block page, the log trail is usually there — you just have to look in the right place.
No block page, no obvious log entry, and the business owner swears nothing changed — this is almost always a rule set to block without logging.
Log > Application-Layer Protection Log -- Custom Query, filter by server / client IP
Log > Traffic Control Log
Log > CC Protection Log
// no block entry in any of the three logs, but disabling the rule group fixes it:
Policy > Rule Groups > Search Rule
action = "Block, No Alert" OR action = "Drop, No Alert"
-> change action to "Detect Only" // makes the WAF start logging what it blocks
// once a block entry exists:
Alert Details > Triggered Rule ID > [rule page] > "Add Current URL to Whitelist"
// overlapping whitelist paths -- longer, more specific URL must be listed ABOVE the shorter one
/api/v1/order/query/detail <- list first
/api/v1/order/query <- shorter, overlapping path, listed afterOnce the branches above have told you where the problem sits, these four account for most of what's actually wrong.
SYMPTOMThe business team insists nothing changed, the three protection logs show nothing at the time of the failure, and yet disabling the rule group fixes it instantly.
CAUSEA rule's action can be set to "Block, No Alert" or "Drop, No Alert" — both stop the request exactly like a normal block rule, but neither writes an entry to the Application-Layer Protection Log. From the log's point of view, nothing happened; from the client's point of view, the site is broken.
FIXGo to Policy > Rule Groups > Search Rule, filter for these two actions specifically, and switch them to "Detect Only" during troubleshooting so the WAF starts producing the log entries you actually need to see.
SYMPTOMBusiness access looks like a network fault — intermittent, hard to reproduce, no rule ever seems to be involved — and no amount of log filtering finds anything.
CAUSEWhen the WAF's management interface address falls in the same subnet as the business interface or a protected site's IP, the two can interfere with each other in ways that present as a generic connectivity problem rather than anything the security logs would ever capture.
FIXKeep the admin interface, the business interface and every protected site's IP address on distinct subnets from each other. This is a network-design check, done once, not a per-incident fix.
SYMPTOMOne specific URL — usually one polled or refreshed frequently by a real integration or a busy user — becomes intermittently unreachable, while the rest of the site is fine.
CAUSECC (anti-flood) protection triggers on request-rate patterns, and a legitimate but frequent access pattern to one path can look identical to an automated attack from the rule's point of view.
FIXAdd an exact-match condition for that specific path in the CC rule so it only protects what it needs to, and add the known-good source IP to the CC source IP whitelist rather than loosening the rule's rate threshold for the whole site.
SYMPTOMA URL that should be whitelisted still gets blocked, even though it clearly appears in the whitelist — and a different, shorter URL that shares the same prefix is not blocked at all.
CAUSEMatching runs from the top of the whitelist down, and the first matching entry wins. When one whitelisted URL is a prefix of, or otherwise contained within, another, listing the shorter one first causes it to intercept traffic that was meant to reach the longer, more specific entry beneath it.
FIXPut the longer, more specific URL above the shorter, overlapping one in the whitelist order, so the intended entry matches first.
Pulled straight from the field — the ones worth having an answer ready for.
An explicit block shows the client a 403 or a block page, and — assuming the rule's action is a normal "Block" — it writes an entry to the Application-Layer Protection Log that you can filter on immediately. A silent block uses the "Block, No Alert" or "Drop, No Alert" action: the request fails exactly the same way from the client's side, but no log entry is produced at all, which is why it so often gets mistaken for a network or backend problem.
From the block entry in Application-Layer Protection Log, open Alert Details and click through to the specific rule ID that triggered. On that rule's own page, "Add Current URL to Whitelist" adds only that URL against that specific rule — the rule group keeps protecting everything else exactly as before.
Both are available. Each individual rule has its own URL whitelist, reached from that rule's page. Separately, Rule Groups > URL Whitelist shows the global whitelist for the whole rule group, and lets you review every rule-level whitelist entry underneath it in one place.
Matching runs top to bottom and stops at the first match. When one whitelisted URL is contained within another — for example a longer path that's a subset of a shorter one — list the longer, more specific URL first, or it will never get the chance to match before the shorter entry above it does.
Before touching any rule, rule out the causes that have nothing to do with rule logic: the client PC's own network path, a browser that doesn't support TLS 1.1/1.2, an SSL negotiation mismatch between the WAF and the origin server, the WAF and the origin simply not being able to talk to each other, or the WAF running under enough load that proxying is delayed. Only once those are ruled out does it make sense to start filtering the protection logs.
This note is built around the Huawei WAF's log filters and menu paths — Application-Layer Protection Log, Traffic Control Log, CC Protection Log, and rule group search — plus the field cases behind them. If your WAF is a different vendor, the exact menu paths change, but the underlying diagnostic order — rule out the network and TLS causes first, then check whether logging was even configured to show you the block — carries over directly. It doesn't cover bot-management-specific rule tuning or API-gateway-layer protections in depth.
Tell us whether it's a hard 403 or a silent failure, plus the log entry — or the fact that there isn't one — and we'll help you read it.