本文档涵盖了上述版本中实现的配置语言。它不提供任何提示、示例或建议。有关此类文档，请参阅参考手册或架构手册。下面的摘要旨在帮助您按名称搜索章节并浏览文档。文档贡献者须知：本文档每行格式为80个字符，缩进为偶数个空格，不使用制表符。请严格遵守这些规则，以便在任何地方都能轻松打印。如果一行需要逐字打印且不适合，请在每行的末尾添加反斜杠（'\'），然后在下一行继续，缩进两个字符。有时，在所有输出行（日志、控制台输出）前面加上三个闭合的尖括号（'>>>'）也很有用，以便在输入和输出可能变得模糊时帮助区分它们。如果您添加章节，请更新下面的摘要以便于搜索。

当haproxy以HTTP模式运行时，请求和响应都会被完全分析和索引，因此可以对内容中几乎所有找到的内容构建匹配条件。但是，理解HTTP请求和响应是如何形成的，以及HAProxy是如何分解它们的，这一点很重要。这样，编写正确的规则和调试现有配置就会更容易。

HTTP协议是事务驱动的。这意味着每个请求将导向一个且仅一个响应。传统上，客户端与服务器之间会建立一个TCP连接，客户端在该连接上发送一个请求，服务器响应后连接关闭。新的请求将涉及新的连接：[CON1] [REQ1] ... [RESP1] [CLO1] [CON2] [REQ2] ... [RESP2] [CLO2] ... 在这种称为“HTTP关闭”模式下，建立连接的数量与HTTP事务的数量相同。由于响应后服务器会关闭连接，客户端不需要知道内容长度。由于协议的事务性，可以对其进行改进，以避免在两个连续事务之间关闭连接。然而，在这种模式下，服务器必须为每个响应指示内容长度，以便客户端不会无限期等待。为此，使用一个特殊的头部：“Content-length”。这种模式称为“keep-alive”（保持连接）模式：[CON] [REQ1] ... [RESP1] [REQ2] ... [RESP2] [CLO] ... 它的优点是事务之间的延迟降低，并且服务器端的处理能力要求更少。它通常比关闭模式更好，但并非总是如此，因为客户端通常会限制其并发连接的数量到一个较小的值。通信中的最后一个改进是流水线模式。它仍然使用keep-alive，但客户端在发送第二个请求之前不需要等待第一个响应。这对于获取构成页面所需的大量图像非常有用：[CON] [REQ1] [REQ2] ... [RESP1] [RESP2] [CLO] ... 这显然可以极大地提高性能，因为后续请求之间的网络延迟被消除了。许多HTTP代理程序不能正确支持流水线，因为HTTP中没有办法将响应与相应的请求关联起来。因此，服务器必须按照接收请求的顺序完全相同的顺序进行回复。默认情况下，HAProxy在持久连接方面以keep-alive模式运行：对于每个连接，它会处理每个请求和响应，并在响应结束和新请求开始之间将连接保持空闲状态。HAProxy支持5种连接模式：- keep alive（保持连接）：处理所有请求和响应（默认）。- tunnel（隧道）：只处理第一个请求和响应，其他所有内容都会被转发而无需分析。- passive close（被动关闭）：隧道模式，并在两个方向上添加“Connection: close”头部。- server close（服务器关闭）：服务器端连接在响应后关闭。- forced close（强制关闭）：连接在响应结束后被主动关闭。

首先，让我们考虑这个 HTTP 请求： 行号 内容 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行是“请求行”。它总是由3个字段组成：- 方法：GET- URI：/serv/login.php?lang=en&profile=2- 版本标签：HTTP/1.1它们都由标准称为LWS（线性空白字符）分隔，通常是空格，但也可以是制表符或换行符/回车符后跟空格/制表符。方法本身不能包含任何冒号（':'），且仅限于字母。所有这些各种组合使得HAProxy执行分割本身比让用户编写复杂或不准确的正则表达式更可取。URI本身有几种形式：- “相对URI”：/serv/login.php?lang=en&profile=2这是一个不包含主机部分的完整URL。这通常是服务器、反向代理和透明代理接收到的。- “绝对URI”，也称为“URL”：http://192.168.0.12:8080/serv/login.php?lang=en&profile=2它由“协议”（协议名称后跟'://'）、主机名或地址、可选的冒号（':'）后跟端口号，然后是以地址部分后的第一个斜杠（'/'）开头的相对URI组成。这通常是代理接收到的，但支持HTTP/1.1的服务器也必须接受这种形式。- 星号（'*'）：这种形式仅与OPTIONS方法一起接受，且不可中继。它用于查询下一跳的能力。- 地址:端口组合：192.168.0.12:80这与CONNECT方法一起使用，该方法用于通过HTTP代理建立TCP隧道，通常用于HTTPS，但有时也用于其他协议。在相对URI中，识别出两个子部分。问号之前的部分称为“路径”。它通常是服务器上静态对象的相对路径。问号之后的部分称为“查询字符串”。它主要与发送到动态脚本的GET请求一起使用，并且非常特定于所使用的语言、框架或应用程序。

头部从第二行开始。它们由行开头的名称组成，后面紧跟着一个冒号（':'）。传统上，冒号后面会添加一个LWS，但这不是必需的。然后是值。多个相同的头部可以折叠成一个单行，用逗号分隔值，前提是保持它们的顺序。这在“Cookie:”字段中很常见。如果后续行以LWS开头，一个头部可以跨越多行。在1.2的示例中，第4行和第5行定义了“Accept:”头部总共3个值。与普遍的误解相反，头部名称不区分大小写，如果它们指向其他头部名称（如“Connection:”头部），它们的值也不区分大小写。头部的结束由第一个空行指示。人们常说这是双换行符，这并不准确，尽管双换行符是空行的一种有效形式。幸运的是，HAProxy在索引头部、检查值和计数时会处理所有这些复杂的组合，因此没有理由担心它们的写法，但不要因为应用程序执行不寻常但有效的事情而指责它存在bug。重要提示：如RFC7231所建议，HAProxy通过将头部中间的换行符替换为LWS来规范化头部，以合并多行头部。这对于正确的分析至关重要，并有助于能力较弱的HTTP解析器正确工作，不被这种复杂的构造所欺骗。

HTTP响应看起来与HTTP请求非常相似。两者都称为HTTP消息。让我们看看这个HTTP响应：行内容编号1 HTTP/1.1 200 OK 2 Content-length: 350 3 Content-Type: text/html 特殊情况下，HTTP支持所谓的“信息性响应”，状态码为1xx。这些消息很特殊，因为它们不携带响应的任何部分，它们只是作为一种信号消息，要求客户端继续发送其请求。对于100状态码的响应，请求的信息将由下一个非100响应消息携带。这意味着可能发送多个响应给单个请求，并且这只在启用keep-alive时才有效（1xx消息仅限HTTP/1.1）。HAProxy处理这些消息，并且能够正确转发和跳过它们，只处理下一个非100响应。因此，除非明确说明，否则这些消息既不会被记录也不会被转换。状态码101表示协议在同一连接上正在改变，并且haproxy必须切换到隧道模式，就像发生CONNECT一样。然后Upgrade头部将包含关于连接正在切换到的协议类型的附加信息。

第1行是“响应行”。它总是由3个字段组成：- 版本标签：HTTP/1.1- 状态码：200- 原因：OK状态码始终是3位数字。第一位数字表示一般状态：- 1xx = 信息性消息，应跳过（例如：100、101）- 2xx = OK，内容即将到来（例如：200、206）- 3xx = OK，没有内容（例如：302、304）- 4xx = 客户端错误（例如：401、403、404）- 5xx = 服务器错误（例如：500、502、503）有关所有这些代码的详细含义，请参阅RFC7231。“原因”字段只是一个提示，但客户端不会解析它。可以在这里找到任何内容，但通常会遵循公认的消息。它可以由一个或多个单词组成，例如“OK”、“Found”或“Authentication Required”。Haproxy自身可能会发出以下状态码：代码何时/原因 200 访问统计页面，以及回复监控请求时 301 执行重定向时，取决于配置的代码 302 执行重定向时，取决于配置的代码 303 执行重定向时，取决于配置的代码 307 执行重定向时，取决于配置的代码 308 执行重定向时，取决于配置的代码 400 对于无效或过大的请求 401 执行操作时需要身份验证时（访问统计页面时） 403 请求被“block”ACL或“reqdeny”过滤器阻止时 408 请求超时在请求完成前触发 500 当haproxy遇到无法恢复的内部错误时，例如内存分配失败，这不应发生 502 服务器返回空、无效或不完整的响应，或当“rspdeny”过滤器阻止响应时。 503 没有可用服务器处理请求时，或响应匹配“monitor fail”条件的监控请求时 504 响应超时在服务器响应前触发上面的4xx和5xx错误代码可以自定义（参见第4.2节中的“errorloc”）。

响应头的处理方式与请求头完全相同，因此 HAProxy 对两者使用相同的解析函数。更多详情请参考 1.2.2 段。

HAProxy 的配置过程涉及 3 个主要的参数来源： - 命令行参数，它们总是优先 - “global”部分，设置进程范围的参数 - 代理部分，可以采用“defaults”、“listen”、“frontend”和“backend”的形式。配置文件语法由以本手册中引用的关键字开头的行组成，后面可以选择性地跟一个或多个由空格分隔的参数。

HAProxy的配置引入了一个类似于许多编程语言的引用和转义系统。配置文件支持3种类型：反斜杠转义、双引号弱引用和单引号强引用。如果字符串中必须包含空格，则必须用反斜杠（'\'）进行转义，或用引号括起来。反斜杠也必须通过加倍或强引用来转义。转义是通过在特殊字符前加上反斜杠（'\'）来实现的：\ 用来标记空格并将其与分隔符区分开\# 用来标记哈希并将其与注释区分开\\ 用来使用反斜杠\' 用来使用单引号并将其与强引用区分开\" 用来使用双引号并将其与弱引用区分开弱引用通过使用双引号（"”）实现。弱引用可防止解释：空格作为参数分隔符' 单引号作为强引用分隔符# 哈希作为注释起始符弱引用允许解释变量，如果您想在双引号字符串中使用未解释的美元符号，您应该用反斜杠（"\$"）转义它，这在弱引用之外不起作用。转义和特殊字符的解释不受弱引用的阻止。强引用通过使用单引号（'）实现。在单引号内，什么都不会被解释，这是引用正则表达式的有效方法。被引用和转义的字符串在内存中被替换为其解释后的等价物，这允许您执行连接。

# 以下是等价的： log-format %{+Q}o\ %t\ %s\ %{-Q}r log-format "%{+Q}o %t %s %{-Q}r" log-format '%{+Q}o %t %s %{-Q}r' log-format "%{+Q}o %t"' %s %{-Q}r' log-format "%{+Q}o %t"' %s'\ %{-Q}r # 以下是等价的： reqrep "^([^\ :]*)\ /static/(.*)" \1\ /\2 reqrep "^([^ :]*)\ /static/(.*)" '\1 /\2' reqrep "^([^ :]*)\ /static/(.*)" "\1 /\2" reqrep "^([^ :]*)\ /static/(.*)" "\1\ /\2"

HAProxy 的配置支持环境变量。这些变量仅在双引号内被解释。变量在配置解析期间展开。变量名前必须加上美元符号（"$"），并可选地用大括号（"{}"）括起来，类似于 Bourne shell 中的做法。变量名可以包含字母数字字符或下划线（"_"），但不应以数字开头。

bind "fd@${FD_APP1}" log "${LOCAL_SYSLOG}:514" local0 notice # 发送到本地服务器 user "$HAPROXY_USER"

一些参数涉及表示时间的值，例如超时。这些值通常以毫秒表示（除非另有明确说明），但也可以通过在数值后附加单位来以任何其他单位表示。考虑这一点很重要，因为每个关键字都不会重复说明。支持的单位有：- us：微秒。1 微秒 = 1/1000000 秒 - ms：毫秒。1 毫秒 = 1/1000 秒。这是默认单位。 - s：秒。1s = 1000ms - m：分钟。1m = 60s = 60000ms - h：小时。1h = 60m = 3600s = 3600000ms - d：天。1d = 24h = 1440m = 86400s = 86400000ms

# 一个简单的 HTTP 代理配置，在所有接口的 80 端口上监听，# 并将请求转发到名为 "servers" 的单个后端，该后端有一个名为 "server1" 的服务器，# 监听于 127.0.0.1:8000 global daemon maxconn 256 defaults mode http timeout connect 5000ms timeout client 50000ms timeout server 50000ms frontend http-in bind *:80 default_backend servers backend servers server server1 127.0.0.1:8000 maxconn 32 # 使用单个 listen 块定义的相同配置。更短但表达力较差，尤其是在 HTTP 模式下。 global daemon maxconn 256 defaults mode http timeout connect 5000ms timeout client 50000ms timeout server 50000ms listen http-in bind *:80 server server1 127.0.0.1:8000 maxconn 32 假设 haproxy 在 $PATH 中，请在 shell 中使用以下命令测试这些配置：$ sudo haproxy -f configuration.conf -c

“global”部分中的参数是全局进程通用的，通常是操作系统特定的。它们通常只需设置一次即可满足所有需求，并且一旦设置正确就不需要更改。其中一些参数有命令行等效项。 “global”部分支持以下关键字：* 进程管理和安全 - ca-base - chroot - crt-base - cpu-map - daemon - description - deviceatlas-json-file - deviceatlas-log-level - deviceatlas-separator - deviceatlas-properties-cookie - external-check - gid - group - hard-stop-after - log - log-tag - log-send-hostname - lua-load - nbproc - node - pidfile - presetenv - resetenv - uid - ulimit-n - user - setenv - stats - ssl-default-bind-ciphers - ssl-default-bind-options - ssl-default-server-ciphers - ssl-default-server-options - ssl-dh-param-file - ssl-server-verify - unix-bind - unsetenv - 51degrees-data-file - 51degrees-property-name-list - 51degrees-property-separator - 51degrees-cache-size - wurfl-data-file - wurfl-information-list - wurfl-information-list-separator - wurfl-engine-mode - wurfl-cache-size - wurfl-useragent-priority * 性能调优 - max-spread-checks - maxconn - maxconnrate - maxcomprate - maxcompcpuusage - maxpipes - maxsessrate - maxsslconn - maxsslrate - maxzlibmem - noepoll - nokqueue - nopoll - nosplice - nogetaddrinfo - noreuseport - spread-checks - server-state-base - server-state-file - tune.buffers.limit - tune.buffers.reserve - tune.bufsize - tune.chksize - tune.comp.maxlevel - tune.http.cookielen - tune.http.maxhdr - tune.idletimer - tune.lua.forced-yield - tune.lua.maxmem - tune.lua.session-timeout - tune.lua.task-timeout - tune.lua.service-timeout - tune.maxaccept - tune.maxpollevents - tune.maxrewrite - tune.pattern.cache-size - tune.pipesize - tune.rcvbuf.client - tune.rcvbuf.server - tune.recv_enough - tune.sndbuf.client - tune.sndbuf.server - tune.ssl.cachesize - tune.ssl.lifetime - tune.ssl.force-private-cache - tune.ssl.maxrecord - tune.ssl.default-dh-param - tune.ssl.ssl-ctx-cache-size - tune.vars.global-max-size - tune.vars.proc-max-size - tune.vars.reqres-max-size - tune.vars.sess-max-size - tune.vars.txn-max-size - tune.zlib.memlevel - tune.zlib.windowsize * 调试 - debug - quiet

