IP assignments for different zones to the same origin

Well sounds logic but I can confirm, this is NOT true.
Why can I do so?

  • I do have 8 Domains which are in the same CF Account
  • All of them point to the same origin Server
  • They all do get routed trough CF
  • But when I check the headers I notice moste of them do get served from different POPs!!

I will not post the Domains itself here but I already created a ticket for this (1772052) Noone is respondig to it since a week!

My closest POP would be FRK (Frankfurt, DE) or MUC (Munic, DE) but I get served from:

  • ZRH (Zürich, CH)
  • LHR (London Heathrow, GB)
  • AMS (Amsterdam, NL)
  • MUC (Munic, DE) (at least one good POP)

Also another example:

domain.de and domain.ch
(domain stands for a synonym for my ‘Domain Name’)

domain.de gets served from ZRH
domain.ch gets served from AMS

So people from Switzerland do not get served from Zürich (which is in switzerland, but from Amsterdam which is in Netherland!?
And People from Germany do not get served from FRK, or MUC, but from Zürich swhich is in Switzerland.

Yes I doublechecked this!

Also: If the ISP choosed the clostest POP, why are the POPs not all the same, as the origin Server + the visitor in this case have been the same?
Same calculation, but every single time a different answer? This is not how CDN works!

One more: when calling other sites (like Cloudflare itself or its Docs/Wiki) I get served from FRK

For me there are soem things very wrong:
Dynamic Content and Static content have to be differenciated!

Should get served the way you (the visitor) gets the dynamic content as fast as possible, so CloudFlare have to route between Origin Server and you

Just go for the nearest/fastest POP you can get, as it is cached at CloudFlare and the origin Server doesnt matter!

But every kind of content gets served from the same Location, no matter what.

For me this is bad practice

Actually thats all/(mostly) explained in the linked article.

Your different domains will have different IP addresses and these will be routed differently by your provider. That is not specific to “people” but to ISPs, so depending on your visitors there is a good chance most will be routed through their local PoPs anyhow, but then again, that depends on their ISPs.

It probably is a bit more complicated than, but overall it is (mostly) ISP dependent.

But I told: these Domains have the same NameServer and point to the same IP (behind CloudFlare) but if you check

nslookup domain.de
nslookup domain.ch

They point to different IPs but why?
Its not up to my ISP as I use CloudFlare to resolve IPs. So again this is up to ClouFlare.
I for myself would like to change how my domains get routed!

For my domain.ch it is important to not be fast over all of the world but just in switzerland
For my domain.de the same but just in germany.

Again: even if I call these two domains the one is faster for me then the other (domain.ch is faster, and does have a better TTFB by 15ms) which is noticable as my content is mostly static

You did, but I didnt refer to that.

Thats something you will have to take up with the people who designed Cloudflare’s architecture :slight_smile:

It is up to your ISP where to route packets for IP addresses.

1 Like

Yeah but they are not even responding/answering to my Ticket, which I created 1 Week ago.
I also added Infos from time to time but they just ignore it. :man_shrugging:

Considering you replied to it, it is open right now, correct?

Can you post the ticket number?

Yes Status is “open” here you go: 1772052

1 Like


1 Like

Have to mention that I changed to “cache everything” (1 day ago) as I do not often change content on my page for getting rid of this problem. Btw: making it less noticable as for swiss visitors the page had been very slow.

(I added these Infos also to the Ticket)

Caching everything will keep your content on Cloudflare’s proxies, but wont reduce any higher latency to these proxies.

I cant comment on what you exactly asked support but I’d assume they wont be able to answer why things are the way they are either. In theory it should be probably possible to change everything to the same IP address pair *) but whether they could or would do that is a different subject.

@cloonan mostly likely wont provide a definitive explanation either, however I tagged him to clarify why your ticket appears to have turned silent.

*) Your domains are all on the same plan level, right? If not, that would explain it.

Yes I know how Cache everything works. It also caches the dynamic content and yes it would not solve the issue, but making it “better” as swiss visitors do not have to get routed to AMS, then waiting for my server to deliver the package to AMS (from Karlsruhe) and then again to Switzerland.
So this is ‘setting’ the TTFB to the time it needs to go to AMS as it will be delivered by the CloudFlare Cache.

Yes my Domains are all on the same plan level.

