5 days ago
Web service in the laudable-kindness project is returning 502 on all external HTTP requests, even though the container is demonstrably healthy and listening on the correct port.
Technical Details:
Service ID: 1e0faab4-ccd3-4883-af05-266d4694a8d4
Deployment ID: 3cd5f4e0-2d50-44dc-a854-665adf1665d1
Commit: 4cff3f2f3445becf1124e0496291ed1fd7dd668c
Domain: vmfweb-production.up.railway.app → Port 8080
Region: us-east4-eqdc4a
Evidence:
Deploy logs confirm: ✓ Ready in 183ms + Network: http://...:8080
Container listening on 8080 (port correctly configured)
CPU: 0.0024 (minimal), Memory: ~93MB (healthy)
HTTP error: connection refused with header x-railway-fallback: true (edge jfk1)
API service in the same project/region works normally (returns 200 OK)
Steps Already Tested:
✅ Removed hardcoded PORT from Dockerfile
✅ Domain deleted and recreated from scratch
✅ PORT=8080 environment variable added and tested
✅ Replicas within plan limits
Conclusion: Issue is in the edge/proxy routing layer, not the application. Requires infrastructure investigation.
5 Replies
5 days ago
Apologies for the trouble. We had an incident affecting the US East edge network and traffic routing, which has since been resolved. Since your service is in us-east4, the 502s and "connection refused" errors were caused by this. Please try your requests again, and let us know if the issue persists. You can see the full timeline here: incident details
Status changed to Awaiting User Response Railway • 5 days ago
Railway
Apologies for the trouble. We had an incident affecting the US East edge network and traffic routing, which has since been resolved. Since your service is in us-east4, the 502s and "connection refused" errors were caused by this. Please try your requests again, and let us know if the issue persists. You can see the full timeline here: [incident details](https://status.railway.com/incident/TAW34N30)
5 days ago
Thanks for the update. Unfortunately, I'm still getting a 502 error on the web service even after a manual redeploy, with the same signature as before:
x-railway-fallback: true
x-railway-edge: mia1
{"status":"error","code":502,"message":"Application failed to respond"}
The API service in the same project is still working normally. Could you confirm if this specific service (web, active deployment, service ID I provided earlier) is still affected by any lingering effects of the incident, or if this is a separate issue?
Status changed to Awaiting Railway Response Railway • 5 days ago
5 days ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • 5 days ago
5 days ago
Is your target port set to 8080? If it is, try to change your app's port to something like 3000 and map that to the target port in your service settings. Set the PORT variable in your service settings to the same port as well.
darseen
Is your [target port](https://docs.railway.com/networking/troubleshooting/application-failed-to-respond#target-port-set-to-the-incorrect-value) set to `8080`? If it is, try to change your app's port to something like `3000` and map that to the target port in your service settings. Set the PORT variable in your service settings to the same port as well.
5 days ago
I ran a more definitive test: I deleted the entire web service and recreated it from scratch (new Service ID, new domain vmf-church-stream-production.up.railway.app, new auto-generated port 8080). The app logs confirm it started up successfully ("Ready in 250ms," listening on 8080, matching the domain port)—yet I still get a 502 error immediately on the first request, with the usual signature (x-railway-fallback: true).
This rules out configuration or state issues specific to that service, since it’s a brand-new service. The API in the same project continues to work normally. This seems to be an issue at the project, account, or region level, rather than with the individual service. Could you escalate this to the engineering team?
5 days ago
I ran a more definitive test: I deleted the entire web service and recreated it from scratch (new Service ID, new domain vmf-church-stream-production.up.railway.app, new auto-generated port 8080). The app logs confirm it started up successfully ("Ready in 250ms," listening on 8080, matching the domain port)—yet I still get a 502 error immediately on the first request, with the usual signature (x-railway-fallback: true).
This rules out configuration or state issues specific to that service, since it’s a brand-new service. The API in the same project continues to work normally. This seems to be an issue at the project, account, or region level, rather than with the individual service. Could you escalate this to the engineering team?