本文档涵盖了上述版本中实现的配置语言。它不提供任何提示、示例或建议。有关此类文档，请参阅参考手册或架构手册。以下摘要旨在帮助您按名称查找章节并在文档中导航。文档贡献者须知：本文档每行格式化为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 关闭”模式，连接建立的次数与 HTTP 事务的次数相同。由于服务器在响应后关闭连接，客户端不需要知道内容长度，它认为当连接关闭时响应就完成了。这也意味着如果某些响应由于网络错误而被截断，客户端可能会错误地认为响应已完成，这有时会导致屏幕上显示截断的图像。由于协议的事务性性质，可以对其进行改进以避免在两个后续事务之间关闭连接。然而，在这种模式下，服务器必须为每个响应指示内容长度，以便客户端不会无限期地等待。为此，使用了一个特殊标头：“Content-length”。这种模式称为“keep-alive”模式，随 HTTP/1.1 出现（一些 HTTP/1.0 代理也支持它），在请求之间重用的连接称为“持久连接”：[CON] [REQ1] ... [RESP1] [REQ2] ... [RESP2] [CLO] ... 它的优点是事务之间的延迟减少，服务器端所需的处理能力减少，以及能够检测截断的响应。它通常比关闭模式更快，但并非总是如此，因为某些客户端通常将其并发连接限制在较小的值，这在很大程度上无法弥补糟糕的网络连接。此外，一些服务器必须长时间保持连接活动以等待可能的新请求，并且由于连接数量过多可能会导致高内存使用，而过快关闭可能会中断在连接关闭时到达的某些请求。在这种模式下，响应大小需要预先知道，因此对于动态生成或压缩的内容来说并不总是可能。出于这个原因，实现了另一种模式，即“分块模式”，其中发送方不是一次性宣布整个大小，而是只公布它在缓冲区中已经拥有的下一个“块”的响应大小，并且可以在任何时候以零大小的块终止。在这种模式下，不使用 Content-Length 标头。通信中的另一个改进是管道模式。它仍然使用 keep-alive，但客户端不会等待第一个响应就发送第二个请求。这对于获取构成页面的大量图像很有用：[CON] [REQ1] [REQ2] ... [RESP1] [RESP2] [CLO] ... 这显然对性能有巨大的好处，因为后续请求之间的网络延迟被消除了。许多 HTTP 代理不正确支持管道，因为在 HTTP 中无法将响应与相应的请求关联起来。出于这个原因，服务器必须按照接收请求的完全相同顺序进行回复。实际上，在各种客户端多次尝试部署后，由于其在某些服务器上的可靠性不足，它已被完全放弃。但服务器必须支持它。下一个改进是多路复用模式，如 HTTP/2 和 HTTP/3 中实现的那样。在这种模式下，多个事务（即请求-响应对）通过单个连接并行传输，并且它们都以自己的速度进行，相互独立。通过多路复用协议，引入了“流”的新概念，以表示通过同一连接发生的这些并行通信。每个流通常被分配一个给定连接的唯一标识符，两端都使用该标识符来知道将数据传递到何处。客户端通过同一连接并行启动许多（最多 100 个，有时更多）流是很常见的，并让服务器对它们进行排序并根据可用的响应以任何顺序进行响应。多路复用模式的主要好处是它显著减少了往返次数，并加快了高延迟网络上的页面加载时间。这在许多使用图像的网站上有时可见，所有图像似乎都是并行加载的。这些协议还通过采用一些机制来压缩标头字段以减少线路上的字节数来提高效率，因此如果没有适当的工具，它们无法像 HTTP/1 那样通过手动操作或肉眼识别。因此，HTTP 消息的各种示例在文献中（包括本文档）继续使用 HTTP/1 语法表示，即使是较新版本的协议也是如此。HTTP/2 存在一些设计限制，例如数据包丢失会同时影响所有流，如果客户端花费太多时间检索对象（例如，需要将其存储在磁盘上），它可能会减慢其检索速度，并使其在此期间无法访问其后面待处理的数据。这称为“队头阻塞”或“HoL 阻塞”，有时也简称“HoL”。HTTP/3 是在 QUIC 之上实现的，QUIC 本身是在 UDP 之上实现的。QUIC 通过独立处理的流在传输层解决了队头阻塞问题。实际上，当发生丢失时，受影响的流不会影响其他流，并且所有流都可以并行访问。QUIC 还提供连接迁移支持，但目前 haproxy 不支持。默认情况下，HAProxy 在持久连接方面以 keep-alive 模式运行：对于每个连接，它处理每个请求和响应，并在响应结束和新请求开始之间将连接在两端保持空闲。当它从客户端接收 HTTP/2 连接时，它并行处理所有请求并使连接空闲，等待新请求，就像它是 keep-alive HTTP 连接一样。HAProxy 主要支持 3 种连接模式：- keep alive：处理所有请求和响应，并且面向客户端和面向服务器的连接保持活动状态以处理新请求。这是默认设置，适用于现代网络和现代协议（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 中的一些不需要服务器的内部处理，例如统计页面、缓存或一些用于实现小型应用程序的 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 个字段组成：- 方法：GET - URI：/serv/login.php?lang=en&profile=2 - 版本标签：HTTP/1.1 所有这些都由标准称之为 LWS（线性空白字符）分隔，通常是空格，但也可能是制表符或换行符/回车符后跟空格/制表符。方法本身不能包含任何冒号（':'），并且仅限于字母字符。所有这些各种组合使得 HAProxy 自己执行拆分而不是让用户编写复杂或不准确的正则表达式是可取的。URI 本身可以有几种形式：- “相对 URI”：/serv/login.php?lang=en&profile=2 它是一个没有主机部分的完整 URL。这通常是服务器、反向代理和透明代理接收到的内容。- “绝对 URI”，也称为“URL”：http://192.168.0.12:8080/serv/login.php?lang=en&profile=2 它由一个“方案”（协议名称后跟 '://'）、一个主机名或地址，可选的一个冒号（':'）后跟一个端口号，然后是一个以地址部分后的第一个斜杠（'/'）开头的相对 URI。这通常是代理接收到的内容，但支持 HTTP/1.1 的服务器也必须接受这种形式。- 星号（'*'）：这种形式仅在与 OPTIONS 方法关联时接受，且不可转发。它用于查询下一跳的功能。- 地址:端口组合：192.168.0.12:80 这与 CONNECT 方法一起使用，该方法用于通过 HTTP 代理建立 TCP 隧道，通常用于 HTTPS，但有时也用于其他协议。在相对 URI 中，识别出两个子部分。问号之前的部分称为“path”。它通常是服务器上静态对象的相对路径。问号之后的部分称为“查询字符串”。它主要与发送到动态脚本的 GET 请求一起使用，并且非常特定于所使用的语言、框架或应用程序。HTTP/2 和 HTTP/3 不在请求中传输版本信息，因此版本被假定为与底层协议的版本相同（即“HTTP/2”）。此外，这些协议不将请求行作为一部分发送，而是将其拆分为称为“伪标头”的单独字段，其名称以冒号开头，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 在索引标头、检查值和计数时会处理所有这些复杂的组合，因此没有理由担心它们的书写方式，但重要的是，如果应用程序做出了不寻常但有效的事情，不要指责它有 bug。重要提示：正如 RFC7231 建议的那样，HAProxy 通过用 LWS 替换标头中间的换行符来规范化标头，以连接多行标头。这对于正确的分析是必要的，并有助于能力较弱的 HTTP 解析器正确工作，不被此类复杂结构所迷惑。

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

