External HTTPS requests never reach container after successful TLS handshake
marcuslaysontrenova
PROOP

a day ago

Description

Our production service is experiencing an issue where Railway successfully terminates TLS but external HTTPS requests never reach the application.

Environment

Project: gallant-spirit

Environment: production

Service: discerning-reflection

Deployment: c1db8dd5-5614-475a-b49d-b4e451a23403

Region: iad

Custom Domain: trenovatech.ai

Railway Domain: discerning-reflection-production-c690.up.railway.app

What we have verified

Domain ownership verification completed successfully.

Railway DNS verification completed successfully.

Let's Encrypt certificate has been issued for trenovatech.ai.

DNS records match Railway's required configuration.

FastAPI application is running and listening on port 8080.

Railway internal health checks receive HTTP 200 responses from /healthz.

Deployment completed successfully without build errors.

Observed behavior

External requests to both:

https://trenovatech.ai/healthz

https://discerning-reflection-production-c690.up.railway.app/healthz

complete TCP and TLS negotiation successfully but then hang until the client times out with no HTTP response.

Our Railway logs show internal requests (100.64.x.x) successfully reaching /healthz with HTTP 200, but our externally generated probe requests never appear in the application logs.

This indicates external traffic is not being forwarded to the running container.

Please investigate

Verify edge-to-container request forwarding.

Confirm the deployment is correctly registered in the routing layer.

Verify both domains point to the active deployment.

Check ingress/load balancer configuration.

Confirm external requests are reaching the edge and determine where they stop.

Verify there are no stale routing or edge cache entries.

Investigate any known issues affecting ingress or routing in the IAD region.

Business Impact

This issue blocks all external production traffic and prevents completion of our Version 1.0 production acceptance and release certification. The application is healthy internally but is inaccessible to external users, making production deployment impossible until routing is restored.

Service Selection

From your dropdown, choose:

✅ gallant-spirit / discerning-reflection / production

Do not select:

Postgres

UAT

N/A

That is the correct production service for this incident.

$20 Bounty

1 Replies

Railway
BOT

a day ago

This thread has been opened as a public bounty so the community can help solve it. The thread and any further activity are now visible to everyone.

Status changed to Open Railway 1 day ago


make sure your app bind the address to 0.0.0.0 and not localhost or 127.0.0.1


Welcome!

Sign in to your Railway account to join the conversation.

Loading...