haproxy BADREQ erros

Question

Estou vendo erros semelhantes aos seguintes nos meus logs haproxy:

Jul 18 17:05:30 localhost haproxy[8247]: 188.223.50.7:51940 [18/Jul/2011:17:05:24.339] http_proxy_ads http_proxy_ads/<NOSRV> -1/-1/-1/-1/6001 408 212 - - cR-- 100/89/0/0/0 0/0 "<BADREQ>" 
Jul 18 17:05:30 localhost haproxy[8247]: 188.223.50.7:51943 [18/Jul/2011:17:05:24.341] http_proxy_ads http_proxy_ads/<NOSRV> -1/-1/-1/-1/6000 408 212 - - cR-- 99/88/0/0/0 0/0 "<BADREQ>" 

etc ...

Até agora, tentei aumentar o tempo limite do cliente (para 6 segundos de 3) e aumentar o buffer de solicitação de http de 16k para 32k. Os erros ainda aparecem.

Alguém pode me dar orientação sobre o que procurar aqui?

    

Answer 1

A Pré-conectar-se a partir de um navegador pode levar a BADREQ também se o navegador não estiver usando todas as conexões. Por exemplo, quando um usuário está baixando apenas um arquivo por navegador.

Isso significa que há duas causas possíveis para BADREQ com cR-- ou CR-- (verificado com o HAProxy v1.5-dev24):

1. Conexão não usada: Isso significa para o HTTP (S) um cliente conectado por TCP, mas nenhum cabeçalho de solicitação HTTP foi enviado até timeout http-request ( CR-- ) ou o cliente estava fechando a conexão novamente ( cR-- ). Causa: Conexão não utilizada de uma pré-conexão de um cliente normal ou balanceador de carga ou de uma varredura.
2. Solicitação incorreta. Um cliente estava enviando uma solicitação incorreta. Esses erros devem estar visíveis por soquete de estatísticas (veja a resposta anterior de womble).

A maioria dos navegadores modernos, como o Firefox ou o Chrome, faz um pré-conectar . Eu estava vendo que o Firefox ou o Chrome estavam abrindo sempre pelo menos duas conexões, mesmo que o navegador estivesse fazendo apenas uma solicitação, como baixar um arquivo (por exemplo, apenas baixando http://cdn.sstatic.net/serverfault/img/favicon.ico )

Aumentar o valor de timeout http-request em sua configuração HAProxy pode ajudar a reduzir essas entradas de log para conexões não utilizadas, porque um valor mais alto significa uma chance maior de que a conexão seja usada de um cliente, mas você também está arriscando O servidor não suporta mais todas as conexões abertas (ociosas). Se você estiver usando outro balanceador de carga como o Amazon ELB na frente do HAProxy, verifique se esse tempo limite no HAProxy está correspondendo ao balanceador de carga, porque eles também podem usar o pré-conector.

Para conexões não usadas, você pode usar option dontlognull em HAProxy para desabilitar essas entradas de log. Citação de Documento HAProxy para esta opção:

It is generally recommended not to use this option in uncontrolled environments (eg: internet), otherwise scans and other malicious activities would not be logged.

    

Answer 2

=> The client never completed its request, which was aborted by the
   time-out ("c---") after 5s, while the proxy was waiting for the request
   headers ("-R--").  Nothing was sent to any server, but the proxy could
   send a 408 return code to the client.

Solução: altere "timeout http-request" para 20s ou mais em vez dos 5s.

    

Answer 3

Apenas desperdiçou um dia com essa questão. Descobrimos que alguns pedidos (cerca de 8% do tráfego no nosso caso) eram muito grandes. 8k é o tamanho máximo padrão em HAProxy (todos os cabeçalhos combinados) e nossa empresa adora cookies. As solicitações foram truncadas após o byte 8092th.

Nos documentos:

If HTTP request is larger than (tune.bufsize - tune.maxrewrite), haproxy will return HTTP 400 (Bad Request) error. Similarly if an HTTP response is larger than this size, haproxy will return HTTP 502 (Bad Gateway).

Atualizamos o arquivo haproxy.cfg com os seguintes valores:

global
  # request limit is (bufsize - maxrewrite), our desired limit is 16k (8k is default)
  tune.maxrewrite  16384
  tune.bufsize     32768

Espero que ajude!

    

Answer 4

BADREQ significa apenas que o cliente enviou um pedido incorreto; no modo HTTP, isso pode significar que o cliente está cheio, e não há nada que você possa fazer sobre isso. Para ver qual foi o erro exato, conecte-se ao soquete de estatísticas (usando socat) e execute show errors . É provável que alguém esteja tentando executar um exploit em outro servidor da Web, para que você possa ignorá-lo.