ошибки haproxy BADREQ

Предварительное подключение из браузера может привести к BADREQ тоже, если браузер не использует все соединения. Например, когда пользователь загружает только один файл на браузер.

Это означает, что есть две возможные причины BADREQ с участием cR-- или CR-- (проверено с HAProxy v1.5-dev24):

1. Неиспользуемое соединение: это означает, что для HTTP (S) клиент подключился по TCP, но заголовок HTTP-запроса не был отправлен до тех пор, пока с timeout http-request (CR--) или клиент снова закрывал соединение (cR--). Причина: неиспользуемое соединение от предварительного соединения нормального клиента или балансировщика нагрузки или от сканирования.
2. Плохой запрос. Клиент отправил неверный запрос. Эти ошибки должны быть видны для каждого сокета статистики (см. Предыдущий ответ от womble).

Большинство современных браузеров, таких как Firefox или Chrome, делают предварительное подключение. Я видел, что Firefox или Chrome всегда открывали как минимум 2 соединения, даже если браузер выполняет только один запрос, например, загрузку файла (например, только загрузка http://cdn.sstatic.net/serverfault/img/favicon.ico)

Повышение стоимости timeout http-request в вашей конфигурации HAProxy может помочь уменьшить количество таких записей журнала для неиспользуемых соединений только потому, что более высокое значение означает более высокую вероятность того, что соединение будет использоваться от клиента, но вы также рискуете, что ваш сервер больше не сможет обрабатывать все открытые (неактивные) соединения . Если вы используете другой балансировщик нагрузки, например Amazon ELB, перед HAProxy, убедитесь, что этот тайм-аут в HAProxy совпадает с балансировщиком нагрузки, потому что они также могут использовать предварительное подключение.

Для неиспользуемых соединений вы можете использовать option dontlognull в HAProxy, чтобы отключить записи журнала. Цитата из HAProxy Docu для этого варианта:

Обычно рекомендуется не использовать эту опцию в неконтролируемых средах (например, в Интернете), иначе сканирование и другие вредоносные действия не будут регистрироваться.

=> 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.

Решение: измените "http-запрос тайм-аута" на 20 или больше вместо 5.

Просто потратил день на эту проблему. Мы обнаружили, что некоторые заголовки запросов были слишком большими. 8k - это максимальный размер по умолчанию в HAProxy (все заголовки вместе взятые), и наша компания любит файлы cookie. В нашем случае около 8% заголовков запросов были слишком большими и поэтому усеченный после 8092-го байта.

Из документов:

Если HTTP-запрос больше (tune.bufsize - tune.maxrewrite), haproxy вернет ошибку HTTP 400 (неверный запрос). Точно так же, если ответ HTTP больше этого размера, haproxy вернет HTTP 502 (Bad Gateway).

Мы обновили haproxy.cfg файл со следующими значениями:

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

Надеюсь, поможет!

BADREQ просто означает, что клиент отправил неверный запрос; в режиме HTTP это может означать, что клиент забит, и с этим ничего не поделать. Чтобы узнать, в чем именно заключалась ошибка, подключитесь к сокету статистики (используя socat) и запустите show errors. Скорее всего, кто-то пытается запустить эксплойт на каком-то другом веб-сервере, поэтому вы можете игнорировать его.