当与“ca-file
此关键字在以下部分可用：
Bind options
Server and default-server options”或“crl-file
此关键字在以下部分可用：
Bind options
Server and default-server options”指令使用相对路径时，分配一个默认目录来从此目录获取 SSL CA 证书和 CRL。在“ca-file
此关键字在以下部分可用：
Bind options
Server and default-server options”和“crl-file
此关键字在以下部分可用：
Bind options
Server and default-server options”指令中指定的绝对位置将优先于并忽略“ca-base”。

更改当前目录到 ，然后在此处执行 chroot()，之后降低权限。这提高了安全性，以防万一出现未知的漏洞被利用，因为它会让攻击者非常难以利用系统。仅当进程以超级用户权限启动时，此功能才有效。务必确保  是空的且任何人都可以写入。

在 Linux 2.6 及更高版本中，可以将进程绑定到特定的 CPU 集合。这意味着该进程将永远不会在其他 CPU 上运行。“cpu-map”指令为进程集指定 CPU 集合。第一个参数是要绑定的进程号。此进程的编号必须介于 1 到 32（或 64，取决于机器的字长）之间，任何大于 nbproc 的进程 ID 都将被忽略。可以使用“all”一次性指定所有进程，“odd”指定奇数编号，“even”指定偶数编号，这与“bind-process”指令类似。第二个及后续参数是 CPU 集合。每个 CPU 集合可以是 0 到 31（或 63）之间的唯一编号，也可以是用连字符（'-'）分隔的两个此类编号的范围。可以指定多个 CPU 编号或范围，并且进程将被允许绑定到所有这些 CPU。显然，可以指定多个“cpu-map”指令。每个“cpu-map”指令在重叠时将替换之前的指令。

当使用 "crtfile" 指令的相对路径时，分配一个用于获取 SSL 证书的默认目录。"crtfile" 后面指定的绝对位置优先，并忽略 "crt-base"。

使进程分叉到后台运行。这是推荐的操作模式。它等效于命令行“-D”参数。可以使用命令行“-db”参数禁用它。

设置 API 加载的 DeviceAtlas JSON 数据文件的路径。路径必须是有效的 JSON 数据文件，并且 HAProxy 进程可以访问。

设置 API 返回的信息级别。此指令是可选的，如果未设置，则默认为 0。

设置 API 属性结果的字符分隔符。此指令是可选的，如果未设置，则默认为 |。

设置用于检测请求期间是否使用了 DeviceAtlas 客户端组件的客户端 cookie 名称。此指令是可选的，如果未设置，则默认为 DAPROPS。

允许使用外部代理执行健康检查。作为安全预防措施，此功能默认禁用。请参阅 "option external-check"。

将进程的组 ID 更改为 <number>。建议将组 ID 分配给 HAProxy 或一小组类似守护进程。HAProxy 必须以属于该组的用户或超级用户权限启动。请注意，如果 HAProxy 是由具有补充组的用户启动的，它只能在以超级用户权限启动时删除这些组。另请参阅“group
此关键字在以下部分可用：
Process management and security
Userlists
Bind options”和“uid
此关键字在以下部分可用：
Process management and security
Bind options”。

定义执行干净的软停止所允许的最长时间。

<time> 是实例在通过 SIGUSR1 信号接收到软停止时将保持活动的最长时间（默认为毫秒）。

这可用于确保即使在软停止期间连接保持打开（例如，在 tcp 模式下为代理设置了长超时），实例也会退出。它适用于 TCP 和 HTTP 模式。

global hard-stop-after 30s

类似于“gid
此关键字在以下部分可用：
Process management and security
Bind options”，但使用 /etc/group 中的组名 <group name> 的 GID。另请参阅“gid
此关键字在以下部分可用：
Process management and security
Bind options”和“user
此关键字在以下部分可用：
Process management and security
Userlists
Bind options”。

添加一个全局 syslog 服务器。可以定义多个全局服务器。它们将接收启动和退出的日志，以及通过“log global”配置的所有代理的日志。
可以是以下之一：- IPv4 地址，后跟可选的冒号和 UDP 端口。如果未指定端口，则默认使用 514（标准 syslog 端口）。- IPv6 地址，后跟冒号和可选的 UDP 端口。如果未指定端口，则默认使用 514（标准 syslog 端口）。- 到 UNIX 域套接字的本地文件系统路径，同时请注意 chroot 的注意事项（确保路径在 chroot 内可访问）以及 uid/gid（确保路径具有适当的写入权限）。您可能希望在地址参数中引用某些环境变量，有关环境变量的信息，请参阅 第 2.3 节。是可选的最大行长度。大于此值的日志行将在发送前被截断。原因是 syslog 服务器在日志行长度上的行为不同。所有服务器都支持 1024 的默认值，但一些服务器会简单地丢弃较长的行，而另一些则会记录它们。如果服务器支持长行，则在此处设置此值可能很有意义，以避免截断长行。同样，如果服务器丢弃长行，最好在发送之前截断它们。接受的值为 80 到 65535（含）。1024 的默认值通常适用于所有标准用法。某些特定情况下的长捕获或 JSON 格式日志可能需要更大的值。是生成 syslog 消息时使用的日志格式。它可以是以下之一：rfc3164 RFC3164 syslog 消息格式。这是默认值。（https://tools.ietf.org/html/rfc3164）rfc5424 RFC5424 syslog 消息格式。（https://tools.ietf.org/html/rfc5424）<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 可以指定一个可选级别来过滤传出的消息。默认情况下，所有消息都会发送。如果指定了最大级别，则只会发送严重性至少为此级别或更高的消息。可以指定一个可选的最小级别。如果设置了此级别，则会将其限制到此级别，以避免在某些默认 syslog 配置上将“emerg”消息发送到所有终端。已知有八个级别：emerg alert crit err warning notice info debug

设置 syslog 报头中的 hostname 字段。如果设置了可选的 "string" 参数，则报头将设置为该字符串内容，否则使用系统的主机名。通常在不通过中间 syslog 服务器中继日志或仅为自定义日志中打印的主机名时使用。

将 syslog 报头中的 tag 字段设置为此字符串。它默认为从命令行启动的程序名，通常是 "haproxy"。有时，区分同一主机上运行的多个进程会很有用。另请参阅每个代理的 "log-tag
This keyword is available in sections :
Process management and security
Alphabetically sorted keywords reference" 指令。

此全局指令加载并执行一个 Lua 文件。此指令可以多次使用。

进入 daemon 模式时创建 <number> 个进程。这需要“daemon”模式。默认情况下，只创建一个进程，这是推荐的操作模式。对于每个进程文件描述符数量有限的系统，可能需要分叉多个守护进程。使用多个进程更难调试，并且非常不推荐。另请参阅“daemon”。

将所有守护进程的 pid 写入文件 <pidfile>。此选项等效于“-p”命令行参数。文件必须是启动进程的用户可访问的。另请参阅“daemon”。

将环境变量 <name> 设置为值 <value>。如果该变量已存在，则不会被覆盖。更改会立即生效，以便配置文件中的下一行可以看到新值。另请参阅 "setenv"、"resetenv" 和 "unsetenv"。

删除除参数中指定的环境变量之外的所有环境变量。它允许在使用 setenv 或 unsetenv 设置新值之前，使用一个干净受控的环境。请注意，一些内部函数可能会使用某些环境变量，例如时间操作函数，以及 OpenSSL 甚至外部检查。此命令必须极其小心使用，并且只能在完全验证后使用。更改会立即生效，因此配置文件中的下一行将看到新的环境。另请参阅 “setenv”、“presetenv” 和 “unsetenv”。

将统计套接字限制在特定的进程号集。默认情况下，统计套接字绑定到所有进程，当 nbproc 大于 1 时会发出警告，因为在连接时无法选择目标进程。但是，通过使用此设置，可以使统计套接字固定到特定的进程集，通常是第一个进程。使用此设置后，无论使用多少进程，警告都会自动禁用。最大进程 ID 取决于机器的字长（32 或 64）。一个更好的选项是使用“stats socket”行中的“process”设置来强制每行上的进程。

指定目录前缀，该前缀将附加在所有不以“/”开头的服务器状态文件名前面。另请参阅 "server-state-file"、"load-server-state-from-file" 和 "server-state-file-name"。

指定包含服务器状态的文件路径。如果路径以斜杠（'/'）开头，则视为绝对路径，否则视为相对于使用 "server-state-base" 指定的目录（如果已设置）或当前目录。在重新加载 HAProxy 之前，可以使用统计命令 "show servers state" 保存服务器的当前状态。该命令的输出必须写入 <file> 指向的文件中。启动时，在处理流量之前，HAProxy 将读取、加载并应用文件中找到且在其当前运行配置中可用的每个服务器的状态。另请参阅 "server-state-base" 和 "show servers state"、"load-server-state-from-file" 和 "server-state-file-name"。

将环境变量 <name> 设置为值 <value>。如果该变量存在，则会被覆盖。更改会立即生效，因此配置文件中的下一行将看到新的值。另请参阅 “presetenv”、“resetenv” 和 “unsetenv”。

此设置仅在内置 OpenSSL 支持时可用。它设置了在 SSL/TLS 握手期间协商的密码算法（“密码套件”）的默认字符串，适用于所有未显式定义自己的“bind”行。字符串的格式在 OpenSSL man 页的“man 1 ciphers”中定义，例如可以是“AES:ALL:!aNULL:!eNULL:+RC4:@STRENGTH”（不带引号）这样的字符串。请参阅“bind”关键字以获取更多信息。

此设置仅在编译时支持 OpenSSL 时可用。它为所有 "bind" 行设置强制使用的默认 ssl-options。请查看 "bind" 关键字以了解可用选项。

global ssl-default-bind-options no-sslv3 no-tls-tickets

此设置仅在内置 OpenSSL 支持时可用。它设置了在与服务器的 SSL/TLS 握手中协商的密码算法的默认字符串，适用于所有未显式定义自己的“server”行。字符串的格式在“man 1 ciphers”中定义。请参阅“server”关键字以获取更多信息。

此设置仅在编译时支持 OpenSSL 时可用。它为所有 "server" 行设置强制使用的默认 ssl-options。请查看 "server" 关键字以了解可用选项。

此设置仅在内置 OpenSSL 支持时可用。它设置了在使用临时 Diffie-Hellman (DHE) 密钥交换期间用于 SSL/TLS 握算的默认 DH 参数，适用于所有未显式定义自己的“bind”行。如果绑定证书文件中存在自定义 DH 参数，则将被覆盖。如果未使用 ssl-dh-param-file 或直接在证书文件中设置自定义 DH 参数，则将使用 tune.ssl.default-dh-param 指定大小的预生成 DH 参数。自定义参数被认为更安全，因此建议使用它们。可以使用 OpenSSL 命令“openssl dhparam <size>”生成自定义 DH 参数，其中 size 至少应为 2048，因为 1024 位 DH 参数不应再被认为安全。

服务器端 SSL 验证的默认行为。如果指定为 'none'，则不验证服务器证书。默认值为 'required'，除非使用命令行选项 '-dV' 强制指定。

将UNIX套接字绑定到<path>，或将TCPv4/v6地址绑定到<address:port>。连接到此套接字将返回各种统计信息输出，甚至允许发出一些命令来更改某些运行时设置。请参阅管理指南的第9.3节“Unix Socket命令”以获取更多详细信息。支持"bind"行的所有参数，例如限制对某些用户或其访问权限的访问。有关更多信息，请参阅第5.1节。

统计套接字的默认超时时间设置为 10 秒。可以使用 "stats timeout" 更改此值。该值必须以毫秒为单位传递，或者带有时间单位后缀，如 { us, ms, s, m, h, d }。

默认情况下，统计套接字限制为 10 个并发连接。可以使用 "stats maxconn" 更改此值。

将进程的用户 ID 更改为 <number>。建议用户 ID 专供 HAProxy 或一小组类似的守护进程使用。HAProxy 必须以超级用户权限启动才能切换到其他用户。另请参阅“gid
此关键字在以下部分可用：
进程管理和安全
绑定选项”和“user
此关键字在以下部分可用：
进程管理和安全
用户列表
绑定选项”。

将每个进程的最大文件描述符数设置为 <number>。默认情况下，它是自动计算的，因此建议不要使用此选项。

为在 "bind" 语句中声明的 UNIX 侦听套接字设置通用配置。这主要用于简化这些 UNIX 套接字的声明并减少错误风险，因为这些设置通常是必需的，但也是特定于进程的。<prefix> 设置可用于强制所有套接字路径相对于该目录。这可能需要访问另一个组件的 chroot。请注意，这些路径在 haproxy chroot 自身之前解析，因此它们是绝对路径。<mode>、<user>、<uid>、<group> 和 <gid> 的含义与 "bind" 语句使用的同名参数相同。如果两者都指定，则 "bind" 语句具有更高的优先级，这意味着 "unix-bind" 设置可被视为进程范围的默认设置。

删除参数中指定的环境变量。这对于隐藏某些操作期间偶尔从用户环境中继承的一些敏感信息很有用。不存在的变量会被静默忽略，因此操作后可以确定这些变量都不再存在。更改会立即生效，因此配置文件中的下一行将看不到这些变量。另请参阅 “setenv”、“presetenv” 和 “resetenv”。

类似于“uid
此关键字在以下部分可用：
进程管理和安全
绑定选项”，但使用 /etc/passwd 中用户名为 <user name> 的用户的 UID。另请参阅“uid
此关键字在以下部分可用：
进程管理和安全
绑定选项”和“group
此关键字在以下部分可用：
进程管理和安全
用户列表
绑定选项”。

只允许字母、数字、连字符和下划线，与 DNS 名称类似。此语句在 HA 配置中很有用，其中两个或多个进程或服务器共享相同的 IP 地址。通过在所有节点上设置不同的节点名称，可以轻松地立即发现哪个服务器正在处理流量。

添加描述实例的文本。请注意，需要转义某些字符（例如 #），并且此文本将插入 HTML 页面中，因此您应避免使用“<”和“>”字符。

提供设备检测服务的 51Degrees 数据文件的路径。该文件应解压缩，并且 HAProxy 具有相应的权限才能访问。请注意，此选项仅在 HAProxy 已使用 USE_51DEGREES 编译时可用。

要从数据集中加载的 51Degrees 属性名称列表。完整的名称列表可在 51Degrees 网站上找到：https://51degrees.com/resources/property-dictionary 请注意，此选项仅在 haproxy 编译时启用了 USE_51DEGREES 时可用。

一个字符，将附加到包含 51Degrees 结果的响应头中的每个属性值之后。如果未设置，则默认为“,”。请注意，此选项仅在 haproxy 编译时启用了 USE_51DEGREES 时可用。

将 51Degrees 转换器缓存的大小设置为 <number> 个条目。这是一个 LRU 缓存，用于记住以前的设备检测及其结果。默认情况下，此缓存是禁用的。请注意，此选项仅在 haproxy 编译时启用了 USE_51DEGREES 时可用。

