7 days ago
Hi,
my production service is deployed to europe-west4 (ams) and the container confirms RAILWAY_REPLICA_REGION=ams, but its outbound traffic is routing via the US West coast, which has made my client-facing app 3–10× slower for about two weeks. Hoping someone from the team can take a look, as no self-serve action fixes it.
Project ID: b5117526-8c6c-4232-bf70-b1dcbdecb4ba Service: printplus-dashboard, environment production, region europe-west4 (ams), 1 replica Working comparison: the same service's staging environment, also ams, is unaffected
Evidence (reproducible via railway ssh)
From the production container:
fetch('https://.supabase.co/cdn-cgi/trace') → colo=SJC (San Jose), egress IP 152.55.177.181 (Railway netblock RC-1550)
Timed fetches to my Supabase project (AWS eu-west-1, Dublin): ~650 ms on a new connection, ~205 ms warm — from a container that should be ~20 ms away
DNS is fine (3 ms, IPv4)
From the staging container (same project, same region, identical build):
Same trace → colo=AMS, egress IP 208.77.244.162 (netblock RLWY-METALGEN1-02)
The same app endpoint (2 sequential DB round trips) answers in ~0.25 s on staging vs 1.1–4.5 s on production
A container in ams being served by Cloudflare's San Jose edge means the packets genuinely travel via the US — so it looks like either the routing/announcement for the 152.55.177.x egress block, or the specific host my production replica keeps landing on.
Already ruled out
Redeploying — the service comes back on the same egress (still colo=SJC after redeploy)
Application code — staging runs the identical build fast
The database — healthy, sub-millisecond execution, both projects in eu-west-1
Ask
Could the production replica be moved to a host with correct European egress routing, or the routing for 152.55.177.x be fixed? Happy to run any diagnostics via railway ssh. Thanks!
1 Replies
7 days ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • 7 days ago
2 days ago
Kinda sounds like a Railway-side routing/egress issue rather than something in your app.
The staging vs production comparison is especially useful here since they’re both in europe-west4 (ams) and running the same build, but staging is going through AMS while production is consistently showing SJC. That essentially rules out the application code and makes the specific production replica/host or the 152.55.177.x egress range look like the likely problem imo.
The fact that redeploying doesn’t change the egress either is another good indication that this isn’t just a temporary bad connection. If the production container is still getting colo=SJC after a redeploy while the staging container gets colo=AMS, I’d expect Railway to check where that production replica is being hosted and how that egress IP block is being announced/routed.
The latency numbers also line up with what you’d expect from the traffic actually leaving Europe. ~650 ms for a new connection to a database in Dublin from an AMS container is way outside what you’d normally expect, while staging being around 250 ms for the same application/database workload makes the difference pretty clear.
I’d definitely include the 152.55.177.181 egress IP and the fact that Cloudflare reports SJC, since that gives Railway something concrete to investigate on their side. Asking them to either move the replica to a correctly routed AMS host or investigate the routing/announcement for that egress block seems like the right request.
Hopefully helps!