Cloudflare IP Ranges: What They Are and How to Use Them

Look up the IP address behind almost any popular website and there's a good chance you land on something like 104.16.x.x or 172.67.x.x. Look up a completely unrelated site and you may get an address from the very same block. Millions of sites, a short list of addresses. That's Cloudflare, and the reason it works this way is worth understanding whether you run a site behind it or you're just trying to figure out what a given address really is.

Cloudflare sits in front of a large share of the web as a reverse proxy. When a domain uses Cloudflare, its DNS points visitors at Cloudflare's network instead of the real server. Cloudflare receives the request at one of its edge locations, applies caching and security filtering, and then fetches from the origin server only if it has to. To the outside world, the site's IP address is Cloudflare's, not the origin's. This is the same trick behind every content delivery network: put a fast, distributed layer between visitors and the server.

This guide covers where Cloudflare's IP ranges are published, why they trace back to a single network identifier, and the two tasks that genuinely require the list: locking down your origin server, and recovering the real visitor IP from your logs.

One network, a short list of blocks#

Because every Cloudflare-proxied request enters through the same shared edge network, all of those sites share one compact set of address blocks. Cloudflare publishes the authoritative list in three places, and these are the only sources you should trust:

• https://www.cloudflare.com/ips-v4 — the IPv4 ranges as plain text
• https://www.cloudflare.com/ips-v6 — the IPv6 ranges as plain text
• https://api.cloudflare.com/client/v4/ips — both sets as JSON, with an etag value you can use to detect when the list changes

The list is genuinely small. At the time of writing it is 15 IPv4 blocks and 7 IPv6 blocks, written as CIDR ranges like 104.16.0.0/13 and 2606:4700::/32. Those look modest, but CIDR notation is deceptive: a single /13 covers more than half a million addresses, so two dozen entries account for an enormous slice of the internet's front door. If you want to see exactly how many addresses one of those prefixes spans, paste it into our CIDR calculator and it will expand the block into its network, broadcast, and host range. The slash number is doing a lot of quiet work.

One caution before you copy anything down: the list is not frozen. Cloudflare adds ranges as its network grows, so anything you hardcode today will eventually drift out of date. That single fact shapes how you should use the list, and we come back to it at the end.

It all traces back to one ASN#

Every one of those blocks is announced to the global routing table by a single Autonomous System: AS13335, Cloudflare's network. An ASN is the identifier for a block of networks operated by one organisation, and it is the most reliable way to answer "who owns this address," far steadier than geolocation, which only guesses at a physical place. If you want the full background on that, we wrote a whole piece on what an ASN actually is.

The ASN is the practical shortcut for spotting a Cloudflare address without memorising a single CIDR block. Drop an IP into our IP lookup and the owner and ASN come straight back; if it reads Cloudflare and AS13335, the address belongs to the edge network, not to the site you were investigating. To go the other direction and see the full set of prefixes AS13335 announces, open the ASN Explorer and search for its number. The announced-prefix list there is the routing-table view of the same ranges Cloudflare publishes on its two text pages.

This also explains a common moment of confusion. You run a lookup on a domain expecting to find where its server lives, and instead you get an address in a Cloudflare data center that could be anywhere. The domain is not lying to you; the origin is simply hidden behind the proxy, which is one of the things Cloudflare exists to do. It is exactly why finding a website's real IP gets harder the moment a CDN is in front of it.

The main reason to care: locking down your origin#

Here is the scenario that sends most people looking for this list. You put your site behind Cloudflare for DDoS protection and a web application firewall, but your origin server still has a real, routable public IP of its own. If an attacker discovers that origin IP (through an old DNS record, a leaked email header, an entry in the certificate transparency logs), they can connect to it directly and skip every protection Cloudflare provides. All your filtering runs at the edge, and they simply walked around it.

The fix is to configure the origin's firewall to accept connections only from Cloudflare's published IP ranges and drop everything else. Now a direct hit on the origin IP is refused, because it did not arrive through Cloudflare. This is the single most valuable use of the list, and it is Cloudflare's own recommended hardening step. Done properly, it means the only path to your server runs through the edge, so the edge's rules always apply.

The trap to avoid is a half-finished allowlist. If you permit only the IPv4 ranges but your origin also answers on IPv6, an attacker can reach it over IPv6 and the lockdown means nothing. Allow both address families, or disable the one you do not use. The same care applies over time: because the ranges change, a firewall rule you set once and forget can quietly start rejecting legitimate Cloudflare edge nodes, or fail to cover new ones that Cloudflare has since added.

Recovering the real visitor IP#

Locking the origin to Cloudflare creates a second problem, and a request header solves it. Once every connection arrives from a Cloudflare edge address, your server logs show Cloudflare's IPs instead of your actual visitors'. Every line looks like it came from the proxy, which makes analytics, rate limiting, and abuse investigation useless.

Cloudflare restores the original address in a header it adds to each request. CF-Connecting-IP carries the real client IP on every request from the edge to your origin, on all plans, as a single clean value. Enterprise plans can additionally send True-Client-IP, which holds the same value under a different name for legacy systems that expect that specific header. There is also the standard X-Forwarded-For, but it can contain a comma-separated chain of every proxy a request passed through, so Cloudflare recommends CF-Connecting-IP for logging precisely because it is always one address, not a list.

Most web servers and application frameworks have a module that trusts these headers and rewrites the logged client IP for you, and Cloudflare ships an official one for the common servers. Configure that, and your logs, dashboards, and per-visitor limits see the genuine visitor again rather than the edge that relayed them.

Track the list, don't hardcode it#

Because Cloudflare's ranges shift over time, treating the list as a one-time copy is a slow-motion outage waiting to happen. The better pattern is to pull the ranges from the API on a schedule and update your firewall automatically. The JSON endpoint returns that etag, which changes only when the underlying list changes, so a small script can fetch the endpoint, compare the etag to the last one it saw, and rebuild the firewall rules only when something actually moved.

If you run on a major cloud host, first check whether your firewall or load balancer already offers a managed "Cloudflare" IP group that stays current on its own. Several providers maintain one, and it saves you from running the sync yourself. The principle is identical either way: the published list is the source of truth, and your job is to follow it, not to snapshot it and hope it holds.

Putting it together#

Cloudflare's IP ranges are a small, public, occasionally changing set of blocks, all announced by AS13335, that front a large fraction of the web. If you operate a site behind Cloudflare, they do two jobs: they are the allowlist that stops attackers from bypassing the proxy to hit your origin, and the CF-Connecting-IP header they pair with is how you pull real visitor IPs back into your logs. If instead you are investigating an address, recognising a Cloudflare IP tells you that you are looking at the edge, and the real origin is somewhere behind it.

Either way, resist the urge to paste the list into a config and walk away. Pull it from the source, watch the etag, and let a little automation keep you honest as the network grows.