cf-connecting-ip mismatch.. how?
yes, you're not reading it wrong.
i have a sample request with cf-connecting-ip "appearing" to be an Cloudflare IP, however the remaining IP data is completely different.
anyone have any ideas why? the asn & geocity is inserted from transform rules
"cf-connecting-ip": "2a06:98c0:3600::103" // quick google search owned by CF.
"x-ip-asn": "7713" // transform rules ip.geoip.asnum
"x-ip-city": "Pontianak", transform rules ip.src.city
"cf-ip-asorg": "PT Telkom Indonesia" // inserted by workers
30 Replies
It's a Worker subrequest
i added another header in transform rules with value
ip.src and its showing the same thing.That IP is used for Cross-Cloudflare Worker fetches
it passes along the normal geo data though
cross-workers doesnt go through transform rules right?
it'd go through the entire flow as long as it's from an external zone
no. it's the same zone
my first thought was cloudflare warp
but shouldn't it show as cloudflare's asn instead?
then it'd go through slightly less (obviously not through workers again), but still most of the flow
That IP is used for Worker Subrequests alone
hm interesting
the funny thing is that its only occuring on this user (i have tracing)
im not experiencing it.
so there's something this dude knows that i dont
You have a worker running on that same zone fetching it? Are you sure it's not someone else's worker? Check CF-Worker header
Some docs on it: https://developers.cloudflare.com/fundamentals/reference/http-request-headers/#cf-connecting-ip-in-worker-subrequests
Cloudflare Docs
Cloudflare HTTP request headers | Cloudflare Fundamentals docs
Cloudflare passes all HTTP request headers to your origin web server and adds additional headers as specified below.
yep i can cofirm it's my own zone
no I mean like the original request which hits the worker has to be on the same zone
ex: user -> worker.example.com -> fetch -> example.com
user -> otherwebsite.com -> fetch -> example.com would be cross-zone
no. the user is hitting the same domain/endpoint as everyone does
cf-worker is my own zone & host header is the same with other users too
That
cf-ew-via is interesting
I wonder if they didn't go External Worker -> Your Worker -> Websitehm
so it might be possible.. that this user is using a worker
to hit my endpoint?
(their own worker)
their own worker to hit your worker which proxies the request, if I understand your setup right
yes i do use worker to proxy it
hm this is interesting
makes sense now
thanks for enlightening me @Chaika 😅
Sure, the behavior of changing connecting ip but keeping geo has always been a bit weird
something to do with cross-workers req probably
well yea that's when it overwrites the connecting ip but the fact it still keeps geo of the original request
do you know if worker's outgoing fetch send cf-worker header to the endpoint?
to the original worker one? Yea
should be something like
ext Worker -> your worker
CF-Worker: extZone
your worker -> proxied request
CF-Worker: yourZone
how would i be able to capture the extZone in my zone?
definitely before hitting the worker
it'd be in the request headers of the request that hits your worker
ah you're right
my tracing only log headers from (my) proxied request so it would show as my zone
caught it. thx for the help once again @Chaika
