a month ago
"Project caico-command-center (7b7fdb48…): since ~13:00 UTC July 9, no newly-created container in any region receives health-check probes or edge routing — they boot and listen on 0.0.0.0:$PORT (verified in logs). This includes brand-new services with fresh domains. Only containers created before the incident still serve. Matches station.railway.com/questions/persistent-health-check-routing-failures-23c41579."
1 Replies
a month ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • about 1 month ago
a month ago
"Listening on 0.0.0.0:$PORT" is the bug, not proof of health. 0.0.0.0 binds
IPv4 only, and Railway's health-check probes and edge-to-container traffic
reach containers over IPv6. An IPv4-only listener never sees the probes or
the routed traffic, which is exactly your symptom: container boots fine,
logs look healthy, zero requests arrive.
It also explains "only containers created before the incident still serve" -
existing containers keep their old networking until recreated, while every
newly created container gets the IPv6 path and silently fails if the app
binds v4-only.
Fix: bind to :: (dual-stack) instead of 0.0.0.0, then redeploy.
Node: server.listen(process.env.PORT, "::")
Gunicorn: -b [::]:$PORT
Uvicorn: --host :: (note: uvicorn CLI can't do true dual-stack;
if you need v4+v6, use hypercorn or bind in code)Go: net.Listen("tcp", ":"+port) // already dual-stack
Caddy/nginx: default binds are already dual-stack
Counter-datapoint that this isn't a platform-wide routing outage: I deployed
brand-new containers on July 10 (after your incident window) that received
probes and edge routing immediately - served by Caddy, which binds dual-stack
by default. New containers route fine when the app listens on ::.