提供设备检测服务的 WURFL 数据文件路径。该文件应由 HAProxy 访问，并具有相关权限。请注意，只有当 haproxy 使用 USE_WURFL=1 编译时，此选项才可用。

WURFL 功能、虚拟功能、我们计划在注入的标头中使用的属性名称的空格分隔列表。功能和虚拟功能的完整名称列表可在 Scientiamobile 网站上找到：https://www.scientiamobile.com/wurflCapability 有效的 WURFL 属性包括： - wurfl_id 包含匹配设备的设备 ID。 - wurfl_root_id 包含匹配设备的设备根 ID。 - wurfl_isdevroot 指示匹配的设备是否为根设备。可能的值为“TRUE”或“FALSE”。 - wurfl_useragent 此特定 Web 请求附带的原始用户代理。 - wurfl_api_version 包含表示当前使用的 Libwurfl API 版本的字符串。 - wurfl_engine_target 包含表示当前设置的 WURFL 引擎目标的字符串。可能的值为“HIGH_ACCURACY”、“HIGH_PERFORMANCE”、“INVALID”。 - wurfl_info 包含有关解析的 wurfl.xml 及其完整路径的信息的字符串。 - wurfl_last_load_time 包含 WURFL 最后成功加载的 UNIX 时间戳。 - wurfl_normalized_useragent 规范化的用户代理。 - wurfl_useragent_priority WURFL 使用的用户代理优先级。请注意，此选项仅在 HAProxy 已使用 USE_WURFL=1 编译时可用。

用于分隔包含 WURFL 结果的响应标头中值的字符。如果未设置，则默认使用逗号 (',')。请注意，只有当 haproxy 使用 USE_WURFL=1 编译时，此选项才可用。

WURFL 补丁文件路径列表。请注意，补丁是在启动时加载的，因此在 chroot 之前加载。请注意，只有当 haproxy 使用 USE_WURFL=1 编译时，此选项才可用。

设置WURFL引擎目标。您可以选择“accuracy”或“performance”目标。在performance模式下，桌面Web浏览器检测是按编程方式完成的，无需引用WURFL数据。因此，大多数桌面Web浏览器将以generic_web_browser WURFL ID返回以获得性能。如果performance或accuracy未定义，则默认启用performance模式。请注意，此选项仅在haproxy使用USE_WURFL=1编译时可用。

设置WURFL缓存策略。其中<U>是Useragent缓存大小，<D>是内部设备缓存大小。这里有三种可能性：-“0”：不使用缓存。-<U>：使用单个LRU缓存，大小以元素表示。-<U>,<D>：使用双重LRU缓存，两个大小都以元素表示。这是性能最高的选项。请注意，此选项仅在haproxy使用USE_WURFL=1编译时可用。

告知WURFL是否应优先使用纯用户代理（'plain'）而不是默认的sideloaded浏览器用户代理（'sideloaded_browser'）。请注意，此选项仅在haproxy使用USE_WURFL=1编译时可用。

默认情况下，haproxy 会尝试将健康检查的开始时间分散到服务器场中所有服务器的最小健康检查间隔内。其原理是避免对同一服务器上运行的服务进行密集检查。但是当使用较大的检查间隔（10 秒或更长）时，服务器场中的最后几个服务器需要一些时间才能开始被测试，这可能是一个问题。此参数用于强制设置第一个和最后一个检查之间的延迟上限，即使服务器的检查间隔较大。当服务器以较短的间隔运行时，它们的间隔仍将得到尊重。

将每个进程的最大并发连接数设置为 <number>。它等同于命令行参数 "-n"。当达到此限制时，代理将停止接受连接。"ulimit-n" 参数会根据此值自动调整。另请参阅 "ulimit-n"。注意：在某些平台上，"select" 轮询器不能可靠地使用超过 1024 个文件描述符。如果您的平台只支持 select 并在启动时报告 "select FAILED"，您需要减少 maxconn 直到它正常工作（通常略低于 500）。如果未设置此值，它将默认为构建时在 DEFAULT_MAXCONN 中设置的值（在 haproxy -vv 中报告），如果没有强制执行内存限制，或者将根据内存限制、缓冲区大小、分配给压缩的内存、SSL 缓存大小以及是否使用 SSL 和相关的 maxsslconn（也可以是自动的）来计算。

将每个进程每秒的最大连接数设置为 <number>。当达到此限制时，代理将停止接受连接。它可以用来限制全局容量，而不考虑每个前端的容量。需要注意的是，这只能用作服务保护措施，因为当达到限制时，前端之间不一定会公平分配，所以最好也为每个前端限制一个接近其预期份额的值。此外，降低 tune.maxaccept 可以提高公平性。

将每个进程的最大输入压缩速率设置为 <number> 千字节/秒。对于每个会话，如果达到最大值，会话期间的压缩级别将降低。如果在会话开始时达到最大值，该会话将完全不压缩。如果未达到最大值，压缩级别将增加到 tune.comp.maxlevel。值为零表示没有限制，这是默认值。

设置 HAProxy 在停止对新请求进行压缩或降低当前请求的压缩级别之前可以达到的最大 CPU 使用率。它的工作方式类似于 'maxcomprate'，但衡量的是 CPU 使用率而不是传入数据带宽。该值以 haproxy 使用的 CPU 百分比表示。在多进程（nbproc > 1）的情况下，每个进程管理其各自的使用率。值为 100 将禁用此限制。默认值为 100。设置较低的值将防止压缩工作减慢整个进程的速度并引入高延迟。

将每个进程的最大管道数设置为 <number>。目前，管道仅由基于内核的 tcp 拼接使用。由于一个管道包含两个文件描述符，"ulimit-n" 值将相应增加。默认值为 maxconn/4，这对于大多数重度使用情况来说似乎已经足够了。拼接代码动态分配和释放管道，并且可以回退到标准复制，因此将此值设置得太低可能只会影响性能。

将每个进程每秒的最大会话数设置为 <number>。当达到此限制时，代理将停止接受连接。它可以用来限制全局容量，而不考虑每个前端的容量。需要注意的是，这只能用作服务保护措施，因为当达到限制时，前端之间不一定会公平分配，所以最好也为每个前端限制一个接近其预期份额的值。此外，降低 tune.maxaccept 可以提高公平性。

将每个进程的并发 SSL 连接数设置为 <number>。默认情况下，没有特定于 SSL 的限制，这意味着全局 maxconn 设置将适用于所有连接。设置此限制可避免 openssl 使用过多内存而崩溃（因为它不幸地不能可靠地检查这种情况，因此 malloc 会返回 NULL）。请注意，该限制同时适用于传入和传出连接，因此一个经过解密然后加密的连接算作 2 个 SSL 连接。如果未设置此值，但强制执行了内存限制，则将根据内存限制、maxconn、缓冲区大小、分配给压缩的内存、SSL 缓存大小以及在前端、后端或两者中是否使用 SSL 来自动计算此值。如果在强制执行内存限制但未指定 maxconn 或 maxsslconn 的情况下，HAProxy 将自动调整这些值，以便 100% 的连接可以安全地通过 SSL 进行，并考虑已启用 SSL 的各个方面（前端、后端或两者）。

将每个进程每秒的最大 SSL 会话数设置为 <number>。当达到此限制时，SSL 侦听器将停止接受连接。它可以用来限制全局 SSL CPU 使用率，而不考虑每个前端的容量。需要注意的是，这只能用作服务保护措施，因为当达到限制时，前端之间不一定会公平分配，所以最好也为每个前端限制一个接近其预期份额的值。同样重要的是要注意，会话是在进入 SSL 堆栈之前而不是之后计算的，这也保护了堆栈免受不良握手的影响。此外，降低 tune.maxaccept 可以提高公平性。

设置 zlib 每个进程可用的最大 RAM 量（以兆字节为单位）。当达到最大量时，只要 RAM 不可用，将来的会话将不会压缩。当设置为 0 时，没有限制。默认值为 0。该值在 UNIX 套接字上以字节为单位可用，通过 "show info" 命令的 "MaxZlibMemUsage" 行显示，zlib 使用的内存为 "ZlibMemUsage"（以字节为单位）。

禁用在 Linux 上使用 "epoll" 事件轮询系统。它等同于命令行参数 "-de"。下一个使用的轮询系统通常是 "poll"。另请参阅 "nopoll"。

禁用在 BSD 上使用 "kqueue" 事件轮询系统。它等同于命令行参数 "-dk"。下一个使用的轮询系统通常是 "poll"。另请参阅 "nopoll"。

禁用 "poll" 事件轮询系统的使用。它等同于命令行参数 "-dp"。下一个使用的轮询系统将是 "select"。通常不需要禁用 "poll"，因为它在 HAProxy 支持的所有平台上都可用。另请参阅 "nokqueue" 和 "noepoll"。

禁用在 Linux 上使用内核在套接字之间进行 tcp 拼接。它等同于命令行参数 "-dS"。数据将使用传统的、更具可移植性的 recv/send 调用进行复制。内核 tcp 拼接仅限于一些非常近期的内核 2.6 实例。大多数 2.6.25 到 2.6.28 之间的版本都有错误，会转发损坏的数据，因此不得使用。此选项使得在有疑问时可以轻松地全局禁用内核拼接。另请参阅 "option splice-auto"、"option splice-request" 和 "option splice-response"。

禁用使用 getaddrinfo(3) 进行名称解析。它等同于命令行参数 "-dG"。将使用已弃用的 gethostbyname(3)。

禁用 SO_REUSEPORT 的使用 - 请参阅 socket(7)。它等同于命令行参数 "-dR"。

有时，希望避免以精确的间隔向服务器发送代理和健康检查，例如当许多逻辑服务器位于同一物理服务器上时。借助此参数，可以在检查间隔中添加 0 到 +/- 50% 之间的随机性。2 到 5 之间的值似乎效果很好。默认值仍为 0。

为每个进程可能分配的缓冲区数量设置硬限制。默认值为零，表示无限制。最小的非零值将始终大于“tune.buffers.reserve”，并且理想情况下应始终是其大小的两倍。强制设置此值可以特别有效地限制进程可能占用的内存量，同时保持正常行为。当达到此限制时，需要缓冲区的会话将等待另一个缓冲区被另一个会话释放。由于缓冲区是动态分配和释放的，因此等待时间非常短，并且只要限制保持合理，就不会被感知。事实上，有时降低限制可以通过提高 CPU 缓存的效率来提高性能。测试表明，对于平均 HTTP 流量，将限制设置为预期全局 maxconn 设置的 1/10 可获得良好结果，这还显著降低了内存使用量。内存节省来自于一个事实，即某些连接不会分配 2*tune.bufsize。除非 HAProxy 核心开发人员建议，否则最好不要更改此值。

设置预分配并保留的缓冲区数量，仅在内存分配失败导致的内存短缺情况下使用。最小值为 2，也是默认值。用户没有理由更改此值，它主要针对 haproxy 核心开发人员。

将缓冲区大小设置为此大小（以字节为单位）。较低的值允许更多的会话在相同数量的 RAM 中共存，而较高的值允许某些具有非常大 cookie 的应用程序正常工作。默认值为 16384，可以在构建时更改。强烈建议不要更改此值，因为非常低的值会破坏某些服务（如统计信息），而大于默认大小的值会增加内存使用量，可能导致系统内存不足。至少，全局 maxconn 参数应减小与此参数增加相同的比例。如果 HTTP 请求大于 (tune.bufsize - tune.maxrewrite)，HAProxy 将返回 HTTP 400 (Bad Request) 错误。同样，如果 HTTP 响应大于此大小，HAProxy 将返回 HTTP 502 (Bad Gateway)。

将检查缓冲区大小设置为此大小（以字节为单位）。较高的值可能有助于在非常大的页面中查找字符串或正则表达式模式，但这可能意味着更多的内存和 CPU 使用。默认值为 16384，可以在构建时更改。不建议更改此值，而应尽可能使用更好的检查方法。

设置最大压缩级别。压缩级别影响压缩期间的 CPU 使用率。此值影响压缩期间的 CPU 使用率。每个使用压缩的会话都使用此值初始化压缩算法。默认值为 1。

设置捕获的 cookie 的最大长度。"capture cookie xxx len yyy" 允许的最大值将是此值，任何更高的值都将自动截断为此值。重要的是不要设置太高的值，因为所有 cookie 捕获无论其配置值如何都会分配此大小（它们共享一个池）。此值是每个请求每个响应的，因此每个连接分配的内存是此值的两倍。如果未指定，限制设置为 63 个字符。建议不要更改此值。

设置请求中的最大报头数。当请求的报头数（包括第一行）大于此值时，它将被拒绝，并返回 "400 Bad Request" 状态码。同样，过大的响应将被阻止，并返回 "502 Bad Gateway"。默认值为 101，对于所有用途来说已经足够，考虑到广泛部署的 Apache 服务器也使用相同的限制。有时可以进一步提高此限制，以便在修复错误的应用程序之前临时允许其工作。可接受的范围是 1..32767。请记住，每个新报头都会为每个会话消耗 32 位的内存，因此不要将此限制设置得太高。

设置 HAProxy 在多长时间后认为空缓冲区可能与空闲流相关联。这用于在交替转发大数据和小数据时优化某些数据包的大小。使用 splice() 或在 SSL 中发送大缓冲区进行的决策由此参数决定。该值以毫秒为单位，范围在 0 到 65535 之间。值为零表示 HAProxy 不会尝试检测空闲流。默认值为 1000，这似乎能正确检测最终用户的暂停（例如，在单击之前阅读页面）。更改此值应该没有理由。请检查下面的 tune.ssl.maxrecord。

此指令强制 Lua 引擎每执行 <number> 条指令执行一次 yield。这允许中断长时间运行的脚本，并允许 HAProxy 调度程序处理其他任务，例如接受连接或转发流量。默认值为 10000 条指令。如果 HAProxy 经常执行一些 Lua 代码但需要更高的响应性，则可以降低此值。如果 Lua 代码相当长，并且其结果对于处理数据绝对是必需的，则可以增加 <number>。

设置 Lua 每个进程可用的最大 RAM 量（以兆字节为单位）。默认情况下为零，表示无限制。设置限制很重要，以确保脚本中的错误不会导致系统内存耗尽。

这是 Lua 会话的执行超时。这对于防止无限循环或在 Lua 中花费过多时间很有用。此超时仅计算纯 Lua 运行时。如果 Lua 执行 sleep，则 sleep 不会计入。默认超时为 4 秒。

目的与 "tune.lua.session-timeout" 相同，但此超时专用于任务。默认情况下，此超时未设置，因为任务可能在 HAProxy 的整个生命周期内保持活动状态。例如，用于检查服务器的任务。

这是 Lua 服务的执行超时。这对于防止无限循环或在 Lua 中花费过多时间很有用。此超时仅计算纯 Lua 运行时。如果 Lua 执行 sleep，则 sleep 不会计入。默认超时为 4 秒。

设置一个进程在切换到其他工作之前可以连续接受的最大连接数。在单进程模式下，较高的数字在高连接率下性能更好。然而，在多进程模式下，在进程之间保持一点公平性通常能更好地提高性能。此值单独应用于每个侦听器，以便考虑到侦听器绑定的进程数。此值默认为 64。在多进程模式下，它除以侦听器绑定的进程数的两倍。将此值设置为 -1 将完全禁用此限制。通常不需要调整此值。

