HAProxy HTTPS timeout with Chrome, works after curl/wget request

I’m experiencing a strange issue with HAProxy running as a Docker container. HAProxy exposes services on a public IP, which is a floating VIP managed by Keepalived between two nodes.

The problem occurs only with HTTPS. When I try to open a page in Chrome, the connection times out, even after refreshing or the browser’s automatic retries. However, if I perform an HTTPS request using curl or wget, subsequent requests from Chrome start working temporarily before the issue reoccurs.

Inspecting the traffic with tcpdump reveals that connections appear to have incorrect TCP sequence numbers after the 3-way handshake:

client->server seq=0,len=0 [SYN]server->client seq=0,len=0 [SYN,ACK]client->server seq=1,ack=1,len=0 [ACK]client->server seq=1441,ack=1,len=327 [PSH,ACK]

On the other hand, requests made with curl or wget seem to work fine:

client->server seq=0,len=0 [SYN]server->client seq=0,len=0 [SYN,ACK]client->server seq=1,ack=1,len=0 [ACK]client->server seq=1,ack=1,len=388 [PSH,ACK] (TLS client Hello)

After making a request with curl, subsequent requests from Chrome start working again, which is driving me crazy. :)

Here’s my haproxy.cfg:

global    maxconn 50000defaults    timeout client 30s    timeout server 30s    timeout connect 5sfrontend www    bind :80    bind :443 ssl crt-list /usr/local/etc/haproxy/crt-list.txt    acl invalid_host hdr(host) -m found    acl allowed_hosts hdr(host) -i creator.dev.mydomain.com www.dev.mydomain.com    http-request deny if invalid_host !allowed_hosts    redirect scheme https if !{ ssl_fc }    http-response set-header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"    default_backend swarm_clusterbackend swarm_cluster    mode http    balance roundrobin    cookie SERVERID insert indirect nocache    server worker1 192.168.24.101:443 ssl verify none check send-proxy    server worker2 192.168.24.102:443 ssl verify none check send-proxy    server worker3 192.168.24.103:443 ssl verify none check send-proxy

Does anyone have any idea what could be causing this behavior?Thansk a lot!

I tried the following steps:

Checked backend server.

Analyzed traffic with tcpdump

Tested with different tools: Requests made with curl and wget worked fine, and interestingly, they temporarily "fixed" the issue for Chrome requests.