The query stalled halfway through, and the cursor blinked on an empty terminal. The command had been simple: use pgcli to connect through a Postgres binary protocol proxy. But the connection was silent. No handshake. No prompt. Just a frozen shell.
Debugging this kind of problem means understanding exactly what happens between pgcli and PostgreSQL. Unlike tools that use simple text-based commands, pgcli speaks over the Postgres wire protocol. This binary protocol is more strict, more efficient, and far less forgiving to intermediaries that don’t fully implement it.
A Postgres binary protocol proxy sits between the client and the server. It listens for packets, understands message types, preserves sequencing, and forwards responses without breaking framing rules. If it mishandles even a single byte, the client will fail. This is why many generic TCP or HTTP proxies can’t simply “work” for this purpose.
When connecting pgcli through such a proxy, the stack looks like this: pgcli → Proxy → PostgreSQL. The correctness of protocol support at this middle layer determines everything. TLS negotiation, authentication messages (StartupMessage, AuthenticationOk, ErrorResponse), prepared statement flows, and COPY streaming all have to pass without modification errors.