设置一次调用轮询系统可以处理的最大事件量。默认值根据操作系统进行调整。已经注意到，将其降低到 200 以下会略微降低延迟，但会牺牲网络带宽，而将其增加到 200 以上则会以延迟换取略微增加的带宽。

将保留的缓冲区空间设置为此大小（以字节为单位）。保留空间用于报头重写或追加。套接字上的第一次读取永远不会超过 bufsize-maxrewrite。历史上，它默认为 bufsize 的一半，但这没有太大意义，因为很少有大量的报头需要添加。设置得太高会妨碍处理大的请求或响应。设置得太低会妨碍向已有的较大请求或 POST 请求添加新报头。通常明智的做法是将其设置为大约 1024。如果大于 bufsize 的一半，它会自动调整为 bufsize 的一半。这意味着您在更改 bufsize 时不必担心它。

将模式查找缓存的大小设置为 <number> 条目。这是一个 LRU 缓存，可以记住之前的查找及其结果。ACL 和映射在缓慢的模式查找中使用它，特别是使用“sub”、“reg”、“dir”、“dom”、“end”、“bin”匹配方法以及不区分大小写的字符串。它适用于模式表达式，这意味着它能够记住配置行（包括从文件中加载的所有配置行）上指定的所有模式的查找结果。它会自动使通过 HTTP 操作或 CLI 更新的条目失效。默认缓存大小设置为 10000 个条目，这限制了其内存占用，在 32 位系统上约为 5 MB，在 64 位系统上约为 8 MB。此缓存中发生冲突的风险非常低，其风险大致等于缓存大小除以 2^64。通常，在每秒 10000 次请求和默认缓存大小 10000 个条目的情况下，暴力攻击导致单个冲突的概率在 60 年后为 1%，在 6 年后为 0.1%。这被认为远低于因老化组件引起的内存损坏风险。如果这不可接受，可以通过将此参数设置为 0 来禁用缓存。

将内核管道缓冲区大小设置为此大小（以字节为单位）。默认情况下，管道是系统的默认大小。但有时在使用 TCP 拼接时，增加管道大小可以提高性能，特别是在怀疑管道未被填满且执行了许多 splice() 调用时。这对内核的内存占用有影响，因此如果影响不明确，则不应更改此值。

将客户端或服务器端的内核套接字接收缓冲区大小强制设置为指定的字节数。此值适用于所有 TCP/HTTP 前端和后端。通常不应设置此值，默认大小 (0) 允许内核根据可用内存量自动调整此值。然而，有时将其设置为非常小的值（例如 4096）可以节省内核内存，防止它缓冲过多的接收数据。然而，较低的值会显著增加 CPU 使用率。

HAProxy 使用一些提示来检测短读是否表示套接字缓冲区的结束。其中一个提示是读取返回的字节数超过 <recv_enough>，默认为 10136（7 个段，每个段 1448 字节）。此默认值可以通过此设置更改，以更好地处理涉及大量短消息的工作负载，例如 telnet 或 SSH 会话。

将客户端或服务器端的内核套接字发送缓冲区大小强制设置为指定的字节数。此值适用于所有 TCP/HTTP 前端和后端。通常不应设置此值，默认大小 (0) 允许内核根据可用内存量自动调整此值。然而，有时将其设置为非常小的值（例如 4096）可以节省内核内存，防止它缓冲过多的接收数据。然而，较低的值会显著增加 CPU 使用率。另一个用例是防止由于内核等待大部分缓冲区被读取然后才再次通知 HAProxy 而导致的极慢客户端的写入超时。

以块数为单位设置全局 SSL 会话缓存的最大大小。一个块足够大，可以包含不带对端证书的编码会话。带有对端证书的编码会话根据对端证书的大小存储在多个块中。一个块约占用 200 字节内存。默认值可能在构建时强制设置，否则默认为 20000。当缓存已满时，最不活跃的条目将被清除并重新分配。较高的值会减少这种清除的发生频率，从而减少 CPU 密集型 SSL 握手的次数，确保所有用户尽可能长时间地保留其会话。所有条目在启动时预先分配，并且如果“nbproc
此关键字在以下部分可用：
进程管理和安全
从内部状态获取样本”大于 1 时，会在所有进程之间共享。将此值设置为 0 将禁用 SSL 会话缓存。

此选项禁用所有进程之间的 SSL 会话缓存共享。通常不应使用它，因为它会由于客户端命中随机进程而强制进行许多重新协商。但在某些操作系统上可能需要它，因为这些操作系统上可能无法使用任何 SSL 缓存同步方法。在这种情况下，在 SSL 层之前添加第一层基于哈希的负载均衡可能会限制缺少会话共享的影响。

设置缓存的 SSL 会话可以保持有效的时长。此时间以秒为单位表示，默认为 300（5 分钟）。重要的是要理解，这并不保证会话会持续那么长时间，因为如果缓存已满，最长时间空闲的会话将被清除，尽管它们配置了生命周期。此设置的真正用处是防止会话被使用太长时间。

设置一次传递给 SSL_write() 的最大字节数。默认值 0 表示没有限制。在 SSL/TLS 上，客户端只能在收到完整记录后才能解密数据。对于大型记录，这意味着客户端可能需要下载多达 16kB 的数据才能开始处理它们。限制此值可以提高位于高延迟或低带宽网络上的浏览器的页面加载时间。建议找到适合 1 或 2 个 TCP 段的最佳值（通常在以太网上传输时间戳时为 1448 字节，禁用时间戳时为 1460 字节），同时记住 SSL/TLS 会增加一些开销。测试期间，典型的 1419 和 2859 值取得了良好效果。使用“strace -e trace=write”查找最佳值。HAProxy 在检测到空闲流后（请参阅上面的 tune.idletimer）会自动切换到此设置。

在 DHE 密钥交换的情况下，设置用于生成临时/瞬时 Diffie-Hellman 密钥的 Diffie-Hellman 参数的最大大小。最终大小将尝试匹配服务器的 RSA（或 DSA）密钥的大小（例如，对于 2048 位 RSA 密钥使用 2048 位临时 DH 密钥），但不会超过此最大值。默认值为 1024。只允许 1024 或更高的值。较高的值会增加 CPU 负载，而大于 1024 位的值不受 Java 7 及更早版本的客户端支持。如果直接在证书文件中或使用 ssl-dh-param-file 参数提供了静态 Diffie-Hellman 参数，则不使用此值。

将用于存储生成证书的缓存大小设置为 <number> 个条目。这是一个 LRU 缓存。因为动态生成 SSL 证书的开销很大，所以它们被缓存起来。默认缓存大小设置为 1000 个条目。

这五个 tune 参数有助于管理变量系统使用的最大内存量。“global”限制了所有范围的总可用内存。“proc”限制了进程范围的内存，“sess”限制了会话范围的内存，“txn”限制了事务范围的内存，而“reqres”限制了每个请求或响应处理的内存。内存记账是分层的，这意味着更粗粒度的限制包含更细粒度的限制：“proc”包含“sess”，“sess”包含“txn”，“txn”包含“reqres”。例如，当“tune.vars.sess-max-size”限制为 100 时，“tune.vars.txn-max-size”和“tune.vars.reqres-max-size”也不能超过 100。如果我们创建一个包含 100 字节的变量“txn.var”，则所有可用空间都被消耗。请注意，在运行时超出限制不会导致错误消息，但值可能会被截断或损坏。因此，请确保准确规划存储所有变量所需的空间量。

为每个会话在 zlib 初始化中设置 memLevel 参数。它定义了应为内部压缩状态分配多少内存。值为 1 使用最少的内存，但速度慢且压缩率降低；值为 9 使用最大的内存以获得最佳速度。可以是 1 到 9 之间的值。默认值为 8。

为每个会话在 zlib 初始化中设置窗口大小（历史缓冲区的大小）。此参数的较大值会以内存使用为代价带来更好的压缩效果。可以是 8 到 15 之间的值。默认值为 15。

启用调试模式，将所有交换信息转储到标准输出，并禁止 fork 到后台。它等同于命令行参数 "-d"。它绝不应在生产配置中使用，因为它可能会阻止系统完全启动。

启动期间不显示任何消息。它等同于命令行参数 "-q"。

可以通过仅允许经过身份验证和授权的用户来控制对前端/后端/侦听部分或 http 统计信息的访问。为此，需要创建至少一个用户列表并定义用户。

创建名为 <listname> 的新用户列表。可以使用许多独立的用户列表来存储独立客户的身份验证和授权数据。

将组 <groupname> 添加到当前用户列表。也可以通过使用逗号分隔的名称列表（前面有 "users" 关键字）将用户附加到此组。

将用户 <username> 添加到当前用户列表。可以使用安全（加密）和不安全（未加密）的密码。加密密码使用 crypt(3) 函数进行评估，因此根据系统的功能，支持不同的算法。例如，现代基于 Glibc 的 Linux 系统支持 MD5、SHA-256、SHA-512，当然还有经典的基于 DES 的密码加密方法。

userlist L1 group G1 users tiger,scott group G2 users xdb,scott user tiger password $6$k6y3o.eP$JlKBx9za9667qe4(...)xHSwRv6J.C0/D7cV91 user scott insecure-password elgato user xdb insecure-password hello userlist L2 group G1 group G2 user tiger password $6$k6y3o.eP$JlKBx(...)xHSwRv6J.C0/D7cV91 groups G1 user scott insecure-password elgato groups G1,G2 user xdb insecure-password hello groups G2

请注意，这两个列表在功能上是相同的。

可以在多个 haproxy 实例之间通过 TCP 连接以多主方式传播粘性表中的任何数据类型的条目。每个实例将其本地更新和插入推送到远程对等节点。推送的值会覆盖远程值，而不进行聚合。中断的交换会自动检测并从最后一个已知点恢复。此外，在软重启期间，旧进程使用这样的 TCP 连接连接到新进程，以在新进程尝试连接其他对等节点之前推送其所有条目。这确保了在重新加载期间的快速复制，即使对于大型表，通常也只需要几分之一秒。请注意，服务器 ID 用于远程识别服务器，因此重要的是配置看起来相似，或者至少在所有参与者上对每个服务器强制使用相同的 ID。

创建名为 <peersect> 的新对等节点列表。它是一个独立的部分，由一个或多个粘性表引用。

禁用一个对等节点部分。它会禁用与此部分相关的侦听和任何同步。这用于禁用粘性表的同步，而无需注释掉所有 "peers" 引用。

这会重新启用先前被禁用的对等节点部分。

在对等节点部分内定义一个对等节点。如果 <peername> 设置为本地对等节点名称（默认为主机名，或使用 "-L" 命令行选项强制指定），haproxy 将在 <ip>:<port> 上侦听传入的远程对等节点连接。否则，<ip>:<port> 定义了连接到远程对等节点的位置，<peername> 在协议级别用于在服务器端识别和验证远程对等节点。在软重启期间，旧实例使用本地对等节点 <ip>:<port> 连接到新实例并启动完整的复制（教学过程）。强烈建议在所有对等节点上具有完全相同的 peers 声明，并且仅依赖 "-L" 命令行参数来更改本地对等节点名称。这使得在所有对等节点之间维护一致的配置文件变得更容易。您可能希望在地址参数中引用一些环境变量，请参阅关于环境变量的第 2.3 节。

peers mypeers peer haproxy1 192.168.0.1:1024 peer haproxy2 192.168.0.2:1024 peer haproxy3 10.2.0.1:1024 backend mybackend mode tcp balance roundrobin stick-table type ip size 20k peers mypeers stick on src server srv1 192.168.0.30:80 server srv2 192.168.0.31:80

当服务器状态发生变化时，可以发送电子邮件警报。如果配置了电子邮件警报，则会发送到邮件发送器部分中配置的每个邮件发送器。电子邮件使用 SMTP 发送给邮件发送器。

创建名为 <mailersect> 的新邮件发送器列表。它是一个独立的部分，由一个或多个代引用。

在邮件发送器部分内定义一个邮件发送器。

mailers mymailers mailer smtp1 192.168.0.1:587 mailer smtp2 192.168.0.2:587 backend mybackend mode tcp balance roundrobin email-alert mailers mymailers email-alert from test1@horms.org email-alert to test2@horms.org server srv1 192.168.0.30:80 server srv2 192.168.0.31:80

定义可用于建立邮件/连接并发送到邮件服务器的时间。如果未定义，默认值为 10 秒。为了允许在初始 TCP 握手期间至少发送两个 SYN-ACK 数据包，建议将此值保持在 4 秒以上。

mailers mymailers timeout mail 20s mailer smtp1 192.168.0.1:587

代理配置可以在以下部分中找到：- defaults [<name>] - frontend <name> - backend <name> - listen <name> "defaults" 部分设置了其声明后所有其他部分的默认参数。这些默认参数会在下一个 "defaults" 部分重置。有关可以在 "defaults" 部分设置的参数列表，请参阅下文。名称是可选的，但为了提高可读性，建议使用。 "frontend" 部分描述了一组接受客户端连接的监听套接字。 "backend" 部分描述了一组服务器，代理将连接到这些服务器来转发传入的连接。 "listen" 部分在一个部分中定义了一个完整的代理，包含其前端和后端部分。这对于纯 TCP 流量通常很有用。所有代理名称必须由大写和小写字母、数字、'-'（连字符）、'_'（下划线）、'.'（点）和':'（冒号）组成。 ACL 名称区分大小写，这意味着 "www" 和 "WWW" 是两个不同的代理。历史上，所有代理名称都可以重叠，这只会给日志带来麻烦。自从引入内容切换以来，具有重叠功能（frontend/backend）的两个代理必须具有不同的名称。但是，前端和后端仍然可以共享相同的名称，因为这种配置似乎很常见。目前支持两种主要的代理模式："tcp"，也称为第 4 层，和 "http"，也称为第 7 层。在第 4 层模式下，HAProxy 仅在双方之间转发双向流量。在第 7 层模式下，HAProxy 会分析协议，并可以根据任意标准允许、阻止、切换、添加、修改或删除请求或响应中的任意内容来与之交互。在 HTTP 模式下，应用于通过连接流动的请求和响应的处理取决于前端的 HTTP 选项和后端的组合。HAProxy 支持 5 种连接模式：- KAL：keep alive ("option http-keep-alive")，这是默认模式：所有请求和响应都经过处理，连接在响应和新请求之间保持打开但空闲状态。- TUN：tunnel ("option http-tunnel")：这是版本 1.0 到 1.5-dev21 的默认模式：仅处理第一个请求和响应，其余所有内容都未经分析直接转发。此模式不应使用，因为它会导致日志记录和 HTTP 处理出现许多问题。- PCL：passive close ("option httpclose")：与 tunnel 模式完全相同，但在两个方向上都附加了 "Connection: close"，以尝试使双方在第一次请求/响应交换后关闭。- SCL：server close ("option http-server-close")：在收到响应结束后，面向服务器的连接将被关闭，但面向客户端的连接将保持打开状态。- FCL：forced close ("option forceclose")：在响应结束后，连接将被主动关闭。通过前端和后端传递的连接将适用的有效模式可以通过以下矩阵中的两种代理模式确定，但简而言之，模式是对称的，keep-alive 是最弱的选项，force close 是最强的。 Backend mode | KAL | TUN | PCL | SCL | FCL ----+-----+-----+-----+-----+---- KAL | KAL | TUN | PCL | SCL | FCL ----+-----+-----+-----+-----+---- TUN | TUN | TUN | PCL | SCL | FCL Frontend ----+-----+-----+-----+-----+---- mode PCL | PCL | PCL | PCL | FCL | FCL ----+-----+-----+-----+-----+---- SCL | SCL | SCL | FCL | SCL | FCL ----+-----+-----+-----+-----+---- FCL | FCL | FCL | FCL | FCL | FCL

