in other words, we're running from a US data center (IAD), yet the location is still HK

AAvi in other words, we're running from a US data center (IAD), yet the location is s...

C

Chaika•4/28/25, 7:36 PM

ignore the

loc

loc

loc

loc, that's tied to GEOIP and is the same thing I was showing above (that original request geoip is what gets passed)

C

Chaika•4/28/25, 7:38 PM

the

colo

colo

colo

colo being IAD for an eu jurisdiction is more interesting, somehow your jurisdiction isn't being set properly, you'd probably want to look further up on your namespace setup

A

ALECKS•4/28/25, 7:43 PM

Does Cloudflare have a KMS - like service?

A

ALECKS•4/28/25, 7:44 PM

Also, any news on worker containers release?

CChaika the `colo` being IAD for an eu jurisdiction is more interesting, somehow your ju...

A

AviOP•4/28/25, 8:14 PM

sorry,

IAD

IAD

IAD

IAD was for

fedramp

fedramp

fedramp

fedramp

A

AviOP•4/28/25, 8:14 PM

my conern is precisely that the original request geoip is being passed

A

AviOP•4/28/25, 8:15 PM

user is in HK -> requests to worker -> binds to DO -> DO fetch handler -> DO makes subrequest -> openai

A

AviOP•4/28/25, 8:15 PM

somehow, the HK location is being passed all the way through there

A

AviOP•4/28/25, 8:15 PM

you'd think that it wouldn't, though, since it's the DO making a "new" request, we're not just proxying...

A

AviOP•4/28/25, 8:16 PM

to be more clear, if I fetch

https://cloudflare.com/cdn-cgi/trace

https://cloudflare.com/cdn-cgi/trace

https://cloudflare.com/cdn-cgi/trace

https://cloudflare.com/cdn-cgi/trace from within a DO, the

loc

loc

loc

loc is set to the

loc

loc

loc

loc of the original request

A

AviOP•4/28/25, 8:16 PM

that's the behavior i'm surprised by

C

Chaika•4/28/25, 8:17 PM

yea, it's just the geo data that gets through all the way to the end request

C

Chaika•4/28/25, 8:17 PM

even if fetching different account workers-and-pages-discussions

A

AviOP•4/28/25, 8:17 PM

how do i stop that though

C

Chaika•4/28/25, 8:17 PM

I can repro the same in a more limited env/not passing any headers.

A

AviOP•4/28/25, 8:17 PM

seems like a privacy issue, no?

AAvi how do i stop that though

C

Chaika•4/28/25, 8:17 PM

I don't think you do. It seems purposeful/intentional

AAvi seems like a privacy issue, no?

C

Chaika•4/28/25, 8:18 PM

it's just coarse geoip data, not the requesting ip or anything

A

AviOP•4/28/25, 8:18 PM

i suppose so

A

AviOP•4/28/25, 8:18 PM

do you know how that data is actually passed?

A

AviOP•4/28/25, 8:18 PM

it doesn't seem like a header

A

AviOP•4/28/25, 8:18 PM

perhaps its out of band, and re-created as a header on the incoming request?

AAvi perhaps its out of band, and re-created as a header on the incoming request?

C

Chaika•4/28/25, 8:21 PM

yea, I think it's entirely out of your direct control/just gets passed through some other property to the Durable Object in the call. The Durable Object makes a request out, which goes through the CDN stuff, and the request out just contains the geo data stuff lingering. It's up to the customer's config on how it's used/if its put into a header/etc

A

AviOP•4/28/25, 8:21 PM

right

C

Chaika•4/28/25, 8:21 PM

could try using RPC instead of fetch to further ensure it's not any piece of the request

A

AviOP•4/28/25, 8:21 PM

my mental model is that cloudflare has its own metadata attached to requests flowing within the CF network

A

AviOP•4/28/25, 8:21 PM

and somewhere there is geo data

and if the receiving side has the geoIP enrichment feature enabled, they attach that data as headers to the incoming request just before delivering it to the worker

C

Chaika•4/28/25, 8:22 PM

I've noticed this same behavior of cross-zone/acct fetches using worker's ip in cf-connecting-ip but not replacing the geodata for years, just never fully tested with Durable Objects and everything

A

AviOP•4/28/25, 8:41 PM

interesting

A

AviOP•4/28/25, 8:41 PM

do you happen to know where worker cron jobs run?

A

AviOP•4/28/25, 8:41 PM

like how does cf decide which colo to run those

A

AviOP•4/28/25, 8:44 PM

hm, it seems like its based on lowest available load, which means it could really be anywhere

AAvi hm, it seems like its based on lowest available load, which means it could reall...

C

Chaika•4/28/25, 8:51 PM

yea pretty much anywhere, I have a bunch of cron monitoring, in the last 24 hours

A

AviOP•4/28/25, 8:51 PM

oh wow!

A

AviOP•4/28/25, 8:52 PM

that's so cool, those are the colos your cron workers ran from in the past 24h?

AAvi that's so cool, those are the colos your cron workers ran from in the past 24h?

