HAProxy Configuration


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가 시작된 경우 수퍼유저 권한으로 시작된 경우에만 
  이러한 그룹을 삭제할 수 있습니다.
  
  See also "group" and "uid".		

grace <time>		
  Defines a delay between SIGUSR1 and real soft-stop.
  SIGUSR1과 실제 소프트 스톱 사이의 지연을 정의합니다.

  Arguments :
    <time>  is an extra delay (by default in milliseconds) after receipt of the
            SIGUSR1 signal that will be waited for before proceeding with the
            soft-stop operation.
    <time>은 SIGUSR1 신호 수신 후 소프트 스톱 작동을 진행하기 전에 대기할 추가 
	        지연 시간(기본적으로 밀리초 단위)입니다.

  This is used for compatibility with legacy environments where the haproxy
  process needs to be stopped but some external components need to detect the
  status before listeners are unbound. The principle is that the internal
  "stopping" variable (which is reported by the "stopping" sample fetch
  function) will be turned to true, but listeners will continue to accept
  connections undisturbed, until the delay expires, after what the regular
  soft-stop will proceed. This must not be used with processes that are
  reloaded, or this will prevent the old process from unbinding, and may
  prevent the new one from starting, or simply cause trouble.
  
  이는 haproxy 프로세스를 중지해야 하지만 일부 외부 구성 요소가 리스너가 바인딩 
  해제되기 전에 상태를 감지해야 하는 레거시 환경과의 호환성을 위해 사용됩니다.
  원칙은 내부 "stopping" 변수("stopping" 샘플 가져오기 기능에 의해 보고됨)가 true로 
  바뀌지만 수신기는 방해받지 않고 지연이 만료될 때까지 연결을 계속 수락한다는 것입니다.  
  그 후 일반 소프트 스톱이 진행됩니다.
  이것은 다시 로드되는 프로세스와 함께 사용하면 안 됩니다. 그렇지 않으면 이전 프로세스의 
  바인딩이 해제되지 않고 새 프로세스가 시작되지 않거나 단순히 문제가 발생할 수 있습니다.  
  Example:

    global
      grace 10s

    # Returns 200 OK until stopping is set via SIGUSR1
    frontend ext-check
      bind :9999
      monitor-uri /ext-check
      monitor fail if { stopping }
  Please note that a more flexible and durable approach would instead consist
  for an orchestration system in setting a global variable from the CLI, use
  that variable to respond to external checks, then after a delay send the
  SIGUSR1 signal.
  보다 유연하고 내구성 있는 접근 방식은 오케스트레이션 시스템이 CLI에서 전역 변수를 
  설정하고 해당 변수를 사용하여 외부 검사에 응답한 다음 지연 후 SIGUSR1 신호를 보내는 
  것으로 대신 구성된다는 점에 유의하십시오.
  Example:

    # Returns 200 OK until proc.stopping is set to non-zero. May be done
    # from HTTP using set-var(proc.stopping) or from the CLI using:
    # > set var proc.stopping int(1)
    frontend ext-check
      bind :9999
      monitor-uri /ext-check
      monitor fail if { var(proc.stopping) -m int gt 0 }

  See also: hard-stop-after, monitor
group <group name>	
  Similar to "gid" but uses the GID of group name <group name> from /etc/group.
  "gid"와 유사하지만 /etc/group에서 그룹 이름 <group name>의 GID를 사용합니다.
  See also "gid" and "user".	

hard-stop-after <time>			
  Defines the maximum time allowed to perform a clean soft-stop.	
  깨끗한 소프트 스톱을 수행하는 데 허용되는 최대 시간을 정의합니다.

  Arguments :	
    <time>  is the maximum time (by default in milliseconds) for which the
            instance will remain alive when a soft-stop is received via the
            SIGUSR1 signal.	
    <time>은 SIGUSR1 신호를 통해 소프트 스톱이 수신될 때 인스턴스가 활성 상태로 
            유지되는 최대 시간(기본적으로 밀리초)입니다.

  This may be used to ensure that the instance will quit even if connections
  remain opened during a soft-stop (for example with long timeouts for a proxy
  in tcp mode). It applies both in TCP and HTTP mode.
  이는 소프트 스톱(예: tcp 모드에서 프록시에 대한 긴 시간 초과) 중에 연결이 열린 상태로 
  유지되더라도 인스턴스가 종료되도록 하는 데 사용할 수 있습니다.
  TCP 및 HTTP 모드 모두에 적용됩니다.
  Example:
    global
      hard-stop-after 30s

  See also: grace
h1-accept-payload-with-any-method		
  Does not reject HTTP/1.0 GET/HEAD/DELETE requests with a payload.
  페이로드가 있는 HTTP/1.0 GET/HEAD/DELETE 요청을 거부하지 않습니다.

  While It is explicitly allowed in HTTP/1.1, HTTP/1.0 is not clear on this
  point and some old servers don't expect any payload and never look for body
  length (via Content-Length or Transfer-Encoding headers). It means that some
  intermediaries may properly handle the payload for HTTP/1.0 GET/HEAD/DELETE
  requests, while some others may totally ignore it. That may lead to security
  issues because a request smuggling attack is possible. Thus, by default,
  HAProxy rejects HTTP/1.0 GET/HEAD/DELETE requests with a payload.

  HTTP/1.1에서는 명시적으로 허용되지만 HTTP/1.0은 이 시점에서 명확하지 않으며 
  일부 오래된 서버는 페이로드를 기대하지 않고 본문 길이를 찾지 않습니다
  (Content-Length 또는 Transfer-Encoding 헤더를 통해).
  이는 일부 중개자가 HTTP/1.0 GET/HEAD/DELETE 요청에 대한 페이로드를 적절하게 
  처리할 수 있는 반면 일부 중개자는 이를 완전히 무시할 수 있음을 의미합니다.
  요청 밀수 공격이 가능하기 때문에 보안 문제가 발생할 수 있습니다.
  따라서 기본적으로 HAProxy는 페이로드가 포함된 HTTP/1.0 GET/HEAD/DELETE 요청을 
  거부합니다.

  However, it may be an issue with some old clients. In this case, this global
  option may be set.
  그러나 일부 오래된 클라이언트에서는 문제가 될 수 있습니다. 
  이 경우 이 전역 옵션을 설정할 수 있습니다.

h1-case-adjust <from> <to>		
  Defines the case adjustment to apply, when enabled, to the header name
  <from>, to change it to <to> before sending it to HTTP/1 clients or
  servers. <from> must be in lower case, and <from> and <to> must not differ
  except for their case. It may be repeated if several header names need to be
  adjusted. Duplicate entries are not allowed. If a lot of header names have to
  be adjusted, it might be more convenient to use "h1-case-adjust-file".
  Please note that no transformation will be applied unless "option
  h1-case-adjust-bogus-client" or "option h1-case-adjust-bogus-server" is
  specified in a proxy.
  
  활성화된 경우 헤더 이름 <from>에 적용할 대소문자 조정을 정의하여 헤더 이름을 
  HTTP/1 클라이언트 또는 서버로 보내기 전에 <to>로 변경합니다.
  <from>은 소문자여야 하며 <from>과 <to>는 대소문자를 제외하고는 달라서는 안 됩니다.
  여러 헤더 이름을 조정해야 하는 경우 반복될 수 있습니다. 중복 입력은 허용되지 않습니다.
  많은 헤더 이름을 조정해야 하는 경우 "h1-case-adjust-file"을 사용하는 것이 더 편리할 수 있습니다.
  "option h1-case-adjust-bogus-client" 또는 "option h1-case-adjust-bogus-server"가 
  프록시에 지정되지 않으면 변환이 적용되지 않습니다.

  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.
  
  RFC7230에 명시된 대로 헤더 이름은 대소문자를 구분하지 않기 때문에 헤더 이름에 
  대한 표준 대소문자는 없습니다. 따라서 애플리케이션은 대소문자를 구분하지 않는 
  방식으로 이를 처리해야 합니다. 그러나 일부 가짜 응용 프로그램은 표준을 위반하고 
  브라우저에서 가장 일반적으로 사용되는 사례에 잘못 의존합니다.
  이 문제는 모든 헤더 이름을 소문자로 교환해야 하고 HAProxy가 동일한 규칙을 따르기 
  때문에 HTTP/2에서 매우 중요합니다.
  모든 헤더 이름은 HTTP 버전에 관계없이 클라이언트와 서버에 소문자로 전송됩니다.

  Applications which fail to properly process requests or responses may require
  to temporarily use such workarounds to adjust header names sent to them for
  the time it takes the application to be fixed. Please note that an
  application which requires such workarounds might be vulnerable to content
  smuggling attacks and must absolutely be fixed.
  
  요청 또는 응답을 제대로 처리하지 못하는 응용 프로그램은 이러한 해결 방법을 임시로 
  사용하여 응용 프로그램을 수정하는 데 걸리는 시간 동안 전송된 헤더 이름을 조정해야 
  할 수 있습니다. 이러한 해결 방법이 필요한 응용 프로그램은 콘텐츠 밀수 공격에 취약할 
  수 있으므로 반드시 수정해야 합니다.
  Example:
    global
      h1-case-adjust content-length Content-Length

  See "h1-case-adjust-file", "option h1-case-adjust-bogus-client" and
  "option h1-case-adjust-bogus-server".
h1-case-adjust-file <hdrs-file>	
  Defines a file containing a list of key/value pairs used to adjust the case
  of some header names before sending them to HTTP/1 clients or servers. The
  file <hdrs-file> must contain 2 header names per line. The first one must be
  in lower case and both must not differ except for their case. Lines which
  start with '#' are ignored, just like empty lines. Leading and trailing tabs
  and spaces are stripped. Duplicate entries are not allowed. Please note that
  no transformation will be applied unless "option h1-case-adjust-bogus-client"
  or "option h1-case-adjust-bogus-server" is specified in a proxy.

  HTTP/1 클라이언트 또는 서버로 보내기 전에 일부 헤더 이름의 대소문자를 조정하는 데 
  사용되는 키/값 쌍 목록이 포함된 파일을 정의합니다.
  파일 <hdrs-file>에는 행당 2개의 헤더 이름이 포함되어야 합니다. 
  첫 번째는 소문자여야 하며 둘 다 대소문자를 제외하고는 다르지 않아야 합니다.
  빈 줄처럼 '#'으로 시작하는 줄은 무시됩니다. 선행 및 후행 탭과 공백이 제거됩니다.
  중복 입력은 허용되지 않습니다.  
  "option h1-case-adjust-bogus-client" 또는 "option h1-case-adjust-bogus-server"가 
  프록시에 지정되지 않으면 변환이 적용되지 않습니다.
  
  If this directive is repeated, only the last one will be processed.  It is an
  alternative to the directive "h1-case-adjust" if a lot of header names need
  to be adjusted. Please read the risks associated with using this.
  
  이 지시문이 반복되면 마지막 지시문만 처리됩니다.
  많은 헤더 이름을 조정해야 하는 경우 "h1-case-adjust" 지시문의 대안입니다.
  이것을 사용하는 것과 관련된 위험을 읽으십시오.

  See "h1-case-adjust", "option h1-case-adjust-bogus-client" and
  "option h1-case-adjust-bogus-server".

httpclient.ssl.ca-file <cafile>	
  This option defines the ca-file which should be used to verify the server
  certificate. It takes the same parameters as the "ca-file" option on the
  server line.
  이 옵션은 서버 인증서를 확인하는 데 사용해야 하는 ca 파일을 정의합니다. 
  서버 라인의 "ca-file" 옵션과 동일한 매개변수를 사용합니다.

  By default and when this option is not used, the value is
  "@system-ca" which tries to load the CA of the system. If it fails the SSL
  will be disabled for the httpclient.	
  기본적으로 이 옵션을 사용하지 않을 때 값은 시스템의 CA를 로드하려고 시도하는 
  "@system-ca"입니다. 실패하면 httpclient에 대해 SSL이 비활성화됩니다.

  However, when this option is explicitly enabled it will trigger a
  configuration error if it fails.
  그러나 이 옵션을 명시적으로 활성화하면 실패할 경우 구성 오류가 발생합니다.

httpclient.ssl.verify [none|required]	
  Works the same way as the verify option on server lines. If specified to 'none',
  servers certificates are not verified. Default option is "required".
  서버 라인의 확인 옵션과 동일한 방식으로 작동합니다. 
  'none'으로 지정하면 서버 인증서가 확인되지 않습니다. 기본 옵션은 "필수 required"입니다.

  By default and when this option is not used, the value is
  "required". If it fails the SSL will be disabled for the httpclient.
  기본적으로 이 옵션을 사용하지 않는 경우 값은 "필수 required"입니다.
  실패하면 httpclient에 대해 SSL이 비활성화됩니다.

  However, when this option is explicitly enabled it will trigger a
  configuration error if it fails.
  그러나 이 옵션을 명시적으로 활성화하면 실패할 경우 구성 오류가 발생합니다.

httpclient.resolvers.id <resolvers id>	
  This option defines the resolvers section with which the httpclient will try
  to resolve.
  이 옵션은 httpclient가 해결을 시도할 resolvers 섹션을 정의합니다.

  Default option is the "default" resolvers ID. By default, if this option is
  not used, it will simply disable the resolving if the section is not found.
  기본 옵션은 "default" 확인자 ID입니다. 기본적으로 이 옵션을 사용하지 않으면 
  섹션을 찾을 수 없는 경우 해결이 비활성화됩니다.

  However, when this option is explicitly enabled it will trigger a
  configuration error if it fails to load.
  그러나 이 옵션을 명시적으로 활성화하면 로드에 실패하면 구성 오류가 발생합니다.

httpclient.resolvers.prefer <ipv4|ipv6>	
  This option allows to chose which family of IP you want when resolving,
  which is convenient when IPv6 is not available on your network. Default
  option is "ipv6".	
  이 옵션을 사용하면 확인할 때 원하는 IP 제품군을 선택할 수 있습니다. 
  이는 네트워크에서 IPv6를 사용할 수 없을 때 편리합니다. 기본 옵션은 "ipv6"입니다.

insecure-fork-wanted	
  By default HAProxy tries hard to prevent any thread and process creation
  after it starts. Doing so is particularly important when using Lua files of
  uncertain origin, and when experimenting with development versions which may
  still contain bugs whose exploitability is uncertain. And generally speaking
  it's good hygiene to make sure that no unexpected background activity can be
  triggered by traffic. But this prevents external checks from working, and may
  break some very specific Lua scripts which actively rely on the ability to
  fork. This option is there to disable this protection. Note that it is a bad
  idea to disable it, as a vulnerability in a library or within HAProxy itself
  will be easier to exploit once disabled. In addition, forking from Lua or
  anywhere else is not reliable as the forked process may randomly embed a lock
  set by another thread and never manage to finish an operation. As such it is
  highly recommended that this option is never used and that any workload
  requiring such a fork be reconsidered and moved to a safer solution (such as
  agents instead of external checks). This option supports the "no" prefix to
  disable it.	
  
  기본적으로 HAProxy는 시작된 후 스레드 및 프로세스 생성을 방지하기 위해 열심히 노력합니다.
  이렇게 하는 것은 출처가 불확실한 Lua 파일을 사용할 때와 악용 가능성이 불확실한 버그가 
  여전히 포함되어 있을 수 있는 개발 버전을 실험할 때 특히 중요합니다.
  그리고 일반적으로 말하면 트래픽으로 인해 예기치 않은 백그라운드 작업이 트리거되지 
  않도록 하는 것이 위생적입니다.
  그러나 이렇게 하면 외부 검사가 작동하지 않으며 분기 기능에 적극적으로 의존하는 일부 
  매우 특정한 Lua 스크립트가 중단될 수 있습니다.
  이 옵션은 이 보호를 비활성화하는 데 있습니다.
  비활성화하면 라이브러리 또는 HAProxy 자체의 취약점을 악용하기가 더 쉽기 때문에 
  비활성화하는 것은 좋지 않습니다.
  또한 포크된 프로세스가 다른 스레드에서 설정한 잠금을 임의로 포함하고 작업을 완료하지 
  못할 수 있으므로 Lua 또는 다른 곳에서 포크하는 것은 신뢰할 수 없습니다.
  따라서 이 옵션은 절대 사용하지 말고 이러한 분기가 필요한 워크로드를 재고하고 
  더 안전한 솔루션(예: 외부 확인 대신 에이전트)으로 이동하는 것이 좋습니다.
  이 옵션은 비활성화하기 위해 "no" 접두사를 지원합니다.

insecure-setuid-wanted	
  HAProxy doesn't need to call executables at run time (except when using
  external checks which are strongly recommended against), and is even expected
  to isolate itself into an empty chroot. As such, there basically is no valid
  reason to allow a setuid executable to be called without the user being fully
  aware of the risks. In a situation where HAProxy would need to call external
  checks and/or disable chroot, exploiting a vulnerability in a library or in
  HAProxy itself could lead to the execution of an external program. On Linux
  it is possible to lock the process so that any setuid bit present on such an
  executable is ignored. This significantly reduces the risk of privilege
  escalation in such a situation. This is what HAProxy does by default. In case
  this causes a problem to an external check (for example one which would need
  the "ping" command), then it is possible to disable this protection by
  explicitly adding this directive in the global section. If enabled, it is
  possible to turn it back off by prefixing it with the "no" keyword.	

  HAProxy는 런타임에 실행 파일을 호출할 필요가 없으며(강력히 권장되는 외부 검사를 
  사용하는 경우 제외) 빈 chroot로 자체 격리될 것으로 예상됩니다.
  따라서 기본적으로 사용자가 위험을 완전히 인식하지 않고 setuid 실행 파일을 
  호출하도록 허용할 타당한 이유가 없습니다.
  HAProxy가 외부 검사를 호출하거나 chroot를 비활성화해야 하는 상황에서 라이브러리 
  또는 HAProxy 자체의 취약점을 악용하면 외부 프로그램이 실행될 수 있습니다.
  Linux에서는 그러한 실행 파일에 있는 setuid 비트가 무시되도록 프로세스를 잠글 수 있습니다.
  이렇게 하면 이러한 상황에서 권한 상승의 위험이 크게 줄어듭니다.
  이것이 HAProxy가 기본적으로 수행하는 작업입니다.
  이로 인해 외부 검사(예: "ping" 명령이 필요한 검사)에 문제가 발생하는 경우 전역 
  섹션에 이 지시문을 명시적으로 추가하여 이 보호 기능을 비활성화할 수 있습니다.
  활성화된 경우 "no" 키워드를 접두사로 사용하여 다시 끌 수 있습니다.

issuers-chain-path <dir>	
  Assigns a directory to load certificate chain for issuer completion. All
  files must be in PEM format. For certificates loaded with "crt" or "crt-list",
  if certificate chain is not included in PEM (also commonly known as
  intermediate certificate), HAProxy will complete chain if the issuer of the
  certificate corresponds to the first certificate of the chain loaded with
  "issuers-chain-path".	
  A "crt" file with PrivateKey+Certificate+IntermediateCA2+IntermediateCA1
  could be replaced with PrivateKey+Certificate. HAProxy will complete the
  chain if a file with IntermediateCA2+IntermediateCA1 is present in
  "issuers-chain-path" directory. All other certificates with the same issuer
  will share the chain in memory.	

  발급자 완료를 위해 인증서 체인을 로드할 디렉터리를 할당합니다.
  모든 파일은 PEM 형식이어야 합니다.
  "crt" 또는 "crt-list"로 로드된 인증서의 경우 인증서 체인이 PEM(일반적으로 중간 
  인증서라고도 함)에 포함되지 않은 경우 인증서 발급자가 로드된 체인의 첫 번째 
  인증서에 해당하는 경우 HAProxy는 체인을 완료합니다. "issuers-chain-path"로.
  PrivateKey+Certificate+IntermediateCA2+IntermediateCA1이 포함된 "crt" 파일은 
  PrivateKey+Certificate로 대체될 수 있습니다. 
  HAProxy는 IntermediateCA2+IntermediateCA1이 포함된 파일이 "issuers-chain-path" 
  디렉터리에 있는 경우 체인을 완료합니다.
  발급자가 동일한 다른 모든 인증서는 메모리에서 체인을 공유합니다.

h2-workaround-bogus-websocket-clients	
  This disables the announcement of the support for h2 websockets to clients.
  This can be use to overcome clients which have issues when implementing the
  relatively fresh RFC8441, such as Firefox 88. To allow clients to
  automatically downgrade to http/1.1 for the websocket tunnel, specify h2
  support on the bind line using "alpn" without an explicit "proto" keyword. If
  this statement was previously activated, this can be disabled by prefixing
  the keyword with "no'.	
  
  이렇게 하면 클라이언트에 대한 h2 웹소켓 지원 발표가 비활성화됩니다.
  이것은 Firefox 88과 같이 비교적 새로운 RFC8441을 구현할 때 문제가 있는 클라이언트를 
  극복하는 데 사용할 수 있습니다.
  클라이언트가 websocket 터널에 대해 자동으로 http/1.1로 다운그레이드할 수 있도록 
  하려면 명시적인 "proto" 키워드 없이 "alpn"을 사용하여 바인드 라인에 h2 지원을 지정합니다.
  이 명령문이 이전에 활성화된 경우 키워드 앞에 "no"를 붙여 비활성화할 수 있습니다.

localpeer <name>	
  Sets the local instance's peer name. It will be ignored if the "-L"
  command line argument is specified or if used after "peers" section
  definitions. In such cases, a warning message will be emitted during
  the configuration parsing.	
  
  로컬 인스턴스의 피어 이름을 설정합니다.
  "-L" 명령줄 인수가 지정되거나 "peers" 섹션 정의 뒤에 사용되는 경우 무시됩니다.
  이러한 경우 구성 구문 분석 중에 경고 메시지가 표시됩니다.

  This option will also set the HAPROXY_LOCALPEER environment variable.
  See also "-L" in the management guide and "peers" section below.
  이 옵션은 HAPROXY_LOCALPEER 환경 변수도 설정합니다.
  관리 가이드의 "-L" 및 아래의 "피어" 섹션도 참조하십시오.

