本文档覆盖了如上版本HAProxy的所有配置命令. 但是不提供任何的提示(hint)、示例(example)或建议.
如果你要获得此类信息，请查看“参考手册”和“架构手册”。
HAProxy的配置过程分为3个主要部分：
- 命令行参数，这是最优先的
- global（全局）段，设置进程级参数
- 代理配置段，通常位于"default", "listen", "fronted", "backend"这样的形式内。
配置文件的语法是由以本手册描述的关键字后跟可选的一个或者多个参数（参数之间空格）
组成。如果字符串中包含空格，必须使用'\'进行转义。\本身需要使用\进行转义。
一些参数值为时间，比如说timeout。时间值通常单位为毫秒(ms)，但是也可以通过加后缀
来使用其他的单位。这是很重要的，因为我并不会在每个关键字中说明这点。支持的单位为：
- 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
1. Global（全局）参数
--------------------
"global" 段的参数是进程级的，通常和操作系统（OS）相关。这些参数一般只设置一次，如果
配置无误，就不需要再次配置进行修改。(译注：也就是说如果设置多个正确的，还是以第一个
为准，后面的无效)。 这些参数其中一些有对应的命令行参数。
global段支持的关键字如下：
* 进程管理和安全
- chroot
- daemon
- gid
- group
- log
- nbproc
- pidfile
- uid
- ulimit-n
- user
- stats
* 性能调优
- maxconn
- noepoll
- nokqueue
- nopoll
- nosepoll
- spread-checks
- tune.maxaccept
- tune.maxpollevents
* 调试
- debug
- quiet
1.1) 进程管理和安全
------------------------------------
chroot <jail dir>
切换运行目录到<jail dir>并且在放弃超级权限前执行chroot()。这会增强HAProxy的安全
级别。仅在HAProxy以超级用户启动时才能使用。要注意的是<jail dir>必须为空并且其他
任何用户不可写。
daemon
使HAProxy进程进入后台运行。这是推荐的运行模式。等同于命令行-D参数。命令行参数
-db则为禁止此选项。
gid <number>
进程运行的组ID。建议将HAProxy的运行gid设置为一个专有的，或者设置为和其他类似进程
一样的gid。 HAProxy必须以属于此组的用户启动，或者使用root来启动。
参考group 和 uid.
group <group name>
和gid类似，不过这里使用/etc/group中对应组名的gid。
参考gid和 uid.
log <address> <facility> [max level]
添加一个全局的syslog服务器。 最多允许定义2个全局服务器。这些服务器将接收HAProxy的
启动和退出日志，如果代理配置里设置了log global，可以接收所有日志。
<address> 可以为:
- 一个IPv4 IP地址后跟一个:和一个UDP端口。如果端口不指定， 默认使用514
(标准的syslog端口)
- 一个到UNIX domain socket文件的路径。注意chroot(此文件在chroot内能访问)
和uid/gid(此文件可写).
<facility> 必须为如下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
还可以设置一个可选的level来过滤发出日志。默认会发出所有日志。如果指定了level，
等于或高于此级别的日志才会发出。 8个级别为：
emerg alert crit err warning notice info debug
nbproc <number>
创建<number>个进程进入deamon模式运行。此参数要求将运行模式设置为"daemon"。
默认只创建一个进程， 这也是推荐的运行模式。 对那些每个进程的文件描述符被限制为
很小值的系统来说， 可能需要开启多个daemon进程。但是使用多个进程将使调试变
得非常艰难，这是非常不鼓励使用的。
参考"daemon"。
pidfile <pidfile>
将所有进程的pid写入文件<pidfile>。 等同于命令行参数"-p"。 启动进程的用户必须
有权限访问此文件。
参考"daemon"
stats socket <path> [{uid | user} <uid>] [{gid | group} <gid>] [mode <mode>]
在<path>下创建流模式的UNIX套接字. 任何已存的套接字会备份后会被替换。连接到
此套接字并输入show stat后会得到一个CSV格式的输出，输出包括进程信息。输入show
info将返回更详细的相关信息。
stats timeout <timeout, in milliseconds>
默认stats套接字的超时时间为10s。可以用此参数修改，单位可以为us,ms,s,m,h,d后缀。
stats maxconn <connections>
默认，stats套接字(socket)仅限10个并发连接。这个值可由此参数修改。
uid <number>
设置进程用户ID为<number>.建议将HAProxy的运行uid设置为一个专有的，或者设置为和
其他类似进程一样的uid。 HAProxy必须以root来启动从而切换到其他用户运行。
参考gid和user.
ulimit-n <number>
设置每个进程的最大文件描述符数。默认的， 此值会自动计算，所以不推荐设置此参数。
user <user name>
和uid类似，不过这里使用/etc/passwd中对应用户名的uid。
参考uid和group.
1.2) 性能调优
-----------------------
maxconn <number>
Sets the maximum per-process number of concurrent connections to <number>. It
is equivalent to the command-line argument "-n". Proxies will stop accepting
connections when this limit is reached. The "ulimit-n" parameter is
automatically adjusted according to this value. See also "ulimit-n".
设置每个进程的最大并发连接数. 等于命令行参数"-n"。 如果达到此值，代理会拒绝接受
新的连接。ulimit-n会根据这个值自动调整。
noepoll
Disables the use of the "epoll" event polling system on Linux. It is
equivalent to the command-line argument "-de". The next polling system
used will generally be "poll". See also "nosepoll", and "nopoll".
在Linux上禁止使用epoll。等于命令行"-de"参数。 下一个会用到的polling系统为
poll。
查看"noepoll"和"nopoll".
nokqueue
Disables the use of the "kqueue" event polling system on BSD. It is
equivalent to the command-line argument "-dk". The next polling system
used will generally be "poll". See also "nopoll".
在BSD上禁止kqueue polling系统。等于命令行"-dk"参数. 下一个会使用的是poll.
查看"nopoll".
nopoll
Disables the use of the "poll" event polling system. It is equivalent to the
command-line argument "-dp". The next polling system used will be "select".
It should never be needed to disable "poll" since it's available on all
platforms supported by HAProxy. See also "nosepoll", and "nopoll" and
"nokqueue".
禁止poll，等于命令行"-dp"。下一个使用的是select。poll在任何能运行HAProxy的机器
上都支持，因此不要禁止poll。
查看"nospoll"和"nopoll"以及"nokquque".
nosepoll
Disables the use of the "speculative epoll" event polling system on Linux. It
is equivalent to the command-line argument "-ds". The next polling system
used will generally be "epoll". See also "nosepoll", and "nopoll".
在Linux上禁止使用speculative epoll系统。等于"-ds". 下一个使用的是epoll.
查看"nospell", "nopoll".
spread-checks <0..50, in percent>
Sometimes it is desirable to avoid sending health checks to servers at exact
intervals, for instance when many logical servers are located on the same
physical server. With the help of this parameter, it becomes possible to add
some randomness in the check interval between 0 and +/- 50%. A value between
2 and 5 seems to show good results. The default value remains at 0.
tune.maxaccept <number>
Sets the maximum number of consecutive accepts that a process may perform on
a single wake up. High values give higher priority to high connection rates,
while lower values give higher priority to already established connections.
This value is unlimited by default in single process mode. However, in
multi-process mode (nbproc > 1), it defaults to 8 so that when one process
wakes up, it does not take all incoming connections for itself and leaves a
part of them to other processes. Setting this value to zero or less disables
the limitation. It should normally not be needed to tweak this value.
tune.maxpollevents <number>
Sets the maximum amount of events that can be processed at once in a call to
the polling system. The default value is adapted to the operating system. It
has been noticed that reducing it below 200 tends to slightly decrease
latency at the expense of network bandwidth, and increasing it above 200
tends to trade latency for slightly increased bandwidth.
1.3) 调试
---------------
debug
启动debug模式，此模式会dump所有的交互信息到stdout，并运行于前台（译注：不进入deamon
模式）。等效于命令行参数-d. 此参数绝不要用于生产环境，因为它会在系统启动时被挂起.
quiet
在启动时不显示任何信息。等于命令行参数-v。
2) 代理(Proxies)
----------
Proxy configuration can be located in a set of sections :
代理相关配置位于下列配置段中：
- defaults <name>
- frontend <name>
- backend <name>
- listen <name>
A "defaults" section sets default parameters for all other sections following
its declaration. Those default parameters are reset by the next "defaults"
section. See below for the list of parameters which can be set in a "defaults"
section. The name is optional but its use is encouraged for better readability.
"defaults"段为其后的所有其他配置段设置默认参数。 "defaults"段可以有多个，后设置的总
是会覆盖之前的配置。 查看下面的列表可以知道"defaults"段可以使用哪些配置参数。"defaults"
关键字是可选的，但是为了更好的可读性，建议加上。
A "frontend" section describes a set of listening sockets accepting client
connections.
"frontend"段描述了一组监听的套接字，它们接受客户端连接。
A "backend" section describes a set of servers to which the proxy will connect
to forward incoming connections.
"backend"段描述了一组服务器，代理(Haproxy)会连接这些服务器并转发客户端请求到这些服
务器上。
A "listen" section defines a complete proxy with its frontend and backend
parts combined in one section. It is generally useful for TCP-only traffic.
"listen"段定义了一个完整的代理，它的前段(frontend)和后端(frontend)都在这个配置
段里。这种配置通常用于仅TCP的流量.
All proxy names must be formed from upper and lower case letters, digits,
'-' (dash), '_' (underscore) , '.' (dot) and ':' (colon). ACL names are
case-sensitive, which means that "www" and "WWW" are two different proxies.
代理名必须由大（小）写字母、数字、'-'、'_'、'.'、':'组成。ACL名字是大小写敏感的，
也即www和WWW分别指不同的代理。
Historically, all proxy names could overlap, it just caused troubles in the
logs. Since the introduction of content switching, it is mandatory that two
proxies with overlapping capabilities (frontend/backend) have different names.
However, it is still permitted that a frontend and a backend share the same
name, as this configuration seems to be commonly encountered.
由于历史原因，所有的代理名字是可以重叠的，这种仅仅会导致日志有些问题。 后来内容交换
（Content Switching）的加入使得两个有重复功能的代理（frontend/backend）必须使用不
同的名字。 然而， 仍然允许frontend和backend使用同一个名字，因为这种配置会经常遇到。
Right now, two major proxy modes are supported : "tcp", also known as layer 4,
and "http", also known as layer 7. In layer 4 mode, HAProxy simply forwards
bidirectionnal traffic between two sides. In layer 7 mode, HAProxy analyzes the
protocol, and can interact with it by allowing, blocking, switching, adding,
modifying, or removing arbitrary contents in requests or responses, based on
arbitrary criteria.
当前，HAProxy支持两种主要的代理模式: "tcp"也即4层，和"http"，即7层。在4层模式下，
HAproxy仅在客户端和服务器之间转发双向流量。7层模式下，HAProxy会分析协议，并且能通过
允许、拒绝、交换、增加、修改或者删除请求(request)或者回应(response)里指定内容来控制
协议，这种操作要基于特定规则。
2.1) Quick reminder about HTTP
------------------------------
When a proxy 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.
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.
2.1.1) The HTTP transaction model
---------------------------------
The HTTP protocol is transaction-driven. This means that each request will lead
to one and only one response. Traditionnally, 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 :
[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.
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 :
[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. HAProxy currently does not support the HTTP keep-alive mode,
but knows how to transform it to the 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 :
[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.
Right now, HAProxy only supports the first mode (HTTP close) if it needs to
process the request. This means that for each request, there will be one TCP
connection. If keep-alive or pipelining are required, HAProxy will still
support them, but will only see the first request and the first response of
each transaction. While this is generally problematic with regards to logs,
content switching or filtering, it most often causes no problem for persistence
with cookie insertion.
2.1.2) HTTP request
-------------------
First, let's consider this HTTP request :
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
2.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.
The URI itself can have several forms :
- A "relative 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.
- An "absolute URI", also called a "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.
- 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.
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.
2.1.2.2) The request 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 2.1.2, lines 4 and 5
define a total of 3 values for the "Accept:" 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).
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.
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.
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.
2.1.3) HTTP response
--------------------
An HTTP response looks very much like an HTTP request. Both are called HTTP
messages. Let's consider this HTTP response :
Line Contents
number
1 HTTP/1.1 200 OK
2 Content-length: 350
3 Content-Type: text/html
2.1.3.1) The Response line
--------------------------
Line 1 is the "response line". It is always composed of 3 fields :
- 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 :
- 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".
2.1.3.2) The response headers
-----------------------------
Response headers work exactly like request headers, and as such, HAProxy uses
the same parsing function for both. Please refer to paragraph 2.1.2.2 for more
details.
2.2) 代理关键字矩阵
----------------------------
The following list of keywords is supported. Most of them may only be used in a
limited set of section types. Some of them are marked as "deprecated" because
they are inherited from an old syntax which may be confusing or functionally
limited, and there are new recommended keywords to replace them. Keywords
listed with [no] can be optionally inverted using the "no" prefix, ex. "no
option contstats". This makes sense when the option has been enabled by default
and must be disabled for a specific instance.
下面是HAProxy目前支持的关键字列表。 大部分只能用于部分配置段。 有一些标注了"deprecate"
是因为它们是从老的语法继承下来的，它们通常容易让人混淆或者功能受限，而且目前都有新的替代
关键字使用。有[no]标注的关键字表明用no作为前缀可以作为此关键字的相反设置，比如"no option
contstats". 比如说一个配置默认是启用的，但是在后面的某个具体的实例中需要关闭，这就非常有用了。
keyword defaults frontend listen backend
----------------------+----------+----------+---------+---------
acl - X X X
appsession - - X X
backlog X X X -
balance X - X X
bind - X X -
block - X X X
capture cookie - X X -
capture request header - X X -
capture response header - X X -
clitimeout X X X - (deprecated)
contimeout X - X X (deprecated)
cookie X - X X
default_backend - X X -
disabled X X X X
dispatch - - X X
enabled X X X X
errorfile X X X X
errorloc X X X X
errorloc302 X X X X
errorloc303 X X X X
fullconn X - X X
grace - X X X
http-check disable-on-404 X - X X
log X X X X
maxconn X X X -
mode X X X X
monitor fail - X X -
monitor-net X X X -
monitor-uri X X X -
[no] option abortonclose X - X X
[no] option allbackups X - X X
[no] option checkcache X - X X
[no] option clitcpka X X X -
[no] option contstats X X X -
[no] option dontlognull X X X -
[no] option forceclose X - X X
option forwardfor X X X X
[no] option http_proxy X X X X
option httpchk X - X X
[no] option httpclose X X X X
option httplog X X X X
[no] option logasap X X X -
[no] option nolinger X X X X
[no] option persist X - X X
[no] option redispatch X - X X
option smtpchk X - X X
[no] option srvtcpka X - X X
option ssl-hello-chk X - X X
option tcpka X X X X
option tcplog X X X X
[no] option tcpsplice X X X X
[no] option transparent X X X -
redisp X - X X (deprecated)
redispatch X - X X (deprecated)
reqadd - X X X
reqallow - X X X
reqdel - X X X
reqdeny - X X X
reqiallow - X X X
reqidel - X X X
reqideny - X X X
reqipass - X X X
reqirep - X X X
reqisetbe - X X X
reqitarpit - X X X
reqpass - X X X
reqrep - X X X
reqsetbe - X X X
reqtarpit - X X X
retries X - X X
rspadd - X X X
rspdel - X X X
rspdeny - X X X
rspidel - X X X
rspideny - X X X
rspirep - X X X
rsprep - X X X
server - - X X
source X - X X
srvtimeout X - X X (deprecated)
stats auth X - X X
stats enable X - X X
stats realm X - X X
stats refresh X - X X
stats scope X - X X
stats uri X - X X
stats hide-version X - X X
timeout check X - X X
timeout client X X X -
timeout clitimeout X X X - (deprecated)
timeout connect X - X X
timeout contimeout X - X X (deprecated)
timeout http-request X X X -
timeout queue X - X X
timeout server X - X X
timeout srvtimeout X - X X (deprecated)
timeout tarpit X X X X
transparent X X X - (deprecated)
use_backend - X X -
----------------------+----------+----------+---------+---------
keyword defaults frontend listen backend
2.2.1) 关键字索引(按字母顺序排序)
-----------------------------------------------
This section provides a description of each keyword and its usage.
本节描述每个关键字及其用法。
acl <aclname> <criterion> [flags] [operator] <value> ...
Declare or complete an access list.
声明或完整一个访问控制列表(ACL).
可用于配置段: defaults | frontend | listen | backend
no | yes | yes | yes
示例:
acl invalid_src src 0.0.0.0/7 224.0.0.0/3
acl invalid_src src_port 0:1023
acl local_dst hdr(host) -i localhost
2.5) HTTP头操作
-----------------------------
在HTTP模式下，可以基于正则表达式来重写、增加或者删除请求或者回应包头，如果一个某特定的
头匹配正则，也可以基于此来拒绝此请求或回应，这样就足以解决大部分简单的基于协议的攻击了，
也可以防止信息从内部网泄露出去。但是这样做却有一个限制： 因为HAproxy的HTTP引擎不支持
keep-alive， 在一个TCP会话中仅仅第一个请求中发送的头信息能被HAProxy看到，所有后续头
仅当做是数据而不会进行分析。而且，HAProxy从来不接触数据内容，它在分析完所有的头后会立即
停止分析。
本节包含了下列在2.2.1中详细描述过的关键字的用法：
- reqadd <string>
- reqallow <search>
- reqiallow <search>
- reqdel <search>
- reqidel <search>
- reqdeny <search>
- reqideny <search>
- reqpass <search>
- reqipass <search>
- reqrep <search> <replace>
- reqirep <search> <replace>
- reqtarpit <search>
- reqitarpit <search>
- rspadd <string>
- rspdel <search>
- rspidel <search>
- rspdeny <search>
- rspideny <search>
- rsprep <search> <replace>
- rspirep <search> <replace>
所有这些关键字都使用相同的约定。<search>参数是一个POSIX扩展的正则表达式(regex)，支持
使用括号()进行分组(括号不需要使用\转义)。空格和其他域(field)分隔符必须使用\开头以避免
和域分隔符混淆。其他字符也可以结合\使用来改变其本身的含义：
\t tab
\r 回车(CR)
\n 换行(LF)
\ 空格(而不是域分隔符)
\# 输出'#'而不当做是注释
\\ 在正则中使用\
\\\\ 在文本中使用\(*2 for regex, *2 for haproxy)
\xXX 就像C语言里一样输出XX的十六进制ASCII码。
The <replace> parameter contains the string to be used to replace the largest
portion of text matching the regex. It can make use of the special characters
above, and can reference a substring which is delimited by parenthesis in the
regex, by writing a backslash ('\') immediately followed by one digit from 0 to
9 indicating the group position (0 designating the entire line). This practice
is very common to users of the "sed" program.
The <string> parameter represents the string which will systematically be added
after the last header line. It can also use special character sequences above.
Notes related to these keywords :
---------------------------------
- these keywords are not always convenient to allow/deny based on header
contents. It is strongly recommended to use ACLs with the "block" keyword
instead, resulting in far more flexible and manageable rules.
- lines are always considered as a whole. It is not possible to reference
a header name only or a value only. This is important because of the way
headers are written (notably the number of spaces after the colon).
- the first line is always considered as a header, which makes it possible to
rewrite or filter HTTP requests URIs or response codes, but in turn makes
it harder to distinguish between headers and request line. The regex prefix
^[^\ \t]*[\ \t] matches any HTTP method followed by a space, and the prefix
^[^ \t:]*: matches any header name followed by a colon.
- for performances reasons, the number of characters added to a request or to
a response is limited at build time to values between 1 and 4 kB. This
should normally be far more than enough for most usages. If it is too short
on occasional usages, it is possible to gain some space by removing some
useless headers before adding new ones.
- keywords beginning with "reqi" and "rspi" are the same as their couterpart
without the 'i' letter except that they ignore case when matching patterns.
- when a request passes through a frontend then a backend, all req* rules
from the frontend will be evaluated, then all req* rules from the backend
will be evaluated. The reverse path is applied to responses.
- req* statements are applied after "block" statements, so that "block" is
always the first one, but before "use_backend" in order to permit rewriting
before switching.
2.6) 日志
------------
[待补充]
2.7) CSV格式
0. pxname: 代理名
1. svname: service name (FRONTEND 指前端, BACKEND指后端,其他名字指服务器)
2. qcur: 当前的请求队列
3. qmax: 最大请求队列
4. scur: 当前会话（session）
5. smax: 最大会话（session）
6. slim: 会话限制
7. stot: 总会话
8. bin: bytes in
9. bout: bytes out
10. dreq: 拒绝的请求
11. dresp: 拒绝的回应（responses）
12. ereq: 请求错误
13. econ: 连接错误
14. eresp: 回应错误
15. wretr: 重试次数（warnings）
16. wredis: redispatches (warning)
17. status: 状态s (UP/DOWN/...)
18. weight: 服务器权重(server), 总权重(backend)
19. act: 服务器为主（active）(server), 主服务器个数(backend)
20. bck: 服务器为备（backup） (server),被服务器个数(backend)
21. chkfail: 失败的检查次数
22. chkdown: 从UP->DOWN 切换的次数
23. lastchg: 最后状态改变时间(seconds)
24. downtime: 总的宕机时间(秒)
25. qlimit: 队列限制
26. pid: 进程id (0 第一个实例, 1 为第二个, ...)
27. iid: 唯一代理id
28. sid: service id (unique inside a proxy)
29. throttle: warm up status
30. lbtot: 服务器被选择的总次数
31. tracked: id of proxy/server if tracking is enabled
32. type (0=frontend, 1=backend, 2=server)
2.8) Unix套接字命令(Unix Socket commands)
- "show stat [<iid> <type> <sid>]": 以csv格式导出状态信息。通过传入id，type和sid可以
导出指定项:
- iid为proxy id, -1导出所有
- type 选择可导出对象类型: 1 为 frontend, 2 指 backend, 4 指
server, -1 为所有. 这些指可以是OR（bit运算），如:
1+2=3 -> frontend+backend.
1+2+4=7 -> frontend+backend+server.
- sid 为service id, -1 从选定的proxy导出所有service.
- "show info": 导出当前haproxy的状态信息。