Block or whitelist an IP, range or ASN in Cloudflare

To block or whitelist an IP in Cloudflare, create an IP Access rule (Security rules, then Create rule, then IP access rules) with the IP, range or ASN and the action Block or Allow. For more control, use a WAF custom rule with ip.src or ip.src.asnum, and keep long sets of addresses in an IP list.

Three ways to block or allow an IP in Cloudflare

Cloudflare has three tools for IP-based decisions. They overlap, but each fits a different job.

Cloudflare itself now recommends custom rules over IP Access rules for IP blocking and geoblocking. IP Access rules still work and are the fastest way to allow one address.

IP Access rules: the quick way

Go to the Security rules page in the dashboard and select Create rule, then IP access rules. Enter the value, pick an action and choose whether the rule applies to the current website only or to all websites in the account. Add a note so you remember why it exists, for example "Payment gateway".

What the field accepts:

• A single IP, IPv4 or IPv6.
• A range, but only fixed sizes: IPv4 /16 or /24, IPv6 /32, /48 or /64. A /20 is not accepted; use a custom rule for that.
• An ASN, written with the prefix, such as AS13335.
• A country as a two-letter code. Blocking a country this way needs Enterprise; on other plans use a custom rule, as in blocking traffic by country.

Every plan can hold up to 50,000 IP Access rules. One catch for troubleshooting: requests matched by an Allow rule do not appear in Security Events, by design.

WAF custom rules with ip.src and ip.src.asnum

Custom rules are where IP blocking becomes precise. You write an expression, Cloudflare runs your action when it matches. The Free plan includes 5 custom rules, Pro 20, Business 100.

Block a single address:

(ip.src eq 203.0.113.50 and not cf.client.bot)

Block several addresses and ranges at once. Inline sets take single IPs, CIDR ranges and explicit ranges written as start..end, separated by spaces:

(ip.src in {203.0.113.0/24 198.51.100.3..198.51.100.7 2001:db8::/32} and not cf.client.bot)

Block a whole network by its AS number (no "AS" prefix in expressions):

(ip.src.asnum in {64496 64497} and not cf.client.bot)

The field ip.src.asnum replaced ip.geoip.asnum, which still works but is deprecated. Older tutorials say "firewall rules": those are deprecated too, replaced by custom rules.

Why not cf.client.bot in every rule? That field is true when the request comes from a known good bot or crawler. Adding it means a typo in a range or an overly broad ASN can never hit Googlebot or Bingbot.

IP lists for ranges you reuse

If you block or allow the same addresses in several rules, or across several sites, put them in a list. Lists live at the account level, so one list serves every zone in the account. Create one under Settings, then Lists, then Create new list, and add items by hand or by CSV upload.

Reference the list by name with a dollar sign. Names use lowercase letters, numbers and underscores only:

(ip.src in $blocked_ips and not cf.client.bot)

Plan limits are tight on the low end. Free gets 1 custom list, Pro and Business 10, all sharing a cap of 10,000 items. Enterprise gets 1,000 lists and 500,000 items. ASN lists and hostname lists are Enterprise only, so on other plans keep ASNs in an inline set like the example above.

How to whitelist an IP in Cloudflare correctly

"Whitelist" can mean two different things in Cloudflare, and they bypass different amounts of protection.

Allow in an IP Access rule excludes the visitor from all security checks, including Browser Integrity Check, Under Attack mode and the WAF. Allowing an IP or ASN bypasses custom rules, rate limiting rules and WAF Managed Rules. Allowing a country does not bypass Managed Rules. IP Access rules run first in the WAF, before custom rules, rate limiting and Managed Rules, and an IP Access rule that matches first also keeps Bot Fight Mode from triggering.

Skip in a custom rule bypasses only what you select: the remaining custom rules, rate limiting, managed rules, Super Bot Fight Mode, or older products such as Zone Lockdown, User Agent Blocking, Browser Integrity Check, Hotlink Protection and Security Level. Bot Fight Mode cannot be skipped. Put the Skip rule at the top of your custom rules:

(ip.src in $trusted_ips and not cf.client.bot)

Use Allow for your own office or a monitor you fully trust. Use Skip to open one door, for example let a payment provider past rate limiting while managed rules still inspect it. Cloudflare suggests replacing Allow with Skip when moving to custom rules.

The reverse pattern, "only these IPs may reach the admin area", is a Block rule with not:

(http.request.uri.path wildcard "/wp-admin/*" and not ip.src in $office_ips and not cf.client.bot)

