haproxy BADREQ 错误

Question

我在 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>" 

等等...

到目前为止，我已经尝试增加客户端超时（从 3 到 6 秒），并将 http 请求缓冲区从 16k 增加到 32k。错误仍然出现。

任何人都可以指导我在这里寻找什么吗？

Answer 1

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

这意味着BADREQwith cR--or有两个可能的原因CR--（使用 HAProxy v1.5-dev24 验证）：

1. 未使用的连接：这意味着对于 HTTP(S)，客户端通过 TCP 连接，但直到从timeout http-request( CR--) 或客户端再次关闭连接 ( cR--)之前，才会发送 HTTP 请求标头。原因：来自普通客户端或负载均衡器的预连接或来自扫描的未使用连接。
2. 错误的请求。客户端发送了错误的请求。每个 stats 套接字都应该可以看到这些错误（请参阅 womble 的先前答案）。

大多数现代浏览器（如 Firefox 或 Chrome）都在进行预连接。我看到 Firefox 或 Chrome 总是打开至少 2 个连接，即使浏览器只执行一个请求，如下载文件（例如只下载http://cdn.sstatic.net/serverfault/img/favicon.ico）

增加timeout http-requestHAProxy 配置中的 值有助于减少未使用连接的此类日志条目，因为较高的值意味着客户端使用连接的可能性更高，但您也面临着服务器无法处理所有打开的风险（空闲）连接了。如果您在 HAProxy 前面使用另一个负载均衡器（如 Amazon ELB），请检查 HAProxy 中的此超时是否与负载均衡器匹配，因为它们也可以使用预连接。

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

通常建议不要在不受控制的环境（例如：互联网）中使用此选项，否则不会记录扫描和其他恶意活动。

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.

解决方案：将“超时 http-request”更改为 20 秒或更多，而不是您的 5 秒。

Answer 3

就这个问题浪费了一天的时间。我们发现一些请求标头太大。8k 是 HAProxy 中的默认最大大小（所有标头组合），我们公司喜欢 cookie。在我们的例子中，大约 8% 的请求标头太大，因此在第 8092 个字节之后被截断。

来自文档：

如果HTTP请求大于（tune.bufsize -une.maxrewrite），haproxy将返回HTTP 400（Bad Request）错误。同样，如果 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

希望能帮助到你！

Answer 4

BADREQ仅仅意味着客户端发送了一个错误的请求；在 HTTP 模式下，这可能意味着客户端堵塞，而您对此无能为力。要查看确切的错误是什么，请连接到 stats 套接字（使用 socat）并运行show errors。很可能有人试图在其他网络服务器上运行漏洞，因此您可以忽略它。