A reverse-proxy WAF puts a proxy in front of your origin server instead of software on it. SucuraGuard runs that proxy on our own anycast network — Toronto, Chicago, Frankfurt, and Singapore — terminating TLS, inspecting every Layer-7 request, and forwarding only clean traffic downstream. Attacks are stopped upstream, before they hit your server. Point one A-record, free to start.
A reverse-proxy WAF is an architecture, not just a feature: the firewall runs as a proxy in front of your origin server, so it terminates TLS, inspects Layer-7 requests, and applies rules before traffic ever touches your infrastructure — as opposed to a plugin that runs on your origin after a request has already arrived, or an appliance you deploy and patch yourself. SucuraGuard implements this as an anycast reverse proxy on Sucura's AS398999 network across four PoPs. You register your hostname and origin in Nexus, point one A-record at our anycast VIP, and clean traffic is all that reaches your server. Free to start, plans from $20/mo.
"Reverse proxy" describes where the firewall physically sits relative to your traffic. Instead of your origin server accepting connections directly from the internet, the DNS record for your hostname points at a proxy — in this case, an anycast VIP on our network. Every request for that hostname arrives at the proxy first, not at your server.
The proxy does four things before your origin ever sees a byte of the request. First, it terminates TLS — the encrypted connection ends at the proxy, using a certificate we issue and renew for your hostname. Second, it inspects the decrypted Layer-7 request — method, path, headers, cookies, body, and connection-level signals like TLS and HTTP/2 fingerprints. Third, it evaluates that request against a managed rule set plus any custom rules you've written, alongside bot-scoring, challenge, and rate-limit logic. Fourth, only the requests that pass are forwarded to your origin — usually re-encrypted over a fresh connection from the proxy to your server.
The result is that your origin server's job shrinks to "answer requests the proxy already decided are clean." It never has to parse a malicious payload, absorb a scanner's request flood, or spend CPU cycles evaluating whether a request is an attack — because that evaluation already happened upstream, on infrastructure that isn't your server.
Your hostname resolves to our anycast VIP, so the connection lands at the nearest of four PoPs, not at your origin.
The encrypted session ends at the proxy using an auto-issued certificate, so the request can be read in the clear for inspection.
Managed and custom rules, bot score, rate limits, and challenge logic all run against the request before any decision to forward it.
Only requests that pass reach your origin over a connection the proxy opens — attacks and bad probes never get that far.
There are three common ways to run a WAF. Where the filtering physically happens is the whole difference between them.
Runs as code inside your application — a WordPress plugin, for example — after the request has already arrived at your origin. It adds PHP and CPU load to the same server it's protecting, and a large or malformed request still costs your server resources before the plugin gets a chance to block it.
A hardware box or software instance you deploy yourself, in front of your servers. It can filter upstream of the origin, but you provision it, size its capacity, patch it, and scale it — the operational burden sits with you, not a vendor.
Runs as a managed proxy on our anycast network, upstream of your origin and upstream of our own patching cycle. Filtering happens before your server ever sees the request, and the capacity, uptime, and rule updates are ours to run — you just point one A-record.
Every feature below is live in the product today — nothing on this page is roadmap.
Per account, unlimited domains on every tier. Pick one in the Nexus panel — the Free tier costs nothing to try.