Never whitelist by user agent. A rule like "allow if the user agent contains Googlebot" lets any scraper in that copies the string, and they do. Verified crawlers are recognized by Cloudflare through cf.client.bot; if you need Google's addresses for your own checks, use Googlebot IP ranges published by Google, not the user agent.

How to block an ASN without blocking Googlebot

An ASN (autonomous system number) identifies a network operated by one organization, such as an ISP, a hosting company or a cloud provider. Blocking an ASN removes every IP that network announces in one rule, which is why it is popular against scrapers rotating addresses inside AWS, Google Cloud, Microsoft Azure, DigitalOcean, Hetzner or OVH.

It is also the rule most likely to backfire. In the traffic reports we have prepared, the hand-written rules that caught Google's or Bing's crawlers by accident were usually a country, a cloud network or a user agent pattern. Cloud networks also carry useful automation: uptime monitors, payment webhooks, feed readers, partner APIs and some verified bots. Three habits keep an ASN block safe:

1. Find the ASN from evidence. Security Analytics can filter events by source ASN (enter the number without "AS"). Block what sends the load, not a list copied from a forum.
2. Use Managed Challenge, not Block, wherever real people might sit behind the network, such as a mobile carrier, a corporate VPN or a residential ISP. A person passes the challenge; a script usually does not. More on the options in Cloudflare challenges explained.
3. Always add not cf.client.bot. It lets verified crawlers through even when they come from a network you challenge.

(ip.src.asnum in {64496 64497 64498} and not cf.client.bot)

Action: Managed Challenge. After a day, open Security Events and check the solve rate and the paths hit. If nobody solves the challenge, you can switch to Block with more confidence.

Whitelist Cloudflare IPs at your origin server

The search "whitelist Cloudflare IP addresses" usually means the opposite direction: your server should accept web traffic only from Cloudflare. Every rule above can be bypassed if an attacker finds your origin IP, for example from old DNS records or mail server headers, and sends requests straight to it.

Cloudflare publishes its ranges at cloudflare.com/ips, with separate IPv4 and IPv6 text lists and an API for automation. The ranges change rarely, and new ones are added to the list before they go into production. Cloudflare's guidance is to allow these ranges in your firewall or .htaccess and drop all other traffic on ports 80 and 443, while still allowing trusted partners and your own tools:

# repeat the ACCEPT line for every range on the Cloudflare IPv4 list
iptables -I INPUT -p tcp -m multiport --dports http,https -s 173.245.48.0/20 -j ACCEPT
# then drop everything else on the web ports
iptables -A INPUT -p tcp -m multiport --dports http,https -j DROP

This does not hurt Googlebot: on a proxied site, crawlers reach you through Cloudflare like everyone else. Before locking the ports, list anything that calls the origin directly, such as a monitor using the raw IP.

Once traffic arrives only from Cloudflare, your logs show Cloudflare's addresses instead of visitors'. Restore the real IP from the CF-Connecting-IP header: on Apache with mod_remoteip (RemoteIPHeader CF-Connecting-IP plus a RemoteIPTrustedProxy line per Cloudflare range), on nginx with the realip module:

# one set_real_ip_from line per Cloudflare range
set_real_ip_from 173.245.48.0/20;
real_ip_header CF-Connecting-IP;

Without this, an IP block in your server config or security plugin sees only Cloudflare and may block it, taking the whole site down. Server-side options are covered in how to block an IP address on your server.

Not sure which IPs or networks deserve a rule? A free bot traffic report breaks your Cloudflare traffic down by network, user agent and hour, and shows whether any current rule touches search crawlers.

FAQ

How do I whitelist my IP in Cloudflare?

Create an IP Access rule with your IP and the action Allow. It excludes your address from all security checks, including the WAF and Under Attack mode. If your IP changes often, use a Skip rule with an IP list, so you update one list, not several rules.

How do I block an IP range in Cloudflare?

IP Access rules take only IPv4 /16 and /24 or IPv6 /32, /48 and /64. For any other size, write a custom rule such as (ip.src in {192.0.2.0/20} and not cf.client.bot), or add the range to an IP list.

Can I block an ASN on the Free plan?

Yes. Both IP Access rules and custom rules with ip.src.asnum are available on all plans. ASN lists are Enterprise only, so on Free put the numbers in an inline set inside the rule.

Why is my Allow rule not showing in Security Events?

That is by design. Requests matched by an IP Access rule with the Allow action are not logged in Security Events. A custom Skip rule logs matches by default.

• Block an IP address
• Block bots with robots.txt
• nginx rate limiting