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

当 HAProxy 在 HTTP 模式下运行时，请求和响应都会被完全分析和索引，因此可以根据内容中找到的几乎任何信息构建匹配标准。然而，了解 HTTP 请求和响应的构成方式以及 HAProxy 如何分解它们是很重要的。这样一来，编写正确的规则和调试现有配置就会变得更加容易。首先，HTTP 由一系列 RFC 标准化，HAProxy 尽可能地遵循这些标准： - RFC 9110: HTTP 语义 (解释协议元素的含义) - RFC 9111: HTTP 缓存 (解释 HTTP 缓存应遵循的规则) - RFC 9112: HTTP/1.1 (表示、互操作性规则、安全) - RFC 9113: HTTP/2 (表示、互操作性规则、安全) - RFC 9114: HTTP/3 (表示、互操作性规则、安全) 除此之外，RFC 8999 到 9002 规定了 HTTP/3 协议使用的 QUIC 传输层。

HTTP 协议是事务驱动的。这意味着每个请求都会导致一个且只有一个响应。最初，在协议的 1.0 版本中，每个连接只有一个请求：客户端与服务器建立 TCP 连接，客户端通过连接发送请求，服务器响应，连接关闭。然后，新的请求涉及新的连接：[CON1] [REQ1] ... [RESP1] [CLO1] [CON2] [REQ2] ... [RESP2] [CLO2] ... 在此模式下（通常称为“HTTP close”模式），连接建立的次数与 HTTP 事务的次数相同。由于连接在响应后由服务器关闭，客户端无需知道内容长度，它认为当连接关闭时响应即告完成。这也意味着如果某些响应由于网络错误而被截断，客户端可能会错误地认为响应已完成，这曾导致有时屏幕上渲染出被截断的图像。由于协议的事务性质，可以对其进行改进，以避免在两个后续事务之间关闭连接。然而，在这种模式下，服务器必须为每个响应指示内容长度，以便客户端不会无限期地等待。为此，使用了特殊的标头：“Content-length”。此模式称为“keep-alive”模式，随 HTTP/1.1 一起出现（一些 HTTP/1.0 代理支持它），在请求之间重用的连接称为“持久连接”：[CON] [REQ1] ... [RESP1] [REQ2] ... [RESP2] [CLO] ... 它的优点是事务之间的延迟减少，服务器端所需的处理能力降低，并且能够检测到被截断的响应。它通常比关闭模式更快，但并非总是如此，因为一些客户端通常将其并发连接限制为一个较小的值，这在网络连接较差时补偿较少。此外，一些服务器必须长时间保持连接活动，等待可能的新请求，并且由于连接数量过多，可能会经历高内存使用率，而关闭过快可能会破坏在连接关闭时到达的一些请求。在此模式下，响应大小需要提前知道，因此对于动态生成或压缩的内容并不总是可行。出于这个原因，实现了另一种模式，即“分块模式”（chunked mode），发送方不是一次性宣布整个大小，而是只宣布其缓冲区中已有的下一个“块”的大小，并且可以随时以零大小的块结束。在此模式下，不使用 Content-Length 标头。通信中的另一个改进是流水线模式（pipelining mode）。它仍然使用 keep-alive，但客户端不等第一个响应就发送第二个请求。这对于获取构成页面的大量图像非常有用：[CON] [REQ1] [REQ2] ... [RESP1] [RESP2] [CLO] ... 这显然对性能有巨大的好处，因为后续请求之间的网络延迟被消除了。许多 HTTP 代理不支持正确的流水线，因为在 HTTP 中无法将响应与相应的请求相关联。因此，服务器必须按照接收请求的完全相同的顺序回复。实际上，在各种客户端尝试部署后，由于在某些服务器上缺乏可靠性，它已被完全放弃。但服务器必须支持它。下一个改进是多路复用模式，如 HTTP/2 和 HTTP/3 中所实现。在此模式下，多个事务（即请求-响应对）通过单个连接并行传输，并且它们都以自己的速度进行，相互独立。对于多路复用协议，引入了“流”（stream）的新概念，以表示发生在同一连接上的这些并行通信。每个流通常被分配一个给定连接的唯一标识符，两端都使用该标识符来知道将数据传送到何处。客户端在同一连接上并行启动多个流（多达 100 个，有时更多）是很常见的，并让服务器对它们进行分类，并根据可用的响应以任何顺序响应。多路复用模式的主要好处是它显着减少了往返次数，并加快了高延迟网络上的页面加载时间。这在许多使用图像的网站上很明显，所有图像似乎都在并行加载。这些协议还通过采用一些机制来压缩标头字段以减少线路上的字节数来提高效率，因此如果没有适当的工具，它们不像 HTTP/1 那样可以通过手动操作或肉眼可读。出于这个原因，HTTP 消息的各种示例在文献中（包括本文档）继续使用 HTTP/1 语法表示，即使是较新版本的协议。HTTP/2 存在一些设计限制，例如数据包丢失会同时影响所有流，如果客户端花费太多时间来检索对象（例如需要将其存储在磁盘上），它可能会减慢检索速度，并使得在此期间无法访问在其后面等待的数据。这称为“队头阻塞”（head of line blocking）或“HoL blocking”或有时简称“HoL”。HTTP/3 是在 QUIC 上实现的，QUIC 本身是在 UDP 上实现的。QUIC 通过独立处理的流在传输层解决了队头阻塞问题。实际上，当遇到丢失时，受影响的流不会影响其他流，并且所有流都可以并行访问。QUIC 还提供连接迁移支持，但目前 haproxy 不支持它。默认情况下，HAProxy 在处理持久连接时以 keep-alive 模式运行：对于它处理的每个连接，它处理每个请求和响应，并在响应结束和新请求开始之间将连接在两端保持空闲状态。当它从客户端接收到 HTTP/2 连接时，它会并行处理所有请求并使连接空闲，等待新请求，就像它是一个 keep-alive HTTP 连接一样。HAProxy 主要支持 3 种连接模式：- keep alive：所有请求和响应都经过处理，面向客户端和面向服务器的连接保持活动状态以等待新请求。这是默认设置，适用于现代 Web 和现代协议（HTTP/2 和 HTTP/3）。- server close：面向服务器的连接在响应后关闭。- close：连接在两端响应结束后主动关闭。除此之外，默认情况下，面向服务器的连接可以被来自任何客户端的任何请求重用，正如 HTTP 协议规范所要求的那样，因此如果需要（例如客户端的源地址等），任何特定于特定客户端的信息都必须随每个请求一起传递。当 HTTP/2 与服务器一起使用时，默认情况下 HAProxy 会将此连接专用于同一客户端，以避免客户端之间出现队头阻塞的风险。

在 HAProxy 内部，术语随着 HTTP 协议及其用法的演变而有所发展。虽然最初连接、会话、流或事务之间没有显着差异，但随着时间的推移，这些术语变得更加清晰，以密切匹配现代 HTTP 协议版本中存在的内容，尽管出于历史兼容性的目的，某些术语在配置或命令行界面中仍然可见。以下是适用于当前版本 HAProxy 的一些定义：- 连接（connection）：连接是在远程代理（客户端或服务器）和 HAProxy 之间以最低级别可能的单个双向通信通道。通常它对应于在一对 IP 和端口之间建立的 TCP 套接字。在面向客户端的一侧，连接是客户端连接到 HAProxy 时实例化的第一个实体，并且在连接级别应用的规则是最早应用的规则。- 会话（session）：会话添加了一些与连接关联的上下文信息。这包括特定于传输层的信息（例如 TLS 密钥等）或变量。这个术语长期以来在 HAProxy 内部用于表示两端之间的端到端 HTTP/1.0 通信，因此尽管现在它代表流，但在某些 CLI 命令或统计信息的名称中仍然可见，但帮助消息和描述试图使其明确。它在网络级别术语（例如操作系统内部的 TCP 会话或跨防火墙的 TCP 会话）或非 HTTP 用户级应用程序（例如 telnet 会话或 SSH 会话）方面仍然有效。它不得与用于在 cookie 中存储完整用户上下文并要求发送到同一服务器的“应用程序会话”混淆。- 流（stream）：流完全对应于应用程序级别的端到端双向通信，可以在其中应用分析和转换。在 HTTP 中，它包含单个请求及其关联的响应，并由请求的到达实例化，并随着响应交付的结束而完成。在这种情况下，这种流与多路复用协议的流之间存在 1:1 的关系。在 TCP 通信中，每个连接只有一个流。- 事务（transaction）：事务仅是一对请求和关联的响应。在流出现之前，该术语与会话结合使用，但现在事务与流之间存在 1:1 的关系。它主要在变量的范围“txn”中可见，该范围在整个事务期间有效，因此在流中有效。- 请求（request）：它表示从客户端流向服务器的流量。它主要用于 HTTP 以指示执行操作的位置。此术语也存在于 TCP 操作中，用于指示处理数据的位置。请求通常作为流量或活动单位出现在计数器中。它们并不总是意味着响应（例如，由于错误），但由于没有自发响应而没有请求，请求仍然是衡量整体活动的相关指标。在 TCP 中，请求的数量与连接数量相同。- 响应（response）：这表示从服务器流向客户端的流量，或者有时是 HAProxy 自己生成响应时（例如 HTTP 重定向）从 HAProxy 流向客户端的流量。- 服务（service）：这通常表示 HAProxy 中的一些内部处理，不需要服务器，例如 stats 页面、缓存或一些 Lua 代码来实现小型应用程序。服务通常读取请求，执行一些操作并生成响应。

首先，让我们考虑这个 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”：/serv/login.php?lang=en&profile=2它是没有主机部分的完整 URL。这通常是服务器、反向代理和透明代理接收到的内容。- “绝对 URI”，也称为“URL”：http://192.168.0.12:8080/serv/login.php?lang=en&profile=2它由一个“方案”（protocol name，后跟 '://'）、一个主机名或地址、可选的冒号（':'）后跟端口号，然后是从地址部分后的第一个斜杠（'/'）开始的相对 URI 组成。这通常是代理接收到的内容，但支持 HTTP/1.1 的服务器也必须接受这种形式。- 星号（'*'）：这种形式仅在与 OPTIONS 方法结合使用时接受，不可中继。它用于查询下一跳的功能。- 地址:端口组合：192.168.0.12:80这与 CONNECT 方法一起使用，CONNECT 方法用于通过 HTTP 代理建立 TCP 隧道，通常用于 HTTPS，但有时也用于其他协议。在相对 URI 中，识别出两个子部分。问号之前的部分称为“路径”。它通常是服务器上静态对象的相对路径。问号之后的部分称为“查询字符串”。它主要用于发送给动态脚本的 GET 请求，并且非常特定于所使用的语言、框架或应用程序。HTTP/2 和 HTTP/3 不会随请求传递版本信息，因此版本被假定为与底层协议的版本相同（即“HTTP/2”）。此外，这些协议不会将请求行作为一个部分发送，而是将其拆分为称为“伪标头”（pseudo-headers）的单个字段，这些伪标头的名称以冒号开头，HAProxy 会方便地将它们重新组装成等效的请求行。因此，日志中找到的请求行在 HTTP/1.x 和 HTTP/2 或 HTTP/3 之间可能略有不同。

标头从第二行开始。它们由行开头的名称组成，紧跟一个冒号（':'）。传统上，在冒号后添加 LWS，但这不是必需的。然后是值。多个相同的标头可以折叠成一行，用逗号分隔值，前提是它们的顺序得到尊重。这在“Cookie:”字段中很常见。如果后续行以 LWS 开头，则标头可以跨多行。在 1.3 中的示例中，第 4 行和第 5 行共定义了“Accept:”标头的 3 个值。最后，根据规范，标头开头或结尾处的所有 LWS 都被忽略，不属于值的一部分。与常见的误解相反，标头名称不区分大小写，如果它们引用其他标头名称（例如“Connection:”标头），则它们的值也不区分大小写。在 HTTP/2 和 HTTP/3 中，标头名称始终以小写形式发送，如在调试模式下运行时所见。在内部，所有标头名称都规范化为小写，以便 HTTP/1.x 和 HTTP/2 或 HTTP/3 使用完全相同的表示形式，并且它们在另一侧按原样发送。这解释了为什么以驼峰式大小写输入的 HTTP/1.x 请求以小写形式交付。标头的末尾由第一个空行表示。人们常说它是双换行符，这并不准确，即使双换行符是空行的一种有效形式。幸运的是，HAProxy 在索引标头、检查值和计算它们时会处理所有这些复杂的组合，因此无需担心它们的写入方式，但重要的是不要指责应用程序如果它做了不寻常、有效的事情是错误的。重要提示：正如 RFC7231 所建议的那样，HAProxy 通过用 LWS 替换标头中间的换行符来规范化标头，以便连接多行标头。这对于正确的分析是必需的，并有助于功能较弱的 HTTP 解析器正常工作，并且不会被此类复杂结构所欺骗。

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

第 1 行是“响应行”。它始终由 3 个字段组成：- 版本标签（version tag）：HTTP/1.1- 状态码（status code）：200- 原因短语（reason phrase）：OK状态码始终是 3 位数字。第一位数字表示一般状态：- 1xx = 要跳过的信息性消息（例如 100、101）- 2xx = OK，内容正在发送中（例如 200、206）- 3xx = OK，没有内容发送中（例如 302、304）- 4xx = 由客户端引起的错误（例如 401、403、404）- 5xx = 由服务器引起的错误（例如 500、502、503）状态码大于 599 不得在通信中发出，尽管某些代理可能会在日志中生成它们以报告其内部状态。有关所有此类代码的详细含义，请参阅 RFC9110。HTTP/2 及更高版本没有版本标签，并使用“:status”伪标头来报告状态码。“原因”字段只是一个提示，但客户端不解析它。那里可以找到任何东西，但尊重公认的消息是一种常见的做法。它可以由一个或多个单词组成，例如“OK”、“Found”或“Authentication Required”。它在 HTTP/2 及更高版本中不存在，并且不会在那里发出。当来自 HTTP/2 或更高版本的响应传输到 HTTP/1 客户端时，HAProxy 将生成与状态码匹配的常见原因字段。HAProxy 可能会自行发出以下状态码：代码 何时/原因200 访问统计信息页面，以及回复监控请求时301 执行重定向时，具体取决于配置的代码302 执行重定向时，具体取决于配置的代码303 执行重定向时，具体取决于配置的代码307 执行重定向时，具体取决于配置的代码308 执行重定向时，具体取决于配置的代码400 对于无效或过大的请求401 执行操作需要身份验证时（访问统计信息页面时）403 当“http-request deny”规则禁止请求时404 当找不到请求的资源时408 在请求完成之前请求超时发生时410 当请求的资源不再可用且以后也不会再次可用时413 当 HTTP/1.0 GET/HEAD/DELETE 请求带有有效负载时，另请参阅“h1-accept-payload-with-any-method”选项500 当 HAProxy 遇到无法恢复的内部错误时，例如内存分配失败，这不应该发生501 当 HAProxy 因不支持的功能而无法满足客户端请求时502 当服务器返回空、无效或不完整的响应时，或者当“http-response deny”规则阻止响应时。503 当没有可用的服务器来处理请求时，或者响应与“monitor fail”条件匹配的监控请求时504 在服务器响应之前响应超时发生时上面的 4xx 和 5xx 错误代码可以自定义（请参阅第 4.2 节中的“errorloc”）。其他状态码可以通过特定操作有意发出（例如，请参阅第 4.3 节中的“deny”、“return”和“redirect
此关键字可在以下部分中找到：
按字母排序的关键字参考
按字母排序的操作参考”操作）。

响应头的工作方式与请求头完全相同，因此，HAProxy 对两者使用相同的解析函数。有关更多详细信息，请参阅第 1.3.2 段。

HAProxy 的配置过程涉及 3 个主要参数来源：- 命令行参数，始终优先- 配置文件，此处描述其格式- 运行进程的环境，以防某些环境变量被明确引用配置文件遵循一个相当简单的层次结构格式，它遵循一些基本规则：1. 配置文件是语句的有序序列2. 语句是在任何未受保护的“#”（哈希）之前的一行非空行3. 一行是由未受保护的空格或制表符分隔的一系列令牌或“词”4. 一行的第一个词或词序列是本文档中列出的关键字或关键字序列之一5. 所有其他词都是第一个词的参数，其中一些是本文档中列出的众所周知的关键字，其他是值、对配置其他部分的引用或表达式6. 某些关键字分隔一个节，在该节中仅支持关键字的子集7. 一个节在文件末尾或在新节开始的特殊关键字处结束要编写简单但可靠的配置生成器，只需要了解以上所有内容，但这不足以可靠地解析任何配置或找出如何处理某些特殊情况。首先，上述规则有一些后果。规则 6 和 7 意味着用于定义新节的关键字在任何地方都有效，并且不能在特定节中具有不同的含义。这些关键字始终是单个词（与词序列相反），传统上，紧随其后的节使用相同的名称来表示。例如，当谈论“全局节”时，它指的是紧随“global”关键字之后的配置节。这种用法在错误消息中经常使用，以帮助定位需要解决的部分。许多节创建内部对象或配置空间，需要将其与其他节区分开来。在这种情况下，它们将使用一个额外的词来设置这个特定节的名称。对于其中一些，节名称是强制性的。例如，“frontend foo”将创建一个名为“foo”的“frontend”类型的新节。通常，名称特定于其节，不同类型的两个节可以使用相同的名称，但不推荐这样做，因为它往往会使配置管理复杂化。规则 7 的直接后果是，当同时读取多个文件时，每个文件必须以新节开头，并且每个文件的结尾将结束一个节。一个文件不能包含子节，也不能结束现有节并开始新节。规则 1 提到顺序很重要。确实，有些关键字创建的指令可以重复多次，以创建要按特定顺序应用的有序列规则。例如，“tcp-request”可用于在不同标准上交替使用“accept”和“reject”规则。因此，配置文件处理器在编辑文件时必须始终保留节的顺序。节的顺序通常无关紧要，除非全局节必须放置在其他节之前，但如果需要可以重复。此外，一些自动标识符可能会自动分配给一些创建的对象（例如代理），并且通过重新排序节，它们的标识符将发生变化。这些出现在统计信息中。因此，下面的配置将为“foo”分配 ID 号 1，为“bar”分配 ID 号 2，如果两个节颠倒，则会交换：listen foo bind :80 listen bar bind :81另一个重要点是，根据上述规则 2 和 3，空行、空格、制表符以及紧随未受保护的“#”字符之后的注释不属于配置的一部分，因为它们仅用作分隔符。这意味着以下配置严格等效：global#这是全局节 daemon#守护进程 frontend foo mode http # 或者 tcp and: global daemon # 这是公共 web 前端 frontend foo mode http 常见的做法是只将启动新节的关键字左对齐，并缩进（即在前面添加制表符或几个空格）所有其他关键字，以便立即看出它们属于同一节（如上例二所示）。在新节之前放置注释有助于读者确定它是否是所需的节。在节末尾留一个空行也有助于在编辑时直观地发现末尾。制表符非常方便用于缩进，但它们复制粘贴效果不佳。如果使用空格代替，建议不要放置太多（2 到 4 个），这样在有限的编辑器中编辑时不会成为负担，因为这些编辑器不支持自动缩进。早期，由于大多数关键字不会占用两个以上的参数，因此将参数在固定制表符位置拆分是很常见的。随着现代版本具有复杂表达式，这种做法不再适用，也不推荐。

在现代配置中，一些参数要求使用以前被认为是纯分隔符的字符。为了使这成为可能，HAProxy 支持通过在要转义的字符前面添加反斜杠（'\'）进行字符转义，使用双引号（""）对一段文本进行弱引用，以及使用单引号（''）对一段文本进行强引用。这与许多编程语言中所做的工作非常相似，并且非常接近 Bourne shell 中常见的做法。原理如下：当配置解析器将行剪切成单词时，它还会处理引号和反斜杠，以确定字符是分隔符还是当前单词中的该字符的原始表示形式。然后删除转义字符，删除引号，剩余的单词按原样用作关键字或参数。如果单词中需要反斜杠，则必须使用自身进行转义（即双反斜杠）或进行强引用。引号外的转义是通过在特殊字符前加上反斜杠（'\'）来实现的：\ 将空格标记为与分隔符不同\# 将哈希标记为与注释开头不同\\ 使用反斜杠\' 使用单引号并将其与强引用分隔\" 使用双引号并将其与弱引用分隔此外，一些不可打印字符可以使用其通常的 C 语言表示形式发出：\n 插入换行符（LF，字符 \x0a 或 ASCII 10 十进制）\r 插入回车符（CR，字符 \x0d 或 ASCII 13 十进制）\t 插入制表符（字符 \x09 或 ASCII 9 十进制）\xNN 插入 ASCII 代码为十六进制 NN 的字符（例如 \x0a 代表 LF）。弱引用是通过在要保护的字符或字符序列周围加上双引号（""）来实现的。弱引用可防止对以下内容的解释：空格或制表符作为单词分隔符' 单引号作为强引用分隔符# 哈希作为注释开头弱引用允许解释环境变量（在引号之外不进行评估），方法是在其前面加上美元符号（'$'）。如果双引号内需要美元字符，则必须使用反斜杠进行转义。强引用是通过在要保护的字符或字符序列周围加上单引号（''）来实现的。在单引号内，不解释任何内容，这是引用正则表达式的有效方式。因此，下表显示了特殊字符在不同上下文中如何输入（不可打印字符替换为其名称，并用尖括号括起来）。请注意，某些只能以转义形式表示的字符在单引号内没有可能的表示形式，因此表中缺少它们

# 以下这些都是完全等效的： 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

