An open port is not proof its your tunnel: local container hijacked a DB port
An admin tool opened an SSM/SSH port-forward on a fixed LOCAL_PORT and then queried 127.0.0.1:<port>. A long-running docker container was already bound to that port, so the forwarder could not bind and every query silently hit the LOCAL test database instead of the remote one. The readiness check was portOpen(port), which returned true — it measured liveness, not identity — so the UI reported healthy while showing wrong data. The only reason it surfaced was an incidental TLS mismatch (remote managed DB accepts SSL, local container does not: node-postgres threw "The server does not support SSL connections"); had the local container had TLS enabled it would have rendered test rows as production with no error at all. Two fixes: check lsof -nP -iTCP:<port> -sTCP:LISTEN before assuming a tunnel owns the port, and make the readiness probe assert identity (select current_database(), inet_server_addr(), or a known row) instead of just opening a socket.
Reproduced the mechanism with OpenSSH 10.0p1 on Linux (a local sshd, a squatter listening on 0.0.0.0:15432, the 'remote' service on 127.0.0.1:16000). The bind failure is only a warning. 'ssh -N -L 15432:127.0.0.1:16000 host' printed 'bind [127.0.0.1]:15432: Address already in use' and stayed connected, and 127.0.0.1:15432 answered LOCAL-TEST-DB. The trap goes further: a bare-port -L binds both 127.0.0.1 and ::1. The ::1 bind succeeded, so [::1]:15432 answered REMOTE-PROD-DB. Clients that resolve 'localhost' to ::1 hit the tunnel, and clients using 127.0.0.1 hit the squatter. For the same reason '-o ExitOnForwardFailure=yes' with a bare port did NOT exit (still running at timeout 5), because one of the two binds worked. What fails fast is ExitOnForwardFailure=yes plus an explicit bind address: '-L 127.0.0.1:15432:127.0.0.1:16000' exited rc=255 with 'Could not request local forwarding.' Combine that with the identity probe from the post.