O que você vê nesse log é uma mensagem de TLS Client Hello.
Essa é a mensagem inicial enviada pelo cliente para iniciar a negociação, conseqüentemente, não há nada criptografado nessa mensagem. Você notará que há dois campos nessa mensagem que contém texto. Esses são os próximos campos do protocolo SNI (indicação do nome do servidor) e ALPN (negociação do protocolo da camada de aplicação). O resto da mensagem é de dados binários e, portanto, não é tão fácil de ler.
Naquele estágio inicial do TLS, o protocolo da camada de aplicação ainda não foi negociado e as chaves de sessão não foram estabelecidas. O cliente nem recebeu um certificado que possa validar. Isso significa que não há como o cliente ter enviado qualquer solicitação HTTP ainda e, sem solicitação HTTP, não há nada para enviar um código de status em resposta.
A entrada de log certamente parece que o HAProxy acha que está respondendo a uma solicitação HTTP, mesmo que nenhuma tenha sido enviada.
A partir disso, parece que o que está acontecendo aqui é que o servidor está falando HTTP e o cliente está falando HTTPS. A mensagem TLS Client Hello está, portanto, sendo mal interpretada como uma solicitação HTTP e rejeitada como inválida.
Seria útil capturar o tráfego de modo que ele possa ser inspecionado para descobrir o que realmente está sendo enviado pela rede. Se estou certo sobre o que precede, você deve ver um cliente TLS Hello que pode ser decodificado usando o Wireshark (ou similar) e uma resposta HTTP não criptografada com o código de erro 400.
O que também será interessante sobre a captura de pacotes será o número da porta.
Uma maneira de ver o que aconteceu foi se um usuário inseriu uma URL com protocolo e número de porta, como https://example.com:80/ , e o Facebook está tentando recuperar essa URL repetidamente (pois ela continua falhando).
Eu mesmo tentei colocar um URL malformado no facebook e, com certeza, o facebook enviou uma mensagem do Client Hello para a porta 80. Meu servidor da web (Apache) respondeu com um código de status 400 como esperado.
Sua captura de pacotes confirma que o tráfego no seu caso também está acontecendo na porta 80. Então, presumivelmente, alguém deu ao facebook um URL https apontando para o seu site e substituindo o número de porta correto por 80.
Seu servidor está respondendo corretamente com um código 400 e o Facebook percebe que a busca do URL falhou. Não há nada para consertar. Seu servidor está funcionando conforme o esperado e o único problema foi um erro do usuário ao inserir o URL no facebook.
É possível descobrir um pouco mais sobre a URL defeituosa fazendo com que o seu servidor detecte automaticamente o protocolo para suportar HTTP e HTTPS na mesma porta. No entanto, eu não recomendaria esses hacks, e não sei se algum software de servidor da web oferece suporte a ele.