You put a reverse proxy in front. Here is what it let through.

When we propose application-layer protection, maintainers answer with the same advice. We take it seriously, so we ran it: a CDN and a hardened web server in front, for 15 days, with real traffic. These are their words, with names and projects removed.

Of those 22,293 requests, 21,110 were refused with a 403 (most of them banned clients), 1,173 were detected attacks and 10 hit rate limits. The edge could not make those calls: it does not know which routes your app serves, its rules judge each request on its own without the app's record of what that client already tried, and its block ends at that one request instead of banning the client across every endpoint of the app.

The busiest banned client sent 5,359 requests in 15 days. The CDN forwarded every one.

They got a 404 only because those files were not there. One leaked .env is a full compromise, and nothing at the edge stopped the attempts.

Any server with a public IP receives direct traffic: scanners do not need your domain name. Whatever is listening on that address is exposed to it, however good the edge in front of the domain is.

fail2ban bans the client IP in the firewall. Behind a CDN, every request to your domain reaches the server from a CDN address, so a firewall rule on the client IP never matches. Only the app, which resolves the real client from trusted proxies, can ban it.

We replayed all 1,149 detections through the production versions. None was on a route the apps serve to their users. 52 are debatable by design: paths a crawler or browser can request on its own, flagged because the app does not serve them. 38 were triggered by a header or the body, which the web server does not log, so their exact trigger cannot be confirmed from the logs; all of them were on paths the apps do not serve.

A distributed attack spreads its requests over many addresses so that no single address looks suspicious: each one stays under every per-IP limit at the edge. In the demo below, no address sent more than 4 requests. Guard Core SaaS looks at the clients together. Campaigns score how alike their traffic is across six signals: shared request sequence, timing cadence, IP spread, endpoint spread, automation share and user-agent concentration. Coordinated Attacks flags many addresses sending the same attack to the same endpoint within minutes. Blocking a campaign from the dashboard adds every member IP to the project's IP blacklist. Both are Guard Core SaaS features on the Team, Business and Enterprise tiers; see pricing.

Here is a demo run on our production stack with documentation IP addresses: 40 identities, 4 requests each to the same 4 endpoints in a fixed order, 250 ms apart, with 6 rotating user agents.

The ban comes from the demo app's own rule, not from a default: the demo app bans after two detections. Rate limits never fired.

These commands read your web server logs locally and print counts only: how many requests for secret files, admin panels and path traversal got each status code. If the edge stopped them, this prints nothing. They only read: run them on the server, and change the log path if yours live elsewhere.

zcat -f /var/log/nginx/access.log* | awk 'tolower($7) ~ /\.env|\.git\/|\.aws\/|\.ssh\/|wp-login\.php|xmlrpc\.php|phpmyadmin|\.\.\/|%2e%2e/ {print $9}' | sort | uniq -c | sort -rn

zcat -f /var/log/caddy/access*.log* | jq -r 'select(.request.uri | ascii_downcase | test("\\.env|\\.git/|\\.aws/|\\.ssh/|wp-login\\.php|xmlrpc\\.php|phpmyadmin|\\.\\./|%2e%2e")) | .status' | sort | uniq -c | sort -rn

A reverse proxy and a CDN lock the front door, and you should keep them: they are the right place for volume, TLS and DDoS protection. Guard Core locks the back door from inside the app, where the routes and the history of each client are known.

• Window: 2026-10-05 to 2026-10-19 (15 days); fail2ban figures cover 30 days.
• Sources: CDN analytics, web server access logs, fail2ban logs and container logs.
• Privacy: client IPs are hashed with a random per-run salt that is never printed, and every output is a count. The page shows aggregates only.
• Limits: 38 detections were triggered by a header or the body, so the logs cannot confirm their exact trigger. This is one deployment over 15 days.