a month ago
Has anyone encountered this issue?
Railway services connect to PostgreSQL normally through private networking
railway connect and the dashboard database console hang
railway connect --ssh works immediately
- The TCP proxy is active and accepts connections, but PostgreSQL readiness checks receive no response
- Restarting the deployment did not help
- A newly created PostgreSQL service had the same problem
The database appears healthy, while the public TCP proxy path is broken. Is this a known issue or is there a safe networking-side fix?
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
This points at the public TCP proxy path, not your database SSH in and private networking both working while even a fresh PG service fails the public proxy is the tell. Things to check/try, safest first:
Just use private networking. If it's your app that needs the DB, connect over postgres.railway.internal (private net already works, and it's what you should use in prod anyway). The public proxy is only needed for external tools bypass it and the issue is moot.
Verify the TCP proxy target port = Postgres's actual listen port. Service → Settings → Networking → TCP Proxy: the application/target port must equal PGPORT (5432). A proxy pointed at the wrong port accepts your TCP connection but forwards to nothing → exactly this hang.
Regenerate the TCP proxy remove the TCP proxy and re-add it. This rebuilds a possibly stale proxy mapping.
Confirm listen_addresses = (via railway ssh → psql → SHOW listen_addresses;). Railway's private net is IPv6; if PG only listened on IPv4 loopback the proxy couldn't reach it. (Unlikely here since a fresh image should be *, but worth ruling out.)
Try a different region / redeploy the DB in another region. If it's a regional proxy incident, this restores the public path immediately.
Check status.railway.app and report it a fresh service failing identically means it's platform-side, not you.
Most likely root cause given your clues: a TCP proxy/region-level issue on Railway's side, with #1 (switch to private networking) as the real fix and #3/#5 as the recovery levers.