20 days ago
Project: calm-mindfulness (21e69079-6f5a-440f-a401-33b0e65a0130), environment production, service portable-call-crm (0a5f716c-c119-4717-9b8b-65cf5c9d5a9e), deployment 86d72f24-ce34-4028-901f-6831afe1fcb3, Hobby plan.
Since moving this NestJS service from us-west2 to europe-west4-drams3a (2026-09-15 22:36 UTC), our Postgres round-trips to Supabase in AWS eu-central-2 (Zurich) got SLOWER: 165 ms → 311 ms per round-trip (measured in-app with Sentry on 75,000+ trivial statements such as BEGIN/COMMIT).
Evidence:
The container is in europe-west4-drams3a (x-railway-upstream-zone header, x-railway-edge: ams1).
Its outbound IPv4 address is 162.220.232.99 (GET https://api.ipify.org from inside the container, and peer_ip seen by the Supabase pooler).
Your geofeed (https://geofeed.railway.com) lists 162.220.232.0/23 as US-CA Santa Clara, while your Amsterdam blocks are 208.77.244.0/23 and 152.55.184.0/22.
External probes: 162.220.232.99 answers in 12.7 ms from Los Angeles and 143 ms from Amsterdam.
The +146 ms delta matches the Amsterdam↔California RTT: traffic appears to go Amsterdam → California NAT → Zurich.
The same egress IP was in use when the service was in us-west2, before the region change.
Questions:
Is it expected that europe-west4-drams3a services egress through a California NAT pool? Can the egress affinity be reassigned to an Amsterdam block for this service?
Would Static Outbound IPs (Pro) on this service be allocated from the Amsterdam blocks (docs say IPs are "tied to the region")?
Is Outbound IPv6 egress regional (Amsterdam) for this region?
Thanks.
1 Replies
20 days ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • 20 days ago
19 days ago
I’d test IPv6 first, since it may provide a different egress path than the current IPv4 NAT.
-
Enable railway outbound IPv6 for portable-call-crm.
-
From the container:
curl -6 https://api64.ipify.org getent ahostsv6 db.project-ref.supabase.co
-
If IPv6 works, connect directly to supabase over IPv6 and compare the same BEGIN/COMMIT workload.
If IPv6 is significantly faster than the current ~311 ms, that would be evidence that the IPv4 egress path is contributing to the latency.
The Santa Clara geolocation is a useful clue, but it doesn't by itself establish that traffic is actually traversing california.
First test: enable IPv6 and run commands above.