我在Ubuntu 14.04上安装了一个HAProxy，在Ubuntu 14.04和Apache2上运行一个单独的后端服务器。
执行请求时，并不是所有的请求都被logging下来 即使在debugging模式下运行HAProxy，也不会显示terminal上的所有请求。
我有一个包含图像的index.html。 当使用Google Chrome请求页面时，我可以在督察中看到总共需要3个文件（index.html，header.gif和favicon.ico）。
然而，HAProxy只会loggingindex.html的实际请求，如果我非常快速地重新载入页面，它甚至不会logging所有index.html的请求。
我曾尝试使用socat进行debugging，但没有通过这种方式logging错误。 我曾尝试将日志格式设置为tcplog，但这也没有帮助，并没有logging所有的请求。
我究竟做错了什么？
rsyslogdconfiguration：
$ ModLoad imudp $ UDPServerAddress 127.0.0.1 $ UDPServerRun 514 local0。* - / var / log / haproxy / haproxy.log ＆〜
HAProxyconfiguration：
全球 日志127.0.0.1 local0 日志发送主机名 守护进程 maxconn 256 统计socket / tmp / haproxy 默认 日志全球 超时连接5000ms 超时客户端50000ms 超时服务器50000ms 前端http-in 模式http 选项httplog ＃绑定到所有IP的端口9200 绑定0.0.0.0:80 default_backend http-out 后端http-out 模式http 平衡最less 服务器web2 xxx.xxx.xxx.xxx:80
haproxy日志
Sep 17 14:38:16 front2.xxx.net haproxy [5436]：xxx.xxx.xxx.xxx:61745 [17 / Sep / 2015：14：38：06.771] http-in http-in / -1 / - 1 / -1 / -1 / 10000 400 187 - - CR - 2/2/0/0/0 0/0“” Sep 17 14:38:16 front2.xxx.net haproxy [5436]：xxx.xxx.xxx.xxx:61744 [17 / Sep / 2015：14：38：06.771] http-in http-out / web2 0/0 / 1/2/10001 200 23198 - - ---- 1/1/0/0/0 0/0“GET /index.html HTTP / 1.1” Sep 17 14:38:26 front2.xxx.net haproxy [5436]：xxx.xxx.xxx.xxx:61746 [17 / Sep / 2015：14：38：06.772] http-in http-in / -1 / - 1 / -1 / -1 / 20000 400 187 - - CR - 0/0/0/0/0 0/0“”
apache2日志
注册.xxx.net:80 185.92.61.11 - - [17 / Sep / 2015：14：38：06 +0200]“GET /index.html HTTP / 1.1”200 1192“ - ”“Mozilla / 5.0（Windows NT 10.0 ; WOW64）AppleWebKit / 537.36（KHTML，像Gecko）Chrome / 45.0.2454.93 Safari / 537.36“ 注册.xxx.net:80 185.92.61.11 - - [17 / Sep / 2015：14：38：06 +0200]“GET /header.gif HTTP / 1.1”200 4145“http://xxx.xxx.xxx。 xxx / index.html“”Mozilla / 5.0（Windows NT 10.0; WOW64）AppleWebKit / 537.36（KHTML，如Gecko）Chrome / 45.0.2454.93 Safari / 537.36“ 注册.xxx.net:80 185.92.61.11 - - [17 / Sep / 2015：14：38：06 +0200]“GET /favicon.ico HTTP / 1.1”200 17861“http://xxx.xxx.xxx。 xxx / index.html“”Mozilla / 5.0（Windows NT 10.0; WOW64）AppleWebKit / 537.36（KHTML，如Gecko）Chrome / 45.0.2454.93 Safari / 537.36“
所有HAProxy版本都在1.5-dev22之前，当在mode http使用时，如果没有指定其他“子模式”，它将在tunnel “子模式”下工作。 我意识到在HAProxy中实际上并没有像“子模式”那样的东西，但我不知道还有什么可以称之为的。 文档只是使用“模式”一词，但我觉得更令人困惑…
无论如何，在tunnel “子模式”中， 只有第一个请求和响应被处理，而其他的一切都是在没有任何分析的情况下被转发的。 这种模式不应该被使用，因为它会在logging和HTTP处理方面造成很多麻烦。
从1.5-dev22开始，默认的“子模式”从tunnel改变为keep alive ，这意味着所有的请求和响应都被处理，并且连接在响应和新请求之间保持打开但是空闲。
这可以通过在前端和后端使用option http-keep-alive ， option http-tunnel ， option httpclose ， option http-server-close和option forceclose关键字以及有效模式（或者“子模式”将）在文档中概述。 在第4节中，有一个表格显示了有效的“子模式”，根据哪个选项设置在前端，后台用于特定的连接。
为了完整起见，这里是文档的相关部分，包括表格和各种“子模式”，就像它在写这篇文章的时候（1.5.14）一样：
In HTTP mode, the processing applied to requests and responses flowing over a connection depends in the combination of the frontend's HTTP options and the backend's. HAProxy supports 5 connection modes : - KAL : keep alive ("option http-keep-alive") which is the default mode : all requests and responses are processed, and connections remain open but idle between responses and new requests. - TUN: tunnel ("option http-tunnel") : this was the default mode for versions 1.0 to 1.5-dev21 : only the first request and response are processed, and everything else is forwarded with no analysis at all. This mode should not be used as it creates lots of trouble with logging and HTTP processing. - PCL: passive close ("option httpclose") : exactly the same as tunnel mode, but with "Connection: close" appended in both directions to try to make both ends close after the first request/response exchange. - SCL: server close ("option http-server-close") : the server-facing connection is closed after the end of the response is received, but the client-facing connection remains open. - FCL: forced close ("option forceclose") : the connection is actively closed after the end of the response. The effective mode that will be applied to a connection passing through a frontend and a backend can be determined by both proxy modes according to the following matrix, but in short, the modes are symmetric, keep-alive is the weakest option and force close is the strongest. Backend mode | KAL | TUN | PCL | SCL | FCL ----+-----+-----+-----+-----+---- KAL | KAL | TUN | PCL | SCL | FCL ----+-----+-----+-----+-----+---- TUN | TUN | TUN | PCL | SCL | FCL Frontend ----+-----+-----+-----+-----+---- mode PCL | PCL | PCL | PCL | FCL | FCL ----+-----+-----+-----+-----+---- SCL | SCL | SCL | FCL | SCL | FCL ----+-----+-----+-----+-----+---- FCL | FCL | FCL | FCL | FCL | FCL