第 1 行是“响应行”。它始终由 3 个字段组成：- 版本标签：HTTP/1.1 - 状态码：200 - 原因：OK 状态码始终是 3 位数字。第一位数字表示一般状态：- 1xx = 要跳过的参考消息（例如 100, 101）- 2xx = OK，内容正在跟随（例如 200, 206）- 3xx = OK，没有内容跟随（例如 302, 304）- 4xx = 客户端引起的错误（例如 401, 403, 404）- 5xx = 服务器引起的错误（例如 500, 502, 503）大于 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
This keyword is available in sections :
Alphabetically sorted keywords reference
Alphabetically sorted actions reference”操作）。

响应头的工作方式与请求头完全相同，因此，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 和：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

在一种特定情况下，可能需要第二层的引用或转义。一些关键字在括号内接受参数，有时用逗号分隔。这些参数通常是整数或预定义词，但当它们是任意字符串时，可能需要执行单独的转义级别，以区分属于参数的字符和用于分隔参数本身的字符。一个非常常见的情况是"regsub"转换器。它将正则表达式作为参数，如果内部需要闭括号，则该括号需要有自己的引号。关键字参数解析器与顶层解析器在引号方面完全相同，只是不处理#、$和\xNN转义。但并非总是显而易见的是，内部使用的分隔符必须首先进行转义或引用，以免它们在顶层被解析。让我们以使用"regsub"转换器为例，该转换器接受3个参数：一个正则表达式、一个替换字符串和一组标志：# 替换路径中所有"foo"为"blah"： http-request set-path %[path,regsub(foo,blah,g)] 这里不需要特殊的引用。但如果现在我们想将"foo"或"bar"替换为"blah"，我们将需要正则表达式"(foo|bar)"。我们不能写：http-request set-path %[path,regsub((foo|bar),blah,g)] 因为我们希望字符串像这样分割：http-request set-path %[path,regsub((foo|bar),blah,g)] |---------|----|-| arg1 _/ / / arg2 __________/ / arg3 ______________/ 但实际上，传递的是一个在开括号和闭括号之间的字符串，然后是垃圾：http-request set-path %[path,regsub((foo|bar),blah,g)] |--------|--------| arg1=(foo|bar _/ / trailing garbage _________/ 这里的明显解决方案似乎是闭括号需要被引用，但单独这样做是行不通的，因为如上所述，引号由顶层解析器处理，它会在处理此词之前解析它们：http-request set-path %[path,regsub("(foo|bar)",blah,g)] ------------ -------- ---------------------------------- word1 word2 word3=%[path,regsub((foo|bar),blah,g)] 所以我们没有改变第二层参数解析器的任何东西，它仍然将截断的正则表达式视为唯一的参数，并在字符串末尾看到垃圾。通过转义引号，它们将未经修改地传递到第二层：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 _______________/ 另一种方法是使用整个字符串外面的单引号和里面的双引号（这样双引号不会再次被剥离）：http-request set-path '%[path,regsub("(foo|bar)",blah,g)]' ------------ -------- ---------------------------------- word1 word2 word3=%[path,regsub("(foo|bar)",blah,g)] |---------||----|-| arg1=(foo|bar) _/ / / arg2 ___________/ / arg3 _______________/ 但在这种情况下，重要的是要注意嵌入到更高层字符串中的分隔符仍然是纯字符，不再是分隔符。这特别意味着逗号周围的空格和制表符是字符串的一部分。下面的例子在多个方面是错误的：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" ______________/ 仅仅用空格包围逗号就导致空格成为字段本身的一部分，因此转换器是" regsub"（以空格开头），它将找不到并触发错误，但更微妙的是，替换字符串" blah"将在输出中插入一个空格。一个好的经验法则是永远不要在表达式中插入不必要的空格。当使用正则表达式时，表达式中可能会出现美元符（'$'）字符，或者替换字符串中使用反斜杠（'\'）。在这种情况下，这些也会在双引号内处理，因此首选单引号（或双重转义）。示例：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 ______________________/ 请记住，反斜杠在单引号内不是转义字符，并且上面的整个词已经使用单引号对其进行了保护。相反，如果整个表达式都使用双引号，则美元符和反斜杠将在顶层解析，从而破坏第二层的参数内容。不幸的是，由于单引号不能在强引用内转义，如果您需要在参数中包含单引号，则需要对其进行两次转义或引用。有几种方法可以做到这一点：http-request set-var(txn.foo) str("\\'foo\\'") http-request set-var(txn.foo) str(\"\'foo\'\") http-request set-var(txn.foo) str(\\\'foo\\\') 当有疑问时，只需在任何地方都不要使用引号，然后开始在需要逗号或闭括号的参数周围放置单引号或双引号，并考虑如果字符串包含美元符或反斜杠，则使用反斜杠转义这些引号。再次强调，这与Bourne shell中将命令双重转义传递给"eval"时所用的方法非常相似。对于API编写者来说，最好的方法可能是围绕每个参数放置转义引号，无论其内容如何。用户可能会发现，在整个表达式周围使用单引号并在每个参数周围使用双引号可以提供更具可读性的配置。

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

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

