16 days ago
Project ID: 3f640ce4-b593-4b9f-b811-0ab94a085745
Services affected: api (dcc1f467-5646-408d-8b95-066fde9b5782), web (aa2f3bad-d14e-48ee-abc0-6f604d2c4b09) — identical on both.
curl -H "X-Railway-Debug: 1" against our domain returns:
HTTP/1.1 502 Bad Gateway
server: railway-hikari
x-railway-fallback: true
x-railway-upstream-zone: railway/europe-west4-drams3a
x-railway-edge: ams1
x-hikari-trace: ams1.9qww
Container is fully healthy: status: SUCCESS, replicas.running: 1, crashed: 0. Railway's own internal healthcheck (healthcheck.railway.app) succeeds every few seconds (confirmed in logs). railway logs --network shows zero external request packets ever reaching the container — only that internal healthcheck traffic. The edge is failing before even attempting to reach the container.
Already tried without effect: full redeploy, explicit 0.0.0.0 bind in app code, HOSTNAME=0.0.0.0 env var, deleting/recreating the domain (new hostname each time), region migration to us-west2 and back, service restart.
This matches the exact edge → upstream-zone mismatch signature reported and left unresolved in prior community threads (e.g. "Custom domain returns 502... edge routing bug", "healthcheck passes internally, but edge returns 502 with x-railway-fallback header") — in one of those cases, even self-service domain deletion silently failed to persist, and a completely fresh service in a different region hit the identical signature, pointing to a stuck account-level routing state rather than anything fixable via redeploy/region-change/domain-reset.
Brand-new account/project, first deployment ever, created 2026-08-05.
Could someone from the infra team check whether this account's edge routing to europe-west4-drams3a is stuck, and rebuild it directly?
Pinned Solution
15 days ago
Try changing the port to an arbitrary number (eg, 4100) on your application and URL.
14 Replies
16 days ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • 16 days ago
16 days ago
Ensure the application binds explicitly to :: (IPv6 all-interfaces) rather than 0.0.0.0 (IPv4-only).
Also try Changing the region from europe-west4 to us-east1 or us-west2.
h707
Ensure the application binds explicitly to :: (IPv6 all-interfaces) rather than 0.0.0.0 (IPv4-only). Also try Changing the region from europe-west4 to us-east1 or us-west2.
16 days ago
Update: Tried both suggestions from the community — no luck:
Dual-stack binding (:: instead of 0.0.0.0) in app code + HOSTNAME=:: — same 502/x-railway-fallback result, this time even from a different edge (cdg1 instead of ams1), still unable to reach europe-west4-drams3a.
Attempted a full region migration (eu-west → us-east) via railway service scale — the scale operation itself silently fails with zero build/deploy logs whatsoever, no error message, just status: FAILED with an empty log stream. This suggests something beyond just edge routing may be stuck on this account's deployment orchestration
scicoale550-ui
Update: Tried both suggestions from the community — no luck: Dual-stack binding (:: instead of 0.0.0.0) in app code + HOSTNAME=:: — same 502/x-railway-fallback result, this time even from a different edge (cdg1 instead of ams1), still unable to reach europe-west4-drams3a. Attempted a full region migration (eu-west → us-east) via railway service scale — the scale operation itself silently fails with zero build/deploy logs whatsoever, no error message, just status: FAILED with an empty log stream. This suggests something beyond just edge routing may be stuck on this account's deployment orchestration
16 days ago
I think you have a brand new account at railway.
Adding a payment method or verifying identity in Account Settings → Billing automatically purges this flag from edge POPs.
16 days ago
Free tier plans reject multi-region scaling operations during pre-flight API authorization (causing the silent FAILED status with zero logs).
I'd recommend you to create a brand-new project and select us-east1 or us-west2 during initial creation.
scicoale550-ui
Update: Tried both suggestions from the community — no luck: Dual-stack binding (:: instead of 0.0.0.0) in app code + HOSTNAME=:: — same 502/x-railway-fallback result, this time even from a different edge (cdg1 instead of ams1), still unable to reach europe-west4-drams3a. Attempted a full region migration (eu-west → us-east) via railway service scale — the scale operation itself silently fails with zero build/deploy logs whatsoever, no error message, just status: FAILED with an empty log stream. This suggests something beyond just edge routing may be stuck on this account's deployment orchestration
16 days ago
Make sure the port your URL is mapped to is the same port your application is listening to.
Also, try deleting the service and create a new one for now.
15 days ago
Update: Deleted and recreated the api service entirely (per your suggestion) — fresh service ID, fresh domain (api-production-0767.up.railway.app), confirmed correct Dockerfile config-as-code path, build now succeeds cleanly via Docker. Public domain still returns the exact identical signature as the old service:
x-railway-fallback: true
x-railway-upstream-zone: railway/europe-west4-drams3a
This proves it's not service-specific — the account itself seems to always land in the broken europe-west4-drams3a zone regardless of which service is created. Could someone check the account-level region/edge routing assignment directly?
15 days ago
I will now buy the hobby plan and hope this is just a billing /fraud flagging problem
15 days ago
Is the port your URL is mapped to the same as the port your application is listening to?
15 days ago
Yes it is 🙏🏽
15 days ago
Update: Created an entirely new project from scratch (not just a new service) to rule out anything project-specific: feedback-ai-system-v2, fresh api service, fresh domain (api-production-49ce.up.railway.app), builds cleanly via Docker, deploy succeeds. Still returns the identical signature: x-railway-fallback: true, x-railway-upstream-zone: railway/europe-west4-drams3a. This conclusively rules out project/service-level causes — it's tied to this account specifically, always defaulting to the broken europe-west4-drams3a zone regardless of what's created. Could someone manually reassign/fix this account's default zone?
scicoale550-ui
Yes it is 🙏🏽
15 days ago
Try changing the port to an arbitrary number (eg, 4100) on your application and URL.
0x5b62656e5d
Try changing the port to an arbitrary number (eg, 4100) on your application and URL.
15 days ago
holy shit it worked on api can you explain??
15 days ago
Not sure exactly how but I’ve seen these strange edge cases a few times and changing the port number helps with port/routing issues.
Status changed to Awaiting User Response Railway • 15 days ago
Status changed to Solved 0x5b62656e5d • 15 days ago
Status changed to Awaiting Conductor Response Railway • 15 days ago
Status changed to Solved 0x5b62656e5d • 15 days ago