Routing HTTPS traffic via the ssl_sni tcp packet header is a way to balance and create virtual hosts pointing directly to their tcp port, so it allows to leave SSL offloading work to the backend, and more useful stuff.

As a result, no http header logic can be used, as it operates at TCP level.

global
    ssl-default-bind-ciphers TLS13-AES-256-GCM-SHA384:TLS13-AES-128-GCM-SHA256:TLS13-CHACHA20-POLY1305-SHA256:EECDH+AESGCM:EECDH+CHACHA20
    ssl-default-bind-options no-sslv3 no-tlsv10 no-tlsv11
    tune.ssl.default-dh-param 2048
 
defaults
    log /dev/log local0 info
    timeout connect 5000
    timeout client  50000
    timeout server  50000
    option tcplog
    option logasap
    mode tcp
 
frontend ssl-sni-router
    bind :::443 v4v6 strict-sni alpn h2,http/1.1
 
    tcp-request inspect-delay 5s
 
    # log the ssl sni on the haproxy
    tcp-request content capture req.ssl_sni len 24
    log-format "%ci:%cp [%t] %f %b -- SNI %[capture.req.hdr(0)]"
 
    tcp-request content accept if { req.ssl_hello_type 1 }
 
 
    acl a_somesite req.ssl_sni -i somesite.net
    use_backend somesite if a_somesite
 
    default_backend adefaultproxy
 
 
backend adefaultproxy
    server def1 127.0.0.1:1443
 
 
backend somesite
    server some1 127.0.0.1:1447

Check out https://coolaj86.com/articles/adventures-in-haproxy-tcp-tls-https-ssh-openvpn/ for additional info maybe?