a month ago
Service: motigo
Project ID: 1ec6e849-bc17-414b-a99a-2305d56ddbb8
Deployment ID: adf2b01b-d35e-492e-9c75-af56bbb8ee1d
Request IDs: cHJFI5FhTHesAVkNnpoFkQ, HOQT0ETZSPyAoa-79fVATg
Key point: Healthcheck passes internally, but edge returns 502 with x-railway-fallback header
Service motigo-production (project 1ec6e849-bc17-414b-a99a-2305d56ddbb8) shows deployment status Active, all phases (Init/Build/Deploy/Healthcheck/Post-deploy) passed, healthcheck confirmed reaching the app internally. Networking target port (8080) matches the app's actual listening port, confirmed via startup logs. Domain was regenerated (same hostname) with no change. Every public request to motigo-production.up.railway.app still returns x-railway-fallback: true / "Application failed to respond" instantly. Request IDs for reference: cHJFI5FhTHesAVkNnpoFkQ, HOQT0ETZSPyAoa-79fVATg.
3 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
Make sure the port your application is listening to is the same port your URL is mapped to.
a month ago
Q: Our FastAPI service binds to [::]:8080 (IPv6) via uvicorn --host :: --port $PORT. Railway's own healthchecker successfully probes /health on that same IPv6 address ([fd12:...]:8080), confirming the app is reachable internally and port binding is correct. Yet every public request to our domain returns 502 with x-railway-fallback: true header — the error happens instantly, before the app even receives the request.
We've ruled out:
Port mismatch (healthcheck proves Railway can reach port 8080)
Binding address (switched :: ↔ 0.0.0.0; :: passes healthcheck, 0.0.0.0 fails it)
Domain/DNS (regenerated, no change)
Deployment state (all phases pass, Active status)
Application logic (healthcheck succeeds, early startup probe succeeds)
The question: Is there a routing or proxy configuration issue between Railway's edge and this container that prevents public traffic from reaching an IPv6-bound service, even though Railway's own internal healthcheck can reach it? Or is there a known limitation with IPv6-bound services on Railway?
a month ago
New evidence for Railway support:
We tested a raw TCP proxy (bypassing HTTP routing entirely) on the same port/service. Same result: "Application failed to respond" / x-railway-fallback: true.
This proves the issue is not HTTP-specific — it's the entire connection path from Railway's edge to the container. Since:
Healthcheck reaches the container successfully (IPv6 internal probe passes)
TCP proxy fails identically to HTTP domain
App binds and startup succeeds
...the problem must be in Railway's edge→container routing layer itself. Request ID from TCP proxy test: vEZZpYK5S8yYMG8Iw9P4nw