a month ago
I've got some services service up on Railway europe-west4, with Cloudflare in front of them. A couple of days ago, one of the users in Dublin reported significantly slowed performance - several seconds per round trip.
I've investigated that today, and found that requests entering Cloudflare in Dublin reach the europe-west4 services through the Melbourne, Australia edge.
Observed this initially on service: erp.stratumcm.io (project stratum-odoo-enterprise, service odoo, deployment d06aecb9-57c7-4ddc-b47b-3d45c9f776e8) and then reproduced it on crm.stratumcm.io (project crm+ops lavish-magic, service twenty)
When I use globalping I can see Dublin probes via Cloudflare: X-Railway-Edge mel1, X-Railway-Upstream-Zone railway/europe-west4-drams3a, with TTFB of 600-1300 ms, on roughly 20-40% of requests. The remaining requests land on lhr1 with TTFB at 40-110 ms.
Direct from Dublin to your anycast, without Cloudflare, goes via lhr1/ams1 every time, ttfb 25-60ms, with traceroutes to 69.46.46.46 from Dublin end in London/Amsterdam in 14ms.
So the anycast is fine from Irish networks. Only Cloudflare Dublin's path to your prefix goes via Melbourne. I can see in our Odoo logs that the mel1 Melbourne edge appears as 89.222.111.x
We've worked round it by taking the erp service off the Cloudflare proxy, but ideally I'd like to return to Cloudflare proxy for the WAF and edge caching.
1 Replies
Status changed to Awaiting Railway Response Railway • 26 days ago
25 days ago
Got the report, and the globalping breakdown plus the X-Railway-Edge / X-Railway-Upstream-Zone headers give a clear picture of the shape of it.
We aren't seeing this reported more broadly right now, so it isn't something we can action immediately, but it is tracked on our side. Your own traceroutes line up with that: the anycast announcement is healthy from Irish networks, and the mel1 selection is happening inside Cloudflare's network on the path to our prefix.
For now, keeping the service off the Cloudflare proxy is the right move, and you don't have to give up the WAF or caching to do it. Both run natively on Railway's edge:
- CDN caching: https://docs.railway.com/networking/cdn
- WAF and Under Attack Mode: https://docs.railway.com/networking/waf
- Edge rules (block, allow, challenge, redirect, cache overrides): https://docs.railway.com/networking/edge-rules
Status changed to Awaiting User Response Railway • 25 days ago
18 days ago
This thread has been marked as solved automatically due to a lack of recent activity. Please re-open this thread or create a new one if you require further assistance. Thank you!
Status changed to Solved Railway • 18 days ago