HAProxy定义了一些变量，它们可以在配置文件中使用，也可以被程序继承（参见12.9. 程序）。这些变量在下面的矩阵中列出，并分为四类：* 可用：变量可从配置中访问，可以按原样解析，也可以在条件块或谓词中使用，以启用或禁用某些配置片段，如第2.4节“条件块”所述。* 可修改：变量可以通过"setenv"/"unsetenv"关键字在配置中重新定义或取消设置。* 已列出：变量在CLI的"show env"命令输出中列出，如管理指南的第9.3节“Unix套接字命令”所述。* 已导出：变量被导出以在修改后的环境中启动程序（参见第12.9节“程序”）。请注意，这不适用于外部检查，外部检查对导出变量有自己的规则。还有两个子类别“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 它们的值在配置解析期间未定义，在初始化期间稍后设置。因此，建议不要在条件块中使用这些变量，也不要在全局部分的"setenv"/"resetenv"/"unsetenv"关键字中引用它们。下表总结了每种变量在不同工作模式下的状态：+--------------------------+----------+---------+------------+-----------+ | 变量 | 导出 | 可用 | 可修改 | 已列出 | | | +---------+------------+-----------+ | | | M | W | M | W | M | W | +--------------------------+----------+----+----+------+-----+-----+-----+ | HAPROXY_STARTUP_VERSION | X | X | X | | | X | X | | HAPROXY_BRANCH | X | X | X | | | X | X | | HAPROXY_CFGFILES | X | | | | | X | X | | HAPROXY_MWORKER | X | | | | | 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: 在主从模式下，此变量设置为 1。 * HAPROXY_CLI: 配置的每个进程的统计套接字监听器地址，这些地址以分号分隔。 * HAPROXY_MASTER_CLI: 在主从模式下，主 CLI 的监听器地址，以分号分隔。 * HAPROXY_STARTUP_VERSION: 包含用于启动的版本，在主从模式下，这是用于启动主的版本，即使在更新二进制文件和重新加载之后也是如此。 * HAPROXY_BRANCH: 包含 HAProxy 分支版本（例如 "2.8"）。它不包含完整的版本号。如果资源（例如映射或证书）位于包含分支号的路径中，则在迁移时可能有用。此外，一些伪变量在内部解析并可用作常规变量。伪变量始终以点号（'.'）开头，并且是唯一允许使用点号的变量。当前的伪变量列表是： * .FILE: 当前正在解析的配置文件的名称。 * .LINE: 当前正在解析的配置文件的行号，从一开始。 * .SECTION: 当前正在解析的节的名称，如果该节没有名称（例如 "global"），则为其类型，或者在第一个节之前为空字符串。这些变量在它们被解析的位置解析。例如，如果 ".LINE" 变量在默认节中的 "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)"。目前支持的谓词列表如下：- 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 在主进程和 # 工作进程环境中自动设置（参见 2.3. 环境变量中的 HAProxy 变量矩阵）。 # 它的存在会启用一个额外的监听器。 global master-worker .if defined(HAPROXY_MWORKER) listen mwcli_px bind :1111 ... .endif # 2. HAPROXY_BRANCH 由 HAProxy 在主进程和工作 # 进程环境中自动设置（参见 2.3. 环境变量中的 HAProxy 变量矩阵）。 # 我们检查 HAPROXY_BRANCH 值并有条件地启用 # mworker-max-reloads 参数。 global master-worker .if streq("$HAPROXY_BRANCH",3.1) mworker-max-reloads 5 .endif # 3. 用户在全局部分设置了一些任意环境变量。 # 如果 HAProxy 以主从模式启动，它们会出现在主进程和 # 工作进程环境中。我们检查这些 # 变量的值并有条件地启用端口 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 配置中，变量可以在样本获取函数、转换器、日志格式字符串或 TCP/HTTP 操作中使用。可以定义进程范围的变量，这些变量在进程的整个生命周期中全局可访问。其他一些变量的生命周期较短。变量类似于 shell 脚本中的变量。它是内存块的符号名称。变量的大小不受限制，并且是动态分配的。因此，必须谨慎使用它们，尤其是在大量使用时。但是，可以通过设置“tune.vars”全局参数来限制变量使用的最大内存量。变量必须使用“<scope>.<name>”格式指定。<scope> 是一个单词，表示变量的生命周期。<name> 部分在作用域内，只能包含字符 'a-z'、'A-Z'、'0-9' 和 '_'。它在此作用域中是唯一的，但不同作用域中的相同名称可以引用不同的变量。支持的作用域有：* proc：用于在整个进程生命周期中已知并全局可访问的变量。“proc”变量可以使用“get var”和“set var”命令从 CLI 操作。它们也可以通过“set-var
This keyword is available in sections :
Process management and security
Alphabetically sorted actions reference
Converters”和“set-var-fmt
This keyword is available in sections :
Process management and security
Alphabetically sorted actions reference”指令从“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
This keyword is available in sections :
Peers declaration
Rings
Alphabetically sorted keywords reference"、"nameserver"和"log
This keyword is available in sections :
Peers declaration
Log forwarding
Process management and security
Alphabetically sorted keywords reference"等几个语句都需要一个地址。此地址可以是主机名、IPv4 地址、IPv6 地址或 '*'。'*' 等同于特殊地址 "0.0.0.0"，在"bind
This keyword is available in sections :
Peers declaration
Log forwarding
Alphabetically sorted keywords reference"或"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>。该文件描述符必须已绑定，并且可能已或未在监听。 'ip@<address>[:port1[-port2]]' 后跟 <address> 被视为 IPv4 或 IPv6 地址，具体取决于语法。根据使用此地址的语句，端口或端口范围可能或必须指定。 'ipv4@<address>[:port1[-port2]]' 后跟 <address> 始终被视为 IPv4 地址。根据使用此地址的语句，端口或端口范围可能或必须指定。 'ipv6@<address>[:port1[-port2]]' 后跟 <address> 始终被视为 IPv6 地址。根据使用此地址的语句，端口或端口范围可能或必须指定。 'sockpair@<n>' 后跟地址是已连接的 unix 套接字或套接字对的文件描述符。在连接期间，发起方创建一对已连接的套接字，并通过 FD 将其中一个传递给另一端。监听器等待从 unix 套接字接收 FD，并将其用作 accept() 的 FD。应谨慎使用。错误：已知此协议在 macOS 上不可靠，因为 macOS sendmsg(2) 实现存在问题。连接可能无法正确接受。 'unix@<path>' 后跟字符串被视为 UNIX 套接字 <path>。此前缀对于声明不以斜杠 '/' 开头的 UNIX 套接字路径很有用。

