On Sun, 09 Nov 2025 11:30:16 +0100,
Christoph Liebender <christoph@liebender.dev> wrote:
> 
> No, there is no apparent reason - I had implemented v1 in op@'s gmid(8)
> (in ports) a while back [1] and still had in mind that v1 is relatively
> straight forward - therefore I initially didn't think about v2 at all.
> 
> Also, nginx stream proxy module only speaks version 1. That of course
> doesn't mean relayd needs to be limited to v1... Though v2 probably
> needs more effort and is less trivial to debug.
> 
> With v1, one can just nc(1) on a port that relayd forwards to, connect
> to the listen port of relayd and see the proxy line in plaintext.
> 
> In my opition, the question about supporting v2 is about:
> 
> - does v2 offer any functionality that v1 doesn't while possibly being
> useful for relayd?
> - is there any server implementation that relayd would forward to that
> only supports v2, not v1?
> - is the added code complexity of v2 worth the "performance benefits"
> that are stated in the v2 spec?
> 
> If this patch gets ok'd and in the future, v2 is supposed to be
> supported as well, it probably makes sense to alter the configuration
> syntax to something like:
> 
> proxy-protocol v1
> 
> to at some point add an option to place a "v2" there.
>

Well, v2 isn't more complicated: read / write fixed header with a bit which
specific a kind of connection and length the payload.

What's all.

If I not mistaken the haproxy docs contains a union with example.

-- 
wbr, Kirill