Re: PROXY protocol support

On 10/19/26 11:38, Peter Eisentraut wrote:
> On 20.06.26 07:46, Julien Riou wrote:
>> The first change drifting from the initial implementation is this
>> patch uses the same port for both proxy protocol aware connections and
>> for not proxy protocol aware connections. To follow the spec, if a
>> connection comes from a trusted network but doesn't provide the PROXY
>> header, the server will reject it. Having only one port to listen is
>> simpler from an operator point of view. No need to configure and
>> document more networking rules. Existing rules will work as usual.
>
> I'm not sure about this change.  I can see both sides.
>
> The original patches from Magnus had a proxy_port setting; this patch
> has a proxy_networks setting.  With the proxy_port setting, you need to
> drill a hole for another port in your network setup, sure, but with the
> proxy_networks setting you are then on a given host stuck with only
> using the proxy protocol, unless you add another IP address, which is
> probably even more complicated than allowing another port.  Also, I
> think relying on IP addresses will always cause some IPv4 vs. IPv6
> confusion.  And the way you have written it, it appears that all or no
> Unix-domain sockets are included into the proxy networks, but note that
> one can configure more than one Unix-domain socket, so one might also
> want to treat those differently.
>
> I don't know what the best solution here is.  Ideally, I would like some
> generalized facility to list socket endpoints (like listen_addresses =
> 'network:port,network:port,...'), and then you can make parallel
> settings for proxy endpoints, direct-SSL endpoints, etc.  Everything
> else will only allow you to configure one particular slice of these
> possibilities, but I don't know which particular slicing would be most
> useful.  What are some precedents that other products that support the
> proxy protocol use for their configuration?

The idea of having one listening endpoint came from MySQL because I'm
used to manage a fleet of MySQL servers in addition to PostgreSQL.

But you are right, if we take a step back and look at the global
picture, there are three categories of implementations:

1. Per listener only: HAProxy, nginx, Postfix, Varnish, MongoDB,
ClickHouse

2. Per listener plus a trusted network list: Dovecot, Squid, Apache,
Traefik, Vault, Caddy

3. Trusted network list only, all ports: MariaDB, Percona Server,
ProxySQL, TiDB, Exim. Oracle MySQL has no server-side support

Network-only configuration runs into the problems you raised. TiDB later
had to add a fallback mode so that hosts in the trusted networks can
also connect without a header. MariaDB handles all Unix sockets with a
single keyword.

Most other products turn on the proxy protocol per listener, often with
a trust list on top. That is closer to Magnus's proxy_port. Varnish and
ClickHouse are close to your generalized endpoint idea: each endpoint,
Unix sockets included, has its own properties.

I'm considering to rework the Magnus's patch to implement the per
listener plus a trusted network list which is the smallest change to the
codebase, while being widely adopted.