支持以下关键字列表。其中大多数只能在有限的节类型中使用。其中一些被标记为“已弃用”，因为它们继承自旧的语法，可能令人困惑或功能有限，并且有新的推荐关键字来替换它们。标记为“(*)”的关键字可以使用“no”前缀选择性地反转，例如“no option contstats”。当选项默认启用并且必须为特定实例禁用时，这样做是有意义的。这些选项也可以以“default”为前缀，以恢复默认设置，无论在之前的“defaults”节中指定了什么。

关键字	defaults	frontend	listen	backend
acl
appsession
backlog
balance
bind
bind-process
(已弃用)block
capture cookie
capture request header
capture response header
(已弃用)clitimeout
compression
(已弃用)contimeout
cookie
declare capture
default-server
default_backend
description
disabled
dispatch
关键字	defaults	frontend	listen	backend
email-alert from
email-alert level
email-alert mailers
email-alert myhostname
email-alert to
enabled
errorfile
errorloc
errorloc302
errorloc303
force-persist
filter
fullconn
grace
hash-type
http-check disable-on-404
http-check expect
http-check send-state
http-request
http-response
关键字	defaults	frontend	listen	backend
http-reuse
http-send-name-header
id
ignore-persist
load-server-state-from-file
(*)log
log-format
log-format-sd
log-tag
max-keep-alive-queue
maxconn
mode
monitor fail
monitor-net
monitor-uri
(*)option abortonclose
(*)option accept-invalid-http-request
(*)option accept-invalid-http-response
(*)option allbackups
(*)option checkcache
关键字	defaults	frontend	listen	backend
(*)option clitcpka
(*)option contstats
(*)option dontlog-normal
(*)option dontlognull
(*)option forceclose
option forwardfor
(*)option http-buffer-request
(*)option http-ignore-probes
(*)option http-keep-alive
(*)option http-no-delay
(*)option http-pretend-keepalive
(*)option http-server-close
(*)option http-tunnel
(*)option http-use-proxy-header
option httpchk
(*)option httpclose
option httplog
(*)option http_proxy
(*)option independent-streams
option ldap-check
关键字	defaults	frontend	listen	backend
option external-check
(*)option log-health-checks
(*)option log-separate-errors
(*)option logasap
option mysql-check
(*)option nolinger
option originalto
(*)option persist
option pgsql-check
(*)option prefer-last-server
(*)option redispatch
option redis-check
option smtpchk
(*)option socket-stats
(*)option splice-auto
(*)option splice-request
(*)option splice-response
option spop-check
(*)option srvtcpka
option ssl-hello-chk
关键字	defaults	frontend	listen	backend
option tcp-check
(*)option tcp-smart-accept
(*)option tcp-smart-connect
option tcpka
option tcplog
(*)option transparent
external-check command
external-check path
persist rdp-cookie
rate-limit sessions
redirect
(已弃用)redisp
(已弃用)redispatch
reqadd
reqallow
reqdel
reqdeny
reqiallow
reqidel
reqideny
关键字	defaults	frontend	listen	backend
reqipass
reqirep
reqitarpit
reqpass
reqrep
reqtarpit
retries
rspadd
rspdel
rspdeny
rspidel
rspideny
rspirep
rsprep
server
server-state-file-name
source
(已弃用)srvtimeout
stats admin
stats auth
关键字	defaults	frontend	listen	backend
stats enable
stats hide-version
stats http-request
stats realm
stats refresh
stats scope
stats show-desc
stats show-legends
stats show-node
stats uri
stick match
stick on
stick store-request
stick store-response
stick-table
tcp-check connect
tcp-check expect
tcp-check send
tcp-check send-binary
tcp-request connection
关键字	defaults	frontend	listen	backend
tcp-request content
tcp-request inspect-delay
tcp-request session
tcp-response content
tcp-response inspect-delay
timeout check
timeout client
timeout client-fin
(已弃用)timeout clitimeout
timeout connect
(已弃用)timeout contimeout
timeout http-keep-alive
timeout http-request
timeout queue
timeout server
timeout server-fin
(已弃用)timeout srvtimeout
timeout tarpit
timeout tunnel
(已弃用)transparent
关键字	defaults	frontend	listen	backend
unique-id-format
unique-id-header
use_backend
use-server

本节提供了每个关键字及其用法的描述。

声明或完成一个访问控制列表。

可在节中使用

defaults	frontend	listen	backend
否	是	是	是

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

有关 ACL 的用法，请参见第 7 节。

基于一个现有的应用程序 cookie 定义会话粘性。

可在节中使用

defaults	frontend	listen	backend
否	否	是	是

<cookie> 这是应用程序使用的 cookie 的名称，HAProxy 需要为每个新会话学习它。<length> 这是在每个 cookie 值中要记忆和检查的最大字符数。<holdtime> 这是 cookie 如果未使用，将在多久后从内存中删除。如果未指定单位，则此时间以毫秒为单位。request-learn 如果指定此选项，则当服务器未在响应中指定 cookie 时，haproxy 将能够学习请求中找到的 cookie。这通常是 PHPSESSID cookie 的情况，或者当 haproxy 的会话在应用程序的会话之前过期并且选择了正确的服务器时。建议指定此选项以提高可靠性。prefix 如果指定此选项，haproxy 将匹配 cookie 前缀（或 URL 参数前缀）。appsession 值是此前缀后的数据。例如：appsession ASPSESSIONID len 64 timeout 3h prefix 这将匹配 cookie ASPSESSIONIDXXXX=XXXXX，appsession 值将是 XXXX=XXXXX。mode 此选项允许更改 URL 解析器模式。目前支持 2 种模式：- path-parameters：解析器在路径参数部分（每个参数用分号分隔）查找 appsession，例如 JSESSIONID 很方便。如果未设置此选项，则这是默认模式。- query-string：在此模式下，解析器将在查询字符串中查找 appsession。

从 1.6 版本开始，appsession 已被移除。使用 stick-tables 更灵活、更方便，并且 stick-tables 支持多主复制和跨重载的数据保留，而 appsession 不支持。

向系统提供关于期望的监听队列（backlog）大致大小的提示。

可在节中使用

defaults	frontend	listen	backend
是	是	是	否

<conns> 是待处理连接的数量。根据操作系统的不同，它可能表示已确认的连接数、未确认的连接数或两者之和。

为了防范 SYN 洪水攻击，一种解决方案是增加系统的 SYN 队列大小。根据系统的不同，有时它只能通过系统参数进行调整，有时根本无法调整，有时系统依赖于应用程序在调用 listen() 系统调用时给出的提示。默认情况下，HAProxy 将前端的 maxconn 值传递给 listen() 系统调用。在可以利用此值的系统上，有时能够指定一个不同的值会很有用，因此有了这个 backlog 参数。在 Linux 2.4 上，该参数被系统忽略。在 Linux 2.6 上，它被用作一个提示，系统最多接受不小于该值的最小的 2 的幂次方，并且永远不会超过某些限制（通常是 32768）。

定义在后端中使用的负载均衡算法。

可在节中使用

defaults	frontend	listen	backend
是	否	是	是

<algorithm> 是在进行负载均衡时用于选择服务器的算法。这仅适用于没有持久性信息可用时，或当连接被重新分发到另一台服务器时。<algorithm> 可能是以下之一：roundrobin 每个服务器按其权重轮流使用。当服务器的处理时间保持相等分布时，这是最平滑、最公平的算法。此算法是动态的，这意味着服务器权重可以动态调整，例如用于慢启动。它被设计限制为每个后端最多 4095 个活动服务器。请注意，在一些大型集群中，当一台服务器在非常短的时间内从宕机状态恢复后，可能需要几百个请求才能将其重新集成到集群中并开始接收流量。这是正常的，尽管非常罕见。在此处提及是为了以防万一您有机会观察到它，以免担心。static-rr 每个服务器按其权重轮流使用。此算法与 roundrobin 非常相似，不同之处在于它是静态的，这意味着动态更改服务器权重将无效。另一方面，它对服务器数量没有设计限制，并且当服务器启动时，在重新计算完整映射后，它将始终立即重新引入集群。它还使用略少的 CPU 来运行（约 -1%）。leastconn 连接数最少的服务器接收连接。通过相同负载的服务器组进行轮询，以确保所有服务器都得到使用。建议在预期会话非常长的情况下使用此算法，例如 LDAP、SQL、TSE 等……但不适用于使用短会话的协议，如 HTTP。此算法是动态的，这意味着服务器权重可以动态调整，例如用于慢启动。first 具有可用连接槽的第一台服务器接收连接。服务器按最低数字标识符到最高数字标识符（请参阅服务器参数“id
此关键字在以下部分中可用：
按字母排序的关键字参考
绑定选项
服务器和默认服务器选项”）选择，默认为服务器在集群中的位置。一旦服务器达到其 maxconn 值，就会使用下一台服务器。不设置 maxconn 而使用此算法没有意义。此算法的目的是始终使用最少数量的服务器，以便在非高峰时段关闭额外的服务器。此算法会忽略服务器权重，并且对 RDP 或 IMAP 等长会话比 HTTP 更有益，尽管在 HTTP 中也有用。为了有效地使用此算法，建议云控制器定期检查服务器使用情况，在未使用的服务器关闭，并在队列膨胀时定期检查后端队列以开启新服务器。或者，使用“http-check send-state”可以告知服务器负载情况。source 源 IP 地址被哈希并除以运行服务器的总权重，以指定哪个服务器将接收请求。这确保了只要没有服务器宕机或上线，相同的客户端 IP 地址将始终访问同一台服务器。如果由于运行服务器数量的变化导致哈希结果发生变化，许多客户端将被定向到不同的服务器。此算法通常用于 TCP 模式，其中可能不会插入 cookie。它也可以在 Internet 上使用，以向拒绝会话 cookie 的客户端提供最佳的粘性。此算法默认是静态的，这意味着动态更改服务器权重将无效，但可以使用“hash-type”进行更改。uri 该算法哈希 URI 的左侧部分（问号之前）或整个 URI（如果存在“whole”参数），并将其哈希值除以运行服务器的总权重。结果指定将哪个服务器接收请求。这确保只要没有服务器上线或宕机，相同的 URI 将始终定向到同一台服务器。这用于代理缓存和防病毒代理，以最大化缓存命中率。请注意，此算法只能在 HTTP 后端使用。此算法默认是静态的，这意味着动态更改服务器权重将无效，但可以使用“hash-type”进行更改。此算法支持两个可选参数“len”和“depth”，后面都跟一个正整数。当需要仅基于 URI 的开头来平衡服务器时，这些选项可能很有用。“len”参数表示算法应仅考虑 URI 开头的字符数来计算哈希。请注意，“len”设置为 1 很少有意义，因为大多数 URI 都以斜杠“/”开头。“depth”参数表示用于计算哈希的最大目录深度。每次请求中的斜杠都算作一个级别。如果指定了这两个参数，则在达到其中一个时评估停止。url_param 参数中指定的 URL 参数将在每个 HTTP GET 请求的查询字符串中查找。如果使用“check_post”修饰符，则会在 HTTP POST 请求实体中搜索参数参数，当它在 URL 中问号 ('?') 之后的查询字符串中找不到时。消息体将在收到广告的数据量或请求缓冲区已满后才开始被分析。在极少数情况下，如果使用分块编码，则仅扫描第一个块。以块边界分隔的参数值可能会被随机平衡，如果根本不平衡的话。此关键字曾支持一个可选的 <max_wait> 参数，但现在已被忽略。如果找到该参数，后面跟着一个等号 ('=') 和一个值，则该值被哈希并除以运行服务器的总权重。结果指定将哪个服务器接收请求。这用于跟踪请求中的用户标识符，并确保只要没有服务器上线或宕机，同一个用户 ID 就会始终发送到同一台服务器。如果找不到值或找不到参数，则应用轮询算法。请注意，此算法只能在 HTTP 后端使用。此算法默认是静态的，这意味着动态更改服务器权重将无效，但可以使用“hash-type”进行更改。hdr(<name>) HTTP 标头 <name> 将在每个 HTTP 请求中查找。就像等效的 ACL 'hdr()' 函数一样，括号中的标头名称不区分大小写。如果标头不存在或不包含任何值，则改为应用 roundrobin 算法。一个可选的“use_domain_only”参数可用，用于将哈希算法缩减到具有特定标头（如“Host”）的主域部分。例如，在主机值“haproxy.1wt.eu”中，只考虑“1wt”。此算法默认是静态的，这意味着动态更改服务器权重将无效，但可以使用“hash-type”进行更改。rdp-cookie rdp-cookie(<name>) RDP cookie <name>（如果省略则为“mstshash”）将在每个传入的 TCP 请求中被查找和哈希。就像等效的 ACL 'req_rdp_cookie()' 函数一样，名称不区分大小写。这种机制很有用，作为一种降级的持久性模式，因为它使得可以将同一个用户（或同一个会话 ID）始终发送到同一台服务器。如果找不到 cookie，则使用正常的 roundrobin 算法。请注意，要使其正常工作，前端必须确保 RDP cookie 已存在于请求缓冲区中。为此，您必须使用“tcp-request content accept”规则并结合“req_rdp_cookie_cnt”ACL。此算法默认是静态的，这意味着动态更改服务器权重将无效，但可以使用“hash-type”进行更改。另请参阅 rdp_cookie 模式提取函数。<arguments> 是某些算法可能需要的可选参数列表。目前，只有“url_param”和“uri”支持可选参数。

当没有设置其他算法、模式或选项时，后端的负载均衡算法被设置为 roundrobin。每个后端只能设置一次算法。

balance roundrobin balance url_param userid balance url_param session_id check_post 64 balance hdr(User-Agent) balance hdr(host) balance hdr(Host) use_domain_only

注意：在使用“check_post”扩展与“url_param”时，必须考虑以下注意事项和限制：- 所有 POST 请求都有资格被考虑，因为无法确定参数是否会在包含二进制数据的正文或实体中找到。因此，可能需要另一种方法来限制考虑正文中没有 URL 参数的 POST 请求。（请参阅 acl reqideny http_end）- 使用大于请求缓冲区大小的 <max_wait> 值没有意义，并且无用。缓冲区大小在构建时设置，默认为 16 kB。- 不支持 Content-Encoding，参数搜索可能会失败；负载均衡将回退到 Round Robin。- 不支持 Expect: 100-continue，负载均衡将回退到 Round Robin。- Transfer-Encoding (RFC7230 3.3.1) 仅在第一个块中受支持。如果整个参数值不在第一个块中，则服务器选择是不确定的（实际上，由第一个块中实际出现的少量内容定义）。- 此功能不支持生成 100、411 或 501 响应。- 在某些情况下，请求“check_post”可能会尝试扫描消息正文的全部内容。扫描通常在找到线性空白字符或控制字符时终止，这表明 URL 参数列表的结束。这可能与 SGML 类型消息体无关。