log <address> [len <length>] [format <format>] [sample <ranges>:<sample_size>]
    <facility> [max level [min level]]	
  Adds a global syslog server. Several global servers can be defined. They
  will receive logs for starts and exits, as well as all logs from proxies
  configured with "log global".  
  글로벌 syslog 서버를 추가합니다. 여러 전역 서버를 정의할 수 있습니다.
  시작 및 종료에 대한 로그와 "log global"로 구성된 프록시의 모든 로그를 수신합니다.

  <address> 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).
          선택적으로 뒤에 콜론과 UDP 포트가 오는 IPv4 주소.
          포트를 지정하지 않으면 기본적으로 514가 사용됩니다(표준 syslog 포트).

        - 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).
          콜론과 선택적으로 UDP 포트가 오는 IPv6 주소.
          포트를 지정하지 않으면 기본적으로 514가 사용됩니다(표준 syslog 포트).

        - A filesystem path to a datagram 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).
          데이터그램 UNIX 도메인 소켓에 대한 파일 시스템 경로, chroot(경로가 chroot 
          내에서 액세스 가능해야 함) 및 uid/gid(경로가 적절하게 쓰기 가능해야 함)에 
          대한 고려 사항을 염두에 두십시오.

        - 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"
          format below.

          파이프, 터미널 또는 소켓을 가리킬 수 있는 "fd@<number>" 형식의 파일 
          설명자 번호입니다. 이 경우 버퍼링되지 않은 로그가 사용되며 로그당 하나의 
          writev() 호출이 수행됩니다. 이것은 약간 비싸지만 대부분의 워크로드에 적합합니다. 
          이 방법으로 전송된 메시지는 잘리지 않지만 삭제될 수 있으며 이 경우 DroppedLogs 
          카운터가 증가합니다.
          writev() 호출은 최대 PIPE_BUF 크기의 메시지에 대한 파이프에서도 원자적이며 
          POSIX는 최소 512를 권장하고 대부분의 최신 운영 체제에서 4096바이트입니다.
          더 큰 메시지는 다른 프로세스의 메시지와 인터리브될 수 있습니다.
          예외적으로 디버깅 목적으로 파일 디스크립터가 파일로 지정될 수도 있지만 이렇게 
          하면 비차단 호출이 무시되므로 HAProxy 속도가 크게 느려집니다.
          또한 프로세스를 다시 시작하지 않고는 이 파일을 제거하거나 회전할 방법이 없습니다.
          구성된 syslog 형식이 보존되므로 출력이 TCP syslog 서버와 함께 사용하기에 적합합니다. 
          아래의 "short" 및 "raw" 형식도 참조하십시오.

        - "stdout" / "stderr", which are respectively aliases for "fd@1" and
          "fd@2", see above.
          각각 "fd@1" 및 "fd@2"의 별칭인 "stdout" / "stderr"은 위를 참조하십시오.

        - 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.
		  
          "ring@<name>" 형식의 링 버퍼는 "show events" 명령을 사용하여 CLI를 
          통해 액세스할 수 있는 메모리 내 링 버퍼에 해당하며 기존 링과 해당 크기도 나열합니다.
          이러한 버퍼는 다시 로드하거나 다시 시작할 때 손실되지만 보완으로 사용하면 
          로그를 즉시 사용할 수 있으므로 문제 해결에 도움이 될 수 있습니다.

        You may want to reference some environment variables in the address
        parameter, see section 2.3 about environment variables.	
        주소 매개변수에서 일부 환경 변수를 참조할 수 있습니다. 
        환경 변수에 대한 섹션 2.3을 참조하십시오.

  <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. You may also need to
           increase "tune.http.logurilen" if your request URIs are truncated.

   <length>는 선택적 최대 줄 길이입니다. 이 값보다 큰 로그 라인은 전송되기 전에 잘립니다.
           그 이유는 syslog 서버가 로그 줄 길이에 따라 다르게 작동하기 때문입니다.
           모든 서버는 기본값인 1024를 지원하지만 일부 서버는 단순히 더 큰 라인을 
           삭제하고 다른 서버는 로그를 기록합니다.
           서버가 긴 줄을 지원하는 경우 긴 줄이 잘리지 않도록 여기에서 이 값을 설정하는 것이 좋습니다.
           마찬가지로 서버가 긴 줄을 삭제하는 경우 보내기 전에 잘라내는 것이 좋습니다. 
           허용되는 값은 80에서 65535까지입니다.
           기본값 1024는 일반적으로 모든 표준 용도에 적합합니다. 
           긴 캡처 또는 JSON 형식 로그의 일부 특정 경우에는 더 큰 값이 필요할 수 있습니다. 
           요청 URI가 잘린 경우 "tune.http.logurilen"을 늘려야 할 수도 있습니다.

  <format> is the log format used when generating syslog messages. It may be
           one of the following :
  <format>은 syslog 메시지를 생성할 때 사용되는 로그 형식입니다. 
           다음 중 하나일 수 있습니다.
  
    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 syslog 메시지 형식과 
              유사합니다. 이것이 기본값입니다.
              참고: "log-send-hostname" 옵션은 기본값을 rfc3164로 전환합니다.

    rfc3164   The RFC3164 syslog message format.  RFC3164 syslog 메시지 형식.
              (https://tools.ietf.org/html/rfc3164)

    rfc5424   The RFC5424 syslog message format.  RFC5424 syslog 메시지 형식.
              (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.			  
              '<63>'과 같은 꺾쇠 괄호 사이에 수준과 syslog 기능만 포함된 메시지와 
              텍스트가 뒤따릅니다. PID, 날짜, 시간, 프로세스 이름 및 시스템 이름은 생략됩니다. 
              이것은 로컬 로그 서버와 함께 사용하도록 설계되었습니다.

    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.
              '<3>'과 같은 꺾쇠 괄호 사이에 수준만 포함된 메시지와 텍스트가 뒤따릅니다.
              PID, 날짜, 시간, 프로세스 이름 및 시스템 이름은 생략됩니다.
              이것은 로컬 로그 서버와 함께 사용하도록 설계되었습니다.
              이 형식은 systemd 로거가 사용하는 것과 호환됩니다.

    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.
              '<3>'과 같은 꺾쇠 괄호 사이에 수준만 포함된 메시지로 ISO 날짜와 
              텍스트가 뒤따릅니다. PID, 프로세스 이름 및 시스템 이름은 생략됩니다.
              이것은 로컬 로그 서버와 함께 사용하도록 설계되었습니다.			  

    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.
              텍스트 뒤에 ISO 날짜만 포함된 메시지입니다.
              PID, 프로세스 이름 및 시스템 이름은 생략됩니다.
              이것은 로컬 로그 서버와 함께 사용하도록 설계되었습니다.			  

    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).
              텍스트만 포함된 메시지입니다. 레벨, PID, 날짜, 시간, 프로세스 이름 및 시스템 
              이름은 생략됩니다. 이는 심각도가 사용된 파일 설명자(stdout/stderr)에만 
              의존하는 개발 중에 또는 컨테이너에서 사용하도록 설계되었습니다.

  <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.
             샘플링할 로그를 식별하기 위한 쉼표로 구분된 범위 목록입니다.
             이는 로그 서버로 보낼 로그의 부하를 분산하는 데 사용됩니다.
             범위 제한은 null일 수 없습니다. 1부터 번호가 매겨집니다.
             샘플의 크기 또는 기간(로그 수)은 <sample_size> 매개변수로 설정해야 합니다.			 

  <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).
             로깅 부하를 분산할 때 고려할 로그 수의 샘플 크기입니다.
             syslog 서버로 보낼 로그의 부하를 분산하는 데 사용됩니다.
             이 크기는 범위 상한의 최대값보다 크거나 같아야 합니다.			 

  <facility> must be one of the 24 standard syslog facilities :
                  24개의 표준 syslog 기능 중 하나여야 합니다.

                 kern   user   mail   daemon auth   syslog lpr    news
                 uucp   cron   auth2  ftp    ntp    audit  alert  cron2
                 local0 local1 local2 local3 local4 local5 local6 local7

             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.
             "short" 및 "raw" 형식에 대해서는 기능이 무시되지만 여전히 위치 
             필드로 필요합니다. 이 경우 "daemon"을 사용하여 로컬에서만 사용해야 함을 
             분명히 하는 것이 좋습니다.

  An optional level can be specified to filter outgoing messages. By default,
  all messages are sent. If a maximum 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 :
  
  나가는 메시지를 필터링하기 위해 선택적 수준을 지정할 수 있습니다. 
  기본적으로 모든 메시지가 전송됩니다.
  최대 수준이 지정되면 최소한 이 수준만큼 중요한 심각도의 메시지만 전송됩니다.
  선택적 최소 수준을 지정할 수 있습니다.
  설정된 경우 이보다 더 심각한 수준으로 내보내는 로그는 이 수준으로 제한됩니다.
  이는 일부 기본 syslog 구성의 모든 터미널에서 "emerg" 메시지를 보내는 것을 방지하는 
  데 사용됩니다.
  여덟 가지 수준이 알려져 있습니다.  

          emerg  alert  crit   err    warning notice info  debug

log-send-hostname [<string>]	
  Sets the hostname field in the syslog header. If optional "string" parameter
  is set the header is set to the string contents, otherwise uses the hostname
  of the system. Generally used if one is not relaying logs through an
  intermediate syslog server or for simply customizing the hostname printed in
  the logs.
  syslog 헤더에서 호스트 이름 필드를 설정합니다.
  선택적 "문자열" 매개변수가 설정되면 헤더가 문자열 내용으로 설정되고 
  그렇지 않으면 시스템의 호스트 이름을 사용합니다.
  일반적으로 중간 syslog 서버를 통해 로그를 릴레이하지 않거나 단순히 로그에 
  인쇄된 호스트 이름을 사용자 정의하는 데 사용됩니다.

log-tag <string>	
  Sets the tag field in the syslog header to this string. It defaults to 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. See also the per-proxy "log-tag" directive.		
  syslog 헤더의 태그 필드를 이 문자열로 설정합니다. 일반적으로 "haproxy"인 
  명령줄에서 실행되는 프로그램 이름이 기본값입니다.
  경우에 따라 동일한 호스트에서 실행되는 여러 프로세스를 구별하는 것이 유용할 
  수 있습니다. 프록시별 "log-tag" 지시문도 참조하십시오.
   
lua-load <file>	
  This global directive loads and executes a Lua file in the shared context
  that is visible to all threads. Any variable set in such a context is visible
  from any thread. This is the easiest and recommended way to load Lua programs
  but it will not scale well if a lot of Lua calls are performed, as only one
  thread may be running on the global state at a time. A program loaded this
  way will always see 0 in the "core.thread" variable. This directive can be
  used multiple times.	

  이 전역 지시어는 모든 스레드에 표시되는 공유 컨텍스트에서 Lua 파일을 로드하고 
  실행합니다. 이러한 컨텍스트에 설정된 모든 변수는 모든 스레드에서 볼 수 있습니다.
  이것은 Lua 프로그램을 로드하는 가장 쉽고 권장되는 방법이지만 많은 Lua 호출이 
  수행되는 경우 한 번에 하나의 스레드만 전역 상태에서 실행될 수 있으므로 제대로 
  확장되지 않습니다.
  이런 방식으로 로드된 프로그램은 "core.thread" 변수에서 항상 0을 볼 것입니다.
  이 지시문은 여러 번 사용할 수 있습니다.  

lua-load-per-thread <file>	
  This global directive loads and executes a Lua file into each started thread.
  Any global variable has a thread-local visibility so that each thread could
  see a different value. As such it is strongly recommended not to use global
  variables in programs loaded this way. An independent copy is loaded and
  initialized for each thread, everything is done sequentially and in the
  thread's numeric order from 1 to nbthread. If some operations need to be
  performed only once, the program should check the "core.thread" variable to
  figure what thread is being initialized. Programs loaded this way will run
  concurrently on all threads and will be highly scalable. This is the
  recommended way to load simple functions that register sample-fetches,
  converters, actions or services once it is certain the program doesn't depend
  on global variables. For the sake of simplicity, the directive is available
  even if only one thread is used and even if threads are disabled (in which
  case it will be equivalent to lua-load). This directive can be used multiple
  times.	

  이 전역 지시문은 시작된 각 스레드에 Lua 파일을 로드하고 실행합니다.
  모든 전역 변수에는 스레드 로컬 가시성이 있으므로 각 스레드가 다른 값을 볼 수 있습니다.
  따라서 이런 방식으로 로드된 프로그램에서는 전역 변수를 사용하지 않는 것이 좋습니다.
  독립적인 복사본이 각 스레드에 대해 로드되고 초기화되며 모든 작업이 1에서 
  nbthread까지 스레드의 숫자 순서로 순차적으로 수행됩니다.
  일부 작업을 한 번만 수행해야 하는 경우 프로그램은 초기화 중인 스레드를 파악하기 
  위해 "core.thread" 변수를 확인해야 합니다.
  이 방법으로 로드된 프로그램은 모든 스레드에서 동시에 실행되며 확장성이 뛰어납니다.
  이것은 프로그램이 전역 변수에 의존하지 않는다는 것이 확실해지면 샘플 가져오기, 
  변환기, 작업 또는 서비스를 등록하는 간단한 함수를 로드하는 데 권장되는 방법입니다.
  단순화를 위해 지시문은 하나의 스레드만 사용되고 스레드가 비활성화된 경우에도 
  사용할 수 있습니다(이 경우 lua-load와 동일함). 이 지시문은 여러 번 사용할 수 있습니다.

lua-prepend-path <string> [<type>]	
  Prepends the given string followed by a semicolon to Lua's package.<type>
  variable.	
  <type> must either be "path" or "cpath". If <type> is not given it defaults
  to "path".	
  Lua의 package.<type> 변수에 세미콜론이 오는 주어진 문자열을 앞에 추가합니다.
  <type>은 "path" 또는 "cpath"여야 합니다. 
  <type>이 지정되지 않은 경우 기본값은 "path"입니다.

  Lua's paths are semicolon delimited lists of patterns that specify how the
  `require` function attempts to find the source file of a library. Question
  marks (?) within a pattern will be replaced by module name. The path is
  evaluated left to right. This implies that paths that are prepended later
  will be checked earlier.	
  
  Lua의 경로는 `require` 함수가 라이브러리의 소스 파일을 찾는 방법을 지정하는 
  세미콜론으로 구분된 패턴 목록입니다.
  패턴 내의 물음표(?)는 모듈 이름으로 대체됩니다.
  경로는 왼쪽에서 오른쪽으로 평가됩니다. 
  이는 나중에 추가되는 경로가 더 일찍 확인됨을 의미합니다.  

  As an example by specifying the following path:
  예를 들어 다음 경로를 지정합니다.

    lua-prepend-path /usr/share/haproxy-lua/?/init.lua
    lua-prepend-path /usr/share/haproxy-lua/?.lua

  When `require "example"` is being called Lua will first attempt to load the
  /usr/share/haproxy-lua/example.lua script, if that does not exist the
  /usr/share/haproxy-lua/example/init.lua will be attempted and the default
  paths if that does not exist either.
  
  'require "example"'이 호출될 때 Lua는 먼저 "/usr/share/haproxy-lua/example.lua" 
  스크립트를 로드하려고 시도합니다. 해당 스크립트가 존재하지 않으면 
  "/usr/share/haproxy-lua/example/init.lua"가 시도되고 기본 경로가 없는 경우 
  기본 경로가 사용됩니다.

  See https://www.lua.org/pil/8.1.html for the details within the Lua documentation.
  Lua 설명서에 대한 자세한 내용은 https://www.lua.org/pil/8.1.html을 참조하십시오.

master-worker [no-exit-on-failure]	
  Master-worker mode. It is equivalent to the command line "-W" argument.
  This mode will launch a "master" which will monitor the "workers". Using
  this mode, you can reload HAProxy directly by sending a SIGUSR2 signal to
  the master. The master-worker mode is compatible either with the foreground
  or daemon mode.	

  마스터 작업자 모드. 명령줄 "-W" 인수와 동일합니다.
  이 모드는 "workers"를 모니터링하는 "master"를 시작합니다.
  이 모드를 사용하면 SIGUSR2 신호를 마스터로 전송하여 HAProxy를 직접 다시 
  로드할 수 있습니다. 마스터-작업자 모드는 포그라운드 또는 데몬 모드와 호환됩니다.

  By default, if a worker exits with a bad return code, in the case of a
  segfault for example, all workers will be killed, and the master will leave.
  It is convenient to combine this behavior with Restart=on-failure in a
  systemd unit file in order to relaunch the whole process. If you don't want
  this behavior, you must use the keyword "no-exit-on-failure".	

  기본적으로 작업자가 잘못된 반환 코드로 종료하면 예를 들어 segfault의 경우 
  모든 작업자가 종료되고 마스터가 떠납니다.
  전체 프로세스를 다시 시작하기 위해 시스템 단위 파일에서 이 동작을 
  Restart=on-failure와 결합하는 것이 편리합니다. 
  이 동작을 원하지 않으면 "no-exit-on-failure" 키워드를 사용해야 합니다.

  See also "-W" in the management guide.

mworker-max-reloads <number>	
  In master-worker mode, this option limits the number of time a worker can
  survive to a reload. If the worker did not leave after a reload, once its
  number of reloads is greater than this number, the worker will receive a
  SIGTERM. This option helps to keep under control the number of workers.
  See also "show proc" in the Management Guide.
  
  마스터-작업자 모드에서 이 옵션은 작업자가 다시 로드할 때까지 생존할 수 있는 
  시간을 제한합니다.  재로드 후 작업자가 떠나지 않은 경우 재로드 횟수가 이 숫자보다 
  크면 작업자는 SIGTERM을 받게 됩니다.
  이 옵션은 작업자 수를 제어하는 데 도움이 됩니다.
  관리 가이드의 "show proc"도 참조하십시오.  

nbthread <number>	
  This setting is only available when support for threads was built in. It
  makes HAProxy run on <number> threads. "nbthread" also works when HAProxy is
  started in foreground. On some platforms supporting CPU affinity, the default
  "nbthread" value is automatically set to the number of CPUs the process is
  bound to upon startup. This means that the thread count can easily be
  adjusted from the calling process using commands like "taskset" or "cpuset".
  Otherwise, this value defaults to 1. The default value is reported in the
  output of "haproxy -vv".	

  이 설정은 스레드 지원이 내장된 경우에만 사용할 수 있습니다.
  HAProxy가 <number> 스레드에서 실행되도록 합니다.
  "nbthread"는 HAProxy가 포그라운드에서 시작될 때도 작동합니다.
  CPU 선호도를 지원하는 일부 플랫폼에서 기본 "nbthread" 값은 시작 시 프로세스가 
  바인딩되는 CPU 수로 자동 설정됩니다.
  즉, "taskset" 또는 "cpuset"와 같은 명령을 사용하여 호출 프로세스에서 스레드 수를 쉽게 
  조정할 수 있습니다.
  그렇지 않으면 이 값의 기본값은 1입니다. 기본값은 "haproxy -vv"의 출력에 보고됩니다.

numa-cpu-mapping		
  If running on a NUMA-aware platform, HAProxy inspects on startup the CPU
  topology of the machine. If a multi-socket machine is detected, the affinity
  is automatically calculated to run on the CPUs of a single node. This is done
  in order to not suffer from the performance penalties caused by the
  inter-socket bus latency. However, if the applied binding is non optimal on a
  particular architecture, it can be disabled with the statement 'no
  numa-cpu-mapping'. This automatic binding is also not applied if a nbthread
  statement is present in the configuration, or the affinity of the process is
  already specified, for example via the 'cpu-map' directive or the taskset
  utility.	
  
  NUMA 인식 플랫폼에서 실행 중인 경우 HAProxy는 시작 시 시스템의 CPU 토폴로지를 
  검사합니다.  다중 소켓 시스템이 감지되면 선호도가 단일 노드의 CPU에서 실행되도록 
  자동으로 계산됩니다.  이는 소켓 간 버스 대기 시간으로 인한 성능 저하를 방지하기 위해 
  수행됩니다.  그러나 적용된 바인딩이 특정 아키텍처에서 최적이 아닌 경우 
  'no numa-cpu-mapping' 문으로 비활성화할 수 있습니다.
  이 자동 바인딩은 구성에 nbthread 문이 있거나 예를 들어 'cpu-map' 지시문 또는 
  taskset 유틸리티를 통해 프로세스의 선호도가 이미 지정된 경우에도 적용되지 않습니다.

pidfile <pidfile>		
  Writes PIDs of all daemons into file <pidfile> when daemon mode or writes PID
  of master process into file <pidfile> when master-worker mode. This option is
  equivalent to the "-p" command line argument. The file must be accessible to
  the user starting the process. See also "daemon" and "master-worker".
  
  데몬 모드에서는 모든 데몬의 PID를 <pidfile> 파일에, 마스터 프로세스의 PID는 
  마스터 작업자 모드일 때는 <pidfile> 파일에 기록합니다.
  이 옵션은 "-p" 명령줄 인수와 동일합니다.
  파일은 프로세스를 시작하는 사용자가 액세스할 수 있어야 합니다. 
  "데몬" 및 "마스터 작업자"도 참조하십시오.

pp2-never-send-local	
  A bug in the PROXY protocol v2 implementation was present in HAProxy up to
  version 2.1, causing it to emit a PROXY command instead of a LOCAL command
  for health checks. This is particularly minor but confuses some servers'
  logs. Sadly, the bug was discovered very late and revealed that some servers
  which possibly only tested their PROXY protocol implementation against
  HAProxy fail to properly handle the LOCAL command, and permanently remain in
  the "down" state when HAProxy checks them. When this happens, it is possible
  to enable this global option to revert to the older (bogus) behavior for the
  time it takes to contact the affected components' vendors and get them fixed.
  This option is disabled by default and acts on all servers having the
  "send-proxy-v2" statement.	
  
  PROXY 프로토콜 v2 구현의 버그가 버전 2.1까지 HAProxy에 존재하여 상태 확인을 위해 
  LOCAL 명령 대신 PROXY 명령을 내보냈습니다.
  이것은 특히 사소하지만 일부 서버의 로그를 혼동합니다.
  슬프게도 이 버그는 매우 늦게 발견되었으며 HAProxy에 대해 PROXY 프로토콜 구현만 
  테스트했을 가능성이 있는 일부 서버가 LOCAL 명령을 제대로 처리하지 못하고 HAProxy가 
  확인할 때 영구적으로 "down" 상태로 남아 있음이 밝혀졌습니다.
  이 경우 이 전역 옵션을 활성화하여 영향을 받는 구성 요소 공급업체에 연락하여 수정하는 데 
  걸리는 시간 동안 이전(가짜) 동작으로 되돌릴 수 있습니다.
  이 옵션은 기본적으로 비활성화되어 있으며 "send-proxy-v2" 문이 있는 모든 서버에서 작동합니다.  

presetenv <name> <value>	
  Sets environment variable <name> to value <value>. If the variable exists, it
  is NOT overwritten. The changes immediately take effect so that the next line
  in the configuration file sees the new value. See also "setenv", "resetenv",
  and "unsetenv".	

  환경 변수 <name>을 값 <value>으로 설정합니다. 변수가 있으면 덮어쓰지 않습니다. 
  구성 파일의 다음 줄에 새 값이 표시되도록 변경 사항이 즉시 적용됩니다. 
  "setenv", "resetenv" 및 "unsetenv"도 참조하십시오.

resetenv [<name> ...]	
  Removes all environment variables except the ones specified in argument. It
  allows to use a clean controlled environment before setting new values with
  setenv or unsetenv. Please note that some internal functions may make use of
  some environment variables, such as time manipulation functions, but also
  OpenSSL or even external checks. This must be used with extreme care and only
  after complete validation. The changes immediately take effect so that the
  next line in the configuration file sees the new environment. See also
  "setenv", "presetenv", and "unsetenv".	

  인수에 지정된 것을 제외한 모든 환경 변수를 제거합니다.
  setenv 또는 unsetenv로 새 값을 설정하기 전에 깨끗한 제어 환경을 사용할 수 있습니다.
  일부 내부 함수는 시간 조작 함수와 같은 일부 환경 변수를 사용할 수 있지만 OpenSSL 또는 
  외부 검사도 사용할 수 있습니다.
  이는 완전한 유효성 검사 후에만 극도의 주의를 기울여 사용해야 합니다.
  구성 파일의 다음 줄에 새 환경이 표시되도록 변경 사항이 즉시 적용됩니다.
  "setenv", "presetenv" 및 "unsetenv"도 참조하십시오.

stats bind-process [ all | odd | even | <process_num>[-[process_num>]] ] ...
  Deprecated. Before threads were supported, this was used to force some stats
  instances on certain processes only. The default and only accepted value is
  "1" (along with "all" and "odd" which alias it). Do not use this setting.	
  
  더 이상 사용되지 않습니다. 스레드가 지원되기 전에는 특정 프로세스에서만 일부 통계 
  인스턴스를 강제 실행하는 데 사용되었습니다.
  기본값이자 유일하게 허용되는 값은 "1"입니다(별칭인 "all" 및 "odd"와 함께).
  이 설정을 사용하지 마십시오.  

server-state-base <directory>	
  Specifies the directory prefix to be prepended in front of all servers state
  file names which do not start with a '/'. See also "server-state-file",
  "load-server-state-from-file" and "server-state-file-name".	

  '/'로 시작하지 않는 모든 서버 상태 파일 이름 앞에 추가할 디렉토리 접두어를 지정합니다.
  "server-state-file", "load-server-state-from-file" 및 "server-state-file-name"도 참조하십시오.  

server-state-file <file>	
  Specifies the path to the file containing state of servers. If the path starts
  with a slash ('/'), it is considered absolute, otherwise it is considered
  relative to the directory specified using "server-state-base" (if set) or to
  the current directory. Before reloading HAProxy, it is possible to save the
  servers' current state using the stats command "show servers state". The
  output of this command must be written in the file pointed by <file>. When
  starting up, before handling traffic, HAProxy will read, load and apply state
  for each server found in the file and available in its current running
  configuration. See also "server-state-base" and "show servers state",
  "load-server-state-from-file" and "server-state-file-name"	
  
  서버 상태를 포함하는 파일의 경로를 지정합니다.
  경로가 슬래시('/')로 시작하면 절대 경로로 간주되고 그렇지 않으면 
  "server-state-base"(설정된 경우)를 사용하여 지정된 디렉토리 또는 현재 디렉토리에 
  상대적인 경로로 간주됩니다.
  HAProxy를 다시 로드하기 전에 stats 명령 "show servers state"를 사용하여 서버의 
  현재 상태를 저장할 수 있습니다.
  이 명령의 출력은 <file>이 가리키는 파일에 기록되어야 합니다.
  시작할 때 트래픽을 처리하기 전에 HAProxy는 파일에서 발견되고 현재 실행 중인 
  구성에서 사용 가능한 각 서버의 상태를 읽고 로드하고 적용합니다.
  "server-state-base" 및 "show servers state", "load-server-state-from-file" 및 
  "server-state-file-name"도 참조하십시오.  