There is one particular case where a second level of quoting or escaping may be necessary. Some keywords take arguments within parenthesis, sometimes delimited by commas. These arguments are commonly integers or predefined words, but when they are arbitrary strings, it may be required to perform a separate level of escaping to disambiguate the characters that belong to the argument from the characters that are used to delimit the arguments themselves. A pretty common case is the "regsub" converter. It takes a regular expression in argument, and if a closing parenthesis is needed inside, this one will require to have its own quotes. The keyword argument parser is exactly the same as the top-level one regarding quotes, except that the \#, \$, and \xNN escapes are not processed. But what is not always obvious is that the delimiters used inside must first be escaped or quoted so that they are not resolved at the top level. Let's take this example making use of the "regsub" converter which takes 3 arguments, one regular expression, one replacement string and one set of flags: # replace all occurrences of "foo" with "blah" in the path: http-request set-path %[path,regsub(foo,blah,g)] Here no special quoting was necessary. But if now we want to replace either "foo" or "bar" with "blah", we'll need the regular expression "(foo|bar)". We cannot write: http-request set-path %[path,regsub((foo|bar),blah,g)] because we would like the string to cut like this: http-request set-path %[path,regsub((foo|bar),blah,g)] |---------|----|-| arg1 _/ / / arg2 __________/ / arg3 ______________/ but actually what is passed is a string between the opening and closing parenthesis then garbage: http-request set-path %[path,regsub((foo|bar),blah,g)] |--------|--------| arg1=(foo|bar _/ / trailing garbage _________/ The obvious solution here seems to be that the closing parenthesis needs to be quoted, but alone this will not work, because as mentioned above, quotes are processed by the top-level parser which will resolve them before processing this word: http-request set-path %[path,regsub("(foo|bar)",blah,g)] ------------ -------- ---------------------------------- word1 word2 word3=%[path,regsub((foo|bar),blah,g)] So we didn't change anything for the argument parser at the second level which still sees a truncated regular expression as the only argument, and garbage at the end of the string. By escaping the quotes they will be passed unmodified to the second level: http-request set-path %[path,regsub(\"(foo|bar)\",blah,g)] ------------ -------- ------------------------------------ word1 word2 word3=%[path,regsub("(foo|bar)",blah,g)] |---------||----|-| arg1=(foo|bar) _/ / / arg2=blah ___________/ / arg3=g _______________/ Another approach consists in using single quotes outside the whole string and double quotes inside (so that the double quotes are not stripped again): http-request set-path '%[path,regsub("(foo|bar)",blah,g)]' ------------ -------- ---------------------------------- word1 word2 word3=%[path,regsub("(foo|bar)",blah,g)] |---------||----|-| arg1=(foo|bar) _/ / / arg2 ___________/ / arg3 _______________/ But in this case it's important to note that delimiters embedded into the higher level string remain pure characters and are not delimiters anymore. It particularly means that spaces and tabs around commas are part of the string. The example below is wrong on multiple points: http-request set-path '%[path, regsub("(foo|bar)", blah, g)]' ------------ -------- -------------------------------------- word1 word2 word3=%[path, regsub("(foo|bar)", blah, g)] |--------|---------||-----|--| converter=" regsub" _/ / / / arg1=(foo|bar) _/ / / arg2=" blah" ___________/ / arg3=" g" ______________/ The single fact of surrounding commas with spaces resulted in the spaces being part of the field itself, hence the converter " regsub" (starting with a space), which won't be found and will trigger an error, but more subtly, the replacement string " blah" will insert a space in the output. A good rule of thumb is to never insert unneeded spaces inside expressions. When using regular expressions, it can happen that the dollar ('$') character appears in the expression or that a backslash ('\') is used in the replacement string. In this case these ones will also be processed inside the double quotes thus single quotes are preferred (or double escaping). Example: http-request set-path '%[path,regsub("^/(here)(/|$)","my/\1",g)]' ------------ -------- ----------------------------------------- word1 word2 word3=%[path,regsub("^/(here)(/|$)","my/\1",g)] |-------------| |-----||-| arg1=(here)(/|$) _/ / / arg2=my/\1 ________________/ / arg3 ______________________/ Remember that backslashes are not escape characters within single quotes and that the whole word above is already protected against them using the single quotes. Conversely, if double quotes had been used around the whole expression, single the dollar character and the backslashes would have been resolved at top level, breaking the argument contents at the second level. Unfortunately, since single quotes can't be escaped inside of strong quoting, if you need to include single quotes in your argument, you will need to escape or quote them twice. There are a few ways to do this: http-request set-var(txn.foo) str("\\'foo\\'") http-request set-var(txn.foo) str(\"\'foo\'\") http-request set-var(txn.foo) str(\\\'foo\\\') When in doubt, simply do not use quotes anywhere, and start to place single or double quotes around arguments that require a comma or a closing parenthesis, and think about escaping these quotes using a backslash if the string contains a dollar or a backslash. Again, this is pretty similar to what is used under a Bourne shell when double-escaping a command passed to "eval". For API writers the best is probably to place escaped quotes around each and every argument, regardless of their contents. Users will probably find that using single quotes around the whole expression and double quotes around each argument provides more readable configurations.

HAProxy 的配置支持环境变量。这些变量仅在双引号内被解释。变量在配置解析期间被展开。变量名前必须有美元符号 ("$")，并且可以选择性地用大括号 ("{}") 括起来，类似于 Bourne shell 中的做法。变量名可以包含字母数字字符或下划线 ("_")，但不应以数字开头。如果变量包含由空格分隔的多个值列表，可以通过用大括号将变量括起来并在右大括号前附加后缀 '[*]' 来将其展开为单个参数。当变量未设置时，也可以通过在变量名旁边的破折号 '-' 后面附加该值来指定一个默认值。请注意，默认值只替换不存在的变量，而不是空变量。

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

HAProxy 定义了一些变量，这些变量可以在配置文件中使用。这些变量列在下面的矩阵中，它们被分为四类： * usable：变量可以在配置中访问，可以按原样解析，也可以在条件块或谓词中使用，以启用或禁用某些配置片段，如第 2.4 节“条件块”所述。 * modifiable：变量可以在配置中通过 "setenv" / "unsetenv" 关键字重新定义或取消设置。 * listed：变量列在 CLI 的 "show env" 命令输出中，如管理指南第 9.3 节“Unix 套接字命令”所述。还有两个子类别“master”和“worker”，在下表中分别标记为“M”和“W”，显示了 HAProxy 以 master-worker 模式启动时两个进程之间的差异。 * master：变量在 master 进程中设置并可访问。因此，它将出现在 master CLI 的 "show env" 输出中，并且可以在条件块或指令中使用，以启用 master 的一些特殊设置（参见第 2.4 节“条件块”中的示例）。 * worker：变量在 worker 进程中设置并可访问。它将出现在 worker CLI 的 "show env"（或 master CLI 的 "@1 show env"）中，并且也可以限制某些 worker 进程参数（参见第 2.4 节“条件块”中的示例）。 在独立模式下（没有 "-W" 选项或 "master-worker" 关键字），进程的行为类似于 worker，除了变量 "HAPROXY_MASTER_CLI" 和 "HAPROXY_MWORKER" 未定义。 有些变量被标记为不可用且不可修改： * HAPROXY_CFGFILES * HAPROXY_MWORKER * HAPROXY_CLI * HAPROXY_MASTER_CLI * HAPROXY_LOCALPEER 它们的值在配置解析期间未定义，而是在初始化期间设置的。因此，建议不要在条件块中使用这些变量，也不要在 global 部分的 "setenv" / "resetenv" / "unsetenv" 关键字中引用它们。 下表总结了每个变量在不同工作模式下的状态： +--------------------------+---------+------------+-----------+ | variable | usable | modifiable | listed | | +---------+------------+-----------+ | | M | W | M | W | M | W | +--------------------------+----+----+------+-----+-----+-----+ | HAPROXY_STARTUP_VERSION | X | X | | | X | X | | HAPROXY_BRANCH | X | X | | | X | X | | HAPROXY_CFGFILES | | | | | X | X | | HAPROXY_MWORKER | | | | | X | X | | HAPROXY_CLI | | | | | | X | | HAPROXY_MASTER_CLI | | | | | X | | | HAPROXY_LOCALPEER | | X | | | | X | | HAPROXY_HTTP_LOG_FMT | | X | | X | | | | HAPROXY_HTTP_CLF_LOG_FMT | | X | | X | | | | HAPROXY_HTTPS_LOG_FMT | | X | | X | | | | HAPROXY_TCP_LOG_FMT | | X | | X | | | +--------------------------+----+----+------+-----+-----+-----+ 所讨论的变量如下： * HAPROXY_LOCALPEER：在进程启动时定义，包含本地对等体的名称。（请参阅管理指南中的 "-L"。） * HAPROXY_CFGFILES：HAProxy 加载的配置文件的列表，以分号分隔。如果您指定了一个目录，这可能很有用。 * HAPROXY_HTTP_LOG_FMT：包含第 8.2.3 节“HTTP 日志格式”中定义的默认 HTTP 日志格式的值。它可用于覆盖默认日志格式，而无需复制整个原始定义。 * HAPROXY_HTTP_CLF_LOG_FMT：包含第 8.2.3 节“HTTP 日志格式”中定义的默认 HTTP CLF 日志格式的值。它可用于覆盖默认日志格式，而无需复制整个原始定义。

# 将给出最终判决的规则添加到日志中 log-format "${HAPROXY_TCP_LOG_FMT} lr=last_rule_file:last_rule_line"

* HAPROXY_HTTPS_LOG_FMT：与 HAPROXY_HTTP_LOG_FMT 类似，但用于第 8.2.4 节“HTTPS 日志格式”中定义的 HTTPS 日志格式。 * HAPROXY_TCP_LOG_FMT：与 HAPROXY_HTTP_LOG_FMT 类似，但用于第 8.2.2 节“TCP 日志格式”中定义的 TCP 日志格式。 * HAPROXY_TCP_CLF_LOG_FMT：与 HAPROXY_HTTP_CLF_LOG_FMT 类似，但用于第 8.2.2 节“TCP 日志格式”中定义的 TCP CLF 日志格式。 * HAPROXY_MWORKER：在 master-worker 模式下，此变量设置为 1。 * HAPROXY_CLI：每个进程的 stats socket 配置的监听地址，这些地址以分号分隔。 * HAPROXY_MASTER_CLI：在 master-worker 模式下，master CLI 的监听地址，以分号分隔。 * HAPROXY_STARTUP_VERSION：包含用于启动的版本，在 master-worker 模式下，这是用于启动 master 的版本，即使在更新二进制文件和重新加载之后也是如此。 * HAPROXY_BRANCH：包含 HAProxy 分支版本（例如 "2.8"）。它不包含完整的版本号。如果资源（如 maps 或证书）位于包含分支号的路径中，这在迁移情况下很有用。 此外，一些伪变量在内部解析，可以用作常规变量。伪变量总是以点号（'.'）开头，并且是唯一允许使用点号的变量。当前的伪变量列表是： * .FILE：当前正在解析的配置文件的名称。 * .LINE：当前正在解析的配置文件的行号，从一开始。 * .SECTION：当前正在解析的节的名称，如果该节没有名称（例如 "global"），则为其类型，或者在第一个节之前为空字符串。 这些变量在它们被解析的位置解析。例如，如果 ".LINE" 变量用于位于 defaults 节中的 "log-format" 指令中，它的行号将在解析和编译 "log-format" 指令之前解析，因此后续代理将重用相同的行号。通过这种方式，可以发出信息以帮助在变量、日志、错误状态、健康检查、标头值中查找规则，甚至可以使用行号来命名某些配置对象，例如服务器。

有时，有条件地启用或禁用配置的某些任意部分可能很方便，例如启用/禁用 SSL 或密码、启用或禁用某些预生产侦听器而无需修改配置，或者调整配置的语法以在迁移期间支持两个不同的 HAProxy 版本。 HAProxy 带来了一组可嵌套的类似预处理器的指令，允许集成或忽略一些文本块。这些指令必须放在自己的行上，它们作用于其后的行。其中两个支持表达式，其他的只切换到备用块或结束当前级别。 定义了以下 4 个指令来形成条件块： - .if <condition> - .elif <condition> - .else - .endif ".if" 指令嵌套一个新级别，".elif" 保持在同一级别，".else" 也是如此，".endif" 关闭一个级别。每个 ".if" 必须以匹配的 ".endif" 终止。".elif" 只能放在 ".if" 或 ".elif" 之后，并且可以链接的 ".elif" 数量没有限制。每个 ".if" 只能有一个 ".else"，并且它必须始终位于 ".if" 或块中最后一个 ".elif" 之后。 如果需要在 '#' 之后放置注释，它们将被忽略。指令像其他配置指令一样被标记化，因此可以在条件中使用环境变量。条件也可以在启动时使用 -cc 参数进行评估。请参阅管理文档中的“3. 启动 HAProxy”。 条件要么是空字符串（返回 false），要么是由以下任意组合组成的表达式： - 整数零 ('0')，始终返回 "false" - 非零整数（例如 '1'），始终返回 "true"。 - 一个谓词，可选地后跟括号中的参数。 - 放置在一对括号 '(' 和 ')' 之间的条件 - 一个感叹号 ('!')，放在上述任何非空元素之前，它将否定其状态。 - 使用逻辑 AND ('&&') 组合的表达式，将从左到右评估，直到一个返回 false - 使用逻辑 OR ('||') 组合的表达式，将从右到左评估，直到一个返回 true 使用与配置语言其余部分相同的行标记器和参数解析器。单词围绕连续的一个或多个未加引号的空格或制表符拆分，并在评估之前使用单个空格重新组合在一起以分隔它们，以避免用户必须引用整行。但这_也_意味着围绕逗号或括号的空格绝对是值的一部分，这并不总是预期的。例如，下面的表达式： .if defined( HAPROXY_MWORKER ) 将测试变量 " HAPROXY_MWORKER "（带空格）是否存在，而这个： .if streq("$ENABLE_SSL", 1) 将把环境变量 "ENABLE_SSL" 与值 " 1"（带一个前导空格）进行比较。原因是该行首先被拆分成如下所示的单词： .if streq("$ENABLE_SSL", 1) |---|--------------------| |--| 1 2 3 然后应用弱引用并解析环境变量 "$ENABLE_SSL"（假设 ENABLE_SSL=0），最后通过在单词之间放置单个空格将单词重新组合成一个字符串： .if streq(0, 1) |---|-------|--| 1 2 3 然后才将其解析为单个表达式。在逗号和 "1" 之间插入的空格仍然是参数值的一部分，使此参数变为 " 1"： .if streq(0, 1) |---|-----|-|--| \ \ \ \_ argument2: " 1" \ \ \___ argument1: "0" \ \_______ function: "streq" \___________ directive: ".if" 在这里可以看到，即使 ENABLE_SSL 等于 "1"，它也不会匹配 " 1"，因为字符串会相差一个空格。注意：如“2.2. 引用和转义”中所述，一个好的经验法则是永远不要在表达式中插入不必要的空格。 请注意，与在其他语言中一样，AND 运算符优先于 OR 运算符，因此 "A && B || C && D" 评估为 "(A && B) || (C && D)"。 当前支持的谓词列表如下： - awslc_api_atleast(<ver>): 如果当前 awslc API 号码至少与 <ver> 一样新，则返回 true，否则返回 false。

awslc_api_atleast(35)

- awslc_api_before(<ver>): 如果当前 awslc API 号码严格早于 <ver>，则返回 true，否则返回 false。

awslc_api_before(26)

- defined(<name>) : 如果环境变量 <name> 存在，无论其内容如何，则返回 true - feature(<name>) : 如果功能 <name> 列在 "haproxy -vv" 报告的功能列表中（这意味着 <name> 出现在 '+' 之后），则返回 true - openssl_version_atleast(<ver>) : 如果当前 openssl 版本至少与 <ver> 一样新，则返回 true，否则返回 false。 LibreSSL、AWS-LC 和 WolfSSL 等库也提供伪 OpenSSL 版本。

ssllib_name_startswith(OpenSSL) && openssl_version_atleast(1.1.1)

- openssl_version_before(<版本>)：如果当前的 openssl 版本严格早于 <版本>，则返回 true，否则返回 false。像 LibreSSL、AWS-LC 和 WolfSSL 这样的库也提供一个伪 OpenSSL 版本。

openssl_version_before(3.5.0)

- ssllib_name_startswith(<名称>)：如果 HAProxy 链接的 SSL 库名称以 <名称> 开头，则返回 true。

ssllib_name_startswith(wolfSSL)

- streq(<字符串1>,<字符串2>)：仅当两个字符串相等时返回 true - strneq(<字符串1>,<字符串2>)：仅当两个字符串不同时返回 true - strstr(<字符串1>,<字符串2>)：仅当第二个字符串在第一个字符串中找到时返回 true。 - version_atleast(<版本>)：如果当前的 haproxy 版本至少与 <版本> 一样新，则返回 true，否则返回 false。版本语法与 "haproxy -v" 显示的相同，缺失的组件被假定为零。 - version_before(<版本>)：如果当前的 haproxy 版本严格早于 <版本>，则返回 true，否则返回 false。版本语法与 "haproxy -v" 显示的相同，缺失的组件被假定为零。 - enabled(<选项>)：如果选项 <选项> 在运行时启用，则返回 true。仅支持一部分选项：POLL、EPOLL、KQUEUE、EVPORTS、SPLICE、GETADDRINFO、REUSEPORT、FAST-FORWARD、SERVER-SSL-VERIFY-NONE

# 1. HAPROXY_MWORKER 变量由 HAProxy 在 master 和 worker 进程环境中自动设置 # （参见 2.3. 环境变量中的 HAProxy 变量矩阵）。它的存在会启用一个额外的侦听器。 global master-worker .if defined(HAPROXY_MWORKER) listen mwcli_px bind :1111 ... .endif # 2. HAPROXY_BRANCH 由 HAProxy 在 master 和 worker 进程环境中自动设置 # （参见 2.3. 环境变量中的 HAProxy 变量矩阵）。我们检查 HAPROXY_BRANCH 值并有条件地启用 # mworker-max-reloads 参数。 global master-worker .if streq("$HAPROXY_BRANCH",3.1) mworker-max-reloads 5 .endif # 3. 一些任意环境变量由用户在 global 部分设置。如果 HAProxy 以 master-worker 模式启动， # 它们将呈现在 master 和 worker 进程环境中。我们检查这些变量的值并有条件地启用端口 80 和 443。 # 环境变量检查可以与功能和版本检查混合使用。 global setenv WITH_SSL yes unsetenv SSL_ONLY .if strneq("$SSL_ONLY",yes) bind :80 .endif .if streq("$WITH_SSL",yes) .if feature(OPENSSL) bind :443 ssl crt ... .endif .endif .if feature(OPENSSL) && (streq("$WITH_SSL",yes) || streq("$SSL_ONLY",yes)) bind :443 ssl crt ... .endif .if version_atleast(2.4-dev19) profiling.memory on .endif .if !feature(OPENSSL) .alert "SSL support is mandatory" .endif

还提供了另外四个指令来报告某些状态： - .diag "message" : 仅在诊断模式（-dD）下发出此消息 - .notice "message" : 以 NOTICE 级别发出此消息 - .warning "message" : 以 WARNING 级别发出此消息 - .alert "message" : 以 ALERT 级别发出此消息 如果启用了 "zero-warning"，以 WARNING 级别发出的消息可能导致进程启动失败。以 ALERT 级别发出的消息将始终导致致命错误。这些可以用来检测一些不适当的条件并向用户提供建议。

.if "${A}" .if "${B}" .notice "A=1, B=1" .elif "${C}" .notice "A=1, B=0, C=1" .elif "${D}" .warning "A=1, B=0, C=0, D=1" .else .alert "A=1, B=0, C=0, D=0" .endif .else .notice "A=0" .endif .diag "WTA/2021-05-07: 切换到 2.4 后将 'redirect' 替换为 'return'" http-request redirect location /goaway if ABUSE

一些参数涉及表示时间的值，例如超时。这些值通常以毫秒表示（除非另有明确说明），但也可以通过在数值后附加单位来以任何其他单位表示。考虑这一点很重要，因为每个关键字都不会重复说明。支持的单位有：- 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

一些参数涉及表示大小的值，例如带宽限制。这些值通常以字节表示（除非另有明确说明），但也可以通过在数值后附加单位来以任何其他单位表示。考虑这一点很重要，因为每个关键字都不会重复说明。支持的单位不区分大小写：- k：千字节。1 千字节 = 1024 字节 - m：兆字节。1 兆字节 = 1048576 字节 - g：吉字节。1 吉字节 = 1073741824 字节 时间和大小格式都需要整数，不允许使用小数表示法。

可以使用地图或 ACL 的模式列表。模式列表由其名称标识，可以在配置中的不同位置使用。模式列表根据名称格式分为三类： * 基于常规文件的模式列表：这是默认情况。文件名（绝对或相对）用作名称。文件必须存在，否则会触发错误。但它可以是空的。也可以指定 "file@" 前缀，但它不是用于标识列表的名称的一部分。带前缀或不带前缀的文件名引用相同的模式列表。 * 基于可选文件的模式列表：文件名必须以 "opt@" 前缀开头。文件存在是可选的。如果文件存在，则加载其内容，但如果不存在，则不报告错误。前缀不是用于标识列表的名称的一部分。这意味着，对于给定的文件名，可选文件和常规文件引用相同的模式列表。 * 基于虚拟文件的模式列表：名称只是一个标识符。它不是对任何文件的引用。"virt@" 前缀必须使用。它是名称的一部分。因此，它不能与任何其他类型的列表混合使用。当模式完全动态管理，启动和重新加载时没有模式时，虚拟文件非常有用。可选文件可以在相同条件下使用。但是模式可以转储到文件中，例如通过基于 "show map" CLI 命令的外部脚本。通过这种方式，可以在重新加载时保留模式。注意：即使不太可能，这也意味着不能加载以 "file@"、"opt@" 或 "virt@" 开头的常规文件，除非在文件名前面显式添加 "./"（例如 "file@./virt@map"）。

