21 days ago
Project: bob-o-job
Service: @bob-o-job/server (service ID 0c8bb7d3-8782-4c7b-9721-d058ea097cd2)
Environment: production
Region: europe-west4-drams3a (1 replica), scaled here from us-west2 on 2026-07-31 via railway service scale eu-west=1 us-west=0
Issue: every request to this service, on both hostnames below, carries x-railway-edge: lax1 (the LA edge PoP) despite the service running in europe-west4 (Amsterdam). Requests from London take a London -> LAX -> Amsterdam -> back round trip, adding roughly 150-175ms versus a European edge.
Confirmed on two independent hostnames, identical trace-prefix pattern on both, ruling out a per-domain binding issue:
- Generated domain: bob-o-jobserver-production.up.railway.app/health
x-railway-edge: lax1
x-hikari-trace: lax1.e74w
- Custom domain (added today specifically to test whether this was a stale per-domain edge assignment): api.bob-o-job.com/health
Verified: yes, certificate VALID
x-railway-edge: lax1
x-hikari-trace: lax1.sx7j
Both show the identical lax1 prefix, so the edge assignment looks pinned to the service (or to when the generated domain was first created, back when the service was in us-west2) rather than being re-derived from the service's current region.
Note: I searched first and found a related but distinct report from dtrask179 (custom-domain-engine-govnu-dev-502) — theirs was intermittent 502s from specific US edges while the generated domain worked from everywhere. Mine is different: both domains succeed (200/no errors), they just consistently land on the wrong edge, 100% of the time.
Question: is a service's edge PoP supposed to follow its region automatically, or is it fixed at domain-creation time? If the latter, is there a way to force a re-assignment without deleting and recreating the generated domain, which is embedded in installed mobile app builds and can't easily be rotated?
Happy to provide further x-railway-request-id values if useful for tracing.
1 Replies
21 days ago
The edge PoP is not tied to the service's deployment region at all, and it is not fixed at domain-creation time. Edge PoPs and deployment regions are two independent layers: every request enters at the PoP nearest to the requester via anycast/BGP routing, then routes internally to the deployment region where the service runs. So x-railway-edge: lax1 means your test requests entered Railway at LAX based on your ISP's BGP path, not that the service is bound to LAX. You can confirm the request is still being served from Amsterdam by sending X-Railway-Debug: 1 and checking the X-Railway-Upstream-Zone header, which should show railway/europe-west4-drams3a. To verify it is your network path and not something broader, test from European locations via globalping.io - requests from other ISPs in Europe will likely enter at a European PoP.
Status changed to Awaiting User Response Railway • 21 days ago
14 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 • 14 days ago