前面的“地址族前缀”也可以作为前缀来强制套接字类型和传输方法。默认值取决于使用此地址的语句，但在某些情况下，用户可以强制将其设置为不同的值。"log
This keyword is available in sections :
Peers declaration
Log forwarding
Process management and security
Alphabetically sorted keywords reference"语句就是这种情况，其默认值是通过 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 地址，但套接字类型强制为“数据报”，传输方法强制为“流”。根据使用此地址的语句，可以或必须指定 UDP 端口或端口范围。它等同于 "quic+ipv4@"。 'quic6@<address>[:port1[-port2]]' 后跟 <address> 始终被视为 IPv6 地址，但套接字类型强制为“数据报”，传输方法强制为“流”。根据使用此地址的语句，可以或必须指定 UDP 端口或端口范围。它等同于 "quic+ipv6@"。 'tcp@<address>[:port1[-port2]]' 后跟 <address> 根据语法被视为 IPv4 或 IPv6 地址，但套接字类型和传输方法强制为“流”。根据使用此地址的语句，可以或必须指定端口或端口范围。它被视为 'stream+ip@' 的别名。 'tcp4@<address>[:port1[-port2]]' 后跟 <address> 始终被视为 IPv4 地址，但套接字类型和传输方法强制为“流”。根据使用此地址的语句，可以或必须指定端口或端口范围。它被视为 'stream+ipv4@' 的别名。 'tcp6@<address>[:port1[-port2]]' 后跟 <address> 始终被视为 IPv6 地址，但套接字类型和传输方法强制为“流”。根据使用此地址的语句，可以或必须指定端口或端口范围。它被视为 'stream+ipv4@' 的别名。 'mptcp@<address>[:port1[-port2]]' 后跟 <address> 根据语法被视为 IPv4 或 IPv6 地址，但套接字类型和传输方法强制为“流”，并使用 MPTCP 协议。根据使用此地址的语句，可以或必须指定端口或端口范围。 'mptcp4@<address>[:port1[-port2]]' 后跟 <address> 始终被视为 IPv4 地址，但套接字类型和传输方法强制为“流”，并使用 MPTCP 协议。根据使用此地址的语句，可以或必须指定端口或端口范围。 'mptcp6@<address>[:port1[-port2]]' 后跟 <address> 始终被视为 IPv6 地址，但套接字类型和传输方法强制为“流”，并使用 MPTCP 协议。根据使用此地址的语句，可以或必须指定端口或端口范围。 'udp@<address>[:port1[-port2]]' 后跟 <address> 根据语法被视为 IPv4 或 IPv6 地址，但套接字类型和传输方法强制为“数据报”。根据使用此地址的语句，可以或必须指定端口或端口范围。它被视为 'dgram+ip@' 的别名。 'udp4@<address>[:port1[-port2]]' 后跟 <address> 始终被视为 IPv4 地址，但套接字类型和传输方法强制为“数据报”。根据使用此地址的语句，可以或必须指定端口或端口范围。它被视为 'dgram+ipv4@' 的别名。 'udp6@<address>[:port1[-port2]]' 后跟 <address> 始终被视为 IPv6 地址，但套接字类型和传输方法强制为“数据报”。根据使用此地址的语句，可以或必须指定端口或端口范围。它被视为 'dgram+ipv4@' 的别名。 'uxdg@<path>' 后跟字符串被视为 unix 套接字 <path>，但传输方法强制为“数据报”。它被视为 'dgram+unix@' 的别名。 'uxst@<path>' 后跟字符串被视为 unix 套接字 <path>，但传输方法强制为“流”。它被视为 'stream+unix@' 的别名。 在未来的版本中，可以使用其他前缀来指定 QUIC 等协议，这些协议提供了基于“数据报”类型套接字的流传输。

# 一个简单的 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 - no-quic - 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 - 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.cc-hystart - tune.quic.cc.cubic.min-losses - tune.quic.disable-tx-pacing - tune.quic.disable-udp-gso - tune.quic.frontend.glitches-threshold - tune.quic.frontend.max-data-size - tune.quic.frontend.max-idle-timeout - tune.quic.frontend.max-streams-bidi - tune.quic.frontend.max-tx-mem - tune.quic.frontend.stream-data-ratio - tune.quic.frontend.default-max-window-size - tune.quic.max-frame-loss - tune.quic.reorder-ratio - tune.quic.retry-threshold - tune.quic.socket-owner - 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 (已废弃) - 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 (已废弃) - tune.ssl.ocsp-update.mindelay (已废弃) - 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
This keyword is available in sections :
Bind options
Server and default-server options"、"ca-verify-file" 或 "crl-file
This keyword is available in sections :
Bind options
Server and default-server options" 指令时，分配一个默认目录来获取 SSL CA 证书和 CRL。在 "ca-file
This keyword is available in sections :
Bind options
Server and default-server options"、"ca-verify-file" 和 "crl-file
This keyword is available in sections :
Bind options
Server and default-server options" 中指定的绝对位置优先并忽略 "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
This keyword is available in sections :
Bind options
Fetching samples from internal states”绑定指令一样。第二个及以后的参数是 CPU 集。每个 CPU 集要么是一个唯一的数字（从 0 开始表示第一个 CPU），要么是一个由短划线 ('-') 分隔的两个这样的数字范围。这些 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分配给线程和线程组。这种映射通常使用“cpu-map”指令执行，尽管在异构系统上维护它可能特别困难。“cpu-policy”指令选择少数分配策略中的哪一个，当不使用“cpu-map”时使用。目前支持以下策略：- none 不执行任何特定的后选择。所有启用的CPU都将可用，如果未设置线程数，它将设置为可用CPU的数量，但每个线程组不超过32位系统上的32个或64位系统上的64个。如果未设置线程组数，它将设置为1。- efficiency 恰好与下面的“group-by-ccx”相同，只是性能比下一个性能较低的CPU高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的CPU可能是有意义的，以避免创建许多组，或者在并非所有核都在使用时稍微平滑分配。请注意，当CCX之间的通信缓慢时，这可能产生非常糟糕的性能影响。通常不建议这样做。- group-by-2-clusters 与“group-by-cluster”相同，但每两个集群创建一个组。这对于具有许多小核集群的CPU可能是有意义的，以避免创建许多组，或者在并非所有核都在使用时稍微平滑分配。请注意，当集群之间的通信缓慢时，这可能产生非常糟糕的性能影响。通常不建议这样做。- group-by-3-ccx 与下面的“group-by-ccx”相同，但每三个CCX创建一个组。这对于具有许多小核CCX的CPU可能是有意义的，以避免创建许多组，或者在并非所有核都在使用时稍微平滑分配。请注意，当CCX之间的通信缓慢时，这可能产生非常糟糕的性能影响。通常不建议这样做。- group-by-3-clusters 与“group-by-cluster”相同，但每三个集群创建一个组。这对于具有许多小核集群的CPU可能是有意义的，以避免创建许多组，或者在并非所有核都在使用时稍微平滑分配。请注意，当集群之间的通信缓慢时，这可能产生非常糟糕的性能影响。通常不建议这样做。- group-by-4-ccx 与下面的“group-by-ccx”相同，但每四个CCX创建一个组。这对于具有许多小核CCX的CPU可能是有意义的，以避免创建许多组，或者在并非所有核都在使用时稍微平滑分配。请注意，当CCX之间的通信缓慢时，这可能产生非常糟糕的性能影响。通常不建议这样做。- group-by-4-clusters 与“group-by-cluster”相同，但每四个集群创建一个组。这对于具有许多小核集群的CPU可能是有意义的，以避免创建许多组，或者在并非所有核都在使用时稍微平滑分配。请注意，当集群之间的通信缓慢时，这可能产生非常糟糕的性能影响。通常不建议这样做。- group-by-ccx 如果既未设置“nbthread”也未设置“nbtgroups”，则为每个具有可用CPU的CPU核心复合体（“CCX”）创建一个线程组，每个组的线程数与CPU数相同。一个CCX将CPU分组在一起，这些CPU对最后一级缓存（“LLC”，通常是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”相同，只是性能比下一个性能较高的CPU低80%以下的CPU集群将被驱逐。这些通常是“小核”或“高效核”，它们的增加通常不会带来显著的增益，并且很容易适得其反（例如TLS握手）。通常，将这些核心用于其他任务，例如网络处理，会更有效。在开发系统上，这些也可以用于运行辅助工具，例如负载生成器和监控工具。- resource 这与上面的“group-by-cluster”类似，只是将只使用最小且最有效的CPU集群，而所有其他集群将被忽略。这可用于将资源使用限制在仍然提供体面性能的最低限度，例如尝试进一步降低功耗或最小化某些租用系统上旁路设置所需的核数，以便更容易地向下扩展系统。请注意，如果只有一个集群存在，它仍将完全使用。

