haproxy BADREQ错误

如果浏览器没有使用所有连接，则来自浏览器的BADREQ也可能导致BADREQ 。 例如，当用户每个浏览器只下载一个文件时。

这意味着BADREQ有两个可能的原因： cR--或CR-- （用HAProxy v1.5-dev24validation）：

1. 未使用的连接：这意味着HTTP（S）客户端连接到每个TCP，但没有HTTP请求头被发送，直到timeout http-request （ CR-- ）或客户端再次closures连接（ cR-- ）。 原因：来自正常客户端或负载均衡器的预连接或扫描的未使用连接。
2. 错误的请求。 一位客户正在发送一个错误的请求。 这些错误应该是可见的每个统计套接字（请参阅womble以前的答案）。

大多数现代浏览器（如Firefox或Chrome）正在进行预连接 。 我发现即使浏览器只下载一个文件（例如只下载http://cdn.sstatic.net/serverfault/img/favicon.ico或Chrome也始终打开至less2个连接。

增加HAProxyconfiguration中超timeout http-request的值可以帮助减less未使用连接的日志条目，这是因为值越高意味着连接将从客户端使用的可能性越高，但是您也有可能冒着服务器不能处理所有打开（空闲）连接了。 如果在HAProxy之前使用另一个负载平衡器（如Amazon ELB），请检查HAProxy中的超时是否与负载平衡器匹配，因为它们也可以使用预连接。

对于未使用的连接，可以使用HAProxy中的option dontlognull来禁用此日志条目。 从HAProxy Docu引用此选项：

通常build议不要在不受控制的环境中使用此选项（例如：internet），否则将不会logging扫描和其他恶意活动。

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

解决scheme：改变“超时http-request”到20s而不是你的5s。

在这个问题上浪费了一天的时间。 我们发现一些请求（在我们的案例中大约8％的stream量）太大。 8k是HAProxy中默认的最大尺寸（所有头文件合并），我们公司喜欢cookies。 请求在第8092个字节后被截断。

从文档：

如果HTTP请求大于（tune.bufsize – tune.maxrewrite），haproxy将返回HTTP 400（错误请求）错误。 同样，如果HTTP响应大于此大小，haproxy将返回HTTP 502（错误网关）。

我们用以下值更新了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 。 有可能是有人试图在其他networking服务器上运行漏洞利用，所以你可以忽略它。