Why a Website Shows Cloudflare IP Addresses Instead of the Origin Server

When a site uses a reverse proxy or CDN, DNS may return the proxy network's IP address instead of the origin server IP.

This is intentional. The proxy handles public traffic, absorbs attacks, caches content, and can hide the origin infrastructure.

Cloudflare is the most common example. When a hostname is proxied through Cloudflare, its DNS records answer with addresses from Cloudflare's anycast network. Your browser connects to the nearest Cloudflare data center, and Cloudflare opens a separate connection to the site's origin server to fetch what it does not already have cached. The origin's address never appears in DNS for that hostname, which is the whole point of the arrangement.

Cloudflare publishes the IPv4 and IPv6 ranges its proxy uses at cloudflare.com/ips, with plain-text lists at /ips-v4 and /ips-v6 that scripts can fetch. Its main network is AS13335, registered in ARIN's records under the name CLOUDFLARENET to Cloudflare, Inc. A lookup that shows that ASN, or an address inside those ranges, is telling you that you have reached the edge network, not the server that runs the site.

A domain that resolves to several addresses is normal for the same reason: anycast networks and load-balanced services return more than one address for performance and resilience, and each of them leads to the same edge.

If an IP lookup shows a CDN or proxy provider, it does not mean the website is hosted in that city or by that company directly.

It means your request is reaching an edge or proxy network that fronts the real application.

Read each field with that in mind. The ISP or organization tells you the site uses Cloudflare, and that is reliable. The city is where a geolocation database placed an anycast range, often the registrant's headquarters or one of many points of presence, and says nothing about where the site's server is. Risk flags on a CDN range reflect the behavior of every tenant sharing the edge, not the site you looked up. What you cannot learn from the address is the hosting provider, the server's country, or whether the site itself is trustworthy; those need other evidence.

Because the connection to the origin comes from Cloudflare, the origin's own logs and rate limits see Cloudflare addresses unless the application reads the headers Cloudflare adds. CF-Connecting-IP carries the visitor's address as a single value on every proxied request, and Cloudflare also appends the visitor to X-Forwarded-For, the widely used but never formally standardized header whose standards-track alternative is the Forwarded header of RFC 7239. Cloudflare's documentation on restoring original visitor IPs shows how to make a web server log the visitor rather than the proxy, and the X-Forwarded-For guide covers how to read forwarded headers safely in application code.

One warning belongs here. Anyone who can reach the origin directly can send a request with any CF-Connecting-IP or X-Forwarded-For value they like. Trust those headers only when the connection itself arrives from Cloudflare's published ranges, and better still when the origin accepts connections from nowhere else. Otherwise an attacker chooses the address that appears in your logs, your rate limits and your allowlists.

Origin hiding can reduce direct attack surface, but origin IPs may still leak through old DNS records, email headers, certificates, or misconfigured services.

The usual leaks are mundane. A DNS record for the same server that is not proxied, such as ftp, mail, cpanel or direct, hands out the origin address. An MX record or an SPF record that names the origin does the same, and so does the Received header of any email the server sends. Historical DNS data records what the hostname pointed at before Cloudflare was switched on. Cloudflare's guidance on protecting the origin server is to restrict inbound connections to its published IP ranges, to use authenticated origin pulls so that the origin accepts only Cloudflare's certificate, or to connect the origin through Cloudflare Tunnel so that it needs no public inbound address at all.

Use IP lookup to confirm what the public internet sees, then audit your infrastructure for accidental origin exposure.