在 HAProxy 配置中，变量可以在示例获取函数、转换器、log-format 字符串或 TCP/HTTP 操作中使用。可以定义进程范围的变量，在进程的整个生命周期内全局可访问。其他一些变量的生命周期较短。变量类似于 shell 脚本中找到的变量。它是内存块的符号名称。变量大小不受限制且动态分配。因此必须谨慎使用，特别是对于密集使用。但是，可以通过设置 "tune.vars" 全局参数来限制变量使用的最大内存量。 变量必须使用 "<scope>.<name>" 格式指定。<scope> 是一个单词，表示变量的生命周期。<name> 部分在范围内可能只包含字符 'a-z'、'A-Z'、'0-9' 和 '_'。它在此范围内是唯一的，但不同范围中的相同名称可以用于指代不同的变量。 支持的范围是： * proc：用于在整个进程生命周期内已知且全局可访问的变量。可以使用 "get var" 和 "set var" 命令从 CLI 操作 "proc" 变量。它们也可以通过 "set-var
此关键字在以下部分可用：
进程管理和安全
按字母顺序排列的操作参考
转换器" 和 "set-var-fmt
此关键字在以下部分可用：
进程管理和安全
按字母顺序排列的操作参考" 指令从 "global" 部分设置。 * sess：用于在整个会话生命周期内已知的变量。"sess" 变量对于会话是私有的，在会话外部不可见，并且不与其他会话共享。 * txn：用于在整个事务生命周期内已知的变量。"txn" 变量对于流是私有的，在流外部不可见，并且不与其他流共享。 * req：用于在特定流的请求处理期间已知的变量。"req" 变量从流创建开始到第一次服务器连接尝试期间可见。它们对于流是私有的，在流外部不可见，并且不与其他流共享。"req" 和 "res" 变量之间没有重叠。 * res：用于在特定流的响应处理期间已知的变量。"res" 变量从第一次服务器连接尝试开始到流销毁期间可见。它们对于流是私有的，在流外部不可见，并且不与其他流共享。"req" 和 "res" 变量之间没有重叠。 * check：用于在健康检查执行期间已知的变量。"check" 变量对于健康检查是私有的，在健康检查外部不可见，并且不与其他健康检查共享。它们可以使用专用的 "tcp-check" 或 "http-check" 指令设置。 根据上下文，可以使用引用当前流的父流的额外范围： * psess：与 "sess" 相同，但使用父流的会话（如果有）。 * ptxn：与 "txn" 相同，但使用父流的事务（如果有）。 * preq：与 "req" 相同，但使用父流（如果有）。"preq" 变量仅在父流的请求处理期间可访问。 * pres：与 "res" 相同，但使用父流（如果有）。"pres" 变量仅在父流的响应处理期间可访问。 引用父流的范围从定义时起即可使用。大多数情况下，没有父流。但是，如果适用，将明确指定。目前，只能检索在父流范围中定义的变量的值。无法设置或取消设置此类变量。通常，子流在特定时刻为父流执行一些处理，并阻止父流继续进行，直到它完成的操作完成为止。这意味着父流可能在请求处理或响应处理中间停止。因此，某些范围将无法从子流访问。例如，如果请求受到子流执行的某些分析的影响，则此子流将无法在 "pres" 范围中找到任何变量，因为父流未处理响应，因此其 "res" 范围中没有任何变量。 变量的内容是样本获取表达式评估的结果，它继承了该表达式的输出类型。当使用变量时，这很重要，因为其类型必须与其用法兼容。例如，在 "add()" 转换器中使用的包含字符串的变量必须可转换为有效的整数才能成功。当变量与静态值进行比较时，尤其如此。必须使用正确的匹配方法。

多个语句如 "bind"、"server
此关键字在以下部分可用：
对等体声明
环
按字母顺序排列的关键字参考"、"nameserver" 和 "log
此关键字在以下部分可用：
对等体声明
日志转发
进程管理和安全
按字母顺序排列的关键字参考" 需要一个地址。此地址可以是主机名、IPv4 地址、IPv6 地址或 '*'。'*' 等于特殊地址 "0.0.0.0"，可用于 "bind
此关键字在以下部分可用：
对等体声明
日志转发
按字母顺序排列的关键字参考" 或 "dgram-bind" 的情况，用于侦听系统的所有 IPv4。IPv6 等效项是 '::'。根据语句的不同，IP 地址后面跟着一个端口或端口范围。这在 'bind' 语句上是必需的，在 'server' 上是可选的。此地址也可以以斜杠 '/' 开头。它被视为 "unix" 系列，'/' 和后面的字符必须是路径。默认套接字类型或传输方法 "datagram" 或 "stream" 取决于显示地址的配置语句。实际上，'bind' 和 'server' 默认使用 "stream" 套接字类型，而 'log'、'nameserver' 或 'dgram-bind' 默认使用 "datagram"。 可选地，可以使用前缀来强制地址族和/或套接字类型和传输方法。

'abns@<name>' 紧跟 <name> 的是抽象命名空间（仅限 Linux）。 'abnsz@<name>' 紧跟 <name> 的是零终止抽象命名空间（仅限 Linux）。 'fd@<n>' 紧跟地址的是从父级继承的文件描述符 <n>。fd 必须已绑定且可能已在侦听。 'ip@<address>[:port1[-port2]]' 紧跟 <address> 的被视为 IPv4 或 IPv6 地址，具体取决于语法。根据使用此地址的语句，可以或必须指定端口或端口范围。 'ipv4@<address>[:port1[-port2]]' 紧跟 <address> 的始终被视为 IPv4 地址。根据使用此地址的语句，可以或必须指定端口或端口范围。 'ipv6@<address>[:port1[-port2]]' 紧跟 <address> 的始终被视为 IPv6 地址。根据使用此地址的语句，可以或必须指定端口或端口范围。 'sockpair@<n>' 紧跟地址的是已连接的 unix socket 或 socketpair 的文件描述符。在连接期间，发起者创建一对已连接的套接字，并将其中一个通过 FD 传递给另一端。侦听器等待从 unix socket 接收 FD，并将其用作 accept() 的 FD。应谨慎使用。 错误：由于 macOS sendmsg(2) 实现中的问题，此协议在 macOS 上已知不可靠。连接可能无法正确接受。 'unix@<path>' 紧跟字符串的被视为 UNIX socket <path>。此前缀对于声明不以斜杠 '/' 开头的 UNIX socket 路径很有用。

前面的“地址族前缀”也可以作为前缀来强制套接字类型和传输方法。默认值取决于使用此地址的语句，但在某些情况下，用户可能会强制将其更改为不同的值。对于 "log
此关键字在以下部分可用：
对等体声明
日志转发
进程管理和安全
按字母顺序排列的关键字参考" 语句就是这种情况，其中默认值是通过 UDP 的 syslog，但我们可以强制使用通过 TCP 的 syslog。这些前缀是为内部目的设计的，用户应该改为使用下一节“2.9.3 协议前缀”的别名。但是，这些有时很方便，例如与通过其文件描述符编号已知的继承套接字结合使用时，在这种情况下，地址族是 "fd"，并且必须声明套接字类型。如果用户需要其中一个前缀来执行他们期望的操作，因为他们无法使用协议前缀配置相同的功能，则应向维护人员报告。 'stream+<family>@<address>' 强制套接字类型和传输方法为 "stream" 'dgram+<family>@<address>' 强制套接字类型和传输方法为 "datagram"。 'quic+<family>@<address>' 强制套接字类型为 "datagram" 和传输方法为 "stream"。

'quic4@<address>[:port1[-port2]]' 紧跟 <address> 的始终被视为 IPv4 地址，但套接字类型强制为 "datagram"，传输方法强制为 "stream"。根据使用此地址的语句，可以或必须指定 UDP 端口或端口范围。它等效于 "quic+ipv4@". 'quic6@<address>[:port1[-port2]]' 紧跟 <address> 的始终被视为 IPv6 地址，但套接字类型强制为 "datagram"，传输方法强制为 "stream"。根据使用此地址的语句，可以或必须指定 UDP 端口或端口范围。它等效于 "quic+ipv6@". 'tcp@<address>[:port1[-port2]]' 紧跟 <address> 的被视为 IPv4 或 IPv6 地址，具体取决于语法，但套接字类型和传输方法强制为 "stream"。根据使用此地址的语句，可以或必须指定端口或端口范围。它被视为 'stream+ip@' 的别名。 'tcp4@<address>[:port1[-port2]]' 紧跟 <address> 的始终被视为 IPv4 地址，但套接字类型和传输方法强制为 "stream"。根据使用此地址的语句，可以或必须指定端口或端口范围。它被视为 'stream+ipv4@' 的别名。 'tcp6@<address>[:port1[-port2]]' 紧跟 <address> 的始终被视为 IPv6 地址，但套接字类型和传输方法强制为 "stream"。根据使用此地址的语句，可以或必须指定端口或端口范围。它被视为 'stream+ipv4@' 的别名。 'mptcp@<address>[:port1[-port2]]' 紧跟 <address> 的被视为 IPv4 或 IPv6 地址，具体取决于语法，但套接字类型和传输方法强制为 "stream"，使用 MPTCP 协议。根据使用此地址的语句，可以或必须指定端口或端口范围。 'mptcp4@<address>[:port1[-port2]]' 紧跟 <address> 的始终被视为 IPv4 地址，但套接字类型和传输方法强制为 "stream"，使用 MPTCP 协议。根据使用此地址的语句，可以或必须指定端口或端口范围。 'mptcp6@<address>[:port1[-port2]]' 紧跟 <address> 的始终被视为 IPv6 地址，但套接字类型和传输方法强制为 "stream"，使用 MPTCP 协议。根据使用此地址的语句，可以或必须指定端口或端口范围。 'udp@<address>[:port1[-port2]]' 紧跟 <address> 的被视为 IPv4 或 IPv6 地址，具体取决于语法，但套接字类型和传输方法强制为 "datagram"。根据使用此地址的语句，可以或必须指定端口或端口范围。它被视为 'dgram+ip@' 的别名。 'udp4@<address>[:port1[-port2]]' 紧跟 <address> 的始终被视为 IPv4 地址，但套接字类型和传输方法强制为 "datagram"。根据使用此地址的语句，可以或必须指定端口或端口范围。它被视为 'dgram+ipv4@' 的别名。 'udp6@<address>[:port1[-port2]]' 紧跟 <address> 的始终被视为 IPv6 地址，但套接字类型和传输方法强制为 "datagram"。根据使用此地址的语句，可以或必须指定端口或端口范围。它被视为 'dgram+ipv4@' 的别名。 'uxdg@<path>' 紧跟字符串的被视为 unix socket <path>，但传输方法强制为 "datagram"。它被视为 'dgram+unix@' 的别名。 'uxst@<path>' 紧跟字符串的被视为 unix socket <path>，但传输方法强制为 "stream"。它被视为 'stream+unix@' 的别名。 在未来的版本中，可以使用其他前缀来指定 QUIC 等协议，这些协议基于 "datagram" 类型的套接字提供流传输。

# 一个简单的 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”部分支持以下关键字： * 进程管理和安全 - 51degrees-allow-unmatched - 51degrees-cache-size - 51degrees-data-file - 51degrees-difference - 51degrees-drift - 51degrees-property-name-list - 51degrees-property-separator - 51degrees-use-performance-graph - 51degrees-use-predictive-graph - ca-base - chroot - cluster-secret - cpu-map - cpu-policy - cpu-set - crt-base - daemon - default-path - description - deviceatlas-json-file - deviceatlas-log-level - deviceatlas-properties-cookie - deviceatlas-separator - dns-accept-family - expose-deprecated-directives - expose-experimental-directives - external-check - fd-hard-limit - gid - grace - group - h1-accept-payload-with-any-method - h1-case-adjust - h1-case-adjust-file - h1-do-not-close-on-insecure-transfer-encoding - h2-workaround-bogus-websocket-clients - hard-stop-after - harden.reject-privileged-ports.tcp - harden.reject-privileged-ports.quic - insecure-fork-wanted - insecure-setuid-wanted - issuers-chain-path - key-base - limited-quic - localpeer - log - log-send-hostname - log-tag - lua-load - lua-load-per-thread - lua-prepend-path - mworker-max-reloads - nbthread - node - numa-cpu-mapping - ocsp-update.disable - ocsp-update.maxdelay - ocsp-update.mindelay - ocsp-update.httpproxy - ocsp-update.mode - pidfile - pp2-never-send-local - presetenv - prealloc-fd - resetenv - set-dumpable - set-var - setenv - ssl-default-bind-ciphers - ssl-default-bind-ciphersuites - ssl-default-bind-client-sigalgs - ssl-default-bind-curves - ssl-default-bind-options - ssl-default-bind-sigalgs - ssl-default-server-ciphers - ssl-default-server-ciphersuites - ssl-default-server-client-sigalgs - ssl-default-server-curves - ssl-default-server-options - ssl-default-server-sigalgs - ssl-dh-param-file - ssl-propquery - ssl-provider - ssl-provider-path - ssl-security-level - ssl-server-verify - ssl-skip-self-issued-ca - stats - stats-file - strict-limits - uid - ulimit-n - unix-bind - unsetenv - user - wurfl-cache-size - wurfl-data-file - wurfl-information-list - wurfl-information-list-separator * 性能调优 - busy-polling - max-spread-checks - maxcompcpuusage - maxcomprate - maxconn - maxconnrate - maxpipes - maxsessrate - maxsslconn - maxsslrate - maxzlibmem - no-memory-trimming - noepoll - noevports - nogetaddrinfo - nokqueue - noktls - nopoll - noreuseport - nosplice - profiling.memory - profiling.tasks - server-state-base - server-state-file - spread-checks - ssl-engine - ssl-mode-async - tune.applet.zero-copy-forwarding - tune.buffers.limit - tune.buffers.reserve - tune.bufsize - tune.bufsize.small - tune.comp.maxlevel - tune.disable-fast-forward - tune.disable-zero-copy-forwarding - tune.epoll.mask-events - tune.events.max-events-at-once - tune.fail-alloc - tune.fd.edge-triggered - tune.h1.zero-copy-fwd-recv - tune.h1.zero-copy-fwd-send - tune.h2.be.glitches-threshold - tune.h2.be.initial-window-size - tune.h2.be.max-concurrent-streams - tune.h2.be.rxbuf - tune.h2.fe.glitches-threshold - tune.h2.fe.initial-window-size - tune.h2.fe.max-concurrent-streams - tune.h2.fe.max-total-streams - tune.h2.fe.rxbuf - tune.h2.header-table-size - tune.h2.initial-window-size - tune.h2.max-concurrent-streams - tune.h2.max-frame-size - tune.h2.zero-copy-fwd-send - tune.http.cookielen - tune.http.logurilen - tune.http.maxhdr - tune.idle-pool.shared - tune.idletimer - tune.lua.bool-sample-conversion - tune.lua.burst-timeout - tune.lua.forced-yield - tune.lua.log.loggers - tune.lua.log.stderr - tune.lua.maxmem - tune.lua.service-timeout - tune.lua.session-timeout - tune.lua.task-timeout - tune.max-checks-per-thread - tune.maxaccept - tune.maxpollevents - tune.maxrewrite - tune.max-rules-at-once - tune.memory.hot-size - tune.pattern.cache-size - tune.peers.max-updates-at-once - tune.pipesize - tune.pool-high-fd-ratio - tune.pool-low-fd-ratio - tune.pt.zero-copy-forwarding - tune.quic.be.cc.cubic-min-losses - tune.quic.be.cc.hystart - tune.quic.be.cc.max-frame-loss - tune.quic.be.cc.max-win-size - tune.quic.be.cc.reorder-ratio - tune.quic.be.max-idle-timeout - tune.quic.be.sec.glitches-threshold - tune.quic.be.stream.data-ratio - tune.quic.be.stream.max-concurrent - tune.quic.be.stream.rxbuf - tune.quic.be.tx.pacing - tune.quic.be.tx.udp-gso - tune.quic.cc.cubic.min-losses (deprecated) - tune.quic.cc-hystart (deprecated) - tune.quic.disable-tx-pacing (deprecated) - tune.quic.disable-udp-gso (deprecated) - tune.quic.fe.cc.cubic-min-losses - tune.quic.fe.cc.hystart - tune.quic.fe.cc.max-frame-loss - tune.quic.fe.cc.max-win-size - tune.quic.fe.cc.reorder-ratio - tune.quic.fe.max-idle-timeout - tune.quic.fe.sec.glitches-threshold - tune.quic.fe.sec.retry-threshold - tune.quic.fe.sock-per-conn - tune.quic.fe.stream.data-ratio - tune.quic.fe.stream.max-concurrent - tune.quic.fe.stream.rxbuf - tune.quic.fe.tx.pacing - tune.quic.fe.tx.udp-gso - tune.quic.frontend.max-data-size (deprecated) - tune.quic.frontend.max-idle-timeout (deprecated) - tune.quic.frontend.max-streams-bidi (deprecated) - tune.quic.frontend.max-tx-mem (deprecated) - tune.quic.frontend.stream-data-ratio (deprecated) - tune.quic.frontend.default-max-window-size (deprecated) - tune.quic.listen - tune.quic.max-frame-loss (deprecated) - tune.quic.mem.tx-max - tune.quic.reorder-ratio (deprecated) - tune.quic.retry-threshold (deprecated) - tune.quic.socket-owner (deprecated) - tune.quic.zero-copy-fwd-send - tune.renice.runtime - tune.renice.startup - tune.rcvbuf.backend - tune.rcvbuf.client - tune.rcvbuf.frontend - tune.rcvbuf.server - tune.recv_enough - tune.ring.queues - tune.runqueue-depth - tune.sched.low-latency - tune.sndbuf.backend - tune.sndbuf.client - tune.sndbuf.frontend - tune.sndbuf.server - tune.stick-counters - tune.ssl.cachesize - tune.ssl.capture-buffer-size - tune.ssl.capture-cipherlist-size (deprecated) - tune.ssl.default-dh-param - tune.ssl.force-private-cache - tune.ssl.hard-maxrecord - tune.ssl.keylog - tune.ssl.lifetime - tune.ssl.maxrecord - tune.ssl.ssl-ctx-cache-size - tune.ssl.ocsp-update.maxdelay (deprecated) - tune.ssl.ocsp-update.mindelay (deprecated) - tune.takeover-other-tg-connections - 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 * 调试 - anonkey - debug.counters - force-cfg-parser-pause - quiet - warn-blocked-traffic-after - zero-warning * HTTP客户端 - httpclient.resolvers.disabled - httpclient.resolvers.id - httpclient.resolvers.prefer - httpclient.retries - httpclient.ssl.ca-file - httpclient.ssl.verify - httpclient.timeout.connect

用于提供设备检测服务的 51Degrees 数据文件的路径。该文件应该是解压缩的，并且 HAProxy 具有相关权限可以访问。请注意，此选项仅在 HAProxy 编译时启用了 USE_51DEGREES 的情况下可用。

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

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

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

启用（'on'）或禁用（'off'）在检测过程中使用性能图。默认值取决于 51Degrees 库。请注意，此选项仅在 HAProxy 编译时启用了 USE_51DEGREES 和 51DEGREES_VER=4 的情况下可用。

启用（'on'）或禁用（'off'）在检测过程中使用预测图。默认值取决于 51Degrees 库。请注意，此选项仅在 HAProxy 编译时启用了 USE_51DEGREES 和 51DEGREES_VER=4 的情况下可用。

设置检测可以允许的漂移值。请注意，此选项仅在 HAProxy 编译时启用了 USE_51DEGREES 和 51DEGREES_VER=4 的情况下可用。

设置检测可以允许的差异值。请注意，此选项仅在 HAProxy 编译时启用了 USE_51DEGREES 和 51DEGREES_VER=4 的情况下可用。

启用（'on'）或禁用（'off'）在检测过程中使用不匹配的节点。默认值取决于 51Degrees 库。请注意，此选项仅在 HAProxy 编译时启用了 USE_51DEGREES 和 51DEGREES_VER=4 的情况下可用。

启用或禁用 ACME 调度器。ACME 调度器在 HAProxy 启动时启动，它将遍历证书并在 notAfter 值超过 curtime + (notAfter - notBefore) / 12 时，或者如果 notBefore 未定义则在 7 天时启动 ACME 续订任务。然后调度器将休眠并在 12 小时后唤醒。默认值为 "auto"。

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

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

定义一个时间窗口，在此期间，在软停止的情况下，空闲连接和活动连接的关闭将被分散进行。收到 SIGUSR1 并且宽限期结束后（如果有的话），如果没有设置此选项，空闲连接将立即全部关闭，而活动的 HTTP 或 HTTP2 连接将在收到下一个请求后结束，方法是在 HTTP 响应中附加“Connection: close”行，或者在 HTTP2 的情况下发送 GOAWAY 帧。当设置此选项时，连接关闭将在此设定的 <time> 内分散进行。如果 close-spread-time 设置为“infinite”，则在软停止期间将禁用活动连接的关闭。“Connection: close”头将不再添加到 HTTP 响应中（或 HTTP2 的 GOAWAY），空闲连接只有在其超时到达时（基于配置中设置的各种超时）才会被关闭。

<time> 是一个时间窗口（默认为毫秒），在此期间，连接关闭将在软停止操作期间分散进行，或者如果应禁用活动连接关闭，则为“infinite”。

如果使用了“hard-stop-after”选项，建议将此设置的值设置为低于该选项中使用的值，以便所有连接都有机会在进程停止前正常关闭。

定义一个由属于同一集群的多个节点共享的 ASCII 字符串密钥。它可以用于不同的用途。它至少用于为该进程实例化的所有 QUIC 连接派生无状态重置令牌。这也用于派生用于加密重试令牌的密钥。如果未设置此参数，则在进程启动时将选择一个随机值。这允许使用依赖于它的功能，尽管有一些限制。

在某些操作系统上，可以将线程组或线程绑定到特定的 CPU 集。这意味着指定的线程永远不会在其他 CPU 上运行。 "cpu-map" 指令指定单个线程或线程组的 CPU 集。第一个参数是线程组范围，可选地后跟一个线程集。这些范围具有以下格式： all | odd | even | number[-[number]] <number> 必须是 1 到 32 或 64 之间的数字，具体取决于机器的字大小。任何大于 'thread-groups' 的组 ID 和大于机器字大小的线程 ID 都将被忽略。所有线程编号都相对于它们所属的组。可以使用由短划线 ('-') 分隔的两个此类数字指定范围。还可以使用 "all" 一次指定所有线程，使用 "odd" 指定奇数编号，或使用 "even" 指定偶数编号，就像使用 "thread
此关键字在以下部分可用：
绑定选项
从内部状态获取样本" 绑定指令一样。 第二个和后续参数是 CPU 集。每个 CPU 集要么是一个唯一的数字（从第一个 CPU 的 0 开始），要么是由短划线 ('-') 分隔的两个此类数字的范围。这些 CPU 编号和范围可以通过逗号分隔或通过在同一行上将更多范围作为新参数传递来重复。 在 Linux 和 BSD 操作系统之外，最大 CPU 索引可能限制为 31 或 63。 可以指定多个 "cpu-map" 指令，但当它们重叠时，每个 "cpu-map" 指令将替换前一个。范围可以部分定义。可以省略上限。在这种情况下，它将被替换为相应的最大值，具体取决于机器的字大小，为 32 或 64。 可以在线程集之前添加前缀 "auto:"，让 HAProxy 通过递增线程和 CPU 集自动将一组线程绑定到 CPU。为了有效，两个集必须具有相同的大小。无论 CPU 集的声明顺序如何，都将从最低绑定到最高绑定。不支持同时具有组和线程范围且带有 "auto:" 前缀。只支持一个范围，另一个必须是固定数字。请注意，支持组范围是出于历史原因。现在，一个单独的数字指定一个线程组，如果不使用线程组，则必须为 1，并且指定线程范围或数字需要在其前面加上 "1/"（如果不使用线程组）。最后，"1" 严格等同于 "1/all"，并指定组中的所有线程。

