Putting Cloudflare in front of your site gives you edge caching, a WAF, bot mitigation, and DDoS protection. That protection has one requirement that’s easy to overlook: every request has to actually pass through Cloudflare’s network. If an attacker can find your server’s real IP address and hit it directly, none of that edge protection matters. They just route around it.
This is the part of DDoS resilience that doesn’t show up in a plugin settings page. It’s about making sure your origin is genuinely invisible, not just fronted.
Why the origin IP is the weak point
Cloudflare’s WAF, rate limiting, and DDoS mitigation all operate at the edge, before traffic reaches your server. That’s the whole model: bad traffic gets filtered or absorbed upstream. But DNS still ultimately has to point somewhere, and that somewhere is your hosting provider’s IP address. If that address is discoverable, an attacker can send traffic straight to it, bypassing every edge control you’ve set up. Your origin then has to survive the attack on its own, which most single-server WordPress stacks are not built to do.
The fix isn’t a single setting. It’s closing off every path that reveals the origin, then verifying the origin refuses traffic that doesn’t come through Cloudflare.
Common ways an origin IP leaks
DNS history
If your domain ever pointed directly at your server before you added Cloudflare, that old A record is likely archived by DNS history services. Anyone can look up your domain’s historical records and find the IP you used before proxying. This is one of the most common leak paths and it has nothing to do with your current configuration; it’s a record of the past.
Unproxied subdomains
Cloudflare only protects records that have the proxy (the orange cloud) turned on. It’s common to leave subdomains like mail, ftp, direct, cpanel, webmail, or a staging subdomain pointed directly at the origin with the proxy off, usually because a mail client or FTP tool needs a direct connection. If any of those subdomains resolve to the same IP as your main site, that IP is public.
Mail server headers
If your site sends email (password resets, contact forms, WooCommerce notifications) from the same server that hosts the site, the email headers often contain the originating IP address in the Received chain. Anyone who receives an email from your site can view the raw headers and pull the IP straight out.
SSL certificate transparency logs
Public certificate transparency logs record every SSL certificate issued for every subdomain, including ones you may have forgotten about, like an old staging environment or a test subdomain that still resolves directly to the origin. Searching a certificate transparency log for your domain can reveal subdomains you didn’t know were exposed.
Server status pages and direct IP access
Some server software exposes status pages, and some servers will happily serve your site to anyone who requests it by IP address with no matching hostname, sidestepping DNS entirely. If your origin responds to plain HTTP or HTTPS requests sent straight to its IP address, that’s a leak in itself, whether or not the IP is publicly known yet.
How to seal the leaks
1. Audit every DNS record
Go through your DNS zone and confirm every record that should be proxied has the proxy enabled. Pay particular attention to subdomains you set up before adding Cloudflare, or ones added later for a quick test and never cleaned up. Anything pointing at your web server’s IP needs the proxy on, or it needs to not exist.
2. Move mail off the web server, or mask the origin in headers
If you can, send transactional email through a separate provider rather than your web server directly. If that’s not practical, check the actual headers of an email your site sends and confirm they don’t expose the origin IP. This is worth testing directly rather than assuming.
3. Check certificate transparency logs for your domain
Search a certificate transparency log service for your domain and review every subdomain listed. Anything unfamiliar, or anything you know points directly at the origin, needs to be either proxied through Cloudflare or removed.
4. Restrict the origin firewall to Cloudflare’s IP ranges
This is the step that actually closes the door, rather than just hiding it. Configure your server’s firewall to only accept HTTP and HTTPS connections from Cloudflare’s published IP ranges. Cloudflare publishes these ranges directly, and they do change occasionally, so this needs to be a rule you can update, not a one-time list you paste in and forget. With this in place, even if someone finds your origin IP, direct requests get dropped before they reach WordPress.
5. Verify the origin actually rejects direct requests
Test this yourself. From an external machine, try connecting to your server’s IP address directly over HTTP and HTTPS. If you get a response, especially one serving your site’s content, the origin is still reachable directly and the firewall rule isn’t doing its job. You should get a connection refusal or a timeout, not your homepage.
6. Rotate the IP if you know it has leaked
If you’ve confirmed the origin IP is publicly known through DNS history or a certificate log, the safest move is to request a new IP address from your hosting provider and rebuild DNS records around it with proxying enabled from the start. An IP that’s already circulating in DNS history archives doesn’t become private again just because you stop pointing at it.
What this doesn’t replace
Hiding the origin IP is a distinct layer from having a WAF, from having 2FA and strong passwords on wp-admin, from keeping backups tested and off-site, and from running current versions of WordPress and PHP. It solves one specific problem: making sure the protection you’ve already set up at the edge can’t simply be bypassed. It’s not a substitute for basic hardening, and a hardened site with an exposed origin IP is still vulnerable to a direct-hit DDoS attack that never touches Cloudflare’s filters at all.
Managed hosts that run infrastructure specifically for WordPress, ServerBorn included, often handle origin firewalling and IP hygiene as part of the stack, which removes this from your list of things to configure manually. If you’re managing your own server, it’s worth putting on the calendar as a periodic check, not a one-time setup task, since new subdomains and new mail configurations have a way of reopening the door.
Takeaway
A CDN and WAF only protect traffic that actually flows through them. An exposed origin IP, found through DNS history, an unproxied subdomain, or a leaked email header, lets an attacker skip all of it. Audit your DNS records, check certificate transparency logs, move or mask mail headers, and firewall your origin to only accept connections from Cloudflare’s ranges. Then verify it by trying to hit the origin directly yourself. If you can’t get through, neither can they.