允许以符号方式描述要在其上运行的 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
This keyword is available in sections :
Load options
Bind options
Server and default-server options" 指令时，分配一个默认目录来获取 SSL 证书。指定的绝对位置优先并忽略 "crt-base
This keyword is available in sections :
Certificate Storage
Process management and security"。

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

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

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

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

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

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

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

默认情况下，DNS 解析器接受 IPv4 和 IPv6 地址。这可以通过服务器行上的 "resolve-prefer" 关键字以及 "do-resolve" 操作的 family 参数来影响，但这只是一种偏好，并不会阻止在单独使用时使用其他家族。在某些双栈不可用的环境中，遇到无法访问的纯 IPv6 DNS 记录可能会导致严重问题，因为它会替换之前可能一直工作到下一个请求的 IPv4 记录。"dns-accept-family" 全局选项允许强制仅使用一个（或两个）地址家族。参数是一个逗号分隔的以下单词列表：- "ipv4"：查询并接受 IPv4 地址 ("A" 记录) - "ipv6"：查询并接受 IPv6 地址 ("AAAA" 记录) - "auto"：使用 IPv4，如果系统有 IPv6 的默认网关，则使用 IPv6。上次检查的结果缓存 30 秒。当仅使用一个家族时，不会向解析器发送其他家族的请求，并且会忽略其他家族的任何响应。默认值为 "ipv4,ipv6"，它有效地启用两个家族。

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

此语句必须出现在使用标记为实验性的指令之前，否则配置文件将被拒绝。请注意，此选项涵盖的功能不能保证良好运行，并且可能在维护周期中出现故障。开发人员将在开发下一版本期间尽最大努力维护它们，并将尽一切合理努力避免破坏它们，但不作保证。因此，这些功能预计在下一个 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 亿），这将消耗过多的 RAM 用于常规使用。fd-hard-limit 设置用于对此限制强制执行一个可能较低的上限。这意味着它将始终遵守系统施加的限制（如果它们低于 <number>），但如果系统施加的限制更高，则将使用指定值。默认情况下，fd-hard-limit 设置为 1048576。此默认值可以通过 DEFAULT_MAXFD 编译时变量更改，该变量可以作为最大（内核）系统限制，如果 RLIMIT_NOFILE 硬限制非常大。在全局部分设置的 fd-hard-limit 允许临时覆盖构建时通过 DEFAULT_MAXFD 提供的值。在下面的示例中，没有指定其他设置，maxconn 值将自动适应 "fd-hard-limit" 和 RLIMIT_NOFILE 限制中的较低值：global # 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
Programs (deprecated)
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
Programs (deprecated)
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。为了允许客户端自动降级到 websocket 隧道使用 http/1.1，请在绑定行上使用 "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 是不可靠的，因为 fork 的进程可能会随机嵌入另一个线程设置的锁，并且永远无法完成操作。因此，强烈建议永远不要使用此选项，并且任何需要此类 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 将完成该链。所有其他具有相同颁发者的证书将共享内存中的链。OCSP 功能能够在未使用 .issuer 或 PEM 中未提供链时使用已完成的链。

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

当 haproxy 编译时所依赖的 TLS/SSL 库不支持 QUIC（通常是 OpenSSL）时，必须使用此设置来显式启用 QUIC 监听器绑定。当 haproxy 编译时所依赖的 TLS/SSL 库支持 QUIC（例如 quictls）时，此设置无效。请注意，设置此项后不支持 QUIC 0-RTT。

设置本地实例的对等名称。如果指定了 "-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）。此指令可以多次使用。有关参数的使用，请参阅 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。

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

在主-从模式下，此选项限制了工作进程可以承受的重载次数。如果工作进程在重载后没有退出，一旦其重载次数大于此数字，该工作进程将收到一个 SIGTERM 信号。此选项有助于控制工作进程的数量。另请参阅管理指南中的“show proc”。

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

禁用 QUIC 传输协议。所有 QUIC 监听器仍将被创建，但它们不会绑定其地址。因此，haproxy 将不会处理任何 QUIC 流量。另请参阅“quic_enabled”样本获取。

当在支持 NUMA 的平台上运行，并且 cpu-policy 设置为 "first-usable-node"（默认值）时，HAProxy 在启动时会检查机器的 CPU 拓扑。如果检测到多插槽机器，则会自动计算亲和性以在单个节点的 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.socket-owner connection" 时，通常需要一些权限，这会导致完全在 uid 0 下运行的设置。设置功能通常是更安全的替代方案，因为只会保留所需的权限。此功能是操作系统特定的，并且仅在 Linux 上构建时设置 USE_LINUX_CAP=1 时启用。支持的功能列表也取决于操作系统，并在传递无效功能名称或空名称时显示错误消息中枚举。可以传递多个功能，以逗号分隔。其中常用的有 "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”。

此设置仅在内置 OpenSSL 支持时可用。它设置描述了在 SSL/TLS 握手期间（直到 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 握手期间协商的密码算法（“密码套件”）列表的默认字符串，适用于所有未明确定义其密码套件的 "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-options，以强制应用于所有 "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-options，以强制应用于所有 "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 支持时可用。它设置了在 SSL/TLS 握手期间使用临时 Diffie-Hellman (DHE) 密钥交换时使用的默认 DH 参数，适用于所有未明确定义其参数的 "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 参数。已知自定义参数更安全，因此建议使用它们。自定义 DH 参数可以使用 OpenSSL 命令 "openssl dhparam <size>" 生成，其中大小应至少为 2048，因为 1024 位 DH 参数不应再被视为安全。