cpu-map 1/all 0-3 # 将第一个组的所有线程绑定到 # 前 4 个 CPU cpu-map 1/1- 0- # 将被 "cpu-map 1/1-64 0-63" 或 "cpu-map 1/1-32 0-31" 替换， # 具体取决于机器的字大小。 # 所有这些行都将线程 1 绑定到 cpu 0，线程 2 绑定到 cpu 1，依此类推。 cpu-map auto:1/1-4 0-3 cpu-map auto:1/1-4 0-1 2-3 cpu-map auto:1/1-4 3 2 1 0 cpu-map auto:1/1-4 3,2,1,0 # 使用 all/odd/even 关键字将每个线程绑定到恰好一个 CPU cpu-map auto:1/all 0-63 cpu-map auto:1/even 0-31 cpu-map auto:1/odd 32-63 # 无效的 cpu-map，因为线程集和 CPU 集大小不同。 cpu-map auto:1/1-4 0 # 无效 cpu-map auto:1/1 0-3 # 无效 # 将这 4 个组的 40 个线程映射到单个 CPU cpu-map auto:1/1-10 0-9 cpu-map auto:2/1-10 10-19 cpu-map auto:3/1-10 20-29 cpu-map auto:4/1-10 30-39 # 将 80 个线程映射到一个物理套接字，将另外 80 个映射到另一个套接字， # 不强制分配。这些被分成 4 个组，因为没有一个组可以有超过 64 个线程。 cpu-map 1/1-40 0-39,80-119 # node0，兄弟 0 和 1 cpu-map 2/1-40 0-39,80-119 cpu-map 3/1-40 40-79,120-159 # node1，兄弟 0 和 1 cpu-map 4/1-40 40-79,120-159

选择要使用的 CPU 分配策略。在多 CPU 系统上，有很多原因不使用所有可用的 CPU 内核，和/或将它们分组到不同的线程组中，以实现性能、延迟、成本或系统范围的资源管理。 "cpu-set" 指令已经允许驱逐其中一些，但完成后，需要决定如何将剩余的 CPU 分配给线程和线程组。这种映射通常是使用 "cpu-map" 指令执行的，尽管在异构系统上维护它可能特别困难。 "cpu-policy" 指令在不使用 "cpu-map" 时选择要使用的少数分配策略之一。目前支持以下策略，其中 "performance" 是默认策略： - none 不执行特定的后选择。所有启用的 CPU 都将可用，并且如果未设置线程数，它将设置为可用 CPU 的数量，但每个线程组不超过 32 个（对于 32 位系统）或 64 个（对于 64 位系统）。如果未设置线程组数，它将设置为 1。 - efficiency 与下面的 "group-by-ccx" 完全相同，不同之处在于，性能比下一个性能较低的内核高出 25% 以上的由内核组成的 CPU 集群将被驱逐。这些通常是“大”或“性能”内核。这意味着如果检测到多种类型的 CPU 内核，将只使用高效的内核。这对于适度的负载可能是有意义的，此时最强大的内核需要可用于应用程序或安全组件。一些现代 CPU 拥有大量此类高效 CPU 内核，它们可以集体提供可观的性能水平，同时使用更少的电量。 - first-usable-node 如果 CPU 以前未在启动时受限（例如使用 "taskset" 实用程序），并且如果未设置 "nbthread" 指令，则将使用第一个具有启用 CPU 的 NUMA 节点，并且此数量的 CPU 将用作线程数。将启用一个线程组，其中包含所有这些线程，限制为 32 或 64，具体取决于系统。 - group-by-2-ccx 与下面的 "group-by-ccx" 相同，但每两个 CCX 创建一个组。这对于具有许多 CCX 且每个 CCX 具有少量内核的 CPU 可能有意义，以避免创建许多组，或者在并非所有内核都在使用时稍微平滑分布。请注意，当 CCX 之间的通信缓慢时，这可能会产生非常糟糕的性能影响。通常不建议这样做。 - group-by-2-clusters 与 "group-by-cluster" 相同，但每两个集群创建一个组。这对于具有许多集群且每个集群具有少量内核的 CPU 可能有意义，以避免创建许多组，或者在并非所有内核都在使用时稍微平滑分布。请注意，当集群之间的通信缓慢时，这可能会产生非常糟糕的性能影响。通常不建议这样做。 - group-by-3-ccx 与下面的 "group-by-ccx" 相同，但每三个 CCX 创建一个组。这对于具有许多 CCX 且每个 CCX 具有少量内核的 CPU 可能有意义，以避免创建许多组，或者在并非所有内核都在使用时稍微平滑分布。请注意，当 CCX 之间的通信缓慢时，这可能会产生非常糟糕的性能影响。通常不建议这样做。 - group-by-3-clusters 与 "group-by-cluster" 相同，但每三个集群创建一个组。这对于具有许多集群且每个集群具有少量内核的 CPU 可能有意义，以避免创建许多组，或者在并非所有内核都在使用时稍微平滑分布。请注意，当集群之间的通信缓慢时，这可能会产生非常糟糕的性能影响。通常不建议这样做。 - group-by-4-ccx 与下面的 "group-by-ccx" 相同，但每四个 CCX 创建一个组。这对于具有许多 CCX 且每个 CCX 具有少量内核的 CPU 可能有意义，以避免创建许多组，或者在并非所有内核都在使用时稍微平滑分布。请注意，当 CCX 之间的通信缓慢时，这可能会产生非常糟糕的性能影响。通常不建议这样做。 - group-by-4-clusters 与 "group-by-cluster" 相同，但每四个集群创建一个组。这对于具有许多集群且每个集群具有少量内核的 CPU 可能有意义，以避免创建许多组，或者在并非所有内核都在使用时稍微平滑分布。请注意，当集群之间的通信缓慢时，这可能会产生非常糟糕的性能影响。通常不建议这样做。 - group-by-ccx 如果既没有设置 "nbthread" 也没有设置 "nbtgroups"，则为每个具有可用 CPU 的 CPU 核心复合体 ("CCX") 创建一个线程组，每个组的线程数与 CPU 数相同。CCX 将具有相似快速访问最后一级缓存 ("LLC") 的 CPU 分组在一起，通常是 L3 缓存。在大多数现代机器上，为了性能，将来自不同 CCX 的 CPU 混合在同一个线程组中至关重要。然后，组中的所有线程都绑定到 CCX 的所有 CPU，以便组内通信保持在 CCX 内部，而不会强制执行过强的绑定。尊重每组线程限制和线程组限制。建议在多插槽和 NUMA 系统以及具有不良 CCX 间延迟的 CPU 上使用此功能。 - group-by-cluster 如果既没有设置 "nbthread" 也没有设置 "nbtgroups"，则为每个具有可用 CPU 的 CPU 集群创建一个线程组，每个组的线程数与 CPU 数相同。组中的所有线程都绑定到集群的所有 CPU，以便组内通信保持在集群内部，而不会强制执行过强的绑定。尊重每组线程限制和线程组限制。建议在多插槽和 NUMA 系统以及具有不良 CCX 间延迟的 CPU 上使用此功能。在大多数服务器机器上，集群和 CCX 是相同的，但在异构机器上（“性能”与“效率”或“大”与“小”），集群通常由 CCX 的一部分组成，仅由非常相似的 CPU 组成（相同类型，频率差异最大 +/-5%）。这种差异在开发人员和管理员用于验证设置的现代笔记本电脑和台式机上可见。 - performance 与上面的 "group-by-ccx" 完全相同，不同之处在于，性能低于下一个性能更高的内核 80% 的由内核组成的 CPU 集群将被驱逐。这些通常是“小”或“高效”内核，它们的添加通常不会带来显著的收益，并且很容易适得其反（例如 TLS 握手）。通常，将此类内核保留用于其他任务（例如网络处理）会更有效。在开发系统上，这些内核也可以用于运行辅助工具，例如负载生成器和监控工具。这是默认策略。 - resource 这与上面的 "group-by-cluster" 类似，不同之处在于只使用最小且最有效的 CPU 集群，而所有其他集群将被忽略。这可用于将资源使用限制在仍能提供可观性能的最低限度，例如尝试进一步降低功耗或最小化某些租赁系统上用于 sidecar 设置所需的内核数量，以便更容易地缩减系统规模。请注意，如果只有一个集群存在，它仍将完全使用。

允许以符号方式描述要在其上运行的 CPU 集。该指令支持以下关键字： - reset 撤销任何先前可能由服务管理器或 "taskset" 命令继承的限制。 - drop-cpu <set> 不绑定到此集合中的 CPU - only-cpu <set> 不绑定到不在此集合中的 CPU - drop-node <set> 不绑定到属于此 NUMA 节点的 CPU - only-node <set> 不绑定到不属于此 NUMA 节点的 CPU - drop-cluster <set> 不绑定到此硬件集群编号上的 CPU - only-cluster <set> 不绑定到其他硬件集群编号上的 CPU - drop-core <set> 不绑定到此硬件核心编号上的 CPU - only-core <set> 不绑定到其他硬件核心编号上的 CPU - drop-thread <set> 不绑定到此硬件线程编号上的 CPU - only-thread <set> 不绑定到其他硬件线程编号上的 CPU

当相对路径与 "crtfile" 或 "crt
此关键字在以下部分可用：
加载选项
绑定选项
服务器和默认服务器选项" 指令一起使用时，分配一个默认目录来获取 SSL 证书。指定的绝对位置优先并忽略 "crt-base
此关键字在以下部分可用：
证书存储
进程管理和安全"。

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

默认情况下，HAProxy 从进程启动位置加载由相对路径指定的所有文件。在某些情况下，可能需要强制所有相对路径从不同位置开始，就像进程是从这些位置启动的一样。这就是此指令的目的。从技术上讲，它将在处理每个配置文件时执行对指定位置的临时 chdir()，并在处理每个文件后返回原始目录。 它需要一个参数，指示加载路径不以斜杠 ('/') 开头的文件时使用的策略： - "current" 指示所有相对文件都从进程启动的目录加载；这是默认设置。 - "config" 指示所有相对文件都应从包含配置文件的目录加载。更具体地说，如果配置文件包含斜杠 ('/')，则使用到最后一个斜杠的最长部分作为要更改的目录，否则使用当前目录。此模式便于将 maps、errorfiles、证书和 Lua 脚本捆绑在一起作为可重定位包。当加载多个配置文件时，目录会为每个文件更新。 - "parent" 指示所有相对文件都应从包含配置文件的目录的父目录加载。更具体地说，如果配置文件包含斜杠 ('/')，则将 ".." 附加到到最后一个斜杠的最长部分作为要更改的目录，否则目录为 ".."。此模式便于将 maps、errorfiles、证书和 Lua 脚本捆绑在一起作为可重定位包，但每个部分位于不同的子目录中（例如 "config/"、"certs/"、"maps/" 等）。 - "origin" 指示所有相对文件都应从指定的（必需的）路径加载。这可用于简化在系统上并行运行的不同 HAProxy 实例的管理，其中每个实例使用不同的前缀，但其余部分易于重定位。 每个 "default-path" 指令会立即替换任何前一个指令，并可能导致切换到不同的目录。虽然这应该始终导致所需的行为，但使用多个 default-path 指令确实不是一个好的做法，如果使用，策略应在所有配置文件中保持一致。 警告：某些配置元素（例如 maps 或证书）由其配置的路径唯一标识。通过使用可重定位布局，它们中的几个可能最终具有相同的唯一名称，使其难以在运行时更新，尤其是在从不同目录加载多个配置文件时。在采用相对路径之前，必须遵守严格的无冲突文件命名方案。一种健壮的方法可以包括将所有文件名前缀为其各自的站点名称，或者在目录级别执行此操作。

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

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

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

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

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

By default, DNS resolvers accept both IPv4 and IPv6 addresses. This can be influenced by the "resolve-prefer" keywords on server lines as well as the family argument to the "do-resolve" action, but that is only a preference, which does not block the other family from being used when it's alone. In some environments where dual-stack is not usable, stumbling on an unreachable IPv6-only DNS record can cause significant trouble as it will replace a previous IPv4 one which would possibly have continued to work till next request. The "dns-accept-family" global option permits to enforce usage of only one (or both) address families. The argument is a comma-delimited list of the following words: - "ipv4": query and accept IPv4 addresses ("A" records) - "ipv6": query and accept IPv6 addresses ("AAAA" records) - "auto": use IPv4, and IPv6 if the system has a default gateway for it. The result of the last check is cached for 30 seconds. When a single family is used, no request will be sent to resolvers for the other family, and any response for the other family will be ignored. The default value since 3.3 is "auto", which effectively enables both families only once IPv6 has been proven to be routable, otherwise sticks to IPv4.

此声明必须在使用一些标记为已弃用的指令之前出现，以消除警告并确保配置文件不会被拒绝。并非所有已弃用的指令都受此影响，只有那些没有任何替代解决方案的指令。

此语句必须出现在使用标记为实验性的指令之前，否则配置文件将被拒绝。请注意，此选项涵盖的功能不保证能正常工作，并且在维护周期中可能会中断。开发人员将在开发下一版本期间尽最大努力维护它们，并将尽一切合理的努力避免破坏它们，但不能保证。由于这些原因，这些功能预计在下一个 LTS 版本发布后将不再受支持。希望试用实验性功能的用户应迅速升级以受益于对该功能的改进。为了知道是否仍需要此指令，方法很简单：如果在未使用任何此类功能的情况下启用它，将发出警告，建议将其关闭。因此，如果没有警告，则表示仍然需要它。

允许使用外部代理执行健康检查。默认情况下，为了安全起见，此功能处于禁用状态，即使启用，检查仍可能失败，除非也启用 "insecure-fork-wanted"。如果启动的程序使用了 setuid 可执行文件（它真的不应该这样做），您可能还需要在全局部分设置 "insecure-setuid-wanted"。默认情况下，检查以一个干净的环境开始，该环境仅包含后端部分中 "external-check
This keyword is available in sections :
Process management and security
Alphabetically sorted keywords reference" 命令中定义的变量。但是，有时可能需要保留环境，例如当复杂的脚本从那里检索额外的路径或信息时。这可以通过附加 "preserve-env" 关键字来完成。但在这种情况下，强烈建议不要运行 setuid 或作为特权用户运行，因为这会将检查程序暴露给潜在的攻击。有关详细信息，请参阅 "option external-check" 和 "insecure-fork-wanted" 以及 "insecure-setuid-wanted"。

设置进程将使用的最大文件描述符数的上限，无论系统限制如何。虽然 "ulimit-n" 和 "maxconn
This keyword is available in sections :
Log forwarding
Performance tuning
Alphabetically sorted keywords reference
Bind options
Server and default-server options" 可用于强制执行某个值，但当未设置时，进程将受限于 "ulimit -n -H" 报告的 RLIMIT_NOFILE 设置的硬限制。但一些现代操作系统现在允许在这里设置极大的值（数量级为 10 亿），这对于常规使用会消耗过多的内存。提供 fd-hard-limit 设置是为了强制执行此限制的可能较低的下限。这意味着它将始终遵守低于 <number> 的系统强制限制，但如果系统强制限制更高，则将使用指定的值。默认情况下，fd-hard-limit 设置为 1048576。可以通过编译时变量 DEFAULT_MAXFD 更改此默认值，该变量可作为最大（内核）系统限制，如果 RLIMIT_NOFILE 硬限制非常大。在全局部分设置 fd-hard-limit 允许暂时覆盖构建时通过 DEFAULT_MAXFD 提供的值。在下面的示例中，未指定其他设置，maxconn 值将自动适应 "fd-hard-limit" 和 RLIMIT_NOFILE 限制中的较低者：global # use as many FDs as possible but no more than 50000 fd-hard-limit 50000

将进程的组 ID 更改为 <number>。建议将组 ID 专用于 HAProxy 或一小部分类似的守护程序。HAProxy 必须以属于此组的用户或具有超级用户权限启动。请注意，如果 HAProxy 是从具有补充组的用户启动的，则只有在具有超级用户权限的情况下才能放弃这些组。另请参阅 "group
This keyword is available in sections :
Userlists
Process management and security
Bind options" 和 "uid
This keyword is available in sections :
Process management and security
Bind options"。

定义 SIGUSR1 和实际软停止之间的延迟。

<time> 是在接收到 SIGUSR1 信号后，在继续执行软停止操作之前将等待的额外延迟（默认为毫秒）。

这用于与需要停止 haproxy 进程但某些外部组件需要在解绑监听器之前检测状态的旧环境兼容。其原理是内部的 "stopping" 变量（由 "stopping" 样本获取函数报告）将被设置为 true，但监听器将继续无干扰地接受连接，直到延迟到期，之后将进行常规的软停止。这不能与重新加载的进程一起使用，否则会阻止旧进程解绑，并可能阻止新进程启动，或者只是引起麻烦。

global grace 10s # 在通过 SIGUSR1 设置 stopping 之前，返回 200 OK frontend ext-check bind :9999 monitor-uri /ext-check monitor fail if { stopping }

请注意，一个更灵活、更持久的方法是让编排系统从 CLI 设置一个全局变量，使用该变量来响应外部检查，然后在延迟后发送 SIGUSR1 信号。

# 在 proc.stopping 设置为非零之前返回 200 OK。可以通过 # HTTP 使用 set-var(proc.stopping) 或从 CLI 使用： # > set var proc.stopping int(1) frontend ext-check bind :9999 monitor-uri /ext-check monitor fail if { var(proc.stopping) -m int gt 0 }

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

不拒绝带有负载的 HTTP/1.0 GET/HEAD/DELETE 请求，并返回 413 Payload Too Large HTTP 响应。虽然这在 HTTP/1.1 中是明确允许的，但 HTTP/1.0 在这一点上并不明确，一些旧服务器不期望任何负载，也从不查找正文长度（通过 Content-Length 或 Transfer-Encoding 头）。这意味着一些中间件可能正确处理 HTTP/1.0 GET/HEAD/DELETE 请求的负载，而另一些则可能完全忽略它。这可能导致安全问题，因为可能发生请求走私攻击。因此，默认情况下，HAProxy 拒绝带有负载的 HTTP/1.0 GET/HEAD/DELETE 请求。然而，这对于一些旧客户端可能是一个问题。在这种情况下，可以设置此全局选项。

