the fact that it accepts the connection then goes silent is the tell, the proxy accepts at the edge first and only then forwards, so if it's forwarding to a port nothing is listening on you get exactly this instead of a refused connection.

check whether you have a PORT variable set on that service. if PORT is set, the tcp proxy points at whatever PORT says and ignores the target port you picked when creating the proxy, so both of your new proxy ports would inherit the same wrong target, which fits what you're seeing. make sure it matches the port your database actually listens on (5432 for postgres), or remove it and set the proxy target explicitly.

reference: https://docs.railway.com/networking/tcp-proxy

Thanks — that's a useful model, and it explains why re-creating the proxy changed nothing for me.

Checked it though, and the misconfiguration doesn't seem to be present in my case: there's no PORT variable set on the service, and RAILWAY_TCP_APPLICATION_PORT already matches the port Postgres actually listens on (5432). So the proxy target looks correct.

One observation that I don't think a dead forwarding target accounts for: the Postgres logs show repeated "could not accept SSL connection: unexpected eof while reading", timed to my connection attempts. If the proxy were forwarding somewhere nothing was listening, the database wouldn't log those at all — so traffic does appear to be reaching Postgres, and the replies aren't making it back.

Symptom shape, in case it's familiar to anyone: TCP connect completes in under a second, an 8-byte SSLRequest gets no response in 20s, and it reproduces identically across two separately-issued proxy ports. Not MTU (8 bytes out, 1 byte expected back), not TLS (HTTPS to Railway works from the same machine), not the local network (same result on a different connection), and not the database (a service running inside Railway reports it healthy).

Have you seen a proxy accept and forward but drop the return path?

good catch, those postgres logs rule out the target port, if it's logging failed ssl handshakes timed to your attempts then traffic is arriving and the return path is what's broken.

that shape has come up before with railway's newer envoy-based edge proxy: tcp connects fine, then hangs until timeout, suspected to be envoy mishandling non-http bytes rather than passing them through raw. the 8-byte SSLRequest getting no reply fits that, and it would reproduce across freshly-issued proxy ports since the problem is at the edge layer, not the port. same discussion here: https://help.railway.com/questions/don-t-auto-enable-the-new-proxy-it-s-ba-0effe692

worth asking staff whether the new edge proxy is enabled on your service and if it can be turned off for it, that's not something you can toggle yourself.