此设置仅在内置 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、颁发者、密钥。"bundle"：当配置中指定的文件不存在时，HAProxy 将尝试加载“证书捆绑包”。证书捆绑包仅在前端侧进行管理，不适用于后端证书。从 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 识别的“证书捆绑包”中，它们必须按以下方式命名：所有要捆绑的 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
Programs (deprecated)
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
Programs (deprecated)
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 时，处理器都会重新进入睡眠状态或长时间提供给另一个虚拟机，这会导致过高的延迟。此选项提供了一种解决方案，通过始终在轮询器上使用 null 超时来防止处理器进入睡眠状态。这会显著降低延迟（观察到 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 的最大值。同样，命令行 "-n" 参数允许在运行时绕过 SYSTEM_MAXCONN 限制（如果设置）。当达到 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 会话数设置为 <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"。

禁用“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_MONOTONIC 和 CLOCK_THREAD_CPUTIME_ID 的系统，否则报告的时间将为零。此选项可以在运行时使用 CLI 上的 "set profiling" 进行更改。

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

将 OpenSSL 引擎设置为 <name>。<name> 的有效值列表可以通过命令 "openssl engine" 获得。此语句可以多次使用，它将简单地启用多个加密引擎。引用不支持的引擎将阻止 HAProxy 启动。请注意，许多引擎会导致 HTTPS 性能低于使用最新处理器的纯软件。可选命令 "algo" 使用 OPENSSL 函数 ENGINE_set_default_string() 设置 ENGINE 将提供的默认算法。值为 "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，可以使用 USE_ENGINE=1 标志重新构建 HAProxy。

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

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

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

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

将缓冲区大小设置为此大小（以字节为单位）。较低的值允许在相同内存量中共存更多流，而较高的值允许某些具有非常大 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 拼接以及零拷贝转发。此命令不适用于常规使用，通常只会在复杂的调试会话中由开发人员建议使用。因此，它在内部被标记为实验性的，这意味着 "expose-experimental-directives" 必须在此指令之前的行上出现。

全局禁用数据的零拷贝转发。这是一种通过避免使用通道缓冲区来优化数据快速转发的机制。通过此指令，可以禁用此优化。注意，它还禁用了任何内核 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.frontend.glitches-threshold 的情况下无效。另请参阅全局参数 "tune.h2.fe.glitches-threshold" 和 "tune.quic.frontend.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 ~= 10.7亿）之外，没有其他限制。大约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
此关键字可在以下部分使用：
对等声明
日志转发
按字母顺序排序的关键字参考”行将创建一个单一分片，即一个进程的所有线程都将监听的单个套接字。在多线程情况下，这种效率不高，甚至可能在内核中引起一些重要的开销，用于更新轮询状态或将事件分发到各个线程。现代操作系统支持传入连接的平衡，这种机制将允许多个套接字绑定到同一个地址和端口，并将所有传入连接均匀地分发到这些套接字，以便每个线程只看到其绑定套接字中等待的连接。这显著减少了内核侧的开销，并提高了传入连接路径的性能。在HAProxy中，通常通过在“bind
此关键字可在以下部分使用：
对等声明
日志转发
按字母顺序排序的关键字参考”行上使用“shards
此关键字可在以下部分使用：
对等声明
绑定选项”设置来启用此功能，该设置默认为1，表示每个监听器在进程中都是唯一的。在具有多个处理器的系统上，将默认设置更改为“by-thread”可能更方便，以便始终为每个线程创建一个监听套接字，或者更改为“by-group”，以便始终为每个线程组创建一个监听套接字。使用“by-thread”时要小心文件描述符的使用，因为每个监听器将需要与线程数一样多的套接字。此外，某些操作系统（例如FreeBSD）限制在同一地址上最多只有256个套接字。请注意，“by-group”对于涉及单个线程组的默认配置将等同于“by-process”，并且在不支持此机制的系统上将回退到共享同一个套接字。对于不支持多个绑定的系统或套接字家族，默认是“by-group”并回退到“by-process”。

启用（'on' / 'fair'）或禁用（'off'）监听器的多队列接受，该功能将传入流量分发到“bind
此关键字可在以下部分使用：
对等声明
日志转发
按字母顺序排序的关键字参考”行被允许运行的所有线程，而不是只由自己处理。这提供了更平滑的流量分布和更好的扩展性，尤其是在由于外部活动（例如网络中断与某个线程冲突）导致线程负载不均匀的环境中。默认模式“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 脚本将布尔型 HAProxy 样本正确地处理为布尔值后，将此选项设置为“normal”。此设置必须在任何“lua-load”或“lua-load-per-thread”指令之前设置，否则将被忽略。

“burst”执行超时适用于任何 Lua 处理程序。如果处理程序在超时前未能完成或让步，它将被中止，以防止线程争用，防止流量长时间未得到服务，并最终防止进程因看门狗介入而崩溃。与其他累积让步的 Lua 超时不同，burst-timeout 将确保单个 Lua 执行窗口中花费的时间不超过配置的超时。这里的让步意味着 Lua 执行通过显式调用 lua-yielding 函数（如 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）多路复用器的数据零拷贝转发。要使用此功能，还必须配置内核拼接。默认启用。

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

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

禁用 QUIC 发送的步调支持。步调的目的是平滑数据发送以减少网络丢失。在大多数情况下，它将通过避免重传显著提高网络吞吐量。但是，对于具有非常高带宽/低延迟特性的网络，禁用它可能很有用，以防止不必要的延迟并降低 CPU 消耗。另请参阅“quic-cc-algo”绑定选项。

禁用UDP GSO发送。此内核功能允许通过单个系统调用发送多个数据报，这对于大数据传输更有效。在开发人员建议怀疑发送有问题时，禁用此功能可能很有用。

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

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

设置前端的 QUIC max_idle_timeout 传输参数（以毫秒为单位），该参数确定了连接在由两个端点宣告的两个 max_idle_timeout 值推导出的有效时间段内保持不活动后，静默关闭的时间段：- 如果两个值都不为空，则为两个值中的最小值，- 如果只有一个不为空，则为最大值，- 如果两个值都为空，则禁用此功能。默认值为 30000。

为前端设置 QUIC initial_max_streams_bidi 传输参数。这是远程对等体将被授权打开的双向流的初始最大数量。这决定了并发客户端请求的数量。默认值为 100。请注意，如果降低此值，可能会限制流在接收时的缓冲能力，从而导致上传吞吐量不佳。可以通过增加 tune.quic.frontend.max-data-size 设置来纠正。

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

此设置允许配置每个流传输中的数据字节数的硬限制。它以相对于“tune.quic.frontend.max-data-size”设置的百分比表示，结果向上取整到 bufsize。默认值为 90。这适用于最常见的 Web 场景，即上传仅针对一个或几个流执行，而其余流仅用于下载。如果 max-data-size 连接限制保持在合理水平，它将确保只有一部分打开的流可以分配到其最大容量。如果应用程序并行使用许多上传流并存在这些流之间的不公平问题，则降低此比例以增加公平性并减少每个流的带宽可能是有意义的。

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

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

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

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

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

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

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

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

