Protecting your origin server from direct access when using Cloudflare

If you're using Cloudflare to protect your website, it's easy to assume that all traffic must pass through Cloudflare first. In reality, if someone is able to discover your hosting server's IP address, they may still be able to access it directly, allowing requests to bypass Cloudflare's firewall, rate limiting and other security features.

This article explains why this happens and how to configure your hosting and Cloudflare account to ensure requests reach your website only through Cloudflare.

Why this matters

If your domain is proxied through Cloudflare (orange-cloud enabled), Cloudflare's firewall, rate-limiting, and caching sit in front of your visitors' traffic. However, your hosting account still has its own IP address, and by default that IP will respond to requests sent to it directly — completely bypassing Cloudflare.

This means anyone who knows or discovers your origin IP address can send traffic straight to your server, skipping any protection you've configured in Cloudflare. This is a common way sites experience unexpected load, scanning, or attacks despite being "behind Cloudflare."

This article explains how to close that gap.

Who this applies to

Any client with a domain proxied through Cloudflare where the origin server has a fixed, discoverable IP address. This includes shared, Enterprise, VPS, and dedicated hosting.

Two ways to close the gap

Which option is right for you depends mainly on your hosting type — the two approaches below aren't interchangeable, so check which applies to your account before proceeding.

Option 1: Network-level firewall restriction (VPS and dedicated servers only)

On an isolated VPS or dedicated server, where your server firewall is not shared with other clients' domains, you can restrict inbound port 80/443 traffic to only accept connections from Cloudflare's published IP ranges (https://www.cloudflare.com/ips/), rejecting everything else at the network level.

This is not available on shared or Enterprise hosting, as the server firewall covers other clients' domains as well, some of which may not be behind Cloudflare. Restricting it server-wide would block direct access for other sites and accounts.

If you're on a VPS or dedicated server and would like this configured, please contact our technical support.

Option 2: Shared-secret header (available on all hosting types, including shared/Enterprise)

This method works at the domain/application level rather than the firewall level, so it's available regardless of hosting type. It uses a secret value that Cloudflare attaches to every request it forwards to your origin — a request sent directly to your origin IP has no way to include this value and is rejected before it reaches your website.

Steps:

1. In your Cloudflare dashboard, select the domain, go to Rules → Overview, click Create rule, and choose Request Header Transform Rule (listed under "Transform requests or responses").
2. Give the rule a descriptive name — for example "Origin verification header".
3. Under "If incoming requests match…", select All incoming requests, unless you want to scope the rule to specific paths using a custom filter expression.
4. Under "Then… Modify request header", leave the action set to Set static, enter the header name (e.g. X-Origin-Verify), and enter a long, random secret value (treat this like a password; a 32+ character random string is recommended).
5. Under "Place at", set the order as First unless you have other Transform Rules that need to run before this one.
6. Click Deploy (or Save as Draft if you'd like to review it before it goes live). Note that Free and Pro plans allow up to 10 Transform Rules in total — worth checking if the account already has several in use.

7. On your hosting account, add the following to your domain's .htaccess file, replacing YOUR_SECRET_VALUE with the value you set in step 4:

   RewriteEngine On
   RewriteCond %{HTTP:X-Origin-Verify} !^YOUR_SECRET_VALUE$
   RewriteRule ^ - [F]
   

8. Test before relying on this — see Testing below.

If you'd prefer, contact support and, provided we already have the necessary access to your Cloudflare account and hosting account, we can configure both sides for you.

Testing

Before assuming this is working, confirm both of the following:

• A normal request of your website through Cloudflare still returns your site normally. Note that a cached response won't reach your origin at all, so use a cache-busting query string (e.g. ?test=123) or a Cloudflare cache purge to force a request through to origin.
  
  To test this over the command line interface, if available: curl -I https://yourdomain.tld/

• A request sent directly to your origin IP (your cPanel account's IP address), with your domain set as the Host header and without the secret header, is rejected:

  curl -I -H "Host: yourdomain.tld" https://YOUR_ORIGIN_IP/ -k
  

  This can only be tested over the command line interface and should return 403 Forbidden. The -k flag is expected to be needed, as your TLS certificate won't match the bare IP address.

Important limitations

• This protects against direct requests to your origin IP bypassing Cloudflare — it does not replace Cloudflare's WAF, rate limiting, or DDoS protection, and it does not provide true network-level filtering. A flood large enough to exhaust your account's available web server workers would still cause impact, since requests still reach the server before being evaluated and rejected.
• Anything that legitimately needs to reach your origin directly — uptime monitors, staging tools, a second CDN, internal testing scripts — will also need the secret header added (if technically possible), or it will be blocked once this is enabled. Review what may call your origin directly before enforcing this rule.
• The secret value is the entire security boundary for this method. Keep it out of any public repository, client-side code, or shared documentation, and rotate it periodically. If you ever suspect it has been exposed, rotate it immediately — update it in both the Cloudflare Transform Rule and your .htaccess rule at the same time to avoid a window of blocked legitimate traffic.
• If you add or remove subdomains that are also proxied through Cloudflare, each one needs its own matching header rule and .htaccess rule if you want it protected the same way.

Related articles

• Cloudflare DDoS Settings
• Grant our technicians access to your CloudFlare Dashboard

Updated by SP on 06/08/2026