I just think its not routed very good. Also let us decide how to route it (domain.ch to Switzerland, domain.de to somewhere in germany) would speed things up (maybe not overall) but at the target clients, as all who are calling domain.ch are from switzerland

Have to says, in the meantime the domain.de domain gets served from LHR not ZRH anymore but again its like 1000km away and cant be faster then FRK or MUC

Really sorry for the issues, @M4rt1n, I see your ticket and the detail you’ve added to it, thank you. I will keep an eye out on the ticket and get with the Support team to review.


Is that one on a free plan?
I have a .cf domain (free plan, server location is Strasbourg) which is routed via London. A .de domain (business) is routed through FRA. But I don’t see any issues, even with large files . :thinking:

Fun fact: my VPN breakout is next door to Cloudflare‘s edge in FRA.

Let it know the outcome please :slight_smile:

1 Like

Yes both domains I’m speaking of are FreePlan Domains.

I also tought about switching to Pro but this topic is already explained here → LINK

So for the moment I’m not switching to pro, also I saw a lot of pages getting routed through FRA which would be as good as MUC for germany (maybe FRA is even better as more in the middle)

Some additional things

I did a traceroute from my VPN node and I am routed via LHR.
Another system within the same AS but different Class C is routed via FRA.


jumper (                                   2019-10-30T08:20:38+0000
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                       Packets               Pings
 Host                                  Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. _gateway                           0.0%   788    0.3   0.2   0.2   0.5   0.1
 2. 62.XX.XXX.XXX                      0.0%   788    1.1   1.4   0.3 133.4   9.4
 3. gi7-2.                             0.0%   788    1.7   1.1   0.7   2.2   0.3
 4. tengige0-1-1-1-                    0.0%   788   10.9  11.0  10.4  15.2   0.6
 5. tengige0-1-1-1-                    0.0%   788   10.3  10.7  10.1  22.8   0.9
 6. linx-lon1.as13335.net              0.0%   788   16.4  12.8  10.5  38.1   4.0
 7.                      0.0%   788   10.5  10.1   9.8  11.9   0.3

Second server

localhost (x)           2019-10-30T09:22:25+0100
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
Packets               Pings
Host                                Loss%   Snt   Last   Avg  Best  Wrst StDev
1. 2axx:xxxx:xxx:xx                  0.0%     8    0.2   0.2   0.2   0.3   0.0
2. fa0-2-172.                        0.0%     8    1.2   1.1   1.0   1.3   0.1
3. de-cix2.                          0.0%     7    1.4   1.5   1.3   1.7   0.1
4. de-cix-frankfurt.as13335.net      0.0%     7    1.6   1.7   1.3   2.4   0.3
5. 2606:4700:30::681c:12ba           0.0%     7    0.8   0.7   0.7   0.8   0.0

Is it possible that this is an IPv6 thing? Every time I use v6 I get routed to FRA, on IPv4 LHR, AMS, VIE… :thinking:

No sure as my Server does not use IPv6 but on CloudFlare I overwrite the header so IPv6 visitors can visit, even if my server does not have a IPv6

Sorry, I was indistinct. It seems different when the client is using IPv4.

Just re-checked that via /cdn-cgi/trace


From our office, IPv6: FRA
(Both on the same ASN)

VDSL at home: IPv6: FRA.
With IPv6 disabled in Windows: LHR

Several public WiFis with IPv4 only: AMS, VIE, LHR

No matter if Free or Business

Have you seen this?

When a POP is congested, you get rerouted to other POPs, and that will depend on how much you pay (Free plans first, then Pro, etc).

You won’t necessarily be rerouted to the second nearest POP. I’m in LIS and when this last happened websites were rerouted to either AMS or LRH depending on the ISP. This was pretty common, then it stopped (always get LIS now), which is consistent with LIS getting a capacity upgrade. LHR and AMS are probably the highest capacity (and cheapest to run) European POPs.

Also, not sure if this is still true, but a while ago some POPs never served Free traffic from certain ISPs, because of deals those ISPs failed to strike with Cloudflare (free peering). This was mostly in Australia (also I guess India) but it’s not something I’ve personally witnessed in large scale in Europe.

You get what you pay for. Is the latency that bad to AMS/LHR? Also ZHR doesn’t strike me as bad for FRA traffic.

Finally, if you want traffic being served from the POP closest to your server (not your users), you should enable Argo, and use Cloudflare Tunnel . That’ll also cost you.