HAProxy Configuration

HAProxy Configuration Manual

version 2.6
2022/09/22

Management Configuration 원래 문서

This document covers the configuration language as implemented in the version specified above. It does not provide any hints, examples, or advice. For such documentation, please refer to the Reference Manual or the Architecture Manual. The summary below is meant to help you find sections by name and navigate through the document.

Note to documentation contributors :
This document is formatted with 80 columns per line, with even number of spaces for indentation and without tabs. Please follow these rules strictly so that it remains easily printable everywhere. If a line needs to be printed verbatim and does not fit, please end each line with a backslash ('\') and continue on next line, indented by two characters. It is also sometimes useful to prefix all output lines (logs, console outputs) with 3 closing angle brackets ('>>>') in order to emphasize the difference between inputs and outputs when they may be ambiguous. If you add sections, please update the summary below for easier searching.

Summary

1. Quick reminder about HTTP
1.1. The HTTP transaction model
1.2. HTTP request
1.2.1. The request line
1.2.2. The request headers
1.3. HTTP response
1.3.1. The response line
1.3.2. The response headers
2. Configuring HAProxy
2.1. Configuration file format
2.2. Quoting and escaping
2.3. Environment variables
2.4. Conditional blocks
2.5. Time format
2.6. Examples
3. Global parameters
3.1. Process management and security
3.2. Performance tuning
3.3. Debugging
3.4. Userlists
3.5. Peers
3.6. Mailers
3.7. Programs
3.8. HTTP-errors
3.9. Rings
3.10. Log forwarding
4. Proxies
4.1. Proxy keywords matrix
4.2. Alphabetically sorted keywords reference
5. Bind and server options
5.1. Bind options
5.2. Server and default-server options
5.3. Server DNS resolution
5.3.1. Global overview
5.3.2. The resolvers section
6. Cache
6.1. Limitation
6.2. Setup
6.2.1. Cache section
6.2.2. Proxy section
7. Using ACLs and fetching samples
7.1. ACL basics
7.1.1. Matching booleans
7.1.2. Matching integers
7.1.3. Matching strings
7.1.4. Matching regular expressions (regexes)
7.1.5. Matching arbitrary data blocks
7.1.6. Matching IPv4 and IPv6 addresses
7.2. Using ACLs to form conditions
7.3. Fetching samples
7.3.1. Converters
7.3.2. Fetching samples from internal states
7.3.3. Fetching samples at Layer 4
7.3.4. Fetching samples at Layer 5
7.3.5. Fetching samples from buffer contents (Layer 6)
7.3.6. Fetching HTTP samples (Layer 7)
7.3.7. Fetching samples for developers
7.4. Pre-defined ACLs
8. Logging
8.1. Log levels
8.2. Log formats
8.2.1. Default log format
8.2.2. TCP log format
8.2.3. HTTP log format
8.2.4. HTTPS log format
8.2.5. Error log format
8.2.6. Custom log format
8.3. Advanced logging options
8.3.1. Disabling logging of external tests
8.3.2. Logging before waiting for the session to terminate
8.3.3. Raising log level upon errors
8.3.4. Disabling logging of successful connections
8.4. Timing events
8.5. Session state at disconnection
8.6. Non-printable characters
8.7. Capturing HTTP cookies
8.8. Capturing HTTP headers
8.9. Examples of logs
9. Supported filters
9.1. Trace
9.2. HTTP compression
9.3. Stream Processing Offload Engine (SPOE)
9.4. Cache
9.5. fcgi-app
9.6. OpenTracing
10. FastCGI applications
10.1. Setup
10.1.1. Fcgi-app section
10.1.2. Proxy section
10.1.3. Example
10.2. Default parameters
10.3. Limitations
11. Address formats
11.1. Address family prefixes
11.2. Socket type prefixes
11.3. Protocol prefixes

1. Quick reminder about HTTP

When HAProxy is running in HTTP mode, both the request and the response are
fully analyzed and indexed, thus it becomes possible to build matching criteria
on almost anything found in the contents.

However, it is important to understand how HTTP requests and responses are
formed, and how HAProxy decomposes them. It will then become easier to write
correct rules and to debug existing configurations.

HAProxy가 HTTP 모드에서 실행되면 요청과 응답이 모두 완전히 분석되고 인덱싱되므로 
콘텐츠에서 발견되는 거의 모든 항목에 대해 일치 기준을 구축할 수 있습니다.

그러나 HTTP 요청 및 응답이 형성되는 방식과 HAProxy가 이를 분해하는 방식을 이해하는 것이 
중요합니다. 그러면 올바른 규칙을 작성하고 기존 구성을 디버그하기가 더 쉬워집니다.

1.1. The HTTP transaction model

The HTTP protocol is transaction-driven. This means that each request will lead
to one and only one response. Traditionally, a TCP connection is established
from the client to the server, a request is sent by the client through the
connection, the server responds, and the connection is closed. A new request
will involve a new connection :

HTTP 프로토콜은 트랜잭션 기반입니다. 즉, 각 요청은 단 하나의 응답으로 이어집니다.
전통적으로 클라이언트에서 서버로 TCP 연결이 설정되고 연결을 통해 클라이언트가 요청을
보내고 서버가 응답하고 연결이 닫힙니다. 새 요청에는 새 연결이 포함됩니다.

[CON1] [REQ1] ... [RESP1] [CLO1] [CON2] [REQ2] ... [RESP2] [CLO2] ...

In this mode, called the "HTTP close" mode, there are as many connection
establishments as there are HTTP transactions. Since the connection is closed
by the server after the response, the client does not need to know the content
length.

"HTTP 닫기" 모드라고 하는 이 모드에는 HTTP 트랜잭션만큼 많은 연결 설정이 있습니다.
응답 후 서버에서 연결을 닫으므로 클라이언트는 콘텐츠 길이를 알 필요가 없습니다.

Due to the transactional nature of the protocol, it was possible to improve it
to avoid closing a connection between two subsequent transactions. In this mode
however, it is mandatory that the server indicates the content length for each
response so that the client does not wait indefinitely. For this, a special
header is used: "Content-length". This mode is called the "keep-alive" mode :

프로토콜의 트랜잭션 특성으로 인해 두 후속 트랜잭션 간의 연결이 닫히지 않도록
개선할 수 있었습니다. 그러나 이 모드에서는 클라이언트가 무한정 기다리지 않도록
서버가 각 응답에 대한 내용 길이를 표시하는 것이 필수입니다.
이를 위해 "Content-length"라는 특수 헤더가 사용됩니다.
이 모드를 "keep-alive" 모드라고 합니다.

[CON] [REQ1] ... [RESP1] [REQ2] ... [RESP2] [CLO] ...

Its advantages are a reduced latency between transactions, and less processing
power required on the server side. It is generally better than the close mode,
but not always because the clients often limit their concurrent connections to
a smaller value.

그 장점은 트랜잭션 간 대기 시간이 감소하고 서버 측에서 처리할 일이 준다는 것입니다.
일반적으로 닫기 모드보다 낫지만 클라이언트가 종종 동시 연결을 더 작은 값으로 제한하기
때문에 항상 그런 것은 아닙니다.

Another improvement in the communications is the pipelining mode. It still uses
keep-alive, but the client does not wait for the first response to send the
second request. This is useful for fetching large number of images composing a
page :

통신의 또 다른 개선 사항은 파이프라이닝 모드입니다. 여전히 keep-alive를 사용하지만
클라이언트는 두 번째 요청을 보내기 위해 첫 번째 응답을 기다리지 않습니다.
이는 페이지를 구성하는 많은 수의 이미지를 가져오는 데 유용합니다.

[CON] [REQ1] [REQ2] ... [RESP1] [RESP2] [CLO] ...

This can obviously have a tremendous benefit on performance because the network
latency is eliminated between subsequent requests. Many HTTP agents do not
correctly support pipelining since there is no way to associate a response with
the corresponding request in HTTP. For this reason, it is mandatory for the
server to reply in the exact same order as the requests were received.

후속 요청 사이에 네트워크 대기 시간이 제거되기 때문에 이는 분명히 성능에 엄청난 이점을
가질 수 있습니다. 많은 HTTP 에이전트는 응답을 HTTP의 해당 요청과 연결할 방법이 없기
때문에 파이프라이닝을 올바르게 지원하지 않습니다. 이러한 이유로 서버는 요청이 수신된 것과
정확히 동일한 순서로 응답해야 합니다.

The next improvement is the multiplexed mode, as implemented in HTTP/2 and HTTP/3.
This time, each transaction is assigned a single stream identifier, and all
streams are multiplexed over an existing connection. Many requests can be sent in
parallel by the client, and responses can arrive in any order since they also
carry the stream identifier.

다음 개선 사항은 HTTP/2 및 HTTP/3에서 구현된 다중화 모드입니다.
이번에는 각 트랜잭션에 단일 스트림 식별자가 할당되고 모든 스트림이 기존 연결을 통해 다중화됩니다.
많은 요청이 클라이언트에 의해 병렬로 전송될 수 있으며 응답도 스트림 식별자를 전달하므로
응답이 임의의 순서로 도착할 수 있습니다.

HTTP/3 is implemented over QUIC, itself implemented over UDP. QUIC solves the
head of line blocking at transport level by means of independently treated
streams. Indeed, when experiencing loss, an impacted stream does not affect the
other streams.

HTTP/3는 QUIC를 통해 구현되며 그 자체는 UDP를 통해 구현됩니다.
QUIC은 독립적으로 처리되는 스트림을 통해 전송 수준에서 HOL(head of line) 차단 문제를
해결합니다. 실제로 손실이 발생한 경우 영향을 받은 스트림은 다른 스트림에 영향을 미치지 않습니다.

By default HAProxy operates in keep-alive mode with regards to persistent
connections: for each connection it processes each request and response, and
leaves the connection idle on both sides between the end of a response and the
start of a new request. When it receives HTTP/2 connections from a client, it
processes all the requests in parallel and leaves the connection idling,
waiting for new requests, just as if it was a keep-alive HTTP connection.

기본적으로 HAProxy는 지속적인 연결과 관련하여 연결 유지 모드에서 작동합니다.
각 연결에 대해 각 요청과 응답을 처리하고 응답 종료와 새 요청 시작 사이의 양쪽에서
연결을 유휴 상태로 둡니다. 클라이언트로부터 HTTP/2 연결을 수신하면 모든 요청을 병렬로
처리하고 연결을 유휴 상태로 두고 마치 연결 유지 HTTP 연결인 것처럼 새 요청을 기다립니다.

HAProxy supports 4 connection modes :
- keep alive : all requests and responses are processed (default)
- tunnel : only the first request and response are processed,
everything else is forwarded with no analysis (deprecated).
- server close : the server-facing connection is closed after the response.
- close : the connection is actively closed after end of response.

HAProxy는 4가지 연결 모드를 지원합니다.
- keep alive: 모든 요청과 응답이 처리됨(기본값)
- tunnel: 첫 번째 요청과 응답만 처리,
다른 모든 것은 분석 없이 전달됩니다(더 이상 사용되지 않음).
- server close: 응답 후 서버 쪽 연결을 닫습니다.
- close: 응답 종료 후 능동적으로 연결을 닫는다.

1.2. HTTP request

First, let's consider this HTTP request :
먼저 다음 HTTP 요청을 살펴보겠습니다.

  Line     Contents
  number
     1     GET /serv/login.php?lang=en&profile=2 HTTP/1.1
     2     Host: www.mydomain.com
     3     User-agent: my small browser
     4     Accept: image/jpeg, image/gif
     5     Accept: image/png

1.2.1. The Request line

Line 1 is the "request line". It is always composed of 3 fields :
라인 1은 "요청 라인"입니다. 항상 3개의 필드로 구성됩니다.

- a METHOD : GET
- a URI : /serv/login.php?lang=en&profile=2
- a version tag : HTTP/1.1

All of them are delimited by what the standard calls LWS (linear white spaces),
which are commonly spaces, but can also be tabs or line feeds/carriage returns
followed by spaces/tabs. The method itself cannot contain any colon (':') and
is limited to alphabetic letters. All those various combinations make it
desirable that HAProxy performs the splitting itself rather than leaving it to
the user to write a complex or inaccurate regular expression.

이들 모두는 표준에서 호출하는 LWS(선형 공백)로 구분되며 일반적으로 공백이지만
탭 또는 줄 바꿈/캐리지 리턴 다음에 공백/탭이 올 수도 있습니다.
메서드 자체는 콜론(':')을 포함할 수 없으며 알파벳 문자로 제한됩니다.
이러한 모든 다양한 조합은 HAProxy가 복잡하거나 부정확한 정규식을 작성하도록
사용자에게 맡기지 않고 분할 자체를 수행하는 것이 바람직합니다.

The URI itself can have several forms :
URI 자체는 여러 형식을 가질 수 있습니다.

- A "relative URI" "상대적 URI" :

/serv/login.php?lang=en&profile=2

It is a complete URL without the host part. This is generally what is
received by servers, reverse proxies and transparent proxies.
호스트 부분이 없는 완전한 URL입니다. 이것은 일반적으로 서버, 리버스 프록시 및
투명 프록시에서 수신하는 것입니다.

- An "absolute URI", also called a "URL" "절대 URI" 또는 "URL":

http://192.168.0.12:8080/serv/login.php?lang=en&profile=2

It is composed of a "scheme" (the protocol name followed by '://'), a host
name or address, optionally a colon (':') followed by a port number, then
a relative URI beginning at the first slash ('/') after the address part.
This is generally what proxies receive, but a server supporting HTTP/1.1
must accept this form too.

이것은 "체계"(프로토콜 이름 뒤에 '://'가 옴), 호스트 이름 또는 주소, 선택적으로 콜론(':')과
포트 번호, ('/') 주소 부분 뒤에 첫 번째 슬래시에서 시작하는 상대 URI로 구성됩니다.
이것은 일반적으로 프록시가 받는 것이지만 HTTP/1.1을 지원하는 서버도 이 형식을 수락해야 합니다.

- a star ('*') : this form is only accepted in association with the OPTIONS
method and is not relayable. It is used to inquiry a next hop's
capabilities.
별표('*') : 이 형식은 OPTIONS 메서드와 관련해서만 허용되며 중계할 수 없습니다.
다음 홉의 기능을 조회하는 데 사용됩니다.

- an address:port combination : 192.168.0.12:80
This is used with the CONNECT method, which is used to establish TCP
tunnels through HTTP proxies, generally for HTTPS, but sometimes for
other protocols too.
주소:포트 조합 : 192.168.0.12:80
이는 일반적으로 HTTPS를 위해 HTTP 프록시를 통해 TCP 터널을 설정하는 데 사용되는
CONNECT 메서드와 함께 사용되지만 때로는 다른 프로토콜에서도 사용됩니다.

In a relative URI, two sub-parts are identified. The part before the question
mark is called the "path". It is typically the relative path to static objects
on the server. The part after the question mark is called the "query string".
It is mostly used with GET requests sent to dynamic scripts and is very
specific to the language, framework or application in use.

상대 URI에서 두 개의 하위 부분이 식별됩니다. 물음표 앞 부분을 "경로"라고 합니다.
일반적으로 서버의 정적 개체에 대한 상대 경로입니다.
물음표 뒤의 부분을 "쿼리 문자열"이라고 합니다.
주로 동적 스크립트로 전송되는 GET 요청과 함께 사용되며 사용 중인 언어, 프레임워크
또는 애플리케이션에 매우 구체적입니다.

HTTP/2 doesn't convey a version information with the request, so the version is
assumed to be the same as the one of the underlying protocol (i.e. "HTTP/2").

HTTP/2는 요청과 함께 버전 정보를 전달하지 않으므로 버전은 기본 프로토콜(예: "HTTP/2") 중
하나와 동일한 것으로 간주됩니다.

1.2.2. The request headers

The headers start at the second line. They are composed of a name at the
beginning of the line, immediately followed by a colon (':'). Traditionally,
an LWS is added after the colon but that's not required. Then come the values.
Multiple identical headers may be folded into one single line, delimiting the
values with commas, provided that their order is respected. This is commonly
encountered in the "Cookie:" field. A header may span over multiple lines if
the subsequent lines begin with an LWS. In the example in 1.2, lines 4 and 5
define a total of 3 values for the "Accept:" header.

헤더는 두 번째 줄에서 시작합니다. 행 시작 부분에 있는 이름과 바로 뒤에 콜론(':')이 오는
것으로 구성됩니다. 전통적으로 LWS는 콜론 뒤에 추가되지만 필수 사항은 아닙니다.
그런 다음 값을 가져옵니다. 여러 개의 동일한 헤더는 순서가 존중되는 경우 값을 쉼표로
구분하여 한 줄로 접을 수 있습니다. 이는 일반적으로 "쿠키:" 필드에서 발생합니다.
후속 라인이 LWS로 시작하는 경우 헤더가 여러 라인에 걸쳐 있을 수 있습니다.
1.2의 예에서 4행과 5행은 "Accept:" 헤더에 대해 총 3개의 값을 정의합니다.

Contrary to a common misconception, header names are not case-sensitive, and
their values are not either if they refer to other header names (such as the
"Connection:" header). In HTTP/2, header names are always sent in lower case,
as can be seen when running in debug mode. Internally, all header names are
normalized to lower case so that HTTP/1.x and HTTP/2 use the exact same
representation, and they are sent as-is on the other side. This explains why an
HTTP/1.x request typed with camel case is delivered in lower case.

일반적인 오해와 달리 헤더 이름은 대소문자를 구분하지 않으며 다른 헤더 이름
(예: "Connection:" 헤더)을 참조하는 경우 해당 값도 대소문자를 구분하지 않습니다.
HTTP/2에서 디버그 모드에서 실행할 때 볼 수 있듯이 헤더 이름은 항상 소문자로 전송됩니다.
내부적으로 모든 헤더 이름은 소문자로 정규화되어 HTTP/1.x 및 HTTP/2가 완전히 동일한 표현을
사용하고 다른 쪽에서 있는 그대로 전송됩니다. 이는 카멜 케이스로 입력된 HTTP/1.x 요청이
소문자로 전달되는 이유를 설명합니다.

The end of the headers is indicated by the first empty line. People often say
that it's a double line feed, which is not exact, even if a double line feed
is one valid form of empty line.

헤더의 끝은 첫 번째 빈 줄로 표시됩니다. 사람들은 종종 그것이 이중 줄 바꿈이라고 말하는데,
이는 이중 줄 바꿈이 유효한 빈 줄 형식 중 하나인 경우에도 정확하지 않습니다.

Fortunately, HAProxy takes care of all these complex combinations when indexing
headers, checking values and counting them, so there is no reason to worry
about the way they could be written, but it is important not to accuse an
application of being buggy if it does unusual, valid things.

다행스럽게도 HAProxy는 헤더를 인덱싱하고 값을 확인하고 계산할 때 이러한 모든 복잡한
조합을 처리하므로 작성 방법에 대해 걱정할 이유가 없지만, 응용 프로그램이 특이하지만
유효한 작업을 수행하는 경우 응용 프로그램이 버그가 있다고 비난하지 않는 것이 중요합니다.

Important note:
As suggested by RFC7231, HAProxy normalizes headers by replacing line breaks
in the middle of headers by LWS in order to join multi-line headers. This
is necessary for proper analysis and helps less capable HTTP parsers to work
correctly and not to be fooled by such complex constructs.

중요 사항:
RFC7231에서 제안한 대로 HAProxy는 여러 줄 헤더를 결합하기 위해 헤더 중간의 줄 바꿈을
LWS로 대체하여 헤더를 정규화합니다. 이는 적절한 분석을 위해 필요하며 기능이 부족한
HTTP 파서가 올바르게 작동하고 이러한 복잡한 구성에 속지 않도록 도와줍니다.

1.3. HTTP response

An HTTP response looks very much like an HTTP request. Both are called HTTP
messages. Let's consider this HTTP response :
HTTP 응답은 HTTP 요청과 매우 유사합니다. 둘 다 HTTP 메시지라고 합니다. 
다음 HTTP 응답을 살펴보겠습니다.

  Line     Contents
  number
     1     HTTP/1.1 200 OK
     2     Content-length: 350
     3     Content-Type: text/html

As a special case, HTTP supports so called "Informational responses" as status
codes 1xx. These messages are special in that they don't convey any part of the
response, they're just used as sort of a signaling message to ask a client to
continue to post its request for instance. In the case of a status 100 response
the requested information will be carried by the next non-100 response message
following the informational one. This implies that multiple responses may be
sent to a single request, and that this only works when keep-alive is enabled
(1xx messages are HTTP/1.1 only). HAProxy handles these messages and is able to
correctly forward and skip them, and only process the next non-100 response. As
such, these messages are neither logged nor transformed, unless explicitly
state otherwise. Status 101 messages indicate that the protocol is changing
over the same connection and that HAProxy must switch to tunnel mode, just as
if a CONNECT had occurred. Then the Upgrade header would contain additional
information about the type of protocol the connection is switching to.

특별한 경우로 HTTP는 소위 "정보 응답"을 상태 코드 1xx로 지원합니다.
이러한 메시지는 응답의 어떤 부분도 전달하지 않는다는 점에서 특별합니다.
예를 들어 요청을 계속 게시하도록 클라이언트에 요청하는 일종의 신호 메시지로 사용됩니다.
상태 100 응답의 경우 요청된 정보는 정보 메시지 다음의 100이 아닌 응답 메시지에 의해 전달됩니다.
이는 여러 응답이 단일 요청으로 전송될 수 있으며 연결 유지가 활성화된 경우에만 작동함을
의미합니다(1xx 메시지는 HTTP/1.1에만 해당).
HAProxy는 이러한 메시지를 처리하고 이를 올바르게 전달하고 건너뛸 수 있으며 100이 아닌
다음 응답만 처리할 수 있습니다. 따라서 이러한 메시지는 달리 명시되지 않는 한 기록되거나
변환되지 않습니다. 상태 101 메시지는 프로토콜이 동일한 연결을 통해 변경되고 있으며 마치
CONNECT가 발생한 것처럼 HAProxy가 터널 모드로 전환되어야 함을 나타냅니다.
그런 다음 업그레이드 헤더에는 연결이 전환되는 프로토콜 유형에 대한 추가 정보가 포함됩니다.

1.3.1. The response line

Line 1 is the "response line". It is always composed of 3 fields :
라인 1은 "응답 라인"입니다. 항상 3개의 필드로 구성됩니다.

  - a version tag : HTTP/1.1
  - a status code : 200
  - a reason      : OK

The status code is always 3-digit. The first digit indicates a general status :
 - 1xx = informational message to be skipped (e.g. 100, 101)
 - 2xx = OK, content is following   (e.g. 200, 206)
 - 3xx = OK, no content following   (e.g. 302, 304)
 - 4xx = error caused by the client (e.g. 401, 403, 404)
 - 5xx = error caused by the server (e.g. 500, 502, 503)

상태 코드는 항상 3자리입니다. 첫 번째 숫자는 일반적인 상태를 나타냅니다.
  - 1xx = 건너뛸 정보 메시지(예: 100, 101)
  - 2xx = OK, 다음 내용 있음(예: 200, 206)
  - 3xx = OK, 다음 내용 없음(예: 302, 304)
  - 4xx = 클라이언트로 인한 오류(예: 401, 403, 404)
  - 5xx = 서버로 인한 오류(예: 500, 502, 503)  
  
Please refer to RFC7231 for the detailed meaning of all such codes. The
"reason" field is just a hint, but is not parsed by clients. Anything can be
found there, but it's a common practice to respect the well-established
messages. It can be composed of one or multiple words, such as "OK", "Found",
or "Authentication Required".

이러한 모든 코드의 자세한 의미는 RFC7231을 참조하십시오. "이유" 필드는 힌트일 뿐 
클라이언트에서 구문 분석되지 않습니다. 거기에서 무엇이든 찾을 수 있지만 잘 정립된 
메시지를 존중하는 것이 일반적인 관행입니다. 
"OK", "Found" 또는 "Authentication Required"와 같이 하나 이상의 단어로 구성될 수 있습니다.

HAProxy may emit the following status codes by itself :
HAProxy는 자체적으로 다음 상태 코드를 내보낼 수 있습니다.

  Code  When / reason
   200  access to stats page, and when replying to monitoring requests
        통계 페이지에 대한 액세스 및 모니터링 요청에 회신할 때
   301  when performing a redirection, depending on the configured code
        구성된 코드에 따라 리디렉션을 수행할 때
   302  when performing a redirection, depending on the configured code
   303  when performing a redirection, depending on the configured code
   307  when performing a redirection, depending on the configured code
   308  when performing a redirection, depending on the configured code
   400  for an invalid or too large request
        유효하지 않거나 너무 큰 요청
   401  when an authentication is required to perform the action (when
        accessing the stats page)
        작업을 수행하기 위해 인증이 필요한 경우(통계 페이지에 액세스할 때)
   403  when a request is forbidden by a "http-request deny" rule
        요청이 "http 요청 거부" 규칙에 의해 금지된 경우
   404  when the requested resource could not be found
        요청한 리소스를 찾을 수 없을 때
   408  when the request timeout strikes before the request is complete
        요청이 완료되기 전에 요청 시간 초과가 발생한 경우
   410  when the requested resource is no longer available and will not
        be available again
		요청한 리소스를 더 이상 사용할 수 없고 다시 사용할 수 없을 때
   500  when HAProxy encounters an unrecoverable internal error, such as a
        memory allocation failure, which should never happen
        HAProxy가 절대 발생해서는 안 되는 메모리 할당 실패와 같은 복구할 수 없는 
        내부 오류를 만났을 때
   501 when HAProxy is unable to satisfy a client request because of an
       unsupported feature
       지원되지 않는 기능으로 인해 HAProxy가 클라이언트 요청을 충족할 수 없는 경우
   502  when the server returns an empty, invalid or incomplete response, or
        when an "http-response deny" rule blocks the response.
       서버가 비어 있거나 유효하지 않거나 불완전한 응답을 반환하거나 "http 응답 거부" 
       규칙이 응답을 차단하는 경우.
   503  when no server was available to handle the request, or in response to
        monitoring requests which match the "monitor fail" condition
        요청을 처리할 수 있는 서버가 없거나 "모니터 실패" 조건과 일치하는 모니터링 요청에 
        대한 응답으로
   504  when the response timeout strikes before the server responds
        서버가 응답하기 전에 응답 시간 초과가 발생한 경우

The error 4xx and 5xx codes above may be customized (see "errorloc" in section 4.2).
위의 오류 4xx 및 5xx 코드는 사용자 정의할 수 있습니다(섹션 4.2의 "errorloc" 참조).

1.3.2. The response headers

Response headers work exactly like request headers, and as such, HAProxy uses the same parsing function for both. Please refer to paragraph 1.2.2 for more details.
응답 헤더는 요청 헤더와 똑같이 작동하므로 HAProxy는 둘 다에 대해 동일한 구문 분석 기능을 사용합니다. 자세한 내용은 단락 1.2.2를 참조하십시오.

2. Configuring HAProxy

2.1. Configuration file format

HAProxy's configuration process involves 3 major sources of parameters :
HAProxy의 구성 프로세스에는 3가지 주요 매개변수 소스가 포함됩니다.

the arguments from the command-line, which always take precedence
항상 우선하는 명령줄의 인수
the configuration file(s), whose format is described here
형식이 여기에 설명된 구성 파일
the running process's environment, in case some environment variables are explicitly referenced
실행 중인 프로세스의 환경(일부 환경 변수가 명시적으로 참조되는 경우)

The configuration file follows a fairly simple hierarchical format which obey a few basic rules:
구성 파일은 몇 가지 기본 규칙을 준수하는 매우 간단한 계층 형식을 따릅니다.

1. a configuration file is an ordered sequence of statements
구성 파일은 명령문의 순서가 지정된 시퀀스입니다.
2. a statement is a single non-empty line before any unprotected "#" (hash)
명령문은 보호되지 않은 "#"(해시) 앞에 있는 비어 있지 않은 단일 행입니다.
3. a line is a series of tokens or "words" delimited by unprotected spaces or tab characters
줄은 보호되지 않은 공백이나 탭 문자로 구분된 일련의 토큰 또는 "단어"입니다.
4. the first word or sequence of words of a line is one of the keywords or keyword sequences listed in this document
줄의 첫 번째 단어 또는 일련의 단어는 이 문서에 나열된 키워드 또는 키워드 시퀀스 중 하나입니다.
5. all other words are all arguments of the first one, some being well-known keywords listed in this document, others being values, references to other parts of the configuration, or expressions
다른 모든 단어는 첫 번째 단어의 모든 인수이며 일부는 이 문서에 나열된 잘 알려진 키워드이고 다른 일부는 값, 구성의 다른 부분에 대한 참조 또는 표현식입니다.
6. certain keywords delimit a section inside which only a subset of keywords are supported
특정 키워드는 키워드의 하위 집합만 지원되는 섹션을 구분합니다.
7. a section ends at the end of a file or on a special keyword starting a new section
섹션은 파일의 끝에서 끝나거나 새 섹션을 시작하는 특수 키워드에서 끝납니다.

This is all that is needed to know to write a simple but reliable configuration generator, but this is not enough to reliably parse any configuration nor to figure how to deal with certain corner cases.
이것은 간단하지만 신뢰할 수 있는 구성 생성기를 작성하기 위해 알아야 할 전부이지만 구성을 안정적으로 구문 분석하거나 특정 코너 케이스를 처리하는 방법을 파악하기에는 충분하지 않습니다.

First, there are a few consequences of the rules above. Rule 6 and 7 imply that the keywords used to define a new section are valid everywhere and cannot have a different meaning in a specific section. These keywords are always a single word (as opposed to a sequence of words), and traditionally the section that follows them is designated using the same name. For example when speaking about the "global section", it designates the section of configuration that follows the "global" keyword. This usage is used a lot in error messages to help locate the parts that need to be addressed.

첫째, 위의 규칙에는 몇 가지 결과가 있습니다. 규칙 6과 7은 새 섹션을 정의하는 데 사용되는 키워드가 모든 곳에서 유효하며 특정 섹션에서 다른 의미를 가질 수 없음을 의미합니다. 이러한 키워드는 항상 단일 단어(단어 시퀀스가 아님)이며 일반적으로 키워드 뒤에 오는 섹션은 동일한 이름을 사용하여 지정됩니다. 예를 들어 "global section"에 대해 말할 때 "global" 키워드 다음에 오는 구성 섹션을 지정합니다. 이 사용법은 해결해야 할 부분을 찾는 데 도움이 되는 오류 메시지에서 많이 사용됩니다.

A number of sections create an internal object or configuration space, which requires to be distinguished from other ones. In this case they will take an extra word which will set the name of this particular section. For some of them the section name is mandatory. For example "frontend foo" will create a new section of type "frontend" named "foo". Usually a name is specific to its section and two sections of different types may use the same name, but this is not recommended as it tends to complexify configuration management.

많은 섹션이 다른 것과 구별되어야 하는 내부 개체 또는 구성 공간을 만듭니다. 이 경우 이 특정 섹션의 이름을 설정할 추가 단어를 사용합니다. 그들 중 일부는 섹션 이름이 필수입니다. 예를 들어 "frontend foo"는 "foo"라는 이름의 "frontend" 유형의 새 섹션을 생성합니다. 일반적으로 이름은 해당 섹션에 고유하며 유형이 다른 두 섹션이 동일한 이름을 사용할 수 있지만 구성 관리가 복잡해지는 경향이 있으므로 권장되지 않습니다.

A direct consequence of rule 7 is that when multiple files are read at once, each of them must start with a new section, and the end of each file will end a section. A file cannot contain sub-sections nor end an existing section and start a new one.
규칙 7의 직접적인 결과는 여러 파일을 한 번에 읽을 때 각 파일이 새 섹션으로 시작해야 하며 각 파일의 끝에서 섹션이 종료된다는 것입니다. 파일은 하위 섹션을 포함하거나 기존 섹션을 끝내고 새 섹션을 시작할 수 없습니다.

Rule 1 mentioned that ordering matters. Indeed, some keywords create directives that can be repeated multiple times to create ordered sequences of rules to be applied in a certain order. For example "tcp-request" can be used to alternate "accept" and "reject" rules on varying criteria. As such, a configuration file processor must always preserve a section's ordering when editing a file. The ordering of sections usually does not matter except for the global section which must be placed before other sections, but it may be repeated if needed. In addition, some automatic identifiers may automatically be assigned to some of the created objects (e.g. proxies), and by reordering sections, their identifiers will change. These ones appear in the statistics for example. As such, the configuration below will assign "foo" ID number 1 and "bar" ID number 2, which will be swapped if the two sections are reversed:

규칙 1은 순서가 중요하다고 언급했습니다. 실제로 일부 키워드는 특정 순서로 적용할 순서가 지정된 규칙 시퀀스를 만들기 위해 여러 번 반복할 수 있는 지시문을 만듭니다. 예를 들어 "tcp-request"는 다양한 기준에서 "accept 수락" 및 "reject 거부" 규칙을 번갈아 사용하는 데 사용할 수 있습니다. 따라서 구성 파일 프로세서는 파일을 편집할 때 항상 섹션의 순서를 유지해야 합니다. 섹션의 순서는 일반적으로 다른 섹션 앞에 배치되어야 하는 전역 섹션을 제외하고는 중요하지 않지만 필요한 경우 반복될 수 있습니다. 또한 일부 자동 식별자는 생성된 일부 개체(예: 프록시)에 자동으로 할당될 수 있으며 섹션을 재정렬하면 해당 식별자가 변경됩니다. 예를 들어 이러한 것들은 통계에 나타납니다. 따라서 아래 구성은 "foo" ID 번호 1과 "bar" ID 번호 2를 할당하며 두 섹션이 뒤바뀐 경우 교체됩니다.

     listen foo
         bind :80

     listen bar
         bind :81

Another important point is that according to rules 2 and 3 above, empty lines, spaces, tabs, and comments following and unprotected "#" character are not part of the configuration as they are just used as delimiters. This implies that the following configurations are strictly equivalent:
또 다른 중요한 점은 위의 규칙 2와 3에 따라 보호되지 않은 "#" 문자 뒤에 오는 빈 줄, 공백, 탭 및 주석은 구분 기호로 사용되기 때문에 구성의 일부가 아니라는 것입니다. 이는 다음 구성이 완전히 동일함을 의미합니다.

         global#this is the global section
     daemon#daemonize
         frontend         foo
     mode             http   # or tcp

and:

     global
         daemon

     # this is the public web frontend
     frontend foo
         mode http

The common practice is to align to the left only the keyword that initiates a new section, and indent (i.e. prepend a tab character or a few spaces) all other keywords so that it's instantly visible that they belong to the same section (as done in the second example above). Placing comments before a new section helps the reader decide if it's the desired one. Leaving a blank line at the end of a section also visually helps spotting the end when editing it.

일반적인 관행은 새 섹션을 시작하는 키워드만 왼쪽에 정렬하고 다른 모든 키워드는 들여쓰기(예: 탭 문자 또는 몇 개의 공백 추가)하여 동일한 섹션에 속한다는 것을 즉시 볼 수 있도록 하는 것입니다(예: 위의 두 번째 예). 새 섹션 앞에 주석을 배치하면 독자가 원하는 섹션인지 판단하는 데 도움이 됩니다. 섹션 끝에 빈 줄을 두는 것도 편집할 때 시각적으로 끝 부분을 찾는 데 도움이 됩니다.

Tabs are very convenient for indent but they do not copy-paste well. If spaces are used instead, it is recommended to avoid placing too many (2 to 4) so that editing in field doesn't become a burden with limited editors that do not support automatic indent.
탭은 들여쓰기에 매우 편리하지만 복사-붙여넣기가 잘 되지 않습니다. 공백을 대신 사용하는 경우 자동 들여쓰기를 지원하지 않는 제한된 편집기로 필드에서 편집하는 것이 부담이 되지 않도록 너무 많이(2~4개) 배치하지 않는 것이 좋습니다.

In the early days it used to be common to see arguments split at fixed tab positions because most keywords would not take more than two arguments. With modern versions featuring complex expressions this practice does not stand anymore, and is not recommended.
초기에는 대부분의 키워드가 두 개 이상의 인수를 사용하지 않기 때문에 고정된 탭 위치에서 인수가 분할되는 것을 보는 것이 일반적이었습니다. 복잡한 표현을 특징으로 하는 최신 버전에서는 이 관행이 더 이상 유효하지 않으며 권장되지 않습니다.

2.2. Quoting and escaping

In modern configurations, some arguments require the use of some characters that were previously considered as pure delimiters. In order to make this possible, HAProxy supports character escaping by prepending a backslash ('\') in front of the character to be escaped, weak quoting within double quotes ('"') and strong quoting within single quotes ("'").

최신 구성에서 일부 인수는 이전에 순수한 구분 기호로 간주되었던 일부 문자를 사용해야 합니다. 이를 가능하게 하기 위해 HAProxy는 이스케이프할 문자 앞에 백슬래시('\')를 추가하여 문자 이스케이프를 지원하고 큰따옴표('"') 안에는 약한 따옴표를, 작은따옴표("'") 안에는 강한 따옴표를 사용합니다.

This is pretty similar to what is done in a number of programming languages and very close to what is commonly encountered in Bourne shell. The principle is the following: while the configuration parser cuts the lines into words, it also takes care of quotes and backslashes to decide whether a character is a delimiter or is the raw representation of this character within the current word. The escape character is then removed, the quotes are removed, and the remaining word is used as-is as a keyword or argument for example.

이는 여러 프로그래밍 언어에서 수행되는 작업과 매우 유사하며 Bourne 셸에서 일반적으로 발생하는 작업과 매우 유사합니다. 원칙은 다음과 같습니다. 구성 파서가 줄을 단어로 자르는 동안 문자가 구분 기호인지 또는 현재 단어 내에서 이 문자의 원시 표현인지 결정하기 위해 따옴표와 백슬래시도 처리합니다. 그런 다음 이스케이프 문자가 제거되고 따옴표가 제거되며 나머지 단어는 예를 들어 키워드 또는 인수로 그대로 사용됩니다.

If a backslash is needed in a word, it must either be escaped using itself (i.e. double backslash) or be strongly quoted.
단어에 백슬래시가 필요한 경우 자체를 사용하여 이스케이프 처리(예: 이중 백슬래시)하거나 강하게 인용해야 합니다.

Escaping outside quotes is achieved by preceding a special character by a backslash ('\'):
외부 따옴표를 이스케이프 처리하려면 특수 문자 앞에 백슬래시('\')를 붙여야 합니다.

  \    to mark a space and differentiate it from a delimiter
  \#   to mark a hash and differentiate it from a comment
  \\   to use a backslash
  \'   to use a single quote and differentiate it from strong quoting
  \"   to use a double quote and differentiate it from weak quoting

In addition, a few non-printable characters may be emitted using their usual C-language representation:
또한 인쇄할 수 없는 몇 가지 문자는 일반적인 C 언어 표현을 사용하여 내보낼 수 있습니다.

  \n   to insert a line feed (LF, character \x0a or ASCII 10 decimal)
  \r   to insert a carriage return (CR, character \x0d or ASCII 13 decimal)
  \t   to insert a tab (character \x09 or ASCII 9 decimal)
  \xNN to insert character having ASCII code hex NN (e.g \x0a for LF).

Weak quoting is achieved by surrounding double quotes ("") around the character or sequence of characters to protect. Weak quoting prevents the interpretation of:
보호할 문자 또는 일련의 문자를 큰따옴표("")로 둘러싸면 약한 인용부호를 사용할 수 있습니다. 약한 인용은 다음의 해석을 방지합니다.

       space or tab as a word separator
  '    single quote as a strong quoting delimiter
  #    hash as a comment start

Weak quoting permits the interpretation of environment variables (which are not evaluated outside of quotes) by preceding them with a dollar sign ('$'). If a dollar character is needed inside double quotes, it must be escaped using a backslash.
약한 따옴표는 앞에 달러 기호('$')를 추가하여 환경 변수(따옴표 외부에서 평가되지 않음)를 해석할 수 있도록 합니다. 큰따옴표 안에 달러 문자가 필요한 경우 백슬래시를 사용하여 이스케이프 처리해야 합니다.

Strong quoting is achieved by surrounding single quotes ('') around the character or sequence of characters to protect. Inside single quotes, nothing is interpreted, it's the efficient way to quote regular expressions.
보호할 문자 또는 일련의 문자를 작은따옴표('')로 둘러싸면 강한 인용부호를 사용할 수 있습니다. 작은따옴표 안에는 아무 것도 해석되지 않으며 정규 표현식을 인용하는 효율적인 방법입니다.

As a result, here is the matrix indicating how special characters can be entered in different contexts (unprintable characters are replaced with their name within angle brackets). Note that some characters that may only be represented escaped have no possible representation inside single quotes, hence the '-' there:

그 결과, 다양한 상황에서 특수 문자를 입력할 수 있는 방법을 나타내는 매트릭스가 있습니다(인쇄할 수 없는 문자는 꺾쇠 괄호 안에 이름으로 대체됨). 이스케이프 처리로만 표시될 수 있는 일부 문자는 작은따옴표 안에는 표시가 불가능하므로 '-'가 있습니다.

  Character  |  Unquoted     |  Weakly quoted              |  Strongly quoted
  -----------+---------------+-----------------------------+-----------------
    <TAB>    |  \<TAB>, \x09 |  "<TAB>", "\<TAB>", "\x09"  |  '<TAB>'
    <LF>     |  \n, \x0a     |  "\n", "\x0a"               |   -
    <CR>     |  \r, \x0d     |  "\r", "\x0d"               |   -
    <SPC>    |  \<SPC>, \x20 |  "<SPC>", "\<SPC>", "\x20"  |  '<SPC>'
    "        |  \", \x22     |  "\"", "\x22"               |  '"'
    #        |  \#, \x23     |  "#", "\#", "\x23"          |  '#'
    $        |  $, \$, \x24  |  "\$", "\x24"               |  '$'
    '        |  \', \x27     |  "'", "\'", "\x27"          |   -
    \        |  \\, \x5c     |  "\\", "\x5c"               |  '\'

  Example:
      # those are all strictly equivalent:
      log-format %{+Q}o\ %t\ %s\ %{-Q}r
      log-format "%{+Q}o %t %s %{-Q}r"
      log-format '%{+Q}o %t %s %{-Q}r'
      log-format "%{+Q}o %t"' %s %{-Q}r'
      log-format "%{+Q}o %t"' %s'\ %{-Q}r

There is one particular case where a second level of quoting or escaping may be necessary. Some keywords take arguments within parenthesis, sometimes delimited by commas. These arguments are commonly integers or predefined words, but when they are arbitrary strings, it may be required to perform a separate level of escaping to disambiguate the characters that belong to the argument from the characters that are used to delimit the arguments themselves. A pretty common case is the "regsub" converter. It takes a regular expression in argument, and if a closing parenthesis is needed inside, this one will require to have its own quotes.

두 번째 수준의 인용 또는 이스케이프가 필요할 수 있는 특별한 경우가 있습니다. 일부 키워드는 괄호 안에 인수를 사용하며 경우에 따라 쉼표로 구분됩니다. 이러한 인수는 일반적으로 정수 또는 미리 정의된 단어이지만 임의의 문자열인 경우 인수 자체를 구분하는 데 사용되는 문자에서 인수에 속하는 문자를 명확하게 구분하기 위해 별도의 이스케이프 수준을 수행해야 할 수 있습니다. 매우 일반적인 경우는 "regsub" 변환기입니다. 인수에 정규식을 사용하며 내부에 닫는 괄호가 필요한 경우 자체 따옴표가 있어야 합니다.

The keyword argument parser is exactly the same as the top-level one regarding quotes, except that the \#, \$, and \xNN escapes are not processed. But what is not always obvious is that the delimiters used inside must first be escaped or quoted so that they are not resolved at the top level.

키워드 인수 구문 분석기는 \#, \$ 및 \xNN 이스케이프가 처리되지 않는다는 점을 제외하면 따옴표에 관한 최상위 수준 구문 분석기와 정확히 동일합니다. 그러나 항상 명확하지 않은 것은 내부에 사용된 구분 기호가 최상위 수준에서 해결되지 않도록 먼저 이스케이프되거나 인용되어야 한다는 것입니다.

Let's take this example making use of the "regsub" converter which takes 3 arguments, one regular expression, one replacement string and one set of flags:
3개의 인수, 하나의 정규식, 하나의 대체 문자열 및 하나의 플래그 세트를 사용하는 "regsub" 변환기를 사용하는 이 예제를 살펴보겠습니다.

    # replace all occurrences of "foo" with "blah" in the path:
    http-request set-path %[path,regsub(foo,blah,g)]

Here no special quoting was necessary. But if now we want to replace either "foo" or "bar" with "blah", we'll need the regular expression "(foo|bar)". We cannot write:
여기에는 특별한 인용이 필요하지 않았습니다. 그러나 이제 "foo" 또는 "bar"를 "blah"로 바꾸려면 정규식 "(foo|bar)"가 필요합니다. 우리는 다음과 같이 쓸 수 없습니다:

    http-request set-path %[path,regsub((foo|bar),blah,g)]

because we would like the string to cut like this:
문자열을 다음과 같이 자르고 싶기 때문입니다.

    http-request set-path %[path,regsub((foo|bar),blah,g)]
                                       |---------|----|-|
                                 arg1 _/         /    /
                                 arg2 __________/    /
                                 arg3 ______________/

but actually what is passed is a string between the opening and closing parenthesis then garbage:
그러나 실제로 전달되는 것은 여는 괄호와 닫는 괄호 사이의 문자열이고 쓰레기입니다.

    http-request set-path %[path,regsub((foo|bar),blah,g)]
                                       |--------|--------|
                        arg1=(foo|bar _/        /
                    trailing garbage  _________/

The obvious solution here seems to be that the closing parenthesis needs to be quoted, but alone this will not work, because as mentioned above, quotes are processed by the top-level parser which will resolve them before processing this word:
여기서 확실한 해결책은 닫는 괄호를 인용해야 한다는 것 같지만 이것만으로는 작동하지 않습니다. 위에서 언급한 것처럼 인용은 다음 단어를 처리하기 전에 해결하는 최상위 파서에서 처리되기 때문입니다.

    http-request set-path %[path,regsub("(foo|bar)",blah,g)]
    ------------ -------- ----------------------------------
       word1       word2    word3=%[path,regsub((foo|bar),blah,g)]

So we didn't change anything for the argument parser at the second level which still sees a truncated regular expression as the only argument, and garbage at the end of the string. By escaping the quotes they will be passed unmodified to the second level:
그래서 우리는 여전히 잘린 정규식을 유일한 인수로 보고 문자열의 끝에서 쓰레기를 보는 두 번째 수준의 인수 파서에 대해 아무 것도 변경하지 않았습니다. 따옴표를 이스케이프 처리하면 수정되지 않은 상태로 두 번째 수준으로 전달됩니다.

    http-request set-path %[path,regsub(\"(foo|bar)\",blah,g)]
    ------------ -------- ------------------------------------
       word1       word2    word3=%[path,regsub("(foo|bar)",blah,g)]
                                                |---------||----|-|
                                arg1=(foo|bar) _/          /    /
                                    arg2=blah  ___________/    /
                                        arg3=g _______________/

Another approach consists in using single quotes outside the whole string and double quotes inside (so that the double quotes are not stripped again):
또 다른 접근 방식은 전체 문자열 외부에 작은따옴표를 사용하고 내부에 큰따옴표를 사용하는 것입니다(큰따옴표가 다시 제거되지 않도록).

    http-request set-path '%[path,regsub("(foo|bar)",blah,g)]'
    ------------ --------  ----------------------------------
       word1       word2    word3=%[path,regsub("(foo|bar)",blah,g)]
                                                |---------||----|-|
                                arg1=(foo|bar) _/          /    /
                                          arg2 ___________/    /
                                          arg3 _______________/

When using regular expressions, it can happen that the dollar ('$') character appears in the expression or that a backslash ('\') is used in the replacement string. In this case these ones will also be processed inside the double quotes thus single quotes are preferred (or double escaping). Example:

정규 표현식을 사용할 때 달러('$') 문자가 표현식에 나타나거나 백슬래시('\')가 대체 문자열에 사용되는 경우가 발생할 수 있습니다. 이 경우 이러한 것들은 큰따옴표 안에서도 처리되므로 작은따옴표가 선호됩니다 (또는 이중 이스케이프). 예:

    http-request set-path '%[path,regsub("^/(here)(/|$)","my/\1",g)]'
    ------------ --------  -----------------------------------------
       word1       word2    word3=%[path,regsub("^/(here)(/|$)","my/\1",g)]
                                                |-------------| |-----||-|
                              arg1=(here)(/|$) _/               /      /
                                    arg2=my/\1 ________________/      /
                                          arg3 ______________________/

Remember that backslashes are not escape characters within single quotes and that the whole word above is already protected against them using the single quotes. Conversely, if double quotes had been used around the whole expression, single the dollar character and the backslashes would have been resolved at top level, breaking the argument contents at the second level.

백슬래시는 작은따옴표 안에 있는 이스케이프 문자가 아니며 위의 전체 단어는 이미 작은따옴표를 사용하여 백슬래시로부터 보호되고 있음을 기억하십시오. 반대로 전체 식 주위에 큰따옴표가 사용된 경우 단일 달러 문자와 백슬래시는 최상위 수준에서 해결되어 두 번째 수준에서 인수 내용이 중단됩니다.

Unfortunately, since single quotes can't be escaped inside of strong quoting, if you need to include single quotes in your argument, you will need to escape or quote them twice. There are a few ways to do this:
불행하게도 작은 따옴표는 강한 인용부호 내에서 이스케이프 처리할 수 없으므로 인수에 작은 따옴표를 포함해야 하는 경우 두 번 이스케이프하거나 인용해야 합니다. 이를 수행하는 몇 가지 방법이 있습니다.

    http-request set-var(txn.foo) str("\\'foo\\'")
    http-request set-var(txn.foo) str(\"\'foo\'\")
    http-request set-var(txn.foo) str(\\\'foo\\\')

When in doubt, simply do not use quotes anywhere, and start to place single or double quotes around arguments that require a comma or a closing parenthesis, and think about escaping these quotes using a backslash if the string contains a dollar or a backslash. Again, this is pretty similar to what is used under a Bourne shell when double-escaping a command passed to "eval". For API writers the best is probably to place escaped quotes around each and every argument, regardless of their contents. Users will probably find that using single quotes around the whole expression and double quotes around each argument provides more readable configurations.

확실하지 않은 경우 아무 데나 따옴표를 사용하지 말고 쉼표나 닫는 괄호가 필요한 인수 주위에 작은따옴표나 큰따옴표를 넣기 시작하고 문자열에 달러나 백슬래시가 포함된 경우 백슬래시를 사용하여 이러한 따옴표를 이스케이프 처리하는 방법을 고려하십시오. 다시 말하지만 이것은 "eval"로 전달된 명령을 이중 이스케이프할 때 Bourne 쉘에서 사용되는 것과 매우 유사합니다. API 작성자의 경우 내용에 관계없이 각 인수 주위에 이스케이프된 인용 부호를 배치하는 것이 가장 좋습니다. 사용자는 아마도 전체 식 주위에 작은따옴표를 사용하고 각 인수 주위에 큰따옴표를 사용하면 더 읽기 쉬운 구성을 제공한다는 것을 알게 될 것입니다.

2.3. Environment variables

HAProxy's configuration supports environment variables. Those variables are interpreted only within double quotes. Variables are expanded during the configuration parsing. Variable names must be preceded by a dollar ("$") and optionally enclosed with braces ("{}") similarly to what is done in Bourne shell. Variable names can contain alphanumerical characters or the character underscore ("_") but should not start with a digit. If the variable contains a list of several values separated by spaces, it can be expanded as individual arguments by enclosing the variable with braces and appending the suffix '[*]' before the closing brace. It is also possible to specify a default value to use when the variable is not set, by appending that value after a dash '-' next to the variable name. Note that the default value only replaces non existing variables, not empty ones.

HAProxy의 구성은 환경 변수를 지원합니다. 이러한 변수는 큰따옴표 내에서만 해석됩니다. 변수는 구성 구문 분석 중에 확장됩니다. 변수 이름 앞에는 달러("$")가 와야 하며 선택적으로 Bourne 셸에서 수행되는 것과 유사하게 중괄호("{}")로 둘러싸야 합니다. 변수 이름에는 영숫자 문자 또는 문자 밑줄("_")이 포함될 수 있지만 숫자로 시작해서는 안 됩니다. 변수에 공백으로 구분된 여러 값 목록이 포함된 경우 변수를 중괄호로 묶고 닫는 중괄호 앞에 접미사 '[*]'를 추가하여 개별 인수로 확장할 수 있습니다. 변수 이름 옆에 대시 '-' 뒤에 해당 값을 추가하여 변수가 설정되지 않은 경우 사용할 기본값을 지정할 수도 있습니다. 기본값은 비어 있는 변수가 아니라 존재하지 않는 변수만 대체합니다.

  Example:

      bind "fd@${FD_APP1}"

      log "${LOCAL_SYSLOG-127.0.0.1}:514" local0 notice  # send to local server

      user "$HAPROXY_USER"

Some variables are defined by HAProxy, they can be used in the configuration file, or could be inherited by a program (See 3.7. Programs):
일부 변수는 HAProxy에 의해 정의되며 구성 파일에서 사용하거나 프로그램에서 상속할 수 있습니다(3.7. 프로그램 참조).

HAPROXY_LOCALPEER: defined at the startup of the process which contains the name of the local peer. (See "-L" in the management guide.)
HAPROXY_LOCALPEER: 로컬 피어의 이름을 포함하는 프로세스 시작 시 정의됩니다. (관리 가이드의 "-L"을 참조하십시오.)
HAPROXY_CFGFILES: list of the configuration files loaded by HAProxy, separated by semicolons. Can be useful in the case you specified a directory.
HAPROXY_CFGFILES: 세미콜론으로 구분된 HAProxy에 의해 로드된 구성 파일 목록입니다. 디렉토리를 지정한 경우에 유용할 수 있습니다.
HAPROXY_MWORKER: In master-worker mode, this variable is set to 1.
HAPROXY_MWORKER: 마스터-작업자 모드에서 이 변수는 1로 설정됩니다.
HAPROXY_CLI: configured listeners addresses of the stats socket for every processes, separated by semicolons.
HAPROXY_CLI: 세미콜론으로 구분된 모든 프로세스에 대한 통계 소켓의 구성된 수신기 주소입니다.
HAPROXY_MASTER_CLI: In master-worker mode, listeners addresses of the master CLI, separated by semicolons.
HAPROXY_MASTER_CLI: 마스터-작업자 모드에서 세미콜론으로 구분된 마스터 CLI의 리스너 주소입니다.

In addition, some pseudo-variables are internally resolved and may be used as regular variables. Pseudo-variables always start with a dot ('.'), and are the only ones where the dot is permitted. The current list of pseudo-variables is:
또한 일부 의사 변수는 내부적으로 해결되어 일반 변수로 사용될 수 있습니다. 의사 변수는 항상 점('.')으로 시작하며 점이 허용되는 유일한 변수입니다. 의사 변수의 현재 목록은 다음과 같습니다.

.FILE: the name of the configuration file currently being parsed.
.FILE: 현재 구문 분석 중인 구성 파일의 이름입니다.
.LINE: the line number of the configuration file currently being parsed, starting at one.
.LINE: 현재 구문 분석 중인 구성 파일의 줄 번호(1부터 시작).
.SECTION: the name of the section currently being parsed, or its type if the section doesn't have a name (e.g. "global"), or an empty string before the first section.
.SECTION: 현재 구문 분석 중인 섹션의 이름 또는 섹션에 이름이 없는 경우 유형(예: "global") 또는 첫 번째 섹션 앞의 빈 문자열.

These variables are resolved at the location where they are parsed. For example if a ".LINE" variable is used in a "log-format" directive located in a defaults section, its line number will be resolved before parsing and compiling the "log-format" directive, so this same line number will be reused by subsequent proxies.
이러한 변수는 구문 분석되는 위치에서 확인됩니다. 예를 들어 ".LINE" 변수가 defaults 섹션에 있는 "log-format" 지시문에 사용되는 경우 해당 줄 번호는 "log-format" 지시문을 구문 분석 및 컴파일하기 전에 확인되므로 이 동일한 줄 번호는 후속 프록시에서 재사용합니다.

This way it is possible to emit information to help locate a rule in variables, logs, error statuses, health checks, header values, or even to use line numbers to name some config objects like servers for example.
이렇게 하면 변수, 로그, 오류 상태, 상태 확인, 헤더 값에서 규칙을 찾는 데 도움이 되는 정보를 내보내거나 줄 번호를 사용하여 예를 들어 서버와 같은 일부 구성 개체의 이름을 지정할 수 있습니다.

See also "external-check command" for other variables.
다른 변수에 대해서는 "external-check command"을 참조하십시오.

2.4. Conditional blocks 조건부 블록

It may sometimes be convenient to be able to conditionally enable or disable some arbitrary parts of the configuration, for example to enable/disable SSL or ciphers, enable or disable some pre-production listeners without modifying the configuration, or adjust the configuration's syntax to support two distinct versions of HAProxy during a migration.. HAProxy brings a set of nestable preprocessor-like directives which allow to integrate or ignore some blocks of text. These directives must be placed on their own line and they act on the lines that follow them. Two of them support an expression, the other ones only switch to an alternate block or end a current level. The 4 following directives are defined to form conditional blocks:

경우에 따라 구성의 일부 임의 부분을 조건부로 활성화 또는 비활성화할 수 있는 것이 편리할 수 있습니다. 예를 들어 SSL 또는 암호를 활성화/비활성화하고 구성을 수정하지 않고 일부 사전 프로덕션 수신기를 활성화 또는 비활성화하려면 또는 마이그레이션 중에 HAProxy의 서로 다른 두 버전을 지원하도록 구성의 구문을 조정합니다. HAProxy는 일부 텍스트 블록을 통합하거나 무시할 수 있는 일련의 중첩 가능한 전처리기 유사 지시문을 제공합니다. 이러한 지시문은 자체 줄에 배치해야 하며 뒤따르는 줄에서 작동합니다. 그 중 두 개는 표현식을 지원하고 다른 하나는 대체 블록으로 전환하거나 현재 레벨을 종료하기만 합니다. 조건부 블록을 형성하기 위해 다음 4개의 지시문이 정의됩니다.

  - .if <condition>
  - .elif <condition>
  - .else
  - .endif

The ".if" directive nests a new level, ".elif" stays at the same level, ".else" as well, and ".endif" closes a level. Each ".if" must be terminated by a matching ".endif". The ".elif" may only be placed after ".if" or ".elif", and there is no limit to the number of ".elif" that may be chained. There may be only one ".else" per ".if" and it must always be after the ".if" or the last ".elif" of a block.

".if" 지시문은 새 수준을 중첩하고 ".elif"는 같은 수준에 머물며 ".else"도 마찬가지이며 ".endif"는 수준을 닫습니다. 각 ".if"는 일치하는 ".endif"로 끝나야 합니다. ".elif"는 ".if" 또는 ".elif" 뒤에만 올 수 있으며 연결될 수 있는 ".elif"의 수에는 제한이 없습니다. ".if"당 하나의 ".else"만 있을 수 있으며 항상 ".if" 또는 블록의 마지막 ".elif" 뒤에 있어야 합니다.

Comments may be placed on the same line if needed after a '#', they will be ignored. The directives are tokenized like other configuration directives, and as such it is possible to use environment variables in conditions.
주석은 '#' 뒤에 필요한 경우 같은 줄에 배치할 수 있으며 무시됩니다. 지시어는 다른 구성 지시어처럼 토큰화되므로 조건에서 환경 변수를 사용할 수 있습니다.

Conditions can also be evaluated on startup with the -cc parameter. See "3. Starting HAProxy" in the management doc.
시작 시 -cc 매개변수를 사용하여 조건을 평가할 수도 있습니다. 관리 문서의 "3. HAProxy 시작하기"를 참조하십시오.

The conditions are either an empty string (which then returns false), or an expression made of any combination of:
조건은 빈 문자열(거짓을 반환함)이거나 다음 조합으로 구성된 표현식입니다.

     - the integer zero ('0'), always returns "false"
     - a non-nul integer (e.g. '1'), always returns "true".
     - a predicate optionally followed by argument(s) in parenthesis.
     - a condition placed between a pair of parenthesis '(' and ')'
     - an exclamation mark ('!') preceding any of the non-empty elements above,
       and which will negate its status.
     - expressions combined with a logical AND ('&&'), which will be evaluated
       from left to right until one returns false
     - expressions combined with a logical OR ('||'), which will be evaluated
       from right to left until one returns true
	
     - 정수 영('0'), 항상 "거짓" 반환
     - null이 아닌 정수(예: '1')는 항상 "true"를 반환합니다.
     - 괄호 안에 인수(들)가 선택적으로 뒤따르는 술어.
     - 한 쌍의 괄호 '('와 ')' 사이에 있는 조건
     - 위의 비어 있지 않은 요소 앞에 오는 느낌표('!')는 해당 상태를 무효화합니다.
     - 거짓을 반환할 때까지 왼쪽에서 오른쪽으로 평가되는 논리적 AND('&&')와 결합된 표현식
     - 논리적 OR('||')과 결합된 표현식으로 true를 반환할 때까지 오른쪽에서 왼쪽으로 평가됩니다.

Note that like in other languages, the AND operator has precedence over the OR operator, so that "A && B || C && D" evalues as "(A && B) || (C && D)".
다른 언어와 마찬가지로 AND 연산자는 OR 연산자보다 우선하므로 "A && B || C && D"는 "(A && B) || (C && D)"로 평가됩니다.

The list of currently supported predicates is the following:
현재 지원되는 술어 목록은 다음과 같습니다.

  - defined(<name>) : returns true if an environment variable <name>
            exists, regardless of its contents
            내용에 관계없이 환경 변수 <name>이 존재하는 경우 true를 반환합니다.
  - feature(<name>) : returns true if feature <name> is listed as present
            in the features list reported by "haproxy -vv"
            (which means a <name> appears after a '+')
            기능 <name>이 "haproxy -vv"에 의해 보고된 기능 목록에 있는 것으로 
            나열되면 true를 반환합니다. 이는 <name>이 '+' 뒤에 나타남을 의미합니다.
  - streq(<str1>,<str2>) : returns true only if the two strings are equal
            두 문자열이 동일한 경우에만 true를 반환합니다.
  - strneq(<str1>,<str2>) : returns true only if the two strings differ
            두 문자열이 다른 경우에만 true를 반환합니다.  
  - version_atleast(<ver>) : returns true if the current haproxy version is
            at least as recent as <ver> otherwise false. The
            version syntax is the same as shown by "haproxy -v"
            and missing components are assumed as being zero.
            현재 haproxy 버전이 적어도 <ver>만큼 최신이면 true를 반환하고 
            그렇지 않으면 false를 반환합니다. 버전 구문은 "haproxy -v"로 표시된 것과 
            동일하며 누락된 구성 요소는 0으로 간주됩니다.
  - version_before(<ver>) : returns true if the current haproxy version is
            strictly older than <ver> otherwise false. The
            version syntax is the same as shown by "haproxy -v"
            and missing components are assumed as being zero.
            현재 haproxy 버전이면 true를 반환합니다.
            엄격하게 보다 오래되었습니다. 그렇지 않으면 거짓입니다.
            버전 구문은 "haproxy -v"로 표시된 것과 동일하며 누락된 구성 요소는 0으로 간주됩니다.

Example:

   .if defined(HAPROXY_MWORKER)
       listen mwcli_px
          bind :1111
          ...
   .endif

   .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

Four other directives are provided to report some status:
일부 상태를 보고하기 위해 4개의 다른 지시문이 제공됩니다.

  - .diag "message"    : emit this message only when in diagnostic mode (-dD)
                         진단 모드(-dD)에 있을 때만 이 메시지를 표시합니다.
  - .notice "message"  : emit this message at level NOTICE
                         NOTICE 수준에서 이 메시지를 내보냅니다.
  - .warning "message" : emit this message at level WARNING
                         WARNING 수준에서 이 메시지를 내보냅니다. 
  - .alert "message"   : emit this message at level ALERT
                         ALERT 수준에서 이 메시지를 내보냅니다.

Messages emitted at level WARNING may cause the process to fail to start if the "strict-mode" is enabled. Messages emitted at level ALERT will always cause a fatal error. These can be used to detect some inappropriate conditions and provide advice to the user.

WARNING 수준에서 방출된 메시지는 "strict-mode"가 활성화된 경우 프로세스 시작에 실패할 수 있습니다. ALERT 수준에서 방출된 메시지는 항상 치명적인 오류를 일으킵니다. 일부 부적절한 조건을 감지하고 사용자에게 조언을 제공하는 데 사용할 수 있습니다.

Example:

  .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: replace 'redirect' with 'return' after switch to 2.4"
        http-request redirect location /goaway if ABUSE

2.5. Time format

Some parameters involve values representing time, such as timeouts. These values are generally expressed in milliseconds (unless explicitly stated otherwise) but may be expressed in any other unit by suffixing the unit to the numeric value. It is important to consider this because it will not be repeated for every keyword. Supported units are :

일부 매개변수에는 시간 제한과 같은 시간을 나타내는 값이 포함됩니다. 이러한 값은 일반적으로 밀리초(달리 명시적으로 언급되지 않는 한)로 표시되지만 단위를 숫자 값에 접미사로 추가하여 다른 단위로 표시할 수 있습니다. 모든 키워드에 대해 반복되지 않기 때문에 이를 고려하는 것이 중요합니다. 지원되는 단위는 다음과 같습니다.

  - us : microseconds. 1 microsecond = 1/1000000 second
  - ms : milliseconds. 1 millisecond = 1/1000 second. This is the default.
  - s  : seconds. 1s = 1000ms
  - m  : minutes. 1m = 60s = 60000ms
  - h  : hours.   1h = 60m = 3600s = 3600000ms
  - d  : days.    1d = 24h = 1440m = 86400s = 86400000ms

2.6. Examples

    # Simple configuration for an HTTP proxy listening on port 80 on all
    # interfaces and forwarding requests to a single backend "servers" with a
    # single server "server1" listening on 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

    # The same configuration defined with a single listen block. Shorter but
    # less expressive, especially in HTTP mode.
    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

Assuming haproxy is in $PATH, test these configurations in a shell with:

    $ sudo haproxy -f configuration.conf -c

3. Global parameters

Parameters in the "global" section are process-wide and often OS-specific. They are generally set once for all and do not need being changed once correct. Some of them have command-line equivalents.
"global" 섹션의 매개변수는 프로세스 전반에 적용되며 종종 OS에 따라 다릅니다. 일반적으로 모두 한 번 설정되며 올바른 후에는 변경할 필요가 없습니다. 그 중 일부는 명령줄과 동일합니다.

The following keywords are supported in the "global" section :
"global" 섹션에서 지원되는 키워드는 다음과 같습니다.

 * Process management and security
   - ca-base
   - chroot
   - cluster-secret
   - crt-base
   - cpu-map
   - daemon
   - default-path
   - description
   - deviceatlas-json-file
   - deviceatlas-log-level
   - deviceatlas-separator
   - deviceatlas-properties-cookie
   - expose-experimental-directives
   - external-check
   - fd-hard-limit
   - gid
   - grace
   - group
   - hard-stop-after
   - httpclient.resolvers.id
   - httpclient.resolvers.prefer
   - httpclient.ssl.ca-file
   - httpclient.ssl.verify
   - h1-accept-payload-with-any-method
   - h1-case-adjust
   - h1-case-adjust-file
   - insecure-fork-wanted
   - insecure-setuid-wanted
   - issuers-chain-path
   - h2-workaround-bogus-websocket-clients
   - localpeer
   - log
   - log-tag
   - log-send-hostname
   - lua-load
   - lua-load-per-thread
   - lua-prepend-path
   - mworker-max-reloads
   - nbthread
   - node
   - numa-cpu-mapping
   - pidfile
   - pp2-never-send-local
   - presetenv
   - resetenv
   - uid
   - ulimit-n
   - user
   - set-dumpable
   - set-var
   - setenv
   - stats
   - ssl-default-bind-ciphers
   - ssl-default-bind-ciphersuites
   - ssl-default-bind-curves
   - ssl-default-bind-options
   - ssl-default-server-ciphers
   - ssl-default-server-ciphersuites
   - ssl-default-server-options
   - ssl-dh-param-file
   - ssl-propquery
   - ssl-provider
   - ssl-provider-path
   - ssl-server-verify
   - ssl-skip-self-issued-ca
   - unix-bind
   - unsetenv
   - 51degrees-data-file
   - 51degrees-property-name-list
   - 51degrees-property-separator
   - 51degrees-cache-size
   - wurfl-data-file
   - wurfl-information-list
   - wurfl-information-list-separator
   - wurfl-cache-size
   - strict-limits

 * Performance tuning
   - busy-polling
   - max-spread-checks
   - maxconn
   - maxconnrate
   - maxcomprate
   - maxcompcpuusage
   - maxpipes
   - maxsessrate
   - maxsslconn
   - maxsslrate
   - maxzlibmem
   - no-memory-trimming
   - noepoll
   - nokqueue
   - noevports
   - nopoll
   - nosplice
   - nogetaddrinfo
   - noreuseport
   - profiling.tasks
   - spread-checks
   - server-state-base
   - server-state-file
   - ssl-engine
   - ssl-mode-async
   - tune.buffers.limit
   - tune.buffers.reserve
   - tune.bufsize
   - tune.comp.maxlevel
   - tune.fd.edge-triggered
   - tune.h2.header-table-size
   - tune.h2.initial-window-size
   - tune.h2.max-concurrent-streams
   - tune.http.cookielen
   - tune.http.logurilen
   - tune.http.maxhdr
   - tune.idle-pool.shared
   - tune.idletimer
   - tune.lua.forced-yield
   - tune.lua.maxmem
   - tune.lua.session-timeout
   - tune.lua.task-timeout
   - tune.lua.service-timeout
   - tune.maxaccept
   - tune.maxpollevents
   - tune.maxrewrite
   - tune.pattern.cache-size
   - tune.peers.max-updates-at-once
   - tune.pipesize
   - tune.pool-high-fd-ratio
   - tune.pool-low-fd-ratio
   - tune.quic.frontend.conn-tx-buffers.limit
   - tune.quic.frontend.max-idle-timeout
   - tune.quic.frontend.max-streams-bidi
   - tune.quic.retry-threshold
   - tune.rcvbuf.client
   - tune.rcvbuf.server
   - tune.recv_enough
   - tune.runqueue-depth
   - tune.sched.low-latency
   - tune.sndbuf.client
   - tune.sndbuf.server
   - tune.ssl.cachesize
   - tune.ssl.force-private-cache
   - tune.ssl.hard-maxrecord
   - tune.ssl.keylog
   - tune.ssl.lifetime
   - tune.ssl.maxrecord
   - tune.ssl.default-dh-param
   - tune.ssl.ssl-ctx-cache-size
   - tune.ssl.capture-buffer-size
   - tune.ssl.capture-cipherlist-size (deprecated)
   - 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

 * Debugging
   - quiet
   - zero-warning

3.1. Process management and security

ca-base <dir>
Assigns a default directory to fetch SSL CA certificates and CRLs from when a
relative path is used with "ca-file", "ca-verify-file" or "crl-file"
directives. Absolute locations specified in "ca-file", "ca-verify-file" and
"crl-file" prevail and ignore "ca-base".

상대 경로가 "ca-file", "ca-verify-file" 또는 "crl-file" 지시문과 함께 사용될 때
SSL CA 인증서 및 CRL을 가져올 기본 디렉터리를 할당합니다.
"ca-file", "ca-verify-file", "crl-file"에 절대 경로를 지정하면 "ca-base"는 무시됩니다.

chroot <jail dir>
Changes current directory to <jail dir> and performs a chroot() there before
dropping privileges. This increases the security level in case an unknown
vulnerability would be exploited, since it would make it very hard for the
attacker to exploit the system. This only works when the process is started
with superuser privileges. It is important to ensure that <jail_dir> is both
empty and non-writable to anyone.

현재 디렉토리를 <jail dir>로 변경하고 권한을 삭제하기 전에 그곳에서 chroot()를 수행합니다.
이렇게 하면 공격자가 시스템을 악용하기가 매우 어려워지기 때문에 알려지지 않은 취약점이
악용될 경우 보안 수준이 높아집니다. 수퍼유저 권한으로 프로세스를 시작할 때만 작동합니다.
<jail_dir>이 비어 있고 누구에게나 쓸 수 없는지 확인하는 것이 중요합니다.

cluster-secret <secret>
Define an ASCII string secret shared between several nodes belonging to the
same cluster. It could be used for different usages. It is at least used to
derive stateless reset tokens for all the QUIC connections instantiated by
this process. This is also the case to derive secrets used to encrypt Retry
tokens. If you do not set this parameter, the stateless reset and Retry QUIC
features will be both silently disabled.

동일한 클러스터에 속하는 여러 노드 간에 공유되는 ASCII 문자열 비밀을 정의합니다.
다양한 용도로 사용할 수 있습니다. 적어도 이 프로세스에 의해 인스턴스화된 모든 QUIC
연결에 대해 상태 비저장 재설정 토큰을 파생시키는 데 사용됩니다.
Retry 토큰을 암호화하는 데 사용되는 암호를 파생하는 경우에도 마찬가지입니다.
이 매개변수를 설정하지 않으면 상태 비저장 재설정 및 QUIC 재시도 기능이 자동으로
비활성화됩니다.

close-spread-time <time>
Define a time window during which idle connections and active connections
closing is spread in case of soft-stop. After a SIGUSR1 is received and the
grace period is over (if any), the idle connections will all be closed at
once if this option is not set, and active HTTP or HTTP2 connections will be
ended after the next request is received, either by appending a "Connection:
close" line to the HTTP response, or by sending a GOAWAY frame in case of
HTTP2. When this option is set, connection closing will be spread over this
set <time>.
If the close-spread-time is set to "infinite", active connection closing
during a soft-stop will be disabled. The "Connection: close" header will not
be added to HTTP responses (or GOAWAY for HTTP2) anymore and idle connections
will only be closed once their timeout is reached (based on the various
timeouts set in the configuration).

소프트 스톱의 경우 유휴 연결 및 활성 연결 종료가 확산되는 시간 창을 정의합니다.
SIGUSR1이 수신되고 유예 기간이 끝난 후(있는 경우) 유휴 연결은 이 옵션이 설정되지 않은
경우 한 번에 모두 닫히고 활성 HTTP 또는 HTTP2 연결은 다음 요청이 수신된 후 종료됩니다.
close" 라인을 HTTP 응답에 연결하거나 HTTP2의 경우 GOAWAY 프레임을 전송합니다.
이 옵션을 설정하면 이 설정한 <time> 동안 연결 종료가 확산됩니다.
close-spread-time이 "infinite"로 설정되면 소프트 스톱 동안 활성 연결 종료가 비활성화됩니다.
"Connection: close" 헤더는 더 이상 HTTP 응답(또는 HTTP2의 경우 GOAWAY)에 추가되지
않으며 유휴 연결은 제한 시간에 도달한 경우에만 닫힙니다(구성에 설정된 다양한 시간 제한에 따라).

Arguments :
<time> is a time window (by default in milliseconds) during which
connection closing will be spread during a soft-stop operation, or
"infinite" if active connection closing should be disabled.
<time>은 소프트 스톱 작업 중에 연결 종료가 확산되는 시간 창(기본적으로 밀리초 단위)
또는 활성 연결 종료를 비활성화해야 하는 경우 "infinite"입니다.

It is recommended to set this setting to a value lower than the one used in
the "hard-stop-after" option if this one is used, so that all connections
have a chance to gracefully close before the process stops.
이 설정을 사용하는 경우 "hard-stop-after" 옵션에 사용된 값보다 낮은 값으로
설정하여 프로세스가 중지되기 전에 모든 연결이 정상적으로 닫힐 수 있도록 하는 것이 좋습니다.

See also: grace, hard-stop-after, idle-close-on-response

cpu-map [auto:]<process-set>[/<thread-set>] <cpu-set>...
On some operating systems, it is possible to bind a process or a thread to a
specific CPU set. This means that the process or the thread will never run on
other CPUs. The "cpu-map" directive specifies CPU sets for process or thread
sets. The first argument is a process set, eventually followed by a thread
set. These sets have the format

일부 운영 체제에서는 프로세스나 스레드를 특정 CPU 세트에 바인딩할 수 있습니다.
이는 프로세스 또는 스레드가 다른 CPU에서 실행되지 않음을 의미합니다.
"cpu-map" 지시문은 프로세스 또는 스레드 세트에 대한 CPU 세트를 지정합니다.
첫 번째 인수는 프로세스 세트이고 결국에는 스레드 세트가 뒤따릅니다.
이 세트의 형식은 다음과 같습니다.

all | odd | even | number[-[number]]

<number> must be a number between 1 and 32 or 64, depending on the machine's
word size. Any process IDs above 1 and any thread IDs above nbthread are
ignored. It is possible to specify a range with two such number delimited by
a dash ('-'). It also is possible to specify all thraeds at once using
"all", only odd numbers using "odd" or even numbers using "even", just like
with the "bind-process" directive. The second and forthcoming arguments are
CPU sets. Each CPU set is either a unique number starting at 0 for the first
CPU or a range with two such numbers delimited by a dash ('-'). Outside of
Linux and BSDs, there may be a limitation on the maximum CPU index to either
31 or 63. Multiple CPU numbers or ranges may be specified, and the processes
or threads will be allowed to bind to all of them. Obviously, multiple
"cpu-map" directives may be specified. Each "cpu-map" directive will replace
the previous ones when they overlap. A thread will be bound on the
intersection of its mapping and the one of the process on which it is
attached. If the intersection is null, no specific binding will be set for
the thread.

<number>는 시스템의 단어 크기에 따라 1에서 32 또는 64 사이의 숫자여야 합니다.
1 이상의 모든 프로세스 ID와 nbthread 이상의 모든 스레드 ID는 무시됩니다.
대시('-')로 구분된 두 개의 숫자로 범위를 지정할 수 있습니다.
"bind-process" 지시문과 마찬가지로 "all"을 사용하여 한 번에 모든 스레드를 지정하고
"odd"를 사용하여 홀수만 지정하거나 "even"을 사용하여 짝수만 지정하는 것도 가능합니다.
두 번째 및 향후 인수는 CPU 세트입니다.
각 CPU 세트는 첫 번째 CPU에 대해 0부터 시작하는 고유 번호이거나 대시('-')로 구분된
두 개의 숫자가 있는 범위입니다.
Linux 및 BSD 외부에서는 최대 CPU 인덱스가 31 또는 63으로 제한될 수 있습니다.
여러 CPU 번호 또는 범위를 지정할 수 있으며 프로세스 또는 스레드는 이들 모두에 바인딩할
수 있습니다. 분명히 여러 개의 "cpu-map" 지시문을 지정할 수 있습니다.
각 "cpu-map" 지시어는 겹치면 이전 지시어를 대체합니다. 스레드는 해당 매핑과 연결된
프로세스 중 하나의 교차점에 바인딩됩니다.
교차가 null이면 스레드에 대해 특정 바인딩이 설정되지 않습니다.

Ranges can be partially defined. The higher bound can be omitted. In such
case, it is replaced by the corresponding maximum value, 32 or 64 depending
on the machine's word size.
범위는 부분적으로 정의할 수 있습니다. 상한선은 생략할 수 있습니다.
이 경우 기계의 워드 크기에 따라 해당 최대값인 32 또는 64로 대체됩니다.

The prefix "auto:" can be added before the process set to let HAProxy
automatically bind a process or a thread to a CPU by incrementing threads and
CPU sets. To be valid, both sets must have the same size. No matter the
declaration order of the CPU sets, it will be bound from the lowest to the
highest bound. Having both a process and a thread range with the "auto:"
prefix is not supported. Only one range is supported, the other one must be
a fixed number.

접두사 "auto:"는 HAProxy가 스레드 및 CPU 집합을 증가시켜 프로세스 또는
스레드를 CPU에 자동으로 바인딩하도록 설정한 프로세스 앞에 추가할 수 있습니다.
유효하려면 두 세트의 크기가 같아야 합니다.
CPU 세트의 선언 순서에 관계없이 가장 낮은 값에서 가장 높은 값으로 바인딩됩니다.
"auto:" 접두사가 있는 프로세스 및 스레드 범위는 모두 지원되지 않습니다.
하나의 범위만 지원되며 다른 하나는 고정된 숫자여야 합니다.

Note that process ranges are supported for historical reasons. Nowadays, a
lone number designates a process and must be 1, and specifying a thread range
or number requires to prepend "1/" in front of it. Finally, "1" is strictly
equivalent to "1/all" and designates all threads on the process.

프로세스 범위는 기록상의 이유로 지원됩니다. 요즘은 고독한 숫자가 프로세스를
지정하고 1이어야 하며 스레드 범위나 숫자를 지정하려면 그 앞에 "1/"을 앞에 추가해야 합니다.
마지막으로 "1"은 "1/all"과 완전히 동일하며 프로세스의 모든 스레드를 지정합니다.

  Examples:
      cpu-map 1/all 0-3 # bind all threads of the first process on the
                        # first 4 CPUs

      cpu-map 1/1- 0-   # will be replaced by "cpu-map 1/1-64 0-63"
                        # or "cpu-map 1/1-32 0-31" depending on the machine's
                        # word size.

      # all these lines bind the thread 1 to the cpu 0, the thread 2 to cpu 1
      # and so on.
      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

      # bind each thread to exactly one CPU using all/odd/even keyword
      cpu-map auto:1/all   0-63
      cpu-map auto:1/even  0-31
      cpu-map auto:1/odd   32-63

      # invalid cpu-map because thread and CPU sets have different sizes.
      cpu-map auto:1/1-4   0    # invalid
      cpu-map auto:1/1     0-3  # invalid

crt-base <dir>
Assigns a default directory to fetch SSL certificates from when a relative
path is used with "crtfile" or "crt" directives. Absolute locations specified
prevail and ignore "crt-base".
상대 경로가 "crtfile" 또는 "crt" 지시문과 함께 사용될 때 SSL 인증서를 가져올
기본 디렉토리를 할당합니다. "crtfile" 또는 "crt"에 절대 경로를 지정하면
"crt-base"는 무시됩니다.

daemon
Makes the process fork into background. This is the recommended mode of
operation. It is equivalent to the command line "-D" argument. It can be
disabled by the command line "-db" argument. This option is ignored in
systemd mode.
프로세스 포크를 백그라운드로 만듭니다. 권장되는 작동 모드입니다.
명령줄 "-D" 인수와 동일합니다. 명령줄 "-db" 인수로 비활성화할 수 있습니다.
이 옵션은 시스템 모드에서 무시됩니다.

default-path { current | config | parent | origin <path> }
By default HAProxy loads all files designated by a relative path from the
location the process is started in. In some circumstances it might be
desirable to force all relative paths to start from a different location
just as if the process was started from such locations. This is what this
directive is made for. Technically it will perform a temporary chdir() to
the designated location while processing each configuration file, and will
return to the original directory after processing each file. It takes an
argument indicating the policy to use when loading files whose path does
not start with a slash ('/'):

기본적으로 HAProxy는 프로세스가 시작된 위치에서 상대 경로로 지정된 모든 파일을 로드합니다.
경우에 따라 프로세스가 해당 위치에서 시작된 것처럼 모든 상대 경로가 다른 위치에서
시작되도록 하는 것이 바람직할 수 있습니다. 이것이 이 지시문이 만들어진 이유입니다.
기술적으로 각 구성 파일을 처리하는 동안 지정된 위치로 임시 chdir()을 수행하고 각 파일을
처리한 후 원래 디렉터리로 돌아갑니다. 경로가 슬래시('/')로 시작하지 않는 파일을 로드할 때
사용할 정책을 나타내는 인수를 사용합니다.

- "current" indicates that all relative files are to be loaded from the
directory the process is started in ; this is the default.
"current"는 모든 관련 파일이 프로세스가 시작된 디렉토리에서 로드됨을
나타냅니다. 이것이 기본값입니다.

- "config" indicates that all relative files should be loaded from the
directory containing the configuration file. More specifically, if the
configuration file contains a slash ('/'), the longest part up to the
last slash is used as the directory to change to, otherwise the current
directory is used. This mode is convenient to bundle maps, errorfiles,
certificates and Lua scripts together as relocatable packages. When
multiple configuration files are loaded, the directory is updated for
each of them.

"config"는 구성 파일이 포함된 디렉토리에서 모든 관련 파일을 로드해야 함을 나타냅니다.
보다 구체적으로, 구성 파일에 슬래시('/')가 포함되어 있으면 마지막 슬래시까지 가장 긴
부분이 변경 대상 디렉터리로 사용되며, 그렇지 않으면 현재 디렉터리가 사용됩니다.
이 모드는 맵, 오류 파일, 인증서 및 Lua 스크립트를 재배치 가능한 패키지로 함께 묶는 데
편리합니다. 여러 구성 파일이 로드되면 각각의 디렉토리가 업데이트됩니다.

-"parent" indicates that all relative files should be loaded from the
parent of the directory containing the configuration file. More
specifically, if the configuration file contains a slash ('/'), ".."
is appended to the longest part up to the last slash is used as the
directory to change to, otherwise the directory is "..". This mode is
convenient to bundle maps, errorfiles, certificates and Lua scripts
together as relocatable packages, but where each part is located in a
different subdirectory (e.g. "config/", "certs/", "maps/", ...).

"parent"는 구성 파일이 포함된 디렉토리의 상위에서 모든 관련 파일을 로드해야 함을 나타냅니다.
보다 구체적으로, 구성 파일에 슬래시('/')가 포함되어 있으면 마지막 슬래시까지 가장 긴
부분에 ".."을 추가하여 변경할 디렉터리로 사용하고 그렇지 않은 경우 디렉터리는 ".."입니다.
이 모드는 맵, 오류 파일, 인증서 및 Lua 스크립트를 재배치 가능한 패키지로 함께 묶는 데
편리하지만 각 부분은 다른 하위 디렉토리(예: "config/", "certs/", "maps/", ...)에 있습니다.

-"origin" indicates that all relative files should be loaded from the
designated (mandatory) path. This may be used to ease management of
different HAProxy instances running in parallel on a system, where each
instance uses a different prefix but where the rest of the sections are
made easily relocatable.

"origin"은 모든 상대 파일이 지정된(필수) 경로에서 로드되어야 함을 나타냅니다.
이것은 각 인스턴스가 다른 접두사를 사용하지만 나머지 섹션은 쉽게 재배치할 수 있는
시스템에서 병렬로 실행되는 다양한 HAProxy 인스턴스의 관리를 용이하게 하는 데
사용할 수 있습니다.

Each "default-path" directive instantly replaces any previous one and will
possibly result in switching to a different directory. While this should
always result in the desired behavior, it is really not a good practice to
use multiple default-path directives, and if used, the policy ought to remain
consistent across all configuration files.

각 "default-path" 지시문은 이전 지시문을 즉시 대체하며 결과적으로 다른 디렉토리로
전환될 수 있습니다. 이렇게 하면 항상 원하는 동작이 발생해야 하지만 여러 기본 경로
지시문을 사용하는 것은 실제로 좋은 방법이 아니며 사용하는 경우 정책은 모든 구성 파일에서
일관성을 유지해야 합니다.

Warning: some configuration elements such as maps or certificates are
uniquely identified by their configured path. By using a relocatable layout,
it becomes possible for several of them to end up with the same unique name,
making it difficult to update them at run time, especially when multiple
configuration files are loaded from different directories. It is essential to
observe a strict collision-free file naming scheme before adopting relative
paths. A robust approach could consist in prefixing all files names with
their respective site name, or in doing so at the directory level.

경고: 맵 또는 인증서와 같은 일부 구성 요소는 구성된 경로로 고유하게 식별됩니다.
재배치 가능한 레이아웃을 사용하면 여러 구성 파일이 동일한 고유한 이름으로 끝날 수
있으므로 특히 여러 구성 파일이 서로 다른 디렉토리에서 로드될 때 런타임에 업데이트하기가
어렵습니다.
상대 경로를 채택하기 전에 엄격한 충돌 방지 파일 명명 체계를 준수하는 것이 중요합니다.
강력한 접근 방식은 모든 파일 이름에 해당 사이트 이름을 접두사로 붙이거나 디렉터리
수준에서 그렇게 하는 것입니다.

deviceatlas-json-file <path>
Sets the path of the DeviceAtlas JSON data file to be loaded by the API.
The path must be a valid JSON data file and accessible by HAProxy process.
API에서 로드할 DeviceAtlas JSON 데이터 파일의 경로를 설정합니다.
경로는 유효한 JSON 데이터 파일이어야 하며 HAProxy 프로세스에서 액세스할 수
있어야 합니다.

deviceatlas-log-level <value>
Sets the level of information returned by the API. This directive is
optional and set to 0 by default if not set.
API가 반환하는 정보의 수준을 설정합니다. 이 지시문은 선택 사항이며
설정하지 않으면 기본적으로 0으로 설정됩니다.

deviceatlas-separator <char>
Sets the character separator for the API properties results. This directive
is optional and set to | by default if not set.
API 속성 결과에 대한 문자 구분 기호를 설정합니다.
이 지시문은 선택 사항이며 설정하지 않으면 기본적으로 '|' 입니다.

deviceatlas-properties-cookie <name>
Sets the client cookie's name used for the detection if the DeviceAtlas
Client-side component was used during the request. This directive is optional
and set to DAPROPS by default if not set.
요청 중에 DeviceAtlas 클라이언트측 구성 요소가 사용된 경우 검색에 사용되는
클라이언트 쿠키의 이름을 설정합니다.
이 지시문은 선택 사항이며 설정하지 않으면 기본적으로 DAPROPS로 설정됩니다.

expose-experimental-directives
This statement must appear before using directives tagged as experimental or
the config file will be rejected.
이 문은 실험용으로 태그가 지정된 지시문을 사용하기 전에 나타나야 합니다.
그렇지 않으면 구성 파일이 거부됩니다.

external-check
Allows the use of an external agent to perform health checks. This is
disabled by default as a security precaution, and even when enabled, checks
may still fail unless "insecure-fork-wanted" is enabled as well. If the
program launched makes use of a setuid executable (it should really not),
you may also need to set "insecure-setuid-wanted" in the global section.
See "option external-check", and "insecure-fork-wanted", and
"insecure-setuid-wanted".

외부 에이전트를 사용하여 상태 확인을 수행할 수 있습니다.
이것은 보안 예방 조치로 기본적으로 비활성화되어 있으며 활성화된 경우에도
"insecure-fork-wanted"도 활성화하지 않으면 검사가 여전히 실패할 수 있습니다.
실행된 프로그램이 setuid 실행 파일을 사용하는 경우(실제로 사용해서는 안 됨)
전역 섹션에서 "insecure-setuid-wanted"를 설정해야 할 수도 있습니다.
"option external-check", "insecure-fork-wanted" 및 "insecure-setuid-wanted"를
참조하십시오.

fd-hard-limit <number>
Sets an upper bound to the maximum number of file descriptors that the
process will use, regardless of system limits. While "ulimit-n" and "maxconn"
may be used to enforce a value, when they are not set, the process will be
limited to the hard limit of the RLIMIT_NOFILE setting as reported by
"ulimit -n -H". But some modern operating systems are now allowing extremely
large values here (in the order of 1 billion), which will consume way too
much RAM for regular usage. The fd-hard-limit setting is provided to enforce
a possibly lower bound to this limit. This means that it will always respect
the system-imposed limits when they are below <number> but the specified
value will be used if system-imposed limits are higher. In the example below,
no other setting is specified and the maxconn value will automatically adapt
to the lower of "fd-hard-limit" and the system-imposed limit:

시스템 제한에 관계없이 프로세스가 사용할 최대 파일 설명자 수의 상한을 설정합니다.
"ulimit-n" 및 "maxconn"은 값을 적용하는 데 사용될 수 있지만 설정되지 않은 경우
프로세스는 "ulimit -n -H"에 의해 보고된 RLIMIT_NOFILE 설정의 하드 제한으로 제한됩니다.
그러나 일부 최신 운영 체제는 이제 여기에서 매우 큰 값(10억 정도)을 허용하므로
일반적인 사용을 위해 너무 많은 RAM을 소비합니다.
fd-hard-limit 설정은 이 제한에 가능한 하한을 적용하기 위해 제공됩니다.
즉, <number> 미만이면 시스템에서 부과한 제한을 항상 준수하지만 시스템에서 부과한
제한이 더 높으면 지정된 값이 사용됩니다.
아래 예에서는 다른 설정이 지정되지 않았으며 maxconn 값은 "fd-hard-limit" 및 시스템 부과
제한 중 낮은 값에 자동으로 적용됩니다.

      global
          # use as many FDs as possible but no more than 50000
          fd-hard-limit 50000

  See also: ulimit-n, maxconn

gid <number>
Changes the process's group ID to <number>. It is recommended that the group
ID is dedicated to HAProxy or to a small set of similar daemons. HAProxy must
be started with a user belonging to this group, or with superuser privileges.
Note that if HAProxy is started from a user having supplementary groups, it
will only be able to drop these groups if started with superuser privileges.

프로세스의 그룹 ID를 <number>로 변경합니다.
그룹 ID는 HAProxy 또는 유사한 데몬의 소규모 세트 전용으로 사용하는 것이 좋습니다.
HAProxy는 이 그룹에 속한 사용자 또는 수퍼유저 권한으로 시작해야 합니다.
보충 그룹이 있는 사용자로부터 HAProxy가 시작된 경우 수퍼유저 권한으로 시작된 경우에만
이러한 그룹을 삭제할 수 있습니다.

3.2. Performance tuning

busy-polling
In some situations, especially when dealing with low latency on processors
supporting a variable frequency or when running inside virtual machines, each
time the process waits for an I/O using the poller, the processor goes back
to sleep or is offered to another VM for a long time, and it causes
excessively high latencies. This option provides a solution preventing the
processor from sleeping by always using a null timeout on the pollers. This
results in a significant latency reduction (30 to 100 microseconds observed)
at the expense of a risk to overheat the processor. It may even be used with
threads, in which case improperly bound threads may heavily conflict,
resulting in a worse performance and high values for the CPU stolen fields
in "show info" output, indicating which threads are misconfigured. It is
important not to let the process run on the same processor as the network
interrupts when this option is used. It is also better to avoid using it on
multiple CPU threads sharing the same core. This option is disabled by
default. If it has been enabled, it may still be forcibly disabled by
prefixing it with the "no" keyword. It is ignored by the "select" and
"poll" pollers.

일부 상황에서, 특히 가변 주파수를 지원하는 프로세서에서 짧은 대기 시간을 처리하거나
가상 머신 내부에서 실행될 때 프로세스가 폴러를 사용하여 I/O를 기다릴 때마다 프로세서는
다시 절전 모드로 전환되거나 다른 VM에 제공됩니다.
시간이 오래 걸리고 대기 시간이 지나치게 길어집니다.
이 옵션은 폴러에서 항상 null 시간 제한을 사용하여 프로세서가 절전 모드가 되지 않도록
방지하는 솔루션을 제공합니다.
이로 인해 프로세서가 과열될 위험이 있는 대신 대기 시간이 크게 감소합니다
(관찰된 30~100마이크로초).
스레드와 함께 사용할 수도 있으며, 이 경우 부적절하게 바인딩된 스레드가 심하게 충돌하여
성능이 저하되고 "show info 정보 표시" 출력에서 CPU stolen(도난) 필드의 값이 높아져
어떤 스레드가 잘못 구성되었는지 나타냅니다.
이 옵션을 사용할 때 네트워크 인터럽트와 동일한 프로세서에서 프로세스를 실행하지 않도록
하는 것이 중요합니다.
또한 동일한 코어를 공유하는 여러 CPU 스레드에서 사용하지 않는 것이 좋습니다.
이 옵션은 기본적으로 비활성화되어 있습니다.
활성화된 경우 "no" 키워드를 접두어로 지정하여 강제로 비활성화할 수 있습니다.
"select" 및 "poll" 폴러에서는 무시됩니다.

This option is automatically disabled on old processes in the context of
seamless reload; it avoids too much cpu conflicts when multiple processes
stay around for some time waiting for the end of their current connections.

이 옵션은 원활한 다시 로드와 관련하여 이전 프로세스에서 자동으로 비활성화됩니다.
여러 프로세스가 현재 연결이 끝날 때까지 잠시 동안 머무를 때 너무 많은 CPU 충돌을 방지합니다.

max-spread-checks <delay in milliseconds>
By default, HAProxy tries to spread the start of health checks across the
smallest health check interval of all the servers in a farm. The principle is
to avoid hammering services running on the same server. But when using large
check intervals (10 seconds or more), the last servers in the farm take some
time before starting to be tested, which can be a problem. This parameter is
used to enforce an upper bound on delay between the first and the last check,
even if the servers' check intervals are larger. When servers run with
shorter intervals, their intervals will be respected though.

기본적으로 HAProxy는 팜에 있는 모든 서버의 가장 작은 상태 확인 간격에 걸쳐
상태 확인 시작을 분산하려고 시도합니다.
원칙은 동일한 서버에서 실행되는 망치질(hammering) 서비스를 피하는 것입니다.
그러나 큰 확인 간격(10초 이상)을 사용하면 팜의 마지막 서버가 테스트를 시작하기 전에
시간이 걸리므로 문제가 될 수 있습니다.
이 매개변수는 서버의 확인 간격이 더 큰 경우에도 첫 번째 확인과 마지막 확인 사이의
지연에 대한 상한을 적용하는 데 사용됩니다.
서버가 더 짧은 간격으로 실행되면 해당 간격이 준수됩니다.

maxconn <number>
Sets the maximum per-process number of concurrent connections to <number>. It
is equivalent to the command-line argument "-n". Proxies will stop accepting
connections when this limit is reached. The "ulimit-n" parameter is
automatically adjusted according to this value. See also "ulimit-n". Note:
the "select" poller cannot reliably use more than 1024 file descriptors on
some platforms. If your platform only supports select and reports "select
FAILED" on startup, you need to reduce maxconn until it works (slightly
below 500 in general). If this value is not set, it will automatically be
calculated based on the current file descriptors limit reported by the
"ulimit -n" command, possibly reduced to a lower value if a memory limit
is enforced, based on the buffer size, memory allocated to compression, SSL
cache size, and use or not of SSL and the associated maxsslconn (which can
also be automatic). In any case, the fd-hard-limit applies if set.

프로세스당 최대 동시 연결 수를 <number>로 설정합니다.
명령줄 인수 "-n"과 동일합니다. 프록시는 이 제한에 도달하면 연결 수락을 중지합니다.
"ulimit-n" 매개변수는 이 값에 따라 자동으로 조정됩니다. "ulimit-n"도 참조하십시오.
참고: "select" 폴러는 일부 플랫폼에서 1024개 이상의 파일 설명자를 안정적으로 사용할 수 없습니다.
플랫폼이 선택만 지원하고 시작 시 "select FAILED"를 보고하는 경우 작동할 때까지
maxconn을 줄여야 합니다(일반적으로 500보다 약간 낮음).
이 값을 설정하지 않으면 "ulimit -n" 명령에 의해 보고된 현재 파일 설명자 제한에 따라
자동으로 계산되며, 메모리 제한이 적용되는 경우 버퍼 크기, 할당된 메모리에 따라 더
낮은 값으로 감소될 수 있습니다.
압축, SSL 캐시 크기, SSL 및 관련 maxsslconn(자동일 수도 있음) 사용 여부.
어떤 경우든 fd-hard-limit가 설정된 경우 적용됩니다.

3.3. Debugging

quiet	
  Do not display any message during startup. It is equivalent to the command-
  line argument "-q".	
  시작하는 동안 메시지를 표시하지 마십시오.
  명령줄 인수 "-q"와 동일합니다.
	
zero-warning	
  When this option is set, HAProxy will refuse to start if any warning was
  emitted while processing the configuration. It is highly recommended to set
  this option on configurations that are not changed often, as it helps detect
  subtle mistakes and keep the configuration clean and forward-compatible. Note
  that "haproxy -c" will also report errors in such a case. This option is
  equivalent to command line argument "-dW".	
  
  이 옵션을 설정하면 HAProxy는 구성을 처리하는 동안 경고가 발생하면 시작을 거부합니다.
  자주 변경되지 않는 구성에서 이 옵션을 설정하는 것이 좋습니다. 
  미묘한 실수를 감지하고 구성을 깨끗하고 향후 호환되도록 유지하는 데 도움이 되기 때문입니다.
  이러한 경우 "haproxy -c"도 오류를 보고합니다. 이 옵션은 명령줄 인수 "-dW"와 동일합니다.

3.4. Userlists

It is possible to control access to frontend/backend/listen sections or to
http stats by allowing only authenticated and authorized users. To do this,
it is required to create at least one userlist and to define users.

인증되고 승인된 사용자만 허용하여 프런트엔드/백엔드/수신 섹션 또는 http 통계에
대한 액세스를 제어할 수 있습니다.
이를 위해서는 하나 이상의 사용자 목록을 생성하고 사용자를 정의해야 합니다.

userlist <listname>
Creates new userlist with name <listname>. Many independent userlists can be
used to store authentication & authorization data for independent customers.
이름이 <listname>인 새 사용자 목록을 만듭니다.
많은 독립 사용자 목록을 사용하여 독립 고객에 대한 인증 및 권한 부여 데이터를 저장할
수 있습니다.

group <groupname> [users <user>,<user>,(...)]
Adds group <groupname> to the current userlist. It is also possible to
attach users to this group by using a comma separated list of names
proceeded by "users" keyword.

현재 사용자 목록에 그룹 <groupname>을 추가합니다.
"users" 키워드로 진행되는 쉼표로 구분된 이름 목록을 사용하여 이 그룹에
사용자를 추가할 수도 있습니다.

user <username> [password|insecure-password <password>]
[groups <group>,<group>,(...)]
Adds user <username> to the current userlist. Both secure (encrypted) and
insecure (unencrypted) passwords can be used. Encrypted passwords are
evaluated using the crypt(3) function, so depending on the system's
capabilities, different algorithms are supported. For example, modern Glibc
based Linux systems support MD5, SHA-256, SHA-512, and, of course, the
classic DES-based method of encrypting passwords.

사용자 <username>을 현재 사용자 목록에 추가합니다.
보안(암호화된) 및 비보안(암호화되지 않은) 암호를 모두 사용할 수 있습니다.
암호화된 암호는 crypt(3) 함수를 사용하여 평가되므로 시스템의 기능에 따라
다른 알고리즘이 지원됩니다. 예를 들어 최신 Glibc 기반 Linux 시스템은
MD5, SHA-256, SHA-512를 지원하며, 물론 고전적인 DES 기반 암호 암호화 방법도
지원합니다.

Attention: Be aware that using encrypted passwords might cause significantly
increased CPU usage, depending on the number of requests, and the algorithm
used. For any of the hashed variants, the password for each request must
be processed through the chosen algorithm, before it can be compared to the
value specified in the config file. Most current algorithms are deliberately
designed to be expensive to compute to achieve resistance against brute
force attacks. They do not simply salt/hash the clear text password once,
but thousands of times. This can quickly become a major factor in HAProxy's
overall CPU consumption!

주의: 암호화된 암호를 사용하면 요청 수 및 사용된 알고리즘에 따라 CPU 사용량이
크게 증가할 수 있습니다. 해시된 변형의 경우 구성 파일에 지정된 값과 비교하기 전에
선택한 알고리즘을 통해 각 요청의 암호를 처리해야 합니다.
대부분의 현재 알고리즘은 무차별 대입 공격에 대한 저항을 달성하기 위해 의도적으로
계산 비용이 많이 들도록 설계되었습니다.
일반 텍스트 암호를 한 번이 아니라 수천 번 솔트/해시합니다.
이는 HAProxy의 전체 CPU 소비에서 빠르게 주요 요인이 될 수 있습니다!

  Example:
        userlist L1
          group G1 users tiger,scott
          group G2 users xdb,scott

          user tiger password $6$k6y3o.eP$JlKBx9za9667qe4(...)xHSwRv6J.C0/D7cV91
          user scott insecure-password elgato
          user xdb insecure-password hello

        userlist L2
          group G1
          group G2

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

  Please note that both lists are functionally identical.
  두 목록은 기능적으로 동일합니다.

3.5. Peers

It is possible to propagate entries of any data-types in stick-tables between
several HAProxy instances over TCP connections in a multi-master fashion. Each
instance pushes its local updates and insertions to remote peers. The pushed
values overwrite remote ones without aggregation. As an exception, the data
type "conn_cur" is never learned from peers, as it is supposed to reflect local
values. Earlier versions used to synchronize it and to cause negative values in
active-active setups, and always-growing values upon reloads or active-passive
switches because the local value would reflect more connections than locally
present. This information, however, is pushed so that monitoring systems can
watch it.

다중 마스터 방식으로 TCP 연결을 통해 여러 HAProxy 인스턴스 간에 스틱 테이블의
모든 데이터 유형 항목을 전파할 수 있습니다.
각 인스턴스는 로컬 업데이트 및 삽입을 원격 피어에 푸시합니다.
푸시된 값은 집계 없이 원격 값을 덮어씁니다.
예외적으로 "conn_cur" 데이터 유형은 로컬 값을 반영해야 하므로 피어에서 학습되지 않습니다.
이전 버전에서는 이를 동기화하고 활성-활성 설정에서 음수 값을 유발하고, 로컬 값이
로컬에 있는 것보다 더 많은 연결을 반영하기 때문에 다시 로드 또는 활성-수동 전환 시
값이 항상 증가했습니다.
그러나 이 정보는 모니터링 시스템에서 볼 수 있도록 푸시됩니다.

Interrupted exchanges are automatically detected and recovered from the last
known point. In addition, during a soft restart, the old process connects to
the new one using such a TCP connection to push all its entries before the new
process tries to connect to other peers. That ensures very fast replication
during a reload, it typically takes a fraction of a second even for large
tables.

중단된 교환은 자동으로 감지되어 마지막으로 알려진 지점에서 복구됩니다.
또한 소프트 재시작 중에 이전 프로세스는 이러한 TCP 연결을 사용하여 새 프로세스에
연결하여 새 프로세스가 다른 피어에 연결을 시도하기 전에 모든 항목을 푸시합니다.
이렇게 하면 다시 로드하는 동안 매우 빠른 복제가 보장되며 일반적으로 큰 테이블의
경우에도 1초도 걸리지 않습니다.

Note that Server IDs are used to identify servers remotely, so it is important
that configurations look similar or at least that the same IDs are forced on
each server on all participants.

서버 ID는 서버를 원격으로 식별하는 데 사용되므로 구성이 유사해 보이거나 적어도
모든 참가자의 각 서버에 동일한 ID가 적용되는 것이 중요합니다.

peers <peersect>
Creates a new peer list with name <peersect>. It is an independent section,
which is referenced by one or more stick-tables.
이름이 <peersect>인 새 피어 목록을 만듭니다.
하나 이상의 스틱 테이블에서 참조하는 독립 섹션입니다.

bind [<address>]:<port_range> [, ...] [param*]
Defines the binding parameters of the local peer of this "peers" section.
Such lines are not supported with "peer" line in the same "peers" section.
이 "peers" 섹션의 로컬 피어의 바인딩 매개변수를 정의합니다.
이러한 라인은 동일한 "peer" 섹션의 "peer" 라인에서 지원되지 않습니다.

disabled
Disables a peers section. It disables both listening and any synchronization
related to this section. This is provided to disable synchronization of stick
tables without having to comment out all "peers" references.
피어 섹션을 비활성화합니다. 이 섹션과 관련된 수신 및 동기화를 모두 비활성화합니다.
이는 모든 "peers" 참조를 주석 처리하지 않고 스틱 테이블의 동기화를 비활성화하기
위해 제공됩니다.

default-bind [param*]
Defines the binding parameters for the local peer, excepted its address.
주소를 제외한 로컬 피어에 대한 바인딩 매개변수를 정의합니다.

default-server [param*]
Change default options for a server in a "peers" section.
"peers" 섹션에서 서버의 기본 옵션을 변경합니다.

Arguments:
<param*> is a list of parameters for this server. The "default-server"
keyword accepts an important number of options and has a complete
section dedicated to it. In a peers section, the transport
parameters of a "default-server" line are supported. Please refer
to section 5 for more details, and the "server" keyword below in
this section for some of the restrictions.

<param*>은 이 서버의 매개변수 목록입니다.
"default-server" 키워드는 중요한 수의 옵션을 허용하며 전용 섹션이 있습니다.
피어 섹션에서 "default-server" 라인의 전송 매개변수가 지원됩니다.
자세한 내용은 섹션 5를 참조하고 일부 제한 사항은 이 섹션 아래의 "server" 키워드를
참조하십시오.

See also: "server" and section 5 about server options

enabled
This re-enables a peers section which was previously disabled via the
"disabled" keyword.
이렇게 하면 이전에 "disabled" 키워드를 통해 비활성화되었던 피어 섹션이
다시 활성화됩니다.

log <address> [len <length>] [format <format>] [sample <ranges>:<sample_size>]
<facility> [<level> [<minlevel>]]
"peers" sections support the same "log" keyword as for the proxies to
log information about the "peers" listener. See "log" option for proxies for
more details.
"peers" 섹션은 프록시가 "peers" 수신기에 대한 정보를 기록하는 것과 동일한
"log" 키워드를 지원합니다. 자세한 내용은 프록시에 대한 "log" 옵션을 참조하십시오.

peer <peername> <ip>:<port> [param*]
Defines a peer inside a peers section.
If <peername> is set to the local peer name (by default hostname, or forced
using "-L" command line option or "localpeer" global configuration setting),
HAProxy will listen for incoming remote peer connection on <ip>:<port>.
Otherwise, <ip>:<port> defines where to connect to in order to join the
remote peer, and <peername> is used at the protocol level to identify and
validate the remote peer on the server side.

peers 섹션 내에서 피어를 정의합니다.
<peername>이 로컬 피어 이름(기본 호스트 이름으로 설정되거나 "-L" 명령줄 옵션
또는 "localpeer" 전역 구성 설정을 사용하여 강제됨)으로 설정된 경우 HAProxy는
<ip>:<포트>에서 들어오는 원격 피어 연결을 수신 대기합니다.
그렇지 않으면 <ip>:<port>는 원격 피어에 가입하기 위해 연결할 위치를 정의하고
<peername>은 서버 측에서 원격 피어를 식별하고 유효성을 검사하기 위해 프로토콜
수준에서 사용됩니다.

During a soft restart, local peer <ip>:<port> is used by the old instance to
connect the new one and initiate a complete replication (teaching process).
소프트 재시작 동안 이전 인스턴스는 로컬 피어 <ip>:<port>를 사용하여 새 인스턴스를
연결하고 전체 복제를 시작합니다(학습 프로세스).

It is strongly recommended to have the exact same peers declaration on all
peers and to only rely on the "-L" command line argument or the "localpeer"
global configuration setting to change the local peer name. This makes it
easier to maintain coherent configuration files across all peers.

모든 피어에서 정확히 동일한 피어 선언을 사용하고 "-L" 명령줄 인수 또는
"localpeer" 전역 구성 설정에만 의존하여 로컬 피어 이름을 변경하는 것이 좋습니다.
이렇게 하면 모든 피어에서 일관된 구성 파일을 보다 쉽게 유지할 수 있습니다.

Note: "peer" keyword may transparently be replaced by "server" keyword (see
"server" keyword explanation below).
참고: "peer" 키워드는 "server" 키워드로 투명하게 대체될 수 있습니다
(아래 "server" 키워드 설명 참조).

server <peername> [<ip>:<port>] [param*]
As previously mentioned, "peer" keyword may be replaced by "server" keyword
with a support for all "server" parameters found in 5.2 paragraph that are
related to transport settings. If the underlying peer is local, <ip>:<port>
parameters must not be present; these parameters must be provided on a "bind"
line (see "bind" keyword of this "peers" section).

이전에 언급한 것처럼 "peer" 키워드는 전송 설정과 관련된 5.2 단락에 있는
모든 "server" 매개변수를 지원하는 "server" 키워드로 대체될 수 있습니다.
기본 피어가 로컬인 경우 <ip>:<port> 매개변수가 없어야 합니다.
이러한 매개변수는 "bind" 줄에 제공되어야 합니다(이 "peers" 섹션의 "bind" 키워드 참조).

A number of "server" parameters are irrelevant for "peers" sections. Peers by
nature do not support dynamic host name resolution nor health checks, hence
parameters like "init_addr", "resolvers", "check", "agent-check", or "track"
are not supported. Similarly, there is no load balancing nor stickiness, thus
parameters such as "weight" or "cookie" have no effect.

많은 "server" 매개변수는 "peers" 섹션과 관련이 없습니다.
본질적으로 피어는 동적 호스트 이름 확인이나 상태 확인을 지원하지 않으므로
"init_addr", "resolvers", "check", "agent-check" 또는 "track"과 같은 매개변수는 지원되지 않습니다.
마찬가지로 로드 밸런싱이나 고정성이 없으므로 "가중치" 또는 "쿠키"와 같은 매개변수가
영향을 미치지 않습니다.

  Example:
    # The old way.
    peers mypeers
        peer haproxy1 192.168.0.1:1024
        peer haproxy2 192.168.0.2:1024
        peer haproxy3 10.2.0.1:1024

    backend mybackend
        mode tcp
        balance roundrobin
        stick-table type ip size 20k peers mypeers
        stick on src

        server srv1 192.168.0.30:80
        server srv2 192.168.0.31:80

   Example:
     peers mypeers
        bind 192.168.0.1:1024 ssl crt mycerts/pem
        default-server ssl verify none
        server haproxy1 #local peer
        server haproxy2 192.168.0.2:1024
        server haproxy3 10.2.0.1:1024

table <tablename> type {ip | integer | string [len <length>] | binary [len <length>]}
      size <size> [expire <expire>] [nopurge] [store <data_type>]*
  Configure a stickiness table for the current section. This line is parsed
  exactly the same way as the "stick-table" keyword in others section, except
  for the "peers" argument which is not required here and with an additional
  mandatory first parameter to designate the stick-table. Contrary to others
  sections, there may be several "table" lines in "peers" sections (see also
  "stick-table" keyword).	

  현재 섹션에 대한 고정 테이블을 구성합니다.
  이 행은 여기에서 필요하지 않은 "peers" 인수와 스틱 테이블을 지정하기 위한 추가 
  필수 첫 번째 매개 변수를 제외하고 다른 섹션의 "스틱 테이블" 키워드와 정확히 동일한 
  방식으로 구문 분석됩니다.
  다른 섹션과 달리 "peers" 섹션에는 여러 "table" 줄이 있을 수 있습니다("stick-table" 키워드 참조).
	
  Also be aware of the fact that "peers" sections have their own stick-table
  namespaces to avoid collisions between stick-table names identical in
  different "peers" section. This is internally handled prepending the "peers"
  sections names to the name of the stick-tables followed by a '/' character.
  If somewhere else in the configuration file you have to refer to such
  stick-tables declared in "peers" sections you must use the prefixed version
  of the stick-table name as follows:	
  
  또한 "peers" 섹션에는 서로 다른 "peers" 섹션에서 동일한 스틱 테이블 이름 간의 충돌을 
  피하기 위해 자체 스틱 테이블 네임스페이스가 있다는 사실에 유의하십시오.
  이것은 스틱 테이블의 이름 뒤에 '/' 문자가 오는 "peers" 섹션 이름 앞에 추가하여 내부적으로 
  처리됩니다.  구성 파일의 다른 위치에서 "peers" 섹션에 선언된 스틱 테이블을 참조해야 하는 
  경우 다음과 같이 스틱 테이블 이름의 접두사가 붙은 버전을 사용해야 합니다.

      peers mypeers
          peer A ...
          peer B ...
          table t1 ...

      frontend fe1
          tcp-request content track-sc0 src table mypeers/t1

  This is also this prefixed version of the stick-table names which must be
  used to refer to stick-tables through the CLI.
  또한 CLI를 통해 스틱 테이블을 참조하는 데 사용해야 하는 스틱 테이블 이름의 
  이 접두사 버전입니다.  
	
  About "peers" protocol, as only "peers" belonging to the same section may
  communicate with each others, there is no need to do such a distinction.
  Several "peers" sections may declare stick-tables with the same name.
  This is shorter version of the stick-table name  which is sent over the network.
  There is only a '/' character as prefix to avoid stick-table name collisions between
  stick-tables declared as backends and stick-table declared in "peers" sections
  as follows in this weird but supported configuration:

  "peers" 프로토콜에 대해서는 같은 섹션에 속한 "peer"만이 서로 통신할 수 있으므로 
  이러한 구분을 할 필요가 없습니다.
  여러 "peers" 섹션이 동일한 이름의 스틱 테이블을 선언할 수 있습니다.
  이것은 네트워크를 통해 전송되는 스틱 테이블 이름의 짧은 버전입니다.
  이 이상하지만 지원되는 구성에서 다음과 같이 백엔드로 선언된 스틱 테이블과 "peers" 
  섹션에서 선언된 스틱 테이블 사이의 스틱 테이블 이름 충돌을 방지하기 위해 접두사로 
  '/' 문자만 있습니다.

      peers mypeers
          peer A ...
          peer B ...
          table t1 type string size 10m store gpc0

      backend t1
          stick-table type string size 10m store gpc0 peers mypeers

  Here "t1" table declared in "mypeers" section has "mypeers/t1" as global name.
  "t1" table declared as a backend as "t1" as global name. But at peer protocol
  level the former table is named "/t1", the latter is again named "t1".

  여기서 "mypeers" 섹션에 선언된 "t1" 테이블은 전역 이름으로 "mypeers/t1"을 갖습니다.
  글로벌 이름으로 "t1"로 백엔드로 선언된 "t1" 테이블.
  그러나 피어 프로토콜 수준에서 전자 테이블의 이름은 "/t1"이고 후자의 이름은 다시 "t1"입니다.

3.6. Mailers

It is possible to send email alerts when the state of servers changes.
If configured email alerts are sent to each mailer that is configured
in a mailers section. Email is sent to mailers using SMTP.	

서버 상태가 변경되면 이메일 알림을 보낼 수 있습니다.
구성된 경우 메일러 섹션에 구성된 각 메일러로 이메일 경고가 전송됩니다.
이메일은 SMTP를 사용하여 메일러로 전송됩니다.
	
mailers <mailersect>	
  Creates a new mailer list with the name <mailersect>. It is an
  independent section which is referenced by one or more proxies.	
  <mailersect>라는 이름으로 새 메일러 목록을 만듭니다. 
  하나 이상의 프록시가 참조하는 독립 섹션입니다.
	
mailer <mailername> <ip>:<port>	
  Defines a mailer inside a mailers section.	
  메일러 섹션 내에서 메일러를 정의합니다.

  Example:
    mailers mymailers
        mailer smtp1 192.168.0.1:587
        mailer smtp2 192.168.0.2:587

    backend mybackend
        mode tcp
        balance roundrobin

        email-alert mailers mymailers
        email-alert from test1@horms.org
        email-alert to test2@horms.org

        server srv1 192.168.0.30:80
        server srv2 192.168.0.31:80

timeout mail <time>
  Defines the time available for a mail/connection to be made and send to
  the mail-server. If not defined the default value is 10 seconds. To allow
  for at least two SYN-ACK packets to be send during initial TCP handshake it
  is advised to keep this value above 4 seconds.

  메일/연결을 만들고 메일 서버로 보낼 수 있는 시간을 정의합니다.
  정의되지 않은 경우 기본값은 10초입니다.
  초기 TCP 핸드셰이크 중에 적어도 두 개의 SYN-ACK 패킷을 보낼 수 있도록 하려면 
  이 값을 4초 이상으로 유지하는 것이 좋습니다.

  Example:
    mailers mymailers
        timeout mail 20s
        mailer smtp1 192.168.0.1:587

3.7. Programs

In master-worker mode, it is possible to launch external binaries with the
master, these processes are called programs. These programs are launched and
managed the same way as the workers.

마스터-작업자 모드에서는 마스터와 함께 외부 바이너리를 시작할 수 있으며
이러한 프로세스를 프로그램이라고 합니다.
이러한 프로그램은 작업자와 동일한 방식으로 시작되고 관리됩니다.

During a reload of HAProxy, those processes are dealing with the same
sequence as a worker:

- the master is re-executed
- the master sends a SIGUSR1 signal to the program
- if "option start-on-reload" is not disabled, the master launches a new
instance of the program

HAProxy를 다시 로드하는 동안 해당 프로세스는 작업자와 동일한 시퀀스를 처리합니다.
- 마스터가 다시 실행됩니다.
- 마스터는 SIGUSR1 신호를 프로그램에 보냅니다.
- "option start-on-reload"가 비활성화되지 않은 경우 마스터는 프로그램의 새 인스턴스를
시작합니다.

During a stop, or restart, a SIGTERM is sent to the programs.
중지 또는 재시작 중에 SIGTERM이 프로그램으로 전송됩니다.

program <name>
This is a new program section, this section will create an instance <name>
which is visible in "show proc" on the master CLI. (See "9.4. Master CLI" in
the management guide).
이것은 새로운 프로그램 섹션이며, 이 섹션은 마스터 CLI의 "show proc"에서 볼 수 있는
인스턴스 <name>을 생성합니다. (관리 가이드의 "9.4. Master CLI" 참조).

command <command> [arguments*]
Define the command to start with optional arguments. The command is looked
up in the current PATH if it does not include an absolute path. This is a
mandatory option of the program section. Arguments containing spaces must
be enclosed in quotes or double quotes or be prefixed by a backslash.

선택적 인수로 시작할 명령을 정의하십시오.
명령이 절대 경로를 포함하지 않는 경우 현재 PATH에서 조회됩니다.
이것은 프로그램 섹션의 필수 옵션입니다.
공백이 포함된 인수는 따옴표 또는 큰따옴표로 묶거나 백슬래시로 시작해야 합니다.

user <user name>
Changes the executed command user ID to the <user name> from /etc/passwd.
실행된 명령 사용자 ID를 /etc/passwd에서 <user name>으로 변경합니다.
See also "group".

group <group name>
Changes the executed command group ID to the <group name> from /etc/group.
실행된 명령 그룹 ID를 /etc/group에서 <group name>으로 변경합니다.
See also "user".

option start-on-reload
no option start-on-reload
Start (or not) a new instance of the program upon a reload of the master.
The default is to start a new instance. This option may only be used in a
program section.
마스터를 다시 로드하면 프로그램의 새 인스턴스를 시작하거나 시작하지 않습니다.
기본값은 새 인스턴스를 시작하는 것입니다. 이 옵션은 프로그램 섹션에서만 사용할 수 있습니다.

3.8. HTTP-errors

It is possible to globally declare several groups of HTTP errors, to be
imported afterwards in any proxy section. Same group may be referenced at
several places and can be fully or partially imported.

프록시 섹션에서 나중에 가져올 여러 HTTP 오류 그룹을 전역적으로 선언할 수 있습니다.
동일한 그룹은 여러 위치에서 참조될 수 있으며 전체 또는 부분적으로 가져올 수 있습니다.

http-errors <name>
Create a new http-errors group with the name <name>. It is an independent
section that may be referenced by one or more proxies using its name.
이름이 <name>인 새 http-errors 그룹을 만듭니다.
이름을 사용하여 하나 이상의 프록시에서 참조할 수 있는 독립적인 섹션입니다.

errorfile <code> <file>
Associate a file contents to an HTTP error code
파일 내용을 HTTP 오류 코드에 연결

Arguments :
<code> is the HTTP status code. Currently, HAProxy is capable of
generating codes 200, 400, 401, 403, 404, 405, 407, 408, 410,
425, 429, 500, 501, 502, 503, and 504.

<file> designates a file containing the full HTTP response. It is
recommended to follow the common practice of appending ".http" to
the filename so that people do not confuse the response with HTML
error pages, and to use absolute paths, since files are read
before any chroot is performed.
<file>은 전체 HTTP 응답을 포함하는 파일을 지정합니다.
사람들이 응답을 HTML 오류 페이지와 혼동하지 않도록 파일 이름에
".http"를 추가하는 일반적인 방법을 따르고 chroot가 수행되기 전에 파일을
읽으므로 절대 경로를 사용하는 것이 좋습니다.

Please referrers to "errorfile" keyword in section 4 for details.
자세한 내용은 섹션 4의 "errorfile" 키워드를 참조하십시오.

  Example:
    http-errors website-1
        errorfile 400 /etc/haproxy/errorfiles/site1/400.http
        errorfile 404 /etc/haproxy/errorfiles/site1/404.http
        errorfile 408 /dev/null  # work around Chrome pre-connect bug

    http-errors website-2
        errorfile 400 /etc/haproxy/errorfiles/site2/400.http
        errorfile 404 /etc/haproxy/errorfiles/site2/404.http
        errorfile 408 /dev/null  # work around Chrome pre-connect bug

3.9. Rings

It is possible to globally declare ring-buffers, to be used as target for log
servers or traces.
로그 서버 또는 추적의 대상으로 사용할 링 버퍼를 전역적으로 선언할 수 있습니다.

ring <ringname>
Creates a new ring-buffer with name <ringname>.
이름이 <ringname>인 새 링 버퍼를 생성합니다.

backing-file <path>
This replaces the regular memory allocation by a RAM-mapped file to store the
ring. This can be useful for collecting traces or logs for post-mortem
analysis, without having to attach a slow client to the CLI. Newer contents
will automatically replace older ones so that the latest contents are always
available. The contents written to the ring will be visible in that file once
the process stops (most often they will even be seen very soon after but
there is no such guarantee since writes are not synchronous).

이는 링을 저장하기 위해 일반 메모리 할당을 RAM 매핑된 파일로 대체합니다.
이는 느린 클라이언트를 CLI에 연결할 필요 없이 사후 분석을 위한 추적 또는 로그를
수집하는 데 유용할 수 있습니다.
최신 콘텐츠가 자동으로 이전 콘텐츠를 대체하므로 항상 최신 콘텐츠를 사용할 수 있습니다.
링에 기록된 내용은 프로세스가 중지되면 해당 파일에서 볼 수 있습니다
(대부분의 경우 바로 볼 수 있지만 쓰기가 동기적이지 않기 때문에 그러한 보장은 없습니다).

When this option is used, the total storage area is reduced by the size of
the "struct ring" that starts at the beginning of the area, and that is
required to recover the area's contents. The file will be created with the
starting user's ownership, with mode 0600 and will be of the size configured
by the "size" directive. When the directive is parsed (thus even during
config checks), any existing non-empty file will first be renamed with the
extra suffix ".bak", and any previously existing file with suffix ".bak" will
be removed. This ensures that instant reload or restart of the process will
not wipe precious debugging information, and will leave time for an admin to
spot this new ".bak" file and to archive it if needed. As such, after a crash
the file designated by <path> will contain the freshest information, and if
the service is restarted, the "<path>.bak" file will have it instead. This
means that the total storage capacity required will be double of the ring
size. Failures to rotate the file are silently ignored, so placing the file
into a directory without write permissions will be sufficient to avoid the
backup file if not desired.

이 옵션을 사용하면 영역의 시작 부분에서 시작하고 영역의 내용을 복구하는 데 필요한
"struct ring"의 크기만큼 전체 저장 영역이 줄어듭니다.
파일은 시작 사용자의 소유권, 모드 0600으로 생성되며 "size" 지시문에 의해 구성된
크기가 됩니다. 지시문이 구문 분석되면(따라서 구성 검사 중에도) 비어 있지 않은
기존 파일은 먼저 추가 접미사 ".bak"로 이름이 바뀌고 접미사가 ".bak"인 기존 파일은 제거됩니다.
이렇게 하면 프로세스를 즉시 다시 로드하거나 다시 시작해도 귀중한 디버깅 정보가
지워지지 않고 관리자가 이 새로운 ".bak" 파일을 찾아 필요한 경우 보관할 시간을 남길 수 있습니다.
따라서 충돌 후 <path>로 지정된 파일에는 가장 최신 정보가 포함되며 서비스가
다시 시작되면 "<path>.bak" 파일에 최신 정보가 포함됩니다.
이는 필요한 총 저장 용량이 링 크기의 두 배가 된다는 것을 의미합니다.
파일 회전 실패는 자동으로 무시되므로 쓰기 권한이 없는 디렉터리에 파일을 배치하면
원하지 않는 경우 백업 파일을 피할 수 있습니다.

WARNING: there are stability and security implications in using this feature.
First, backing the ring to a slow device (e.g. physical hard drive) may cause
perceptible slowdowns during accesses, and possibly even panics if too many
threads compete for accesses. Second, an external process modifying the area
could cause the haproxy process to crash or to overwrite some of its own
memory with traces. Third, if the file system fills up before the ring,
writes to the ring may cause the process to crash.

경고: 이 기능을 사용하면 안정성과 보안에 영향을 미칩니다.
첫째, 링을 느린 장치(예: 물리적 하드 드라이브)에 백업하면 액세스 중에 감지할 수 있는
속도 저하가 발생할 수 있으며 너무 많은 스레드가 액세스를 위해 경쟁하는 경우 패닉이
발생할 수도 있습니다.
둘째, 영역을 수정하는 외부 프로세스로 인해 haproxy 프로세스가 충돌하거나 자체 메모리의
일부를 추적으로 덮어쓸 수 있습니다.
셋째, 파일 시스템이 링보다 먼저 가득 차면 링에 쓰기 작업을 수행하면 프로세스가
중단될 수 있습니다.

The information present in this ring are structured and are NOT directly
readable using a text editor (even though most of it looks barely readable).
The output of this file is only intended for developers.
이 링에 있는 정보는 구조화되어 있으며 텍스트 편집기를 사용하여 직접 읽을 수
없습니다(대부분은 거의 읽을 수 없는 것처럼 보이지만).
이 파일의 출력은 개발자 전용입니다.

description <text>
The description is an optional description string of the ring. It will
appear on CLI. By default, <name> is reused to fill this field.
설명은 링의 선택적 설명 문자열입니다.
CLI에 나타납니다. 기본적으로 <name>은 이 필드를 채우는 데 재사용됩니다.

format <format>
Format used to store events into the ring buffer.
이벤트를 링 버퍼에 저장하는 데 사용되는 형식입니다.

Arguments:
<format> is the log format used when generating syslog messages. It may be
one of the following :

iso A message containing only the ISO date, followed by the text.
The PID, process name and system name are omitted. This is
designed to be used with a local log server.

local Analog to rfc3164 syslog message format except that hostname
field is stripped. This is the default.
Note: option "log-send-hostname" switches the default to
rfc3164.

rfc3164 The RFC3164 syslog message format.
(https://tools.ietf.org/html/rfc3164)
https://tools.ietf.org/html/rfc3164

rfc5424 The RFC5424 syslog message format.
(https://tools.ietf.org/html/rfc5424)
https://tools.ietf.org/html/rfc5424

maxlen <length>
The maximum length of an event message stored into the ring,
including formatted header. If an event message is longer than
<length>, it will be truncated to this length.
포맷된 헤더를 포함하여 링에 저장되는 이벤트 메시지의 최대 길이입니다.
이벤트 메시지가 <length>보다 길면 이 길이로 잘립니다.

server <name> <address> [param*]
Used to configure a syslog tcp server to forward messages from ring buffer.
This supports for all "server" parameters found in 5.2 paragraph. Some of
these parameters are irrelevant for "ring" sections. Important point: there
is little reason to add more than one server to a ring, because all servers
will receive the exact same copy of the ring contents, and as such the ring
will progress at the speed of the slowest server. If one server does not
respond, it will prevent old messages from being purged and may block new
messages from being inserted into the ring. The proper way to send messages
to multiple servers is to use one distinct ring per log server, not to
attach multiple servers to the same ring. Note that specific server directive
"log-proto" is used to set the protocol used to send messages.

링 버퍼에서 메시지를 전달하도록 syslog tcp 서버를 구성하는 데 사용됩니다.
이는 5.2 단락에 있는 모든 "server" 매개변수를 지원합니다.
이러한 매개변수 중 일부는 "ring" 섹션과 관련이 없습니다.
중요한 점: 모든 서버가 링 내용의 정확히 동일한 복사본을 수신하므로 링이 가장
느린 서버의 속도로 진행되기 때문에 하나 이상의 서버를 링에 추가할 이유가 거의 없습니다.
한 서버가 응답하지 않으면 이전 메시지가 제거되지 않고 새 메시지가 링에 삽입되지
않을 수 있습니다.
여러 서버에 메시지를 보내는 올바른 방법은 여러 서버를 동일한 링에 연결하는 것이
아니라 로그 서버당 하나의 고유한 링을 사용하는 것입니다.
특정 서버 지시문 "log-proto"는 메시지를 보내는 데 사용되는 프로토콜을 설정하는 데 사용됩니다.

size <size>
This is the optional size in bytes for the ring-buffer. Default value is
set to BUFSIZE.
이는 링 버퍼의 선택적 크기(바이트)입니다. 기본값은 BUFSIZE로 설정됩니다.

timeout connect <timeout>
Set the maximum time to wait for a connection attempt to a server to succeed.
서버에 대한 연결 시도가 성공할 때까지 대기하는 최대 시간을 설정합니다.

Arguments :
<timeout> is the timeout value specified in milliseconds by default, but
can be in any other unit if the number is suffixed by the unit,
as explained at the top of this document.
<timeout>은 기본적으로 밀리초 단위로 지정된 타임아웃 값이지만 이 문서 상단에
설명된 대로 숫자 뒤에 단위가 붙으면 다른 단위가 될 수 있습니다.

timeout server <timeout>
Set the maximum time for pending data staying into output buffer.
보류 중인 데이터가 출력 버퍼에 머무는 최대 시간을 설정합니다.

Arguments :
<timeout> is the timeout value specified in milliseconds by default, but
can be in any other unit if the number is suffixed by the unit,
as explained at the top of this document.
<timeout>은 기본적으로 밀리초 단위로 지정된 타임아웃 값이지만 이 문서
상단에 설명된 대로 숫자 뒤에 단위가 붙으면 다른 단위가 될 수 있습니다.

  Example:
    global
        log ring@myring local7

    ring myring
        description "My local buffer"
        format rfc3164
        maxlen 1200
        size 32764
        timeout connect 5s
        timeout server 10s
        server mysyslogsrv 127.0.0.1:6514 log-proto octet-count

3.10. Log forwarding

It is possible to declare one or multiple log forwarding section,
HAProxy will forward all received log messages to a log servers list.
하나 또는 여러 개의 로그 전달 섹션을 선언할 수 있으며 HAProxy는 수신된 모든 로그
메시지를 로그 서버 목록으로 전달합니다.

log-forward <name>
Creates a new log forwarder proxy identified as <name>.
<name>으로 식별되는 새 로그 전달자 프록시를 생성합니다.

backlog <conns>
Give hints to the system about the approximate listen backlog desired size
on connections accept.
연결 수락 시 원하는 대략적인 수신 백로그 크기에 대한 힌트를 시스템에 제공합니다.

bind <addr> [param*]
Used to configure a stream log listener to receive messages to forward.
This supports the "bind" parameters found in 5.1 paragraph including
those about ssl but some statements such as "alpn" may be irrelevant for
syslog protocol over TCP.
Those listeners support both "Octet Counting" and "Non-Transparent-Framing"
modes as defined in rfc-6587.

전달할 메시지를 수신하도록 스트림 로그 수신기를 구성하는 데 사용됩니다.
이는 ssl에 대한 매개변수를 포함하여 5.1 단락에 있는 "bind" 매개변수를 지원하지만
"alpn"과 같은 일부 명령문은 TCP를 통한 syslog 프로토콜과 관련이 없을 수 있습니다.
이러한 리스너는 rfc-6587에 정의된 대로 "Octet Counting" 및 "Non-Transparent-Framing"
모드를 모두 지원합니다.

dgram-bind <addr> [param*]
Used to configure a datagram log listener to receive messages to forward.
Addresses must be in IPv4 or IPv6 form,followed by a port. This supports
for some of the "bind" parameters found in 5.1 paragraph among which
"interface", "namespace" or "transparent", the other ones being
silently ignored as irrelevant for UDP/syslog case.

전달할 메시지를 수신하도록 데이터그램 로그 수신기를 구성하는 데 사용됩니다.
주소는 IPv4 또는 IPv6 형식이어야 하며 뒤에 포트가 와야 합니다.
이것은 "interface", "namespace" 또는 "transparent" 중에서 5.1 단락에 있는
"bind" 매개변수 중 일부를 지원하며, 다른 매개변수는 UDP/syslog 사례와 관련이
없으므로 자동으로 무시됩니다.

log global
log <address> [len <length>] [format <format>] [sample <ranges>:<sample_size>]
<facility> [<level> [<minlevel>]]
Used to configure target log servers. See more details on proxies
documentation.
If no format specified, HAProxy tries to keep the incoming log format.
Configured facility is ignored, except if incoming message does not
present a facility but one is mandatory on the outgoing format.
If there is no timestamp available in the input format, but the field
exists in output format, HAProxy will use the local date.

대상 로그 서버를 구성하는 데 사용됩니다.
프록시 설명서에 대한 자세한 내용을 참조하십시오.
형식이 지정되지 않은 경우 HAProxy는 들어오는 로그 형식을 유지하려고 시도합니다.
수신 메시지에 기능이 표시되지 않지만 나가는 형식에서 필수인 경우를 제외하고 구성된
기능은 무시됩니다.
입력 형식에 사용 가능한 타임스탬프가 없지만 필드가 출력 형식에 있는 경우 HAProxy는
현지 날짜를 사용합니다.

  Example:
    global
       log stderr format iso local7

    ring myring
        description "My local buffer"
        format rfc5424
        maxlen 1200
        size 32764
        timeout connect 5s
        timeout server 10s
        # syslog tcp server
        server mysyslogsrv 127.0.0.1:514 log-proto octet-count

    log-forward sylog-loadb
        dgram-bind 127.0.0.1:1514
        bind 127.0.0.1:1514
        # all messages on stderr
        log global
        # all messages on local tcp syslog server
        log ring@myring local0
        # load balance messages on 4 udp syslog servers
        log 127.0.0.1:10001 sample 1:4 local0
        log 127.0.0.1:10002 sample 2:4 local0
        log 127.0.0.1:10003 sample 3:4 local0
        log 127.0.0.1:10004 sample 4:4 local0

maxconn <conns>	
  Fix the maximum number of concurrent connections on a log forwarder.
  10 is the default.	
  로그 전달자에서 최대 동시 연결 수를 수정합니다.   10이 기본값입니다.
	
timeout client <timeout>	
  Set the maximum inactivity time on the client side.	
  클라이언트 측에서 최대 비활성 시간을 설정합니다.

4. Proxies

Proxy configuration can be located in a set of sections :
프록시 구성은 일련의 섹션에서 찾을 수 있습니다.
- defaults [<name>] [ from <defaults_name> ]
- frontend <name> [ from <defaults_name> ]
- backend <name> [ from <defaults_name> ]
- listen <name> [ from <defaults_name> ]

A "frontend" section describes a set of listening sockets accepting client
connections.
"frontend" 섹션은 클라이언트 연결을 수락하는 청취 소켓 세트를 설명합니다.

A "backend" section describes a set of servers to which the proxy will connect
to forward incoming connections.
"backend" 섹션은 들어오는 연결을 전달하기 위해 프록시가 연결할 서버 집합을 설명합니다.

A "listen" section defines a complete proxy with its frontend and backend
parts combined in one section. It is generally useful for TCP-only traffic.
"listen" 섹션은 프런트엔드 및 백엔드 부분이 하나의 섹션에 결합된 완전한 프록시를 정의합니다.
일반적으로 TCP 전용 트래픽에 유용합니다.

A "defaults" section resets all settings to the documented ones and presets new
ones for use by subsequent sections. All of "frontend", "backend" and "listen"
sections always take their initial settings from a defaults section, by default
the latest one that appears before the newly created section. It is possible to
explicitly designate a specific "defaults" section to load the initial settings
from by indicating its name on the section line after the optional keyword
"from". While "defaults" section do not impose a name, this use is encouraged
for better readability. It is also the only way to designate a specific section
to use instead of the default previous one. Since "defaults" section names are
optional, by default a very permissive check is applied on their name and these
are even permitted to overlap. However if a "defaults" section is referenced by
any other section, its name must comply with the syntax imposed on all proxy
names, and this name must be unique among the defaults sections. Please note
that regardless of what is currently permitted, it is recommended to avoid
duplicate section names in general and to respect the same syntax as for proxy
names. This rule might be enforced in a future version. In addition, a warning
is emitted if a defaults section is explicitly used by a proxy while it is also
implicitly used by another one because it is the last one defined. It is highly
encouraged to not mix both usages by always using explicit references or by
adding a last common defaults section reserved for all implicit uses.

"defaults" 섹션은 모든 설정을 문서화된 설정으로 재설정하고 후속 섹션에서 사용할
새 설정을 미리 설정합니다.
모든 "frontend", "backend" 및 "listen" 섹션은 항상 기본 섹션에서 초기 설정을 가져옵니다.
기본적으로 새로 생성된 섹션 앞에 나타나는 최신 섹션입니다.
선택적 키워드 "from" 뒤에 섹션 행에 해당 이름을 표시하여 초기 설정을 로드할 특정
"defaults" 섹션을 명시적으로 지정할 수 있습니다.
"defaults" 섹션은 이름을 지정하지 않지만 가독성을 높이기 위해 이렇게 사용하는 것이 좋습니다.
또한 기본 이전 섹션 대신 사용할 특정 섹션을 지정하는 유일한 방법입니다.
"defaults" 섹션 이름은 선택 사항이므로 기본적으로 이름에 매우 관대한 검사가 적용되며 겹치는
것도 허용됩니다.
그러나 "defaults" 섹션이 다른 섹션에서 참조되는 경우 해당 이름은 모든 프록시 이름에 지정된
구문을 준수해야 하며 이 이름은 defaults 섹션 간에 고유해야 합니다.
현재 허용되는 내용에 관계없이 일반적으로 중복 섹션 이름을 피하고 프록시 이름과 동일한
구문을 존중하는 것이 좋습니다.
이 규칙은 향후 버전에서 시행될 수 있습니다.
또한 defaults 섹션이 프록시에서 명시적으로 사용되는 동안 다른 섹션이 마지막으로 정의되었기
때문에 묵시적으로 사용되는 경우 경고가 발생합니다.
항상 명시적 참조를 사용하거나 모든 암시적 사용을 위해 예약된 마지막 공통 기본값 섹션을
추가하여 두 가지 사용을 혼합하지 않는 것이 좋습니다.

Note that it is even possible for a defaults section to take its initial
settings from another one, and as such, inherit settings across multiple levels
of defaults sections. This can be convenient to establish certain configuration
profiles to carry groups of default settings (e.g. TCP vs HTTP or short vs long
timeouts) but can quickly become confusing to follow.

기본 섹션이 다른 섹션에서 초기 설정을 가져와 여러 수준의 기본 섹션에서 설정을
상속하는 것도 가능합니다.
이는 기본 설정 그룹(예: TCP 대 HTTP 또는 짧은 시간 대 긴 시간 제한)을 전달하기 위해
특정 구성 프로필을 설정하는 데 편리할 수 있지만 따라가기가 금방 혼란스러워질 수 있습니다.

All proxy names must be formed from upper and lower case letters, digits,
'-' (dash), '_' (underscore) , '.' (dot) and ':' (colon). ACL names are
case-sensitive, which means that "www" and "WWW" are two different proxies.

모든 프록시 이름은 대문자와 소문자, 숫자, '-'(대시), '_'(밑줄), '.'(점) 및 ':'(콜론)로 구성되어야 합니다.
ACL 이름은 대소문자를 구분합니다. 즉, "www"와 "WWW"는 서로 다른 두 프록시입니다.

Historically, all proxy names could overlap, it just caused troubles in the
logs. Since the introduction of content switching, it is mandatory that two
proxies with overlapping capabilities (frontend/backend) have different names.
However, it is still permitted that a frontend and a backend share the same
name, as this configuration seems to be commonly encountered.

과거에는 모든 프록시 이름이 겹칠 수 있었고 이로 인해 로그에 문제가 발생했습니다.
콘텐츠 전환 도입 이후 기능이 겹치는 두 개의 프록시(프론트엔드/백엔드)는 서로 다른
이름을 사용해야 합니다.
그러나 프런트엔드와 백엔드가 동일한 이름을 공유하는 것은 여전히 허용됩니다.
이 구성은 일반적으로 발생하는 것으로 보입니다.

Right now, two major proxy modes are supported : "tcp", also known as layer 4,
and "http", also known as layer 7. In layer 4 mode, HAProxy simply forwards
bidirectional traffic between two sides. In layer 7 mode, HAProxy analyzes the
protocol, and can interact with it by allowing, blocking, switching, adding,
modifying, or removing arbitrary contents in requests or responses, based on
arbitrary criteria.

현재 두 가지 주요 프록시 모드가 지원됩니다.
계층 4라고도 하는 "tcp" 및 계층 7이라고도 하는 "http".
레이어 4 모드에서 HAProxy는 단순히 양측 간에 양방향 트래픽을 전달합니다.
레이어 7 모드에서 HAProxy는 프로토콜을 분석하고 임의의 기준에 따라 요청 또는
응답에서 임의의 콘텐츠를 허용, 차단, 전환, 추가, 수정 또는 제거하여 프로토콜과
상호 작용할 수 있습니다.

In HTTP mode, the processing applied to requests and responses flowing over
a connection depends in the combination of the frontend's HTTP options and
the backend's. HAProxy supports 3 connection modes :

HTTP 모드에서 연결을 통해 흐르는 요청 및 응답에 적용되는 처리는 프런트엔드의
HTTP 옵션과 백엔드의 조합에 따라 다릅니다.
HAProxy는 3가지 연결 모드를 지원합니다.

- KAL : keep alive ("option http-keep-alive") which is the default mode : all
requests and responses are processed, and connections remain open but idle
between responses and new requests.
- KAL: 기본 모드인 연결 유지("option http-keep-alive"): 모든 요청과 응답이 처리되고
연결은 열려 있지만 응답과 새 요청 사이에는 유휴 상태로 유지됩니다.

- SCL: server close ("option http-server-close") : the server-facing
connection is closed after the end of the response is received, but the
client-facing connection remains open.
- SCL: 서버 닫기("option http-server-close"): 서버 쪽 연결은 응답의 끝이 수신된 후
닫히지만 클라이언트 쪽 연결은 열린 상태로 유지됩니다.

- CLO: close ("option httpclose"): the connection is closed after the end of
the response and "Connection: close" appended in both directions.
- CLO: 닫기("option httpclose"): 응답이 끝나면 연결이 닫히고 양방향으로
"Connection: close"가 추가됩니다.

The effective mode that will be applied to a connection passing through a
frontend and a backend can be determined by both proxy modes according to the
following matrix, but in short, the modes are symmetric, keep-alive is the
weakest option and close is the strongest.

프런트엔드와 백엔드를 통과하는 연결에 적용될 유효 모드는 다음 매트릭스에 따라
두 프록시 모드에 의해 결정될 수 있습니다.
그러나 간단히 말해서 모드는 대칭이며 연결 유지가 가장 약한 옵션이며 닫기가 가장 강력합니다.

                   Backend mode

                | KAL | SCL | CLO
            ----+-----+-----+----
            KAL | KAL | SCL | CLO
            ----+-----+-----+----
   mode     SCL | SCL | SCL | CLO
            ----+-----+-----+----
            CLO | CLO | CLO | CLO

It is possible to chain a TCP frontend to an HTTP backend. It is pointless if
only HTTP traffic is handled. But it may be used to handle several protocols
within the same frontend. In this case, the client's connection is first handled
as a raw tcp connection before being upgraded to HTTP. Before the upgrade, the
content processings are performend on raw data. Once upgraded, data is parsed
and stored using an internal representation called HTX and it is no longer
possible to rely on raw representation. There is no way to go back.

TCP 프런트엔드를 HTTP 백엔드에 연결할 수 있습니다.
HTTP 트래픽만 처리하면 의미가 없습니다.
그러나 동일한 프런트엔드 내에서 여러 프로토콜을 처리하는 데 사용할 수 있습니다.
이 경우 클라이언트의 연결은 HTTP로 업그레이드되기 전에 먼저 원시 TCP 연결로 처리됩니다.
업그레이드 전에 콘텐츠 처리는 원시 데이터에서 수행됩니다. 업그레이드되면 데이터는
HTX라는 내부 표현을 사용하여 구문 분석 및 저장되며 더 이상 원시 표현에 의존할 수 없습니다.
돌아갈 방법이 없습니다.

There are two kind of upgrades, in-place upgrades and destructive upgrades. The
first ones involves a TCP to HTTP/1 upgrade. In HTTP/1, the request
processings are serialized, thus the applicative stream can be preserved. The
second one involves a TCP to HTTP/2 upgrade. Because it is a multiplexed
protocol, the applicative stream cannot be associated to any HTTP/2 stream and
is destroyed. New applicative streams are then created when HAProxy receives
new HTTP/2 streams at the lower level, in the H2 multiplexer. It is important
to understand this difference because that drastically changes the way to
process data. When an HTTP/1 upgrade is performed, the content processings
already performed on raw data are neither lost nor reexecuted while for an
HTTP/2 upgrade, applicative streams are distinct and all frontend rules are
evaluated systematically on each one. And as said, the first stream, the TCP
one, is destroyed, but only after the frontend rules were evaluated.

업그레이드에는 전체 업그레이드와 파괴적 업그레이드의 두 가지 종류가 있습니다.
첫 번째는 TCP에서 HTTP/1로 업그레이드하는 것입니다.
HTTP/1에서는 요청 처리가 직렬화되므로 적용 스트림을 보존할 수 있습니다.
두 번째는 TCP에서 HTTP/2로 업그레이드하는 것입니다.
멀티플렉싱 프로토콜이기 때문에 응용 스트림은 HTTP/2 스트림과 연결될 수 없으며 소멸됩니다.
그러면 HAProxy가 H2 멀티플렉서의 하위 수준에서 새 HTTP/2 스트림을 수신할 때
새 적용 스트림이 생성됩니다.
이 차이점을 이해하는 것이 중요합니다. 왜냐하면 데이터 처리 방식이 크게 바뀌기 때문입니다.
HTTP/1 업그레이드가 수행되면 원시 데이터에 대해 이미 수행된 콘텐츠 처리가 손실되거나
재실행되지 않는 반면, HTTP/2 업그레이드의 경우 적용 가능한 스트림이 구별되고
모든 프런트엔드 규칙이 각각에 대해 체계적으로 평가됩니다.
앞에서 말했듯이 첫 번째 스트림인 TCP 스트림은 프런트엔드 규칙이 평가된 후에만 파괴됩니다.

There is another importnat point to understand when HTTP processings are
performed from a TCP proxy. While HAProxy is able to parse HTTP/1 in-fly from
tcp-request content rules, it is not possible for HTTP/2. Only the HTTP/2
preface can be parsed. This is a huge limitation regarding the HTTP content
analysis in TCP. Concretely it is only possible to know if received data are
HTTP. For instance, it is not possible to choose a backend based on the Host
header value while it is trivial in HTTP/1. Hopefully, there is a solution to
mitigate this drawback.

HTTP 처리가 TCP 프록시에서 수행되는 경우를 이해해야 하는 또 다른 중요한 지점이 있습니다.
HAProxy는 tcp-request 콘텐츠 규칙에서 즉시 HTTP/1을 구문 분석할 수 있지만 HTTP/2에서는
불가능합니다. HTTP/2 서문만 구문 분석할 수 있습니다.
이것은 TCP의 HTTP 콘텐츠 분석과 관련하여 큰 제한 사항입니다.
구체적으로 수신된 데이터가 HTTP인지 여부만 알 수 있습니다.
예를 들어 HTTP/1에서는 사소한 것이지만 호스트 헤더 값을 기반으로 백엔드를 선택할 수 없습니다.
이 단점을 완화할 수 있는 솔루션이 있기를 바랍니다.

There are two ways to perform an HTTP upgrade. The first one, the historical
method, is to select an HTTP backend. The upgrade happens when the backend is
set. Thus, for in-place upgrades, only the backend configuration is considered
in the HTTP data processing. For destructive upgrades, the applicative stream
is destroyed, thus its processing is stopped. With this method, possibilities
to choose a backend with an HTTP/2 connection are really limited, as mentioned
above, and a bit useless because the stream is destroyed. The second method is
to upgrade during the tcp-request content rules evaluation, thanks to the
"switch-mode http" action. In this case, the upgrade is performed in the
frontend context and it is possible to define HTTP directives in this
frontend. For in-place upgrades, it offers all the power of the HTTP analysis
as soon as possible. It is not that far from an HTTP frontend. For destructive
upgrades, it does not change anything except it is useless to choose a backend
on limited information. It is of course the recommended method. Thus, testing
the request protocol from the tcp-request content rules to perform an HTTP
upgrade is enough. All the remaining HTTP manipulation may be moved to the
frontend http-request ruleset. But keep in mind that tcp-request content rules
remains evaluated on each streams, that can't be changed.

HTTP 업그레이드를 수행하는 방법에는 두 가지가 있습니다.
역사적인 방법인 첫 번째 방법은 HTTP 백엔드를 선택하는 것입니다.
백엔드가 설정되면 업그레이드가 발생합니다.
따라서 전체 업그레이드의 경우 HTTP 데이터 처리에서 백엔드 구성만 고려됩니다.
파괴적 업그레이드의 경우 적용 가능한 스트림이 파괴되므로 처리가 중지됩니다.
이 방법을 사용하면 위에서 언급한 것처럼 HTTP/2 연결이 있는 백엔드를 선택할 가능성이
실제로 제한되며 스트림이 파괴되기 때문에 약간 쓸모가 없습니다.
두 번째 방법은 "switch-mode http" 작업 덕분에 tcp-request 콘텐츠 규칙 평가 중에
업그레이드하는 것입니다.
이 경우 업그레이드는 프런트엔드 컨텍스트에서 수행되며 이 프런트엔드에서 HTTP
지시문을 정의할 수 있습니다.
전체 업그레이드의 경우 가능한 한 빨리 HTTP 분석의 모든 기능을 제공합니다.
HTTP 프론트엔드와 그리 멀지 않습니다.
파괴적인 업그레이드의 경우 제한된 정보에서 백엔드를 선택하는 것이 쓸모가 없다는 점을
제외하고는 아무것도 변경하지 않습니다.
물론 추천하는 방법입니다.
따라서 HTTP 업그레이드를 수행하기 위해 tcp-request 콘텐츠 규칙에서 요청 프로토콜을
테스트하는 것으로 충분합니다.
나머지 모든 HTTP 조작은 프런트엔드 http-request 규칙 집합으로 이동할 수 있습니다.
그러나 tcp-request 콘텐츠 규칙은 변경할 수 없는 각 스트림에서 평가된 상태로 유지된다는
점을 명심하십시오.

4.1. Proxy keywords matrix

The following list of keywords is supported. Most of them may only be used in a
limited set of section types. Some of them are marked as "deprecated" because
they are inherited from an old syntax which may be confusing or functionally
limited, and there are new recommended keywords to replace them. Keywords
marked with "(*)" can be optionally inverted using the "no" prefix, e.g. "no
option contstats". This makes sense when the option has been enabled by default
and must be disabled for a specific instance. Such options may also be prefixed
with "default" in order to restore default settings regardless of what has been
specified in a previous "defaults" section. Keywords supported in defaults
sections marked with "(!)" are only supported in named defaults sections, not
anonymous ones.

다음 키워드 목록이 지원됩니다.
대부분은 제한된 섹션 유형 집합에서만 사용할 수 있습니다.
그들 중 일부는 혼란스럽거나 기능적으로 제한될 수 있는 이전 구문에서 상속되었으며
이를 대체할 새로운 권장 키워드가 있기 때문에 "deprecated(사용되지 않음)"으로 표시됩니다.
"(*)"로 표시된 키워드는 "no" 접두사를 사용하여 선택적으로 반전될 수 있습니다.
예) "no option contstats".
이는 옵션이 기본적으로 활성화되어 있고 특정 인스턴스에 대해 비활성화되어야 하는 경우
의미가 있습니다.
이러한 옵션에는 이전 "defaults" 섹션에서 지정한 내용에 관계없이 기본 설정을 복원하기
위해 "default"이라는 접두사가 붙을 수도 있습니다.
"(!)"로 표시된 기본 섹션에서 지원되는 키워드는 익명 섹션이 아닌 명명된 기본 섹션에서만
지원됩니다.

 keyword                              defaults   frontend   listen    backend
------------------------------------+----------+----------+---------+---------
acl                                       X (!)      X         X         X
backlog                                   X          X         X         -
balance                                   X          -         X         X
bind                                      -          X         X         -
bind-process                              X          X         X         X
capture cookie                            -          X         X         -
capture request header                    -          X         X         -
capture response header                   -          X         X         -
clitcpka-cnt                              X          X         X         -
clitcpka-idle                             X          X         X         -
clitcpka-intvl                            X          X         X         -
compression                               X          X         X         X
cookie                                    X          -         X         X
declare capture                           -          X         X         -
default-server                            X          -         X         X
default_backend                           X          X         X         -
description                               -          X         X         X
disabled                                  X          X         X         X
dispatch                                  -          -         X         X
email-alert from                          X          X         X         X
email-alert level                         X          X         X         X
email-alert mailers                       X          X         X         X
email-alert myhostname                    X          X         X         X
email-alert to                            X          X         X         X
enabled                                   X          X         X         X
errorfile                                 X          X         X         X
errorfiles                                X          X         X         X
errorloc                                  X          X         X         X
errorloc302                               X          X         X         X
-- keyword -------------------------- defaults - frontend - listen -- backend -
errorloc303                               X          X         X         X
error-log-format                          X          X         X         -
force-persist                             -          -         X         X
filter                                    -          X         X         X
fullconn                                  X          -         X         X
hash-type                                 X          -         X         X
http-after-response                       X (!)      X         X         X
http-check comment                        X          -         X         X
http-check connect                        X          -         X         X
http-check disable-on-404                 X          -         X         X
http-check expect                         X          -         X         X
http-check send                           X          -         X         X
http-check send-state                     X          -         X         X
http-check set-var                        X          -         X         X
http-check unset-var                      X          -         X         X
http-error                                X          X         X         X
http-request                              X (!)      X         X         X
http-response                             X (!)      X         X         X
http-reuse                                X          -         X         X
http-send-name-header                     -          -         X         X
id                                        -          X         X         X
ignore-persist                            -          -         X         X
load-server-state-from-file               X          -         X         X
log                                  (*)  X          X         X         X
log-format                                X          X         X         -
log-format-sd                             X          X         X         -
log-tag                                   X          X         X         X
max-keep-alive-queue                      X          -         X         X
maxconn                                   X          X         X         -
mode                                      X          X         X         X
monitor fail                              -          X         X         -
monitor-uri                               X          X         X         -
option abortonclose                  (*)  X          -         X         X
option accept-invalid-http-request   (*)  X          X         X         -
option accept-invalid-http-response  (*)  X          -         X         X
option allbackups                    (*)  X          -         X         X
option checkcache                    (*)  X          -         X         X
option clitcpka                      (*)  X          X         X         -
option contstats                     (*)  X          X         X         -
option disable-h2-upgrade            (*)  X          X         X         -
option dontlog-normal                (*)  X          X         X         -
option dontlognull                   (*)  X          X         X         -
-- keyword -------------------------- defaults - frontend - listen -- backend -
option forwardfor                         X          X         X         X
option h1-case-adjust-bogus-client   (*)  X          X         X         -
option h1-case-adjust-bogus-server   (*)  X          -         X         X
option http-buffer-request           (*)  X          X         X         X
option http-ignore-probes            (*)  X          X         X         -
option http-keep-alive               (*)  X          X         X         X
option http-no-delay                 (*)  X          X         X         X
option http-pretend-keepalive        (*)  X          -         X         X
option http-restrict-req-hdr-names        X          X         X         X
option http-server-close             (*)  X          X         X         X
option http-use-proxy-header         (*)  X          X         X         -
option httpchk                            X          -         X         X
option httpclose                     (*)  X          X         X         X
option httplog                            X          X         X         -
option httpslog                           X          X         X         -
option independent-streams           (*)  X          X         X         X
option ldap-check                         X          -         X         X
option external-check                     X          -         X         X
option log-health-checks             (*)  X          -         X         X
option log-separate-errors           (*)  X          X         X         -
option logasap                       (*)  X          X         X         -
option mysql-check                        X          -         X         X
option nolinger                      (*)  X          X         X         X
option originalto                         X          X         X         X
option persist                       (*)  X          -         X         X
option pgsql-check                        X          -         X         X
option prefer-last-server            (*)  X          -         X         X
option redispatch                    (*)  X          -         X         X
option redis-check                        X          -         X         X
option smtpchk                            X          -         X         X
option socket-stats                  (*)  X          X         X         -
option splice-auto                   (*)  X          X         X         X
option splice-request                (*)  X          X         X         X
option splice-response               (*)  X          X         X         X
option spop-check                         -          -         -         X
option srvtcpka                      (*)  X          -         X         X
option ssl-hello-chk                      X          -         X         X
-- keyword -------------------------- defaults - frontend - listen -- backend -
option tcp-check                          X          -         X         X
option tcp-smart-accept              (*)  X          X         X         -
option tcp-smart-connect             (*)  X          -         X         X
option tcpka                              X          X         X         X
option tcplog                             X          X         X         X
option transparent                   (*)  X          -         X         X
option idle-close-on-response        (*)  X          X         X         -
external-check command                    X          -         X         X
external-check path                       X          -         X         X
persist rdp-cookie                        X          -         X         X
rate-limit sessions                       X          X         X         -
redirect                                  -          X         X         X
-- keyword -------------------------- defaults - frontend - listen -- backend -
retries                                   X          -         X         X
retry-on                                  X          -         X         X
server                                    -          -         X         X
server-state-file-name                    X          -         X         X
server-template                           -          -         X         X
source                                    X          -         X         X
srvtcpka-cnt                              X          -         X         X
srvtcpka-idle                             X          -         X         X
srvtcpka-intvl                            X          -         X         X
stats admin                               -          X         X         X
stats auth                                X          X         X         X
stats enable                              X          X         X         X
stats hide-version                        X          X         X         X
stats http-request                        -          X         X         X
stats realm                               X          X         X         X
stats refresh                             X          X         X         X
stats scope                               X          X         X         X
stats show-desc                           X          X         X         X
stats show-legends                        X          X         X         X
stats show-node                           X          X         X         X
stats uri                                 X          X         X         X
-- keyword -------------------------- defaults - frontend - listen -- backend -
stick match                               -          -         X         X
stick on                                  -          -         X         X
stick store-request                       -          -         X         X
stick store-response                      -          -         X         X
stick-table                               -          X         X         X
tcp-check comment                         X          -         X         X
tcp-check connect                         X          -         X         X
tcp-check expect                          X          -         X         X
tcp-check send                            X          -         X         X
tcp-check send-lf                         X          -         X         X
tcp-check send-binary                     X          -         X         X
tcp-check send-binary-lf                  X          -         X         X
tcp-check set-var                         X          -         X         X
tcp-check unset-var                       X          -         X         X
tcp-request connection                    X (!)      X         X         -
tcp-request content                       X (!)      X         X         X
tcp-request inspect-delay                 X (!)      X         X         X
tcp-request session                       X (!)      X         X         -
tcp-response content                      X (!)      -         X         X
tcp-response inspect-delay                X (!)      -         X         X
timeout check                             X          -         X         X
timeout client                            X          X         X         -
timeout client-fin                        X          X         X         -
timeout connect                           X          -         X         X
timeout http-keep-alive                   X          X         X         X
timeout http-request                      X          X         X         X
timeout queue                             X          -         X         X
timeout server                            X          -         X         X
timeout server-fin                        X          -         X         X
timeout tarpit                            X          X         X         X
timeout tunnel                            X          -         X         X
transparent                 (deprecated)  X          -         X         X
unique-id-format                          X          X         X         -
unique-id-header                          X          X         X         -
use_backend                               -          X         X         -
use-fcgi-app                              -          -         X         X
use-server                                -          -         X         X
------------------------------------+----------+----------+---------+---------
 keyword                              defaults   frontend   listen    backend

4.2. Alphabetically sorted keywords reference

This section provides a description of each keyword and its usage.  
이 섹션에서는 각 키워드와 사용법에 대한 설명을 제공합니다.

acl <aclname> <criterion> [flags] [operator] <value> ...    

  Declare or complete an access list.

  May be used in sections :   defaults | frontend | listen | backend
                                yes(!) |    yes   |   yes  |   yes

  This directive is only available from named defaults sections, not anonymous
  ones. ACLs defined in a defaults section are not visible from other sections
  using it.
  이 지시문은 익명 섹션이 아닌 명명된 기본 섹션에서만 사용할 수 있습니다.
  defaults 섹션에 정의된 ACL은 이를 사용하는 다른 섹션에서 볼 수 없습니다.

  Example:
        acl invalid_src  src          0.0.0.0/7 224.0.0.0/3
        acl invalid_src  src_port     0:1023
        acl local_dst    hdr(host) -i localhost

  See section 7 about ACL usage.

backlog <conns>   
  Give hints to the system about the approximate listen backlog desired size
  대략적인 청취 백로그가 원하는 크기에 대해 시스템에 힌트 제공

  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    yes   |   yes  |   no

Arguments :
<conns> is the number of pending connections. Depending on the operating
system, it may represent the number of already acknowledged
connections, of non-acknowledged ones, or both.
<conns>는 보류 중인 연결 수입니다. 운영 체제에 따라 이미 승인된 연결 수, 승인되지
않은 연결 수 또는 둘 모두를 나타낼 수 있습니다.

In order to protect against SYN flood attacks, one solution is to increase
the system's SYN backlog size. Depending on the system, sometimes it is just
tunable via a system parameter, sometimes it is not adjustable at all, and
sometimes the system relies on hints given by the application at the time of
the listen() syscall. By default, HAProxy passes the frontend's maxconn value
to the listen() syscall. On systems which can make use of this value, it can
sometimes be useful to be able to specify a different value, hence this
backlog parameter.

SYN 플러드 공격으로부터 보호하기 위한 한 가지 솔루션은 시스템의 SYN 백로그
크기를 늘리는 것입니다.
시스템에 따라 시스템 매개변수를 통해 조정할 수 있는 경우도 있고, 전혀 조정할 수 없는
경우도 있으며, 시스템이 listen() 시스템 호출 시 애플리케이션에서 제공하는 힌트에 의존하는
경우도 있습니다.
기본적으로 HAProxy는 프런트엔드의 maxconn 값을 listen() 시스템 호출에 전달합니다.
이 값을 사용할 수 있는 시스템에서는 때때로 다른 값을 지정할 수 있는 것이 유용할 수
있으므로 이 백로그 매개변수입니다.

On Linux 2.4, the parameter is ignored by the system. On Linux 2.6, it is
used as a hint and the system accepts up to the smallest greater power of
two, and never more than some limits (usually 32768).
Linux 2.4에서는 시스템에서 매개변수를 무시합니다.
Linux 2.6에서는 힌트로 사용되며 시스템은 최소 2의 거듭제곱까지 허용하며 일부
제한(보통 32768)을 초과하지 않습니다.

See also : "maxconn" and the target operating system's tuning guide.

balance <algorithm> [ <arguments> ]
balance url_param <param> [check_post]
Define the load balancing algorithm to be used in a backend.
백엔드에서 사용할 부하 분산 알고리즘을 정의합니다.

 
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    no    |   yes  |   yes

Arguments :
<algorithm> is the algorithm used to select a server when doing load
balancing. This only applies when no persistence information
is available, or when a connection is redispatched to another
server. <algorithm> may be one of the following :
<algorithm>은 부하 분산 시 서버를 선택하는 데 사용되는 알고리즘입니다.
이는 지속성 정보를 사용할 수 없거나 연결이 다른 서버로 재지정된 경우에만
적용됩니다. <algorithm>은 다음 중 하나일 수 있습니다.

roundrobin Each server is used in turns, according to their weights.
This is the smoothest and fairest algorithm when the server's
processing time remains equally distributed. This algorithm
is dynamic, which means that server weights may be adjusted
on the fly for slow starts for instance. It is limited by
design to 4095 active servers per backend. Note that in some
large farms, when a server becomes up after having been down
for a very short time, it may sometimes take a few hundreds
requests for it to be re-integrated into the farm and start
receiving traffic. This is normal, though very rare. It is
indicated here in case you would have the chance to observe
it, so that you don't worry.

roundrobin 각 서버는 가중치에 따라 차례로 사용됩니다.
이것은 서버의 처리 시간이 균등하게 분배될 때 가장 매끄럽고 공정한
알고리즘입니다. 이 알고리즘은 동적이므로 예를 들어 느린 시작을 위해
서버 가중치를 즉시 조정할 수 있습니다. 설계상 백엔드당 4095개의 활성
서버로 제한됩니다.
일부 대규모 팜에서는 서버가 매우 짧은 시간 동안 중단되었다가 다시
가동되면 서버가 팜에 다시 통합되고 트래픽 수신을 시작하는 데 수백 건의
요청이 필요할 수 있습니다.
이것은 매우 드물지만 정상입니다.
관찰할 기회가 있을 경우에 대비하여 여기에 표시되어 있으니 걱정하지
않으셔도 됩니다.

static-rr Each server is used in turns, according to their weights.
This algorithm is as similar to roundrobin except that it is
static, which means that changing a server's weight on the
fly will have no effect. On the other hand, it has no design
limitation on the number of servers, and when a server goes
up, it is always immediately reintroduced into the farm, once
the full map is recomputed. It also uses slightly less CPU to
run (around -1%).

static-rr 각 서버는 가중치에 따라 차례로 사용됩니다.
이 알고리즘은 정적이라는 점을 제외하면 라운드 로빈과 비슷합니다.
즉, 서버의 가중치를 즉석에서 변경해도 아무런 효과가 없습니다.
반면에 서버 수에 대한 설계 제한이 없으며 서버가 올라가면 전체 맵이
다시 계산되면 항상 즉시 팜에 다시 도입됩니다. 또한 실행하는 데 약간
더 적은 CPU를 사용합니다(약 -1%).

leastconn The server with the lowest number of connections receives the
connection. Round-robin is performed within groups of servers
of the same load to ensure that all servers will be used. Use
of this algorithm is recommended where very long sessions are
expected, such as LDAP, SQL, TSE, etc... but is not very well
suited for protocols using short sessions such as HTTP. This
algorithm is dynamic, which means that server weights may be
adjusted on the fly for slow starts for instance. It will
also consider the number of queued connections in addition to
the established ones in order to minimize queuing.

leastconn 연결 수가 가장 적은 서버가 연결을 수신합니다.
로드가 동일한 서버 그룹 내에서 라운드 로빈이 수행되어 모든 서버가
사용되도록 합니다. 이 알고리즘의 사용은 LDAP, SQL, TSE 등과 같이
매우 긴 세션이 예상되는 경우에 권장되지만, HTTP와 같은 짧은 세션을
사용하는 프로토콜에는 적합하지 않습니다.
이 알고리즘은 동적이므로 예를 들어 느린 시작을 위해 서버 가중치를
즉시 조정할 수 있습니다. 또한 대기열을 최소화하기 위해 설정된 연결 외에
대기열에 있는 연결의 수도 고려합니다.

first The first server with available connection slots receives the
connection. The servers are chosen from the lowest numeric
identifier to the highest (see server parameter "id"), which
defaults to the server's position in the farm. Once a server
reaches its maxconn value, the next server is used. It does
not make sense to use this algorithm without setting maxconn.
The purpose of this algorithm is to always use the smallest
number of servers so that extra servers can be powered off
during non-intensive hours. This algorithm ignores the server
weight, and brings more benefit to long session such as RDP
or IMAP than HTTP, though it can be useful there too. In
order to use this algorithm efficiently, it is recommended
that a cloud controller regularly checks server usage to turn
them off when unused, and regularly checks backend queue to
turn new servers on when the queue inflates. Alternatively,
using "http-check send-state" may inform servers on the load.

first 사용 가능한 연결 슬롯이 있는 첫 번째 서버가 연결을 수신합니다.
서버는 가장 낮은 숫자 식별자에서 가장 높은 숫자 식별자까지 선택되며
(서버 매개변수 "id" 참조) 기본적으로 팜의 서버 위치입니다.
서버가 maxconn 값에 도달하면 다음 서버가 사용됩니다.
maxconn을 설정하지 않고 이 알고리즘을 사용하는 것은 의미가 없습니다.
이 알고리즘의 목적은 집중적이지 않은 시간에 추가 서버의 전원을 끌 수
있도록 항상 최소 수의 서버를 사용하는 것입니다.
이 알고리즘은 서버 가중치를 무시하고 HTTP보다 RDP 또는 IMAP과 같은
긴 세션에 더 많은 이점을 제공하지만 거기에서도 유용할 수 있습니다.
이 알고리즘을 효율적으로 사용하려면 클라우드 컨트롤러가 정기적으로
서버 사용량을 확인하여 사용하지 않을 때는 끄고, 정기적으로 백엔드 대기열을
확인하여 대기열이 팽창하면 새 서버를 켜는 것이 좋습니다.
또는 "http-check send-state"를 사용하면 로드 시 서버에 알릴 수 있습니다.

hash Takes a regular sample expression in argument. The expression
is evaluated for each request and hashed according to the
configured hash-type. The result of the hash is divided by
the total weight of the running servers to designate which
server will receive the request. This can be used in place of
"source", "uri", "hdr()", "url_param()", "rdp-cookie" to make
use of a converter, refine the evaluation, or be used to
extract data from local variables for example. When the data
is not available, round robin will apply. This algorithm is
static by default, which means that changing a server's
weight on the fly will have no effect, but this can be
changed using "hash-type".

hash 인수에서 정규 샘플 표현식을 사용합니다.
표현식은 각 요청에 대해 평가되고 구성된 해시 유형에 따라 해시됩니다.
해시 결과를 실행 중인 서버의 총 가중치로 나누어 요청을 수신할 서버를 지정합니다.
"source", "uri", "hdr()", "url_param()", "rdp-cookie" 대신 사용할 수 있습니다.
또는 예를 들어 지역 변수에서 데이터를 추출하는 데 사용할 수 있습니다.
데이터를 사용할 수 없는 경우 라운드 로빈이 적용됩니다.
이 알고리즘은 기본적으로 정적이며 즉석에서 서버의 가중치를 변경해도
아무런 효과가 없지만 "hash-type"을 사용하여 변경할 수 있습니다.

source The source IP address is hashed and divided by the total
weight of the running servers to designate which server will
receive the request. This ensures that the same client IP
address will always reach the same server as long as no
server goes down or up. If the hash result changes due to the
number of running servers changing, many clients will be
directed to a different server. This algorithm is generally
used in TCP mode where no cookie may be inserted. It may also
be used on the Internet to provide a best-effort stickiness
to clients which refuse session cookies. This algorithm is
static by default, which means that changing a server's
weight on the fly will have no effect, but this can be
changed using "hash-type". See also the "hash" option above.

source 소스 IP 주소는 요청을 수신할 서버를 지정하기 위해 해시되고 실행 중인
서버의 총 가중치로 나뉩니다.
이렇게 하면 서버가 다운되거나 업되지 않는 한 동일한 클라이언트 IP 주소가
항상 동일한 서버에 도달하게 됩니다.
실행 중인 서버의 수가 변경되어 해시 결과가 변경되면 많은 클라이언트가 다른
서버로 연결됩니다.
이 알고리즘은 일반적으로 쿠키를 삽입할 수 없는 TCP 모드에서 사용됩니다.
세션 쿠키를 거부하는 클라이언트에게 최선의 노력을 다하기 위해 인터넷에서
사용될 수도 있습니다.
이 알고리즘은 기본적으로 정적이며 즉석에서 서버의 가중치를 변경해도 아무런
효과가 없지만 "hash-type"을 사용하여 변경할 수 있습니다.
위의 "hash" 옵션도 참조하십시오.

uri This algorithm hashes either the left part of the URI (before
the question mark) or the whole URI (if the "whole" parameter
is present) and divides the hash value by the total weight of
the running servers. The result designates which server will
receive the request. This ensures that the same URI will
always be directed to the same server as long as no server
goes up or down. This is used with proxy caches and
anti-virus proxies in order to maximize the cache hit rate.
Note that this algorithm may only be used in an HTTP backend.
This algorithm is static by default, which means that
changing a server's weight on the fly will have no effect,
but this can be changed using "hash-type".

uri 이 알고리즘은 URI의 왼쪽 부분(물음표 앞) 또는 전체 URI("whole" 매개변수가
있는 경우)를 해시하고 해시 값을 실행 중인 서버의 총 가중치로 나눕니다.
결과는 요청을 수신할 서버를 지정합니다.
이렇게 하면 서버가 작동하거나 중지되지 않는 한 동일한 URI가 항상 동일한
서버로 지정됩니다.
이것은 캐시 적중률을 최대화하기 위해 프록시 캐시 및 바이러스 백신 프록시와
함께 사용됩니다. 이 알고리즘은 HTTP 백엔드에서만 사용할 수 있습니다.
이 알고리즘은 기본적으로 정적이며 즉석에서 서버의 가중치를 변경해도
아무런 효과가 없지만 "hash-type"을 사용하여 변경할 수 있습니다.

This algorithm supports two optional parameters "len" and
"depth", both followed by a positive integer number. These
options may be helpful when it is needed to balance servers
based on the beginning of the URI only. The "len" parameter
indicates that the algorithm should only consider that many
characters at the beginning of the URI to compute the hash.
Note that having "len" set to 1 rarely makes sense since most
URIs start with a leading "/".

이 알고리즘은 두 개의 선택적 매개변수 "len" 및 "depth"를 지원하며 둘 다
뒤에 양의 정수가 옵니다. 이러한 옵션은 서버 균형이 필요할 때 유용할 수 있습니다.
URI의 시작 부분에만 기반합니다.
"len" 매개변수는 알고리즘이 해시를 계산하기 위해 URI의 시작 부분에
있는 많은 문자만 고려해야 함을 나타냅니다.
대부분의 URI는 선행 "/"로 시작하므로 "len"을 1로 설정하는 것은 거의
의미가 없습니다.

The "depth" parameter indicates the maximum directory depth
to be used to compute the hash. One level is counted for each
slash in the request. If both parameters are specified, the
evaluation stops when either is reached.

"depth" 매개변수는 해시를 계산하는 데 사용되는 최대 디렉터리 깊이를
나타냅니다. 요청의 슬래시마다 하나의 수준이 계산됩니다.
두 매개변수가 모두 지정된 경우 둘 중 하나에 도달하면 평가가 중지됩니다.

A "path-only" parameter indicates that the hashing key starts
at the first '/' of the path. This can be used to ignore the
authority part of absolute URIs, and to make sure that HTTP/1
and HTTP/2 URIs will provide the same hash. See also the
"hash" option above.

"path-only" 매개변수는 해싱 키가 경로의 첫 번째 '/'에서 시작함을 나타냅니다.
이는 절대 URI의 권한 부분을 무시하고 HTTP/1 및 HTTP/2 URI가 동일한 해시를
제공하는지 확인하는 데 사용할 수 있습니다.
위의 "hash" 옵션도 참조하십시오.

url_param The URL parameter specified in argument will be looked up in
the query string of each HTTP GET request.
url_param 인수에 지정된 URL 매개변수는 각 HTTP GET 요청의 쿼리 문자열에서
조회됩니다.

If the modifier "check_post" is used, then an HTTP POST
request entity will be searched for the parameter argument,
when it is not found in a query string after a question mark
('?') in the URL. The message body will only start to be
analyzed once either the advertised amount of data has been
received or the request buffer is full. In the unlikely event
that chunked encoding is used, only the first chunk is
scanned. Parameter values separated by a chunk boundary, may
be randomly balanced if at all. This keyword used to support
an optional <max_wait> parameter which is now ignored.

수정자 "check_post"가 사용되면 HTTP POST 요청 엔터티는 URL의
물음표('?') 뒤의 쿼리 문자열에서 매개변수 인수를 찾을 수 없을 때 검색됩니다.
메시지 본문은 광고된 양의 데이터가 수신되었거나 요청 버퍼가 가득 찬
경우에만 분석을 시작합니다.
청크 분할 인코딩이 사용되는 드문 경우에는 첫 번째 청크만 스캔됩니다.
청크 경계로 구분된 매개변수 값은 무작위로 균형을 이룰 수 있습니다.
이 키워드는 이제 무시되는 선택적 <max_wait> 매개변수를 지원하는 데
사용됩니다.

If the parameter is found followed by an equal sign ('=') and
a value, then the value is hashed and divided by the total
weight of the running servers. The result designates which
server will receive the request.

매개변수 뒤에 등호('=')와 값이 있으면 값이 해시되고 실행 중인 서버의
총 가중치로 나뉩니다. 결과는 요청을 수신할 서버를 지정합니다.

This is used to track user identifiers in requests and ensure
that a same user ID will always be sent to the same server as
long as no server goes up or down. If no value is found or if
the parameter is not found, then a round robin algorithm is
applied. Note that this algorithm may only be used in an HTTP
backend. This algorithm is static by default, which means
that changing a server's weight on the fly will have no
effect, but this can be changed using "hash-type". See also
the "hash" option above.

이것은 요청에서 사용자 식별자를 추적하고 서버가 작동하거나
중지되지 않는 한 동일한 사용자 ID가 항상 동일한 서버로 전송되도록
하는 데 사용됩니다.
값이 없거나 매개변수가 없으면 라운드 로빈 알고리즘이 적용됩니다.
이 알고리즘은 HTTP 백엔드에서만 사용할 수 있습니다.
이 알고리즘은 기본적으로 정적이며 즉석에서 서버의 가중치를 변경해도
아무런 효과가 없지만 "hash-type"을 사용하여 변경할 수 있습니다.
위의 "hash" 옵션도 참조하십시오.

hdr(<name>) The HTTP header <name> will be looked up in each HTTP
request. Just as with the equivalent ACL 'hdr()' function,
the header name in parenthesis is not case sensitive. If the
header is absent or if it does not contain any value, the
roundrobin algorithm is applied instead.

An optional 'use_domain_only' parameter is available, for
reducing the hash algorithm to the main domain part with some
specific headers such as 'Host'. For instance, in the Host
value "haproxy.1wt.eu", only "1wt" will be considered.

This algorithm is static by default, which means that
changing a server's weight on the fly will have no effect,
but this can be changed using "hash-type". See also the
"hash" option above.

hdr(<name>) HTTP 헤더 <name>은 각 HTTP 요청에서 조회됩니다.
동등한 ACL 'hdr()' 함수와 마찬가지로 괄호 안의 헤더 이름은 대소문자를
구분하지 않습니다.
헤더가 없거나 헤더에 값이 없으면 라운드 로빈 알고리즘이 대신 적용됩니다.

선택적 'use_domain_only' 매개변수를 사용하여 해시 알고리즘을 'Host'와
같은 일부 특정 헤더가 있는 기본 도메인 부분으로 줄일 수 있습니다.
예를 들어 호스트 값 "haproxy.1wt.eu"에서 "1wt"만 고려됩니다.

이 알고리즘은 기본적으로 정적이며 즉석에서 서버의 가중치를 변경해도
아무런 효과가 없지만 "hash-type"을 사용하여 변경할 수 있습니다.
위의 "hash" 옵션도 참조하십시오.

random
random(<draws>)
A random number will be used as the key for the consistent
hashing function. This means that the servers' weights are
respected, dynamic weight changes immediately take effect, as
well as new server additions. Random load balancing can be
useful with large farms or when servers are frequently added
or removed as it may avoid the hammering effect that could
result from roundrobin or leastconn in this situation. The
hash-balance-factor directive can be used to further improve
fairness of the load balancing, especially in situations
where servers show highly variable response times. When an
argument <draws> is present, it must be an integer value one
or greater, indicating the number of draws before selecting
the least loaded of these servers. It was indeed demonstrated
that picking the least loaded of two servers is enough to
significantly improve the fairness of the algorithm, by
always avoiding to pick the most loaded server within a farm
and getting rid of any bias that could be induced by the
unfair distribution of the consistent list. Higher values N
will take away N-1 of the highest loaded servers at the
expense of performance. With very high values, the algorithm
will converge towards the leastconn's result but much slower.
The default value is 2, which generally shows very good
distribution and performance. This algorithm is also known as
the Power of Two Random Choices and is described here :
http://www.eecs.harvard.edu/~michaelm/postscripts/handbook2001.pdf

random
random(<draws>)
일관된 해싱 기능의 키로 임의의 숫자가 사용됩니다.
즉, 서버의 가중치가 존중되고 동적 가중치 변경 사항은 물론 새 서버 추가도
즉시 적용됩니다. 무작위 로드 밸런싱은 대규모 팜에서 또는 서버가 자주
추가되거나 제거될 때 유용할 수 있습니다.
이 상황에서 라운드 로빈 또는 leastconn으로 인해 발생할 수 있는 해머링 효과를
피할 수 있기 때문입니다.
hash-balance-factor 지시문은 특히 서버가 매우 가변적인 응답 시간을 보이는
상황에서 로드 밸런싱의 공정성을 더욱 개선하는 데 사용할 수 있습니다.
<draws> 인수가 있는 경우 이러한 서버 중 가장 로드가 적은 서버를 선택하기
전에 뽑은 횟수를 나타내는 1 이상의 정수 값이어야 합니다.
실제로 두 서버 중 부하가 가장 적은 서버를 선택하는 것만으로도 알고리즘의
공정성을 크게 향상시킬 수 있음이 입증되었습니다.
항상 팜 내에서 가장 로드가 많은 서버를 선택하는 것을 피하고 일관성 있는
목록의 불공평한 배포로 인해 발생할 수 있는 편견을 제거합니다.
값이 높을수록 N이 성능을 희생시키면서 로드가 가장 높은 서버 중 N-1개를 제거합니다.
매우 높은 값을 사용하면 알고리즘이 leastconn의 결과 쪽으로 수렴하지만 훨씬 느립니다.
기본값은 2이며 일반적으로 매우 좋은 분포와 성능을 보여줍니다.
이 알고리즘은 Power of Two Random Choices라고도 하며 여기에 설명되어 있습니다.
http://www.eecs.harvard.edu/~michaelm/postscripts/handbook2001.pdf

rdp-cookie
rdp-cookie(<name>)
The RDP cookie <name> (or "mstshash" if omitted) will be
looked up and hashed for each incoming TCP request. Just as
with the equivalent ACL 'req.rdp_cookie()' function, the name
is not case-sensitive. This mechanism is useful as a degraded
persistence mode, as it makes it possible to always send the
same user (or the same session ID) to the same server. If the
cookie is not found, the normal roundrobin algorithm is
used instead.

Note that for this to work, the frontend must ensure that an
RDP cookie is already present in the request buffer. For this
you must use 'tcp-request content accept' rule combined with
a 'req.rdp_cookie_cnt' ACL.

This algorithm is static by default, which means that
changing a server's weight on the fly will have no effect,
but this can be changed using "hash-type". See also the
"hash" option above.

rdp-cookie
rdp-cookie(<name>)
RDP 쿠키 <name>(또는 생략된 경우 "mstshash")은 수신되는 각 TCP 요청에
대해 조회 및 해시됩니다. 동등한 ACL 'req.rdp_cookie()' 함수와 마찬가지로 이름은
대소문자를 구분하지 않습니다.
이 메커니즘은 항상 동일한 사용자(또는 동일한 세션 ID)를 동일한 서버로
보낼 수 있게 하므로 저하된 지속성 모드로 유용합니다.
쿠키를 찾을 수 없으면 일반 라운드 로빈 알고리즘이 대신 사용됩니다.

이것이 작동하려면 프런트엔드에서 요청 버퍼에 RDP 쿠키가 이미 있는지
확인해야 합니다. 이를 위해 'req.rdp_cookie_cnt' ACL과 결합된
'tcp-request content accept' 규칙을 사용해야 합니다.

<arguments> is an optional list of arguments which may be needed by some
algorithms. Right now, only "url_param" and "uri" support an
optional argument.
<arguments>는 일부 알고리즘에서 필요할 수 있는 선택적 인수 목록입니다.
현재 "url_param" 및 "uri"만 선택적 인수를 지원합니다.

The load balancing algorithm of a backend is set to roundrobin when no other
algorithm, mode nor option have been set. The algorithm may only be set once
for each backend.
백엔드의 부하 분산 알고리즘은 다른 알고리즘, 모드 또는 옵션이 설정되지 않은 경우
라운드 로빈으로 설정됩니다.
알고리즘은 각 백엔드에 대해 한 번만 설정할 수 있습니다.

With authentication schemes that require the same connection like NTLM, URI
based algorithms must not be used, as they would cause subsequent requests
to be routed to different backend servers, breaking the invalid assumptions
NTLM relies on.
NTLM과 같은 동일한 연결이 필요한 인증 체계에서는 URI 기반 알고리즘을 사용해서는
안 됩니다. URI 기반 알고리즘을 사용하면 후속 요청이 다른 백엔드 서버로 라우팅되어
NTLM이 의존하는 잘못된 가정이 깨질 수 있기 때문입니다.

  Examples :
        balance roundrobin
        balance url_param userid
        balance url_param session_id check_post 64
        balance hdr(User-Agent)
        balance hdr(host)
        balance hdr(Host) use_domain_only
        balance hash req.cookie(clientid)
        balance hash var(req.client_id)
        balance hash req.hdr_ip(x-forwarded-for,-1),ipmask(24)

Note: the following caveats and limitations on using the "check_post"
extension with "url_param" must be considered :

- all POST requests are eligible for consideration, because there is no way
to determine if the parameters will be found in the body or entity which
may contain binary data. Therefore another method may be required to
restrict consideration of POST requests that have no URL parameters in
the body. (see acl http_end)

- using a <max_wait> value larger than the request buffer size does not
make sense and is useless. The buffer size is set at build time, and
defaults to 16 kB.

- Content-Encoding is not supported, the parameter search will probably
fail; and load balancing will fall back to Round Robin.

- Expect: 100-continue is not supported, load balancing will fall back to
Round Robin.

- Transfer-Encoding (RFC7230 3.3.1) is only supported in the first chunk.
If the entire parameter value is not present in the first chunk, the
selection of server is undefined (actually, defined by how little
actually appeared in the first chunk).

- This feature does not support generation of a 100, 411 or 501 response.

- In some cases, requesting "check_post" MAY attempt to scan the entire
contents of a message body. Scanning normally terminates when linear
white space or control characters are found, indicating the end of what
might be a URL parameter list. This is probably not a concern with SGML
type message bodies.

See also : "dispatch", "cookie", "transparent", "hash-type".

bind [<address>]:<port_range> [, ...] [param*]
bind /<path> [, ...] [param*]
Define one or several listening addresses and/or ports in a frontend.
프런트엔드에서 하나 이상의 수신 주소 및/또는 포트를 정의합니다.

  May be used in sections :   defaults | frontend | listen | backend
                                  no   |    yes   |   yes  |   no

Arguments :
<address> is optional and can be a host name, an IPv4 address, an IPv6
address, or '*'. It designates the address the frontend will
listen on. If unset, all IPv4 addresses of the system will be
listened on. The same will apply for '*' or the system's
special address "0.0.0.0". The IPv6 equivalent is '::'. Note
that if you bind a frontend to multiple UDP addresses you have
no guarantee about the address which will be used to respond.
This is why "0.0.0.0" addresses and lists of comma-separated
IP addresses have been forbidden to bind QUIC addresses.
Optionally, an address family prefix may be used before the
address to force the family regardless of the address format,
which can be useful to specify a path to a unix socket with
no slash ('/'). Currently supported prefixes are :
- 'ipv4@' -> address is always IPv4
- 'ipv6@' -> address is always IPv6
- 'udp@' -> address is resolved as IPv4 or IPv6 and
protocol UDP is used. Currently those listeners are
supported only in log-forward sections.
- 'udp4@' -> address is always IPv4 and protocol UDP
is used. Currently those listeners are supported
only in log-forward sections.
- 'udp6@' -> address is always IPv6 and protocol UDP
is used. Currently those listeners are supported
only in log-forward sections.
- 'unix@' -> address is a path to a local unix socket
- 'abns@' -> address is in abstract namespace (Linux only).
- 'fd@<n>' -> use file descriptor <n> inherited from the
parent. The fd must be bound and may or may not already
be listening.
- 'sockpair@<n>'-> like fd@ but you must use the fd of a
connected unix socket or of a socketpair. The bind waits
to receive a FD over the unix socket and uses it as if it
was the FD of an accept(). Should be used carefully.
- 'quicv4@' -> address is resolved as IPv4 and protocol
UDP is used.
- 'quicv6@' -> address is resolved as IPv6 and protocol
UDP is used.

You may want to reference some environment variables in the
address parameter, see section 2.3 about environment
variables.

<address>는 선택 사항이며 호스트 이름, IPv4 주소, IPv6 주소 또는 '*'일 수 있습니다.
프런트엔드가 수신 대기할 주소를 지정합니다.
설정하지 않으면 시스템의 모든 IPv4 주소가 청취됩니다.
'*' 또는 시스템의 특수 주소 "0.0.0.0"에도 동일하게 적용됩니다.
IPv6에 해당하는 것은 '::'입니다.
프런트엔드를 여러 UDP 주소에 바인딩하는 경우 응답에 사용되는 주소에
대해 보장할 수 없습니다. 이것이 "0.0.0.0" 주소와 쉼표로 구분된 IP 주소
목록이 QUIC 주소를 바인딩하는 것이 금지된 이유입니다.
선택적으로 주소 형식에 관계없이 패밀리를 강제로 지정하기 위해 주소 앞에
주소 패밀리 접두사를 사용할 수 있습니다. 이는 슬래시('/') 없이 유닉스 소켓에
대한 경로를 지정하는 데 유용할 수 있습니다.
현재 지원되는 접두사는 다음과 같습니다.
- 'ipv4@' -> 주소는 항상 IPv4입니다.
- 'ipv6@' -> 주소는 항상 IPv6입니다.
- 'udp@' -> 주소는 IPv4 또는 IPv6으로 확인되며 프로토콜 UDP가 사용됩니다.
현재 이러한 리스너는 로그 포워드 섹션에서만 지원됩니다.
- 'udp4@' -> 주소는 항상 IPv4이며 프로토콜은 UDP를 사용합니다.
현재 이러한 리스너는 로그 포워드 섹션에서만 지원됩니다.
- 'udp6@' -> 주소는 항상 IPv6이며 프로토콜은 UDP를 사용합니다.
현재 이러한 리스너는 로그 포워드 섹션에서만 지원됩니다.
- 'unix@' -> 주소는 로컬 유닉스 소켓의 경로입니다.
- 'abns@' -> 주소는 추상 네임스페이스에 있습니다(Linux만 해당).
- 'fd@<n>' -> 부모로부터 물려받은 파일 디스크립터 <n>을 사용합니다.
fd는 바인드되어야 하며 이미 수신 중일 수도 있고 그렇지 않을 수도 있습니다.
- 'sockpair@<n>'-> fd@와 같지만 연결된 유닉스 소켓이나 소켓쌍의 fd를 사용해야
합니다. 바인드는 유닉스 소켓을 통해 FD를 수신하기 위해 대기하고 이를 마치
accept()의 FD인 것처럼 사용합니다. 주의해서 사용해야 합니다.
- 'quicv4@' -> 주소는 IPv4로 확인하고 프로토콜 UDP를 사용한다.
- 'quicv6@' -> 주소는 IPv6으로 확인되며 프로토콜 UDP가 사용됩니다.

주소 매개변수에서 일부 환경 변수를 참조할 수 있습니다.
환경 변수에 대한 섹션 2.3을 참조하십시오.

<port_range> is either a unique TCP port, or a port range for which the
proxy will accept connections for the IP address specified
above. The port is mandatory for TCP listeners. Note that in
the case of an IPv6 address, the port is always the number
after the last colon (':'). A range can either be :
- a numerical port (ex: '80')
- a dash-delimited ports range explicitly stating the lower
and upper bounds (ex: '2000-2100') which are included in
the range.

Particular care must be taken against port ranges, because
every <address:port> couple consumes one socket (= a file
descriptor), so it's easy to consume lots of descriptors
with a simple range, and to run out of sockets. Also, each
<address:port> couple must be used only once among all
instances running on a same system. Please note that binding
to ports lower than 1024 generally require particular
privileges to start the program, which are independent of
the 'uid' parameter.

<port_range>는 고유한 TCP 포트이거나 프록시가 위에 지정된 IP 주소에 대한
연결을 허용하는 포트 범위입니다. 포트는 TCP 수신기에 필수입니다.
IPv6 주소의 경우 포트는 항상 마지막 콜론(':') 뒤의 숫자입니다.
범위는 다음 중 하나일 수 있습니다.
- 숫자 포트(예: '80')
- 범위에 포함되는 하한 및 상한을 명시적으로 나타내는 대시로 구분된
포트 범위(예: '2000-2100').

모든 <address:port> 커플이 하나의 소켓(= 파일 설명자)을 사용하므로
포트 범위에 대해 특별한 주의를 기울여야 합니다. 따라서 간단한 범위로 많은
설명자를 사용하고 소켓이 부족해지기 쉽습니다.
또한 각 <address:port> 쌍은 동일한 시스템에서 실행 중인 모든 인스턴스
간에 한 번만 사용해야 합니다.
1024보다 낮은 포트에 바인딩하려면 일반적으로 프로그램을 시작하기 위해
'uid' 매개변수와 독립적인 특정 권한이 필요합니다.

<path> is a UNIX socket path beginning with a slash ('/'). This is
alternative to the TCP listening port. HAProxy will then
receive UNIX connections on the socket located at this place.
The path must begin with a slash and by default is absolute.
It can be relative to the prefix defined by "unix-bind" in
the global section. Note that the total length of the prefix
followed by the socket path cannot exceed some system limits
for UNIX sockets, which commonly are set to 107 characters.

<path>는 슬래시('/')로 시작하는 UNIX 소켓 경로입니다.
이것은 TCP 청취 포트의 대안입니다.
그런 다음 HAProxy는 이 위치에 있는 소켓에서 UNIX 연결을 수신합니다.
경로는 슬래시로 시작해야 하며 기본적으로 절대 경로입니다.
전역 섹션에서 "unix-bind"로 정의된 접두사에 상대적일 수 있습니다.
소켓 경로가 뒤따르는 접두사의 총 길이는 일반적으로 107자로 설정되는
UNIX 소켓에 대한 일부 시스템 제한을 초과할 수 없습니다.

<param*> is a list of parameters common to all sockets declared on the
same line. These numerous parameters depend on OS and build
options and have a complete section dedicated to them. Please
refer to section 5 to for more details.

<param*>은 같은 줄에 선언된 모든 소켓에 공통적인 매개변수 목록입니다.
이러한 수많은 매개변수는 OS 및 빌드 옵션에 따라 다르며 전용 섹션이 있습니다.
자세한 내용은 섹션 5를 참조하십시오.

It is possible to specify a list of address:port combinations delimited by
commas. The frontend will then listen on all of these addresses. There is no
fixed limit to the number of addresses and ports which can be listened on in
a frontend, as well as there is no limit to the number of "bind" statements
in a frontend.

쉼표로 구분된 주소:포트 조합 목록을 지정할 수 있습니다.
그러면 프런트엔드는 이러한 모든 주소에서 수신 대기합니다.
프런트엔드에서 수신할 수 있는 주소 및 포트 수에는 고정된 제한이 없으며
프런트엔드의 "bind" 문의 수에도 제한이 없습니다.

  Example :
        listen http_proxy
            bind :80,:443
            bind 10.0.0.1:10080,10.0.0.1:10443
            bind /var/run/ssl-frontend.sock user root mode 600 accept-proxy

        listen http_https_proxy
            bind :80
            bind :443 ssl crt /etc/haproxy/site.pem

        listen http_https_proxy_explicit
            bind ipv6@:80
            bind ipv4@public_ssl:443 ssl crt /etc/haproxy/site.pem
            bind unix@ssl-frontend.sock user root mode 600 accept-proxy

        listen external_bind_app1
            bind "fd@${FD_APP1}"

        listen h3_quic_proxy
            bind quic@10.0.0.1:8888 ssl crt /etc/mycrt alpn h3

  Note: regarding Linux's abstract namespace sockets, HAProxy uses the whole
        sun_path length is used for the address length. Some other programs
        such as socat use the string length only by default. Pass the option
        ",unix-tightsocklen=0" to any abstract socket definition in socat to
        make it compatible with HAProxy's.

  참고: Linux의 추상 네임스페이스 소켓과 관련하여 HAProxy는 주소 길이에 사용되는 
         전체 sun_path 길이를 사용합니다.
         socat과 같은 일부 다른 프로그램은 기본적으로 문자열 길이만 사용합니다.
         HAProxy와 호환되도록 ",unix-tightsocklen=0" 옵션을 socat의 추상 소켓 정의에 
         전달합니다.
        
  See also : "source", "option forwardfor", "unix-bind" and the PROXY protocol
             documentation, and section 5 about bind options.

bind-process [ all | odd | even | <process_num>[-[<process_num>]] ] ...

  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    yes   |   yes  |   yes

  Deprecated. Before threads were supported, this was used to force some
  frontends on certain processes only, or to adjust backends so that they
  could match the frontends that used them. The default and only accepted
  value is "1" (along with "all" and "odd" which alias it). Do not use this
  setting. Threads can still be bound per-socket using the "process" bind
  keyword.
  
  더 이상 사용되지 않습니다. 스레드가 지원되기 전에는 특정 프로세스에만 일부 
  프런트엔드를 적용하거나 백엔드를 사용하는 프런트엔드와 일치하도록 백엔드를 
  조정하는 데 사용되었습니다.
  기본값이자 유일하게 허용되는 값은 "1"입니다(별칭인 "all" 및 "odd"와 함께). 
  이 설정을 사용하지 마십시오.
  스레드는 여전히 "process" 바인드 키워드를 사용하여 소켓별로 바인드될 수 있습니다.  

  See also : "process" in section 5.1.

capture cookie <name> len <length> 
  Capture and log a cookie in the request and in the response.
  요청과 응답에서 쿠키를 캡처하고 기록합니다.

  
  May be used in sections :   defaults | frontend | listen | backend
                                  no   |    yes   |   yes  |   no

Arguments :
<name> is the beginning of the name of the cookie to capture. In order
to match the exact name, simply suffix the name with an equal
sign ('='). The full name will appear in the logs, which is
useful with application servers which adjust both the cookie name
and value (e.g. ASPSESSIONXXX).

<name>은 캡처할 쿠키 이름의 시작 부분입니다.
정확한 이름을 일치시키려면 이름 뒤에 등호('=')를 붙입니다.
쿠키 이름과 값을 모두 조정하는 애플리케이션 서버에 유용한 전체
이름이 로그에 표시됩니다(예: ASPSESSIONXXX).

<length> is the maximum number of characters to report in the logs, which
include the cookie name, the equal sign and the value, all in the
standard "name=value" form. The string will be truncated on the
right if it exceeds <length>.

<length>는 쿠키 이름, 등호 및 값을 모두 표준 "name=value" 형식으로 포함하여
로그에 보고할 최대 문자 수입니다. 문자열이 <length>를 초과하면 오른쪽이
잘립니다.

Only the first cookie is captured. Both the "cookie" request headers and the
"set-cookie" response headers are monitored. This is particularly useful to
check for application bugs causing session crossing or stealing between
users, because generally the user's cookies can only change on a login page.

첫 번째 쿠키만 캡처됩니다. "cookie" 요청 헤더와 "set-cookie" 응답 헤더가 모두
모니터링됩니다. 이것은 일반적으로 사용자의 쿠키가 로그인 페이지에서만 변경될
수 있기 때문에 사용자 간에 세션 교차 또는 도용을 유발하는 애플리케이션 버그를
확인하는 데 특히 유용합니다.

When the cookie was not presented by the client, the associated log column
will report "-". When a request does not cause a cookie to be assigned by the
server, a "-" is reported in the response column.

클라이언트가 쿠키를 제공하지 않은 경우 연결된 로그 열에 "-"가 보고됩니다.
요청으로 인해 서버에서 쿠키를 할당하지 않으면 응답 열에 "-"가 보고됩니다.

The capture is performed in the frontend only because it is necessary that
the log format does not change for a given frontend depending on the
backends. This may change in the future. Note that there can be only one
"capture cookie" statement in a frontend. The maximum capture length is set
by the global "tune.http.cookielen" setting and defaults to 63 characters. It
is not possible to specify a capture in a "defaults" section.

캡처는 백엔드에 따라 주어진 프런트엔드에 대한 로그 형식이 변경되지 않아야 하기
때문에 프런트엔드에서만 수행됩니다.
이는 향후 변경될 수 있습니다. 프런트엔드에는 하나의 "capture cookie" 문만 있을 수 있습니다.
최대 캡처 길이는 전역 "tune.http.cookielen" 설정으로 설정되며 기본값은 63자입니다.
"defaults" 섹션에서 캡처를 지정할 수 없습니다.

  Example:
        capture cookie ASPSESSION len 32

  See also : "capture request header", "capture response header" as well as
            section 8 about logging.

capture request header <name> len <length>
  Capture and log the last occurrence of the specified request header.
  지정된 요청 헤더의 마지막 항목을 캡처하고 기록합니다.

  May be used in sections :   defaults | frontend | listen | backend
                                  no   |    yes   |   yes  |   no

Arguments :
<name> is the name of the header to capture. The header names are not
case-sensitive, but it is a common practice to write them as they
appear in the requests, with the first letter of each word in
upper case. The header name will not appear in the logs, only the
value is reported, but the position in the logs is respected.

<name>은 캡처할 헤더의 이름입니다. 헤더 이름은 대소문자를 구분하지 않지만
각 단어의 첫 글자를 대문자로 하여 요청에 나타나는 대로 작성하는 것이 일반적입니다.
헤더 이름은 로그에 표시되지 않고 값만 보고되지만 로그의 위치는 존중됩니다.

<length> is the maximum number of characters to extract from the value and
report in the logs. The string will be truncated on the right if
it exceeds <length>.
<length>는 값에서 추출하고 로그에 보고할 최대 문자 수입니다.
문자열이 <length>를 초과하면 오른쪽이 잘립니다.

The complete value of the last occurrence of the header is captured. The
value will be added to the logs between braces ('{}'). If multiple headers
are captured, they will be delimited by a vertical bar ('|') and will appear
in the same order they were declared in the configuration. Non-existent
headers will be logged just as an empty string. Common uses for request
header captures include the "Host" field in virtual hosting environments, the
"Content-length" when uploads are supported, "User-agent" to quickly
differentiate between real users and robots, and "X-Forwarded-For" in proxied
environments to find where the request came from.

마지막으로 나타나는 헤더의 전체 값이 캡처됩니다.
중괄호('{}') 사이의 로그에 값이 추가됩니다. 여러 헤더가 캡처되면 세로 막대('|')로
구분되며 구성에서 선언된 순서대로 나타납니다.
존재하지 않는 헤더는 빈 문자열로만 기록됩니다.
요청 헤더 캡처의 일반적인 용도로는 가상 호스팅 환경의 "Host" 필드, 업로드가
지원되는 경우 "Content-length", 실제 사용자와 로봇을 신속하게 구별하기 위한
"User-agent" 및 "X-Forwarded-For"가 있습니다.
요청이 어디에서 왔는지 찾기 위해 프록시 환경에서.

Note that when capturing headers such as "User-agent", some spaces may be
logged, making the log analysis more difficult. Thus be careful about what
you log if you know your log parser is not smart enough to rely on the
braces.
"User-agent"와 같은 헤더를 캡처할 때 일부 공백이 기록되어 로그 분석이 더 어려워질
수 있습니다. 따라서 로그 파서가 중괄호에 의존할 만큼 똑똑하지 않다는 것을 알고 있다면
기록하는 내용에 주의하십시오.

There is no limit to the number of captured request headers nor to their
length, though it is wise to keep them low to limit memory usage per session.
In order to keep log format consistent for a same frontend, header captures
can only be declared in a frontend. It is not possible to specify a capture
in a "defaults" section.

캡처된 요청 헤더의 수나 길이에는 제한이 없지만 세션당 메모리 사용량을 제한하려면
낮게 유지하는 것이 좋습니다.
동일한 프런트엔드에 대해 로그 형식을 일관되게 유지하기 위해 헤더 캡처는 프런트엔드에서만
선언할 수 있습니다. "defaults" 섹션에서 캡처를 지정할 수 없습니다.

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

See also : "capture cookie", "capture response header" as well as section 8
about logging.

capture response header <name> len <length>
Capture and log the last occurrence of the specified response header.
지정된 응답 헤더의 마지막 항목을 캡처하고 기록합니다.

  
  May be used in sections :   defaults | frontend | listen | backend
                                  no   |    yes   |   yes  |   no

Arguments :
<name> is the name of the header to capture. The header names are not
case-sensitive, but it is a common practice to write them as they
appear in the response, with the first letter of each word in
upper case. The header name will not appear in the logs, only the
value is reported, but the position in the logs is respected.

<name>은 캡처할 헤더의 이름입니다.
헤더 이름은 대소문자를 구분하지 않지만 응답에 나타나는 대로 각 단어의
첫 글자를 대문자로 작성하는 것이 일반적입니다.
헤더 이름은 로그에 표시되지 않고 값만 보고되지만 로그의 위치는 존중됩니다.

<length> is the maximum number of characters to extract from the value and
report in the logs. The string will be truncated on the right if
it exceeds <length>.

<length>는 값에서 추출하고 로그에 보고할 최대 문자 수입니다.
문자열이 <length>를 초과하면 오른쪽이 잘립니다.

The complete value of the last occurrence of the header is captured. The
result will be added to the logs between braces ('{}') after the captured
request headers. If multiple headers are captured, they will be delimited by
a vertical bar ('|') and will appear in the same order they were declared in
the configuration. Non-existent headers will be logged just as an empty
string. Common uses for response header captures include the "Content-length"
header which indicates how many bytes are expected to be returned, the
"Location" header to track redirections.

There is no limit to the number of captured response headers nor to their
length, though it is wise to keep them low to limit memory usage per session.
In order to keep log format consistent for a same frontend, header captures
can only be declared in a frontend. It is not possible to specify a capture
in a "defaults" section.

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

See also : "capture cookie", "capture request header" as well as section 8
about logging.

clitcpka-cnt <count>
Sets the maximum number of keepalive probes TCP should send before dropping
the connection on the client side.

  
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    yes   |   yes  |   no

  
  Arguments :
    <count>   is the maximum number of keepalive probes.

  This keyword corresponds to the socket option TCP_KEEPCNT. If this keyword
  is not specified, system-wide TCP parameter (tcp_keepalive_probes) is used.
  The availability of this setting depends on the operating system. It is
  known to work on Linux.

  See also : "option clitcpka", "clitcpka-idle", "clitcpka-intvl".

clitcpka-idle <timeout>
  Sets the time the connection needs to remain idle before TCP starts sending
  keepalive probes, if enabled the sending of TCP keepalive packets on the
  client side.
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    yes   |   yes  |   no
  Arguments :
    <timeout> is the time the connection needs to remain idle before TCP starts
              sending keepalive probes. It is specified in seconds by default,
              but can be in any other unit if the number is suffixed by the
              unit, as explained at the top of this document.

  This keyword corresponds to the socket option TCP_KEEPIDLE. If this keyword
  is not specified, system-wide TCP parameter (tcp_keepalive_time) is used.
  The availability of this setting depends on the operating system. It is
  known to work on Linux.

  See also : "option clitcpka", "clitcpka-cnt", "clitcpka-intvl".

clitcpka-intvl <timeout>
  Sets the time between individual keepalive probes on the client side.
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    yes   |   yes  |   no
  Arguments :
    <timeout> is the time between individual keepalive probes. It is specified
              in seconds by default, but can be in any other unit if the number
              is suffixed by the unit, as explained at the top of this
              document.

  This keyword corresponds to the socket option TCP_KEEPINTVL. If this keyword
  is not specified, system-wide TCP parameter (tcp_keepalive_intvl) is used.
  The availability of this setting depends on the operating system. It is
  known to work on Linux.

  See also : "option clitcpka", "clitcpka-cnt", "clitcpka-idle".

compression algo <algorithm> ...
compression type  ...
  Enable HTTP compression.
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    yes   |   yes  |   yes
  Arguments :
    algo     is followed by the list of supported compression algorithms.
    type     is followed by the list of MIME types that will be compressed.

  The currently supported algorithms are :
    identity     this is mostly for debugging, and it was useful for developing
                 the compression feature. Identity does not apply any change on
                 data.

    gzip         applies gzip compression. This setting is only available when
                 support for zlib or libslz was built in.

    deflate      same as "gzip", but with deflate algorithm and zlib format.
                 Note that this algorithm has ambiguous support on many
                 browsers and no support at all from recent ones. It is
                 strongly recommended not to use it for anything else than
                 experimentation. This setting is only available when support
                 for zlib or libslz was built in.

    raw-deflate  same as "deflate" without the zlib wrapper, and used as an
                 alternative when the browser wants "deflate". All major
                 browsers understand it and despite violating the standards,
                 it is known to work better than "deflate", at least on MSIE
                 and some versions of Safari. Do not use it in conjunction
                 with "deflate", use either one or the other since both react
                 to the same Accept-Encoding token. This setting is only
                 available when support for zlib or libslz was built in.

  Compression will be activated depending on the Accept-Encoding request
  header. With identity, it does not take care of that header.
  If backend servers support HTTP compression, these directives
  will be no-op: HAProxy will see the compressed response and will not
  compress again. If backend servers do not support HTTP compression and
  there is Accept-Encoding header in request, HAProxy will compress the
  matching response.

  Compression is disabled when:
    * the request does not advertise a supported compression algorithm in the
      "Accept-Encoding" header
    * the response message is not HTTP/1.1 or above
    * HTTP status code is not one of 200, 201, 202, or 203
    * response contain neither a "Content-Length" header nor a
      "Transfer-Encoding" whose last value is "chunked"
    * response contains a "Content-Type" header whose first value starts with
      "multipart"
    * the response contains the "no-transform" value in the "Cache-control"
      header
    * User-Agent matches "Mozilla/4" unless it is MSIE 6 with XP SP2, or MSIE 7
      and later
    * The response contains a "Content-Encoding" header, indicating that the
      response is already compressed (see compression offload)
    * The response contains an invalid "ETag" header or multiple ETag headers

  Note: The compression does not emit the Warning header.

  Examples :
        compression algo gzip
        compression type text/html text/plain

  See also : "compression offload"

compression offload
  Makes HAProxy work as a compression offloader only.
  May be used in sections :   defaults | frontend | listen | backend
                                 no    |    yes   |   yes  |   yes

  The "offload" setting makes HAProxy remove the Accept-Encoding header to
  prevent backend servers from compressing responses. It is strongly
  recommended not to do this because this means that all the compression work
  will be done on the single point where HAProxy is located. However in some
  deployment scenarios, HAProxy may be installed in front of a buggy gateway
  with broken HTTP compression implementation which can't be turned off.
  In that case HAProxy can be used to prevent that gateway from emitting
  invalid payloads. In this case, simply removing the header in the
  configuration does not work because it applies before the header is parsed,
  so that prevents HAProxy from compressing. The "offload" setting should
  then be used for such scenarios.

  If this setting is used in a defaults section, a warning is emitted and the
  option is ignored.

  See also : "compression type", "compression algo"

cookie <name> [ rewrite | insert | prefix ] [ indirect ] [ nocache ]
              [ postonly ] [ preserve ] [ httponly ] [ secure ]
              [ domain  ]* [ maxidle  ] [ maxlife  ]
              [ dynamic ] [ attr <value> ]*
  Enable cookie-based persistence in a backend.
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    no    |   yes  |   yes
  Arguments :
    <name>    is the name of the cookie which will be monitored, modified or
              inserted in order to bring persistence. This cookie is sent to
              the client via a "Set-Cookie" header in the response, and is
              brought back by the client in a "Cookie" header in all requests.
              Special care should be taken to choose a name which does not
              conflict with any likely application cookie. Also, if the same
              backends are subject to be used by the same clients (e.g.
              HTTP/HTTPS), care should be taken to use different cookie names
              between all backends if persistence between them is not desired.

    rewrite   This keyword indicates that the cookie will be provided by the
              server and that HAProxy will have to modify its value to set the
              server's identifier in it. This mode is handy when the management
              of complex combinations of "Set-cookie" and "Cache-control"
              headers is left to the application. The application can then
              decide whether or not it is appropriate to emit a persistence
              cookie. Since all responses should be monitored, this mode
              doesn't work in HTTP tunnel mode. Unless the application
              behavior is very complex and/or broken, it is advised not to
              start with this mode for new deployments. This keyword is
              incompatible with "insert" and "prefix".

    insert    This keyword indicates that the persistence cookie will have to
              be inserted by HAProxy in server responses if the client did not

              already have a cookie that would have permitted it to access this
              server. When used without the "preserve" option, if the server
              emits a cookie with the same name, it will be removed before
              processing. For this reason, this mode can be used to upgrade
              existing configurations running in the "rewrite" mode. The cookie
              will only be a session cookie and will not be stored on the
              client's disk. By default, unless the "indirect" option is added,
              the server will see the cookies emitted by the client. Due to
              caching effects, it is generally wise to add the "nocache" or
              "postonly" keywords (see below). The "insert" keyword is not
              compatible with "rewrite" and "prefix".

    prefix    This keyword indicates that instead of relying on a dedicated
              cookie for the persistence, an existing one will be completed.
              This may be needed in some specific environments where the client
              does not support more than one single cookie and the application
              already needs it. In this case, whenever the server sets a cookie
              named <name>, it will be prefixed with the server's identifier
              and a delimiter. The prefix will be removed from all client
              requests so that the server still finds the cookie it emitted.
              Since all requests and responses are subject to being modified,
              this mode doesn't work with tunnel mode. The "prefix" keyword is
              not compatible with "rewrite" and "insert". Note: it is highly
              recommended not to use "indirect" with "prefix", otherwise server
              cookie updates would not be sent to clients.

    indirect  When this option is specified, no cookie will be emitted to a
              client which already has a valid one for the server which has
              processed the request. If the server sets such a cookie itself,
              it will be removed, unless the "preserve" option is also set. In
              "insert" mode, this will additionally remove cookies from the
              requests transmitted to the server, making the persistence
              mechanism totally transparent from an application point of view.
              Note: it is highly recommended not to use "indirect" with
              "prefix", otherwise server cookie updates would not be sent to
              clients.

    nocache   This option is recommended in conjunction with the insert mode
              when there is a cache between the client and HAProxy, as it
              ensures that a cacheable response will be tagged non-cacheable if
              a cookie needs to be inserted. This is important because if all
              persistence cookies are added on a cacheable home page for
              instance, then all customers will then fetch the page from an
              outer cache and will all share the same persistence cookie,
              leading to one server receiving much more traffic than others.
              See also the "insert" and "postonly" options.

    postonly  This option ensures that cookie insertion will only be performed
              on responses to POST requests. It is an alternative to the
              "nocache" option, because POST responses are not cacheable, so
              this ensures that the persistence cookie will never get cached.
              Since most sites do not need any sort of persistence before the
              first POST which generally is a login request, this is a very
              efficient method to optimize caching without risking to find a
              persistence cookie in the cache.
              See also the "insert" and "nocache" options.

    preserve  This option may only be used with "insert" and/or "indirect". It
              allows the server to emit the persistence cookie itself. In this
              case, if a cookie is found in the response, HAProxy will leave it
              untouched. This is useful in order to end persistence after a
              logout request for instance. For this, the server just has to
              emit a cookie with an invalid value (e.g. empty) or with a date in
              the past. By combining this mechanism with the "disable-on-404"
              check option, it is possible to perform a completely graceful
              shutdown because users will definitely leave the server after
              they logout.

    httponly  This option tells HAProxy to add an "HttpOnly" cookie attribute
              when a cookie is inserted. This attribute is used so that a
              user agent doesn't share the cookie with non-HTTP components.
              Please check RFC6265 for more information on this attribute.

    secure    This option tells HAProxy to add a "Secure" cookie attribute when
              a cookie is inserted. This attribute is used so that a user agent
              never emits this cookie over non-secure channels, which means
              that a cookie learned with this flag will be presented only over
              SSL/TLS connections. Please check RFC6265 for more information on
              this attribute.

    domain    This option allows to specify the domain at which a cookie is
              inserted. It requires exactly one parameter: a valid domain
              name. If the domain begins with a dot, the browser is allowed to
              use it for any host ending with that name. It is also possible to
              specify several domain names by invoking this option multiple
              times. Some browsers might have small limits on the number of
              domains, so be careful when doing that. For the record, sending
              10 domains to MSIE 6 or Firefox 2 works as expected.

    maxidle   This option allows inserted cookies to be ignored after some idle
              time. It only works with insert-mode cookies. When a cookie is
              sent to the client, the date this cookie was emitted is sent too.
              Upon further presentations of this cookie, if the date is older
              than the delay indicated by the parameter (in seconds), it will
              be ignored. Otherwise, it will be refreshed if needed when the
              response is sent to the client. This is particularly useful to
              prevent users who never close their browsers from remaining for
              too long on the same server (e.g. after a farm size change). When
              this option is set and a cookie has no date, it is always
              accepted, but gets refreshed in the response. This maintains the
              ability for admins to access their sites. Cookies that have a
              date in the future further than 24 hours are ignored. Doing so
              lets admins fix timezone issues without risking kicking users off
              the site.

    maxlife   This option allows inserted cookies to be ignored after some life
              time, whether they're in use or not. It only works with insert
              mode cookies. When a cookie is first sent to the client, the date
              this cookie was emitted is sent too. Upon further presentations
              of this cookie, if the date is older than the delay indicated by
              the parameter (in seconds), it will be ignored. If the cookie in
              the request has no date, it is accepted and a date will be set.
              Cookies that have a date in the future further than 24 hours are
              ignored. Doing so lets admins fix timezone issues without risking
              kicking users off the site. Contrary to maxidle, this value is
              not refreshed, only the first visit date counts. Both maxidle and
              maxlife may be used at the time. This is particularly useful to
              prevent users who never close their browsers from remaining for
              too long on the same server (e.g. after a farm size change). This
              is stronger than the maxidle method in that it forces a
              redispatch after some absolute delay.

    dynamic   Activate dynamic cookies. When used, a session cookie is
              dynamically created for each server, based on the IP and port
              of the server, and a secret key, specified in the
              "dynamic-cookie-key" backend directive.
              The cookie will be regenerated each time the IP address change,
              and is only generated for IPv4/IPv6.

    attr      This option tells HAProxy to add an extra attribute when a
              cookie is inserted. The attribute value can contain any
              characters except control ones or ";". This option may be
              repeated.

  There can be only one persistence cookie per HTTP backend, and it can be
  declared in a defaults section. The value of the cookie will be the value
  indicated after the "cookie" keyword in a "server" statement. If no cookie
  is declared for a given server, the cookie is not set.

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

  See also : "balance source", "capture cookie", "server" and "ignore-persist".

declare capture [ request | response ] len <length>
  Declares a capture slot.
  May be used in sections :   defaults | frontend | listen | backend
                                 no    |    yes   |   yes  |   no
  Arguments:
    <length> is the length allowed for the capture.

  This declaration is only available in the frontend or listen section, but the
  reserved slot can be used in the backends. The "request" keyword allocates a
  capture slot for use in the request, and "response" allocates a capture slot
  for use in the response.

  See also: "capture-req", "capture-res" (sample converters),
            "capture.req.hdr", "capture.res.hdr" (sample fetches),
            "http-request capture" and "http-response capture".


default-server [param*]
  Change default options for a server in a backend
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    no    |   yes  |   yes
  Arguments:
    <param*>  is a list of parameters for this server. The "default-server"
              keyword accepts an important number of options and has a complete
              section dedicated to it. Please refer to section 5 for more
              details.

  Example :
        default-server inter 1000 weight 13

  See also: "server" and section 5 about server options

default_backend <backend>
  Specify the backend to use when no "use_backend" rule has been matched.
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    yes   |   yes  |   no
  Arguments :
    <backend> is the name of the backend to use.

  When doing content-switching between frontend and backends using the
  "use_backend" keyword, it is often useful to indicate which backend will be
  used when no rule has matched. It generally is the dynamic backend which
  will catch all undetermined requests.

  Example :

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

  See also : "use_backend"

description <string>
  Describe a listen, frontend or backend.
  May be used in sections :   defaults | frontend | listen | backend
                                 no    |    yes   |   yes  |   yes
  Arguments : string

  Allows to add a sentence to describe the related object in the HAProxy HTML
  stats page. The description will be printed on the right of the object name
  it describes.
  No need to backslash spaces in the <string> arguments.

disabled
  Disable a proxy, frontend or backend.
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    yes   |   yes  |   yes
  Arguments : none

  The "disabled" keyword is used to disable an instance, mainly in order to
  liberate a listening port or to temporarily disable a service. The instance
  will still be created and its configuration will be checked, but it will be
  created in the "stopped" state and will appear as such in the statistics. It
  will not receive any traffic nor will it send any health-checks or logs. It
  is possible to disable many instances at once by adding the "disabled"
  keyword in a "defaults" section.

  See also : "enabled"

dispatch <address>:<port>
  Set a default server address
  May be used in sections :   defaults | frontend | listen | backend
                                 no    |    no    |   yes  |   yes
  Arguments :

    <address> is the IPv4 address of the default server. Alternatively, a
              resolvable hostname is supported, but this name will be resolved
              during start-up.

    <ports>   is a mandatory port specification. All connections will be sent
              to this port, and it is not permitted to use port offsets as is
              possible with normal servers.

  The "dispatch" keyword designates a default server for use when no other
  server can take the connection. In the past it was used to forward non
  persistent connections to an auxiliary load balancer. Due to its simple
  syntax, it has also been used for simple TCP relays. It is recommended not to
  use it for more clarity, and to use the "server" directive instead.

  See also : "server"

dynamic-cookie-key <string>
  Set the dynamic cookie secret key for a backend.
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    no    |   yes  |   yes
  Arguments : The secret key to be used.

  When dynamic cookies are enabled (see the "dynamic" directive for cookie),
  a dynamic cookie is created for each server (unless one is explicitly
  specified on the "server" line), using a hash of the IP address of the
  server, the TCP port, and the secret key.
  That way, we can ensure session persistence across multiple load-balancers,
  even if servers are dynamically added or removed.

enabled
  Enable a proxy, frontend or backend.
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    yes   |   yes  |   yes
  Arguments : none

  The "enabled" keyword is used to explicitly enable an instance, when the
  defaults has been set to "disabled". This is very rarely used.

  See also : "disabled"

errorfile <code> <file>
  Return a file contents instead of errors generated by HAProxy
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    yes   |   yes  |   yes
  Arguments :
    <code>    is the HTTP status code. Currently, HAProxy is capable of
              generating codes 200, 400, 401, 403, 404, 405, 407, 408, 410,
              413, 425, 429, 500, 501, 502, 503, and 504.

    <file>    designates a file containing the full HTTP response. It is
              recommended to follow the common practice of appending ".http" to
              the filename so that people do not confuse the response with HTML
              error pages, and to use absolute paths, since files are read
              before any chroot is performed.

  It is important to understand that this keyword is not meant to rewrite
  errors returned by the server, but errors detected and returned by HAProxy.
  This is why the list of supported errors is limited to a small set.

  Code 200 is emitted in response to requests matching a "monitor-uri" rule.

  The files are parsed when HAProxy starts and must be valid according to the
  HTTP specification. They should not exceed the configured buffer size
  (BUFSIZE), which generally is 16 kB, otherwise an internal error will be
  returned. It is also wise not to put any reference to local contents
  (e.g. images) in order to avoid loops between the client and HAProxy when all
  servers are down, causing an error to be returned instead of an
  image. Finally, The response cannot exceed (tune.bufsize - tune.maxrewrite)
  so that "http-after-response" rules still have room to operate (see
  "tune.maxrewrite").

  The files are read at the same time as the configuration and kept in memory.
  For this reason, the errors continue to be returned even when the process is
  chrooted, and no file change is considered while the process is running. A
  simple method for developing those files consists in associating them to the
  403 status code and interrogating a blocked URL.

  See also : "http-error", "errorloc", "errorloc302", "errorloc303"

  Example :
        errorfile 400 /etc/haproxy/errorfiles/400badreq.http
        errorfile 408 /dev/null  # work around Chrome pre-connect bug
        errorfile 403 /etc/haproxy/errorfiles/403forbid.http
        errorfile 503 /etc/haproxy/errorfiles/503sorry.http

errorfiles <name> [<code> ...]
  Import, fully or partially, the error files defined in the <name> http-errors
  section.
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    yes   |   yes  |   yes
  Arguments :
    <name>  is the name of an existing http-errors section.

    <code>  is a HTTP status code. Several status code may be listed.
            Currently, HAProxy is capable of generating codes 200, 400, 401,
            403, 404, 405, 407, 408, 410, 413, 425, 429, 500, 501, 502, 503,
            and 504.

  Errors defined in the http-errors section with the name <name> are imported
  in the current proxy. If no status code is specified, all error files of the
  http-errors section are imported. Otherwise, only error files associated to
  the listed status code are imported. Those error files override the already
  defined custom errors for the proxy. And they may be overridden by following
  ones. Functionally, it is exactly the same as declaring all error files by
  hand using "errorfile" directives.

  See also : "http-error", "errorfile", "errorloc", "errorloc302" ,
             "errorloc303" and section 3.8 about http-errors.

  Example :
        errorfiles generic
    errorfiles site-1 403 404

errorloc <code> 
errorloc302 <code> 
  Return an HTTP redirection to a URL instead of errors generated by HAProxy
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    yes   |   yes  |   yes
  Arguments :
    <code>    is the HTTP status code. Currently, HAProxy is capable of
              generating codes 200, 400, 401, 403, 404, 405, 407, 408, 410,
              413, 425, 429, 500, 501, 502, 503, and 504.

         it is the exact contents of the "Location" header. It may contain
              either a relative URI to an error page hosted on the same site,
              or an absolute URI designating an error page on another site.
              Special care should be given to relative URIs to avoid redirect
              loops if the URI itself may generate the same error (e.g. 500).

  It is important to understand that this keyword is not meant to rewrite
  errors returned by the server, but errors detected and returned by HAProxy.
  This is why the list of supported errors is limited to a small set.

  Code 200 is emitted in response to requests matching a "monitor-uri" rule.

  Note that both keyword return the HTTP 302 status code, which tells the
  client to fetch the designated URL using the same HTTP method. This can be
  quite problematic in case of non-GET methods such as POST, because the URL
  sent to the client might not be allowed for something other than GET. To
  work around this problem, please use "errorloc303" which send the HTTP 303
  status code, indicating to the client that the URL must be fetched with a GET
  request.

  See also : "http-error", "errorfile", "errorloc303"

errorloc303 <code> 
  Return an HTTP redirection to a URL instead of errors generated by HAProxy
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    yes   |   yes  |   yes
  Arguments :
    <code>    is the HTTP status code. Currently, HAProxy is capable of
              generating codes 200, 400, 401, 403, 404, 405, 407, 408, 410,
              413, 425, 429, 500, 501, 502, 503, and 504.

         it is the exact contents of the "Location" header. It may contain
              either a relative URI to an error page hosted on the same site,
              or an absolute URI designating an error page on another site.
              Special care should be given to relative URIs to avoid redirect
              loops if the URI itself may generate the same error (e.g. 500).

  It is important to understand that this keyword is not meant to rewrite
  errors returned by the server, but errors detected and returned by HAProxy.
  This is why the list of supported errors is limited to a small set.

  Code 200 is emitted in response to requests matching a "monitor-uri" rule.

  Note that both keyword return the HTTP 303 status code, which tells the
  client to fetch the designated URL using the same HTTP GET method. This
  solves the usual problems associated with "errorloc" and the 302 code. It is
  possible that some very old browsers designed before HTTP/1.1 do not support
  it, but no such problem has been reported till now.

  See also : "http-error", "errorfile", "errorloc", "errorloc302"

email-alert from 
  Declare the from email address to be used in both the envelope and header
  of email alerts. This is the address that email alerts are sent from.
  May be used in sections:    defaults | frontend | listen | backend
                                 yes   |    yes   |   yes  |   yes

  Arguments :

     is the from email address to use when sending email alerts

  Also requires "email-alert mailers" and "email-alert to" to be set
  and if so sending email alerts is enabled for the proxy.

  See also : "email-alert level", "email-alert mailers",
             "email-alert myhostname", "email-alert to", section 3.6 about
             mailers.

email-alert level <level>
  Declare the maximum log level of messages for which email alerts will be
  sent. This acts as a filter on the sending of email alerts.
  May be used in sections:    defaults | frontend | listen | backend
                                 yes   |    yes   |   yes  |   yes

  Arguments :

    <level> One of the 8 syslog levels:
              emerg alert crit err warning notice info  debug
            The above syslog levels are ordered from lowest to highest.

  By default level is alert

  Also requires "email-alert from", "email-alert mailers" and
  "email-alert to" to be set and if so sending email alerts is enabled
  for the proxy.

  Alerts are sent when :

  * An un-paused server is marked as down and <level> is alert or lower
  * A paused server is marked as down and <level> is notice or lower
  * A server is marked as up or enters the drain state and <level>
    is notice or lower
  * "option log-health-checks" is enabled, <level> is info or lower,
     and a health check status update occurs

  See also : "email-alert from", "email-alert mailers",
             "email-alert myhostname", "email-alert to",
             section 3.6 about mailers.

email-alert mailers <mailersect>
  Declare the mailers to be used when sending email alerts
  May be used in sections:    defaults | frontend | listen | backend
                                 yes   |    yes   |   yes  |   yes

  Arguments :

    <mailersect> is the name of the mailers section to send email alerts.

  Also requires "email-alert from" and "email-alert to" to be set
  and if so sending email alerts is enabled for the proxy.

  See also : "email-alert from", "email-alert level", "email-alert myhostname",
             "email-alert to", section 3.6 about mailers.

email-alert myhostname 
  Declare the to hostname address to be used when communicating with
  mailers.
  May be used in sections:    defaults | frontend | listen | backend
                                 yes   |    yes   |   yes  |   yes

  Arguments :

     is the hostname to use when communicating with mailers

  By default the systems hostname is used.

  Also requires "email-alert from", "email-alert mailers" and
  "email-alert to" to be set and if so sending email alerts is enabled
  for the proxy.

  See also : "email-alert from", "email-alert level", "email-alert mailers",
             "email-alert to", section 3.6 about mailers.

email-alert to 
  Declare both the recipient address in the envelope and to address in the
  header of email alerts. This is the address that email alerts are sent to.
  May be used in sections:    defaults | frontend | listen | backend
                                 yes   |    yes   |   yes  |   yes

  Arguments :

     is the to email address to use when sending email alerts

  Also requires "email-alert mailers" and "email-alert to" to be set
  and if so sending email alerts is enabled for the proxy.

  See also : "email-alert from", "email-alert level", "email-alert mailers",
             "email-alert myhostname", section 3.6 about mailers.

error-log-format <string>
  Specifies the log format string to use in case of connection error on the frontend side.
  May be used in sections:    defaults | frontend | listen | backend
                                 yes   |    yes   |   yes  |    no

  This directive specifies the log format string that will be used for logs
  containing information related to errors, timeouts, retries redispatches or
  HTTP status code 5xx. This format will in short be used for every log line
  that would be concerned by the "log-separate-errors" option, including
  connection errors described in section 8.2.5.

  If the directive is used in a defaults section, all subsequent frontends will
  use the same log format. Please see section 8.2.4 which covers the log format
  string in depth.

  "error-log-format" directive overrides previous "error-log-format"
  directives.

force-persist { if | unless } <condition>
  Declare a condition to force persistence on down servers
  May be used in sections:    defaults | frontend | listen | backend
                                  no   |    no    |   yes  |   yes

  By default, requests are not dispatched to down servers. It is possible to
  force this using "option persist", but it is unconditional and redispatches
  to a valid server if "option redispatch" is set. That leaves with very little
  possibilities to force some requests to reach a server which is artificially
  marked down for maintenance operations.

  The "force-persist" statement allows one to declare various ACL-based
  conditions which, when met, will cause a request to ignore the down status of
  a server and still try to connect to it. That makes it possible to start a
  server, still replying an error to the health checks, and run a specially
  configured browser to test the service. Among the handy methods, one could
  use a specific source IP address, or a specific cookie. The cookie also has
  the advantage that it can easily be added/removed on the browser from a test
  page. Once the service is validated, it is then possible to open the service
  to the world by returning a valid response to health checks.

  The forced persistence is enabled when an "if" condition is met, or unless an
  "unless" condition is met. The final redispatch is always disabled when this
  is used.

  See also : "option redispatch", "ignore-persist", "persist",
             and section 7 about ACL usage.

filter <name> [param*]
  Add the filter <name> in the filter list attached to the proxy.
  May be used in sections :   defaults | frontend | listen | backend
                                 no    |   yes    |   yes  |   yes
  Arguments :
    <name>     is the name of the filter. Officially supported filters are
               referenced in section 9.

    <param*>   is a list of parameters accepted by the filter <name>. The
               parsing of these parameters are the responsibility of the
               filter. Please refer to the documentation of the corresponding
               filter (section 9) for all details on the supported parameters.

  Multiple occurrences of the filter line can be used for the same proxy. The
  same filter can be referenced many times if needed.

  Example:
      listen
        bind *:80

        filter trace name BEFORE-HTTP-COMP
        filter compression
        filter trace name AFTER-HTTP-COMP

        compression algo gzip
        compression offload

        server srv1 192.168.0.1:80

  See also : section 9.

fullconn <conns>
  Specify at what backend load the servers will reach their maxconn
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    no    |   yes  |   yes
  Arguments :
    <conns>   is the number of connections on the backend which will make the
              servers use the maximal number of connections.

  When a server has a "maxconn" parameter specified, it means that its number
  of concurrent connections will never go higher. Additionally, if it has a
  "minconn" parameter, it indicates a dynamic limit following the backend's
  load. The server will then always accept at least <minconn> connections,
  never more than , and the limit will be on the ramp between both
  values when the backend has less than <conns> concurrent connections. This
  makes it possible to limit the load on the servers during normal loads, but
  push it further for important loads without overloading the servers during
  exceptional loads.

  Since it's hard to get this value right, HAProxy automatically sets it to
  10% of the sum of the maxconns of all frontends that may branch to this
  backend (based on "use_backend" and "default_backend" rules). That way it's
  safe to leave it unset. However, "use_backend" involving dynamic names are
  not counted since there is no way to know if they could match or not.

  Example :
     # The servers will accept between 100 and 1000 concurrent connections each
     # and the maximum of 1000 will be reached when the backend reaches 10000
     # connections.
     backend dynamic
        fullconn   10000
        server     srv1   dyn1:80 minconn 100 maxconn 1000
        server     srv2   dyn2:80 minconn 100 maxconn 1000

  See also : "maxconn", "server"

hash-balance-factor 
  Specify the balancing factor for bounded-load consistent hashing
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    no    |   no   |   yes
  Arguments :
     is the control for the maximum number of concurrent requests to
             send to a server, expressed as a percentage of the average number
             of concurrent requests across all of the active servers.

  Specifying a "hash-balance-factor" for a server with "hash-type consistent"
  enables an algorithm that prevents any one server from getting too many
  requests at once, even if some hash buckets receive many more requests than
  others. Setting  to 0 (the default) disables the feature. Otherwise,
   is a percentage greater than 100. For example, if  is 150,
  then no server will be allowed to have a load more than 1.5 times the average.
  If server weights are used, they will be respected.

  If the first-choice server is disqualified, the algorithm will choose another
  server based on the request hash, until a server with additional capacity is
  found. A higher  allows more imbalance between the servers, while a
  lower  means that more servers will be checked on average, affecting
  performance. Reasonable values are from 125 to 200.

  This setting is also used by "balance random" which internally relies on the
  consistent hashing mechanism.

  See also : "balance" and "hash-type".

hash-type <method> <function> <modifier>
  Specify a method to use for mapping hashes to servers
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    no    |   yes  |   yes
  Arguments :
    <method> is the method used to select a server from the hash computed by
             the <function> :

      map-based   the hash table is a static array containing all alive servers.
                  The hashes will be very smooth, will consider weights, but
                  will be static in that weight changes while a server is up
                  will be ignored. This means that there will be no slow start.
                  Also, since a server is selected by its position in the array,
                  most mappings are changed when the server count changes. This
                  means that when a server goes up or down, or when a server is
                  added to a farm, most connections will be redistributed to
                  different servers. This can be inconvenient with caches for
                  instance.

      consistent  the hash table is a tree filled with many occurrences of each
                  server. The hash key is looked up in the tree and the closest
                  server is chosen. This hash is dynamic, it supports changing
                  weights while the servers are up, so it is compatible with the
                  slow start feature. It has the advantage that when a server
                  goes up or down, only its associations are moved. When a
                  server is added to the farm, only a few part of the mappings
                  are redistributed, making it an ideal method for caches.
                  However, due to its principle, the distribution will never be
                  very smooth and it may sometimes be necessary to adjust a
                  server's weight or its ID to get a more balanced distribution.
                  In order to get the same distribution on multiple load
                  balancers, it is important that all servers have the exact
                  same IDs. Note: consistent hash uses sdbm and avalanche if no
                  hash function is specified.

    <function> is the hash function to be used :

       sdbm   this function was created initially for sdbm (a public-domain
              reimplementation of ndbm) database library. It was found to do
              well in scrambling bits, causing better distribution of the keys
              and fewer splits. It also happens to be a good general hashing
              function with good distribution, unless the total server weight
              is a multiple of 64, in which case applying the avalanche
              modifier may help.

       djb2   this function was first proposed by Dan Bernstein many years ago
              on comp.lang.c. Studies have shown that for certain workload this
              function provides a better distribution than sdbm. It generally
              works well with text-based inputs though it can perform extremely
              poorly with numeric-only input or when the total server weight is
              a multiple of 33, unless the avalanche modifier is also used.

       wt6    this function was designed for HAProxy while testing other
              functions in the past. It is not as smooth as the other ones, but
              is much less sensible to the input data set or to the number of
              servers. It can make sense as an alternative to sdbm+avalanche or
              djb2+avalanche for consistent hashing or when hashing on numeric
              data such as a source IP address or a visitor identifier in a URL
              parameter.

       crc32  this is the most common CRC32 implementation as used in Ethernet,
              gzip, PNG, etc. It is slower than the other ones but may provide
              a better distribution or less predictable results especially when
              used on strings.

    <modifier> indicates an optional method applied after hashing the key :

       avalanche   This directive indicates that the result from the hash
                   function above should not be used in its raw form but that
                   a 4-byte full avalanche hash must be applied first. The
                   purpose of this step is to mix the resulting bits from the
                   previous hash in order to avoid any undesired effect when
                   the input contains some limited values or when the number of
                   servers is a multiple of one of the hash's components (64
                   for SDBM, 33 for DJB2). Enabling avalanche tends to make the
                   result less predictable, but it's also not as smooth as when
                   using the original function. Some testing might be needed
                   with some workloads. This hash is one of the many proposed
                   by Bob Jenkins.

  The default hash type is "map-based" and is recommended for most usages. The
  default function is "sdbm", the selection of a function should be based on
  the range of the values being hashed.

  See also : "balance", "hash-balance-factor", "server"

http-after-response <action> <options...> [ { if | unless } <condition> ]
  Access control for all Layer 7 responses (server, applet/service and internal
  ones).

  May be used in sections:   defaults | frontend | listen | backend
                               yes(!) |    yes   |   yes  |   yes

  The http-after-response statement defines a set of rules which apply to layer
  7 processing. The rules are evaluated in their declaration order when they
  are met in a frontend, listen or backend section. Any rule may optionally be
  followed by an ACL-based condition, in which case it will only be evaluated
  if the condition is true. Since these rules apply on responses, the backend
  rules are applied first, followed by the frontend's rules.

  Unlike http-response rules, these ones are applied on all responses, the
  server ones but also to all responses generated by HAProxy. These rules are
  evaluated at the end of the responses analysis, before the data forwarding.

  The first keyword is the rule's action. Several types of actions are
  supported:
    - add-header <name> <fmt>
    - allow
    - capture <sample> id <id>
    - del-header <name> [ -m  ]
    - replace-header <name> <regex-match> <replace-fmt>
    - replace-value <name> <regex-match> <replace-fmt>
    - set-header <name> <fmt>
    - set-status  [reason ]
    - set-var(<var-name>[,<cond> ...]) <expr>
    - set-var-fmt(<var-name>[,<cond> ...]) <fmt>
    - strict-mode { on | off }
    - unset-var(<var-name>)

  The supported actions are described below.

  There is no limit to the number of http-after-response statements per
  instance.

  This directive is only available from named defaults sections, not anonymous
  ones. Rules defined in the defaults section are evaluated before ones in the
  associated proxy section. To avoid ambiguities, in this case the same
  defaults section cannot be used by proxies with the frontend capability and
  by proxies with the backend capability. It means a listen section cannot use
  a defaults section defining such rules.

  Note: Errors emitted in early stage of the request parsing are handled by the
        multiplexer at a lower level, before any http analysis. Thus no
        http-after-response ruleset is evaluated on these errors.

  Example:
    http-after-response set-header Strict-Transport-Security "max-age=31536000"
    http-after-response set-header Cache-Control "no-store,no-cache,private"
    http-after-response set-header Pragma "no-cache"

http-after-response add-header <name> <fmt> [ { if | unless } <condition> ]

  This appends an HTTP header field whose name is specified in <name> and whose
  value is defined by <fmt>. Please refer to "http-request add-header" for a
  complete description.

http-after-response capture <sample> id <id> [ { if | unless } <condition> ]

  This captures sample expression <sample> from the response buffer, and
  converts it to a string. Please refer to "http-response capture" for a
  complete description.

http-after-response allow [ { if | unless } <condition> ]

  This stops the evaluation of the rules and lets the response pass the check.
  No further "http-after-response" rules are evaluated for the current section.

http-after-response del-header <name> [ -m  ] [ { if | unless } <condition> ]

  This removes all HTTP header fields whose name is specified in <name>. Please
  refer to "http-request del-header" for a complete description.

http-after-response replace-header <name> <regex-match> <replace-fmt>
                                   [ { if | unless } <condition> ]

  This works like "http-response replace-header".

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

    # applied to:
    Set-Cookie: C=1; expires=Tue, 14-Jun-2016 01:40:45 GMT

    # outputs:
    Set-Cookie: C=1;ip=192.168.1.20; expires=Tue, 14-Jun-2016 01:40:45 GMT

    # assuming the backend IP is 192.168.1.20.

http-after-response replace-value <name> <regex-match> <replace-fmt>
                                 [ { if | unless } <condition> ]

  This works like "http-response replace-value".

  Example:
    http-after-response replace-value Cache-control ^public$ private

    # applied to:
    Cache-Control: max-age=3600, public

    # outputs:
    Cache-Control: max-age=3600, private

http-after-response set-header <name> <fmt> [ { if | unless } <condition> ]

  This does the same as "http-after-response add-header" except that the header
  name is first removed if it existed. This is useful when passing security
  information to the server, where the header must not be manipulated by
  external users.

http-after-response set-status  [reason ]
                               [ { if | unless } <condition> ]

  This replaces the response status code with  which must be an integer
  between 100 and 999. Please refer to "http-response set-status" for a complete
  description.

http-after-response set-var(<var-name>[,<cond> ...]) <expr> [ { if | unless } <condition> ]
http-after-response set-var-fmt(<var-name>[,<cond> ...]) <fmt> [ { if | unless } <condition> ]

  This is used to set the contents of a variable. The variable is declared
  inline. Please refer to "http-request set-var" and "http-request set-var-fmt"
  for a complete description.

http-after-response strict-mode { on | off }  [ { if | unless } <condition> ]

  This enables or disables the strict rewriting mode for following
  rules. Please refer to "http-request strict-mode" for a complete description.

http-after-response unset-var(<var-name>) [ { if | unless } <condition> ]

  This is used to unset a variable. See "http-request set-var" for details
  about <var-name>.

http-check comment <string>
  Defines a comment for the following the http-check rule, reported in logs if
  it fails.
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    no    |   yes  |   yes

  Arguments :
    <string>  is the comment message to add in logs if the following http-check
              rule fails.

  It only works for connect, send and expect rules. It is useful to make
  user-friendly error reporting.

  See also : "option httpchk", "http-check connect", "http-check send" and
             "http-check expect".

http-check connect [default] [port <expr>] [addr <ip>] [send-proxy]
                   [via-socks4] [ssl] [sni <sni>] [alpn <alpn>] [linger]
           [proto <name>] [comment <msg>]
  Opens a new connection to perform an HTTP health check
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    no    |   yes  |   yes

  Arguments :
    comment <msg>  defines a message to report if the rule evaluation fails.

    default      Use default options of the server line to do the health
                 checks. The server options are used only if not redefined.

    port <expr>  if not set, check port or server port is used.
                 It tells HAProxy where to open the connection to.
                 <port> must be a valid TCP port source integer, from 1 to
                 65535 or an sample-fetch expression.

    addr <ip>    defines the IP address to do the health check.

    send-proxy   send a PROXY protocol string

    via-socks4   enables outgoing health checks using upstream socks4 proxy.

    ssl          opens a ciphered connection

    sni <sni>    specifies the SNI to use to do health checks over SSL.

    alpn <alpn>  defines which protocols to advertise with ALPN. The protocol
                 list consists in a comma-delimited list of protocol names,
                 for instance: "h2,http/1.1". If it is not set, the server ALPN
                 is used.

    proto <name> forces the multiplexer's protocol to use for this connection.
                 It must be an HTTP mux protocol and it must be usable on the
                 backend side. The list of available protocols is reported in
                 haproxy -vv.

    linger       cleanly close the connection instead of using a single RST.

  Just like tcp-check health checks, it is possible to configure the connection
  to use to perform HTTP health check. This directive should also be used to
  describe a scenario involving several request/response exchanges, possibly on
  different ports or with different servers.

  When there are no TCP port configured on the server line neither server port
  directive, then the first step of the http-check sequence must be to specify
  the port with a "http-check connect".

  In an http-check ruleset a 'connect' is required, it is also mandatory to start
  the ruleset with a 'connect' rule. Purpose is to ensure admin know what they
  do.

  When a connect must start the ruleset, if may still be preceded by set-var,
  unset-var or comment rules.

  Examples :
         # check HTTP and HTTPs services on a server.
         # first open port 80 thanks to server line port directive, then
         # tcp-check opens port 443, ciphered and run a request on it:
         option httpchk

         http-check connect
         http-check send meth GET uri / ver HTTP/1.1 hdr host haproxy.1wt.eu
         http-check expect status 200-399
         http-check connect port 443 ssl sni haproxy.1wt.eu
         http-check send meth GET uri / ver HTTP/1.1 hdr host haproxy.1wt.eu
         http-check expect status 200-399

         server www 10.0.0.1 check port 80

  See also : "option httpchk", "http-check send", "http-check expect"

http-check disable-on-404
  Enable a maintenance mode upon HTTP/404 response to health-checks
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    no    |   yes  |   yes
  Arguments : none

  When this option is set, a server which returns an HTTP code 404 will be
  excluded from further load-balancing, but will still receive persistent
  connections. This provides a very convenient method for Web administrators
  to perform a graceful shutdown of their servers. It is also important to note
  that a server which is detected as failed while it was in this mode will not
  generate an alert, just a notice. If the server responds 2xx or 3xx again, it
  will immediately be reinserted into the farm. The status on the stats page
  reports "NOLB" for a server in this mode. It is important to note that this
  option only works in conjunction with the "httpchk" option. If this option
  is used with "http-check expect", then it has precedence over it so that 404
  responses will still be considered as soft-stop. Note also that a stopped
  server will stay stopped even if it replies 404s. This option is only
  evaluated for running servers.

  See also : "option httpchk" and "http-check expect".

http-check expect [min-recv <int>] [comment <msg>]
                  [ok-status <st>] [error-status <st>] [tout-status <st>]
                  [on-success <fmt>] [on-error <fmt>] [status-code <expr>]
                  [!] <match> <pattern>
  Make HTTP health checks consider response contents or specific status codes
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    no    |   yes  |   yes

  Arguments :
    comment <msg>  defines a message to report if the rule evaluation fails.

    min-recv  is optional and can define the minimum amount of data required to
              evaluate the current expect rule. If the number of received bytes
              is under this limit, the check will wait for more data. This
              option can be used to resolve some ambiguous matching rules or to
              avoid executing costly regex matches on content known to be still
              incomplete. If an exact string is used, the minimum between the
              string length and this parameter is used. This parameter is
              ignored if it is set to -1. If the expect rule does not match,
              the check will wait for more data. If set to 0, the evaluation
              result is always conclusive.

    ok-status <st>     is optional and can be used to set the check status if
                       the expect rule is successfully evaluated and if it is
                       the last rule in the tcp-check ruleset. "L7OK", "L7OKC",
                       "L6OK" and "L4OK" are supported :
                         - L7OK  : check passed on layer 7
                         - L7OKC : check conditionally passed on layer 7, set
                                   server to NOLB state.
                         - L6OK  : check passed on layer 6
                         - L4OK  : check passed on layer 4
                       By default "L7OK" is used.

    error-status <st>  is optional and can be used to set the check status if
                       an error occurred during the expect rule evaluation.
                       "L7OKC", "L7RSP", "L7STS", "L6RSP" and "L4CON" are
                       supported :
                         - L7OKC : check conditionally passed on layer 7, set
                                   server to NOLB state.
                         - L7RSP : layer 7 invalid response - protocol error
                         - L7STS : layer 7 response error, for example HTTP 5xx
                         - L6RSP : layer 6 invalid response - protocol error
                         - L4CON : layer 1-4 connection problem
                       By default "L7RSP" is used.

    tout-status <st>   is optional and can be used to set the check status if
                       a timeout occurred during the expect rule evaluation.
                       "L7TOUT", "L6TOUT", and "L4TOUT" are supported :
                         - L7TOUT : layer 7 (HTTP/SMTP) timeout
                         - L6TOUT : layer 6 (SSL) timeout
                         - L4TOUT : layer 1-4 timeout
                       By default "L7TOUT" is used.

    on-success <fmt>   is optional and can be used to customize the
                       informational message reported in logs if the expect
                       rule is successfully evaluated and if it is the last rule
                       in the tcp-check ruleset. <fmt> is a log-format string.

    on-error <fmt>     is optional and can be used to customize the
                       informational message reported in logs if an error
                       occurred during the expect rule evaluation. <fmt> is a
                       log-format string.

    <match>   is a keyword indicating how to look for a specific pattern in the
              response. The keyword may be one of "status", "rstatus", "hdr",
              "fhdr", "string", or "rstring". The keyword may be preceded by an
              exclamation mark ("!") to negate the match. Spaces are allowed
              between the exclamation mark and the keyword. See below for more
              details on the supported keywords.

    <pattern> is the pattern to look for. It may be a string, a regular
              expression or a more complex pattern with several arguments. If
              the string pattern contains spaces, they must be escaped with the
              usual backslash ('\').

  By default, "option httpchk" considers that response statuses 2xx and 3xx
  are valid, and that others are invalid. When "http-check expect" is used,
  it defines what is considered valid or invalid. Only one "http-check"
  statement is supported in a backend. If a server fails to respond or times
  out, the check obviously fails. The available matches are :

    status <codes> :  test the status codes found parsing <codes> string. it
                      must be a comma-separated list of status codes or range
                      codes. A health check response will be considered as
                      valid if the response's status code matches any status
                      code or is inside any range of the list. If the "status"
                      keyword is prefixed with "!", then the response will be
                      considered invalid if the status code matches.

    rstatus <regex> : test a regular expression for the HTTP status code.
                      A health check response will be considered valid if the
                      response's status code matches the expression. If the
                      "rstatus" keyword is prefixed with "!", then the response
                      will be considered invalid if the status code matches.
                      This is mostly used to check for multiple codes.

    hdr  { name | name-lf } [ -m  ] <name>
         [ { value | value-lf } [ -m  ] <value> :
                      test the specified header pattern on the HTTP response
                      headers. The name pattern is mandatory but the value
                      pattern is optional. If not specified, only the header
                      presence is verified.  is the matching method,
                      applied on the header name or the header value. Supported
                      matching methods are "str" (exact match), "beg" (prefix
                      match), "end" (suffix match), "sub" (substring match) or
                      "reg" (regex match). If not specified, exact matching
                      method is used. If the "name-lf" parameter is used,
                      <name> is evaluated as a log-format string. If "value-lf"
                      parameter is used, <value> is evaluated as a log-format
                      string. These parameters cannot be used with the regex
                      matching method. Finally, the header value is considered
                      as comma-separated list. Note that matchings are case
                      insensitive on the header names.

    fhdr { name | name-lf } [ -m  ] <name>
         [ { value | value-lf } [ -m  ] <value> :
                      test the specified full header pattern on the HTTP
                      response headers. It does exactly the same than "hdr"
                      keyword, except the full header value is tested, commas
                      are not considered as delimiters.

    string <string> : test the exact string match in the HTTP response body.
                      A health check response will be considered valid if the
                      response's body contains this exact string. If the
                      "string" keyword is prefixed with "!", then the response
                      will be considered invalid if the body contains this
                      string. This can be used to look for a mandatory word at
                      the end of a dynamic page, or to detect a failure when a
                      specific error appears on the check page (e.g. a stack
                      trace).

    rstring <regex> : test a regular expression on the HTTP response body.
                      A health check response will be considered valid if the
                      response's body matches this expression. If the "rstring"
                      keyword is prefixed with "!", then the response will be
                      considered invalid if the body matches the expression.
                      This can be used to look for a mandatory word at the end
                      of a dynamic page, or to detect a failure when a specific
                      error appears on the check page (e.g. a stack trace).

    string-lf <fmt> : test a log-format string match in the HTTP response body.
                      A health check response will be considered valid if the
                      response's body contains the  string resulting of the
                      evaluation of <fmt>, which follows the log-format rules.
                      If prefixed with "!", then the response will be
                      considered invalid if the body contains the string.

  It is important to note that the responses will be limited to a certain size
  defined by the global "tune.bufsize" option, which defaults to 16384 bytes.
  Thus, too large responses may not contain the mandatory pattern when using
  "string" or "rstring". If a large response is absolutely required, it is
  possible to change the default max size by setting the global variable.
  However, it is worth keeping in mind that parsing very large responses can
  waste some CPU cycles, especially when regular expressions are used, and that
  it is always better to focus the checks on smaller resources.

  In an http-check ruleset, the last expect rule may be implicit. If no expect
  rule is specified after the last "http-check send", an implicit expect rule
  is defined to match on 2xx or 3xx status codes. It means this rule is also
  defined if there is no "http-check" rule at all, when only "option httpchk"
  is set.

  Last, if "http-check expect" is combined with "http-check disable-on-404",
  then this last one has precedence when the server responds with 404.

  Examples :
         # only accept status 200 as valid
         http-check expect status 200,201,300-310

         # be sure a sessid coookie is set
         http-check expect header name "set-cookie" value -m beg "sessid="

         # consider SQL errors as errors
         http-check expect ! string SQL\ Error

         # consider status 5xx only as errors
         http-check expect ! rstatus ^5

         # check that we have a correct hexadecimal tag before /html
         http-check expect rstring 

  See also : "option httpchk", "http-check connect", "http-check disable-on-404"
             and "http-check send".

http-check send [meth <method>] [{ uri <uri> | uri-lf <fmt> }>] [ver <version>]
                [hdr <name> <fmt>]* [{ body <string> | body-lf <fmt> }]
                [comment <msg>]
  Add a possible list of headers and/or a body to the request sent during HTTP
  health checks.
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    no    |   yes  |   yes
  Arguments :
    comment <msg>  defines a message to report if the rule evaluation fails.

    meth <method>  is the optional HTTP method used with the requests. When not
                   set, the "OPTIONS" method is used, as it generally requires
                   low server processing and is easy to filter out from the
                   logs. Any method may be used, though it is not recommended
                   to invent non-standard ones.

    uri <uri>      is optional and set the URI referenced in the HTTP requests
                   to the string <uri>. It defaults to "/" which is accessible
                   by default on almost any server, but may be changed to any
                   other URI. Query strings are permitted.

    uri-lf <fmt>   is optional and set the URI referenced in the HTTP requests
                   using the log-format string <fmt>. It defaults to "/" which
                   is accessible by default on almost any server, but may be
                   changed to any other URI. Query strings are permitted.

    ver <version>  is the optional HTTP version string. It defaults to
                   "HTTP/1.0" but some servers might behave incorrectly in HTTP
                   1.0, so turning it to HTTP/1.1 may sometimes help. Note that
                   the Host field is mandatory in HTTP/1.1, use "hdr" argument
                   to add it.

    hdr <name> <fmt>  adds the HTTP header field whose name is specified in
                      <name> and whose value is defined by <fmt>, which follows
                      to the log-format rules.

    body <string>  add the body defined by <string> to the request sent during
                   HTTP health checks. If defined, the "Content-Length" header
                   is thus automatically added to the request.

    body-lf <fmt>  add the body defined by the log-format string <fmt> to the
                   request sent during HTTP health checks. If defined, the
                   "Content-Length" header is thus automatically added to the
                   request.

  In addition to the request line defined by the "option httpchk" directive,
  this one is the valid way to add some headers and optionally a body to the
  request sent during HTTP health checks. If a body is defined, the associate
  "Content-Length" header is automatically added. Thus, this header or
  "Transfer-encoding" header should not be present in the request provided by
  "http-check send". If so, it will be ignored. The old trick consisting to add
  headers after the version string on the "option httpchk" line is now
  deprecated.

  Also "http-check send" doesn't support HTTP keep-alive. Keep in mind that it
  will automatically append a "Connection: close" header, unless a Connection
  header has already already been configured via a hdr entry.

  Note that the Host header and the request authority, when both defined, are
  automatically synchronized. It means when the HTTP request is sent, when a
  Host is inserted in the request, the request authority is accordingly
  updated. Thus, don't be surprised if the Host header value overwrites the
  configured request authority.

  Note also for now, no Host header is automatically added in HTTP/1.1 or above
  requests. You should add it explicitly.

  See also : "option httpchk", "http-check send-state" and "http-check expect".

http-check send-state
  Enable emission of a state header with HTTP health checks
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    no    |   yes  |   yes
  Arguments : none

  When this option is set, HAProxy will systematically send a special header
  "X-Haproxy-Server-State" with a list of parameters indicating to each server
  how they are seen by HAProxy. This can be used for instance when a server is
  manipulated without access to HAProxy and the operator needs to know whether
  HAProxy still sees it up or not, or if the server is the last one in a farm.

  The header is composed of fields delimited by semi-colons, the first of which
  is a word ("UP", "DOWN", "NOLB"), possibly followed by a number of valid
  checks on the total number before transition, just as appears in the stats
  interface. Next headers are in the form "<variable>=<value>", indicating in
  no specific order some values available in the stats interface :
    - a variable "address", containing the address of the backend server.
      This corresponds to the <address> field in the server declaration. For
      unix domain sockets, it will read "unix".

    - a variable "port", containing the port of the backend server. This
      corresponds to the <port> field in the server declaration. For unix
      domain sockets, it will read "unix".

    - a variable "name", containing the name of the backend followed by a slash
      ("/") then the name of the server. This can be used when a server is
      checked in multiple backends.

    - a variable "node" containing the name of the HAProxy node, as set in the
      global "node" variable, otherwise the system's hostname if unspecified.

    - a variable "weight" indicating the weight of the server, a slash ("/")
      and the total weight of the farm (just counting usable servers). This
      helps to know if other servers are available to handle the load when this
      one fails.

    - a variable "scur" indicating the current number of concurrent connections
      on the server, followed by a slash ("/") then the total number of
      connections on all servers of the same backend.

    - a variable "qcur" indicating the current number of requests in the
      server's queue.

  Example of a header received by the application server :
    >>>  X-Haproxy-Server-State: UP 2/3; name=bck/srv2; node=lb1; weight=1/2; \
           scur=13/22; qcur=0

  See also : "option httpchk", "http-check disable-on-404" and
             "http-check send".

http-check set-var(<var-name>[,<cond> ...]) <expr>
http-check set-var-fmt(<var-name>[,<cond> ...]) <fmt>
  This operation sets the content of a variable. The variable is declared inline.
  May be used in sections:   defaults | frontend | listen | backend
                               yes    |    no    |   yes  |   yes

  Arguments :
    <var-name>  The name of the variable starts with an indication about its
                scope. The scopes allowed for http-check are:
                  "proc" : the variable is shared with the whole process.
                  "sess" : the variable is shared with the tcp-check session.
                  "check": the variable is declared for the lifetime of the tcp-check.
                This prefix is followed by a name. The separator is a '.'.
                The name may only contain characters 'a-z', 'A-Z', '0-9', '.',
                and '-'.

    <cond>      A set of conditions that must all be true for the variable to
                actually be set (such as "ifnotempty", "ifgt" ...). See the
                set-var converter's description for a full list of possible
                conditions.

    <expr>      Is a sample-fetch expression potentially followed by converters.

    <fmt>       This is the value expressed using log-format rules (see Custom
                Log Format in section 8.2.4).

  Examples :
        http-check set-var(check.port) int(1234)
        http-check set-var-fmt(check.port) "name=%H"

http-check unset-var(<var-name>)
  Free a reference to a variable within its scope.
  May be used in sections:   defaults | frontend | listen | backend
                               yes    |    no    |   yes  |   yes

  Arguments :
    <var-name>  The name of the variable starts with an indication about its
                scope. The scopes allowed for http-check are:
                  "proc" : the variable is shared with the whole process.
                  "sess" : the variable is shared with the tcp-check session.
                  "check": the variable is declared for the lifetime of the tcp-check.
                This prefix is followed by a name. The separator is a '.'.
                The name may only contain characters 'a-z', 'A-Z', '0-9', '.',
                and '-'.

  Examples :
        http-check unset-var(check.port)

http-error status <code> [content-type ]
           [ { default-errorfiles | errorfile <file> | errorfiles <name> |
               file <file> | lf-file <file> | string  | lf-string <fmt> } ]
           [ hdr <name> <fmt> ]*
  Defines a custom error message to use instead of errors generated by HAProxy.
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    yes   |   yes  |   yes
  Arguments :
    status <code>        is the HTTP status code. It must be specified.
                         Currently, HAProxy is capable of generating codes
                         200, 400, 401, 403, 404, 405, 407, 408, 410, 413, 425,
                         429, 500, 501, 502, 503, and 504.

    content-type   is the response content type, for instance
                         "text/plain". This parameter is ignored and should be
                         omitted when an errorfile is configured or when the
                         payload is empty. Otherwise, it must be defined.

    default-errorfiles   Reset the previously defined error message for current
                         proxy for the status <code>. If used on a backend, the
                         frontend error message is used, if defined. If used on
                         a frontend, the default error message is used.

    errorfile <file>     designates a file containing the full HTTP response.
                         It is recommended to follow the common practice of
                         appending ".http" to the filename so that people do
                         not confuse the response with HTML error pages, and to
                         use absolute paths, since files are read before any
                         chroot is performed.

    errorfiles <name>    designates the http-errors section to use to import
                         the error message with the status code <code>. If no
                         such message is found, the proxy's error messages are
                         considered.

    file <file>          specifies the file to use as response payload. If the
                         file is not empty, its content-type must be set as
                         argument to "content-type", otherwise, any
                         "content-type" argument is ignored. <file> is
                         considered as a raw string.

    string          specifies the raw string to use as response payload.
                         The content-type must always be set as argument to
                         "content-type".

    lf-file <file>       specifies the file to use as response payload. If the
                         file is not empty, its content-type must be set as
                         argument to "content-type", otherwise, any
                         "content-type" argument is ignored. <file> is
                         evaluated as a log-format string.

    lf-string       specifies the log-format string to use as response
                         payload. The content-type must always be set as
                         argument to "content-type".

    hdr <name> <fmt>     adds to the response the HTTP header field whose name
                         is specified in <name> and whose value is defined by
                         <fmt>, which follows to the log-format rules.
                         This parameter is ignored if an errorfile is used.

  This directive may be used instead of "errorfile", to define a custom error
  message. As "errorfile" directive, it is used for errors detected and
  returned by HAProxy. If an errorfile is defined, it is parsed when HAProxy
  starts and must be valid according to the HTTP standards. The generated
  response must not exceed the configured buffer size (BUFFSIZE), otherwise an
  internal error will be returned.  Finally, if you consider to use some
  http-after-response rules to rewrite these errors, the reserved buffer space
  should be available (see "tune.maxrewrite").

  The files are read at the same time as the configuration and kept in memory.
  For this reason, the errors continue to be returned even when the process is
  chrooted, and no file change is considered while the process is running.

  Note: 400/408/500 errors emitted in early stage of the request parsing are
        handled by the multiplexer at a lower level. No custom formatting is
        supported at this level. Thus only static error messages, defined with
        "errorfile" directive, are supported. However, this limitation only
        exists during the request headers parsing or between two transactions.

  See also : "errorfile", "errorfiles", "errorloc", "errorloc302",
             "errorloc303" and section 3.8 about http-errors.

http-request <action> [options...] [ { if | unless } <condition> ]
  Access control for Layer 7 requests

  May be used in sections:   defaults | frontend | listen | backend
                               yes(!) |    yes   |   yes  |   yes

  The http-request statement defines a set of rules which apply to layer 7
  processing. The rules are evaluated in their declaration order when they are
  met in a frontend, listen or backend section. Any rule may optionally be
  followed by an ACL-based condition, in which case it will only be evaluated
  if the condition is true.

  The first keyword is the rule's action. Several types of actions are
  supported:
    - add-acl(<file-name>) <key fmt>
    - add-header <name> <fmt>
    - allow
    - auth [realm ]
    - cache-use <name>
    - capture <sample> [ len <length> | id <id> ]
    - del-acl(<file-name>) <key fmt>
    - del-header <name> [ -m  ]
    - del-map(<file-name>) <key fmt>
    - deny [ { status | deny_status } <code>]  ...
    - disable-l7-retry
    - do-resolve(<var>,,[ipv4,ipv6]) <expr>
    - early-hint <name> <fmt>
    - normalize-uri 
    - redirect 
    - reject
    - replace-header <name>  <replace-fmt>
    - replace-path  <replace-fmt>
    - replace-pathq  <replace-fmt>
    - replace-uri  <replace-fmt>
    - replace-value <name>  <replace-fmt>
    - return [status <code>] [content-type ] ...
    - sc-inc-gpc(<idx>,<sc-id>)
    - sc-inc-gpc0(<sc-id>)
    - sc-inc-gpc1(<sc-id>)
    - sc-set-gpt(<idx>,<sc-id>) { <int> | <expr> }
    - sc-set-gpt0(<sc-id>) { <int> | <expr> }
    - set-dst <expr>
    - set-dst-port <expr>
    - set-header <name> <fmt>
    - set-log-level <level>
    - set-map(<file-name>) <key fmt> <value fmt>
    - set-mark <mark>
    - set-method <fmt>
    - set-nice <nice>
    - set-path <fmt>
    - set-pathq <fmt>
    - set-priority-class <expr>
    - set-priority-offset <expr>
    - set-query <fmt>
    - set-src <expr>
    - set-src-port <expr>
    - set-timeout { server | tunnel } { <timeout> | <expr> }
    - set-tos <tos>
    - set-uri <fmt>
    - set-var(<var-name>[,<cond> ...]) <expr>
    - set-var-fmt(<var-name>[,<cond> ...]) <fmt>
    - send-spoe-group  <group-name>
    - silent-drop
    - strict-mode { on | off }
    - tarpit [ { status | deny_status } <code>] ...
    - track-sc0 <key> [table <table>]
    - track-sc1 <key> [table <table>]
    - track-sc2 <key> [table <table>]
    - unset-var(<var-name>)
    - use-service 
    - wait-for-body time <time> [ at-least <bytes> ]
    - wait-for-handshake
    - cache-use <name>

  The supported actions are described below.

  There is no limit to the number of http-request statements per instance.

  This directive is only available from named defaults sections, not anonymous
  ones. Rules defined in the defaults section are evaluated before ones in the
  associated proxy section. To avoid ambiguities, in this case the same
  defaults section cannot be used by proxies with the frontend capability and
  by proxies with the backend capability. It means a listen section cannot use
  a defaults section defining such rules.

  Example:
        acl nagios src 192.168.129.3
        acl local_net src 192.168.0.0/16
        acl auth_ok http_auth(L1)

        http-request allow if nagios
        http-request allow if local_net auth_ok
        http-request auth realm Gimme if local_net auth_ok
        http-request deny

  Example:
        acl key req.hdr(X-Add-Acl-Key) -m found
        acl add path /addacl
        acl del path /delacl

        acl myhost hdr(Host) -f myhost.lst

        http-request add-acl(myhost.lst) %[req.hdr(X-Add-Acl-Key)] if key add
        http-request del-acl(myhost.lst) %[req.hdr(X-Add-Acl-Key)] if key del

  Example:
        acl value  req.hdr(X-Value) -m found
        acl setmap path /setmap
        acl delmap path /delmap

        use_backend bk_appli if { hdr(Host),map_str(map.lst) -m found }

        http-request set-map(map.lst) %[src] %[req.hdr(X-Value)] if setmap value
        http-request del-map(map.lst) %[src]                     if delmap

  See also : "stats http-request", section 3.4 about userlists and section 7
             about ACL usage.

http-request add-acl(<file-name>) <key fmt> [ { if | unless } <condition> ]

  This is used to add a new entry into an ACL. The ACL must be loaded from a
  file (even a dummy empty file). The file name of the ACL to be updated is
  passed between parentheses. It takes one argument: <key fmt>, which follows
  log-format rules, to collect content of the new entry. It performs a lookup
  in the ACL before insertion, to avoid duplicated (or more) values. This
  lookup is done by a linear search and can be expensive with large lists!
  It is the equivalent of the "add acl" command from the stats socket, but can
  be triggered by an HTTP request.

http-request add-header <name> <fmt> [ { if | unless } <condition> ]

  This appends an HTTP header field whose name is specified in <name> and
  whose value is defined by <fmt> which follows the log-format rules (see
  Custom Log Format in section 8.2.4). This is particularly useful to pass
  connection-specific information to the server (e.g. the client's SSL
  certificate), or to combine several headers into one. This rule is not
  final, so it is possible to add other similar rules. Note that header
  addition is performed immediately, so one rule might reuse the resulting
  header from a previous rule.

http-request allow [ { if | unless } <condition> ]

  This stops the evaluation of the rules and lets the request pass the check.
  No further "http-request" rules are evaluated for the current section.

http-request auth [realm ] [ { if | unless } <condition> ]

  This stops the evaluation of the rules and immediately responds with an
  HTTP 401 or 407 error code to invite the user to present a valid user name
  and password. No further "http-request" rules are evaluated. An optional
  "realm" parameter is supported, it sets the authentication realm that is
  returned with the response (typically the application's name).

  The corresponding proxy's error message is used. It may be customized using
  an "errorfile" or an "http-error" directive. For 401 responses, all
  occurrences of the WWW-Authenticate header are removed and replaced by a new
  one with a basic authentication challenge for realm "". For 407
  responses, the same is done on the Proxy-Authenticate header. If the error
  message must not be altered, consider to use "http-request return" rule
  instead.

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

http-request cache-use <name> [ { if | unless } <condition> ]

  See section 6.2 about cache setup.

http-request capture <sample> [ len <length> | id <id> ]
                     [ { if | unless } <condition> ]

  This captures sample expression <sample> from the request buffer, and
  converts it to a string of at most  characters. The resulting string is
  stored into the next request "capture" slot, so it will possibly appear next
  to some captured HTTP headers. It will then automatically appear in the logs,
  and it will be possible to extract it using sample fetch rules to feed it
  into headers or anything. The length should be limited given that this size
  will be allocated for each capture during the whole session life.
  Please check section 7.3 (Fetching samples) and "capture request header" for
  more information.

  If the keyword "id" is used instead of "len", the action tries to store the
  captured string in a previously declared capture slot. This is useful to run
  captures in backends. The slot id can be declared by a previous directive
  "http-request capture" or with the "declare capture" keyword.

  When using this action in a backend, double check that the relevant
  frontend(s) have the required capture slots otherwise, this rule will be
  ignored at run time. This can't be detected at configuration parsing time
  due to HAProxy's ability to dynamically resolve backend name at runtime.

http-request del-acl(<file-name>) <key fmt> [ { if | unless } <condition> ]

  This is used to delete an entry from an ACL. The ACL must be loaded from a
  file (even a dummy empty file). The file name of the ACL to be updated is
  passed between parentheses. It takes one argument: <key fmt>, which follows
  log-format rules, to collect content of the entry to delete.
  It is the equivalent of the "del acl" command from the stats socket, but can
  be triggered by an HTTP request.

http-request del-header <name> [ -m  ] [ { if | unless } <condition> ]

  This removes all HTTP header fields whose name is specified in <name>. 
  is the matching method, applied on the header name. Supported matching methods
  are "str" (exact match), "beg" (prefix match), "end" (suffix match), "sub"
  (substring match) and "reg" (regex match). If not specified, exact matching
  method is used.

http-request del-map(<file-name>) <key fmt> [ { if | unless } <condition> ]

  This is used to delete an entry from a MAP. The MAP must be loaded from a
  file (even a dummy empty file). The file name of the MAP to be updated is
  passed between parentheses. It takes one argument: <key fmt>, which follows
  log-format rules, to collect content of the entry to delete.
  It takes one argument: "file name" It is the equivalent of the "del map"
  command from the stats socket, but can be triggered by an HTTP request.

http-request deny [deny_status ] [ { if | unless } <condition> ]
http-request deny [ { status | deny_status } <code>] [content-type ]
          [ { default-errorfiles | errorfile <file> | errorfiles <name> |
              file <file> | lf-file <file> | string  | lf-string <fmt> } ]
          [ hdr <name> <fmt> ]*
          [ { if | unless } <condition> ]

  This stops the evaluation of the rules and immediately rejects the request.
  By default an HTTP 403 error is returned. But the response may be customized
  using same syntax than "http-request return" rules. Thus, see "http-request
  return" for details. For compatibility purpose, when no argument is defined,
  or only "deny_status", the argument "default-errorfiles" is implied. It means
  "http-request deny [deny_status ]" is an alias of
  "http-request deny [status ] default-errorfiles".
  No further "http-request" rules are evaluated.
  See also "http-request return".

http-request disable-l7-retry [ { if | unless } <condition> ]
  This disables any attempt to retry the request if it fails for any other
  reason than a connection failure. This can be useful for example to make
  sure POST requests aren't retried on failure.

http-request do-resolve(<var>,,[ipv4,ipv6]) <expr>
             [ { if | unless } <condition> ]

  This action performs a DNS resolution of the output of <expr> and stores
  the result in the variable <var>. It uses the DNS resolvers section
  pointed by .
  It is possible to choose a resolution preference using the optional
  arguments 'ipv4' or 'ipv6'.
  When performing the DNS resolution, the client side connection is on
  pause waiting till the end of the resolution.
  If an IP address can be found, it is stored into <var>. If any kind of
  error occurs, then <var> is not set.
  One can use this action to discover a server IP address at run time and
  based on information found in the request (IE a Host header).
  If this action is used to find the server's IP address (using the
  "set-dst" action), then the server IP address in the backend must be set
  to 0.0.0.0. The do-resolve action takes an host-only parameter, any port must
  be removed from the string.

  Example:
    resolvers mydns
      nameserver local 127.0.0.53:53
      nameserver google 8.8.8.8:53
      timeout retry   1s
      hold valid 10s
      hold nx 3s
      hold other 3s
      hold obsolete 0s
      accepted_payload_size 8192

    frontend fe
      bind 10.42.0.1:80
      http-request do-resolve(txn.myip,mydns,ipv4) hdr(Host),host_only
      http-request capture var(txn.myip) len 40

      # return 503 when the variable is not set,
      # which mean DNS resolution error
      use_backend b_503 unless { var(txn.myip) -m found }

      default_backend be

    backend b_503
      # dummy backend used to return 503.
      # one can use the errorfile directive to send a nice
      # 503 error page to end users

    backend be
      # rule to prevent HAProxy from reconnecting to services
      # on the local network (forged DNS name used to scan the network)
      http-request deny if { var(txn.myip) -m ip 127.0.0.0/8 10.0.0.0/8 }
      http-request set-dst var(txn.myip)
      server clear 0.0.0.0:0

  NOTE: Don't forget to set the "protection" rules to ensure HAProxy won't
        be used to scan the network or worst won't loop over itself...

http-request early-hint <name> <fmt> [ { if | unless } <condition> ]

  This is used to build an HTTP 103 Early Hints response prior to any other one.
  This appends an HTTP header field to this response whose name is specified in
  <name> and whose value is defined by <fmt> which follows the log-format rules
  (see Custom Log Format in section 8.2.4). This is particularly useful to pass
  to the client some Link headers to preload resources required to render the
  HTML documents.

  See RFC 8297 for more information.

http-request normalize-uri  [ { if | unless } <condition> ]
http-request normalize-uri fragment-encode [ { if | unless } <condition> ]
http-request normalize-uri fragment-strip [ { if | unless } <condition> ]
http-request normalize-uri path-merge-slashes [ { if | unless } <condition> ]
http-request normalize-uri path-strip-dot [ { if | unless } <condition> ]
http-request normalize-uri path-strip-dotdot [ full ] [ { if | unless } <condition> ]
http-request normalize-uri percent-decode-unreserved [ strict ] [ { if | unless } <condition> ]
http-request normalize-uri percent-to-uppercase [ strict ] [ { if | unless } <condition> ]
http-request normalize-uri query-sort-by-name [ { if | unless } <condition> ]

  Performs normalization of the request's URI.

  URI normalization in HAProxy 2.4 is currently available as an experimental
  technical preview. As such, it requires the global directive
  'expose-experimental-directives' first to be able to invoke it. You should be
  prepared that the behavior of normalizers might change to fix possible
  issues, possibly breaking proper request processing in your infrastructure.

  Each normalizer handles a single type of normalization to allow for a
  fine-grained selection of the level of normalization that is appropriate for
  the supported backend.

  As an example the "path-strip-dotdot" normalizer might be useful for a static
  fileserver that directly maps the requested URI to the path within the local
  filesystem. However it might break routing of an API that expects a specific
  number of segments in the path.

  It is important to note that some normalizers might result in unsafe
  transformations for broken URIs. It might also be possible that a combination
  of normalizers that are safe by themselves results in unsafe transformations
  when improperly combined.

  As an example the "percent-decode-unreserved" normalizer might result in
  unexpected results when a broken URI includes bare percent characters. One
  such a broken URI is "/%%36%36" which would be decoded to "/%66" which in
  turn is equivalent to "/f". By specifying the "strict" option requests to
  such a broken URI would safely be rejected.

  The following normalizers are available:

  - fragment-encode: Encodes "#" as "%23".

      The "fragment-strip" normalizer should be preferred, unless it is known
      that broken clients do not correctly encode '#' within the path component.

      Example:
      - /#foo  -> /%23foo

  - fragment-strip: Removes the URI's "fragment" component.

      According to RFC 3986#3.5 the "fragment" component of an URI should not
      be sent, but handled by the User Agent after retrieving a resource.

      This normalizer should be applied first to ensure that the fragment is
      not interpreted as part of the request's path component.

      Example:
      - /#foo  -> /

  - path-strip-dot: Removes "/./" segments within the "path" component
      (RFC 3986#6.2.2.3).

      Segments including percent encoded dots ("%2E") will not be detected. Use
      the "percent-decode-unreserved" normalizer first if this is undesired.

      Example:
      - /.            -> /
      - /./bar/       -> /bar/
      - /a/./a        -> /a/a
      - /.well-known/ -> /.well-known/ (no change)

  - path-strip-dotdot: Normalizes "/../" segments within the "path" component
      (RFC 3986#6.2.2.3).

      This merges segments that attempt to access the parent directory with
      their preceding segment.

      Empty segments do not receive special treatment. Use the "merge-slashes"
      normalizer first if this is undesired.

      Segments including percent encoded dots ("%2E") will not be detected. Use
      the "percent-decode-unreserved" normalizer first if this is undesired.

      Example:
      - /foo/../     -> /
      - /foo/../bar/ -> /bar/
      - /foo/bar/../ -> /foo/
      - /../bar/     -> /../bar/
      - /bar/../../  -> /../
      - /foo//../    -> /foo/
      - /foo/%2E%2E/ -> /foo/%2E%2E/

      If the "full" option is specified then "../" at the beginning will be
      removed as well:

      Example:
      - /../bar/     -> /bar/
      - /bar/../../  -> /

  - path-merge-slashes: Merges adjacent slashes within the "path" component
      into a single slash.

      Example:
      - //        -> /
      - /foo//bar -> /foo/bar

  - percent-decode-unreserved: Decodes unreserved percent encoded characters to
      their representation as a regular character (RFC 3986#6.2.2.2).

      The set of unreserved characters includes all letters, all digits, "-",
      ".", "_", and "~".

      Example:
      - /%61dmin       -> /admin
      - /foo%3Fbar=baz -> /foo%3Fbar=baz (no change)
      - /%%36%36       -> /%66           (unsafe)
      - /%ZZ           -> /%ZZ

      If the "strict" option is specified then invalid sequences will result
      in a HTTP 400 Bad Request being returned.

      Example:
      - /%%36%36 -> HTTP 400
      - /%ZZ     -> HTTP 400

  - percent-to-uppercase: Uppercases letters within percent-encoded sequences
      (RFC 3986#6.2.2.1).

      Example:
      - /%6f -> /%6F
      - /%zz -> /%zz

      If the "strict" option is specified then invalid sequences will result
      in a HTTP 400 Bad Request being returned.

      Example:
      - /%zz -> HTTP 400

  - query-sort-by-name: Sorts the query string parameters by parameter name.
      Parameters are assumed to be delimited by '&'. Shorter names sort before
      longer names and identical parameter names maintain their relative order.

      Example:
      - /?c=3&a=1&b=2         -> /?a=1&b=2&c=3
      - /?aaa=3&a=1&aa=2      -> /?a=1&aa=2&aaa=3
      - /?a=3&b=4&a=1&b=5&a=2 -> /?a=3&a=1&a=2&b=4&b=5

http-request redirect  [ { if | unless } <condition> ]

  This performs an HTTP redirection based on a redirect rule. This is exactly
  the same as the "redirect" statement except that it inserts a redirect rule
  which can be processed in the middle of other "http-request" rules and that
  these rules use the "log-format" strings. See the "redirect" keyword for the
  rule's syntax.

http-request reject [ { if | unless } <condition> ]

  This stops the evaluation of the rules and immediately closes the connection
  without sending any response. It acts similarly to the
  "tcp-request content reject" rules. It can be useful to force an immediate
  connection closure on HTTP/2 connections.

http-request replace-header <name>  <replace-fmt>
                            [ { if | unless } <condition> ]

  This matches the value of all occurrences of header field <name> against
  . Matching is performed case-sensitively. Matching values are
  completely replaced by <replace-fmt>. Format characters are allowed in
  <replace-fmt> and work like <fmt> arguments in "http-request add-header".
  Standard back-references using the backslash ('\') followed by a number are
  supported.

  This action acts on whole header lines, regardless of the number of values
  they may contain. Thus it is well-suited to process headers naturally
  containing commas in their value, such as If-Modified-Since. Headers that
  contain a comma-separated list of values, such as Accept, should be processed
  using "http-request replace-value".

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

    # applied to:
    Cookie: foo=foobar; expires=Tue, 14-Jun-2016 01:40:45 GMT;

    # outputs:
    Cookie: foo=foobar;ip=192.168.1.20; expires=Tue, 14-Jun-2016 01:40:45 GMT;

    # assuming the backend IP is 192.168.1.20

    http-request replace-header User-Agent curl foo

    # applied to:
    User-Agent: curl/7.47.0

    # outputs:
    User-Agent: foo

http-request replace-path  <replace-fmt>
                           [ { if | unless } <condition> ]

  This works like "replace-header" except that it works on the request's path
  component instead of a header. The path component starts at the first '/'
  after an optional scheme+authority and ends before the question mark. Thus,
  the replacement does not modify the scheme, the authority and the
  query-string.

  It is worth noting that regular expressions may be more expensive to evaluate
  than certain ACLs, so rare replacements may benefit from a condition to avoid
  performing the evaluation at all if it does not match.

  Example:
    # prefix /foo : turn /bar?q=1 into /foo/bar?q=1 :
    http-request replace-path (.*) /foo\1

    # strip /foo : turn /foo/bar?q=1 into /bar?q=1
    http-request replace-path /foo/(.*) /\1
    # or more efficient if only some requests match :
    http-request replace-path /foo/(.*) /\1 if { url_beg /foo/ }

http-request replace-pathq  <replace-fmt>
                           [ { if | unless } <condition> ]

  This does the same as "http-request replace-path" except that the path
  contains the query-string if any is present. Thus, the path and the
  query-string are replaced.

  Example:
    # suffix /foo : turn /bar?q=1 into /bar/foo?q=1 :
    http-request replace-pathq ([^?]*)(\?(.*))? \1/foo\2

http-request replace-uri  <replace-fmt>
                           [ { if | unless } <condition> ]

  This works like "replace-header" except that it works on the request's URI part
  instead of a header. The URI part may contain an optional scheme, authority or
  query string. These are considered to be part of the value that is matched
  against.

  It is worth noting that regular expressions may be more expensive to evaluate
  than certain ACLs, so rare replacements may benefit from a condition to avoid
  performing the evaluation at all if it does not match.

  IMPORTANT NOTE: historically in HTTP/1.x, the vast majority of requests sent
  by browsers use the "origin form", which differs from the "absolute form" in
  that they do not contain a scheme nor authority in the URI portion. Mostly
  only requests sent to proxies, those forged by hand and some emitted by
  certain applications use the absolute form. As such, "replace-uri" usually
  works fine most of the time in HTTP/1.x with rules starting with a "/". But
  with HTTP/2, clients are encouraged to send absolute URIs only, which look
  like the ones HTTP/1 clients use to talk to proxies. Such partial replace-uri
  rules may then fail in HTTP/2 when they work in HTTP/1. Either the rules need
  to be adapted to optionally match a scheme and authority, or replace-path
  should be used.

  Example:
    # rewrite all "http" absolute requests to "https":
    http-request replace-uri ^http://(.*) https://\1

    # prefix /foo : turn /bar?q=1 into /foo/bar?q=1 :
    http-request replace-uri ([^/:]*://[^/]*)?(.*) \1/foo\2

http-request replace-value <name>  <replace-fmt>
                           [ { if | unless } <condition> ]

  This works like "replace-header" except that it matches the regex against
  every comma-delimited value of the header field <name> instead of the
  entire header. This is suited for all headers which are allowed to carry
  more than one value. An example could be the Accept header.

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

    # applied to:
    X-Forwarded-For: 192.168.10.1, 192.168.13.24, 10.0.0.37

    # outputs:
    X-Forwarded-For: 172.16.10.1, 172.16.13.24, 10.0.0.37

http-request return [status <code>] [content-type ]
          [ { default-errorfiles | errorfile <file> | errorfiles <name> |
              file <file> | lf-file <file> | string  | lf-string <fmt> } ]
      [ hdr <name> <fmt> ]*
          [ { if | unless } <condition> ]

  This stops the evaluation of the rules and immediately returns a response. The
  default status code used for the response is 200. It can be optionally
  specified as an arguments to "status". The response content-type may also be
  specified as an argument to "content-type". Finally the response itself may
  be defined. It can be a full HTTP response specifying the errorfile to use,
  or the response payload specifying the file or the string to use. These rules
  are followed to create the response :

  * If neither the errorfile nor the payload to use is defined, a dummy
    response is returned. Only the "status" argument is considered. It can be
    any code in the range [200, 599]. The "content-type" argument, if any, is
    ignored.

  * If "default-errorfiles" argument is set, the proxy's errorfiles are
    considered.  If the "status" argument is defined, it must be one of the
    status code handled by HAProxy (200, 400, 403, 404, 405, 408, 410, 413,
    425, 429, 500, 501, 502, 503, and 504). The "content-type" argument, if
    any, is ignored.

  * If a specific errorfile is defined, with an "errorfile" argument, the
    corresponding file, containing a full HTTP response, is returned. Only the
    "status" argument is considered. It must be one of the status code handled
    by HAProxy (200, 400, 403, 404, 405, 408, 410, 413, 425, 429, 500, 501,
    502, 503, and 504). The "content-type" argument, if any, is ignored.

  * If an http-errors section is defined, with an "errorfiles" argument, the
    corresponding file in the specified http-errors section, containing a full
    HTTP response, is returned. Only the "status" argument is considered. It
    must be one of the status code handled by HAProxy (200, 400, 403, 404, 405,
    408, 410, 413, 425, 429, 500, 501, 502, 503, and 504). The "content-type"
    argument, if any, is ignored.

  * If a "file" or a "lf-file" argument is specified, the file's content is
    used as the response payload. If the file is not empty, its content-type
    must be set as argument to "content-type". Otherwise, any "content-type"
    argument is ignored. With a "lf-file" argument, the file's content is
    evaluated as a log-format string. With a "file" argument, it is considered
    as a raw content.

  * If a "string" or "lf-string" argument is specified, the defined string is
    used as the response payload. The content-type must always be set as
    argument to "content-type". With a "lf-string" argument, the string is
    evaluated as a log-format string. With a "string" argument, it is
    considered as a raw string.

  When the response is not based on an errorfile, it is possible to append HTTP
  header fields to the response using "hdr" arguments. Otherwise, all "hdr"
  arguments are ignored. For each one, the header name is specified in <name>
  and its value is defined by <fmt> which follows the log-format rules.

  Note that the generated response must be smaller than a buffer. And to avoid
  any warning, when an errorfile or a raw file is loaded, the buffer space
  reserved for the headers rewriting should also be free.

  No further "http-request" rules are evaluated.

  Example:
    http-request return errorfile /etc/haproxy/errorfiles/200.http \
        if { path /ping }

    http-request return content-type image/x-icon file /var/www/favicon.ico  \
        if { path /favicon.ico }

    http-request return status 403 content-type text/plain    \
        lf-string "Access denied. IP %[src] is blacklisted."  \
        if { src -f /etc/haproxy/blacklist.lst }

http-request sc-inc-gpc(<idx>,<sc-id>) [ { if | unless } <condition> ]

  This actions increments the General Purpose Counter at the index <idx>
  of the array associated to the sticky counter designated by <sc-id>.
  If an error occurs, this action silently fails and the actions evaluation
  continues. <idx> is an integer between 0 and 99 and <sc-id> is an integer
  between 0 and 2. It also silently fails if the there is no GPC stored
  at this index.
  This action applies only to the 'gpc' and 'gpc_rate' array data_types (and
  not to the legacy 'gpc0', 'gpc1', 'gpc0_rate' nor 'gpc1_rate' data_types).

http-request sc-inc-gpc0(<sc-id>) [ { if | unless } <condition> ]
http-request sc-inc-gpc1(<sc-id>) [ { if | unless } <condition> ]

  This actions increments the GPC0 or GPC1 counter according with the sticky
  counter designated by <sc-id>. If an error occurs, this action silently fails
  and the actions evaluation continues.

http-request sc-set-gpt(<idx>,<sc-id>) { <int> | <expr> }
                                           [ { if | unless } <condition> ]
  This action sets the 32-bit unsigned GPT at the index <idx> of the array
  associated to the sticky counter designated by <sc-id> at the value of
  <int>/<expr>. The expected result is a boolean.
  If an error occurs, this action silently fails and the actions evaluation
  continues. <idx> is an integer between 0 and 99 and <sc-id> is an integer
  between 0 and 2. It also silently fails if the there is no GPT stored
  at this index.
  This action applies only to the 'gpt' array data_type (and not to the
  legacy 'gpt0' data-type).

http-request sc-set-gpt0(<sc-id>) { <int> | <expr> }
                                  [ { if | unless } <condition> ]

  This action sets the 32-bit unsigned GPT0 tag according to the sticky counter
  designated by <sc-id> and the value of <int>/<expr>. The expected result is a
  boolean. If an error occurs, this action silently fails and the actions
  evaluation continues.

http-request send-spoe-group  <group-name>
                             [ { if | unless } <condition> ]

  This action is used to trigger sending of a group of SPOE messages. To do so,
  the SPOE engine used to send messages must be defined, as well as the SPOE
  group to send. Of course, the SPOE engine must refer to an existing SPOE
  filter. If not engine name is provided on the SPOE filter line, the SPOE
  agent name must be used.

  Arguments:
      The SPOE engine name.

    <group-name>   The SPOE group name as specified in the engine
                   configuration.

http-request set-dst <expr> [ { if | unless } <condition> ]

  This is used to set the destination IP address to the value of specified
  expression. Useful when a proxy in front of HAProxy rewrites destination IP,
  but provides the correct IP in a HTTP header; or you want to mask the IP for
  privacy. If you want to connect to the new address/port, use '0.0.0.0:0' as a
  server address in the backend.

  Arguments:
    <expr>  Is a standard HAProxy expression formed by a sample-fetch followed
            by some converters.

  Example:
    http-request set-dst hdr(x-dst)
    http-request set-dst dst,ipmask(24)

  When possible, set-dst preserves the original destination port as long as the
  address family allows it, otherwise the destination port is set to 0.

http-request set-dst-port <expr> [ { if | unless } <condition> ]

  This is used to set the destination port address to the value of specified
  expression. If you want to connect to the new address/port, use '0.0.0.0:0'
  as a server address in the backend.

  Arguments:
    <expr>  Is a standard HAProxy expression formed by a sample-fetch
            followed by some converters.

  Example:
    http-request set-dst-port hdr(x-port)
    http-request set-dst-port int(4000)

  When possible, set-dst-port preserves the original destination address as
  long as the address family supports a port, otherwise it forces the
  destination address to IPv4 "0.0.0.0" before rewriting the port.

http-request set-header <name> <fmt> [ { if | unless } <condition> ]

  This does the same as "http-request add-header" except that the header name
  is first removed if it existed. This is useful when passing security
  information to the server, where the header must not be manipulated by
  external users. Note that the new value is computed before the removal so it
  is possible to concatenate a value to an existing header.

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

http-request set-log-level <level> [ { if | unless } <condition> ]

  This is used to change the log level of the current request when a certain
  condition is met. Valid levels are the 8 syslog levels (see the "log"
  keyword) plus the special level "silent" which disables logging for this
  request. This rule is not final so the last matching rule wins. This rule
  can be useful to disable health checks coming from another equipment.

http-request set-map(<file-name>) <key fmt> <value fmt>
                                  [ { if | unless } <condition> ]

  This is used to add a new entry into a MAP. The MAP must be loaded from a
  file (even a dummy empty file). The file name of the MAP to be updated is
  passed between parentheses. It takes 2 arguments: <key fmt>, which follows
  log-format rules, used to collect MAP key, and <value fmt>, which follows
  log-format rules, used to collect content for the new entry.
  It performs a lookup in the MAP before insertion, to avoid duplicated (or
  more) values. This lookup is done by a linear search and can be expensive
  with large lists! It is the equivalent of the "set map" command from the
  stats socket, but can be triggered by an HTTP request.

http-request set-mark <mark> [ { if | unless } <condition> ]

  This is used to set the Netfilter/IPFW MARK on all packets sent to the client
  to the value passed in <mark> on platforms which support it. This value is an
  unsigned 32 bit value which can be matched by netfilter/ipfw and by the
  routing table or monitoring the packets through DTrace. It can be expressed
  both in decimal or hexadecimal format (prefixed by "0x").
  This can be useful to force certain packets to take a different route (for
  example a cheaper network path for bulk downloads). This works on Linux
  kernels 2.6.32 and above and requires admin privileges, as well on FreeBSD
  and OpenBSD.

http-request set-method <fmt> [ { if | unless } <condition> ]

  This rewrites the request method with the result of the evaluation of format
  string <fmt>. There should be very few valid reasons for having to do so as
  this is more likely to break something than to fix it.

http-request set-nice <nice> [ { if | unless } <condition> ]

  This sets the "nice" factor of the current request being processed. It only
  has effect against the other requests being processed at the same time.
  The default value is 0, unless altered by the "nice" setting on the "bind"
  line. The accepted range is -1024..1024. The higher the value, the nicest
  the request will be. Lower values will make the request more important than
  other ones. This can be useful to improve the speed of some requests, or
  lower the priority of non-important requests. Using this setting without
  prior experimentation can cause some major slowdown.

http-request set-path <fmt> [ { if | unless } <condition> ]

    This rewrites the request path with the result of the evaluation of format
    string <fmt>. The query string, if any, is left intact. If a scheme and
    authority is found before the path, they are left intact as well. If the
    request doesn't have a path ("*"), this one is replaced with the format.
    This can be used to prepend a directory component in front of a path for
    example. See also "http-request set-query" and "http-request set-uri".

    Example :
      # prepend the host name before the path
      http-request set-path /%[hdr(host)]%[path]

http-request set-pathq <fmt> [ { if | unless } <condition> ]

  This does the same as "http-request set-path" except that the query-string is
  also rewritten. It may be used to remove the query-string, including the
  question mark (it is not possible using "http-request set-query").

http-request set-priority-class <expr> [ { if | unless } <condition> ]

  This is used to set the queue priority class of the current request.
  The value must be a sample expression which converts to an integer in the
  range -2047..2047. Results outside this range will be truncated.
  The priority class determines the order in which queued requests are
  processed. Lower values have higher priority.

http-request set-priority-offset <expr> [ { if | unless } <condition> ]

  This is used to set the queue priority timestamp offset of the current
  request. The value must be a sample expression which converts to an integer
  in the range -524287..524287. Results outside this range will be truncated.
  When a request is queued, it is ordered first by the priority class, then by
  the current timestamp adjusted by the given offset in milliseconds. Lower
  values have higher priority.
  Note that the resulting timestamp is is only tracked with enough precision
  for 524,287ms (8m44s287ms). If the request is queued long enough to where the
  adjusted timestamp exceeds this value, it will be misidentified as highest
  priority. Thus it is important to set "timeout queue" to a value, where when
  combined with the offset, does not exceed this limit.

http-request set-query <fmt> [ { if | unless } <condition> ]

  This rewrites the request's query string which appears after the first
  question mark ("?") with the result of the evaluation of format string <fmt>.
  The part prior to the question mark is left intact. If the request doesn't
  contain a question mark and the new value is not empty, then one is added at
  the end of the URI, followed by the new value. If a question mark was
  present, it will never be removed even if the value is empty. This can be
  used to add or remove parameters from the query string.

  See also "http-request set-query" and "http-request set-uri".

  Example:
    # replace "%3D" with "=" in the query string
    http-request set-query %[query,regsub(%3D,=,g)]

http-request set-src <expr> [ { if | unless } <condition> ]
  This is used to set the source IP address to the value of specified
  expression. Useful when a proxy in front of HAProxy rewrites source IP, but
  provides the correct IP in a HTTP header; or you want to mask source IP for
  privacy. All subsequent calls to "src" fetch will return this value
  (see example).

  Arguments :
    <expr>  Is a standard HAProxy expression formed by a sample-fetch followed
            by some converters.

  See also "option forwardfor".

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

    # After the masking this will track connections
    # based on the IP address with the last byte zeroed out.
    http-request track-sc0 src

  When possible, set-src preserves the original source port as long as the
  address family allows it, otherwise the source port is set to 0.

http-request set-src-port <expr> [ { if | unless } <condition> ]

  This is used to set the source port address to the value of specified
  expression.

  Arguments:
    <expr>  Is a standard HAProxy expression formed by a sample-fetch followed
            by some converters.

  Example:
    http-request set-src-port hdr(x-port)
    http-request set-src-port int(4000)

  When possible, set-src-port preserves the original source address as long as
  the address family supports a port, otherwise it forces the source address to
  IPv4 "0.0.0.0" before rewriting the port.

http-request set-timeout { server | tunnel } { <timeout> | <expr> }
                                       [ { if | unless } <condition> ]

  This action overrides the specified "server" or "tunnel" timeout for the
  current stream only. The timeout can be specified in millisecond or with any
  other unit if the number is suffixed by the unit as explained at the top of
  this document. It is also possible to write an expression which must returns
  a number interpreted as a timeout in millisecond.

  Note that the server/tunnel timeouts are only relevant on the backend side
  and thus this rule is only available for the proxies with backend
  capabilities. Also the timeout value must be non-null to obtain the expected
  results.

  Example:
    http-request set-timeout tunnel 5s
    http-request set-timeout server req.hdr(host),map_int(host.lst)

http-request set-tos <tos> [ { if | unless } <condition> ]

  This is used to set the TOS or DSCP field value of packets sent to the client
  to the value passed in <tos> on platforms which support this. This value
  represents the whole 8 bits of the IP TOS field, and can be expressed both in
  decimal or hexadecimal format (prefixed by "0x"). Note that only the 6 higher
  bits are used in DSCP or TOS, and the two lower bits are always 0. This can
  be used to adjust some routing behavior on border routers based on some
  information from the request.

  See RFC 2474, 2597, 3260 and 4594 for more information.

http-request set-uri <fmt> [ { if | unless } <condition> ]

  This rewrites the request URI with the result of the evaluation of format
  string <fmt>. The scheme, authority, path and query string are all replaced
  at once. This can be used to rewrite hosts in front of proxies, or to
  perform complex modifications to the URI such as moving parts between the
  path and the query string.
  See also "http-request set-path" and "http-request set-query".

http-request set-var(<var-name>[,<cond> ...]) <expr> [ { if | unless } <condition> ]
http-request set-var-fmt(<var-name>[,<cond> ...]) <fmt> [ { if | unless } <condition> ]

  This is used to set the contents of a variable. The variable is declared
  inline.

  Arguments:
    <var-name>  The name of the variable starts with an indication about its
                scope. The scopes allowed are:
                  "proc" : the variable is shared with the whole process
                  "sess" : the variable is shared with the whole session
                  "txn"  : the variable is shared with the transaction
                           (request and response)
                  "req"  : the variable is shared only during request
                           processing
                  "res"  : the variable is shared only during response
                           processing
                This prefix is followed by a name. The separator is a '.'.
                The name may only contain characters 'a-z', 'A-Z', '0-9'
                and '_'.

    <cond>      A set of conditions that must all be true for the variable to
                actually be set (such as "ifnotempty", "ifgt" ...). See the
                set-var converter's description for a full list of possible
                conditions.

    <expr>      Is a standard HAProxy expression formed by a sample-fetch
                followed by some converters.

    <fmt>       This is the value expressed using log-format rules (see Custom
                Log Format in section 8.2.4).

  Example:
    http-request set-var(req.my_var) req.fhdr(user-agent),lower
    http-request set-var-fmt(txn.from) %[src]:%[src_port]

http-request silent-drop [ { if | unless } <condition> ]

  This stops the evaluation of the rules and makes the client-facing connection
  suddenly disappear using a system-dependent way that tries to prevent the
  client from being notified. The effect it then that the client still sees an
  established connection while there's none on HAProxy. The purpose is to
  achieve a comparable effect to "tarpit" except that it doesn't use any local
  resource at all on the machine running HAProxy. It can resist much higher
  loads than "tarpit", and slow down stronger attackers. It is important to
  understand the impact of using this mechanism. All stateful equipment placed
  between the client and HAProxy (firewalls, proxies, load balancers) will also
  keep the established connection for a long time and may suffer from this
  action.
  On modern Linux systems running with enough privileges, the TCP_REPAIR socket
  option is used to block the emission of a TCP reset. On other systems, the
  socket's TTL is reduced to 1 so that the TCP reset doesn't pass the first
  router, though it's still delivered to local networks. Do not use it unless
  you fully understand how it works.

http-request strict-mode { on | off } [ { if | unless } <condition> ]

  This enables or disables the strict rewriting mode for following rules. It
  does not affect rules declared before it and it is only applicable on rules
  performing a rewrite on the requests. When the strict mode is enabled, any
  rewrite failure triggers an internal error. Otherwise, such errors are
  silently ignored. The purpose of the strict rewriting mode is to make some
  rewrites optional while others must be performed to continue the request
  processing.

  By default, the strict rewriting mode is enabled. Its value is also reset
  when a ruleset evaluation ends. So, for instance, if you change the mode on
  the frontend, the default mode is restored when HAProxy starts the backend
  rules evaluation.

http-request tarpit [deny_status ] [ { if | unless } <condition> ]
http-request tarpit [ { status | deny_status } <code>] [content-type ]
          [ { default-errorfiles | errorfile <file> | errorfiles <name> |
              file <file> | lf-file <file> | string  | lf-string <fmt> } ]
          [ hdr <name> <fmt> ]*
          [ { if | unless } <condition> ]

  This stops the evaluation of the rules and immediately blocks the request
  without responding for a delay specified by "timeout tarpit" or
  "timeout connect" if the former is not set. After that delay, if the client
  is still connected, a response is returned so that the client does not
  suspect it has been tarpitted. Logs will report the flags "PT". The goal of
  the tarpit rule is to slow down robots during an attack when they're limited
  on the number of concurrent requests. It can be very efficient against very
  dumb robots, and will significantly reduce the load on firewalls compared to
  a "deny" rule. But when facing "correctly" developed robots, it can make
  things worse by forcing HAProxy and the front firewall to support insane
  number of concurrent connections. By default an HTTP error 500 is returned.
  But the response may be customized using same syntax than
  "http-request return" rules. Thus, see "http-request return" for details.
  For compatibility purpose, when no argument is defined, or only "deny_status",
  the argument "default-errorfiles" is implied. It means
  "http-request tarpit [deny_status ]" is an alias of
  "http-request tarpit [status ] default-errorfiles".
  No further "http-request" rules are evaluated.
  See also "http-request return" and "http-request silent-drop".

http-request track-sc0 <key> [table <table>] [ { if | unless } <condition> ]
http-request track-sc1 <key> [table <table>] [ { if | unless } <condition> ]
http-request track-sc2 <key> [table <table>] [ { if | unless } <condition> ]

  This enables tracking of sticky counters from current request. These rules do
  not stop evaluation and do not change default action. The number of counters
  that may be simultaneously tracked by the same connection is set in
  MAX_SESS_STKCTR at build time (reported in haproxy -vv) which defaults to 3,
  so the track-sc number is between 0 and (MAX_SESS_STKCTR-1). The first
  "track-sc0" rule executed enables tracking of the counters of the specified
  table as the first set. The first "track-sc1" rule executed enables tracking
  of the counters of the specified table as the second set. The first
  "track-sc2" rule executed enables tracking of the counters of the specified
  table as the third set. It is a recommended practice to use the first set of
  counters for the per-frontend counters and the second set for the per-backend
  ones. But this is just a guideline, all may be used everywhere.

  Arguments :
    <key>   is mandatory, and is a sample expression rule as described in
            section 7.3. It describes what elements of the incoming request or
            connection will be analyzed, extracted, combined, and used to
            select which table entry to update the counters.

    <table> is an optional table to be used instead of the default one, which
            is the stick-table declared in the current proxy. All the counters
            for the matches and updates for the key will then be performed in
            that table until the session ends.

  Once a "track-sc*" rule is executed, the key is looked up in the table and if
  it is not found, an entry is allocated for it. Then a pointer to that entry
  is kept during all the session's life, and this entry's counters are updated
  as often as possible, every time the session's counters are updated, and also
  systematically when the session ends. Counters are only updated for events
  that happen after the tracking has been started. As an exception, connection
  counters and request counters are systematically updated so that they reflect
  useful information.

  If the entry tracks concurrent connection counters, one connection is counted
  for as long as the entry is tracked, and the entry will not expire during
  that time. Tracking counters also provides a performance advantage over just
  checking the keys, because only one table lookup is performed for all ACL
  checks that make use of it.

http-request unset-var(<var-name>) [ { if | unless } <condition> ]

  This is used to unset a variable. See above for details about <var-name>.

  Example:
    http-request unset-var(req.my_var)

http-request use-service  [ { if | unless } <condition> ]

  This directive executes the configured HTTP service to reply to the request
  and stops the evaluation of the rules. An HTTP service may choose to reply by
  sending any valid HTTP response or it may immediately close the connection
  without sending any response. Outside natives services, for instance the
  Prometheus exporter, it is possible to write your own services in Lua. No
  further "http-request" rules are evaluated.

  Arguments :
      is mandatory. It is the service to call

  Example:
    http-request use-service prometheus-exporter if { path /metrics }

http-request wait-for-body time <time> [ at-least <bytes> ]
             [ { if | unless } <condition> ]

  This will delay the processing of the request waiting for the payload for at
  most <time> milliseconds. if "at-least" argument is specified, HAProxy stops
  to wait the payload when the first <bytes> bytes are received. 0 means no
  limit, it is the default value. Regardless the "at-least" argument value,
  HAProxy stops to wait if the whole payload is received or if the request
  buffer is full.  This action may be used as a replacement to "option
  http-buffer-request".

  Arguments :

    <time>    is mandatory. It is the maximum time to wait for the body. It
              follows the HAProxy time format and is expressed in milliseconds.

    <bytes>   is optional. It is the minimum payload size to receive to stop to
              wait. It follows the HAProxy size format and is expressed in
              bytes.

  Example:
    http-request wait-for-body time 1s at-least 1k if METH_POST

  See also : "option http-buffer-request"

http-request wait-for-handshake [ { if | unless } <condition> ]

  This will delay the processing of the request until the SSL handshake
  happened. This is mostly useful to delay processing early data until we're
  sure they are valid.

http-response <action> <options...> [ { if | unless } <condition> ]
  Access control for Layer 7 responses

  May be used in sections:   defaults | frontend | listen | backend
                               yes(!) |    yes   |   yes  |   yes

  The http-response statement defines a set of rules which apply to layer 7
  processing. The rules are evaluated in their declaration order when they are
  met in a frontend, listen or backend section. Any rule may optionally be
  followed by an ACL-based condition, in which case it will only be evaluated
  if the condition is true. Since these rules apply on responses, the backend
  rules are applied first, followed by the frontend's rules.

  The first keyword is the rule's action. Several types of actions are
  supported:
    - add-acl(<file-name>) <key fmt>
    - add-header <name> <fmt>
    - allow
    - cache-store <name>
    - capture <sample> id <id>
    - del-acl(<file-name>) <key fmt>
    - del-header <name> [ -m  ]
    - del-map(<file-name>) <key fmt>
    - deny [ { status | deny_status } <code>] ...
    - redirect 
    - replace-header <name> <regex-match> <replace-fmt>
    - replace-value <name> <regex-match> <replace-fmt>
    - return [status <code>] [content-type ] ...
    - sc-inc-gpc(<idx>,<sc-id>)
    - sc-inc-gpc0(<sc-id>)
    - sc-inc-gpc1(<sc-id>)
    - sc-set-gpt(<idx>,<sc-id>) { <int> | <expr> }
    - sc-set-gpt0(<sc-id>) { <int> | <expr> }
    - send-spoe-group  <group-name>
    - set-header <name> <fmt>
    - set-log-level <level>
    - set-map(<file-name>) <key fmt> <value fmt>
    - set-mark <mark>
    - set-nice <nice>
    - set-status  [reason ]
    - set-tos <tos>
    - set-var(<var-name>[,<cond> ...]) <expr>
    - set-var-fmt(<var-name>[,<cond> ...]) <fmt>
    - silent-drop
    - strict-mode { on | off }
    - track-sc0 <key> [table <table>]
    - track-sc1 <key> [table <table>]
    - track-sc2 <key> [table <table>]
    - unset-var(<var-name>)
    - wait-for-body time <time> [ at-least <bytes> ]

  The supported actions are described below.

  There is no limit to the number of http-response statements per instance.

  This directive is only available from named defaults sections, not anonymous
  ones. Rules defined in the defaults section are evaluated before ones in the
  associated proxy section. To avoid ambiguities, in this case the same
  defaults section cannot be used by proxies with the frontend capability and
  by proxies with the backend capability. It means a listen section cannot use
  a defaults section defining such rules.

  Example:
    acl key_acl res.hdr(X-Acl-Key) -m found

    acl myhost hdr(Host) -f myhost.lst

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

  Example:
    acl value  res.hdr(X-Value) -m found

    use_backend bk_appli if { hdr(Host),map_str(map.lst) -m found }

    http-response set-map(map.lst) %[src] %[res.hdr(X-Value)] if value
    http-response del-map(map.lst) %[src]                     if ! value

  See also : "http-request", section 3.4 about userlists and section 7 about
             ACL usage.

http-response add-acl(<file-name>) <key fmt> [ { if | unless } <condition> ]

  This is used to add a new entry into an ACL. Please refer to "http-request
  add-acl" for a complete description.

http-response add-header <name> <fmt> [ { if | unless } <condition> ]

  This appends an HTTP header field whose name is specified in <name> and whose
  value is defined by <fmt>. Please refer to "http-request add-header" for a
  complete description.

http-response allow [ { if | unless } <condition> ]

  This stops the evaluation of the rules and lets the response pass the check.
  No further "http-response" rules are evaluated for the current section.

http-response cache-store <name> [ { if | unless } <condition> ]

  See section 6.2 about cache setup.

http-response capture <sample> id <id> [ { if | unless } <condition> ]

  This captures sample expression <sample> from the response buffer, and
  converts it to a string. The resulting string is stored into the next request
  "capture" slot, so it will possibly appear next to some captured HTTP
  headers. It will then automatically appear in the logs, and it will be
  possible to extract it using sample fetch rules to feed it into headers or
  anything. Please check section 7.3 (Fetching samples) and
  "capture response header" for more information.

  The keyword "id" is the id of the capture slot which is used for storing the
  string. The capture slot must be defined in an associated frontend.
  This is useful to run captures in backends. The slot id can be declared by a
  previous directive "http-response capture" or with the "declare capture"
  keyword.

  When using this action in a backend, double check that the relevant
  frontend(s) have the required capture slots otherwise, this rule will be
  ignored at run time. This can't be detected at configuration parsing time
  due to HAProxy's ability to dynamically resolve backend name at runtime.

http-response del-acl(<file-name>) <key fmt> [ { if | unless } <condition> ]

  This is used to delete an entry from an ACL. Please refer to "http-request
  del-acl" for a complete description.

http-response del-header <name> [ -m  ] [ { if | unless } <condition> ]

  This removes all HTTP header fields whose name is specified in <name>. Please
  refer to "http-request del-header" for a complete description.

http-response del-map(<file-name>) <key fmt> [ { if | unless } <condition> ]

  This is used to delete an entry from a MAP. Please refer to "http-request
  del-map" for a complete description.

http-response deny [deny_status ] [ { if | unless } <condition> ]
http-response deny [ { status | deny_status } <code>] [content-type ]
          [ { default-errorfiles | errorfile <file> | errorfiles <name> |
              file <file> | lf-file <file> | string  | lf-string <fmt> } ]
          [ hdr <name> <fmt> ]*
          [ { if | unless } <condition> ]

  This stops the evaluation of the rules and immediately rejects the response.
  By default an HTTP 502 error is returned. But the response may be customized
  using same syntax than "http-response return" rules. Thus, see
  "http-response return" for details. For compatibility purpose, when no
  argument is defined, or only "deny_status", the argument "default-errorfiles"
  is implied. It means "http-response deny [deny_status ]" is an alias
  of "http-response deny [status ] default-errorfiles".
  No further "http-response" rules are evaluated.
  See also "http-response return".

http-response redirect  [ { if | unless } <condition> ]

  This performs an HTTP redirection based on a redirect rule.
  This supports a format string similarly to "http-request redirect" rules,
  with the exception that only the "location" type of redirect is possible on
  the response. See the "redirect" keyword for the rule's syntax. When a
  redirect rule is applied during a response, connections to the server are
  closed so that no data can be forwarded from the server to the client.

http-response replace-header <name> <regex-match> <replace-fmt>
                             [ { if | unless } <condition> ]

  This works like "http-request replace-header" except that it works on the
  server's response instead of the client's request.

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

    # applied to:
    Set-Cookie: C=1; expires=Tue, 14-Jun-2016 01:40:45 GMT

    # outputs:
    Set-Cookie: C=1;ip=192.168.1.20; expires=Tue, 14-Jun-2016 01:40:45 GMT

    # assuming the backend IP is 192.168.1.20.

http-response replace-value <name> <regex-match> <replace-fmt>
                            [ { if | unless } <condition> ]

  This works like "http-request replace-value" except that it works on the
  server's response instead of the client's request.

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

    # applied to:
    Cache-Control: max-age=3600, public

    # outputs:
    Cache-Control: max-age=3600, private

http-response return [status <code>] [content-type ]
          [ { default-errorfiles | errorfile <file> | errorfiles <name> |
              file <file> | lf-file <file> | string  | lf-string <fmt> } ]
      [ hdr <name> <value> ]*
          [ { if | unless } <condition> ]

  This stops the evaluation of the rules and immediately returns a
  response. Please refer to "http-request return" for a complete
  description. No further "http-response" rules are evaluated.

http-response sc-inc-gpc(<idx>,<sc-id>) [ { if | unless } <condition> ]
http-response sc-inc-gpc0(<sc-id>) [ { if | unless } <condition> ]
http-response sc-inc-gpc1(<sc-id>) [ { if | unless } <condition> ]

  These actions increment the General Purppose Counters according to the sticky
  counter designated by <sc-id>. Please refer to "http-request sc-inc-gpc",
  "http-request sc-inc-gpc0" and "http-request sc-inc-gpc1" for a complete
  description.

http-response sc-set-gpt(<idx>,<sc-id>) { <int> | <expr> }
                                        [ { if | unless } <condition> ]
http-response sc-set-gpt0(<sc-id>) { <int> | <expr> }
                                   [ { if | unless } <condition> ]
http-response sc-set-gpt0(<sc-id>) { <int> | <expr> }
                                   [ { if | unless } <condition> ]

  These actions set the 32-bit unsigned General Purpose Tags according to the
  sticky counter designated by <sc-id>. Please refer to "http-request
  sc-inc-gpt" and "http-request sc-inc-gpt0" for a complete description.

http-response send-spoe-group  <group-name>
                              [ { if | unless } <condition> ]

  This action is used to trigger sending of a group of SPOE messages. Please
  refer to "http-request send-spoe-group" for a complete description.

http-response set-header <name> <fmt> [ { if | unless } <condition> ]

  This does the same as "http-response add-header" except that the header name
  is first removed if it existed. This is useful when passing security
  information to the server, where the header must not be manipulated by
  external users.

http-response set-log-level <level> [ { if | unless } <condition> ]

  This is used to change the log level of the current response. Please refer to
  "http-request set-log-level" for a complete description.

http-response set-map(<file-name>) <key fmt> <value fmt>

  This is used to add a new entry into a MAP. Please refer to "http-request
  set-map" for a complete description.

http-response set-mark <mark> [ { if | unless } <condition> ]

  This action is used to set the Netfilter/IPFW MARK in all packets sent to the
  client to the value passed in <mark> on platforms which support it. Please
  refer to "http-request set-mark" for a complete description.

http-response set-nice <nice> [ { if | unless } <condition> ]

  This sets the "nice" factor of the current request being processed. Please
  refer to "http-request set-nice" for a complete description.

http-response set-status  [reason ]
                         [ { if | unless } <condition> ]

  This replaces the response status code with  which must be an integer
  between 100 and 999. Optionally, a custom reason text can be provided defined
  by , or the default reason for the specified code will be used as a
  fallback.

  Example:
    # return "431 Request Header Fields Too Large"
    http-response set-status 431
    # return "503 Slow Down", custom reason
    http-response set-status 503 reason "Slow Down".

http-response set-tos <tos> [ { if | unless } <condition> ]

  This is used to set the TOS or DSCP field value of packets sent to the client
  to the value passed in <tos> on platforms which support this. Please refer to
  "http-request set-tos" for a complete description.

http-response set-var(<var-name>[,<cond> ...]) <expr> [ { if | unless } <condition> ]
http-response set-var-fmt(<var-name>[,<cond> ...]) <fmt> [ { if | unless } <condition> ]

  This is used to set the contents of a variable. The variable is declared
  inline. Please refer to "http-request set-var" and "http-request set-var-fmt"
  for a complete description.

http-response silent-drop [ { if | unless } <condition> ]

  This stops the evaluation of the rules and makes the client-facing connection
  suddenly disappear using a system-dependent way that tries to prevent the
  client from being notified. Please refer to "http-request silent-drop" for a
  complete description.

http-response strict-mode { on | off }  [ { if | unless } <condition> ]

  This enables or disables the strict rewriting mode for following
  rules. Please refer to "http-request strict-mode" for a complete description.

http-response track-sc0 <key> [table <table>] [ { if | unless } <condition> ]
http-response track-sc1 <key> [table <table>] [ { if | unless } <condition> ]
http-response track-sc2 <key> [table <table>] [ { if | unless } <condition> ]

  This enables tracking of sticky counters from current connection. Please
  refer to "http-request track-sc0", "http-request track-sc1" and "http-request
  track-sc2" for a complete description.

http-response unset-var(<var-name>) [ { if | unless } <condition> ]

  This is used to unset a variable. See "http-request set-var" for details
  about <var-name>.

http-response wait-for-body time <time> [ at-least <bytes> ]
             [ { if | unless } <condition> ]

  This will delay the processing of the response waiting for the payload for at
  most <time> milliseconds. Please refer to "http-request wait-for-body" for a
  complete description.

http-reuse { never | safe | aggressive | always }
  Declare how idle HTTP connections may be shared between requests

  May be used in sections:   defaults | frontend | listen | backend
                               yes    |    no    |   yes  |   yes

  By default, a connection established between HAProxy and the backend server
  which is considered safe for reuse is moved back to the server's idle
  connections pool so that any other request can make use of it. This is the
  "safe" strategy below.

  The argument indicates the desired connection reuse strategy :

    - "never"  : idle connections are never shared between sessions. This mode
                 may be enforced to cancel a different strategy inherited from
                 a defaults section or for troubleshooting. For example, if an
                 old bogus application considers that multiple requests over
                 the same connection come from the same client and it is not
                 possible to fix the application, it may be desirable to
                 disable connection sharing in a single backend. An example of
                 such an application could be an old HAProxy using cookie
                 insertion in tunnel mode and not checking any request past the
                 first one.

    - "safe"   : this is the default and the recommended strategy. The first
                 request of a session is always sent over its own connection,
                 and only subsequent requests may be dispatched over other
                 existing connections. This ensures that in case the server
                 closes the connection when the request is being sent, the
                 browser can decide to silently retry it. Since it is exactly
                 equivalent to regular keep-alive, there should be no side
                 effects. There is also a special handling for the connections
                 using protocols subject to Head-of-line blocking (backend with
                 h2 or fcgi). In this case, when at least one stream is
                 processed, the used connection is reserved to handle streams
                 of the same session. When no more streams are processed, the
                 connection is released and can be reused.

    - "aggressive" : this mode may be useful in webservices environments where
                 all servers are not necessarily known and where it would be
                 appreciable to deliver most first requests over existing
                 connections. In this case, first requests are only delivered
                 over existing connections that have been reused at least once,
                 proving that the server correctly supports connection reuse.
                 It should only be used when it's sure that the client can
                 retry a failed request once in a while and where the benefit
                 of aggressive connection reuse significantly outweighs the
                 downsides of rare connection failures.

    - "always" : this mode is only recommended when the path to the server is
                 known for never breaking existing connections quickly after
                 releasing them. It allows the first request of a session to be
                 sent to an existing connection. This can provide a significant
                 performance increase over the "safe" strategy when the backend
                 is a cache farm, since such components tend to show a
                 consistent behavior and will benefit from the connection
                 sharing. It is recommended that the "http-keep-alive" timeout
                 remains low in this mode so that no dead connections remain
                 usable. In most cases, this will lead to the same performance
                 gains as "aggressive" but with more risks. It should only be
                 used when it improves the situation over "aggressive".

  When http connection sharing is enabled, a great care is taken to respect the
  connection properties and compatibility. Indeed, some properties are specific
  and it is not possibly to reuse it blindly. Those are the SSL SNI, source
  and destination address and proxy protocol block. A connection is reused only
  if it shares the same set of properties with the request.

  Also note that connections with certain bogus authentication schemes (relying
  on the connection) like NTLM are marked private and never shared.

  A connection pool is involved and configurable with "pool-max-conn".

  Note: connection reuse improves the accuracy of the "server maxconn" setting,
  because almost no new connection will be established while idle connections
  remain available. This is particularly true with the "always" strategy.

  See also : "option http-keep-alive", "server maxconn"

http-send-name-header [<header>]
  Add the server name to a request. Use the header string given by <header>
  May be used in sections:   defaults | frontend | listen | backend
                               yes    |    no    |   yes  |   yes
  Arguments :
    <header>  The header string to use to send the server name

  The "http-send-name-header" statement causes the header field named <header>
  to be set to the name of the target server at the moment the request is about
  to be sent on the wire. Any existing occurrences of this header are removed.
  Upon retries and redispatches, the header field is updated to always reflect
  the server being attempted to connect to. Given that this header is modified
  very late in the connection setup, it may have unexpected effects on already
  modified headers. For example using it with transport-level header such as
  connection, content-length, transfer-encoding and so on will likely result in
  invalid requests being sent to the server. Additionally it has been reported
  that this directive is currently being used as a way to overwrite the Host
  header field in outgoing requests; while this trick has been known to work
  as a side effect of the feature for some time, it is not officially supported
  and might possibly not work anymore in a future version depending on the
  technical difficulties this feature induces. A long-term solution instead
  consists in fixing the application which required this trick so that it binds
  to the correct host name.

  See also : "server"

id <value>
  Set a persistent ID to a proxy.
  May be used in sections :   defaults | frontend | listen | backend
                                  no   |    yes   |   yes  |   yes
  Arguments : none

  Set a persistent ID for the proxy. This ID must be unique and positive.
  An unused ID will automatically be assigned if unset. The first assigned
  value will be 1. This ID is currently only returned in statistics.

ignore-persist { if | unless } <condition>
  Declare a condition to ignore persistence
  May be used in sections:    defaults | frontend | listen | backend
                                  no   |    no    |   yes  |   yes

  By default, when cookie persistence is enabled, every requests containing
  the cookie are unconditionally persistent (assuming the target server is up
  and running).

  The "ignore-persist" statement allows one to declare various ACL-based
  conditions which, when met, will cause a request to ignore persistence.
  This is sometimes useful to load balance requests for static files, which
  often don't require persistence. This can also be used to fully disable
  persistence for a specific User-Agent (for example, some web crawler bots).

  The persistence is ignored when an "if" condition is met, or unless an
  "unless" condition is met.

  Example:
      acl url_static  path_beg         /static /images /img /css
      acl url_static  path_end         .gif .png .jpg .css .js
      ignore-persist  if url_static

  See also : "force-persist", "cookie", and section 7 about ACL usage.

load-server-state-from-file { global | local | none }
  Allow seamless reload of HAProxy
  May be used in sections:    defaults | frontend | listen | backend
                                  yes   |    no   |   yes  |   yes

  This directive points HAProxy to a file where server state from previous
  running process has been saved. That way, when starting up, before handling
  traffic, the new process can apply old states to servers exactly has if no
  reload occurred. The purpose of the "load-server-state-from-file" directive is
  to tell HAProxy which file to use. For now, only 2 arguments to either prevent
  loading state or load states from a file containing all backends and servers.
  The state file can be generated by running the command "show servers state"
  over the stats socket and redirect output.

  The format of the file is versioned and is very specific. To understand it,
  please read the documentation of the "show servers state" command (chapter
  9.3 of Management Guide).

  Arguments:
    global     load the content of the file pointed by the global directive
               named "server-state-file".

    local      load the content of the file pointed by the directive
               "server-state-file-name" if set. If not set, then the backend
               name is used as a file name.

    none       don't load any stat for this backend

  Notes:
    - server's IP address is preserved across reloads by default, but the
      order can be changed thanks to the server's "init-addr" setting. This
      means that an IP address change performed on the CLI at run time will
      be preserved, and that any change to the local resolver (e.g. /etc/hosts)
      will possibly not have any effect if the state file is in use.

    - server's weight is applied from previous running process unless it has
      has changed between previous and new configuration files.

  Example: Minimal configuration

      global
       stats socket /tmp/socket
       server-state-file /tmp/server_state

      defaults
       load-server-state-from-file global

      backend bk
       server s1 127.0.0.1:22 check weight 11
       server s2 127.0.0.1:22 check weight 12

  Then one can run :

    socat /tmp/socket - <<< "show servers state" > /tmp/server_state

  Content of the file /tmp/server_state would be like this:

    1
    # <field names skipped for the doc example>
    1 bk 1 s1 127.0.0.1 2 0 11 11 4 6 3 4 6 0 0
    1 bk 2 s2 127.0.0.1 2 0 12 12 4 6 3 4 6 0 0

  Example: Minimal configuration

    global
     stats socket /tmp/socket
     server-state-base /etc/haproxy/states

    defaults
     load-server-state-from-file local

    backend bk
     server s1 127.0.0.1:22 check weight 11
     server s2 127.0.0.1:22 check weight 12

  Then one can run :

    socat /tmp/socket - <<< "show servers state bk" > /etc/haproxy/states/bk

  Content of the file /etc/haproxy/states/bk would be like this:

    1
    # <field names skipped for the doc example>
    1 bk 1 s1 127.0.0.1 2 0 11 11 4 6 3 4 6 0 0
    1 bk 2 s2 127.0.0.1 2 0 12 12 4 6 3 4 6 0 0

  See also: "server-state-file", "server-state-file-name", and
  "show servers state"

log global
log <address> [len <length>] [format <format>] [sample <ranges>:<sample_size>]
    <facility> [<level> [<minlevel>]]
no log
  Enable per-instance logging of events and traffic.
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    yes   |   yes  |   yes

  Prefix :
    no         should be used when the logger list must be flushed. For example,
               if you don't want to inherit from the default logger list. This
               prefix does not allow arguments.

  Arguments :
    global     should be used when the instance's logging parameters are the
               same as the global ones. This is the most common usage. "global"
               replaces <address>, <facility> and <level> with those of the log
               entries found in the "global" section. Only one "log global"
               statement may be used per instance, and this form takes no other
               parameter.

    <address>  indicates where to send the logs. It takes the same format as
               for the "global" section's logs, and can be one of :

               - An IPv4 address optionally followed by a colon (':') and a UDP
                 port. If no port is specified, 514 is used by default (the
                 standard syslog port).

               - An IPv6 address followed by a colon (':') and optionally a UDP
                 port. If no port is specified, 514 is used by default (the
                 standard syslog port).

               - A filesystem path to a UNIX domain socket, keeping in mind
                 considerations for chroot (be sure the path is accessible
                 inside the chroot) and uid/gid (be sure the path is
                 appropriately writable).

               - A file descriptor number in the form "fd@<number>", which may
                 point to a pipe, terminal, or socket. In this case unbuffered
                 logs are used and one writev() call per log is performed. This
                 is a bit expensive but acceptable for most workloads. Messages
                 sent this way will not be truncated but may be dropped, in
                 which case the DroppedLogs counter will be incremented. The
                 writev() call is atomic even on pipes for messages up to
                 PIPE_BUF size, which POSIX recommends to be at least 512 and
                 which is 4096 bytes on most modern operating systems. Any
                 larger message may be interleaved with messages from other
                 processes.  Exceptionally for debugging purposes the file
                 descriptor may also be directed to a file, but doing so will
                 significantly slow HAProxy down as non-blocking calls will be
                 ignored. Also there will be no way to purge nor rotate this
                 file without restarting the process. Note that the configured
                 syslog format is preserved, so the output is suitable for use
                 with a TCP syslog server. See also the "short" and "raw"
                 formats below.

               - "stdout" / "stderr", which are respectively aliases for "fd@1"
                 and "fd@2", see above.

               - A ring buffer in the form "ring@<name>", which will correspond
                 to an in-memory ring buffer accessible over the CLI using the
                 "show events" command, which will also list existing rings and
                 their sizes. Such buffers are lost on reload or restart but
                 when used as a complement this can help troubleshooting by
                 having the logs instantly available.

               - An explicit stream address prefix such as "tcp@","tcp6@",
                 "tcp4@" or "uxst@" will allocate an implicit ring buffer with
                 a stream forward server targeting the given address.

               You may want to reference some environment variables in the
               address parameter, see section 2.3 about environment variables.

    <length>   is an optional maximum line length. Log lines larger than this
               value will be truncated before being sent. The reason is that
               syslog servers act differently on log line length. All servers
               support the default value of 1024, but some servers simply drop
               larger lines while others do log them. If a server supports long
               lines, it may make sense to set this value here in order to avoid
               truncating long lines. Similarly, if a server drops long lines,
               it is preferable to truncate them before sending them. Accepted
               values are 80 to 65535 inclusive. The default value of 1024 is
               generally fine for all standard usages. Some specific cases of
               long captures or JSON-formatted logs may require larger values.

    <ranges>   A list of comma-separated ranges to identify the logs to sample.
               This is used to balance the load of the logs to send to the log
               server. The limits of the ranges cannot be null. They are numbered
               from 1. The size or period (in number of logs) of the sample must
               be set with <sample_size> parameter.

    <sample_size>
               The size of the sample in number of logs to consider when balancing
               their logging loads. It is used to balance the load of the logs to
               send to the syslog server. This size must be greater or equal to the
               maximum of the high limits of the ranges.
               (see also <ranges> parameter).

    <format> is the log format used when generating syslog messages. It may be
             one of the following :

      local     Analog to rfc3164 syslog message format except that hostname
                field is stripped. This is the default.
                Note: option "log-send-hostname" switches the default to
                rfc3164.

      rfc3164   The RFC3164 syslog message format.
                (https://tools.ietf.org/html/rfc3164)

      rfc5424   The RFC5424 syslog message format.
                (https://tools.ietf.org/html/rfc5424)

      priority  A message containing only a level plus syslog facility between
                angle brackets such as '<63>', followed by the text. The PID,
                date, time, process name and system name are omitted. This is
                designed to be used with a local log server.

      short     A message containing only a level between angle brackets such as
                '<3>', followed by the text. The PID, date, time, process name
                and system name are omitted. This is designed to be used with a
                local log server. This format is compatible with what the
                systemd logger consumes.

      timed     A message containing only a level between angle brackets such as
                '<3>', followed by ISO date and by the text. The PID, process
                name and system name are omitted. This is designed to be
                used with a local log server.

      iso       A message containing only the ISO date, followed by the text.
                The PID, process name and system name are omitted. This is
                designed to be used with a local log server.

      raw       A message containing only the text. The level, PID, date, time,
                process name and system name are omitted. This is designed to
                be used in containers or during development, where the severity
                only depends on the file descriptor used (stdout/stderr).

    <facility> must be one of the 24 standard syslog facilities :

                   kern   user   mail   daemon auth   syslog lpr    news
                   uucp   cron   auth2  ftp    ntp    audit  alert  cron2
                   local0 local1 local2 local3 local4 local5 local6 local7

               Note that the facility is ignored for the "short" and "raw"
               formats, but still required as a positional field. It is
               recommended to use "daemon" in this case to make it clear that
               it's only supposed to be used locally.

    <level>    is optional and can be specified to filter outgoing messages. By
               default, all messages are sent. If a level is specified, only
               messages with a severity at least as important as this level
               will be sent. An optional minimum level can be specified. If it
               is set, logs emitted with a more severe level than this one will
               be capped to this level. This is used to avoid sending "emerg"
               messages on all terminals on some default syslog configurations.
               Eight levels are known :

                 emerg  alert  crit   err    warning notice info  debug

  It is important to keep in mind that it is the frontend which decides what to
  log from a connection, and that in case of content switching, the log entries
  from the backend will be ignored. Connections are logged at level "info".

  However, backend log declaration define how and where servers status changes
  will be logged. Level "notice" will be used to indicate a server going up,
  "warning" will be used for termination signals and definitive service
  termination, and "alert" will be used for when a server goes down.

  Note : According to RFC3164, messages are truncated to 1024 bytes before
         being emitted.

  Example :
    log global
    log stdout format short daemon          # send log to systemd
    log stdout format raw daemon            # send everything to stdout
    log stderr format raw daemon notice     # send important events to stderr
    log 127.0.0.1:514 local0 notice         # only send important events
    log tcp@127.0.0.1:514 local0 notice notice  # same but limit output
                                                # level and send in tcp
    log "${LOCAL_SYSLOG}:514" local0 notice   # send to local server

log-format <string>
  Specifies the log format string to use for traffic logs
  May be used in sections:    defaults | frontend | listen | backend
                                 yes   |    yes   |   yes  |    no

  This directive specifies the log format string that will be used for all logs
  resulting from traffic passing through the frontend using this line. If the
  directive is used in a defaults section, all subsequent frontends will use
  the same log format. Please see section 8.2.4 which covers the log format
  string in depth.
  A specific log-format used only in case of connection error can also be
  defined, see the "error-log-format" option.

  "log-format" directive overrides previous "option tcplog", "log-format",
  "option httplog" and "option httpslog" directives.

log-format-sd <string>
  Specifies the RFC5424 structured-data log format string
  May be used in sections:    defaults | frontend | listen | backend
                                 yes   |    yes   |   yes  |    no

  This directive specifies the RFC5424 structured-data log format string that
  will be used for all logs resulting from traffic passing through the frontend
  using this line. If the directive is used in a defaults section, all
  subsequent frontends will use the same log format. Please see section 8.2.4
  which covers the log format string in depth.

  See https://tools.ietf.org/html/rfc5424#section-6.3 for more information
  about the RFC5424 structured-data part.

  Note : This log format string will be used only for loggers that have set
         log format to "rfc5424".

  Example :
    log-format-sd [exampleSDID@1234\ bytes=\"%B\"\ status=\"%ST\"]

log-tag <string>
  Specifies the log tag to use for all outgoing logs
  May be used in sections:    defaults | frontend | listen | backend
                                 yes   |    yes   |   yes  |   yes

  Sets the tag field in the syslog header to this string. It defaults to the
  log-tag set in the global section, otherwise the program name as launched
  from the command line, which usually is "HAProxy". Sometimes it can be useful
  to differentiate between multiple processes running on the same host, or to
  differentiate customer instances running in the same process. In the backend,
  logs about servers up/down will use this tag. As a hint, it can be convenient
  to set a log-tag related to a hosted customer in a defaults section then put
  all the frontends and backends for that customer, then start another customer
  in a new defaults section. See also the global "log-tag" directive.

max-keep-alive-queue <value>
  Set the maximum server queue size for maintaining keep-alive connections
  May be used in sections:    defaults | frontend | listen | backend
                                 yes   |     no   |   yes  |   yes

  HTTP keep-alive tries to reuse the same server connection whenever possible,
  but sometimes it can be counter-productive, for example if a server has a lot
  of connections while other ones are idle. This is especially true for static
  servers.

  The purpose of this setting is to set a threshold on the number of queued
  connections at which HAProxy stops trying to reuse the same server and prefers
  to find another one. The default value, -1, means there is no limit. A value
  of zero means that keep-alive requests will never be queued. For very close
  servers which can be reached with a low latency and which are not sensible to
  breaking keep-alive, a low value is recommended (e.g. local static server can
  use a value of 10 or less). For remote servers suffering from a high latency,
  higher values might be needed to cover for the latency and/or the cost of
  picking a different server.

  Note that this has no impact on responses which are maintained to the same
  server consecutively to a 401 response. They will still go to the same server
  even if they have to be queued.

  See also : "option http-server-close", "option prefer-last-server", server
             "maxconn" and cookie persistence.

max-session-srv-conns 
  Set the maximum number of outgoing connections we can keep idling for a given
  client session. The default is 5 (it precisely equals MAX_SRV_LIST which is
  defined at build time).

maxconn <conns>
  Fix the maximum number of concurrent connections on a frontend
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    yes   |   yes  |   no
  Arguments :
    <conns>   is the maximum number of concurrent connections the frontend will
              accept to serve. Excess connections will be queued by the system
              in the socket's listen queue and will be served once a connection
              closes.

  If the system supports it, it can be useful on big sites to raise this limit
  very high so that HAProxy manages connection queues, instead of leaving the
  clients with unanswered connection attempts. This value should not exceed the
  global maxconn. Also, keep in mind that a connection contains two buffers
  of tune.bufsize (16kB by default) each, as well as some other data resulting
  in about 33 kB of RAM being consumed per established connection. That means
  that a medium system equipped with 1GB of RAM can withstand around
  20000-25000 concurrent connections if properly tuned.

  Also, when <conns> is set to large values, it is possible that the servers
  are not sized to accept such loads, and for this reason it is generally wise
  to assign them some reasonable connection limits.

  When this value is set to zero, which is the default, the global "maxconn"
  value is used.

  See also : "server", global section's "maxconn", "fullconn"

mode { tcp|http }
  Set the running mode or protocol of the instance
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    yes   |   yes  |   yes
  Arguments :
    tcp       The instance will work in pure TCP mode. A full-duplex connection
              will be established between clients and servers, and no layer 7
              examination will be performed. This is the default mode. It
              should be used for SSL, SSH, SMTP, ...

    http      The instance will work in HTTP mode. The client request will be
              analyzed in depth before connecting to any server. Any request
              which is not RFC-compliant will be rejected. Layer 7 filtering,
              processing and switching will be possible. This is the mode which
              brings HAProxy most of its value.

  When doing content switching, it is mandatory that the frontend and the
  backend are in the same mode (generally HTTP), otherwise the configuration
  will be refused.

  Example :
     defaults http_instances
         mode http

monitor fail { if | unless } <condition>
  Add a condition to report a failure to a monitor HTTP request.
  May be used in sections :   defaults | frontend | listen | backend
                                 no    |    yes   |   yes  |   no
  Arguments :
    if <cond>     the monitor request will fail if the condition is satisfied,
                  and will succeed otherwise. The condition should describe a
                  combined test which must induce a failure if all conditions
                  are met, for instance a low number of servers both in a
                  backend and its backup.

    unless <cond> the monitor request will succeed only if the condition is
                  satisfied, and will fail otherwise. Such a condition may be
                  based on a test on the presence of a minimum number of active
                  servers in a list of backends.

  This statement adds a condition which can force the response to a monitor
  request to report a failure. By default, when an external component queries
  the URI dedicated to monitoring, a 200 response is returned. When one of the
  conditions above is met, HAProxy will return 503 instead of 200. This is
  very useful to report a site failure to an external component which may base
  routing advertisements between multiple sites on the availability reported by
  HAProxy. In this case, one would rely on an ACL involving the "nbsrv"
  criterion. Note that "monitor fail" only works in HTTP mode. Both status
  messages may be tweaked using "errorfile" or "errorloc" if needed.

  Example:
     frontend www
        mode http
        acl site_dead nbsrv(dynamic) lt 2
        acl site_dead nbsrv(static)  lt 2
        monitor-uri   /site_alive
        monitor fail  if site_dead

  See also : "monitor-uri", "errorfile", "errorloc"

monitor-uri <uri>
  Intercept a URI used by external components' monitor requests
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    yes   |   yes  |   no
  Arguments :
    <uri>     is the exact URI which we want to intercept to return HAProxy's
              health status instead of forwarding the request.

  When an HTTP request referencing <uri> will be received on a frontend,
  HAProxy will not forward it nor log it, but instead will return either
  "HTTP/1.0 200 OK" or "HTTP/1.0 503 Service unavailable", depending on failure
  conditions defined with "monitor fail". This is normally enough for any
  front-end HTTP probe to detect that the service is UP and running without
  forwarding the request to a backend server. Note that the HTTP method, the
  version and all headers are ignored, but the request must at least be valid
  at the HTTP level. This keyword may only be used with an HTTP-mode frontend.

  Monitor requests are processed very early, just after the request is parsed
  and even before any "http-request". The only rulesets applied before are the
  tcp-request ones. They cannot be logged either, and it is the intended
  purpose. They are only used to report HAProxy's health to an upper component,
  nothing more. However, it is possible to add any number of conditions using
  "monitor fail" and ACLs so that the result can be adjusted to whatever check
  can be imagined (most often the number of available servers in a backend).

  Note: if <uri> starts by a slash ('/'), the matching is performed against the
        request's path instead of the request's uri. It is a workaround to let
        the HTTP/2 requests match the monitor-uri. Indeed, in HTTP/2, clients
        are encouraged to send absolute URIs only.

  Example :
    # Use /haproxy_test to report HAProxy's status
    frontend www
        mode http
        monitor-uri /haproxy_test

  See also : "monitor fail"

option abortonclose
no option abortonclose
  Enable or disable early dropping of aborted requests pending in queues.
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |     no   |   yes  |   yes
  Arguments : none

  In presence of very high loads, the servers will take some time to respond.
  The per-instance connection queue will inflate, and the response time will
  increase respective to the size of the queue times the average per-session
  response time. When clients will wait for more than a few seconds, they will
  often hit the "STOP" button on their browser, leaving a useless request in
  the queue, and slowing down other users, and the servers as well, because the
  request will eventually be served, then aborted at the first error
  encountered while delivering the response.

  As there is no way to distinguish between a full STOP and a simple output
  close on the client side, HTTP agents should be conservative and consider
  that the client might only have closed its output channel while waiting for
  the response. However, this introduces risks of congestion when lots of users
  do the same, and is completely useless nowadays because probably no client at
  all will close the session while waiting for the response. Some HTTP agents
  support this behavior (Squid, Apache, HAProxy), and others do not (TUX, most
  hardware-based load balancers). So the probability for a closed input channel
  to represent a user hitting the "STOP" button is close to 100%, and the risk
  of being the single component to break rare but valid traffic is extremely
  low, which adds to the temptation to be able to abort a session early while
  still not served and not pollute the servers.

  In HAProxy, the user can choose the desired behavior using the option
  "abortonclose". By default (without the option) the behavior is HTTP
  compliant and aborted requests will be served. But when the option is
  specified, a session with an incoming channel closed will be aborted while
  it is still possible, either pending in the queue for a connection slot, or
  during the connection establishment if the server has not yet acknowledged
  the connection request. This considerably reduces the queue size and the load
  on saturated servers when users are tempted to click on STOP, which in turn
  reduces the response time for other users.

  If this option has been enabled in a "defaults" section, it can be disabled
  in a specific instance by prepending the "no" keyword before it.

  See also : "timeout queue" and server's "maxconn" and "maxqueue" parameters

option accept-invalid-http-request
no option accept-invalid-http-request
  Enable or disable relaxing of HTTP request parsing
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    yes   |   yes  |   no
  Arguments : none

  By default, HAProxy complies with RFC7230 in terms of message parsing. This
  means that invalid characters in header names are not permitted and cause an
  error to be returned to the client. This is the desired behavior as such
  forbidden characters are essentially used to build attacks exploiting server
  weaknesses, and bypass security filtering. Sometimes, a buggy browser or
  server will emit invalid header names for whatever reason (configuration,
  implementation) and the issue will not be immediately fixed. In such a case,
  it is possible to relax HAProxy's header name parser to accept any character
  even if that does not make sense, by specifying this option. Similarly, the
  list of characters allowed to appear in a URI is well defined by RFC3986, and
  chars 0-31, 32 (space), 34 ('"'), 60 ('<'), 62 ('>'), 92 ('\'), 94 ('^'), 96
  ('`'), 123 ('{'), 124 ('|'), 125 ('}'), 127 (delete) and anything above are
  not allowed at all. HAProxy always blocks a number of them (0..32, 127). The
  remaining ones are blocked by default unless this option is enabled. This
  option also relaxes the test on the HTTP version, it allows HTTP/0.9 requests
  to pass through (no version specified), as well as different protocol names
  (e.g. RTSP), and multiple digits for both the major and the minor version.

  This option should never be enabled by default as it hides application bugs
  and open security breaches. It should only be deployed after a problem has
  been confirmed.

  When this option is enabled, erroneous header names will still be accepted in
  requests, but the complete request will be captured in order to permit later
  analysis using the "show errors" request on the UNIX stats socket. Similarly,
  requests containing invalid chars in the URI part will be logged. Doing this
  also helps confirming that the issue has been solved.

  If this option has been enabled in a "defaults" section, it can be disabled
  in a specific instance by prepending the "no" keyword before it.

  See also : "option accept-invalid-http-response" and "show errors" on the
             stats socket.

option accept-invalid-http-response
no option accept-invalid-http-response
  Enable or disable relaxing of HTTP response parsing
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |     no   |   yes  |   yes
  Arguments : none

  By default, HAProxy complies with RFC7230 in terms of message parsing. This
  means that invalid characters in header names are not permitted and cause an
  error to be returned to the client. This is the desired behavior as such
  forbidden characters are essentially used to build attacks exploiting server
  weaknesses, and bypass security filtering. Sometimes, a buggy browser or
  server will emit invalid header names for whatever reason (configuration,
  implementation) and the issue will not be immediately fixed. In such a case,
  it is possible to relax HAProxy's header name parser to accept any character
  even if that does not make sense, by specifying this option. This option also
  relaxes the test on the HTTP version format, it allows multiple digits for
  both the major and the minor version.

  This option should never be enabled by default as it hides application bugs
  and open security breaches. It should only be deployed after a problem has
  been confirmed.

  When this option is enabled, erroneous header names will still be accepted in
  responses, but the complete response will be captured in order to permit
  later analysis using the "show errors" request on the UNIX stats socket.
  Doing this also helps confirming that the issue has been solved.

  If this option has been enabled in a "defaults" section, it can be disabled
  in a specific instance by prepending the "no" keyword before it.

  See also : "option accept-invalid-http-request" and "show errors" on the
             stats socket.

option allbackups
no option allbackups
  Use either all backup servers at a time or only the first one
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |     no   |   yes  |   yes
  Arguments : none

  By default, the first operational backup server gets all traffic when normal
  servers are all down. Sometimes, it may be preferred to use multiple backups
  at once, because one will not be enough. When "option allbackups" is enabled,
  the load balancing will be performed among all backup servers when all normal
  ones are unavailable. The same load balancing algorithm will be used and the
  servers' weights will be respected. Thus, there will not be any priority
  order between the backup servers anymore.

  This option is mostly used with static server farms dedicated to return a
  "sorry" page when an application is completely offline.

  If this option has been enabled in a "defaults" section, it can be disabled
  in a specific instance by prepending the "no" keyword before it.

option checkcache
no option checkcache
  Analyze all server responses and block responses with cacheable cookies
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |     no   |   yes  |   yes
  Arguments : none

  Some high-level frameworks set application cookies everywhere and do not
  always let enough control to the developer to manage how the responses should
  be cached. When a session cookie is returned on a cacheable object, there is a
  high risk of session crossing or stealing between users traversing the same
  caches. In some situations, it is better to block the response than to let
  some sensitive session information go in the wild.

  The option "checkcache" enables deep inspection of all server responses for
  strict compliance with HTTP specification in terms of cacheability. It
  carefully checks "Cache-control", "Pragma" and "Set-cookie" headers in server
  response to check if there's a risk of caching a cookie on a client-side
  proxy. When this option is enabled, the only responses which can be delivered
  to the client are :
    - all those without "Set-Cookie" header;
    - all those with a return code other than 200, 203, 204, 206, 300, 301,
      404, 405, 410, 414, 501, provided that the server has not set a
      "Cache-control: public" header field;
    - all those that result from a request using a method other than GET, HEAD,
      OPTIONS, TRACE, provided that the server has not set a 'Cache-Control:
      public' header field;
    - those with a 'Pragma: no-cache' header
    - those with a 'Cache-control: private' header
    - those with a 'Cache-control: no-store' header
    - those with a 'Cache-control: max-age=0' header
    - those with a 'Cache-control: s-maxage=0' header
    - those with a 'Cache-control: no-cache' header
    - those with a 'Cache-control: no-cache="set-cookie"' header
    - those with a 'Cache-control: no-cache="set-cookie,' header
      (allowing other fields after set-cookie)

  If a response doesn't respect these requirements, then it will be blocked
  just as if it was from an "http-response deny" rule, with an "HTTP 502 bad
  gateway". The session state shows "PH--" meaning that the proxy blocked the
  response during headers processing. Additionally, an alert will be sent in
  the logs so that admins are informed that there's something to be fixed.

  Due to the high impact on the application, the application should be tested
  in depth with the option enabled before going to production. It is also a
  good practice to always activate it during tests, even if it is not used in
  production, as it will report potentially dangerous application behaviors.

  If this option has been enabled in a "defaults" section, it can be disabled
  in a specific instance by prepending the "no" keyword before it.

option clitcpka
no option clitcpka
  Enable or disable the sending of TCP keepalive packets on the client side
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    yes   |   yes  |   no
  Arguments : none

  When there is a firewall or any session-aware component between a client and
  a server, and when the protocol involves very long sessions with long idle
  periods (e.g. remote desktops), there is a risk that one of the intermediate
  components decides to expire a session which has remained idle for too long.

  Enabling socket-level TCP keep-alives makes the system regularly send packets
  to the other end of the connection, leaving it active. The delay between
  keep-alive probes is controlled by the system only and depends both on the
  operating system and its tuning parameters.

  It is important to understand that keep-alive packets are neither emitted nor
  received at the application level. It is only the network stacks which sees
  them. For this reason, even if one side of the proxy already uses keep-alives
  to maintain its connection alive, those keep-alive packets will not be
  forwarded to the other side of the proxy.

  Please note that this has nothing to do with HTTP keep-alive.

  Using option "clitcpka" enables the emission of TCP keep-alive probes on the
  client side of a connection, which should help when session expirations are
  noticed between HAProxy and a client.

  If this option has been enabled in a "defaults" section, it can be disabled
  in a specific instance by prepending the "no" keyword before it.

  See also : "option srvtcpka", "option tcpka"

option contstats
  Enable continuous traffic statistics updates
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    yes   |   yes  |   no
  Arguments : none

  By default, counters used for statistics calculation are incremented
  only when a session finishes. It works quite well when serving small
  objects, but with big ones (for example large images or archives) or
  with A/V streaming, a graph generated from HAProxy counters looks like
  a hedgehog. With this option enabled counters get incremented frequently
  along the session, typically every 5 seconds, which is often enough to
  produce clean graphs. Recounting touches a hotpath directly so it is not
  not enabled by default, as it can cause a lot of wakeups for very large
  session counts and cause a small performance drop.

option disable-h2-upgrade
no option disable-h2-upgrade
  Enable or disable the implicit HTTP/2 upgrade from an HTTP/1.x client
  connection.
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    yes   |   yes  |   no
  Arguments : none

  By default, HAProxy is able to implicitly upgrade an HTTP/1.x client
  connection to an HTTP/2 connection if the first request it receives from a
  given HTTP connection matches the HTTP/2 connection preface (i.e. the string
  "PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n"). This way, it is possible to support
  HTTP/1.x and HTTP/2 clients on a non-SSL connections. This option must be
  used to disable the implicit upgrade. Note this implicit upgrade is only
  supported for HTTP proxies, thus this option too. Note also it is possible to
  force the HTTP/2 on clear connections by specifying "proto h2" on the bind
  line. Finally, this option is applied on all bind lines. To disable implicit
  HTTP/2 upgrades for a specific bind line, it is possible to use "proto h1".

  If this option has been enabled in a "defaults" section, it can be disabled
  in a specific instance by prepending the "no" keyword before it.

option dontlog-normal
no option dontlog-normal
  Enable or disable logging of normal, successful connections
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    yes   |   yes  |   no
  Arguments : none

  There are large sites dealing with several thousand connections per second
  and for which logging is a major pain. Some of them are even forced to turn
  logs off and cannot debug production issues. Setting this option ensures that
  normal connections, those which experience no error, no timeout, no retry nor
  redispatch, will not be logged. This leaves disk space for anomalies. In HTTP
  mode, the response status code is checked and return codes 5xx will still be
  logged.

  It is strongly discouraged to use this option as most of the time, the key to
  complex issues is in the normal logs which will not be logged here. If you
  need to separate logs, see the "log-separate-errors" option instead.

  See also : "log", "dontlognull", "log-separate-errors" and section 8 about
             logging.

option dontlognull
no option dontlognull
  Enable or disable logging of null connections
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    yes   |   yes  |   no
  Arguments : none

  In certain environments, there are components which will regularly connect to
  various systems to ensure that they are still alive. It can be the case from
  another load balancer as well as from monitoring systems. By default, even a
  simple port probe or scan will produce a log. If those connections pollute
  the logs too much, it is possible to enable option "dontlognull" to indicate
  that a connection on which no data has been transferred will not be logged,
  which typically corresponds to those probes. Note that errors will still be
  returned to the client and accounted for in the stats. If this is not what is
  desired, option http-ignore-probes can be used instead.

  It is generally recommended not to use this option in uncontrolled
  environments (e.g. internet), otherwise scans and other malicious activities
  would not be logged.

  If this option has been enabled in a "defaults" section, it can be disabled
  in a specific instance by prepending the "no" keyword before it.

  See also : "log", "http-ignore-probes", "monitor-uri", and
             section 8 about logging.

option forwardfor [ except  ] [ header <name> ] [ if-none ]
  Enable insertion of the X-Forwarded-For header to requests sent to servers
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    yes   |   yes  |   yes
  Arguments :
     is an optional argument used to disable this option for sources
              matching 
    <name>    an optional argument to specify a different "X-Forwarded-For"
              header name.

  Since HAProxy works in reverse-proxy mode, the servers see its IP address as
  their client address. This is sometimes annoying when the client's IP address
  is expected in server logs. To solve this problem, the well-known HTTP header
  "X-Forwarded-For" may be added by HAProxy to all requests sent to the server.
  This header contains a value representing the client's IP address. Since this
  header is always appended at the end of the existing header list, the server
  must be configured to always use the last occurrence of this header only. See
  the server's manual to find how to enable use of this standard header. Note
  that only the last occurrence of the header must be used, since it is really
  possible that the client has already brought one.

  The keyword "header" may be used to supply a different header name to replace
  the default "X-Forwarded-For". This can be useful where you might already
  have a "X-Forwarded-For" header from a different application (e.g. stunnel),
  and you need preserve it. Also if your backend server doesn't use the
  "X-Forwarded-For" header and requires different one (e.g. Zeus Web Servers
  require "X-Cluster-Client-IP").

  Sometimes, a same HAProxy instance may be shared between a direct client
  access and a reverse-proxy access (for instance when an SSL reverse-proxy is
  used to decrypt HTTPS traffic). It is possible to disable the addition of the
  header for a known source address or network by adding the "except" keyword
  followed by the network address. In this case, any source IP matching the
  network will not cause an addition of this header. Most common uses are with
  private networks or 127.0.0.1. IPv4 and IPv6 are both supported.

  Alternatively, the keyword "if-none" states that the header will only be
  added if it is not present. This should only be used in perfectly trusted
  environment, as this might cause a security issue if headers reaching HAProxy
  are under the control of the end-user.

  This option may be specified either in the frontend or in the backend. If at
  least one of them uses it, the header will be added. Note that the backend's
  setting of the header subargument takes precedence over the frontend's if
  both are defined. In the case of the "if-none" argument, if at least one of
  the frontend or the backend does not specify it, it wants the addition to be
  mandatory, so it wins.

  Example :
    # Public HTTP address also used by stunnel on the same machine
    frontend www
        mode http
        option forwardfor except 127.0.0.1  # stunnel already adds the header

    # Those servers want the IP Address in X-Client
    backend www
        mode http
        option forwardfor header X-Client

  See also : "option httpclose", "option http-server-close",
             "option http-keep-alive"

option h1-case-adjust-bogus-client
no option h1-case-adjust-bogus-client
  Enable or disable the case adjustment of HTTP/1 headers sent to bogus clients
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    yes   |   yes  |   no
  Arguments : none

  There is no standard case for header names because, as stated in RFC7230,
  they are case-insensitive. So applications must handle them in a case-
  insensitive manner. But some bogus applications violate the standards and
  erroneously rely on the cases most commonly used by browsers. This problem
  becomes critical with HTTP/2 because all header names must be exchanged in
  lower case, and HAProxy follows the same convention. All header names are
  sent in lower case to clients and servers, regardless of the HTTP version.

  When HAProxy receives an HTTP/1 response, its header names are converted to
  lower case and manipulated and sent this way to the clients. If a client is
  known to violate the HTTP standards and to fail to process a response coming
  from HAProxy, it is possible to transform the lower case header names to a
  different format when the response is formatted and sent to the client, by
  enabling this option and specifying the list of headers to be reformatted
  using the global directives "h1-case-adjust" or "h1-case-adjust-file". This
  must only be a temporary workaround for the time it takes the client to be
  fixed, because clients which require such workarounds might be vulnerable to
  content smuggling attacks and must absolutely be fixed.

  Please note that this option will not affect standards-compliant clients.

  If this option has been enabled in a "defaults" section, it can be disabled
  in a specific instance by prepending the "no" keyword before it.

  See also: "option h1-case-adjust-bogus-server", "h1-case-adjust",
  "h1-case-adjust-file".

option h1-case-adjust-bogus-server
no option h1-case-adjust-bogus-server
  Enable or disable the case adjustment of HTTP/1 headers sent to bogus servers
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    no   |   yes  |   yes
  Arguments : none

  There is no standard case for header names because, as stated in RFC7230,
  they are case-insensitive. So applications must handle them in a case-
  insensitive manner. But some bogus applications violate the standards and
  erroneously rely on the cases most commonly used by browsers. This problem
  becomes critical with HTTP/2 because all header names must be exchanged in
  lower case, and HAProxy follows the same convention. All header names are
  sent in lower case to clients and servers, regardless of the HTTP version.

  When HAProxy receives an HTTP/1 request, its header names are converted to
  lower case and manipulated and sent this way to the servers. If a server is
  known to violate the HTTP standards and to fail to process a request coming
  from HAProxy, it is possible to transform the lower case header names to a
  different format when the request is formatted and sent to the server, by
  enabling this option and specifying the list of headers to be reformatted
  using the global directives "h1-case-adjust" or "h1-case-adjust-file". This
  must only be a temporary workaround for the time it takes the server to be
  fixed, because servers which require such workarounds might be vulnerable to
  content smuggling attacks and must absolutely be fixed.

  Please note that this option will not affect standards-compliant servers.

  If this option has been enabled in a "defaults" section, it can be disabled
  in a specific instance by prepending the "no" keyword before it.

  See also: "option h1-case-adjust-bogus-client", "h1-case-adjust",
  "h1-case-adjust-file".

option http-buffer-request
no option http-buffer-request
  Enable or disable waiting for whole HTTP request body before proceeding
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    yes   |   yes  |   yes
  Arguments : none

  It is sometimes desirable to wait for the body of an HTTP request before
  taking a decision. This is what is being done by "balance url_param" for
  example. The first use case is to buffer requests from slow clients before
  connecting to the server. Another use case consists in taking the routing
  decision based on the request body's contents. This option placed in a
  frontend or backend forces the HTTP processing to wait until either the whole
  body is received or the request buffer is full. It can have undesired side
  effects with some applications abusing HTTP by expecting unbuffered
  transmissions between the frontend and the backend, so this should definitely
  not be used by default.

  See also : "option http-no-delay", "timeout http-request",
             "http-request wait-for-body"

option http-ignore-probes
no option http-ignore-probes
  Enable or disable logging of null connections and request timeouts
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    yes   |   yes  |   no
  Arguments : none

  Recently some browsers started to implement a "pre-connect" feature
  consisting in speculatively connecting to some recently visited web sites
  just in case the user would like to visit them. This results in many
  connections being established to web sites, which end up in 408 Request
  Timeout if the timeout strikes first, or 400 Bad Request when the browser
  decides to close them first. These ones pollute the log and feed the error
  counters. There was already "option dontlognull" but it's insufficient in
  this case. Instead, this option does the following things :
     - prevent any 400/408 message from being sent to the client if nothing
       was received over a connection before it was closed;
     - prevent any log from being emitted in this situation;
     - prevent any error counter from being incremented

  That way the empty connection is silently ignored. Note that it is better
  not to use this unless it is clear that it is needed, because it will hide
  real problems. The most common reason for not receiving a request and seeing
  a 408 is due to an MTU inconsistency between the client and an intermediary
  element such as a VPN, which blocks too large packets. These issues are
  generally seen with POST requests as well as GET with large cookies. The logs
  are often the only way to detect them.

  If this option has been enabled in a "defaults" section, it can be disabled
  in a specific instance by prepending the "no" keyword before it.

  See also : "log", "dontlognull", "errorfile", and section 8 about logging.

option http-keep-alive
no option http-keep-alive
  Enable or disable HTTP keep-alive from client to server
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    yes   |   yes  |   yes
  Arguments : none

  By default HAProxy operates in keep-alive mode with regards to persistent
  connections: for each connection it processes each request and response, and
  leaves the connection idle on both sides between the end of a response and
  the start of a new request. This mode may be changed by several options such
  as "option http-server-close" or "option httpclose". This option allows to
  set back the keep-alive mode, which can be useful when another mode was used
  in a defaults section.

  Setting "option http-keep-alive" enables HTTP keep-alive mode on the client-
  and server- sides. This provides the lowest latency on the client side (slow
  network) and the fastest session reuse on the server side at the expense
  of maintaining idle connections to the servers. In general, it is possible
  with this option to achieve approximately twice the request rate that the
  "http-server-close" option achieves on small objects. There are mainly two
  situations where this option may be useful :

    - when the server is non-HTTP compliant and authenticates the connection
      instead of requests (e.g. NTLM authentication)

    - when the cost of establishing the connection to the server is significant
      compared to the cost of retrieving the associated object from the server.

  This last case can happen when the server is a fast static server of cache.
  In this case, the server will need to be properly tuned to support high enough
  connection counts because connections will last until the client sends another
  request.

  If the client request has to go to another backend or another server due to
  content switching or the load balancing algorithm, the idle connection will
  immediately be closed and a new one re-opened. Option "prefer-last-server" is
  available to try optimize server selection so that if the server currently
  attached to an idle connection is usable, it will be used.

  At the moment, logs will not indicate whether requests came from the same
  session or not. The accept date reported in the logs corresponds to the end
  of the previous request, and the request time corresponds to the time spent
  waiting for a new request. The keep-alive request time is still bound to the
  timeout defined by "timeout http-keep-alive" or "timeout http-request" if
  not set.

  This option disables and replaces any previous "option httpclose" or "option
  http-server-close". When backend and frontend options differ, all of these 4
  options have precedence over "option http-keep-alive".

  See also : "option httpclose",, "option http-server-close",
             "option prefer-last-server", "option http-pretend-keepalive",
             and "1.1. The HTTP transaction model".

option http-no-delay
no option http-no-delay
  Instruct the system to favor low interactive delays over performance in HTTP
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    yes   |   yes  |   yes
  Arguments : none

  In HTTP, each payload is unidirectional and has no notion of interactivity.
  Any agent is expected to queue data somewhat for a reasonably low delay.
  There are some very rare server-to-server applications that abuse the HTTP
  protocol and expect the payload phase to be highly interactive, with many
  interleaved data chunks in both directions within a single request. This is
  absolutely not supported by the HTTP specification and will not work across
  most proxies or servers. When such applications attempt to do this through
  HAProxy, it works but they will experience high delays due to the network
  optimizations which favor performance by instructing the system to wait for
  enough data to be available in order to only send full packets. Typical
  delays are around 200 ms per round trip. Note that this only happens with
  abnormal uses. Normal uses such as CONNECT requests nor WebSockets are not
  affected.

  When "option http-no-delay" is present in either the frontend or the backend
  used by a connection, all such optimizations will be disabled in order to
  make the exchanges as fast as possible. Of course this offers no guarantee on
  the functionality, as it may break at any other place. But if it works via
  HAProxy, it will work as fast as possible. This option should never be used
  by default, and should never be used at all unless such a buggy application
  is discovered. The impact of using this option is an increase of bandwidth
  usage and CPU usage, which may significantly lower performance in high
  latency environments.

  See also : "option http-buffer-request"

option http-pretend-keepalive
no option http-pretend-keepalive
  Define whether HAProxy will announce keepalive to the server or not
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    no   |   yes  |   yes
  Arguments : none

  When running with "option http-server-close" or "option httpclose", HAProxy
  adds a "Connection: close" header to the request forwarded to the server.
  Unfortunately, when some servers see this header, they automatically refrain
  from using the chunked encoding for responses of unknown length, while this
  is totally unrelated. The immediate effect is that this prevents HAProxy from
  maintaining the client connection alive. A second effect is that a client or
  a cache could receive an incomplete response without being aware of it, and
  consider the response complete.

  By setting "option http-pretend-keepalive", HAProxy will make the server
  believe it will keep the connection alive. The server will then not fall back
  to the abnormal undesired above. When HAProxy gets the whole response, it
  will close the connection with the server just as it would do with the
  "option httpclose". That way the client gets a normal response and the
  connection is correctly closed on the server side.

  It is recommended not to enable this option by default, because most servers
  will more efficiently close the connection themselves after the last packet,
  and release its buffers slightly earlier. Also, the added packet on the
  network could slightly reduce the overall peak performance. However it is
  worth noting that when this option is enabled, HAProxy will have slightly
  less work to do. So if HAProxy is the bottleneck on the whole architecture,
  enabling this option might save a few CPU cycles.

  This option may be set in backend and listen sections. Using it in a frontend
  section will be ignored and a warning will be reported during startup. It is
  a backend related option, so there is no real reason to set it on a
  frontend. This option may be combined with "option httpclose", which will
  cause keepalive to be announced to the server and close to be announced to
  the client. This practice is discouraged though.

  If this option has been enabled in a "defaults" section, it can be disabled
  in a specific instance by prepending the "no" keyword before it.

  See also : "option httpclose", "option http-server-close", and
             "option http-keep-alive"

option http-restrict-req-hdr-names { preserve | delete | reject }
  Set HAProxy policy about HTTP request header names containing characters
  outside the "[a-zA-Z0-9-]" charset
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    yes   |   yes  |   yes
  Arguments :
      preserve  disable the filtering. It is the default mode for HTTP proxies
                with no FastCGI application configured.

      delete    remove request headers with a name containing a character
                outside the "[a-zA-Z0-9-]" charset. It is the default mode for
                HTTP backends with a configured FastCGI application.

      reject    reject the request with a 403-Forbidden response if it contains a
                header name with a character outside the "[a-zA-Z0-9-]" charset.

  This option may be used to restrict the request header names to alphanumeric
  and hyphen characters ([A-Za-z0-9-]). This may be mandatory to interoperate
  with non-HTTP compliant servers that fail to handle some characters in header
  names. It may also be mandatory for FastCGI applications because all
  non-alphanumeric characters in header names are replaced by an underscore
  ('_'). Thus, it is easily possible to mix up header names and bypass some
  rules. For instance, "X-Forwarded-For" and "X_Forwarded-For" headers are both
  converted to "HTTP_X_FORWARDED_FOR" in FastCGI.

  Note this option is evaluated per proxy and after the http-request rules
  evaluation.

option http-server-close
no option http-server-close
  Enable or disable HTTP connection closing on the server side
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    yes   |   yes  |   yes
  Arguments : none

  By default HAProxy operates in keep-alive mode with regards to persistent
  connections: for each connection it processes each request and response, and
  leaves the connection idle on both sides between the end of a response and
  the start of a new request. This mode may be changed by several options such
  as "option http-server-close" or "option httpclose". Setting "option
  http-server-close" enables HTTP connection-close mode on the server side
  while keeping the ability to support HTTP keep-alive and pipelining on the
  client side. This provides the lowest latency on the client side (slow
  network) and the fastest session reuse on the server side to save server
  resources, similarly to "option httpclose".  It also permits non-keepalive
  capable servers to be served in keep-alive mode to the clients if they
  conform to the requirements of RFC7230. Please note that some servers do not
  always conform to those requirements when they see "Connection: close" in the
  request. The effect will be that keep-alive will never be used. A workaround
  consists in enabling "option http-pretend-keepalive".

  At the moment, logs will not indicate whether requests came from the same
  session or not. The accept date reported in the logs corresponds to the end
  of the previous request, and the request time corresponds to the time spent
  waiting for a new request. The keep-alive request time is still bound to the
  timeout defined by "timeout http-keep-alive" or "timeout http-request" if
  not set.

  This option may be set both in a frontend and in a backend. It is enabled if
  at least one of the frontend or backend holding a connection has it enabled.
  It disables and replaces any previous "option httpclose" or "option
  http-keep-alive". Please check section 4 ("Proxies") to see how this option
  combines with others when frontend and backend options differ.

  If this option has been enabled in a "defaults" section, it can be disabled
  in a specific instance by prepending the "no" keyword before it.

  See also : "option httpclose", "option http-pretend-keepalive",
             "option http-keep-alive", and "1.1. The HTTP transaction model".

option http-use-proxy-header
no option http-use-proxy-header
  Make use of non-standard Proxy-Connection header instead of Connection
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    yes   |   yes  |   no
  Arguments : none

  While RFC7230 explicitly states that HTTP/1.1 agents must use the
  Connection header to indicate their wish of persistent or non-persistent
  connections, both browsers and proxies ignore this header for proxied
  connections and make use of the undocumented, non-standard Proxy-Connection
  header instead. The issue begins when trying to put a load balancer between
  browsers and such proxies, because there will be a difference between what
  HAProxy understands and what the client and the proxy agree on.

  By setting this option in a frontend, HAProxy can automatically switch to use
  that non-standard header if it sees proxied requests. A proxied request is
  defined here as one where the URI begins with neither a '/' nor a '*'. This
  is incompatible with the HTTP tunnel mode. Note that this option can only be
  specified in a frontend and will affect the request along its whole life.

  Also, when this option is set, a request which requires authentication will
  automatically switch to use proxy authentication headers if it is itself a
  proxied request. That makes it possible to check or enforce authentication in
  front of an existing proxy.

  This option should normally never be used, except in front of a proxy.

  See also : "option httpclose", and "option http-server-close".

option httpchk
option httpchk <uri>
option httpchk <method> <uri>
option httpchk <method> <uri> <version>
  Enables HTTP protocol to check on the servers health
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    no    |   yes  |   yes
  Arguments :
    <method>  is the optional HTTP method used with the requests. When not set,
              the "OPTIONS" method is used, as it generally requires low server
              processing and is easy to filter out from the logs. Any method
              may be used, though it is not recommended to invent non-standard
              ones.

    <uri>     is the URI referenced in the HTTP requests. It defaults to " / "
              which is accessible by default on almost any server, but may be
              changed to any other URI. Query strings are permitted.

    <version> is the optional HTTP version string. It defaults to "HTTP/1.0"
              but some servers might behave incorrectly in HTTP 1.0, so turning
              it to HTTP/1.1 may sometimes help. Note that the Host field is
              mandatory in HTTP/1.1, use "http-check send" directive to add it.

  By default, server health checks only consist in trying to establish a TCP
  connection. When "option httpchk" is specified, a complete HTTP request is
  sent once the TCP connection is established, and responses 2xx and 3xx are
  considered valid, while all other ones indicate a server failure, including
  the lack of any response.

  Combined with "http-check" directives, it is possible to customize the
  request sent during the HTTP health checks or the matching rules on the
  response. It is also possible to configure a send/expect sequence, just like
  with the directive "tcp-check" for TCP health checks.

  The server configuration is used by default to open connections to perform
  HTTP health checks. By it is also possible to overwrite server parameters
  using "http-check connect" rules.

  "httpchk" option does not necessarily require an HTTP backend, it also works
  with plain TCP backends. This is particularly useful to check simple scripts
  bound to some dedicated ports using the inetd daemon. However, it will always
  internally relies on an HTX multiplexer. Thus, it means the request
  formatting and the response parsing will be strict.

  Note : For a while, there was no way to add headers or body in the request
         used for HTTP health checks. So a workaround was to hide it at the end
         of the version string with a "\r\n" after the version. It is now
     deprecated. The directive "http-check send" must be used instead.

  Examples :
        # Relay HTTPS traffic to Apache instance and check service availability
        # using HTTP request "OPTIONS * HTTP/1.1" on port 80.
        backend https_relay
            mode tcp
            option httpchk OPTIONS * HTTP/1.1
            http-check send hdr Host www
            server apache1 192.168.1.1:443 check port 80

  See also : "option ssl-hello-chk", "option smtpchk", "option mysql-check",
             "option pgsql-check", "http-check" and the "check", "port" and
             "inter" server options.

option httpclose
no option httpclose
  Enable or disable HTTP connection closing
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    yes   |   yes  |   yes
  Arguments : none

  By default HAProxy operates in keep-alive mode with regards to persistent
  connections: for each connection it processes each request and response, and
  leaves the connection idle on both sides between the end of a response and
  the start of a new request. This mode may be changed by several options such
  as "option http-server-close" or "option httpclose".

  If "option httpclose" is set, HAProxy will close connections with the server
  and the client as soon as the request and the response are received. It will
  also check if a "Connection: close" header is already set in each direction,
  and will add one if missing. Any "Connection" header different from "close"
  will also be removed.

  This option may also be combined with "option http-pretend-keepalive", which
  will disable sending of the "Connection: close" header, but will still cause
  the connection to be closed once the whole response is received.

  This option may be set both in a frontend and in a backend. It is enabled if
  at least one of the frontend or backend holding a connection has it enabled.
  It disables and replaces any previous "option http-server-close" or "option
  http-keep-alive". Please check section 4 ("Proxies") to see how this option
  combines with others when frontend and backend options differ.

  If this option has been enabled in a "defaults" section, it can be disabled
  in a specific instance by prepending the "no" keyword before it.

  See also : "option http-server-close" and "1.1. The HTTP transaction model".

option httplog [ clf ]
  Enable logging of HTTP request, session state and timers
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    yes   |   yes  |   no
  Arguments :
    clf       if the "clf" argument is added, then the output format will be
              the CLF format instead of HAProxy's default HTTP format. You can
              use this when you need to feed HAProxy's logs through a specific
              log analyzer which only support the CLF format and which is not
              extensible.

  By default, the log output format is very poor, as it only contains the
  source and destination addresses, and the instance name. By specifying
  "option httplog", each log line turns into a much richer format including,
  but not limited to, the HTTP request, the connection timers, the session
  status, the connections numbers, the captured headers and cookies, the
  frontend, backend and server name, and of course the source address and
  ports.

  Specifying only "option httplog" will automatically clear the 'clf' mode
  if it was set by default.

  "option httplog" overrides any previous "log-format" directive.

  See also :  section 8 about logging.

option httpslog
  Enable logging of HTTPS request, session state and timers
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    yes   |   yes  |   no

  By default, the log output format is very poor, as it only contains the
  source and destination addresses, and the instance name. By specifying
  "option httpslog", each log line turns into a much richer format including,
  but not limited to, the HTTP request, the connection timers, the session
  status, the connections numbers, the captured headers and cookies, the
  frontend, backend and server name, the SSL certificate verification and SSL
  handshake statuses, and of course the source address and ports.

  "option httpslog" overrides any previous "log-format" directive.

  See also :  section 8 about logging.

option independent-streams
no option independent-streams
  Enable or disable independent timeout processing for both directions
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    yes   |   yes  |  yes
  Arguments : none

  By default, when data is sent over a socket, both the write timeout and the
  read timeout for that socket are refreshed, because we consider that there is
  activity on that socket, and we have no other means of guessing if we should
  receive data or not.

  While this default behavior is desirable for almost all applications, there
  exists a situation where it is desirable to disable it, and only refresh the
  read timeout if there are incoming data. This happens on sessions with large
  timeouts and low amounts of exchanged data such as telnet session. If the
  server suddenly disappears, the output data accumulates in the system's
  socket buffers, both timeouts are correctly refreshed, and there is no way
  to know the server does not receive them, so we don't timeout. However, when
  the underlying protocol always echoes sent data, it would be enough by itself
  to detect the issue using the read timeout. Note that this problem does not
  happen with more verbose protocols because data won't accumulate long in the
  socket buffers.

  When this option is set on the frontend, it will disable read timeout updates
  on data sent to the client. There probably is little use of this case. When
  the option is set on the backend, it will disable read timeout updates on
  data sent to the server. Doing so will typically break large HTTP posts from
  slow lines, so use it with caution.

  See also : "timeout client", "timeout server" and "timeout tunnel"

option ldap-check
  Use LDAPv3 health checks for server testing
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    no    |   yes  |   yes
  Arguments : none

  It is possible to test that the server correctly talks LDAPv3 instead of just
  testing that it accepts the TCP connection. When this option is set, an
  LDAPv3 anonymous simple bind message is sent to the server, and the response
  is analyzed to find an LDAPv3 bind response message.

  The server is considered valid only when the LDAP response contains success
  resultCode (http://tools.ietf.org/html/rfc4511#section-4.1.9).

  Logging of bind requests is server dependent see your documentation how to
  configure it.

  Example :
        option ldap-check

  See also : "option httpchk"

option external-check
  Use external processes for server health checks
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    no    |   yes  |   yes

  It is possible to test the health of a server using an external command.
  This is achieved by running the executable set using "external-check
  command".

  Requires the "external-check" global to be set.

  See also : "external-check", "external-check command", "external-check path"

option idle-close-on-response
no option idle-close-on-response
  Avoid closing idle frontend connections if a soft stop is in progress
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    yes   |   yes  |   no
  Arguments : none

  By default, idle connections will be closed during a soft stop. In some
  environments, a client talking to the proxy may have prepared some idle
  connections in order to send requests later. If there is no proper retry on
  write errors, this can result in errors while haproxy is reloading. Even
  though a proper implementation should retry on connection/write errors, this
  option was introduced to support backwards compatibility with haproxy prior
  to version 2.4. Indeed before v2.4, haproxy used to wait for a last request
  and response to add a "connection: close" header before closing, thus
  notifying the client that the connection would not be reusable.

  In a real life example, this behavior was seen in AWS using the ALB in front
  of a haproxy. The end result was ALB sending 502 during haproxy reloads.

  Users are warned that using this option may increase the number of old
  processes if connections remain idle for too long. Adjusting the client
  timeouts and/or the "hard-stop-after" parameter accordingly might be
  needed in case of frequent reloads.

  See also: "timeout client", "timeout client-fin", "timeout http-request",
            "hard-stop-after"

option log-health-checks
no option log-health-checks
  Enable or disable logging of health checks status updates
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    no    |   yes  |  yes
  Arguments : none

  By default, failed health check are logged if server is UP and successful
  health checks are logged if server is DOWN, so the amount of additional
  information is limited.

  When this option is enabled, any change of the health check status or to
  the server's health will be logged, so that it becomes possible to know
  that a server was failing occasional checks before crashing, or exactly when
  it failed to respond a valid HTTP status, then when the port started to
  reject connections, then when the server stopped responding at all.

  Note that status changes not caused by health checks (e.g. enable/disable on
  the CLI) are intentionally not logged by this option.

  See also: "option httpchk", "option ldap-check", "option mysql-check",
            "option pgsql-check", "option redis-check", "option smtpchk",
            "option tcp-check", "log" and section 8 about logging.

option log-separate-errors
no option log-separate-errors
  Change log level for non-completely successful connections
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    yes   |   yes  |   no
  Arguments : none

  Sometimes looking for errors in logs is not easy. This option makes HAProxy
  raise the level of logs containing potentially interesting information such
  as errors, timeouts, retries, redispatches, or HTTP status codes 5xx. The
  level changes from "info" to "err". This makes it possible to log them
  separately to a different file with most syslog daemons. Be careful not to
  remove them from the original file, otherwise you would lose ordering which
  provides very important information.

  Using this option, large sites dealing with several thousand connections per
  second may log normal traffic to a rotating buffer and only archive smaller
  error logs.

  See also : "log", "dontlognull", "dontlog-normal" and section 8 about
             logging.

option logasap
no option logasap
  Enable or disable early logging.
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    yes   |   yes  |   no
  Arguments : none

  By default, logs are emitted when all the log format variables and sample
  fetches used in the definition of the log-format string return a value, or
  when the session is terminated. This allows the built in log-format strings
  to account for the transfer time, or the number of bytes in log messages.

  When handling long lived connections such as large file transfers or RDP,
  it may take a while for the request or connection to appear in the logs.
  Using "option logasap", the log message is created as soon as the server
  connection is established in mode tcp, or as soon as the server sends the
  complete headers in mode http. Missing information in the logs will be the
  total number of bytes which will only indicate the amount of data transferred
  before the message was created and the total time which will not take the
  remainder of the connection life or transfer time into account. For the case
  of HTTP, it is good practice to capture the Content-Length response header
  so that the logs at least indicate how many bytes are expected to be
  transferred.

  Examples :
      listen http_proxy 0.0.0.0:80
          mode http
          option httplog
          option logasap
          log 192.168.2.200 local3

    >>> Feb  6 12:14:14 localhost \
          haproxy[14389]: 10.0.1.2:33317 [06/Feb/2009:12:14:14.655] http-in \
          static/srv1 9/10/7/14/+30 200 +243 - - ---- 3/1/1/1/0 1/0 \
          "GET /image.iso HTTP/1.0"

  See also : "option httplog", "capture response header", and section 8 about
             logging.

option mysql-check [ user <username> [ { post-41 | pre-41 } ] ]
  Use MySQL health checks for server testing
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    no    |   yes  |   yes
  Arguments :
    <username> This is the username which will be used when connecting to MySQL
               server.
    post-41    Send post v4.1 client compatible checks (the default)
    pre-41     Send pre v4.1 client compatible checks

  If you specify a username, the check consists of sending two MySQL packet,
  one Client Authentication packet, and one QUIT packet, to correctly close
  MySQL session. We then parse the MySQL Handshake Initialization packet and/or
  Error packet. It is a basic but useful test which does not produce error nor
  aborted connect on the server. However, it requires an unlocked authorised
  user without a password. To create a basic limited user in MySQL with
  optional resource limits:

      CREATE USER '<username>'@'<ip_of_haproxy|network_of_haproxy/netmask>'
      /*!50701 WITH MAX_QUERIES_PER_HOUR 1 MAX_UPDATES_PER_HOUR 0 */
      /*M!100201 MAX_STATEMENT_TIME 0.0001 */;

  If you don't specify a username (it is deprecated and not recommended), the
  check only consists in parsing the Mysql Handshake Initialization packet or
  Error packet, we don't send anything in this mode. It was reported that it
  can generate lockout if check is too frequent and/or if there is not enough
  traffic. In fact, you need in this case to check MySQL "max_connect_errors"
  value as if a connection is established successfully within fewer than MySQL
  "max_connect_errors" attempts after a previous connection was interrupted,
  the error count for the host is cleared to zero. If HAProxy's server get
  blocked, the "FLUSH HOSTS" statement is the only way to unblock it.

  Remember that this does not check database presence nor database consistency.
  To do this, you can use an external check with xinetd for example.

  The check requires MySQL >=3.22, for older version, please use TCP check.

  Most often, an incoming MySQL server needs to see the client's IP address for
  various purposes, including IP privilege matching and connection logging.
  When possible, it is often wise to masquerade the client's IP address when
  connecting to the server using the "usesrc" argument of the "source" keyword,
  which requires the transparent proxy feature to be compiled in, and the MySQL
  server to route the client via the machine hosting HAProxy.

  See also: "option httpchk"

option nolinger
no option nolinger
  Enable or disable immediate session resource cleaning after close
  May be used in sections:    defaults | frontend | listen | backend
                                 yes   |    yes   |   yes  |   yes
  Arguments : none

  When clients or servers abort connections in a dirty way (e.g. they are
  physically disconnected), the session timeouts triggers and the session is
  closed. But it will remain in FIN_WAIT1 state for some time in the system,
  using some resources and possibly limiting the ability to establish newer
  connections.

  When this happens, it is possible to activate "option nolinger" which forces
  the system to immediately remove any socket's pending data on close. Thus,
  a TCP RST is emitted, any pending data are truncated, and the session is
  instantly purged from the system's tables. The generally visible effect for
  a client is that responses are truncated if the close happens with a last
  block of data (e.g. on a redirect or error response). On the server side,
  it may help release the source ports immediately when forwarding a client
  aborts in tunnels. In both cases, TCP resets are emitted and given that
  the session is instantly destroyed, there will be no retransmit. On a lossy
  network this can increase problems, especially when there is a firewall on
  the lossy side, because the firewall might see and process the reset (hence
  purge its session) and block any further traffic for this session,, including
  retransmits from the other side. So if the other side doesn't receive it,
  it will never receive any RST again, and the firewall might log many blocked
  packets.

  For all these reasons, it is strongly recommended NOT to use this option,
  unless absolutely needed as a last resort. In most situations, using the
  "client-fin" or "server-fin" timeouts achieves similar results with a more
  reliable behavior. On Linux it's also possible to use the "tcp-ut" bind or
  server setting.

  This option may be used both on frontends and backends, depending on the side
  where it is required. Use it on the frontend for clients, and on the backend
  for servers. While this option is technically supported in "defaults"
  sections, it must really not be used there as it risks to accidentally
  propagate to sections that must no use it and to cause problems there.

  If this option has been enabled in a "defaults" section, it can be disabled
  in a specific instance by prepending the "no" keyword before it.

  See also: "timeout client-fin", "timeout server-fin", "tcp-ut" bind or server
            keywords.

option originalto [ except  ] [ header <name> ]
  Enable insertion of the X-Original-To header to requests sent to servers
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    yes   |   yes  |   yes
  Arguments :
     is an optional argument used to disable this option for sources
              matching 
    <name>    an optional argument to specify a different "X-Original-To"
              header name.

  Since HAProxy can work in transparent mode, every request from a client can
  be redirected to the proxy and HAProxy itself can proxy every request to a
  complex SQUID environment and the destination host from SO_ORIGINAL_DST will
  be lost. This is annoying when you want access rules based on destination ip
  addresses. To solve this problem, a new HTTP header "X-Original-To" may be
  added by HAProxy to all requests sent to the server. This header contains a
  value representing the original destination IP address. Since this must be
  configured to always use the last occurrence of this header only. Note that
  only the last occurrence of the header must be used, since it is really
  possible that the client has already brought one.

  The keyword "header" may be used to supply a different header name to replace
  the default "X-Original-To". This can be useful where you might already
  have a "X-Original-To" header from a different application, and you need
  preserve it. Also if your backend server doesn't use the "X-Original-To"
  header and requires different one.

  Sometimes, a same HAProxy instance may be shared between a direct client
  access and a reverse-proxy access (for instance when an SSL reverse-proxy is
  used to decrypt HTTPS traffic). It is possible to disable the addition of the
  header for a known destination address or network by adding the "except"
  keyword followed by the network address. In this case, any destination IP
  matching the network will not cause an addition of this header. Most common
  uses are with private networks or 127.0.0.1. IPv4 and IPv6 are both
  supported.

  This option may be specified either in the frontend or in the backend. If at
  least one of them uses it, the header will be added. Note that the backend's
  setting of the header subargument takes precedence over the frontend's if
  both are defined.

  Examples :
    # Original Destination address
    frontend www
        mode http
        option originalto except 127.0.0.1

    # Those servers want the IP Address in X-Client-Dst
    backend www
        mode http
        option originalto header X-Client-Dst

  See also : "option httpclose", "option http-server-close".

option persist
no option persist
  Enable or disable forced persistence on down servers
  May be used in sections:    defaults | frontend | listen | backend
                                 yes   |    no    |   yes  |   yes
  Arguments : none

  When an HTTP request reaches a backend with a cookie which references a dead
  server, by default it is redispatched to another server. It is possible to
  force the request to be sent to the dead server first using "option persist"
  if absolutely needed. A common use case is when servers are under extreme
  load and spend their time flapping. In this case, the users would still be
  directed to the server they opened the session on, in the hope they would be
  correctly served. It is recommended to use "option redispatch" in conjunction
  with this option so that in the event it would not be possible to connect to
  the server at all (server definitely dead), the client would finally be
  redirected to another valid server.

  If this option has been enabled in a "defaults" section, it can be disabled
  in a specific instance by prepending the "no" keyword before it.

  See also : "option redispatch", "retries", "force-persist"

option pgsql-check user <username>
  Use PostgreSQL health checks for server testing
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    no    |   yes  |   yes
  Arguments :
    <username> This is the username which will be used when connecting to
               PostgreSQL server.

  The check sends a PostgreSQL StartupMessage and waits for either
  Authentication request or ErrorResponse message. It is a basic but useful
  test which does not produce error nor aborted connect on the server.
  This check is identical with the "mysql-check".

  See also: "option httpchk"

option prefer-last-server
no option prefer-last-server
  Allow multiple load balanced requests to remain on the same server
  May be used in sections:    defaults | frontend | listen | backend
                                 yes   |    no    |   yes  |   yes
  Arguments : none

  When the load balancing algorithm in use is not deterministic, and a previous
  request was sent to a server to which HAProxy still holds a connection, it is
  sometimes desirable that subsequent requests on a same session go to the same
  server as much as possible. Note that this is different from persistence, as
  we only indicate a preference which HAProxy tries to apply without any form
  of warranty. The real use is for keep-alive connections sent to servers. When
  this option is used, HAProxy will try to reuse the same connection that is
  attached to the server instead of rebalancing to another server, causing a
  close of the connection. This can make sense for static file servers. It does
  not make much sense to use this in combination with hashing algorithms. Note,
  HAProxy already automatically tries to stick to a server which sends a 401 or
  to a proxy which sends a 407 (authentication required), when the load
  balancing algorithm is not deterministic. This is mandatory for use with the
  broken NTLM authentication challenge, and significantly helps in
  troubleshooting some faulty applications. Option prefer-last-server might be
  desirable in these environments as well, to avoid redistributing the traffic
  after every other response.

  If this option has been enabled in a "defaults" section, it can be disabled
  in a specific instance by prepending the "no" keyword before it.

  See also: "option http-keep-alive"

option redispatch
option redispatch <interval>
no option redispatch
  Enable or disable session redistribution in case of connection failure
  May be used in sections:    defaults | frontend | listen | backend
                                 yes   |    no    |   yes  |   yes
  Arguments :
    <interval> The optional integer value that controls how often redispatches
               occur when retrying connections. Positive value P indicates a
               redispatch is desired on every Pth retry, and negative value
               N indicate a redispatch is desired on the Nth retry prior to the
               last retry. For example, the default of -1 preserves the
               historical behavior of redispatching on the last retry, a
               positive value of 1 would indicate a redispatch on every retry,
               and a positive value of 3 would indicate a redispatch on every
               third retry. You can disable redispatches with a value of 0.


  In HTTP mode, if a server designated by a cookie is down, clients may
  definitely stick to it because they cannot flush the cookie, so they will not
  be able to access the service anymore.

  Specifying "option redispatch" will allow the proxy to break cookie or
  consistent hash based persistence and redistribute them to a working server.

  Active servers are selected from a subset of the list of available
  servers. Active servers that are not down or in maintenance (i.e., whose
  health is not checked or that have been checked as "up"), are selected in the
  following order:

    1. Any active, non-backup server, if any, or,

    2. If the "allbackups" option is not set, the first backup server in the
       list, or

    3. If the "allbackups" option is set, any backup server.

  When a retry occurs, HAProxy tries to select another server than the last
  one. The new server is selected from the current list of servers.

  Sometimes, if the list is updated between retries (e.g., if numerous retries
  occur and last longer than the time needed to check that a server is down,
  remove it from the list and fall back on the list of backup servers),
  connections may be redirected to a backup server, though.

  It also allows to retry connections to another server in case of multiple
  connection failures. Of course, it requires having "retries" set to a nonzero
  value.

  If this option has been enabled in a "defaults" section, it can be disabled
  in a specific instance by prepending the "no" keyword before it.

  See also : "retries", "force-persist"

option redis-check
  Use redis health checks for server testing
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    no    |   yes  |   yes
  Arguments : none

  It is possible to test that the server correctly talks REDIS protocol instead
  of just testing that it accepts the TCP connection. When this option is set,
  a PING redis command is sent to the server, and the response is analyzed to
  find the "+PONG" response message.

  Example :
        option redis-check

  See also : "option httpchk", "option tcp-check", "tcp-check expect"

option smtpchk
option smtpchk  
  Use SMTP health checks for server testing
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    no    |   yes  |   yes
  Arguments :
       is an optional argument. It is the "hello" command to use. It can
              be either "HELO" (for SMTP) or "EHLO" (for ESMTP). All other
              values will be turned into the default command ("HELO").

      is the domain name to present to the server. It may only be
              specified (and is mandatory) if the hello command has been
              specified. By default, "localhost" is used.

  When "option smtpchk" is set, the health checks will consist in TCP
  connections followed by an SMTP command. By default, this command is
  "HELO localhost". The server's return code is analyzed and only return codes
  starting with a "2" will be considered as valid. All other responses,
  including a lack of response will constitute an error and will indicate a
  dead server.

  This test is meant to be used with SMTP servers or relays. Depending on the
  request, it is possible that some servers do not log each connection attempt,
  so you may want to experiment to improve the behavior. Using telnet on port
  25 is often easier than adjusting the configuration.

  Most often, an incoming SMTP server needs to see the client's IP address for
  various purposes, including spam filtering, anti-spoofing and logging. When
  possible, it is often wise to masquerade the client's IP address when
  connecting to the server using the "usesrc" argument of the "source" keyword,
  which requires the transparent proxy feature to be compiled in.

  Example :
        option smtpchk HELO mydomain.org

  See also : "option httpchk", "source"

option socket-stats
no option socket-stats

  Enable or disable collecting & providing separate statistics for each socket.
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    yes   |   yes  |   no

  Arguments : none

option splice-auto
no option splice-auto
  Enable or disable automatic kernel acceleration on sockets in both directions
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    yes   |   yes  |   yes
  Arguments : none

  When this option is enabled either on a frontend or on a backend, HAProxy
  will automatically evaluate the opportunity to use kernel tcp splicing to
  forward data between the client and the server, in either direction. HAProxy
  uses heuristics to estimate if kernel splicing might improve performance or
  not. Both directions are handled independently. Note that the heuristics used
  are not much aggressive in order to limit excessive use of splicing. This
  option requires splicing to be enabled at compile time, and may be globally
  disabled with the global option "nosplice". Since splice uses pipes, using it
  requires that there are enough spare pipes.

  Important note: kernel-based TCP splicing is a Linux-specific feature which
  first appeared in kernel 2.6.25. It offers kernel-based acceleration to
  transfer data between sockets without copying these data to user-space, thus
  providing noticeable performance gains and CPU cycles savings. Since many
  early implementations are buggy, corrupt data and/or are inefficient, this
  feature is not enabled by default, and it should be used with extreme care.
  While it is not possible to detect the correctness of an implementation,
  2.6.29 is the first version offering a properly working implementation. In
  case of doubt, splicing may be globally disabled using the global "nosplice"
  keyword.

  Example :
        option splice-auto

  If this option has been enabled in a "defaults" section, it can be disabled
  in a specific instance by prepending the "no" keyword before it.

  See also : "option splice-request", "option splice-response", and global
             options "nosplice" and "maxpipes"

option splice-request
no option splice-request
  Enable or disable automatic kernel acceleration on sockets for requests
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    yes   |   yes  |   yes
  Arguments : none

  When this option is enabled either on a frontend or on a backend, HAProxy
  will use kernel tcp splicing whenever possible to forward data going from
  the client to the server. It might still use the recv/send scheme if there
  are no spare pipes left. This option requires splicing to be enabled at
  compile time, and may be globally disabled with the global option "nosplice".
  Since splice uses pipes, using it requires that there are enough spare pipes.

  Important note: see "option splice-auto" for usage limitations.

  Example :
        option splice-request

  If this option has been enabled in a "defaults" section, it can be disabled
  in a specific instance by prepending the "no" keyword before it.

  See also : "option splice-auto", "option splice-response", and global options
             "nosplice" and "maxpipes"

option splice-response
no option splice-response
  Enable or disable automatic kernel acceleration on sockets for responses
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    yes   |   yes  |   yes
  Arguments : none

  When this option is enabled either on a frontend or on a backend, HAProxy
  will use kernel tcp splicing whenever possible to forward data going from
  the server to the client. It might still use the recv/send scheme if there
  are no spare pipes left. This option requires splicing to be enabled at
  compile time, and may be globally disabled with the global option "nosplice".
  Since splice uses pipes, using it requires that there are enough spare pipes.

  Important note: see "option splice-auto" for usage limitations.

  Example :
        option splice-response

  If this option has been enabled in a "defaults" section, it can be disabled
  in a specific instance by prepending the "no" keyword before it.

  See also : "option splice-auto", "option splice-request", and global options
             "nosplice" and "maxpipes"

option spop-check
  Use SPOP health checks for server testing
  May be used in sections :   defaults | frontend | listen | backend
                                 no    |    no    |   no   |   yes
  Arguments : none

  It is possible to test that the server correctly talks SPOP protocol instead
  of just testing that it accepts the TCP connection. When this option is set,
  a HELLO handshake is performed between HAProxy and the server, and the
  response is analyzed to check no error is reported.

  Example :
        option spop-check

  See also : "option httpchk"

option srvtcpka
no option srvtcpka
  Enable or disable the sending of TCP keepalive packets on the server side
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    no    |   yes  |   yes
  Arguments : none

  When there is a firewall or any session-aware component between a client and
  a server, and when the protocol involves very long sessions with long idle
  periods (e.g. remote desktops), there is a risk that one of the intermediate
  components decides to expire a session which has remained idle for too long.

  Enabling socket-level TCP keep-alives makes the system regularly send packets
  to the other end of the connection, leaving it active. The delay between
  keep-alive probes is controlled by the system only and depends both on the
  operating system and its tuning parameters.

  It is important to understand that keep-alive packets are neither emitted nor
  received at the application level. It is only the network stacks which sees
  them. For this reason, even if one side of the proxy already uses keep-alives
  to maintain its connection alive, those keep-alive packets will not be
  forwarded to the other side of the proxy.

  Please note that this has nothing to do with HTTP keep-alive.

  Using option "srvtcpka" enables the emission of TCP keep-alive probes on the
  server side of a connection, which should help when session expirations are
  noticed between HAProxy and a server.

  If this option has been enabled in a "defaults" section, it can be disabled
  in a specific instance by prepending the "no" keyword before it.

  See also : "option clitcpka", "option tcpka"

option ssl-hello-chk
  Use SSLv3 client hello health checks for server testing
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    no    |   yes  |   yes
  Arguments : none

  When some SSL-based protocols are relayed in TCP mode through HAProxy, it is
  possible to test that the server correctly talks SSL instead of just testing
  that it accepts the TCP connection. When "option ssl-hello-chk" is set, pure
  SSLv3 client hello messages are sent once the connection is established to
  the server, and the response is analyzed to find an SSL server hello message.
  The server is considered valid only when the response contains this server
  hello message.

  All servers tested till there correctly reply to SSLv3 client hello messages,
  and most servers tested do not even log the requests containing only hello
  messages, which is appreciable.

  Note that this check works even when SSL support was not built into HAProxy
  because it forges the SSL message. When SSL support is available, it is best
  to use native SSL health checks instead of this one.

  See also: "option httpchk", "check-ssl"

option tcp-check
  Perform health checks using tcp-check send/expect sequences
  May be used in sections:   defaults | frontend | listen | backend
                               yes    |    no    |   yes  |   yes

  This health check method is intended to be combined with "tcp-check" command
  lists in order to support send/expect types of health check sequences.

  TCP checks currently support 4 modes of operations :
    - no "tcp-check" directive : the health check only consists in a connection
      attempt, which remains the default mode.

    - "tcp-check send" or "tcp-check send-binary" only is mentioned : this is
      used to send a string along with a connection opening. With some
      protocols, it helps sending a "QUIT" message for example that prevents
      the server from logging a connection error for each health check. The
      check result will still be based on the ability to open the connection
      only.

    - "tcp-check send" 또는 "tcp-check send-binary"만 언급됨: 
       이것은 연결 열기와 함께 문자열을 보내는 데 사용됩니다. 
       일부 프로토콜을 사용하면 예를 들어 서버가 각 상태 확인에 대한 연결 오류를 
       기록하지 못하도록 하는 "QUIT" 메시지를 보내는 데 도움이 됩니다. 
       확인 결과는 여전히 연결을 여는 기능에만 기반합니다.

    - "tcp-check expect" only is mentioned : this is used to test a banner.
      The connection is opened and HAProxy waits for the server to present some
      contents which must validate some rules. The check result will be based
      on the matching between the contents and the rules. This is suited for
      POP, IMAP, SMTP, FTP, SSH, TELNET.
    - "tcp-check expect"만 언급됨: 배너를 테스트하는 데 사용됩니다.
       연결이 열리고 HAProxy는 서버가 일부 규칙의 유효성을 검사해야 하는 콘텐츠를 
       제공할 때까지 기다립니다. 검사 결과는 내용과 규칙 간의 일치를 기반으로 합니다. 
       POP, IMAP, SMTP, FTP, SSH, TELNET에 적합합니다.
       
    - both "tcp-check send" and "tcp-check expect" are mentioned : this is
      used to test a hello-type protocol. HAProxy sends a message, the server
      responds and its response is analyzed. the check result will be based on
      the matching between the response contents and the rules. This is often
      suited for protocols which require a binding or a request/response model.
      LDAP, MySQL, Redis and SSL are example of such protocols, though they
      already all have their dedicated checks with a deeper understanding of
      the respective protocols.
      In this mode, many questions may be sent and many answers may be
      analyzed.
    - "tcp-check send" 및 "tcp-check expect"가 모두 언급됨: 이것은 hello-type 
       프로토콜을 테스트하는 데 사용됩니다. HAProxy가 메시지를 보내면 서버가 응답하고 
       해당 응답을 분석합니다. 확인 결과는 응답 내용과 규칙 간의 일치를 기반으로 합니다. 
       이는 종종 바인딩 또는 요청/응답 모델이 필요한 프로토콜에 적합합니다.
       LDAP, MySQL, Redis 및 SSL은 이러한 프로토콜의 예이지만 이미 모두 해당 프로토콜에 
       대한 더 깊은 이해를 통해 전용 검사를 가지고 있습니다.
       이 모드에서는 많은 질문이 전송되고 많은 답변이 분석될 수 있습니다.
       
  A fifth mode can be used to insert comments in different steps of the script.
  다섯 번째 모드는 스크립트의 다른 단계에 주석을 삽입하는 데 사용할 수 있습니다.
  
  For each tcp-check rule you create, you can add a "comment" directive,
  followed by a string. This string will be reported in the log and stderr in
  debug mode. It is useful to make user-friendly error reporting.  The
  "comment" is of course optional.
  생성한 각 tcp-check 규칙에 대해 "주석" 지시어와 문자열을 추가할 수 있습니다. 
  이 문자열은 디버그 모드에서 로그 및 stderr에 보고됩니다. 
  사용자에게 친숙한 오류 보고를 만드는 데 유용합니다. 
  그만큼 "주석"은 물론 선택 사항입니다.
   
  During the execution of a health check, a variable scope is made available to
  store data samples, using the "tcp-check set-var" operation. Freeing those
  variable is possible using "tcp-check unset-var".
  상태 확인을 실행하는 동안 "tcp-check set-var" 작업을 사용하여 데이터 샘플을 저장하는 데 
  변수 범위를 사용할 수 있습니다. "tcp-check unset-var"를 사용하여 해당 변수를 해제할 수 있습니다.

  Examples :
         # perform a POP check (analyze only server's banner)
         option tcp-check
         tcp-check expect string +OK\ POP3\ ready comment POP\ protocol

         # perform an IMAP check (analyze only server's banner)
         option tcp-check
         tcp-check expect string *\ OK\ IMAP4\ ready comment IMAP\ protocol

         # look for the redis master server after ensuring it speaks well
         # redis protocol, then it exits properly.
         # (send a command then analyze the response 3 times)
         option tcp-check
         tcp-check comment PING\ phase
         tcp-check send PING\r\n
         tcp-check expect string +PONG
         tcp-check comment role\ check
         tcp-check send info\ replication\r\n
         tcp-check expect string role:master
         tcp-check comment QUIT\ phase
         tcp-check send QUIT\r\n
         tcp-check expect string +OK

         forge a HTTP request, then analyze the response
         (send many headers before analyzing)
         option tcp-check
         tcp-check comment forge\ and\ send\ HTTP\ request
         tcp-check send HEAD\ /\ HTTP/1.1\r\n
         tcp-check send Host:\ www.mydomain.com\r\n
         tcp-check send User-Agent:\ HAProxy\ tcpcheck\r\n
         tcp-check send \r\n
         tcp-check expect rstring HTTP/1\..\ (2..|3..) comment check\ HTTP\ response


  See also : "tcp-check connect", "tcp-check expect" and "tcp-check send".

option tcp-smart-accept
no option tcp-smart-accept
  Enable or disable the saving of one ACK packet during the accept sequence
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    yes   |   yes  |    no
  Arguments : none

  When an HTTP connection request comes in, the system acknowledges it on
  behalf of HAProxy, then the client immediately sends its request, and the
  system acknowledges it too while it is notifying HAProxy about the new
  connection. HAProxy then reads the request and responds. This means that we
  have one TCP ACK sent by the system for nothing, because the request could
  very well be acknowledged by HAProxy when it sends its response.

  For this reason, in HTTP mode, HAProxy automatically asks the system to avoid
  sending this useless ACK on platforms which support it (currently at least
  Linux). It must not cause any problem, because the system will send it anyway
  after 40 ms if the response takes more time than expected to come.

  During complex network debugging sessions, it may be desirable to disable
  this optimization because delayed ACKs can make troubleshooting more complex
  when trying to identify where packets are delayed. It is then possible to
  fall back to normal behavior by specifying "no option tcp-smart-accept".

  It is also possible to force it for non-HTTP proxies by simply specifying
  "option tcp-smart-accept". For instance, it can make sense with some services
  such as SMTP where the server speaks first.

  It is recommended to avoid forcing this option in a defaults section. In case
  of doubt, consider setting it back to automatic values by prepending the
  "default" keyword before it, or disabling it using the "no" keyword.

  See also : "option tcp-smart-connect"

option tcp-smart-connect
no option tcp-smart-connect
  Enable or disable the saving of one ACK packet during the connect sequence
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    no    |   yes  |   yes
  Arguments : none

  On certain systems (at least Linux), HAProxy can ask the kernel not to
  immediately send an empty ACK upon a connection request, but to directly
  send the buffer request instead. This saves one packet on the network and
  thus boosts performance. It can also be useful for some servers, because they
  immediately get the request along with the incoming connection.

  This feature is enabled when "option tcp-smart-connect" is set in a backend.
  It is not enabled by default because it makes network troubleshooting more
  complex.

  It only makes sense to enable it with protocols where the client speaks first
  such as HTTP. In other situations, if there is no data to send in place of
  the ACK, a normal ACK is sent.

  If this option has been enabled in a "defaults" section, it can be disabled
  in a specific instance by prepending the "no" keyword before it.

  See also : "option tcp-smart-accept"

option tcpka
  Enable or disable the sending of TCP keepalive packets on both sides
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    yes   |   yes  |   yes
  Arguments : none

  When there is a firewall or any session-aware component between a client and
  a server, and when the protocol involves very long sessions with long idle
  periods (e.g. remote desktops), there is a risk that one of the intermediate
  components decides to expire a session which has remained idle for too long.

  Enabling socket-level TCP keep-alives makes the system regularly send packets
  to the other end of the connection, leaving it active. The delay between
  keep-alive probes is controlled by the system only and depends both on the
  operating system and its tuning parameters.

  It is important to understand that keep-alive packets are neither emitted nor
  received at the application level. It is only the network stacks which sees
  them. For this reason, even if one side of the proxy already uses keep-alives
  to maintain its connection alive, those keep-alive packets will not be
  forwarded to the other side of the proxy.

  Please note that this has nothing to do with HTTP keep-alive.

  Using option "tcpka" enables the emission of TCP keep-alive probes on both
  the client and server sides of a connection. Note that this is meaningful
  only in "defaults" or "listen" sections. If this option is used in a
  frontend, only the client side will get keep-alives, and if this option is
  used in a backend, only the server side will get keep-alives. For this
  reason, it is strongly recommended to explicitly use "option clitcpka" and
  "option srvtcpka" when the configuration is split between frontends and
  backends.

  See also : "option clitcpka", "option srvtcpka"

option tcplog
  Enable advanced logging of TCP connections with session state and timers
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    yes   |   yes  |   no
  Arguments : none

  By default, the log output format is very poor, as it only contains the
  source and destination addresses, and the instance name. By specifying
  "option tcplog", each log line turns into a much richer format including, but
  not limited to, the connection timers, the session status, the connections
  numbers, the frontend, backend and server name, and of course the source
  address and ports. This option is useful for pure TCP proxies in order to
  find which of the client or server disconnects or times out. For normal HTTP
  proxies, it's better to use "option httplog" which is even more complete.

  "option tcplog" overrides any previous "log-format" directive.

  See also :  "option httplog", and section 8 about logging.

option transparent
no option transparent
  Enable client-side transparent proxying
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    no    |   yes  |   yes
  Arguments : none

  This option was introduced in order to provide layer 7 persistence to layer 3
  load balancers. The idea is to use the OS's ability to redirect an incoming
  connection for a remote address to a local process (here HAProxy), and let
  this process know what address was initially requested. When this option is
  used, sessions without cookies will be forwarded to the original destination
  IP address of the incoming request (which should match that of another
  equipment), while requests with cookies will still be forwarded to the
  appropriate server.

  Note that contrary to a common belief, this option does NOT make HAProxy
  present the client's IP to the server when establishing the connection.

  See also: the "usesrc" argument of the "source" keyword, and the
            "transparent" option of the "bind" keyword.

external-check command 
  Executable to run when performing an external-check
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    no    |   yes  |   yes

  Arguments :
     is the external command to run

  The arguments passed to the to the command are:

  <proxy_address> <proxy_port> <server_address> <server_port>

  The <proxy_address> and <proxy_port> are derived from the first listener
  that is either IPv4, IPv6 or a UNIX socket. In the case of a UNIX socket
  listener the proxy_address will be the path of the socket and the
  <proxy_port> will be the string "NOT_USED". In a backend section, it's not
  possible to determine a listener, and both <proxy_address> and <proxy_port>
  will have the string value "NOT_USED".

  Some values are also provided through environment variables.

  Environment variables :
    HAPROXY_PROXY_ADDR      The first bind address if available (or empty if not
                            applicable, for example in a "backend" section).

    HAPROXY_PROXY_ID        The backend id.

    HAPROXY_PROXY_NAME      The backend name.

    HAPROXY_PROXY_PORT      The first bind port if available (or empty if not
                            applicable, for example in a "backend" section or
                            for a UNIX socket).

    HAPROXY_SERVER_ADDR     The server address.

    HAPROXY_SERVER_CURCONN  The current number of connections on the server.

    HAPROXY_SERVER_ID       The server id.

    HAPROXY_SERVER_MAXCONN  The server max connections.

    HAPROXY_SERVER_NAME     The server name.

    HAPROXY_SERVER_PORT     The server port if available (or empty for a UNIX
                            socket).

    HAPROXY_SERVER_SSL      "0" when SSL is not used, "1" when it is used

    HAPROXY_SERVER_PROTO    The protocol used by this server, which can be one
                            of "cli" (the haproxy CLI), "syslog" (syslog TCP
                            server), "peers" (peers TCP server), "h1" (HTTP/1.x
                            server), "h2" (HTTP/2 server), or "tcp" (any other
                            TCP server).

    PATH                    The PATH environment variable used when executing
                            the command may be set using "external-check path".

  See also "2.3. Environment variables" for other variables.

  If the command executed and exits with a zero status then the check is
  considered to have passed, otherwise the check is considered to have
  failed.

  Example :
        external-check command /bin/true

  See also : "external-check", "option external-check", "external-check path"

external-check path <path>
  The value of the PATH environment variable used when running an external-check
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    no    |   yes  |   yes

  Arguments :
    <path> is the path used when executing external command to run

  The default path is "".

  Example :
        external-check path "/usr/bin:/bin"

  See also : "external-check", "option external-check",
             "external-check command"

persist rdp-cookie
persist rdp-cookie(<name>)
  Enable RDP cookie-based persistence
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    no    |   yes  |   yes
  Arguments :
    <name>    is the optional name of the RDP cookie to check. If omitted, the
              default cookie name "msts" will be used. There currently is no
              valid reason to change this name.

  This statement enables persistence based on an RDP cookie. The RDP cookie
  contains all information required to find the server in the list of known
  servers. So when this option is set in the backend, the request is analyzed
  and if an RDP cookie is found, it is decoded. If it matches a known server
  which is still UP (or if "option persist" is set), then the connection is
  forwarded to this server.

  Note that this only makes sense in a TCP backend, but for this to work, the
  frontend must have waited long enough to ensure that an RDP cookie is present
  in the request buffer. This is the same requirement as with the "rdp-cookie"
  load-balancing method. Thus it is highly recommended to put all statements in
  a single "listen" section.

  Also, it is important to understand that the terminal server will emit this
  RDP cookie only if it is configured for "token redirection mode", which means
  that the "IP address redirection" option is disabled.

  Example :
        listen tse-farm
            bind :3389
            # wait up to 5s for an RDP cookie in the request
            tcp-request inspect-delay 5s
            tcp-request content accept if RDP_COOKIE
            # apply RDP cookie persistence
            persist rdp-cookie
            # if server is unknown, let's balance on the same cookie.
            # alternatively, "balance leastconn" may be useful too.
            balance rdp-cookie
            server srv1 1.1.1.1:3389
            server srv2 1.1.1.2:3389

  See also : "balance rdp-cookie", "tcp-request" and the "req.rdp_cookie" ACL.

rate-limit sessions 
  Set a limit on the number of new sessions accepted per second on a frontend
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    yes   |   yes  |   no
  Arguments :
        The  parameter is an integer designating the maximum number
              of new sessions per second to accept on the frontend.

  When the frontend reaches the specified number of new sessions per second, it
  stops accepting new connections until the rate drops below the limit again.
  During this time, the pending sessions will be kept in the socket's backlog
  (in system buffers) and HAProxy will not even be aware that sessions are
  pending. When applying very low limit on a highly loaded service, it may make
  sense to increase the socket's backlog using the "backlog" keyword.

  This feature is particularly efficient at blocking connection-based attacks
  or service abuse on fragile servers. Since the session rate is measured every
  millisecond, it is extremely accurate. Also, the limit applies immediately,
  no delay is needed at all to detect the threshold.

  Example : limit the connection rate on SMTP to 10 per second max
        listen smtp
            mode tcp
            bind :25
            rate-limit sessions 10
            server smtp1 127.0.0.1:1025

  Note : when the maximum rate is reached, the frontend's status is not changed
         but its sockets appear as "WAITING" in the statistics if the
         "socket-stats" option is enabled.

  See also : the "backlog" keyword and the "fe_sess_rate" ACL criterion.

redirect location  [code <code>] <option> [{if | unless} <condition>]
redirect prefix    [code <code>] <option> [{if | unless} <condition>]
redirect scheme   <sch> [code <code>] <option> [{if | unless} <condition>]
  Return an HTTP redirection if/unless a condition is matched
  May be used in sections :   defaults | frontend | listen | backend
                                 no    |    yes   |   yes  |   yes

  If/unless the condition is matched, the HTTP request will lead to a redirect
  response. If no condition is specified, the redirect applies unconditionally.

  Arguments :
         With "redirect location", the exact value in  is placed into
              the HTTP "Location" header. When used in an "http-request" rule,
               value follows the log-format rules and can include some
              dynamic values (see Custom Log Format in section 8.2.4).

         With "redirect prefix", the "Location" header is built from the
              concatenation of  and the complete URI path, including the
              query string, unless the "drop-query" option is specified (see
              below). As a special case, if  equals exactly "/", then
              nothing is inserted before the original URI. It allows one to
              redirect to the same URL (for instance, to insert a cookie). When
              used in an "http-request" rule,  value follows the log-format
              rules and can include some dynamic values (see Custom Log Format
              in section 8.2.4).

    <sch>     With "redirect scheme", then the "Location" header is built by
              concatenating <sch> with "://" then the first occurrence of the
              "Host" header, and then the URI path, including the query string
              unless the "drop-query" option is specified (see below). If no
              path is found or if the path is "*", then "/" is used instead. If
              no "Host" header is found, then an empty host component will be
              returned, which most recent browsers interpret as redirecting to
              the same host. This directive is mostly used to redirect HTTP to
              HTTPS. When used in an "http-request" rule, <sch> value follows
              the log-format rules and can include some dynamic values (see
              Custom Log Format in section 8.2.4).

    <code>    The code is optional. It indicates which type of HTTP redirection
              is desired. Only codes 301, 302, 303, 307 and 308 are supported,
              with 302 used by default if no code is specified. 301 means
              "Moved permanently", and a browser may cache the Location. 302
              means "Moved temporarily" and means that the browser should not
              cache the redirection. 303 is equivalent to 302 except that the
              browser will fetch the location with a GET method. 307 is just
              like 302 but makes it clear that the same method must be reused.
              Likewise, 308 replaces 301 if the same method must be used.

    <option>  There are several options which can be specified to adjust the
              expected behavior of a redirection :

      - "drop-query"
        When this keyword is used in a prefix-based redirection, then the
        location will be set without any possible query-string, which is useful
        for directing users to a non-secure page for instance. It has no effect
        with a location-type redirect.

      - "append-slash"
        This keyword may be used in conjunction with "drop-query" to redirect
        users who use a URL not ending with a '/' to the same one with the '/'.
        It can be useful to ensure that search engines will only see one URL.
        For this, a return code 301 is preferred.

      - "ignore-empty"
        This keyword only has effect when a location is produced using a log
        format expression (i.e. when used in http-request or http-response).
        It indicates that if the result of the expression is empty, the rule
        should silently be skipped. The main use is to allow mass-redirects
        of known paths using a simple map.

      - "set-cookie NAME[=value]"
        A "Set-Cookie" header will be added with NAME (and optionally "=value")
        to the response. This is sometimes used to indicate that a user has
        been seen, for instance to protect against some types of DoS. No other
        cookie option is added, so the cookie will be a session cookie. Note
        that for a browser, a sole cookie name without an equal sign is
        different from a cookie with an equal sign.

      - "clear-cookie NAME[=]"
        A "Set-Cookie" header will be added with NAME (and optionally "="), but
        with the "Max-Age" attribute set to zero. This will tell the browser to
        delete this cookie. It is useful for instance on logout pages. It is
        important to note that clearing the cookie "NAME" will not remove a
        cookie set with "NAME=value". You have to clear the cookie "NAME=" for
        that, because the browser makes the difference.

  Example: move the login URL only to HTTPS.
        acl clear      dst_port  80
        acl secure     dst_port  8080
        acl login_page url_beg   /login
        acl logout     url_beg   /logout
        acl uid_given  url_reg   /login?userid=[^&]+
        acl cookie_set hdr_sub(cookie) SEEN=1

        redirect prefix   https://mysite.com set-cookie SEEN=1 if !cookie_set
        redirect prefix   https://mysite.com           if login_page !secure
        redirect prefix   http://mysite.com drop-query if login_page !uid_given
        redirect location http://mysite.com/           if !login_page secure
        redirect location / clear-cookie USERID=       if logout

  Example: send redirects for request for articles without a '/'.
        acl missing_slash path_reg ^/article/[^/]*$
        redirect code 301 prefix / drop-query append-slash if missing_slash

  Example: redirect all HTTP traffic to HTTPS when SSL is handled by HAProxy.
        redirect scheme https if !{ ssl_fc }

  Example: append 'www.' prefix in front of all hosts not having it
        http-request redirect code 301 location      \
          http://www.%[hdr(host)]%[capture.req.uri]  \
          unless { hdr_beg(host) -i www }

  Example: permanently redirect only old URLs to new ones
        http-request redirect code 301 location               \
          %[path,map_str(old-blog-articles.map)] ignore-empty

  See section 7 about ACL usage.

retries <value>
  Set the number of retries to perform on a server after a connection failure
  May be used in sections:    defaults | frontend | listen | backend
                                 yes   |    no    |   yes  |   yes
  Arguments :
    <value>   is the number of times a connection attempt should be retried on
              a server when a connection either is refused or times out. The
              default value is 3.

  It is important to understand that this value applies to the number of
  connection attempts, not full requests. When a connection has effectively
  been established to a server, there will be no more retry.

  In order to avoid immediate reconnections to a server which is restarting,
  a turn-around timer of min("timeout connect", one second) is applied before
  a retry occurs.

  When "option redispatch" is set, the last retry may be performed on another
  server even if a cookie references a different server.

  See also : "option redispatch"

retry-on [space-delimited list of keywords]
  Specify when to attempt to automatically retry a failed request.
  This setting is only valid when "mode" is set to http and is silently ignored
  otherwise.
  May be used in sections:    defaults | frontend | listen | backend
                                 yes   |    no    |   yes  |   yes
  Arguments :
    <keywords>  is a space-delimited list of keywords or HTTP status codes, each
                representing a type of failure event on which an attempt to
                retry the request is desired. Please read the notes at the
                bottom before changing this setting. The following keywords are
                supported :

      none              never retry

      conn-failure      retry when the connection or the SSL handshake failed
                        and the request could not be sent. This is the default.

      empty-response    retry when the server connection was closed after part
                        of the request was sent, and nothing was received from
                        the server. This type of failure may be caused by the
                        request timeout on the server side, poor network
                        condition, or a server crash or restart while
                        processing the request.

      junk-response     retry when the server returned something not looking
                        like a complete HTTP response. This includes partial
                        responses headers as well as non-HTTP contents. It
                        usually is a bad idea to retry on such events, which
                        may be caused a configuration issue (wrong server port)
                        or by the request being harmful to the server (buffer
                        overflow attack for example).

      response-timeout  the server timeout stroke while waiting for the server
                        to respond to the request. This may be caused by poor
                        network condition, the reuse of an idle connection
                        which has expired on the path, or by the request being
                        extremely expensive to process. It generally is a bad
                        idea to retry on such events on servers dealing with
                        heavy database processing (full scans, etc) as it may
                        amplify denial of service attacks.

      0rtt-rejected     retry requests which were sent over early data and were
                        rejected by the server. These requests are generally
                        considered to be safe to retry.

                any HTTP status code among "401" (Unauthorized), "403"
                        (Forbidden), "404" (Not Found), "408" (Request Timeout),
                        "425" (Too Early), "500" (Server Error), "501" (Not
                        Implemented), "502" (Bad Gateway), "503" (Service
                        Unavailable), "504" (Gateway Timeout).

      all-retryable-errors
                        retry request for any error that are considered
            retryable. This currently activates "conn-failure",
            "empty-response", "junk-response", "response-timeout",
            "0rtt-rejected", "500", "502", "503", and "504".

  Using this directive replaces any previous settings with the new ones; it is
  not cumulative.

  Please note that using anything other than "none" and "conn-failure" requires
  to allocate a buffer and copy the whole request into it, so it has memory and
  performance impacts. Requests not fitting in a single buffer will never be
  retried (see the global tune.bufsize setting).

  You have to make sure the application has a replay protection mechanism built
  in such as a unique transaction IDs passed in requests, or that replaying the
  same request has no consequence, or it is very dangerous to use any retry-on
  value beside "conn-failure" and "none". Static file servers and caches are
  generally considered safe against any type of retry. Using a status code can
  be useful to quickly leave a server showing an abnormal behavior (out of
  memory, file system issues, etc), but in this case it may be a good idea to
  immediately redispatch the connection to another server (please see "option
  redispatch" for this). Last, it is important to understand that most causes
  of failures are the requests themselves and that retrying a request causing a
  server to misbehave will often make the situation even worse for this server,
  or for the whole service in case of redispatch.

  Unless you know exactly how the application deals with replayed requests, you
  should not use this directive.

  The default is "conn-failure".

  Example:
    retry-on 503 504

  See also: "retries", "option redispatch", "tune.bufsize"

server <name> <address>[:[port]] [param*]
  Declare a server in a backend
  May be used in sections :   defaults | frontend | listen | backend
                                 no    |    no    |   yes  |   yes
  Arguments :
    <name>    is the internal name assigned to this server. This name will
              appear in logs and alerts. If "http-send-name-header" is
              set, it will be added to the request header sent to the server.

    <address> is the IPv4 or IPv6 address of the server. Alternatively, a
              resolvable hostname is supported, but this name will be resolved
              during start-up. Address "0.0.0.0" or "*" has a special meaning.
              It indicates that the connection will be forwarded to the same IP
              address as the one from the client connection. This is useful in
              transparent proxy architectures where the client's connection is
              intercepted and HAProxy must forward to the original destination
              address. This is more or less what the "transparent" keyword does
              except that with a server it's possible to limit concurrency and
              to report statistics. Optionally, an address family prefix may be
              used before the address to force the family regardless of the
              address format, which can be useful to specify a path to a unix
              socket with no slash ('/'). Currently supported prefixes are :
                    - 'ipv4@'  -> address is always IPv4
                    - 'ipv6@'  -> address is always IPv6
                    - 'unix@'  -> address is a path to a local unix socket
                    - 'abns@'  -> address is in abstract namespace (Linux only)
                    - 'sockpair@' -> address is the FD of a connected unix
                      socket or of a socketpair. During a connection, the
                      backend creates a pair of connected sockets, and passes
                      one of them over the FD. The bind part will use the
                      received socket as the client FD. Should be used
                      carefully.
              You may want to reference some environment variables in the
              address parameter, see section 2.3 about environment
              variables. The "init-addr" setting can be used to modify the way
              IP addresses should be resolved upon startup.

    <port>    is an optional port specification. If set, all connections will
              be sent to this port. If unset, the same port the client
              connected to will be used. The port may also be prefixed by a "+"
              or a "-". In this case, the server's port will be determined by
              adding this value to the client's port.

    <param*>  is a list of parameters for this server. The "server" keywords
              accepts an important number of options and has a complete section
              dedicated to it. Please refer to section 5 for more details.

  Examples :
        server first  10.1.1.1:1080 cookie first  check inter 1000
        server second 10.1.1.2:1080 cookie second check inter 1000
        server transp ipv4@
        server backup "${SRV_BACKUP}:1080" backup
        server www1_dc1 "${LAN_DC1}.101:80"
        server www1_dc2 "${LAN_DC2}.101:80"

  Note: regarding Linux's abstract namespace sockets, HAProxy uses the whole
        sun_path length is used for the address length. Some other programs
        such as socat use the string length only by default. Pass the option
        ",unix-tightsocklen=0" to any abstract socket definition in socat to
        make it compatible with HAProxy's.

  See also: "default-server", "http-send-name-header" and section 5 about
             server options

server-state-file-name [ { use-backend-name | <file> } ]
  Set the server state file to read, load and apply to servers available in
  this backend.
  May be used in sections:    defaults | frontend | listen | backend
                                  no   |    no   |   yes  |   yes

  It only applies when the directive "load-server-state-from-file" is set to
  "local". When <file> is not provided, if "use-backend-name" is used or if
  this directive is not set, then backend name is used. If <file> starts with a
  slash '/', then it is considered as an absolute path. Otherwise, <file> is
  concatenated to the global directive "server-state-base".

  Example: the minimal configuration below would make HAProxy look for the
           state server file '/etc/haproxy/states/bk':

    global
      server-state-file-base /etc/haproxy/states

    backend bk
      load-server-state-from-file

  See also: "server-state-base", "load-server-state-from-file", and
  "show servers state"

server-template   [:<port>] [params*]
  Set a template to initialize servers with shared parameters.
  The names of these servers are built from  and  parameters.
  May be used in sections :   defaults | frontend | listen | backend
                                 no    |    no    |   yes  |   yes

  Arguments:
      A prefix for the server names to be built.

    
              If  is provided, this template initializes  servers
              with 1 up to  as server name suffixes. A range of numbers
              - may also be used to use  up to
               as server name suffixes.

        A FQDN for all the servers this template initializes.

    <port>    Same meaning as "server" <port> argument (see "server" keyword).

    <params*>
              Remaining server parameters among all those supported by "server"
              keyword.

  Examples:
    # Initializes 3 servers with srv1, srv2 and srv3 as names,
    # google.com as FQDN, and health-check enabled.
    server-template srv 1-3 google.com:80 check

    # or
    server-template srv 3 google.com:80 check

    # would be equivalent to:
    server srv1 google.com:80 check
    server srv2 google.com:80 check
    server srv3 google.com:80 check

source <addr>[:<port>] [usesrc { <addr2>[:<port2>] | client | clientip } ]
source <addr>[:<port>] [usesrc { <addr2>[:<port2>] | hdr_ip([,<occ>]) } ]
source <addr>[:<port>] [interface <name>]
  Set the source address for outgoing connections
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    no    |   yes  |   yes
  Arguments :
    <addr>    is the IPv4 address HAProxy will bind to before connecting to a
              server. This address is also used as a source for health checks.

              The default value of 0.0.0.0 means that the system will select
              the most appropriate address to reach its destination. Optionally
              an address family prefix may be used before the address to force
              the family regardless of the address format, which can be useful
              to specify a path to a unix socket with no slash ('/'). Currently
              supported prefixes are :
                - 'ipv4@' -> address is always IPv4
                - 'ipv6@' -> address is always IPv6
                - 'unix@' -> address is a path to a local unix socket
                - 'abns@' -> address is in abstract namespace (Linux only)
              You may want to reference some environment variables in the
              address parameter, see section 2.3 about environment variables.

    <port>    is an optional port. It is normally not needed but may be useful
              in some very specific contexts. The default value of zero means
              the system will select a free port. Note that port ranges are not
              supported in the backend. If you want to force port ranges, you
              have to specify them on each "server" line.

    <addr2>   is the IP address to present to the server when connections are
              forwarded in full transparent proxy mode. This is currently only
              supported on some patched Linux kernels. When this address is
              specified, clients connecting to the server will be presented
              with this address, while health checks will still use the address
              <addr>.

    <port2>   is the optional port to present to the server when connections
              are forwarded in full transparent proxy mode (see <addr2> above).
              The default value of zero means the system will select a free
              port.

         is the name of a HTTP header in which to fetch the IP to bind to.
              This is the name of a comma-separated header list which can
              contain multiple IP addresses. By default, the last occurrence is
              used. This is designed to work with the X-Forwarded-For header
              and to automatically bind to the client's IP address as seen
              by previous proxy, typically Stunnel. In order to use another
              occurrence from the last one, please see the <occ> parameter
              below. When the header (or occurrence) is not found, no binding
              is performed so that the proxy's default IP address is used. Also
              keep in mind that the header name is case insensitive, as for any
              HTTP header.

    <occ>     is the occurrence number of a value to be used in a multi-value
              header. This is to be used in conjunction with "hdr_ip()",
              in order to specify which occurrence to use for the source IP
              address. Positive values indicate a position from the first
              occurrence, 1 being the first one. Negative values indicate
              positions relative to the last one, -1 being the last one. This
              is helpful for situations where an X-Forwarded-For header is set
              at the entry point of an infrastructure and must be used several
              proxy layers away. When this value is not specified, -1 is
              assumed. Passing a zero here disables the feature.

    <name>    is an optional interface name to which to bind to for outgoing
              traffic. On systems supporting this features (currently, only
              Linux), this allows one to bind all traffic to the server to
              this interface even if it is not the one the system would select
              based on routing tables. This should be used with extreme care.
              Note that using this option requires root privileges.

  The "source" keyword is useful in complex environments where a specific
  address only is allowed to connect to the servers. It may be needed when a
  private address must be used through a public gateway for instance, and it is
  known that the system cannot determine the adequate source address by itself.

  An extension which is available on certain patched Linux kernels may be used
  through the "usesrc" optional keyword. It makes it possible to connect to the
  servers with an IP address which does not belong to the system itself. This
  is called "full transparent proxy mode". For this to work, the destination
  servers have to route their traffic back to this address through the machine
  running HAProxy, and IP forwarding must generally be enabled on this machine.

  In this "full transparent proxy" mode, it is possible to force a specific IP
  address to be presented to the servers. This is not much used in fact. A more
  common use is to tell HAProxy to present the client's IP address. For this,
  there are two methods :

    - present the client's IP and port addresses. This is the most transparent
      mode, but it can cause problems when IP connection tracking is enabled on
      the machine, because a same connection may be seen twice with different
      states. However, this solution presents the huge advantage of not
      limiting the system to the 64k outgoing address+port couples, because all
      of the client ranges may be used.

    - present only the client's IP address and select a spare port. This
      solution is still quite elegant but slightly less transparent (downstream
      firewalls logs will not match upstream's). It also presents the downside
      of limiting the number of concurrent connections to the usual 64k ports.
      However, since the upstream and downstream ports are different, local IP
      connection tracking on the machine will not be upset by the reuse of the
      same session.

  This option sets the default source for all servers in the backend. It may
  also be specified in a "defaults" section. Finer source address specification
  is possible at the server level using the "source" server option. Refer to
  section 5 for more information.

  In order to work, "usesrc" requires root privileges.

  Examples :
        backend private
            # Connect to the servers using our 192.168.1.200 source address
            source 192.168.1.200

        backend transparent_ssl1
            # Connect to the SSL farm from the client's source address
            source 192.168.1.200 usesrc clientip

        backend transparent_ssl2
            # Connect to the SSL farm from the client's source address and port
            # not recommended if IP conntrack is present on the local machine.
            source 192.168.1.200 usesrc client

        backend transparent_ssl3
            # Connect to the SSL farm from the client's source address. It
            # is more conntrack-friendly.
            source 192.168.1.200 usesrc clientip

        backend transparent_smtp
            # Connect to the SMTP farm from the client's source address/port
            # with Tproxy version 4.
            source 0.0.0.0 usesrc clientip

        backend transparent_http
            # Connect to the servers using the client's IP as seen by previous
            # proxy.
            source 0.0.0.0 usesrc hdr_ip(x-forwarded-for,-1)

  See also : the "source" server option in section 5, the Tproxy patches for
             the Linux kernel on www.balabit.com, the "bind" keyword.

srvtcpka-cnt <count>
  Sets the maximum number of keepalive probes TCP should send before dropping
  the connection on the server side.
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    no    |   yes  |   yes
  Arguments :
    <count>   is the maximum number of keepalive probes.

  This keyword corresponds to the socket option TCP_KEEPCNT. If this keyword
  is not specified, system-wide TCP parameter (tcp_keepalive_probes) is used.
  The availability of this setting depends on the operating system. It is
  known to work on Linux.

  See also : "option srvtcpka", "srvtcpka-idle", "srvtcpka-intvl".

srvtcpka-idle <timeout>
  Sets the time the connection needs to remain idle before TCP starts sending
  keepalive probes, if enabled the sending of TCP keepalive packets on the
  server side.
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    no    |   yes  |   yes
  Arguments :
    <timeout> is the time the connection needs to remain idle before TCP starts
              sending keepalive probes. It is specified in seconds by default,
              but can be in any other unit if the number is suffixed by the
              unit, as explained at the top of this document.

  This keyword corresponds to the socket option TCP_KEEPIDLE. If this keyword
  is not specified, system-wide TCP parameter (tcp_keepalive_time) is used.
  The availability of this setting depends on the operating system. It is
  known to work on Linux.

  See also : "option srvtcpka", "srvtcpka-cnt", "srvtcpka-intvl".

srvtcpka-intvl <timeout>
  Sets the time between individual keepalive probes on the server side.
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    no    |   yes  |   yes
  Arguments :
    <timeout> is the time between individual keepalive probes. It is specified
              in seconds by default, but can be in any other unit if the number
              is suffixed by the unit, as explained at the top of this
              document.

  This keyword corresponds to the socket option TCP_KEEPINTVL. If this keyword
  is not specified, system-wide TCP parameter (tcp_keepalive_intvl) is used.
  The availability of this setting depends on the operating system. It is
  known to work on Linux.

  See also : "option srvtcpka", "srvtcpka-cnt", "srvtcpka-idle".

stats admin { if | unless } <cond>
  Enable statistics admin level if/unless a condition is matched
  May be used in sections :   defaults | frontend | listen | backend
                                 no    |    yes   |   yes  |   yes

  This statement enables the statistics admin level if/unless a condition is
  matched.

  The admin level allows to enable/disable servers from the web interface. By
  default, statistics page is read-only for security reasons.

  Currently, the POST request is limited to the buffer size minus the reserved
  buffer space, which means that if the list of servers is too long, the
  request won't be processed. It is recommended to alter few servers at a
  time.

  Example :
    # statistics admin level only for localhost
    backend stats_localhost
        stats enable
        stats admin if LOCALHOST

  Example :
    # statistics admin level always enabled because of the authentication
    backend stats_auth
        stats enable
        stats auth  admin:AdMiN123
        stats admin if TRUE

  Example :
    # statistics admin level depends on the authenticated user
    userlist stats-auth
        group admin    users admin
        user  admin    insecure-password AdMiN123
        group readonly users haproxy
        user  haproxy  insecure-password haproxy

    backend stats_auth
        stats enable
        acl AUTH       http_auth(stats-auth)
        acl AUTH_ADMIN http_auth_group(stats-auth) admin
        stats http-request auth unless AUTH
        stats admin if AUTH_ADMIN

  See also : "stats enable", "stats auth", "stats http-request", section 3.4
             about userlists and section 7 about ACL usage.

stats auth <user>:
  Enable statistics with authentication and grant access to an account
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    yes   |   yes  |   yes
  Arguments :
    <user>    is a user name to grant access to

      is the cleartext password associated to this user

  This statement enables statistics with default settings, and restricts access
  to declared users only. It may be repeated as many times as necessary to
  allow as many users as desired. When a user tries to access the statistics
  without a valid account, a "401 Forbidden" response will be returned so that
  the browser asks the user to provide a valid user and password. The real
  which will be returned to the browser is configurable using "stats realm".

  Since the authentication method is HTTP Basic Authentication, the passwords
  circulate in cleartext on the network. Thus, it was decided that the
  configuration file would also use cleartext passwords to remind the users
  that those ones should not be sensitive and not shared with any other account.

  It is also possible to reduce the scope of the proxies which appear in the
  report using "stats scope".

  Though this statement alone is enough to enable statistics reporting, it is
  recommended to set all other settings in order to avoid relying on default
  unobvious parameters.

  Example :
    # public access (limited to this backend only)
    backend public_www
        server srv1 192.168.0.1:80
        stats enable
        stats hide-version
        stats scope   .
        stats uri     /admin?stats
        stats realm   HAProxy\ Statistics
        stats auth    admin1:AdMiN123
        stats auth    admin2:AdMiN321

    # internal monitoring access (unlimited)
    backend private_monitoring
        stats enable
        stats uri     /admin?stats
        stats refresh 5s

  See also : "stats enable", "stats realm", "stats scope", "stats uri"

stats enable
  Enable statistics reporting with default settings
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    yes   |   yes  |   yes
  Arguments : none

  This statement enables statistics reporting with default settings defined
  at build time. Unless stated otherwise, these settings are used :
    - stats uri   : /haproxy?stats
    - stats realm : "HAProxy Statistics"
    - stats auth  : no authentication
    - stats scope : no restriction

  Though this statement alone is enough to enable statistics reporting, it is
  recommended to set all other settings in order to avoid relying on default
  unobvious parameters.

  Example :
    # public access (limited to this backend only)
    backend public_www
        server srv1 192.168.0.1:80
        stats enable
        stats hide-version
        stats scope   .
        stats uri     /admin?stats
        stats realm   HAProxy\ Statistics
        stats auth    admin1:AdMiN123
        stats auth    admin2:AdMiN321

    # internal monitoring access (unlimited)
    backend private_monitoring
        stats enable
        stats uri     /admin?stats
        stats refresh 5s

  See also : "stats auth", "stats realm", "stats uri"

stats hide-version
  Enable statistics and hide HAProxy version reporting
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    yes   |   yes  |   yes
  Arguments : none

  By default, the stats page reports some useful status information along with
  the statistics. Among them is HAProxy's version. However, it is generally
  considered dangerous to report precise version to anyone, as it can help them
  target known weaknesses with specific attacks. The "stats hide-version"
  statement removes the version from the statistics report. This is recommended
  for public sites or any site with a weak login/password.

  Though this statement alone is enough to enable statistics reporting, it is
  recommended to set all other settings in order to avoid relying on default
  unobvious parameters.

  Example :
    # public access (limited to this backend only)
    backend public_www
        server srv1 192.168.0.1:80
        stats enable
        stats hide-version
        stats scope   .
        stats uri     /admin?stats
        stats realm   HAProxy\ Statistics
        stats auth    admin1:AdMiN123
        stats auth    admin2:AdMiN321

    # internal monitoring access (unlimited)
    backend private_monitoring
        stats enable
        stats uri     /admin?stats
        stats refresh 5s

  See also : "stats auth", "stats enable", "stats realm", "stats uri"

stats http-request { allow | deny | auth [realm ] }
             [ { if | unless } <condition> ]
  Access control for statistics

  May be used in sections:   defaults | frontend | listen | backend
                                no    |    no    |   yes  |   yes

  As "http-request", these set of options allow to fine control access to
  statistics. Each option may be followed by if/unless and acl.
  First option with matched condition (or option without condition) is final.
  For "deny" a 403 error will be returned, for "allow" normal processing is
  performed, for "auth" a 401/407 error code is returned so the client
  should be asked to enter a username and password.

  There is no fixed limit to the number of http-request statements per
  instance.

  See also : "http-request", section 3.4 about userlists and section 7
             about ACL usage.

stats realm 
  Enable statistics and set authentication realm
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    yes   |   yes  |   yes
  Arguments :
       is the name of the HTTP Basic Authentication realm reported to
              the browser. The browser uses it to display it in the pop-up
              inviting the user to enter a valid username and password.

  The realm is read as a single word, so any spaces in it should be escaped
  using a backslash ('\').

  This statement is useful only in conjunction with "stats auth" since it is
  only related to authentication.

  Though this statement alone is enough to enable statistics reporting, it is
  recommended to set all other settings in order to avoid relying on default
  unobvious parameters.

  Example :
    # public access (limited to this backend only)
    backend public_www
        server srv1 192.168.0.1:80
        stats enable
        stats hide-version
        stats scope   .
        stats uri     /admin?stats
        stats realm   HAProxy\ Statistics
        stats auth    admin1:AdMiN123
        stats auth    admin2:AdMiN321

    # internal monitoring access (unlimited)
    backend private_monitoring
        stats enable
        stats uri     /admin?stats
        stats refresh 5s

  See also : "stats auth", "stats enable", "stats uri"

stats refresh <delay>
  Enable statistics with automatic refresh
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    yes   |   yes  |   yes
  Arguments :
    <delay>   is the suggested refresh delay, specified in seconds, which will
              be returned to the browser consulting the report page. While the
              browser is free to apply any delay, it will generally respect it
              and refresh the page this every seconds. The refresh interval may
              be specified in any other non-default time unit, by suffixing the
              unit after the value, as explained at the top of this document.

    <지연>은 보고서 페이지를 참조하는 브라우저로 반환되는 초 단위로 지정되는 
            제안된 새로 고침 지연입니다.
            브라우저는 지연을 자유롭게 적용할 수 있지만 일반적으로 이를 존중하고 
            매초마다 페이지를 새로고침합니다.
            새로 고침 간격은 이 문서의 상단에 설명된 대로 값 뒤에 단위를 접미사로 추가하여 
            기본이 아닌 다른 시간 단위로 지정할 수 있습니다.

  This statement is useful on monitoring displays with a permanent page
  reporting the load balancer's activity. When set, the HTML report page will
  include a link "refresh"/"stop refresh" so that the user can select whether
  they want automatic refresh of the page or not.
    이 명령문은 로드 밸런서의 활동을 보고하는 영구 페이지가 있는 모니터링 
    디스플레이에 유용합니다.
    설정하면 HTML 보고서 페이지에 "새로 고침"/"새로 고침 중지" 링크가 포함되어 
    사용자가 페이지를 자동으로 새로 고칠지 여부를 선택할 수 있습니다.

  Though this statement alone is enough to enable statistics reporting, it is
  recommended to set all other settings in order to avoid relying on default
  unobvious parameters.
    이 명령문만으로도 통계 보고를 활성화하기에 충분하지만 명확하지 않은 기본 
    매개변수에 의존하지 않도록 다른 모든 설정을 지정하는 것이 좋습니다.

  Example :
    # public access (limited to this backend only)
    backend public_www
        server srv1 192.168.0.1:80
        stats enable
        stats hide-version
        stats scope   .
        stats uri     /admin?stats
        stats realm   HAProxy\ Statistics
        stats auth    admin1:AdMiN123
        stats auth    admin2:AdMiN321

    # internal monitoring access (unlimited)
    backend private_monitoring
        stats enable
        stats uri     /admin?stats
        stats refresh 5s

  See also : "stats auth", "stats enable", "stats realm", "stats uri"

stats scope { <name> | "." }
  Enable statistics and limit access scope
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    yes   |   yes  |   yes
  Arguments :
    <name>    is the name of a listen, frontend or backend section to be
              reported. The special name "." (a single dot) designates the
              section in which the statement appears.

  When this statement is specified, only the sections enumerated with this
  statement will appear in the report. All other ones will be hidden. This
  statement may appear as many times as needed if multiple sections need to be
  reported. Please note that the name checking is performed as simple string
  comparisons, and that it is never checked that a give section name really
  exists.

  Though this statement alone is enough to enable statistics reporting, it is
  recommended to set all other settings in order to avoid relying on default
  unobvious parameters.

  Example :
    # public access (limited to this backend only)
    backend public_www
        server srv1 192.168.0.1:80
        stats enable
        stats hide-version
        stats scope   .
        stats uri     /admin?stats
        stats realm   HAProxy\ Statistics
        stats auth    admin1:AdMiN123
        stats auth    admin2:AdMiN321

    # internal monitoring access (unlimited)
    backend private_monitoring
        stats enable
        stats uri     /admin?stats
        stats refresh 5s

  See also : "stats auth", "stats enable", "stats realm", "stats uri"

stats show-desc [  ]
  Enable reporting of a description on the statistics page.
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    yes   |   yes  |   yes

        is an optional description to be reported. If unspecified, the
              description from global section is automatically used instead.

  This statement is useful for users that offer shared services to their
  customers, where node or description should be different for each customer.

  Though this statement alone is enough to enable statistics reporting, it is
  recommended to set all other settings in order to avoid relying on default
  unobvious parameters. By default description is not shown.

  Example :
    # internal monitoring access (unlimited)
    backend private_monitoring
        stats enable
        stats show-desc Master node for Europe, Asia, Africa
        stats uri       /admin?stats
        stats refresh   5s

  See also: "show-node", "stats enable", "stats uri" and "description" in
            global section.

stats show-legends
  Enable reporting additional information on the statistics page
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    yes   |   yes  |   yes
  Arguments : none

  Enable reporting additional information on the statistics page :
    - cap: capabilities (proxy)
    - mode: one of tcp, http or health (proxy)
    - id: SNMP ID (proxy, socket, server)
    - IP (socket, server)
    - cookie (backend, server)

  Though this statement alone is enough to enable statistics reporting, it is
  recommended to set all other settings in order to avoid relying on default
  unobvious parameters. Default behavior is not to show this information.

  See also: "stats enable", "stats uri".

stats show-modules
  Enable display of extra statistics module on the statistics page
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    yes   |   yes  |   yes
  Arguments : none

  New columns are added at the end of the line containing the extra statistics
  values as a tooltip.

  Though this statement alone is enough to enable statistics reporting, it is
  recommended to set all other settings in order to avoid relying on default
  unobvious parameters. Default behavior is not to show this information.

  See also: "stats enable", "stats uri".

stats show-node [ <name> ]
  Enable reporting of a host name on the statistics page.
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    yes   |   yes  |   yes
  Arguments:
    <name>    is an optional name to be reported. If unspecified, the
              node name from global section is automatically used instead.

  This statement is useful for users that offer shared services to their
  customers, where node or description might be different on a stats page
  provided for each customer. Default behavior is not to show host name.

  Though this statement alone is enough to enable statistics reporting, it is
  recommended to set all other settings in order to avoid relying on default
  unobvious parameters.

  Example:
    # internal monitoring access (unlimited)
    backend private_monitoring
        stats enable
        stats show-node Europe-1
        stats uri       /admin?stats
        stats refresh   5s

  See also: "show-desc", "stats enable", "stats uri", and "node" in global
            section.

stats uri 
  Enable statistics and define the URI prefix to access them
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    yes   |   yes  |   yes
  Arguments :
      is the prefix of any URI which will be redirected to stats. This
              prefix may contain a question mark ('?') to indicate part of a
              query string.

  The statistics URI is intercepted on the relayed traffic, so it appears as a
  page within the normal application. It is strongly advised to ensure that the
  selected URI will never appear in the application, otherwise it will never be
  possible to reach it in the application.

  The default URI compiled in HAProxy is "/haproxy?stats", but this may be
  changed at build time, so it's better to always explicitly specify it here.
  It is generally a good idea to include a question mark in the URI so that
  intermediate proxies refrain from caching the results. Also, since any string
  beginning with the prefix will be accepted as a stats request, the question
  mark helps ensuring that no valid URI will begin with the same words.

  It is sometimes very convenient to use "/" as the URI prefix, and put that
  statement in a "listen" instance of its own. That makes it easy to dedicate
  an address or a port to statistics only.

  Though this statement alone is enough to enable statistics reporting, it is
  recommended to set all other settings in order to avoid relying on default
  unobvious parameters.

  Example :
    # public access (limited to this backend only)
    backend public_www
        server srv1 192.168.0.1:80
        stats enable
        stats hide-version
        stats scope   .
        stats uri     /admin?stats
        stats realm   HAProxy\ Statistics
        stats auth    admin1:AdMiN123
        stats auth    admin2:AdMiN321

    # internal monitoring access (unlimited)
    backend private_monitoring
        stats enable
        stats uri     /admin?stats
        stats refresh 5s

  See also : "stats auth", "stats enable", "stats realm"

stick match <pattern> [table <table>] [{if | unless} <cond>]
  Define a request pattern matching condition to stick a user to a server
  May be used in sections :   defaults | frontend | listen | backend
                                 no    |    no    |   yes  |   yes

  Arguments :
    <pattern>  is a sample expression rule as described in section 7.3. It
               describes what elements of the incoming request or connection
               will be analyzed in the hope to find a matching entry in a
               stickiness table. This rule is mandatory.

    <table>    is an optional stickiness table name. If unspecified, the same
               backend's table is used. A stickiness table is declared using
               the "stick-table" statement.

    <cond>     is an optional matching condition. It makes it possible to match
               on a certain criterion only when other conditions are met (or
               not met). For instance, it could be used to match on a source IP
               address except when a request passes through a known proxy, in
               which case we'd match on a header containing that IP address.

  Some protocols or applications require complex stickiness rules and cannot
  always simply rely on cookies nor hashing. The "stick match" statement
  describes a rule to extract the stickiness criterion from an incoming request
  or connection. See section 7 for a complete list of possible patterns and
  transformation rules.

  The table has to be declared using the "stick-table" statement. It must be of
  a type compatible with the pattern. By default it is the one which is present
  in the same backend. It is possible to share a table with other backends by
  referencing it using the "table" keyword. If another table is referenced,
  the server's ID inside the backends are used. By default, all server IDs
  start at 1 in each backend, so the server ordering is enough. But in case of
  doubt, it is highly recommended to force server IDs using their "id" setting.

  It is possible to restrict the conditions where a "stick match" statement
  will apply, using "if" or "unless" followed by a condition. See section 7 for
  ACL based conditions.

  There is no limit on the number of "stick match" statements. The first that
  applies and matches will cause the request to be directed to the same server
  as was used for the request which created the entry. That way, multiple
  matches can be used as fallbacks.

  The stick rules are checked after the persistence cookies, so they will not
  affect stickiness if a cookie has already been used to select a server. That
  way, it becomes very easy to insert cookies and match on IP addresses in
  order to maintain stickiness between HTTP and HTTPS.

  Example :
    # forward SMTP users to the same server they just used for POP in the
    # last 30 minutes
    backend pop
        mode tcp
        balance roundrobin
        stick store-request src
        stick-table type ip size 200k expire 30m
        server s1 192.168.1.1:110
        server s2 192.168.1.1:110

    backend smtp
        mode tcp
        balance roundrobin
        stick match src table pop
        server s1 192.168.1.1:25
        server s2 192.168.1.1:25

  See also : "stick-table", "stick on", and section 7 about ACLs and samples
             fetching.

stick on <pattern> [table <table>] [{if | unless} <condition>]
  Define a request pattern to associate a user to a server
  May be used in sections :   defaults | frontend | listen | backend
                                 no    |    no    |   yes  |   yes

  Note : This form is exactly equivalent to "stick match" followed by
         "stick store-request", all with the same arguments. Please refer
         to both keywords for details. It is only provided as a convenience
         for writing more maintainable configurations.

  Examples :
    # The following form ...
    stick on src table pop if !localhost

    # ...is strictly equivalent to this one :
    stick match src table pop if !localhost
    stick store-request src table pop if !localhost


    # Use cookie persistence for HTTP, and stick on source address for HTTPS as
    # well as HTTP without cookie. Share the same table between both accesses.
    backend http
        mode http
        balance roundrobin
        stick on src table https
        cookie SRV insert indirect nocache
        server s1 192.168.1.1:80 cookie s1
        server s2 192.168.1.1:80 cookie s2

    backend https
        mode tcp
        balance roundrobin
        stick-table type ip size 200k expire 30m
        stick on src
        server s1 192.168.1.1:443
        server s2 192.168.1.1:443

  See also : "stick match", "stick store-request".

stick store-request <pattern> [table <table>] [{if | unless} <condition>]
  Define a request pattern used to create an entry in a stickiness table
  May be used in sections :   defaults | frontend | listen | backend
                                 no    |    no    |   yes  |   yes

  Arguments :
    <pattern>  is a sample expression rule as described in section 7.3. It
               describes what elements of the incoming request or connection
               will be analyzed, extracted and stored in the table once a
               server is selected.

    <table>    is an optional stickiness table name. If unspecified, the same
               backend's table is used. A stickiness table is declared using
               the "stick-table" statement.

    <cond>     is an optional storage condition. It makes it possible to store
               certain criteria only when some conditions are met (or not met).
               For instance, it could be used to store the source IP address
               except when the request passes through a known proxy, in which
               case we'd store a converted form of a header containing that IP
               address.

  Some protocols or applications require complex stickiness rules and cannot
  always simply rely on cookies nor hashing. The "stick store-request" statement
  describes a rule to decide what to extract from the request and when to do
  it, in order to store it into a stickiness table for further requests to
  match it using the "stick match" statement. Obviously the extracted part must
  make sense and have a chance to be matched in a further request. Storing a
  client's IP address for instance often makes sense. Storing an ID found in a
  URL parameter also makes sense. Storing a source port will almost never make
  any sense because it will be randomly matched. See section 7 for a complete
  list of possible patterns and transformation rules.

  The table has to be declared using the "stick-table" statement. It must be of
  a type compatible with the pattern. By default it is the one which is present
  in the same backend. It is possible to share a table with other backends by
  referencing it using the "table" keyword. If another table is referenced,
  the server's ID inside the backends are used. By default, all server IDs
  start at 1 in each backend, so the server ordering is enough. But in case of
  doubt, it is highly recommended to force server IDs using their "id" setting.

  It is possible to restrict the conditions where a "stick store-request"
  statement will apply, using "if" or "unless" followed by a condition. This
  condition will be evaluated while parsing the request, so any criteria can be
  used. See section 7 for ACL based conditions.

  There is no limit on the number of "stick store-request" statements, but
  there is a limit of 8 simultaneous stores per request or response. This
  makes it possible to store up to 8 criteria, all extracted from either the
  request or the response, regardless of the number of rules. Only the 8 first
  ones which match will be kept. Using this, it is possible to feed multiple
  tables at once in the hope to increase the chance to recognize a user on
  another protocol or access method. Using multiple store-request rules with
  the same table is possible and may be used to find the best criterion to rely
  on, by arranging the rules by decreasing preference order. Only the first
  extracted criterion for a given table will be stored. All subsequent store-
  request rules referencing the same table will be skipped and their ACLs will
  not be evaluated.

  The "store-request" rules are evaluated once the server connection has been
  established, so that the table will contain the real server that processed
  the request.

  Example :
    # forward SMTP users to the same server they just used for POP in the
    # last 30 minutes
    backend pop
        mode tcp
        balance roundrobin
        stick store-request src
        stick-table type ip size 200k expire 30m
        server s1 192.168.1.1:110
        server s2 192.168.1.1:110

    backend smtp
        mode tcp
        balance roundrobin
        stick match src table pop
        server s1 192.168.1.1:25
        server s2 192.168.1.1:25

  See also : "stick-table", "stick on", about ACLs and sample fetching.

stick-table type {ip | integer | string [len <length>] | binary [len <length>]}
            size <size> [expire <expire>] [nopurge] [peers <peersect>] [srvkey <srvkey>]
            [store <data_type>]*
  Configure the stickiness table for the current section
  May be used in sections :   defaults | frontend | listen | backend
                                 no    |    yes   |   yes  |   yes

  Arguments :
    ip         a table declared with "type ip" will only store IPv4 addresses.
               This form is very compact (about 50 bytes per entry) and allows
               very fast entry lookup and stores with almost no overhead. This
               is mainly used to store client source IP addresses.

    ipv6       a table declared with "type ipv6" will only store IPv6 addresses.
               This form is very compact (about 60 bytes per entry) and allows
               very fast entry lookup and stores with almost no overhead. This
               is mainly used to store client source IP addresses.

    integer    a table declared with "type integer" will store 32bit integers
               which can represent a client identifier found in a request for
               instance.

    string     a table declared with "type string" will store substrings of up
               to  characters. If the string provided by the pattern
               extractor is larger than , it will be truncated before
               being stored. During matching, at most  characters will be
               compared between the string in the table and the extracted
               pattern. When not specified, the string is automatically limited
               to 32 characters.

    binary     a table declared with "type binary" will store binary blocks
               of  bytes. If the block provided by the pattern
               extractor is larger than , it will be truncated before
               being stored. If the block provided by the sample expression
               is shorter than , it will be padded by 0. When not
               specified, the block is automatically limited to 32 bytes.

    <length>   is the maximum number of characters that will be stored in a
               "string" type table (See type "string" above). Or the number
               of bytes of the block in "binary" type table. Be careful when
               changing this parameter as memory usage will proportionally
               increase.

    <size>     is the maximum number of entries that can fit in the table. This
               value directly impacts memory usage. Count approximately
               50 bytes per entry, plus the size of a string if any. The size
               supports suffixes "k", "m", "g" for 2^10, 2^20 and 2^30 factors.

    [nopurge]  indicates that we refuse to purge older entries when the table
               is full. When not specified and the table is full when HAProxy
               wants to store an entry in it, it will flush a few of the oldest
               entries in order to release some space for the new ones. This is
               most often the desired behavior. In some specific cases, it
               be desirable to refuse new entries instead of purging the older
               ones. That may be the case when the amount of data to store is
               far above the hardware limits and we prefer not to offer access
               to new clients than to reject the ones already connected. When
               using this parameter, be sure to properly set the "expire"
               parameter (see below).

    <peersect> is the name of the peers section to use for replication. Entries
               which associate keys to server IDs are kept synchronized with
               the remote peers declared in this section. All entries are also
               automatically learned from the local peer (old process) during a
               soft restart.

    <expire>   defines the maximum duration of an entry in the table since it
               was last created, refreshed using 'track-sc' or matched using
               'stick match' or 'stick on' rule. The expiration delay is
               defined using the standard time format, similarly as the various
               timeouts. The maximum duration is slightly above 24 days. See
               section 2.5 for more information. If this delay is not specified,
               the session won't automatically expire, but older entries will
               be removed once full. Be sure not to use the "nopurge" parameter
               if not expiration delay is specified.
               Note: 'table_*' converters performs lookups but won't update touch
               expire since they don't require 'track-sc'.

    <srvkey>   specifies how each server is identified for the purposes of the
               stick table. The valid values are "name" and "addr". If "name" is
               given, then <name> argument for the server (may be generated by
               a template). If "addr" is given, then the server is identified
               by its current network address, including the port. "addr" is
               especially useful if you are using service discovery to generate
               the addresses for servers with peered stick-tables and want
               to consistently use the same host across peers for a stickiness
               token.

   <data_type> is used to store additional information in the stick-table. This
               may be used by ACLs in order to control various criteria related
               to the activity of the client matching the stick-table. For each
               item specified here, the size of each entry will be inflated so
               that the additional data can fit. Several data types may be
               stored with an entry. Multiple data types may be specified after
               the "store" keyword, as a comma-separated list. Alternatively,
               it is possible to repeat the "store" keyword followed by one or
               several data types. Except for the "server_id" type which is
               automatically detected and enabled, all data types must be
               explicitly declared to be stored. If an ACL references a data
               type which is not stored, the ACL will simply not match. Some
               data types require an argument which must be passed just after
               the type between parenthesis. See below for the supported data
               types and their arguments.

  The data types that can be stored with an entry are the following :
    - server_id : this is an integer which holds the numeric ID of the server a
      request was assigned to. It is used by the "stick match", "stick store",
      and "stick on" rules. It is automatically enabled when referenced.

    - gpc() : General Purpose Counters Array of  elements. This is an
      array of positive 32-bit integers which may be used to count anything.
      Most of the time they will be used as a incremental counters on some
      entries, for instance to note that a limit is reached and trigger some
      actions. This array is limited to a maximum of 100 elements:
      gpc0 to gpc99, to ensure that the build of a peer update
      message can fit into the buffer. Users should take in consideration
      that a large amount of counters will increase the data size and the
      traffic load using peers protocol since all data/counters are pushed
      each time any of them is updated.
      This data_type will exclude the usage of the legacy data_types 'gpc0'
      and 'gpc1' on the same table. Using the 'gpc' array data_type, all 'gpc0'
      and 'gpc1' related fetches and actions will apply to the two first
      elements of this array.

    - gpc_rate(,) : Array of increment rates of General Purpose
      Counters over a period. Those elements are positive 32-bit integers which
      may be used for anything. Just like , the count events, but instead
      of keeping a cumulative number, they maintain the rate at which the
      counter is incremented. Most of the time it will be used to measure the
      frequency of occurrence of certain events (e.g. requests to a specific
      URL). This array is limited to a maximum of 100 elements: gpt(100)
      allowing the storage of gpc0 to gpc99, to ensure that the build of a peer
      update message can fit into the buffer.
      The array cannot contain less than 1 element: use gpc(1) if you want to
      store only the counter gpc0.
      Users should take in consideration that a large amount of
      counters will increase the data size and the traffic load using peers
      protocol since all data/counters are pushed each time any of them is
      updated.
      This data_type will exclude the usage of the legacy data_types
      'gpc0_rate' and 'gpc1_rate' on the same table. Using the 'gpc_rate'
      array data_type, all 'gpc0' and 'gpc1' related fetches and actions
      will apply to the two first elements of this array.

    - gpc0 : first General Purpose Counter. It is a positive 32-bit integer
      integer which may be used for anything. Most of the time it will be used
      to put a special tag on some entries, for instance to note that a
      specific behavior was detected and must be known for future matches.

    - gpc0_rate() : increment rate of the first General Purpose Counter
      over a period. It is a positive 32-bit integer integer which may be used
      for anything. Just like , it counts events, but instead of keeping
      a cumulative number, it maintains the rate at which the counter is
      incremented. Most of the time it will be used to measure the frequency of
      occurrence of certain events (e.g. requests to a specific URL).

    - gpc1 : second General Purpose Counter. It is a positive 32-bit integer
      integer which may be used for anything. Most of the time it will be used
      to put a special tag on some entries, for instance to note that a
      specific behavior was detected and must be known for future matches.

    - gpc1_rate() : increment rate of the second General Purpose Counter
      over a period. It is a positive 32-bit integer integer which may be used
      for anything. Just like , it counts events, but instead of keeping
      a cumulative number, it maintains the rate at which the counter is
      incremented. Most of the time it will be used to measure the frequency of
      occurrence of certain events (e.g. requests to a specific URL).

    - gpt() : General Purpose Tags Array of  elements. This is an array
      of positive 32-bit integers which may be used for anything.
      Most of the time they will be used to put a special tags on some entries,
      for instance to note that a specific behavior was detected and must be
      known for future matches. This array is limited to a maximum of 100
      elements: gpt(100) allowing the storage of gpt0 to gpt99, to ensure that
      the build of a peer update message can fit into the buffer.
      The array cannot contain less than 1 element: use gpt(1) if you want to
      to store only the tag gpt0.
      Users should take in consideration that a large amount of counters will
      increase the data size and the traffic load using peers protocol since
      all data/counters are pushed each time any of them is updated.
      This data_type will exclude the usage of the legacy data_type 'gpt0'
      on the same table. Using the 'gpt' array data_type, all 'gpt0' related
      fetches and actions will apply to the first element of this array.

    - gpt0 : first General Purpose Tag. It is a positive 32-bit integer
      integer which may be used for anything. Most of the time it will be used
      to put a special tag on some entries, for instance to note that a
      specific behavior was detected and must be known for future matches

    - conn_cnt : Connection Count. It is a positive 32-bit integer which counts
      the absolute number of connections received from clients which matched
      this entry. It does not mean the connections were accepted, just that
      they were received.

    - conn_cur : Current Connections. It is a positive 32-bit integer which
      stores the concurrent connection counts for the entry. It is incremented
      once an incoming connection matches the entry, and decremented once the
      connection leaves. That way it is possible to know at any time the exact
      number of concurrent connections for an entry.

    - conn_rate() : frequency counter (takes 12 bytes). It takes an
      integer parameter  which indicates in milliseconds the length
      of the period over which the average is measured. It reports the average
      incoming connection rate over that period, in connections per period. The
      result is an integer which can be matched using ACLs.

    - sess_cnt : Session Count. It is a positive 32-bit integer which counts
      the absolute number of sessions received from clients which matched this
      entry. A session is a connection that was accepted by the layer 4 rules.

    - sess_rate() : frequency counter (takes 12 bytes). It takes an
      integer parameter  which indicates in milliseconds the length
      of the period over which the average is measured. It reports the average
      incoming session rate over that period, in sessions per period. The
      result is an integer which can be matched using ACLs.

    - http_req_cnt : HTTP request Count. It is a positive 32-bit integer which
      counts the absolute number of HTTP requests received from clients which
      matched this entry. It does not matter whether they are valid requests or
      not. Note that this is different from sessions when keep-alive is used on
      the client side.

    - http_req_rate() : frequency counter (takes 12 bytes). It takes an
      integer parameter  which indicates in milliseconds the length
      of the period over which the average is measured. It reports the average
      HTTP request rate over that period, in requests per period. The result is
      an integer which can be matched using ACLs. It does not matter whether
      they are valid requests or not. Note that this is different from sessions
      when keep-alive is used on the client side.

    - http_err_cnt : HTTP Error Count. It is a positive 32-bit integer which
      counts the absolute number of HTTP requests errors induced by clients
      which matched this entry. Errors are counted on invalid and truncated
      requests, as well as on denied or tarpitted requests, and on failed
      authentications. If the server responds with 4xx, then the request is
      also counted as an error since it's an error triggered by the client
      (e.g. vulnerability scan).

    - http_err_rate() : frequency counter (takes 12 bytes). It takes an
      integer parameter  which indicates in milliseconds the length
      of the period over which the average is measured. It reports the average
      HTTP request error rate over that period, in requests per period (see
      http_err_cnt above for what is accounted as an error). The result is an
      integer which can be matched using ACLs.

    - http_fail_cnt : HTTP Failure Count. It is a positive 32-bit integer which
      counts the absolute number of HTTP response failures induced by servers
      which matched this entry. Errors are counted on invalid and truncated
      responses, as well as any 5xx response other than 501 or 505. It aims at
      being used combined with path or URI to detect service failures.

    - http_fail_rate() : frequency counter (takes 12 bytes). It takes
      an integer parameter  which indicates in milliseconds the length
      of the period over which the average is measured. It reports the average
      HTTP response failure rate over that period, in requests per period (see
      http_fail_cnt above for what is accounted as a failure). The result is an
      integer which can be matched using ACLs.

    - bytes_in_cnt : client to server byte count. It is a positive 64-bit
      integer which counts the cumulative number of bytes received from clients
      which matched this entry. Headers are included in the count. This may be
      used to limit abuse of upload features on photo or video servers.

    - bytes_in_rate() : frequency counter (takes 12 bytes). It takes an
      integer parameter  which indicates in milliseconds the length
      of the period over which the average is measured. It reports the average
      incoming bytes rate over that period, in bytes per period. It may be used
      to detect users which upload too much and too fast. Warning: with large
      uploads, it is possible that the amount of uploaded data will be counted
      once upon termination, thus causing spikes in the average transfer speed
      instead of having a smooth one. This may partially be smoothed with
      "option contstats" though this is not perfect yet. Use of byte_in_cnt is
      recommended for better fairness.

    - bytes_out_cnt : server to client byte count. It is a positive 64-bit
      integer which counts the cumulative number of bytes sent to clients which
      matched this entry. Headers are included in the count. This may be used
      to limit abuse of bots sucking the whole site.

    - bytes_out_rate() : frequency counter (takes 12 bytes). It takes
      an integer parameter  which indicates in milliseconds the length
      of the period over which the average is measured. It reports the average
      outgoing bytes rate over that period, in bytes per period. It may be used
      to detect users which download too much and too fast. Warning: with large
      transfers, it is possible that the amount of transferred data will be
      counted once upon termination, thus causing spikes in the average
      transfer speed instead of having a smooth one. This may partially be
      smoothed with "option contstats" though this is not perfect yet. Use of
      byte_out_cnt is recommended for better fairness.

  There is only one stick-table per proxy. At the moment of writing this doc,
  it does not seem useful to have multiple tables per proxy. If this happens
  to be required, simply create a dummy backend with a stick-table in it and
  reference it.

  It is important to understand that stickiness based on learning information
  has some limitations, including the fact that all learned associations are
  lost upon restart unless peers are properly configured to transfer such
  information upon restart (recommended). In general it can be good as a
  complement but not always as an exclusive stickiness.

  Last, memory requirements may be important when storing many data types.
  Indeed, storing all indicators above at once in each entry requires 116 bytes
  per entry, or 116 MB for a 1-million entries table. This is definitely not
  something that can be ignored.

  Example:
        # Keep track of counters of up to 1 million IP addresses over 5 minutes
        # and store a general purpose counter and the average connection rate
        # computed over a sliding window of 30 seconds.
        stick-table type ip size 1m expire 5m store gpc0,conn_rate(30s)

  See also : "stick match", "stick on", "stick store-request", section 2.5
             about time format and section 7 about ACLs.

stick store-response <pattern> [table <table>] [{if | unless} <condition>]
  Define a response pattern used to create an entry in a stickiness table
  May be used in sections :   defaults | frontend | listen | backend
                                 no    |    no    |   yes  |   yes

  Arguments :
    <pattern>  is a sample expression rule as described in section 7.3. It
               describes what elements of the response or connection will
               be analyzed, extracted and stored in the table once a
               server is selected.

    <table>    is an optional stickiness table name. If unspecified, the same
               backend's table is used. A stickiness table is declared using
               the "stick-table" statement.

    <cond>     is an optional storage condition. It makes it possible to store
               certain criteria only when some conditions are met (or not met).
               For instance, it could be used to store the SSL session ID only
               when the response is a SSL server hello.

  Some protocols or applications require complex stickiness rules and cannot
  always simply rely on cookies nor hashing. The "stick store-response"
  statement  describes a rule to decide what to extract from the response and
  when to do it, in order to store it into a stickiness table for further
  requests to match it using the "stick match" statement. Obviously the
  extracted part must make sense and have a chance to be matched in a further
  request. Storing an ID found in a header of a response makes sense.
  See section 7 for a complete list of possible patterns and transformation
  rules.

  The table has to be declared using the "stick-table" statement. It must be of
  a type compatible with the pattern. By default it is the one which is present
  in the same backend. It is possible to share a table with other backends by
  referencing it using the "table" keyword. If another table is referenced,
  the server's ID inside the backends are used. By default, all server IDs
  start at 1 in each backend, so the server ordering is enough. But in case of
  doubt, it is highly recommended to force server IDs using their "id" setting.

  It is possible to restrict the conditions where a "stick store-response"
  statement will apply, using "if" or "unless" followed by a condition. This
  condition will be evaluated while parsing the response, so any criteria can
  be used. See section 7 for ACL based conditions.

  There is no limit on the number of "stick store-response" statements, but
  there is a limit of 8 simultaneous stores per request or response. This
  makes it possible to store up to 8 criteria, all extracted from either the
  request or the response, regardless of the number of rules. Only the 8 first
  ones which match will be kept. Using this, it is possible to feed multiple
  tables at once in the hope to increase the chance to recognize a user on
  another protocol or access method. Using multiple store-response rules with
  the same table is possible and may be used to find the best criterion to rely
  on, by arranging the rules by decreasing preference order. Only the first
  extracted criterion for a given table will be stored. All subsequent store-
  response rules referencing the same table will be skipped and their ACLs will
  not be evaluated. However, even if a store-request rule references a table, a
  store-response rule may also use the same table. This means that each table
  may learn exactly one element from the request and one element from the
  response at once.

  The table will contain the real server that processed the request.

  Example :
    # Learn SSL session ID from both request and response and create affinity.
    backend https
        mode tcp
        balance roundrobin
        # maximum SSL session ID length is 32 bytes.
        stick-table type binary len 32 size 30k expire 30m

        acl clienthello req.ssl_hello_type 1
        acl serverhello rep.ssl_hello_type 2

        # use tcp content accepts to detects ssl client and server hello.
        tcp-request inspect-delay 5s
        tcp-request content accept if clienthello

        # no timeout on response inspect delay by default.
        tcp-response content accept if serverhello

        # SSL session ID (SSLID) may be present on a client or server hello.
        # Its length is coded on 1 byte at offset 43 and its value starts
        # at offset 44.

        # Match and learn on request if client hello.
        stick on req.payload_lv(43,1) if clienthello

        # Learn on response if server hello.
        stick store-response resp.payload_lv(43,1) if serverhello

        server s1 192.168.1.1:443
        server s2 192.168.1.1:443

  See also : "stick-table", "stick on", and section 7 about ACLs and pattern
             extraction.

tcp-check comment <string>
  Defines a comment for the following the tcp-check rule, reported in logs if
  it fails.
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    no    |   yes  |   yes

  Arguments :
    <string>  is the comment message to add in logs if the following tcp-check
              rule fails.

  It only works for connect, send and expect rules. It is useful to make
  user-friendly error reporting.

  See also : "option tcp-check", "tcp-check connect", "tcp-check send" and
             "tcp-check expect".


tcp-check connect [default] [port <expr>] [addr <ip>] [send-proxy] [via-socks4]
                  [ssl] [sni <sni>] [alpn <alpn>] [linger]
                  [proto <name>] [comment <msg>]
  Opens a new connection
  May be used in sections:   defaults | frontend | listen | backend
                               yes    |    no    |   yes  |   yes

  Arguments :
    comment <msg>  defines a message to report if the rule evaluation fails.

    default      Use default options of the server line to do the health
                 checks. The server options are used only if not redefined.

    port <expr>  if not set, check port or server port is used.
                 It tells HAProxy where to open the connection to.
                 <port> must be a valid TCP port source integer, from 1 to
                 65535 or an sample-fetch expression.

    addr <ip>    defines the IP address to do the health check.

    send-proxy   send a PROXY protocol string

    via-socks4   enables outgoing health checks using upstream socks4 proxy.

    ssl          opens a ciphered connection

    sni <sni>    specifies the SNI to use to do health checks over SSL.

    alpn <alpn>  defines which protocols to advertise with ALPN. The protocol
                 list consists in a comma-delimited list of protocol names,
                 for instance: "http/1.1,http/1.0" (without quotes).
                 If it is not set, the server ALPN is used.

    proto <name> forces the multiplexer's protocol to use for this connection.
                 It must be a TCP mux protocol and it must be usable on the
                 backend side. The list of available protocols is reported in
                 haproxy -vv.

    linger       cleanly close the connection instead of using a single RST.

  When an application lies on more than a single TCP port or when HAProxy
  load-balance many services in a single backend, it makes sense to probe all
  the services individually before considering a server as operational.

  When there are no TCP port configured on the server line neither server port
  directive, then the 'tcp-check connect port <port>' must be the first step
  of the sequence.

  In a tcp-check ruleset a 'connect' is required, it is also mandatory to start
  the ruleset with a 'connect' rule. Purpose is to ensure admin know what they
  do.

  When a connect must start the ruleset, if may still be preceded by set-var,
  unset-var or comment rules.

  Examples :
         # check HTTP and HTTPs services on a server.
         # first open port 80 thanks to server line port directive, then
         # tcp-check opens port 443, ciphered and run a request on it:
         option tcp-check
         tcp-check connect
         tcp-check send GET\ /\ HTTP/1.0\r\n
         tcp-check send Host:\ haproxy.1wt.eu\r\n
         tcp-check send \r\n
         tcp-check expect rstring (2..|3..)
         tcp-check connect port 443 ssl
         tcp-check send GET\ /\ HTTP/1.0\r\n
         tcp-check send Host:\ haproxy.1wt.eu\r\n
         tcp-check send \r\n
         tcp-check expect rstring (2..|3..)
         server www 10.0.0.1 check port 80

         # check both POP and IMAP from a single server:
         option tcp-check
         tcp-check connect port 110 linger
         tcp-check expect string +OK\ POP3\ ready
         tcp-check connect port 143
         tcp-check expect string *\ OK\ IMAP4\ ready
         server mail 10.0.0.1 check

  See also : "option tcp-check", "tcp-check send", "tcp-check expect"

tcp-check expect [min-recv <int>] [comment <msg>]
                 [ok-status <st>] [error-status <st>] [tout-status <st>]
                 [on-success <fmt>] [on-error <fmt>] [status-code <expr>]
                 [!] <match> <pattern>
  Specify data to be collected and analyzed during a generic health check
  May be used in sections:   defaults | frontend | listen | backend
                               yes    |    no    |   yes  |   yes

  Arguments :
    comment <msg>  defines a message to report if the rule evaluation fails.

    min-recv  is optional and can define the minimum amount of data required to
              evaluate the current expect rule. If the number of received bytes
              is under this limit, the check will wait for more data. This
              option can be used to resolve some ambiguous matching rules or to
              avoid executing costly regex matches on content known to be still
              incomplete. If an exact string (string or binary) is used, the
              minimum between the string length and this parameter is used.
              This parameter is ignored if it is set to -1. If the expect rule
              does not match, the check will wait for more data. If set to 0,
              the evaluation result is always conclusive.

    <match>   is a keyword indicating how to look for a specific pattern in the
              response. The keyword may be one of "string", "rstring", "binary" or
              "rbinary".
              The keyword may be preceded by an exclamation mark ("!") to negate
              the match. Spaces are allowed between the exclamation mark and the
              keyword. See below for more details on the supported keywords.

    ok-status <st>     is optional and can be used to set the check status if
                       the expect rule is successfully evaluated and if it is
                       the last rule in the tcp-check ruleset. "L7OK", "L7OKC",
                       "L6OK" and "L4OK" are supported :
                         - L7OK  : check passed on layer 7
                         - L7OKC : check conditionally passed on layer 7, set
                                   server to NOLB state.
                         - L6OK  : check passed on layer 6
                         - L4OK  : check passed on layer 4
                        By default "L7OK" is used.

    error-status <st>  is optional and can be used to set the check status if
                       an error occurred during the expect rule evaluation.
                       "L7OKC", "L7RSP", "L7STS", "L6RSP" and "L4CON" are
                       supported :
                         - L7OKC : check conditionally passed on layer 7, set
                                   server to NOLB state.
                         - L7RSP : layer 7 invalid response - protocol error
                         - L7STS : layer 7 response error, for example HTTP 5xx
                         - L6RSP : layer 6 invalid response - protocol error
                         - L4CON : layer 1-4 connection problem
                       By default "L7RSP" is used.

    tout-status <st>   is optional and can be used to set the check status if
                       a timeout occurred during the expect rule evaluation.
                       "L7TOUT", "L6TOUT", and "L4TOUT" are supported :
                         - L7TOUT : layer 7 (HTTP/SMTP) timeout
                         - L6TOUT : layer 6 (SSL) timeout
                         - L4TOUT : layer 1-4 timeout
                       By default "L7TOUT" is used.

    on-success <fmt>   is optional and can be used to customize the
                       informational message reported in logs if the expect
                       rule is successfully evaluated and if it is the last rule
                       in the tcp-check ruleset. <fmt> is a log-format string.

    on-error <fmt>     is optional and can be used to customize the
                       informational message reported in logs if an error
                       occurred during the expect rule evaluation. <fmt> is a
                       log-format string.

    status-code <expr> is optional and can be used to set the check status code
                       reported in logs, on success or on error. <expr> is a
                       standard HAProxy expression formed by a sample-fetch
                       followed by some converters.

    <pattern> is the pattern to look for. It may be a string or a regular
              expression. If the pattern contains spaces, they must be escaped
              with the usual backslash ('\').
              If the match is set to binary, then the pattern must be passed as
              a series of hexadecimal digits in an even number. Each sequence of
              two digits will represent a byte. The hexadecimal digits may be
              used upper or lower case.

  The available matches are intentionally similar to their http-check cousins :

    string <string> : test the exact string matches in the response buffer.
                      A health check response will be considered valid if the
                      response's buffer contains this exact string. If the
                      "string" keyword is prefixed with "!", then the response
                      will be considered invalid if the body contains this
                      string. This can be used to look for a mandatory pattern
                      in a protocol response, or to detect a failure when a
                      specific error appears in a protocol banner.

    rstring <regex> : test a regular expression on the response buffer.
                      A health check response will be considered valid if the
                      response's buffer matches this expression. If the
                      "rstring" keyword is prefixed with "!", then the response
                      will be considered invalid if the body matches the
                      expression.

    string-lf <fmt> : test a log-format string match in the response's buffer.
                      A health check response will be considered valid if the
                      response's buffer contains the  string resulting of the
                      evaluation of <fmt>, which follows the log-format rules.
                      If prefixed with "!", then the response will be
                      considered invalid if the buffer contains the string.

    binary  : test the exact string in its hexadecimal form matches
                         in the response buffer. A health check response will
                         be considered valid if the response's buffer contains
                         this exact hexadecimal string.
                         Purpose is to match data on binary protocols.

    rbinary <regex> : test a regular expression on the response buffer, like
                      "rstring". However, the response buffer is transformed
                      into its hexadecimal form, including NUL-bytes. This
                      allows using all regex engines to match any binary
                      content.  The hexadecimal transformation takes twice the
                      size of the original response. As such, the expected
                      pattern should work on at-most half the response buffer
                      size.

    binary-lf  : test a log-format string in its hexadecimal form
                         match in the response's buffer. A health check response
                         will be considered valid if the response's buffer
                         contains the hexadecimal string resulting of the
                         evaluation of <fmt>, which follows the log-format
                         rules. If prefixed with "!", then the response will be
                         considered invalid if the buffer contains the
                         hexadecimal string. The hexadecimal string is converted
                         in a binary string before matching the response's
                         buffer.

  It is important to note that the responses will be limited to a certain size
  defined by the global "tune.bufsize" option, which defaults to 16384 bytes.
  Thus, too large responses may not contain the mandatory pattern when using
  "string", "rstring" or binary. If a large response is absolutely required, it
  is possible to change the default max size by setting the global variable.
  However, it is worth keeping in mind that parsing very large responses can
  waste some CPU cycles, especially when regular expressions are used, and that
  it is always better to focus the checks on smaller resources. Also, in its
  current state, the check will not find any string nor regex past a null
  character in the response. Similarly it is not possible to request matching
  the null character.

  Examples :
         # perform a POP check
         option tcp-check
         tcp-check expect string +OK\ POP3\ ready

         # perform an IMAP check
         option tcp-check
         tcp-check expect string *\ OK\ IMAP4\ ready

         # look for the redis master server
         option tcp-check
         tcp-check send PING\r\n
         tcp-check expect string +PONG
         tcp-check send info\ replication\r\n
         tcp-check expect string role:master
         tcp-check send QUIT\r\n
         tcp-check expect string +OK


  See also : "option tcp-check", "tcp-check connect", "tcp-check send",
             "tcp-check send-binary", "http-check expect", tune.bufsize

tcp-check send <data> [comment <msg>]
tcp-check send-lf <fmt> [comment <msg>]
  Specify a string or a log-format string to be sent as a question during a
  generic health check
  May be used in sections:   defaults | frontend | listen | backend
                               yes    |    no    |   yes  |   yes

  Arguments :
    comment <msg>  defines a message to report if the rule evaluation fails.

    <data>         is the string that will be sent during a generic health
                   check session.

    <fmt>          is the log-format string that will be sent, once evaluated,
                   during a generic health check session.

  Examples :
         # look for the redis master server
         option tcp-check
         tcp-check send info\ replication\r\n
         tcp-check expect string role:master

  See also : "option tcp-check", "tcp-check connect", "tcp-check expect",
             "tcp-check send-binary", tune.bufsize

tcp-check send-binary  [comment <msg>]
tcp-check send-binary-lf  [comment <msg>]
  Specify an hex digits string or an hex digits log-format string to be sent as
  a binary question during a raw tcp health check
  May be used in sections:   defaults | frontend | listen | backend
                               yes    |    no    |   yes  |   yes

  Arguments :
    comment <msg>  defines a message to report if the rule evaluation fails.

        is the hexadecimal string that will be send, once converted
                   to binary, during a generic health check session.

           is the hexadecimal log-format string that will be send, once
                   evaluated and converted to binary, during a generic health
                   check session.

  Examples :
         # redis check in binary
         option tcp-check
         tcp-check send-binary 50494e470d0a # PING\r\n
         tcp-check expect binary 2b504F4e47 # +PONG


  See also : "option tcp-check", "tcp-check connect", "tcp-check expect",
             "tcp-check send", tune.bufsize

tcp-check set-var(<var-name>[,<cond> ...]) <expr>
tcp-check set-var-fmt(<var-name>[,<cond> ...]) <fmt>
  This operation sets the content of a variable. The variable is declared inline.
  May be used in sections:   defaults | frontend | listen | backend
                               yes    |    no    |   yes  |   yes

  Arguments :
    <var-name>  The name of the variable starts with an indication about its
                scope. The scopes allowed for tcp-check are:
                  "proc" : the variable is shared with the whole process.
                  "sess" : the variable is shared with the tcp-check session.
                  "check": the variable is declared for the lifetime of the tcp-check.
                This prefix is followed by a name. The separator is a '.'.
                The name may only contain characters 'a-z', 'A-Z', '0-9', '.',
                and '-'.

    <cond>      A set of conditions that must all be true for the variable to
                actually be set (such as "ifnotempty", "ifgt" ...). See the
                set-var converter's description for a full list of possible
                conditions.

    <expr>      Is a sample-fetch expression potentially followed by converters.

    <fmt>       This is the value expressed using log-format rules (see Custom
                Log Format in section 8.2.4).

  Examples :
    tcp-check set-var(check.port) int(1234)
    tcp-check set-var-fmt(check.name) "%H"

tcp-check unset-var(<var-name>)
  Free a reference to a variable within its scope.
  May be used in sections:   defaults | frontend | listen | backend
                               yes    |    no    |   yes  |   yes

  Arguments :
    <var-name>  The name of the variable starts with an indication about its
                scope. The scopes allowed for tcp-check are:
                  "proc" : the variable is shared with the whole process.
                  "sess" : the variable is shared with the tcp-check session.
                  "check": the variable is declared for the lifetime of the tcp-check.
                This prefix is followed by a name. The separator is a '.'.
                The name may only contain characters 'a-z', 'A-Z', '0-9', '.',
                and '-'.

  Examples :
    tcp-check unset-var(check.port)

tcp-request connection <action> <options...> [ { if | unless } <condition> ]
  Perform an action on an incoming connection depending on a layer 4 condition
  May be used in sections :   defaults | frontend | listen | backend
                                yes(!) |    yes   |   yes  |   no
  Arguments :
    <action>    defines the action to perform if the condition applies. See
                below.

    <condition> is a standard layer4-only ACL-based condition (see section 7).

  Immediately after acceptance of a new incoming connection, it is possible to
  evaluate some conditions to decide whether this connection must be accepted
  or dropped or have its counters tracked. Those conditions cannot make use of
  any data contents because the connection has not been read from yet, and the
  buffers are not yet allocated. This is used to selectively and very quickly
  accept or drop connections from various sources with a very low overhead. If
  some contents need to be inspected in order to take the decision, the
  "tcp-request content" statements must be used instead.

  The "tcp-request connection" rules are evaluated in their exact declaration
  order. If no rule matches or if there is no rule, the default action is to
  accept the incoming connection. There is no specific limit to the number of
  rules which may be inserted. Any rule may optionally be followed by an
  ACL-based condition, in which case it will only be evaluated if the condition
  is true.

  The first keyword is the rule's action. Several types of actions are
  supported:
    - accept
    - expect-netscaler-cip layer4
    - expect-proxy layer4
    - reject
    - sc-inc-gpc(<idx>,<sc-id>)
    - sc-inc-gpc0(<sc-id>)
    - sc-inc-gpc1(<sc-id>)
    - sc-set-gpt(<idx>,<sc-id>) { <int> | <expr> }
    - sc-set-gpt0(<sc-id>) { <int> | <expr> }
    - set-dst <expr>
    - set-dst-port <expr>
    - set-mark <mark>
    - set-src <expr>
    - set-src-port <expr>
    - set-tos <tos>
    - set-var(<var-name>[,<cond> ...]) <expr>
    - set-var-fmt(<var-name>[,<cond> ...]) <fmt>
    - silent-drop
    - track-sc0 <key> [table <table>]
    - track-sc1 <key> [table <table>]
    - track-sc2 <key> [table <table>]
    - unset-var(<var-name>)

  The supported actions are described below.

  There is no limit to the number of "tcp-request connection" statements per
  instance.

  This directive is only available from named defaults sections, not anonymous
  ones. Rules defined in the defaults section are evaluated before ones in the
  associated proxy section. To avoid ambiguities, in this case the same
  defaults section cannot be used by proxies with the frontend capability and
  by proxies with the backend capability. It means a listen section cannot use
  a defaults section defining such rules.

  Note that the "if/unless" condition is optional. If no condition is set on
  the action, it is simply performed unconditionally. That can be useful for
  "track-sc*" actions as well as for changing the default action to a reject.

  Example: accept all connections from white-listed hosts, reject too fast
           connection without counting them, and track accepted connections.
           This results in connection rate being capped from abusive sources.

        tcp-request connection accept if { src -f /etc/haproxy/whitelist.lst }
        tcp-request connection reject if { src_conn_rate gt 10 }
        tcp-request connection track-sc0 src

  Example: accept all connections from white-listed hosts, count all other
           connections and reject too fast ones. This results in abusive ones
           being blocked as long as they don't slow down.

        tcp-request connection accept if { src -f /etc/haproxy/whitelist.lst }
        tcp-request connection track-sc0 src
        tcp-request connection reject if { sc0_conn_rate gt 10 }

  Example: enable the PROXY protocol for traffic coming from all known proxies.

        tcp-request connection expect-proxy layer4 if { src -f proxies.lst }

  See section 7 about ACL usage.

  See also : "tcp-request session", "tcp-request content", "stick-table"

tcp-request connection accept [ { if | unless } <condition> ]

  This is used to accept the connection. No further "tcp-request connection"
  rules are evaluated.

tcp-request connection expect-netscaler-cip layer4
                       [ { if | unless } <condition> ]

  This configures the client-facing connection to receive a NetScaler Client IP
  insertion protocol header before any byte is read from the socket.  This is
  equivalent to having the "accept-netscaler-cip" keyword on the "bind" line,
  except that using the TCP rule allows the PROXY protocol to be accepted only
  for certain IP address ranges using an ACL. This is convenient when multiple
  layers of load balancers are passed through by traffic coming from public
  hosts.

tcp-request connection expect-proxy layer4 [ { if | unless } <condition> ]

  This configures the client-facing connection to receive a PROXY protocol
  header before any byte is read from the socket. This is equivalent to having
  the "accept-proxy" keyword on the "bind" line, except that using the TCP rule
  allows the PROXY protocol to be accepted only for certain IP address ranges
  using an ACL. This is convenient when multiple layers of load balancers are
  passed through by traffic coming from public hosts.

tcp-request connection reject [ { if | unless } <condition> ]

  This is used to reject the connection. No further "tcp-request connection"
  rules are evaluated. Rejected connections do not even become a session, which
  is why they are accounted separately for in the stats, as "denied
  connections". They are not considered for the session rate-limit and are not
  logged either. The reason is that these rules should only be used to filter
  extremely high connection rates such as the ones encountered during a massive
  DDoS attack. Under these extreme conditions, the simple action of logging
  each event would make the system collapse and would considerably lower the
  filtering capacity. If logging is absolutely desired, then "tcp-request
  content" rules should be used instead, as "tcp-request session" rules will
  not log either.

tcp-request connection sc-inc-gpc(<idx>,<sc-id>) [ { if | unless } <condition> ]
tcp-request connection sc-inc-gpc0(<sc-id>) [ { if | unless } <condition> ]
tcp-request connection sc-inc-gpc1(<sc-id>) [ { if | unless } <condition> ]

  These actions increment the General Purppose Counters according to the sticky
  counter designated by <sc-id>. Please refer to "http-request sc-inc-gpc",
  "http-request sc-inc-gpc0" and "http-request sc-inc-gpc1" for a complete
  description.

tcp-request connection sc-set-gpt(<idx>,<sc-id>) { <int> | <expr> }
                       [ { if | unless } <condition> ]
tcp-request connection sc-set-gpt0(<sc-id>) { <int> | <expr> }
                       [ { if | unless } <condition> ]

  These actions set the 32-bit unsigned General Purpose Tags according to the
  sticky counter designated by <sc-id>. Please refer to "http-request
  sc-inc-gpt" and "http-request sc-inc-gpt0" for a complete description.

tcp-request connection set-dst <expr> [ { if | unless } <condition> ]
tcp-request connection set-dst-port <expr> [ { if | unless } <condition> ]

  These actions are used to set the destination IP/Port address to the value of
  specified expression. Please refer to "http-request set-dst" and
  "http-request set-dst-port" for a complete description.

tcp-request connection set-mark <mark> [ { if | unless } <condition> ]

  This action is used to set the Netfilter/IPFW MARK in all packets sent to the
  client to the value passed in <mark> on platforms which support it. Please
  refer to "http-request set-mark" for a complete description.




tcp-request connection set-src <expr> [ { if | unless } <condition> ]
tcp-request connection set-src-port <expr> [ { if | unless } <condition> ]

  These actions are used to set the source IP/Port address to the value of
  specified expression. Please refer to "http-request set-src" and
  "http-request set-src-port" for a complete description.

tcp-request connection set-tos <tos> [ { if | unless } <condition> ]

  This is used to set the TOS or DSCP field value of packets sent to the client
  to the value passed in <tos> on platforms which support this. Please refer to
  "http-request set-tos" for a complete description.

tcp-request connection set-var(<var-name>[,<cond> ...]) <expr> [ { if | unless } <condition> ]
tcp-request connection set-var-fmt(<var-name>[,<cond> ...]) <fmt> [ { if | unless } <condition> ]

  This is used to set the contents of a variable. The variable is declared
  inline. "tcp-request connection" can set variables in the "proc" and "sess"
  scopes. Please refer to "http-request set-var" and "http-request set-var-fmt"
  for a complete description.

tcp-request connection silent-drop [ { if | unless } <condition> ]

  This stops the evaluation of the rules and makes the client-facing connection
  suddenly disappear using a system-dependent way that tries to prevent the
  client from being notified. Please refer to "http-request silent-drop" for a
  complete description.

tcp-request connection track-sc0 <key> [table <table>] [ { if | unless } <condition> ]
tcp-request connection track-sc1 <key> [table <table>] [ { if | unless } <condition> ]
tcp-request connection track-sc2  <key> [table <table>] [ { if | unless } <condition> ]

  This enables tracking of sticky counters from current connection. Please
  refer to "http-request track-sc0", "http-request track-sc1" and "http-request
  track-sc2" for a complete description.

tcp-request connection unset-var(<var-name>) [ { if | unless } <condition> ]

  This is used to unset a variable. Please refer to "http-request set-var" for
  details about variables.

tcp-request content <action> [{if | unless} <condition>]
  Perform an action on a new session depending on a layer 4-7 condition
  May be used in sections :   defaults | frontend | listen | backend
                                yes(!) |    yes   |   yes  |   yes
  Arguments :
    <action>    defines the action to perform if the condition applies. See
                below.

    <condition> is a standard layer 4-7 ACL-based condition (see section 7).

  A request's contents can be analyzed at an early stage of request processing
  called "TCP content inspection". During this stage, ACL-based rules are
  evaluated every time the request contents are updated, until either an
  "accept", a "reject" or a "switch-mode" rule matches, or the TCP request
  inspection delay expires with no matching rule.

  The first difference between these rules and "tcp-request connection" rules
  is that "tcp-request content" rules can make use of contents to take a
  decision. Most often, these decisions will consider a protocol recognition or
  validity. The second difference is that content-based rules can be used in
  both frontends and backends. In case of HTTP keep-alive with the client, all
  tcp-request content rules are evaluated again, so HAProxy keeps a record of
  what sticky counters were assigned by a "tcp-request connection" versus a
  "tcp-request content" rule, and flushes all the content-related ones after
  processing an HTTP request, so that they may be evaluated again by the rules
  being evaluated again for the next request. This is of particular importance
  when the rule tracks some L7 information or when it is conditioned by an
  L7-based ACL, since tracking may change between requests.

  Content-based rules are evaluated in their exact declaration order. If no
  rule matches or if there is no rule, the default action is to accept the
  contents. There is no specific limit to the number of rules which may be
  inserted.

  The first keyword is the rule's action. Several types of actions are
  supported:
    - accept
    - capture <sample> len <length>
    - do-resolve(<var>,,[ipv4,ipv6]) <expr>
    - reject
    - sc-inc-gpc(<idx>,<sc-id>)
    - sc-inc-gpc0(<sc-id>)
    - sc-inc-gpc1(<sc-id>)
    - sc-set-gpt(<idx>,<sc-id>) { <int> | <expr> }
    - sc-set-gpt0(<sc-id>) { <int> | <expr> }
    - send-spoe-group  <group-name>
    - set-dst <expr>
    - set-dst-port <expr>
    - set-log-level <level>
    - set-mark <mark>
    - set-nice <nice>
    - set-priority-class <expr>
    - set-priority-offset <expr>
    - set-src <expr>
    - set-src-port <expr>
    - set-tos <tos>
    - set-var(<var-name>[,<cond> ...]) <expr>
    - set-var-fmt(<var-name>[,<cond> ...]) <fmt>
    - silent-drop
    - switch-mode http [ proto <name> ]
    - track-sc0 <key> [table <table>]
    - track-sc1 <key> [table <table>]
    - track-sc2 <key> [table <table>]
    - unset-var(<var-name>)
    - use-service 

  The supported actions are described below.

  While there is nothing mandatory about it, it is recommended to use the
  track-sc0 in "tcp-request connection" rules, track-sc1 for "tcp-request
  content" rules in the frontend, and track-sc2 for "tcp-request content"
  rules in the backend, because that makes the configuration more readable
  and easier to troubleshoot, but this is just a guideline and all counters
  may be used everywhere.

  This directive is only available from named defaults sections, not anonymous
  ones. Rules defined in the defaults section are evaluated before ones in the
  associated proxy section. To avoid ambiguities, in this case the same
  defaults section cannot be used by proxies with the frontend capability and
  by proxies with the backend capability. It means a listen section cannot use
  a defaults section defining such rules.

  Note that the "if/unless" condition is optional. If no condition is set on
  the action, it is simply performed unconditionally. That can be useful for
  "track-sc*" actions as well as for changing the default action to a reject.

  Note also that it is recommended to use a "tcp-request session" rule to track
  information that does *not* depend on Layer 7 contents, especially for HTTP
  frontends. Some HTTP processing are performed at the session level and may
  lead to an early rejection of the requests. Thus, the tracking at the content
  level may be disturbed in such case. A warning is emitted during startup to
  prevent, as far as possible, such unreliable usage.

  It is perfectly possible to match layer 7 contents with "tcp-request content"
  rules from a TCP proxy, since HTTP-specific ACL matches are able to
  preliminarily parse the contents of a buffer before extracting the required
  data. If the buffered contents do not parse as a valid HTTP message, then the
  ACL does not match.  The parser which is involved there is exactly the same
  as for all other HTTP processing, so there is no risk of parsing something
  differently. In an HTTP frontend or an HTTP backend, it is guaranteed that
  HTTP contents will always be immediately present when the rule is evaluated
  first because the HTTP parsing is performed in the early stages of the
  connection processing, at the session level. But for such proxies, using
  "http-request" rules is much more natural and recommended.

  Tracking layer7 information is also possible provided that the information
  are present when the rule is processed. The rule processing engine is able to
  wait until the inspect delay expires when the data to be tracked is not yet
  available.

  Example:
    tcp-request content use-service lua.deny if { src -f /etc/haproxy/blacklist.lst }

  Example:

        tcp-request content set-var(sess.my_var) src
        tcp-request content set-var-fmt(sess.from) %[src]:%[src_port]
        tcp-request content unset-var(sess.my_var2)

  Example:
        # Accept HTTP requests containing a Host header saying "example.com"
        # and reject everything else. (Only works for HTTP/1 connections)
        acl is_host_com hdr(Host) -i example.com
        tcp-request inspect-delay 30s
        tcp-request content accept if is_host_com
        tcp-request content reject

        # Accept HTTP requests containing a Host header saying "example.com"
        # and reject everything else. (works for HTTP/1 and HTTP/2 connections)
        acl is_host_com hdr(Host) -i example.com
        tcp-request inspect-delay 5s
        tcp-request switch-mode http if HTTP
        tcp-request reject   # non-HTTP traffic is implicit here
        ...
        http-request reject unless is_host_com

  Example:
        # reject SMTP connection if client speaks first
        tcp-request inspect-delay 30s
        acl content_present req.len gt 0
        tcp-request content reject if content_present

        # Forward HTTPS connection only if client speaks
        tcp-request inspect-delay 30s
        acl content_present req.len gt 0
        tcp-request content accept if content_present
        tcp-request content reject

  Example:
        # Track the last IP(stick-table type string) from X-Forwarded-For
        tcp-request inspect-delay 10s
        tcp-request content track-sc0 hdr(x-forwarded-for,-1)
        # Or track the last IP(stick-table type ip|ipv6) from X-Forwarded-For
        tcp-request content track-sc0 req.hdr_ip(x-forwarded-for,-1)

  Example:
        # track request counts per "base" (concatenation of Host+URL)
        tcp-request inspect-delay 10s
        tcp-request content track-sc0 base table req-rate

  Example: track per-frontend and per-backend counters, block abusers at the
           frontend when the backend detects abuse(and marks gpc0).

        frontend http
            # Use General Purpose Counter 0 in SC0 as a global abuse counter
            # protecting all our sites
            stick-table type ip size 1m expire 5m store gpc0
            tcp-request connection track-sc0 src
            tcp-request connection reject if { sc0_get_gpc0 gt 0 }
            ...
            use_backend http_dynamic if { path_end .php }

        backend http_dynamic
            # if a source makes too fast requests to this dynamic site (tracked
            # by SC1), block it globally in the frontend.
            stick-table type ip size 1m expire 5m store http_req_rate(10s)
            acl click_too_fast sc1_http_req_rate gt 10
            acl mark_as_abuser sc0_inc_gpc0(http) gt 0
            tcp-request content track-sc1 src
            tcp-request content reject if click_too_fast mark_as_abuser

  See section 7 about ACL usage.

  See also : "tcp-request connection", "tcp-request session",
             "tcp-request inspect-delay", and "http-request".

tcp-request content accept [ { if | unless } <condition> ]

  This is used to accept the connection. No further "tcp-request content"
  rules are evaluated for the current section.

tcp-request content capture <sample> len <length>
                    [ { if | unless } <condition> ]

  This captures sample expression <sample> from the request buffer, and
  converts it to a string of at most  characters. The resulting string is
  stored into the next request "capture" slot, so it will possibly appear next
  to some captured HTTP headers. It will then automatically appear in the logs,
  and it will be possible to extract it using sample fetch rules to feed it
  into headers or anything. The length should be limited given that this size
  will be allocated for each capture during the whole session life. Please
  check section 7.3 (Fetching samples) and "capture request header" for more
  information.

tcp-request content do-resolve(<var>,,[ipv4,ipv6]) <expr>

  This action performs a DNS resolution of the output of <expr> and stores the
  result in the variable <var>. Please refer to "http-request do-resolve" for a
  complete description.

tcp-request content reject [ { if | unless } <condition> ]

  This is used to reject the connection. No further "tcp-request content" rules
  are evaluated.

tcp-request content sc-inc-gpc(<idx>,<sc-id>) [ { if | unless } <condition> ]
tcp-request content sc-inc-gpc0(<sc-id>) [ { if | unless } <condition> ]
tcp-request content sc-inc-gpc1(<sc-id>) [ { if | unless } <condition> ]

  These actions increment the General Purppose Counters according to the sticky
  counter designated by <sc-id>. Please refer to "http-request sc-inc-gpc",
  "http-request sc-inc-gpc0" and "http-request sc-inc-gpc1" for a complete
  description.

tcp-request content sc-set-gpt(<idx>,<sc-id>) { <int> | <expr> }
                    [ { if | unless } <condition> ]
tcp-request content sc-set-gpt0(<sc-id>) { <int> | <expr> }
                    [ { if | unless } <condition> ]

  These actions set the 32-bit unsigned General Purpose Tags according to the
  sticky counter designated by <sc-id>. Please refer to "http-request
  sc-inc-gpt" and "http-request sc-inc-gpt0" for a complete description.

tcp-request content send-spoe-group  <group-name>
                    [ { if | unless } <condition> ]

  Thaction is is used to trigger sending of a group of SPOE messages. Please
  refer to "http-request send-spoe-group" for a complete description.

tcp-request content set-dst <expr> [ { if | unless } <condition> ]
tcp-request content set-dst-port <expr> [ { if | unless } <condition> ]

  These actions are used to set the destination IP/Port address to the value of
  specified expression. Please refer to "http-request set-dst" and
  "http-request set-dst-port" for a complete description.

tcp-request content set-log-level <level>  [ { if | unless } <condition> ]

  This action is used to set the log level of the current session. Please refer
  to "http-request set-log-level". for a complete description.

tcp-request content set-mark <mark> [ { if | unless } <condition> ]

  This action is used to set the Netfilter/IPFW MARK in all packets sent to the
  client to the value passed in <mark> on platforms which support it. Please
  refer to "http-request set-mark" for a complete description.

tcp-request content set-nice <nice> [ { if | unless } <condition> ]

  This sets the "nice" factor of the current request being processed. Please
  refer to "http-request set-nice" for a complete description.

tcp-request content set-priority-class <expr> [ { if | unless } <condition> ]

  This is used to set the queue priority class of the current request. Please
  refer to "http-request set-priority-class" for a complete description.

tcp-request content set-priority-offset <expr> [ { if | unless } <condition> ]

  This is used to set the queue priority timestamp offset of the current
  request. Please refer to "http-request set-priority-offset" for a complete
  description.

tcp-request content set-src <expr> [ { if | unless } <condition> ]
tcp-request content set-src-port <expr> [ { if | unless } <condition> ]

  These actions are used to set the source IP/Port address to the value of
  specified expression. Please refer to "http-request set-src" and
  "http-request set-src-port" for a complete description.

tcp-request content set-tos <tos> [ { if | unless } <condition> ]

  This is used to set the TOS or DSCP field value of packets sent to the client
  to the value passed in <tos> on platforms which support this. Please refer to
  "http-request set-tos" for a complete description.

tcp-request content set-var(<var-name>[,<cond> ...]) <expr> [ { if | unless } <condition> ]
tcp-request content set-var-fmt(<var-name>[,<cond> ...]) <fmt> [ { if | unless } <condition> ]

  This is used to set the contents of a variable. The variable is declared
  inline. Please refer to "http-request set-var" and "http-request set-var-fmt"
  for a complete description.

tcp-request content silent-drop [ { if | unless } <condition> ]

  This stops the evaluation of the rules and makes the client-facing connection
  suddenly disappear using a system-dependent way that tries to prevent the
  client from being notified. Please refer to "http-request silent-drop" for a
  complete description.

tcp-request content switch-mode http [ proto <name> ]
                    [ { if | unless } <condition> ]

  This action is used to perform a connection upgrade. Only HTTP upgrades are
  supported for now. The protocol may optionally be specified. This action is
  only available for a proxy with the frontend capability. The connection
  upgrade is immediately performed, following "tcp-request content" rules are
  not evaluated. This upgrade method should be preferred to the implicit one
  consisting to rely on the backend mode. When used, it is possible to set HTTP
  directives in a frontend without any warning. These directives will be
  conditionally evaluated if the HTTP upgrade is performed. However, an HTTP
  backend must still be selected. It remains unsupported to route an HTTP
  connection (upgraded or not) to a TCP server.

  See section 4 about Proxies for more details on HTTP upgrades.

tcp-request content track-sc0 <key> [table <table>] [ { if | unless } <condition> ]
tcp-request content track-sc1 <key> [table <table>] [ { if | unless } <condition> ]
tcp-request content track-sc2  <key> [table <table>] [ { if | unless } <condition> ]

  This enables tracking of sticky counters from current connection. Please
  refer to "http-request track-sc0", "http-request track-sc1" and "http-request
  track-sc2" for a complete description.

tcp-request content unset-var(<var-name>) [ { if | unless } <condition> ]

  This is used to unset a variable. Please refer to "http-request set-var" for
  details about variables.

tcp-request content use-service  [ { if | unless } <condition> ]

  This action is used to executes a TCP service which will reply to the request
  and stop the evaluation of the rules. This service may choose to reply by
  sending any valid response or it may immediately close the connection without
  sending anything. Outside natives services, it is possible to write your own
  services in Lua. No further "tcp-request content" rules are evaluated.

tcp-request inspect-delay <timeout>
  Set the maximum allowed time to wait for data during content inspection
  May be used in sections :   defaults | frontend | listen | backend
                                yes(!) |    yes   |   yes  |   yes
  Arguments :
    <timeout> is the timeout value specified in milliseconds by default, but
              can be in any other unit if the number is suffixed by the unit,
              as explained at the top of this document.

  People using HAProxy primarily as a TCP relay are often worried about the
  risk of passing any type of protocol to a server without any analysis. In
  order to be able to analyze the request contents, we must first withhold
  the data then analyze them. This statement simply enables withholding of
  data for at most the specified amount of time.

  TCP content inspection applies very early when a connection reaches a
  frontend, then very early when the connection is forwarded to a backend. This
  means that a connection may experience a first delay in the frontend and a
  second delay in the backend if both have tcp-request rules.

  Note that when performing content inspection, HAProxy will evaluate the whole
  rules for every new chunk which gets in, taking into account the fact that
  those data are partial. If no rule matches before the aforementioned delay,
  a last check is performed upon expiration, this time considering that the
  contents are definitive. If no delay is set, HAProxy will not wait at all
  and will immediately apply a verdict based on the available information.
  Obviously this is unlikely to be very useful and might even be racy, so such
  setups are not recommended.

  As soon as a rule matches, the request is released and continues as usual. If
  the timeout is reached and no rule matches, the default policy will be to let
  it pass through unaffected.

  For most protocols, it is enough to set it to a few seconds, as most clients
  send the full request immediately upon connection. Add 3 or more seconds to
  cover TCP retransmits but that's all. For some protocols, it may make sense
  to use large values, for instance to ensure that the client never talks
  before the server (e.g. SMTP), or to wait for a client to talk before passing
  data to the server (e.g. SSL). Note that the client timeout must cover at
  least the inspection delay, otherwise it will expire first. If the client
  closes the connection or if the buffer is full, the delay immediately expires
  since the contents will not be able to change anymore.

  This directive is only available from named defaults sections, not anonymous
  ones. Proxies inherit this value from their defaults section.

  See also : "tcp-request content accept", "tcp-request content reject",
             "timeout client".

tcp-request session <action> [{if | unless} <condition>]
  Perform an action on a validated session depending on a layer 5 condition
  May be used in sections :   defaults | frontend | listen | backend
                                yes(!) |    yes   |   yes  |   no
  Arguments :
    <action>    defines the action to perform if the condition applies. See
                below.

    <condition> is a standard layer5-only ACL-based condition (see section 7).

  Once a session is validated, (i.e. after all handshakes have been completed),
  it is possible to evaluate some conditions to decide whether this session
  must be accepted or dropped or have its counters tracked. Those conditions
  cannot make use of any data contents because no buffers are allocated yet and
  the processing cannot wait at this stage. The main use case is to copy some
  early information into variables (since variables are accessible in the
  session), or to keep track of some information collected after the handshake,
  such as SSL-level elements (SNI, ciphers, client cert's CN) or information
  from the PROXY protocol header (e.g. track a source forwarded this way). The
  extracted information can thus be copied to a variable or tracked using
  "track-sc" rules. Of course it is also possible to decide to accept/reject as
  with other rulesets. Most operations performed here could also be performed
  in "tcp-request content" rules, except that in HTTP these rules are evaluated
  for each new request, and that might not always be acceptable. For example a
  rule might increment a counter on each evaluation. It would also be possible
  that a country is resolved by geolocation from the source IP address,
  assigned to a session-wide variable, then the source address rewritten from
  an HTTP header for all requests. If some contents need to be inspected in
  order to take the decision, the "tcp-request content" statements must be used
  instead.

  The "tcp-request session" rules are evaluated in their exact declaration
  order. If no rule matches or if there is no rule, the default action is to
  accept the incoming session. There is no specific limit to the number of
  rules which may be inserted.

  The first keyword is the rule's action. Several types of actions are
  supported:
    - accept
    - reject
    - sc-inc-gpc(<idx>,<sc-id>)
    - sc-inc-gpc0(<sc-id>)
    - sc-inc-gpc1(<sc-id>)
    - sc-set-gpt(<idx>,<sc-id>) { <int> | <expr> }
    - sc-set-gpt0(<sc-id>) { <int> | <expr> }
    - set-dst <expr>
    - set-dst-port <expr>
    - set-mark <mark>
    - set-src <expr>
    - set-src-port <expr>
    - set-tos <tos>
    - set-var(<var-name>[,<cond> ...]) <expr>
    - set-var-fmt(<var-name>[,<cond> ...]) <fmt>
    - silent-drop
    - track-sc0 <key> [table <table>]
    - track-sc1 <key> [table <table>]
    - track-sc2 <key> [table <table>]
    - unset-var(<var-name>)

  The supported actions are described below.

  This directive is only available from named defaults sections, not anonymous
  ones. Rules defined in the defaults section are evaluated before ones in the
  associated proxy section. To avoid ambiguities, in this case the same
  defaults section cannot be used by proxies with the frontend capability and
  by proxies with the backend capability. It means a listen section cannot use
  a defaults section defining such rules.

  Note that the "if/unless" condition is optional. If no condition is set on
  the action, it is simply performed unconditionally. That can be useful for
  "track-sc*" actions as well as for changing the default action to a reject.

  Example: track the original source address by default, or the one advertised
           in the PROXY protocol header for connection coming from the local
           proxies. The first connection-level rule enables receipt of the
           PROXY protocol for these ones, the second rule tracks whatever
           address we decide to keep after optional decoding.

        tcp-request connection expect-proxy layer4 if { src -f proxies.lst }
        tcp-request session track-sc0 src

  Example: accept all sessions from white-listed hosts, reject too fast
           sessions without counting them, and track accepted sessions.
           This results in session rate being capped from abusive sources.

        tcp-request session accept if { src -f /etc/haproxy/whitelist.lst }
        tcp-request session reject if { src_sess_rate gt 10 }
        tcp-request session track-sc0 src

  Example: accept all sessions from white-listed hosts, count all other
           sessions and reject too fast ones. This results in abusive ones
           being blocked as long as they don't slow down.

        tcp-request session accept if { src -f /etc/haproxy/whitelist.lst }
        tcp-request session track-sc0 src
        tcp-request session reject if { sc0_sess_rate gt 10 }

  See section 7 about ACL usage.

  See also : "tcp-request connection", "tcp-request content", "stick-table"

tcp-request session accept [ { if | unless } <condition> ]

  This is used to accept the connection. No further "tcp-request session"
  rules are evaluated.

tcp-request session reject [ { if | unless } <condition> ]

  This is used to reject the connection. No further "tcp-request session" rules
  are evaluated.

tcp-request session sc-inc-gpc(<idx>,<sc-id>) [ { if | unless } <condition> ]
tcp-request session sc-inc-gpc0(<sc-id>) [ { if | unless } <condition> ]
tcp-request session sc-inc-gpc1(<sc-id>) [ { if | unless } <condition> ]

  These actions increment the General Purppose Counters according to the sticky
  counter designated by <sc-id>. Please refer to "http-request sc-inc-gpc",
  "http-request sc-inc-gpc0" and "http-request sc-inc-gpc1" for a complete
  description.

tcp-request session sc-set-gpt(<idx>,<sc-id>) { <int> | <expr> }
                    [ { if | unless } <condition> ]
tcp-request session sc-set-gpt0(<sc-id>) { <int> | <expr> }
                    [ { if | unless } <condition> ]

  These actions set the 32-bit unsigned General Purpose Tags according to the
  sticky counter designated by <sc-id>. Please refer to "tcp-request connection
  sc-inc-gpt" and "tcp-request connection sc-inc-gpt0" for a complete
  description.

tcp-request session set-dst <expr> [ { if | unless } <condition> ]
tcp-request session set-dst-port <expr> [ { if | unless } <condition> ]

  These actions are used to set the destination IP/Port address to the value of
  specified expression. Please refer to "http-request set-dst" and
  "http-request set-dst-port" for a complete description.

tcp-request session set-mark <mark> [ { if | unless } <condition> ]

  This action is used to set the Netfilter/IPFW MARK in all packets sent to the
  client to the value passed in <mark> on platforms which support it. Please
  refer to "http-request set-mark" for a complete description.

tcp-request session set-src <expr> [ { if | unless } <condition> ]
tcp-request session set-src-port <expr> [ { if | unless } <condition> ]

  These actions are used to set the source IP/Port address to the value of
  specified expression. Please refer to "http-request set-src" and
  "http-request set-src-port" for a complete description.

tcp-request session set-tos <tos> [ { if | unless } <condition> ]

  This is used to set the TOS or DSCP field value of packets sent to the client
  to the value passed in <tos> on platforms which support this. Please refer to
  "http-request set-tos" for a complete description.

tcp-request session set-var(<var-name>[,<cond> ...]) <expr> [ { if | unless } <condition> ]
tcp-request session set-var-fmt(<var-name>[,<cond> ...]) <fmt> [ { if | unless } <condition> ]

  This is used to set the contents of a variable. The variable is declared
  inline. Please refer to "http-request set-var" and "http-request set-var-fmt"
  for a complete description.

tcp-request session silent-drop [ { if | unless } <condition> ]

  This stops the evaluation of the rules and makes the client-facing connection
  suddenly disappear using a system-dependent way that tries to prevent the
  client from being notified. Please refer to "http-request silent-drop" for a
  complete description.

tcp-request session track-sc0 <key> [table <table>] [ { if | unless } <condition> ]
tcp-request session track-sc1 <key> [table <table>] [ { if | unless } <condition> ]
tcp-request session track-sc2  <key> [table <table>] [ { if | unless } <condition> ]

  This enables tracking of sticky counters from current connection. Please
  refer to "http-request track-sc0", "http-request track-sc1" and "http-request
  track-sc2" for a complete description.

tcp-request session unset-var(<var-name>) [ { if | unless } <condition> ]

  This is used to unset a variable. Please refer to "http-request set-var" for
  details about variables.

tcp-response content <action> [{if | unless} <condition>]
  Perform an action on a session response depending on a layer 4-7 condition
  May be used in sections :   defaults | frontend | listen | backend
                                yes(!) |    no    |   yes  |   yes
  Arguments :
    <action>    defines the action to perform if the condition applies. See
                below.

    <condition> is a standard layer 4-7 ACL-based condition (see section 7).

  Response contents can be analyzed at an early stage of response processing
  called "TCP content inspection". During this stage, ACL-based rules are
  evaluated every time the response contents are updated, until either an
  "accept", "close" or a "reject" rule matches, or a TCP response inspection
  delay is set and expires with no matching rule.

  Most often, these decisions will consider a protocol recognition or validity.

  Content-based rules are evaluated in their exact declaration order. If no
  rule matches or if there is no rule, the default action is to accept the
  contents. There is no specific limit to the number of rules which may be
  inserted.

  The first keyword is the rule's action. Several types of actions are
  supported:
    - accept
    - close
    - reject
    - sc-inc-gpc(<idx>,<sc-id>)
    - sc-inc-gpc0(<sc-id>)
    - sc-inc-gpc1(<sc-id>)
    - sc-set-gpt(<idx>,<sc-id>) { <int> | <expr> }
    - sc-set-gpt0(<sc-id>) { <int> | <expr> }
    - send-spoe-group  <group-name>
    - set-log-level <level>
    - set-mark <mark>
    - set-nice <nice>
    - set-tos <tos>
    - set-var(<var-name>[,<cond> ...]) <expr>
    - set-var-fmt(<var-name>[,<cond> ...]) <fmt>
    - silent-drop
    - unset-var(<var-name>)

  The supported actions are described below.

  This directive is only available from named defaults sections, not anonymous
  ones. Rules defined in the defaults section are evaluated before ones in the
  associated proxy section. To avoid ambiguities, in this case the same
  defaults section cannot be used by proxies with the frontend capability and
  by proxies with the backend capability. It means a listen section cannot use
  a defaults section defining such rules.

  Note that the "if/unless" condition is optional. If no condition is set on
  the action, it is simply performed unconditionally. That can be useful for
  for changing the default action to a reject.

  Several types of actions are supported :

  It is perfectly possible to match layer 7 contents with "tcp-response
  content" rules, but then it is important to ensure that a full response has
  been buffered, otherwise no contents will match. In order to achieve this,
  the best solution involves detecting the HTTP protocol during the inspection
  period.

  See section 7 about ACL usage.

  See also : "tcp-request content", "tcp-response inspect-delay"

tcp-response content accept [ { if | unless } <condition> ]

  This is used to accept the response. No further "tcp-response content" rules
  are evaluated.

tcp-response content close [ { if | unless } <condition> ]

  This is used to immediately closes the connection with the server. No further
  "tcp-response content" rules are evaluated. The main purpose of this action
  is to force a connection to be finished between a client and a server after
  an exchange when the application protocol expects some long time outs to
  elapse first. The goal is to eliminate idle connections which take
  significant resources on servers with certain protocols.

tcp-response content reject [ { if | unless } <condition> ]

  This is used to reject the response. No further "tcp-response content" rules
  are evaluated.

tcp-response content sc-inc-gpc(<idx>,<sc-id>) [ { if | unless } <condition> ]
tcp-response content sc-inc-gpc0(<sc-id>) [ { if | unless } <condition> ]
tcp-response content sc-inc-gpc1(<sc-id>) [ { if | unless } <condition> ]

  These actions increment the General Purppose Counters according to the sticky
  counter designated by <sc-id>. Please refer to "http-request sc-inc-gpc",
  "http-request sc-inc-gpc0" and "http-request sc-inc-gpc1" for a complete
  description.

tcp-response content sc-set-gpt(<idx>,<sc-id>) { <int> | <expr> }
                     [ { if | unless } <condition> ]
tcp-resposne content sc-set-gpt0(<sc-id>) { <int> | <expr> }
                     [ { if | unless } <condition> ]

  These actions set the 32-bit unsigned General Purpose Tags according to the
  sticky counter designated by <sc-id>. Please refer to "http-request
  sc-inc-gpt" and "http-request sc-inc-gpt0" for a complete description.

tcp-response content send-spoe-group  <group-name>
                     [ { if | unless } <condition> ]

  Thaction is is used to trigger sending of a group of SPOE messages. Please
  refer to "http-request send-spoe-group" for a complete description.

tcp-response content set-log-level <level>  [ { if | unless } <condition> ]

  This action is used to set the log level of the current session. Please refer
  to "http-request set-log-level". for a complete description.

tcp-response content set-mark <mark> [ { if | unless } <condition> ]

  This action is used to set the Netfilter/IPFW MARK in all packets sent to the
  client to the value passed in <mark> on platforms which support it. Please
  refer to "http-request set-mark" for a complete description.

tcp-response content set-nice <nice> [ { if | unless } <condition> ]

  This sets the "nice" factor of the current request being processed. Please
  refer to "http-request set-nice" for a complete description.

tcp-response content set-tos <tos> [ { if | unless } <condition> ]

  This is used to set the TOS or DSCP field value of packets sent to the client
  to the value passed in <tos> on platforms which support this. Please refer to
  "http-request set-tos" for a complete description.

tcp-response content set-var(<var-name>[,<cond> ...]) <expr> [ { if | unless } <condition> ]
tcp-response content set-var-fmt(<var-name>[,<cond> ...]) <fmt> [ { if | unless } <condition> ]

  This is used to set the contents of a variable. The variable is declared
  inline. Please refer to "http-request set-var" and "http-request set-var-fmt"
  for a complete description.

tcp-response content silent-drop [ { if | unless } <condition> ]

  This stops the evaluation of the rules and makes the client-facing connection
  suddenly disappear using a system-dependent way that tries to prevent the
  client from being notified. Please refer to "http-request silent-drop" for a
  complete description.

tcp-response content unset-var(<var-name>) [ { if | unless } <condition> ]

  This is used to unset a variable. Please refer to "http-request set-var" for
  details about variables.

tcp-response inspect-delay <timeout>
  Set the maximum allowed time to wait for a response during content inspection
  May be used in sections :   defaults | frontend | listen | backend
                               yes(!)  |    no    |   yes  |   yes
  Arguments :
    <timeout> is the timeout value specified in milliseconds by default, but
              can be in any other unit if the number is suffixed by the unit,
              as explained at the top of this document.

  This directive is only available from named defaults sections, not anonymous
  ones. Proxies inherit this value from their defaults section.

  See also : "tcp-response content", "tcp-request inspect-delay".

timeout check <timeout>
  Set additional check timeout, but only after a connection has been already
  established.

  May be used in sections:    defaults | frontend | listen | backend
                                 yes   |    no    |   yes  |   yes
  Arguments:
    <timeout> is the timeout value specified in milliseconds by default, but
              can be in any other unit if the number is suffixed by the unit,
              as explained at the top of this document.

  If set, HAProxy uses min("timeout connect", "inter") as a connect timeout
  for check and "timeout check" as an additional read timeout. The "min" is
  used so that people running with *very* long "timeout connect" (e.g. those
  who needed this due to the queue or tarpit) do not slow down their checks.
  (Please also note that there is no valid reason to have such long connect
  timeouts, because "timeout queue" and "timeout tarpit" can always be used to
  avoid that).

  If "timeout check" is not set HAProxy uses "inter" for complete check
  timeout (connect + read) exactly like all <1.3.15 version.

  In most cases check request is much simpler and faster to handle than normal
  requests and people may want to kick out laggy servers so this timeout should
  be smaller than "timeout server".

  This parameter is specific to backends, but can be specified once for all in
  "defaults" sections. This is in fact one of the easiest solutions not to
  forget about it.

  This directive is only available from named defaults sections, not anonymous
  ones. Proxies inherit this value from their defaults section.

  See also: "timeout connect", "timeout queue", "timeout server",
            "timeout tarpit".

timeout client <timeout>
  Set the maximum inactivity time on the client side.
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    yes   |   yes  |   no
  Arguments :
    <timeout> is the timeout value specified in milliseconds by default, but
              can be in any other unit if the number is suffixed by the unit,
              as explained at the top of this document.

  The inactivity timeout applies when the client is expected to acknowledge or
  send data. In HTTP mode, this timeout is particularly important to consider
  during the first phase, when the client sends the request, and during the
  response while it is reading data sent by the server. That said, for the
  first phase, it is preferable to set the "timeout http-request" to better
  protect HAProxy from Slowloris like attacks. The value is specified in
  milliseconds by default, but can be in any other unit if the number is
  suffixed by the unit, as specified at the top of this document. In TCP mode
  (and to a lesser extent, in HTTP mode), it is highly recommended that the
  client timeout remains equal to the server timeout in order to avoid complex
  situations to debug. It is a good practice to cover one or several TCP packet
  losses by specifying timeouts that are slightly above multiples of 3 seconds
  (e.g. 4 or 5 seconds). If some long-lived sessions are mixed with short-lived
  sessions (e.g. WebSocket and HTTP), it's worth considering "timeout tunnel",
  which overrides "timeout client" and "timeout server" for tunnels, as well as
  "timeout client-fin" for half-closed connections.

  This parameter is specific to frontends, but can be specified once for all in
  "defaults" sections. This is in fact one of the easiest solutions not to
  forget about it. An unspecified timeout results in an infinite timeout, which
  is not recommended. Such a usage is accepted and works but reports a warning
  during startup because it may result in accumulation of expired sessions in
  the system if the system's timeouts are not configured either.

  See also : "timeout server", "timeout tunnel", "timeout http-request".

timeout client-fin <timeout>
  Set the inactivity timeout on the client side for half-closed connections.
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    yes   |   yes  |   no
  Arguments :
    <timeout> is the timeout value specified in milliseconds by default, but
              can be in any other unit if the number is suffixed by the unit,
              as explained at the top of this document.

  The inactivity timeout applies when the client is expected to acknowledge or
  send data while one direction is already shut down. This timeout is different
  from "timeout client" in that it only applies to connections which are closed
  in one direction. This is particularly useful to avoid keeping connections in
  FIN_WAIT state for too long when clients do not disconnect cleanly. This
  problem is particularly common long connections such as RDP or WebSocket.
  Note that this timeout can override "timeout tunnel" when a connection shuts
  down in one direction. It is applied to idle HTTP/2 connections once a GOAWAY
  frame was sent, often indicating an expectation that the connection quickly
  ends.

  This parameter is specific to frontends, but can be specified once for all in
  "defaults" sections. By default it is not set, so half-closed connections
  will use the other timeouts (timeout.client or timeout.tunnel).

  See also : "timeout client", "timeout server-fin", and "timeout tunnel".

timeout connect <timeout>
  Set the maximum time to wait for a connection attempt to a server to succeed.
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    no    |   yes  |   yes
  Arguments :
    <timeout> is the timeout value specified in milliseconds by default, but
              can be in any other unit if the number is suffixed by the unit,
              as explained at the top of this document.

  If the server is located on the same LAN as HAProxy, the connection should be
  immediate (less than a few milliseconds). Anyway, it is a good practice to
  cover one or several TCP packet losses by specifying timeouts that are
  slightly above multiples of 3 seconds (e.g. 4 or 5 seconds). By default, the
  connect timeout also presets both queue and tarpit timeouts to the same value
  if these have not been specified.

  This parameter is specific to backends, but can be specified once for all in
  "defaults" sections. This is in fact one of the easiest solutions not to
  forget about it. An unspecified timeout results in an infinite timeout, which
  is not recommended. Such a usage is accepted and works but reports a warning
  during startup because it may result in accumulation of failed sessions in
  the system if the system's timeouts are not configured either.

  See also: "timeout check", "timeout queue", "timeout server", "timeout tarpit".

timeout http-keep-alive <timeout>
  Set the maximum allowed time to wait for a new HTTP request to appear
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    yes   |   yes  |   yes
  Arguments :
    <timeout> is the timeout value specified in milliseconds by default, but
              can be in any other unit if the number is suffixed by the unit,
              as explained at the top of this document.

  By default, the time to wait for a new request in case of keep-alive is set
  by "timeout http-request". However this is not always convenient because some
  people want very short keep-alive timeouts in order to release connections
  faster, and others prefer to have larger ones but still have short timeouts
  once the request has started to present itself.

  The "http-keep-alive" timeout covers these needs. It will define how long to
  wait for a new HTTP request to start coming after a response was sent. Once
  the first byte of request has been seen, the "http-request" timeout is used
  to wait for the complete request to come. Note that empty lines prior to a
  new request do not refresh the timeout and are not counted as a new request.

  There is also another difference between the two timeouts : when a connection
  expires during timeout http-keep-alive, no error is returned, the connection
  just closes. If the connection expires in "http-request" while waiting for a
  connection to complete, a HTTP 408 error is returned.

  In general it is optimal to set this value to a few tens to hundreds of
  milliseconds, to allow users to fetch all objects of a page at once but
  without waiting for further clicks. Also, if set to a very small value (e.g.
  1 millisecond) it will probably only accept pipelined requests but not the
  non-pipelined ones. It may be a nice trade-off for very large sites running
  with tens to hundreds of thousands of clients.

  If this parameter is not set, the "http-request" timeout applies, and if both
  are not set, "timeout client" still applies at the lower level. It should be
  set in the frontend to take effect, unless the frontend is in TCP mode, in
  which case the HTTP backend's timeout will be used.

  See also : "timeout http-request", "timeout client".

timeout http-request <timeout>
  Set the maximum allowed time to wait for a complete HTTP request
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    yes   |   yes  |   yes
  Arguments :
    <timeout> is the timeout value specified in milliseconds by default, but
              can be in any other unit if the number is suffixed by the unit,
              as explained at the top of this document.

  In order to offer DoS protection, it may be required to lower the maximum
  accepted time to receive a complete HTTP request without affecting the client
  timeout. This helps protecting against established connections on which
  nothing is sent. The client timeout cannot offer a good protection against
  this abuse because it is an inactivity timeout, which means that if the
  attacker sends one character every now and then, the timeout will not
  trigger. With the HTTP request timeout, no matter what speed the client
  types, the request will be aborted if it does not complete in time. When the
  timeout expires, an HTTP 408 response is sent to the client to inform it
  about the problem, and the connection is closed. The logs will report
  termination codes "cR". Some recent browsers are having problems with this
  standard, well-documented behavior, so it might be needed to hide the 408
  code using "option http-ignore-probes" or "errorfile 408 /dev/null". See
  more details in the explanations of the "cR" termination code in section 8.5.

  By default, this timeout only applies to the header part of the request,
  and not to any data. As soon as the empty line is received, this timeout is
  not used anymore. When combined with "option http-buffer-request", this
  timeout also applies to the body of the request..
  It is used again on keep-alive connections to wait for a second
  request if "timeout http-keep-alive" is not set.

  Generally it is enough to set it to a few seconds, as most clients send the
  full request immediately upon connection. Add 3 or more seconds to cover TCP
  retransmits but that's all. Setting it to very low values (e.g. 50 ms) will
  generally work on local networks as long as there are no packet losses. This
  will prevent people from sending bare HTTP requests using telnet.

  If this parameter is not set, the client timeout still applies between each
  chunk of the incoming request. It should be set in the frontend to take
  effect, unless the frontend is in TCP mode, in which case the HTTP backend's
  timeout will be used.

  See also : "errorfile", "http-ignore-probes", "timeout http-keep-alive", and
             "timeout client", "option http-buffer-request".

timeout queue <timeout>
  Set the maximum time to wait in the queue for a connection slot to be free
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    no    |   yes  |   yes
  Arguments :
    <timeout> is the timeout value specified in milliseconds by default, but
              can be in any other unit if the number is suffixed by the unit,
              as explained at the top of this document.

  When a server's maxconn is reached, connections are left pending in a queue
  which may be server-specific or global to the backend. In order not to wait
  indefinitely, a timeout is applied to requests pending in the queue. If the
  timeout is reached, it is considered that the request will almost never be
  served, so it is dropped and a 503 error is returned to the client.

  The "timeout queue" statement allows to fix the maximum time for a request to
  be left pending in a queue. If unspecified, the same value as the backend's
  connection timeout ("timeout connect") is used, for backwards compatibility
  with older versions with no "timeout queue" parameter.

  See also : "timeout connect".

timeout server <timeout>
  Set the maximum inactivity time on the server side.
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    no    |   yes  |   yes
  Arguments :
    <timeout> is the timeout value specified in milliseconds by default, but
              can be in any other unit if the number is suffixed by the unit,
              as explained at the top of this document.

  The inactivity timeout applies when the server is expected to acknowledge or
  send data. In HTTP mode, this timeout is particularly important to consider
  during the first phase of the server's response, when it has to send the
  headers, as it directly represents the server's processing time for the
  request. To find out what value to put there, it's often good to start with
  what would be considered as unacceptable response times, then check the logs
  to observe the response time distribution, and adjust the value accordingly.

  The value is specified in milliseconds by default, but can be in any other
  unit if the number is suffixed by the unit, as specified at the top of this
  document. In TCP mode (and to a lesser extent, in HTTP mode), it is highly
  recommended that the client timeout remains equal to the server timeout in
  order to avoid complex situations to debug. Whatever the expected server
  response times, it is a good practice to cover at least one or several TCP
  packet losses by specifying timeouts that are slightly above multiples of 3
  seconds (e.g. 4 or 5 seconds minimum). If some long-lived sessions are mixed
  with short-lived sessions (e.g. WebSocket and HTTP), it's worth considering
  "timeout tunnel", which overrides "timeout client" and "timeout server" for
  tunnels.

  This parameter is specific to backends, but can be specified once for all in
  "defaults" sections. This is in fact one of the easiest solutions not to
  forget about it. An unspecified timeout results in an infinite timeout, which
  is not recommended. Such a usage is accepted and works but reports a warning
  during startup because it may result in accumulation of expired sessions in
  the system if the system's timeouts are not configured either.

  See also : "timeout client" and "timeout tunnel".

timeout server-fin <timeout>
  Set the inactivity timeout on the server side for half-closed connections.
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    no    |   yes  |   yes
  Arguments :
    <timeout> is the timeout value specified in milliseconds by default, but
              can be in any other unit if the number is suffixed by the unit,
              as explained at the top of this document.

  The inactivity timeout applies when the server is expected to acknowledge or
  send data while one direction is already shut down. This timeout is different
  from "timeout server" in that it only applies to connections which are closed
  in one direction. This is particularly useful to avoid keeping connections in
  FIN_WAIT state for too long when a remote server does not disconnect cleanly.
  This problem is particularly common long connections such as RDP or WebSocket.
  Note that this timeout can override "timeout tunnel" when a connection shuts
  down in one direction. This setting was provided for completeness, but in most
  situations, it should not be needed.

  This parameter is specific to backends, but can be specified once for all in
  "defaults" sections. By default it is not set, so half-closed connections
  will use the other timeouts (timeout.server or timeout.tunnel).

  See also : "timeout client-fin", "timeout server", and "timeout tunnel".

timeout tarpit <timeout>
  Set the duration for which tarpitted connections will be maintained
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    yes   |   yes  |   yes
  Arguments :
    <timeout> is the tarpit duration specified in milliseconds by default, but
              can be in any other unit if the number is suffixed by the unit,
              as explained at the top of this document.

  When a connection is tarpitted using "http-request tarpit", it is maintained
  open with no activity for a certain amount of time, then closed. "timeout
  tarpit" defines how long it will be maintained open.

  The value is specified in milliseconds by default, but can be in any other
  unit if the number is suffixed by the unit, as specified at the top of this
  document. If unspecified, the same value as the backend's connection timeout
  ("timeout connect") is used, for backwards compatibility with older versions
  with no "timeout tarpit" parameter.

  See also : "timeout connect".

timeout tunnel <timeout>
  Set the maximum inactivity time on the client and server side for tunnels.
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    no    |   yes  |   yes
  Arguments :
    <timeout> is the timeout value specified in milliseconds by default, but
              can be in any other unit if the number is suffixed by the unit,
              as explained at the top of this document.

  The tunnel timeout applies when a bidirectional connection is established
  between a client and a server, and the connection remains inactive in both
  directions. This timeout supersedes both the client and server timeouts once
  the connection becomes a tunnel. In TCP, this timeout is used as soon as no
  analyzer remains attached to either connection (e.g. tcp content rules are
  accepted). In HTTP, this timeout is used when a connection is upgraded (e.g.
  when switching to the WebSocket protocol, or forwarding a CONNECT request
  to a proxy), or after the first response when no keepalive/close option is
  specified.

  Since this timeout is usually used in conjunction with long-lived connections,
  it usually is a good idea to also set "timeout client-fin" to handle the
  situation where a client suddenly disappears from the net and does not
  acknowledge a close, or sends a shutdown and does not acknowledge pending
  data anymore. This can happen in lossy networks where firewalls are present,
  and is detected by the presence of large amounts of sessions in a FIN_WAIT
  state.

  The value is specified in milliseconds by default, but can be in any other
  unit if the number is suffixed by the unit, as specified at the top of this
  document. Whatever the expected normal idle time, it is a good practice to
  cover at least one or several TCP packet losses by specifying timeouts that
  are slightly above multiples of 3 seconds (e.g. 4 or 5 seconds minimum).

  This parameter is specific to backends, but can be specified once for all in
  "defaults" sections. This is in fact one of the easiest solutions not to
  forget about it.

  Example :
        defaults http
            option http-server-close
            timeout connect 5s
            timeout client 30s
            timeout client-fin 30s
            timeout server 30s
            timeout tunnel  1h    # timeout to use with WebSocket and CONNECT

  See also : "timeout client", "timeout client-fin", "timeout server".

transparent (deprecated)
  Enable client-side transparent proxying
  May be used in sections :   defaults | frontend | listen | backend
                                 yes   |    no    |   yes  |   yes
  Arguments : none

  This keyword was introduced in order to provide layer 7 persistence to layer
  3 load balancers. The idea is to use the OS's ability to redirect an incoming
  connection for a remote address to a local process (here HAProxy), and let
  this process know what address was initially requested. When this option is
  used, sessions without cookies will be forwarded to the original destination
  IP address of the incoming request (which should match that of another
  equipment), while requests with cookies will still be forwarded to the
  appropriate server.

  The "transparent" keyword is deprecated, use "option transparent" instead.

  Note that contrary to a common belief, this option does NOT make HAProxy
  present the client's IP to the server when establishing the connection.

  See also: "option transparent"

unique-id-format <string>
  Generate a unique ID for each request.
  May be used in sections :   defaults | frontend | listen | backend
                                  yes  |    yes   |   yes  |   no
  Arguments :
    <string>   is a log-format string.

  This keyword creates a ID for each request using the custom log format. A
  unique ID is useful to trace a request passing through many components of
  a complex infrastructure. The newly created ID may also be logged using the
  %ID tag the log-format string.

  The format should be composed from elements that are guaranteed to be
  unique when combined together. For instance, if multiple HAProxy instances
  are involved, it might be important to include the node name. It is often
  needed to log the incoming connection's source and destination addresses
  and ports. Note that since multiple requests may be performed over the same
  connection, including a request counter may help differentiate them.
  Similarly, a timestamp may protect against a rollover of the counter.
  Logging the process ID will avoid collisions after a service restart.

  It is recommended to use hexadecimal notation for many fields since it
  makes them more compact and saves space in logs.

  Example:

        unique-id-format %{+X}o\ %ci:%cp_%fi:%fp_%Ts_%rt:%pid

        will generate:

               7F000001:8296_7F00001E:1F90_4F7B0A69_0003:790A

  See also: "unique-id-header"

unique-id-header <name>
  Add a unique ID header in the HTTP request.
  May be used in sections :   defaults | frontend | listen | backend
                                  yes  |    yes   |   yes  |   no
  Arguments :
    <name>   is the name of the header.

  Add a unique-id header in the HTTP request sent to the server, using the
  unique-id-format. It can't work if the unique-id-format doesn't exist.

  Example:

        unique-id-format %{+X}o\ %ci:%cp_%fi:%fp_%Ts_%rt:%pid
        unique-id-header X-Unique-ID

        will generate:

           X-Unique-ID: 7F000001:8296_7F00001E:1F90_4F7B0A69_0003:790A

    See also: "unique-id-format"

use_backend <backend> [{if | unless} <condition>]
  Switch to a specific backend if/unless an ACL-based condition is matched.
  May be used in sections :   defaults | frontend | listen | backend
                                  no   |    yes   |   yes  |   no
  Arguments :
    <backend>   is the name of a valid backend or "listen" section, or a
                "log-format" string resolving to a backend name.

    <condition> is a condition composed of ACLs, as described in section 7. If
                it is omitted, the rule is unconditionally applied.

  When doing content-switching, connections arrive on a frontend and are then
  dispatched to various backends depending on a number of conditions. The
  relation between the conditions and the backends is described with the
  "use_backend" keyword. While it is normally used with HTTP processing, it can
  also be used in pure TCP, either without content using stateless ACLs (e.g.
  source address validation) or combined with a "tcp-request" rule to wait for
  some payload.

  There may be as many "use_backend" rules as desired. All of these rules are
  evaluated in their declaration order, and the first one which matches will
  assign the backend.

  In the first form, the backend will be used if the condition is met. In the
  second form, the backend will be used if the condition is not met. If no
  condition is valid, the backend defined with "default_backend" will be used.
  If no default backend is defined, either the servers in the same section are
  used (in case of a "listen" section) or, in case of a frontend, no server is
  used and a 503 service unavailable response is returned.

  Note that it is possible to switch from a TCP frontend to an HTTP backend. In
  this case, either the frontend has already checked that the protocol is HTTP,
  and backend processing will immediately follow, or the backend will wait for
  a complete HTTP request to get in. This feature is useful when a frontend
  must decode several protocols on a unique port, one of them being HTTP.

  When <backend> is a simple name, it is resolved at configuration time, and an
  error is reported if the specified backend does not exist. If <backend> is
  a log-format string instead, no check may be done at configuration time, so
  the backend name is resolved dynamically at run time. If the resulting
  backend name does not correspond to any valid backend, no other rule is
  evaluated, and the default_backend directive is applied instead. Note that
  when using dynamic backend names, it is highly recommended to use a prefix
  that no other backend uses in order to ensure that an unauthorized backend
  cannot be forced from the request.

  It is worth mentioning that "use_backend" rules with an explicit name are
  used to detect the association between frontends and backends to compute the
  backend's "fullconn" setting. This cannot be done for dynamic names.

  See also: "default_backend", "tcp-request", "fullconn", "log-format", and
            section 7 about ACLs.

use-fcgi-app <name>
  Defines the FastCGI application to use for the backend.
  May be used in sections :   defaults | frontend | listen | backend
                                  no   |    no    |   yes   |   yes
  Arguments :
    <name>    is the name of the FastCGI application to use.

  See section 10.1 about FastCGI application setup for details.

use-server <server> if <condition>
use-server <server> unless <condition>
  Only use a specific server if/unless an ACL-based condition is matched.
  May be used in sections :   defaults | frontend | listen | backend
                                  no   |    no    |   yes  |   yes
  Arguments :
    <server>    is the name of a valid server in the same backend section
                or a "log-format" string resolving to a server name.

    <condition> is a condition composed of ACLs, as described in section 7.

  By default, connections which arrive to a backend are load-balanced across
  the available servers according to the configured algorithm, unless a
  persistence mechanism such as a cookie is used and found in the request.

  Sometimes it is desirable to forward a particular request to a specific
  server without having to declare a dedicated backend for this server. This
  can be achieved using the "use-server" rules. These rules are evaluated after
  the "redirect" rules and before evaluating cookies, and they have precedence
  on them. There may be as many "use-server" rules as desired. All of these
  rules are evaluated in their declaration order, and the first one which
  matches will assign the server.

  If a rule designates a server which is down, and "option persist" is not used
  and no force-persist rule was validated, it is ignored and evaluation goes on
  with the next rules until one matches.

  In the first form, the server will be used if the condition is met. In the
  second form, the server will be used if the condition is not met. If no
  condition is valid, the processing continues and the server will be assigned
  according to other persistence mechanisms.

  Note that even if a rule is matched, cookie processing is still performed but
  does not assign the server. This allows prefixed cookies to have their prefix
  stripped.

  The "use-server" statement works both in HTTP and TCP mode. This makes it
  suitable for use with content-based inspection. For instance, a server could
  be selected in a farm according to the TLS SNI field when using protocols with
  implicit TLS (also see "req.ssl_sni"). And if these servers have their weight
  set to zero, they will not be used for other traffic.

  Example :
     # intercept incoming TLS requests based on the SNI field
     use-server www if { req.ssl_sni -i www.example.com }
     server     www 192.168.0.1:443 weight 0
     use-server mail if { req.ssl_sni -i mail.example.com }
     server     mail 192.168.0.1:465 weight 0
     use-server imap if { req.ssl_sni -i imap.example.com }
     server     imap 192.168.0.1:993 weight 0
     # all the rest is forwarded to this server
     server  default 192.168.0.2:443 check

  When <server> is a simple name, it is checked against existing servers in the
  configuration and an error is reported if the specified server does not exist.
  If it is a log-format, no check is performed when parsing the configuration,
  and if we can't resolve a valid server name at runtime but the use-server rule
  was conditioned by an ACL returning true, no other use-server rule is applied
  and we fall back to load balancing.

  See also: "use_backend", section 5 about server and section 7 about ACLs.

5. Bind and server options

The "bind", "server" and "default-server" keywords support a number of settings
depending on some build options and on the system HAProxy was built on. These
settings generally each consist in one word sometimes followed by a value,
written on the same line as the "bind" or "server" line. All these options are
described in this section.

5.1. Bind options

The "bind" keyword supports a certain number of settings which are all passed
as arguments on the same line. The order in which those arguments appear makes
no importance, provided that they appear after the bind address. All of these
parameters are optional. Some of them consist in a single words (booleans),
while other ones expect a value after them. In this case, the value must be
provided immediately after the setting name.

The currently supported settings are the following ones.

accept-netscaler-cip
Enforces the use of the NetScaler Client IP insertion protocol over any
connection accepted by any of the TCP sockets declared on the same line. The
NetScaler Client IP insertion protocol dictates the layer 3/4 addresses of
the incoming connection to be used everywhere an address is used, with the
only exception of "tcp-request connection" rules which will only see the
real connection address. Logs will reflect the addresses indicated in the
protocol, unless it is violated, in which case the real address will still
be used. This keyword combined with support from external components can be
used as an efficient and reliable alternative to the X-Forwarded-For
mechanism which is not always reliable and not even always usable. See also
"tcp-request connection expect-netscaler-cip" for a finer-grained setting of
which client is allowed to use the protocol.

accept-proxy
Enforces the use of the PROXY protocol over any connection accepted by any of
the sockets declared on the same line. Versions 1 and 2 of the PROXY protocol
are supported and correctly detected. The PROXY protocol dictates the layer
3/4 addresses of the incoming connection to be used everywhere an address is
used, with the only exception of "tcp-request connection" rules which will
only see the real connection address. Logs will reflect the addresses
indicated in the protocol, unless it is violated, in which case the real
address will still be used. This keyword combined with support from external
components can be used as an efficient and reliable alternative to the
X-Forwarded-For mechanism which is not always reliable and not even always
usable. See also "tcp-request connection expect-proxy" for a finer-grained
setting of which client is allowed to use the protocol.

allow-0rtt
Allow receiving early data when using TLSv1.3. This is disabled by default,
due to security considerations. Because it is vulnerable to replay attacks,
you should only allow if for requests that are safe to replay, i.e. requests
that are idempotent. You can use the "wait-for-handshake" action for any
request that wouldn't be safe with early data.

alpn
This enables the TLS ALPN extension and advertises the specified protocol
list as supported on top of ALPN. The protocol list consists in a comma-
delimited list of protocol names, for instance: "http/1.1,http/1.0" (without
quotes). This requires that the SSL library is built with support for TLS
extensions enabled (check with haproxy -vv). The ALPN extension replaces the
initial NPN extension. ALPN is required to enable HTTP/2 on an HTTP frontend.
Versions of OpenSSL prior to 1.0.2 didn't support ALPN and only supposed the
now obsolete NPN extension. At the time of writing this, most browsers still
support both ALPN and NPN for HTTP/2 so a fallback to NPN may still work for
a while. But ALPN must be used whenever possible. If both HTTP/2 and HTTP/1.1
are expected to be supported, both versions can be advertised, in order of
preference, like below :

bind :443 ssl crt pub.pem alpn h2,http/1.1

QUIC supports only h3 and hq-interop as ALPN. h3 is for HTTP/3 and hq-interop
is used for http/0.9 and QUIC interop runner (see https://interop.seemann.io).

backlog
Sets the socket's backlog to this value. If unspecified or 0, the frontend's
backlog is used instead, which generally defaults to the maxconn value.

curves
This setting is only available when support for OpenSSL was built in. It sets
the string describing the list of elliptic curves algorithms ("curve suite")
that are negotiated during the SSL/TLS handshake with ECDHE. The format of the
string is a colon-delimited list of curve name.
Example: "X25519:P-256" (without quote)
When "curves" is set, "ecdhe" parameter is ignored.

ecdhe <named curve>
This setting is only available when support for OpenSSL was built in. It sets
the named curve (RFC 4492) used to generate ECDH ephemeral keys. By default,
used named curve is prime256v1.

ca-file
This setting is only available when support for OpenSSL was built in. It
designates a PEM file from which to load CA certificates used to verify
client's certificate. It is possible to load a directory containing multiple
CAs, in this case HAProxy will try to load every ".pem", ".crt", ".cer", and
.crl" available in the directory, files starting with a dot are ignored.

Warning: The "@system-ca" parameter could be used in place of the cafile
in order to use the trusted CAs of your system, like its done with the server
directive. But you mustn't use it unless you know what you are doing.
Configuring it this way basically mean that the bind will accept any client
certificate generated from one of the CA present on your system, which is
extremely unsecure.

ca-ignore-err [all|,...]
This setting is only available when support for OpenSSL was built in.
Sets a comma separated list of errorIDs to ignore during verify at depth > 0.
If set to 'all', all errors are ignored. SSL handshake is not aborted if an
error is ignored.

ca-sign-file
This setting is only available when support for OpenSSL was built in. It
designates a PEM file containing both the CA certificate and the CA private
key used to create and sign server's certificates. This is a mandatory
setting when the dynamic generation of certificates is enabled. See
'generate-certificates' for details.

ca-sign-pass
This setting is only available when support for OpenSSL was built in. It is
the CA private key passphrase. This setting is optional and used only when
the dynamic generation of certificates is enabled. See
'generate-certificates' for details.

ca-verify-file
This setting designates a PEM file from which to load CA certificates used to
verify client's certificate. It designates CA certificates which must not be
included in CA names sent in server hello message. Typically, "ca-file" must
be defined with intermediate certificates, and "ca-verify-file" with
certificates to ending the chain, like root CA.

ciphers
This setting is only available when support for OpenSSL was built in. It sets
the string describing the list of cipher algorithms ("cipher suite") that are
negotiated during the SSL/TLS handshake up to TLSv1.2. The format of the
string is defined in "man 1 ciphers" from OpenSSL man pages. For background
information and recommendations see e.g.
(https://wiki.mozilla.org/Security/Server_Side_TLS) and
(https://mozilla.github.io/server-side-tls/ssl-config-generator/). For TLSv1.3
cipher configuration, please check the "ciphersuites" keyword.

ciphersuites
This setting is only available when support for OpenSSL was built in and
OpenSSL 1.1.1 or later was used to build HAProxy. It sets the string describing
the list of cipher algorithms ("cipher suite") that are negotiated during the
TLSv1.3 handshake. The format of the string is defined in "man 1 ciphers" from
OpenSSL man pages under the "ciphersuites" section. For cipher configuration
for TLSv1.2 and earlier, please check the "ciphers" keyword.

crl-file
This setting is only available when support for OpenSSL was built in. It
designates a PEM file from which to load certificate revocation list used
to verify client's certificate. You need to provide a certificate revocation
list for every certificate of your certificate authority chain.

crt
This setting is only available when support for OpenSSL was built in. It
designates a PEM file containing both the required certificates and any
associated private keys. This file can be built by concatenating multiple
PEM files into one (e.g. cat cert.pem key.pem > combined.pem). If your CA
requires an intermediate certificate, this can also be concatenated into this
file. Intermediate certificate can also be shared in a directory via
"issuers-chain-path" directive.

If the file does not contain a private key, HAProxy will try to load
the key at the same path suffixed by a ".key".

If the OpenSSL used supports Diffie-Hellman, parameters present in this file
are loaded.

If a directory name is used instead of a PEM file, then all files found in
that directory will be loaded in alphabetic order unless their name ends
with '.key', '.issuer', '.ocsp' or '.sctl' (reserved extensions). Files
starting with a dot are also ignored. This directive may be specified multiple
times in order to load certificates from multiple files or directories. The
certificates will be presented to clients who provide a valid TLS Server Name
Indication field matching one of their CN or alt subjects. Wildcards are
supported, where a wildcard character '*' is used instead of the first
hostname component (e.g. *.example.org matches www.example.org but not
www.sub.example.org).

If no SNI is provided by the client or if the SSL library does not support
TLS extensions, or if the client provides an SNI hostname which does not
match any certificate, then the first loaded certificate will be presented.
This means that when loading certificates from a directory, it is highly
recommended to load the default one first as a file or to ensure that it will
always be the first one in the directory.

Note that the same cert may be loaded multiple times without side effects.

Some CAs (such as GoDaddy) offer a drop down list of server types that do not
include HAProxy when obtaining a certificate. If this happens be sure to
choose a web server that the CA believes requires an intermediate CA (for
GoDaddy, selection Apache Tomcat will get the correct bundle, but many
others, e.g. nginx, result in a wrong bundle that will not work for some
clients).

For each PEM file, HAProxy checks for the presence of file at the same path
suffixed by ".ocsp". If such file is found, support for the TLS Certificate
Status Request extension (also known as "OCSP stapling") is automatically
enabled. The content of this file is optional. If not empty, it must contain
a valid OCSP Response in DER format. In order to be valid an OCSP Response
must comply with the following rules: it has to indicate a good status,
it has to be a single response for the certificate of the PEM file, and it
has to be valid at the moment of addition. If these rules are not respected
the OCSP Response is ignored and a warning is emitted. In order to identify
which certificate an OCSP Response applies to, the issuer's certificate is
necessary. If the issuer's certificate is not found in the PEM file, it will
be loaded from a file at the same path as the PEM file suffixed by ".issuer"
if it exists otherwise it will fail with an error.

For each PEM file, HAProxy also checks for the presence of file at the same
path suffixed by ".sctl". If such file is found, support for Certificate
Transparency (RFC6962) TLS extension is enabled. The file must contain a
valid Signed Certificate Timestamp List, as described in RFC. File is parsed
to check basic syntax, but no signatures are verified.

There are cases where it is desirable to support multiple key types, e.g. RSA
and ECDSA in the cipher suites offered to the clients. This allows clients
that support EC certificates to be able to use EC ciphers, while
simultaneously supporting older, RSA only clients.

To achieve this, OpenSSL 1.1.1 is required, you can configure this behavior
by providing one crt entry per certificate type, or by configuring a "cert
bundle" like it was required before HAProxy 1.8. See "ssl-load-extra-files".

crt-ignore-err
This setting is only available when support for OpenSSL was built in. Sets a
comma separated list of errorIDs to ignore during verify at depth == 0. If
set to 'all', all errors are ignored. SSL handshake is not aborted if an error
is ignored.

crt-list <file>
This setting is only available when support for OpenSSL was built in. It
designates a list of PEM file with an optional ssl configuration and a SNI
filter per certificate, with the following format for each line :

<crtfile> [\[<sslbindconf> ...\]] [[!]<snifilter> ...]

sslbindconf supports "allow-0rtt", "alpn", "ca-file", "ca-verify-file",
"ciphers", "ciphersuites", "crl-file", "curves", "ecdhe", "no-ca-names",
"npn", "verify" configuration. With BoringSSL and Openssl >= 1.1.1
"ssl-min-ver" and "ssl-max-ver" are also supported. It overrides the
configuration set in bind line for the certificate.

Wildcards are supported in the SNI filter. Negative filter are also supported,
useful in combination with a wildcard filter to exclude a particular SNI, or
after the first certificate to exclude a pattern from its CN or Subject Alt
Name (SAN). The certificates will be presented to clients who provide a valid
TLS Server Name Indication field matching one of the SNI filters. If no SNI
filter is specified, the CN and SAN are used. This directive may be specified
multiple times. See the "crt" option for more information. The default
certificate is still needed to meet OpenSSL expectations. If it is not used,
the 'strict-sni' option may be used.

Multi-cert bundling (see "ssl-load-extra-files") is supported with crt-list,
as long as only the base name is given in the crt-list. SNI filter will do
the same work on all bundled certificates.

Empty lines as well as lines beginning with a hash ('#') will be ignored.

The first declared certificate of a bind line is used as the default
certificate, either from crt or crt-list option, which HAProxy should use in
the TLS handshake if no other certificate matches. This certificate will also
be used if the provided SNI matches its CN or SAN, even if a matching SNI
filter is found on any crt-list. The SNI filter !* can be used after the first
declared certificate to not include its CN and SAN in the SNI tree, so it will
never match except if no other certificate matches. This way the first
declared certificate act as a fallback.

crt-list file example:
cert1.pem !*
# comment
cert2.pem [alpn h2,http/1.1]
certW.pem *.domain.tld !secure.domain.tld
certS.pem [curves X25519:P-256 ciphers ECDHE-ECDSA-AES256-GCM-SHA384] secure.domain.tld

defer-accept
Is an optional keyword which is supported only on certain Linux kernels. It
states that a connection will only be accepted once some data arrive on it,
or at worst after the first retransmit. This should be used only on protocols
for which the client talks first (e.g. HTTP). It can slightly improve
performance by ensuring that most of the request is already available when
the connection is accepted. On the other hand, it will not be able to detect
connections which don't talk. It is important to note that this option is
broken in all kernels up to 2.6.31, as the connection is never accepted until
the client talks. This can cause issues with front firewalls which would see
an established connection while the proxy will only see it in SYN_RECV. This
option is only supported on TCPv4/TCPv6 sockets and ignored by other ones.

expose-fd listeners
This option is only usable with the stats socket. It gives your stats socket
the capability to pass listeners FD to another HAProxy process.
In master-worker mode, this is not required anymore, the listeners will be
passed using the internal socketpairs between the master and the workers.
See also "-x" in the management guide.

force-sslv3
This option enforces use of SSLv3 only on SSL connections instantiated from
this listener. SSLv3 is generally less expensive than the TLS counterparts
for high connection rates. This option is also available on global statement
"ssl-default-bind-options". See also "ssl-min-ver" and "ssl-max-ver".

force-tlsv10
This option enforces use of TLSv1.0 only on SSL connections instantiated from
this listener. This option is also available on global statement
"ssl-default-bind-options". See also "ssl-min-ver" and "ssl-max-ver".

force-tlsv11
This option enforces use of TLSv1.1 only on SSL connections instantiated from
this listener. This option is also available on global statement
"ssl-default-bind-options". See also "ssl-min-ver" and "ssl-max-ver".

force-tlsv12
This option enforces use of TLSv1.2 only on SSL connections instantiated from
this listener. This option is also available on global statement
"ssl-default-bind-options". See also "ssl-min-ver" and "ssl-max-ver".

force-tlsv13
This option enforces use of TLSv1.3 only on SSL connections instantiated from
this listener. This option is also available on global statement
"ssl-default-bind-options". See also "ssl-min-ver" and "ssl-max-ver".

generate-certificates
This setting is only available when support for OpenSSL was built in. It
enables the dynamic SSL certificates generation. A CA certificate and its
private key are necessary (see 'ca-sign-file'). When HAProxy is configured as
a transparent forward proxy, SSL requests generate errors because of a common
name mismatch on the certificate presented to the client. With this option
enabled, HAProxy will try to forge a certificate using the SNI hostname
indicated by the client. This is done only if no certificate matches the SNI
hostname (see 'crt-list'). If an error occurs, the default certificate is
used, else the 'strict-sni' option is set.
It can also be used when HAProxy is configured as a reverse proxy to ease the
deployment of an architecture with many backends.

Creating a SSL certificate is an expensive operation, so a LRU cache is used
to store forged certificates (see 'tune.ssl.ssl-ctx-cache-size'). It
increases the HAProxy's memory footprint to reduce latency when the same
certificate is used many times.

gid
Sets the group of the UNIX sockets to the designated system gid. It can also
be set by default in the global section's "unix-bind" statement. Note that
some platforms simply ignore this. This setting is equivalent to the "group"
setting except that the group ID is used instead of its name. This setting is
ignored by non UNIX sockets.

group <group>
Sets the group of the UNIX sockets to the designated system group. It can
also be set by default in the global section's "unix-bind" statement. Note
that some platforms simply ignore this. This setting is equivalent to the
"gid" setting except that the group name is used instead of its gid. This
setting is ignored by non UNIX sockets.

id <id>
Fixes the socket ID. By default, socket IDs are automatically assigned, but
sometimes it is more convenient to fix them to ease monitoring. This value
must be strictly positive and unique within the listener/frontend. This
option can only be used when defining only a single socket.

interface <interface>
Restricts the socket to a specific interface. When specified, only packets
received from that particular interface are processed by the socket. This is
currently only supported on Linux. The interface must be a primary system
interface, not an aliased interface. It is also possible to bind multiple
frontends to the same address if they are bound to different interfaces. Note
that binding to a network interface requires root privileges. This parameter
is only compatible with TCPv4/TCPv6 sockets. When specified, return traffic
uses the same interface as inbound traffic, and its associated routing table,
even if there are explicit routes through different interfaces configured.
This can prove useful to address asymmetric routing issues when the same
client IP addresses need to be able to reach frontends hosted on different
interfaces.

level <level>
This setting is used with the stats sockets only to restrict the nature of
the commands that can be issued on the socket. It is ignored by other
sockets. <level> can be one of :
- "user" is the least privileged level; only non-sensitive stats can be
read, and no change is allowed. It would make sense on systems where it
is not easy to restrict access to the socket.
- "operator" is the default level and fits most common uses. All data can
be read, and only non-sensitive changes are permitted (e.g. clear max
counters).
- "admin" should be used with care, as everything is permitted (e.g. clear
all counters).

severity-output <format>
This setting is used with the stats sockets only to configure severity
level output prepended to informational feedback messages. Severity
level of messages can range between 0 and 7, conforming to syslog
rfc5424. Valid and successful socket commands requesting data
(i.e. "show map", "get acl foo" etc.) will never have a severity level
prepended. It is ignored by other sockets. <format> can be one of :
- "none" (default) no severity level is prepended to feedback messages.
- "number" severity level is prepended as a number.
- "string" severity level is prepended as a string following the
rfc5424 convention.

maxconn
Limits the sockets to this number of concurrent connections. Extraneous
connections will remain in the system's backlog until a connection is
released. If unspecified, the limit will be the same as the frontend's
maxconn. Note that in case of port ranges or multiple addresses, the same
value will be applied to each socket. This setting enables different
limitations on expensive sockets, for instance SSL entries which may easily
eat all memory.

mode
Sets the octal mode used to define access permissions on the UNIX socket. It
can also be set by default in the global section's "unix-bind" statement.
Note that some platforms simply ignore this. This setting is ignored by non
UNIX sockets.

mss
Sets the TCP Maximum Segment Size (MSS) value to be advertised on incoming
connections. This can be used to force a lower MSS for certain specific
ports, for instance for connections passing through a VPN. Note that this
relies on a kernel feature which is theoretically supported under Linux but
was buggy in all versions prior to 2.6.28. It may or may not work on other
operating systems. It may also not change the advertised value but change the
effective size of outgoing segments. The commonly advertised value for TCPv4
over Ethernet networks is 1460 = 1500(MTU) - 40(IP+TCP). If this value is
positive, it will be used as the advertised MSS. If it is negative, it will
indicate by how much to reduce the incoming connection's advertised MSS for
outgoing segments. This parameter is only compatible with TCP v4/v6 sockets.

name <name>
Sets an optional name for these sockets, which will be reported on the stats
page.

namespace <name>
On Linux, it is possible to specify which network namespace a socket will
belong to. This directive makes it possible to explicitly bind a listener to
a namespace different from the default one. Please refer to your operating
system's documentation to find more details about network namespaces.

nice <nice>
Sets the 'niceness' of connections initiated from the socket. Value must be
in the range -1024..1024 inclusive, and defaults to zero. Positive values
means that such connections are more friendly to others and easily offer
their place in the scheduler. On the opposite, negative values mean that
connections want to run with a higher priority than others. The difference
only happens under high loads when the system is close to saturation.
Negative values are appropriate for low-latency or administration services,
and high values are generally recommended for CPU intensive tasks such as SSL
processing or bulk transfers which are less sensible to latency. For example,
it may make sense to use a positive value for an SMTP socket and a negative
one for an RDP socket.

no-ca-names
This setting is only available when support for OpenSSL was built in. It
prevents from send CA names in server hello message when ca-file is used.
Use "ca-verify-file" instead of "ca-file" with "no-ca-names".

no-sslv3
This setting is only available when support for OpenSSL was built in. It
disables support for SSLv3 on any sockets instantiated from the listener when
SSL is supported. Note that SSLv2 is forced disabled in the code and cannot
be enabled using any configuration option. This option is also available on
global statement "ssl-default-bind-options". Use "ssl-min-ver" and
"ssl-max-ver" instead.

no-tls-tickets
This setting is only available when support for OpenSSL was built in. It
disables the stateless session resumption (RFC 5077 TLS Ticket
extension) and force to use stateful session resumption. Stateless
session resumption is more expensive in CPU usage. This option is also
available on global statement "ssl-default-bind-options".
The TLS ticket mechanism is only used up to TLS 1.2.
Forward Secrecy is compromised with TLS tickets, unless ticket keys
are periodically rotated (via reload or by using "tls-ticket-keys").

no-tlsv10
This setting is only available when support for OpenSSL was built in. It
disables support for TLSv1.0 on any sockets instantiated from the listener
when SSL is supported. Note that SSLv2 is forced disabled in the code and
cannot be enabled using any configuration option. This option is also
available on global statement "ssl-default-bind-options". Use "ssl-min-ver"
and "ssl-max-ver" instead.

no-tlsv11
This setting is only available when support for OpenSSL was built in. It
disables support for TLSv1.1 on any sockets instantiated from the listener
when SSL is supported. Note that SSLv2 is forced disabled in the code and
cannot be enabled using any configuration option. This option is also
available on global statement "ssl-default-bind-options". Use "ssl-min-ver"
and "ssl-max-ver" instead.

no-tlsv12
This setting is only available when support for OpenSSL was built in. It
disables support for TLSv1.2 on any sockets instantiated from the listener
when SSL is supported. Note that SSLv2 is forced disabled in the code and
cannot be enabled using any configuration option. This option is also
available on global statement "ssl-default-bind-options". Use "ssl-min-ver"
and "ssl-max-ver" instead.

no-tlsv13
This setting is only available when support for OpenSSL was built in. It
disables support for TLSv1.3 on any sockets instantiated from the listener
when SSL is supported. Note that SSLv2 is forced disabled in the code and
cannot be enabled using any configuration option. This option is also
available on global statement "ssl-default-bind-options". Use "ssl-min-ver"
and "ssl-max-ver" instead.

npn
This enables the NPN TLS extension and advertises the specified protocol list
as supported on top of NPN. The protocol list consists in a comma-delimited
list of protocol names, for instance: "http/1.1,http/1.0" (without quotes).
This requires that the SSL library is built with support for TLS extensions
enabled (check with haproxy -vv). Note that the NPN extension has been
replaced with the ALPN extension (see the "alpn" keyword), though this one is
only available starting with OpenSSL 1.0.2. If HTTP/2 is desired on an older
version of OpenSSL, NPN might still be used as most clients still support it
at the time of writing this. It is possible to enable both NPN and ALPN
though it probably doesn't make any sense out of testing.

prefer-client-ciphers
Use the client's preference when selecting the cipher suite, by default
the server's preference is enforced. This option is also available on
global statement "ssl-default-bind-options".
Note that with OpenSSL >= 1.1.1 ChaCha20-Poly1305 is reprioritized anyway
(without setting this option), if a ChaCha20-Poly1305 cipher is at the top of
the client cipher list.

process <process-set>[/]
This restricts the list of threads on which this listener is allowed to run.
It does not enforce any of them but eliminates those which do not match. Note
that only process number 1 is permitted. If a thread set is specified, it
limits the threads allowed to process incoming connections for this listener.
For the unlikely case where several ranges are needed, this directive may be
repeated. <process-set> and must use the format

all | odd | even | number[-[number]]

Ranges can be partially defined. The higher bound can be omitted. In such a
case, it is replaced by the corresponding maximum value. The main purpose is
to have multiple bind lines sharing the same IP:port but not the same thread
in a listener, so that the system can distribute the incoming connections
into multiple queues, bypassing haproxy's internal queue load balancing.
Currently Linux 3.9 and above is known for supporting this.

This directive is deprecated in favor of the more suited "thread" directive
below, and will be removed in 2.7.

proto <name>
Forces the multiplexer's protocol to use for the incoming connections. It
must be compatible with the mode of the frontend (TCP or HTTP). It must also
be usable on the frontend side. The list of available protocols is reported
in haproxy -vv. The protocols properties are reported : the mode (TCP/HTTP),
the side (FE/BE), the mux name and its flags.

Some protocols are subject to the head-of-line blocking on server side
(flag=HOL_RISK). Finally some protocols don't support upgrades (flag=NO_UPG).
The HTX compatibility is also reported (flag=HTX).

Here are the protocols that may be used as argument to a "proto" directive on
a bind line :

Idea behind this option is to bypass the selection of the best multiplexer's
protocol for all connections instantiated from this listening socket. For
instance, it is possible to force the http/2 on clear TCP by specifying "proto
h2" on the bind line.

quic-cc-algo [ cubic | newreno ]
Warning: QUIC support in HAProxy is currently experimental. Configuration may

This is a QUIC specific setting to select the congestion control algorithm
for any connection attempts to the configured QUIC listeners. They are similar
to those used by TCP.

Default value: cubic

quic-force-retry
Warning: QUIC support in HAProxy is currently experimental. Configuration may
change without deprecation in the future.

This is a QUIC specific setting which forces the use of the QUIC Retry feature
for all the connection attempts to the configured QUIC listeners. It consists
in veryfying the peers are able to receive packets at the transport address
they used to initiate a new connection, sending them a Retry packet which
contains a token. This token must be sent back to the Retry packet sender,
this latter being the only one to be able to validate the token. Note that QUIC
Retry will always be used even if a Retry threshold was set (see
"tune.quic.retry-threshold" setting). To be functional this setting needs a
cluster secret to be set, if not it will be silently ignored (see "cluster-secret"
setting).

See https://www.rfc-editor.org/rfc/rfc9000.html#section-8.1.2 for more
information about QUIC retry.

shards <number> | by-thread
In multi-threaded mode, on operating systems supporting multiple listeners on
the same IP:port, this will automatically create this number of multiple
identical listeners for the same line, all bound to a fair share of the number
of the threads attached to this listener. This can sometimes be useful when
using very large thread counts where the in-kernel locking on a single socket
starts to cause a significant overhead. In this case the incoming traffic is
distributed over multiple sockets and the contention is reduced. Note that
doing this can easily increase the CPU usage by making more threads work a
little bit.

If the number of shards is higher than the number of available threads, it
will automatically be trimmed to the number of threads (i.e. one shard per
thread). The special "by-thread" value also creates as many shards as there
are threads on the "bind" line. Since the system will evenly distribute the
incoming traffic between all these shards, it is important that this number
is an integral divisor of the number of threads.

ssl
This setting is only available when support for OpenSSL was built in. It
enables SSL deciphering on connections instantiated from this listener. A
certificate is necessary (see "crt" above). All contents in the buffers will
appear in clear text, so that ACLs and HTTP processing will only have access
to deciphered contents. SSLv3 is disabled per default, use "ssl-min-ver SSLv3"
to enable it.

ssl-max-ver [ SSLv3 | TLSv1.0 | TLSv1.1 | TLSv1.2 | TLSv1.3 ]
This option enforces use of <version> or lower on SSL connections instantiated
from this listener. Using this setting without "ssl-min-ver" can be
ambiguous because the default ssl-min-ver value could change in future HAProxy
versions. This option is also available on global statement
"ssl-default-bind-options". See also "ssl-min-ver".

ssl-min-ver [ SSLv3 | TLSv1.0 | TLSv1.1 | TLSv1.2 | TLSv1.3 ]
This option enforces use of <version> or upper on SSL connections
instantiated from this listener. The default value is "TLSv1.2". This option
is also available on global statement "ssl-default-bind-options".
See also "ssl-max-ver".

strict-sni
This setting is only available when support for OpenSSL was built in. The
SSL/TLS negotiation is allow only if the client provided an SNI which match
a certificate. The default certificate is not used.
See the "crt" option for more information.

tcp-ut <delay>
Sets the TCP User Timeout for all incoming connections instantiated from this
listening socket. This option is available on Linux since version 2.6.37. It
allows HAProxy to configure a timeout for sockets which contain data not
receiving an acknowledgment for the configured delay. This is especially
useful on long-lived connections experiencing long idle periods such as
remote terminals or database connection pools, where the client and server
timeouts must remain high to allow a long period of idle, but where it is
important to detect that the client has disappeared in order to release all
resources associated with its connection (and the server's session). The
argument is a delay expressed in milliseconds by default. This only works
for regular TCP connections, and is ignored for other protocols.

tfo
Is an optional keyword which is supported only on Linux kernels >= 3.7. It
enables TCP Fast Open on the listening socket, which means that clients which
support this feature will be able to send a request and receive a response
during the 3-way handshake starting from second connection, thus saving one
round-trip after the first connection. This only makes sense with protocols
that use high connection rates and where each round trip matters. This can
possibly cause issues with many firewalls which do not accept data on SYN
packets, so this option should only be enabled once well tested. This option
is only supported on TCPv4/TCPv6 sockets and ignored by other ones. You may
need to build HAProxy with USE_TFO=1 if your libc doesn't define
TCP_FASTOPEN.

thread [/]
This restricts the list of threads on which this listener is allowed to run.
It does not enforce any of them but eliminates those which do not match. It
limits the threads allowed to process incoming connections for this listener.

There are two numbering schemes. By default, thread numbers are absolute in
the process, comprised between 1 and the value specified in global.nbthread.
When thread groups are enabled, the number of a single desired thread group
(starting at 1) may be specified before a slash ('/') before the thread
range. In this case, the thread numbers in the range are relative to the
thread group instead, and start at 1 for each thread group. Absolute and
relative thread numbers may be used interchangeably but they must not be
mixed on a single "bind" line, as those not set will be resolved at the end
of the parsing.

For the unlikely case where several ranges are needed, this directive may be
repeated. It is not permitted to use different thread groups even when using
multiple directives. The specification must use the format:

all | odd | even | number[-[number]]

tls-ticket-keys <keyfile>
Sets the TLS ticket keys file to load the keys from. The keys need to be 48
or 80 bytes long, depending if aes128 or aes256 is used, encoded with base64
with one line per key (ex. openssl rand 80 | openssl base64 -A | xargs echo).
The first key determines the key length used for next keys: you can't mix
aes128 and aes256 keys. Number of keys is specified by the TLS_TICKETS_NO
build option (default 3) and at least as many keys need to be present in
the file. Last TLS_TICKETS_NO keys will be used for decryption and the
penultimate one for encryption. This enables easy key rotation by just
appending new key to the file and reloading the process. Keys must be
periodically rotated (ex. every 12h) or Perfect Forward Secrecy is
compromised. It is also a good idea to keep the keys off any permanent
storage such as hard drives (hint: use tmpfs and don't swap those files).
Lifetime hint can be changed using tune.ssl.timeout.

transparent
Is an optional keyword which is supported only on certain Linux kernels. It
indicates that the addresses will be bound even if they do not belong to the
local machine, and that packets targeting any of these addresses will be
intercepted just as if the addresses were locally configured. This normally
requires that IP forwarding is enabled. Caution! do not use this with the
default address '*', as it would redirect any traffic for the specified port.
This keyword is available only when HAProxy is built with USE_LINUX_TPROXY=1.
This parameter is only compatible with TCPv4 and TCPv6 sockets, depending on
kernel version. Some distribution kernels include backports of the feature,
so check for support with your vendor.

v4v6
Is an optional keyword which is supported only on most recent systems
including Linux kernels >= 2.4.21. It is used to bind a socket to both IPv4
and IPv6 when it uses the default address. Doing so is sometimes necessary
on systems which bind to IPv6 only by default. It has no effect on non-IPv6
sockets, and is overridden by the "v6only" option.

v6only
Is an optional keyword which is supported only on most recent systems
including Linux kernels >= 2.4.21. It is used to bind a socket to IPv6 only
when it uses the default address. Doing so is sometimes preferred to doing it
system-wide as it is per-listener. It has no effect on non-IPv6 sockets and
has precedence over the "v4v6" option.

uid
Sets the owner of the UNIX sockets to the designated system uid. It can also
be set by default in the global section's "unix-bind" statement. Note that
some platforms simply ignore this. This setting is equivalent to the "user"
setting except that the user numeric ID is used instead of its name. This
setting is ignored by non UNIX sockets.

user <user>
Sets the owner of the UNIX sockets to the designated system user. It can also
be set by default in the global section's "unix-bind" statement. Note that
some platforms simply ignore this. This setting is equivalent to the "uid"
setting except that the user name is used instead of its uid. This setting is
ignored by non UNIX sockets.

verify [none|optional|required]
This setting is only available when support for OpenSSL was built in. If set
to 'none', client certificate is not requested. This is the default. In other
cases, a client certificate is requested. If the client does not provide a
certificate after the request and if 'verify' is set to 'required', then the
handshake is aborted, while it would have succeeded if set to 'optional'. The
certificate provided by the client is always verified using CAs from
'ca-file' and optional CRLs from 'crl-file'. On verify failure the handshake
is aborted, regardless of the 'verify' option, unless the error code exactly
matches one of those listed with 'ca-ignore-err' or 'crt-ignore-err'.

5.2. Server and default-server options

The "server" and "default-server" keywords support a certain number of settings
which are all passed as arguments on the server line. The order in which those
arguments appear does not count, and they are all optional. Some of those
settings are single words (booleans) while others expect one or several values
after them. In this case, the values must immediately follow the setting name.
Except default-server, all those settings must be specified after the server's
address if they are used:

server <name> <address>[:port] [settings ...]
default-server [settings ...]

Note that all these settings are supported both by "server" and "default-server"
keywords, except "id" which is only supported by "server".

The currently supported settings are the following ones.

addr <ipv4|ipv6>
Using the "addr" parameter, it becomes possible to use a different IP address
to send health-checks or to probe the agent-check. On some servers, it may be
desirable to dedicate an IP address to specific component able to perform
complex tests which are more suitable to health-checks than the application.
This parameter is ignored if the "check" parameter is not set. See also the
"port" parameter.

agent-check
Enable an auxiliary agent check which is run independently of a regular
health check. An agent health check is performed by making a TCP connection
to the port set by the "agent-port" parameter and reading an ASCII string
terminated by the first '\r' or '\n' met. The string is made of a series of
words delimited by spaces, tabs or commas in any order, each consisting of :

- An ASCII representation of a positive integer percentage, e.g. "75%".
Values in this format will set the weight proportional to the initial
weight of a server as configured when HAProxy starts. Note that a zero
weight is reported on the stats page as "DRAIN" since it has the same
effect on the server (it's removed from the LB farm).

- The string "maxconn:" followed by an integer (no space between). Values
in this format will set the maxconn of a server. The maximum number of
connections advertised needs to be multiplied by the number of load
balancers and different backends that use this health check to get the
total number of connections the server might receive. Example: maxconn:30

- The word "ready". This will turn the server's administrative state to the
READY mode, thus canceling any DRAIN or MAINT state

- The word "drain". This will turn the server's administrative state to the
DRAIN mode, thus it will not accept any new connections other than those
that are accepted via persistence.

- The word "maint". This will turn the server's administrative state to the
MAINT mode, thus it will not accept any new connections at all, and health
checks will be stopped.

- The words "down", "fail", or "stopped", optionally followed by a
description string after a sharp ('#'). All of these mark the server's
operating state as DOWN, but since the word itself is reported on the stats
page, the difference allows an administrator to know if the situation was
expected or not : the service may intentionally be stopped, may appear up
but fail some validity tests, or may be seen as down (e.g. missing process,
or port not responding).

- The word "up" sets back the server's operating state as UP if health checks
also report that the service is accessible.

Parameters which are not advertised by the agent are not changed. For
example, an agent might be designed to monitor CPU usage and only report a
relative weight and never interact with the operating status. Similarly, an
agent could be designed as an end-user interface with 3 radio buttons
allowing an administrator to change only the administrative state. However,
it is important to consider that only the agent may revert its own actions,
so if a server is set to DRAIN mode or to DOWN state using the agent, the
agent must implement the other equivalent actions to bring the service into
operations again.

Failure to connect to the agent is not considered an error as connectivity
is tested by the regular health check which is enabled by the "check"
parameter. Warning though, it is not a good idea to stop an agent after it
reports "down", since only an agent reporting "up" will be able to turn the
server up again. Note that the CLI on the Unix stats socket is also able to
force an agent's result in order to work around a bogus agent if needed.

Requires the "agent-port" parameter to be set. See also the "agent-inter"
and "no-agent-check" parameters.

agent-send <string>
If this option is specified, HAProxy will send the given string (verbatim)
to the agent server upon connection. You could, for example, encode
the backend name into this string, which would enable your agent to send
different responses based on the backend. Make sure to include a '\n' if
you want to terminate your request with a newline.

agent-inter <delay>
The "agent-inter" parameter sets the interval between two agent checks
to <delay> milliseconds. If left unspecified, the delay defaults to 2000 ms.

Just as with every other time-based parameter, it may be entered in any
other explicit unit among { us, ms, s, m, h, d }. The "agent-inter"
parameter also serves as a timeout for agent checks "timeout check" is
not set. In order to reduce "resonance" effects when multiple servers are
hosted on the same hardware, the agent and health checks of all servers
are started with a small time offset between them. It is also possible to
add some random noise in the agent and health checks interval using the
global "spread-checks" keyword. This makes sense for instance when a lot
of backends use the same servers.

See also the "agent-check" and "agent-port" parameters.

agent-addr <addr>
The "agent-addr" parameter sets address for agent check.

You can offload agent-check to another target, so you can make single place
managing status and weights of servers defined in HAProxy in case you can't
make self-aware and self-managing services. You can specify both IP or
hostname, it will be resolved.

agent-port <port>
The "agent-port" parameter sets the TCP port used for agent checks.

See also the "agent-check" and "agent-inter" parameters.

allow-0rtt
Allow sending early data to the server when using TLS 1.3.
Note that early data will be sent only if the client used early data, or
if the backend uses "retry-on" with the "0rtt-rejected" keyword.

alpn
This enables the TLS ALPN extension and advertises the specified protocol
list as supported on top of ALPN. The protocol list consists in a comma-
delimited list of protocol names, for instance: "http/1.1,http/1.0" (without
quotes). This requires that the SSL library is built with support for TLS
extensions enabled (check with haproxy -vv). The ALPN extension replaces the
initial NPN extension. ALPN is required to connect to HTTP/2 servers.
Versions of OpenSSL prior to 1.0.2 didn't support ALPN and only supposed the
now obsolete NPN extension.
If both HTTP/2 and HTTP/1.1 are expected to be supported, both versions can
be advertised, in order of preference, like below :

server 127.0.0.1:443 ssl crt pub.pem alpn h2,http/1.1

See also "ws" to use an alternative ALPN for websocket streams.

backup
When "backup" is present on a server line, the server is only used in load
balancing when all other non-backup servers are unavailable. Requests coming
with a persistence cookie referencing the server will always be served
though. By default, only the first operational backup server is used, unless
the "allbackups" option is set in the backend. See also the "no-backup" and
"allbackups" options.

ca-file
This setting is only available when support for OpenSSL was built in. It
designates a PEM file from which to load CA certificates used to verify
server's certificate. It is possible to load a directory containing multiple
CAs, in this case HAProxy will try to load every ".pem", ".crt", ".cer", and
.crl" available in the directory, files starting with a dot are ignored.

In order to use the trusted CAs of your system, the "@system-ca" parameter
could be used in place of the cafile. The location of this directory could be
overwritten by setting the SSL_CERT_DIR environment variable.

check
This option enables health checks on a server:
- when not set, no health checking is performed, and the server is always
considered available.
- when set and no other check method is configured, the server is considered
available when a connection can be established at the highest configured
transport layer. This means TCP by default, or SSL/TLS when "ssl" or
"check-ssl" are set, both possibly combined with connection prefixes such
as a PROXY protocol header when "send-proxy" or "check-send-proxy" are
set. This behavior is slightly different for dynamic servers, read the
following paragraphs for more details.
- when set and an application-level health check is defined, the
application-level exchanges are performed on top of the configured
transport layer and the server is considered available if all of the
exchanges succeed.

By default, health checks are performed on the same address and port as
configured on the server, using the same encapsulation parameters (SSL/TLS,
proxy-protocol header, etc... ). It is possible to change the destination
address using "addr" and the port using "port". When done, it is assumed the
server isn't checked on the service port, and configured encapsulation
parameters are not reused. One must explicitly set "check-send-proxy" to send
connection headers, "check-ssl" to use SSL/TLS.

Note that the implicit configuration of ssl and PROXY protocol is not
performed for dynamic servers. In this case, it is required to explicitly
use "check-ssl" and "check-send-proxy" when wanted, even if the check port is
not overridden.

When "sni" or "alpn" are set on the server line, their value is not used for
health checks and one must use "check-sni" or "check-alpn".

The default source address for health check traffic is the same as the one
defined in the backend. It can be changed with the "source" keyword.

The interval between checks can be set using the "inter" keyword, and the
"rise" and "fall" keywords can be used to define how many successful or
failed health checks are required to flag a server available or not
available.

Optional application-level health checks can be configured with "option
httpchk", "option mysql-check" "option smtpchk", "option pgsql-check",
"option ldap-check", or "option redis-check".

Example:
# simple tcp check
backend foo
server s1 192.168.0.1:80 check
# this does a tcp connect + tls handshake
backend foo
server s1 192.168.0.1:443 ssl check
# simple tcp check is enough for check success
backend foo
option tcp-check
tcp-check connect
server s1 192.168.0.1:443 ssl check

check-send-proxy
This option forces emission of a PROXY protocol line with outgoing health
checks, regardless of whether the server uses send-proxy or not for the
normal traffic. By default, the PROXY protocol is enabled for health checks
if it is already enabled for normal traffic and if no "port" nor "addr"
directive is present. However, if such a directive is present, the
"check-send-proxy" option needs to be used to force the use of the
protocol. See also the "send-proxy" option for more information.

check-alpn
Defines which protocols to advertise with ALPN. The protocol list consists in
a comma-delimited list of protocol names, for instance: "http/1.1,http/1.0"
(without quotes). If it is not set, the server ALPN is used.

check-proto <name>
Forces the multiplexer's protocol to use for the server's health-check
connections. It must be compatible with the health-check type (TCP or
HTTP). It must also be usable on the backend side. The list of available
protocols is reported in haproxy -vv. The protocols properties are
reported : the mode (TCP/HTTP), the side (FE/BE), the mux name and its flags.

Some protocols are subject to the head-of-line blocking on server side
(flag=HOL_RISK). Finally some protocols don't support upgrades (flag=NO_UPG).
The HTX compatibility is also reported (flag=HTX).

Here are the protocols that may be used as argument to a "check-proto"
directive on a server line:

Idea behind this option is to bypass the selection of the best multiplexer's
protocol for health-check connections established to this server.
If not defined, the server one will be used, if set.

check-sni <sni>
This option allows you to specify the SNI to be used when doing health checks
over SSL. It is only possible to use a string to set <sni>. If you want to
set a SNI for proxied traffic, see "sni".

check-ssl
This option forces encryption of all health checks over SSL, regardless of
whether the server uses SSL or not for the normal traffic. This is generally
used when an explicit "port" or "addr" directive is specified and SSL health
checks are not inherited. It is important to understand that this option
inserts an SSL transport layer below the checks, so that a simple TCP connect
check becomes an SSL connect, which replaces the old ssl-hello-chk. The most
common use is to send HTTPS checks by combining "httpchk" with SSL checks.
All SSL settings are common to health checks and traffic (e.g. ciphers).
See the "ssl" option for more information and "no-check-ssl" to disable
this option.

check-via-socks4
This option enables outgoing health checks using upstream socks4 proxy. By
default, the health checks won't go through socks tunnel even it was enabled
for normal traffic.

ciphers
This setting is only available when support for OpenSSL was built in. This
option sets the string describing the list of cipher algorithms that is
negotiated during the SSL/TLS handshake with the server. The format of the
string is defined in "man 1 ciphers" from OpenSSL man pages. For background
information and recommendations see e.g.
(https://wiki.mozilla.org/Security/Server_Side_TLS) and
(https://mozilla.github.io/server-side-tls/ssl-config-generator/). For TLSv1.3
cipher configuration, please check the "ciphersuites" keyword.

ciphersuites
This setting is only available when support for OpenSSL was built in and
OpenSSL 1.1.1 or later was used to build HAProxy. This option sets the string
describing the list of cipher algorithms that is negotiated during the TLS
1.3 handshake with the server. The format of the string is defined in
"man 1 ciphers" from OpenSSL man pages under the "ciphersuites" section.
For cipher configuration for TLSv1.2 and earlier, please check the "ciphers"
keyword.

cookie <value>
The "cookie" parameter sets the cookie value assigned to the server to
<value>. This value will be checked in incoming requests, and the first
operational server possessing the same value will be selected. In return, in
cookie insertion or rewrite modes, this value will be assigned to the cookie
sent to the client. There is nothing wrong in having several servers sharing
the same cookie value, and it is in fact somewhat common between normal and
backup servers. See also the "cookie" keyword in backend section.

crl-file
This setting is only available when support for OpenSSL was built in. It
designates a PEM file from which to load certificate revocation list used
to verify server's certificate.

crt
This setting is only available when support for OpenSSL was built in.
It designates a PEM file from which to load both a certificate and the
associated private key. This file can be built by concatenating both PEM
files into one. This certificate will be sent if the server send a client
certificate request.

If the file does not contain a private key, HAProxy will try to load the key
at the same path suffixed by a ".key" (provided the "ssl-load-extra-files"
option is set accordingly).

disabled
The "disabled" keyword starts the server in the "disabled" state. That means
that it is marked down in maintenance mode, and no connection other than the
ones allowed by persist mode will reach it. It is very well suited to setup
new servers, because normal traffic will never reach them, while it is still
possible to test the service by making use of the force-persist mechanism.
See also "enabled" setting.

enabled
This option may be used as 'server' setting to reset any 'disabled'
setting which would have been inherited from 'default-server' directive as
default value.
It may also be used as 'default-server' setting to reset any previous
'default-server' 'disabled' setting.

error-limit <count>
If health observing is enabled, the "error-limit" parameter specifies the
number of consecutive errors that triggers event selected by the "on-error"
option. By default it is set to 10 consecutive errors.

See also the "check", "error-limit" and "on-error".

fall <count>
The "fall" parameter states that a server will be considered as dead after
<count> consecutive unsuccessful health checks. This value defaults to 3 if
unspecified. See also the "check", "inter" and "rise" parameters.

force-sslv3
This option enforces use of SSLv3 only when SSL is used to communicate with
the server. SSLv3 is generally less expensive than the TLS counterparts for
high connection rates. This option is also available on global statement
"ssl-default-server-options". See also "ssl-min-ver" and ssl-max-ver".

force-tlsv10
This option enforces use of TLSv1.0 only when SSL is used to communicate with
the server. This option is also available on global statement
"ssl-default-server-options". See also "ssl-min-ver" and ssl-max-ver".

force-tlsv11
This option enforces use of TLSv1.1 only when SSL is used to communicate with
the server. This option is also available on global statement
"ssl-default-server-options". See also "ssl-min-ver" and ssl-max-ver".

force-tlsv12
This option enforces use of TLSv1.2 only when SSL is used to communicate with
the server. This option is also available on global statement
"ssl-default-server-options". See also "ssl-min-ver" and ssl-max-ver".

force-tlsv13
This option enforces use of TLSv1.3 only when SSL is used to communicate with
the server. This option is also available on global statement
"ssl-default-server-options". See also "ssl-min-ver" and ssl-max-ver".

id <value>
Set a persistent ID for the server. This ID must be positive and unique for
the proxy. An unused ID will automatically be assigned if unset. The first
assigned value will be 1. This ID is currently only returned in statistics.

init-addr {last | libc | none | <ip>},[...]*
Indicate in what order the server's address should be resolved upon startup
if it uses an FQDN. Attempts are made to resolve the address by applying in
turn each of the methods mentioned in the comma-delimited list. The first
method which succeeds is used. If the end of the list is reached without
finding a working method, an error is thrown. Method "last" suggests to pick
the address which appears in the state file (see "server-state-file"). Method
"libc" uses the libc's internal resolver (gethostbyname() or getaddrinfo()
depending on the operating system and build options). Method "none"
specifically indicates that the server should start without any valid IP
address in a down state. It can be useful to ignore some DNS issues upon
startup, waiting for the situation to get fixed later. Finally, an IP address
(IPv4 or IPv6) may be provided. It can be the currently known address of the
server (e.g. filled by a configuration generator), or the address of a dummy
server used to catch old sessions and present them with a decent error
message for example. When the "first" load balancing algorithm is used, this
IP address could point to a fake server used to trigger the creation of new
instances on the fly. This option defaults to "last,libc" indicating that the
previous address found in the state file (if any) is used first, otherwise
the libc's resolver is used. This ensures continued compatibility with the
historic behavior.

Example:
defaults
# never fail on address resolution
default-server init-addr last,libc,none

inter <delay>
fastinter <delay>
downinter <delay>
The "inter" parameter sets the interval between two consecutive health checks
to <delay> milliseconds. If left unspecified, the delay defaults to 2000 ms.
It is also possible to use "fastinter" and "downinter" to optimize delays
between checks depending on the server state :
"inter" 매개변수는 두 개의 연속 상태 확인 사이의 간격을 <delay>밀리초로 설정합니다.
지정하지 않은 경우 지연은 기본적으로 2000ms입니다.
서버 상태에 따라 검사 간 지연을 최적화하기 위해 "fastinter" 및 "downinter"를 사용할 수도 있습니다.

Server state | Interval used
----------------------------------------+----------------------------------
UP 100% (non-transitional) | "inter"
----------------------------------------+----------------------------------
Transitionally UP (going down "fall"), | "fastinter" if set,
Transitionally DOWN (going up "rise"), | "inter" otherwise.
or yet unchecked. |
----------------------------------------+----------------------------------
DOWN 100% (non-transitional) | "downinter" if set,
| "inter" otherwise.
----------------------------------------+----------------------------------

Just as with every other time-based parameter, they can be entered in any
other explicit unit among { us, ms, s, m, h, d }. The "inter" parameter also
serves as a timeout for health checks sent to servers if "timeout check" is
not set. In order to reduce "resonance" effects when multiple servers are
hosted on the same hardware, the agent and health checks of all servers
are started with a small time offset between them. It is also possible to
add some random noise in the agent and health checks interval using the
global "spread-checks" keyword. This makes sense for instance when a lot
of backends use the same servers.

다른 모든 시간 기반 매개변수와 마찬가지로 {us, ms, s, m, h, d} 중에서 다른 명시적
단위로 입력할 수 있습니다. "inter" 매개변수는 "timeout check"가 설정되지 않은 경우
서버로 전송되는 상태 확인에 대한 시간 초과 역할도 합니다.
여러 서버가 동일한 하드웨어에서 호스팅될 때 "공명(울림 resonance)" 효과를 줄이기 위해
모든 서버의 에이전트 및 상태 검사가 그들 사이에 작은 시간 오프셋으로 시작됩니다.
전역 "확산 검사(spread-checks)" 키워드를 사용하여 에이전트 및 상태 검사 간격에 임의의
노이즈를 추가할 수도 있습니다. 이는 예를 들어 많은 백엔드가 동일한 서버를 사용하는
경우에 적합합니다.

log-proto
The "log-proto" specifies the protocol used to forward event messages to
a server configured in a ring section. Possible values are "legacy"
and "octet-count" corresponding respectively to "Non-transparent-framing"
and "Octet counting" in rfc6587. "legacy" is the default.

maxconn
The "maxconn" parameter specifies the maximal number of concurrent
connections that will be sent to this server. If the number of incoming
concurrent connections goes higher than this value, they will be queued,
waiting for a slot to be released. This parameter is very important as it can
save fragile servers from going down under extreme loads. If a "minconn"
parameter is specified, the limit becomes dynamic. The default value is "0"
which means unlimited. See also the "minconn" and "maxqueue" parameters, and
the backend's "fullconn" keyword.

In HTTP mode this parameter limits the number of concurrent requests instead
of the number of connections. Multiple requests might be multiplexed over a
single TCP connection to the server. As an example if you specify a maxconn
of 50 you might see between 1 and 50 actual server connections, but no more
than 50 concurrent requests.

maxqueue
The "maxqueue" parameter specifies the maximal number of connections which
will wait in the queue for this server. If this limit is reached, next
requests will be redispatched to other servers instead of indefinitely
waiting to be served. This will break persistence but may allow people to
quickly re-log in when the server they try to connect to is dying. Some load
balancing algorithms such as leastconn take this into account and accept to
add requests into a server's queue up to this value if it is explicitly set
to a value greater than zero, which often allows to better smooth the load
when dealing with single-digit maxconn values. The default value is "0" which
means the queue is unlimited. See also the "maxconn" and "minconn" parameters
and "balance leastconn".

max-reuse <count>
The "max-reuse" argument indicates the HTTP connection processors that they
should not reuse a server connection more than this number of times to send
new requests. Permitted values are -1 (the default), which disables this
limit, or any positive value. Value zero will effectively disable keep-alive.
This is only used to work around certain server bugs which cause them to leak
resources over time. The argument is not necessarily respected by the lower
layers as there might be technical limitations making it impossible to
enforce. At least HTTP/2 connections to servers will respect it.

minconn <minconn>
When the "minconn" parameter is set, the maxconn limit becomes a dynamic
limit following the backend's load. The server will always accept at least
<minconn> connections, never more than , and the limit will be on
the ramp between both values when the backend has less than
concurrent connections. This makes it possible to limit the load on the
server during normal loads, but push it further for important loads without
overloading the server during exceptional loads. See also the "maxconn"
and "maxqueue" parameters, as well as the "fullconn" backend keyword.

namespace <name>
On Linux, it is possible to specify which network namespace a socket will
belong to. This directive makes it possible to explicitly bind a server to
a namespace different from the default one. Please refer to your operating
system's documentation to find more details about network namespaces.

no-agent-check
This option may be used as "server" setting to reset any "agent-check"
setting which would have been inherited from "default-server" directive as
default value.
It may also be used as "default-server" setting to reset any previous
"default-server" "agent-check" setting.

no-backup
This option may be used as "server" setting to reset any "backup"
setting which would have been inherited from "default-server" directive as
default value.
It may also be used as "default-server" setting to reset any previous
"default-server" "backup" setting.

no-check
This option may be used as "server" setting to reset any "check"
setting which would have been inherited from "default-server" directive as
default value.
It may also be used as "default-server" setting to reset any previous
"default-server" "check" setting.

no-check-ssl
This option may be used as "server" setting to reset any "check-ssl"
setting which would have been inherited from "default-server" directive as
default value.
It may also be used as "default-server" setting to reset any previous
"default-server" "check-ssl" setting.

no-send-proxy
This option may be used as "server" setting to reset any "send-proxy"
setting which would have been inherited from "default-server" directive as
default value.
It may also be used as "default-server" setting to reset any previous
"default-server" "send-proxy" setting.

no-send-proxy-v2
This option may be used as "server" setting to reset any "send-proxy-v2"
setting which would have been inherited from "default-server" directive as
default value.
It may also be used as "default-server" setting to reset any previous
"default-server" "send-proxy-v2" setting.

no-send-proxy-v2-ssl
This option may be used as "server" setting to reset any "send-proxy-v2-ssl"
setting which would have been inherited from "default-server" directive as
default value.
It may also be used as "default-server" setting to reset any previous
"default-server" "send-proxy-v2-ssl" setting.

no-send-proxy-v2-ssl-cn
This option may be used as "server" setting to reset any "send-proxy-v2-ssl-cn"
setting which would have been inherited from "default-server" directive as
default value.
It may also be used as "default-server" setting to reset any previous
"default-server" "send-proxy-v2-ssl-cn" setting.

no-ssl
This option may be used as "server" setting to reset any "ssl"
setting which would have been inherited from "default-server" directive as
default value.
It may also be used as "default-server" setting to reset any previous
"default-server" "ssl" setting.

Note that using `default-server ssl` setting and `no-ssl` on server will
however init SSL connection, so it can be later be enabled through the
runtime API: see `set server` commands in management doc.

no-ssl-reuse
This option disables SSL session reuse when SSL is used to communicate with
the server. It will force the server to perform a full handshake for every
new connection. It's probably only useful for benchmarking, troubleshooting,
and for paranoid users.

no-sslv3
This option disables support for SSLv3 when SSL is used to communicate with
the server. Note that SSLv2 is disabled in the code and cannot be enabled
using any configuration option. Use "ssl-min-ver" and "ssl-max-ver" instead.