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

当 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 个字段组成：- 一个方法 (METHOD)：GET - 一个 URI：/serv/login.php?lang=en&profile=2 - 一个版本标签 (version tag)：HTTP/1.1 所有这些都由标准所谓的 LWS（线性空白）分隔，通常是空格，但也可以是制表符或换行符/回车符后跟空格/制表符。方法本身不能包含任何冒号（':'），并且仅限于字母。所有这些不同的组合使得 HAProxy 最好自己进行拆分，而不是让用户编写复杂或不准确的正则表达式。URI 本身可以有几种形式：- “相对 URI” (relative URI)：/serv/login.php?lang=en&profile=2 这是一个没有主机部分的完整 URL。这通常是服务器、反向代理和透明代理接收到的内容。- “绝对 URI” (absolute 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 在索引标头、检查值和计数时会处理所有这些复杂的组合，因此无需担心它们的书写方式，但重要的是不要因为一个应用程序做了不寻常但有效的操作而指责它有错误。重要说明：根据 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 - log - log-tag - log-send-hostname - lua-load - nbproc - node - pidfile - uid - ulimit-n - user - 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 - 51degrees-data-file - 51degrees-property-name-list - 51degrees-property-separator - 51degrees-cache-size * 性能调优 - 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.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.reqres-max-size - tune.vars.sess-max-size - tune.vars.txn-max-size - tune.zlib.memlevel - tune.zlib.windowsize * 调试 - debug - quiet

当使用相对路径与 "ca-file
此关键字可在以下部分使用：
绑定选项
服务器和默认服务器选项" 或 "crl-file
此关键字可在以下部分使用：
绑定选项
服务器和默认服务器选项" 指令时，分配一个用于获取 SSL CA 证书和 CRL 的默认目录。在 "ca-file
此关键字可在以下部分使用：
绑定选项
服务器和默认服务器选项" 和 "crl-file
此关键字可在以下部分使用：
绑定选项
服务器和默认服务器选项" 中指定的绝对位置优先，并忽略 "ca-base"。

在降低权限之前，将当前目录更改为 <jail dir> 并在那里执行 chroot()。这在未知漏洞被利用的情况下提高了安全级别，因为它会使攻击者很难利用系统。这仅在进程以超级用户权限启动时有效。确保 <jail_dir> 为空且对任何人都是不可写的，这很重要。

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

使进程 fork 到后台运行。这是推荐的操作模式。它等同于命令行参数 "-D"。它可以通过命令行参数 "-db" 禁用。

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

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

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

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

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

将进程的组 ID 更改为 <number>。建议该组 ID 专用于 HAProxy 或一小组类似的守护进程。HAProxy 必须以属于该组的用户或以超级用户权限启动。请注意，如果 haproxy 从具有附加组的用户启动，它只有在以超级用户权限启动时才能放弃这些组。另请参阅 "group
此关键字可在以下部分使用：
进程管理与安全
用户列表
绑定选项" 和 "uid
此关键字可在以下部分使用：
进程管理与安全
绑定选项"。

与 "gid
此关键字可在以下部分使用：
进程管理与安全
绑定选项" 类似，但使用 /etc/group 中组名 <group name> 的 GID。另请参阅 "gid
此关键字可在以下部分使用：
进程管理与安全
绑定选项" 和 "user
此关键字可在以下部分使用：
进程管理与安全
用户列表
绑定选项"。

添加一个全局 syslog 服务器。可以定义多个全局服务器。它们将接收启动和退出的日志，以及所有配置了 "log global" 的代理的日志。<address> 可以是以下之一： - 一个 IPv4 地址，后面可选地跟一个冒号和一个 UDP 端口。如果未指定端口，则默认使用 514（标准 syslog 端口）。 - 一个 IPv6 地址，后面跟一个冒号和可选的 UDP 端口。如果未指定端口，则默认使用 514（标准 syslog 端口）。 - 一个指向 UNIX 域套接字的文件系统路径，同时要考虑 chroot 的情况（确保路径在 chroot 内可访问）和 uid/gid（确保路径具有适当的写权限）。您可能希望在地址参数中引用一些环境变量，请参阅关于环境变量的 第 2.3 节。<length> 是可选的最大行长度。大于此值的日志行在发送前将被截断。原因是不同的 syslog 服务器对日志行长度的处理方式不同。所有服务器都支持默认值 1024，但一些服务器会简单地丢弃更长的行，而另一些则会记录它们。如果服务器支持长行，那么在此处设置此值以避免截断长行可能是有意义的。类似地，如果服务器丢弃长行，最好在发送前截断它们。可接受的值为 80 到 65535（含）。对于所有标准用法，默认值 1024 通常是合适的。某些特定情况下的长捕获或 JSON 格式的日志可能需要更大的值。<format> 是生成 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 文件。此指令可以多次使用。

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

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

将统计套接字限制在一组特定的进程号上。默认情况下，统计套接字绑定到所有进程，当 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"。

此设置仅在编译时支持 OpenSSL 时可用。它为所有未明确定义密码算法列表的 "bind" 行设置默认字符串，该字符串描述在 SSL/TLS 握手期间协商的密码算法列表（“密码套件”）。该字符串的格式在 OpenSSL 手册页的 "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 时可用。它为所有未明确定义密码算法列表的 "server" 行设置默认字符串，该字符串描述在与服务器进行 SSL/TLS 握手期间协商的密码算法列表。该字符串的格式在 "man 1 ciphers" 中定义。请查看 "server" 关键字以获取更多信息。

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

此设置仅在编译时支持 OpenSSL 时可用。它为所有未明确定义 DH 参数的 "bind" 行设置默认 DH 参数，这些参数在 SSL/TLS 握手期间使用临时 Diffie-Hellman（DHE）密钥交换时使用。如果绑定证书文件中存在自定义 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.2 节“Unix 套接字命令”以获取更多详细信息。支持 "bind" 行支持的所有参数，例如限制某些用户或其访问权限的访问。请查阅第 5.1 节以获取更多信息。

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

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

将进程的用户 ID 更改为 <number>。建议该用户 ID 专用于 HAProxy 或一小组类似的守护进程。HAProxy 必须以超级用户权限启动才能切换到另一个用户。另请参阅 "gid
This keyword is available in sections :
Process management and security
Bind options" 和 "user
This keyword is available in sections :
Process management and security
Userlists
Bind options"。

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

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

与 "uid
This keyword is available in sections :
Process management and security
Bind options" 类似，但使用 /etc/passwd 中用户名 <user name> 的 UID。另请参阅 "uid
This keyword is available in sections :
Process management and security
Bind options" 和 "group
This keyword is available in sections :
Process management and security
Userlists
Bind options"。

只允许字母、数字、连字符和下划线，与 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 时可用。

默认情况下，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 和 map 用于慢速模式查找，即使用 "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 使用率。

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

设置全局 SSL 会话缓存的大小，以块为单位。一个块足够大，可以容纳一个没有对等证书的编码会话。带有对等证书的编码会话根据对等证书的大小存储在多个块中。一个块大约使用 200 字节的内存。默认值可以在构建时强制指定，否则默认为 20000。当缓存已满时，最空闲的条目将被清除并重新分配。较高的值可以减少这种清除的发生，从而通过确保所有用户尽可能长时间地保持其会话来减少 CPU 密集型的 SSL 握手次数。如果 "nbproc
This keyword is available in sections :
Process management and security
Fetching samples from internal states" 大于 1，所有条目在启动时预先分配，并在所有进程之间共享。将此值设置为 0 会禁用 SSL 会话缓存。

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

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

设置一次传递给 SSL_write() 的最大字节数。默认值 0 表示没有限制。通过 SSL/TLS，客户端只有在收到完整的记录后才能解密数据。对于大记录，这意味着客户端可能需要下载多达 16kB 的数据才能开始处理它们。限制该值可以改善位于高延迟或低带宽网络上的浏览器的页面加载时间。建议找到适合 1 或 2 个 TCP 段（通常在以太网上启用 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 个条目。

这四个调整项有助于管理变量系统使用的最大内存量。"global" 限制所有作用域可用的总内存量。"sess" 限制会话作用域的内存，"txn" 限制事务作用域的内存，"reqres" 限制每个请求或响应处理的内存。内存核算是分层的，意味着更粗粒度的限制包含更细粒度的限制："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

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

支持以下关键字列表。它们中的大多数只能在有限的几种配置段类型中使用。其中一些被标记为“已弃用”(deprecated)，因为它们继承自可能令人困惑或功能受限的旧语法，并且有新的推荐关键字来替代它们。标有“(*)”的关键字可以选择性地使用“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
fullconn
grace
hash-type
http-check disable-on-404
http-check expect
http-check send-state
http-request
http-response
http-reuse
关键字	defaults	frontend	listen	backend
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
(*)option clitcpka
关键字	defaults	frontend	listen	backend
(*)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
option external-check
关键字	defaults	frontend	listen	backend
(*)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 srvtcpka
option ssl-hello-chk
option tcp-check
(*)option tcp-smart-accept
关键字	defaults	frontend	listen	backend
(*)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
reqipass
reqirep
关键字	defaults	frontend	listen	backend
reqitarpit
reqpass
reqrep
reqtarpit
retries
rspadd
rspdel
rspdeny
rspidel
rspideny
rspirep
rsprep
server
server-state-file-name
source
(已弃用)srvtimeout
stats admin
stats auth
stats enable
stats hide-version
关键字	defaults	frontend	listen	backend
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
tcp-request content
tcp-request inspect-delay
关键字	defaults	frontend	listen	backend
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
unique-id-format
unique-id-header
use_backend
关键字	defaults	frontend	listen	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 将需要为每个新会话学习该 cookie。 <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
此关键字可在以下配置段中使用：
按字母排序的关键字参考
Bind 选项
Server 和 default-server 选项"），默认为服务器在集群中的位置。一旦服务器达到其 maxconn 值，就使用下一个服务器。不设置 maxconn 就使用此算法是没有意义的。此算法的目的是始终使用最少数量的服务器，以便在非繁忙时段可以关闭多余的服务器。此算法忽略服务器权重，对长会话（如 RDP 或 IMAP）比 HTTP 带来更多好处，尽管在 HTTP 中也可能有用。为了有效使用此算法，建议云控制器定期检查服务器使用情况，在未使用时关闭它们，并定期检查后端队列，在队列膨胀时启动新服务器。或者，使用 "http-check send-state" 可以通知服务器负载情况。 source 源 IP 地址被哈希并除以运行中服务器的总权重，以指定哪台服务器将接收请求。这确保了只要没有服务器宕机或上线，相同的客户端 IP 地址将始终访问同一台服务器。如果由于运行中服务器数量的变化导致哈希结果改变，许多客户端将被导向到不同的服务器。此算法通常用于 TCP 模式，其中无法插入 cookie。它也可以在互联网上使用，为拒绝会话 cookie 的客户端提供尽力而为的粘性。此算法默认是静态的，这意味着实时更改服务器权重将没有效果，但这可以通过使用 "hash-type" 来改变。 uri 此算法对 URI 的左半部分（问号之前）或整个 URI（如果存在 "whole" 参数）进行哈希，并将哈希值除以运行中服务器的总权重。结果指定哪台服务器将接收请求。这确保了只要没有服务器上线或宕机，相同的 URI 将始终被导向到同一台服务器。这用于代理缓存和反病毒代理，以最大化缓存命中率。请注意，此算法只能在 HTTP 后端中使用。此算法默认是静态的，这意味着实时更改服务器权重将没有效果，但这可以通过使用 "hash-type" 来改变。此算法支持两个可选参数 "len" 和 "depth"，两者都后跟一个正整数。当需要仅根据 URI 的开头来均衡服务器时，这些选项可能很有用。"len" 参数表示算法应仅考虑 URI 开头的那么多字符来计算哈希。请注意，将 "len" 设置为 1 很少有意义，因为大多数 URI 以一个前导 "/" 开头。"depth" 参数表示用于计算哈希的最大目录深度。请求中的每个斜杠都算作一个级别。如果两个参数都指定了，当任一参数达到时评估就会停止。 url_param 将在每个 HTTP GET 请求的查询字符串中查找参数中指定的 URL 参数。如果使用了 "check_post" 修饰符，那么当在 URL 中的问号（'?'）后的查询字符串中找不到参数时，将在 HTTP POST 请求实体中搜索该参数。只有在收到已通告的数据量或请求缓冲区已满时，才会开始分析消息体。在极少数情况下使用分块编码时，只扫描第一个分块。被分块边界分隔的参数值可能会被随机均衡（如果可能的话）。此关键字曾支持一个可选的 <max_wait> 参数，现在已被忽略。如果找到参数后跟一个等号（'='）和一个值，则该值被哈希并除以运行中服务器的总权重。结果指定哪台服务器将接收请求。这用于在请求中跟踪用户标识符，并确保只要没有服务器上线或宕机，同一用户 ID 将始终被发送到同一台服务器。如果没有找到值或没有找到参数，则应用轮询算法。请注意，此算法只能在 HTTP 后端中使用。此算法默认是静态的，这意味着实时更改服务器权重将没有效果，但这可以通过使用 "hash-type" 来改变。 hdr(<name>) HTTP 头部 <name> 将在每个 HTTP 请求中被查找。就像等效的 ACL 'hdr()' 函数一样，括号中的头部名称不区分大小写。如果头部不存在或不包含任何值，则应用轮询算法。有一个可选的 'use_domain_only' 参数可用，用于将哈希算法缩减到主域部分，适用于某些特定的头部，如 'Host'。例如，在 Host 值 "haproxy.1wt.eu" 中，只会考虑 "1wt"。此算法默认是静态的，这意味着实时更改服务器权重将没有效果，但这可以通过使用 "hash-type" 来改变。 rdp-cookie rdp-cookie(<name>) RDP cookie <name>（如果省略，则为 "mstshash"）将在每个传入的 TCP 请求中被查找和哈希。就像等效的 ACL 'req_rdp_cookie()' 函数一样，名称不区分大小写。此机制作为一种降级的持久性模式很有用，因为它使得始终将同一用户（或同一会话 ID）发送到同一台服务器成为可能。如果找不到 cookie，则使用正常的轮询算法。请注意，为使其工作，前端必须确保请求缓冲区中已存在 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

注意：在使用带“url_param”的“check_post”扩展时，必须考虑以下注意事项和限制： - 所有 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，否则将被强制到所有进程。

此关键字将某些实例的绑定限制在某些进程上。这对于避免有太多进程监听相同端口非常有用。例如，在一台双核机器上，在全局配置段中设置 'nbproc 2'，然后将监听器分配给 'odd' 和 'even' 实例可能是有意义的。目前，使用此关键字无法引用超过 32 或 64 个进程，但这对于大多数设置应该足够了。请注意，'all' 真正意味着所有进程，无论机器的字长如何，并不限于前 32 或 64 个。每个 "bind" 行可以进一步限制在代理进程的一个子集上，请参阅第 5.1 节中的 "process" bind 关键字。当前端没有显式的 "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
否	是	是	是

如果/除非 <condition> 匹配，HTTP 请求将在第 7 层处理的早期阶段被阻止。如果请求被阻止，将返回一个 403 错误。条件必须引用 ACL（参见第 7 节）。这通常用于在满足或不满足某些条件时，拒绝访问某些敏感资源。每个实例的 "block" 语句数量没有固定限制。此形式已弃用，请不要在任何新配置中使用它，请改用新的 "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

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

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

可在以下配置段中使用

defaults	frontend	listen	backend
否	是	是	否

<name> 是要捕获的 cookie 名称的开头部分。为了匹配确切的名称，只需在名称后加上一个等号（'='）。完整的名称将出现在日志中，这对于那些会同时调整 cookie 名称和值的应用服务器（例如：ASPSESSIONXXXXX）很有用。<length> 是日志中报告的最大字符数，包括 cookie 名称、等号和值，全部采用标准的 "name=value" 形式。如果字符串超过 <length>，它将被从右侧截断。

只捕获第一个 cookie。请求头中的 "cookie
此关键字可在以下配置段中使用：
按字母排序的关键字参考
Server 和 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" 设置应该用于此类场景。注意：目前，在 defaults 配置段中设置 "offload" 会被忽略。 在以下情况下禁用压缩： * 请求的 "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" 头，表明响应已经被压缩（参见 compression offload） 注意：压缩不会重写 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，则持久性 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 在客户端和 HAProxy 之间有缓存的情况下，建议与 insert 模式结合使用此选项，因为它确保如果需要插入 cookie，可缓存的响应将被标记为不可缓存。这很重要，因为如果所有的持久性 cookie 都添加在一个可缓存的主页上，那么所有的客户都将从外部缓存中获取该页面，并且都将共享相同的持久性 cookie，导致一台服务器接收的流量远多于其他服务器。另请参阅 "insert" 和 "postonly" 选项。 postonly 此选项确保 cookie 插入将仅在对 POST 请求的响应上执行。它是 "nocache" 选项的替代方案，因为 POST 响应是不可缓存的，所以这确保了持久性 cookie 永远不会被缓存。由于大多数网站在第一次 POST（通常是登录请求）之前不需要任何形式的持久性，这是一种优化缓存而不会有在缓存中找到持久性 cookie 风险的非常有效的方法。另请参阅 "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 的域。它需要一个参数：一个有效的域名。如果域名以点开头，浏览器允许将其用于任何以该名称结尾的主机。也可以通过多次调用此选项来指定多个域名。某些浏览器可能对域名数量有小的限制，所以这样做时要小心。作为记录，向 MSIE 6 或 Firefox 2 发送 10 个域名可以正常工作。 maxidle 此选项允许插入的 cookie 在闲置一段时间后被忽略。它仅适用于插入模式的 cookie。当 cookie 发送给客户端时，该 cookie 的发出日期也会被发送。在后续呈现此 cookie 时，如果日期比参数指示的延迟（以秒为单位）更早，它将被忽略。否则，当响应发送给客户端时，如果需要，它将被刷新。这对于防止那些从不关闭浏览器的用户在同一台服务器上停留太长时间（例如：在服务器集群大小更改后）特别有用。当设置此选项且 cookie 没有日期时，它总是被接受，但在响应中会被刷新。这保留了管理员访问其网站的能力。日期在未来超过 24 小时的 cookie 会被忽略。这样做可以让管理员修复时区问题，而不会有将用户踢出网站的风险。 maxlife 此选项允许插入的 cookie 在一定生命周期后被忽略，无论它们是否在使用中。它仅适用于插入模式的 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 选项”关键字用于禁用一个实例，主要目的是为了释放一个监听端口或临时禁用一个服务。该实例仍会被创建，其配置也会被检查，但它将以“停止”状态创建，并在统计信息中显示为该状态。它不会接收任何流量，也不会发送任何健康检查或日志。通过在“defaults”部分添加“disabled
此关键字在以下部分可用：
Peers
按字母排序的关键字参考
Server 和 default-server 选项”关键字，可以一次性禁用多个实例。

设置一个默认服务器地址

可在以下配置段中使用

defaults	frontend	listen	backend
否	否	是	是

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

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

启用一个 proxy、frontend 或 backend。

可在以下配置段中使用

defaults	frontend	listen	backend
是	是	是	是

“enabled”关键字用于显式启用一个实例，当 defaults 已被设置为“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 检测并返回的错误。这就是为什么支持的错误列表仅限于一小部分。状态码 200 是为响应匹配“monitor-uri”规则的请求而发出的。文件内容会原样返回到 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”条件时，强制持久性将被启用。使用此功能时，最终的重新分派总是被禁用的。

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

可在以下配置段中使用

defaults	frontend	listen	backend
是	否	是	是

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

当服务器指定了“maxconn
此关键字在以下部分可用：
性能调优
按字母排序的关键字参考
Bind 选项
Server 和 default-server 选项”参数时，表示其并发连接数永远不会更高。此外，如果它有“minconn”参数，则表示一个根据后端负载动态变化的限制。服务器将始终接受至少 <minconn> 个连接，绝不会超过 <maxconn>，并且当后端的并发连接数少于 <conns> 时，限制将在两个值之间平滑过渡。这使得在正常负载期间可以限制服务器上的负载，但在重要负载时可以进一步推高负载，而不会在异常负载期间使服务器过载。由于很难正确设置此值，haproxy 会自动将其设置为所有可能分支到此后端的（基于“use_backend”和“default_backend”规则）前端 maxconn 总和的 10%。这样，不设置它也是安全的。但是，涉及动态名称的“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
是	否	是	是

<method> 是用于从 <function> 计算出的哈希值中选择服务器的方法： map-based 哈希表是一个包含所有活动服务器的静态数组。哈希值将非常平滑，会考虑权重，但是是静态的，即服务器运行时权重的变化将被忽略。这意味着不会有慢启动。此外，由于服务器是根据其在数组中的位置选择的，当服务器数量变化时，大多数映射都会改变。这意味着当服务器上线或下线，或者当服务器添加到服务器组时，大多数连接将被重新分配到不同的服务器。这对于缓存等场景可能不方便。 consistent 哈希表是一个填充了每个服务器多次出现的树。哈希键在树中查找，并选择最近的服务器。这种哈希是动态的，它支持在服务器运行时更改权重，因此与慢启动功能兼容。它的优点是，当服务器上线或下线时，只有它的关联被移动。当服务器添加到服务器组时，只有一小部分映射被重新分配，使其成为缓存的理想方法。然而，由于其原理，分布永远不会非常平滑，有时可能需要调整服务器的权重或其 ID 以获得更平衡的分布。为了在多个负载均衡器上获得相同的分布，重要的是所有服务器都具有完全相同的 ID。注意：如果没有指定哈希函数，一致性哈希使用 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 健康检查中发送状态头

可在以下配置段中使用

defaults	frontend	listen	backend
是	否	是	是

设置此选项后，haproxy 将系统性地发送一个特殊的“X-Haproxy-Server-State”头，其中包含一系列参数，向每个服务器指示 haproxy 如何看待它们。例如，当一个服务器在无法访问 haproxy 的情况下被操作，并且操作员需要知道 haproxy 是否仍然认为它在线，或者该服务器是否是服务器组中的最后一个时，这可能很有用。该头由分号分隔的字段组成，第一个字段是一个词（“UP”、“DOWN”、“NOLB”），后面可能跟着转换前的总检查次数中的有效检查次数，就像在统计界面中显示的那样。接下来的头是“<variable>=<value>”的形式，以无特定顺序指示统计界面中可用的一些值： - 一个变量“address”，包含后端服务器的地址。这对应于服务器声明中的 <address> 字段。对于 unix 域套接字，它将显示“unix”。 - 一个变量“port”，包含后端服务器的端口。这对应于服务器声明中的 <port> 字段。对于 unix 域套接字，它将显示“unix”。 - 一个变量“name”，包含后端名称后跟一个斜杠（“/”）然后是服务器名称。当一个服务器在多个后端中被检查时，这很有用。 - 一个变量“node”，包含 haproxy 节点的名称，如全局“node”变量中所设置，否则为系统的未指定主机名。 - 一个变量“weight”，表示服务器的权重，一个斜杠（“/”）和服务器组的总权重（仅计算可用的服务器）。这有助于了解当此服务器失败时是否有其他服务器可用来处理负载。 - 一个变量“scur”，表示服务器上当前的并发连接数，后跟一个斜杠（“/”）然后是同一后端所有服务器上的总连接数。 - 一个变量“qcur”，表示服务器队列中当前的请求数。 应用服务器接收到的头示例： >>> X-Haproxy-Server-State: UP 2/3; name=bck/srv2; node=lb1; weight=1/2; \ scur=13/22; qcur=0

第 7 层请求的访问控制

可在以下配置段中使用

defaults	frontend	listen	backend
否	是	是	是

http-request 语句定义了一组适用于第 7 层处理的规则。这些规则在 frontend、listen 或 backend 部分遇到时，会按其声明顺序进行评估。任何规则都可以选择性地后跟一个基于 ACL 的条件，在这种情况下，只有当条件为真时，该规则才会被评估。第一个关键字是规则的操作。目前支持的操作包括： - “allow”：停止规则评估，让请求通过检查。不再评估后续的“http-request”规则。 - “deny”：停止规则评估，并立即拒绝请求，发出一个 HTTP 403 错误，或者可选地发出“deny_status”参数指定的状码。允许的状态码列表仅限于那些可以被“errorfile”指令覆盖的状态码。不再评估后续的“http-request”规则。 - “tarpit”：停止规则评估，并立即阻塞请求，在由“timeout tarpit”或（如果前者未设置）“timeout connect”指定的延迟时间内不响应。在该延迟之后，如果客户端仍然连接，则返回一个 HTTP 500 错误，这样客户端就不会怀疑它被“tarpitted”（拖延）了。日志将报告标志“PT”。tarpit 规则的目标是在攻击期间减慢机器人的速度，当它们在并发请求数量上受到限制时。它对非常愚蠢的机器人非常有效，并且与“deny”规则相比，将显著减少防火墙的负载。但当面对“正确”开发的机器人时，它可能会通过强迫 haproxy 和前端防火墙支持疯狂数量的并发连接而使情况变得更糟。另请参阅下面的“silent-drop”操作。 - “auth”：停止规则评估，并立即以 HTTP 401 或 407 错误代码响应，以邀请用户提供有效的用户名和密码。不再评估后续的“http-request”规则。支持一个可选的“realm”参数，它设置与响应一起返回的认证领域（通常是应用程序的名称）。 - “redirect”：根据重定向规则执行 HTTP 重定向。这与“redirect”语句完全相同，只是它插入了一个可以在其他“http-request”规则中间处理的重定向规则，并且这些规则使用“log-format”字符串。有关规则的语法，请参阅“redirect”关键字。 - “add-header”附加一个 HTTP 头字段，其名称在 <name> 中指定，其值由 <fmt> 定义，<fmt> 遵循日志格式规则（请参阅第 8.2.4 节中的自定义日志格式）。这对于将连接特定的信息传递给服务器（例如：客户端的 SSL 证书），或将多个头合并为一个特别有用。此规则不是最终规则，因此可以添加其他类似的规则。请注意，头的添加是立即执行的，因此一个规则可能会重用前一个规则产生的头。 - “set-header”与“add-header”作用相同，只是首先会移除已存在的同名头。这在向服务器传递安全信息时很有用，此时头不能被外部用户操纵。请注意，新值是在移除之前计算的，因此可以将一个值连接到现有头。 - “del-header”移除所有名称在 <name> 中指定的 HTTP 头字段。 - “replace-header”根据 <match-regex> 匹配头字段 <name> 的所有出现中的正则表达式，并用 <replace-fmt> 参数替换它们。<replace-fmt> 中允许使用格式字符，其工作方式与“add-header”中的 <fmt> 参数类似。匹配是区分大小写的。重要的是要理解，此操作只考虑整个头行，而不管它们可能包含多少个值。此用法适用于值中自然包含逗号的头，例如 If-Modified-Since 等。

http-request replace-header Cookie foo=([^;]*);(.*) foo=\1;ip=%bi;\2

应用于： Cookie: foo=foobar; expires=Tue, 14-Jun-2016 01:40:45 GMT; 输出： Cookie: foo=foobar;ip=192.168.1.20; expires=Tue, 14-Jun-2016 01:40:45 GMT; 假设后端 IP 是 192.168.1.20 - “replace-value”的工作方式与“replace-header”类似，但它将正则表达式与头字段 <name> 的每个逗号分隔的值进行匹配，而不是整个头。这适用于允许携带多个值的所有头。一个例子可以是 Accept 头。

http-request replace-value X-Forwarded-For ^192\.168\.(.*)$ 172.16.\1

应用于： X-Forwarded-For: 192.168.10.1, 192.168.13.24, 10.0.0.37 输出： X-Forwarded-For: 172.16.10.1, 172.16.13.24, 10.0.0.37 - “set-method”用格式字符串 <fmt> 的评估结果重写请求方法。很少有正当理由需要这样做，因为这更有可能破坏某些东西而不是修复它。 - “set-path”用格式字符串 <fmt> 的评估结果重写请求路径。查询字符串（如果有）保持不变。如果在路径之前找到方案和授权机构，它们也保持不变。如果请求没有路径（“*”），则用格式替换它。这可以用于在路径前添加一个目录组件。另请参阅“set-query”和“set-uri”。

# 在路径前添加主机名 http-request set-path /%[hdr(host)]%[path]

- “set-query”用格式字符串 <fmt> 的评估结果重写请求的查询字符串，该字符串出现在第一个问号（“?”）之后。问号之前的部分保持不变。如果请求不包含问号并且新值不为空，则在 URI 的末尾添加一个问号，后跟新值。如果问号存在，即使值为空，它也永远不会被移除。这可以用于从查询字符串中添加或删除参数。另请参阅“set-query”和“set-uri”。

# 在查询字符串中将“%3D”替换为“=” http-request set-query %[query,regsub(%3D,=,g)]

- “set-uri”用格式字符串 <fmt> 的评估结果重写请求 URI。方案、授权机构、路径和查询字符串都一次性被替换。这可以用于在代理前重写主机，或对 URI 进行复杂修改，例如在路径和查询字符串之间移动部分。另请参阅“set-path”和“set-query”。 - “set-nice”设置当前正在处理的请求的“nice”因子。它只对同时处理的其他请求产生影响。默认值为 0，除非被“bind”行上的“nice”设置更改。接受的范围是 -1024..1024。值越高，请求就越“友好”。较低的值会使请求比其他请求更重要。这可以用于提高某些请求的速度，或降低不重要请求的优先级。在没有事先实验的情况下使用此设置可能会导致一些重大的性能下降。 - “set-log-level”用于在满足某个条件时更改当前请求的日志级别。有效级别是 8 个 syslog 级别（参见“log
此关键字在以下部分可用：
进程管理和安全
按字母排序的关键字参考”关键字）加上特殊级别“silent”，它会禁用此请求的日志记录。此规则不是最终规则，因此最后一个匹配的规则获胜。此规则可用于禁用来自其他设备的健康检查。 - “set-tos”用于在支持此功能的平台上，将发送给客户端的数据包的 TOS 或 DSCP 字段值设置为在 <tos> 中传递的值。此值表示整个 8 位的 IP TOS 字段，可以用十进制或十六进制格式（以“0x”为前缀）表示。请注意，在 DSCP 或 TOS 中只使用较高的 6 位，而较低的两位始终为 0。这可以用于根据请求中的某些信息调整边界路由器上的一些路由行为。有关更多信息，请参阅 RFC 2474、2597、3260 和 4594。 - “set-mark”用于在支持此功能的平台上，将发送给客户端的所有数据包的 Netfilter MARK 设置为在 <mark> 中传递的值。此值是一个无符号 32 位值，可由 netfilter 和路由表匹配。它可以用十进制或十六进制格式（以“0x”为前缀）表示。这可用于强制某些数据包走不同的路由（例如，对于批量下载使用更便宜的网络路径）。这适用于 Linux 内核 2.6.32 及更高版本，并需要管理员权限。 - “add-acl”用于向 ACL 添加新条目。ACL 必须从文件中加载（即使是虚拟的空文件）。要更新的 ACL 的文件名在括号之间传递。它接受一个参数：<key fmt>，它遵循日志格式规则，用于收集新条目的内容。它在插入前在 ACL 中进行查找，以避免重复（或更多）的值。此查找通过线性搜索完成，对于大型列表可能会很昂贵！它等同于 stats 套接字中的“add acl”命令，但可以由 HTTP 请求触发。 - “del-acl”用于从 ACL 中删除一个条目。ACL 必须从文件中加载（即使是虚拟的空文件）。要更新的 ACL 的文件名在括号之间传递。它接受一个参数：<key fmt>，它遵循日志格式规则，用于收集要删除的条目的内容。它等同于 stats 套接字中的“del acl”命令，但可以由 HTTP 请求触发。 - “del-map”用于从 MAP 中删除一个条目。MAP 必须从文件中加载（即使是虚拟的空文件）。要更新的 MAP 的文件名在括号之间传递。它接受一个参数：<key fmt>，它遵循日志格式规则，用于收集要删除的条目的内容。它接受一个参数：“文件名”它等同于 stats 套接字中的“del map”命令，但可以由 HTTP 请求触发。 - “set-map”用于向 MAP 添加新条目。MAP 必须从文件中加载（即使是虚拟的空文件）。要更新的 MAP 的文件名在括号之间传递。它接受 2 个参数：<key fmt>，它遵循日志格式规则，用于收集 MAP 键；<value fmt>，它遵循日志格式规则，用于收集新条目的内容。它在插入前在 MAP 中进行查找，以避免重复（或更多）的值。此查找通过线性搜索完成，对于大型列表可能会很昂贵！它等同于 stats 套接字中的“set map”命令，但可以由 HTTP 请求触发。 - capture <sample> [ len <length> | id <id> ] : 从请求缓冲区捕获样本表达式 <sample>，并将其转换为最多 <len> 个字符的字符串。生成的字符串存储在下一个请求的“capture”槽中，因此它可能会出现在一些捕获的 HTTP 头旁边。然后它会自动出现在日志中，并且可以使用样本获取规则提取它以将其提供给头或其他任何东西。长度应该受到限制，因为在整个会话生命周期中，此大小将为每次捕获分配。请查看第 7.3 节（获取样本）和“捕获请求头”以获取更多信息。如果使用关键字“id
此关键字在以下部分可用：
按字母排序的关键字参考
Bind 选项
Server 和 default-server 选项”而不是“len”，则操作会尝试将捕获的字符串存储在先前声明的捕获槽中。这在后端运行捕获时很有用。槽 ID 可以由先前的指令“http-request capture”或“declare capture”关键字声明。在后端使用此操作时，请仔细检查相关的前端是否具有所需的捕获槽，否则此规则将在运行时被忽略。由于 HAProxy 能够在运行时动态解析后端名称，因此在配置解析时无法检测到这一点。 - { track-sc0 | track-sc1 | track-sc2 } <key> [table <table>] : 启用从当前请求跟踪粘性计数器。这些规则不会停止评估，也不会更改默认操作。同一连接可同时跟踪的计数器数量在构建时在 MAX_SESS_STKCTR 中设置（在 haproxy -vv 中报告），默认为 3，因此 track-sc 的数量在 0 和 (MAX_SESS_STCKTR-1) 之间。执行的第一个“track-sc0”规则启用对指定表的计数器作为第一组进行跟踪。执行的第一个“track-sc1”规则启用对指定表的计数器作为第二组进行跟踪。执行的第一个“track-sc2”规则启用对指定表的计数器作为第三组进行跟踪。建议的做法是使用第一组计数器用于每个前端的计数器，第二组用于每个后端的计数器。但这只是一个指导方针，所有计数器都可以在任何地方使用。这些操作接受一个或两个参数：<key> 是强制性的，并且是第 7.3 节中描述的样本表达式规则。它描述了将分析、提取、组合和使用传入请求或连接的哪些元素，以选择要更新哪个表条目的计数器。<table> 是一个可选的表，用于替代默认表，即当前代理中声明的粘性表。然后，键的所有匹配和更新的计数器都将在该表中执行，直到会话结束。一旦执行了“track-sc*”规则，就会在表中查找该键，如果未找到，则为其分配一个条目。然后在整个会话生命周期中保留指向该条目的指针，并且该条目的计数器会尽可能频繁地更新，每次会话的计数器更新时，以及在会话结束时系统地更新。计数器仅针对跟踪开始后发生的事件进行更新。作为一个例外，连接计数器和请求计数器会系统地更新，以便它们反映有用的信息。如果条目跟踪并发连接计数器，只要条目被跟踪，就会计算一个连接，并且在该时间内条目不会过期。跟踪计数器还提供了比仅仅检查键更高的性能优势，因为对于所有使用它的 ACL 检查，只执行一次表查找。 - sc-set-gpt0(<sc-id>) <int> : 此操作根据由 <sc-id> 指定的粘性计数器和 <int> 的值设置 GPT0 标记。预期的结果是一个布尔值。如果发生错误，此操作会静默失败，并继续评估操作。 - sc-inc-gpc0(<sc-id>): 此操作根据由 <sc-id> 指定的粘性计数器递增 GPC0 计数器。如果发生错误，此操作会静默失败，并继续评估操作。 - set-var(<var-name>) <expr> : 用于设置变量的内容。变量是内联声明的。<var-name> 变量的名称以其作用域的指示开始。允许的作用域是：“sess”：变量在整个会话中共享 “txn”：变量在事务（请求和响应）中共享 “req”：变量仅在请求处理期间共享 “res”：变量仅在响应处理期间共享 此前缀后跟一个名称。分隔符是“.”。名称只能包含字符“a-z”、“A-Z”、“0-9”和“_”。<expr> 是一个标准的 HAProxy 表达式，由样本获取后跟一些转换器组成。

http-request set-var(req.my_var) req.fhdr(user-agent),lower

- set-src <expr> : 用于将源 IP 地址设置为指定表达式的值。当 HAProxy 前面的代理重写了源 IP，但在 HTTP 头中提供了正确的 IP 时，或者您想为了隐私而屏蔽源 IP 时，这很有用。<expr> 是一个标准的 HAProxy 表达式，由样本获取后跟一些转换器组成。

http-request set-src hdr(x-forwarded-for) http-request set-src src,ipmask(24)

当 set-src 成功时，源端口设置为 0。 - “silent-drop”：停止规则评估，并使用一种系统相关的方式使面向客户端的连接突然消失，该方式试图阻止客户端被通知。其效果是客户端仍然看到一个已建立的连接，而 HAProxy 上则没有。其目的是实现与“tarpit”类似的效果，只是它在运行 HAProxy 的机器上完全不使用任何本地资源。它可以承受比“tarpit”高得多的负载，并减慢更强大的攻击者的速度。重要的是要理解使用此机制的影响。放置在客户端和 HAProxy 之间的所有有状态设备（防火墙、代理、负载均衡器）也将长时间保持已建立的连接，并可能因此操作而受到影响。在具有足够权限的现代 Linux 系统上，使用 TCP_REPAIR 套接字选项来阻止 TCP 重置的发送。在其他系统上，套接字的 TTL 会减少到 1，以便 TCP 重置不会通过第一个路由器，尽管它仍然会传送到本地网络。除非您完全理解其工作原理，否则不要使用它。 每个实例的 http-request 语句数量没有限制。重要的是要知道，http-request 规则在 HTTP 处理的早期阶段处理，紧接在“block”规则之后，在“reqdel”或“reqrep”或“reqadd”规则之前。这样，“add-header”/“set-header”添加的头对于几乎所有后续的 ACL 规则都是可见的。在较新版本（>= 1.5）中不鼓励使用“reqadd”/“reqdel”/“reqrep”来操作请求头。但如果需要使用正则表达式来删除头，仍然可以使用“reqdel”。另外，请使用“http-request deny/allow/tarpit”而不是“reqdeny”/“reqpass”/“reqtarpit”。

acl nagios src 192.168.129.3 acl local_net src 192.168.0.0/16 acl auth_ok http_auth(L1) http-request allow if nagios http-request allow if local_net auth_ok http-request auth realm Gimme if local_net auth_ok http-request deny

acl auth_ok http_auth_group(L1) G1 http-request auth unless auth_ok

http-request set-header X-Haproxy-Current-Date %T http-request set-header X-SSL %[ssl_fc] http-request set-header X-SSL-Session_ID %[ssl_fc_session_id,hex] http-request set-header X-SSL-Client-Verify %[ssl_c_verify] http-request set-header X-SSL-Client-DN %{+Q}[ssl_c_s_dn] http-request set-header X-SSL-Client-CN %{+Q}[ssl_c_s_dn(cn)] http-request set-header X-SSL-Issuer %{+Q}[ssl_c_i_dn] http-request set-header X-SSL-Client-NotBefore %{+Q}[ssl_c_notbefore] http-request set-header X-SSL-Client-NotAfter %{+Q}[ssl_c_notafter]

acl key req.hdr(X-Add-Acl-Key) -m found acl add path /addacl acl del path /delacl acl myhost hdr(Host) -f myhost.lst http-request add-acl(myhost.lst) %[req.hdr(X-Add-Acl-Key)] if key add http-request del-acl(myhost.lst) %[req.hdr(X-Add-Acl-Key)] if key del

acl value req.hdr(X-Value) -m found acl setmap path /setmap acl delmap path /delmap use_backend bk_appli if { hdr(Host),map_str(map.lst) -m found } http-request set-map(map.lst) %[src] %[req.hdr(X-Value)] if setmap value http-request del-map(map.lst) %[src] if delmap

第 7 层响应的访问控制

可在以下配置段中使用

defaults	frontend	listen	backend
否	是	是	是

http-response 语句定义了一组应用于第 7 层处理的规则。在 frontend、listen 或 backend 部分遇到这些规则时，会按照声明的顺序对其进行评估。任何规则后面都可以选择性地跟一个基于 ACL 的条件，这种情况下，只有当条件为真时，规则才会被评估。由于这些规则应用于响应，因此 backend 的规则会首先应用，然后是 frontend 的规则。第一个关键字是规则的操作。目前支持的操作包括： - "allow"：停止规则的评估，并让响应通过检查。当前部分不再评估任何 "http-response" 规则。 - "deny"：停止规则的评估，并立即拒绝响应，发出 HTTP 502 错误。不再评估任何 "http-response" 规则。 - "add-header" 追加一个 HTTP 头部字段，其名称由 <name> 指定，其值由 <fmt> 定义，遵循日志格式规则（参见第 8.2.4 节中的自定义日志格式）。例如，这可以用于向客户端发送 cookie，或者传递一些内部信息。此规则不是最终规则，因此可以添加其他类似的规则。请注意，头部添加是立即执行的，因此一条规则可能会重用前一条规则产生的头部。 - "set-header" 的作用与 "add-header" 相同，只是如果头部名称已存在，会先将其删除。这在向服务器传递安全信息时很有用，因为该头部不能被外部用户操纵。 - "del-header" 删除所有名称由 <name> 指定的 HTTP 头部字段。 - "replace-header" 根据 <match-regex> 匹配头部字段 <name> 中的所有正则表达式出现，并用 <replace-fmt> 参数替换它们。<replace-fmt> 中允许使用格式字符，其工作方式与 "add-header" 中的 <fmt> 参数类似。匹配是区分大小写的。重要的是要理解，此操作只考虑整个头部行，无论它们可能包含多少个值。这种用法适用于值中自然包含逗号的头部，例如 Set-Cookie、Expires 等。

http-response replace-header Set-Cookie (C=[^;]*);(.*) \1;ip=%bi;\2

应用于：Set-Cookie: C=1; expires=Tue, 14-Jun-2016 01:40:45 GMT 输出：Set-Cookie: C=1;ip=192.168.1.20; expires=Tue, 14-Jun-2016 01:40:45 GMT 假设后端 IP 是 192.168.1.20。 - "replace-value" 的工作方式与 "replace-header" 类似，不同之处在于它针对头部字段 <name> 的每个逗号分隔的值匹配正则表达式，而不是整个头部。这适用于所有允许携带多个值的头部。一个例子可以是 Accept 头部。

http-response replace-value Cache-control ^public$ private

应用于：Cache-Control: max-age=3600, public 输出：Cache-Control: max-age=3600, private - "set-status" 将响应状态码替换为 <status>，该值必须是介于 100 和 999 之间的整数。请注意，原因会自动适应新的状态码。

# 返回 "431 Request Header Fields Too Large" http-response set-status 431

- "set-nice" 设置当前正在处理的请求的 "nice" 因子。它只对同时处理的其他请求产生影响。默认值为 0，除非被 "bind" 行上的 "nice" 设置更改。接受的范围是 -1024..1024。值越高，请求就越“友好”（优先级越低）。较低的值将使请求比其他请求更重要。这可以用于提高某些请求的速度，或降低不重要请求的优先级。未经事先实验使用此设置可能会导致严重的性能下降。 - "set-log-level" 用于在满足特定条件时更改当前请求的日志级别。有效级别是 8 个 syslog 级别（参见 "log
此关键字在以下部分可用：
进程管理和安全
按字母排序的关键字参考" 关键字）加上特殊级别 "silent"，该级别会禁用此请求的日志记录。此规则不是最终规则，因此最后一个匹配的规则生效。此规则可用于禁用来自其他设备的健康检查。 - "set-tos" 用于在支持此功能的平台上，将发送给客户端的数据包的 TOS 或 DSCP 字段值设置为在 <tos> 中传递的值。此值表示 IP TOS 字段的全部 8 位，可以用十进制或十六进制格式（以 "0x" 为前缀）表示。请注意，DSCP 或 TOS 中只使用较高的 6 位，而较低的两位始终为 0。这可以用于根据请求中的某些信息调整边界路由器上的一些路由行为。更多信息请参见 RFC 2474、2597、3260 和 4594。 - "set-mark" 用于在支持此功能的平台上，将发送给客户端的所有数据包的 Netfilter MARK 设置为在 <mark> 中传递的值。此值是一个无符号的 32 位值，可以被 netfilter 和路由表匹配。它可以用十进制或十六进制格式（以 "0x" 为前缀）表示。这可以用于强制某些数据包采用不同的路由（例如，为批量下载选择更便宜的网络路径）。这在 Linux 内核 2.6.32 及以上版本上有效，并需要管理员权限。 - "add-acl" 用于向 ACL 添加新条目。ACL 必须从文件中加载（即使是空的虚拟文件）。要更新的 ACL 的文件名在括号之间传递。它接受一个参数：<key fmt>，该参数遵循日志格式规则，用于收集新条目的内容。它在插入前会先在 ACL 中进行查找，以避免重复（或多个）值。此查找是通过线性搜索完成的，对于大型列表可能会很耗时！它等同于来自 stats 套接字的 "add acl" 命令，但可以由 HTTP 响应触发。 - "del-acl" 用于从 ACL 中删除一个条目。ACL 必须从文件中加载（即使是空的虚拟文件）。要更新的 ACL 的文件名在括号之间传递。它接受一个参数：<key fmt>，该参数遵循日志格式规则，用于收集要删除的条目的内容。它等同于来自 stats 套接字的 "del acl" 命令，但可以由 HTTP 响应触发。 - "del-map" 用于从 MAP 中删除一个条目。MAP 必须从文件中加载（即使是空的虚拟文件）。要更新的 MAP 的文件名在括号之间传递。它接受一个参数：<key fmt>，该参数遵循日志格式规则，用于收集要删除的条目的内容。它等同于来自 stats 套接字的 "del map" 命令，但可以由 HTTP 响应触发。 - "set-map" 用于向 MAP 中添加一个新条目。MAP 必须从文件中加载（即使是空的虚拟文件）。要更新的 MAP 的文件名在括号之间传递。它接受 2 个参数：<key fmt>，遵循日志格式规则，用于收集 MAP 键；以及 <value fmt>，遵循日志格式规则，用于收集新条目的内容。它在插入前会先在 MAP 中进行查找，以避免重复（或多个）值。此查找是通过线性搜索完成的，对于大型列表可能会很耗时！它等同于来自 stats 套接字的 "set map" 命令，但可以由 HTTP 响应触发。 - capture <sample> id <id> : 从响应缓冲区中捕获样本表达式 <sample>，并将其转换为字符串。生成的字符串存储到下一个请求的 "capture" 槽中，因此它可能会出现在一些捕获的 HTTP 头部旁边。然后它会自动出现在日志中，并且可以使用样本提取规则将其提取出来，以馈送到头部或任何其他地方。请查看第 7.3 节（提取样本）和“捕获响应头部”以获取更多信息。关键字 "id
此关键字在以下部分可用：
按字母排序的关键字参考
Bind 选项
Server 和 default-server 选项" 是用于存储字符串的捕获槽的 ID。捕获槽必须在关联的 frontend 中定义。这对于在后端运行捕获很有用。槽 ID 可以由之前的 "http-response capture" 指令声明，或使用 "declare capture" 关键字。在后端使用此操作时，请仔细检查相关的 frontend 是否具有所需的捕获槽，否则此规则将在运行时被忽略。由于 HAProxy 能够在运行时动态解析后端名称，因此在配置解析时无法检测到此问题。 - "redirect"：此操作基于重定向规则执行 HTTP 重定向。它支持类似于 "http-request redirect" 规则的格式字符串，但有一个例外，即在响应上只可能进行 "location" 类型的重定向。有关规则的语法，请参见 "redirect" 关键字。在响应期间应用重定向规则时，与服务器的连接将被关闭，以便无法将任何数据从服务器转发到客户端。 - set-var(<var-name>) expr：用于设置变量的内容。变量是内联声明的。<var-name> 变量的名称以一个关于其作用域的指示开始。允许的作用域是： "sess"：变量在整个会话中共享 "txn"：变量在事务（请求和响应）中共享 "req"：变量仅在请求处理期间共享 "res"：变量仅在响应处理期间共享 此前缀后跟一个名称。分隔符是“.”。名称只能包含字符 'a-z'、'A-Z'、'0-9' 和 '_'。 <expr> 是一个标准的 HAProxy 表达式，由一个样本提取后跟一些转换器组成。

http-response set-var(sess.last_redir) res.hdr(location)

- sc-set-gpt0(<sc-id>) <int> : 此操作根据由 <sc-id> 指定的粘性计数器和 <int> 的值设置 GPT0 标记。预期的结果是一个布尔值。如果发生错误，此操作将静默失败，并且操作评估将继续。 - sc-inc-gpc0(<sc-id>)：此操作根据由 <sc-id> 指定的粘性计数器递增 GPC0 计数器。如果发生错误，此操作将静默失败，并且操作评估将继续。 - "silent-drop"：停止规则的评估，并使用一种系统相关的方式使面向客户端的连接突然消失，该方式试图阻止客户端被通知。其效果是客户端仍然看到一个已建立的连接，而在 HAProxy 上则没有。目的是实现与 "tarpit" 相当的效果，只不过它完全不使用运行 HAProxy 的机器上的任何本地资源。它可以抵抗比 "tarpit" 高得多的负载，并减慢更强大的攻击者的速度。理解使用此机制的影响很重要。放置在客户端和 HAProxy 之间的所有有状态设备（防火墙、代理、负载均衡器）也将长时间保持已建立的连接，并可能因此操作而受到影响。在具有足够权限的现代 Linux 系统上，TCP_REPAIR 套接字选项用于阻止 TCP 重置的发送。在其他系统上，套接字的 TTL 会减少到 1，以便 TCP 重置不会通过第一个路由器，尽管它仍然会传递到本地网络。除非你完全理解其工作原理，否则不要使用它。 每个实例的 http-response 语句数量没有限制。重要的是要知道 http-response 规则在 HTTP 处理的非常早期阶段进行处理，在 "rspdel"、"rsprep" 或 "rspadd" 规则之前。这样，由 "add-header"/"set-header" 添加的头部对于几乎所有后续的 ACL 规则都是可见的。在较新版本（>= 1.5）中，不鼓励使用 "rspadd"/"rspdel"/"rsprep" 来操作请求头。但如果需要使用正则表达式来删除头部，仍然可以使用 "rspdel"。另外，请使用 "http-response deny" 而不是 "rspdeny"。

acl key_acl res.hdr(X-Acl-Key) -m found acl myhost hdr(Host) -f myhost.lst http-response add-acl(myhost.lst) %[res.hdr(X-Acl-Key)] if key_acl http-response del-acl(myhost.lst) %[res.hdr(X-Acl-Key)] if key_acl

acl value res.hdr(X-Value) -m found use_backend bk_appli if { hdr(Host),map_str(map.lst) -m found } http-response set-map(map.lst) %[src] %[res.hdr(X-Value)] if value http-response del-map(map.lst) %[src] if ! value

声明空闲的 HTTP 连接如何在请求之间共享

可在以下配置段中使用

defaults	frontend	listen	backend
是	否	是	是

默认情况下，HAProxy 和后端服务器之间建立的连接属于发起它的会话。缺点是在响应和下一个请求之间，连接保持空闲且未被使用。在许多情况下，出于性能原因，希望能够重用这些空闲连接来服务来自不同会话的其他请求。该指令允许调整此行为。参数指示所需的连接重用策略： - "never"：空闲连接永远不会在会话之间共享。这是默认选择。可以强制使用此选项来取消从 defaults 部分继承的不同策略，或用于故障排除。例如，如果某个旧的错误应用程序认为同一连接上的多个请求来自同一个客户端，并且无法修复该应用程序，则可能需要在单个后端中禁用连接共享。此类应用程序的一个例子可能是在隧道模式下使用 cookie 插入且不检查第一个请求之后的任何请求的旧版 HAProxy。 - "safe"：这是推荐的策略。会话的第一个请求总是通过其自己的连接发送，只有后续的请求可能会被分派到其他现有连接上。这确保了在发送请求时如果服务器关闭连接，浏览器可以决定静默重试。由于它与常规的 keep-alive 完全等效，因此不应有任何副作用。 - "aggressive"：此模式在 Web 服务环境中可能很有用，其中并非所有服务器都已知，并且希望将大多数第一个请求通过现有连接传递。在这种情况下，第一个请求仅通过已至少重用过一次的现有连接传递，证明服务器正确支持连接重用。只有在确定客户端可以偶尔重试失败的请求，并且积极连接重用的好处明显超过罕见连接失败的缺点时，才应使用此模式。 - "always"：此模式仅在已知到服务器的路径在释放现有连接后不会很快断开时推荐使用。它允许会话的第一个请求发送到现有连接。当后端是缓存服务器群时，这可以提供显著的性能提升，因为这类组件倾向于表现出一致的行为，并将从连接共享中受益。建议在此模式下保持 "http-keep-alive" 超时值较低，以使没有死连接保持可用。在大多数情况下，这将导致与 "aggressive" 相同的性能增益，但风险更大。只有当它比 "aggressive" 模式能改善情况时才应使用。 当启用 HTTP 连接共享时，会特别注意尊重连接属性和兼容性。具体来说： - 使用 "usesrc" 后跟客户端相关值（"client"、"clientip"、"hdr_ip"）建立的连接被标记为私有，永不共享； - 发送到带有 TLS SNI 扩展的服务器的连接被标记为私有，永不共享； - 接收到状态码 401 或 407 的连接期望返回时发送一些身份验证信息。由于某些错误的身份验证方案（如 NTLM）依赖于连接，这些连接被标记为私有，永不共享； 不涉及连接池，一旦会话死亡，它所附加的最后一个空闲连接将同时被删除。这确保了连接在所有会话关闭后不会持续存在。 注意：连接重用提高了 "server maxconn" 设置的准确性，因为在空闲连接仍然可用时，几乎不会建立新的连接。这在使用 "always" 策略时尤其如此。

将服务器名称添加到请求中。使用由 <header> 给出的头字符串。

可在以下配置段中使用

defaults	frontend	listen	backend
是	否	是	是

<header> 用于发送服务器名称的头字符串。

"http-send-name-header" 语句会将目标服务器的名称添加到 HTTP 请求的头信息中。该名称是使用提供的头字符串添加的。