PROXY protocol sets TCP4/TCP6 protocol based on actual connection, not --haproxy-clientip

[airtower-luna]

I did this

I used the HAProxy protocol over IPv6, reporting an IPv4 client IP:

curl --ipv6 --haproxy-protocol --haproxy-clientip 192.0.2.42 -v --insecure --connect-to ::localhost:8080 https://example.com/

Resulting proxy protocol header:

PROXY TCP6 192.0.2.42 ::1 50882 8080

Same the other way around, reporting an IPv6 client IP over IPv4:

curl --ipv4 --haproxy-protocol --haproxy-clientip 2001:db8::42 -v --insecure --connect-to ::localhost:8080 https://example.com/

Resulting proxy protocol header:

PROXY TCP4 2001:db8::42 127.0.0.1 44410 8080

I expected the following

The transport protocol reported in the PROXY header must match the client IP (TCP6 if it is IPv6, TCP4 if IPv4). Both HAProxy and Traefik (correctly) reject the connection if there's a mismatch. If I force the transport protocol to match the reported client IP it works (e.g. --ipv6 --haproxy-protocol --haproxy-clientip 2001:db8::42), but the whole point of using the PROXY protocol is to report the actual client IP regardless of proxy transport.

curl/libcurl version

curl 8.20.0-rc2 (x86_64-pc-linux-gnu) libcurl/8.20.0-rc2 OpenSSL/3.6.2 zlib/1.3.2 brotli/1.2.0 zstd/1.5.7 libidn2/2.3.8 libpsl/0.21.5 libssh2/1.11.1 nghttp2/1.68.1 ngtcp2/1.21.0 nghttp3/1.15.0 mit-krb5/1.22.1 OpenLDAP/2.6.10
Release-Date: 2026-04-13, security patched: 8.20.0~rc2-1
Protocols: dict file ftp ftps gopher gophers http https imap imaps ipfs ipns ldap ldaps mqtt mqtts pop3 pop3s rtsp scp sftp smtp smtps telnet tftp ws wss
Features: alt-svc AsynchDNS brotli GSS-API HSTS HTTP2 HTTP3 HTTPS-proxy IDN IPv6 Kerberos Largefile libz PSL SPNEGO SSL threadsafe TLS-SRP UnixSockets zstd

operating system

Linux haruka 6.19.11+deb14-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.19.11-1 (2026-04-05) x86_64 GNU/Linux (AKA Debian Sid)

[icing]

From the documentation CURLOPT_HAPROXY_CLIENT_IP(3):

"As with most libcurl options, the user of this option must make sure that the correct data (address) is passed on. libcurl does little to no verification."

Explainer: curl can be (and is) used to test endpoints with data that does not have to "make sense". This is on purpose.

[airtower-luna]

Curl offers no way to override the TCP4/TCP6 value (which must match the client IP, not the actual transport), only the client IP. This is a curl bug.

[icing]

Ok, I see your point and agree that this is a bug.

[icing]

I propose #21341 as fix. Can you verify? Thanks!

[airtower-luna]

Fix looks correct, I'll test with my setup after lunch and report back.

[airtower-luna]

The patch works as expected, thank you!

Unfortunately I missed an important detail in my analysis: the destination address family must match the client address family. Which makes sense, curl is effectively pretending to be a proxy here that reports to a backend server "I received this connection from [clientip] at my own address [destination IP]", so both can only be of the same address family. But the destination address is currently unconditionally set to the address curl connects to, which causes a new problem: If I set an IPv4 client address and the connection uses IPv6, the destination address is set to an IPv6 address (or vice versa), which is invalid. But doing the reporting over the respective other address family should be fine (and is, looking at the proxies I've tested with).

I don't see a good way to fix this short of adding another command line option (e.g. --haproxy-destination) to override the destination IP, too (picking a random local address of the same family as the clientip should work but seems rather messy). If you don't have time for that I could try to add it on top of your PR, but I can't promise when I might get to it.

Sorry about the confusion!

[airtower-luna]

As practical example, curl sending the following over IPv6 would be correct:

PROXY TCP4 192.0.2.42 192.0.2.43 50882 8080

And so would be be sending this over IPv4:

PROXY TCP6 2001:db8::42 2001:db8::43 44410 8080

But as of now there's no way to override the destination (second) address.

[icing]

Maybe curl should just use 127.0.0.1 or ::1 as the reported destination address all the time.

[airtower-luna]

Right, picking one of those depending on the family of the clientip would be a quick and simple fix. If someone needs a specific value they could still add another command line option. 🙂

[icing]

Or just report the source ip as the destination ip when a value is set.