Server Security

How Attackers Bypass Cloudflare and Hit Your Origin Directly — and How to Stop It

By Josh Comstock · Updated July 2026 · ~7 min read

A dense bundle of blue network cables connected to switch ports

Putting a site behind Cloudflare hides your server, but it doesn't move it. Your origin still has a real, routable IP address — and if an attacker finds it, they can skip Cloudflare entirely and connect straight to your server on port 443 with a valid Host header. To your logs it looks like ordinary traffic. To your edge protection it's invisible, because the request never touched the edge. This is the origin bypass, and it's the single most common way a "protected" server still gets hammered.

What the Origin Bypass Actually Is

When Cloudflare proxies your domain (the orange cloud), visitors connect to a Cloudflare edge server, which then forwards the request to your origin. Your WAF rules, rate limits, bot management, and managed challenges all live at that edge. They only run on traffic that arrives through the proxy.

The catch: your origin server is still listening on its public IP. Cloudflare doesn't change that — it just hopes nobody connects to it directly. An attacker who learns your origin IP can open a TCP socket straight to your.origin.ip:443, send Host: yourdomain.com, and your web server will happily answer. Every edge protection you pay for is bypassed in one step, because none of it is in the path.

How Attackers Find Your Origin IP

Origin IPs leak constantly. The common sources:

DNS history. Services like SecurityTrails and DNS history aggregators keep your old A records from before you enabled Cloudflare — the origin is sitting in plain sight.
Certificate Transparency logs. Every TLS certificate you issue is logged publicly. Subdomains in those logs (staging, dev, mail, cpanel) often point straight at the origin.
Unproxied DNS records. A grey-cloud MX, mail., ftp., or cpanel. record that resolves to the same box hands over the IP. cPanel auto-creates several of these.
Email headers. If your web server also sends mail, the Received: headers carry its real IP into every inbox you contact.
Application leaks. Server-side requests, webhooks, error pages, and misconfigured X-Forwarded handling can all echo the origin address.

So assume your origin IP is discoverable. The defensive question isn't "how do I hide it forever" — it's "what happens when someone has it?"

Why It Is Dangerous

A direct-to-origin attacker gets everything the edge was supposed to stop:

Your WAF never sees the request. SQLi/XSS rules, managed rulesets, and custom Cloudflare rules all run at the edge. Direct traffic skips them.
Rate limits do not apply. A flood that would trip a Cloudflare rate-limit rule lands unmetered on your origin and spikes load.
Bot management and challenges are gone. There is no edge to issue a managed challenge, so credential brute-force and scanners run unchallenged.

And there's a nasty second-order trap. On a Cloudflare-fronted server your access logs show the real visitor IP (via mod_remoteip / CF-Connecting-IP), but the actual TCP socket your firewall sees is a Cloudflare edge address. So a tool like fail2ban bans the logged IP and accomplishes nothing — or, worse, bans a Cloudflare range and takes every site on the box offline. Blocking the bypass correctly means knowing, per request, which side of the proxy the traffic is really on.

How to Tell if It Is Already Happening

Add Cloudflare's ray ID to your access log format and the answer becomes obvious — present means the request came through Cloudflare, absent means it didn't:

LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" cfray=%{CF-Ray}i" combined_cf

Any line with an empty cfray= reached your origin without passing the edge. You can also watch live: a TCP peer on ports 80/443 that isn't in Cloudflare's published ranges is, by definition, a direct connection.

How to Stop It

1. Lock Your Origin Firewall to Cloudflare's Ranges (the Real Fix)

The structural fix is to refuse any connection to your content port that doesn't come from a Cloudflare edge. With ipset + iptables, the shape is:

# Build a set from Cloudflare's published v4 ranges, then only allow those to 443
ipset create cf_edge hash:net
for cidr in $(curl -s https://www.cloudflare.com/ips-v4); do ipset add cf_edge "$cidr"; done
iptables -A INPUT -p tcp --dport 443 -m set --match-set cf_edge src -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j DROP

Two caveats this simple version glosses over, and both will bite you:

Certificate validation — lock 443 only, not 80. Locking :80 silently breaks ACME HTTP-01 renewals and cPanel/Sectigo AutoSSL DCV, and no /.well-known/ firewall carve-out can save them: a payload match can never admit a new connection, because the validator's SYN carries no payload to match — it's dropped before the HTTP request exists. And validator source IPs are deliberately unpublished, so you can't allowlist them either. Leave :80 serving only redirects and challenges (your content stays locked on 443), or switch to DNS-01 validation before locking both ports. Full post-mortem here.
cPanel service subdomains. cpanel., whm., and webmail. are grey-cloud records that hit the origin directly — the lock will drop them on 443. Use their service ports (2083/2087/2096) or proxy them through Cloudflare.

Build the rules accept-first, drop-last, and never install the DROP with an empty allow-list — an empty Cloudflare set plus a drop firewalls the entire internet, including you.

2. Authenticated Origin Pulls

Cloudflare can present a client certificate on every request it forwards, and your origin can be configured to reject any TLS connection that doesn't present it. This is mutual TLS between the edge and your origin — even an attacker who knows your IP can't complete the handshake. It pairs well with the firewall lock as defense in depth.

3. Stop Leaking the IP — and Rotate It After a Known Leak

Proxy every record that can be proxied, send mail from a separate host or relay, and avoid baking the origin into error pages and webhooks. If your current IP has already been published in DNS history or CT logs, the firewall lock matters more than rotation — but rotating after a confirmed leak buys time.

Automating It: Reactive Blocking plus a Structural Lock

Hand-maintaining ipset rules, refreshing Cloudflare's ranges, and watching logs for direct hits is exactly the kind of toil that rots. Swatter — our free, open-source abuse blocker for cPanel + CSF servers — does both halves automatically. It reads your web logs and the live socket to decide, per offender, whether traffic is direct-to-origin or proxied, and blocks each on the correct firewall plane (CSF for direct, a Cloudflare managed challenge for proxied) so it can never firewall the edge by mistake. And its optional origin lock is the structural complement described above: an inline L3 rule that admits only Cloudflare's ranges to port 443 by default — leaving :80 to serve only redirects and ACME challenges so certificate renewals keep working, with the cPanel caveats documented, a safe off → log → drop rollout, and a fail-open build so it can never blackhole real visitors.

See how Swatter works →

← All articles