Question 2 of 6
Why is my site coming from California?!
Customer ticket
Subject: Why is my site coming from California?!
I’m in London, but looking at your IPs it shows that you are serving my website from California. Can that be right? Why is that? I thought you were supposed to serve my website from some places close to me?
1. Email reply to the customer
Hi there,
Thanks for getting in touch, and good question. You’re right that Cloudflare should serve your visitors from a data centre close to them, and the good news is that this is almost certainly happening already. The “California” label comes from how IP geolocation databases describe our addresses, not from where your traffic is actually served.
Why the IP looks like it’s in California
Cloudflare uses anycast. The same IP addresses are announced from every one of our data centres worldwide (including London, Manchester and many other European locations). When you connect to one of those IPs, internet routing takes you to a nearby Cloudflare location, usually the closest or best-connected one for your ISP.
IP geolocation tools (the “where is this IP?” websites) can only store one location per IP range. They usually record the address of the company that owns the range. Cloudflare is headquartered in San Francisco, California, so our IPs often show up as “California”, even though the same IP is answering you from London.
How to see where you’re really being served from
From your browser in London, open:
https://example.com/cdn-cgi/traceLook for the colo= line. It shows the IATA airport code of the Cloudflare data centre that handled your request. In London you would typically see colo=LHR. You can also check the cf-ray response header: the three letters after the dash are the same data centre code.
curl -sI https://example.com/ | grep -i cf-ray
# cf-ray: 8f1a2b3c4d5e6f70-LHR <- served from LondonOne thing to bear in mind is that routing is decided by your ISP’s peering with Cloudflare, so you may sometimes be served from another nearby European location (for example Manchester or Amsterdam). That is normal and can change from one request to the next. If you ever see a consistently distant location such as LAX or SJC from a UK connection, please send me the full /cdn-cgi/trace output, your ISP name and a traceroute, and I’ll take it up with our network team.
Also, if your application needs the visitor’s location, don’t rely on our edge IPs. Cloudflare can add a CF-IPCountry header to requests to your origin, and the original visitor IP is available in CF-Connecting-IP.
Let me know what colo you see. I’m happy to check it with you.
Kind regards,
Marwan
Cloudflare Customer Support
2. Thought process
This is a misunderstanding rather than a fault, so I wanted the answer to be reassuring, educational and verifiable. I explain the concept briefly, then give the customer a 30-second way to prove it themselves.
- Root cause: anycast plus GeoIP. Third-party GeoIP databases map Cloudflare’s ranges to the registrant (Cloudflare, San Francisco, CA). Those databases can’t represent “announced from 300+ cities”.
- Proof:
/cdn-cgi/trace(colo=) and thecf-raysuffix are the authoritative answer to “which data centre served me?”. Both are documented in Cloudflare’s troubleshooting docs. - Setting expectations: Cloudflare’s docs say that the visitor’s ISP, not Cloudflare, decides which data centre receives the traffic, and that it cannot be pinned per zone. I mention this so the customer isn’t alarmed if they see Manchester or Amsterdam rather than LHR, and I give them a clear path to escalate if they see something truly distant.
- Practical extra: customers who ask this are sometimes trying to geolocate visitors, so I point them to
CF-IPCountryandCF-Connecting-IP.
3. Tools I would use, and why
| Tool | Why |
|---|---|
https://<domain>/cdn-cgi/trace | Shows the colo (serving data centre), the visitor’s IP and the location Cloudflare sees. This is the quickest proof. |
curl -sI / browser DevTools | Read the cf-ray header; its suffix is the data centre’s IATA code. |
dig example.com | Confirm the customer is resolving to Cloudflare anycast IPs (proxied record) and not to their origin. |
IP geolocation / WHOIS lookup (e.g. ipinfo, RIPE/ARIN) | Shows the customer why the IP is labelled California: it’s registered to Cloudflare, Inc. in San Francisco. |
traceroute / mtr | If a distant colo appears consistently, these show the ISP path for an escalation to the network team. |
Cloudflare status page (Locations view) | Map IATA codes to cities and check whether a nearby data centre is under maintenance or re-routed. |