set-var <var-name> <expr>	
  Sets the process-wide variable '<var-name>' to the result of the evaluation
  of the sample expression <expr>. The variable '<var-name>' may only be a
  process-wide variable (using the 'proc.' prefix). It works exactly like the
  'set-var' action in TCP or HTTP rules except that the expression is evaluated
  at configuration parsing time and that the variable is instantly set. The
  sample fetch functions and converters permitted in the expression are only
  those using internal data, typically 'int(value)' or 'str(value)'. It is
  possible to reference previously allocated variables as well. These variables
  will then be readable (and modifiable) from the regular rule sets.	
  
  프로세스 전체 변수 '<var-name>'을 샘플 표현식 <expr>의 평가 결과로 설정합니다.
  변수 '<var-name>'은 프로세스 전체 변수('proc.' 접두사 사용)만 가능합니다.
  표현식이 구성 구문 분석 시간에 평가되고 변수가 즉시 설정된다는 점을 제외하면 TCP 또는 
  HTTP 규칙의 'set-var' 작업과 똑같이 작동합니다.
  식에서 허용되는 샘플 가져오기 함수 및 변환기는 내부 데이터(일반적으로 'int(value)' 또는 
  'str(value)')를 사용하는 함수와 변환기뿐입니다.
  이전에 할당된 변수도 참조할 수 있습니다.
  그런 다음 이러한 변수는 일반 규칙 세트에서 읽을 수 있고 수정할 수 있습니다.  
  Example:
      global
          set-var proc.current_state str(primary)
          set-var proc.prio int(100)
          set-var proc.threshold int(200),sub(proc.prio)
set-var-fmt <var-name> <fmt>
  Sets the process-wide variable '<var-name>' to the string resulting from the
  evaluation of the log-format <fmt>. The variable '<var-name>' may only be a
  process-wide variable (using the 'proc.' prefix). It works exactly like the
  'set-var-fmt' action in TCP or HTTP rules except that the expression is
  evaluated at configuration parsing time and that the variable is instantly
  set. The sample fetch functions and converters permitted in the expression
  are only those using internal data, typically 'int(value)' or 'str(value)'.
  It is possible to reference previously allocated variables as well. These
  variables will then be readable (and modifiable) from the regular rule sets.
  Please see section 8.2.4 for details on the log-format syntax.
  
  프로세스 전체 변수 '<var-name>'을 로그 형식 <fmt>의 평가 결과 문자열로 설정합니다.
  변수 '<var-name>'은 프로세스 전체 변수('proc.' 접두사 사용)만 가능합니다.
  표현식이 구성 구문 분석 시간에 평가되고 변수가 즉시 설정된다는 점을 제외하면 TCP 또는 
  HTTP 규칙의 'set-var-fmt' 작업과 똑같이 작동합니다.
  식에서 허용되는 샘플 가져오기 함수 및 변환기는 내부 데이터(일반적으로 'int(value)' 
  또는 'str(value)')를 사용하는 함수와 변환기뿐입니다.
  이전에 할당된 변수도 참조할 수 있습니다.
  그런 다음 이러한 변수는 일반 규칙 세트에서 읽을 수 있고 수정할 수 있습니다.
  로그 형식 구문에 대한 자세한 내용은 섹션 8.2.4를 참조하십시오.  
  Example:
      global
          set-var-fmt proc.current_state "primary"
          set-var-fmt proc.bootid        "%pid|%t"
setenv <name> <value>		
  Sets environment variable <name> to value <value>. If the variable exists, it
  is overwritten. The changes immediately take effect so that the next line in
  the configuration file sees the new value. See also "presetenv", "resetenv",
  and "unsetenv".	

  환경 변수 <name>을 값 <value>으로 설정합니다. 변수가 있으면 덮어씁니다.
  구성 파일의 다음 줄에 새 값이 표시되도록 변경 사항이 즉시 적용됩니다. 
  "presetenv", "resetenv" 및 "unsetenv"도 참조하십시오.  

set-dumpable	
  This option is better left disabled by default and enabled only upon a
  developer's request. If it has been enabled, it may still be forcibly
  disabled by prefixing it with the "no" keyword. It has no impact on
  performance nor stability but will try hard to re-enable core dumps that were
  possibly disabled by file size limitations (ulimit -f), core size limitations
  (ulimit -c), or "dumpability" of a process after changing its UID/GID (such
  as /proc/sys/fs/suid_dumpable on Linux). Core dumps might still be limited by
  the current directory's permissions (check what directory the file is started
  from), the chroot directory's permission (it may be needed to temporarily
  disable the chroot directive or to move it to a dedicated writable location),
  or any other system-specific constraint. For example, some Linux flavours are
  notorious for replacing the default core file with a path to an executable
  not even installed on the system (check /proc/sys/kernel/core_pattern). Often,
  simply writing "core", "core.%p" or "/var/log/core/core.%p" addresses the
  issue. When trying to enable this option waiting for a rare issue to
  re-appear, it's often a good idea to first try to obtain such a dump by
  issuing, for example, "kill -11" to the "haproxy" process and verify that it
  leaves a core where expected when dying.	

  이 옵션은 기본적으로 비활성화된 상태로 두는 것이 좋으며 개발자의 요청이 있을 때만 활성화됩니다.
  활성화된 경우 "no" 키워드를 접두어로 지정하여 강제로 비활성화할 수 있습니다.
  성능이나 안정성에는 영향을 미치지 않지만 파일 크기 제한(ulimit -f), 코어 크기 제한(ulimit -c) 
  또는 변경 후 프로세스의 "dumpability(덤프 가능성)"으로 인해 비활성화되었을 수 있는 
  코어 덤프를 다시 활성화하기 위해 열심히 노력합니다. 
  UID/GID(예: Linux의 /proc/sys/fs/suid_dumpable).
  코어 덤프는 여전히 현재 디렉토리의 권한(파일이 시작된 디렉토리 확인), 
  chroot 디렉토리의 권한(chroot 지시문을 일시적으로 비활성화하거나 쓰기 가능한 전용 위치로 
  이동하는 데 필요할 수 있음) 또는 기타 시스템별 제약.
  예를 들어 일부 Linux 버전은 기본 코어 파일을 시스템에 설치되지 않은 실행 파일 경로로 
  바꾸는 것으로 유명합니다(/proc/sys/kernel/core_pattern 확인).
  종종 단순히 "core", "core.%p" 또는 "/var/log/core/core.%p"를 작성하면 문제가 해결됩니다.
  드문 문제가 다시 나타날 때까지 기다리는 이 옵션을 활성화하려고 할 때, 
  예를 들어 "haproxy" 프로세스에 "kill -11"을 실행하여 이러한 덤프를 먼저 얻고 
  확인하는 것이 좋습니다. 죽을 때 예상되는 곳에 코어를 남깁니다.

