When a WAF fault is taking down the business it's supposed to protect, the fastest fix depends entirely on how it's deployed — transparent proxy, reverse proxy, bypass/out-of-path monitoring, or bridge mode each has its own bypass path, and using the wrong one wastes the minutes that matter most.
By the AtlasCommTech engineering team — 13 years of carrier & enterprise network deployments · Updated July 2026
Before touching any configuration under pressure, confirm which of the four deployment modes you're actually running — the bypass mechanics aren't the same for any two of them.
Whether a WAF fault can take down the business it protects, and what "bypass" even means to fix it, depends entirely on whether the device sits inline in the traffic path or only watches a mirrored copy of it. Transparent proxy, reverse proxy and bridge mode are all inline — a fault there can genuinely stop traffic, and each has its own emergency recovery mechanics. Bypass/out-of-path monitoring mode isn't inline at all, so a device fault there structurally can't interrupt business, and the correct response is to recognize that rather than start changing configuration.
What follows is a map of what "in the path" actually means for each mode, the emergency recovery steps for each with the exact console paths, a staged verification and rollback ladder, a post-incident review checklist, the gotchas that waste the most time under pressure, and 5 FAQ answers from real deployments.
Whether the device is genuinely inline decides whether it needs an emergency bypass procedure at all.
Compare your actual deployment against this map before doing anything else — it tells you which of the procedures below actually applies.
Diagram labels are kept in English for engineering clarity.
Only the three inline modes need an emergency bypass procedure at all — a fault in bypass/out-of-path monitoring mode cannot interrupt business traffic by definition, because the device was never in the forwarding path to begin with.
Each mode's bypass mechanics are different — here's the exact recovery path for each, in the order to try them.
Two software-level recovery types before hardware: disable the protected site, then switch the device itself to physical bypass.
Configuration > Protected Sites > [site] > Enable [ ] unchecked
Apply Changes ... Apply changes successful
// business restored? if not, escalate to physical bypass below
System > (scroll to runtime section) > Running Mode: [ Physical Bypass ]
[Switch Running Mode] ... Switch successful
// device is now hardware-bypassed -- traffic flows around every WAF engine entirelyTwo recovery types: an application-layer allow-all rule first, then a network-level bypass if that alone doesn't restore business.
Configuration > Application Layer Access Control > Create Rule
Match type: URL Pattern: .*
Match mode: Match Action: Allow Status: Enable Scope: All
Save Rule -> drag to position #1 -> Apply Rules ... applied
// business restored? if not, the fault is below layer 7 -- bypass at the network level instead
// diversion switch: remove inbound/outbound diversion ACL for this site
// or: gateway device -- cancel NAT mapping / domain binding, point traffic at the real server IPThis is the one deployment mode with no emergency procedure to run at all — and confirming that is itself the check.
Because a bypass-mode WAF only ever receives a mirrored copy of traffic and was never part of the forwarding path, a fault on the device — a crash, a full disk, a stuck detection engine — has no way to interrupt business traffic. If a protected site is down while the WAF is running in this mode, the WAF is not the cause; look at the real forwarding path instead. Adjusting the switch's mirroring/SPAN configuration is a separate, non-emergency admin task, not something to touch under outage pressure.
The fewest software levers of the four — recovery goes straight to the hardware level.
Bridge mode has no equivalent app-layer allow-all rule to fall back on before the hardware level, because the device is a Layer 2 bridge, not a proxy. The two recovery types are: power the unit off entirely, so its physical bypass relay engages automatically, or jumper a cable around the device directly. Either restores the raw link; neither is graceful, and the site should be treated as fully unprotected until the underlying fault is fixed and the device is deliberately brought back in-line.
Rolling a bypass back in the wrong order can hide the fact that the actual fault is still there.
Once you know which mode you're in, these five account for most of the wasted minutes during an actual outage.
SYMPTOMAn engineer starts hunting for a bypass procedure for a WAF running in bypass/out-of-path monitoring mode during an outage.
CAUSEOut-of-path monitoring mode only ever sees a mirrored copy of traffic — it was never in the forwarding path, so a fault on the device structurally cannot be the reason a site is down.
FIXIf a site is down while the WAF is in this mode, stop looking at the WAF entirely and check the real forwarding path — routing, the real gateway, the server itself. Confirming the mode is the check; there's no bypass step to run.
SYMPTOMA reverse-proxy access-control allow-all rule is created and saved, but the site is still being blocked.
CAUSEAccess-control rules are evaluated in order. An allow-all rule sitting anywhere below an existing blocking rule never gets reached, because the earlier rule already matched and acted first.
FIXAfter saving the rule, drag it to position #1 in the rule list and click "Apply Rules" — creating the rule and applying it are two separate steps, and skipping the drag-to-top step is the single most common reason this bypass appears to fail.
SYMPTOMThe allow-all rule is confirmed applied and correctly prioritized in reverse-proxy mode, but the site still won't come back.
CAUSEAn access-control bypass only addresses the security-engine layer. If traffic is arriving via a diversion switch's ACLs or a gateway NAT/domain-binding rule that's itself part of the problem, an allow-all rule inside the WAF changes nothing about how traffic gets to it in the first place.
FIXEscalate to the network level: remove the diversion switch's inbound/outbound diversion ACLs, or cancel the gateway's NAT mapping or domain binding, so traffic goes straight to the real server IP without touching the WAF at all.
SYMPTOMBusiness is restored after switching straight to hardware/physical bypass, but nobody can say afterward which WAF engine actually caused the outage.
CAUSEPhysical bypass rules out every WAF engine at once — rule/security engine, proxy/forwarding engine, and WEB-stats engine alike — so restoring business this way answers "is it fixed" but not "what actually broke".
FIXWhere the outage allows it, escalate through the narrower steps first — disable the referenced rule group, then an allow-all access-control rule, then a single-site disable — before jumping to physical bypass, so each step that restores business also tells you which engine was implicated.
SYMPTOMThe bypass is rolled back and protection is restored, and the same outage recurs within hours.
CAUSEBusiness being restored by a bypass only proves the bypass worked — it says nothing about whether the underlying condition (a resource exhaustion trend, a rule that will trigger again, a hardware fault that hasn't actually been repaired) has been addressed.
FIXConfirm CPU, memory, load and disk are back in their normal ranges and the root cause is actually identified before rolling the bypass back — not just that the site loads again while the bypass is still in effect.
Pulled straight from the field — the ones worth having an answer ready for.
Escalate progressively: disable the rule group referenced by the site, then an allow-all application-layer rule at top priority, then disable the single site (a site-level bridge-through), then switch the whole device to bridge/pass-through mode, and use physical/hardware bypass or a power-off only as the last resort. Each step rules out a different engine, and the earlier, narrower steps leave you the most information to diagnose with afterward.
No. Because the device only ever sees a mirrored copy of traffic in that mode, a WAF fault there structurally cannot take business down. If a site is down while the WAF is in bypass monitoring mode, look at the real forwarding path, not the WAF.
Escalate to the network level: log into the diversion switch and remove the inbound and outbound diversion ACLs, or cancel the gateway's NAT mapping or domain binding so traffic goes straight to the real server IP without touching the WAF at all.
Confirm from an actual client test, not the gateway or the WAF's own console. Confirm CPU and memory under 60%, CPU load under 30, disk under 70%, and confirm alert-log volume is back in its normal per-site range (roughly 10,000-50,000 entries a day) before rolling the bypass back and calling it closed.
One combined runbook, but it has to branch by mode at the very first step, because the mechanics don't overlap: transparent proxy falls back to disabling the site then physical bypass; reverse proxy falls back to an access-control allow-all then a diversion/NAT-level bypass; bridge mode falls back straight to power-off or a jumper cable; and bypass monitoring mode has no bypass procedure at all, because it was never inline to begin with.
This note is built around the Huawei WAF5000-series deployment-mode model — transparent proxy, reverse proxy, bypass/out-of-path monitoring and bridge mode — and the emergency-maintenance field cases behind it. If your WAF is a different vendor or firmware version, the exact console paths will vary, but the underlying logic — whether the device is genuinely inline, and which layer each bypass step rules out — carries over directly. It doesn't cover clustered/HA WAF pair failover in depth, or SD-WAN overlay deployment scenarios.
Tell us your deployment mode — transparent proxy, reverse proxy, bypass monitoring, or bridge — plus what you've already tried, and we'll help you read it.