If the external service doesn't have AAAA records/support IPv6, how would you be connecting to them
If the external service doesn't have AAAA records/support IPv6, how would you be connecting to them over IPv6? Workers are cool but not magical lol
Cfetch uses the normal cdn pipeline too which prefers IPv4 over IPv6
CIf they do use Cloudflare though, they'd see the cf-connecting-ip as the Cloudflare's cross-cf worker's IP, which is
2a06:98c0:3600::103
BThat's a very good point actually, didn't think of that
BThat's exactly what they are seeing according to their support:
If I understand correctly, would they need to enable "Pseudo IPv4" on their Cloudflare account then?
. It's a decently big international service though, so not sure why we are the only ones hitting it with our Workers
Invalid IP address: >2a06:98c0:3600::103.If I understand correctly, would they need to enable "Pseudo IPv4" on their Cloudflare account then?
. It's a decently big international service though, so not sure why we are the only ones hitting it with our Workers
Cohhh ok I thought they weren't on Cloudflare since you said "so not hosted on Cloudflare"
BYeah it's not hosted on my Cloudflare account I meant indeed, was unaware they were on Cloudflare
CIf I understand correctly, would they need to enable "Pseudo IPv4" on their Cloudflare account then?
Edit: Psuedo IPv4 on their zone would, your settings don't effect anything though
Cif you wanted docs to refer them to: https://developers.cloudflare.com/fundamentals/reference/http-request-headers/#cf-connecting-ip-in-worker-subrequests
In cross-zone subrequests from one Cloudflare zone to another Cloudflare zone, the CF-Connecting-IP value will be set to the Worker client IP address '2a06:98c0:3600::103' for security reasons.
Cloudflare Docs
Cloudflare passes all HTTP request headers to your origin web server and adds additional headers as specified below.
BI see, that's very helpful! So this is an edge case, since we are both using Cloudflare Workers (I'm assuming they are), but they are on a different zone, they get the internal worker IPv6 address in
If I understand correctly, there is no easy fix for this on both our sides right?
CF-Connecting-IP, even though they don't have IPv6 set up.If I understand correctly, there is no easy fix for this on both our sides right?
BIn any case, extremely helpful already, so thanks a lot!
CI see, that's very helpful! So this is an edge case, since we are both using Cloudflare Workers (I'm assuming they are), but they are on a different zone, they get the internal worker IPv6 address in CF-Connecting-IP, even though they don't have IPv6 set up.Yep
If I understand correctly, there is no easy fix for this on both our sides right?I thought about it again and tested it, and Psuedo IPv4 does convert the Worker's IPv6 into a Class-E IPv4, but it's not an easy fix and has a lot of drawbacks of its own. Some legacy systems require IPv4 for fraud reasons or do GeoIP lookups, both of which would fail. Having non-real IPv4s in logging/analytics systems is messy as well if trying to understand/piece together logs or build reports.
In a perfect world they would tell your traffic apart from the CF-Worker header when it's a worker, otherwise enough people using CF Workers will run into other rate limits/issues. If they were a partner you were closely tied to, you could pass the actual user's IP in a seperate header too depending on the purpose of your integration.
CYou always have the cumbersome but feasible option of using a proxy that your worker sends requests through as well
C(this got buried, you might want to ask this in #workers-ai btw)
BThanks so much @Chaika, this really was incredibly helpful. I passed the info (and suggested solutions) on the other service. Definitely an error they'll be running into again if more and more people start using Cloudflare Workers!
CI want to check on whether I am missing something obvious...
I have a worker bound to a domain like
Unfortunately, that means I cannot also have another SaaS worker at
A way to make this work would be to write specific routes for SaaS (instead of
I have a worker bound to a domain like
api.something.com. And then I set up SaaS hostnames for it. In order to do that, I set up a route */* in order to match all of the requests.Unfortunately, that means I cannot also have another SaaS worker at
other-api.something.com . (Because the */* route is taken). Is that expected?A way to make this work would be to write specific routes for SaaS (instead of
*/*). But that would be ~ 1 route per custom hostname. Is that expected or advisable to write that many routes? */* is a nice solution, but it only works once per Zone. Which means one SaaS worker per zone 
Bwhen specifying build configuration there are a ton of frameworks to choose from. However, I you none of those and just have a bash script for deployment - I assume this is fine?
Cof course, build config presets are just meant to help guide, you can do whatever your app needs to get built
Bperfect, thank you
CWhat are you looking for exactly, how would two SaaS workers help you? Routes are matched on the incoming hostname which is their custom hostname, they couldn't CNAME at a specific subdomain and get a specific worker for example. You could use a worker or a snippet as a gateway though alongside custom hostname metadata and then use service binding and such to direct to the right one
Lquick question about workers, if I use all 100,000 requests of the free plan, the worker will just stop working until the daily reset, right?
Cit can take a bit for it to stop working/fail espec if they all come in at once, and the exact behavior depends on the worker route settings (can make it fail open -> requests straight to origin) or fail closed (worker custom domains just do this). If the question is just about billing you won't get charged for more or forced to upgrade or anything, it'll just eventually stop working
LOk thanks
Lis there a way to upgrade to the $5/month plan for the 300.000 daily requests but disable billing for requests past the 300.000?
CWorkers Paid includes 10 mil requests for free, it's not broken down daily or anything like that
CYou can setup Alerts for when you go above a specific threshold, but no hard cutoffs
Lso 10 million requests per month?
C10 million included per month
+$0.30 per additional million and then you get billed for cpu time as well (and there's an included tier of that)
https://developers.cloudflare.com/workers/platform/pricing/
+$0.30 per additional million and then you get billed for cpu time as well (and there's an included tier of that)
https://developers.cloudflare.com/workers/platform/pricing/
Lhmmm ok thanks for the info
Crespond with 429/specific status code and you can see it in web traffic analytics (pro or higher)
CI have mine set to 1,500 per minute (per key) and I have some cases where I'm seeing 10x that (15k per minute - assumed to be per key)Is the traffic distributed? Rate limiter is per Cloudflare location/pop
CUnder your website/zone "Analytics & Logs" -> Traffic. You'd have to be sending all the requests through that zone though, wouldn't see any if they were direct to workers.dev
CI mean, is the incoming traffic distributed?
CWorkers by default run in every cloudflare location everywhere
CIf you get 1499 requests in EWR/New York and 1499 in LHR/London and 1499 in SLC/Salt Lake City, your rate limiter wouldn't be exceeded
CYou could use a Durable Object as a rate limiter then per key to have globally consistent limits
CWeb Analytics isn't what you want, that's more Google Analytics type /client-side analytics
CWeb Traffic Analytics is server-side and under each website "Analytics & Logs" -> Traffic
CCall you have to do is have Pro or higher and send the traffic through that website on a worker custom domain or route, and you can see response codes on there:
CIf you wanted more granular/user specific stuff, you send metrics to Analytics Engine: https://developers.cloudflare.com/analytics/analytics-engine/, with the index being some id for the api key and the double/value being blocked or not, and then you could filter off that. You could also just send only rate-limited response metrics, up to you
