11 hours ago
Hi Railway team,
Services Web App, Api and Web Landing, all in europe-west4-drams3a.
Custom domains app.sofia-post.com, api.sofia-post.com and www.sofia-post.com.
Measured from France, Cloudflare PoP MRS, free plan.
--
MEASUREMENTS, TAKEN TODAY
Through the Cloudflare proxy, on a page our origin marks no-store so that it always reaches the origin:
8 requests out of 8 returned
x-railway-edge: mel1cf-rayending in-MRSTTFB: 1320 to 1820 ms.
Same host, same page, record set to DNS only:
x-railway-edge: cdg1TTFB: 68 to 118 ms.
A cacheable page through the proxy:
51 to 57 mson a cache hit1350 mson the revalidation that actually reaches the origin, again through mel1.
--
RULED OUT ON OUR SIDE
Not DNS and not GeoDNS. The Railway target resolves to one single address from 1.1.1.1, 8.8.8.8 and 9.9.9.9, and to that same address under EDNS Client Subnet for French, Australian and US client prefixes.
There is no per-region answer, so edge selection is BGP only.
Not hostname or IP specific. Our three targets are 69.46.46.86, 69.46.46.106 and 69.46.46.118, all in the same /24, and all three answer cdg1 when reached directly from France.
Not TLS and not the application. Direct TTFB on the same containers is 55 to 107 ms, handshakes are 20 to 40 ms.
--
THE BGP PICTURE, WHICH IS WHY WE HAVE NO LEVER
69.46.46.0/24 is an ARIN direct allocation to Railway, NET-69-46-46-0-1, named RLWY-HIKARI-01, originated by AS400940.
In RIPE RIS, across 350 observed sessions, that prefix has exactly one upstream: AS60068, Datacamp / CDN77. AS13335, Cloudflare, appears in none of the observed paths, so Cloudflare has no direct adjacency for this prefix and reaches it through that single transit.
That leaves the customer with nothing to configure. There is no per-region address to pin, no second path to prefer, and no Cloudflare setting that selects an egress. Which Hikari PoP wins is decided entirely by how the anycast announcement propagates through AS60068. From a French ISP the winner is Paris. From the Cloudflare Marseille PoP the winner is Melbourne.
--
WHY "SET THE RECORDS TO DNS ONLY" DOES NOT WORK FOR US
We ran that experiment and measured it, and we are running that way right now, so this is not a preference. It costs us three things we depend on.
WAF and bot protection, in front of an authenticated application and its API.Edge caching. Our storefront HTML is s-maxage=60 and our i18n dictionaries are immutable. Both are served in 51 to 68 ms from the Cloudflare cache and in 70 to 180 ms from the origin, and taking the proxy away removes that layer entirely.cf-ipcountry. Our pricing page derives its currency from that header, and it is the only edge country header our stack can read. Without the proxy, every European visitor is quoted in USD instead of EUR. That one is a revenue bug rather than a latency preference.
--
WHAT WE ARE ASKING FOR
Not a workaround. The two threads referenced in f3b47faa were both closed by work on your side, one under the internal ticket "Cloudflare incorrect routing" and the other by moving the affected traffic to new edge subnets. We are asking for the same treatment here: either localize the anycast announcement of 69.46.46.0/24 on the Cloudflare-facing paths, or move these domains onto the edge subnets that already route correctly from Cloudflare.
If the real answer is that a second transit or a direct adjacency with AS13335 is needed, that is worth saying out loud, because it changes what any European team should expect when putting Cloudflare in front of Railway.
Happy to share project, environment, service and domain identifiers privately, and to run any diagnostic on demand: traceroutes, timed samples, or a fixed test hostname you can watch on your side.
2 Replies
Status changed to Awaiting Railway Response Railway • about 11 hours ago
10 hours ago
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.
Status changed to Awaiting User Response Railway • about 10 hours ago
an hour ago
This is not an isolated report. It is the second one, and the first is yours to check: https://station.railway.com/questions/cloudflare-proxied-domain-routes-to-mel1-f3b47faa
Different account, different project, different domains, and the same failure measured from France within hours of each other. The shared pattern in the affected paths is specific enough to act on: Cloudflare MRS PoP, AS60068 as the only upstream of 69.46.46.0/24, and mel1 winning the anycast selection while a direct query from the same country wins cdg1. Both reports show the same three-way split between the Cloudflare leg, the direct leg and the origin region.
That is the bar you named. It is met.
On the workaround: Argo is not one. The other thread measured it on this exact symptom - roughly half the requests moved to bcn1 and the rest still landed on mel1, with p90 unchanged.
DNS only is not one either, for us. We are running that way right now, so this is measured and not hypothetical. It costs us the WAF in front of an authenticated application and its API, the edge cache that serves our storefront in 51 to 68 ms instead of 70 to 180 ms, and cf-ipcountry. That last one is the expensive one: our pricing page derives its currency from that header, so with the records out of the proxy every European visitor is quoted in USD instead of EUR. We are eating a revenue bug to work around a routing bug.
We are asking for the same remedy that closed the two threads referenced in f3b47faa: localize the anycast announcement of 69.46.46.0/24 on the Cloudflare-facing paths, or move these domains onto the edge subnets that already route correctly from Cloudflare.
Happy to stand up a fixed test hostname you can watch from your side, and to send project and domain identifiers privately.
Status changed to Awaiting Railway Response Railway • about 1 hour ago