10 hours ago
Summary: With Cloudflare proxying our custom domain, every request enters
Railway's network at mel1 even though the service runs in Europe West. The
same service reached directly enters at lhr1 and is 5–6x faster. This matches
two existing reports of the same pattern, so I am adding a third data point.
Existing reports of the same signature:
- https://station.railway.com/questions/cloudflare-proxied-domains-route-to-mel1-3d3ca049 (Cloudflare MRS, from France)
- https://station.railway.com/questions/cloudflare-proxied-domain-routes-to-mel1-f3b47faa
Project: thriving-playfulness — e259f36f-a312-441c-965b-e97887e660db
Environment: production — 4a236f8c-aae0-4708-8cda-e14b650d2eed
Services:
web—3415e40d-65d3-47bd-aa67-66a24e43b74a— deploymentff7ace6f-8eae-4b41-a031-ee62530cb6f4jobsee-api—81afe1ff-743a-417c-bae5-59536fea0341career—b004b034-5a72-433c-a889-782a39c5f871
Domains: jobsee.ie and www.jobsee.ie, both Cloudflare-proxied (orange),
both routing to the web service.
Observed from: Dublin, Ireland — AS6830 (Liberty Global).
CDN: Cloudflare, Free plan. cf-ray ends in -DUB, so the user-facing edge
is Dublin — the detour is purely on the Cloudflare-to-origin leg.
Measurements (taken 2026-09-11, with X-Railway-Debug: 1):
| Path | x-railway-edge | x-railway-upstream-zone | TTFB |
|---|---|---|---|
| https://jobsee.ie/ (via Cloudflare) | mel1 | railway/europe-west4-drams3a | 0.73–0.81 s |
| https://jobsee.ie/api/backend/healthz (via Cloudflare) | mel1 | railway/europe-west4-drams3a | 0.70 s |
| https://web-production-10dd2.up.railway.app/ (direct) | lhr1 | railway/europe-west4-drams3a | 0.11–0.17 s |
8 out of 8 proxied requests returned mel1; the direct path consistently
returned lhr1. The deployment zone is correct in both cases, so the
mis-selection is on the Cloudflare-to-origin leg, not the path to the edge.
The origin hostname resolves to a single address (69.46.46.125) from public
resolvers with no GeoDNS, so there is no per-region answer to pin and no
customer-side setting that selects an egress.
Impact: ~0.6 s added to every request that reaches the origin. Pages served
from Cloudflare's cache are unaffected (65 ms from Dublin); everything
session-bearing — the authenticated app and every API call — pays it in full.
Ask: localise the anycast announcement of 69.46.46.0/24 on the
Cloudflare-facing paths, or move these domains onto edge subnets that already
route correctly from Cloudflare. Happy to run diagnostics on request
(traceroutes, timed samples, or a fixed test hostname you can watch).
On the DNS-only workaround: we are not taking it. It would cost us the WAF
in front of an authenticated application and the edge caching this storefront
depends on. We understand Argo does not close the gap either, since it is still
choosing among the same origin paths.
3 Replies
Status changed to Awaiting Railway Response Railway • about 10 hours ago
6 hours ago
We don’t have a confirmed fix or timeline for the routing you’ve reported. Disabling Cloudflare’s proxy is the workaround we can currently recommend, but we understand that losing its WAF and caching makes that unsuitable for your application. We can’t currently offer a verified alternative that preserves those features and resolves the detour.
Status changed to Awaiting User Response Railway • about 6 hours ago
sam-a
We don’t have a confirmed fix or timeline for the routing you’ve reported. Disabling Cloudflare’s proxy is the workaround we can currently recommend, but we understand that losing its WAF and caching makes that unsuitable for your application. We can’t currently offer a verified alternative that preserves those features and resolves the detour.
4 hours ago
Update: the detour is gone on our side.
As of 2026-09-12, every request now enters at a European edge:
/app x-railway-edge: lhr1 0.093–0.122 s (was mel1, 0.70 s)
/api/backend/healthz x-railway-edge: lhr1 0.092–0.118 s (was mel1, 0.70 s)
/ x-railway-edge: ams1 cache HIT, 0.086 s
8/8 samples over ~40 s, so it looks stable rather than a one-off. Cloudflare is
now as fast as hitting the origin directly (0.114–0.152 s), which is what we were
after.
We changed nothing on our side that would explain it — same DNS, same proxy
settings, same Cloudflare-to-origin hop. Did anything change on the edge subnet or
the announcement for 69.46.46.0/24?
Not claiming a fix, and not assuming it's permanent — we don't know the cause, so
we're treating it as something that could regress. We've kept a Cloudflare Tunnel
connector deployed as a contingency: outbound-only, so it skips Railway's public
edge entirely, and unlike the DNS-only workaround it preserves the WAF and edge
caching. We haven't needed to route traffic through it yet, so I can't call it
verified.
Flagging it here because the two reporters above are still affected and the
situation has changed for us.
Status changed to Awaiting Railway Response Railway • about 4 hours ago
2 hours ago
The improvement is noted. Consistent with what was shared earlier, we haven't confirmed a specific change that would explain the shift from mel1 to European edges, so treating it as potentially temporary and keeping the tunnel as a fallback is pragmatic.
Status changed to Awaiting User Response Railway • about 2 hours ago