Hello, It was fixed but it's waiting for a new release. There is a workaround. Look into this issue :
<https://github.com/haproxy/haproxy/issues/3355> Le 9 mai 2026 18:27:15 GMT+02:00, Bren <[email protected]> a écrit : >Hello, > >We upgraded to 3.3.9 yesterday and started getting reports from users that >they couldn't connect to our chat, which uses websockets. I've narrowed it >down to ws connections made over h2. haproxy reports this when the browser >attempts a ws upgrade: > >[09/May/2026:11:54:09.568] main~ main/<NOSRV> -1/-1/-1/-1/477 0 0 - - PR-- >2/2/0/0/0 0/0 "<BADREQ>" 0/0000000000000000/0/0/0 >chat.domain.com/TLSv1.3/TLS_AES_128_GCM_SHA256 serverid="-" alpn=h2 > >If I disable h2, the connection succeeds both over http1.1 and h3. > >Here is the relevant bind config: > >frontend main > bind ip:80 tfo > bind ip:443 ssl crt /etc/haproxy/certs alpn h2,http/1.1 tfo > bind quic4@ip:443 ssl crt /etc/haproxy/certs alpn h3 > >Here are the headers from the websocket requests that fail over h2: > >GET /ws undefined >Host: chat.domain.com >User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:150.0) >Gecko/20100101 Firefox/150.0 >Accept: */* >Accept-Language: en-US,en;q=0.9 >Accept-Encoding: gzip, deflate, br, zstd >Sec-WebSocket-Version: 13 >Origin: https://chat.domain.com >Sec-WebSocket-Extensions: permessage-deflate >Sec-WebSocket-Key: xxx >Connection: Upgrade >Cookie: xxx >Sec-Fetch-Dest: empty >Sec-Fetch-Mode: websocket >Sec-Fetch-Site: same-origin >Pragma: no-cache >Cache-Control: no-cache > >I've temporarily disabled h2 for now. > >Let me know if I can provide anything else. > >Bren > > -- Best regards, Artur