将非连接套接字的内核套接字接收缓冲区大小设置为此大小。这可以在监听模式下的 QUIC 和前端的日志转发中使用。默认的系统缓冲区有时可能太小，无法处理接收大量聚合流量的套接字，导致一些丢失并可能导致重传（在 QUIC 的情况下），从而可能在流量高峰期减慢连接建立。该值以字节表示，应用于每个套接字。在监听模式下，套接字在所有连接之间共享，并且套接字的总数取决于“bind
此关键字可在以下部分使用：
对等声明
日志转发
按字母顺序排序的关键字参考”行的“shards
此关键字可在以下部分使用：
对等声明
绑定选项”值。没有一个完美的数值，一个好的数值应该等于每个连接的预期大小乘以预期连接数。内核可能会修剪过大的值。另请参阅“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 会话。

设置环形缓冲区前面的写队列数量。这可能会影响调试会话期间跟踪的 CPU 使用率，过低或过高的值都可能产生重要影响。合适的值是由开发人员通过实验确定的，除非被指示这样做以尝试解决特定问题，否则不应尝试更改它。在版本升级时不应将此类设置保留在配置中，因为其最佳值可能会随时间变化。

设置运行任务时一次可以处理的最大任务量。默认值取决于线程数，但在 35 到 280 之间，这往往显示出最高的请求率和最低的延迟。增加它可能会在处理 I/O 时产生延迟，使其太小可能会产生额外的开销。较高的线程数受益于较低的值。当尝试使用更大的值时，启用 tune.sched.low-latency 和可能启用 tune.fd.edge-triggered 以将最大延迟限制在最低可能值可能会很有用。

启用（'on'）或禁用（'off'）低延迟任务调度器。默认情况下，HAProxy 一次处理一个类别的多个类别的任务，因为这是最有效的。但是当使用较大的 tune.runqueue-depth 值运行时，这可能对请求或连接延迟产生可测量的影响。启用此低延迟设置后，如果存在较低优先级类别的任务，它们将始终在其他任务之前执行。这将允许在大量流量中降低新请求或连接所经历的最大延迟，但代价是对这种大流量产生更大的影响。对于常规使用，最好保持关闭。默认值为 off。

将非连接套接字的内核套接字发送缓冲区大小设置为此大小。这可用于后端侧的 UNIX 套接字和 UDP 日志记录，以及前端监听模式下的 QUIC。默认的系统缓冲区有时可能太小，无法用于在许多连接（或日志发送者）之间共享的套接字，导致一些丢失并可能导致重传，从而在高流量下减慢新连接的建立。该值以字节表示，应用于每个套接字。在监听模式下，套接字在所有连接之间共享，并且套接字的总数取决于“bind
此关键字可在以下部分使用：
对等声明
日志转发
按字母顺序排序的关键字参考”行的“shards
此关键字可在以下部分使用：
对等声明
绑定选项”值。没有一个好的值，一个好的值对应于每个连接的预期大小乘以预期的连接数。内核可能会修剪过大的值。另请参阅“tune.sndbuf.client”和“tune.sndbuf.server”以了解其连接套接字对应项，以及“tune.rcvbuf.backend”和“tune.rcvbuf.frontend”以了解接收设置。

强制将客户端或服务器端的内核套接字发送缓冲区大小设置为指定的字节值。此值适用于所有 TCP/HTTP 前端和后端。通常不应设置此值，默认大小（0）让内核根据可用内存量自动调整此值。但是，有时将其设置为非常低的值（例如 4096）有助于节省内核内存，因为它阻止内核缓冲过多的接收数据。不过，较低的值会显著增加 CPU 使用率。另一个用例是防止与极慢的客户端发生写超时，因为内核会等待缓冲区的大部分被读取后才再次通知 HAProxy。另请参阅 tune.notsent-lowat.client 和 tune.notsent-lowat.server，以获取更有效设置，以更精细地控制 Linux 上的内存使用和响应性，而不会损害性能。

设置全局 SSL 会话缓存的大小，以块为单位。一个块足够大，可以包含一个不带对等证书的编码会话。一个带对等证书的编码会话根据对等证书的大小存储在多个块中。一个块大约使用 200 字节的内存（基于用于 `shctx_init` 函数的 `sizeof(struct sh_ssl_sess_hdr) + SHSESS_BLOCK_MIN_SIZE` 计算）。默认值可在构建时强制指定，否则默认为 20000。当缓存满时，最空闲的条目将被清除并重新分配。较高的值会减少这种清除的发生，从而通过确保所有用户尽可能长时间地保留其会话来减少 CPU 密集型的 SSL 握手次数。所有条目在启动时预先分配。将此值设置为 0 会禁用 SSL 会话缓存。

设置用于捕获客户端 hello 密码列表、扩展列表、椭圆曲线列表和椭圆曲线点格式的缓冲区的最大大小。如果值为 0（默认值），则禁用捕获，否则将为每个 SSL/TLS 连接分配一个缓冲区。

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

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

设置在任何时候传递给 SSL_write() 的最大字节数。默认值 0 表示没有限制。与 tune.ssl.maxrecord 相反，此设置不会动态调整。较小的记录可能会降低吞吐量，但在处理低占用客户端时可能是必需的。

此选项激活 TLS 密钥的日志记录。应谨慎使用，因为它会为每个 SSL 会话消耗更多内存，并可能降低性能。默认情况下禁用。这些样本获取应用于生成 Wireshark 解密流量所需的 SSLKEYLOGFILE。https://mdn.org.cn/en-US/docs/Mozilla/Projects/NSS/Key_Log_Format SSLKEYLOG 是一系列行，其格式如下：<Label> <space> <ClientRandom> <space> <Secret> ClientRandom 由 %[ssl_fc_client_random,hex] 样本获取提供，secret 和 Label 可以在下面的数组中找到。您需要生成一个包含此数组中所有标签的 SSLKEYLOGFILE。以下样本获取是十六进制字符串，无需转换。SSLKEYLOGFILE Label | Secrets 的样本获取 --------------------------------|----------------------------------------- CLIENT_EARLY_TRAFFIC_SECRET | %[ssl_xx_client_early_traffic_secret] CLIENT_HANDSHAKE_TRAFFIC_SECRET | %[ssl_xx_client_handshake_traffic_secret] SERVER_HANDSHAKE_TRAFFIC_SECRET | %[ssl_xx_server_handshake_traffic_secret] CLIENT_TRAFFIC_SECRET_0 | %[ssl_xx_client_traffic_secret_0] SERVER_TRAFFIC_SECRET_0 | %[ssl_xx_server_traffic_secret_0] EXPORTER_SECRET | %[ssl_xx_exporter_secret] EARLY_EXPORTER_SECRET | %[ssl_xx_early_exporter_secret] 这些获取存在于前端 (fc) 或后端 (bc) 侧，将“xx”替换为“fc”或“bc”以使用正确的侧。这仅适用于 OpenSSL 1.1.1，并且对 TLS1.3 会话有用。如果您想使用 TLS < 1.3 生成 SSLKEYLOGFILE 的内容，您只需此行：“CLIENT_RANDOM %[ssl_fc_client_random,hex] %[ssl_fc_session_key,hex]” 一个完整的密钥日志可以通过这种方式生成日志格式，尽管这对于 syslog 来说并不理想：log-format "CLIENT_EARLY_TRAFFIC_SECRET %[ssl_bc_client_random,hex] %[ssl_bc_client_early_traffic_secret]\n CLIENT_HANDSHAKE_TRAFFIC_SECRET %[ssl_bc_client_random,hex] %[ssl_bc_client_handshake_traffic_secret]\n SERVER_HANDSHAKE_TRAFFIC_SECRET %[ssl_bc_client_random,hex] %[ssl_bc_server_handshake_traffic_secret]\n CLIENT_TRAFFIC_SECRET_0 %[ssl_bc_client_random,hex] %[ssl_bc_client_traffic_secret_0]\n SERVER_TRAFFIC_SECRET_0 %[ssl_bc_client_random,hex] %[ssl_bc_server_traffic_secret_0]\n EXPORTER_SECRET %[ssl_bc_client_random,hex] %[ssl_bc_exporter_secret]\n EARLY_EXPORTER_SECRET %[ssl_bc_client_random,hex] %[ssl_bc_early_exporter_secret]"

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

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

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

