Wrong datacenter used to cache files?

I’ve noticed an issue where my requests to cached files are being handled on the other side of the world. Is this expected to happen?

I am in Germany, and requesting for example this URL:
https://www.cloudflare.com/img/logo-cloudflare-dark.svg
Results in: cf-ray: 57fdd390fd99c2bd-FRA

However, requesting an URL from our site, like this:
https://static.brickadia.com/website/ea3fadf132d04b11724edd13d457ea30565680c2/images/brickadia-logo-trimmed.png
Results in: cf-ray: 57fdd6987d68c1a2-IAD

Which is nowhere near Germany at all. What happened?

IAD is Dulles International Airport which is in the USA. Are you sure you are not using any VPN? If not pls open a ticket at CloudFlare support. They will help you.

Yes, VPN is off, I checked it twice. I will try the support ticket.

Just to be sure: could you call: https://www.wieistmeineip.de and provide your anonymized IP? (last block should be replaced by “0”)

It is showing me 79.239.196.0 and that I’m in Germany.

True thats in germany. Pls open a support ticket and give them the needed Infos like domain, IP from origin Server etc. They will guide you trough this

Would you mind doing a ping and trace route to the two websites you listed?

This is what I get, assuming it’s what you meant:

>ping www.cloudflare.com

Pinging www.cloudflare.com [2606:4700::6811:d109] with 32 bytes of data:
Reply from 2606:4700::6811:d109: time=11ms
Reply from 2606:4700::6811:d109: time=9ms
Reply from 2606:4700::6811:d109: time=13ms
Reply from 2606:4700::6811:d109: time=9ms

Ping statistics for 2606:4700::6811:d109:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 9ms, Maximum = 13ms, Average = 10ms

>tracert www.cloudflare.com

Tracing route to www.cloudflare.com [2606:4700::6811:d109]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  p200300D21F11C3009A9BCBFFFE2F8CD2.dip0.t-ipconnect.de [2003:d2:1f11:c300:9a9b:cbff:fe2f:8cd2]
  2     4 ms     4 ms     4 ms  2003:0:8501:c000::1
  3    10 ms     9 ms    10 ms  dtag-ic-319284-ffm-b4.c.telia.net [2001:2000:3080:104f::2]
  4     *        *        *     Request timed out.
  5    10 ms    10 ms    10 ms  2001:2000:3019:6b::1
  6    10 ms    10 ms    10 ms  ffm-b1-v6.telia.net [2001:2000:3018:90::1]
  7    13 ms    11 ms    11 ms  cloudflare-ic-328337-ffm-b1.c.telia.net [2001:2000:3080:760::2]
  8    10 ms    10 ms     9 ms  2606:4700::6811:d109

Trace complete.

>ping brickadia.com

Pinging brickadia.com [104.27.164.23] with 32 bytes of data:
Reply from 104.27.164.23: bytes=32 time=122ms TTL=58
Reply from 104.27.164.23: bytes=32 time=121ms TTL=58
Reply from 104.27.164.23: bytes=32 time=121ms TTL=58
Reply from 104.27.164.23: bytes=32 time=121ms TTL=58

Ping statistics for 104.27.164.23:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 121ms, Maximum = 122ms, Average = 121ms

>tracert brickadia.com

Tracing route to brickadia.com [104.27.164.23]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  FRITZ-NAS [192.168.178.1]
  2     4 ms     4 ms     6 ms  62.155.243.56
  3    10 ms    10 ms    10 ms  f-ed11-i.F.DE.NET.DTAG.DE [62.154.2.185]
  4    12 ms     9 ms    10 ms  62.157.250.38
  5    44 ms    44 ms    44 ms  et1-1-5.parigi72.par.seabone.net [195.22.210.122]
  6    45 ms    47 ms    36 ms  213.144.173.161
  7     *        *        *     Request timed out.
  8   121 ms   121 ms   121 ms  104.27.164.23

Trace complete.

This domain gets served from AMS (Amsterdam) for me.

Do you have any idea what could cause it to be served from the US for me?

Well yes CloudFlare could cause it by “rating” your IP wrong.
CloudFlare tries to serve every request from the nearest POP, but is also respecting costs. So most probably in germany you could be served from FRA the fastest way but instead you get served from AMS becasue its cheaper for CLoudFlare.

But getting served from IAD for me indicates there is something wrong with CloudFlares “tracking” of your IP. But I can not tell you more. Pls verify that this Image is getting served from IAD:

https://static.brickadia.com/website/ea3fadf132d04b11724edd13d457ea30565680c2/images/brickadia-logo-trimmed.png

Yes, I am still getting cf-ray: 57fe0c1c2e4073a5-IAD.

Sorry I can not resolve this issue for you. But may others can.

Are you willing to provide your DNS Service?
Are you using your standard DNS Server? CloudFlare DNS Server? Google DNS Server? Or any other DNS Server?

I was using Cloudflare DNS (the 1.1.1.1 thing), but let’s see what happens if I change back to the normal one.

Little other tipp:
if you use a subdomain for out-source static assets to another sub-domain. Pls do not use CloudFlare at the subdomain for static assets because the reason for serving assets from another domain is to have a cookiefree domain. Using CloudFlare never is cookiefree.

So just using the maindomain for serving static assets is 100% fine and in this example even faster as the client does not have so resolve another domain :slight_smile:

This is a good point, I am not sure why it is the way it is currently but I’ll pass it on.

Unfortunately changing my DNS settings back to the ones provided by ISP and clearing the cache in windows and chrome has changed nothing, it is still being served from IAD

Oh, it’s that way as preparation so we can use a CNAME entry to redirect that subdomain to a CDN later on. I don’t think that’s possible with a normal path.

You will get served based on what CloudFlare is thinking about where you are, based on your IP and on the route it would be served the fastest. But thats clearly wrong here.
Can you also provide your TTFB here?

But in fact noone will be able to help you here in the forum… sorry. Your Domain have to be re-routed. Just the support is able to do so.

TTFB looks like this:

Yes, I’ve already submitted a support ticket.

I have to slightly correct you here. Cloudflare does limit some POPs to specific plans in some cases due to costs or load, but the actual decision to where you go is done by your ISP. It may be some issue cause by the IPv4 network compared to IPv6, given that the problematic website doesn’t have IPv6 enabled (why?).

1 Like