在前端（frontend）中定义一个或多个监听地址和/或端口。

可在节中使用

defaults	frontend	listen	backend
否	是	是	否

<address> 是可选的，可以是主机名、IPv4 地址、IPv6 地址或 '*'。它指定前端将监听的地址。如果未设置，则监听系统的所有 IPv4 地址。对于 '*' 或系统特殊地址 "0.0.0.0" 也适用。IPv6 等效是 '::'。可以选择使用地址族前缀，然后在地址之前强制指定地址族，这对于指定没有斜杠 ('/') 的 unix 套接字的路径很有用。当前支持的前缀有：- 'ipv4@' -> 地址始终是 IPv4- 'ipv6@' -> 地址始终是 IPv6- 'unix@' -> 地址是本地 unix 套接字的路径- 'abns@' -> 地址在抽象命名空间（仅限 Linux）。注意：由于抽象套接字不是“可重绑定的”，它们与软重启期间的多进程模式不兼容，因此最好避免在 nbproc 大于 1 的情况下使用它们。效果是，如果新进程启动失败，旧进程中只有一个能够重新绑定到套接字。- 'fd@<n>' -> 使用从父进程继承的文件描述符 <n>。fd 必须已绑定，并且可能已监听，也可能尚未监听。您可能希望在地址参数中引用一些环境变量，请参阅 第 2.3 节关于环境变量。<port_range> 是一个唯一的 TCP 端口，或者是一个端口范围，代理将接受上面指定的 IP 地址的连接。对于 TCP 监听器，端口是强制性的。请注意，对于 IPv6 地址，端口始终是最后一个冒号 (':') 之后的数字。范围可以是：- 数字端口（例如：'80'）- 短划线分隔的端口范围，明确说明下限和上限（例如：'2000-2100'），包含在范围内。必须特别注意端口范围，因为每个 <address:port> 对都会消耗一个套接字（= 一个文件描述符），因此很容易用一个简单的范围消耗大量描述符，从而耗尽套接字。此外，每个 <address:port> 对在同一系统上运行的所有实例之间只能使用一次。请注意，绑定到低于 1024 的端口通常需要特殊的权限才能启动程序，这独立于 'uid' 参数。<path> 是一个以斜杠 ('/') 开头的 UNIX 套接字路径。这是 TCP 监听端口的替代方案。Haproxy 将在位于此处的套接字上接收 UNIX 连接。路径必须以斜杠开头，默认情况下是绝对路径。它可以是全局部分中由“unix-bind”定义的路径的相对路径。请注意，前缀加上套接字路径的总长度不能超过 UNIX 套接字的一些系统限制，这些限制通常设置为 107 个字符。<param*> 是同一行上声明的所有套接字的通用参数列表。这些众多参数取决于操作系统和构建选项，并有一个专门的部分介绍它们。请参阅 第 5 节了解更多详细信息。

可以指定一个由逗号分隔的地址:端口组合列表。然后，前端将监听所有这些地址。一个前端可以监听的地址和端口数量没有固定限制，一个前端中的 "bind" 语句数量也没有限制。

listen http_proxy bind :80,:443 bind 10.0.0.1:10080,10.0.0.1:10443 bind /var/run/ssl-frontend.sock user root mode 600 accept-proxy listen http_https_proxy bind :80 bind :443 ssl crt /etc/haproxy/site.pem listen http_https_proxy_explicit bind ipv6@:80 bind ipv4@public_ssl:443 ssl crt /etc/haproxy/site.pem bind unix@ssl-frontend.sock user root mode 600 accept-proxy listen external_bind_app1 bind "fd@${FD_APP1}"

注意：关于 Linux 的抽象命名空间套接字，HAProxy 使用整个 sun_path 长度作为地址长度。其他一些程序，如 socat，默认只使用字符串长度。在 socat 中对任何抽象套接字定义传递选项 ",unix-tightsocklen=0"，以使其与 HAProxy 兼容。

将一个实例的可见性限制在特定的进程号集合中。

可在节中使用

defaults	frontend	listen	backend
是	是	是	是

all 所有进程都会看到此实例。这是默认设置。它可用于覆盖默认值。odd 此实例将在进程 1,3,5,...63 上启用。此选项可以与其他数字组合使用。even 此实例将在进程 2,4,6,...64 上启用。此选项可以与其他数字组合使用。不要将其与少于 2 个进程一起使用，否则某些实例可能会从所有进程中丢失。number 该实例将在此进程号或范围内启用，其值必须全部在 1 到 32 或 64 之间，具体取决于机器的字大小。如果代理绑定到大于配置的 global.nbproc 的进程号，它将被强制绑定到进程 #1（如果指定了单个进程）或绑定到所有进程（否则）。

此关键字限制将某些实例绑定到某些进程。这有助于避免过多的进程监听同一端口。例如，在双核机器上，可以在 global 部分设置 'nbproc 2'，然后将监听器分配到 'odd' 和 'even' 实例。目前，无法使用此关键字引用超过 32 或 64 个进程，但这对于大多数设置来说应该足够了。请注意，'all' 实际上意味着所有进程，而不管机器的字大小，并且不限于前 32 或 64 个。每个“bind”行还可以进一步限制为代理进程的子集，请参阅 第 5.1 节中的“process”绑定关键字。当前端没有显式的“bind-process”行时，它会尝试绑定到其“bind”行引用的所有进程。这意味着前端可以轻松适应其监听器的进程。如果某些后端由绑定到其他进程的前端引用，则后端会自动继承前端的进程。

listen app_ip1 bind 10.0.0.1:80 bind-process odd listen app_ip2 bind 10.0.0.2:80 bind-process even listen management bind 10.0.0.3:80 bind-process 1 2 3 4 listen management bind 10.0.0.4:80 bind-process 1-4

如果/除非条件匹配，则阻止一个第 7 层请求。

可在节中使用

defaults	frontend	listen	backend
否	是	是	是

如果在层 7 处理的早期匹配/不匹配 <condition>，HTTP 请求将被阻止。如果请求被阻止，将返回 403 错误。该条件必须引用 ACL（参见 第 7 节）。这通常用于在满足或不满足某些条件时拒绝访问某些敏感资源。每个“block”语句没有固定数量的限制。要在第 4 层阻止连接（不发送 403 错误），请参阅“tcp-request connection reject”和“tcp-request content reject”规则。此形式已弃用，请勿在新配置中使用，而是使用新的“http-request deny”。

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 # block 已弃用。请改用 http-request deny： #block if invalid_src || local_dst http-request deny if invalid_src || local_dst

在请求和响应中捕获并记录一个 cookie。

可在节中使用

defaults	frontend	listen	backend
否	是	是	否

<name> 是要捕获的 Cookie 名称的开头。为了精确匹配名称，只需在名称后加上等号 ('=')。完整名称将出现在日志中，这对于调整 Cookie 名称和值（例如：ASPSESSIONXXXXX）的应用程序服务器很有用。<length> 是在日志中报告的最大字符数，包括 Cookie 名称、等号和值，所有这些都以标准的“name=value”形式。如果字符串超过 <length>，则会在右侧截断。

只捕获第一个 Cookie。同时监控“cookie
此关键字在以下部分可用：
按字母顺序排序的关键字参考
服务器和 default-server 选项
获取 HTTP 样本（第 7 层）”请求头和“set-cookie”响应头。这对于检查导致用户之间会话交叉或盗窃的应用程序错误特别有用，因为用户 Cookie 通常只能在登录页面上更改。当客户端未提供 Cookie 时，关联的日志列将报告“-”。当请求不导致服务器分配 Cookie 时，将在响应列中报告“-”。捕获仅在前段进行，因为日志格式对于给定的前端不应因后端而改变。这将来可能会改变。请注意，一个前端只能有一个“capture cookie”语句。最大捕获长度由全局“tune.http.cookielen”设置确定，默认为 63 个字符。不能在“defaults”部分指定捕获。

capture cookie ASPSESSION len 32

捕获并记录指定请求头的最后一次出现。

可在节中使用

defaults	frontend	listen	backend
否	是	是	否

<name> 是要捕获的头的名称。头名称不区分大小写，但通常的做法是按照它们在请求中出现的样子来写，每个单词的首字母大写。头名称不会出现在日志中，只报告其值，但其在日志中的位置会得到尊重。<length> 是从值中提取并报告在日志中的最大字符数。如果字符串超过 <length>，它将被从右侧截断。

将捕获最后一个出现的头的完整值。值将用花括号 ('{}') 包围并添加到日志中。如果捕获了多个头，它们将用竖线 ('|') 分隔，并按照在配置中声明的顺序出现。不存在的头将仅作为空字符串记录。请求头捕获的常见用途包括虚拟托管环境中的“Host”字段，“Content-length”（当支持上传时），“User-agent”（以快速区分真实用户和机器人），以及代理环境中的“X-Forwarded-For”（以查找请求的来源）。请注意，在捕获“User-agent”等头时，日志中可能会包含一些空格，这会使日志分析更加困难。因此，如果您知道日志解析器不够智能，无法依赖花括号，请注意您记录的内容。捕获的请求头的数量或长度没有限制，但最好将它们保持较低以限制每个会话的内存使用。为了保持同一前端的日志格式一致，头捕获只能在前段声明。不能在“defaults”部分指定捕获。

capture request header Host len 15 capture request header X-Forwarded-For len 15 capture request header Referer len 15

捕获并记录指定响应头的最后一次出现。

可在节中使用

defaults	frontend	listen	backend
否	是	是	否

<name> 是要捕获的头的名称。头名称不区分大小写，但通常的做法是按照它们在响应中出现的样子来写，每个单词的首字母大写。头名称不会出现在日志中，只报告其值，但其在日志中的位置会得到尊重。<length> 是从值中提取并报告在日志中的最大字符数。如果字符串超过 <length>，它将被从右侧截断。

捕获该头最后一次出现的完整值。结果将在捕获的请求头之后，添加在日志中的大括号 ('{}') 之间。如果捕获了多个头，它们将由竖线 ('|') 分隔，并按照它们在配置中声明的相同顺序出现。不存在的头将被记录为空字符串。响应头捕获的常见用途包括 "Content-length" 头，它指示预计将返回多少字节，以及 "Location" 头，用于跟踪重定向。捕获的响应头数量及其长度没有限制，但明智的做法是保持它们较低以限制每个会话的内存使用。为了保持同一前端的日志格式一致，头捕获只能在前端声明。不能在 "defaults" 配置段中指定捕获。

capture response header Content-length len 9 capture response header Location len 15

设置客户端侧的最大不活动时间。

可在节中使用

defaults	frontend	listen	backend
是	是	是	否

<timeout> 超时值默认以毫秒为单位指定，但也可以是任何其他单位，如果数字后跟有单位后缀，如本文档开头所述。

不活动超时适用于客户端应确认或发送数据时。在 HTTP 模式下，此超时在第一阶段（客户端发送请求时）和响应期间（客户端读取服务器发送的数据时）尤其重要。默认情况下，该值以毫秒为单位指定，但如果数字后缀有单位，则可以为任何其他单位，如本文档顶部所述。在 TCP 模式下（以及在 HTTP 模式下，程度较小），强烈建议客户端超时与服务器超时保持相等，以避免复杂的调试情况。良好的做法是通过指定略高于 3 秒倍数的超时（例如 4 或 5 秒）来覆盖一个或多个 TCP 数据包丢失。此参数特定于前端，但可以一次性在“defaults”部分指定。这实际上是最简单的解决方案之一，以免忘记它。未指定的超时将导致无限超时，这是不推荐的。这种用法是可以接受的并且可以工作，但在启动期间会报告警告，因为它可能导致系统中累积过期的会话（如果系统超时未配置）。此参数是为了兼容性而提供的，但目前已弃用。请改用“timeout client”。

启用 HTTP 压缩。

可在节中使用

defaults	frontend	listen	backend
是	是	是	是

algo 后面是支持的压缩算法列表。type 后面是将要被压缩的 MIME 类型列表。offload 使 haproxy 仅作为压缩卸载器工作（见说明）。

当前支持的算法包括：identity 主要用于调试，对于开发压缩功能很有用。Identity 不对数据进行任何更改。gzip 应用 gzip 压缩。此设置仅在内置 zlib 或 libslz 支持时可用。deflate 与“gzip”相同，但使用 deflate 算法和 zlib 格式。请注意，此算法在许多浏览器上支持模糊，并且在最近的浏览器上完全不支持。强烈建议不要将其用于实验以外的任何目的。此设置仅在内置 zlib 或 libslz 支持时可用。raw-deflate 与“deflate”相同，但没有 zlib 包装器，当浏览器需要“deflate”时使用。所有主流浏览器都理解它，尽管违反了标准，但它比“deflate”工作得更好，至少在 MSIE 和某些版本的 Safari 上如此。不要将其与“deflate”结合使用，选择其中一个即可，因为它们都会响应相同的 Accept-Encoding 令牌。此设置仅在内置 zlib 或 libslz 支持时可用。压缩将根据 Accept-Encoding 请求头激活。使用 identity 时，它不处理该头。如果后端服务器支持 HTTP 压缩，这些指令将无效：haproxy 将看到压缩的响应，并且不会再次压缩。如果后端服务器不支持 HTTP 压缩并且请求中有 Accept-Encoding 头，haproxy 将压缩匹配的响应。“offload”设置使 haproxy 移除 Accept-Encoding 头，以防止后端服务器压缩响应。强烈建议不要这样做，因为这意味着所有压缩工作将在 haproxy 所在的单个点上完成。但是，在某些部署场景中，haproxy 可能安装在有缺陷的网关前面，该网关具有损坏的 HTTP 压缩实现，无法关闭。在这种情况下，haproxy 可以用来防止该网关发出无效的有效负载。在这种情况下，简单地在配置中删除头不起作用，因为它在头被解析之前就应用了，所以这会阻止 haproxy 进行压缩。因此，“offload”设置应用于这种情况。注意：目前，“offload”设置在 defaults 部分设置时将被忽略。当以下情况发生时，压缩将被禁用：* 请求未在“Accept-Encoding”头中声明支持的压缩算法* 响应消息不是 HTTP/1.1* HTTP 状态码不是 200* 响应头“Transfer-Encoding”包含“chunked”（临时解决方法）* 响应不包含“Content-Length”头，也不包含最后一个值为“chunked”的“Transfer-Encoding”* 响应包含“Content-Type”头，其第一个值以“multipart”开头* 响应在“Cache-control”头中包含“no-transform”值* User-Agent 匹配“Mozilla/4”，除非它是带有 XP SP2 的 MSIE 6，或 MSIE 7 及更高版本* 响应包含“Content-Encoding”头，表示响应已压缩（请参阅压缩卸载）注意：压缩不会重写 Etag 头，也不会发出 Warning 头。

compression algo gzip compression type text/html text/plain

设置等待服务器连接尝试成功的最大时间。

可在节中使用

