A bot that discovers your server's real IP address can bypass Cloudflare entirely — hitting your origin directly on ports 80 and 443 without passing through a single Cloudflare security check. Your nginx deny all rules still catch the request when it arrives, but the request still arrives. The connection is accepted, the request parsed, the response sent. A cloud firewall stops that traffic before your server ever sees the TCP handshake.
This is not a replacement for nginx-level blocking or Cloudflare's edge protections. It's a layer between them — a stateless packet filter at the infrastructure level that drops traffic from anyone who isn't Cloudflare. Your server becomes invisible to port scanners, botnets, and attackers probing IP ranges directly. The only path in is through Cloudflare's proxy network.
Don't use Cloudflare? The principle still applies. Close every port you don't use. If you run a web server and SSH, that's three open ports — 80, 443, and 22 (or a custom SSH port). Everything else stays dropped. Most cloud images ship with services listening on ports you didn't even realize were open. A cloud firewall with a default DROP policy costs nothing on most providers and means your server never has to accept, parse, or log garbage traffic on ports you never intended to expose.
Prerequisites
- A cloud provider that offers a configurable firewall at the infrastructure layer — Linode Cloud Firewall, Vultr Firewall, DigitalOcean Cloud Firewall, AWS Security Groups, or equivalent
- All domains proxied through Cloudflare (orange cloud) — if any subdomain on your certificate uses DNS-only mode, certificate renewal will break. The Certbot section below explains why and how to fix it
- Real visitor IPs restored via
ngx_http_realip_module— the Cloudflare Real IP guide covers the full setup - SSH hardened and running on a non-default port — the Hardening SSH guide walks through key auth, port changes, and sshd_config lockdown
Why direct IP attacks matter
Cloudflare publishes its IP ranges publicly. So do most CDNs. An attacker who wants to bypass Cloudflare's DDoS protection, WAF rules, or bot detection doesn't need to find a vulnerability — they just need to find your origin IP. Common discovery methods include:
- DNS history databases — services that archive historical DNS records. If your domain ever pointed directly to your server before you added Cloudflare, the IP is in those databases permanently
- Shodan and Censys — search engines that scan the entire IPv4 space and index SSL certificates. Your origin cert's Common Name or SAN entries can tie it back to your domain
- Outbound connections — if your server sends email, makes API calls, or loads external resources, those outbound packets contain your origin IP in the TCP header
Once an attacker has your IP, they can send requests directly to https://203.0.113.50 with a Host: example.com header. No Cloudflare. No WAF. No managed challenges. Just your nginx config and whatever defenses you built at the origin.
Nginx handles it — your deny all rules drop the obvious probes, your rate limiting throttles the rest, your fail2ban jails catch repeat offenders. But that's the point: your server is still doing the work. Accepting the TCP connection, parsing the HTTP request, matching it against location blocks, and returning a 403 burns CPU cycles, eats a small amount of bandwidth, and occupies a worker connection that could be serving a legitimate visitor. One bot doing this at scale — thousands of requests per hour — adds up.