ssl-default-bind-ciphers <ciphers>		
  This setting is only available when support for OpenSSL was built in. It sets
  the default string describing the list of cipher algorithms ("cipher suite")
  that are negotiated during the SSL/TLS handshake up to TLSv1.2 for all
  "bind" lines which do not explicitly define theirs. 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 "ssl-default-bind-ciphersuites" keyword.
  Please check the "bind" keyword for more information.	

  이 설정은 OpenSSL에 대한 지원이 내장된 경우에만 사용할 수 있습니다.
  명시적으로 정의하지 않은 모든 "바인딩" 라인에 대해 TLSv1.2까지 SSL/TLS 핸드셰이크 
  중에 협상되는 암호 알고리즘("cipher suite 암호 모음") 목록을 설명하는 기본 문자열을 
  설정합니다.
  문자열의 형식은 OpenSSL 매뉴얼 페이지의 "man 1 ciphers"에 정의되어 있습니다.
  배경 정보 및 권장 사항은 예)
  (https://wiki.mozilla.org/Security/Server_Side_TLS) 및 
  (https://mozilla.github.io/server-side-tls/ssl-config-generator/).
  TLSv1.3 암호 구성의 경우 "ssl-default-bind-ciphersuites" 키워드를 확인하십시오.
  자세한 내용은 "bind" 키워드를 확인하십시오.

ssl-default-bind-ciphersuites <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 default string
  describing the list of cipher algorithms ("cipher suite") that are negotiated
  during the TLSv1.3 handshake for all "bind" lines which do not explicitly define
  theirs. The format of the string is defined in
  "man 1 ciphers" from OpenSSL man pages under the section "ciphersuites". For
  cipher configuration for TLSv1.2 and earlier, please check the
  "ssl-default-bind-ciphers" keyword. Please check the "bind" keyword for more
  information.

  이 설정은 OpenSSL에 대한 지원이 기본 제공되고 OpenSSL 1.1.1 이상이 HAProxy를 빌드하는 데 
  사용된 경우에만 사용할 수 있습니다.
  명시적으로 정의하지 않은 모든 "바인드" 행에 대해 TLSv1.3 핸드셰이크 중에 협상되는 
  암호 알고리즘("암호 모음") 목록을 설명하는 기본 문자열을 설정합니다.
  문자열의 형식은 OpenSSL 매뉴얼 페이지의 "ciphersuites" 섹션에 있는 "man 1 ciphers"에 
  정의되어 있습니다.
  TLSv1.2 및 이전 버전에 대한 암호 구성의 경우 "ssl-default-bind-ciphers" 키워드를 확인하십시오. 
  자세한 내용은 "bind" 키워드를 확인하십시오.

ssl-default-bind-curves <curves>		
  This setting is only available when support for OpenSSL was built in. It sets
  the default 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.
  Please check the "bind" keyword for more information.	

  이 설정은 OpenSSL에 대한 지원이 내장된 경우에만 사용할 수 있습니다.
  ECDHE와의 SSL/TLS 핸드셰이크 중에 협상되는 타원 곡선 알고리즘("곡선 모음") 목록을 
  설명하는 기본 문자열을 설정합니다.
  문자열 형식은 콜론으로 구분된 곡선 이름 목록입니다.
  자세한 내용은 "bind" 키워드를 확인하십시오.

ssl-default-bind-options [<option>]...		
  This setting is only available when support for OpenSSL was built in. It sets
  default ssl-options to force on all "bind" lines. Please check the "bind"
  keyword to see available options.
  
  이 설정은 OpenSSL에 대한 지원이 내장된 경우에만 사용할 수 있습니다.
  모든 "bind" 라인에 강제로 기본 SSL 옵션을 설정합니다.
  사용 가능한 옵션을 보려면 "bind" 키워드를 확인하십시오.  
  Example:
        global
           ssl-default-bind-options ssl-min-ver TLSv1.0 no-tls-tickets
ssl-default-server-ciphers <ciphers>		
  This setting is only available when support for OpenSSL was built in. It
  sets the default string describing the list of cipher algorithms that are
  negotiated during the SSL/TLS handshake up to TLSv1.2 with the server,
  for all "server" lines which do not explicitly define theirs. 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
  "ssl-default-server-ciphersuites" keyword. Please check the "server" keyword
  for more information.	
  
  이 설정은 OpenSSL에 대한 지원이 내장된 경우에만 사용할 수 있습니다.
  명시적으로 정의하지 않은 모든 "server" 라인에 대해 TLSv1.2까지 서버와 SSL/TLS 
  핸드셰이크 중에 협상되는 암호 알고리즘 목록을 설명하는 기본 문자열을 설정합니다.
  문자열의 형식은 OpenSSL 매뉴얼 페이지의 "man 1 ciphers"에 정의되어 있습니다.
  배경 정보 및 권장 사항은 예)
     (https://wiki.mozilla.org/Security/Server_Side_TLS) 및
     (https://mozilla.github.io/server-side-tls/ssl-config-generator/).
  TLSv1.3 암호 구성의 경우 "ssl-default-server-ciphersuites" 키워드를 확인하십시오.
  자세한 내용은 "서버" 키워드를 확인하십시오.  

ssl-default-server-ciphersuites <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 default
  string describing the list of cipher algorithms that are negotiated during
  the TLSv1.3 handshake with the server, for all "server" lines which do not
  explicitly define theirs. The format of the string is defined in
  "man 1 ciphers" from OpenSSL man pages under the section "ciphersuites". For
  cipher configuration for TLSv1.2 and earlier, please check the
  "ssl-default-server-ciphers" keyword. Please check the "server" keyword for
  more information.	

  이 설정은 OpenSSL에 대한 지원이 기본 제공되고 OpenSSL 1.1.1 이상이 HAProxy를 
  빌드하는 데 사용된 경우에만 사용할 수 있습니다.
  명시적으로 정의하지 않은 모든 "server" 행에 대해 TLSv1.3 핸드셰이크 중에 서버와 
  협상되는 암호 알고리즘 목록을 설명하는 기본 문자열을 설정합니다.
  문자열의 형식은 OpenSSL 매뉴얼 페이지의 "ciphersuites" 섹션에 있는 
  "man 1 ciphers"에 정의되어 있습니다.
  TLSv1.2 및 이전 버전에 대한 암호 구성의 경우 "ssl-default-server-ciphers" 키워드를 
  확인하십시오.
  자세한 내용은 "서버" 키워드를 확인하십시오.

ssl-default-server-options [<option>]...	
  This setting is only available when support for OpenSSL was built in. It sets
  default ssl-options to force on all "server" lines. Please check the "server"
  keyword to see available options.	
  이 설정은 OpenSSL에 대한 지원이 내장된 경우에만 사용할 수 있습니다.
  모든 "서버" 라인에 강제로 기본 ssl 옵션을 설정합니다. 
  사용 가능한 옵션을 보려면 "서버" 키워드를 확인하십시오.  

ssl-dh-param-file <file>	
  This setting is only available when support for OpenSSL was built in. It sets
  the default DH parameters that are used during the SSL/TLS handshake when
  ephemeral Diffie-Hellman (DHE) key exchange is used, for all "bind" lines
  which do not explicitly define theirs. It will be overridden by custom DH
  parameters found in a bind certificate file if any. If custom DH parameters
  are not specified either by using ssl-dh-param-file or by setting them
  directly in the certificate file, DHE ciphers will not be used, unless
  tune.ssl.default-dh-param is set. In this latter case, pre-defined DH
  parameters of the specified size will be used. Custom parameters are known to
  be more secure and therefore their use is recommended.
  Custom DH parameters may be generated by using the OpenSSL command
  "openssl dhparam <size>", where size should be at least 2048, as 1024-bit DH
  parameters should not be considered secure anymore.	

ssl-propquery <query>	
  This setting is only available when support for OpenSSL was built in and when
  OpenSSL's version is at least 3.0. It allows to define a default property
  string used when fetching algorithms in providers. It behave the same way as
  the openssl propquery option and it follows the same syntax (described in
  https://www.openssl.org/docs/man3.0/man7/property.html). For instance, if you
  have two providers loaded, the foo one and the default one, the propquery
  "?provider=foo" allows to pick the algorithm implementations provided by the
  foo provider by default, and to fallback on the default provider's one if it
  was not found.	

ssl-provider <name>		
  This setting is only available when support for OpenSSL was built in and when
  OpenSSL's version is at least 3.0. It allows to load a provider during init.
  If loading is successful, any capabilities provided by the loaded provider
  might be used by HAProxy. Multiple 'ssl-provider' options can be specified in
  a configuration file. The providers will be loaded in their order of
  appearance.	

  Please note that loading a provider explicitly prevents OpenSSL from loading
  the 'default' provider automatically. OpenSSL also allows to define the
  providers that should be loaded directly in its configuration file
  (openssl.cnf for instance) so it is not necessary to use this 'ssl-provider'
  option to load providers. The "show ssl providers" CLI command can be used to
  show all the providers that were successfully loaded.	

  The default search path of OpenSSL provider can be found in the output of the
  "openssl version -a" command. If the provider is in another directory, you
  can set the OPENSSL_MODULES environment variable, which takes the directory
  where your provider can be found.	

  See also "ssl-propquery" and "ssl-provider-path".

ssl-provider-path <path>	
  This setting is only available when support for OpenSSL was built in and when
  OpenSSL's version is at least 3.0. It allows to specify the search path that
  is to be used by OpenSSL for looking for providers. It behaves the same way
  as the OPENSSL_MODULES environment variable. It will be used for any
  following 'ssl-provider' option or until a new 'ssl-provider-path' is
  defined.	
  See also "ssl-provider".	

ssl-load-extra-del-ext	
  This setting allows to configure the way HAProxy does the lookup for the
  extra SSL files. By default HAProxy adds a new extension to the filename.
  (ex: with "foobar.crt" load "foobar.crt.key"). With this option enabled,
  HAProxy removes the extension before adding the new one (ex: with
  "foobar.crt" load "foobar.key").		

  Your crt file must have a ".crt" extension for this option to work.	

  This option is not compatible with bundle extensions (.ecdsa, .rsa. .dsa)
  and won't try to remove them.	

  This option is disabled by default. See also "ssl-load-extra-files".	

ssl-load-extra-files <none|all|bundle|sctl|ocsp|issuer|key>*	
  This setting alters the way HAProxy will look for unspecified files during
  the loading of the SSL certificates. This option applies to certificates
  associated to "bind" lines as well as "server" lines but some of the extra
  files will not have any functional impact for "server" line certificates.	

  By default, HAProxy discovers automatically a lot of files not specified in
  the configuration, and you may want to disable this behavior if you want to
  optimize the startup time.

  "none": Only load the files specified in the configuration. Don't try to load
  a certificate bundle if the file does not exist. In the case of a directory,
  it won't try to bundle the certificates if they have the same basename.

  "all": This is the default behavior, it will try to load everything,
  bundles, sctl, ocsp, issuer, key.

  "bundle": When a file specified in the configuration does not exist, HAProxy
  will try to load a "cert bundle". Certificate bundles are only managed on the
  frontend side and will not work for backend certificates.

  Starting from HAProxy 2.3, the bundles are not loaded in the same OpenSSL
  certificate store, instead it will loads each certificate in a separate
  store which is equivalent to declaring multiple "crt". OpenSSL 1.1.1 is
  required to achieve this. Which means that bundles are now used only for
  backward compatibility and are not mandatory anymore to do an hybrid RSA/ECC
  bind configuration.	

  To associate these PEM files into a "cert bundle" that is recognized by
  HAProxy, they must be named in the following way: All PEM files that are to
  be bundled must have the same base name, with a suffix indicating the key
  type. Currently, three suffixes are supported: rsa, dsa and ecdsa. For
  example, if www.example.com has two PEM files, an RSA file and an ECDSA
  file, they must be named: "example.pem.rsa" and "example.pem.ecdsa". The
  first part of the filename is arbitrary; only the suffix matters. To load
  this bundle into HAProxy, specify the base name only:	

  Example :  bind :8443 ssl crt example.pem	

  Note that the suffix is not given to HAProxy; this tells HAProxy to look for
  a cert bundle.	

  HAProxy will load all PEM files in the bundle as if they were configured
  separately in several "crt".	

  The bundle loading does not have an impact anymore on the directory loading
  since files are loading separately.		

  On the CLI, bundles are seen as separate files, and the bundle extension is
  required to commit them.	

  OCSP files (.ocsp), issuer files (.issuer), Certificate Transparency (.sctl)
  as well as private keys (.key) are supported with multi-cert bundling.	

  "sctl": Try to load ".sctl" for each crt keyword. If provided for
  a backend certificate, it will be loaded but will not have any functional
  impact.	

  "ocsp": Try to load ".ocsp" for each crt keyword. If provided for
  a backend certificate, it will be loaded but will not have any functional
  impact.	

  "issuer": Try to load ".issuer" if the issuer of the OCSP file is
  not provided in the PEM file. If provided for a backend certificate, it will
  be loaded but will not have any functional impact.	

  "key": If the private key was not provided by the PEM file, try to load a
  file ".key" containing a private key.	

  The default behavior is "all".	
  Example:
    ssl-load-extra-files bundle sctl
    ssl-load-extra-files sctl ocsp issuer
    ssl-load-extra-files none
  See also: "crt", section 5.1 about bind options and section 5.2 about server
  options.	

ssl-server-verify [none|required]		
  The default behavior for SSL verify on servers side. If specified to 'none',
  servers certificates are not verified. The default is 'required' except if
  forced using cmdline option '-dV'.	

ssl-skip-self-issued-ca		
  Self issued CA, aka x509 root CA, is the anchor for chain validation: as a
  server is useless to send it, client must have it. Standard configuration
  need to not include such CA in PEM file. This option allows you to keep such
  CA in PEM file without sending it to the client. Use case is to provide
  issuer for ocsp without the need for '.issuer' file and be able to share it
  with 'issuers-chain-path'. This concerns all certificates without intermediate
  certificates. It's useless for BoringSSL, .issuer is ignored because ocsp
  bits does not need it. Requires at least OpenSSL 1.0.2.	

stats socket [<address:port>|<path>] [param*]	
  Binds a UNIX socket to <path> or a TCPv4/v6 address to <address:port>.
  Connections to this socket will return various statistics outputs and even
  allow some commands to be issued to change some runtime settings. Please
  consult section 9.3 "Unix Socket commands" of Management Guide for more
  details.	
  
  UNIX 소켓을 <path>에 바인딩하거나 TCPv4/v6 주소를 <address:port>에 
  바인딩합니다.  이 소켓에 대한 연결은 다양한 통계 출력을 반환하고 일부 런타임 
  설정을 변경하기 위해 일부 명령을 실행할 수도 있습니다.
  자세한 내용은 관리 가이드의 섹션 9.3 "Unix 소켓 명령"을 참조하십시오.  

  All parameters supported by "bind" lines are supported, for instance to
  restrict access to some users or their access rights. Please consult
  section 5.1 for more information.
  예를 들어 일부 사용자 또는 해당 액세스 권한에 대한 액세스를 제한하기 위해 
  "bind" 라인에서 지원하는 모든 매개변수가 지원됩니다.
  자세한 내용은 섹션 5.1을 참조하십시오.  

stats timeout <timeout, in milliseconds>	
  The default timeout on the stats socket is set to 10 seconds. It is possible
  to change this value with "stats timeout". The value must be passed in
  milliseconds, or be suffixed by a time unit among { us, ms, s, m, h, d }.
  통계 소켓의 기본 시간 초과는 10초로 설정됩니다. "stats timeout"으로 이 값을 
  변경할 수 있습니다.  값은 밀리초 단위로 전달되거나 { us, ms, s, m, h, d } 중에서 
  시간 단위로 접미사를 붙여야 합니다.

stats maxconn <connections>	
  By default, the stats socket is limited to 10 concurrent connections. It is
  possible to change this value with "stats maxconn".	
  기본적으로 통계 소켓은 10개의 동시 연결로 제한됩니다.
  "stats maxconn"으로 이 값을 변경할 수 있습니다.  

thread-group <group> [<thread-range>...]	
  This setting is only available when support for threads was built in. It
  enumerates the list of threads that will compose thread group <group>.
  Thread numbers and group numbers start at 1. Thread ranges are defined either
  using a single thread number at once, or by specifying the lower and upper
  bounds delimited by a dash '-' (e.g. "1-16"). Unassigned threads will be
  automatically assigned to unassigned thread groups, and thread groups
  defined with this directive will never receive more threads than those
  defined. Defining the same group multiple times overrides previous
  definitions with the new one. See also "nbthread" and "thread-groups".	

  이 설정은 스레드 지원이 내장된 경우에만 사용할 수 있습니다.
  스레드 그룹 <group>을 구성할 스레드 목록을 열거합니다.
  스레드 번호와 그룹 번호는 1부터 시작합니다.
  스레드 범위는 한 번에 단일 스레드 번호를 사용하거나 대시 '-'로 구분된 하한 및 
  상한을 지정하여 정의됩니다(예: "1-16").
  할당되지 않은 스레드는 할당되지 않은 스레드 그룹에 자동으로 할당되며 이 
  지시문으로 정의된 스레드 그룹은 정의된 스레드보다 더 많은 스레드를 수신하지 않습니다.
  동일한 그룹을 여러 번 정의하면 이전 정의가 새 정의로 재정의됩니다.
  "nbthread" 및 "thread-groups"도 참조하십시오.

thread-groups <number>	
  This setting is only available when support for threads was built in. It
  makes HAProxy split its threads into <number> independent groups. At the
  moment, the limit is 1 and is also the default value. See also "nbthread".	
  이 설정은 스레드 지원이 내장된 경우에만 사용할 수 있습니다.
  HAProxy가 스레드를 <number>개의 독립 그룹으로 분할합니다.
  현재 제한은 1이며 기본값이기도 합니다. "nbthread"도 참조하십시오.  

uid <number>	
  Changes the process's user ID to <number>. It is recommended that the user ID
  is dedicated to HAProxy or to a small set of similar daemons. HAProxy must
  be started with superuser privileges in order to be able to switch to another
  one. See also "gid" and "user".	
  프로세스의 사용자 ID를 <number>로 변경합니다. 사용자 ID는 HAProxy 또는 유사한 
  데몬의 소규모 세트 전용으로 사용하는 것이 좋습니다. 다른 권한으로 전환하려면 
  수퍼유저 권한으로 HAProxy를 시작해야 합니다. "gid" 및 "user"도 참조하십시오.	

ulimit-n <number>		
  Sets the maximum number of per-process file-descriptors to <number>. By
  default, it is automatically computed, so it is recommended not to use this
  option. If the intent is only to limit the number of file descriptors, better
  use "fd-hard-limit" instead.	
  프로세스당 최대 파일 설명자 수를 <number>로 설정합니다.
  기본적으로 자동으로 계산되므로 이 옵션을 사용하지 않는 것이 좋습니다.
  파일 디스크립터의 수를 제한하려는 의도라면 대신 "fd-hard-limit"를 사용하는 것이 좋습니다.  

  Note that the dynamic servers are not taken into account in this automatic
  resource calculation. If using a large number of them, it may be needed to
  manually specify this value.	
  이 자동 리소스 계산에서 동적 서버는 고려되지 않습니다.
  많은 수를 사용하는 경우 이 값을 수동으로 지정해야 할 수 있습니다.  

  See also: fd-hard-limit, maxconn	

unix-bind [ prefix <prefix> ] [ mode <mode> ] [ user <user> ] [ uid <uid> ]
          [ group <group> ] [ gid <gid> ]	

  Fixes common settings to UNIX listening sockets declared in "bind" statements.
  This is mainly used to simplify declaration of those UNIX sockets and reduce
  the risk of errors, since those settings are most commonly required but are
  also process-specific. The <prefix> setting can be used to force all socket
  path to be relative to that directory. This might be needed to access another
  component's chroot. Note that those paths are resolved before HAProxy chroots
  itself, so they are absolute. The <mode>, <user>, <uid>, <group> and <gid>
  all have the same meaning as their homonyms used by the "bind" statement. If
  both are specified, the "bind" statement has priority, meaning that the
  "unix-bind" settings may be seen as process-wide default settings.	

  "bind" 문에서 선언된 UNIX 청취 소켓에 대한 일반 설정을 수정합니다.
  이러한 설정은 가장 일반적으로 필요하지만 프로세스에 따라 다르기 때문에 주로 
  해당 UNIX 소켓의 선언을 단순화하고 오류 위험을 줄이는 데 사용됩니다.
  <prefix> 설정을 사용하여 모든 소켓 경로가 해당 디렉토리에 상대적이 되도록 할 수 있습니다.
  이것은 다른 구성 요소의 chroot에 액세스하는 데 필요할 수 있습니다.
  이러한 경로는 HAProxy chroots 자체보다 먼저 확인되므로 절대적입니다.
  <mode>, <user>, <uid>, <group> 및 <gid>는 모두 "bind" 문에서 사용되는 
  동음이의어와 동일한 의미를 갖습니다.
  둘 다 지정된 경우 "bind" 문이 우선 순위를 가지며 "unix-bind" 설정이 프로세스 
  전체의 기본 설정으로 표시될 수 있음을 의미합니다.

unsetenv [<name> ...]	
  Removes environment variables specified in arguments. This can be useful to
  hide some sensitive information that are occasionally inherited from the
  user's environment during some operations. Variables which did not exist are
  silently ignored so that after the operation, it is certain that none of
  these variables remain. The changes immediately take effect so that the next
  line in the configuration file will not see these variables. 
  See also "setenv", "presetenv", and "resetenv".	

  인수에 지정된 환경 변수를 제거합니다.
  이는 일부 작업 중에 사용자 환경에서 가끔 상속되는 민감한 정보를 숨기는 데 유용할 수 있습니다.  
  존재하지 않는 변수는 자동으로 무시되므로 작업 후 이러한 변수가 남아 있지 않습니다.
  변경 사항은 즉시 적용되므로 구성 파일의 다음 줄에는 이러한 변수가 표시되지 않습니다. 
  "setenv", "presetenv" 및 "resetenv"도 참조하십시오.  

user <user name>	
  Similar to "uid" but uses the UID of user name <user name> from /etc/passwd.
  "uid"와 유사하지만 /etc/passwd에서 사용자 이름 <user name>의 UID를 사용합니다.
  See also "uid" and "group".	

node <name>		
  Only letters, digits, hyphen and underscore are allowed, like in DNS names.	
  DNS 이름과 같이 문자, 숫자, 하이픈 및 밑줄만 허용됩니다.

  This statement is useful in HA configurations where two or more processes or
  servers share the same IP address. By setting a different node-name on all
  nodes, it becomes easy to immediately spot what server is handling the
  traffic.	
  이 명령문은 둘 이상의 프로세스 또는 서버가 동일한 IP 주소를 공유하는 HA 구성에서 
  유용합니다.  모든 노드에 다른 노드 이름을 설정하면 트래픽을 처리하는 서버를 즉시 쉽게 
  파악할 수 있습니다.  

description <text>		
  Add a text that describes the instance.	
  인스턴스를 설명하는 텍스트를 추가합니다.

  Please note that it is required to escape certain characters (# for example)
  and this text is inserted into a html page so you should avoid using
  "<" and ">" characters.	
  특정 문자(예: #)를 이스케이프해야 하며 이 텍스트는 html 페이지에 삽입되므로 
  "<" 및 ">" 문자 사용을 피해야 합니다.

51degrees-data-file <file path>		
  The path of the 51Degrees data file to provide device detection services. The
  file should be unzipped and accessible by HAProxy with relevant permissions.
  장치 감지 서비스를 제공하기 위한 51Degrees 데이터 파일의 경로입니다.
  파일은 압축을 풀고 관련 권한이 있는 HAProxy에서 액세스할 수 있어야 합니다.

  Please note that this option is only available when HAProxy has been
  compiled with USE_51DEGREES.
  이 옵션은 HAProxy가 USE_51DEGREES로 컴파일된 경우에만 사용할 수 있습니다.  

51degrees-property-name-list [<string> ...]		
  A list of 51Degrees property names to be load from the dataset. A full list
  of names is available on the 51Degrees website:	
  데이터세트에서 로드할 51Degrees 속성 이름 목록입니다.
  전체 이름 목록은 51Degrees 웹사이트에서 확인할 수 있습니다.  
  https://51degrees.com/resources/property-dictionary

  Please note that this option is only available when HAProxy has been
  compiled with USE_51DEGREES.
  이 옵션은 HAProxy가 USE_51DEGREES로 컴파일된 경우에만 사용할 수 있습니다.

51degrees-property-separator <char>		
  A char that will be appended to every property value in a response header
  containing 51Degrees results. If not set that will be set as ','.	
  51Degrees 결과를 포함하는 응답 헤더의 모든 속성 값에 추가되는 문자입니다. 
  설정하지 않으면 ','로 설정됩니다.

  Please note that this option is only available when HAProxy has been
  compiled with USE_51DEGREES.	
  이 옵션은 HAProxy가 USE_51DEGREES로 컴파일된 경우에만 사용할 수 있습니다.

51degrees-cache-size <number>		
  Sets the size of the 51Degrees converter cache to <number> entries. This
  is an LRU cache which reminds previous device detections and their results.
  By default, this cache is disabled.
  51Degrees 변환기 캐시의 크기를 <number> 항목으로 설정합니다.
  이것은 이전 장치 감지 및 그 결과를 상기시키는 LRU 캐시입니다.
  기본적으로 이 캐시는 비활성화되어 있습니다.  

  Please note that this option is only available when HAProxy has been
  compiled with USE_51DEGREES.	
  이 옵션은 HAProxy가 USE_51DEGREES로 컴파일된 경우에만 사용할 수 있습니다.

wurfl-data-file <file path>		
  The path of the WURFL data file to provide device detection services. The
  file should be accessible by HAProxy with relevant permissions.	
  장치 감지 서비스를 제공하기 위한 WURFL 데이터 파일의 경로입니다.
  파일은 관련 권한이 있는 HAProxy에서 액세스할 수 있어야 합니다.

  Please note that this option is only available when HAProxy has been compiled
  with USE_WURFL=1.	
  이 옵션은 HAProxy가 USE_WURFL=1로 컴파일된 경우에만 사용할 수 있습니다.

wurfl-information-list [<capability>]*			
  A space-delimited list of WURFL capabilities, virtual capabilities, property
  names we plan to use in injected headers. A full list of capability and
  virtual capability names is available on the Scientiamobile website :
  WURFL 기능, 가상 기능, 삽입된 헤더에서 사용할 속성 이름의 공백으로 구분된 목록입니다. 
  기능 및 가상 기능 이름의 전체 목록은 Scientiamobile 웹사이트에서 확인할 수 있습니다.  
      
  https://www.scientiamobile.com/wurflCapability
  Valid WURFL properties are:
  - wurfl_id                    Contains the device ID of the matched device.

  - wurfl_root_id               Contains the device root ID of the matched
                                device.

  - wurfl_isdevroot             Tells if the matched device is a root device.
                                Possible values are "TRUE" or "FALSE".

  - wurfl_useragent             The original useragent coming with this
                                particular web request.

  - wurfl_api_version           Contains a string representing the currently
                                used Libwurfl API version.

  - wurfl_info                  A string containing information on the parsed
                                wurfl.xml and its full path.

  - wurfl_last_load_time        Contains the UNIX timestamp of the last time
                                WURFL has been loaded successfully.

  - wurfl_normalized_useragent  The normalized useragent.
  Please note that this option is only available when HAProxy has been compiled
  with USE_WURFL=1.
  이 옵션은 HAProxy가 USE_WURFL=1로 컴파일된 경우에만 사용할 수 있습니다.  

wurfl-information-list-separator <char>	
  A char that will be used to separate values in a response header containing
  WURFL results. If not set that a comma (',') will be used by default.	

  Please note that this option is only available when HAProxy has been compiled
  with USE_WURFL=1.	

wurfl-patch-file [<file path>]	
  A list of WURFL patch file paths. Note that patches are loaded during startup
  thus before the chroot.	

  Please note that this option is only available when HAProxy has been compiled
  with USE_WURFL=1.	

wurfl-cache-size <size>	
  Sets the WURFL Useragent cache size. For faster lookups, already processed user
  agents are kept in a LRU cache :
  - "0"     : no cache is used.
  - <size>  : size of lru cache in elements.

  Please note that this option is only available when HAProxy has been compiled
  with USE_WURFL=1.

strict-limits
  Makes process fail at startup when a setrlimit fails. HAProxy tries to set the
  best setrlimit according to what has been calculated. If it fails, it will
  emit a warning. This option is here to guarantee an explicit failure of
  HAProxy when those limits fail. It is enabled by default. It may still be
  forcibly disabled by prefixing it with the "no" keyword.
  
  setrlimit가 실패하면 시작 시 프로세스가 실패하도록 합니다. 
  HAProxy는 계산된 내용에 따라 최상의 setrlimit를 설정하려고 시도합니다.
  실패하면 경고를 내보냅니다. 이 옵션은 해당 제한이 실패할 때 HAProxy의 명시적 실패를 
  보장하기 위해 여기에 있습니다.
  기본적으로 활성화되어 있습니다. "no" 키워드 접두사를 붙여 강제로 비활성화할 수 있습니다.  

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가 설정된 경우 적용됩니다.

  See also: fd-hard-limit, ulimit-n

maxconnrate <number>		
  Sets the maximum per-process number of connections per second to <number>.
  Proxies will stop accepting connections when this limit is reached. It can be
  used to limit the global capacity regardless of each frontend capacity. It is
  important to note that this can only be used as a service protection measure,
  as there will not necessarily be a fair share between frontends when the
  limit is reached, so it's a good idea to also limit each frontend to some
  value close to its expected share. Also, lowering tune.maxaccept can improve
  fairness.	

  초당 프로세스별 최대 연결 수를 <number>로 설정합니다.
  프록시는 이 제한에 도달하면 연결 수락을 중지합니다.
  각 프런트엔드 용량에 관계없이 전역 용량을 제한하는 데 사용할 수 있습니다.
  한도에 도달했을 때 프런트엔드 간에 공정한 공유가 반드시 있는 것은 아니므로 서비스 
  보호 조치로만 사용할 수 있다는 점에 유의해야 합니다.
  따라서 각 프런트엔드를 예상 점유율에 가까운 값으로 제한하는 것도 좋은 생각입니다.
  또한 tune.maxaccept를 낮추면 공정성이 향상될 수 있습니다.  

maxcomprate <number>		
  Sets the maximum per-process input compression rate to <number> kilobytes
  per second. For each session, if the maximum is reached, the compression
  level will be decreased during the session. If the maximum is reached at the
  beginning of a session, the session will not compress at all. If the maximum
  is not reached, the compression level will be increased up to
  tune.comp.maxlevel. A value of zero means there is no limit, this is the
  default value.	

  프로세스당 최대 입력 압축률을 초당 <number> 킬로바이트로 설정합니다.
  각 세션에 대해 최대값에 도달하면 세션 동안 압축 수준이 감소합니다.
  세션 시작 시 최대값에 도달하면 세션이 전혀 압축되지 않습니다.
  최대값에 도달하지 않으면 압축 수준이 tune.comp.maxlevel까지 증가합니다.
  0 값은 제한이 없음을 의미하며 이것이 기본값입니다.

maxcompcpuusage <number>		
  Sets the maximum CPU usage HAProxy can reach before stopping the compression
  for new requests or decreasing the compression level of current requests.
  It works like 'maxcomprate' but measures CPU usage instead of incoming data
  bandwidth. The value is expressed in percent of the CPU used by HAProxy. A
  value of 100 disable the limit. The default value is 100. Setting a lower
  value will prevent the compression work from slowing the whole process down
  and from introducing high latencies.	
  
  새 요청에 대한 압축을 중지하거나 현재 요청의 압축 수준을 낮추기 전에 HAProxy가 도달할 수 
  있는 최대 CPU 사용량을 설정합니다.
  'maxcomprate'처럼 작동하지만 들어오는 데이터 대역폭 대신 CPU 사용량을 측정합니다. 
  이 값은 HAProxy에서 사용하는 CPU의 백분율로 표시됩니다.
  값 100은 제한을 비활성화합니다.  기본값은 100입니다. 
  더 낮은 값을 설정하면 압축 작업으로 인해 전체 프로세스가 느려지고 대기 시간이 길어지는 
  것을 방지할 수 있습니다.  

maxpipes <number>		
  Sets the maximum per-process number of pipes to <number>. Currently, pipes
  are only used by kernel-based tcp splicing. Since a pipe contains two file
  descriptors, the "ulimit-n" value will be increased accordingly. The default
  value is maxconn/4, which seems to be more than enough for most heavy usages.
  The splice code dynamically allocates and releases pipes, and can fall back
  to standard copy, so setting this value too low may only impact performance.	

  프로세스당 최대 파이프 수를 <number>로 설정합니다.
  현재 파이프는 커널 기반 tcp splicing에서만 사용됩니다. 
  파이프에는 두 개의 파일 설명자가 포함되어 있으므로 "ulimit-n" 값이 그에 따라 증가합니다.
  기본값은 maxconn/4이며 대부분의 대량 사용에 충분합니다.
  스플라이스 코드는 파이프를 동적으로 할당 및 해제하고 표준 복사본으로 폴백할 수 
  있으므로 이 값을 너무 낮게 설정하면 성능에만 영향을 미칠 수 있습니다.

maxsessrate <number>		
  Sets the maximum per-process number of sessions per second to <number>.
  Proxies will stop accepting connections when this limit is reached. It can be
  used to limit the global capacity regardless of each frontend capacity. It is
  important to note that this can only be used as a service protection measure,
  as there will not necessarily be a fair share between frontends when the
  limit is reached, so it's a good idea to also limit each frontend to some
  value close to its expected share. Also, lowering tune.maxaccept can improve
  fairness.	

  초당 프로세스당 최대 세션 수를 <number>로 설정합니다.
  프록시는 이 제한에 도달하면 연결 수락을 중지합니다.
  각 프런트엔드 용량에 관계없이 전역 용량을 제한하는 데 사용할 수 있습니다.
  한도에 도달했을 때 프런트엔드 간에 공정한 공유가 반드시 있는 것은 아니므로 서비스 
  보호 조치로만 사용할 수 있다는 점에 유의해야 합니다.
  따라서 각 프런트엔드를 예상 점유율에 가까운 값으로 제한하는 것도 좋은 생각입니다.
  또한 tune.maxaccept를 낮추면 공정성이 향상될 수 있습니다.

maxsslconn <number>		
  Sets the maximum per-process number of concurrent SSL connections to
  <number>. By default there is no SSL-specific limit, which means that the
  global maxconn setting will apply to all connections. Setting this limit
  avoids having openssl use too much memory and crash when malloc returns NULL
  (since it unfortunately does not reliably check for such conditions). Note
  that the limit applies both to incoming and outgoing connections, so one
  connection which is deciphered then ciphered accounts for 2 SSL connections.
  If this value is not set, but a memory limit is enforced, this value will be
  automatically computed based on the memory limit, maxconn,  the buffer size,
  memory allocated to compression, SSL cache size, and use of SSL in either
  frontends, backends or both. If neither maxconn nor maxsslconn are specified
  when there is a memory limit, HAProxy will automatically adjust these values
  so that 100% of the connections can be made over SSL with no risk, and will
  consider the sides where it is enabled (frontend, backend, both).	

  동시 SSL 연결의 프로세스당 최대 수를 <number>로 설정합니다.
  기본적으로 SSL 관련 제한이 없으므로 전역 maxconn 설정이 모든 연결에 적용됩니다.
  이 제한을 설정하면 malloc이 NULL을 반환할 때 openssl이 너무 많은 메모리를 사용하고 
  충돌하는 것을 방지할 수 있습니다(불행히도 이러한 조건을 안정적으로 확인하지 않기 때문입니다).
  이 제한은 들어오는 연결과 나가는 연결 모두에 적용되므로 해독된 다음 암호화되는 
  하나의 연결은 2개의 SSL 연결을 차지합니다.
  이 값이 설정되지 않았지만 메모리 제한이 적용된 경우 이 값은 메모리 제한, maxconn, 
  버퍼 크기, 압축에 할당된 메모리, SSL 캐시 크기 및 프런트엔드, 백엔드에서 SSL 사용을 
  기반으로 자동으로 계산됩니다. 아니면 둘다.
  메모리 제한이 있을 때 maxconn과 maxsslconn이 모두 지정되지 않은 경우 
  HAProxy는 이러한 값을 자동으로 조정하여 연결의 100%가 위험 없이 
  SSL을 통해 이루어질 수 있도록 하고 활성화된 측면(프론트엔드, 백엔드, 둘 다)
  을 고려합니다.

maxsslrate <number>		
  Sets the maximum per-process number of SSL sessions per second to <number>.
  SSL listeners will stop accepting connections when this limit is reached. It
  can be used to limit the global SSL CPU usage regardless of each frontend
  capacity. It is important to note that this can only be used as a service
  protection measure, as there will not necessarily be a fair share between
  frontends when the limit is reached, so it's a good idea to also limit each
  frontend to some value close to its expected share. It is also important to
  note that the sessions are accounted before they enter the SSL stack and not
  after, which also protects the stack against bad handshakes. Also, lowering
  tune.maxaccept can improve fairness.	

  초당 SSL 세션의 프로세스당 최대 수를 <number>로 설정합니다.
  SSL 수신기는 이 제한에 도달하면 연결 수락을 중지합니다.
  각 프런트엔드 용량에 관계없이 글로벌 SSL CPU 사용량을 제한하는 데 사용할 수 있습니다.
  한도에 도달했을 때 프런트엔드 간에 공정한 공유가 반드시 있는 것은 아니므로 서비스 
  보호 조치로만 사용할 수 있다는 점에 유의해야 합니다.
  따라서 각 프런트엔드를 예상 점유율에 가까운 값으로 제한하는 것도 좋은 생각입니다.
  또한 세션이 SSL 스택에 들어가기 전에 계산되고 이후가 아니라 잘못된 핸드셰이크로부터 
  스택을 보호한다는 점에 유의하는 것이 중요합니다.
  또한 tune.maxaccept를 낮추면 공정성이 향상될 수 있습니다.

maxzlibmem <number>		
  Sets the maximum amount of RAM in megabytes per process usable by the zlib.
  When the maximum amount is reached, future sessions will not compress as long
  as RAM is unavailable. When sets to 0, there is no limit.
  The default value is 0. The value is available in bytes on the UNIX socket
  with "show info" on the line "MaxZlibMemUsage", the memory used by zlib is
  "ZlibMemUsage" in bytes.	

  zlib에서 사용할 수 있는 프로세스당 최대 RAM 양(MB)을 설정합니다.
  최대 용량에 도달하면 RAM을 사용할 수 없는 한 이후 세션은 압축되지 않습니다. 
  0으로 설정하면 제한이 없습니다.  기본값은 0입니다.
  값은 "MaxZlibMemUsage" 줄에 "show info"가 있는 UNIX 소켓에서 바이트 단위로 
  사용할 수 있으며, zlib에서 사용하는 메모리는 "ZlibMemUsage" 바이트 단위입니다.

no-memory-trimming		
  Disables memory trimming ("malloc_trim") at a few moments where attempts are
  made to reclaim lots of memory (on memory shortage or on reload). Trimming
  memory forces the system's allocator to scan all unused areas and to release
  them. This is generally seen as nice action to leave more available memory to
  a new process while the old one is unlikely to make significant use of it.
  But some systems dealing with tens to hundreds of thousands of concurrent
  connections may experience a lot of memory fragmentation, that may render
  this release operation extremely long. During this time, no more traffic
  passes through the process, new connections are not accepted anymore, some
  health checks may even fail, and the watchdog may even trigger and kill the
  unresponsive process, leaving a huge core dump. If this ever happens, then it
  is suggested to use this option to disable trimming and stop trying to be
  nice with the new process. Note that advanced memory allocators usually do
  not suffer from such a problem.	

  많은 메모리를 회수하려는 시도(메모리 부족 또는 다시 로드 시)가 발생하는 순간에 메모리 
  트리밍("malloc_trim")을 비활성화합니다.
  트리밍 메모리는 시스템 할당자가 사용하지 않는 모든 영역을 검색하고 해제하도록 강제합니다.
  이것은 일반적으로 이전 프로세스가 메모리를 많이 사용하지 않는 동안 새 프로세스에 더 많은 
  사용 가능한 메모리를 남겨두는 좋은 조치로 간주됩니다.
  그러나 수만에서 수십만 개의 동시 연결을 처리하는 일부 시스템에서는 많은 메모리 조각화가 
  발생할 수 있으며, 이로 인해 이 릴리스 작업이 매우 길어질 수 있습니다.
  이 시간 동안 더 이상 트래픽이 프로세스를 통과하지 않고 새 연결이 더 이상 허용되지 않으며 
  일부 상태 확인이 실패할 수도 있고 워치독이 응답하지 않는 프로세스를 트리거하고 종료하여 
  막대한 코어 덤프를 남길 수도 있습니다.
  이런 일이 발생하면 이 옵션을 사용하여 트리밍을 비활성화하고 새 프로세스를 잘 사용하려는 
  시도를 중지하는 것이 좋습니다.
  고급 메모리 할당자는 일반적으로 이러한 문제를 겪지 않습니다.

noepoll		
  Disables the use of the "epoll" event polling system on Linux. It is
  equivalent to the command-line argument "-de". The next polling system
  used will generally be "poll". See also "nopoll".	
  Linux에서 "epoll" 이벤트 폴링 시스템의 사용을 비활성화합니다.
  명령줄 인수 "-de"와 동일합니다.
  다음에 사용되는 폴링 시스템은 일반적으로 "poll"입니다. "nopoll"도 참조하십시오.  

nokqueue		
  Disables the use of the "kqueue" event polling system on BSD. It is
  equivalent to the command-line argument "-dk". The next polling system
  used will generally be "poll". See also "nopoll".	
  BSD에서 "kqueue" 이벤트 폴링 시스템의 사용을 비활성화합니다.
  명령줄 인수 "-dk"와 동일합니다.
  다음에 사용되는 폴링 시스템은 일반적으로 "poll"입니다. "nopoll"도 참조하십시오.
  
noevports		
  Disables the use of the event ports event polling system on SunOS systems
  derived from Solaris 10 and later. It is equivalent to the command-line
  argument "-dv". The next polling system used will generally be "poll". See
  also "nopoll".	
  Solaris 10 이상에서 파생된 SunOS 시스템에서 이벤트 포트 이벤트 폴링 시스템의 
  사용을 비활성화합니다.  명령줄 인수 "-dv"와 동일합니다.
  다음에 사용되는 폴링 시스템은 일반적으로 "poll"입니다.
  "nopoll"도 참조하십시오.  

nopoll		
  Disables the use of the "poll" event polling system. It is equivalent to the
  command-line argument "-dp". The next polling system used will be "select".
  It should never be needed to disable "poll" since it's available on all
  platforms supported by HAProxy. See also "nokqueue", "noepoll" and
  "noevports".	

  "poll" 이벤트 폴링 시스템의 사용을 비활성화합니다.
  명령줄 인수 "-dp"와 동일합니다.  사용되는 다음 폴링 시스템은 "select"입니다.
  HAProxy가 지원하는 모든 플랫폼에서 사용할 수 있으므로 "poll"을 비활성화할 필요가 
  없습니다.
  "nokqueue", "noepoll" 및 "noevports"도 참조하십시오.

nosplice		
  Disables the use of kernel tcp splicing between sockets on Linux. It is
  equivalent to the command line argument "-dS". Data will then be copied
  using conventional and more portable recv/send calls. Kernel tcp splicing is
  limited to some very recent instances of kernel 2.6. Most versions between
  2.6.25 and 2.6.28 are buggy and will forward corrupted data, so they must not
  be used. This option makes it easier to globally disable kernel splicing in
  case of doubt. See also "option splice-auto", "option splice-request" and
  "option splice-response".	

  Linux에서 소켓 간의 커널 tcp splicing 사용을 비활성화합니다.
  명령줄 인수 "-dS"와 동일합니다.
  그런 다음 기존의 보다 휴대 가능한 수신/전송 호출을 사용하여 데이터를 복사합니다.
  커널 tcp 스플라이싱은 커널 2.6의 일부 최신 인스턴스로 제한됩니다. 
  2.6.25에서 2.6.28 사이의 대부분의 버전은 버그가 있고 손상된 데이터를 전달하므로 
  사용해서는 안 됩니다.  이 옵션을 사용하면 의심스러운 경우 커널 스플라이싱을 전역적으로 
  비활성화하는 것이 더 쉬워집니다.
  "option splice-auto", "option splice-request" 및 "option splice-response"도 참조하십시오.

nogetaddrinfo		
  Disables the use of getaddrinfo(3) for name resolving. It is equivalent to
  the command line argument "-dG". Deprecated gethostbyname(3) will be used.
  이름 확인을 위한 getaddrinfo(3) 사용을 비활성화합니다.
  명령줄 인수 "-dG"와 동일합니다.
  더 이상 사용되지 않는 gethostbyname(3)이 사용됩니다.

noreuseport		
  Disables the use of SO_REUSEPORT - see socket(7). It is equivalent to the
  command line argument "-dR".	
  SO_REUSEPORT 사용을 비활성화합니다. 
  socket(7)을 참조하십시오. 
  명령줄 인수 "-dR"과 동일합니다.

profiling.memory { on | off }		
  Enables ('on') or disables ('off') per-function memory profiling. This will
  keep usage statistics of malloc/calloc/realloc/free calls anywhere in the
  process (including libraries) which will be reported on the CLI using the
  "show profiling" command. This is essentially meant to be used when an
  abnormal memory usage is observed that cannot be explained by the pools and
  other info are required. The performance hit will typically be around 1%,
  maybe a bit more on highly threaded machines, so it is normally suitable for
  use in production. The same may be achieved at run time on the CLI using the
  "set profiling memory" command, please consult the management manual.	

  기능별 메모리 프로파일링을 활성화('on') 또는 비활성화('off')합니다.
  이렇게 하면 "show profiling" 명령을 사용하여 CLI에 보고되는 프로세스(라이브러리 포함)의 
  어디에서나 malloc/calloc/realloc/free 호출의 사용 통계가 유지됩니다.
  이것은 기본적으로 풀에서 설명할 수 없는 비정상적인 메모리 사용이 관찰되고 다른 정보가 
  필요할 때 사용하기 위한 것입니다.
  성능 적중은 일반적으로 약 1%이며 스레드가 많은 기계에서는 약간 더 높을 수 있으므로 
  일반적으로 생산에 사용하기에 적합합니다.
  "set profiling memory" 명령을 사용하여 CLI에서 런타임에 동일한 작업을 수행할 수 있습니다. 
  관리 설명서를 참조하십시오.

profiling.tasks { auto | on | off }		
  Enables ('on') or disables ('off') per-task CPU profiling. When set to 'auto'
  the profiling automatically turns on a thread when it starts to suffer from
  an average latency of 1000 microseconds or higher as reported in the
  "avg_loop_us" activity field, and automatically turns off when the latency
  returns below 990 microseconds (this value is an average over the last 1024
  loops so it does not vary quickly and tends to significantly smooth short
  spikes). It may also spontaneously trigger from time to time on overloaded
  systems, containers, or virtual machines, or when the system swaps (which
  must absolutely never happen on a load balancer).	

  작업별 CPU 프로파일링을 활성화('on') 또는 비활성화('off')합니다.
  'auto'으로 설정하면 프로파일링은 "avg_loop_us" 활동 필드에 보고된 평균 대기 시간이 
  1000마이크로초 이상인 스레드를 자동으로 켜고 대기 시간이 990마이크로초 미만으로 돌아오면 
  자동으로 꺼집니다(이는 값은 마지막 1024 루프에 대한 평균이므로 빠르게 변화하지 않고 
  짧은 스파이크를 상당히 부드럽게 하는 경향이 있습니다.
  또한 오버로드된 시스템, 컨테이너 또는 가상 머신에서 또는 시스템이 스왑될 때
  (로드 밸런서에서 절대로 발생해서는 안 됨) 때때로 자발적으로 트리거될 수 있습니다.

  CPU profiling per task can be very convenient to report where the time is
  spent and which requests have what effect on which other request. Enabling
  it will typically affect the overall's performance by less than 1%, thus it
  is recommended to leave it to the default 'auto' value so that it only
  operates when a problem is identified. This feature requires a system
  supporting the clock_gettime(2) syscall with clock identifiers
  CLOCK_MONOTONIC and CLOCK_THREAD_CPUTIME_ID, otherwise the reported time will
  be zero. This option may be changed at run time using "set profiling" on the
  CLI.	

  작업당 CPU 프로파일링은 시간이 소요되는 위치와 어떤 요청이 다른 요청에 어떤 영향을 
  미치는지 보고하는 데 매우 편리할 수 있습니다.
  활성화하면 일반적으로 전체 성능에 1% 미만의 영향을 미치므로 문제가 식별된 경우에만 
  작동하도록 기본 'auto' 값으로 두는 것이 좋습니다.
  이 기능을 사용하려면 시계 식별자 CLOCK_MONOTONIC 및 LOCK_THREAD_CPUTIME_ID가 
  있는 clock_gettime(2) 시스템 호출을 지원하는 시스템이 필요합니다. 
  그렇지 않으면 보고된 시간이 0이 됩니다.
  이 옵션은 CLI에서 "set profiling"을 사용하여 런타임에 변경할 수 있습니다.

spread-checks <0..50, in percent>		
  Sometimes it is desirable to avoid sending agent and health checks to
  servers at exact intervals, for instance when many logical servers are
  located on the same physical server. With the help of this parameter, it
  becomes possible to add some randomness in the check interval between 0
  and +/- 50%. A value between 2 and 5 seems to show good results. The
  default value remains at 0.	

  예를 들어 많은 논리 서버가 동일한 물리적 서버에 있는 경우와 같이 정확한 간격으로 
  서버에 에이전트 및 상태 검사를 보내지 않는 것이 바람직한 경우가 있습니다.
  이 매개변수의 도움으로 0에서 +/- 50% 사이의 확인 간격에 임의성을 추가할 수 있습니다.
  2에서 5 사이의 값이 좋은 결과를 나타내는 것 같습니다.
  기본값은 0으로 유지됩니다.  

ssl-engine <name> [algo <comma-separated list of algorithms>]		
  Sets the OpenSSL engine to <name>. List of valid values for <name> may be
  obtained using the command "openssl engine". This statement may be used
  multiple times, it will simply enable multiple crypto engines. Referencing an
  unsupported engine will prevent HAProxy from starting. Note that many engines
  will lead to lower HTTPS performance than pure software with recent
  processors. The optional command "algo" sets the default algorithms an ENGINE
  will supply using the OPENSSL function ENGINE_set_default_string(). A value
  of "ALL" uses the engine for all cryptographic operations. If no list of
  algo is specified then the value of "ALL" is used. A comma-separated list
  of different algorithms may be specified, including: RSA, DSA, DH, EC, RAND,
  CIPHERS, DIGESTS, PKEY, PKEY_CRYPTO, PKEY_ASN1. This is the same format that
  openssl configuration file uses:	
  https://www.openssl.org/docs/man1.0.2/apps/config.html	

  OpenSSL 엔진을 <name>으로 설정합니다.
  <name>의 유효한 값 목록은 "openssl engine" 명령을 사용하여 얻을 수 있습니다.
  이 문은 여러 번 사용될 수 있으며 단순히 여러 암호화 엔진을 활성화합니다.
  지원되지 않는 엔진을 참조하면 HAProxy가 시작되지 않습니다.
  많은 엔진은 최신 프로세서를 사용하는 순수 소프트웨어보다 HTTPS 성능이 낮습니다.
  선택적 명령 "algo"는 ENGINE이 OPENSSL 함수 ENGINE_set_default_string()을 사용하여 
  제공할 기본 알고리즘을 설정합니다.
  "ALL" 값은 모든 암호화 작업에 엔진을 사용합니다.
  알고 목록이 지정되지 않은 경우 "ALL" 값이 사용됩니다. 
  RSA, DSA, DH, EC, RAND, CIPHERS, DIGESTS, PKEY, PKEY_CRYPTO, PKEY_ASN1을 포함하여 
  쉼표로 구분된 다양한 알고리즘 목록을 지정할 수 있습니다.
  이것은 openssl 구성 파일이 사용하는 것과 동일한 형식입니다.  

ssl-mode-async		
  Adds SSL_MODE_ASYNC mode to the SSL context. This enables asynchronous TLS
  I/O operations if asynchronous capable SSL engines are used. The current
  implementation supports a maximum of 32 engines. The Openssl ASYNC API
  doesn't support moving read/write buffers and is not compliant with
  HAProxy's buffer management. So the asynchronous mode is disabled on
  read/write  operations (it is only enabled during initial and renegotiation
  handshakes).	

  SSL 컨텍스트에 SSL_MODE_ASYNC 모드를 추가합니다.
  이것은 비동기 가능 SSL 엔진이 사용되는 경우 비동기 TLS I/O 조작을 가능하게 합니다.
  현재 구현은 최대 32개의 엔진을 지원합니다.
  Openssl ASYNC API는 읽기/쓰기 버퍼 이동을 지원하지 않으며 HAProxy의 버퍼 관리와 
  호환되지 않습니다.  따라서 비동기 모드는 읽기/쓰기 작업에서 비활성화됩니다
  (초기 및 재협상 핸드셰이크 중에만 활성화됨).
	
tune.buffers.limit <number>		
  Sets a hard limit on the number of buffers which may be allocated per process.
  The default value is zero which means unlimited. The minimum non-zero value
  will always be greater than "tune.buffers.reserve" and should ideally always
  be about twice as large. Forcing this value can be particularly useful to
  limit the amount of memory a process may take, while retaining a sane
  behavior. When this limit is reached, sessions which need a buffer wait for
  another one to be released by another session. Since buffers are dynamically
  allocated and released, the waiting time is very short and not perceptible
  provided that limits remain reasonable. In fact sometimes reducing the limit
  may even increase performance by increasing the CPU cache's efficiency. Tests
  have shown good results on average HTTP traffic with a limit to 1/10 of the
  expected global maxconn setting, which also significantly reduces memory
  usage. The memory savings come from the fact that a number of connections
  will not allocate 2*tune.bufsize. It is best not to touch this value unless
  advised to do so by an HAProxy core developer.	

  프로세스당 할당할 수 있는 버퍼 수에 대한 엄격한 제한을 설정합니다.
  기본값은 무제한을 의미하는 0입니다. 0이 아닌 최소값은 항상 "tune.buffers.reserve"보다 
  크고 이상적으로는 항상 두 배 정도 커야 합니다.
  이 값을 강제 적용하면 정상적인 동작을 유지하면서 프로세스가 사용할 수 있는 메모리 양을 
  제한하는 데 특히 유용할 수 있습니다.
  이 제한에 도달하면 버퍼가 필요한 세션은 다른 세션에서 다른 버퍼를 해제하기를 기다립니다.
  버퍼가 동적으로 할당되고 해제되기 때문에 대기 시간이 매우 짧고 제한이 합리적으로 
  유지된다면 인지할 수 없습니다.
  실제로 때때로 제한을 줄이면 CPU 캐시의 효율성이 증가하여 성능이 향상될 수도 있습니다.
  테스트 결과 평균 HTTP 트래픽에서 예상되는 전역 maxconn 설정의 1/10로 제한되는 좋은 
  결과가 나타났으며, 이는 메모리 사용량도 크게 줄입니다.
  메모리 절약은 많은 연결이 2*tune.bufsize를 할당하지 않는다는 사실에서 비롯됩니다.
  HAProxy 핵심 개발자가 권장하지 않는 한 이 값을 건드리지 않는 것이 가장 좋습니다.
	
tune.buffers.reserve <number>		
  Sets the number of buffers which are pre-allocated and reserved for use only
  during memory shortage conditions resulting in failed memory allocations. The
  minimum value is 2 and is also the default. There is no reason a user would
  want to change this value, it's mostly aimed at HAProxy core developers.	

  메모리 부족 상태에서 메모리 할당 실패가 발생한 경우에만 사용하도록 사전 할당 및 
  예약된 버퍼 수를 설정합니다.  최소값은 2이며 기본값이기도 합니다.
  사용자가 이 값을 변경할 이유가 없으며 대부분 HAProxy 핵심 개발자를 대상으로 합니다.
	
tune.bufsize <number>		
  Sets the buffer size to this size (in bytes). Lower values allow more
  sessions to coexist in the same amount of RAM, and higher values allow some
  applications with very large cookies to work. The default value is 16384 and
  can be changed at build time. It is strongly recommended not to change this
  from the default value, as very low values will break some services such as
  statistics, and values larger than default size will increase memory usage,
  possibly causing the system to run out of memory. At least the global maxconn
  parameter should be decreased by the same factor as this one is increased. In
  addition, use of HTTP/2 mandates that this value must be 16384 or more. If an
  HTTP request is larger than (tune.bufsize - tune.maxrewrite), HAProxy will
  return HTTP 400 (Bad Request) error. Similarly if an HTTP response is larger
  than this size, HAProxy will return HTTP 502 (Bad Gateway). Note that the
  value set using this parameter will automatically be rounded up to the next
  multiple of 8 on 32-bit machines and 16 on 64-bit machines.	

  버퍼 크기를 이 크기(바이트 단위)로 설정합니다.
  값이 낮을수록 같은 양의 RAM에 더 많은 세션이 공존할 수 있고 값이 높을수록 쿠키가 
  매우 큰 일부 응용 프로그램이 작동할 수 있습니다.
  기본값은 16384이며 빌드 시 변경할 수 있습니다.
  값이 너무 낮으면 통계와 같은 일부 서비스가 중단되고 기본 크기보다 큰 값은 메모리 
  사용량이 증가하여 시스템 메모리가 부족할 수 있으므로 기본값에서 변경하지 않는 것이 좋습니다.
  적어도 글로벌 maxconn 매개변수는 이 매개변수가 증가하는 것과 같은 비율로 감소되어야 합니다.
  또한 HTTP/2를 사용하려면 이 값이 16384 이상이어야 합니다.
  HTTP 요청이 (tune.bufsize - tune.maxrewrite)보다 큰 경우 HAProxy는 HTTP 400(잘못된 요청) 
  오류를 반환합니다.
  마찬가지로 HTTP 응답이 이 크기보다 큰 경우 HAProxy는 HTTP 502(잘못된 게이트웨이)를 반환합니다.
  이 매개변수를 사용하여 설정한 값은 자동으로 32비트 시스템에서는 8의 다음 배수로, 
  64비트 시스템에서는 16으로 반올림됩니다.
	
tune.comp.maxlevel <number>		
  Sets the maximum compression level. The compression level affects CPU
  usage during compression. This value affects CPU usage during compression.
  Each session using compression initializes the compression algorithm with
  this value. The default value is 1.	

  최대 압축 수준을 설정합니다.  압축 수준은 압축 중 CPU 사용량에 영향을 미칩니다.
  이 값은 압축 중 CPU 사용량에 영향을 미칩니다.
  압축을 사용하는 각 세션은 이 값으로 압축 알고리즘을 초기화합니다.
  기본값은 1입니다.
	
tune.fail-alloc		
  If compiled with DEBUG_FAIL_ALLOC or started with "-dMfail", gives the
  percentage of chances an allocation attempt fails. Must be between 0 (no
  failure) and 100 (no success). This is useful to debug and make sure memory
  failures are handled gracefully.	

  DEBUG_FAIL_ALLOC로 컴파일하거나 "-dMfail"로 시작한 경우 할당 시도가 실패할 
  확률을 제공합니다.  0(실패 없음)에서 100(성공 없음) 사이여야 합니다.
  이는 메모리 오류가 정상적으로 처리되도록 디버깅하고 확인하는 데 유용합니다.
	
tune.fd.edge-triggered { on | off }  [ EXPERIMENTAL ]		
  Enables ('on') or disables ('off') the edge-triggered polling mode for FDs
  that support it. This is currently only support with epoll. It may noticeably
  reduce the number of epoll_ctl() calls and slightly improve performance in
  certain scenarios. This is still experimental, it may result in frozen
  connections if bugs are still present, and is disabled by default.	

  이를 지원하는 FD에 대해 에지 트리거 폴링 모드를 활성화('on') 또는 비활성화('off')합니다.
  이것은 현재 epoll에서만 지원됩니다.
  epoll_ctl() 호출 수를 눈에 띄게 줄이고 특정 시나리오에서 성능을 약간 향상시킬 수 있습니다.
  이것은 아직 실험적이며 버그가 여전히 존재하는 경우 연결이 정지될 수 있으며 기본적으로 
  비활성화되어 있습니다.
	
tune.h2.header-table-size <number>		
  Sets the HTTP/2 dynamic header table size. It defaults to 4096 bytes and
  cannot be larger than 65536 bytes. A larger value may help certain clients
  send more compact requests, depending on their capabilities. This amount of
  memory is consumed for each HTTP/2 connection. It is recommended not to
  change it.	

  HTTP/2 동적 헤더 테이블 크기를 설정합니다. 기본값은 4096바이트이며 65536바이트보다 
  클 수 없습니다.  더 큰 값은 특정 클라이언트가 기능에 따라 더 압축된 요청을 보내는 데 
  도움이 될 수 있습니다.  이 양의 메모리는 각 HTTP/2 연결에 사용됩니다. 
  변경하지 않는 것이 좋습니다.
	
tune.h2.initial-window-size <number>		
  Sets the HTTP/2 initial window size, which is the number of bytes the client
  can upload before waiting for an acknowledgment from HAProxy. This setting
  only affects payload contents (i.e. the body of POST requests), not headers.
  The default value is 65535, which roughly allows up to 5 Mbps of upload
  bandwidth per client over a network showing a 100 ms ping time, or 500 Mbps
  over a 1-ms local network. It can make sense to increase this value to allow
  faster uploads, or to reduce it to increase fairness when dealing with many
  clients. It doesn't affect resource usage.	

  클라이언트가 HAProxy의 승인을 기다리기 전에 업로드할 수 있는 바이트 수인 HTTP/2 
  초기 창 크기를 설정합니다.
  이 설정은 헤더가 아닌 페이로드 콘텐츠(예: POST 요청 본문)에만 영향을 미칩니다.
  기본값은 65535이며, 100ms 핑 시간을 나타내는 네트워크를 통해 클라이언트당 
  대략 5Mbps의 업로드 대역폭 또는 1ms 로컬 네트워크를 통해 500Mbps를 허용합니다.
  더 빠른 업로드를 위해 이 값을 늘리거나 많은 클라이언트를 처리할 때 공정성을 높이기 
  위해 값을 줄이는 것이 합리적일 수 있습니다. 리소스 사용량에는 영향을 미치지 않습니다.
	
tune.h2.max-concurrent-streams <number>		
  Sets the HTTP/2 maximum number of concurrent streams per connection (ie the
  number of outstanding requests on a single connection). The default value is
  100. A larger one may slightly improve page load time for complex sites when
  visited over high latency networks, but increases the amount of resources a
  single client may allocate. A value of zero disables the limit so a single
  client may create as many streams as allocatable by HAProxy. It is highly
  recommended not to change this value.	

  연결당 HTTP/2 최대 동시 스트림 수(즉, 단일 연결의 미해결 요청 수)를 설정합니다. 
  기본값은 100입니다.  더 큰 것은 대기 시간이 긴 네트워크를 통해 방문할 때 복잡한 
  사이트의 페이지 로드 시간을 약간 개선할 수 있지만 단일 클라이언트가 할당할 수 있는 
  리소스의 양을 증가시킵니다.
  0 값은 제한을 비활성화하므로 단일 클라이언트가 HAProxy에서 할당할 수 있는 만큼의 
  스트림을 생성할 수 있습니다.  이 값을 변경하지 않는 것이 좋습니다.
	
tune.h2.max-frame-size <number>		
  Sets the HTTP/2 maximum frame size that HAProxy announces it is willing to
  receive to its peers. The default value is the largest between 16384 and the
  buffer size (tune.bufsize). In any case, HAProxy will not announce support
  for frame sizes larger than buffers. The main purpose of this setting is to
  allow to limit the maximum frame size setting when using large buffers. Too
  large frame sizes might have performance impact or cause some peers to
  misbehave. It is highly recommended not to change this value.	

  HAProxy가 피어에게 수신할 의향이 있다고 발표하는 HTTP/2 최대 프레임 크기를 설정합니다.
  기본값은 16384와 버퍼 크기(tune.bufsize) 사이에서 가장 큰 값입니다.
  어쨌든 HAProxy는 버퍼보다 큰 프레임 크기에 대한 지원을 발표하지 않습니다.
  이 설정의 주요 목적은 큰 버퍼를 사용할 때 최대 프레임 크기 설정을 제한할 수 있도록 
  하는 것입니다.  프레임 크기가 너무 크면 성능에 영향을 미치거나 일부 피어가 
  오작동할 수 있습니다. 이 값을 변경하지 않는 것이 좋습니다.
	
tune.http.cookielen <number>		
  Sets the maximum length of captured cookies. This is the maximum value that
  the "capture cookie xxx len yyy" will be allowed to take, and any upper value
  will automatically be truncated to this one. It is important not to set too
  high a value because all cookie captures still allocate this size whatever
  their configured value (they share a same pool). This value is per request
  per response, so the memory allocated is twice this value per connection.
  When not specified, the limit is set to 63 characters. It is recommended not
  to change this value.	

  캡처된 쿠키의 최대 길이를 설정합니다.
  이것은 "capture cookie xxx len yyy"가 취할 수 있는 최대값이며 상위 값은 자동으로 
  이 값으로 잘립니다.  모든 쿠키 캡처는 구성된 값(동일한 풀을 공유함)이 무엇이든 
  여전히 이 크기를 할당하기 때문에 너무 높은 값을 설정하지 않는 것이 중요합니다.
  이 값은 요청당 응답당이므로 할당된 메모리는 연결당 이 값의 두 배입니다.
  지정하지 않으면 63자로 제한됩니다. 이 값은 변경하지 않는 것이 좋습니다.
	
tune.http.logurilen <number>		
  Sets the maximum length of request URI in logs. This prevents truncating long
  request URIs with valuable query strings in log lines. This is not related
  to syslog limits. If you increase this limit, you may also increase the
  'log ... len yyy' parameter. Your syslog daemon may also need specific
  configuration directives too.
  The default value is 1024.	

  로그에서 요청 URI의 최대 길이를 설정합니다.  이렇게 하면 로그 라인에서 중요한 
  쿼리 문자열이 포함된 긴 요청 URI가 잘리는 것을 방지할 수 있습니다.
  이는 syslog 한계와 관련이 없습니다.
  이 제한을 늘리면 'log ... len yyy' 매개변수도 늘릴 수 있습니다.
  syslog 데몬에도 특정 구성 지시문이 필요할 수 있습니다.
  기본값은 1024입니다.
	
tune.http.maxhdr <number>		
  Sets the maximum number of headers in a request. When a request comes with a
  number of headers greater than this value (including the first line), it is
  rejected with a "400 Bad Request" status code. Similarly, too large responses
  are blocked with "502 Bad Gateway". The default value is 101, which is enough
  for all usages, considering that the widely deployed Apache server uses the
  same limit. It can be useful to push this limit further to temporarily allow
  a buggy application to work by the time it gets fixed. The accepted range is
  1..32767. Keep in mind that each new header consumes 32bits of memory for
  each session, so don't push this limit too high.	

  요청의 최대 헤더 수를 설정합니다.  요청이 이 값(첫 번째 줄 포함)보다 많은 수의 헤더와 
  함께 제공되면 "400 잘못된 요청" 상태 코드와 함께 거부됩니다. 마찬가지로 너무 큰 응답은 
  "502 잘못된 게이트웨이"로 차단됩니다.
  기본값은 101이며 널리 배포된 Apache 서버가 동일한 제한을 사용한다는 점을 고려하면 
  모든 용도에 충분합니다.  버그가 있는 응용 프로그램이 수정될 때까지 일시적으로 
  작동하도록 이 제한을 더 늘리는 것이 유용할 수 있습니다.
  허용되는 범위는 1..32767입니다.
  각각의 새 헤더는 각 세션에 대해 32비트의 메모리를 사용하므로 이 제한을 너무 높게 
  설정하지 마십시오.
	
tune.idle-pool.shared { on | off }		
  Enables ('on') or disables ('off') sharing of idle connection pools between
  threads for a same server. The default is to share them between threads in
  order to minimize the number of persistent connections to a server, and to
  optimize the connection reuse rate. But to help with debugging or when
  suspecting a bug in HAProxy around connection reuse, it can be convenient to
  forcefully disable this idle pool sharing between multiple threads, and force
  this option to "off". The default is on. It is strongly recommended against
  disabling this option without setting a conservative value on "pool-low-conn"
  for all servers relying on connection reuse to achieve a high performance
  level, otherwise connections might be closed very often as the thread count
  increases.	

  동일한 서버의 스레드 간에 유휴 연결 풀 공유를 활성화('on') 또는 비활성화('off')합니다.
  기본값은 서버에 대한 지속적인 연결 수를 최소화하고 연결 재사용률을 최적화하기 위해 
  스레드 간에 공유하는 것입니다.  그러나 디버깅에 도움이 되거나 연결 재사용과 관련된 
  HAProxy의 버그가 의심되는 경우 여러 스레드 간에 이 유휴 풀 공유를 강제로 비활성화하고 
  이 옵션을 강제로 "off"하는 것이 편리할 수 있습니다.
  기본값은 켜져 있습니다. 높은 성능 수준을 달성하기 위해 연결 재사용에 의존하는 
  모든 서버에 대해 "pool-low-conn"에 보수적인 값을 설정하지 않고 이 옵션을 비활성화하지 
  않는 것이 좋습니다. 그렇지 않으면 스레드 수가 증가함에 따라 연결이 매우 자주 닫힐 수 있습니다.
	
tune.idletimer <timeout>		
  Sets the duration after which HAProxy will consider that an empty buffer is
  probably associated with an idle stream. This is used to optimally adjust
  some packet sizes while forwarding large and small data alternatively. The
  decision to use splice() or to send large buffers in SSL is modulated by this
  parameter. The value is in milliseconds between 0 and 65535. A value of zero
  means that HAProxy will not try to detect idle streams. The default is 1000,
  which seems to correctly detect end user pauses (e.g. read a page before
  clicking). There should be no reason for changing this value. Please check
  tune.ssl.maxrecord below.	

  HAProxy가 빈 버퍼가 아마도 유휴 스트림과 연결되어 있다고 간주하는 기간을 설정합니다.
  크고 작은 데이터를 번갈아 전달하면서 일부 패킷 크기를 최적으로 조정하는 데 사용됩니다.
  splice()를 사용하거나 SSL에서 큰 버퍼를 보내는 결정은 이 매개변수에 의해 조정됩니다.
  값은 0에서 65535 사이의 밀리초 단위입니다.
  0 값은 HAProxy가 유휴 스트림 감지를 시도하지 않음을 의미합니다.
  기본값은 1000이며 최종 사용자 일시 중지를 올바르게 감지하는 것 같습니다
  (예: 클릭하기 전에 페이지 읽기).  이 값을 변경할 이유가 없습니다.
  아래의 tune.ssl.maxrecord를 확인하십시오.
	
tune.listener.multi-queue { on | off }		
  Enables ('on') or disables ('off') the listener's multi-queue accept which
  spreads the incoming traffic to all threads a "bind" line is allowed to run
  on instead of taking them for itself. This provides a smoother traffic
  distribution and scales much better, especially in environments where threads
  may be unevenly loaded due to external activity (network interrupts colliding
  with one thread for example). This option is enabled by default, but it may
  be forcefully disabled for troubleshooting or for situations where it is
  estimated that the operating system already provides a good enough
  distribution and connections are extremely short-lived.	

  들어오는 트래픽을 "bind" 라인이 자체적으로 처리하는 대신 실행할 수 있는 모든 
  스레드로 분산시키는 수신기의 다중 대기열 수락을 활성화('on') 또는 비활성화('off')합니다.
  이는 특히 외부 활동으로 인해 스레드가 고르지 않게 로드될 수 있는 환경(예: 하나의 
  스레드와 충돌하는 네트워크 인터럽트)에서 보다 원활한 트래픽 분배 및 확장성을 제공합니다.
  이 옵션은 기본적으로 활성화되어 있지만 문제 해결을 위해 또는 운영 체제가 이미 
  충분한 배포를 제공하고 연결 수명이 매우 짧은 것으로 추정되는 상황에서는 강제로 
  비활성화할 수 있습니다.
	
tune.lua.forced-yield <number>		
  This directive forces the Lua engine to execute a yield each <number> of
  instructions executed. This permits interrupting a long script and allows the
  HAProxy scheduler to process other tasks like accepting connections or
  forwarding traffic. The default value is 10000 instructions. If HAProxy often
  executes some Lua code but more responsiveness is required, this value can be
  lowered. If the Lua code is quite long and its result is absolutely required
  to process the data, the <number> can be increased.	

  이 지시어는 Lua 엔진이 실행된 명령의 각 <number>를 산출하도록 강제합니다.
  이를 통해 긴 스크립트를 중단하고 HAProxy 스케줄러가 연결 수락 또는 트래픽 전달과 같은 
  다른 작업을 처리할 수 있습니다.  기본값은 10000 명령어입니다.
  HAProxy가 일부 Lua 코드를 자주 실행하지만 더 많은 응답성이 필요한 경우 이 값을 낮출 
  수 있습니다.  Lua 코드가 상당히 길고 그 결과가 데이터 처리에 절대적으로 필요한 
  경우 <number>를 늘릴 수 있습니다.
	
tune.lua.maxmem		
  Sets the maximum amount of RAM in megabytes per process usable by Lua. By
  default it is zero which means unlimited. It is important to set a limit to
  ensure that a bug in a script will not result in the system running out of
  memory.	

  Lua에서 사용할 수 있는 프로세스당 최대 RAM 양(MB)을 설정합니다.
  기본적으로 0이며 무제한을 의미합니다.
  스크립트의 버그로 인해 시스템 메모리가 부족해지지 않도록 제한을 설정하는 
  것이 중요합니다.
	
tune.lua.session-timeout <timeout>		
  This is the execution timeout for the Lua sessions. This is useful for
  preventing infinite loops or spending too much time in Lua. This timeout
  counts only the pure Lua runtime. If the Lua does a sleep, the sleep is
  not taken in account. The default timeout is 4s.	

  Lua 세션의 실행 제한 시간입니다.
  이는 무한 루프를 방지하거나 Lua에서 너무 많은 시간을 보내는 데 유용합니다.
  이 제한 시간은 순수 Lua 런타임만 계산합니다. Lua가 절전 모드를 수행하는 경우 
  해당 절전 모드는 고려되지 않습니다.
  기본 제한 시간은 4초입니다.
	
tune.lua.task-timeout <timeout>		
  Purpose is the same as "tune.lua.session-timeout", but this timeout is
  dedicated to the tasks. By default, this timeout isn't set because a task may
  remain alive during of the lifetime of HAProxy. For example, a task used to
  check servers.	

  목적은 "tune.lua.session-timeout"과 동일하지만 이 타임아웃은 작업 전용입니다.
  기본적으로 이 시간 제한은 HAProxy 수명 동안 작업이 활성 상태로 유지될 수 있으므로 
  설정되지 않습니다.  예를 들어 서버를 확인하는 데 사용되는 작업입니다.
	
tune.lua.service-timeout <timeout>		
  This is the execution timeout for the Lua services. This is useful for
  preventing infinite loops or spending too much time in Lua. This timeout
  counts only the pure Lua runtime. If the Lua does a sleep, the sleep is
  not taken in account. The default timeout is 4s.	

  이것은 Lua 서비스의 실행 제한 시간입니다.
  이는 무한 루프를 방지하거나 Lua에서 너무 많은 시간을 보내는 데 유용합니다.
  이 제한 시간은 순수 Lua 런타임만 계산합니다.
  Lua가 절전 모드를 수행하는 경우 해당 절전 모드는 고려되지 않습니다. 
  기본 제한 시간은 4초입니다.
	
tune.maxaccept <number>		
  Sets the maximum number of consecutive connections a process may accept in a
  row before switching to other work. In single process mode, higher numbers
  used to give better performance at high connection rates, though this is not
  the case anymore with the multi-queue. This value applies individually to
  each listener, so that the number of processes a listener is bound to is
  taken into account. This value defaults to 4 which showed best results. If a
  significantly higher value was inherited from an ancient config, it might be
  worth removing it as it will both increase performance and lower response
  time. In multi-process mode, it is divided by twice the number of processes
  the listener is bound to. Setting this value to -1 completely disables the
  limitation. It should normally not be needed to tweak this value.	

  프로세스가 다른 작업으로 전환하기 전에 연속적으로 허용할 수 있는 최대 연속 
  연결 수를 설정합니다.  단일 프로세스 모드에서는 높은 연결 속도에서 더 나은 성능을 
  제공하기 위해 더 높은 숫자가 사용되지만 다중 대기열에서는 더 이상 그렇지 않습니다.
  이 값은 각 수신기에 개별적으로 적용되므로 수신기가 바인딩된 프로세스 수가 고려됩니다.
  이 값은 기본적으로 최상의 결과를 보인 4입니다.
  고대 구성에서 훨씬 더 높은 값이 상속된 경우 성능이 향상되고 응답 시간이 단축되므로 
  제거하는 것이 좋습니다.
  다중 프로세스 모드에서는 수신기가 바인딩된 프로세스 수의 두 배로 나뉩니다.
  이 값을 -1로 설정하면 제한이 완전히 비활성화됩니다.
  일반적으로 이 값을 조정할 필요가 없습니다.
	
tune.maxpollevents <number>		
  Sets the maximum amount of events that can be processed at once in a call to
  the polling system. The default value is adapted to the operating system. It
  has been noticed that reducing it below 200 tends to slightly decrease
  latency at the expense of network bandwidth, and increasing it above 200
  tends to trade latency for slightly increased bandwidth.	

  폴링 시스템에 대한 호출에서 한 번에 처리할 수 있는 최대 이벤트 수를 설정합니다.
  기본값은 운영 체제에 맞게 조정됩니다.
  200 미만으로 줄이면 네트워크 대역폭을 희생시키면서 대기 시간이 약간 감소하는 
  경향이 있고, 200 이상으로 늘리면 대역폭이 약간 증가하는 경향이 있습니다.
	
tune.maxrewrite <number>		
  Sets the reserved buffer space to this size in bytes. The reserved space is
  used for header rewriting or appending. The first reads on sockets will never
  fill more than bufsize-maxrewrite. Historically it has defaulted to half of
  bufsize, though that does not make much sense since there are rarely large
  numbers of headers to add. Setting it too high prevents processing of large
  requests or responses. Setting it too low prevents addition of new headers
  to already large requests or to POST requests. It is generally wise to set it
  to about 1024. It is automatically readjusted to half of bufsize if it is
  larger than that. This means you don't have to worry about it when changing
  bufsize.	

  예약된 버퍼 공간을 이 크기(바이트)로 설정합니다. 
  예약된 공간은 헤더 재작성 또는 추가에 사용됩니다.
  소켓의 첫 번째 읽기는 bufsize-maxrewrite 이상을 채우지 않습니다.
  역사적으로 기본적으로 bufsize의 절반으로 설정되어 있지만 추가할 헤더 수가 많지 
  않기 때문에 의미가 없습니다.
  너무 높게 설정하면 대규모 요청이나 응답을 처리할 수 없습니다.
  너무 낮게 설정하면 이미 큰 요청이나 POST 요청에 새 헤더를 추가할 수 없습니다.
  일반적으로 약 1024로 설정하는 것이 현명합니다.
  bufsize보다 크면 자동으로 bufsize의 절반으로 재조정됩니다.
  즉, bufsize를 변경할 때 걱정할 필요가 없습니다.
	
tune.pattern.cache-size <number>		
  Sets the size of the pattern lookup cache to <number> entries. This is an LRU
  cache which reminds previous lookups and their results. It is used by ACLs
  and maps on slow pattern lookups, namely the ones using the "sub", "reg",
  "dir", "dom", "end", "bin" match methods as well as the case-insensitive
  strings. It applies to pattern expressions which means that it will be able
  to memorize the result of a lookup among all the patterns specified on a
  configuration line (including all those loaded from files). It automatically
  invalidates entries which are updated using HTTP actions or on the CLI. The
  default cache size is set to 10000 entries, which limits its footprint to
  about 5 MB per process/thread on 32-bit systems and 8 MB per process/thread
  on 64-bit systems, as caches are thread/process local. There is a very low
  risk of collision in this cache, which is in the order of the size of the
  cache divided by 2^64. Typically, at 10000 requests per second with the
  default cache size of 10000 entries, there's 1% chance that a brute force
  attack could cause a single collision after 60 years, or 0.1% after 6 years.
  This is considered much lower than the risk of a memory corruption caused by
  aging components. If this is not acceptable, the cache can be disabled by
  setting this parameter to 0.	

  패턴 조회 캐시의 크기를 <number> 항목으로 설정합니다.
  이것은 이전 조회 및 그 결과를 상기시키는 LRU 캐시입니다.
  이것은 느린 패턴 조회, 즉 "sub", "reg", "dir", "dom", "end", "bin" 일치 방법 및 
  대소문자를 구분하지 않는 문자열을 사용하는 ACL 및 맵에서 사용됩니다. .
  이는 구성 라인에 지정된 모든 패턴(파일에서 로드된 모든 패턴 포함) 중에서 조회 결과를 
  기억할 수 있음을 의미하는 패턴 표현식에 적용됩니다.
  HTTP 작업을 사용하거나 CLI에서 업데이트된 항목을 자동으로 무효화합니다.
  기본 캐시 크기는 10000개 항목으로 설정되며 캐시가 스레드/프로세스 로컬이므로 
  32비트 시스템에서는 프로세스/스레드당 약 5MB, 
  64비트 시스템에서는 프로세스/스레드당 8MB로 공간을 제한합니다.
  이 캐시에는 충돌 위험이 매우 낮으며 캐시 크기를 2^64로 나눈 정도입니다.
  일반적으로 기본 캐시 크기가 10000개 항목인 초당 10000개의 요청에서 무차별 
  암호 대입 공격이 60년 후에 단일 충돌을 일으킬 가능성은 1%, 6년 후에는 0.1%입니다.
  이는 구성 요소 노후화로 인한 메모리 손상 위험보다 훨씬 낮은 것으로 간주됩니다.
  이것이 허용되지 않는 경우 이 매개변수를 0으로 설정하여 캐시를 비활성화할 수 있습니다.
	
tune.peers.max-updates-at-once <number>		
  Sets the maximum number of stick-table updates that haproxy will try to
  process at once when sending messages. Retrieving the data for these updates
  requires some locking operations which can be CPU intensive on highly
  threaded machines if unbound, and may also increase the traffic latency
  during the initial batched transfer between an older and a newer process.
  Conversely low values may also incur higher CPU overhead, and take longer
  to complete. The default value is 200 and it is suggested not to change it.	

  haproxy가 메시지를 보낼 때 한 번에 처리하려고 시도하는 최대 스틱 테이블 업데이트 
  수를 설정합니다.  이러한 업데이트에 대한 데이터를 검색하려면 일부 잠금 작업이 
  필요하며 바인딩되지 않은 경우 스레드가 많은 컴퓨터에서 CPU를 많이 사용할 수 있으며 
  이전 프로세스와 새 프로세스 간의 초기 일괄 전송 중에 트래픽 대기 시간이 증가할 수도 있습니다.
  반대로 값이 낮으면 CPU 오버헤드가 높아져 완료하는 데 시간이 더 오래 걸릴 수 있습니다.
  기본값은 200이며 변경하지 않는 것이 좋습니다.
	
tune.pipesize <number>		
  Sets the kernel pipe buffer size to this size (in bytes). By default, pipes
  are the default size for the system. But sometimes when using TCP splicing,
  it can improve performance to increase pipe sizes, especially if it is
  suspected that pipes are not filled and that many calls to splice() are
  performed. This has an impact on the kernel's memory footprint, so this must
  not be changed if impacts are not understood.	

  커널 파이프 버퍼 크기를 이 크기(바이트 단위)로 설정합니다.
  기본적으로 파이프는 시스템의 기본 크기입니다.
  그러나 때때로 TCP 스플라이싱을 사용할 때 특히 파이프가 채워지지 않고 
  splice()에 대한 많은 호출이 수행되는 것으로 의심되는 경우 파이프 크기를 늘리기 
  위해 성능을 향상시킬 수 있습니다.
  이는 커널의 메모리 공간에 영향을 미치므로 영향을 이해하지 못하는 경우 
  변경해서는 안 됩니다.
	
tune.pool-high-fd-ratio <number>		
  This setting sets the max number of file descriptors (in percentage) used by
  HAProxy globally against the maximum number of file descriptors HAProxy can
  use before we start killing idle connections when we can't reuse a connection
  and we have to create a new one. The default is 25 (one quarter of the file
  descriptor will mean that roughly half of the maximum front connections can
  keep an idle connection behind, anything beyond this probably doesn't make
  much sense in the general case when targeting connection reuse).	

  이 설정은 연결을 재사용할 수 없고 새 연결을 만들어야 할 때 유휴 연결을 종료하기 전에 
  HAProxy가 사용할 수 있는 최대 파일 설명자 수에 대해 HAProxy가 전역적으로 사용하는 
  최대 파일 설명자 수(백분율)를 설정합니다.
  기본값은 25입니다(파일 디스크립터의 1/4은 최대 전면 연결의 약 절반이 유휴 연결을 
  뒤에 유지할 수 있음을 의미하며, 이 이상은 연결 재사용을 목표로 하는 일반적인 
  경우에 별 의미가 없습니다).
  	
tune.pool-low-fd-ratio <number>		
  This setting sets the max number of file descriptors (in percentage) used by
  HAProxy globally against the maximum number of file descriptors HAProxy can
  use before we stop putting connection into the idle pool for reuse. The
  default is 20.	

  이 설정은 재사용을 위해 유휴 풀에 연결을 중지하기 전에 HAProxy가 사용할 수 
  있는 최대 파일 설명자 수에 대해 HAProxy가 전역적으로 사용하는 
  최대 파일 설명자 수(백분율)를 설정합니다. 기본값은 20입니다.
	
tune.quic.frontend.conn-tx-buffers.limit <number>		
  Warning: QUIC support in HAProxy is currently experimental. Configuration may
  change without deprecation in the future.	
  경고: HAProxy의 QUIC 지원은 현재 실험적입니다. 
  향후 예고없이 변경될 수 있습니다.  
	
  This settings defines the maximum number of buffers allocated for a QUIC
  connection on data emission. By default, it is set to 30. QUIC buffers are
  drained on ACK reception. This setting has a direct impact on the throughput
  and memory consumption and can be adjusted according to an estimated round
  time-trip. Each buffer is tune.bufsize.	

  이 설정은 데이터 방출 시 QUIC 연결에 할당되는 최대 버퍼 수를 정의합니다. 
  기본적으로 30으로 설정되어 있습니다.
  QUIC 버퍼는 ACK 수신 시 소모됩니다.
  이 설정은 처리량 및 메모리 소비에 직접적인 영향을 미치며 예상 왕복 시간에 
  따라 조정할 수 있습니다. 각 버퍼는 tune.bufsize입니다.
	
tune.quic.frontend.max-idle-timeout <timeout>		
  Warning: QUIC support in HAProxy is currently experimental. Configuration may
  change without deprecation in the future.	
  경고: HAProxy의 QUIC 지원은 현재 실험적입니다.
  향후 예고없이 변경될 수 있습니다.  
	
  Sets the QUIC max_idle_timeout transport parameters in milliseconds for
  frontends which determines the period of time after which a connection silently
  closes if it has remained inactive during an effective period of time deduced
  from the two max_idle_timeout values announced by the two endpoints:	
    - the minimum of the two values if both are not null,
    - the maximum if only one of them is not null,
    - if both values are null, this feature is disabled.
	
  The default value is 30000.	

  프런트엔드에 대한 QUIC max_idle_timeout 전송 매개변수를 밀리초 단위로 설정합니다. 
  이 매개변수는 두 엔드포인트에서 발표한 두 개의 max_idle_timeout 값에서 추론된 
  유효 기간 동안 비활성 상태로 유지된 경우 연결이 자동으로 종료되는 시간을 결정합니다.
     - 둘 다 null이 아닌 경우 두 값 중 최소값,
     - 그 중 하나만 null이 아닌 경우 최대값,
     - 두 값이 모두 null이면 이 기능이 비활성화됩니다.

  기본값은 30000 입니다.
  
tune.quic.frontend.max-streams-bidi <number>		
  Warning: QUIC support in HAProxy is currently experimental. Configuration may
  change without deprecation in the future.	
  경고: HAProxy의 QUIC 지원은 현재 실험적입니다.
  향후 예고없이 변경될 수 있습니다.  
  
  Sets the QUIC initial_max_streams_bidi transport parameter for frontends.
  This is the initial maximum number of bidirectional streams the remote peer
  will be authorized to open. This determines the number of concurrent client
  requests.	
  
  프런트엔드에 대한 QUIC initial_max_streams_bidi 전송 매개변수를 설정합니다.
  이는 원격 피어가 열 수 있는 초기 최대 양방향 스트림 수입니다.
  이는 동시 클라이언트 요청 수를 결정합니다.  
	
  The default value is 100.	
  기본값은 100 입니다.
	
tune.quic.retry-threshold <number>		
  Warning: QUIC support in HAProxy is currently experimental. Configuration may
  change without deprecation in the future.	
  경고: HAProxy의 QUIC 지원은 현재 실험적입니다.
  향후 예고없이 변경될 수 있습니다.  
	
  Dynamically enables the Retry feature for all the configured QUIC listeners
  as soon as this number of half open connections is reached. A half open
  connection is a connection whose handshake has not already successfully
  completed or failed. To be functional this setting needs a cluster secret to
  be set, if not it will be silently ignored (see "cluster-secret" setting).
  This setting will be also silently ignored if the use of QUIC Retry was
  forced (see "quic-force-retry").	

  이 절반 열린 연결 수에 도달하는 즉시 구성된 모든 QUIC 리스너에 대해 재시도 기능을 
  동적으로 활성화합니다.
  반개방 연결은 핸드셰이크가 아직 성공적으로 완료되지 않았거나 실패한 연결입니다.
  이 설정이 작동하려면 클러스터 암호를 설정해야 합니다. 그렇지 않으면 자동으로 무시됩니다
  ("cluster-secret" 설정 참조).
  QUIC Retry 사용이 강제된 경우 이 설정도 자동으로 무시됩니다("quic-force-retry" 참조).
	
  The default value is 100.	
  기본값은 100 입니다.
	
  See https://www.rfc-editor.org/rfc/rfc9000.html#section-8.1.2 for more
  information about QUIC retry.	
  QUIC 재시도에 대한 자세한 내용은 https://www.rfc-editor.org/rfc/rfc9000.html#section-8.1.2를 참조하세요.
	
tune.rcvbuf.client <number>	
tune.rcvbuf.server <number>		
  Forces the kernel socket receive buffer size on the client or the server side
  to the specified value in bytes. This value applies to all TCP/HTTP frontends
  and backends. It should normally never be set, and the default size (0) lets
  the kernel auto-tune this value depending on the amount of available memory.
  However it can sometimes help to set it to very low values (e.g. 4096) in
  order to save kernel memory by preventing it from buffering too large amounts
  of received data. Lower values will significantly increase CPU usage though.	

  클라이언트 또는 서버 측의 커널 소켓 수신 버퍼 크기를 지정된 값(바이트)으로 설정합니다.
  이 값은 모든 TCP/HTTP 프런트엔드 및 백엔드에 적용됩니다.
  일반적으로 설정해서는 안 되며 기본 크기(0)를 사용하면 커널이 사용 가능한 메모리 양에 
  따라 이 값을 자동 조정할 수 있습니다.
  그러나 너무 많은 양의 수신 데이터를 버퍼링하는 것을 방지하여 커널 메모리를 절약하기 
  위해 매우 낮은 값(예: 4096)으로 설정하는 것이 때때로 도움이 될 수 있습니다.
  값이 낮을수록 CPU 사용량이 크게 증가합니다.
	
tune.recv_enough <number>		
  HAProxy uses some hints to detect that a short read indicates the end of the
  socket buffers. One of them is that a read returns more than <recv_enough>
  bytes, which defaults to 10136 (7 segments of 1448 each). This default value
  may be changed by this setting to better deal with workloads involving lots
  of short messages such as telnet or SSH sessions.	

  HAProxy는 몇 가지 힌트를 사용하여 짧은 읽기가 소켓 버퍼의 끝을 나타내는지 감지합니다.
  그 중 하나는 읽기가 <recv_enough> 바이트 이상을 반환하며 기본값은 10136
  (각각 1448의 7개 세그먼트)입니다.
  이 기본값은 텔넷 또는 SSH 세션과 같은 짧은 메시지가 많이 포함된 워크로드를 더 잘 
  처리하기 위해 이 설정에 의해 변경될 수 있습니다.
	
tune.runqueue-depth <number>		
  Sets the maximum amount of task that can be processed at once when running
  tasks. The default value depends on the number of threads but sits between 35
  and 280, which tend to show the highest request rates and lowest latencies.
  Increasing it may incur latency when dealing with I/Os, making it too small
  can incur extra overhead. Higher thread counts benefit from lower values.
  When experimenting with much larger values, it may be useful to also enable
  tune.sched.low-latency and possibly tune.fd.edge-triggered to limit the
  maximum latency to the lowest possible.	
	
  태스크 실행 시 한 번에 처리할 수 있는 최대 태스크 양을 설정합니다.
  기본값은 스레드 수에 따라 다르지만 35~280 사이에 있으며 가장 높은 요청률과 
  가장 낮은 대기 시간을 나타내는 경향이 있습니다.
  이 값을 늘리면 I/O를 처리할 때 대기 시간이 발생할 수 있으므로 너무 작게 만들면 
  추가 오버헤드가 발생할 수 있습니다.
  스레드 수가 높을수록 값이 낮을수록 좋습니다.
  훨씬 더 큰 값으로 실험할 때 tune.sched.low-latency 및 가능한 경우 
  tune.fd.edge-triggered를 활성화하여 최대 지연 시간을 가능한 가장 낮은 값으로 
  제한하는 것이 유용할 수 있습니다.
	
tune.sched.low-latency { on | off }		
  Enables ('on') or disables ('off') the low-latency task scheduler. By default
  HAProxy processes tasks from several classes one class at a time as this is
  the most efficient. But when running with large values of tune.runqueue-depth
  this can have a measurable effect on request or connection latency. When this
  low-latency setting is enabled, tasks of lower priority classes will always
  be executed before other ones if they exist. This will permit to lower the
  maximum latency experienced by new requests or connections in the middle of
  massive traffic, at the expense of a higher impact on this large traffic.
  For regular usage it is better to leave this off. The default value is off.	

  대기 시간이 짧은 작업 스케줄러를 활성화('on') 또는 비활성화('off')합니다.
  기본적으로 HAProxy는 여러 클래스의 작업을 한 번에 한 클래스씩 처리하므로 
  이것이 가장 효율적입니다.
  그러나 큰 값의 tune.runqueue-depth로 실행하면 요청 또는 연결 대기 시간에 
  상당한 영향을 미칠 수 있습니다.
  이 짧은 대기 시간 설정이 활성화되면 우선 순위가 낮은 클래스의 작업이 항상 다른 
  작업보다 먼저 실행됩니다(존재하는 경우).
  이렇게 하면 이 대규모 트래픽에 더 큰 영향을 미치는 대신 대규모 트래픽 중간에 
  새로운 요청 또는 연결이 경험하는 최대 대기 시간을 줄일 수 있습니다.
  일반적인 사용을 위해서는 이 기능을 끄는 것이 좋습니다.
  기본값은 꺼져 있습니다.
	
tune.sndbuf.client <number>	
tune.sndbuf.server <number>		
  Forces the kernel socket send buffer size on the client or the server side to
  the specified value in bytes. This value applies to all TCP/HTTP frontends
  and backends. It should normally never be set, and the default size (0) lets
  the kernel auto-tune this value depending on the amount of available memory.
  However it can sometimes help to set it to very low values (e.g. 4096) in
  order to save kernel memory by preventing it from buffering too large amounts
  of received data. Lower values will significantly increase CPU usage though.
  Another use case is to prevent write timeouts with extremely slow clients due
  to the kernel waiting for a large part of the buffer to be read before
  notifying HAProxy again.	

  클라이언트 또는 서버 측의 커널 소켓 전송 버퍼 크기를 바이트 단위로 지정된 값으로 
  강제합니다.  이 값은 모든 TCP/HTTP 프런트엔드 및 백엔드에 적용됩니다.
  일반적으로 설정해서는 안 되며 기본 크기(0)를 사용하면 커널이 사용 가능한 메모리 양에 
  따라 이 값을 자동 조정할 수 있습니다.
  그러나 너무 많은 양의 수신 데이터를 버퍼링하는 것을 방지하여 커널 메모리를 절약하기 위해 
  매우 낮은 값(예: 4096)으로 설정하는 것이 때때로 도움이 될 수 있습니다.
  값이 낮을수록 CPU 사용량이 크게 증가합니다.
  또 다른 사용 사례는 커널이 HAProxy에 다시 알리기 전에 읽을 버퍼의 상당 부분을 기다리기 
  때문에 매우 느린 클라이언트에서 쓰기 시간 초과를 방지하는 것입니다.
	
tune.ssl.cachesize <number>		
  Sets the size of the global SSL session cache, in a number of blocks. A block
  is large enough to contain an encoded session without peer certificate.  An
  encoded session with peer certificate is stored in multiple blocks depending
  on the size of the peer certificate. A block uses approximately 200 bytes of
  memory (based on `sizeof(struct sh_ssl_sess_hdr) + SHSESS_BLOCK_MIN_SIZE`
  calculation used for `shctx_init` function). The default value may be forced
  at build time, otherwise defaults to 20000. When the cache is full, the most
  idle entries are purged and reassigned. Higher values reduce the occurrence
  of such a purge, hence the number of CPU-intensive SSL handshakes by ensuring
  that all users keep their session as long as possible. All entries are
  pre-allocated upon startup. Setting this value to 0 disables the SSL session
  cache.	
	
tune.ssl.force-private-cache		
  This option disables SSL session cache sharing between all processes. It
  should normally not be used since it will force many renegotiations due to
  clients hitting a random process. But it may be required on some operating
  systems where none of the SSL cache synchronization method may be used. In
  this case, adding a first layer of hash-based load balancing before the SSL
  layer might limit the impact of the lack of session sharing.	
	
tune.ssl.hard-maxrecord <number>		
  Sets the maximum amount of bytes passed to SSL_write() at any time. Default
  value 0 means there is no limit. In contrast to tune.ssl.maxrecord this
  settings will not be adjusted dynamically. Smaller records may decrease
  throughput, but may be required when dealing with low-footprint clients.	
	
tune.ssl.keylog { on | off }		
  This option activates the logging of the TLS keys. It should be used with
  care as it will consume more memory per SSL session and could decrease
  performances. This is disabled by default.	
	
  These sample fetches should be used to generate the SSLKEYLOGFILE that is
  required to decipher traffic with wireshark.	
	
  https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Key_Log_Format	
	
  The SSLKEYLOG is a series of lines which are formatted this way:	
	
    <Label> <space> <ClientRandom> <space> <Secret>	
	
  The ClientRandom is provided by the %[ssl_fc_client_random,hex] sample
  fetch, the secret and the Label could be find in the array below. You need
  to generate a SSLKEYLOGFILE with all the labels in this array.	
	
  The following sample fetches are hexadecimal strings and does not need to be
  converted.	
  SSLKEYLOGFILE Label             |  Sample fetches for the Secrets
  --------------------------------|-----------------------------------------
  CLIENT_EARLY_TRAFFIC_SECRET     |  %[ssl_fc_client_early_traffic_secret]
  CLIENT_HANDSHAKE_TRAFFIC_SECRET |  %[ssl_fc_client_handshake_traffic_secret]
  SERVER_HANDSHAKE_TRAFFIC_SECRET |  %[ssl_fc_server_handshake_traffic_secret]
  CLIENT_TRAFFIC_SECRET_0         |  %[ssl_fc_client_traffic_secret_0]
  SERVER_TRAFFIC_SECRET_0         |  %[ssl_fc_server_traffic_secret_0]
  EXPORTER_SECRET                 |  %[ssl_fc_exporter_secret]
  EARLY_EXPORTER_SECRET           |  %[ssl_fc_early_exporter_secret]
  This is only available with OpenSSL 1.1.1, and useful with TLS1.3 session.	
	
  If you want to generate the content of a SSLKEYLOGFILE with TLS < 1.3, you
  only need this line:	
	
  "CLIENT_RANDOM %[ssl_fc_client_random,hex] %[ssl_fc_session_key,hex]"	
	
tune.ssl.lifetime <timeout>		
  Sets how long a cached SSL session may remain valid. This time is expressed
  in seconds and defaults to 300 (5 min). It is important to understand that it
  does not guarantee that sessions will last that long, because if the cache is
  full, the longest idle sessions will be purged despite their configured
  lifetime. The real usefulness of this setting is to prevent sessions from
  being used for too long.	
	
tune.ssl.maxrecord <number>		
  Sets the maximum amount of bytes passed to SSL_write() at the beginning of
  the data transfer. Default value 0 means there is no limit. Over SSL/TLS,
  the client can decipher the data only once it has received a full record.
  With large records, it means that clients might have to download up to 16kB
  of data before starting to process them. Limiting the value can improve page
  load times on browsers located over high latency or low bandwidth networks.
  It is suggested to find optimal values which fit into 1 or 2 TCP segments
  (generally 1448 bytes over Ethernet with TCP timestamps enabled, or 1460 when
  timestamps are disabled), keeping in mind that SSL/TLS add some overhead.
  Typical values of 1419 and 2859 gave good results during tests. Use
  "strace -e trace=write" to find the best value. HAProxy will automatically
  switch to this setting after an idle stream has been detected (see
  tune.idletimer above). See also tune.ssl.hard-maxrecord.	
	
tune.ssl.default-dh-param <number>		
  Sets the maximum size of the Diffie-Hellman parameters used for generating
  the ephemeral/temporary Diffie-Hellman key in case of DHE key exchange. The
  final size will try to match the size of the server's RSA (or DSA) key (e.g,
  a 2048 bits temporary DH key for a 2048 bits RSA key), but will not exceed
  this maximum value. Only 1024 or higher values are allowed. Higher values
  will increase the CPU load, and values greater than 1024 bits are not
  supported by Java 7 and earlier clients. This value is not used if static
  Diffie-Hellman parameters are supplied either directly in the certificate
  file or by using the ssl-dh-param-file parameter.
  If there is neither a default-dh-param nor a ssl-dh-param-file defined, and
  if the server's PEM file of a given frontend does not specify its own DH
  parameters, then DHE ciphers will be unavailable for this frontend.	
	
tune.ssl.ssl-ctx-cache-size <number>		
  Sets the size of the cache used to store generated certificates to <number>
  entries. This is a LRU cache. Because generating a SSL certificate
  dynamically is expensive, they are cached. The default cache size is set to
  1000 entries.	
	
tune.ssl.capture-buffer-size <number>		
tune.ssl.capture-cipherlist-size <number> (deprecated)	
  Sets the maximum size of the buffer used for capturing client hello cipher
  list, extensions list, elliptic curves list and elliptic curve point
  formats. If the value is 0 (default value) the capture is disabled,
  otherwise a buffer is allocated for each SSL/TLS connection.	
	
tune.vars.global-max-size <size>	
tune.vars.proc-max-size <size>	
tune.vars.reqres-max-size <size>	
tune.vars.sess-max-size <size>	
tune.vars.txn-max-size <size>		
  These five tunes help to manage the maximum amount of memory used by the
  variables system. "global" limits the overall amount of memory available for
  all scopes. "proc" limits the memory for the process scope, "sess" limits the
  memory for the session scope, "txn" for the transaction scope, and "reqres"
  limits the memory for each request or response processing.
  Memory accounting is hierarchical, meaning more coarse grained limits include
  the finer grained ones: "proc" includes "sess", "sess" includes "txn", and
  "txn" includes "reqres".	
	
  For example, when "tune.vars.sess-max-size" is limited to 100,
  "tune.vars.txn-max-size" and "tune.vars.reqres-max-size" cannot exceed
  100 either. If we create a variable "txn.var" that contains 100 bytes,
  all available space is consumed.
  Notice that exceeding the limits at runtime will not result in an error
  message, but values might be cut off or corrupted. So make sure to accurately
  plan for the amount of space needed to store all your variables.	
	
tune.zlib.memlevel <number>		
  Sets the memLevel parameter in zlib initialization for each session. It
  defines how much memory should be allocated for the internal compression
  state. A value of 1 uses minimum memory but is slow and reduces compression
  ratio, a value of 9 uses maximum memory for optimal speed. Can be a value
  between 1 and 9. The default value is 8.	
	
tune.zlib.windowsize <number>		
  Sets the window size (the size of the history buffer) as a parameter of the
  zlib initialization for each session. Larger values of this parameter result
  in better compression at the expense of memory usage. Can be a value between
  8 and 15. The default value is 15.	

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" 전역 구성 설정에만 의존하여 로컬 피어 이름을 변경하는 것이 좋습니다.
  이렇게 하면 모든 피어에서 일관된 구성 파일을 보다 쉽게 유지할 수 있습니다.
	
  You may want to reference some environment variables in the address
  parameter, see section 2.3 about environment variables.	
  주소 매개변수에서 일부 환경 변수를 참조할 수 있습니다. 
  환경 변수에 대한 섹션 2.3을 참조하십시오.
	
  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.	
	
      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). This
              is the default.	
	
      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
	
      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.	
	
     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.	
	
      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.	
	
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' 규칙을 사용해야 합니다.                  
                  
                  이 알고리즘은 기본적으로 정적이며 즉석에서 서버의 가중치를 변경해도 
                  아무런 효과가 없지만 "hash-type"을 사용하여 변경할 수 있습니다. 
                  위의 "hash" 옵션도 참조하십시오.

    <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 :	
	
    h2   : mode=HTTP  side=FE|BE  mux=H2    flags=HTX|HOL_RISK|NO_UPG
    h1   : mode=HTTP  side=FE|BE  mux=H1    flags=HTX|NO_UPG
    none : mode=TCP   side=FE|BE  mux=PASS  flags=NO_UPG
	
  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]]	
	
  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.	
	
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: h2 : mode=HTTP side=FE|BE mux=H2 flags=HTX|HOL_RISK|NO_UPG fcgi : mode=HTTP side=BE mux=FCGI flags=HTX|HOL_RISK|NO_UPG h1 : mode=HTTP side=FE|BE mux=H1 flags=HTX|NO_UPG none : mode=TCP side=FE|BE mux=PASS flags=NO_UPG 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. Supported in default-server: No 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 for servers. This option is also available on global statement "ssl-default-server-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"). See also "tls-tickets". no-tlsv10 This option disables support for TLSv1.0 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. TLSv1 is more expensive than SSLv3 so it often makes sense to disable it when communicating with local servers. This option is also available on global statement "ssl-default-server-options". Use "ssl-min-ver" and "ssl-max-ver" instead. Supported in default-server: No no-tlsv11 This option disables support for TLSv1.1 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. TLSv1 is more expensive than SSLv3 so it often makes sense to disable it when communicating with local servers. This option is also available on global statement "ssl-default-server-options". Use "ssl-min-ver" and "ssl-max-ver" instead. Supported in default-server: No no-tlsv12 This option disables support for TLSv1.2 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. TLSv1 is more expensive than SSLv3 so it often makes sense to disable it when communicating with local servers. This option is also available on global statement "ssl-default-server-options". Use "ssl-min-ver" and "ssl-max-ver" instead. Supported in default-server: No no-tlsv13 This option disables support for TLSv1.3 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. TLSv1 is more expensive than SSLv3 so it often makes sense to disable it when communicating with local servers. This option is also available on global statement "ssl-default-server-options". Use "ssl-min-ver" and "ssl-max-ver" instead. Supported in default-server: No no-verifyhost This option may be used as "server" setting to reset any "verifyhost" 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" "verifyhost" setting. no-tfo This option may be used as "server" setting to reset any "tfo" 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" "tfo" setting. non-stick Never add connections allocated to this sever to a stick-table. This may be used in conjunction with backup to ensure that stick-table persistence is disabled for backup servers. 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. observe This option enables health adjusting based on observing communication with the server. By default this functionality is disabled and enabling it also requires to enable health checks. There are two supported modes: "layer4" and "layer7". In layer4 mode, only successful/unsuccessful tcp connections are significant. In layer7, which is only allowed for http proxies, responses received from server are verified, like valid/wrong http code, unparsable headers, a timeout, etc. Valid status codes include 100 to 499, 501 and 505. See also the "check", "on-error" and "error-limit". on-error Select what should happen when enough consecutive errors are detected. Currently, four modes are available: - fastinter: force fastinter - fail-check: simulate a failed check, also forces fastinter (default) - sudden-death: simulate a pre-fatal failed health check, one more failed check will mark a server down, forces fastinter - mark-down: mark the server immediately down and force fastinter See also the "check", "observe" and "error-limit". on-marked-down <action> Modify what occurs when a server is marked down. Currently one action is available: - shutdown-sessions: Shutdown peer sessions. When this setting is enabled, all connections to the server are immediately terminated when the server goes down. It might be used if the health check detects more complex cases than a simple connection status, and long timeouts would cause the service to remain unresponsive for too long a time. For instance, a health check might detect that a database is stuck and that there's no chance to reuse existing connections anymore. Connections killed this way are logged with a 'D' termination code (for "Down"). Actions are disabled by default on-marked-up <action> Modify what occurs when a server is marked up. Currently one action is available: - shutdown-backup-sessions: Shutdown sessions on all backup servers. This is done only if the server is not in backup state and if it is not disabled (it must have an effective weight > 0). This can be used sometimes to force an active server to take all the traffic back after recovery when dealing with long sessions (e.g. LDAP, SQL, ...). Doing this can cause more trouble than it tries to solve (e.g. incomplete transactions), so use this feature with extreme care. Sessions killed because a server comes up are logged with an 'U' termination code (for "Up"). Actions are disabled by default pool-low-conn Set a low threshold on the number of idling connections for a server, below which a thread will not try to steal a connection from another thread. This can be useful to improve CPU usage patterns in scenarios involving many very fast servers, in order to ensure all threads will keep a few idle connections all the time instead of letting them accumulate over one thread and migrating them from thread to thread. Typical values of twice the number of threads seem to show very good performance already with sub-millisecond response times. The default is zero, indicating that any idle connection can be used at any time. It is the recommended setting for normal use. This only applies to connections that can be shared according to the same principles as those applying to "http-reuse". In case connection sharing between threads would be disabled via "tune.idle-pool.shared", it can become very important to use this setting to make sure each thread always has a few connections, or the connection reuse rate will decrease as thread count increases. pool-max-conn Set the maximum number of idling connections for a server. -1 means unlimited connections, 0 means no idle connections. The default is -1. When idle connections are enabled, orphaned idle connections which do not belong to any client session anymore are moved to a dedicated pool so that they remain usable by future clients. This only applies to connections that can be shared according to the same principles as those applying to "http-reuse". pool-purge-delay <delay> Sets the delay to start purging idle connections. Each <delay> interval, half of the idle connections are closed. 0 means we don't keep any idle connection. The default is 5s. port <port> Using the "port" parameter, it becomes possible to use a different port to send health-checks or to probe the agent-check. On some servers, it may be desirable to dedicate a port to a specific component able to perform complex tests which are more suitable to health-checks than the application. It is common to run a simple script in inetd for instance. This parameter is ignored if the "check" parameter is not set. See also the "addr" parameter. proto <name> Forces the multiplexer's protocol to use for the outgoing connections to this server. It must be compatible with the mode of the backend (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 "proto" directive on a server line : h2 : mode=HTTP side=FE|BE mux=H2 flags=HTX|HOL_RISK|NO_UPG fcgi : mode=HTTP side=BE mux=FCGI flags=HTX|HOL_RISK|NO_UPG h1 : mode=HTTP side=FE|BE mux=H1 flags=HTX|NO_UPG none : mode=TCP side=FE|BE mux=PASS flags=NO_UPG Idea behind this option is to bypass the selection of the best multiplexer's protocol for all connections established to this server. See also "ws" to use an alternative protocol for websocket streams. redir The "redir" parameter enables the redirection mode for all GET and HEAD requests addressing this server. This means that instead of having HAProxy forward the request to the server, it will send an "HTTP 302" response with the "Location" header composed of this prefix immediately followed by the requested URI beginning at the leading '/' of the path component. That means that no trailing slash should be used after . All invalid requests will be rejected, and all non-GET or HEAD requests will be normally served by the server. Note that since the response is completely forged, no header mangling nor cookie insertion is possible in the response. However, cookies in requests are still analyzed, making this solution completely usable to direct users to a remote location in case of local disaster. Main use consists in increasing bandwidth for static servers by having the clients directly connect to them. Note: never use a relative location here, it would cause a loop between the client and HAProxy! Example : server srv1 192.168.1.1:80 redir http://image1.mydomain.com check rise <count> The "rise" parameter states that a server will be considered as operational after <count> consecutive successful health checks. This value defaults to 2 if unspecified. See also the "check", "inter" and "fall" parameters. resolve-opts <option>,<option>,... Comma separated list of options to apply to DNS resolution linked to this server. Available options: * allow-dup-ip By default, HAProxy prevents IP address duplication in a backend when DNS resolution at runtime is in operation. That said, for some cases, it makes sense that two servers (in the same backend, being resolved by the same FQDN) have the same IP address. For such case, simply enable this option. This is the opposite of prevent-dup-ip. * ignore-weight Ignore any weight that is set within an SRV record. This is useful when you would like to control the weights using an alternate method, such as using an "agent-check" or through the runtime api. * prevent-dup-ip Ensure HAProxy's default behavior is enforced on a server: prevent re-using an IP address already set to a server in the same backend and sharing the same fqdn. This is the opposite of allow-dup-ip. Example: backend b_myapp default-server init-addr none resolvers dns server s1 myapp.example.com:80 check resolve-opts allow-dup-ip server s2 myapp.example.com:81 check resolve-opts allow-dup-ip With the option allow-dup-ip set: * if the nameserver returns a single IP address, then both servers will use it * If the nameserver returns 2 IP addresses, then each server will pick up a different address Default value: not set resolve-prefer <family> When DNS resolution is enabled for a server and multiple IP addresses from different families are returned, HAProxy will prefer using an IP address from the family mentioned in the "resolve-prefer" parameter. Available families: "ipv4" and "ipv6" Default value: ipv6 Example: server s1 app1.domain.com:80 resolvers mydns resolve-prefer ipv6 resolve-net [, Points to an existing "resolvers" section to resolve current server's hostname. Example: server s1 app1.domain.com:80 check resolvers mydns See also section 5.3 send-proxy The "send-proxy" parameter enforces use of the PROXY protocol over any connection established to this server. The PROXY protocol informs the other end about the layer 3/4 addresses of the incoming connection, so that it can know the client's address or the public address it accessed to, whatever the upper layer protocol. For connections accepted by an "accept-proxy" or "accept-netscaler-cip" listener, the advertised address will be used. Only TCPv4 and TCPv6 address families are supported. Other families such as Unix sockets, will report an UNKNOWN family. Servers using this option can fully be chained to another instance of HAProxy listening with an "accept-proxy" setting. This setting must not be used if the server isn't aware of the protocol. When health checks are sent to the server, the PROXY protocol is automatically used when this option is set, unless there is an explicit "port" or "addr" directive, in which case an explicit "check-send-proxy" directive would also be needed to use the PROXY protocol. See also the "no-send-proxy" option of this section and "accept-proxy" and "accept-netscaler-cip" option of the "bind" keyword. send-proxy-v2 The "send-proxy-v2" parameter enforces use of the PROXY protocol version 2 over any connection established to this server. The PROXY protocol informs the other end about the layer 3/4 addresses of the incoming connection, so that it can know the client's address or the public address it accessed to, whatever the upper layer protocol. It also send ALPN information if an alpn have been negotiated. This setting must not be used if the server isn't aware of this version of the protocol. See also the "no-send-proxy-v2" option of this section and send-proxy" option of the "bind" keyword. proxy-v2-options <option>[,<option>]* The "proxy-v2-options" parameter add options to send in PROXY protocol version 2 when "send-proxy-v2" is used. Options available are: - ssl : See also "send-proxy-v2-ssl". - cert-cn : See also "send-proxy-v2-ssl-cn". - ssl-cipher: Name of the used cipher. - cert-sig : Signature algorithm of the used certificate. - cert-key : Key algorithm of the used certificate - authority : Host name value passed by the client (only SNI from a TLS connection is supported). - crc32c : Checksum of the PROXYv2 header. - unique-id : Send a unique ID generated using the frontend's "unique-id-format" within the PROXYv2 header. This unique-id is primarily meant for "mode tcp". It can lead to unexpected results in "mode http", because the generated unique ID is also used for the first HTTP request within a Keep-Alive connection. send-proxy-v2-ssl The "send-proxy-v2-ssl" parameter enforces use of the PROXY protocol version 2 over any connection established to this server. The PROXY protocol informs the other end about the layer 3/4 addresses of the incoming connection, so that it can know the client's address or the public address it accessed to, whatever the upper layer protocol. In addition, the SSL information extension of the PROXY protocol is added to the PROXY protocol header. This setting must not be used if the server isn't aware of this version of the protocol. See also the "no-send-proxy-v2-ssl" option of this section and the "send-proxy-v2" option of the "bind" keyword. send-proxy-v2-ssl-cn The "send-proxy-v2-ssl" parameter enforces use of the PROXY protocol version 2 over any connection established to this server. The PROXY protocol informs the other end about the layer 3/4 addresses of the incoming connection, so that it can know the client's address or the public address it accessed to, whatever the upper layer protocol. In addition, the SSL information extension of the PROXY protocol, along along with the Common Name from the subject of the client certificate (if any), is added to the PROXY protocol header. This setting must not be used if the server isn't aware of this version of the protocol. See also the "no-send-proxy-v2-ssl-cn" option of this section and the "send-proxy-v2" option of the "bind" keyword. slowstart <start_time_in_ms> The "slowstart" parameter for a server accepts a value in milliseconds which indicates after how long a server which has just come back up will run at full speed. Just as with every other time-based parameter, it can be entered in any other explicit unit among { us, ms, s, m, h, d }. The speed grows linearly from 0 to 100% during this time. The limitation applies to two parameters : - maxconn: the number of connections accepted by the server will grow from 1 to 100% of the usual dynamic limit defined by (minconn,maxconn,fullconn). - weight: when the backend uses a dynamic weighted algorithm, the weight grows linearly from 1 to 100%. In this case, the weight is updated at every health-check. For this reason, it is important that the "inter" parameter is smaller than the "slowstart", in order to maximize the number of steps. The slowstart never applies when HAProxy starts, otherwise it would cause trouble to running servers. It only applies when a server has been previously seen as failed. sni <expression> The "sni" parameter evaluates the sample fetch expression, converts it to a string and uses the result as the host name sent in the SNI TLS extension to the server. A typical use case is to send the SNI received from the client in a bridged HTTPS scenario, using the "ssl_fc_sni" sample fetch for the expression, though alternatives such as req.hdr(host) can also make sense. If "verify required" is set (which is the recommended setting), the resulting name will also be matched against the server certificate's names. See the "verify" directive for more details. If you want to set a SNI for health checks, see the "check-sni" directive for more details. source <addr>[:[-]] [usesrc { <addr2>[:<port2>] | client | clientip } ] source <addr>[:<port>] [usesrc { <addr2>[:<port2>] | hdr_ip([,<occ>]) } ] source <addr>[:[-]] [interface <name>] ... The "source" parameter sets the source address which will be used when connecting to the server. It follows the exact same parameters and principle as the backend "source" keyword, except that it only applies to the server referencing it. Please consult the "source" keyword for details. Additionally, the "source" statement on a server line allows one to specify a source port range by indicating the lower and higher bounds delimited by a dash ('-'). Some operating systems might require a valid IP address when a source port range is specified. It is permitted to have the same IP/range for several servers. Doing so makes it possible to bypass the maximum of 64k total concurrent connections. The limit will then reach 64k connections per server. Since Linux 4.2/libc 2.23 IP_BIND_ADDRESS_NO_PORT is set for connections specifying the source address without port(s). ssl This option enables SSL ciphering on outgoing connections to the server. It is critical to verify server certificates using "verify" when using SSL to connect to servers, otherwise the communication is prone to trivial man in the-middle attacks rendering SSL useless. When this option is used, health checks are automatically sent in SSL too unless there is a "port" or an "addr" directive indicating the check should be sent to a different location. See the "no-ssl" to disable "ssl" option and "check-ssl" option to force SSL health checks. ssl-max-ver [ SSLv3 | TLSv1.0 | TLSv1.1 | TLSv1.2 | TLSv1.3 ] This option enforces use of <version> or lower 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". ssl-min-ver [ SSLv3 | TLSv1.0 | TLSv1.1 | TLSv1.2 | TLSv1.3 ] This option enforces use of <version> or upper when SSL is used to communicate with the server. This option is also available on global statement "ssl-default-server-options". See also "ssl-max-ver". ssl-reuse This option may be used as "server" setting to reset any "no-ssl-reuse" 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" "no-ssl-reuse" setting. stick This option may be used as "server" setting to reset any "non-stick" 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" "non-stick" setting. socks4 <addr>:<port> This option enables upstream socks4 tunnel for outgoing connections to the server. Using this option won't force the health check to go via socks4 by default. You will have to use the keyword "check-via-socks4" to enable it. tcp-ut <delay> Sets the TCP User Timeout for all outgoing connections to this server. 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 server has disappeared in order to release all resources associated with its connection (and the client's session). One typical use case is also to force dead server connections to die when health checks are too slow or during a soft reload since health checks are then disabled. The argument is a delay expressed in milliseconds by default. This only works for regular TCP connections, and is ignored for other protocols. tfo This option enables using TCP fast open when connecting to servers, on systems that support it (currently only the Linux kernel >= 4.11). See the "tfo" bind option for more information about TCP fast open. Please note that when using tfo, you should also use the "conn-failure", "empty-response" and "response-timeout" keywords for "retry-on", or HAProxy won't be able to retry the connection on failure. See also "no-tfo". track [<proxy>/]<server> This option enables ability to set the current state of the server by tracking another one. It is possible to track a server which itself tracks another server, provided that at the end of the chain, a server has health checks enabled. If <proxy> is omitted the current one is used. If disable-on-404 is used, it has to be enabled on both proxies. tls-tickets This option may be used as "server" setting to reset any "no-tls-tickets" setting which would have been inherited from "default-server" directive as default value. 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"). It may also be used as "default-server" setting to reset any previous "default-server" "no-tls-tickets" setting. verify [none|required] This setting is only available when support for OpenSSL was built in. If set to 'none', server certificate is not verified. In the other case, The certificate provided by the server is verified using CAs from 'ca-file' and optional CRLs from 'crl-file' after having checked that the names provided in the certificate's subject and subjectAlternateNames attributes match either the name passed using the "sni" directive, or if not provided, the static host name passed using the "verifyhost" directive. When no name is found, the certificate's names are ignored. For this reason, without SNI it's important to use "verifyhost". On verification failure the handshake is aborted. It is critically important to verify server certificates when using SSL to connect to servers, otherwise the communication is prone to trivial man-in-the-middle attacks rendering SSL totally useless. Unless "ssl_server_verify" appears in the global section, "verify" is set to "required" by default. verifyhost This setting is only available when support for OpenSSL was built in, and only takes effect if 'verify required' is also specified. This directive sets a default static hostname to check the server's certificate against when no SNI was used to connect to the server. If SNI is not used, this is the only way to enable hostname verification. This static hostname, when set, will also be used for health checks (which cannot provide an SNI value). If none of the hostnames in the certificate match the specified hostname, the handshake is aborted. The hostnames in the server-provided certificate may include wildcards. See also "verify", "sni" and "no-verifyhost" options. weight The "weight" parameter is used to adjust the server's weight relative to other servers. All servers will receive a load proportional to their weight relative to the sum of all weights, so the higher the weight, the higher the load. The default weight is 1, and the maximal value is 256. A value of 0 means the server will not participate in load-balancing but will still accept persistent connections. If this parameter is used to distribute the load according to server's capacity, it is recommended to start with values which can both grow and shrink, for instance between 10 and 100 to leave enough room above and below for later adjustments. ws { auto | h1 | h2 } This option allows to configure the protocol used when relaying websocket streams. This is most notably useful when using an HTTP/2 backend without the support for H2 websockets through the RFC8441. The default mode is "auto". This will reuse the same protocol as the main one. The only difference is when using ALPN. In this case, it can try to downgrade the ALPN to "http/1.1" only for websocket streams if the configured server ALPN contains it. The value "h1" is used to force HTTP/1.1 for websockets streams, through ALPN if SSL ALPN is activated for the server. Similarly, "h2" can be used to force HTTP/2.0 websockets. Use this value with care : the server must support RFC8441 or an error will be reported by haproxy when relaying websockets. Note that NPN is not taken into account as its usage has been deprecated in favor of the ALPN extension. See also "alpn" and "proto".

5.3. Server IP address resolution using DNS

HAProxy allows using a host name on the server line to retrieve its IP address
using name servers. By default, HAProxy resolves the name when parsing the
configuration file, at startup and cache the result for the process's life.
This is not sufficient in some cases, such as in Amazon where a server's IP
can change after a reboot or an ELB Virtual IP can change based on current
workload.
This chapter describes how HAProxy can be configured to process server's name
resolution at run time.
Whether run time server name resolution has been enable or not, HAProxy will
carry on doing the first resolution when parsing the configuration.

5.3.1. Global overview

As we've seen in introduction, name resolution in HAProxy occurs at two
different steps of the process life:	
	
  1. when starting up, HAProxy parses the server line definition and matches a
     host name. It uses libc functions to get the host name resolved. This
     resolution relies on /etc/resolv.conf file.	
	
  2. at run time, HAProxy performs periodically name resolutions for servers
     requiring DNS resolutions.	
	
A few other events can trigger a name resolution at run time:
  - when a server's health check ends up in a connection timeout: this may be
    because the server has a new IP address. So we need to trigger a name
    resolution to know this new IP.	
	
When using resolvers, the server name can either be a hostname, or a SRV label.
HAProxy considers anything that starts with an underscore as a SRV label. If a
SRV label is specified, then the corresponding SRV records will be retrieved
from the DNS server, and the provided hostnames will be used. The SRV label
will be checked periodically, and if any server are added or removed, HAProxy
will automatically do the same.	
	
A few things important to notice:	
  - all the name servers are queried in the meantime. HAProxy will process the
    first valid response.	
	
  - a resolution is considered as invalid (NX, timeout, refused), when all the
    servers return an error.	

5.3.2. The resolvers section

This section is dedicated to host information related to name resolution in
HAProxy. There can be as many as resolvers section as needed. Each section can
contain many name servers.	
	
At startup, HAProxy tries to generate a resolvers section named "default", if
no section was named this way in the configuration. This section is used by
default by the httpclient and uses the parse-resolv-conf keyword. If HAProxy
failed to generate automatically this section, no error or warning are emitted.	
	
When multiple name servers are configured in a resolvers section, then HAProxy
uses the first valid response. In case of invalid responses, only the last one
is treated. Purpose is to give the chance to a slow server to deliver a valid
answer after a fast faulty or outdated server.	
	
When each server returns a different error type, then only the last error is
used by HAProxy. The following processing is applied on this error:	

  1. HAProxy retries the same DNS query with a new query type. The A queries are
     switch to AAAA or the opposite. SRV queries are not concerned here. Timeout
     errors are also excluded.	

  2. When the fallback on the query type was done (or not applicable), HAProxy
     retries the original DNS query, with the preferred query type.	

  3. HAProxy retries previous steps  times. If no valid
     response is received after that, it stops the DNS resolution and reports
     the error.	
	
For example, with 2 name servers configured in a resolvers section, the
following scenarios are possible:	

  - First response is valid and is applied directly, second response is
    ignored	

  - First response is invalid and second one is valid, then second response is
    applied	

  - First response is a NX domain and second one a truncated response, then
    HAProxy retries the query with a new type	

  - First response is a NX domain and second one is a timeout, then HAProxy
    retries the query with a new type	

  - Query timed out for both name servers, then HAProxy retries it with the
    same query type	
	
As a DNS server may not answer all the IPs in one DNS request, HAProxy keeps
a cache of previous answers, an answer will be considered obsolete after
 seconds without the IP returned.
	

resolvers 	
  Creates a new name server list labeled 	
	
A resolvers section accept the following parameters:	
	
accepted_payload_size 	
  Defines the maximum payload size accepted by HAProxy and announced to all the
  name servers configured in this resolvers section.	
   is in bytes. If not set, HAProxy announces 512. (minimal value defined
       by RFC 6891)	

  Note: the maximum allowed value is 65535. Recommended value for UDP is
        4096 and it is not recommended to exceed 8192 except if you are sure
        that your system and network can handle this (over 65507 makes no sense
        since is the maximum UDP payload size). If you are using only TCP
        nameservers to handle huge DNS responses, you should put this value
        to the max: 65535.	
	
nameserver <name> <address>[:port] [param*]	
  Used to configure a nameserver. <name> of the nameserver should ne unique.
  By default the <address> is considered of type datagram. This means if an
  IPv4 or IPv6 is configured without special address prefixes (paragraph 11.)
  the UDP protocol will be used.  If an stream protocol address prefix is used,
  the nameserver will be considered as a stream server (TCP for instance) and
  "server" parameters found in 5.2 paragraph which are relevant for DNS
  resolving will be considered.  Note: currently, in TCP mode, 4 queries are
  pipelined on the same connections. A batch of idle connections are removed
  every 5 seconds. "maxconn" can be configured to limit the amount of those
  concurrent connections and TLS should also usable if the server supports.	
	
parse-resolv-conf	
  Adds all nameservers found in /etc/resolv.conf to this resolvers nameservers
  list. Ordered as if each nameserver in /etc/resolv.conf was individually
  placed in the resolvers section in place of this directive.	
	
hold  	
  Defines  during which the last name resolution should be kept based
  on last resolution 	
     : last name resolution status. Acceptable values are "nx",
               "other", "refused", "timeout", "valid", "obsolete".	
     : interval between two successive name resolution when the last
               answer was in . It follows the HAProxy time format.
                is in milliseconds by default.	
	
  Default value is 10s for "valid", 0s for "obsolete" and 30s for others.	
	
resolve_retries 	
  Defines the number  of queries to send to resolve a server name before
  giving up.	
  Default value: 3	
	
  A retry occurs on name server timeout or when the full sequence of DNS query
  type failover is over and we need to start up from the default ANY query
  type.	
	
timeout  <time>	
  Defines timeouts related to name resolution	
      : the event on which the <time> timeout period applies to.
               events available are:
               - resolve : default time to trigger name resolutions when no
                           other time applied.
                           Default value: 1s
               - retry   : time between two DNS queries, when no valid response
                           have been received.
                           Default value: 1s
     <time>  : time related to the event. It follows the HAProxy time format.
               <time> is expressed in milliseconds.

  Example:

   resolvers mydns
     nameserver dns1 10.0.0.1:53
     nameserver dns2 10.0.0.2:53
     nameserver dns3 tcp@10.0.0.3:53
     parse-resolv-conf
     resolve_retries       3
     timeout resolve       1s
     timeout retry         1s
     hold other           30s
     hold refused         30s
     hold nx              30s
     hold timeout         30s
     hold valid           10s
     hold obsolete        30s

6. Cache

HAProxy provides a cache, which was designed to perform cache on small objects
(favicon, css...). This is a minimalist low-maintenance cache which runs in
RAM.		
		
The cache is based on a memory area shared between all threads, and split in 1kB
blocks.		
		
If an object is not used anymore, it can be deleted to store a new object
independently of its expiration date. The oldest objects are deleted first
when we try to allocate a new one.		
		
The cache uses a hash of the host header and the URI as the key.		
		
It's possible to view the status of a cache using the Unix socket command
"show cache" consult section 9.3 "Unix Socket commands" of Management Guide
for more details.		
		
When an object is delivered from the cache, the server name in the log is
replaced by "<CACHE>".

6.1. Limitation

The cache won't store and won't deliver objects in these cases:		
		
- If the response is not a 200	
- If the response contains a Vary header and either the process-vary option is
  disabled, or a currently unmanaged header is specified in the Vary value (only
  accept-encoding and referer are managed for now)
- If the Content-Length + the headers size is greater than "max-object-size"
- If the response is not cacheable
- If the response does not have an explicit expiration time (s-maxage or max-age
  Cache-Control directives or Expires header) or a validator (ETag or Last-Modified
  headers)
- If the process-vary option is enabled and there are already max-secondary-entries
  entries with the same primary key as the current response
- If the process-vary option is enabled and the response has an unknown encoding (not
  mentioned in https://www.iana.org/assignments/http-parameters/http-parameters.xhtml)
  while varying on the accept-encoding client header

- If the request is not a GET
- If the HTTP version of the request is smaller than 1.1
- If the request contains an Authorization header

6.2. Setup

To setup a cache, you must define a cache section and use it in a proxy with
the corresponding http-request and response actions.

6.2.1. Cache section

cache <name>		
  Declare a cache section, allocate a shared cache memory named <name>, the
  size of cache is mandatory.		
		
total-max-size 		
  Define the size in RAM of the cache in megabytes. This size is split in
  blocks of 1kB which are used by the cache entries. Its maximum value is 4095.		
		
max-object-size <bytes>		
  Define the maximum size of the objects to be cached. Must not be greater than
  an half of "total-max-size". If not set, it equals to a 256th of the cache size.
  All objects with sizes larger than "max-object-size" will not be cached.		
		
max-age 		
  Define the maximum expiration duration. The expiration is set as the lowest
  value between the s-maxage or max-age (in this order) directive in the
  Cache-Control response header and this value. The default value is 60
  seconds, which means that you can't cache an object more than 60 seconds by
  default.		
		
process-vary 		
  Enable or disable the processing of the Vary header. When disabled, a response
  containing such a header will never be cached. When enabled, we need to calculate
  a preliminary hash for a subset of request headers on all the incoming requests
  (which might come with a cpu cost) which will be used to build a secondary key
  for a given request (see RFC 7234#4.1). The default value is off (disabled).		
		
max-secondary-entries <number>		
  Define the maximum number of simultaneous secondary entries with the same primary
  key in the cache. This needs the vary support to be enabled. Its default value is 10
  and should be passed a strictly positive integer.		

6.2.2. Proxy section

http-request cache-use <name> [ { if | unless } <condition> ]		
  Try to deliver a cached object from the cache <name>. This directive is also
  mandatory to store the cache as it calculates the cache hash. If you want to
  use a condition for both storage and delivering that's a good idea to put it
  after this one.		
		
http-response cache-store <name> [ { if | unless } <condition> ]		
  Store an http-response within the cache. The storage of the response headers
  is done at this step, which means you can use others http-response actions
  to modify headers before or after the storage of the response. This action
  is responsible for the setup of the cache storage filter.

Example:

    backend bck1
      mode http

      http-request cache-use foobar
      http-response cache-store foobar
      server srv1 127.0.0.1:80

    cache foobar
      total-max-size 4
      max-age 240

7. Using ACLs and fetching samples

HAProxy is capable of extracting data from request or response streams, from
client or server information, from tables, environmental information etc...
The action of extracting such data is called fetching a sample. Once retrieved,
these samples may be used for various purposes such as a key to a stick-table,
but most common usages consist in matching them against predefined constant
data called patterns.

7.1. ACL basics

The use of Access Control Lists (ACL) provides a flexible solution to perform
content switching and generally to take decisions based on content extracted
from the request, the response or any environmental status. The principle is
simple :		
	
  - extract a data sample from a stream, table or the environment
  - optionally apply some format conversion to the extracted sample
  - apply one or multiple pattern matching methods on this sample
  - perform actions only when a pattern matches the sample
	
The actions generally consist in blocking a request, selecting a backend, or
adding a header.	
	
In order to define a test, the "acl" keyword is used. The syntax is :	
	
   acl <aclname> <criterion> [flags] [operator] [<value>] ...	
	
This creates a new ACL <aclname> or completes an existing one with new tests.
Those tests apply to the portion of request/response specified in <criterion>
and may be adjusted with optional flags [flags]. Some criteria also support
an operator which may be specified before the set of values. Optionally some
conversion operators may be applied to the sample, and they will be specified
as a comma-delimited list of keywords just after the first keyword. The values
are of the type supported by the criterion, and are separated by spaces.	
	
ACL names must be formed from upper and lower case letters, digits, '-' (dash),
'_' (underscore) , '.' (dot) and ':' (colon). ACL names are case-sensitive,
which means that "my_acl" and "My_Acl" are two different ACLs.	
	
There is no enforced limit to the number of ACLs. The unused ones do not affect
performance, they just consume a small amount of memory.	
	
The criterion generally is the name of a sample fetch method, or one of its ACL
specific declinations. The default test method is implied by the output type of
this sample fetch method. The ACL declinations can describe alternate matching
methods of a same sample fetch method. The sample fetch methods are the only
ones supporting a conversion.	
	
Sample fetch methods return data which can be of the following types :
  - boolean
  - integer (signed or unsigned)
  - IPv4 or IPv6 address
  - string
  - data block
	
Converters transform any of these data into any of these. For example, some
converters might convert a string to a lower-case string while other ones
would turn a string to an IPv4 address, or apply a netmask to an IP address.
The resulting sample is of the type of the last converter applied to the list,
which defaults to the type of the sample fetch method.	
	
Each sample or converter returns data of a specific type, specified with its
keyword in this documentation. When an ACL is declared using a standard sample
fetch method, certain types automatically involved a default matching method
which are summarized in the table below :	
   +---------------------+-----------------+
   | Sample or converter | Default         |
   |    output type      | matching method |
   +---------------------+-----------------+
   | boolean             | bool            |
   +---------------------+-----------------+
   | integer             | int             |
   +---------------------+-----------------+
   | ip                  | ip              |
   +---------------------+-----------------+
   | string              | str             |
   +---------------------+-----------------+
   | binary              | none, use "-m"  |
   +---------------------+-----------------+
Note that in order to match a binary samples, it is mandatory to specify a
matching method, see below.		
	
The ACL engine can match these types against patterns of the following types :	
  - boolean	
  - integer or integer range	
  - IP address / network	
  - string (exact, substring, suffix, prefix, subdir, domain)	
  - regular expression	
  - hex block	
	
The following ACL flags are currently supported :	
	
   -i : ignore case during matching of all subsequent patterns.	
   -f : load patterns from a file.	
   -m : use a specific pattern matching method	
   -n : forbid the DNS resolutions	
   -M : load the file pointed by -f like a map file.	
   -u : force the unique id of the ACL	
   -- : force end of flags. Useful when a string looks like one of the flags.	
	
The "-f" flag is followed by the name of a file from which all lines will be
read as individual values. It is even possible to pass multiple "-f" arguments
if the patterns are to be loaded from multiple files. Empty lines as well as
lines beginning with a sharp ('#') will be ignored. All leading spaces and tabs
will be stripped. If it is absolutely necessary to insert a valid pattern
beginning with a sharp, just prefix it with a space so that it is not taken for
a comment. Depending on the data type and match method, HAProxy may load the
lines into a binary tree, allowing very fast lookups. This is true for IPv4 and
exact string matching. In this case, duplicates will automatically be removed.	
	
The "-M" flag allows an ACL to use a map file. If this flag is set, the file is
parsed as two column file. The first column contains the patterns used by the
ACL, and the second column contain the samples. The sample can be used later by
a map. This can be useful in some rare cases where an ACL would just be used to
check for the existence of a pattern in a map before a mapping is applied.	
	
The "-u" flag forces the unique id of the ACL. This unique id is used with the
socket interface to identify ACL and dynamically change its values. Note that a
file is always identified by its name even if an id is set.	
	
Also, note that the "-i" flag applies to subsequent entries and not to entries
loaded from files preceding it. For instance :	
	
    acl valid-ua hdr(user-agent) -f exact-ua.lst -i -f generic-ua.lst test	
	
In this example, each line of "exact-ua.lst" will be exactly matched against
the "user-agent" header of the request. Then each line of "generic-ua" will be
case-insensitively matched. Then the word "test" will be insensitively matched
as well.	
	
The "-m" flag is used to select a specific pattern matching method on the input
sample. All ACL-specific criteria imply a pattern matching method and generally
do not need this flag. However, this flag is useful with generic sample fetch
methods to describe how they're going to be matched against the patterns. This
is required for sample fetches which return data type for which there is no
obvious matching method (e.g. string or binary). When "-m" is specified and
followed by a pattern matching method name, this method is used instead of the
default one for the criterion. This makes it possible to match contents in ways
that were not initially planned, or with sample fetch methods which return a
string. The matching method also affects the way the patterns are parsed.	
	
The "-n" flag forbids the dns resolutions. It is used with the load of ip files.
By default, if the parser cannot parse ip address it considers that the parsed
string is maybe a domain name and try dns resolution. The flag "-n" disable this
resolution. It is useful for detecting malformed ip lists. Note that if the DNS
server is not reachable, the HAProxy configuration parsing may last many minutes
waiting for the timeout. During this time no error messages are displayed. The
flag "-n" disable this behavior. Note also that during the runtime, this
function is disabled for the dynamic acl modifications.	
	
There are some restrictions however. Not all methods can be used with all
sample fetch methods. Also, if "-m" is used in conjunction with "-f", it must
be placed first. The pattern matching method must be one of the following :	

  - "found" : only check if the requested sample could be found in the stream,
              but do not compare it against any pattern. It is recommended not
              to pass any pattern to avoid confusion. This matching method is
              particularly useful to detect presence of certain contents such
              as headers, cookies, etc... even if they are empty and without
              comp