根据 HTTP/1.1 规范 (RFC9112#6.1) 的要求，同一消息中同时存在 Transfer-Encoding 和 Content-Length 标头字段会带来严重的内容走私攻击风险，如果上游或下游链中的任何地方存在 HTTP/1.0 代理，并且面对这种情况，代理必须在响应后立即关闭连接，以防止任何利用。但这可能会对一些非常旧的客户端产生性能影响，特别是如果它们需要为每个请求重新协商 TLS 连接。此选项允许 HAProxy 不强制执行此规则，而只是清除消息，但在响应后保持连接活动。这只有在绝对确定链中没有 HTTP/1.0 代理并且 HAProxy 之前的所有实现都完全符合 HTTP/1.1 关于这些标头字段规则的情况下才能执行。在任何情况下，HAProxy 将继续忽略并丢弃多余的 Content-Length 标头，以免混淆下一个跳跃点。当启用此选项来解决旧的损坏客户端或服务器时，了解以下事实很重要：无论是否需要此选项，违反此规则的代理都面临着其消息被旧代理截断的风险，这些旧代理会考虑 Content-Length 并忽略 Transfer-Encoding，因为编码块大小的累积大小未被计算在内。因此，上述规则不仅是一个安全问题，也是一个需要解决的问题，以摆脱可能因与旧版本不兼容而面临通信问题的代理。

定义在将标头名称 <from> 发送给 HTTP/1 客户端或服务器之前，将其更改为 <to> 时应用的大小写调整（如果启用）。<from> 必须是小写，<from> 和 <to> 除了大小写之外不得不同。如果需要调整多个标头名称，可以重复此设置。不允许重复条目。如果需要调整大量标头名称，使用 "h1-case-adjust-file" 可能会更方便。请注意，除非在代理中指定了 "option h1-case-adjust-bogus-client" 或 "option h1-case-adjust-bogus-server"，否则不会应用任何转换。标头名称没有标准大小写，因为正如 RFC7230 所述，它们是不区分大小写的。因此，应用程序必须以不区分大小写的方式处理它们。但一些有问题的应用程序违反了标准，错误地依赖于浏览器最常用的大小写。当使用 HTTP/2 时，这个问题变得至关重要，因为所有标头名称都必须以小写形式交换，HAProxy 也遵循相同的约定。无论 HTTP 版本如何，所有标头名称都以小写形式发送给客户端和服务器。无法正确处理请求或响应的应用程序可能需要暂时使用此类变通方法来调整发送给它们的标头名称，直到应用程序修复为止。请注意，需要此类变通方法的应用程序可能容易受到内容走私攻击，必须绝对修复。

global h1-case-adjust content-length Content-Length

请参阅 "h1-case-adjust-file"、"option h1-case-adjust-bogus-client" 和 "option h1-case-adjust-bogus-server"。

定义一个文件，其中包含键/值对列表，用于在将某些标头名称发送给 HTTP/1 客户端或服务器之前调整其大小写。文件 <hdrs-file> 每行必须包含 2 个标头名称。第一个必须是小写，两者除了大小写之外不得不同。以 '#' 开头的行将被忽略，空行也是如此。前导和尾随的制表符和空格将被删除。不允许重复条目。请注意，除非在代理中指定了 "option h1-case-adjust-bogus-client" 或 "option h1-case-adjust-bogus-server"，否则不会应用任何转换。如果重复此指令，则只处理最后一个。如果需要调整大量标头名称，它是指令 "h1-case-adjust" 的替代方案。请阅读与使用此功能相关的风险。请参阅 "h1-case-adjust"、"option h1-case-adjust-bogus-client" 和 "option h1-case-adjust-bogus-server"。

这将禁用向客户端宣布支持 h2 websockets。这可用于克服在实现相对较新的 RFC8441 时遇到问题的客户端，例如 Firefox 88。要允许客户端自动降级到 http/1.1 进行 websocket 隧道，请在绑定行上使用 "alpn
This keyword is available in sections :
Bind options
Server and default-server options" 指定 h2 支持，而无需显式使用 "proto
This keyword is available in sections :
Bind options
Server and default-server options" 关键字。如果此语句先前已激活，则可以通过在关键字前加上 "no" 来禁用。

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

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

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

global hard-stop-after 30s

切换每个协议的保护，禁止与使用特权端口作为其源端口的客户端进行通信。此端口范围根据 RFC 6335 定义。默认情况下，对 QUIC 协议启用保护，因为这种行为是可疑的，并可能被用作欺骗或 DNS/NTP 放大攻击。

替换、减少或扩展定义错误的状态码列表，这些错误被终止码和粘性表中的 "http_err_cnt" 计数器所考虑。错误的默认范围是 400 到 499，但在某些情况下，一些用户更喜欢排除特定的代码，特别是在跟踪客户端错误时（例如，在动态生成内容的系统上出现 404）。另请参阅 "http-fail-codes" 和 "http_err_cnt"。不带 '+' 或 '-' 的范围会将现有范围重新定义为新范围。以 '+' 开头的范围会将现有范围扩展以包含指定的范围，该范围可能与现有范围重叠，也可能不重叠。以 '-' 开头的范围会从现有范围中删除指定的范围。范围由一个 100 到 599 之间的数字组成，可选地后跟一个 "-" 和另一个大于或等于第一个数字的数字，以指示范围的上界。多个范围可以用逗号分隔，用于同一个添加/删除/替换操作。

http-err-codes 400,402-444,446-480,490 # 精确设置这些代码 http-err-codes 400-499 -450 +500 # 设置 400 到 500，除了 450 http-err-codes -450-459 # 从范围中移除 450 到 459 http-err-codes +501,505 # 将 501 和 505 添加到范围中

替换、减少或扩展定义失败的状态码列表，这些失败被终止码和粘性表中的 "http_fail_cnt" 计数器所考虑。失败的默认范围是 500 到 599，除了 501 和 505，它们可以由客户端触发，通常表示服务器处理请求失败。一些用户更喜欢在某些情况下排除某些代码，当已知它们不相关时，例如在某些 SOAP 环境中的 500，因为它在那里不表示服务器故障。语法与上面的 http-err-codes 完全相同。另请参阅 "http-err-codes" 和 "http_fail_cnt"。

默认情况下，HAProxy 会努力阻止在启动后创建任何线程和进程。在使用来源不确定的 Lua 文件以及试验可能仍包含漏洞（其可利用性不确定）的开发版本时，这样做尤为重要。一般来说，确保不会因流量触发任何意外的后台活动是一种良好的卫生习惯。但这会阻止外部检查工作，并可能破坏一些严重依赖 fork 能力的特定 Lua 脚本。此选项用于禁用此保护。请注意，禁用它是一个坏主意，因为一旦禁用，库中或 HAProxy 本身中的漏洞将更容易被利用。此外，从 Lua 或其他地方 fork 不可靠，因为 forked 进程可能会随机嵌入另一个线程设置的锁，并且永远无法完成操作。因此，强烈建议永远不要使用此选项，并且任何需要此类 fork 的工作负载都应重新考虑并转移到更安全的解决方案（例如，使用代理而不是外部检查）。此选项支持 "no" 前缀来禁用它。也可以通过 haproxy 命令行上的 "-dI" 激活它。

HAProxy 在运行时不需要调用可执行文件（除了使用强烈不推荐的外部检查时），甚至预计会隔离到空的 chroot 中。因此，基本上没有充分的理由允许调用 setuid 可执行文件，除非用户完全了解风险。在 HAProxy 需要调用外部检查和/或禁用 chroot 的情况下，利用库中或 HAProxy 本身中的漏洞可能导致执行外部程序。在 Linux 上，可以锁定进程，以便忽略此类可执行文件上存在的任何 setuid 位。这大大降低了在这种情况下权限升级的风险。这是 HAProxy 默认执行的操作。如果这导致外部检查出现问题（例如，需要 "ping" 命令的检查），则可以通过在全局部分明确添加此指令来禁用此保护。如果启用，可以通过在关键字前加上 "no" 来将其关闭。

分配一个目录以加载用于签发者完成的证书链。所有文件必须采用 PEM 格式。对于使用 "crt
This keyword is available in sections :
Load options
Bind options
Server and default-server options" 或 "crt-list" 加载的证书，如果证书链未包含在 PEM 中（也通常称为中间证书），HAProxy 将完成证书链，前提是证书的签发者对应于使用 "issuers-chain-path" 加载的证书链中的第一个证书。包含 PrivateKey+Certificate+IntermediateCA2+IntermediateCA1 的 "crt
This keyword is available in sections :
Load options
Bind options
Server and default-server options" 文件可以用 PrivateKey+Certificate 替换。如果 "issuers-chain-path" 目录中存在包含 IntermediateCA2+IntermediateCA1 的文件，HAProxy 将完成链。具有相同签发者的所有其他证书将共享内存中的链。当未使用 .issuer 或 PEM 中未提供链时，OCSP 功能能够使用已完成的链。

当使用 "key" 指令并使用相对路径时，指定一个用于获取 SSL 私钥的默认目录。指定的绝对路径优先，并忽略 "key-base
此关键字在以下部分可用：
证书存储
进程管理和安全"。此选项仅在使用 crt-store 加载行时有效。

当 haproxy 使用没有 QUIC 支持的 OpenSSL 版本编译时，必须使用此设置来显式启用 QUIC 侦听器绑定。它激活了一个 haproxy 内部兼容层，必须在构建时通过 USE_QUIC_OPENSSL_COMPAT=1 选择该兼容层。该兼容层支持大多数必要的 TLS 操作，尽管没有 QUIC 0-RTT 功能。此功能主要针对 OpenSSL 3.5.2 之前的版本，其中 QUIC API 未实现或仅部分实现。对于 3.5.2 及更高版本，仍然可以激活兼容层，但这可能没有必要。如果设置了 limited-quic，但在构建时未选择兼容层，则该选项将被静默忽略，并且 QUIC TLS 操作依赖于 TLS 库。

设置本地实例的对等名称。如果指定了 "-L" 命令行参数或在 "peers" 部分定义之后使用，它将被忽略。在这种情况下，在配置解析期间将发出警告消息。此选项还将设置 HAPROXY_LOCALPEER 环境变量。另请参阅管理指南中的 "-L" 和下面的 "peers" 部分。

添加一个全局 syslog 服务器。可以定义多个全局服务器。它们将接收启动和退出日志，以及配置有 "log global
This keyword is available in sections :
Log forwarding
Alphabetically sorted keywords reference" 的代理的所有日志。有关代理的更多详细信息，请参阅 "log
This keyword is available in sections :
Peers declaration
Log forwarding
Process management and security
Alphabetically sorted keywords reference" 选项。

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

将 syslog 头中的标签字段设置为此字符串。它默认为从命令行启动的程序名称，通常是 "haproxy"。有时，区分在同一主机上运行的多个进程可能很有用。另请参阅每个代理的 "log-tag
此关键字在以下部分可用：
进程管理和安全
按字母排序的关键字参考
日志配置文件" 指令。

此全局指令在对所有线程可见的共享上下文中加载并执行一个 Lua 文件。在此类上下文中设置的任何变量对任何线程都可见。这是加载 Lua 程序的最简单和推荐的方法，但如果执行大量 Lua 调用，它将无法很好地扩展，因为一次只有一个线程可以在全局状态上运行。以这种方式加载的程序在 "core.thread" 变量中将始终看到 0。此指令可以多次使用。在 Lua 文件的主体中使用以下代码可以使用参数。不要忘记 Lua 数组的索引从 1 开始。在文件中声明的 "local" 变量在整个文件中可用，但在其他文件中不可用。 local args = table.pack(...)

此全局指令将给定的 Lua 文件加载并执行到每个启动的线程中。任何全局变量都具有线程本地可见性，因此每个线程可以看到不同的值。因此，强烈建议不要在以这种方式加载的程序中使用全局变量。对于每个线程，都会加载并初始化一个独立的副本，一切都按线程的数字顺序从 1 到 nbthread 顺序完成。如果某些操作只需要执行一次，程序应该检查 "core.thread" 变量以找出正在初始化的线程。以这种方式加载的程序将在所有线程上并发运行，并且具有高度可扩展性。这是加载注册样本获取器、转换器、操作或服务的简单函数的推荐方法，前提是确定程序不依赖于全局变量。为了简单起见，即使只使用一个线程，甚至禁用线程（在这种情况下，它将等同于 lua-load），此指令也可用。此指令可以多次使用。有关 args 的用法，请参阅 lua-load。

在 Lua 的 package.<type> 变量前加上给定的字符串，后跟一个分号。<type> 必须是 "path" 或 "cpath"。如果未给出 <type>，则默认为 "path"。Lua 的路径是以分号分隔的模式列表，用于指定 `require` 函数如何尝试查找库的源文件。模式中的问号 (?) 将替换为模块名称。路径从左到右评估。这意味着稍后添加的路径将首先被检查。例如，通过指定以下路径：lua-prepend-path /usr/share/haproxy-lua/?/init.lua lua-prepend-path /usr/share/haproxy-lua/?.lua 当调用 `require "example"` 时，Lua 将首先尝试加载 /usr/share/haproxy-lua/example.lua 脚本，如果不存在，则将尝试加载 /usr/share/haproxy-lua/example/init.lua，如果仍不存在，则尝试加载默认路径。有关详细信息，请参阅 Lua 文档中的 https://lua.ac.cn/pil/8.1.html。

主-工作模式。它等同于命令行 "-W" 参数。此关键字已弃用，请使用 "-W" 或 "-Ws" 启动主-工作模式。此模式将启动一个 "master"，它将在读取配置后 fork 一个 "worker" 来处理流量。master 用作进程管理器，将监视 "worker"。使用此模式，您可以通过向 master 发送 SIGUSR2 信号来直接重新加载 HAProxy。重新加载将要求 master 再次读取配置并 fork 一个新的 worker。前一个 worker 将保留直到其作业结束。主-工作模式与前台或守护程序模式兼容。默认情况下，如果 worker 以错误的返回码退出（例如发生段错误），所有 worker 都将被终止，并且 master 将退出。将此行为与 systemd 单元文件中的 Restart=on-failure 结合使用很方便，以便重新启动整个进程。如果您不希望这种行为，则必须使用关键字 "no-exit-on-failure"。另请参阅管理指南中的 "-W"。

在主-工作模式下，默认情况下，如果 worker 以错误的返回码退出（例如发生段错误），所有 worker 都将被终止，并且 master 将退出。将此行为与 systemd 单元文件中的 Restart=on-failure 结合使用很方便，以便重新启动整个进程。此关键字允许在 worker 崩溃时保持其余进程活动，而不是终止所有进程。使用时需要谨慎，因为它仅用于调试，并可能使 master 进程处于异常状态。

在主-工作模式下，此选项限制了 worker 在重新加载后可以存活的次数。如果 worker 在重新加载后没有退出，一旦其重新加载次数大于此数字，worker 将收到 SIGTERM。此选项有助于控制 worker 的数量。另请参阅管理指南中的 "show proc"。默认情况下，此值设置为 50。

此设置仅在内置线程支持时可用。它使 HAProxy 在 <number> 个线程上运行。“nbthread” 在 HAProxy 在前台启动时也有效。在某些支持 CPU 亲和性的平台上，默认的 “nbthread” 值会自动设置为启动时进程绑定的 CPU 数量。这意味着线程数可以轻松地从调用进程中使用 "taskset" 或 "cpuset" 等命令进行调整。否则，此值默认为 1。默认值在 "haproxy -vv" 的输出中报告。请注意，此处设置或自动检测的值受 “thread-hard-limit”（如果设置）设置的限制。

当在支持 NUMA 的平台上运行时，这会启用 "cpu-policy" 指令来检查拓扑结构，并找出要使用的最佳 CPU 集和相应的线程数。但是，如果应用的绑定在特定架构上不是最佳的，则可以使用 'no numa-cpu-mapping' 语句将其禁用。如果配置中存在 'nbthread' 语句，如果进程的亲和性已指定（例如通过 'cpu-map' 指令或 taskset 实用程序），或者如果 cpu-policy 设置为任何其他值，则也不会应用此自动绑定。另请参阅 "cpu-map"、"cpu-policy"、"cpu-set"。

完全禁用 HAProxy 中的 ocsp-update。任何 ocsp-update 配置都将被忽略。默认为 "off"。有关自动更新机制的更多信息，请参阅选项 "ocsp-update"。

允许为 OCSP 更新使用 HTTP 代理。这仅适用于 HTTP，不支持 HTTPS。此选项将允许 OCSP 更新器在请求中向代理发送绝对 URI。

设置同一 OCSP 响应两次自动更新之间的最大间隔。此时间以秒表示，默认为 3600（1 小时）。它必须设置为高于 “ocsp-update.mindelay” 的值。有关自动更新机制的更多信息，请参阅选项 “ocsp-update”。

设置同一 OCSP 响应两次自动更新之间的最小间隔。此时间以秒表示，默认为 300（5 分钟）。它对于没有明确过期时间的 OCSP 响应特别有用。它必须设置为低于 “ocsp-update.maxdelay” 的值。有关自动更新机制的更多信息，请参阅选项 “ocsp-update”。

为配置中使用的所有证书设置默认的 ocsp-update 模式。此全局选项可以被 crt-list 的 “ocsp-update” 选项覆盖。此选项默认设置为 "off"。有关自动更新机制的更多信息，请参阅选项 “ocsp-update”。

在守护进程模式下，将所有守护进程的 PID 写入文件 <pidfile>；在主-工作者模式下，将主进程的 PID 写入文件 <pidfile>。此选项等同于 "-p" 命令行参数。该文件必须对启动进程的用户可访问。另请参阅 "daemon" 和 "master-worker"。

PROXY 协议 v2 实现中的一个错误存在于 HAProxy 2.1 之前的版本中，导致它为健康检查发出 PROXY 命令而不是 LOCAL 命令。这问题特别微小，但会混淆一些服务器的日志。遗憾的是，这个错误发现得很晚，并揭示出一些可能只针对 HAProxy 测试其 PROXY 协议实现的服务器无法正确处理 LOCAL 命令，并在 HAProxy 检查它们时永久保持在 "down" 状态。当这种情况发生时，可以启用此全局选项以恢复到旧的（错误的）行为，直到联系受影响组件的供应商并修复它们。此选项默认禁用，并作用于所有具有 "send-proxy-v2" 语句的服务器。

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

执行一次性打开最大文件描述符的操作，从而预分配内核的数据结构。这可以防止当 nbthread>1 且 HAProxy 打开一个需要内核扩展其数据结构的文件描述符时出现的短暂暂停。

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

指定目录前缀，该前缀将附加在所有不以“/”开头的服务器状态文件名前面。另请参阅 "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"。

此选项最好默认禁用，仅在开发人员要求时才启用。如果已启用，仍可以通过在其前加上 "no" 关键字来强制禁用。它对性能或稳定性没有影响，但会努力重新启用可能因文件大小限制 (ulimit -f)、核心大小限制 (ulimit -c) 或更改其 UID/GID 后进程的 "可转储性"（例如 Linux 上的 /proc/sys/fs/suid_dumpable）而禁用的核心转储。核心转储可能仍然受当前目录权限（检查启动文件的目录）、chroot 目录权限（可能需要暂时禁用 chroot 指令或将其移动到专用的可写位置）或任何其他系统特定约束的限制。例如，一些 Linux 发行版以将默认核心文件替换为系统上甚至未安装的可执行文件路径而闻名（检查 /proc/sys/kernel/core_pattern）。通常，只需写入 "core"、"core.%p" 或 "/var/log/core/core.%p" 即可解决问题。当尝试启用此选项以等待罕见问题重新出现时，通常最好先尝试通过向 "haproxy" 进程发出 "kill -11" 等命令来获取此类转储，并验证它在死亡时是否在预期位置留下核心文件。

将进程范围变量“<var-name>”设置为样本表达式 <expr> 的求值结果。变量“<var-name>”只能是进程范围变量（使用“proc.”前缀）。它的工作方式与 TCP 或 HTTP 规则中的“set-var”操作完全相同，不同之处在于表达式在配置解析时进行求值，并且变量会立即设置。表达式中允许的样本获取函数和转换器仅限于那些使用内部数据的函数，通常是“int(value)”或“str(value)”。也可以引用先前分配的变量。然后，这些变量将可以从常规规则集中读取（和修改）。

global set-var proc.current_state str(primary) set-var proc.prio int(100) set-var proc.threshold int(200),sub(proc.prio)

将进程范围变量“<var-name>”设置为日志格式 <fmt> 求值产生的字符串。变量“<var-name>”只能是进程范围变量（使用“proc.”前缀）。它的工作方式与 TCP 或 HTTP 规则中的“set-var-fmt”操作完全相同，不同之处在于表达式在配置解析时进行求值，并且变量会立即设置。表达式中允许的样本获取函数和转换器仅限于那些使用内部数据的函数，通常是“int(value)”或“str(value)”。也可以引用先前分配的变量。然后，这些变量将可以从常规规则集中读取（和修改）。有关自定义日志格式语法的详细信息，请参见第 8.2.6 节。

global set-var-fmt proc.current_state "primary" set-var-fmt proc.bootid "%pid|%t"

设置在以非 root 用户 (uid > 0) 身份启动和运行时，或以 uid 0 (root) 身份启动然后切换到非 root 用户时必须保留的功能列表。默认情况下，uid 切换会丢失所有权限，但在透明代理期间尝试从外部地址连接到服务器时，或者绑定到低于 1024 的端口时，通常需要保留一些权限，例如当使用 "tune.quic.fe.sock-per-conn default-on" 时，导致设置完全在 uid 0 下运行。设置功能通常是更安全的选择，因为只保留所需的功能。此功能是操作系统特定的，仅在构建时设置 USE_LINUX_CAP=1 时在 Linux 上启用。支持的功能列表也取决于操作系统，并通过传递无效功能名称或空名称时显示错误消息来枚举。可以传递多个功能，用逗号分隔。在常用功能中，"cap_net_raw" 允许透明地绑定到外部地址，"cap_net_bind_service" 允许绑定到特权端口，可用于 QUIC。如果进程以相同的非 root 用户身份启动和运行，则应使用 setcap 以及此关键字在 haproxy 二进制文件上设置所需的功能。有关在 haproxy 二进制文件上设置功能的更多详细信息，请参阅管理指南中的第 13.1 章 Linux 功能支持。

global setcap cap_net_bind_service,cap_net_admin

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

设置此指令后，它将启用使用共享内存来存储统计计数器。<name> 用作 shm_open() 的参数，用于在唯一位置打开共享内存。这也意味着该指令仅适用于支持 shm_open() 的系统。当 SHM 用于统计信息时，前端、后端、侦听器和服务器的所有可共享计数器都将存储在 SHM 中，前提是它们设置了 GUID。重新加载 haproxy 时，新进程将尝试扫描 SHM 以查找可以根据 GUID 和类型与配置中定义的对象关联的对象，目标是能够在重新加载时保留一些计数器的值。另一方面，当 haproxy 正确停止时，SHM 对象会被释放，这意味着计数器会有效地重置。也可以在启动新进程之前手动删除该文件以强制重置。另请参阅 "guid
This keyword is available in sections :
Alphabetically sorted keywords reference
Server and default-server options"、"guid-prefix" 和 "shm-stats-file-max-objects"

此设置定义了用于共享计数器的共享内存能够存储的每个线程组的最大对象数。它与 shm 的最大内存大小直接相关，用于将 shm "预映射"到给定大小，以避免运行时重新映射。它默认为 2k，这应该适用于大多数设置，而不会有不合适的内存使用风险，但如果需要，可以轻松更改。如果此值太低而无法注册预期存储在共享内存中的对象，haproxy 将在启动期间发出警告。它仅在定义了 "shm-stats-file" 时才相关。另请参阅 "thread-groups"

此设置仅在内置 OpenSSL 支持时可用。它设置了默认字符串，描述了在 SSL/TLS 握手期间协商的密码算法列表（"cipher suite"），直到 TLSv1.2，适用于所有未显式定义其密码算法列表的 "bind
This keyword is available in sections :
Peers declaration
Log forwarding
Alphabetically sorted keywords reference" 行。字符串格式在 OpenSSL 手册页中的 "man 1 ciphers" 中定义。有关背景信息和建议，请参阅例如 (https://wiki.mozilla.org/Security/Server_Side_TLS) 和 (https://mozilla.github.io/server-side-tls/ssl-config-generator/)。对于 TLSv1.3 密码配置，请检查 "ssl-default-bind-ciphersuites" 关键字。请检查 "bind
This keyword is available in sections :
Peers declaration
Log forwarding
Alphabetically sorted keywords reference" 关键字以获取更多信息。

此设置仅在内置 OpenSSL 支持且使用 OpenSSL 1.1.1 或更高版本构建 HAProxy 时可用。它设置了默认字符串，描述了在 TLSv1.3 握手期间协商的密码算法列表（"cipher suite"），适用于所有未显式定义其密码算法列表的 "bind
This keyword is available in sections :
Peers declaration
Log forwarding
Alphabetically sorted keywords reference" 行。字符串格式在 OpenSSL 手册页中的 "man 1 ciphers" 中 "ciphersuites
This keyword is available in sections :
Bind options
Server and default-server options" 部分定义。对于 TLSv1.2 及更早版本的密码配置，请检查 "ssl-default-bind-ciphers" 关键字。此设置可能接受 TLSv1.2 密码套件，但这是一种未记录的行为，不推荐，因为它可能不一致或有错误。OpenSSL 的默认 TLSv1.3 密码套件是："TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256" TLSv1.3 仅支持 5 个密码套件： - TLS_AES_128_GCM_SHA256 - TLS_AES_256_GCM_SHA384 - TLS_CHACHA20_POLY1305_SHA256 - TLS_AES_128_CCM_SHA256 - TLS_AES_128_CCM_8_SHA256 请检查 "bind
This keyword is available in sections :
Peers declaration
Log forwarding
Alphabetically sorted keywords reference" 关键字以获取更多信息。

global ssl-default-bind-ciphers ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256 ssl-default-bind-ciphersuites TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256

此设置仅在内置 OpenSSL 支持时可用。它设置了默认字符串，描述了与客户端身份验证相关的签名算法列表，适用于所有未显式定义其签名算法列表的 "bind
This keyword is available in sections :
Peers declaration
Log forwarding
Alphabetically sorted keywords reference" 行。字符串格式是以冒号分隔的签名算法列表。每个签名算法可以使用两种形式之一：TLS1.3 签名方案名称 ("rsa_pss_rsae_sha256") 或公钥算法 + 摘要形式 ("ECDSA+SHA256")。列表可以包含两种形式。有关格式的更多信息，请参阅 SSL_CTX_set1_client_sigalgs(3)。签名算法列表也可在 RFC8446 section 4.2.3 和 OpenSSL 的 ssl/t1_lib.c 文件中找到。此设置不适用于 TLSv1.1 及更早版本的协议，因为这些版本中不会单独协商签名算法。除非需要与中间盒兼容，否则不建议更改此设置。

此设置仅在内置 OpenSSL 支持时可用。它设置了在使用 ECDHE 进行 SSL/TLS 握手期间协商的椭圆曲线算法列表（“曲线套件”）的默认字符串。该字符串的格式是一个以冒号分隔的曲线名称列表。请检查 “bind
此关键字可在以下部分使用：
对等体声明
日志转发
按字母排序的关键字参考” 关键字以获取更多信息。

此设置仅在内置 OpenSSL 支持时可用。它设置了默认的 ssl 选项，以强制应用于所有 "bind
This keyword is available in sections :
Peers declaration
Log forwarding
Alphabetically sorted keywords reference" 行。请检查 "bind
This keyword is available in sections :
Peers declaration
Log forwarding
Alphabetically sorted keywords reference" 关键字以查看可用选项。

global ssl-default-bind-options ssl-min-ver TLSv1.0 no-tls-tickets

此设置仅在内置 OpenSSL 支持时可用。它设置了默认字符串，描述了在 TLSv1.2 和 TLSv1.3 握手期间协商的签名算法列表，适用于所有未显式定义其签名算法列表的 "bind
This keyword is available in sections :
Peers declaration
Log forwarding
Alphabetically sorted keywords reference" 行。字符串格式是以冒号分隔的签名算法列表。每个签名算法可以使用两种形式之一：TLS1.3 签名方案名称 ("rsa_pss_rsae_sha256") 或公钥算法 + 摘要形式 ("ECDSA+SHA256")。列表可以包含两种形式。有关格式的更多信息，请参阅 SSL_CTX_set1_sigalgs(3)。签名算法列表也可在 RFC8446 section 4.2.3 和 OpenSSL 的 ssl/t1_lib.c 文件中找到。此设置不适用于 TLSv1.1 及更早版本的协议，因为这些版本中不会单独协商签名算法。除非需要与中间盒兼容，否则不建议更改此设置。

此设置仅在内置 OpenSSL 支持时可用。它设置了默认字符串，描述了在 SSL/TLS 握手期间与服务器协商的密码算法列表，直到 TLSv1.2，适用于所有未显式定义其密码算法列表的 "server
This keyword is available in sections :
Peers declaration
Rings
Alphabetically sorted keywords reference" 行。字符串格式在 OpenSSL 手册页中的 "man 1 ciphers" 中定义。有关背景信息和建议，请参阅例如 (https://wiki.mozilla.org/Security/Server_Side_TLS) 和 (https://mozilla.github.io/server-side-tls/ssl-config-generator/)。对于 TLSv1.3 密码配置，请检查 "ssl-default-server-ciphersuites" 关键字。请检查 "server
This keyword is available in sections :
Peers declaration
Rings
Alphabetically sorted keywords reference" 关键字以获取更多信息。

此设置仅在内置 OpenSSL 支持且使用 OpenSSL 1.1.1 或更高版本构建 HAProxy 时可用。它设置了默认字符串，描述了在 TLSv1.3 握手期间与服务器协商的密码算法列表，适用于所有未显式定义其密码算法列表的 "server
This keyword is available in sections :
Peers declaration
Rings
Alphabetically sorted keywords reference" 行。字符串格式在 OpenSSL 手册页中的 "man 1 ciphers" 中 "ciphersuites
This keyword is available in sections :
Bind options
Server and default-server options" 部分定义。对于 TLSv1.2 及更早版本的密码配置，请检查 "ssl-default-server-ciphers" 关键字。请检查 "server
This keyword is available in sections :
Peers declaration
Rings
Alphabetically sorted keywords reference" 关键字以获取更多信息。

此设置仅在内置 OpenSSL 支持时可用。它设置了默认字符串，描述了与客户端身份验证相关的签名算法列表，适用于所有未显式定义其签名算法列表的 "server
This keyword is available in sections :
Peers declaration
Rings
Alphabetically sorted keywords reference" 行。字符串格式是以冒号分隔的签名算法列表。每个签名算法可以使用两种形式之一：TLS1.3 签名方案名称 ("rsa_pss_rsae_sha256") 或公钥算法 + 摘要形式 ("ECDSA+SHA256")。列表可以包含两种形式。有关格式的更多信息，请参阅 SSL_CTX_set1_client_sigalgs(3)。签名算法列表也可在 RFC8446 section 4.2.3 和 OpenSSL 的 ssl/t1_lib.c 文件中找到。此设置不适用于 TLSv1.1 及更早版本的协议，因为这些版本中不会单独协商签名算法。除非需要与中间盒兼容，否则不建议更改此设置。

此设置仅在内置 OpenSSL 支持时可用。它设置了在使用 ECDHE 进行 SSL/TLS 握手期间协商的椭圆曲线算法列表（“曲线套件”）的默认字符串。该字符串的格式是一个以冒号分隔的曲线名称列表。请检查 “server
此关键字可在以下部分使用：
对等体声明
环
按字母排序的关键字参考” 关键字以获取更多信息。

此设置仅在内置 OpenSSL 支持时可用。它设置了默认的 ssl 选项，以强制应用于所有 "server
This keyword is available in sections :
Peers declaration
Rings
Alphabetically sorted keywords reference" 行。请检查 "server
This keyword is available in sections :
Peers declaration
Rings
Alphabetically sorted keywords reference" 关键字以查看可用选项。

此设置仅在内置 OpenSSL 支持时可用。它设置了默认字符串，描述了在 TLSv1.2 和 TLSv1.3 握手期间协商的签名算法列表，适用于所有未显式定义其签名算法列表的 "server
This keyword is available in sections :
Peers declaration
Rings
Alphabetically sorted keywords reference" 行。字符串格式是以冒号分隔的签名算法列表。每个签名算法可以使用两种形式之一：TLS1.3 签名方案名称 ("rsa_pss_rsae_sha256") 或公钥算法 + 摘要形式 ("ECDSA+SHA256")。列表可以包含两种形式。有关格式的更多信息，请参阅 SSL_CTX_set1_sigalgs(3)。签名算法列表也可在 RFC8446 section 4.2.3 和 OpenSSL 的 ssl/t1_lib.c 文件中找到。此设置不适用于 TLSv1.1 及更早版本的协议，因为这些版本中不会单独协商签名算法。除非需要与中间盒兼容，否则不建议更改此设置。

此设置仅在内置 OpenSSL 支持时可用。它设置了默认 DH 参数，用于在 SSL/TLS 握手期间使用短暂 Diffie-Hellman (DHE) 密钥交换时，适用于所有未显式定义其参数的 "bind
This keyword is available in sections :
Peers declaration
Log forwarding
Alphabetically sorted keywords reference" 行。如果绑定证书文件中包含自定义 DH 参数，则此设置将被覆盖。如果未使用 ssl-dh-param-file 或未直接在证书文件中设置自定义 DH 参数，则不会使用 DHE 密码，除非设置了 tune.ssl.default-dh-param。在后一种情况下，将使用指定大小的预定义 DH 参数。自定义参数已知更安全，因此建议使用。可以通过使用 OpenSSL 命令 "openssl dhparam <size>" 生成自定义 DH 参数，其中 size 应至少为 2048，因为 1024 位 DH 参数不应再被视为安全。

此设置仅在内置 OpenSSL 支持时可用。它允许定义一个完整的命令行，该命令行将在初始化期间加载加密证书时调用。该命令可以是脚本或任何其他程序。它将提供加密私钥路径作为第一个参数，然后是用户定义的 "args" 参数，并且应该将允许解码加密私钥的密码短语转储到标准输出。对于在初始化期间加载的每个新的加密私钥，HAProxy 将首先尝试所有其他已知的密码短语来解码私钥，如果都不起作用，则最终会再次调用密码短语命令。

此设置仅在内置 OpenSSL 支持且 OpenSSL 版本至少为 3.0 时可用。它允许定义在提供程序中获取算法时使用的默认属性字符串。它的行为方式与 openssl propquery 选项相同，并遵循相同的语法（在 https://www.openssl.org/docs/man3.0/man7/property.html 中描述）。例如，如果您加载了两个提供程序，foo 和默认提供程序，则 propquery “?provider=foo” 允许默认选择由 foo 提供程序提供的算法实现，如果找不到，则回退到默认提供程序的实现。

此设置仅在内置 OpenSSL 支持且 OpenSSL 版本至少为 3.0 时可用。它允许在初始化期间加载提供程序。如果加载成功，HAProxy 可能会使用加载的提供程序提供的任何功能。可以在配置文件中指定多个 'ssl-provider' 选项。提供程序将按照它们的出现顺序加载。请注意，显式加载提供程序会阻止 OpenSSL 自动加载 'default' 提供程序。OpenSSL 还允许直接在其配置文件（例如 openssl.cnf）中定义应加载的提供程序，因此不一定需要使用此 'ssl-provider' 选项来加载提供程序。可以使用 "show ssl providers" CLI 命令来显示所有已成功加载的提供程序。OpenSSL 提供程序的默认搜索路径可以在 "openssl version -a" 命令的输出中找到。如果提供程序位于另一个目录中，您可以设置 OPENSSL_MODULES 环境变量，该变量接受可以找到提供程序的目录。另请参阅 "ssl-propquery" 和 "ssl-provider-path"。

此设置仅在内置 OpenSSL 支持且 OpenSSL 版本至少为 3.0 时可用。它允许指定 OpenSSL 用于查找提供程序的搜索路径。它的行为方式与 OPENSSL_MODULES 环境变量相同。它将用于任何后续的 “ssl-provider” 选项，直到定义新的 “ssl-provider-path”。另请参阅 “ssl-provider”。

此设置允许配置 HAProxy 查找额外 SSL 文件的方式。默认情况下，HAProxy 会在文件名后添加一个新的扩展名。（例如：对于 “foobar.crt”，加载 “foobar.crt.key”）。启用此选项后，HAProxy 会在添加新扩展名之前删除原扩展名（例如：对于 “foobar.crt”，加载 “foobar.key”）。您的 crt 文件必须具有 “.crt” 扩展名才能使此选项生效。此选项与捆绑扩展名（.ecdsa、.rsa、.dsa）不兼容，并且不会尝试删除它们。此选项默认禁用。另请参阅 “ssl-load-extra-files”。

此设置更改了 HAProxy 在加载 SSL 证书期间查找未指定文件的方式。此选项适用于与 "bind
This keyword is available in sections :
Peers declaration
Log forwarding
Alphabetically sorted keywords reference" 行以及 "server
This keyword is available in sections :
Peers declaration
Rings
Alphabetically sorted keywords reference" 行关联的证书，但某些额外文件对 "server
This keyword is available in sections :
Peers declaration
Rings
Alphabetically sorted keywords reference" 行证书没有任何功能影响。默认情况下，HAProxy 会自动发现配置中未指定的许多文件，如果需要优化启动时间，您可能希望禁用此行为。"none"：仅加载配置中指定的文件。如果文件不存在，请勿尝试加载证书包。如果是目录，则不会尝试捆绑具有相同基本名称的证书。"all"：这是默认行为，它将尝试加载所有内容，包括包、sctl、ocsp、issuer、key。"bundle"：当配置中指定的文件不存在时，HAProxy 将尝试加载 "cert bundle"。证书包仅在前端管理，不适用于后端证书。从 HAProxy 2.3 开始，包不再加载到相同的 OpenSSL 证书存储中，而是将每个证书加载到单独的存储中，这等同于声明多个 "crt
This keyword is available in sections :
Load options
Bind options
Server and default-server options"。需要 OpenSSL 1.1.1 才能实现此目的。这意味着包现在仅用于向后兼容，并且不再是执行混合 RSA/ECC 绑定配置所必需的。要将这些 PEM 文件关联到 HAProxy 识别的 "cert bundle" 中，必须按以下方式命名它们：所有要捆绑的 PEM 文件必须具有相同的基本名称，并带有指示密钥类型的后缀。目前支持三个后缀：rsa、dsa 和 ecdsa。例如，如果 www.example.com 有两个 PEM 文件，一个 RSA 文件和一个 ECDSA 文件，则必须命名为："example.pem.rsa" 和 "example.pem.ecdsa"。文件名中的第一部分是任意的；只有后缀才重要。要将此包加载到 HAProxy 中，只需指定基本名称

bind :8443 ssl crt example.pem

请注意，后缀未提供给 HAProxy；这告诉 HAProxy 查找证书包。HAProxy 将加载包中的所有 PEM 文件，就像它们是单独配置在多个 "crt
This keyword is available in sections :
Load options
Bind options
Server and default-server options" 中一样。包加载不再对目录加载产生影响，因为文件是单独加载的。在 CLI 上，包被视为单独的文件，并且需要包扩展名才能提交它们。OCSP 文件 (.ocsp)、签发者文件 (.issuer)、证书透明度 (.sctl) 以及私钥 (.key) 支持多证书捆绑。"sctl"：尝试为每个 crt 关键字加载 "<basename>.sctl"。如果为后端证书提供，它将被加载但不会产生任何功能影响。"ocsp"：尝试为每个 crt 关键字加载 "<basename>.ocsp"。如果为后端证书提供，它将被加载但不会产生任何功能影响。"issuer"：如果 PEM 文件中未提供 OCSP 文件的签发者，请尝试加载 "<basename>.issuer"。如果为后端证书提供，它将被加载但不会产生任何功能影响。"key"：如果 PEM 文件未提供私钥，请尝试加载包含私钥的文件 "<basename>.key"。默认行为是 "all"。

ssl-load-extra-files bundle sctl ssl-load-extra-files sctl ocsp issuer ssl-load-extra-files none

此指令允许选择 OpenSSL 安全级别，如 https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set_security_level.html 中所述。该安全级别将应用于 HAProxy 中的每个 SSL 上下文。仅支持 0 到 5 之间的值。默认值取决于您的 OpenSSL 版本、发行版以及库的编译方式。此指令至少需要 OpenSSL 1.1.1。

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

自签发 CA，即 x509 根 CA，是证书链验证的锚点：作为服务器发送它是无用的，客户端必须拥有它。标准配置需要不在 PEM 文件中包含此类 CA。此选项允许您在 PEM 文件中保留此类 CA 而不将其发送给客户端。用例是为 ocsp 提供颁发者，而无需“.issuer”文件，并能够与“issuers-chain-path”共享它。这涉及所有没有中间证书的证书。对于 BoringSSL 来说是无用的，.issuer 被忽略，因为 ocsp 位不需要它。至少需要 OpenSSL 1.0.2。

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

将 UNIX 套接字绑定到 <path> 或将 TCPv4/v6 地址绑定到 <address:port>。对此套接字的连接将返回各种统计信息输出，甚至允许发出一些命令来更改某些运行时设置。有关更多详细信息，请参阅管理指南的第 9.3 节“Unix 套接字命令”。支持“bind
此关键字可在以下部分使用：
对等体声明
日志转发
按字母排序的关键字参考”行支持的所有参数，例如限制某些用户或其访问权限的访问。有关更多信息，请参阅第 5.1 节。

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

生成的 haproxy stats-file 的路径。启动时，haproxy 会将值预加载到其内部计数器中。使用 CLI 命令 “dump stats-file” 生成此类 stats-file。有关更多详细信息，请参阅管理手册。

激活备用代码以对 haproxy 二进制文件进行压力测试。级别是从 0 到 9 的整数。默认值 0 禁用任何压力执行。级别从 1 到 9 将增加对 haproxy 二进制文件的压力。请注意，使用任何正数级别都可能显著损害性能。因此，除非用于调试目的并在开发人员请求时，否则绝不应激活它。

当 setrlimit 失败时，使进程在启动时失败。HAProxy 会根据计算结果尝试设置最佳的 setrlimit。如果失败，它将发出警告。此选项旨在保证当这些限制失败时 HAProxy 明确失败。它默认启用。仍可通过在其前添加“no”关键字来强制禁用它。

此设置仅在内置线程支持时可用。它枚举了将组成线程组 <group> 的线程列表。线程号和组号从 1 开始。线程范围可以一次使用单个线程号定义，也可以通过指定由破折号“-”分隔的下限和上限来定义（例如 “1-16”）。未分配的线程将自动分配给未分配的线程组，而使用此指令定义的线程组将永远不会接收超过定义的线程数。多次定义同一组会用新的定义覆盖以前的定义。另请参阅 “nbthread” 和 “thread-groups”。

此设置仅在内置线程支持时可用。它使 HAProxy 将其线程分成 <number> 个独立的组。目前，默认值为 1。线程组可以减少线程之间的共享以限制争用，但需要一些额外的配置工作。这也是使用超过 64 个线程的唯一方法，因为每个组最多可以配置 64 个线程。最大组数在编译时配置，默认为 16。另请参阅 “nbthread”。

此设置用于强制限制线程数，无论是检测到的还是配置的。这在线程数是自动检测的操作系统上特别有用，其中在通用和可移植的配置中希望线程数低于 CPU 数。实际上，虽然 “nbthread” 强制的线程数如果高于可用 CPU 数将导致警告和性能不佳，但 thread-hard-limit 只会限制最大值，并自动将线程数限制为不高于此值，但不会提高较低的值。如果 “nbthread” 被强制设置为更高的值，则 thread-hard-limit 生效，并发出警告，以便可以修复配置异常。默认情况下没有限制。另请参阅 “nbthread”。

将进程的用户 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 :
Userlists
Process management and security
Bind options"。

将每个进程的文件描述符最大数量设置为 <number>。默认情况下，它是自动计算的，因此建议不要使用此选项。如果目的只是限制文件描述符的数量，最好改用 “fd-hard-limit”。请注意，在此自动资源计算中未考虑动态服务器。如果使用大量动态服务器，可能需要手动指定此值。

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

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

与 "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 :
Userlists
Process management and security
Bind options"。

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

设置 WURFL User-Agent 缓存大小。为了更快地查找，已处理的用户代理会保存在 LRU 缓存中：- “0”：不使用缓存。- <size>：lru 缓存的大小（以元素为单位）。请注意，此选项仅在 HAProxy 编译时带有 USE_WURFL=1 时可用。

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 请求而来的原始 useragent。 - wurfl_api_version 包含表示当前使用的 Libwurfl API 版本的字符串。 - wurfl_info 包含有关已解析的 wurfl.xml 及其完整路径的字符串。 - wurfl_last_load_time 包含上次成功加载 WURFL 的 UNIX 时间戳。 - wurfl_normalized_useragent 规范化的 useragent。请注意，此选项仅在 HAProxy 使用 USE_WURFL=1 编译时才可用。

一个将用于在包含 WURFL 结果的响应头中分隔值的字符。如果未设置，则默认使用逗号（‘,’）。请注意，此选项仅在 HAProxy 编译时带有 USE_WURFL=1 时可用。

WURFL 补丁文件路径列表。请注意，补丁在启动期间加载，因此在 chroot 之前。请注意，此选项仅在 HAProxy 编译时带有 USE_WURFL=1 时可用。

在某些情况下，尤其是在处理支持可变频率的处理器上的低延迟时，或者在虚拟机中运行时，每次进程使用轮询器等待 I/O 时，处理器都会重新进入睡眠状态或长时间提供给另一个 VM，这会导致延迟过高。此选项提供了一种解决方案，通过始终在轮询器上使用空超时来防止处理器休眠。这会导致延迟显著降低（观察到 30 到 100 微秒），代价是处理器过热的风险。它甚至可以与线程一起使用，在这种情况下，绑定不正确的线程可能会严重冲突，导致性能更差，并且 "show info" 输出中的 CPU stolen 字段值很高，表明哪些线程配置错误。使用此选项时，重要的是不要让进程与网络中断在同一处理器上运行。最好避免在共享同一核心的多个 CPU 线程上使用它。此选项默认禁用。如果已启用，仍可以通过在其前加上 "no" 关键字来强制禁用。它被 "select" 和 "poll" 轮询器忽略。此选项在无缝重新加载的上下文中会自动在旧进程上禁用；它避免了当多个进程停留一段时间等待当前连接结束时过多的 cpu 冲突。

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

设置 HAProxy 在停止新请求的压缩或降低当前请求的压缩级别之前可以达到的最大 CPU 使用率。它的工作方式类似于“maxcomprate”，但测量的是 CPU 使用率而不是传入数据带宽。该值以 HAProxy 使用的 CPU 百分比表示。值 100 表示禁用限制。默认值为 100。设置较低的值将防止压缩工作减慢整个进程的速度并引入高延迟。

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

设置每个进程的最大并发连接数上限为 <number>。它等同于命令行参数 "-n"。通过 "-n" 在命令行参数中提供的值优先于在全局部分设置的 maxconn 值。Haproxy 进程也可以使用 SYSTEM_MAXCONN 编译时变量编译，在这种情况下，它用作系统 maxconn 最大值。同样，如果设置了 SYSTEM_MAXCONN 限制，命令行 "-n" 参数允许在运行时绕过它。当达到 maxconn 时，代理将停止接受连接。进程软文件描述符限制（可以使用 "ulimit -n" 命令获取）会根据提供的 maxconn 自动调整。另请参阅 "ulimit-n"。注意："select" 轮询器在某些平台上无法可靠地使用超过 1024 个文件描述符。如果您的平台仅支持 select 并在启动时报告 "select FAILED"，则需要减少 maxconn 直到它起作用（通常略低于 500）。如果未设置 maxconn 值，它将根据当前文件描述符限制自动计算，由 "ulimit -nH" 命令报告（我们取硬限制和软限制之间的最大值），然后自动值可能会被 "fd-hard-limit" 和内存限制（如果后者是通过 "-m" 命令行选项强制执行的）减少。自动值还取决于缓冲区大小、分配给压缩的内存、SSL 缓存大小以及是否使用 SSL 和相关的 maxsslconn（也可以是自动的）。

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

将每个进程的最大管道数设置为 <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”（以字节为单位）。

在某些尝试回收大量内存的时刻（内存不足或重载时）禁用内存修剪（“malloc_trim”）。修剪内存会强制系统的分配器扫描所有未使用的区域并释放它们。这通常被视为一种好的做法，可以为新进程留出更多可用内存，而旧进程不太可能大量使用它。但某些处理成千上万并发连接的系统可能会经历大量的内存碎片，这可能导致此释放操作极其漫长。在此期间，没有更多的流量通过该进程，不再接受新的连接，一些健康检查甚至可能失败，看门狗（watchdog）甚至可能触发并杀死无响应的进程，留下一个巨大的核心转储文件。如果发生这种情况，建议使用此选项来禁用修剪，停止尝试对新进程友好。请注意，先进的内存分配器通常不会遇到此类问题。

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

在源自 Solaris 10 及更高版本的 SunOS 系统上禁用事件端口（event ports）事件轮询系统的使用。它等同于命令行参数“-dv”。下一个使用的轮询系统通常是“poll”。另请参阅“nopoll”。

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

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

禁用 ktls 的使用。它等同于命令行参数 "-dT"。

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

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

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

启用（'on'）或禁用（'off'）按函数的内存分析。这将保留进程中任何地方（包括库）的 malloc/calloc/realloc/free 调用的使用统计信息，这些信息将通过 CLI 上的“show profiling”命令报告。这主要用于当观察到无法通过池信息解释的异常内存使用，并且需要其他信息时。性能损失通常在 1% 左右，在高度线程化的机器上可能会更高一些，因此通常适合在生产环境中使用。同样的功能也可以在运行时通过 CLI 上的“set profiling memory”命令实现，请查阅管理手册。

启用 ('on') 或禁用 ('off') 每任务 CPU 分析。当设置为 'auto' 时，分析会在线程开始遭受平均延迟 1000 微秒或更高（如 "avg_loop_us" 活动字段中所报告）时自动打开，并在延迟返回到 990 微秒以下时自动关闭（此值是过去 1024 个循环的平均值，因此变化不快，并且倾向于显著平滑短时峰值）。它也可能在过载系统、容器或虚拟机上自发触发，或者在系统交换时（这在负载均衡器上绝对不应该发生）。每任务 CPU 分析对于报告时间花费在哪里以及哪些请求对哪些其他请求产生什么影响非常方便。启用它通常会对整体性能产生不到 1% 的影响，因此建议将其保留为默认的 'auto' 值，以便仅在发现问题时才运行。此功能需要支持 clock_gettime(2) 系统调用以及 clock 标识符 CLOCK_MONOTONIC 和 CLOCK_THREAD_CPUTIME_ID 的系统，否则报告的时间将为零。此选项可以在运行时使用 CLI 上的 "set profiling" 进行更改。

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

将 OpenSSL 引擎设置为 <name>。<name> 的有效值列表可以使用命令 "openssl engine" 获取。此语句可以多次使用，它只会启用多个加密引擎。引用不支持的引擎将阻止 HAProxy 启动。请注意，对于最近的处理器，许多引擎的 HTTPS 性能低于纯软件。可选命令 "algo" 设置 ENGINE 将使用 OPENSSL 函数 ENGINE_set_default_string() 提供的默认算法。值 "ALL" 将引擎用于所有加密操作。如果未指定算法列表，则使用 "ALL" 值。可以指定逗号分隔的不同算法列表，包括：RSA、DSA、DH、EC、RAND、CIPHERS、DIGESTS、PKEY、PKEY_CRYPTO、PKEY_ASN1。这与 openssl 配置文件使用的格式相同：https://www.openssl.org/docs/man1.0.2/apps/config.html HAProxy 版本 2.6 在默认构建中禁用了对引擎的支持。此选项仅在 HAProxy 构建时支持它时才可用。如果需要 ssl-engine，可以重建 HAProxy 时使用 USE_ENGINE=1 标志。

向 SSL 上下文添加 SSL_MODE_ASYNC 模式。如果使用支持异步的 SSL 引擎，这将启用异步 TLS I/O 操作。当前实现最多支持 32 个引擎。Openssl ASYNC API 不支持移动读/写缓冲区，并且与 HAProxy 的缓冲区管理不兼容。因此，在读/写操作上禁用了异步模式（它仅在初始和重新协商握手期间启用）。

启用（'on'）或禁用（'off'）小程序（applet）的数据零拷贝转发。默认启用。

为每个进程可分配的缓冲区数量设置一个硬限制。默认值为零，表示无限制。该限制将自动重新调整以满足紧急情况下的保留缓冲区，这样用户就不必进行复杂的计算。强制设置此值对于限制进程可能占用的内存量，同时保持正常的行为特别有用。当达到此限制时，请求缓冲区的任务会等待另一个缓冲区被释放。只要限制合理，大多数情况下等待时间非常短且不易察觉。然而，一些历史上的限制在不同版本中削弱了这一机制，已知在某些持续短缺的情况下，一些任务可能会冻结直到超时，因此在非严格必要时，最好避免使用此选项。

设置每个线程预分配并保留的缓冲区数量，这些缓冲区仅在内存分配失败导致的内存短缺情况下使用。最小值为 0，默认值为 4。除非核心开发人员出于非常具体的原因建议更改，否则用户没有理由更改此值。

设置缓冲区大小（以字节为单位）。较低的值允许在相同数量的 RAM 中共存更多流，而较高的值允许某些具有非常大 cookie 的应用程序工作。默认值是 16384，可以在构建时更改。强烈建议不要更改此默认值，因为非常低的值会破坏某些服务（例如统计信息），而大于默认值的值会增加内存使用量，可能会导致系统内存不足。至少全局 maxconn 参数应按此参数增加的相同因子减小。此外，HTTP/2 的使用要求此值必须为 16384 或更大。如果 HTTP 请求大于 (tune.bufsize - tune.maxrewrite)，HAProxy 将返回 HTTP 400（Bad Request）错误。同样，如果 HTTP 响应大于此大小，HAProxy 将返回 HTTP 502（Bad Gateway）。请注意，使用此参数设置的值将在 32 位机器上自动向上舍入为 8 的下一个倍数，在 64 位机器上自动向上舍入为 16 的下一个倍数。

设置小缓冲区的字节大小。默认值为 1024。这些缓冲区设计用于一些内存消耗受限但似乎不必分配完整缓冲区的特定上下文中。然而，如果小缓冲区不足，会自动进行重新分配以切换到标准大小的缓冲区。目前，它仅由 HTTP/3 协议用于发出响应头。

设置最大压缩级别。压缩级别影响压缩过程中的 CPU 使用率。此值影响压缩过程中的 CPU 使用率。每个使用压缩的数据流都使用此值初始化压缩算法。默认值为 1。

禁用数据快速转发。它是一种通过将数据直接从一侧传递到另一侧而不唤醒流来优化数据转发的机制。通过此指令，可以禁用此优化。请注意，它还禁用了任何内核 tcp 拼接，以及零拷贝转发。此命令不适用于常规使用，通常只有开发人员在复杂的调试会话中才会建议使用。

全局禁用数据的零拷贝转发。这是一种通过避免使用通道缓冲区来优化数据快速转发的机制。通过此指令，可以禁用此优化。注意，它还禁用了任何内核 TCP 拼接。

在 HAProxy 的历史中，遇到了一些由 Linux 内核中 epoll 机制的错误引起的复杂问题。这些问题通常非常罕见，并且无法在报告者的环境之外重现，并且只能通过禁用 epoll 并切换到 poll 来解决，这对于高性能环境来说并不令人满意。每次，问题都只影响非常特定（且罕见）的事件类型，提供屏蔽它们的能力可以构成一种更可接受的解决方案。此选项提供了这种可能性，允许默默地忽略一些不常见的事件，并用输入（报告未指定的传入事件）替换它们。效果是避免在某些地方使用快速错误处理路径，而只使用常见路径。除非专家邀请您这样做以诊断或解决内核错误，否则不应使用此选项。该选项接受一个参数，该参数是以逗号分隔的单词列表，每个单词指定要屏蔽的事件。目前支持的事件列表是：- "err"：屏蔽 EPOLLERR 事件 - "hup"：屏蔽 EPOLLHUP 事件 - "rdhup"：屏蔽 EPOLLRDHUP 事件

# 屏蔽所有非流量的 epoll 事件： tune.epoll.mask-events err,hup,rdhup

设置异步任务处理程序（来自 event_hdl API）一次可以处理的事件数量。<number> 应在 1 到 10000 之间。较大的数字可能导致线程争用，因为任务在不中断的情况下进行繁重的工作；另一方面，较小的数字可能导致任务不断被重新调度，因为它每次运行无法消耗足够多的事件，也无法跟上事件生成者的速度。默认值可以在构建时强制设置，否则默认为 100。

如果使用 DEBUG_FAIL_ALLOC 编译或使用 "-dMfail" 启动，则给出分配尝试失败的百分比机会。必须在 0（无失败）和 100（无成功）之间。这对于调试并确保内存故障得到妥善处理非常有用。未设置时，比率为 0。但是，命令行 "-dMfail" 选项会自动将其设置为 1% 的失败率，因此无需更改配置进行测试。

为支持它的文件描述符（FD）启用（'on'）或禁用（'off'）边缘触发轮询模式。目前仅在 epoll 下支持。在某些情况下，它可能会显著减少 epoll_ctl() 调用的数量并略微提高性能。这仍然是实验性的，如果仍然存在错误，可能会导致连接冻结，并且默认禁用。

设置 CPU 最小使用率（介于 0 和 100 之间），当连接显示过多故障时，将终止这些连接。这适用于已达到其故障阈值限制的连接。在非常长的连接经常表现不佳但不会造成任何性能影响的环境中，只要它们没有造成损害，就可能希望保留它们，并且只在 CPU 变得繁忙时才开始终止此类连接。此参数允许指定当 CPU 使用率达到或超过此级别时，将主动终止达到其故障阈值的连接，但在低于此级别时永远不会终止。请注意，CPU 使用率是按线程测量的，因此单个行为不当的连接可能会被终止。默认值为零，这意味着达到其故障阈值的连接将自动被终止。经验法则是将此值设置为通常观察到的 CPU 使用率的两倍，或者通常观察到的 CPU 使用率加上一半的空闲时间（例如，如果 CPU 通常达到 60%，则在此处设置 80 可能有意义）。如果没有 tune.h2.fe.glitches-threshold 或 tune.quic.fe.sec.glitches-threshold，此参数无效。另请参阅全局参数 "tune.h2.fe.glitches-threshold" 和 "tune.quic.fe.sec.glitches-threshold"。

启用（'on'）或禁用（'off'）H1 多路复用器的数据零拷贝接收。默认启用。

启用（'on'）或禁用（'off'）H1 多路复用器的数据零拷贝发送。默认启用。

设置后端连接上故障（glitches）数量的阈值，超过该阈值连接将自动被终止。这允许自动终止行为不佳的连接，而无需为其编写明确的规则。默认值为零，表示未设置阈值，因此任何事件都不会导致连接关闭。请注意，一些 H2 服务器可能会在长时间连接上偶尔引起一些故障，因此这里的任何非零值可能应该在数百或数千的量级，以便在不影响轻微有问题的服务器的情况下有效。也可以通过使用“tune.glitches.kill.cpu-usage”来仅在 CPU 使用率超过某个水平时终止连接。

设置传出连接的 HTTP/2 初始窗口大小，即服务器在等待 HAProxy 确认之前可以响应的字节数。此设置仅影响有效负载内容，不影响头部。如果未设置，则应用由 tune.h2.initial-window-size 设置的通用默认值。稍微增加此值可以加快下载速度或减少服务器上的 CPU 使用率，但代价是在客户端之间造成不公平。最好使用 tune.h2.be.rxbuf，它不会引起任何不公平。它不影响资源使用。

设置每个传出连接的 HTTP/2 最大并发流数（即单个到服务器连接上的未完成请求数）。如果未设置，则应用由 tune.h2.max-concurrent-streams 设置的默认值。小于默认值 100 的值可能会提高站点的响应能力，但代价是需要维护更多到服务器的已建立连接。当“http-reuse”设置为“always”时，建议减小此值，以免在同一连接上混合过多不同的客户端，因为如果一个客户端比其他客户端慢，一种称为“队头阻塞”的机制往往会对共享连接的所有客户端的下载速度产生级联效应（在这种情况下，保持 tune.h2.be.initial-window-size 较低）。强烈建议不要增加此值；有些人可能会发现在较低的值（通常为 1..5）下运行是最佳的。

设置传出连接的 HTTP/2 接收缓冲区大小（以字节为单位）。此大小将向上取整到 tune.bufsize 的下一个倍数，并将在所有上传数据（HEADERS 和 DATA 帧）的流之间共享。在任何情况下，每个流都将始终被授予一个缓冲区，并且 7/8 的未使用缓冲区将在下载有效负载的流之间共享，从而在 http-reuse 设置为 "always" 时，显著提高上传性能并避免在多个客户端之间共享的后端连接上出现队头阻塞（HoL）。通告的每个流的窗口会自动调整以反映可用空间，因此实际上应该不需要调整 tune.h2.be.initial-window-size。如果设置的大小小于处理所有流所需的大小，则将使用此最小值。默认值约为 1600k（100 个流，每个流有 16kB 的缓冲区）。

设置前端连接上故障（glitches）数量的阈值，超过该阈值连接将自动被终止。这允许自动终止行为不佳的连接，而无需为其编写明确的规则。默认值为零，表示未设置阈值，因此任何事件都不会导致连接关闭。请注意，一些 H2 客户端可能会在长时间连接上偶尔引起一些故障，因此这里的任何非零值可能应该在数百或数千的量级，以便在不影响轻微有问题的客户端的情况下有效。也可以通过使用“tune.glitches.kill.cpu-usage”来仅在 CPU 使用率超过某个水平时终止连接。

设置传入连接的 HTTP/2 初始窗口大小，即客户端在等待 HAProxy 确认之前可以上传的字节数。此设置仅影响有效负载内容（即 POST 请求的主体），不影响头部。如果未设置，则应用由 tune.h2.initial-window-size 设置的通用默认值。增加此值可以加快上传速度。默认值等于 tune.bufsize (16384)，允许每个流在 100 毫秒 ping 时间下至少有 1.25 Mbps 的带宽，在 1 毫秒 ping 时间下有 125 Mbps 的带宽。它不影响资源使用。使用过大的值可能会导致客户端在并行访问页面与大文件上传时体验到响应性不足。最好使用 tune.h2.fe.rxbuf，它不会引起任何不公平。

设置每个传入连接的 HTTP/2 最大并发流数（即单个客户端连接上的未完成请求数）。如果未设置，则应用由 tune.h2.max-concurrent-streams 设置的默认值。对于具有大量小对象的复杂站点，在高延迟网络上，大于默认值 100 的值有时可能会略微改善页面加载时间，但也可能因允许客户端一次性分配更多资源而导致使用更多内存。默认值 100 通常很好，建议不要更改此值。

设置每个传入连接处理的 HTTP/2 总流的最大数量。一旦达到此限制，HAProxy 将发送一个优雅的 GOAWAY 帧，通知客户端它将在所有挂起的流关闭后关闭连接。实际上，客户端在收到此消息时倾向于尽快关闭，并为下一个请求建立新连接。在客户端连接时间很长并在场内造成一些不平衡的情况下，这样做有时很有用且合乎需要。例如，在某些高度动态的环境中，可能会在负载增加时即时实例化新的负载均衡器，并且一旦负载下降，应停止它们而不断开已建立的连接。通过在此处设置限制，连接将具有有限的生命周期，并且会经常更新，其中一些可能会建立到其他节点，从而快速释放现有资源。重要的是要理解此限制与上面的 "tune.h2.fe.max-concurrent-streams" 之间存在隐式关系。实际上，HAProxy 将始终接受处理客户端和前端之间可能在传输中的任何可能挂起的流，因此所宣传的限制将始终自动提高由 max-concurrent-streams 中配置的值，并且此值将作为硬限制，非兼容客户端违反此限制将导致连接关闭。因此，当从日志中计算每个连接的请求数时，可能会观察到介于 max-total-streams 和 (max-total-streams + max-concurrent-streams) 之间的任何数字，具体取决于客户端创建流的速度。默认值为零，它不施加超出协议隐含限制（2^30 ~= 1.07 十亿）的任何限制。值在 1000 左右可能已经会导致频繁的连接更新，而不会对大多数客户端造成任何明显延迟。设置得太低可能会导致由于频繁的 TLS 重新连接而增加 CPU 使用率，此外还会增加页面加载时间。请注意，某些负载测试工具不支持重新连接，并且可能会报告此设置的错误；因此，在运行性能基准测试时可能需要禁用它。另请参阅 "tune.h2.fe.max-concurrent-streams"。

设置传入连接的 HTTP/2 接收缓冲区大小（以字节为单位）。此大小将向上取整到 tune.bufsize 的下一个倍数，并将在所有上传数据（HEADERS 和 DATA 帧）的流之间共享。在任何情况下，每个流都将始终被授予一个缓冲区，并且 7/8 的未使用缓冲区将在上传有效负载的流之间共享，从而显著提高上传性能。通告的每个流的窗口会自动调整以反映可用空间，因此实际上应该不需要调整 tune.h2.fe.initial-window-size。如果设置的大小小于处理所有流所需的大小，则将使用此最小值。默认值 1600k（100 个流，每个流有 16kB 的缓冲区）允许具有 100ms RTT 的客户端大约有 130 Mbps 的上传速度。

设置 HTTP/2 动态头表大小。默认为 4096 字节，不能大于 65536 字节。较大的值可能有助于某些客户端发送更紧凑的请求，具体取决于它们的能力。每个 HTTP/2 连接都会消耗此数量的内存。建议不要更改它。

设置 HTTP/2 初始窗口大小的默认值，适用于传入和传出连接。当未设置 tune.h2.fe.initial-window-size 时，此值用于传入连接；当未设置 tune.h2.be.initial-window-size 时，此值用于传出连接。此设置既用作初始值，也用作每流的最小值。默认值等于 16384 (tune.bufsize)，对于上传而言，在显示 100 毫秒 ping 时间的网络上，每流大致允许至少 1.25 Mbps 的带宽，或者在 1 毫秒本地网络上允许 125 Mbps 的带宽。当使用的接收缓冲区少于最大值时，在 tune.h2.be.rxbuf 和 tune.h2.fe.rxbuf 定义的限制内，未使用的缓冲区将在接收流之间共享。因此，通常没有必要更改此默认设置。鉴于更改此默认值会同时提高上传速度并导致客户端在下载方面更加不公平，建议改用特定于端点的设置 tune.h2.fe.initial-window-size 和 tune.h2.be.initial-window-size。

设置每个连接的默认 HTTP/2 最大并发流数（即单个连接上的未完成请求数）。当未设置 tune.h2.fe.max-concurrent-streams 时，此值用于传入连接；当未设置 tune.h2.be.max-concurrent-streams 时，此值用于传出连接。默认值为 100。影响因方向而异，因此请参阅上述两个设置以获取更多详细信息。建议不要使用此设置，而是切换到按方向的设置。值为零将禁用限制，因此单个客户端可以创建 HAProxy 可分配的任意数量的流。强烈建议不要更改此值。

设置 HAProxy 向其对等方宣告愿意接收的 HTTP/2 最大帧大小。默认值是 16384 和缓冲区大小 (tune.bufsize) 之间的较大者。在任何情况下，HAProxy 都不会宣告支持大于缓冲区的帧大小。此设置的主要目的是允许在使用大缓冲区时限制最大帧大小设置。过大的帧大小可能会影响性能或导致某些对等方行为不当。强烈建议不要更改此值。

启用（'on'）或禁用（'off'）H2 多路复用器的数据零拷贝发送。默认启用。

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

设置日志中请求 URI 的最大长度。这可以防止在日志行中截断带有有价值查询字符串的长请求 URI。这与 syslog 的限制无关。如果增加此限制，您可能还需要增加 'log ... len yyy' 参数。您的 syslog 守护进程可能也需要特定的配置指令。默认值为 1024。

设置接收到的 HTTP 消息中允许的最大标头数。当消息中的标头数大于此值（包括第一行）时，它将被拒绝，对于请求，状态码为 "400 Bad Request"，对于响应，状态码为 "502 Bad Gateway"。默认值是 101，这对于所有用法都足够了，考虑到广泛部署的 Apache 服务器使用相同的限制。将此限制推得更远可能很有用，以便在应用程序得到修复之前暂时允许有错误的应用程序工作。接受范围是 1..32767。请记住，每个新标头会为每个流消耗 32 位内存，因此不要将此限制推得太高。请注意，HTTP/1.1 是一个文本协议，因此在发送消息时没有特殊限制。消息解析期间的限制就足够了。HTTP/2 和 HTTP/3 是二进制协议，需要编码步骤。当编码标头以符合协议施加的限制时，也会设置限制。此限制足够大，但出于目的未记录。出于相同的原因，在解码的第一步中应用了相同的限制。

启用（'on'）或禁用（'off'）同一服务器的空闲连接池在线程间的共享。默认是共享它们，以最小化到服务器的持久连接数，并优化连接重用率。但为了帮助调试或当怀疑 HAProxy 在连接重用方面存在错误时，强制禁用多线程间的空闲池共享，并将此选项设置为 "off" 可能很方便。默认是 on。强烈建议在禁用此选项时，不要为所有依赖连接重用以实现高性能的服务器设置一个保守的“pool-low-conn”值，否则随着线程数的增加，连接可能会被频繁关闭。

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

通常，所有 "bind
This keyword is available in sections :
Peers declaration
Log forwarding
Alphabetically sorted keywords reference" 行将创建一个单独的分片，即所有进程线程都将侦听的单个套接字。对于许多线程，这不是很高效，甚至可能在内核中引起一些重要的开销来更新轮询状态甚至向各个线程分发事件。现代操作系统支持传入连接的平衡，这种机制将包括允许多个套接字绑定到同一地址和端口，并均匀地将所有传入连接分发到这些套接字，以便每个线程只看到在其绑定的套接字中等待的连接。这显著减少了内核端的开销，并提高了传入连接路径的性能。这通常在 HAProxy 中使用 "shards
This keyword is available in sections :
Peers declaration
Bind options" 设置在 "bind
This keyword is available in sections :
Peers declaration
Log forwarding
Alphabetically sorted keywords reference" 行上启用，默认值为 1，这意味着每个侦听器在进程中都是唯一的。在具有许多处理器的系统上，将默认设置更改为 "by-thread" 以始终为每个线程创建一个侦听套接字，或更改为 "by-group" 以始终为每个线程组创建一个侦听套接字可能更方便。请注意 "by-thread" 的文件描述符使用情况，因为每个侦听器将需要与线程数一样多的套接字。此外，某些操作系统（例如 FreeBSD）在同一地址上最多限制为 256 个套接字。请注意，对于涉及单个线程组的默认配置，"by-group" 将保持与 "by-process" 等效，并且在不支持此机制的系统上将回退到共享同一套接字。默认值是 "by-group"，对于不支持多个绑定的系统或套接字族，将回退到 "by-process"。

启用（'on' / 'fair'）或禁用（'off'）侦听器的多队列接受，它将传入流量分发给 "bind
This keyword is available in sections :
Peers declaration
Log forwarding
Alphabetically sorted keywords reference" 行允许运行的所有线程，而不是自己接管它们。这提供了更平滑的流量分发并更好地扩展，特别是在由于外部活动（例如网络中断与一个线程冲突）而导致线程负载不均衡的环境中。默认模式 "on" 通过在样本中选择连接最少的线程来优化线程选择。当连接寿命较长时，它通常是最佳选择，因为它可以使所有线程保持忙碌。第二种模式 "fair" 不考虑其即时负载级别，而是循环遍历所有线程。它可能更适合短寿命连接，或者在具有大量线程的机器上，其中使用第一种模式找到负载最轻线程的概率很低。最后，可以使用 "off" 强制禁用重新分发机制以进行故障排除，或者在连接寿命较短且估计操作系统已经提供了足够好的分发的情况下。默认值是 "on"。

明确告诉 haproxy 在将 haproxy 样本对象推送到 Lua 时应如何处理。确实，在利用 Lua 脚本中的本机转换器、样本获取或变量时（仅举几例），haproxy 会将内部 smp 类型转换为等效的 Lua 类型。由于历史实现的原因，布尔值处理存在歧义：当进行 Lua -> haproxy smp 转换时，布尔值会正确保留，但当进行 haproxy smp -> Lua 转换时，布尔值会错误地转换为整数。这意味着返回布尔值的样本获取或转换器在从 Lua 调用时会返回整数 0 或 1。不幸的是，在 Lua 中，布尔值和整数是不可互换的。因此，为避免歧义，必须明确将 "tune.lua.bool-sample-conversion" 设置为 "normal"（这意味着放弃历史行为以获得更好的一致性）或 "pre-3.1-bug"（强制执行历史行为以防止现有脚本逻辑行为不当）。如果未明确设置此选项，并且从配置中加载了 Lua 脚本，haproxy 将发出警告，并且该选项将隐式默认为 "pre-3.1-bug" 以匹配历史行为。建议在确保正在使用的 Lua 脚本正确将 bool haproxy 样本作为布尔值处理后，将此选项设置为 "normal"。此设置必须在任何 "lua-load" 或 "lua-load-per-thread" 指令之前设置才能被考虑，否则将被忽略。

"burst" 执行超时适用于任何 Lua 处理器。如果处理器未能在超时之前完成或让出，它将被中止，以防止线程争用、防止流量长时间得不到服务，并最终防止进程因看门狗介入而崩溃。与其他是让出累积的 Lua 超时不同，burst-timeout 将确保单个 Lua 执行窗口中花费的时间不超过配置的超时。此处让出意味着 Lua 执行被有效中断，要么是通过对 Lua 让出函数的显式调用（例如 core.(m)sleep() 或 core.yield()），要么是跟随自动强制让出（参见 tune.lua.forced-yield），并且将在相关任务设置为重新调度时稍后恢复。并非所有 Lua 处理器都可以让出：我们必须区分可让出处理器和不可让出处理器。对于可让出处理器（任务、操作等），达到超时意味着 "tune.lua.forced-yield" 对于系统来说可能太高了，降低它可能会改善情况，但检查在 Lua 函数中的某些关键点添加手动让出是否有帮助也是一个好主意。它也可能表明处理器在无法中断的特定 Lua 库函数中花费了太多时间。对于不可让出处理器（Lua 转换器、样本获取），它可能仅仅表明处理器正在进行过多的计算，这可能是由于设计不当造成的，因为此类处理器（通常会阻塞请求执行流）预计会快速终止以允许请求处理通过。这里常见的解决方案是尝试更好地优化 Lua 函数以提高速度，因为减少 "tune.lua.forced-yield" 无济于事。此超时仅计算纯 Lua 运行时。如果 Lua 执行 core.sleep，则不计算睡眠时间。默认超时为 1000 毫秒。注意：如果从处理器发起 Lua GC 周期（无论是显式请求还是 Lua 在一段时间后自动触发），GC 周期时间也将被计算在内。确实，无法推断 GC 周期时间，因此这可能会在饱和系统上导致一些误报（GC 难以赶上并消耗大部分可用执行运行时）。如果发生这种情况，这里有一些解决方案线索：- 检查脚本是否可以优化以减少 Lua 内存占用 - 微调 Lua GC 参数和/或请求手动 GC 周期（参见：https://lua.ac.cn/manual/5.4/manual.html#pdf-collectgarbage）- 增加 tune.lua.burst-timeout 将值设置为 0 会完全禁用此保护。

此指令强制 Lua 引擎每执行 <number> 条指令就执行一次让出（yield）。这允许中断一个长脚本，并让 HAProxy 调度器处理其他任务，如接受连接或转发流量。对于使用“lua-load-per-thread”加载的脚本，默认值为 10000 条指令；对于使用“lua-load”加载的脚本，默认值为 MAX(500, 10000 / nbthread) 条指令（这被认为是性能的最佳值，同时注意不要因多个线程竞争全局 Lua 锁而造成线程争用）。如果 HAProxy 经常执行一些 Lua 代码但需要更高的响应性，可以降低此值。如果 Lua 代码相当长且其结果对于处理数据是绝对必需的，可以增加 <number>，但应明智地设置该值，因为在多线程环境中它可能会增加争用。

启用（'on'）或禁用（'off'）通过适用于当前代理的日志记录器（如果有）记录 LUA 脚本的输出。默认为 'on'。

启用（'on'）或禁用（'off'）通过 stderr 记录 LUA 脚本的输出。当设置为 'auto' 时，如果满足以下任一条件，则通过 stderr 进行日志记录为 'on'： - tune.lua.log.loggers 设置为 'off' - 脚本在没有全局日志记录器的非代理上下文中执行 - 脚本在没有附加日志记录器的代理上下文中执行。请注意，启用时，此日志记录是 tune.lua.log.loggers 配置的日志记录之外的补充。默认为 'auto'。

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

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

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

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

设置每个线程的活动检查数，超过此数，线程将主动尝试寻找负载较轻的线程来运行健康检查，或者将其排队，直到其上运行的活动检查数量减少。默认值为零，表示没有设置此类限制。在某些运行大量昂贵检查且线程数众多的环境中，当负载出现不均并可能导致健康检查在启动时随机超时时，可能需要此设置，尤其是在使用 OpenSSL 3.0 时，其在健康检查上的 CPU 密集度比旧版本高约 20 倍。这将导致尝试在所有线程之间平均分配健康检查工作。绝大多数配置不需要调整此参数。请注意，如果检查执行缓慢，过低的值可能会显著减慢健康检查的速度。

设置一个进程在切换到其他工作之前可以连续接受的最大连接数。在单进程模式下，较高的数字曾经在高连接率下提供更好的性能，但现在有了多队列后，情况已非如此。此值单独应用于每个监听器，因此会考虑监听器绑定的进程数。此值默认为 4，表现出最佳结果。如果从旧配置中继承了一个明显更高的值，可能值得将其移除，因为这既能提高性能又能降低响应时间。在多进程模式下，它会被监听器绑定的进程数的两倍所除。将此值设置为 -1 会完全禁用该限制。通常不需要调整此值。

设置在一次调用轮询系统时可以处理的最大事件量。默认值根据操作系统进行调整。已经注意到，将其减少到 200 以下会以网络带宽为代价略微降低延迟，而将其增加到 200 以上则会以延迟为代价略微增加带宽。配置的值必须小于或等于 1000000。

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

设置在支持让出的规则集评估函数中可以一次评估的最大规则数。确实，看到具有大量 "tcp-request content" 或 "http-request" 规则的配置并不罕见。大量的规则与耗费 CPU 的操作（例如：处理内容的动作）相结合可能会产生线程争用，因为如果评估没有中断，给定规则集中的所有规则都会在同一个轮询循环中进行评估。此选项确保对于面向内容的规则集（由于内容检查而已经支持让出），在同一轮询循环中执行的规则数不超过 。它的作用是强制评估函数让出，以便它在下一个轮询循环中返回以继续评估。受影响的规则集是：- "tcp-request content" - "tcp-response content" - "http-request" - "http-response" 默认值为 50。

设置将保留在本地缓存中并永远不会被其他线程恢复的每线程内存量。对该内存的访问非常快（无锁），并且拥有足够的内存对于在极端线程争用下保持良好的性能水平至关重要。该值以字节表示，默认值在构建时通过 CONFIG_HAP_POOL_CACHE_SIZE 配置，默认值为 524288 (512 kB)。在某些使用场景中，较大的值可能会提高性能，尤其是当性能配置文件显示内存分配压力很大时。经验表明，一个好的值是每 CPU 核心 L2 缓存大小的一到两倍。过大的值会对性能产生负面影响，因为会对 CPU 中的 L3 缓存造成低效使用，并且会消耗更大的内存量。建议不要更改此值，或者以小幅度增量进行更改。为了完全禁用每线程 CPU 缓存，使用一个非常小的值可能会起作用，但最好在命令行上使用 "-dMno-cache"。

调整内核的每个套接字缓冲，以便在缓冲的数据量等于此值加上测量的窗口大小时，报告套接字的发送端已满。其原理是在套接字缓冲区中保留严格需要的最小字节量，再加上一个小余量，对应于 haproxy 再次尝试发送时将要发送的内容。将其设置为一个较低的值（通常在 tune.bufsize 左右）可以显著减少系统缓冲区中的内存消耗，并减少因刷新缓冲数据而引起的应用程序级延迟。对于支持它的系统，这通常比 tune.sndbuf.client 和 tune.sndbuf.server 是更有效、更准确的设置。这适用于每个连接（取决于设置，是来自客户端的连接还是到服务器的连接），并且仅用于 TCP 连接。默认值为零，表示无限制。这仅在 Linux 上可用。

设置模式查找缓存的大小为  个条目。这是一个 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 来禁用缓存。

设置 haproxy 在发送消息时一次将尝试处理的粘性表更新的最大数量。检索这些更新的数据需要一些锁定操作，这在高度线程化的机器上如果无限制可能会消耗大量 CPU，并且在旧进程和新进程之间的初始批量传输期间也可能增加流量延迟。相反，低值也可能导致更高的 CPU 开销，并需要更长的时间来完成。默认值为 200，建议不要更改它。

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

此设置设置 HAProxy 全局使用的文件描述符最大数量（百分比），相对于 HAProxy 在我们无法重用连接并且必须创建新连接时开始终止空闲连接之前可以使用的最大文件描述符数量。默认值为 25（四分之一的文件描述符将意味着大约一半的最大前端连接可以保留一个空闲的后端连接，任何超出此范围的在针对连接重用的通用情况下可能没有多大意义）。

此设置设置 HAProxy 全局使用的文件描述符最大数量（百分比），相对于 HAProxy 在我们停止将连接放入空闲池以供重用之前可以使用的最大文件描述符数量。默认值为 20。

启用（'on'）或禁用（'off'）直通（pass-through）多路复用器的数据零拷贝转发。要使用此功能，还必须配置内核拼接。默认启用。

定义 Cubic 拥塞控制算法真正考虑丢失事件所需的丢失数据包数。通常，任何丢失事件都被认为是拥塞的结果，足以让 Cubic 从较小的窗口重新开始。但实验表明，丢失的原因多种多样，根本不是由拥塞引起的，可以简单地称为虚假丢失，对于这些丢失，调整窗口没有效果，只会减慢通信速度。无线电信号差、乱序交付、客户端 CPU 使用率高导致随机延迟以及系统计时器不精确都可能是常见原因。此设置允许 Cubic 对虚假丢失更加容忍，通过更改两次 ACK 之间累积丢失的最小数量以被视为丢失事件，默认值为 1。实验中观察到了一些显著的增益，但总是伴随着重传浪费的带宽增加以及拥塞链路饱和的风险增加。值 2 可用于短时间比较某些指标。未经专家事先分析情况，切勿超过 2。默认值和最小值是 1。始终使用 1。

此关键字在 3.3 中已弃用，并将在 3.5 中删除。它是 QUIC 配置应用精简流程的一部分。如果使用，此设置将仅应用于前端连接。

启用（'on'）或禁用（'off'）用于 QUIC 连接的 HyStart++ (RFC 9406) 算法，作为拥塞控制算法慢启动阶段的替代方案，该阶段可能导致高丢包率。默认禁用。

此关键字在 3.3 中已弃用，并将在 3.5 中删除。它是 QUIC 配置应用精简流程的一部分。如果使用，此设置将仅应用于前端连接。

设置单个 QUIC 帧可以被标记为丢失的限制。如果超过此限制，连接将被视为失败并立即关闭。默认值为 10。

此关键字在 3.3 中已弃用，并将在 3.5 中删除。它是 QUIC 配置应用精简流程的一部分。如果使用，此设置将仅应用于前端连接。

设置单个 QUIC 连接的拥塞控制器在前端或后端侧的默认最大窗口大小。该值必须写为整数，带有可选后缀 'k'、'm' 或 'g'。它必须介于 10k 和 4g 之间。QUIC 多路复用器还使用当前的拥塞窗口大小来确定是否可以在数据发射时分配新的流缓冲区。因此，最大拥塞窗口大小也用作此分配器的限制。默认值为 480k。另请参阅 "quic-cc-algo" 绑定选项。

此关键字在 3.3 中已弃用，并将在 3.5 中删除。它是 QUIC 配置应用精简流程的一部分。如果使用，此设置将仅应用于前端连接。

应用于计算出的数据包重排阈值的比率。如果太小，可能会触发高丢包检测。默认值为 50。

此关键字在 3.3 中已弃用，并将在 3.5 中删除。它是 QUIC 配置应用精简流程的一部分。如果使用，此设置将仅应用于前端连接。

设置前端或后端侧的 QUIC max_idle_timeout 传输参数。它遵循 HAProxy 时间格式，以毫秒表示。这决定了连接在有效时间段内保持不活动后静默关闭的时间段。两个端点都依赖于相同的协商值：- 如果两个参数都不为空，则取两个参数中的最小值，- 如果只有一个参数不为空，则取最大值，- 如果两个参数都为空，则禁用此功能。默认值为 30 秒。

此关键字在 3.3 中已弃用，并将在 3.5 中删除。它是 QUIC 配置应用精简流程的一部分。如果使用，此设置将仅应用于前端连接。

设置前端或后端侧每个连接的故障阈值，达到该阈值时连接将自动终止。这允许自动终止行为不当的连接，而无需为它们编写显式规则。默认值为零，表示未设置阈值，因此不会有任何事件导致连接关闭。请注意，一些 QUIC 客户端在长时间连接中可能会偶尔导致一些故障，因此这里的任何非零值可能都应在数百或数千范围内才能有效，而不会影响稍微有问题的客户端。也可以通过使用 "tune.glitches.kill.cpu-usage" 仅在 CPU 使用率超过某个级别时终止连接。

此关键字在 3.3 中已弃用，并将在 3.5 中删除。它是 QUIC 配置应用精简流程的一部分。如果使用，此设置将仅应用于前端连接。

一旦半开连接数达到此数值，将为所有已配置的 QUIC 侦听器动态启用重试（Retry）功能。半开连接是指其握手尚未成功完成或失败的连接。要使此设置生效，需要设置集群密钥（cluster secret），否则它将被静默忽略（参见“cluster-secret”设置）。如果强制使用了 QUIC 重试（参见“quic-force-retry”），此设置也将被静默忽略。默认值为 100。有关 QUIC 重试的更多信息，请参阅 https://www.rfc-editor.org/rfc/rfc9000.html#section-8.1.2。

此关键字在 3.3 中已弃用，并将在 3.5 中删除。它是 QUIC 配置应用精简流程的一部分。如果使用，此设置将仅应用于前端连接。

全局指定 QUIC 前端连接如何使用套接字进行接收/发送操作。连接可以共享侦听器套接字，或者每个连接可以分配自己的套接字。默认值是 "default-on"。这用于为每个 QUIC 连接分配一个专用套接字。此选项是实现大量 QUIC 流量最佳性能的首选选项。这也是确保软停止正确执行而不会丢失 QUIC 连接数据以及有效处理 sendto() 操作期间瞬态错误情况的唯一方法。但是，这依赖于 UDP 网络堆栈的一些高级功能。如果您的平台被认为不兼容，haproxy 将在启动时自动切换到 "force-off" 模式。请注意，在特权端口上运行的 QUIC 侦听器可能需要以 uid 0 身份运行，或者需要一些特定于操作系统的调整才能允许目标 uid 绑定此类端口，例如系统功能。另请参阅 "setcap" 全局指令。"force-off" 值表示 QUIC 传输将发生在共享侦听器套接字上。此选项对于小流量可能是一个很好的折衷方案，因为它可以减少 FD 消耗。但是，如果侦听器在大量线程之间共享，或者可以同时使用大量 QUIC 连接，则性能不会是最佳的，因为 CPU 使用率会更高。此设置与每个 "quic-socket" 绑定选项结合应用。如果在全局调优上使用 "default-on" 模式，它将为每个侦听器激活，但带有 "quic-socket listener" 的侦听器除外。但是，如果在全局使用 "force-off"，它将应用于每个侦听器实例，无论其单独配置如何。

此关键字在 3.3 中已弃用，并将在 3.5 中删除。它是 QUIC 配置应用精简流程的一部分。较新的选项名为 "tune.quic.fe.sock-per-conn"，传统值 "connection" 对应于 "default-on"，"listener" 对应于 "force-off"。

此设置允许配置每个流中传输中数据字节数的硬限制。它以 QUIC 流 rxbuf 连接设置的百分比表示，结果向上舍入到 bufsize。默认值是 90。这适用于最常见的 Web 场景，其中上传仅针对一个或几个流执行，而其余流仅用于下载。如果流 rxbuf 连接限制保持在合理水平，则确保只有一部分打开的流可以分配到其最大容量。在应用程序并行使用许多上传流并遭受这些流之间不公平性的情况下，降低此比率可能是有意义的，以增加公平性并减少每流带宽。

此关键字在 3.3 中已弃用，并将在 3.5 中删除。它是 QUIC 配置应用精简流程的一部分。如果使用，此设置将仅应用于前端连接。

设置前端或后端侧的 QUIC initial_max_streams_bidi 传输参数。这是远程对等方在连接生命周期内将被授权同时打开的双向流的最大数量。在前端侧，这限制了并发 HTTP/3 客户端请求的数量。默认值是 100。请注意，如果您减少它，它可能会限制流在接收时的缓冲能力，这会导致上传吞吐量差。可以通过增加 QUIC 流 rxbuf 连接设置来纠正。

此关键字在 3.3 中已弃用，并将在 3.5 中删除。它是 QUIC 配置应用精简流程的一部分。如果使用，此设置将仅应用于前端连接。

此设置是 QUIC 前端连接中传输中数据字节数的硬限制。它被重用作为 initial_max_data 传输参数的值。它直接影响对等方的上传带宽，具体取决于延迟和 haproxy 中每个连接的内存消耗。默认情况下，该值设置为 0，表示它必须自动生成为 max-concurrent 和 bufsize 的乘积。例如，如果后端应用程序依赖于高延迟网络上的大量上传，则可以增加此值。

此关键字在 3.3 中已弃用，并将在 3.5 中删除。它是 QUIC 配置应用精简流程的一部分。如果使用，此设置将仅应用于前端连接。

启用（'on'）或禁用（'off'）QUIC 发射的分组支持。默认情况下，它是活动的。分组的目的是平滑数据发射以减少网络丢失。在大多数情况下，它将通过避免重传来显著提高网络吞吐量。但是，对于具有非常高带宽/低延迟特性的网络，禁用它可能很有用，以防止不必要的延迟并减少 CPU 消耗。另请参阅 "quic-cc-algo" 绑定选项。

此关键字在 3.3 中已弃用，并将在 3.5 中删除。它是 QUIC 配置应用精简流程的一部分。如果使用，此设置将仅应用于前端连接。

启用（'on'）或禁用（'off'）QUIC 发射的 UDP GSO 支持。默认情况下，它是活动的。此内核功能允许通过单个系统调用发射多个数据报，这对于大型传输更高效。当怀疑发射有问题时，根据开发人员的建议禁用它可能很有用。

此关键字在 3.3 中已弃用，并将在 3.5 中删除。它是 QUIC 配置应用精简流程的一部分。如果使用，此设置将仅应用于前端连接。

禁用前端侧的 QUIC 传输协议。所有 QUIC 侦听器仍将创建，但它们不会侦听传入数据报。因此，haproxy 将不会处理前端侧的任何 QUIC 流量。默认值是 "on"。如果怀疑 QUIC 流量有问题，可以使用此选项轻松切换 QUIC 侦听器，而无需修改每个单独的配置行。另请参阅 "quic_enabled" 样本获取。

设置 QUIC 协议栈在传输层用于发送的最大可用内存量。这既是飞行中字节的限制，也是多路复用器输出缓冲区的限制。请注意，为防止线程竞争，此限制并非严格执行，因此在某些情况下可能会超过。此外，每个连接将始终能够使用至少 2 个数据报的窗口，因此应与适当的 maxconn 结合使用。

此关键字在 3.3 中已弃用，并将在 3.5 中删除。它是 QUIC 配置应用精简流程的一部分。如果使用，此设置将仅应用于前端连接。

启用（'on'）或禁用（'off'）QUIC 多路复用器的零拷贝数据发送。默认情况下启用。

此配置选项接受一个介于 -20 和 19 之间的值。它应用了 man 2 setpriority 中记录的调度优先级。此优先级在配置解析之后应用，这意味着只有工作进程或独立进程会应用它。通常配置它以设置比执行配置解析的进程（tune.renice.startup）更高的优先级。

此配置选项接受一个介于 -20 和 19 之间的值。它应用了 man 2 setpriority 中记录的调度优先级。此优先级在应用其余配置之前应用，如果您想降低配置解析的优先级，这可能很有用。这应用于独立进程或工作进程在配置解析之前。一旦配置被解析，除非使用 tune.renice.runtime，否则将恢复先前的优先级。

将非连接套接字上的内核套接字接收缓冲区大小设置为此大小。这可用于侦听器模式下的 QUIC 和前端上的日志转发。默认系统缓冲区有时可能太小，无法接收大量聚合流量的套接字，导致一些丢失和可能的重传（在 QUIC 的情况下），可能会在高流量下减慢连接建立速度。该值以字节表示，应用于每个套接字。在侦听器模式下，套接字在所有连接之间共享，套接字总数取决于 "bind
This keyword is available in sections :
Peers declaration
Log forwarding
Alphabetically sorted keywords reference" 行的 "shards
This keyword is available in sections :
Peers declaration
Bind options" 值。没有一个好的值，一个好的值对应于预期大小乘以预期连接数。内核可能会修剪大值。另请参阅 "tune.rcvbuf.client" 和 "tune.rcvbuf.server" 以了解其连接套接字对应项，以及 "tune.sndbuf.backend" 和 "tune.sndbuf.frontend" 以了解发送设置。

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

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