[iforgotpassword]

I'd guess if this gains traction, the caching on Cloudflare's side will usually make up for this, and if it hits the actual mirror behind it, the load on that one should be lower than before. It reads like they will try to proxy multiple local mirrors so time will tell how well they will pick amongst them. I'm switching for now to see how it will perform over a longer period.

[gravitas]

The difficulty is if the mirror itself is behind, Cloudflare's cache for that specific endpoint will be correct (functional, working) but out of date compared to another mirror.

Example: around the end of June this year the mirrors.kernel.org infra was failing to sync (DNS issues of some sort) the latest content, so your upgrade would appear to have no new packages because the stale content was a valid repo, when in fact there were many updates and other mirrors were in sync.

[iforgotpassword]

Right that makes sense, so Cloudflare would actually have to make the caching context-aware, not just classic HTTP proxying.

[gravitas]

I'm not aware of the technical how, but the Arch infrastructure seems to measure this successfully; a hook into this data might be a great way for the two to interoperate (so that Cloudflare always serves the freshest cache/mirrors). https://www.archlinux.org/mirrors/status/

[Foxboron]

The relevant code can be found here I believe: https://github.com/archlinux/archweb/blob/master/mirrors/man...