11 days ago
Database: Postgres service in the "Syncrea" project, production environment
Proxy address: acela.proxy.rlwy.net:41981
Symptom: Any real Postgres protocol connection (tested via psql, pg_dump, and Python's psycopg, both with sslmode=require and sslmode=disable) times out after several seconds. However, Test-NetConnection confirms raw TCP connects instantly (TcpTestSucceeded: True).
Already ruled out:
No VPN
Tested from a completely different network (mobile hotspot) — same timeout
Windows Firewall has no outbound block rules
Windows Defender Network Protection is disabled
Tested from both native Windows and inside a Docker container — same result both ways
Railway's own browser-based Data/query tool connects and works fine against this same database
Question: Is there something on Railway's side (proxy health for this specific service, IP-based restriction, rate limiting) that would explain TCP succeeding while the actual Postgres wire protocol connection hangs?
1 Replies
11 days 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 • 11 days ago
11 days ago
I can reproduce the failure without credentials.
Raw TCP to acela.proxy.rlwy.net:41981 succeeds, but a minimal PostgreSQL SSLRequest packet receives no response. A healthy Postgres server/proxy should immediately return one byte, S or N, before authentication. A non-SSL StartupMessage also receives no response.
That means this is not a client password/auth/sslmode issue. It points to the Railway TCP proxy accepting the socket but not successfully forwarding the Postgres protocol stream to the backing Postgres service, or to a stale/wrong TCP proxy mapping/internal application port.
Railway docs say external Postgres access goes through TCP Proxy, and TCP Proxy forwards all traffic from generated domain:port to the service’s configured internal port. Since Railway’s browser Data tool works, the database itself is likely healthy and the issue is specifically the public TCP proxy path.
Recommended Railway-side checks:
- Verify the TCP proxy internal/application port is the Postgres listener port, normally 5432.
- Remove/recreate the TCP Proxy or regenerate the public proxy endpoint.
- Restart the Postgres deployment after proxy recreation.
- Ask Railway support to check backend mapping/health for acela.proxy.rlwy.net:41981 and whether that proxy is attached to the current production Postgres deployment.
- Compare a connection from another Railway service using the private PGHOST/PGPORT versus the public proxy. If private works and public hangs, the proxy path is isolated.