Haproxy-2.8.4 最新版代理工具

---------------------- HAProxy Configuration Manual ---------------------- version 2.8 2023/11/17 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. Size format 2.7. 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 9.7. Bandwidth limitation 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. 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 : [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. 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 : [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 : [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. 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/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. 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 supports 4 connection modes : - keep al