Project ID: 10707cfb-7cfc-418c-98a9-d5f74ff1eeda (previously also reproduced on a now-deleted project: f1fd909b-fc49-4d76-852b-cc3fa22c4e2d)

Service ID: c0b66006-2fb4-4182-aad1-3b4efcf73034

Domain: materials-dashboard-production-dea1.up.railway.app

Summary: The public service domain routes zero traffic to a healthy, confirmed-running container. This is more severe than a typical 502 — the TLS handshake doesn't even complete (SSL_ERROR_SYSCALL), and no HTTP-level response is ever returned, not even with X-Railway-Debug: 1.

Confirmed healthy / ruled out:

• Deployment status: SUCCESS, container RUNNING, 0 crashed, clean startup logs every time
• Billing: Active Hobby plan, payment method on file (confirmed on account/billing page)
• WAF / Under Attack Mode: disabled

Everything tried below had zero effect on the domain — container always stays healthy, domain always fails identically:

1. Default app binding (no explicit host)
2. Explicit bind to 0.0.0.0
3. Explicit bind to :: (IPv6)
4. Simultaneous dual listeners — one on 0.0.0.0, one on :: with ipv6Only (confirmed both bound successfully via logs)
5. HOSTNAME=0.0.0.0 env var (per a similar community thread's fix)
6. Changed app port 8080 → 3000 (custom PORT env var) with domain's targetPort updated to match
7. Reverted back to port 8080, domain targetPort re-synced
8. Domain deleted and recreated multiple times
9. Entire project deleted and recreated from scratch (2 separate fresh projects total — identical failure both times)
10. Deployment region changed: us-west2 → us-east4 → back — identical failure in both regions
11. Multiple full redeploys / restarts

Diagnostic evidence:

• railway logs --network, streamed live during an active request to the domain, shows zero TCP packets reaching the container — only background mDNS/LLMNR multicast noise from container startup
• curl -H "X-Railway-Debug: 1" against the domain returns no response at all, not even Railway's own debug/fallback headers
• A TCP proxy on the same app port (8080) initially worked — returned a clean HTTP 200 with correct application content, proving the container was fully healthy and network-reachable, isolating the issue to HTTP(S) service-domain edge routing specifically
• That TCP proxy access has since stopped working too, while the container remains confirmed healthy (SUCCESS, running: 1, crashed: 0) — suggesting the underlying networking issue is not static and isn't isolated to just the domain/HTTP routing layer anymore

Ask: This looks like an infrastructure-level issue tied to this account/workspace, not something fixable via redeploys, domain resets, project recreation, region changes, or app-level config. Could someone from the infrastructure team investigate directly? Happy to provide additional deployment IDs, timestamps, or logs.