设置连接或请求可以通过 "tcp-request" 或 "http-request" 规则中的 "track-sc*" 操作同时跟踪的粘性计数器（stick-counters）的数量。默认值在构建时由宏 MAX_SESS_STK_CTR 设置，默认为 3。使用此设置可以更改该值并忽略构建时传递的值。在将复杂配置移植到 HAProxy 时可能需要增加此值，但请用户注意其成本：每个条目每个连接占用 16 字节，每个请求占用 16 字节，所有这些都需要为所有请求分配和清零，即使未使用。因此，值为 10 将使每个请求的内存消耗增加 320 字节，并导致该内存在每个请求时都被擦除，这确实会对 CPU 产生可测量的影响。相反，当不使用 "track-sc" 规则时，可以降低该值（0 是有效的，可以完全禁用粘性计数器）。

默认情况下，我们不会尝试使用其他线程组的空闲连接。但是，这可以更改。<值> 的有效值为：“none”，默认值，如果使用，将不会尝试使用其他线程组的空闲连接；“restricted”，其中我们只有在使用无法创建新连接的协议（例如反向 http）以及使用 strict-maxconn 时才会尝试从另一个线程获取空闲连接；以及“full”，其中我们将始终在其他线程组中查找空闲连接。请注意，使用其他线程组的连接可能会产生性能损失，因此除非确实需要，否则不应使用。

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

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

为每个流设置窗口大小（历史缓冲区的大小）作为 zlib 初始化的参数。此参数的较大值会导致更好的压缩，但代价是内存使用量增加。可以是 8 到 15 之间的值。默认值为 15。

这将全局匿名化密钥设置为 <密钥>，它必须是一个介于 0 和 4294967295 之间的 32 位数字。这是启用匿名模式时 CLI 命令默认使用的密钥。此密钥也可以在运行时通过 CLI 命令“set anon global-key”设置。另请参阅管理手册中的命令行参数“-dC”。

启用（'on'）或禁用（'off'）代码中事件计数器的更新。这些是 CLI 命令“debug counters”中“CNT”类型下报告的计数器。这些计数器仅在代码构建时将 DEBUG_COUNTERS 设置为 1 或更高时可用。值为 1 时，默认不更新计数器（“debug.counters off”）；值为 2 时，默认更新计数器（“debug.counters on”）。通常没有理由更改此设置，除非开发人员要求，或者怀疑它消耗了异常多的 CPU（在这种情况下，需要向开发人员报告并附上计数器转储）。也可以在运行时使用“debug counters”CLI 命令更改此状态。请查阅管理手册。

此命令将配置解析器暂停 <timeout> 毫秒。这对于开发或测试 init 脚本的超时非常有用，特别是用于模拟非常长的重载。它需要设置 expose-experimental-directives。<timeout> 是默认以毫秒为单位指定的超时值，但如果数字后跟单位后缀，也可以是任何其他单位，如本文档开头所述。

global expose-experimental-directives force-cfg-parser-pause 10s

这通过跳过释放内存对象和侦听器来加快重载时旧进程的退出，因为所有这些都将在进程死亡时由操作系统回收。收益只是微不足道的（对于巨大的配置，最多也就几百毫秒）。实际上，主要目标用途是当在 deinit() 代码中发现错误时，因为它允许绕过它。除非开发人员指示，否则最好不要使用此选项。

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

这允许调整一个阻塞流量的卡住任务触发标准错误输出警告的延迟。延迟以毫秒表示，默认为 100 毫秒。允许的值必须在 1 毫秒到 1000 毫秒之间（含）。较低的值会频繁触发警告，而较高的值则很少触发。看门狗无论如何都会在运行失控任务两次未响应一秒钟后将其杀死，因此 1000 毫秒的警告延迟通常不会触发任何警告。建议将值保持在 10 毫秒到 100 毫秒之间，以检测可能降低用户体验、导致长时间响应或交互式会话卡顿的配置异常。例如，设计不良的 Lua 样本获取函数执行大量计算，或非常大的 map_reg 或 map_regm 映射文件具有非常高的评估成本，都可能导致此类问题。相比之下，一次 TLS 握手可能耗时 1 到 2 毫秒，压缩一个 16KB 的 HTTP 响应缓冲区大约需要 1 毫秒。输出包含违规任务的线程转储，其中包含回溯和一些上下文，有助于找出时间花费在哪里。

设置此选项后，如果在处理和应用配置时发出任何警告，HAProxy 将拒绝启动。这意味着有关参数组合不佳的警告、有关无法设置的非常高限制的警告等等，都会使进程在启动期间因错误而退出。此选项无法捕获一些较晚的启动警告，例如在“daemon”或“master-worker”模式下更改组 ID 时未能丢弃补充组，或者在 fork() 后未能将进程标记为可转储。此选项不捕获运行时发出的警告。强烈建议在不经常更改的配置上设置此选项，因为它有助于检测细微的错误并保持配置的整洁和向前兼容。请注意，“haproxy -c”在这种情况下也会报告错误。此选项等同于命令行参数“-dW”。

HTTPClient 是一个内部 HTTP 库，可供各种子系统使用，例如在 LUA 脚本中。HTTPClient 不用于数据路径，换句话说，它与通过 HAProxy 的 HTTP 流量无关。

禁用 httpclient 的 DNS 解析。阻止创建“default”解析器部分。默认值为 off。