haproxy 官方文档

分享一下我老师大神的人工智能教程。零基础！通俗易懂！风趣幽默！还带黄段子！希望你也加入到我们人工智能的队伍中来！https://blog.csdn.net/jiangjunshow

                       

HAProxy     Configuration Manual
            version 1.5-dev24   willy tarreau       2014/04/26

This document covers the configuration language as implemented in the version
specified above. It does not provide any hint, example or advice. For such
documentation, please refer to the Reference Manual or the Architecture Manual.
The summary below is meant to help you search sections by name and navigate
through the document.

本文档涵盖了实现配置语言,它不提供任何提示,例子或者建议。 对于这样的文件,

请参阅参考手册或建筑手册。
下面的摘要是为了帮助你搜索部分的名称和导航
通过文件.

Note to documentation contributors :  注意文档的贡献者

This document is formatted with 80 columns per line, with even number ofspaces for indentation and without tabs. Please follow these rules strictlyso that it remains easily printable everywhere. If a line needs to beprinted verbatim and does not fit, please end each line with a backslash('\') and continue on next line, indented by two characters. It is alsosometimes useful to prefix all output lines (logs, console outs) with 3closing angle brackets ('>>>') in order to help get the difference betweeninputs and outputs when it can become ambiguous. If you add sections,please update the summary below for easier searching.
  
  
1
2
3
4
5
6
7
8
9

Summary
1.Quick reminder about HTTP
1.1.The HTTP transaction model
1.2.HTTP request
1.2.1.The Request line
1.2.2.The request headers
1.3.HTTP response
1.3.1.The Response line
1.3.2.The response headers

2.Configuring HAProxy
2.1.Configuration file format
2.2.Time format
2.3.Examples

3.Global parameters
3.1.Process management and security
3.2.Performance tuning
3.3.Debugging
3.4.Userlists
3.5.Peers

4.Proxies
4.1.Proxy keywords matrix
4.2.Alphabetically sorted keywords reference

5.Bind and Server options
5.1.Bind options
5.2.Server and default-server options

6.HTTP header manipulation
7.Using ACLs and fetching samples
7.1.ACL basics
7.1.1.Matching booleans
7.1.2.Matching integers
7.1.3.Matching strings
7.1.4.Matching regular expressions (regexes)
7.1.5.Matching arbitrary data blocks
7.1.6.Matching IPv4 and IPv6 addresses
7.2.Using ACLs to form conditions
7.3.Fetching samples
7.3.1.Converters
7.3.2.Fetching samples from internal states
7.3.3.Fetching samples at Layer 4
7.3.4.Fetching samples at Layer 5
7.3.5.Fetching samples from buffer contents (Layer 6)
7.3.6.Fetching HTTP samples (Layer 7)
7.4.Pre-defined ACLs

8.Logging
8.1.Log levels
8.2.Log formats
8.2.1.Default log format
8.2.2.TCP log format
8.2.3.HTTP log format
8.2.4.Custom log format
8.2.5.Error log format
8.3.Advanced logging options
8.3.1.Disabling logging of external tests
8.3.2.Logging before waiting for the session to terminate
8.3.3.Raising log level upon errors
8.3.4.Disabling logging of successful connections
8.4.Timing events
8.5.Session state at disconnection
8.6.Non-printable characters
8.7.Capturing HTTP cookies
8.8.Capturing HTTP headers
8.9.
Examples of logs

9.Statistics and monitoring
9.1.CSV format
9.2.Unix Socket commands

1. Quick reminder about HTTP  关于HTTP快速提示

When haproxy is running in HTTP mode, both the request and the response are
fully analyzed and indexed, thus it becomes possible to build matching criteria
on almost anything found in the contents.

当HAProxy 在HTTP模式运行,无论是请求和响应是充分的分析和索引,从而建立匹配的标准在几乎在内容里可以发现的任何内容。

However, it is important to understand how HTTP requests and responses are
formed, and how HAProxy decomposes them. It will then become easier to write
correct rules and to debug existing configurations.
1.1. The HTTP transaction model

然而, 了解HTTP请求和响应的形成是重要的,HAProxy 如何处理他们,它会变得容易写正确的规则和调试现有的配置

1.1. HTTP事务模型

The HTTP protocol is transaction-driven. This means that each request will lead
to one and only one response. Traditionally, a TCP connection is established
from the client to the server, a request is sent by the client on the
connection, the server responds and the connection is closed. A new request
will involve a new connection :

HTTP 是事务驱动的,这意味着每个请求会lead to one and only one response。

传统的,一个TCP 连接是建立从客户端到服务端, 请求是被客户端发送,server 响应,连接关闭。

一个新的请求会调用新的连接:

[CON1] [REQ1] … [RESP1] [CLO1] [CON2] [REQ2] … [RESP2] [CLO2] …

In this mode, called the “HTTP close” mode, there are as many connection
establishments as there are HTTP transactions. Since the connection is closed
by the server after the response, the client does not need to know the content
length.

在这种模式下,叫做HTTP close 模式,有多少HTTP连接就有多少连接,因为一个连接被server关闭在响应后,

客户端不需要知道内容的长度。

Due to the transactional nature of the protocol, it was possible to improve it
to avoid closing a connection between two subsequent transactions. In this mode
however, it is mandatory that the server indicates the content length for each
response so that the client does not wait indefinitely. For this, a special
header is used: “Content-length”. This mode is called the “keep-alive” mode :

由于协议的的事务特性,它是可能来改善它避免关闭一个连接在两个随后的事务。

在这种模式下，它是强制的server 表明每个响应的内容长度,让客户端不在等下去。为此,

一个特殊的header 被使用:”Content-length” 这种模式叫做keep-alive

[CON] [REQ1] … [RESP1] [REQ2] … [RESP2] [CLO] …

Its advantages are a reduced latency between transactions, and less processing
power required on the server side. It is generally better than the close mode,
but not always because the clients often limit their concurrent connections to
a smaller value.

它的优点是减少交易之间的延迟,减少了处理器的需要。它通常比close mode好,

但并不总是因为客户端经常限制它们的并发连接到一个较小的值

A last improvement in the communications is the pipelining mode. It still uses
keep-alive, but the client does not wait for the first response to send the
second request. This is useful for fetching large number of images composing a
page :

一个最后的改善在通信中是在流水线模式, 它仍旧使用keep-alive，但客户端不等待第一个响应来发送第一个请求。

这对于获取大量的图片组成的页。

[CON] [REQ1] [REQ2] … [RESP1] [RESP2] [CLO] …

This can obviously have a tremendous benefit on performance because the network
latency is eliminated between subsequent requests. Many HTTP agents do not
correctly support pipelining since there is no way to associate a response with
the corresponding request in HTTP. For this reason, it is mandatory for the
server to reply in the exact same order as the requests were received.

这显然有一个巨大的好处在性能上,因为网络的潜在因素在随后的请求中被消除。

很多的HTTP 代理不正确的支持流水线操作,因为没有办法来关联一个响应和相应的请求在HTTP里。

对于这个原因, 它是强制性的对于server来响应以准确的顺序当请求被接收时

By default HAProxy operates in keep-alive mode with regards to persistent
connections: for each connection it processes each request and response, and
leaves the connection idle on both sides between the end of a response and the
start of a new request.

默认情况下, HAProxy 操作在keep-alive模式来强制保持连接:

对于每个它处理的请求和响应, 让连接保持idle在响应的结束端和请求的发起端

HAProxy supports 5 connection modes :
  - keep alive    : all requests and responses are processed (default)  所有的请求和响应被处理(默认)
  - tunnel        : only the first request and response are processed,   只有第一个请求和响应被处理, 其他的都被转发
                    everything else is forwarded with no analysis.
  - passive close : tunnel with “Connection: close” added in both directions.
  - server close  : the server-facing connection is closed after the response.
  - forced close  : the connection is actively closed after end of response.

1.2. HTTP request
First, let’s consider this HTTP request :  首先,让我们考虑这个HTTP请求

Line     Contents
  number
     1     GET /serv/login.php?lang=en&profile=2 HTTP/1.1
     2     Host: www.mydomain.com
     3     User-agent: my small browser
     4     Accept: image/jpeg, image/gif
     5     Accept: image/png

1.2.1. The Request line
Line 1 is the “request line”. It is always composed of 3 fields :

• a METHOD      : GET
• a URI         : /serv/login.php?lang=en&profile=2
• a version tag : HTTP/1.1

All of them are delimited by what the standard calls LWS (linear white spaces),
which are commonly spaces, but can also be tabs or line feeds/carriage returns
followed by spaces/tabs. The method itself cannot contain any colon (‘:’) and
is limited to alphabetic letters. All those various combinations make it
desirable that HAProxy performs the splitting itself rather than leaving it to
the user to write a complex or inaccurate regular expression.

所有都遵循LWS标准,这里通常是空格,但也可以是tabs

The URI itself can have several forms : URI本身可以有多种形式

• A “relative URI” : 相对URI

  /serv/login.php?lang=en&profile=2

  It is a complete URL without the host part. This is generally what is
  received by servers, reverse proxies and transparent proxies.

  它是一个完整的网址没有host部分,这通常是被服务器接收,反向代理或者透明代理。

• An “absolute URI”, also called a “URL” : 绝对URI 被叫做URL

  http://192.168.0.12:8080/serv/login.php?lang=en&profile=2

  It is composed of a “scheme” (the protocol name followed by ‘://’), a host
  name or address, optionally a colon (‘:’) followed by a port number, then
  a relative URI beginning at the first slash (‘/’) after the address part.
  This is generally what proxies receive, but a server supporting HTTP/1.1
  must accept this form too.

  它是有一个”scheme”（鞋子名字后面跟着’://’), 一个host name或者address,人选的一个colon(‘:’) 跟在一个端口号后面

  相对的URI 在第一个斜杠(/) 在地址部分后 这通常是代理接收,但服务器支持HTTP/1.1 必须接受这个格式

• a star (‘*’) : this form is only accepted in association with the OPTIONS
  method and is not relayable. It is used to inquiry a next hop’s
  capabilities.

  一个星号(‘*’)： 这种格式只能在一个选项方法相关被接收,不是被废弃的。它用于查询吓一跳的能力

• an address:port combination : 192.168.0.12:80
  This is used with the CONNECT method, which is used to establish TCP
  tunnels through HTTP proxies, generally for HTTPS, but sometimes for
  other protocols too.

  一个地址:端口组合  192.168.0.12:80

  这个用于在连接方法,用于建立TCP隧道通过HTTP代理,通常用于HTTPS，但也用于其他协议。

In a relative URI, two sub-parts are identified. The part before the question
mark is called the “path”. It is typically the relative path to static objects
on the server. The part after the question mark is called the “query string”.
It is mostly used with GET requests sent to dynamic scripts and is very
specific to the language, framework or application in use.

在一个相对的URI,两个字部分被确定. 在查询表级前的部分称为path，

它通常是是服务器上静态对象的相对路径。 请求表级后面的被称为  “query string”.

它主要用于GET 请求发送动态的脚本,特定的语言,框架或者应用

1.2.2. The request headers  请求Headers

The headers start at the second line. They are composed of a name at the
beginning of the line, immediately followed by a colon (‘:’). Traditionally,
an LWS is added after the colon but that’s not required. Then come the values.
Multiple identical headers may be folded into one single line, delimiting the
values with commas, provided that their order is respected. This is commonly
encountered in the “Cookie:” field. A header may span over multiple lines if
the subsequent lines begin with an LWS. In the example in 1.2, lines 4 and 5
define a total of 3 values for the “Accept:” header.

headers 从第2行开始, 他们是有一个名字在行开头组成,后面跟着一个colon(‘:’)

传统上,一个LWS 是被增加在;后面 但不是必须的。 接来是只值,

多个相同的页眉可以折腾成一个单一的行, 用逗号分隔,

但他们的顺序是严格的。  这通常是”Cookie”  一个header 可以扩约多行。

Contrary to a common mis-conception, header names are not case-sensitive, and
their values are not either if they refer to other header names (such as the
“Connection:” header).

相反的一个常见的错误概念,header 名字不区分大小写,他们的值是不可能的 如果它们指向一个其他的header names

The end of the headers is indicated by the first empty line. People often say
that it’s a double line feed, which is not exact, even if a double line feed
is one valid form of empty line.

headers 表明第一个空行, 人们常说这是一个双线的feed，这是不准确的,即使一个双行feed 是一个有效的空行。

Fortunately, HAProxy takes care of all these complex combinations when indexing
headers, checking values and counting them, so there is no reason to worry
about the way they could be written, but it is important not to accuse an
application of being buggy if it does unusual, valid things.

幸运的是,HAProxy 照顾所有的复杂的组合当索引headers时,检查值和计数,

因此没有理由担心关于它们写的方式,但重要的是不要指责一个应用被变得古怪的 如果它是不寻常的,有效的东西。

Important note:
   As suggested by RFC2616, HAProxy normalizes headers by replacing line breaks
   in the middle of headers by LWS in order to join multi-line headers. This
   is necessary for proper analysis and helps less capable HTTP parsers to work
   correctly and not to be fooled by such complex constructs.

重要说明；

1.3. HTTP response HTTP 响应

An HTTP response looks very much like an HTTP request. Both are called HTTP
messages. Let’s consider this HTTP response :

一个HTTP 响应 看起来像一个HTTP请求, 都叫做HTTP 消息,让我们考虑一下这个HTTP响应:

Line     Contents
  number
     1     HTTP/1.1 200 OK
     2     Content-length: 350
     3     Content-Type: text/html

As a special case, HTTP supports so called “Informational responses” as status
codes 1xx. These messages are special in that they don’t convey any part of the
response, they’re just used as sort of a signaling message to ask a client to
continue to post its request for instance. In the case of a status 100 response
the requested information will be carried by the next non-100 response message
following the informational one. This implies that multiple responses may be
sent to a single request, and that this only works when keep-alive is enabled
(1xx messages are HTTP/1.1 only). HAProxy handles these messages and is able to
correctly forward and skip them, and only process the next non-100 response. As
such, these messages are neither logged nor transformed, unless explicitly
state otherwise. Status 101 messages indicate that the protocol is changing
over the same connection and that haproxy must switch to tunnel mode, just as
if a CONNECT had occurred. Then the Upgrade header would contain additional
information about the type of protocol the connection is switching to.

作为一个特殊的情况下, HTTP支持所谓的’信息反应’是状态码1xx，这些消息是特别的,它们不传达响应的任何部分,

他们只用于一组信号消息来告诉客户端来继续POST 它的请求。

在状态100响应请求信息,将在下一个100响应信息执行在下面的信息里。

这意味着, 多个响应可能发送一个单独的请求,它只工作于keep-alive启动的时候(1xx 消息是HTTP/1.1 only)

HAProxy 处理那些消息,并能正确的转发和跳过它们,只会处理接下来的非100响应

那些消息既不记录也不转换, 除非显示的规定。

Status 101 消息表明协议是正在改变在相同的连接 ,haproxy 必须切换到隧道模式,

正如
如果发生连接。升级头将包含其他
有关连接的协议类型的信息是切换到。

1.3.1. The Response line   响应行

Line 1 is the “response line”. It is always composed of 3 fields : 

Line 1 是响应行, 它总是有3个部分组成:

• a version tag : HTTP/1.1
• a status code : 200
• a reason      : OK

The status code is always 3-digit. The first digit indicates a general status :
 - 1xx = informational message to be skipped (eg: 100, 101)
 - 2xx = OK, content is following   (eg: 200, 206)
 - 3xx = OK, no content following   (eg: 302, 304)
 - 4xx = error caused by the client (eg: 401, 403, 404)
 - 5xx = error caused by the server (eg: 500, 502, 503)

Please refer to RFC2616 for the detailed meaning of all such codes. The
“reason” field is just a hint, but is not parsed by clients. Anything can be
found there, but it’s a common practice to respect the well-established
messages. It can be composed of one or multiple words, such as “OK”, “Found”,
or “Authentication Required”.

请参见RFC2616的所有代码的具体含义,这个原因字段只是一个提示,但是不被客户端解析。

Haproxy may emit the following status codes by itself :

HAProxy 可以发出以下状态代码本身:

Code  When / reason
   200  access to stats page, and when replying to monitoring requests
   301  when performing a redirection, depending on the configured code
   302  when performing a redirection, depending on the configured code
   303  when performing a redirection, depending on the configured code
   307  when performing a redirection, depending on the configured code
   308  when performing a redirection, depending on the configured code
   400  for an invalid or too large request
   401  when an authentication is required to perform the action (when
        accessing the stats page)
   403  when a request is forbidden by a “block” ACL or “reqdeny” filter
   408  when the request timeout strikes before the request is complete
   500  when haproxy encounters an unrecoverable internal error, such as a
        memory allocation failure, which should never happen
   502  when the server returns an empty, invalid or incomplete response, or
        when an “rspdeny” filter blocks the response.
   503  when no server was available to handle the request, or in response to
        monitoring requests which match the “monitor fail” condition
   504  when the response timeout strikes before the server responds

The error 4xx and 5xx codes above may be customized (see “errorloc” in section
4.2).

1.3.2. The response headers 响应headers

Response headers work exactly like request headers, and as such, HAProxy uses
the same parsing function for both. Please refer to paragraph 1.2.2 for more
details.

响应头 工作和request头类似, 因此,HAProxy 使用相同的解析函数

1. Configuring HAProxy  配置HAProxy

2.1. Configuration file format  配置文件格式

HAProxy’s configuration process involves 3 major sources of parameters :

HAProxy 的配置涉及的参数涉及3个主要的来源:

• the arguments from the command-line, which always take precedence

  来自命令行的参数, 它总是优先

• the “global” section, which sets process-wide parameters
  global 章节, 设置过程参数

• the proxies sections which can take form of “defaults”, “listen”,
  “frontend” and “backend”.

  代理章节 采取defaults，listen，frontend，backend

The configuration file syntax consists in lines beginning with a keyword
referenced in this manual, optionally followed by one or several parameters
delimited by spaces. If spaces have to be entered in strings, then they must be
preceded by a backslash (‘\’) to be escaped. Backslashes also have to be
escaped by doubling them.

配置文件的语法是以关键字开头的,选项后跟着一个或者多个参数有空格分隔。

如果空格比需输入字符串,那么它们必须之前有一个转义\

2.2. Time format 时间格式

Some parameters involve values representing time, such as timeouts. These
values are generally expressed in milliseconds (unless explicitly stated
otherwise) but may be expressed in any other unit by suffixing the unit to the
numeric value. It is important to consider this because it will not be repeated
for every keyword. Supported units are :

一些参数涉及表示时间值,比如timeout，这些值通常是表示以毫秒显示

• us : microseconds. 1 microsecond = 1/1000000 second
• ms : milliseconds. 1 millisecond = 1/1000 second. This is the default.
• s  : seconds. 1s = 1000ms
• m  : minutes. 1m = 60s = 60000ms
• h  : hours.   1h = 60m = 3600s = 3600000ms
• d  : days.    1d = 24h = 1440m = 86400s = 86400000ms

2.3. Examples 例子
    # Simple configuration for an HTTP proxy listening on port 80 on all
     简单的配置用于HTTP 代理 侦听端口80

# interfaces and forwarding requests to a single backend "servers" with a接口和转发请求到一个单独的backedn "server"用一个单独的server server1 侦听在127.0.0.1:8000#single server "server1" listening on 127.0.0.1:8000global    daemon    maxconn 256defaults    mode http    timeout connect 5000ms    timeout client 50000ms    timeout server 50000msfrontend http-in    bind *:80    default_backend serversbackend servers    server server1 127.0.0.1:8000 maxconn 32# The same configuration defined with a single listen block. Shorter but# less expressive, especially in HTTP mode.相同的配置定义一个单独的侦听块, 短且少的表达式,尤其是HTTP模式global    daemon    maxconn 256defaults    mode http    timeout connect 5000ms    timeout client 50000ms    timeout server 50000mslisten http-in    bind *:80    server server1 127.0.0.1:8000 maxconn 32
  
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

Assuming haproxy is in $PATH, test these configurations in a shell with:

假设HAProxy 是在$PATH里， 测试那些配置在shell里:

$ sudo haproxy -f configuration.conf -c
  
  
1

1. Global parameters  全局参数
   Parameters in the “global” section are process-wide and often OS-specific. They
   are generally set once for all and do not need being changed once correct. Some
   of them have command-line equivalents.

在全局部分的参数是处理广泛的,通常是OS指定的。它们通常只设置一次对于所有的,不需要被改变一旦正确的话。

有些有命令行等价

The following keywords are supported in the “global” section :

下面的关键在”全局章节”

• Process management and security  处理管理和安全

  • ca-base
  • chroot
  • crt-base
  • daemon
  • gid
  • group
  • log
  • log-send-hostname
  • nbproc
  • pidfile
  • uid
  • ulimit-n
  • user
  • stats
  • ssl-server-verify
  • node
  • description
  • unix-bind

• Performance tuning   性能调优

  • max-spread-checks
  • maxconn
  • maxconnrate
  • maxcomprate
  • maxcompcpuusage
  • maxpipes
  • maxsessrate
  • maxsslconn
  • maxsslrate
  • noepoll
  • nokqueue
  • nopoll
  • nosplice
  • nogetaddrinfo
  • spread-checks
  • tune.bufsize
  • tune.chksize
  • tune.comp.maxlevel
  • tune.http.cookielen
  • tune.http.maxhdr
  • tune.idletimer
  • tune.maxaccept
  • tune.maxpollevents
  • tune.maxrewrite
  • tune.pipesize
  • tune.rcvbuf.client
  • tune.rcvbuf.server
  • tune.sndbuf.client
  • tune.sndbuf.server
  • tune.ssl.cachesize
  • tune.ssl.lifetime
  • tune.ssl.maxrecord
  • tune.zlib.memlevel
  • tune.zlib.windowsize

• Debugging

  • debug
  • quiet

3.1. Process management and security  处理管理和安全
ca-base

Assigns a default directory to fetch SSL CA certificates and CRLs from when a
relative path is used with “ca-file” or “crl-file” directives. Absolute
locations specified in “ca-file” and “crl-file” prevail and ignore “ca-base”.

指定一个默认的获取SSL CA证书目录,CRLs从一个相对的路径被用于  “ca-file” or “crl-file” 目录。

决定的路径在”ca-file” and “crl-file” 为准忽略”ca-base”.

chroot

Changes current directory to  and performs a chroot() there before
dropping privileges. This increases the security level in case an unknown
vulnerability would be exploited, since it would make it very hard for the
attacker to exploit the system. This only works when the process is started
with superuser privileges. It is important to ensure that  is both
empty and unwritable to anyone.

改变当前目录到 执行一个chroot()  在放弃权限前。这个增加了安全级别万一一个未知的安全级别的

漏洞被利用,因为它会使黑客变得苦难。

cpu-map <”all”|”odd”|”even”|process_num> …
On Linux 2.6 and above, it is possible to bind a process to a specific CPU
set. This means that the process will never run on other CPUs. The “cpu-map”
directive specifies CPU sets for process sets. The first argument is the
process number to bind. This process must have a number between 1 and 32,
and any process IDs above nbproc are ignored. It is possible to specify all
processes at once using “all”, only odd numbers using “odd” or even numbers
using “even”, just like with the “bind-process” directive. The second and
forthcoming arguments are CPU sets. Each CPU set is either a unique number
between 0 and 31 or a range with two such numbers delimited by a dash (‘-‘).
Multiple CPU numbers or ranges may be specified, and the processes will be
allowed to bind to all of them. Obviously, multiple “cpu-map” directives may
be specified. Each “cpu-map” directive will replace the previous ones when
they overlap.

在Linux 2.6以上版本, 它有可能将一个进程绑定到一个特别的CPU 集。

这意味着进程不会运行在其他的CPUs上。
“cpu-map” 指令 特定的CPU集来处理。第一个参数是需要绑定的进程号,

进程号必须有一个数字在1-32之间,任何进程IDs 在nbproc 被忽略。 可以指定所有的进程使用all

只有奇数使用奇数或者偶数使用偶数,就像bind-process 指令。

第二 即将到来的参数是CPU 集,每个CPU 集是一个唯一的数字在0-31 或者一个范围

crt-base

Assigns a default directory to fetch SSL certificates from when a relative
path is used with “crtfile” directives. Absolute locations specified after
“crtfile” prevail and ignore “crt-base”.

指定一个默认的目录用来获取SSL 认证从一个相对路径使用 “crtfile” 目录,

指定的决定路径在”crtfile” 为准

daemon
Makes the process fork into background. This is the recommended mode of
operation. It is equivalent to the command line “-D” argument. It can be
disabled by the command line “-db” argument.

让进程变成后台进程, 这是推荐的模式

gid 
Changes the process’ group ID to . It is recommended that the group
ID is dedicated to HAProxy or to a small set of similar daemons. HAProxy must
be started with a user belonging to this group, or with superuser privileges.
Note that if haproxy is started from a user having supplementary groups, it
will only be able to drop these groups if started with superuser privileges.
See also “group” and “uid”.
改变进程的group ID, 建议goup ID 是单独的对于HAPorxy 或者一个小部分的守护进程。

HAProxy 必须启用用户必须属于这个组,或者有超级用户权限。

注意如果haproxy 从一个超级用户组启动

group 
Similar to “gid” but uses the GID of group name  from /etc/group.
See also “gid” and “user”.
log

  [max level [min level]]
Adds a global syslog server. Up to two global servers can be defined. They
will receive logs for startups and exits, as well as all logs from proxies
configured with “log global”.

类似 “gid”  但使用group name 的GID 在/etc/group

can be one of:

  - An IPv4 address optionally followed by a colon and a UDP port. If    no port is specified, 514 is used by default (the standard syslog    port).  - An IPv6 address followed by a colon and optionally a UDP port. If    no port is specified, 514 is used by default (the standard syslog    port).  - A filesystem path to a UNIX domain socket, keeping in mind    considerations for chroot (be sure the path is accessible inside    the chroot) and uid/gid (be sure the path is appropriately    writeable).  Any part of the address string may reference any number of environment  variables by preceding their name with a dollar sign ('$') and  optionally enclosing them with braces ('{}'), similarly to what is done  in Bourne shell.
  
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

must be one of the 24 standard syslog facilities :  <设备>必须是24个标准的syslog设备

    kern   user   mail   daemon auth   syslog lpr    news    uucp   cron   auth2  ftp    ntp    audit  alert  cron2    local0 local1 local2 local3 local4 local5 local6 local7
  
  
1
2
3

An optional level can be specified to filter outgoing messages. By default,
all messages are sent. If a maximum level is specified, only messages with a
severity at least as important as this level will be sent. An optional minimum
level can be specified. If it is set, logs emitted with a more severe level
than this one will be capped to this level. This is used to avoid sending
“emerg” messages on all terminals on some default syslog configurations.
Eight levels are known :

一个额外的level可以被指定来过滤传出的消息。默认, 所有的消息发送 如果最大的level 被指定,

则只有至少同样重要的的消息才会被发送。 一个可选的最小的level 可以被指定。

如果被设置,记录发出一个多个严重level。

    emerg  alert  crit   err    warning notice info  debug
  
  
1

log-send-hostname []
Sets the hostname field in the syslog header. If optional “string” parameter
is set the header is set to the string contents, otherwise uses the hostname
of the system. Generally used if one is not relaying logs through an
intermediate syslog server or for simply customizing the hostname printed in
the logs.

设置hostname 域在syslog header， 如果选项”字符串” 参数设置header 设置了字符串内容,

否则使用系统的hostname ,一般使用,如果一个不是中间日志通过一个中间的Syslog server
或者简单的定义主机打印日志

log-tag 
Sets the tag field in the syslog header to this string. It defaults to the
program name as launched from the command line, which usually is “haproxy”.
Sometimes it can be useful to differentiate between multiple processes
running on the same host.

在syslog header里设置tag 字段,默认是程序名 通常是haproxy 

有些时候它是有用的 当有多个进程运行在一个主机

nbproc 
Creates  processes when going daemon. This requires the “daemon”
mode. By default, only one process is created, which is the recommended mode
of operation. For systems limited to small sets of file descriptors per
process, it may be needed to fork multiple daemons. USING MULTIPLE PROCESSES
IS HARDER TO DEBUG AND IS REALLY DISCOURAGED. See also “daemon”.

创建 进程当运行在dsemon模式, 这个需要 “daemon” 模式,

默认的,只有一个进程被创建,是推荐的操作模式。  系统限制到一个小的sets 对于每个进程的文件描述符

它可能需要fork 多个daemons 使用多个进程是很难debug ,真的很沮丧

pidfile

Writes pids of all daemons into file . This option is equivalent to
the “-p” command line argument. The file must be accessible to the user
starting the process. See also “daemon”.

写入所有的dsemons 到一个pidfile，这个选项相当于命令行的-p命令  这个文件必须是可读的

stats bind-process [ all | odd | even | [-] ] …

Limits the stats socket to a certain set of processes numbers. By default the
stats socket is bound to all processes, causing a warning to be emitted when
nbproc is greater than 1 because there is no way to select the target process
when connecting. However, by using this setting, it becomes possible to pin
the stats socket to a specific set of processes, typically the first one. The
warning will automatically be disabled when this setting is used, whatever
the number of processes used.

限制统计 socket 到某个进程数,默认的统计的socket 是限定到所有的进程,

导致一个警告当nbproc >1，因为没有办法来选择目标的处理器 当连接的时候。

然而,通过使用设置, 是可能pin 统计的socket 到一个特定的CPU, 通常是第一个。

ssl-default-bind-ciphers 
This setting is only available when support for OpenSSL was built in. It sets
the default string describing the list of cipher algorithms (“cipher suite”)
that are negotiated during the SSL/TLS handshake for all “bind” lines which
do not explicitly define theirs. The format of the string is defined in
“man 1 ciphers” from OpenSSL man pages, and can be for instance a string such
as “AES:ALL:!aNULL:!eNULL:+RC4:@STRENGTH” (without quotes). Please check the
“bind” keyword for more information.

ssl-default-server-ciphers 
This setting is only available when support for OpenSSL was built in. It
sets the default string describing the list of cipher algorithms that are
negotiated during the SSL/TLS handshake with the server, for all “server”
lines which do not explicitly define theirs. The format of the string is
defined in “man 1 ciphers”. Please check the “server” keyword for more
information.

ssl-server-verify [none|required]
The default behavior for SSL verify on servers side. If specified to ‘none’,
servers certificates are not verified. The default is ‘required’ except if
forced using cmdline option ‘-dV’.

stats socket [|] [param*]
Binds a UNIX socket to  or a TCPv4/v6 address to .
Connections to this socket will return various statistics outputs and even
allow some commands to be issued to change some runtime settings. Please
consult section 9.2 “Unix Socket commands” for more details.

All parameters supported by “bind” lines are supported, for instance to
restrict access to some users or their access rights. Please consult
section 5.1 for more information.
stats timeout

The servers will accept between 100 and 1000 concurrent connections each

and the maximum of 1000 will be reached when the backend reaches 10000

connections.

backend dynamic
   fullconn   10000
   server     srv1   dyn1:80 minconn 100 maxconn 1000
   server     srv2   dyn2:80 minconn 100 maxconn 1000
See also : “maxconn”, “server”
grace
Maintain a proxy operational for some time after a soft stop
May be used in sections :

defaults    frontend    listen  backend
yes
yes yes
yes yes
yes yes
yes
Arguments :
    is the time (by default in milliseconds) for which the instance
          will remain operational with the frontend sockets still listening
          when a soft-stop is received via the SIGUSR1 signal.

This may be used to ensure that the services disappear in a certain order.
This was designed so that frontends which are dedicated to monitoring by an
external equipment fail immediately while other ones remain up for the time
needed by the equipment to detect the failure.

这个可能是用来确保服务在某个order中消失

Note that currently, there is very little benefit in using this parameter,
and it may in fact complicate the soft-reconfiguration process more than
simplify it.

注意,目前,使用这个参数有很少的好处.
hash-type   
Specify a method to use for mapping hashes to servers
May be used in sections :

defaults    frontend    listen  backend
yes
yes no
no  yes
yes yes
yes
Arguments :
 is the method used to select a server from the hash computed by
         the  :

map-based   the hash table is a static array containing all alive servers.
              The hashes will be very smooth, will consider weights, but
              will be static in that weight changes while a server is up
              will be ignored. This means that there will be no slow start.
              Also, since a server is selected by its position in the array,
              most mappings are changed when the server count changes. This
              means that when a server goes up or down, or when a server is
              added to a farm, most connections will be redistributed to
              different servers. This can be inconvenient with caches for
              instance.

consistent  the hash table is a tree filled with many occurrences of each
              server. The hash key is looked up in the tree and the closest
              server is chosen. This hash is dynamic, it supports changing
              weights while the servers are up, so it is compatible with the
              slow start feature. It has the advantage that when a server
              goes up or down, only its associations are moved. When a
              server is added to the farm, only a few part of the mappings
              are redistributed, making it an ideal method for caches.
              However, due to its principle, the distribution will never be
              very smooth and it may sometimes be necessary to adjust a
              server’s weight or its ID to get a more balanced distribution.
              In order to get the same distribution on multiple load
              balancers, it is important that all servers have the exact
              same IDs. Note: consistent hash uses sdbm and avalanche if no
              hash function is specified.

is the hash function to be used :

sdbm   this function was created initially for sdbm (a public-domain
          reimplementation of ndbm) database library. It was found to do
          well in scrambling bits, causing better distribution of the keys
          and fewer splits. It also happens to be a good general hashing
          function with good distribution, unless the total server weight
          is a multiple of 64, in which case applying the avalanche
          modifier may help.

djb2   this function was first proposed by Dan Bernstein many years ago
          on comp.lang.c. Studies have shown that for certain workload this
          function provides a better distribution than sdbm. It generally
          works well with text-based inputs though it can perform extremely
          poorly with numeric-only input or when the total server weight is
          a multiple of 33, unless the avalanche modifier is also used.

wt6    this function was designed for haproxy while testing other
          functions in the past. It is not as smooth as the other ones, but
          is much less sensible to the input data set or to the number of
          servers. It can make sense as an alternative to sdbm+avalanche or
          djb2+avalanche for consistent hashing or when hashing on numeric
          data such as a source IP address or a visitor identifier in a URL
          parameter.

indicates an optional method applied after hashing the key :

avalanche   This directive indicates that the result from the hash
               function above should not be used in its raw form but that
               a 4-byte full avalanche hash must be applied first. The
               purpose of this step is to mix the resulting bits from the
               previous hash in order to avoid any undesired effect when
               the input contains some limited values or when the number of
               servers is a multiple of one of the hash’s components (64
               for SDBM, 33 for DJB2). Enabling avalanche tends to make the
               result less predictable, but it’s also not as smooth as when
               using the original function. Some testing might be needed
               with some workloads. This hash is one of the many proposed
               by Bob Jenkins.
The default hash type is “map-based” and is recommended for most usages. The
default function is “sdbm”, the selection of a function should be based on
the range of the values being hashed.
See also : “balance”, “server”
http-check disable-on-404
Enable a maintenance mode upon HTTP/404 response to health-checks
May be used in sections :

defaults    frontend    listen  backend
yes
yes no
no  yes
yes yes
yes
Arguments : none
When this option is set, a server which returns an HTTP code 404 will be
excluded from further load-balancing, but will still receive persistent
connections. This provides a very convenient method for Web administrators
to perform a graceful shutdown of their servers. It is also important to note
that a server which is detected as failed while it was in this mode will not
generate an alert, just a notice. If the server responds 2xx or 3xx again, it
will immediately be reinserted into the farm. The status on the stats page
reports “NOLB” for a server in this mode. It is important to note that this
option only works in conjunction with the “httpchk” option. If this option
is used with “http-check expect”, then it has precedence over it so that 404
responses will still be considered as soft-stop.

当这个选项被设置后, 服务器返回一个HTTP code 404 将被排除,

但是仍旧会收到持续的连接。

See also : “option httpchk”, “http-check expect”
http-check expect [!]  
Make HTTP health checks consider response contents or specific status codes
May be used in sections :

defaults    frontend    listen  backend
yes
yes no
no  yes
yes yes
yes
Arguments :
   is a keyword indicating how to look for a specific pattern in the
          response. The keyword may be one of “status”, “rstatus”,
          “string”, or “rstring”. The keyword may be preceded by an
          exclamation mark (“!”) to negate the match. Spaces are allowed
          between the exclamation mark and the keyword. See below for more
          details on the supported keywords.

is the pattern to look for. It may be a string or a regular
          expression. If the pattern contains spaces, they must be escaped
          with the usual backslash (‘\’).
By default, “option httpchk” considers that response statuses 2xx and 3xx
are valid, and that others are invalid. When “http-check expect” is used,
it defines what is considered valid or invalid. Only one “http-check”
statement is supported in a backend. If a server fails to respond or times
out, the check obviously fails. The available matches are :

status  : test the exact string match for the HTTP status code.
                    A health check response will be considered valid if the
                    response’s status code is exactly this string. If the
                    “status” keyword is prefixed with “!”, then the response
                    will be considered invalid if the status code matches.

rstatus  : test a regular expression for the HTTP status code.
                    A health check response will be considered valid if the
                    response’s status code matches the expression. If the
                    “rstatus” keyword is prefixed with “!”, then the response
                    will be considered invalid if the status code matches.
                    This is mostly used to check for multiple codes.

string  : test the exact string match in the HTTP response body.
                    A health check response will be considered valid if the
                    response’s body contains this exact string. If the
                    “string” keyword is prefixed with “!”, then the response
                    will be considered invalid if the body contains this
                    string. This can be used to look for a mandatory word at
                    the end of a dynamic page, or to detect a failure when a
                    specific error appears on the check page (eg: a stack
                    trace).

rstring  : test a regular expression on the HTTP response body.
                    A health check response will be considered valid if the
                    response’s body matches this expression. If the “rstring”
                    keyword is prefixed with “!”, then the response will be
                    considered invalid if the body matches the expression.
                    This can be used to look for a mandatory word at the end
                    of a dynamic page, or to detect a failure when a specific
                    error appears on the check page (eg: a stack trace).

It is important to note that the responses will be limited to a certain size
defined by the global “tune.chksize” option, which defaults to 16384 bytes.
Thus, too large responses may not contain the mandatory pattern when using
“string” or “rstring”. If a large response is absolutely required, it is
possible to change the default max size by setting the global variable.
However, it is worth keeping in mind that parsing very large responses can
waste some CPU cycles, especially when regular expressions are used, and that
it is always better to focus the checks on smaller resources.

Last, if “http-check expect” is combined with “http-check disable-on-404”,
then this last one has precedence when the server responds with 404.
Examples :

only accept status 200 as valid

http-check expect status 200

consider SQL errors as errors

http-check expect ! string SQL\ Error

consider status 5xx only as errors

http-check expect ! rstatus ^5

check that we have a correct hexadecimal tag before /html

http-check expect rstring

addresses .252 and .253 are just probing us.

frontend www
    monitor-net 192.168.0.252/31
See also : “monitor fail”, “monitor-uri”
monitor-uri 
Intercept a URI used by external components’ monitor requests
May be used in sections :

defaults    frontend    listen  backend
yes
yes yes
yes yes
yes no
no
Arguments :
     is the exact URI which we want to intercept to return HAProxy’s
          health status instead of forwarding the request.
When an HTTP request referencing  will be received on a frontend,
HAProxy will not forward it nor log it, but instead will return either
“HTTP/1.0 200 OK” or “HTTP/1.0 503 Service unavailable”, depending on failure
conditions defined with “monitor fail”. This is normally enough for any
front-end HTTP probe to detect that the service is UP and running without
forwarding the request to a backend server. Note that the HTTP method, the
version and all headers are ignored, but the request must at least be valid
at the HTTP level. This keyword may only be used with an HTTP-mode frontend.

Monitor requests are processed very early. It is not possible to block nor
divert them using ACLs. They cannot be logged either, and it is the intended
purpose. They are only used to report HAProxy’s health to an upper component,
nothing more. However, it is possible to add any number of conditions using
“monitor fail” and ACLs so that the result can be adjusted to whatever check
can be imagined (most often the number of available servers in a backend).
Example :

Use /haproxy_test to report haproxy’s status

frontend www
    mode http
    monitor-uri /haproxy_test
See also : “monitor fail”, “monitor-net”
option abortonclose
no option abortonclose
Enable or disable early dropping of aborted requests pending in queues.
May be used in sections :

defaults    frontend    listen  backend
yes
yes no
no  yes
yes yes
yes
Arguments : none
In presence of very high loads, the servers will take some time to respond.
The per-instance connection queue will inflate, and the response time will
increase respective to the size of the queue times the average per-session
response time. When clients will wait for more than a few seconds, they will
often hit the “STOP” button on their browser, leaving a useless request in
the queue, and slowing down other users, and the servers as well, because the
request will eventually be served, then aborted at the first error
encountered while delivering the response.

As there is no way to distinguish between a full STOP and a simple output
close on the client side, HTTP agents should be conservative and consider
that the client might only have closed its output channel while waiting for
the response. However, this introduces risks of congestion when lots of users
do the same, and is completely useless nowadays because probably no client at
all will close the session while waiting for the response. Some HTTP agents
support this behaviour (Squid, Apache, HAProxy), and others do not (TUX, most
hardware-based load balancers). So the probability for a closed input channel
to represent a user hitting the “STOP” button is close to 100%, and the risk
of being the single component to break rare but valid traffic is extremely
low, which adds to the temptation to be able to abort a session early while
still not served and not pollute the servers.

In HAProxy, the user can choose the desired behaviour using the option
“abortonclose”. By default (without the option) the behaviour is HTTP
compliant and aborted requests will be served. But when the option is
specified, a session with an incoming channel closed will be aborted while
it is still possible, either pending in the queue for a connection slot, or
during the connection establishment if the server has not yet acknowledged
the connection request. This considerably reduces the queue size and the load
on saturated servers when users are tempted to click on STOP, which in turn
reduces the response time for other users.

If this option has been enabled in a “defaults” section, it can be disabled
in a specific instance by prepending the “no” keyword before it.
See also : “timeout queue” and server’s “maxconn” and “maxqueue” parameters
option accept-invalid-http-request
no option accept-invalid-http-request
Enable or disable relaxing of HTTP request parsing
May be used in sections :

defaults    frontend    listen  backend
yes
yes yes
yes yes
yes no
no
Arguments : none
By default, HAProxy complies with RFC2616 in terms of message parsing. This
means that invalid characters in header names are not permitted and cause an
error to be returned to the client. This is the desired behaviour as such
forbidden characters are essentially used to build attacks exploiting server
weaknesses, and bypass security filtering. Sometimes, a buggy browser or
server will emit invalid header names for whatever reason (configuration,
implementation) and the issue will not be immediately fixed. In such a case,
it is possible to relax HAProxy’s header name parser to accept any character
even if that does not make sense, by specifying this option. Similarly, the
list of characters allowed to appear in a URI is well defined by RFC3986, and
chars 0-31, 32 (space), 34 (‘”’), 60 (‘<’), 62 (‘>’), 92 (‘\’), 94 (‘^’), 96
(‘`’), 123 (‘{‘), 124 (‘|’), 125 (‘}’), 127 (delete) and anything above are
not allowed at all. Haproxy always blocks a number of them (0..32, 127). The
remaining ones are blocked by default unless this option is enabled.

This option should never be enabled by default as it hides application bugs
and open security breaches. It should only be deployed after a problem has
been confirmed.

When this option is enabled, erroneous header names will still be accepted in
requests, but the complete request will be captured in order to permit later
analysis using the “show errors” request on the UNIX stats socket. Similarly,
requests containing invalid chars in the URI part will be logged. Doing this
also helps confirming that the issue has been solved.

If this option has been enabled in a “defaults” section, it can be disabled
in a specific instance by prepending the “no” keyword before it.
See also : “option accept-invalid-http-response” and “show errors” on the stats socket.
option accept-invalid-http-response
no option accept-invalid-http-response
Enable or disable relaxing of HTTP response parsing
May be used in sections :

defaults    frontend    listen  backend
yes
yes no
no  yes
yes yes
yes
Arguments : none
By default, HAProxy complies with RFC2616 in terms of message parsing. This
means that invalid characters in header names are not permitted and cause an
error to be returned to the client. This is the desired behaviour as such
forbidden characters are essentially used to build attacks exploiting server
weaknesses, and bypass security filtering. Sometimes, a buggy browser or
server will emit invalid header names for whatever reason (configuration,
implementation) and the issue will not be immediately fixed. In such a case,
it is possible to relax HAProxy’s header name parser to accept any character
even if that does not make sense, by specifying this option.

This option should never be enabled by default as it hides application bugs
and open security breaches. It should only be deployed after a problem has
been confirmed.

When this option is enabled, erroneous header names will still be accepted in
responses, but the complete response will be captured in order to permit
later analysis using the “show errors” request on the UNIX stats socket.
Doing this also helps confirming that the issue has been solved.

If this option has been enabled in a “defaults” section, it can be disabled
in a specific instance by prepending the “no” keyword before it.
See also : “option accept-invalid-http-request” and “show errors” on the stats socket.
option allbackups
no option allbackups
Use either all backup servers at a time or only the first one
May be used in sections :

defaults    frontend    listen  backend
yes
yes no
no  yes
yes yes
yes
Arguments : none
By default, the first operational backup server gets all traffic when normal
servers are all down. Sometimes, it may be preferred to use multiple backups
at once, because one will not be enough. When “option allbackups” is enabled,
the load balancing will be performed among all backup servers when all normal
ones are unavailable. The same load balancing algorithm will be used and the
servers’ weights will be respected. Thus, there will not be any priority
order between the backup servers anymore.

默认情况下,第一个可操作的备份server 得到所有的流量当普通的servers 都down了。

有时候,它可能优选使用多个备份

This option is mostly used with static server farms dedicated to return a
“sorry” page when an application is completely offline.

If this option has been enabled in a “defaults” section, it can be disabled
in a specific instance by prepending the “no” keyword before it.
option checkcache
no option checkcache
Analyze all server responses and block responses with cacheable cookies
May be used in sections :

defaults    frontend    listen  backend
yes
yes no
no  yes
yes yes
yes
Arguments : none
Some high-level frameworks set application cookies everywhere and do not
always let enough control to the developer to manage how the responses should
be cached. When a session cookie is returned on a cacheable object, there is a
high risk of session crossing or stealing between users traversing the same
caches. In some situations, it is better to block the response than to let
some sensitive session information go in the wild.

The option “checkcache” enables deep inspection of all server responses for
strict compliance with HTTP specification in terms of cacheability. It
carefully checks “Cache-control”, “Pragma” and “Set-cookie” headers in server
response to check if there’s a risk of caching a cookie on a client-side
proxy. When this option is enabled, the only responses which can be delivered
to the client are :
  - all those without “Set-Cookie” header ;
  - all those with a return code other than 200, 203, 206, 300, 301, 410,
    provided that the server has not set a “Cache-control: public” header ;
  - all those that come from a POST request, provided that the server has not
    set a ‘Cache-Control: public’ header ;
  - those with a ‘Pragma: no-cache’ header
  - those with a ‘Cache-control: private’ header
  - those with a ‘Cache-control: no-store’ header
  - those with a ‘Cache-control: max-age=0’ header
  - those with a ‘Cache-control: s-maxage=0’ header
  - those with a ‘Cache-control: no-cache’ header
  - those with a ‘Cache-control: no-cache=”set-cookie”’ header
  - those with a ‘Cache-control: no-cache=”set-cookie,’ header
    (allowing other fields after set-cookie)

If a response doesn’t respect these requirements, then it will be blocked
just as if it was from an “rspdeny” filter, with an “HTTP 502 bad gateway”.
The session state shows “PH–” meaning that the proxy blocked the response
during headers processing. Additionally, an alert will be sent in the logs so
that admins are informed that there’s something to be fixed.

Due to the high impact on the application, the application should be tested
in depth with the option enabled before going to production. It is also a
good practice to always activate it during tests, even if it is not used in
production, as it will report potentially dangerous application behaviours.

If this option has been enabled in a “defaults” section, it can be disabled
in a specific instance by prepending the “no” keyword before it.
option clitcpka
no option clitcpka
Enable or disable the sending of TCP keepalive packets on the client side
May be used in sections :

defaults    frontend    listen  backend
yes
yes yes
yes yes
yes no
no
Arguments : none
When there is a firewall or any session-aware component between a client and
a server, and when the protocol involves very long sessions with long idle
periods (eg: remote desktops), there is a risk that one of the intermediate
components decides to expire a session which has remained idle for too long.

当这里有一个防火墙或者任何session-aware组件在客户端和server之间,

当协议涉及一个很长的会话 有很长的idle期限(例如 远程桌面),有一个风险，中间
组件决定过期一个会话，它一直处于闲置状态太长。

Enabling socket-level TCP keep-alives makes the system regularly send packets
to the other end of the connection, leaving it active. The delay between
keep-alive probes is controlled by the system only and depends both on the
operating system and its tuning parameters.

It is important to understand that keep-alive packets are neither emitted nor
received at the application level. It is only the network stacks which sees
them. For this reason, even if one side of the proxy already uses keep-alives
to maintain its connection alive, those keep-alive packets will not be
forwarded to the other side of the proxy.

需要了解keep-alive 包既不是发出也不不接收在应用层面。

Please note that this has nothing to do with HTTP keep-alive.

Using option “clitcpka” enables the emission of TCP keep-alive probes on the
client side of a connection, which should help when session expirations are
noticed between HAProxy and a client.

If this option has been enabled in a “defaults” section, it can be disabled
in a specific instance by prepending the “no” keyword before it.
See also : “option srvtcpka”, “option tcpka”
option contstats
Enable continuous traffic statistics updates
May be used in sections :

defaults    frontend    listen  backend
yes
yes yes
yes yes
yes no
no
Arguments : none
By default, counters used for statistics calculation are incremented
only when a session finishes. It works quite well when serving small
objects, but with big ones (for example large images or archives) or
with A/V streaming, a graph generated from haproxy counters looks like
a hedgehog. With this option enabled counters get incremented continuously,
during a whole session. Recounting touches a hotpath directly so
it is not enabled by default, as it has small performance impact (~0.5%).
option dontlog-normal
no option dontlog-normal
Enable or disable logging of normal, successful connections
May be used in sections :

defaults    frontend    listen  backend
yes
yes yes
yes yes
yes no
no
Arguments : none
There are large sites dealing with several thousand connections per second
and for which logging is a major pain. Some of them are even forced to turn
logs off and cannot debug production issues. Setting this option ensures that
normal connections, those which experience no error, no timeout, no retry nor
redispatch, will not be logged. This leaves disk space for anomalies. In HTTP
mode, the response status code is checked and return codes 5xx will still be
logged.

It is strongly discouraged to use this option as most of the time, the key to
complex issues is in the normal logs which will not be logged here. If you
need to separate logs, see the “log-separate-errors” option instead.
See also : “log”, “dontlognull”, “log-separate-errors” and section 8 about logging.
option dontlognull
no option dontlognull
Enable or disable logging of null connections
May be used in sections :

defaults    frontend    listen  backend
yes
yes yes
yes yes
yes no
no
Arguments : none
In certain environments, there are components which will regularly connect to
various systems to ensure that they are still alive. It can be the case from
another load balancer as well as from monitoring systems. By default, even a
simple port probe or scan will produce a log. If those connections pollute
the logs too much, it is possible to enable option “dontlognull” to indicate
that a connection on which no data has been transferred will not be logged,
which typically corresponds to those probes.

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

If this option has been enabled in a “defaults” section, it can be disabled
in a specific instance by prepending the “no” keyword before it.
See also : “log”, “monitor-net”, “monitor-uri” and section 8 about logging.
option forceclose
no option forceclose
Enable or disable active connection closing after response is transferred.
May be used in sections :

defaults    frontend    listen  backend
yes
yes yes
yes yes
yes yes
yes
Arguments : none
Some HTTP servers do not necessarily close the connections when they receive
the “Connection: close” set by “option httpclose”, and if the client does not
close either, then the connection remains open till the timeout expires. This
causes high number of simultaneous connections on the servers and shows high
global session times in the logs.

一些HTTP 服务器不需要关闭连接放它们接收到”Connection: close”(通过”option httpclose”)

如果客户端不关闭,连接仍旧打开直到超时,这个会导致同时有大量的连接

When this happens, it is possible to use “option forceclose”. It will
actively close the outgoing server channel as soon as the server has finished
to respond and release some resources earlier than with “option httpclose”.

当这种情况发生时,可以使用”option forceclose”. 它将主动关闭 outgoing server channel

只要server 已经完成响应和释放一些资源

This option may also be combined with “option http-pretend-keepalive”, which
will disable sending of the “Connection: close” header, but will still cause
the connection to be closed once the whole response is received.

这个选项可以结合 “option http-pretend-keepalive”, 会关闭发送”Connection: close” header,

但是仍旧会导致连接被关闭当整个响应被接收后。

This option disables and replaces any previous “option httpclose”, “option
http-server-close”, “option http-keep-alive”, or “option http-tunnel”.

If this option has been enabled in a “defaults” section, it can be disabled
in a specific instance by prepending the “no” keyword before it.
See also : “option httpclose” and “option http-pretend-keepalive”
option forwardfor [ except  ] [ header  ] [ if-none ]
Enable insertion of the X-Forwarded-For header to requests sent to servers
May be used in sections :

defaults    frontend    listen  backend
yes
yes yes
yes yes
yes yes
yes
Arguments :
 is an optional argument used to disable this option for sources
          matching 
    an optional argument to specify a different “X-Forwarded-For”
          header name.
Since HAProxy works in reverse-proxy mode, the servers see its IP address as
their client address. This is sometimes annoying when the client’s IP address
is expected in server logs. To solve this problem, the well-known HTTP header
“X-Forwarded-For” may be added by HAProxy to all requests sent to the server.
This header contains a value representing the client’s IP address. Since this
header is always appended at the end of the existing header list, the server
must be configured to always use the last occurrence of this header only. See
the server’s manual to find how to enable use of this standard header. Note
that only the last occurrence of the header must be used, since it is really
possible that the client has already brought one.

The keyword “header” may be used to supply a different header name to replace
the default “X-Forwarded-For”. This can be useful where you might already
have a “X-Forwarded-For” header from a different application (eg: stunnel),
and you need preserve it. Also if your backend server doesn’t use the
“X-Forwarded-For” header and requires different one (eg: Zeus Web Servers
require “X-Cluster-Client-IP”).

Sometimes, a same HAProxy instance may be shared between a direct client
access and a reverse-proxy access (for instance when an SSL reverse-proxy is
used to decrypt HTTPS traffic). It is possible to disable the addition of the
header for a known source address or network by adding the “except” keyword
followed by the network address. In this case, any source IP matching the
network will not cause an addition of this header. Most common uses are with
private networks or 127.0.0.1.

Alternatively, the keyword “if-none” states that the header will only be
added if it is not present. This should only be used in perfectly trusted
environment, as this might cause a security issue if headers reaching haproxy
are under the control of the end-user.

This option may be specified either in the frontend or in the backend. If at
least one of them uses it, the header will be added. Note that the backend’s
setting of the header subargument takes precedence over the frontend’s if
both are defined. In the case of the “if-none” argument, if at least one of
the frontend or the backend does not specify it, it wants the addition to be
mandatory, so it wins.
Examples :

Public HTTP address also used by stunnel on the same machine

frontend www
    mode http
    option forwardfor except 127.0.0.1  # stunnel already adds the header

Those servers want the IP Address in X-Client

backend www
    mode http
    option forwardfor header X-Client
See also : “option httpclose”, “option http-server-close”, “option forceclose”, “option http-keep-alive”
option http-keep-alive
no option http-keep-alive
Enable or disable HTTP keep-alive from client to server
May be used in sections :

defaults    frontend    listen  backend
yes
yes yes
yes yes
yes yes
yes
Arguments : none
By default HAProxy operates in keep-alive mode with regards to persistent
connections: for each connection it processes each request and response, and
leaves the connection idle on both sides between the end of a response and the
start of a new request. This mode may be changed by several options such as
“option http-server-close”, “option forceclose”, “option httpclose” or
“option http-tunnel”. This option allows to set back the keep-alive mode,
which can be useful when another mode was used in a defaults section.

默认情况下,HAPorxy 操作在keep-alive 模式来保持持续连接:

对于每个连接它处理每个请求和响应, 以及让连接idle 在启动新的请求和响应结束的两端。

这种模式会被改变通过几个选项 比如”option http-server-close”, “option forceclose”, “option httpclose” or
“option http-tunnel”.

Setting “option http-keep-alive” enables HTTP keep-alive mode on the client-
and server- sides. This provides the lowest latency on the client side (slow
network) and the fastest session reuse on the server side at the expense
of maintaining idle connections to the servers. In general, it is possible
with this option to achieve approximately twice the request rate that the
“http-server-close” option achieves on small objects. There are mainly two
situations where this option may be useful :

设置  “option http-keep-alive” 启用HTTP keep-alive mode 在客户端个服务端

这个提供了最低延迟在客户端(慢网络)，最快的session重用在server端。

在一般情况下,用这个选项来实现大约2倍的请求速度,”http-server-close”  选项完成在小的对象上。

• when the server is non-HTTP compliant and authenticates the connection
  instead of requests (eg: NTLM authentication)

  当服务器是non-HTTP 符合和认证连接代替请求

• when the cost of establishing the connection to the server is significant
  compared to the cost of retrieving the associated object from the server.

当建立连接的成本是重要的比较 检索相关对象的成本

This last case can happen when the server is a fast static server of cache.
In this case, the server will need to be properly tuned to support high enough
connection counts because connections will last until the client sends another
request.

当服务器是缓存的快速静态服务器, 在这种情况下, 服务器需要进行适当的调整来支持更加足够的连接数

因为连接会持续知道客户端发送另外一个请求。

If the client request has to go to another backend or another server due to
content switching or the load balancing algorithm, the idle connection will
immediately be closed and a new one re-opened. Option “prefer-last-server” is
available to try optimize server selection so that if the server currently
attached to an idle connection is usable, it will be used.

如果客户端请求需要到另外一个backend或者另外一个server 由于连接切换或者负载算法。

空闲的连接会立即被关闭,一个新的会重新被打开。 选项”prefer-last-server”

是可以尝试优化服务器

In general it is preferred to use “option http-server-close” with application
servers, and some static servers might benefit from “option http-keep-alive”.

一般来说,优先使用”option http-server-close” 一些静态的服务器可能从”option http-keep-alive”收益。

At the moment, logs will not indicate whether requests came from the same
session or not. The accept date reported in the logs corresponds to the end
of the previous request, and the request time corresponds to the time spent
waiting for a new request. The keep-alive request time is still bound to the
timeout defined by “timeout http-keep-alive” or “timeout http-request” if
not set.

在这一刻,日志不会显示青青是否来自相同的会话。接收的日期报告显示在日志

This option disables and replaces any previous “option httpclose”, “option
http-server-close”, “option forceclose” or “option http-tunnel”. When backend
and frontend options differ, all of these 4 options have precedence over
“option http-keep-alive”.
See also : “option forceclose”, “option http-server-close”, “option prefer-last-server”, “option http-pretend-keepalive”, “option httpclose”, and “1.1. The HTTP transaction model”.
option http-no-delay
no option http-no-delay
Instruct the system to favor low interactive delays over performance in HTTP
May be used in sections :

defaults    frontend    listen  backend
yes
yes yes
yes yes
yes yes
yes
Arguments : none
In HTTP, each payload is unidirectional and has no notion of interactivity.
Any agent is expected to queue data somewhat for a reasonably low delay.
There are some very rare server-to-server applications that abuse the HTTP
protocol and expect the payload phase to be highly interactive, with many
interleaved data chunks in both directions within a single request. This is
absolutely not supported by the HTTP specification and will not work across
most proxies or servers. When such applications attempt to do this through
haproxy, it works but they will experience high delays due to the network
optimizations which favor performance by instructing the system to wait for
enough data to be available in order to only send full packets. Typical
delays are around 200 ms per round trip. Note that this only happens with
abnormal uses. Normal uses such as CONNECT requests nor WebSockets are not
affected.

When “option http-no-delay” is present in either the frontend or the backend
used by a connection, all such optimizations will be disabled in order to
make the exchanges as fast as possible. Of course this offers no guarantee on
the functionality, as it may break at any other place. But if it works via
HAProxy, it will work as fast as possible. This option should never be used
by default, and should never be used at all unless such a buggy application
is discovered. The impact of using this option is an increase of bandwidth
usage and CPU usage, which may significantly lower performance in high
latency environments.
option http-pretend-keepalive
no option http-pretend-keepalive
Define whether haproxy will announce keepalive to the server or not
May be used in sections :

defaults    frontend    listen  backend
yes
yes yes
yes yes
yes yes
yes
Arguments : none
When running with “option http-server-close” or “option forceclose”, haproxy
adds a “Connection: close” header to the request forwarded to the server.
Unfortunately, when some servers see this header, they automatically refrain
from using the chunked encoding for responses of unknown length, while this
is totally unrelated. The immediate effect is that this prevents haproxy from
maintaining the client connection alive. A second effect is that a client or
a cache could receive an incomplete response without being aware of it, and
consider the response complete.

By setting “option http-pretend-keepalive”, haproxy will make the server
believe it will keep the connection alive. The server will then not fall back
to the abnormal undesired above. When haproxy gets the whole response, it
will close the connection with the server just as it would do with the
“forceclose” option. That way the client gets a normal response and the
connection is correctly closed on the server side.

It is recommended not to enable this option by default, because most servers
will more efficiently close the connection themselves after the last packet,
and release its buffers slightly earlier. Also, the added packet on the
network could slightly reduce the overall peak performance. However it is
worth noting that when this option is enabled, haproxy will have slightly
less work to do. So if haproxy is the bottleneck on the whole architecture,
enabling this option might save a few CPU cycles.

This option may be set both in a frontend and in a backend. It is enabled if
at least one of the frontend or backend holding a connection has it enabled.
This option may be combined with “option httpclose”, which will cause
keepalive to be announced to the server and close to be announced to the
client. This practice is discouraged though.

If this option has been enabled in a “defaults” section, it can be disabled
in a specific instance by prepending the “no” keyword before it.
See also : “option forceclose”, “option http-server-close”, and “option http-keep-alive”
option http-server-close
no option http-server-close
Enable or disable HTTP connection closing on the server side
May be used in sections :

defaults    frontend    listen  backend
yes
yes yes
yes yes
yes yes
yes
Arguments : none
By default HAProxy operates in keep-alive mode with regards to persistent
connections: for each connection it processes each request and response, and
leaves the connection idle on both sides between the end of a response and
the start of a new request. This mode may be changed by several options such
as “option http-server-close”, “option forceclose”, “option httpclose” or
“option http-tunnel”. Setting “option http-server-close” enables HTTP
connection-close mode on the server side while keeping the ability to support
HTTP keep-alive and pipelining on the client side.  This provides the lowest
latency on the client side (slow network) and the fastest session reuse on
the server side to save server resources, similarly to “option forceclose”.
It also permits non-keepalive capable servers to be served in keep-alive mode
to the clients if they conform to the requirements of RFC2616. Please note
that some servers do not always conform to those requirements when they see
“Connection: close” in the request. The effect will be that keep-alive will
never be used. A workaround consists in enabling “option
http-pretend-keepalive”.

At the moment, logs will not indicate whether requests came from the same
session or not. The accept date reported in the logs corresponds to the end
of the previous request, and the request time corresponds to the time spent
waiting for a new request. The keep-alive request time is still bound to the
timeout defined by “timeout http-keep-alive” or “timeout http-request” if
not set.

This option may be set both in a frontend and in a backend. It is enabled if
at least one of the frontend or backend holding a connection has it enabled.
It disables and replaces any previous “option httpclose”, “option forceclose”,
“option http-tunnel” or “option http-keep-alive”. Please check section 4
(“Proxies”) to see how this option combines with others when frontend and
backend options differ.

If this option has been enabled in a “defaults” section, it can be disabled
in a specific instance by prepending the “no” keyword before it.
See also : “option forceclose”, “option http-pretend-keepalive”, “option httpclose”, “option http-keep-alive”, and “1.1. The HTTP transaction model”.
option http-tunnel
no option http-tunnel
Disable or enable HTTP connection processing after first transaction
May be used in sections :

defaults    frontend    listen  backend
yes
yes yes
yes yes
yes yes
yes
Arguments : none
By default HAProxy operates in keep-alive mode with regards to persistent
connections: for each connection it processes each request and response, and
leaves the connection idle on both sides between the end of a response and
the start of a new request. This mode may be changed by several options such
as “option http-server-close”, “option forceclose”, “option httpclose” or
“option http-tunnel”.

Option “http-tunnel” disables any HTTP processing past the first request and
the first response. This is the mode which was used by default in versions
1.0 to 1.5-dev21. It is the mode with the lowest processing overhead, which
is normally not needed anymore unless in very specific cases such as when
using an in-house protocol that looks like HTTP but is not compatible, or
just to log one request per client in order to reduce log size. Note that
everything which works at the HTTP level, including header parsing/addition,
cookie processing or content switching will only work for the first request
and will be ignored after the first response.

If this option has been enabled in a “defaults” section, it can be disabled
in a specific instance by prepending the “no” keyword before it.
See also : “option forceclose”, “option http-server-close”, “option httpclose”, “option http-keep-alive”, and “1.1. The HTTP transaction model”.
option http-use-proxy-header
no option http-use-proxy-header
Make use of non-standard Proxy-Connection header instead of Connection
May be used in sections :

defaults    frontend    listen  backend
yes
yes yes
yes yes
yes no
no
Arguments : none
While RFC2616 explicitly states that HTTP/1.1 agents must use the
Connection header to indicate their wish of persistent or non-persistent
connections, both browsers and proxies ignore this header for proxied
connections and make use of the undocumented, non-standard Proxy-Connection
header instead. The issue begins when trying to put a load balancer between
browsers and such proxies, because there will be a difference between what
haproxy understands and what the client and the proxy agree on.

By setting this option in a frontend, haproxy can automatically switch to use
that non-standard header if it sees proxied requests. A proxied request is
defined here as one where the URI begins with neither a ‘/’ nor a ‘*’. The
choice of header only affects requests passing through proxies making use of
one of the “httpclose”, “forceclose” and “http-server-close” options. Note
that this option can only be specified in a frontend and will affect the
request along its whole life.

Also, when this option is set, a request which requires authentication will
automatically switch to use proxy authentication headers if it is itself a
proxied request. That makes it possible to check or enforce authentication in
front of an existing proxy.

This option should normally never be used, except in front of a proxy.
See also : “option httpclose”, “option forceclose” and “option http-server-close”.
option httpchk
option httpchk 
option httpchk  
option httpchk   
Enable HTTP protocol to check on the servers health
May be used in sections :

defaults    frontend    listen  backend
yes
yes no
no  yes
yes yes
yes
Arguments :
  is the optional HTTP method used with the requests. When not set,
          the “OPTIONS” method is used, as it generally requires low server
          processing and is easy to filter out from the logs. Any method
          may be used, though it is not recommended to invent non-standard
          ones.

     is the URI referenced in the HTTP requests. It defaults to ” / ”
          which is accessible by default on almost any server, but may be
          changed to any other URI. Query strings are permitted.

is the optional HTTP version string. It defaults to “HTTP/1.0”
          but some servers might behave incorrectly in HTTP 1.0, so turning
          it to HTTP/1.1 may sometimes help. Note that the Host field is
          mandatory in HTTP/1.1, and as a trick, it is possible to pass it
          after “\r\n” following the version string.
By default, server health checks only consist in trying to establish a TCP
connection. When “option httpchk” is specified, a complete HTTP request is
sent once the TCP connection is established, and responses 2xx and 3xx are
considered valid, while all other ones indicate a server failure, including
the lack of any response.

The port and interval are specified in the server configuration.

This option does not necessarily require an HTTP backend, it also works with
plain TCP backends. This is particularly useful to check simple scripts bound
to some dedicated ports using the inetd daemon.
Examples :

Relay HTTPS traffic to Apache instance and check service availability

using HTTP request “OPTIONS * HTTP/1.1” on port 80.

backend https_relay
    mode tcp
    option httpchk OPTIONS * HTTP/1.1\r\nHost:\ www
    server apache1 192.168.1.1:443 check port 80
See also : “option ssl-hello-chk”, “option smtpchk”, “option mysql-check”, “option pgsql-check”, “http-check” and the “check”, “port” and “inter” server options.
option httpclose
no option httpclose
Enable or disable passive HTTP connection closing
May be used in sections :

defaults    frontend    listen  backend
yes
yes yes
yes yes
yes yes
yes
Arguments : none
By default HAProxy operates in keep-alive mode with regards to persistent
connections: for each connection it processes each request and response, and
leaves the connection idle on both sides between the end of a response and
the start of a new request. This mode may be changed by several options such
as “option http-server-close”, “option forceclose”, “option httpclose” or
“option http-tunnel”.

If “option httpclose” is set, HAProxy will work in HTTP tunnel mode and check
if a “Connection: close” header is already set in each direction, and will
add one if missing. Each end should react to this by actively closing the TCP
connection after each transfer, thus resulting in a switch to the HTTP close
mode. Any “Connection” header different from “close” will also be removed.
Note that this option is deprecated since what it does is very cheap but not
reliable. Using “option http-server-close” or “option forceclose” is strongly
recommended instead.

It seldom happens that some servers incorrectly ignore this header and do not
close the connection even though they reply “Connection: close”. For this
reason, they are not compatible with older HTTP 1.0 browsers. If this happens
it is possible to use the “option forceclose” which actively closes the
request connection once the server responds. Option “forceclose” also
releases the server connection earlier because it does not have to wait for
the client to acknowledge it.

This option may be set both in a frontend and in a backend. It is enabled if
at least one of the frontend or backend holding a connection has it enabled.
It disables and replaces any previous “option http-server-close”,
“option forceclose”, “option http-keep-alive” or “option http-tunnel”. Please
check section 4 (“Proxies”) to see how this option combines with others when
frontend and backend options differ.

If this option has been enabled in a “defaults” section, it can be disabled
in a specific instance by prepending the “no” keyword before it.
See also : “option forceclose”, “option http-server-close” and “1.1. The HTTP transaction model”.
option httplog [ clf ]
Enable logging of HTTP request, session state and timers
May be used in sections :

defaults    frontend    listen  backend
yes
yes yes
yes yes
yes yes
yes
Arguments :
clf       if the “clf” argument is added, then the output format will be
          the CLF format instead of HAProxy’s default HTTP format. You can
          use this when you need to feed HAProxy’s logs through a specific
          log analyser which only support the CLF format and which is not
          extensible.
By default, the log output format is very poor, as it only contains the
source and destination addresses, and the instance name. By specifying
“option httplog”, each log line turns into a much richer format including,
but not limited to, the HTTP request, the connection timers, the session
status, the connections numbers, the captured headers and cookies, the
frontend, backend and server name, and of course the source address and
ports.

This option may be set either in the frontend or the backend.

If this option has been enabled in a “defaults” section, it can be disabled
in a specific instance by prepending the “no” keyword before it. Specifying
only “option httplog” will automatically clear the ‘clf’ mode if it was set
by default.
See also : section 8 about logging.
option http_proxy
no option http_proxy
Enable or disable plain HTTP proxy mode
May be used in sections :

defaults    frontend    listen  backend
yes
yes yes
yes yes
yes yes
yes
Arguments : none
It sometimes happens that people need a pure HTTP proxy which understands
basic proxy requests without caching nor any fancy feature. In this case,
it may be worth setting up an HAProxy instance with the “option http_proxy”
set. In this mode, no server is declared, and the connection is forwarded to
the IP address and port found in the URL after the “http://” scheme.

No host address resolution is performed, so this only works when pure IP
addresses are passed. Since this option’s usage perimeter is rather limited,
it will probably be used only by experts who know they need exactly it. Last,
if the clients are susceptible of sending keep-alive requests, it will be
needed to add “option httpclose” to ensure that all requests will correctly
be analyzed.

If this option has been enabled in a “defaults” section, it can be disabled
in a specific instance by prepending the “no” keyword before it.
Example :

this backend understands HTTP proxy requests and forwards them directly.

backend direct_forward
    option httpclose
    option http_proxy
See also : “option httpclose”
option independent-streams
no option independent-streams
Enable or disable independent timeout processing for both directions
May be used in sections :

defaults    frontend    listen  backend
yes
yes yes
yes yes
yes yes
yes
Arguments : none
By default, when data is sent over a socket, both the write timeout and the
read timeout for that socket are refreshed, because we consider that there is
activity on that socket, and we have no other means of guessing if we should
receive data or not.

While this default behaviour is desirable for almost all applications, there
exists a situation where it is desirable to disable it, and only refresh the
read timeout if there are incoming data. This happens on sessions with large
timeouts and low amounts of exchanged data such as telnet session. If the
server suddenly disappears, the output data accumulates in the system’s
socket buffers, both timeouts are correctly refreshed, and there is no way
to know the server does not receive them, so we don’t timeout. However, when
the underlying protocol always echoes sent data, it would be enough by itself
to detect the issue using the read timeout. Note that this problem does not
happen with more verbose protocols because data won’t accumulate long in the
socket buffers.

When this option is set on the frontend, it will disable read timeout updates
on data sent to the client. There probably is little use of this case. When
the option is set on the backend, it will disable read timeout updates on
data sent to the server. Doing so will typically break large HTTP posts from
slow lines, so use it with caution.

Note: older versions used to call this setting “option independent-streams”
      with a spelling mistake. This spelling is still supported but
      deprecated.
See also : “timeout client”, “timeout server” and “timeout tunnel”
option ldap-check
Use LDAPv3 health checks for server testing
May be used in sections :

defaults    frontend    listen  backend
yes
yes no
no  yes
yes yes
yes
Arguments : none
It is possible to test that the server correctly talks LDAPv3 instead of just
testing that it accepts the TCP connection. When this option is set, an
LDAPv3 anonymous simple bind message is sent to the server, and the response
is analyzed to find an LDAPv3 bind response message.

The server is considered valid only when the LDAP response contains success
resultCode (http://tools.ietf.org/html/rfc4511#section-4.1.9).

Logging of bind requests is server dependent see your documentation how to
configure it.
Example :
option ldap-check
See also : “option httpchk”
option log-health-checks
no option log-health-checks
Enable or disable logging of health checks
May be used in sections :

defaults    frontend    listen  backend
yes
yes no
no  yes
yes yes
yes
Arguments : none
Enable health checks logging so it possible to check for example what
was happening before a server crash. Failed health check are logged if
server is UP and succeeded health checks if server is DOWN, so the amount
of additional information is limited.

If health check logging is enabled no health check status is printed
when servers is set up UP/DOWN/ENABLED/DISABLED.
See also: “log” and section 8 about logging.
option log-separate-errors
no option log-separate-errors
Change log level for non-completely successful connections
May be used in sections :

分享一下我老师大神的人工智能教程。零基础！通俗易懂！风趣幽默！还带黄段子！希望你也加入到我们人工智能的队伍中来！https://blog.csdn.net/jiangjunshow