Your report is logged and tracked on our side, and the diagnostics you included are exactly what we would have asked for.

The mis-selection is happening on the Cloudflare-to-origin leg, not on the path to our edge. Your own measurements confirm that: the same services resolve to cdg1 when the records are queried directly. We take on edge routing work of this shape once we see it reported across multiple accounts and can identify a shared pattern in the affected paths. Right now this is an isolated report, so it is not something we can action immediately.

The workaround available today is to take the records out of Cloudflare's proxy and set them to DNS only. That removes the Cloudflare-to-origin hop entirely and resolves straight to our edge, which is already selecting cdg1 for you. Argo will not fully close the gap, since it is still choosing among the same origin paths.

Thanks, that matches what I measured, and I understand the threshold for acting on it. Two findings that may be useful for the shared pattern you are looking for, and for anyone landing on this thread.

TIERED CACHE WORKS AROUND IT, WITHOUT LEAVING THE PROXY

Enabling Cloudflare Tiered Cache (Smart topology, available on the Free plan) changed the picture completely. Before, forced cache MISSes split between mel1 (1350-1390 ms) and bcn1 (~90 ms). After, 10 out of 10 MISSes stay in Europe: ams1 five times, bcn1 four times, cdg1 once, median 123 ms on assets and 114 ms on HTML. ams1 is the same city as the origin.

The upper tier appears to select a PoP near the origin instead of following the anycast path that was picking mel1. The bad path is still there, it is simply no longer on the critical path for cached content. That may be a useful datapoint on where the mis-selection actually happens.

WHY DNS ONLY IS NOT VIABLE HERE

Most of this site's traffic is organic search from Indonesia and India. Removing the proxy would also remove the Cloudflare edge cache, so those visitors would go from a cache hit at a nearby PoP to a full trip to Amsterdam on every page. Measured HTML TTFB is 56 ms from the edge cache against 59-114 ms from the native Railway domain measured in France, and considerably worse from Asia. DNS only would fix the routing but cost more than it saves in this particular case.

ON THIS BEING AN ISOLATED REPORT

The thread composer displayed "4 similar threads found" while I was writing this one, and the two I linked were the same shape and were actioned. Not pushing for priority, just flagging it in case they help identify the shared pattern.

Happy to share project and service IDs, run traceroutes from specific regions, or re-test if you push any change to the edge subnets.

The Tiered Cache finding is genuinely useful, thanks for documenting it. The upper tier bypassing the bad anycast path and selecting a PoP near the origin is a strong signal about where the mis-selection sits in the Cloudflare-to-origin leg, and it is a cleaner workaround than Argo for this shape of problem.