defaults	frontend	listen	backend
是	否	是	是

<timeout> 超时值默认以毫秒为单位指定，但也可以是任何其他单位，如果数字后跟有单位后缀，如本文档开头所述。

如果服务器位于与 haproxy 相同的局域网中，连接应该会立即建立（几毫秒以内）。无论如何，通过指定略高于 3 秒倍数的超时（例如 4 或 5 秒）来覆盖一个或多个 TCP 数据包丢失是一个好习惯。默认情况下，如果队列超时未指定，连接超时也会将队列超时设置为相同的值。从历史上看，contimeout 也用于在 listen 部分设置 tarpit 超时，这在纯前端中是不可能的。此参数特定于后端，但可以一次性在“defaults”部分指定。这实际上是最简单的解决方案之一，以免忘记它。未指定的超时将导致无限超时，这是不推荐的。这种用法是可以接受的并且可以工作，但在启动期间会报告警告，因为它可能导致系统中累积失败的会话（如果系统超时未配置）。此参数是为了向后兼容性而提供的，但目前已弃用。请改用“timeout connect”、“timeout queue”或“timeout tarpit”。

在后端启用基于 cookie 的持久性。

可在节中使用

defaults	frontend	listen	backend
是	否	是	是

<name> 是将要被监控、修改或插入以实现持久性的 cookie 的名称。此 cookie 通过响应中的 "Set-Cookie" 标头发送到客户端，并在所有请求中通过客户端的 "Cookie" 标头带回。应特别注意选择一个不会与任何可能的应用程序 cookie 冲突的名称。此外，如果相同的后端服务器可能被相同的客户端使用（例如，HTTP/HTTPS），则应注意在所有后端服务器之间使用不同的 cookie 名称，除非期望它们之间存在持久性。rewrite 此关键字表示 cookie 将由服务器提供，haproxy 将不得不修改其值以在其内部设置服务器标识符。当复杂的 "Set-cookie" 和 "Cache-control" 标头组合的管理留给应用程序处理时，此模式非常方便。然后，应用程序可以决定是否发出持久性 cookie 是合适的。由于应监控所有响应，因此此模式在 HTTP 隧道模式下不起作用。除非应用程序的行为非常复杂和/或有缺陷，否则建议在新部署中不要从此模式开始。此关键字与 "insert" 和 "prefix" 不兼容。insert 此关键字表示如果客户端还没有允许其访问此服务器的 cookie，则 haproxy 将需要将其插入到服务器响应中。当不使用 "preserve" 选项时，如果服务器发出同名的 cookie，它将在处理前被删除。因此，此模式可用于升级已在 "rewrite" 模式下运行的现有配置。cookie 将仅为会话 cookie，不会存储在客户端的磁盘上。默认情况下，除非添加了 "indirect" 选项，否则服务器将看到客户端发出的 cookie。由于缓存效应，通常最好添加 "nocache" 或 "postonly" 关键字（见下文）。"insert" 关键字与 "rewrite" 和 "prefix" 不兼容。prefix 此关键字表示不是依赖于专用的持久性 cookie，而是将现有 cookie 进行补充。在某些特定环境中，客户端不支持多个 cookie，而应用程序已经需要它，这时可能需要这样做。在这种情况下，每当服务器设置名为 <name> 的 cookie 时，它都会被服务器标识符和一个分隔符前缀。前缀将从所有客户端请求中删除，以便服务器仍然找到它发出的 cookie。由于所有请求和响应都可能被修改，因此此模式不适用于隧道模式。"prefix" 关键字与 "rewrite" 和 "insert" 不兼容。注意：强烈建议不要将 "indirect" 与 "prefix" 一起使用，否则服务器 cookie 更新将不会发送到客户端。indirect 指定此选项时，如果客户端已有服务器处理请求的有效 cookie，则不会向客户端发出 cookie。如果服务器自行设置此类 cookie，它将被删除，除非还设置了 "preserve" 选项。在 "insert" 模式下，这还将从发送到服务器的请求中删除 cookie，使持久性机制对应用程序而言完全透明。注意：强烈建议不要将 "indirect" 与 "prefix" 一起使用，否则服务器 cookie 更新将不会发送到客户端。nocache 建议将此选项与 insert 模式结合使用，当客户端和 HAProxy 之间存在缓存时，因为它确保可缓存的响应将被标记为不可缓存，如果需要插入 cookie。这一点很重要，因为如果所有持久性 cookie 都添加到可缓存的主页上，例如，那么所有客户都会从外部缓存中获取页面，并共享相同的持久性 cookie，导致一个服务器接收的流量比其他服务器多得多。另请参阅 "insert" 和 "postonly" 选项。postonly 此选项确保 cookie 插入仅在对 POST 请求的响应中执行。它是 "nocache" 选项的替代方案，因为 POST 响应是不可缓存的，因此可以确保持久性 cookie 永远不会被缓存。由于大多数网站在第一次 POST 请求（通常是登录请求）之前不需要任何形式的持久性，因此这是一种在不冒缓存风险的情况下优化缓存的非常有效的方法。另请参阅 "insert" 和 "nocache" 选项。preserve 此选项只能与 "insert" 和/或 "indirect" 一起使用。它允许服务器自行发出持久性 cookie。在这种情况下，如果在响应中找到 cookie，haproxy 将保持不变。这对于例如在注销请求后结束持久性非常有用。为此，服务器只需发出具有无效值（例如，空值）或过期的 cookie。通过将此机制与 "disable-on-404" 检查选项结合使用，可以执行完全优雅的关闭，因为用户在注销后肯定会离开服务器。httponly 此选项告诉 haproxy 在插入 cookie 时添加 "HttpOnly" cookie 属性。此属性用于确保用户代理不与非 HTTP 组件共享 cookie。有关此属性的更多信息，请参阅 RFC6265。secure 此选项告诉 haproxy 在插入 cookie 时添加 "Secure" cookie 属性。此属性用于确保用户代理从不通过不安全通道发出此 cookie，这意味着带有此标志的 cookie 将仅通过 SSL/TLS 连接提供。有关此属性的更多信息，请参阅 RFC6265。domain 此选项允许指定插入 cookie 的域。它需要一个参数：一个有效的域名。如果域以点开头，则浏览器可以使用它来匹配以该名称结尾的任何主机。还可以通过多次调用此选项来指定多个域名。某些浏览器可能对域名数量有限制，因此在执行此操作时要小心。记录在案，将 10 个域发送到 MSIE 6 或 Firefox 2 可以按预期工作。maxidle 此选项允许在一段时间的空闲时间后忽略插入的 cookie。它仅适用于 insert 模式 cookie。当 cookie 发送给客户端时，也会发送 cookie 发出的日期。在进一步呈现此 cookie 时，如果日期早于参数（以秒为单位）指示的延迟，则将其忽略。否则，在将响应发送给客户端时，如果需要，它将被刷新。这对于防止从不关闭浏览器的用户在同一服务器上停留时间过长（例如，在农场规模改变后）特别有用。设置此选项且 cookie 没有日期时，始终接受 cookie，但在响应中会刷新。这保留了管理员访问其站点的能力。日期超出 24 小时（未来）的 cookie 将被忽略。这样做可以使管理员修复时区问题，而不会冒着将用户踢出站点的风险。maxlife 此选项允许在一段时间后忽略插入的 cookie，无论其是否在使用中。它仅适用于 insert 模式 cookie。当 cookie 首次发送到客户端时，也会发送 cookie 发出的日期。在进一步呈现此 cookie 时，如果日期早于参数（以秒为单位）指示的延迟，则将其忽略。如果请求中的 cookie 没有日期，则接受它并设置日期。日期超出 24 小时（未来）的 cookie 将被忽略。这样做可以使管理员修复时区问题，而不会冒着将用户踢出站点的风险。与 maxidle 不同，此值不会刷新，仅第一个访问日期有效。maxidle 和 maxlife 都可以同时使用。这对于防止从不关闭浏览器的用户在同一服务器上停留时间过长（例如，在农场规模改变后）特别有用。它比 maxidle 方法更强大，因为它强制在某个绝对延迟后重新分发。attr 此选项告诉 haproxy 在插入 cookie 时添加一个额外的属性。属性值可以包含除控制字符或 ";" 以外的任何字符。此选项可以重复。

每个 HTTP 后端只能有一个持久性 cookie，并且可以在 defaults 配置段中声明。cookie 的值将是 "server" 语句中 "cookie
此关键字可在以下配置段中使用：
按字母排序的关键字参考
Server 和 default-server 选项
获取 HTTP 样本（第 7 层）" 关键字后指定的值。如果未为给定服务器声明 cookie，则不会设置 cookie。

cookie JSESSIONID prefix cookie SRV insert indirect nocache cookie SRV insert postonly indirect cookie SRV insert indirect nocache maxidle 30m maxlife 8h

声明一个捕获槽。

可在节中使用

defaults	frontend	listen	backend
否	是	是	否

<length> 是允许捕获的长度。

此声明仅在 frontend 或 listen 配置段中可用，但保留的槽可以在 backend 中使用。“request”关键字分配一个用于请求中的捕获槽，“response”分配一个用于响应中的捕获槽。

更改后端中服务器的默认选项。

可在节中使用

defaults	frontend	listen	backend
是	否	是	是

<param*> 是此服务器的参数列表。“default-server”关键字接受许多重要选项，并有专门的完整章节进行介绍。请参阅第 5 节以获取更多详细信息。

default-server inter 1000 weight 13

指定在没有匹配到“use_backend”规则时使用的后端。

可在节中使用

defaults	frontend	listen	backend
是	是	是	否

<backend> 是要使用的后端的名称。

在使用“use_backend”关键字在前端和后端之间进行内容切换时，指明在没有规则匹配时将使用哪个后端通常很有用。这通常是动态后端，它将捕获所有未确定的请求。

use_backend dynamic if url_dyn use_backend static if url_css url_img extension_img default_backend dynamic

描述一个 listen、frontend 或 backend。

可在节中使用

defaults	frontend	listen	backend
否	是	是	是

允许添加一句话来在 HAProxy HTML 统计页面中描述相关对象。该描述将打印在其所描述对象名称的右侧。<string> 参数中的空格无需使用反斜杠转义。

禁用一个 proxy、frontend 或 backend。

可在节中使用

defaults	frontend	listen	backend
是	是	是	是

关键字 "disabled
此关键字可在以下部分找到：
Peers
按字母顺序排序的关键字参考
Server 和 default-server 选项" 用于禁用实例，主要目的是释放监听端口或临时禁用服务。实例仍将被创建，其配置也将被检查，但它将处于 "stopped" 状态，并在统计信息中显示为此状态。它不会接收任何流量，也不会发送任何健康检查或日志。通过在 "defaults" 部分添加关键字 "disabled
此关键字可在以下部分找到：
Peers
按字母顺序排序的关键字参考
Server 和 default-server 选项" 可以同时禁用多个实例。

设置一个默认服务器地址

可在节中使用

defaults	frontend	listen	backend
否	否	是	是

<address> 是默认服务器的 IPv4 地址。或者，也支持可解析的主机名，但此名称将在启动期间解析。<ports> 是一个强制性的端口规范。所有连接都将发送到此端口，并且不允许像普通服务器那样使用端口偏移量。

“dispatch”关键字指定一个默认服务器，用于在没有其他服务器可以接受连接时使用。过去它曾被用于将非持久连接转发到辅助负载均衡器。由于其语法简单，它也被用于简单的 TCP 中继。为了更清晰，建议不要使用它，而是使用“server”指令。

启用一个 proxy、frontend 或 backend。

可在节中使用

defaults	frontend	listen	backend
是	是	是	是

关键字 "enabled" 用于显式启用实例，当默认设置为 "disabled
此关键字可在以下部分找到：
Peers
按字母顺序排序的关键字参考
Server 和 default-server 选项" 时。这种情况非常少见。

返回文件内容以替代 HAProxy 生成的错误

可在节中使用

defaults	frontend	listen	backend
是	是	是	是

<code> 是 HTTP 状态码。目前，HAProxy 能够生成 200、400、403、405、408、429、500、502、503 和 504 码。<file> 指定一个包含完整 HTTP 响应的文件。建议遵循将 ".http" 追加到文件名中的常见做法，以免人们将其与 HTML 错误页面混淆，并使用绝对路径，因为文件在执行任何 chroot 之前就会被读取。

理解此关键字并非用于重写服务器返回的错误，而是用于重写 HAProxy 检测并返回的错误，这一点很重要。这就是为什么支持的错误列表仅限于一小部分。响应匹配 "monitor-uri" 规则的请求会发出 200 码。文件将按原样返回到 TCP 套接字。这允许任何技巧，例如重定向到另一个 URL 或站点，以及清理 cookie、强制启用或禁用缓存等技巧... 该软件包提供了默认错误文件，其内容与默认错误相同。文件不应超过配置的缓冲区大小 (BUFSIZE)，通常为 8 或 16 kB，否则将被截断。明智的做法是不包含任何对本地内容的引用（例如，图像），以避免在所有服务器都关闭时客户端和 HAProxy 之间发生循环，导致返回错误而不是图像。为了更好地符合 HTTP 标准，建议所有标头行都以 CR-LF 结尾，而不是单独的 LF。文件在配置的同时被读取并保存在内存中。因此，即使进程被 chroot，错误仍然会返回，并且在进程运行时不考虑文件更改。开发这些文件的一个简单方法是将它们与 403 状态码关联，并查询一个被阻止的 URL。

errorfile 400 /etc/haproxy/errorfiles/400badreq.http errorfile 408 /dev/null # 解决 Chrome 预连接的 bug errorfile 403 /etc/haproxy/errorfiles/403forbid.http errorfile 503 /etc/haproxy/errorfiles/503sorry.http

返回一个到某个 URL 的 HTTP 重定向，以替代 HAProxy 生成的错误

可在节中使用

defaults	frontend	listen	backend
是	是	是	是

<code> 是 HTTP 状态码。目前，HAProxy 能够生成 200、400、403、405、408、429、500、502、503 和 504 码。<url> 它是 "Location" 标头的确切内容。它可以包含指向同一站点上错误页面的相对 URI，或指向另一个站点上错误页面的绝对 URI。应特别注意相对 URI，以避免重定向循环（如果 URI 本身可能产生相同的错误，例如 500）。

重要的是要理解，此关键字并非用于重写服务器返回的错误，而是用于重写 HAProxy 检测并返回的错误。这就是为什么支持的错误列表仅限于一小部分。状态码 200 是为响应匹配“monitor-uri”规则的请求而发出的。请注意，这两个关键字都返回 HTTP 302 状态码，它告诉客户端使用相同的 HTTP 方法获取指定的 URL。对于非 GET 方法（如 POST），这可能会很有问题，因为发送给客户端的 URL 可能不允许 GET 以外的方法。要解决此问题，请使用“errorloc303”，它会发送 HTTP 303 状态码，指示客户端必须使用 GET 请求获取该 URL。

返回一个到某个 URL 的 HTTP 重定向，以替代 HAProxy 生成的错误

可在节中使用

defaults	frontend	listen	backend
是	是	是	是

