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?