C

Chaika•4/28/25, 8:53 PM

indeed. For a specific account/cron picks a location and usually sticks with it for a few hours, barring any incidents

A

AviOP•4/28/25, 8:53 PM

very cool

A

AviOP•4/28/25, 8:53 PM

well... none of those countries seem to be on the openai banned list

A

AviOP•4/28/25, 8:54 PM

the countries that are blocked by OpenAI but have colos seem to be:

Russia
Saudi Arabia
Hong Kong
China (mainland)

A

AviOP•4/28/25, 8:55 PM

we're debating solving this problem of the request geolocation by shifting the work to run out-of-band from the inital request, via a cron job

C

Chaika•4/28/25, 8:56 PM

HKG is going to be the biggest one there and one that supports Durable Objects
CF has Russia stuff but not too much I don't think. China for Cloudflare is all locked behind Enterprise

A

AviOP•4/28/25, 8:56 PM

well it's just a scheduled worker so i dont think it'd need to support DO

A

AviOP•4/28/25, 8:56 PM

good to know china is behind enterprise

AAvi well it's just a scheduled worker so i dont think it'd need to support DO

C

Chaika•4/28/25, 8:57 PM

true but supporting DOs is an indictator of sign/nearby locations (in HKG's case case, CF has ~9 or so colocations making up the entire PoP)

A

AviOP•4/28/25, 8:58 PM

but why would that impact the likliehood of a cron job getting scheduled to run there?

C

Chaika•4/28/25, 8:58 PM

only a few locations run cron jobs

CChaika only a few locations run cron jobs

A

AviOP•4/28/25, 8:59 PM

i see, and it sounds like, so far, it's a safe bet that those WONT be in russia/china/saudi arabia/HK?

A

AviOP•4/28/25, 8:59 PM

riskiest one being HK, it sounds like

AAvi i see, and it sounds like, so far, it's a safe bet that those WONT be in russia/...

C

Chaika•4/28/25, 9:01 PM

Pretty much. I've been collecting cron data into this system from 2025-03-17 01:44:20, and I've only seen

    ┌─colo─┬─count─┐
 1. │ EWR  │ 26965 │
 2. │ LHR  │ 38506 │
 3. │ ZRH  │ 38292 │
 4. │ IAH  │ 25177 │
 5. │ KIX  │ 39401 │
 6. │ MEL  │ 35336 │
 7. │ SCL  │ 22145 │
 8. │ WAW  │ 33659 │
 9. │ SLC  │ 28135 │
10. │ TPE  │ 33274 │
11. │ NRT  │ 34217 │
12. │ SIN  │ 41770 │
13. │ MAD  │ 40630 │
14. │ DFW  │ 25319 │
15. │ DTW  │ 30731 │
    └──────┴───────┘

    ┌─colo─┬─count─┐
 1. │ EWR  │ 26965 │
 2. │ LHR  │ 38506 │
 3. │ ZRH  │ 38292 │
 4. │ IAH  │ 25177 │
 5. │ KIX  │ 39401 │
 6. │ MEL  │ 35336 │
 7. │ SCL  │ 22145 │
 8. │ WAW  │ 33659 │
 9. │ SLC  │ 28135 │
10. │ TPE  │ 33274 │
11. │ NRT  │ 34217 │
12. │ SIN  │ 41770 │
13. │ MAD  │ 40630 │
14. │ DFW  │ 25319 │
15. │ DTW  │ 30731 │
    └──────┴───────┘

    ┌─colo─┬─count─┐
 1. │ EWR  │ 26965 │
 2. │ LHR  │ 38506 │
 3. │ ZRH  │ 38292 │
 4. │ IAH  │ 25177 │
 5. │ KIX  │ 39401 │
 6. │ MEL  │ 35336 │
 7. │ SCL  │ 22145 │
 8. │ WAW  │ 33659 │
 9. │ SLC  │ 28135 │
10. │ TPE  │ 33274 │
11. │ NRT  │ 34217 │
12. │ SIN  │ 41770 │
13. │ MAD  │ 40630 │
14. │ DFW  │ 25319 │
15. │ DTW  │ 30731 │
    └──────┴───────┘

    ┌─colo─┬─count─┐
 1. │ EWR  │ 26965 │
 2. │ LHR  │ 38506 │
 3. │ ZRH  │ 38292 │
 4. │ IAH  │ 25177 │
 5. │ KIX  │ 39401 │
 6. │ MEL  │ 35336 │
 7. │ SCL  │ 22145 │
 8. │ WAW  │ 33659 │
 9. │ SLC  │ 28135 │
10. │ TPE  │ 33274 │
11. │ NRT  │ 34217 │
12. │ SIN  │ 41770 │
13. │ MAD  │ 40630 │
14. │ DFW  │ 25319 │
15. │ DTW  │ 30731 │
    └──────┴───────┘

A

AviOP•4/28/25, 9:01 PM

amazing

in other words, we're running from a US data center (IAD), yet the location is still HK

Similar Threads