<code> 是 HTTP 状态码。目前，HAProxy 能够生成 200、400、403、405、408、429、500、502、503 和 504 码。<url> 它是 "Location" 标头的确切内容。它可以包含指向同一站点上错误页面的相对 URI，或指向另一个站点上错误页面的绝对 URI。应特别注意相对 URI，以避免重定向循环（如果 URI 本身可能产生相同的错误，例如 500）。

重要的是要理解，此关键字并非用于重写服务器返回的错误，而是用于重写 HAProxy 检测并返回的错误。这就是为什么支持的错误列表仅限于一小部分。状态码 200 是为响应匹配“monitor-uri”规则的请求而发出的。请注意，这两个关键字都返回 HTTP 303 状态码，它告诉客户端使用相同的 HTTP GET 方法获取指定的 URL。这解决了与“errorloc”和 302 状态码相关的常见问题。一些在 HTTP/1.1 之前设计的非常旧的浏览器可能不支持它，但到目前为止还没有报告过此类问题。

声明用于电子邮件警报的信封和头部的发件人电子邮件地址。这是发送电子邮件警报的来源地址。

可在节中使用

defaults	frontend	listen	backend
是	是	是	是

<emailaddr> 是发送电子邮件警报时使用的发件人电子邮件地址

还需要设置“email-alert mailers”和“email-alert to”，如果设置了，则为该代理启用电子邮件警报发送功能。

声明将发送电子邮件警报的消息的最大日志级别。这充当发送电子邮件警报的过滤器。

可在节中使用

defaults	frontend	listen	backend
是	是	是	是

<level> 8 个 syslog 级别之一：emerg alert crit err warning notice info debug 以上 syslog 级别从低到高排序。

默认级别是 alert。还需要设置“email-alert from”、“email-alert mailers”和“email-alert to”，如果设置了，则为该代理启用电子邮件警报发送功能。在以下情况下会发送警报： * 一个未暂停的服务器被标记为 down 且 <level> 是 alert 或更低 * 一个已暂停的服务器被标记为 down 且 <level> 是 notice 或更低 * 一个服务器被标记为 up 或进入 drain 状态且 <level> 是 notice 或更低 * 启用了“option log-health-checks”，<level> 是 info 或更低，并且发生了健康检查状态更新

声明发送电子邮件警报时要使用的邮件程序

可在节中使用

defaults	frontend	listen	backend
是	是	是	是

<mailersect> 是用于发送电子邮件警报的邮件程序部分的名称。

还需要设置“email-alert from”和“email-alert to”，如果设置了，则为该代理启用电子邮件警报发送功能。

声明与邮件程序通信时要使用的主机名地址。

可在节中使用

defaults	frontend	listen	backend
是	是	是	是

<hostname> 是与邮件程序通信时使用的主机名

默认使用系统的主机名。还需要设置“email-alert from”、“email-alert mailers”和“email-alert to”，如果设置了，则为该代理启用电子邮件警报发送功能。

在电子邮件警报的信封和收件人地址中都声明收件人地址。这是发送电子邮件警报的地址。

可在节中使用

defaults	frontend	listen	backend
是	是	是	是

<emailaddr> 是发送电子邮件警报时使用的收件人电子邮件地址

还需要设置“email-alert mailers”和“email-alert to”，如果设置了，则为该代理启用电子邮件警报发送功能。

声明一个条件以强制在宕机服务器上保持持久性

可在节中使用

defaults	frontend	listen	backend
否	否	是	是

默认情况下，请求不会分派到已关闭的服务器。可以使用 "option persist" 来强制执行此操作，但它是无条件的，并且如果设置了 "option redispatch" 则会重新分派到有效服务器。这样就几乎没有可能强制某些请求到达为维护操作而人为标记为关闭的服务器。"force-persist" 语句允许声明各种基于 ACL 的条件，当这些条件满足时，将导致请求忽略服务器的关闭状态，并仍然尝试连接到它。这使得可以启动一个服务器，仍然对健康检查返回错误，并运行一个专门配置的浏览器来测试服务。在方便的方法中，可以使用特定的源 IP 地址或特定的 cookie。cookie 的优点还在于可以从测试页面轻松地在浏览器中添加/删除。一旦服务得到验证，就可以通过对健康检查返回有效响应来向全世界开放该服务。当满足 "if" 条件或不满足 "unless" 条件时，将启用强制持久性。使用此选项时，始终禁用最终的重新分发。

将过滤器 <name> 添加到附加到代理的过滤器列表中。

可在节中使用

defaults	frontend	listen	backend
否	是	是	是

<name> 是过滤器的名称。官方支持的过滤器在第 9 节中引用。<param*> 是过滤器 <name> 接受的参数列表。这些参数的解析是过滤器的责任。有关支持的参数的所有详细信息，请参阅相应过滤器（第 9 节）的文档。

对于同一个代理，可以多次使用 filter 行。如果需要，可以多次引用同一个过滤器。

listen bind *:80 filter trace name BEFORE-HTTP-COMP filter compression filter trace name AFTER-HTTP-COMP compression algo gzip compression offload server srv1 192.168.0.1:80

指定后端负载达到何种程度时服务器将达到其 maxconn

可在节中使用

defaults	frontend	listen	backend
是	否	是	是

<conns> 是后端上的连接数，该连接数将使服务器使用最大连接数。

当服务器指定了 "maxconn
此关键字在以下部分可用：
性能调优
按字母顺序排序的关键字参考
Bind 选项
Server 和 default-server 选项" 参数时，这意味着其并发连接数永远不会超过该值。此外，如果它还有一个 "minconn" 参数，则表示一个动态限制，该限制会根据后端负载进行调整。服务器将始终接受至少 <minconn> 个连接，永远不会超过 <maxconn> 个，并且当后端并发连接数少于 <conns> 时，限制将在这两个值之间变化。这使得可以在正常负载下限制服务器的负载，但在重要负载下可以进一步提高负载，而不会在异常负载下使服务器过载。由于很难正确设置此值，haproxy 会自动将其设置为可能连接到此后端的*所有前端*的 maxconn 总和的 10%（根据 "use_backend" 和 "default_backend" 规则）。这样，即使不设置它也是安全的。但是，涉及动态名称的 "use_backend" 不会被计算在内，因为无法知道它们是否会匹配。

# 服务器将接受 100 到 1000 个并发连接 # 当后端达到 10000 个连接时，将达到 1000 的最大值。 backend dynamic fullconn 10000 server srv1 dyn1:80 minconn 100 maxconn 1000 server srv2 dyn2:80 minconn 100 maxconn 1000

在软停止后，维持代理在一段时间内可操作

可在节中使用

defaults	frontend	listen	backend
是	是	是	是

<time> 是当通过 SIGUSR1 信号接收到软停止时，实例将保持可操作且前端套接字仍在监听的时间（默认为毫秒）。

这可以用来确保服务按特定顺序消失。它被设计成这样，专用于外部设备监控的前端会立即失败，而其他前端则会保持运行，直到设备检测到故障所需的时间。请注意，目前使用此参数的好处非常小，实际上它可能会使软重新配置过程复杂化，而不是简化它。

指定有界负载一致性哈希的平衡因子

可在节中使用

defaults	frontend	listen	backend
是	否	否	是

<factor> 是控制发送到服务器的最大并发请求数的参数，表示为所有活动服务器上平均并发请求数的百分比。

为具有 "hash-type consistent" 的服务器指定 "hash-balance-factor" 会启用一种算法，即使某些哈希桶接收的请求比其他请求多得多，也能防止任何单个服务器一次接收过多请求。将 <factor> 设置为 0（默认值）会禁用此功能。否则，<factor> 是一个大于 100 的百分比。例如，如果 <factor> 为 150，则任何服务器的负载都将不允许超过平均负载的 1.5 倍。如果使用了服务器权重，则会尊重这些权重。如果第一个选择的服务器不合格，算法将根据请求哈希选择另一个服务器，直到找到一个具有额外容量的服务器。较高的 <factor> 允许服务器之间的不平衡度更大，而较低的 <factor> 意味着平均会检查更多的服务器，从而影响性能。合理的值在 125 到 200 之间。

指定一种将哈希值映射到服务器的方法

可在节中使用

defaults	frontend	listen	backend
是	否	是	是

<method> 是用于从 <function> 计算出的哈希中选择服务器的方法：map-based 哈希表是一个包含所有存活服务器的静态数组。哈希值将非常平滑，会考虑权重，但会是静态的，意味着当服务器运行时更改权重将被忽略。这意味着不会有慢启动。此外，由于服务器是通过其在数组中的位置选择的，因此当服务器计数发生变化时，大多数映射都会被更改。这意味着当服务器上线或下线，或当服务器添加到集群时，大多数连接将被重新分配到不同的服务器。这对缓存来说可能不方便。consistent 哈希表是一个包含每个服务器许多副本的树。哈希键在树中查找，并选择最接近的服务器。此哈希是动态的，它支持在服务器运行时更改权重，因此与慢启动功能兼容。它的优点是，当服务器上线或下线时，只有它的关联会发生移动。当服务器添加到集群时，只有一部分映射会被重新分配，这使其成为缓存的理想方法。然而，由于其原理，分布永远不会非常平滑，有时可能需要调整服务器的权重或其 ID 来获得更均衡的分布。为了在多个负载均衡器上获得相同的分布，所有服务器具有完全相同的 ID 非常重要。注意：如果未指定哈希函数，consistent hash 使用 sdbm 和 avalanche。<function> 是要使用的哈希函数：sdbm 此函数最初是为 sdbm（ndbm 的公共领域重新实现）数据库库创建的。它在打乱位方面表现良好，能够更好地分布键并减少分裂。它也是一个很好的通用哈希函数，分布良好，除非总服务器权重是 64 的倍数，在这种情况下，应用 avalanche 修饰符可能会有帮助。djb2 此函数多年前由 Dan Bernstein 在 comp.lang.c 上首次提出。研究表明，对于某些工作负载，此函数比 sdbm 提供更好的分布。它通常与基于文本的输入一起使用，尽管它在仅数字输入或总服务器权重是 33 的倍数时表现极差，除非也使用了 avalanche 修饰符。wt6 此函数是在过去测试其他函数时为 haproxy 设计的。它不如其他函数平滑，但对输入数据集或服务器数量的敏感度要低得多。在一致性哈希或对数字数据（如源 IP 地址或 URL 参数中的访问者标识符）进行哈希时，它可以作为 sdbm+avalanche 或 djb2+avalanche 的替代方案。crc32 这是以太网、gzip、PNG 等使用的最常见的 CRC32 实现。它比其他实现慢，但可能提供更好的分布或更不可预测的结果，尤其是在字符串上使用时。<modifier> 指示在对键进行哈希后应用的可选方法：avalanche 此指令表示不应直接使用上述哈希函数的结果，而是应首先应用一个 4 字节的全雪崩哈希。此步骤的目的是混合前一个哈希的结果位，以避免在输入包含某些有限值或服务器数量是哈希组件（SDBM 为 64，DJB2 为 33）的倍数时出现任何不良影响。启用 avalanche 倾向于使结果更不可预测，但它也不如使用原始函数时平滑。可能需要对某些工作负载进行一些测试。此哈希是 Bob Jenkins 提出的众多哈希之一。

默认的哈希类型是“map-based”，建议在大多数情况下使用。默认的函数是“sdbm”，函数的选择应基于被哈希值的范围。

在对健康检查响应 HTTP/404 时启用维护模式

可在节中使用

defaults	frontend	listen	backend
是	否	是	是

当设置此选项时，返回 HTTP 404 状态码的服务器将从进一步的负载均衡中排除，但仍会接收持久连接。这为 Web 管理员提供了一种非常方便的方法来优雅地关闭他们的服务器。同样重要的是要注意，在此模式下被检测为失败的服务器不会生成警报，只会生成一个通知。如果服务器再次响应 2xx 或 3xx，它将立即被重新插入到服务器组中。在统计页面上，处于此模式的服务器状态报告为“NOLB”。重要的是要注意，此选项仅与“httpchk”选项一起使用。如果此选项与“http-check expect”一起使用，则它优先于后者，因此 404 响应仍将被视为软停止。

使 HTTP 健康检查考虑响应内容或特定状态码

可在节中使用

defaults	frontend	listen	backend
是	否	是	是

<match> 是一个关键字，指示如何在响应中查找特定模式。该关键字可以是“status”、“rstatus”、“string”或“rstring”之一。关键字前面可以加上感叹号（“!”）以否定匹配。感叹号和关键字之间允许有空格。有关支持的关键字的更多详细信息，请参见下文。<pattern> 是要查找的模式。它可以是字符串或正则表达式。如果模式包含空格，必须使用通常的反斜杠（'\'）进行转义。

默认情况下，"option httpchk" 认为响应状态码 2xx 和 3xx 是有效的，其他都是无效的。当使用 "http-check expect" 时，它定义了什么是有效或无效的。每个后端只支持一个 "http-check" 语句。如果服务器未能响应或超时，检查显然会失败。可用的匹配有：status <string>：测试 HTTP 状态码的确切字符串匹配。如果响应的状态码与此字符串完全匹配，则健康检查响应将被视为有效。如果 "status" 关键字前面加上 "!"，则如果状态码匹配，响应将被视为无效。rstatus <regex>：测试 HTTP 状态码的正则表达式。如果响应的状态码与表达式匹配，则健康检查响应将被视为有效。如果 "rstatus" 关键字前面加上 "!"，则如果状态码匹配，响应将被视为无效。这主要用于检查多个代码。string <string>：测试 HTTP 响应正文中的确切字符串匹配。如果响应正文包含此确切字符串，则健康检查响应将被视为有效。如果 "string" 关键字前面加上 "!"，则如果正文包含此字符串，响应将被视为无效。这可用于查找动态页面末尾的必需单词，或检测检查页面上出现特定错误（例如，堆栈跟踪）时的失败。rstring <regex>：在 HTTP 响应正文上测试正则表达式。如果响应正文与表达式匹配，则健康检查响应将被视为有效。如果 "rstring" 关键字前面加上 "!"，则如果正文匹配表达式，响应将被视为无效。这可用于查找动态页面末尾的必需单词，或检测检查页面上出现特定错误（例如，堆栈跟踪）时的失败。需要注意的是，响应将被限制在全局 "tune.chksize" 选项定义的特定大小内，该选项默认为 16384 字节。因此，在使用 "string" 或 "rstring" 时，过大的响应可能不包含必需的模式。如果绝对需要大响应，可以通过设置全局变量来更改默认的最大大小。但是，需要记住的是，解析非常大的响应会浪费一些 CPU 周期，尤其是在使用正则表达式时，并且最好始终将检查重点放在较小的资源上。此外，"http-check expect" 不支持 HTTP keep-alive。请记住，它会自动添加 "Connection: close" 头，这意味着此头不应存在于 "option httpchk" 提供的请求中。最后，如果 "http-check expect" 与 "http-check disable-on-404" 结合使用，则当服务器响应 404 时，后者具有优先权。

# 只接受状态 200 为有效 http-check expect status 200 # 将 SQL 错误视为错误 http-check expect ! string SQL\ Error # 仅将状态 5xx 视为错误 http-check expect ! rstatus ^5 # 检查在 /html 之前是否有一个正确的十六进制标签 http-check expect rstring <!--tag:[0-9a-f]*--></html>

启用在 HTTP 健康检查中发送状态头