# 4. Proxies > Défauts, frontal, backend, écouteurs, mots-clés proxy et références d'action --- Index LLMS : [llms.txt](/fr/llms.txt) --- La configuration du proxy peut être située dans un ensemble de sections : - defaults [``] [ depuis `` ] - frontal `` [ depuis `` ] - backend `` [ depuis `` ] - écouter `` [ depuis `` ] Une section « frontend » décrit un ensemble de sockets d'écoute acceptant les connexions clientes. Une section « backend » décrit un ensemble de serveurs auxquels le proxy se connectera pour acheminer les connexions entrantes. Une section « listen » définit un proxy complet comprenant ses parties frontale et arrière regroupées dans une même section. Elle est généralement utile pour le trafic TCP uniquement. Une section « defaults » réinitialise toutes les paramètres aux valeurs documentées et définit de nouveaux paramètres utilisables par les sections ultérieures. Toutes les sections « frontend », « backend » et « listen » prennent toujours leurs paramètres initiaux à partir d'une section « defaults », par défaut la dernière apparaissant avant la section nouvellement créée. Il est possible de désigner explicitement une section « defaults » spécifique pour charger les paramètres initiaux en indiquant son nom sur la ligne de section après le mot-clé facultatif « from ». Bien que les sections « defaults » n'imposent pas de nom, il est recommandé de les nommer pour une meilleure lisibilité. C'est également la seule manière de désigner une section spécifique à utiliser à la place de la précédente par défaut. Étant donné que les noms de sections « defaults » sont facultatifs, une vérification très permissive est appliquée par défaut à leur nom, qui peut même se chevaucher. Toutefois, si une section « defaults » est référencée par une autre section, son nom doit respecter la syntaxe imposée aux noms de proxy, et ce nom doit être unique parmi les sections « defaults ». Veuillez noter qu’indépendamment de ce qui est actuellement autorisé, il est recommandé d’éviter les noms de section en double en général et de respecter la même syntaxe que pour les noms de proxy. Cette règle pourrait être imposée dans une version future. En outre, un avertissement est émis si une section « defaults » est utilisée explicitement par un proxy tout en étant également utilisée implicitement par un autre, car elle est la dernière définie. Il est fortement conseillé de ne pas mélanger ces deux modes d’utilisation, en utilisant toujours des références explicites ou en ajoutant une dernière section « defaults » commune réservée à toutes les utilisations implicites. Notez qu'il est même possible qu'une section defaults prenne ses paramètres initiaux à partir d'une autre, et hérite ainsi des paramètres à travers plusieurs niveaux de sections defaults. Cela peut être pratique pour établir certains profils de configuration afin de regrouper des paramètres par défaut (par exemple, TCP contre HTTP ou délais courts contre délais longs), mais cela peut rapidement devenir difficile à suivre. Par défaut, les sections defaults nommées sont conservées après l'analyse de la configuration. Cela permet de les réutiliser pour la création dynamique de backends. Ce comportement peut être modifié globalement via le mot-clé "tune.defaults.purge". Tous les noms de proxy doivent être composés de lettres majuscules et minuscules, de chiffres, de '-' (tiret), '\_' (souligné), '.' (point) et ':' (deux-points). Les noms d'ACL sont sensibles à la casse, ce qui signifie que « www » et « WWW » représentent deux proxies différents. Historiquement, tous les noms de proxy pouvaient se chevaucher sous certaines conditions (par exemple, lorsqu’ils ne possédaient pas les mêmes capacités frontend/backend), mais cela provoquait trop de problèmes dans les journaux ainsi que des ambiguïtés lors des opérations en ligne de commande, des noms de tables de persistance et de la récupération des statistiques. Il est désormais obligatoire que deux proxies aient des noms différents, quelle que soit leur capacité respective. Actuellement, deux modes de proxy majeurs sont pris en charge : « tcp », également appelé couche 4, et « http », également appelé couche 7. En mode couche 4, HAProxy transfère simplement le trafic bidirectionnel entre deux extrémités. En mode couche 7, HAProxy analyse le protocole et peut interagir avec celui-ci en autorisant, bloquant, redirigeant, ajoutant, modifiant ou supprimant des contenus arbitraires dans les requêtes ou les réponses, selon des critères arbitraires. En mode HTTP, le traitement appliqué aux requêtes et réponses transitées sur une connexion dépend de la combinaison des options HTTP du frontal et du backend. HAProxy prend en charge 3 modes de connexion : - KAL : maintien de la connexion ouverte (« option http-keep-alive »), qui est le mode par défaut : toutes les requêtes et réponses sont traitées, et les connexions restent ouvertes mais inactives entre les réponses et les nouvelles requêtes. - SCL : fermeture du serveur ("option http-server-close") : la connexion orientée serveur est fermée après la réception de la fin de la réponse, mais la connexion orientée client reste ouverte. - CLO : fermeture ("option httpclose") : la connexion est fermée après la fin de la réponse, et l'en-tête "Connection: close" est ajouté dans les deux sens. Le mode effectif appliqué à une connexion passant par un frontal et un backend peut être déterminé par les deux modes de proxy selon la matrice suivante, mais en résumé, les modes sont symétriques, keep-alive est l'option la plus faible et close est l'option la plus forte. Backend mode ```text | KAL | SCL | CLO ----+-----+-----+---- KAL | KAL | SCL | CLO ----+-----+-----+---- mode SCL | SCL | SCL | CLO ----+-----+-----+---- CLO | CLO | CLO | CLO ``` Il est possible de chaîner un frontend TCP à un backend HTTP. Cette configuration est sans intérêt si seule la circulation HTTP est traitée. Toutefois, elle peut être utilisée pour gérer plusieurs protocoles au sein du même frontend. Dans ce cas, la connexion client est d'abord traitée comme une connexion TCP brute avant d'être mise à niveau vers HTTP. Avant la mise à niveau, les traitements de contenu sont effectués sur des données brutes. Une fois la mise à niveau effectuée, les données sont analysées et stockées à l’aide d’une représentation interne appelée HTX, et il n’est plus possible de s’appuyer sur la représentation brute. Il n’existe aucun moyen de revenir en arrière. Il existe deux types de mises à jour : les mises à jour in situ et les mises à jour destructrices. La première implique une mise à jour TCP vers HTTP/1. Dans HTTP/1, le traitement des requêtes est sérialisé, de sorte que le flux applicatif peut être préservé. La seconde implique une mise à jour TCP vers HTTP/2. Étant donné qu'il s'agit d'un protocole multiplexé, le flux applicatif ne peut être associé à aucun flux HTTP/2 et est donc détruit. De nouveaux flux applicatifs sont ensuite créés lorsque HAProxy reçoit de nouveaux flux HTTP/2 au niveau inférieur, dans le multiplexeur H2. Il est important de comprendre cette différence, car elle change radicalement la manière de traiter les données. Lorsqu'une mise à jour HTTP/1 est effectuée, les traitements appliqués sur les données brutes ne sont ni perdus ni réexécutés, tandis qu'en cas de mise à jour HTTP/2, les flux applicatifs sont distincts et toutes les règles frontales sont systématiquement évaluées sur chacun. Comme indiqué, le premier flux, le flux TCP, est détruit, mais uniquement après l'évaluation des règles frontales. Il existe un autre point important à comprendre lorsqu’un traitement HTTP est effectué à partir d’un proxy TCP. Bien que HAProxy soit capable d’analyser HTTP/1 en temps réel à l’aide des règles tcp-request, il n’est pas possible pour HTTP/2. Seul le préambule HTTP/2 peut être analysé. Il s’agit d’une limitation majeure concernant l’analyse du contenu HTTP en TCP. Concrètement, il n’est possible de déterminer qu’avec certitude si les données reçues sont au format HTTP. Par exemple, il n’est pas possible de choisir un backend en fonction de la valeur de l’en-tête Host, alors qu’il s’agit d’une opération triviale dans HTTP/1.. Heureusement, une solution existe pour atténuer cet inconvénient. Il existe deux façons d’effectuer une mise à niveau HTTP. La première, méthode historique, consiste à sélectionner un backend HTTP. La mise à niveau a lieu lorsque le backend est défini. Ainsi, pour les mises à niveau in situ, seule la configuration du backend est prise en compte dans le traitement des données HTTP. Pour les mises à niveau destructrices, le flux applicatif est détruit, ce qui arrête son traitement. Avec cette méthode, les possibilités de choisir un backend avec une connexion HTTP/2 sont réellement limitées, comme mentionné ci-dessus, et un peu inutiles car le flux est détruit. La deuxième méthode consiste à effectuer la mise à niveau pendant l’évaluation des règles tcp-request content, grâce à l’action « switch-mode http ». Dans ce cas, la mise à niveau est effectuée dans le contexte du frontal et il est possible de définir des directives HTTP dans ce frontal. Pour les mises à niveau in situ, elle offre toute la puissance de l’analyse HTTP dès que possible. Elle n’est pas très éloignée d’un frontal HTTP. Pour les mises à niveau destructrices, cela ne change rien, sauf qu’il est inutile de choisir un backend sur une information limitée. Il s’agit bien sûr de la méthode recommandée. Ainsi, tester le protocole de la requête dans les règles tcp-request content pour effectuer une mise à niveau HTTP est suffisant. Toutes les manipulations HTTP restantes peuvent être déplacées vers le jeu de règles http-request du frontal. Mais gardez à l’esprit que les règles tcp-request content sont toujours évaluées sur chaque flux, ce qui ne peut pas être modifié. ## 4.1. Matrice des mots-clés proxy {#section-4-1} La liste suivante de mots-clés est prise en charge. La plupart d'entre eux ne peuvent être utilisés que dans un ensemble limité de types de sections. Certains sont marqués comme « dépréciés » car ils sont hérités d'une ancienne syntaxe pouvant prêter à confusion ou être fonctionnellement limitée, et de nouveaux mots-clés recommandés ont été introduits pour les remplacer. Les mots-clés marqués par «(\*)» peuvent être inversés de manière optionnelle en utilisant le préfixe « no », par exemple « no option contstats ». Cette fonctionnalité est utile lorsque l'option est activée par défaut et doit être désactivée pour une instance spécifique. Ces options peuvent également être préfixées par « default » afin de restaurer les paramètres par défaut, indépendamment de ce qui a été spécifié dans une section « defaults » précédente. Les mots-clés pris en charge dans les sections « defaults » marqués par «(!) » ne sont pris en charge que dans les sections « defaults » nommées, et non dans les sections anonymes. Note : Certains directives dangereuses et non recommandées sont intentionnellement omises dans la matrice suivante. Cela est voulu. Ces directives sont documentées. Mais leur omission dans cette liste constitue une autre manière de dissuader toute personne souhaitant les utiliser. ```text keyword defaults frontend listen backend ------------------------------------+----------+----------+---------+--------- acl X (!) X X X backlog X X X - balance X - X X be-unpublished - - X X bind - 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 crt - 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 (deprecated) - - 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 - external-check command X - X X external-check path X - X X force-persist - - X X force-be-switch - X X - filter - X X X filter-sequence - X X X fullconn X - X X guid - X X X hash-balance-factor X - X X hash-preserve-affinity 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 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 log-steps X X X - max-keep-alive-queue X - X X max-session-srv-conns 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 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 external-check X - X X option forwardfor X X X X option forwarded (*) 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-drop-request-trailers (*) X - - X option http-drop-response-trailers (*) 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 idle-close-on-response (*) X X X - option independent-streams (*) X X X X option ldap-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 - X 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 - option transparent (deprecated) (*) X - X X option use-small-buffers (*) X - X X persist rdp-cookie X - X X quic-initial 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 show-version 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 client-hs 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 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. Référence des mots-clés triés par ordre alphabétique {#section-4-2} Cette section décrit chaque mot-clé et son utilisation. **`acl [flags] [operator] ...`** ```haproxy acl [flags] [operator] ... ``` Déclarer ou compléter une liste d'accès. Peut être utilisé dans les contextes suivants : tcp, http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui(!) \| oui \| oui \| oui Cette directive n'est disponible que dans les sections defaults nommées, et non dans les sections anonymes. Les ACL définies dans une section defaults ne sont pas visibles depuis d'autres sections qui l'utilisent. Exemple : ```text 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 ``` Voir [section 7](/fr/docs/haproxy/acls-and-samples/) concernant l'utilisation des ACL. **`backlog `** ```haproxy backlog ``` Fournir des indications au système concernant la taille approximative du tampon d'écoute souhaitée Peut être utilisé dans les contextes suivants : tcp, http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| oui \| oui \| non Arguments : ```text 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. ``` Cette option n’est significative que pour les écouteurs en mode flux, y compris ceux utilisant QUIC. Son comportement, toutefois, n’est pas identique à celui des instances QUIC. Pour tous les écouteurs sauf QUIC, afin de se protéger contre les attaques par inondation SYN, une solution consiste à augmenter la taille de la file d’attente des SYN du système. Selon le système, cette valeur peut être ajustable via un paramètre système, ne pas être ajustable du tout, ou dépendre des indications fournies par l’application au moment de l’appel système listen(). Par défaut, HAProxy transmet la valeur maxconn du frontal à l’appel système listen(). Sur les systèmes pouvant utiliser cette valeur, il peut parfois être utile de pouvoir spécifier une valeur différente, d’où la présence de ce paramètre backlog. Sous Linux 2.4, le paramètre est ignoré par le système. Sous Linux 2.6, il est utilisé comme indication et le système accepte au plus la plus petite puissance de deux supérieure, sans dépasser certaines limites (généralement 32768). Pour les écouteurs QUIC, le paramètre backlog définit une limite partagée entre le nombre maximal de poignées d'établissement actives et le nombre de connexions en attente d'acceptation. La phase de poignée dépend principalement de la latence réseau avec le pair distant, tandis que la deuxième phase dépend uniquement de la charge de HAProxy. Lorsqu'une de ces limites est atteinte, haproxy commence à rejeter les paquets INITIAL, empêchant toute nouvelle allocation de connexion, jusqu'à ce que l'excédent de connexions commence à diminuer. Cette situation peut entraîner un passage silencieux des navigateurs vers des versions HTTP inférieures et le basculement vers TCP. Voir également : « maxconn » et le guide d'ajustement du système d'exploitation cible. **`balance [ ]`** ```haproxy balance [ ] balance url_param [check_post] ``` Définir l'algorithme de répartition de charge à utiliser dans un backend. Peut être utilisé dans les contextes suivants : tcp, http, log Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| non \| oui \| oui Arguments : ```text 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. may be one of the following: 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. Note: weights are ignored for backends in LOG mode. 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%). This algorithm is not usable in LOG mode. 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. This algorithm is not usable in LOG mode. 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. This algorithm is not usable in LOG mode. 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". This algorithm is not usable for backends in LOG mode, please use "log-hash" instead. 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. This algorithm is not usable for backends in LOG mode. 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". 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 "/". 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. 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. url_param The URL parameter specified in argument will be looked up in the query string of each HTTP GET request. 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 parameter which is now ignored. 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. hdr() The HTTP header 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. random random() 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 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. In addition, for large server farms with very low loads (or perfect balance), comparing loads will often lead to a tie, so in case of equal loads between all measured servers, their request rate over the last second are compared, which allows to better balance server usage over time in the same spirit as roundrobin does, and smooth consistent hash unfairness. The default value is 2, which generally shows very good distribution and performance. For large farms with low loads (less than a few requests per second per server), it may help to raise it to 3 or even 4. 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 For backends in LOG mode, the number of draws is ignored and a single random is picked since there is no notion of server load. Random log balancing can be useful with large farms or when servers are frequently added or removed from the pool of available servers as it may avoid the hammering effect that could result from roundrobin in this situation. rdp-cookie rdp-cookie() The RDP cookie (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. log-hash Takes a comma-delimited list of converters in argument. These converters are applied in sequence to the input log message, and the result will be cast as a string then hashed according to the configured hash-type. The resulting hash will be used to select the destination server among the ones declared in the log backend. The goal of this algorithm is to be able to extract a key within the final log message using string converters and then be able to stick to the same server thanks to the hash. Only "map-based" hashes are supported for now. This algorithm is only usable for backends in LOG mode, for others, please use "hash" instead. sticky Tries to stick to the same server as much as possible. The first server in the list of available servers receives all the log messages. When the server goes DOWN, the next server in the list takes its place. When a previously DOWN server goes back UP it is added at the end of the list so that the sticky server doesn't change until it becomes DOWN. is an optional list of arguments which may be needed by some algorithms. Right now, only "url_param", "uri" and "log-hash" support an optional argument. ``` L'algorithme de répartition de charge d'un backend est défini sur « random » lorsque aucun autre algorithme, mode ni option n'a été défini. L'algorithme ne peut être défini qu'une seule fois pour chaque backend. Avec les schémas d'authentification qui exigent la même connexion, comme NTLM, les algorithmes basés sur l'URI ne doivent pas être utilisés, car ils entraîneraient la redirection des requêtes ultérieures vers des serveurs backend différents, rompant ainsi les hypothèses non valides sur lesquelles repose NTLM. TCP/HTTP Exemples : ```text 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) ``` Exemples de backend de journalisation : ```text global log backend@mylog-rrb local0 # send all logs to mylog-rrb backend log backend@mylog-hash local0 # send all logs to mylog-hash backend backend mylog-rrb mode log balance roundrobin server s1 udp@127.0.0.1:514 # will receive 50% of log messages server s2 udp@127.0.0.1:514 backend mylog-hash mode log # extract "METHOD URL PROTO" at the end of the log message, # and let haproxy hash it so that log messages generated from # similar requests get sent to the same syslog server: balance log-hash 'field(-2,\")' # server list here server s1 127.0.0.1:514 #... ``` Remarque : les limitations et précautions suivantes relatives à l'utilisation de l'extension "check_post" avec "url_param" doivent être prises en compte : - toutes les requêtes POST sont prises en compte, car il n'existe aucun moyen de déterminer si les paramètres se trouvent dans le corps ou dans l'entité, qui peut contenir des données binaires. Il peut donc être nécessaire d'utiliser une autre méthode pour limiter le traitement des requêtes POST ne comportant pas de paramètres URL dans le corps. (voir acl http_end) - utiliser une valeur `` supérieure à la taille du tampon de requête n'a pas de sens et est inutile. La taille du tampon est définie au moment de la compilation et vaut 16 ko par défaut. - L'encodage de contenu n'est pas pris en charge, la recherche de paramètres échouera probablement ; la répartition de charge passera alors en mode Round Robin. - Attendu : la directive 100-continue n'est pas prise en charge, la répartition de charge passera en mode Round Robin. - Transfer-Encoding (RFC7230 3.3.1) n'est pris en charge que dans le premier morceau. Si la valeur entière du paramètre n'est pas présente dans le premier morceau, la sélection du serveur est indéfinie (en réalité, elle est déterminée par la quantité effectivement présente dans le premier morceau). - Cette fonctionnalité ne prend pas en charge la génération d'une réponse 100, 411 ou 501. - Dans certains cas, une requête "check_post" peut tenter de scanner tout le contenu du corps d’un message. La lecture se termine normalement lorsqu’un espace blanc linéaire ou un caractère de contrôle est détecté, indiquant la fin d’une éventuelle liste de paramètres d’URL. Ce comportement n’est probablement pas préoccupant pour les corps de message de type SGML. Voir aussi : « dispatch », « cookie », « transparent », « hash-type ». **`be-unpublished`** ```haproxy be-unpublished ``` Instructe le backend à démarrer dans l'état non publié. Peut être utilisé dans les contextes suivants : tcp, http, log Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend non \| non \| oui \| oui En pratique, toutes les règles use_backend et default_backend provenant d’un autre proxy qui font référence au proxy actuel sont ignorées, et les règles de commutation de contenu suivantes sont évaluées. Cette comportement peut cependant être contourné à l’aide d’une règle « force-be-switch ». Cet état est similaire à celui de désactivation, mais avec quelques différences. Premièrement, un backend non publié sera entièrement initialisé, y compris les contrôles d'état des serveurs, qui restent actifs. Enfin, un backend peut être rendu publiquement accessible via la commande « publish backend » sur la ligne de commande. Voir le manuel de gestion. Voir aussi : « force-be-switch » **`bind [
]: [, ...] [param*]`** ```haproxy bind [
]: [, ...] [param*] bind / [, ...] [param*] ``` Définissez une ou plusieurs adresses d'écoute et/ou ports dans un frontal. Peut être utilisé dans les contextes suivants : tcp, http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend non \| oui \| oui \| non Arguments : ```text
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 for UDP, specific OS features are required when binding on multiple addresses to ensure the correct network interface and source address will be used on response. In other way, for QUIC listeners only bind on multiple addresses if running with a modern enough systems. 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). - 'abnsz@' -> address is in abstract namespace (Linux only) but it is explicitly zero-terminated. This means no \0 padding is used to complete sun_path. It is useful to interconnect with programs that don't implement the default abns naming logic that haproxy uses. - 'fd@' -> use file descriptor inherited from the parent. The fd must be bound and may or may not already be listening. - 'sockpair@'-> 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. - 'quic4@' -> address is resolved as IPv4 and protocol UDP is used. Note that to achieve the best performance with a large traffic you should keep "tune.quic.fe.sock-per-conn default-on". Else QUIC connections will be multiplexed over the listener socket. Another alternative would be to duplicate QUIC listener instances over several threads, for example using "shards" keyword to at least reduce thread contention. - 'quic6@' -> address is resolved as IPv6 and protocol UDP is used. The performance note for QUIC over IPv4 applies as well. - 'rhttp@' [ EXPERIMENTAL ] -> used for reverse HTTP. Address must be a server with the format '/'. The server will be used to instantiate connections to a remote address. The listener will try to maintain "nbconn" connections. This is an experimental features which requires "expose-experimental-directives" on a line before this bind. You may want to reference some environment variables in the address parameter, see section 2.3 about environment variables. 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 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 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. 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. 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. ``` Il est possible de spécifier une liste de combinaisons adresse:port séparées par des virgules. Le frontal écoutera alors sur toutes ces adresses. Il n'existe aucune limite fixe au nombre d'adresses et de ports sur lesquels un frontal peut écouter, ni aucune limite au nombre d'instructions « bind » dans un frontal. Exemple : ```text 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 quic4@10.0.0.1:8888 ssl crt /etc/mycrt ``` Note : En ce qui concerne les sockets de l'espace de noms abstrait sous Linux, les sockets HAProxy « abns » utilisent la longueur entière de sun_path pour la longueur de l'adresse. Certains autres programmes, comme socat, utilisent par défaut uniquement la longueur de chaîne. Passez l'option « ,unix-tightsocklen=0 » à toute définition de socket abstrait dans socat pour la rendre compatible avec celle de HAProxy, ou utilisez à la place la famille de sockets HAProxy « abnsz ». Voir également : « source », « option forwardfor », « unix-bind » et la documentation du protocole PROXY, ainsi que [section 5](/fr/docs/haproxy/bind-and-server-options/) concernant les options bind. **`capture cookie len `** ```haproxy capture cookie len ``` Capturez et enregistrez un cookie dans la requête et dans la réponse. Peut être utilisé dans les contextes suivants : http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend non \| oui \| oui \| non Arguments : ```text 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). 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 . ``` Seul le premier cookie est capturé. Les en-têtes de requête « cookie » et les en-têtes de réponse « set-cookie » sont surveillés. Cela est particulièrement utile pour détecter des bugs applicatifs provoquant une chevauchement ou un vol de session entre utilisateurs, car les cookies de l'utilisateur ne devraient normalement changer que sur une page de connexion. Lorsqu'un cookie n'est pas fourni par le client, la colonne de journal associée indique « - ». Lorsqu'une requête ne provoque pas l'attribution d'un cookie par le serveur, une « - » est indiquée dans la colonne de réponse. La capture est effectuée uniquement dans le frontend, car il est nécessaire que le format des journaux ne change pas pour un frontend donné en fonction des backends. Cela pourrait évoluer à l'avenir. Notez qu'il ne peut y avoir qu'une seule instruction « capture cookie » dans un frontend. La longueur maximale de capture est définie par le paramètre global "tune.http.cookielen" et vaut 63 caractères par défaut. Il n'est pas possible de spécifier une capture dans une section « defaults ». Exemple : ```text capture cookie ASPSESSION len 32 ``` Voir également : « capture d’en-tête de requête », « capture d’en-tête de réponse » ainsi que la section [8](/fr/docs/haproxy/configuration-logging/) concernant la journalisation. **`capture request header len `** ```haproxy capture request header len ``` Capturez et enregistrez la dernière occurrence de l'en-tête de requête spécifié. Peut être utilisé dans les contextes suivants : http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend non \| oui \| oui \| non Arguments : ```text 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. 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 . ``` La valeur complète de la dernière occurrence de l’en-tête est capturée. La valeur sera ajoutée aux journaux entre accolades ('{}'). Si plusieurs en-têtes sont capturés, ils seront séparés par une barre verticale ('\|') et apparaîtront dans le même ordre que leur déclaration dans la configuration. Les en-têtes inexistants seront journalisés sous forme de chaîne vide. Les utilisations courantes de la capture d’en-têtes de requête incluent le champ "Host" dans les environnements de hébergement virtuel, le champ "Content-length" lorsqu’un téléchargement est pris en charge, le champ "User-agent" pour distinguer rapidement les utilisateurs réels des robots, et le champ "X-Forwarded-For" dans les environnements proxy afin de déterminer l’origine de la requête. Notez que lors de la capture d'en-têtes tels que « User-agent », certains espaces peuvent être enregistrés, ce qui complique l'analyse des journaux. Veillez donc à ce que vous enregistrez, si vous savez que votre analyseur de journaux n'est pas suffisamment intelligent pour s'appuyer sur les accolades. Il n’y a aucune limite au nombre d’en-têtes de requête capturés ni à leur longueur, bien qu’il soit recommandé de les limiter afin de réduire l’utilisation mémoire par flux. Pour maintenir un format de journal cohérent pour un même frontal, les captures d’en-têtes ne peuvent être déclarées qu’au sein d’un frontend. Il n’est pas possible de spécifier une capture dans une section « defaults ». Exemple : ```text capture request header Host len 15 capture request header X-Forwarded-For len 15 capture request header Referer len 15 ``` Voir aussi : « capture cookie », « capture d’en-tête de réponse » ainsi que la [section 8](/fr/docs/haproxy/configuration-logging/) concernant la journalisation. **`capture response header len `** ```haproxy capture response header len ``` Capturez et enregistrez la dernière occurrence de l'en-tête de réponse spécifié. Peut être utilisé dans les contextes suivants : http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend non \| oui \| oui \| non Arguments : ```text 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. 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 . ``` La valeur complète de la dernière occurrence de l’en-tête est capturée. Le résultat sera ajouté aux journaux entre accolades ('{}') après les en-têtes de requête capturés. Si plusieurs en-têtes sont capturés, ils seront séparés par une barre verticale ('\|') et apparaîtront dans le même ordre qu’ils ont été déclarés dans la configuration. Les en-têtes inexistants seront journalisés sous forme de chaîne vide. Les utilisations courantes des en-têtes de réponse capturés incluent l’en-tête "Content-length", qui indique le nombre d’octets attendus en retour, et l’en-tête "Location" pour suivre les redirections. Il n’y a aucune limite au nombre d’en-têtes de réponse capturés ni à leur longueur, bien qu’il soit recommandé de les garder faibles afin de limiter l’utilisation mémoire par flux. Pour maintenir un format de journal cohérent pour un même frontal, les captures d’en-têtes ne peuvent être déclarées qu’au niveau d’un frontal. Il n’est pas possible de spécifier une capture dans une section « defaults ». Exemple : ```text capture response header Content-length len 9 capture response header Location len 15 ``` Voir aussi : « capture cookie », « capture en-tête de requête », ainsi que la [section 8](/fr/docs/haproxy/configuration-logging/) concernant la journalisation. **`clitcpka-cnt `** ```haproxy clitcpka-cnt ``` Définit le nombre maximal d'enquêtes keepalive TCP qui doivent être envoyées avant de fermer la connexion du côté client. Peut être utilisé dans les contextes suivants : tcp, http, log Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| oui \| oui \| non Arguments : ```text is the maximum number of keepalive probes. ``` Ce mot-clé correspond à l'option de socket TCP_KEEPCNT. Si ce mot-clé n'est pas spécifié, le paramètre TCP système (tcp_keepalive_probes) est utilisé. La disponibilité de ce paramètre dépend du système d'exploitation. Il est connu pour fonctionner sous Linux. Voir aussi : « option clitcpka », « clitcpka-idle », « clitcpka-intvl ». **`clitcpka-idle `** ```haproxy clitcpka-idle ``` Définit le délai pendant lequel la connexion doit rester inactif avant que TCP ne commence à envoyer des sondes de maintien de connexion, si activé, l'envoi des paquets TCP keepalive côté client. Peut être utilisé dans les contextes suivants : tcp, http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| oui \| oui \| non Arguments : ```text 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. ``` Ce mot-clé correspond à l'option de socket TCP_KEEPIDLE. Si ce mot-clé n'est pas spécifié, le paramètre TCP système (tcp_keepalive_time) est utilisé. La disponibilité de ce paramètre dépend du système d'exploitation. Il est connu pour fonctionner sous Linux. Voir aussi : « option clitcpka », « clitcpka-cnt », « clitcpka-intvl ». **`clitcpka-intvl `** ```haproxy clitcpka-intvl ``` Définit le délai entre les sondes keepalive individuelles du côté client. Peut être utilisé dans les contextes suivants : tcp, http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| oui \| oui \| non Arguments : ```text 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. ``` Ce mot-clé correspond à l'option de socket TCP_KEEPINTVL. Si ce mot-clé n'est pas spécifié, le paramètre TCP système (tcp_keepalive_intvl) est utilisé. La disponibilité de ce paramètre dépend du système d'exploitation. Il est connu pour fonctionner sous Linux. Voir aussi : « option clitcpka », « clitcpka-cnt », « clitcpka-idle ». **`compression algo ...`** ```haproxy compression algo ... compression algo-req compression algo-res compression type ... ``` Activer la compression HTTP. Peut être utilisé dans les contextes suivants : http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| oui \| oui \| oui Arguments : ```text algo is followed by the list of supported compression algorithms for responses (legacy keyword) algo-req is followed by compression algorithm for request (only one is provided). algo-res is followed by the list of supported compression algorithms for responses. type is followed by the list of MIME types that will be compressed for responses (legacy keyword). type-req is followed by the list of MIME types that will be compressed for requests. type-res is followed by the list of MIME types that will be compressed for responses. ``` Les algorithmes actuellement pris en charge sont : ```text 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. ``` La compression sera activée en fonction de l’en-tête de requête Accept-Encoding. Avec la valeur identity, cet en-tête n’est pas pris en compte. Si les serveurs backend prennent en charge la compression HTTP, ces directives n’auront aucun effet : HAProxy détectera la réponse compressée et ne la comprimera pas à nouveau. Si les serveurs backend ne prennent pas en charge la compression HTTP et qu’un en-tête Accept-Encoding est présent dans la requête, HAProxy comprimera la réponse correspondante. La compression est désactivée lorsque : - la requête ne déclare pas d'algorithme de compression pris en charge dans l’en-tête « Accept-Encoding » - le message de réponse n’est pas HTTP/1.1 ou supérieur - le code de statut HTTP n’est pas l’un des codes suivants : 200, 201, 202 ou 203 - la réponse ne contient ni l’en-tête « Content-Length » ni un en-tête « Transfer-Encoding » dont la dernière valeur est « chunked » - la réponse contient un en-tête « Content-Type » dont la première valeur commence par « multipart » - la réponse contient la valeur « no-transform » dans l’en-tête « Cache-control » - l’en-tête « User-Agent » correspond à « Mozilla/4 », sauf si c’est MSIE 6 sous XP SP2, ou MSIE 7 et versions ultérieures - la réponse contient un en-tête « Content-Encoding », indiquant que la réponse est déjà compressée (voir déchargement de compression) - la réponse contient un en-tête « ETag » invalide ou plusieurs en-têtes « ETag » - la taille du contenu est inférieure à la taille minimale (voir compression minsize-res) Note : La compression n'émet pas l'en-tête Warning. Exemples : ```text compression algo gzip compression type text/html text/plain ``` Voir également : « compression offload », « compression direction », « compression minsize-req » et « compression minsize-res » **`compression minsize-req `** ```haproxy compression minsize-req compression minsize-res ``` Définit la taille minimale du contenu en octets pour la compression soit appliquée. Peut être utilisé dans les contextes suivants : http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| oui \| oui \| oui Les charges plus petites que cette taille ne seront pas compressées, évitant ainsi une surcharge CPU inutile pour des données qui ne bénéficieraient pas significativement de la compression. « minsize-req » s'applique aux requêtes et « minsize-res » aux réponses. La valeur par défaut est 0. **`compression offload`** ```haproxy compression offload ``` Fait fonctionner HAProxy en tant qu'accélérateur de compression uniquement. Peut être utilisé dans les contextes suivants : http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend non \| oui \| oui \| oui L’option « offload » fait que HAProxy supprime l’en-tête Accept-Encoding afin d’empêcher les backends de compresser les réponses. Il est fortement recommandé de ne pas procéder ainsi, car cela implique que toute la charge de compression sera effectuée au niveau du seul point où HAProxy est installé. Toutefois, dans certains scénarios de déploiement, HAProxy peut être placé devant une passerelle défectueuse présentant une implémentation incorrecte de la compression HTTP, dont la désactivation n’est pas possible. Dans ce cas, HAProxy peut être utilisé pour empêcher cette passerelle d’émettre des charges utiles non valides. Dans ce contexte, supprimer simplement l’en-tête dans la configuration ne fonctionne pas, car cette opération s’applique avant l’analyse de l’en-tête, ce qui empêche HAProxy de procéder à la compression. L’option « offload » doit alors être utilisée pour de tels scénarios. Si cette option est utilisée dans une section defaults, un avertissement est émis et l'option est ignorée. Voir aussi : « compression type », « compression algo », « compression direction » **`compression direction (deprecated)`** ```haproxy compression direction (deprecated) ``` Permet à HAProxy de compresser à la fois les requêtes et les réponses. Les valeurs valides sont « request », pour compresser uniquement les requêtes, « response », pour compresser uniquement les réponses, ou « both », lorsque vous souhaitez compresser les deux. La valeur par défaut est « response ». Cette directive n’est pertinente que lorsque la « compression filtre » ancienne était activée, car avec les filtres comp-req et comp-res, la direction de compression est redondante. Peut être utilisé dans les contextes suivants : http Voir aussi : « compression type », « compression algo », « compression offload » **`cookie [ rewrite | insert | prefix ] [ indirect ] [ nocache ]`** ```haproxy cookie [ rewrite | insert | prefix ] [ indirect ] [ nocache ] [ postonly ] [ preserve ] [ httponly ] [ secure ] [ domain ]* [ maxidle ] [ maxlife ] [ dynamic ] [ attr ]* ``` Activez la persistance basée sur les cookies dans un backend. Peut être utilisé dans les contextes suivants : http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| non \| oui \| oui Arguments : ```text 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 , 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. ``` Il ne peut y avoir qu'un seul cookie de persistance par backend HTTP, et celui-ci peut être déclaré dans une section defaults. La valeur du cookie sera la valeur indiquée après le mot-clé « cookie » dans une déclaration server. Si aucun cookie n'est déclaré pour un serveur donné, le cookie n'est pas défini. Exemples : ```text cookie JSESSIONID prefix cookie SRV insert indirect nocache cookie SRV insert postonly indirect cookie SRV insert indirect nocache maxidle 30m maxlife 8h ``` Voir aussi : « balance source », « capture cookie », « server » et « ignore-persist ». **`declare capture [ request | response ] len `** ```haproxy declare capture [ request | response ] len ``` Déclare une plage de capture. Peut être utilisé dans les contextes suivants : tcp, http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend non \| oui \| oui \| non Arguments : ```text is the length allowed for the capture. ``` Cette déclaration n'est disponible que dans la section frontend ou listen, mais l'emplacement réservé peut être utilisé dans les backends. Le mot-clé « request » alloue une plage de capture destinée à être utilisée dans la requête, et le mot-clé « response » alloue une plage de capture destinée à être utilisée dans la réponse. Voir aussi : « capture-req », « capture-res » (convertisseurs d'échantillon), "capture.req.hdr", "capture.res.hdr" (extractions d'échantillon), « http-request capture » et « http-response capture ». **`default-server [param*]`** ```haproxy default-server [param*] ``` Modifier les options par défaut d'un serveur dans un backend Peut être utilisé dans les contextes suivants : tcp, http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| non \| oui \| oui Arguments : ```text 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. ``` Exemple : ```text default-server inter 1000 weight 13 ``` Voir également : « server » et [section 5](/fr/docs/haproxy/bind-and-server-options/) concernant les options du serveur **`default_backend `** ```haproxy default_backend ``` Spécifiez le backend à utiliser lorsque aucune règle "use_backend" n'a été matchée. Peut être utilisé dans les contextes suivants : tcp, http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| oui \| oui \| non Arguments : ```text is the name of the backend to use. ``` Lorsque l'on effectue un commutateur de contenu entre un frontal et des backends en utilisant le mot-clé "use_backend", il est souvent utile d'indiquer quel backend sera utilisé lorsque aucune règle ne correspond. Il s'agit généralement du backend dynamique, qui intercepte toutes les requêtes non déterminées. Si un backend est désactivé ou non publié, les règles default_backend qui le ciblent seront ignorées et le traitement des flux restera sur le proxy d'origine. Exemple : ```text use_backend dynamic if url_dyn use_backend static if url_css url_img extension_img default_backend dynamic ``` Voir également : "use_backend" **`description `** ```haproxy description ``` Décrivez un écouteur, un frontal ou un backend. Peut être utilisé dans les contextes suivants : tcp, http, log Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend non \| oui \| oui \| oui Arguments : chaîne Permet d'ajouter une phrase de description de l'objet lié dans la page de statistiques HTML de HAProxy. La description s'affichera à droite du nom de l'objet qu'elle décrit. Aucun besoin d'échapper les espaces dans les arguments ``. **`disabled`** ```haproxy disabled ``` Désactivez un proxy, un frontal ou un backend. Peut être utilisé dans les contextes suivants : tcp, http, log Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| oui \| oui \| oui Arguments : aucun Le mot-clé « disabled » est utilisé pour désactiver une instance, principalement afin de libérer un port d'écoute ou de désactiver temporairement un service. L'instance sera toujours créée et sa configuration vérifiée, mais elle sera initialisée dans l'état « arrêté » et apparaîtra ainsi dans les statistiques. Elle ne recevra aucune requête, ni ne transmettra de vérifications de santé ni de journaux. Il est possible de désactiver plusieurs instances en même temps en ajoutant le mot-clé « disabled » dans une section « defaults ». Par défaut, un backend désactivé ne peut pas être sélectionné pour le commutateur de contenu. Toutefois, une partie du trafic peut ignorer cette règle lorsque force-be-switch est utilisé. Voir aussi : « enabled », « force-be-switch » **`dispatch
: (deprecated)`** ```haproxy dispatch
: (deprecated) ``` Définir une adresse de serveur par défaut Peut être utilisé dans les contextes suivants : tcp, http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend non \| non \| oui \| oui Arguments : ```text
is the IPv4 address of the default server. Alternatively, a resolvable hostname is supported, but this name will be resolved during start-up. 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. ``` Le mot-clé « dispatch » désigne un serveur par défaut utilisé lorsque aucun autre serveur ne peut accepter la connexion. À l’origine, il était utilisé pour acheminer les connexions non persistantes vers un chargeur d’équilibre auxiliaire. En raison de sa syntaxe simple, il a également été utilisé pour des relais TCP simples. Il est recommandé de ne pas l’utiliser afin d’améliorer la clarté, et d’utiliser à la place la directive « server ». Ce mot-clé est obsolète depuis la version 3.3 et sera supprimé dans la version 3.5 en raison de limitations internes (absence de prise en charge du SSL, des connexions inactives, etc.). Son utilisation génère un avertissement qui peut être supprimé en activant la directive « expose-deprecated-directives » dans la section globale. La bonne manière de procéder sans cette directive consiste à déclarer simplement un serveur avec la même adresse et le même port. Si la directive « dispatch » est combinée à d'autres serveurs, ces derniers doivent être configurés avec un poids nul afin de ne jamais être sélectionnés par l'algorithme de répartition de charge. Exemple : ```text backend deprecated_setup dispatch 192.168.100.100:80 # external load balancer's address server s1 192.168.100.1:80 cookie S1 check server s2 192.168.100.2:80 cookie S2 check backend modern_setup server external_lb 192.168.100.100:80 server s1 192.168.100.1:80 cookie S1 check weight 0 server s2 192.168.100.2:80 cookie S2 check weight 0 ``` Voir également : « server » **`dynamic-cookie-key `** ```haproxy dynamic-cookie-key ``` Définir la clé secrète dynamique pour un backend. Peut être utilisé dans les contextes suivants : http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| non \| oui \| oui Arguments : La clé secrète à utiliser. Lorsque les cookies dynamiques sont activés (voir la directive « dynamic » pour les cookies), un cookie dynamique est créé pour chaque serveur (sauf si un cookie est explicitement spécifié dans la ligne « server »), en utilisant un hachage de l'adresse IP du serveur, du port TCP et de la clé secrète. Ainsi, il est possible d'assurer la persistance de session à travers plusieurs équilibreurs de charge, même si les serveurs sont ajoutés ou supprimés dynamiquement. **`enabled`** ```haproxy enabled ``` Activez un proxy, un frontal ou un backend. Peut être utilisé dans les contextes suivants : tcp, http, log Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| oui \| oui \| oui Arguments : aucun Le mot-clé « enabled » est utilisé pour activer explicitement une instance, lorsque les paramètres par défaut ont été définis sur « disabled ». Cette utilisation est très rare. Voir aussi : « disabled » **`errorfile `** ```haproxy errorfile ``` Renvoyer le contenu d'un fichier au lieu des erreurs générées par HAProxy Peut être utilisé dans les contextes suivants : http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| oui \| oui \| oui Arguments : ```text is the HTTP status code. Currently, HAProxy is capable of generating codes 200, 400, 401, 403, 404, 405, 407, 408, 410, 413, 414, 425, 429, 431, 500, 501, 502, 503, and 504. 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. ``` Il est important de comprendre que ce mot-clé n’a pas pour but de réécrire les erreurs renvoyées par le serveur, mais les erreurs détectées et renvoyées par HAProxy. C’est pourquoi la liste des erreurs prises en charge est limitée à un ensemble réduit. Le code 200 est émis en réponse aux requêtes correspondant à une règle « monitor-uri ». Les fichiers sont analysés au démarrage de HAProxy et doivent être valides selon la spécification HTTP. Ils ne doivent pas dépasser la taille de tampon configurée (BUFSIZE), qui est généralement de 16 ko, faute de quoi une erreur interne sera renvoyée. Il est également recommandé de ne pas référencer de contenus locaux (par exemple des images) afin d'éviter les boucles entre le client et HAProxy lorsque tous les serveurs sont hors service, ce qui provoquerait une erreur au lieu d'une image. Enfin, la réponse ne peut pas dépasser (tune.bufsize - tune.maxrewrite) afin que les règles « http-after-response » puissent encore fonctionner (voir "tune.maxrewrite"). Les fichiers sont lus en même temps que la configuration et conservés en mémoire. Pour cette raison, les erreurs sont toujours renvoyées, même lorsque le processus est chrooté, et aucune modification de fichier n'est prise en compte pendant l'exécution du processus. Une méthode simple pour développer ces fichiers consiste à les associer au code d'état 403 et à interroger une URL bloquée. Voir aussi : « http-error », « errorloc », « errorloc302 », « errorloc303 » Exemple : ```text 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 [ ...]`** ```haproxy errorfiles [ ...] ``` Importez, en totalité ou en partie, les fichiers d'erreur définis dans la section `` http-errors. Peut être utilisé dans les contextes suivants : http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| oui \| oui \| oui Arguments : ```text is the name of an existing http-errors section. 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, 414, 425, 429, 431, 500, 501, 502, 503, and 504. ``` Les erreurs définies dans la section http-errors sous le nom `` sont importées dans le proxy actuel. Si aucun code d'état n'est spécifié, tous les fichiers d'erreur de la section http-errors sont importés. Sinon, seuls les fichiers d'erreur associés aux codes d'état indiqués sont importés. Ces fichiers d'erreur remplacent les erreurs personnalisées déjà définies pour le proxy. Ils peuvent être remplacés par des fichiers ultérieurs. Fonctionnellement, cela revient exactement à déclarer tous les fichiers d'erreur manuellement à l'aide des directives "errorfile". Voir également : « http-error », « errorfile », « errorloc », « errorloc302 », « errorloc303 » et [section 12.4](/fr/docs/haproxy/other-sections/#section-12-4) concernant les erreurs HTTP. Exemple : ```text errorfiles generic errorfiles site-1 403 404 ``` **`errorloc `** ```haproxy errorloc errorloc302 ``` Renvoyer une redirection HTTP vers une URL au lieu des erreurs générées par HAProxy Peut être utilisé dans les contextes suivants : http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| oui \| oui \| oui Arguments : ```text is the HTTP status code. Currently, HAProxy is capable of generating codes 200, 400, 401, 403, 404, 405, 407, 408, 410, 413, 414, 425, 429, 431, 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). ``` Il est important de comprendre que ce mot-clé n’a pas pour but de réécrire les erreurs renvoyées par le serveur, mais les erreurs détectées et renvoyées par HAProxy. C’est pourquoi la liste des erreurs prises en charge est limitée à un ensemble réduit. Le code 200 est émis en réponse aux requêtes correspondant à une règle « monitor-uri ». Notez que les deux mots-clés renvoient le code d’état HTTP 302, qui indique au client de récupérer l’URL désignée en utilisant la même méthode HTTP. Cela peut poser des problèmes importants en cas de méthodes autres que GET, comme POST, car l’URL envoyée au client pourrait ne pas être autorisée pour une requête autre que GET. Pour contourner ce problème, utilisez plutôt « errorloc303 », qui envoie le code d’état HTTP 303, indiquant au client que l’URL doit être récupérée à l’aide d’une requête GET. Voir aussi : « http-error », « errorfile », « errorloc303 » **`errorloc303 `** ```haproxy errorloc303 ``` Renvoyer une redirection HTTP vers une URL au lieu des erreurs générées par HAProxy Peut être utilisé dans les contextes suivants : http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| oui \| oui \| oui Arguments : ```text is the HTTP status code. Currently, HAProxy is capable of generating codes 200, 400, 401, 403, 404, 405, 407, 408, 410, 413, 414, 425, 429, 431, 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). ``` Il est important de comprendre que ce mot-clé n’a pas pour but de réécrire les erreurs renvoyées par le serveur, mais les erreurs détectées et renvoyées par HAProxy. C’est pourquoi la liste des erreurs prises en charge est limitée à un ensemble réduit. Le code 200 est émis en réponse aux requêtes correspondant à une règle « monitor-uri ». Notez que les deux mots-clés renvoient le code d’état HTTP 303, qui indique au client de récupérer l’URL désignée en utilisant la méthode HTTP GET. Cela résout les problèmes habituels liés à « errorloc » et au code 302. Il est possible que certains navigateurs très anciens, conçus avant HTTP/1.1, ne le supportent pas, mais aucun problème de ce type n’a été signalé à ce jour. Voir aussi : « http-error », « errorfile », « errorloc », « errorloc302 » **`email-alert from `** ```haproxy email-alert from ``` Déclare l'adresse email à utiliser à la fois dans l'enveloppe et l'en-tête des alertes par courriel. Il s'agit de l'adresse depuis laquelle les alertes par courriel sont envoyées. Peut être utilisé dans les contextes suivants : tcp, http, log Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| oui \| oui \| oui Arguments : ```text is the from email address to use when sending email alerts ``` Exige également que les paramètres « email-alert mailers » et « email-alert to » soient définis, et, le cas échéant, active l'envoi d'alertes par courriel pour le proxy. Voir aussi : « email-alert level », « email-alert mailers », « email-alert myhostname », « email-alert to », [section 12.3](/fr/docs/haproxy/other-sections/#section-12-3) concernant les serveurs de messagerie. **`email-alert level `** ```haproxy email-alert level ``` Déclare le niveau maximal de journalisation des messages pour lesquels des alertes par courriel seront envoyées. Cela agit comme un filtre sur l'envoi des alertes par courriel. Peut être utilisé dans les contextes suivants : tcp, http, log Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| oui \| oui \| oui Arguments : ```text One of the 8 syslog levels: emerg alert crit err warning notice info debug The above syslog levels are ordered from lowest to highest. ``` Par défaut, le niveau est alert Exige également que les paramètres « email-alert from », « email-alert mailers » et « email-alert to » soient définis ; si c’est le cas, l’envoi d’alertes par courriel est activé pour le proxy. Les alertes sont envoyées lorsque : - Un serveur non mis en pause est marqué comme hors service lorsque `` est à l'état d'alerte ou inférieur - Un serveur mis en pause est marqué comme hors service lorsque `` est à l'état d'information ou inférieur - Un serveur est marqué comme opérationnel ou passe en état de vidage lorsque `` est à l'état d'information ou inférieur - L'option log-health-checks est activée, `` est à l'état d'information ou inférieur, et une mise à jour de l'état du contrôle d'état a lieu Voir aussi : « email-alert from », « email-alert mailers », « email-alert myhostname », « email-alert to », [section 12.3](/fr/docs/haproxy/other-sections/#section-12-3) concernant les serveurs de messagerie. **`email-alert mailers `** ```haproxy email-alert mailers ``` Déclare les serveurs de messagerie à utiliser lors de l'envoi d'alertes par courrier électronique Peut être utilisé dans les contextes suivants : tcp, http, log Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| oui \| oui \| oui Arguments : ```text is the name of the mailers section to send email alerts. ``` Exige également que les paramètres « email-alert from » et « email-alert to » soient définis ; si c’est le cas, l’envoi d’alertes par courriel est activé pour le proxy. Voir également : « email-alert from », « email-alert level », « email-alert myhostname », « email-alert to », [section 12.3](/fr/docs/haproxy/other-sections/#section-12-3) concernant les serveurs de messagerie. **`email-alert myhostname `** ```haproxy email-alert myhostname ``` Déclare l'adresse du nom d'hôte à utiliser lors de la communication avec les serveurs de messagerie. Peut être utilisé dans les contextes suivants : tcp, http, log Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| oui \| oui \| oui Arguments : ```text is the hostname to use when communicating with mailers ``` Par défaut, le nom d'hôte du système est utilisé. Exige également que les paramètres « email-alert from », « email-alert mailers » et « email-alert to » soient définis ; si c’est le cas, l’envoi d’alertes par courriel est activé pour le proxy. Voir également : « email-alert from », « email-alert level », « email-alert mailers », « email-alert to », [section 12.3](/fr/docs/haproxy/other-sections/#section-12-3) concernant les serveurs de messagerie. **`email-alert to `** ```haproxy email-alert to ``` Déclarez à la fois l'adresse du destinataire dans l'enveloppe et l'adresse de destination dans l'en-tête des alertes par courriel. C'est l'adresse à laquelle les alertes par courriel sont envoyées. Peut être utilisé dans les contextes suivants : tcp, http, log Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| oui \| oui \| oui Arguments : ```text is the to email address to use when sending email alerts ``` Exige également que les paramètres « email-alert mailers » et « email-alert to » soient définis, et, le cas échéant, active l'envoi d'alertes par courriel pour le proxy. Voir aussi : « email-alert from », « email-alert level », « email-alert mailers », « email-alert myhostname », [section 12.3](/fr/docs/haproxy/other-sections/#section-12-3) concernant les serveurs de messagerie. **`error-log-format `** ```haproxy error-log-format ``` Spécifie la chaîne de format de journalisation à utiliser en cas d'erreur de connexion du côté frontal. Peut être utilisé dans les contextes suivants : tcp, http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| oui \| oui \| non Ce directive spécifie la chaîne de format de journalisation utilisée pour les journaux contenant des informations relatives aux erreurs, aux délais d'expiration, aux réessais, aux redirigements ou aux codes d'état HTTP 5xx. Ce format sera brièvement utilisé pour chaque ligne de journal concernée par l'option « log-separate-errors », y compris les erreurs de connexion décrites dans la [section 8.2.5](/fr/docs/haproxy/configuration-logging/#section-8-2-5). Si la directive est utilisée dans une section defaults, tous les frontaux ultérieurs utiliseront le même format de journalisation. Veuillez consulter [section 8.2.6](/fr/docs/haproxy/configuration-logging/#section-8-2-6) qui traite en détail la chaîne de format de journalisation personnalisée. La directive « error-log-format » remplace les directives « error-log-format » précédentes. **`force-persist { if | unless } `** ```haproxy force-persist { if | unless } ``` Déclare une condition pour forcer la persistance sur les serveurs inaccessibles Peut être utilisé dans les contextes suivants : tcp, http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend non \| non \| oui \| oui Par défaut, les requêtes ne sont pas acheminées vers les serveurs hors service. Il est possible de forcer ce comportement en utilisant « option persist », mais cette option est inconditionnelle et redirige vers un serveur valide si « option redispatch » est activée. Cela laisse très peu de possibilités pour forcer certaines requêtes à atteindre un serveur artificiellement marqué comme hors service lors d'opérations de maintenance. L'instruction « force-persist » permet de déclarer diverses conditions basées sur des ACL qui, lorsqu'elles sont remplies, font en sorte qu'une requête ignore l'état « hors service » d'un serveur et tente tout de même de s'y connecter. Cela permet de démarrer un serveur, qui continue de renvoyer une erreur aux contrôles d'état, tout en permettant d'exécuter un navigateur spécialement configuré pour tester le service. Parmi les méthodes pratiques, on peut utiliser une adresse IP source spécifique, ou un cookie spécifique. Le cookie présente l'avantage de pouvoir être facilement added/removed depuis le navigateur à partir d'une page de test. Une fois le service validé, il devient possible d'ouvrir le service au monde entier en renvoyant une réponse valide aux contrôles d'état. La persistance forcée est activée lorsque la condition « if » est remplie, ou sauf si la condition « unless » est remplie. Le réacheminement final est toujours désactivé lors de son utilisation. Voir aussi : « option redispatch », « ignore-persist », « persist » et [section 7](/fr/docs/haproxy/acls-and-samples/) concernant l'utilisation des ACL. **`external-check command `** ```haproxy external-check command ``` Exécutable à exécuter lors d'un contrôle externe Peut être utilisé dans les contextes suivants : tcp, http, log Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| non \| oui \| oui Arguments : ```text is the external command to run ``` Les arguments passés à la commande sont : `` `` `` `` Les `` et `` sont dérivés de la première écouteur qui est soit IPv4, soit IPv6, soit une socket UNIX. Dans le cas d'un écouteur de socket UNIX, le proxy_address sera le chemin de la socket et `` sera la chaîne "NOT_USED". Dans une section backend, il n'est pas possible de déterminer un écouteur, et les deux valeurs `` et `` auront pour valeur la chaîne "NOT_USED". Certains valeurs sont également fournies via des variables d'environnement. Variables d'environnement : ```text 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". ``` Si la commande exécutée se termine avec un statut zéro, le contrôle est considéré comme réussi ; sinon, le contrôle est considéré comme échoué. Exemple : ```text external-check command /bin/true ``` Voir aussi : « external-check », « option external-check », « external-check path » **`external-check path `** ```haproxy external-check path ``` Valeur de la variable d'environnement PATH utilisée lors de l'exécution d'un contrôle externe Peut être utilisé dans les contextes suivants : tcp, http, log Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| non \| oui \| oui Arguments : ```text is the path used when executing external command to run ``` Le chemin par défaut est "". Exemple : ```text external-check path "/usr/bin:/bin" ``` Voir aussi : « external-check », « option external-check », « external-check command » **`force-be-switch { if | unless } `** ```haproxy force-be-switch { if | unless } ``` Permet le choix d'une instance backend, même si elle est désactivée ou non publiée, lors du commutateur de contenu. Cette règle peut être utilisée par les administrateurs pour tester le trafic vers des services avant de les exposer au monde extérieur. Peut être utilisé dans les contextes suivants : tcp, http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend non \| oui \| oui \| non Voir aussi : « be-unpublished », « disabled » **`filter [param*]`** ```haproxy filter [param*] ``` Ajoutez le filtre `` à la liste des filtres associée au proxy. Peut être utilisé dans les contextes suivants : tcp, http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend non \| oui \| oui \| oui Arguments : ```text is the name of the filter. Officially supported filters are referenced in section 9. is a list of parameters accepted by the filter . 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. ``` Plusieurs occurrences de la ligne de filtre peuvent être utilisées pour le même proxy. Le même filtre peut être référencé plusieurs fois si nécessaire. Exemple : ```text 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 ``` Voir aussi : [section 9](/fr/docs/haproxy/filters/), « filter-sequence » filter-sequence { requête \| réponse } `` Spécifie l'ordre d'exécution des filtres déclarés sur le proxy. Peut être utilisé dans les contextes suivants : tcp, http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend non \| oui \| oui \| oui Liste séparée par des virgules de noms de filtres (``) pour spécifier l'ordre d'exécution des filtres déclarés sur le proxy, respectivement pour le chemin de la requête ou de la réponse. Lorsque filter-sequence n'est pas spécifié pour un chemin donné (par exemple : requête vs réponse), l'ordre dans lequel les filtres sont déclarés sur le proxy est utilisé. Si la séquence de filtres omet certains filtres déclarés sur le proxy, ceux-ci ne seront pas exécutés. Ceci constitue une méthode efficace pour désactiver temporairement un filtre sans le supprimer de la configuration. Exemple : ```text global lua-load my-filter.lua # defines custom "lua.my-filter" frontend myfront filter comp-req filter comp-res filter lua.my-filter filter-sequence request lua.my-filter,comp-req filter-sequence response lua.my-filter,comp-res ``` Voir aussi : « filter » **`fullconn `** ```haproxy fullconn ``` Spécifiez à quelle charge du backend les serveurs atteindront leur maxconn Peut être utilisé dans les contextes suivants : tcp, http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| non \| oui \| oui Arguments : ```text is the number of connections on the backend which will make the servers use the maximal number of connections. ``` Lorsqu’un serveur dispose d’un paramètre « maxconn » défini, cela signifie que son nombre de connexions simultanées ne dépassera jamais cette valeur. En outre, si un paramètre « minconn » est également défini, cela indique une limite dynamique qui suit la charge du backend. Le serveur acceptera alors toujours au moins `` connexions, jamais plus de ``, et la limite sera ajustée progressivement entre ces deux valeurs lorsque le backend dispose de moins de `` connexions simultanées. Cela permet de limiter la charge sur les serveurs en conditions normales, tout en permettant de la pousser davantage en cas de charges importantes, sans surcharger les serveurs en cas de charges exceptionnelles. Étant donné qu'il est difficile d'obtenir cette valeur correcte, HAProxy la définit automatiquement à 10 % de la somme des maxconns de tous les frontaux pouvant rediriger vers ce backend (selon les règles "use_backend" et "default_backend"). Ainsi, il est sans risque de la laisser non définie. Toutefois, les règles "use_backend" impliquant des noms dynamiques ne sont pas prises en compte, car il n'existe aucun moyen de savoir si elles pourraient correspondre ou non. Exemple : ```shell # 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 ``` Voir aussi : « maxconn », « server » **`guid `** ```haproxy guid ``` Spécifiez un identifiant global unique sensible à la casse pour ce proxy. Peut être utilisé dans les contextes suivants : tcp, http, log Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend non \| oui \| oui \| oui `` doit être unique dans l'ensemble de la configuration haproxy, pour tous les types d'objets. Le format n'est pas spécifié afin de permettre à l'utilisateur de choisir sa politique d'affectation de noms. La seule restriction est sa longueur, qui ne peut pas dépasser 127 caractères. Toutes les valeurs alphanumériques ainsi que les caractères '.', ':', '-' et '\_' sont autorisés. Voir également « shm-stats-file ». **`hash-balance-factor `** ```haproxy hash-balance-factor ``` Spécifiez le facteur de répartition pour le hachage cohérent à charge bornée Peut être utilisé dans les contextes suivants : tcp, http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| non \| non \| oui Arguments : ```text 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. ``` Spécifier un « hash-balance-factor » pour un serveur avec « hash-type consistent » active un algorithme qui empêche qu’un serveur reçoive trop de requêtes en même temps, même si certaines buckets de hachage reçoivent beaucoup plus de requêtes que d’autres. La mise à `` de 0 (valeur par défaut) désactive cette fonctionnalité. Sinon, `` est un pourcentage supérieur à 100. Par exemple, si `` est égal à 150, aucun serveur ne pourra avoir une charge supérieure à 1,5 fois la charge moyenne. Si des poids de serveurs sont utilisés, ceux-ci seront respectés. Si le serveur de première choix est déclaré inapte, l'algorithme sélectionne un autre serveur en fonction du hachage de la requête, jusqu'à trouver un serveur disposant de capacité supplémentaire. Une valeur plus élevée de `` autorise un déséquilibre plus important entre les serveurs, tandis qu'une valeur plus faible de `` signifie qu'en moyenne, plus de serveurs seront examinés, ce qui impacte les performances. Des valeurs raisonnables se situent entre 125 et 200. Ce paramètre est également utilisé par « balance random », qui repose en interne sur le mécanisme de hachage cohérent. Voir également : « balance » et « hash-type ». **`hash-preserve-affinity { always | maxconn | maxqueue }`** ```haproxy hash-preserve-affinity { always | maxconn | maxqueue } ``` Spécifiez une méthode d’affectation des flux aux serveurs avec la répartition de charge par hachage lorsque les serveurs sont saturés ou ont une file d’attente pleine. Peut être utilisé dans les contextes suivants : http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| non \| oui \| oui Les valeurs suivantes peuvent être spécifiées : - "always" : il s'agit de la stratégie par défaut. Un flux est affecté à un serveur en fonction d'un hachage, indépendamment du fait que le serveur soit actuellement surchargé. - "maxconn" : lorsque sélectionné, les serveurs ayant la valeur "maxconn" définie et actuellement saturés sont ignorés. Un autre serveur est sélectionné en suivant l'anneau de hachage. Cela n'a aucun effet sur les serveurs qui n'ont pas défini "maxconn". Si tous les serveurs sont saturés, la requête est mise en file d'attente sur le dernier serveur de l'anneau de hachage situé avant le serveur initialement sélectionné. - "maxqueue" : lorsque sélectionné, les serveurs ayant la valeur "maxconn" définie, ainsi que "maxqueue" définie sur une valeur non nulle (taille de file limitée) et dont la file est actuellement pleine sont ignorés. Un autre serveur est sélectionné en suivant l'anneau de hachage. Cette option n'a aucun effet sur les serveurs qui ne définissent pas à la fois "maxconn" et "maxqueue". Voir aussi : « maxconn », « maxqueue », « hash-balance-factor » **`hash-type `** ```haproxy hash-type ``` Spécifiez une méthode à utiliser pour mapper les hachages sur les serveurs Peut être utilisé dans les contextes suivants : tcp, http, log Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| non \| oui \| oui Arguments : ```text is the method used to select a server from the hash computed by the : 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. 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. none don't hash the key, the key will be used as a hash, this can be useful to manually hash the key using a converter for that purpose and let haproxy use the result directly. The operation will convert the key to a string if it is not already, and parse it as an integer whose value will be used as the key. Some input key types might not be relevant here (e.g. IP addresses). 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. ``` Le type de hachage par défaut est « map-based » et est recommandé pour la plupart des utilisations. La fonction par défaut est « sdbm ». Le choix d'une fonction doit être fondé sur la plage des valeurs à hacher. Voir aussi : « balance », « hash-balance-factor », « hash-preserve-affinity », « server » **`http-after-response [ { if | unless } ]`** ```haproxy http-after-response [ { if | unless } ] ``` Contrôle d'accès pour toutes les réponses au niveau 7 (serveur, applet/service et internes). Peut être utilisé dans les contextes suivants : http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui(!) \| oui \| oui \| oui L'instruction http-after-response définit un ensemble de règles applicables au traitement au niveau couche 7. Ces règles sont évaluées dans l'ordre de leur déclaration lorsqu'elles sont rencontrées dans une section frontend, listen ou backend. Comme ces règles s'appliquent aux réponses, les règles du backend sont évaluées en premier, suivies par celles du frontend. Toute règle peut éventuellement être suivie d'une condition basée sur une ACL, auquel cas elle n'est évaluée que si la condition est vraie. Contrairement aux règles http-response, celles-ci s'appliquent à toutes les réponses, tant aux réponses du serveur qu'aux réponses générées par HAProxy. Ces règles sont évaluées à la fin de l'analyse des réponses, avant la phase de transfert des données. La condition est évaluée juste avant l'exécution de l'action, et celle-ci est exécutée exactement une fois. Il n'y a donc aucun problème si une action modifie un élément vérifié dans le cadre de la condition. Cela signifie également que plusieurs actions peuvent s'appuyer sur la même condition, de sorte que la première action qui modifie l'évaluation de la condition suffit à désactiver implicitement les actions restantes. Cette approche est utilisée, par exemple, lorsqu'il s'agit d'attribuer une valeur à une variable à partir de différentes sources lorsque celle-ci est vide. Il n'y a aucune limite au nombre d'instructions « http-after-response » par instance. Le premier mot-clé après « http-after-response » dans la syntaxe est l’action de la règle, éventuellement suivi d’un nombre variable d’arguments pour cette action. Les actions prises en charge ainsi que leurs syntaxes respectives sont énumérées dans [section 4.3](/fr/docs/haproxy/proxies/#section-4-3) « Actions » (rechercher les actions marquées de « HTTP Aft »). Cette directive n'est disponible que dans les sections defaults nommées, et non dans les sections anonymes. Les règles définies dans la section defaults sont évaluées avant celles de la section proxy associée. Pour éviter les ambigüités, dans ce cas, une même section defaults ne peut pas être utilisée par des proxies possédant la capacité frontend et par des proxies possédant la capacité backend. Cela signifie qu'une section listen ne peut pas utiliser une section defaults définissant de telles règles. Note : Les erreurs émises en phase précoce de l'analyse de la requête sont gérées par le multiplexeur à un niveau inférieur, avant toute analyse HTTP. Ainsi, aucun jeu de règles http-after-response n'est évalué sur ces erreurs. Exemple : ```text 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-check comment `** ```haproxy http-check comment ``` Définit un commentaire pour la règle http-check suivante, signalé dans les journaux en cas d'échec. Peut être utilisé dans les contextes suivants : tcp, http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| non \| oui \| oui Arguments : ```text is the comment message to add in logs if the following http-check rule fails. ``` Il ne fonctionne qu'avec les règles connect, send et expect. Il est utile pour produire des rapports d'erreurs conviviaux. Voir également : « option httpchk », « http-check connect », « http-check send » et « http-check expect ». **`http-check connect [default] [port ] [addr ] [send-proxy]`** ```haproxy http-check connect [default] [port ] [addr ] [send-proxy] [via-socks4] [ssl] [sni ] [alpn ] [linger] [proto ] [comment ] ``` Ouvre une nouvelle connexion pour effectuer un contrôle d'état HTTP Peut être utilisé dans les contextes suivants : tcp, http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| non \| oui \| oui Arguments : ```text comment 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 if not set, check port or server port is used. It tells HAProxy where to open the connection to. must be a valid TCP port source integer, from 1 to 65535 or an sample-fetch expression. addr 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 specifies the SNI to use to do health checks over SSL. 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 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. ``` Tout comme les contrôles d'état tcp-check, il est possible de configurer la connexion à utiliser pour effectuer un contrôle d'état HTTP. Cette directive doit également être utilisée pour décrire un scénario impliquant plusieurs échanges request/response, éventuellement sur des ports différents ou avec des serveurs distincts. Lorsqu’aucun port TCP n’est configuré dans la ligne server ni dans la directive server port, le premier étape de la séquence http-check doit consister à préciser le port à l’aide de la directive « http-check connect ». Dans un ensemble de règles http-check, une directive « connect » est obligatoire ; il est également obligatoire de commencer l'ensemble de règles par une règle « connect ». L'objectif est de garantir que l'administrateur sait ce qu'il fait. Lorsqu'une connexion doit démarrer le jeu de règles, elle peut encore être précédée par des règles set-var, unset-var ou comment. Exemples : ```shell # 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 ``` Voir également : « option httpchk », « http-check send », « http-check expect » **`http-check disable-on-404`** ```haproxy http-check disable-on-404 ``` Activer un mode maintenance en cas de réponse HTTP/404 aux vérifications de santé Peut être utilisé dans les contextes suivants : tcp, http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| non \| oui \| oui Arguments : aucun Lorsque cette option est activée, un serveur renvoyant un code HTTP 404 est exclu du chargement de la répartition, mais continue de recevoir les connexions persistantes. Cette fonctionnalité offre une méthode très pratique aux administrateurs Web pour effectuer un arrêt progressif de leurs serveurs. Il est également important de noter qu’un serveur détecté comme défaillant pendant qu’il était en ce mode ne déclenche pas d’alerte, uniquement un avis. Si le serveur répond à nouveau avec un code 2xx ou 3xx, il est immédiatement réintégré dans la ferme. L’état affiché sur la page de statistiques indique « NOLB » pour un serveur en ce mode. Il est essentiel de noter que cette option ne fonctionne qu’en conjonction avec l’option « httpchk ». Si cette option est utilisée avec « http-check expect », elle a priorité sur celle-ci, de sorte que les réponses 404 sont toujours considérées comme une interruption douce. Notez également qu’un serveur arrêté reste arrêté même s’il répond avec un code 404. Cette option n’est évaluée que pour les serveurs en cours d’exécution. Voir également : « option httpchk » et « http-check expect ». **`http-check expect [min-recv ] [comment ]`** ```haproxy http-check expect [min-recv ] [comment ] [ok-status ] [error-status ] [tout-status ] [on-success ] [on-error ] [status-code ] [!] ``` Effectuez des contrôles d'état HTTP en tenant compte du contenu de la réponse ou de codes d'état spécifiques Peut être utilisé dans les contextes suivants : tcp, http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| non \| oui \| oui Arguments : ```text comment 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 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 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 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 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. is a Custom log format string (see section 8.2.6). on-error is optional and can be used to customize the informational message reported in logs if an error occurred during the expect rule evaluation. is a Custom log format string (see section 8.2.6). status-code is optional and can be used to set the check status code reported in logs, on success or on error. is a standard HAProxy expression formed by a sample-fetch followed by some converters. 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. 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 ('\'). ``` Par défaut, l’option « option httpchk » considère que les codes de réponse 2xx et 3xx sont valides, et que les autres sont invalides. Lorsque « http-check expect » est utilisé, il définit ce qui est considéré comme valide ou invalide. Une seule instruction « http-check » est autorisée dans un backend. Si un serveur ne répond pas ou expiré, le contrôle échoue évidemment. Les correspondances disponibles sont : ```text status : test the status codes found parsing 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 : 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 ] [ { value | value-lf } [ -m ] : 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, is evaluated as a Custom log format string (see section 8.2.6). If "value-lf" parameter is used, 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 ] [ { value | value-lf } [ -m ] : test the specified full header pattern on the HTTP response headers. It does exactly the same as the "hdr" keyword, except the full header value is tested, commas are not considered as delimiters. 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 : 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 : test a Custom log format string (see section 8.2.6) 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 , which follows the log-format rules. If prefixed with "!", then the response will be considered invalid if the body contains the string. ``` Il est important de noter que les réponses seront limitées à une taille définie par l'option globale "tune.bufsize", qui vaut par défaut 16384 octets. Ainsi, les réponses trop grandes peuvent ne pas contenir le motif obligatoire lors de l'utilisation de « string » ou de « rstring ». Si une réponse de grande taille est absolument nécessaire, il est possible de modifier la taille maximale par défaut en définissant la variable globale. Toutefois, il convient de garder à l'esprit que l'analyse de réponses très grandes peut consommer des cycles CPU, notamment lors de l'utilisation d'expressions régulières, et qu'il est toujours préférable de cibler les vérifications sur des ressources plus petites. Dans un jeu de règles http-check, la dernière règle expect peut être implicite. Si aucune règle expect n'est spécifiée après le dernier « http-check send », une règle expect implicite est définie pour correspondre aux codes d'état 2xx ou 3xx. Cela signifie que cette règle est également définie lorsque aucune règle « http-check » n'est présente du tout, à condition que seule l'option « option httpchk » soit définie. Enfin, si « http-check expect » est combiné avec « http-check disable-on-404 », alors ce dernier a la priorité lorsque le serveur répond avec le code 404. Exemples : ```shell # only accept status 200 as valid http-check expect status 200,201,300-310 # be sure a sessid coookie is set http-check expect hdr 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 ``` Voir également : « option httpchk », « http-check connect », « http-check disable-on-404 » et « http-check send ». **`http-check send [meth ] [{ uri | uri-lf }>] [ver ]`** ```haproxy http-check send [meth ] [{ uri | uri-lf }>] [ver ] [hdr ]* [{ body | body-lf }] [comment ] ``` Ajoutez une liste éventuelle d'en-têtes et/ou un corps à la requête envoyée lors des contrôles d'état HTTP. Peut être utilisé dans les contextes suivants : tcp, http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| non \| oui \| oui Arguments : ```text comment defines a message to report if the rule evaluation fails. meth 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 optional and set the URI referenced in the HTTP requests to the string . 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 is optional and set the URI referenced in the HTTP requests using the Custom log format (see section 8.2.6). 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 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 adds the HTTP header field whose name is specified in and whose value is defined by , which follows the Custom log format rules described in section 8.2.6. body add the body defined by to the request sent during HTTP health checks. If defined, the "Content-Length" header is thus automatically added to the request. body-lf add the body defined by the Custom log format (see section 8.2.6) to the request sent during HTTP health checks. If defined, the "Content-Length" header is thus automatically added to the request. ``` En plus de la ligne de requête définie par la directive « option httpchk », cette méthode est la façon valide d’ajouter des en-têtes et éventuellement un corps à la requête envoyée lors des contrôles d’état HTTP. Si un corps est défini, l’en-tête « Content-Length » associé est automatiquement ajouté. Par conséquent, cet en-tête ou l’en-tête « Transfer-encoding » ne doit pas être présent dans la requête fournie par « http-check send ». S’ils sont présents, ils seront ignorés. La méthode ancienne consistant à ajouter des en-têtes après la chaîne de version sur la ligne « option httpchk » est désormais obsolète. De plus, « http-check send » ne prend pas en charge la persistance de connexion HTTP. Veillez à ce qu’un en-tête « Connection: close » soit automatiquement ajouté, sauf si un en-tête Connection a déjà été configuré via une entrée hdr. Notez que l’en-tête Host et l’autorité de requête, lorsqu’ils sont tous deux définis, sont automatiquement synchronisés. Cela signifie que, lorsque la requête HTTP est envoyée, l’insertion d’un en-tête Host entraîne une mise à jour correspondante de l’autorité de requête. Par conséquent, ne vous étonnez pas si la valeur de l’en-tête Host remplace l’autorité de requête configurée. Notez également que, pour l'instant, aucun en-tête Host n'est ajouté automatiquement dans les requêtes HTTP/1.1 ou ultérieures. Vous devez l'ajouter explicitement. Voir également : « option httpchk », « http-check send-state » et « http-check expect ». **`http-check send-state`** ```haproxy http-check send-state ``` Activer l'émission d'un en-tête d'état avec les contrôles d'état HTTP Peut être utilisé dans les contextes suivants : tcp, http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| non \| oui \| oui Arguments : aucun Lorsque cette option est activée, HAProxy enverra systématiquement un en-tête spécial « X-HAProxy-Server-State » contenant une liste de paramètres indiquant à chaque serveur la manière dont HAProxy le perçoit. Cette fonctionnalité peut être utilisée, par exemple, lorsque un serveur est manipulé sans accès à HAProxy et que l'opérateur doit savoir si HAProxy le considère toujours comme actif ou non, ou s'il s'agit du dernier serveur d'une ferme. L'en-tête est composé de champs séparés par des points-virgules, le premier étant un mot ("UP", "DOWN", "NOLB"), éventuellement suivi d'un nombre de vérifications valides avant la transition, tel qu'il apparaît dans l'interface de statistiques. Les en-têtes suivants sont au format "``=``", indiquant, dans un ordre quelconque, certaines valeurs disponibles dans l'interface de statistiques : - une variable "address", contenant l'adresse du backend. Cela correspond au champ `
` dans la déclaration du serveur. Pour les sockets Unix, cela affichera "unix". - une variable "port", contenant le port du serveur backend. Cela correspond au champ `` dans la déclaration du serveur. Pour les sockets Unix, la valeur sera "unix". - une variable "name", contenant le nom du backend suivi d'un slash ("/") puis le nom du serveur. Cette variable peut être utilisée lorsque serveur est vérifié dans plusieurs backends. - une variable "node" contenant le nom du nœud HAProxy, tel qu'indiqué dans la variable globale "node", sinon le nom d'hôte du système si non spécifié. - une variable "weight" indiquant le poids du serveur, un slash ("/") et le poids total de la ferme (en ne comptant que les serveurs utilisables). Cela permet de savoir si d'autres serveurs sont disponibles pour prendre en charge la charge en cas de défaillance de celui-ci. - une variable "scur" indiquant le nombre actuel de connexions simultanées sur le serveur, suivie d'une barre oblique ("/") puis du nombre total de connexions sur tous les serveurs du même backend. - une variable "qcur" indiquant le nombre actuel de requêtes dans la file d'attente du serveur. Exemple d’un en-tête reçu par le serveur d’application : ```shell >>> X-Haproxy-Server-State: UP 2/3; name=bck/srv2; node=lb1; weight=1/2; \ scur=13/22; qcur=0 ``` Voir également : « option httpchk », « http-check disable-on-404 » et « http-check send ». **`http-check set-var([,...]) `** ```haproxy http-check set-var([,...]) http-check set-var-fmt([,...]) ``` Cette opération définit le contenu d'une variable. La variable est déclarée en inline. Peut être utilisé dans les contextes suivants : tcp, http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| non \| oui \| oui Arguments : ```text The name of the variable. Only "proc", "sess" and "check" scopes can be used. See section 2.8 about variables for details. 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. Is a sample-fetch expression potentially followed by converters. This is the value expressed using Custom log format (see Custom Log Format in section 8.2.6). ``` Exemples : ```text http-check set-var(check.port) int(1234) http-check set-var-fmt(check.port) "name=%H" ``` **`http-check unset-var()`** ```haproxy http-check unset-var() ``` Libère une référence à une variable dans son contexte. Peut être utilisé dans les contextes suivants : tcp, http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| non \| oui \| oui Arguments : ```text The name of the variable. Only "proc", "sess" and "check" scopes can be used. See section 2.8 about variables for details. ``` Exemples : ```text http-check unset-var(check.port) ``` **`http-error status [content-type ]`** ```haproxy http-error status [content-type ] [ { default-errorfiles | errorfile | errorfiles | ``` file `` | lf-file `` | string `` | lf-string `` } ] [ hdr `` `` ]* Définit un message d'erreur personnalisé à utiliser à la place des erreurs générées par HAProxy. Peut être utilisé dans les contextes suivants : http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| oui \| oui \| oui Arguments : ```text status 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, 414, 425, 429, 431, 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 . 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 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 designates the http-errors section to use to import the error message with the status code . If no such message is found, the proxy's error messages are considered. 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. 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 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. is evaluated as a Custom log format (see section 8.2.6). 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 adds to the response the HTTP header field whose name is specified in and whose value is defined by , which follows the Custom log format rules (see section 8.2.6). This parameter is ignored if an errorfile is used. ``` Ce directive peut être utilisée à la place de « errorfile » pour définir un message d'erreur personnalisé. Comme la directive « errorfile », elle est utilisée pour les erreurs détectées et renvoyées par HAProxy. Si un fichier d'erreur est défini, il est analysé au démarrage de HAProxy et doit être conforme aux normes HTTP. La réponse générée ne doit pas dépasser la taille de tampon configurée (BUFFSIZE), sinon une erreur interne sera renvoyée. Enfin, si vous envisagez d'utiliser des règles http-after-response pour réécrire ces erreurs, l'espace de tampon réservé doit être disponible (voir "tune.maxrewrite"). Les fichiers sont lus en même temps que la configuration et conservés en mémoire. Pour cette raison, les erreurs sont toujours renvoyées, même lorsque le processus est chrooté, et aucune modification de fichier n'est prise en compte pendant l'exécution du processus. Note : les erreurs 400/408/500 émises en phase précoce de l'analyse de la requête sont gérées par le multiplexeur à un niveau inférieur. Aucune mise en forme personnalisée n'est prise en charge à ce niveau. Seules les messages d'erreur statiques, définis avec la directive « errorfile », sont prises en charge. Toutefois, cette limitation n'existe que pendant l'analyse des en-têtes de la requête ou entre deux transactions. Voir aussi : « errorfile », « errorfiles », « errorloc », « errorloc302 », « errorloc303 » et [section 12.4](/fr/docs/haproxy/other-sections/#section-12-4) concernant les erreurs HTTP. **`http-request [options...] [ { if | unless } ]`** ```haproxy http-request [options...] [ { if | unless } ] ``` Contrôle d'accès pour les requêtes au niveau 7 Peut être utilisé dans les contextes suivants : http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui(!) \| oui \| oui \| oui L'instruction http-request définit un ensemble de règles applicables au traitement au niveau 7. Ces règles sont évaluées dans l'ordre de leur déclaration lorsqu'elles sont rencontrées dans une section frontend, listen ou backend. Chaque règle peut éventuellement être suivie d'une condition basée sur une ACL, auquel cas elle n'est évaluée que si la condition se traduit par une valeur vraie. La condition est évaluée juste avant l'exécution de l'action, et celle-ci est exécutée exactement une fois. Il n’y a donc aucun problème si une action modifie un élément vérifié dans le cadre de la condition. Cela signifie également que plusieurs actions peuvent s’appuyer sur la même condition, de sorte que la première action qui modifie l’évaluation de la condition suffit à désactiver implicitement les actions restantes. Cette approche est utilisée, par exemple, lorsqu’il s’agit d’attribuer une valeur à une variable provenant de différentes sources lorsque celle-ci est vide. Il n’y a aucune limite au nombre d’instructions « http-request » par instance. Le premier mot-clé après « http-request » dans la syntaxe est l’action de la règle, éventuellement suivi d’un nombre variable d’arguments pour cette action. Les actions prises en charge ainsi que leurs syntaxes respectives sont énumérées dans [section 4.3](/fr/docs/haproxy/proxies/#section-4-3) « Actions » (rechercher les actions marquées de « HTTP Req »). Cette directive n'est disponible que dans les sections defaults nommées, et non dans les sections anonymes. Les règles définies dans la section defaults sont évaluées avant celles de la section proxy associée. Pour éviter les ambigüités, dans ce cas, une même section defaults ne peut pas être utilisée par des proxies possédant la capacité frontend et par des proxies possédant la capacité backend. Cela signifie qu'une section listen ne peut pas utiliser une section defaults définissant de telles règles. Exemple : ```text 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 ``` Exemple : ```text 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 ``` Exemple : ```text 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 ``` Voir aussi : « stats http-request », [section 12.2](/fr/docs/haproxy/other-sections/#section-12-2) sur les listes d'utilisateurs et [section 7](/fr/docs/haproxy/acls-and-samples/) sur l'utilisation des ACL. **`http-response [ { if | unless } ]`** ```haproxy http-response [ { if | unless } ] ``` Contrôle d'accès pour les réponses au niveau 7 Peut être utilisé dans les contextes suivants : http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui(!) \| oui \| oui \| oui L'instruction http-response définit un ensemble de règles applicables au traitement au niveau couche 7. Ces règles sont évaluées dans l'ordre de leur déclaration lorsqu'elles sont rencontrées dans une section frontend, listen ou backend. Comme ces règles s'appliquent aux réponses, les règles du backend sont évaluées en premier, suivies par celles du frontend. Une règle peut éventuellement être suivie d'une condition basée sur une ACL, auquel cas elle n'est évaluée que si la condition est vraie. La condition est évaluée juste avant l'exécution de l'action, et celle-ci est exécutée exactement une fois. Il n'y a donc aucun problème si une action modifie un élément vérifié dans le cadre de la condition. Cela signifie également que plusieurs actions peuvent s'appuyer sur la même condition, de sorte que la première action qui modifie l'évaluation de la condition suffit à désactiver implicitement les actions restantes. Cette approche est utilisée, par exemple, lorsqu'il s'agit d'attribuer une valeur à une variable provenant de différentes sources lorsque celle-ci est vide. Il n'y a aucune limite au nombre d'instructions « http-response » par instance. Le premier mot-clé après « http-response » dans la syntaxe est l’action de la règle, éventuellement suivi d’un nombre variable d’arguments pour cette action. Les actions prises en charge ainsi que leurs syntaxes respectives sont énumérées dans [section 4.3](/fr/docs/haproxy/proxies/#section-4-3) « Actions » (rechercher les actions marquées de « HTTP Res »). Cette directive n'est disponible que dans les sections defaults nommées, et non dans les sections anonymes. Les règles définies dans la section defaults sont évaluées avant celles de la section proxy associée. Pour éviter les ambigüités, dans ce cas, une même section defaults ne peut pas être utilisée par des proxies possédant la capacité frontend et par des proxies possédant la capacité backend. Cela signifie qu'une section listen ne peut pas utiliser une section defaults définissant de telles règles. Exemple : ```text 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 ``` Exemple : ```text 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 ``` Voir également : « http-request », [section 12.2](/fr/docs/haproxy/other-sections/#section-12-2) sur les listes d'utilisateurs et [section 7](/fr/docs/haproxy/acls-and-samples/) sur l'utilisation des ACL. **`http-reuse { never | safe | aggressive | always }`** ```haproxy http-reuse { never | safe | aggressive | always } ``` Déclare la manière dont les connexions HTTP inactives peuvent être partagées entre les requêtes Peut être utilisé dans les contextes suivants : http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| non \| oui \| oui Afin d’éviter le coût lié à la mise en place de nouvelles connexions vers les serveurs backend pour chaque requête HTTP, HAProxy tente de maintenir ces connexions inactives ouvertes après leur utilisation. Ces connexions sont spécifiques à un serveur et sont stockées dans une liste appelée pool, regroupées selon un ensemble de propriétés clés communes. Les requêtes HTTP ultérieures provoquent une recherche d’une connexion compatible partageant les mêmes propriétés dans le pool associé, ce qui permet de réutiliser cette connexion au lieu d’en établir une nouvelle. Une limite sur le nombre de connexions inactives à maintenir sur un serveur peut être spécifiée à l'aide du mot-clé de configuration pool-max-conn pour le serveur. Les connexions inutilisées sont purgées périodiquement selon l'intervalle pool-purge-delay. Les propriétés de connexion suivantes sont utilisées pour déterminer si une connexion inactif est éligible à la réutilisation pour une requête donnée : - adresses source et destination - protocole proxy - options de socket TOS et mark - nom de connexion, déterminé soit par le résultat de l'évaluation de l'expression « pool-conn-name » si présente, soit par l'expression « sni », qui par défaut vaut « req.hdr(host),field(1,:) », c’est-à-dire utilise le champ d’en-tête « Host » de la requête entrante sans deux-points ni numéro de port. Dans certains cas, la recherche ou la réutilisation de connexion n'est pas effectuée en raison de restrictions supplémentaires. Cela est déterminé par la stratégie de réutilisation spécifiée via l'argument mot-clé : - "never" : les connexions inactives ne sont jamais partagées entre les sessions. Ce mode peut être imposé pour annuler une stratégie différente héritée d'une section defaults ou dans un contexte de dépannage. Par exemple, si une ancienne application erronée considère que plusieurs requêtes effectuées sur la même connexion proviennent du même client, et qu'il n'est pas possible de corriger l'application, il peut être souhaitable de désactiver le partage des connexions pour un seul backend. Un exemple d'une telle application pourrait être une ancienne version d'HAProxy utilisant l'insertion de cookies en mode tunnel sans vérifier aucune requête après la première. - "safe" : il s'agit de la stratégie par défaut et recommandée. La première requête d'une session est toujours envoyée via sa propre connexion, et seules les requêtes ultérieures peuvent être acheminées par d'autres connexions existantes. Cela garantit que, si le serveur ferme la connexion pendant l'envoi de la requête, le navigateur peut décider de la renvoyer silencieusement. Étant donné qu'il s'agit d'une configuration strictement équivalente à la mise en mémoire tampon régulière, aucune conséquence secondaire n'est à craindre. Une gestion spéciale est également appliquée aux connexions utilisant des protocoles sujets au blocage en tête de file (backend avec h2 ou fcgi). Dans ce cas, dès qu'au moins un flux est traité, la connexion utilisée est réservée pour gérer les flux de la même session. Dès lors que plus aucun flux n'est traité, la connexion est libérée et peut être réutilisée. - "aggressive" : ce mode peut être utile dans les environnements de services web où tous les serveurs ne sont pas nécessairement connus, et où il serait avantageux de traiter la plupart des premières requêtes sur des connexions existantes. Dans ce cas, les premières requêtes ne sont envoyées que sur des connexions existantes ayant déjà été réutilisées au moins une fois, ce qui prouve que le serveur prend correctement en charge la réutilisation des connexions. Ce mode ne doit être utilisé que lorsque l'on est certain que le client peut réessayer une requête en échec de temps en temps, et où l'avantage de la réutilisation agressive des connexions dépasse nettement les inconvénients liés aux rares échecs de connexion. - "always" : ce mode est recommandé uniquement lorsque le chemin vers le serveur est connu pour ne jamais interrompre les connexions existantes rapidement après les avoir libérées. Il permet d'envoyer la première requête d'une session vers une connexion existante. Cela peut offrir une amélioration de performance significative par rapport à la stratégie "safe" lorsque le backend est une ferme de cache, car ces composants présentent généralement un comportement constant et bénéficient du partage de connexion. Il est recommandé de maintenir le délai d'expiration "http-keep-alive" faible dans ce mode afin qu'aucune connexion morte ne reste utilisable. Dans la plupart des cas, cela entraîne les mêmes gains de performance que le mode "aggressive", mais avec des risques plus élevés. Ce mode ne doit être utilisé que lorsqu'il améliore la situation par rapport à "aggressive". Notez également que les connexions utilisant des mécanismes d’authentification frauduleux (reliés à la connexion), tels que NTLM, sont marquées comme privées si possible et jamais partagées. Cela ne s’applique toutefois pas lors de l’utilisation d’un protocole à capacité de multiplexage et d’un mode de réutilisation dont la valeur est supérieure à la stratégie par défaut « sûre », car dans ce cas, rien n’empêche la connexion d’être déjà partagée. Les règles déterminant si une connexion inactif doit être conservée ou fermée après traitement sont également régies par les paramètres "tune.pool-low-fd-ratio" (valeur par défaut : 20 %) et "tune.pool-high-fd-ratio" (valeur par défaut : 25 %). Ces valeurs correspondent au pourcentage total des descripteurs de fichiers utilisés par des connexions inactives au-delà duquel HAProxy va respectivement éviter de conserver une connexion ouverte après une réponse, et tuer activement les connexions inactives. Certains environnements utilisant un taux très élevé de connexions inactives, soit en raison d'une valeur globale "maxconn" trop faible, soit en raison d'un grand nombre de connexions HTTP/2 ou HTTP/3 sur le frontal (peu de connexions) mais de nombreuses connexions HTTP/1 sur le backend, peuvent observer un taux de réutilisation plus faible car trop peu de connexions sont conservées ouvertes. Dans ce cas, il peut être souhaitable de modifier ces seuils ou simplement d'augmenter la valeur globale de "maxconn". Dans certains cas rares, lorsque le nom d'hôte est utilisé pour distinguer les connexions TLS sortantes (par exemple, dans un proxy inverse), où la plupart des requêtes ciblent des hôtes différents, le taux de réutilisation sera très faible, et l'éviction automatique des connexions peu utilisées interviendra avant que les connexions n'aient eu la possibilité d'être réutilisées, car le mécanisme mesure continuellement le nombre moyen de connexions nécessaires pour assurer le service sans épuiser les ressources. Dans de tels cas, définir « pool-low-conn » à une valeur proche du nombre moyen attendu de connexions inactives peut aider à préserver davantage de connexions en incitant les threads à en établir eux-mêmes au lieu de tenter de choisir celles d'autres threads, réduisant ainsi la taille du pool de connexions disponibles. Si un serveur hébergé localement utilise un seul certificat (avec plusieurs noms d'hôte ou des caractères génériques) et gère plusieurs sites, il peut être plus efficace d'utiliser simplement « no-sni-auto » sur la ligne « server » afin d'éviter de réserver une connexion à un nom d'hôte unique. Cela augmente considérablement le taux de réutilisation. Certains serveurs peuvent toutefois effectuer des vérifications excessives entre le nom d'hôte et le SNI, entraînant le rejet des requêtes ultérieures ; cette option nécessite donc une validation préalable. Le comportement par défaut ("sni-auto") vise à garantir la sécurité même avec de tels serveurs. Lorsque les groupes de threads sont activés explicitement, il est important de comprendre que les connexions inactives ne sont utilisables qu'entre les threads d'un même groupe. Il peut donc arriver qu'un déséquilibre de charge entre les groupes entraîne un besoin accru de connexions inactives, réduisant ainsi le taux de réutilisation. La même solution peut alors être appliquée (augmenter la valeur globale de « maxconn » ou augmenter les ratios de pool). Voir aussi : « option http-keep-alive », « pool-conn-name », « pool-max-conn », « pool-purge-delay », « server maxconn », « sni », « thread-groups », "tune.pool-high-fd-ratio", "tune.pool-low-fd-ratio" **`http-send-name-header [
]`** ```haproxy http-send-name-header [
] ``` Ajoutez le nom du serveur à une requête. Utilisez la chaîne d'en-tête fournie par `
` Peut être utilisé dans les contextes suivants : http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| non \| oui \| oui Arguments : ```text
The header string to use to send the server name ``` L'instruction « http-send-name-header » fait que le champ d'en-tête nommé `
` est défini au nom du serveur cible au moment où la requête est sur le point d'être envoyée sur le réseau. Toutes les occurrences existantes de cet en-tête sont supprimées. Lors de réessais ou de redirigements, le champ d'en-tête est mis à jour afin de refléter toujours le serveur auquel une tentative de connexion est effectuée. Étant donné que cet en-tête est modifié très tard dans la phase de configuration de la connexion, il peut avoir des effets imprévus sur des en-têtes déjà modifiés. Par exemple, son utilisation avec des en-têtes au niveau du transport, tels que connection, content-length, transfer-encoding, etc., risque fortement de provoquer l'envoi de requêtes non valides au serveur. C'est pourquoi les noms d'en-tête suivants sont interdits : host, content-length, transfer-encoding et connection. Voir également : « server » **`id `** ```haproxy id ``` Définir un identifiant persistant pour un proxy. Peut être utilisé dans les contextes suivants : tcp, http, log Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend non \| oui \| oui \| oui Arguments : aucun Définir un identifiant persistant pour le proxy. Cet identifiant doit être unique et positif. Un identifiant non utilisé sera automatiquement attribué s'il n'est pas défini. En raison d'un comportement historique, la valeur 1 n'est pas utilisée à moins d'être explicitement définie. Par conséquent, la plus petite valeur automatiquement attribuée sera 2. Cet identifiant est actuellement retourné uniquement dans les statistiques. **`ignore-persist { if | unless } `** ```haproxy ignore-persist { if | unless } ``` Déclarer une condition pour ignorer la persistance Peut être utilisé dans les contextes suivants : tcp, http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend non \| non \| oui \| oui Par défaut, lorsque la persistance des cookies est activée, toutes les requêtes contenant le cookie sont persistantes sans condition (à condition que le serveur cible soit en fonctionnement). L'instruction « ignore-persist » permet de déclarer diverses conditions basées sur des ACL qui, lorsqu'elles sont remplies, entraînent l'ignorance de la persistance pour une requête. Cela peut être utile pour équilibrer la charge des requêtes de fichiers statiques, qui n'ont souvent pas besoin de persistance. Cela peut également servir à désactiver entièrement la persistance pour un User-Agent spécifique (par exemple, certains robots de navigation web). La persistance est ignorée lorsque la condition « if » est remplie, ou sauf si la condition « unless » est remplie. Exemple : ```text acl url_static path_beg /static /images /img /css acl url_static path_end .gif .png .jpg .css .js ignore-persist if url_static ``` Voir aussi : « force-persist », « cookie » et [section 7](/fr/docs/haproxy/acls-and-samples/) concernant l'utilisation des ACL. **`load-server-state-from-file { global | local | none }`** ```haproxy load-server-state-from-file { global | local | none } ``` Permettre le rechargement sans interruption de HAProxy Peut être utilisé dans les contextes suivants : tcp, http, log Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| non \| oui \| oui Ce directive indique à HAProxy le chemin vers un fichier dans lequel l’état des serveurs du processus précédent a été sauvegardé. Ainsi, au démarrage, avant de traiter le trafic, le nouveau processus peut appliquer les anciens états aux serveurs exactement comme s’il n’y avait pas eu de rechargement. L’objectif de la directive « load-server-state-from-file » est de préciser à HAProxy le fichier à utiliser. Pour l’instant, deux arguments permettent soit d’empêcher le chargement de l’état, soit de charger les états à partir d’un fichier contenant tous les backends et serveurs. Ce fichier d’état peut être généré en exécutant la commande « show servers state » sur le socket de statistiques et en redirigeant la sortie. Le format du fichier est versionné et très spécifique. Pour le comprendre, veuillez lire la documentation de la commande « show servers state » (chapitre 9.3 du Guide d'administration). Arguments : ```text 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 : - l'adresse IP du serveur est conservée entre les rechargements par défaut, mais son ordre peut être modifié grâce au paramètre « init-addr » du serveur. Cela signifie qu'un changement d'adresse IP effectué en ligne de commande en cours d'exécution sera conservé, et qu'une modification du résolveur local (par exemple /etc/hosts) pourra ne pas avoir d'effet si un fichier d'état est utilisé. - Le poids du serveur est appliqué à partir du processus précédent, sauf s'il a changé entre les fichiers de configuration précédent et nouveau. Exemple : Configuration minimale 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 Ensuite, on peut exécuter : ```text socat /tmp/socket - <<< "show servers state" > /tmp/server_state ``` Contenu du fichier /tmp/server_state serait le suivant : ```shell 1 # 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 ``` Exemple : Configuration minimale 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 Ensuite, on peut exécuter : ```text socat /tmp/socket - <<< "show servers state bk" > /etc/haproxy/states/bk ``` Contenu du fichier /etc/haproxy/states/bk serait le suivant : ```shell 1 # 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 ``` Voir également : « server-state-file », « server-state-file-name » et « show servers state » **`log global`** ```haproxy log global log [len ] [format ] [sample :] [profile ] [ []] no log ``` Activez la journalisation par instance des événements et du trafic. Peut être utilisé dans les contextes suivants : tcp, http, log Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| oui \| oui \| oui Préfixe : ```text 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 : ```text 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 all log arguments 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. 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@", 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@", 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. See section 12.5 about rings. - A log backend in the form "backend@", which will send log messages to the corresponding log backend responsible for sending the message to the proper server according to the backend's lb settings. A log backend is a backend section with "mode log" set (see "mode" for more information). - 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. 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. 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 parameter. 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 parameter). 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). name of the optional "log-profile" section that will be considered during the log building process to override some log options. Check out "8.3.5. Log profiles" for more info. 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. 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 ``` Il est important de garder à l’esprit que ce sont les paramètres du frontal qui déterminent ce qui doit être journalisé pour une connexion, et que, en cas de commutation de contenu, les entrées de journal du backend seront ignorées. Les connexions sont journalisées au niveau « info ». Toutefois, la déclaration de journalisation des backends définit la manière et l'emplacement où les changements d'état des serveurs seront journalisés. Le niveau « notice » sera utilisé pour indiquer un serveur qui passe à l'état actif, le niveau « warning » pour les signaux de terminaison et les arrêts définitifs du service, et le niveau « alert » pour les cas où un serveur tombe. Note : Selon RFC3164, les messages sont tronqués à 1024 octets avant d’être émis. Exemple : ```text 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 `** ```haproxy log-format ``` Spécifie la chaîne de format personnalisé à utiliser pour les journaux de trafic Peut être utilisé dans les contextes suivants : tcp, http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| oui \| oui \| non Ce directive spécifie la chaîne de format de journalisation utilisée pour tous les journaux issus du trafic passant par le frontal utilisant cette ligne. Si la directive est utilisée dans une section defaults, tous les frontaux ultérieurs utiliseront le même format de journalisation. Veuillez consulter [section 8.2.6](/fr/docs/haproxy/configuration-logging/#section-8-2-6) qui traite en détail la chaîne de format de journalisation personnalisée. Un format de journal spécifique, utilisé uniquement en cas d'erreur de connexion, peut également être défini, voir l'option « error-log-format ». La directive « log-format » remplace les directives précédentes « option tcplog », « log-format », « option httplog » et « option httpslog ». **`log-format-sd `** ```haproxy log-format-sd ``` Spécifie la chaîne de format de journal personnalisé utilisée pour produire des données structurées RFC5424 Peut être utilisé dans les contextes suivants : tcp, http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| oui \| oui \| non Cette directive spécifie la chaîne de format de journalisation structurée RFC5424 qui sera utilisée pour tous les journaux issus du trafic passant par le frontal utilisant cette ligne. Si la directive est utilisée dans une section defaults, tous les frontaux ultérieurs utiliseront le même format de journalisation. Voir la [section 8.2.6](/fr/docs/haproxy/configuration-logging/#section-8-2-6) qui traite en détail la chaîne de format de journalisation. Consultez pour en savoir plus sur la partie données structurées de RFC5424. Note : cette chaîne de format de journal sera utilisée uniquement par les journaux ayant défini le format de journalisation sur « rfc5424 ». Exemple : ```text log-format-sd [exampleSDID@1234\ bytes=\"%B\"\ status=\"%ST\"] ``` **`log-steps `** ```haproxy log-steps ``` Spécifie à quels stades du traitement des transactions les journaux doivent être générés. Peut être utilisé dans les contextes suivants : tcp, http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| oui \| oui \| non Pendant le traitement des transactions tcp/http, HAProxy peut produire des journaux à différentes étapes du traitement (par exemple : accepter, se connecter, requête, réponse, fermer). Par défaut, HAProxy émet une seule ligne de journal par transaction, une fois que toutes les composantes utilisées dans l'expression logformat ont pu être satisfaites. Cela signifie qu'en pratique, le journal est généralement émis à la fin de la transaction (après la fin de la réponse pour HTTP ou la fin de la connexion pour TCP), sauf si l'option logasap est utilisée. La directive « log-steps » permet de préciser les instants exacts auxquels les journaux seront émis, et même de générer plusieurs journaux pour une même transaction. La valeur spéciale « all » peut être utilisée pour activer toutes les origines de journalisation disponibles, permettant ainsi de suivre une transaction de l’acceptation à la fermeture. Les origines de journalisation individuelles peuvent également être spécifiées en indiquant leurs noms séparés par des virgules, afin d’activer sélectivement la production des journaux. Les origines de journalisation courantes sont : accept, connect, request, response, close. Exemple : ```text frontend myfront option httplog log-steps accept,close #only log accept and close for the txn ``` Les origines de journalisation spécifiées sous forme de « étapes de journalisation » (comme accept, close) peuvent être utilisées telles quelles dans les profils de journalisation (après la directive « on »). Combiner les « étapes de journalisation » avec les profils de journalisation est particulièrement intéressant pour exercer un contrôle fin sur les journaux générés automatiquement par HAProxy lors du traitement des transactions. Ce paramètre n’est pertinent que sur les frontaux ; il est ignoré sur les backends. Voir aussi : « log-profile » **`log-tag `** ```haproxy log-tag ``` Spécifie l'étiquette de journalisation à utiliser pour tous les journaux sortants Peut être utilisé dans les contextes suivants : tcp, http, log Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| oui \| oui \| oui Définit le champ tag dans l’en-tête syslog à cette chaîne. La valeur par défaut est le log-tag défini dans la section global, sinon le nom du programme tel qu’il a été lancé depuis la ligne de commande, qui est généralement « HAProxy ». Il peut parfois être utile de distinguer plusieurs processus s’exécutant sur le même hôte, ou de distinguer des instances clientes s’exécutant dans le même processus. Dans le backend, les journaux concernant les serveurs up/down utiliseront cette étiquette. À titre indicatif, il peut être pratique de définir un log-tag lié à un client hébergé dans une section defaults, puis d’ajouter tous les frontaux et backends de ce client, avant de commencer une autre instance cliente dans une nouvelle section defaults. Voir également la directive global « log-tag ». **`max-keep-alive-queue `** ```haproxy max-keep-alive-queue ``` Définir la taille maximale de la file d'attente du serveur pour la maintenance des connexions keep-alive Peut être utilisé dans les contextes suivants : http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| non \| oui \| oui La réutilisation de la connexion serveur via HTTP keep-alive tente de réutiliser la même connexion serveur dès que possible, mais cela peut parfois s'avérer contre-productif, par exemple si un serveur possède un grand nombre de connexions tandis que d'autres sont inactives. Cela est particulièrement vrai pour les serveurs statiques. Ce paramètre permet de définir un seuil sur le nombre de connexions en attente au-delà duquel HAProxy cesse de tenter de réutiliser le même serveur et privilégie la recherche d’un autre. La valeur par défaut, -1, signifie qu’aucune limite n’est appliquée. Une valeur nulle signifie que les requêtes keep-alive ne seront jamais mises en attente. Pour des serveurs très proches, accessibles avec une faible latence et peu sensibles à la rupture des connexions keep-alive, une valeur faible est recommandée (par exemple, un serveur local statique peut utiliser une valeur de 10 ou moins). Pour des serveurs distants souffrant d’une forte latence, des valeurs plus élevées peuvent être nécessaires afin de compenser la latence et/ou le coût associé au choix d’un autre serveur. Notez que cela n'a aucune incidence sur les réponses qui sont conservées sur le même serveur consécutivement à une réponse 401. Elles continueront à être acheminées vers le même serveur, même si elles doivent être mises en file d'attente. Voir également : « option http-server-close », « option prefer-last-server », la directive « maxconn » du serveur et la persistance des cookies. **`max-session-srv-conns `** ```haproxy max-session-srv-conns ``` Définir le nombre maximal de connexions sortantes que l'on peut maintenir en veille pour une session cliente donnée. La valeur par défaut est 5 (elle correspond exactement à MAX_SRV_LIST, définie au moment de la compilation). Peut être utilisé dans les contextes suivants : tcp, http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| oui \| oui \| non **`maxconn `** ```haproxy maxconn ``` Corriger le nombre maximum de connexions simultanées sur un frontal Peut être utilisé dans les contextes suivants : tcp, http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| oui \| oui \| non Arguments : ```text 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. ``` Si le système le permet, il peut être utile, sur de grands sites, d’augmenter fortement cette limite afin que HAProxy gère les files d’attente de connexions, plutôt que de laisser les clients avec des tentatives de connexion non répondues. Cette valeur ne doit pas dépasser maxconn global. Gardez à l’esprit qu’une connexion consomme environ 33 ko de mémoire RAM, incluant deux tampons de taille tune.bufsize (16 ko par défaut) ainsi que d’autres données. Cela signifie qu’un système moyen doté de 1 Go de mémoire vive peut supporter environ 20 000 à 25 000 connexions simultanées, si correctement configuré. En outre, lorsque `` est défini avec des valeurs élevées, il se peut que les serveurs ne soient pas dimensionnés pour supporter de telles charges ; il est donc généralement conseillé de leur attribuer des limites de connexion raisonnables. Lorsque cette valeur est définie à zéro, ce qui est la valeur par défaut, la valeur globale « maxconn » est utilisée. Voir également : « server », section « global » et son paramètre « maxconn », « fullconn » **`mode { tcp|http|log|spop }`** ```haproxy mode { tcp|http|log|spop } ``` Définir le mode d'exécution ou le protocole de l'instance. Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend. oui \| oui \| oui \| oui Arguments : ```text 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. haterm The frontend will work in haterm HTTP benchmark mode. This is not supported by backends. See doc/haterm.txt for details. log When used in a backend section, it will turn the backend into a log backend. Such backend can be used as a log destination for any "log" directive by using the "backend@" syntax. Log messages will be distributed to the servers from the backend according to the lb settings which can be configured using the "balance" keyword. Log backends support UDP servers by prefixing the server's address with the "udp@" prefix. Common backend and server features are supported, but not TCP or HTTP specific ones. spop When used in a backend section, it will turn the backend into a spop backend. This mode is mandatory if the backend contains SPOA servers, but when mode is tcp, it will automatically be converted to mode spop if such servers are detected. ``` Lors de la commutation de contenu, il est obligatoire que le frontal et le backend soient dans le même mode (généralement HTTP), faute de quoi la configuration sera refusée. Exemple : ```text defaults http_instances mode http ``` **`monitor fail { if | unless } `** ```haproxy monitor fail { if | unless } ``` Ajoutez une condition pour signaler un échec à une requête HTTP de surveillance. Peut être utilisé dans les contextes suivants : http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend non \| oui \| oui \| non Arguments : ```text if 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 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. ``` Cette instruction ajoute une condition qui peut forcer la réponse à une requête de surveillance à signaler une erreur. Par défaut, lorsque un composant externe interroge l'URI dédié à la surveillance, une réponse 200 est renvoyée. Lorsqu'une des conditions ci-dessus est remplie, HAProxy renvoie 503 au lieu de 200. Cela est très utile pour signaler une panne du site à un composant externe qui pourrait baser ses annonces de routage entre plusieurs sites sur la disponibilité signalée par HAProxy. Dans ce cas, on s'appuierait sur une ACL impliquant le critère « nbsrv ». Notez que « monitor fail » ne fonctionne qu'en mode HTTP. Les deux messages d'état peuvent être ajustés à l'aide de « errorfile » ou « errorloc » si nécessaire. Exemple : ```text 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 ``` Voir aussi : « monitor-uri », « errorfile », « errorloc » **`monitor-uri `** ```haproxy monitor-uri ``` Intercepte une URI utilisée par les requêtes de surveillance des composants externes Peut être utilisé dans les contextes suivants : http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| oui \| oui \| non Arguments : ```text is the exact URI which we want to intercept to return HAProxy's health status instead of forwarding the request. ``` Lorsqu'une requête HTTP faisant référence à `` sera reçue sur un frontal, HAProxy ne la transmettra ni ne la journalisera, mais renverra soit "HTTP/1.0 200 OK" soit "HTTP/1.0 503 Service unavailable", selon les conditions d'échec définies avec "monitor fail". Cela suffit généralement à toute sonde HTTP frontale pour détecter que le service est actif et en fonctionnement, sans transmettre la requête à un serveur backend. Notez que la méthode HTTP, la version et tous les en-têtes sont ignorés, mais la requête doit être au moins valide au niveau HTTP. Ce mot-clé ne peut être utilisé qu'avec un frontal en mode HTTP. Les requêtes de surveillance sont traitées très tôt, juste après l'analyse de la requête, et même avant toute directive « http-request ». Seules les règles tcp-request sont appliquées avant celles-ci. Elles ne peuvent pas non plus être journalisées, ce qui est le comportement attendu. Une seule URI peut être configurée pour la surveillance ; lorsque plusieurs directives « monitor-uri » sont présentes, celle qui est définie en dernier détermine l'URI utilisée. Elles ne sont utilisées que pour signaler l'état de santé de HAProxy à un composant supérieur, rien de plus. Toutefois, il est possible d'ajouter un nombre quelconque de conditions à l'aide de « monitor fail » et des ACLs afin d'ajuster le résultat selon n'importe quelle vérification imaginable (le plus souvent, le nombre de serveurs disponibles dans un backend). Note : si `` commence par une barre oblique ('/'), la correspondance est effectuée sur le chemin de la requête plutôt que sur l'URI de la requête. Il s'agit d'un contournement permettant aux requêtes HTTP/2 de correspondre à l'URI de surveillance. En effet, dans HTTP/2, les clients sont encouragés à n'envoyer que des URIs absolus. Exemple : ```shell # Use /haproxy_test to report HAProxy's status frontend www mode http monitor-uri /haproxy_test ``` Voir aussi : « monitor fail » **`option abortonclose`** ```haproxy option abortonclose no option abortonclose ``` Activer ou désactiver l'abandon anticipé du traitement non démarré lorsque le client se ferme Peut être utilisé dans les contextes suivants : tcp, http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| oui \| oui \| oui Arguments : aucun La prise en charge des connexions TCP permet la fermeture indépendante dans chaque direction, et une connexion dont une seule direction est fermée est souvent qualifiée de « demi-fermée ». À l’origine, lorsque l’écosystème HTTP était principalement basé sur le mode « fermeture », avec une seule requête et une seule réponse par connexion avant la fermeture, il était fréquent de voir des clients scriptés envoyer leur requête, fermer le côté envoi, attendre la réponse, recevoir l’indication de fermeture et terminer ainsi la connexion. Mais avec l’arrivée du keep-alive et de protocoles plus avancés, cette pratique a pratiquement disparu, et les seuls cas où un client ferme la connexion avant de recevoir sa réponse sont essentiellement ceux où l’utilisateur souhaite interrompre un transfert, ou lorsque le délai d'expiration est atteint et que la connexion est fermée. Ces deux situations (demi-fermeture vs interruption) sont indiscernables du côté serveur (ici, l’écouteur HAProxy). Cela pose problème, car laisser la connexion ouverte et continuer à traiter une requête lorsque le client interrompt peut consommer beaucoup de ressources, notamment si la fermeture résulte d’un utilisateur cliquant sur le bouton « actualiser », ce qui signifie que de nouvelles requêtes sont en file d’attente sans que les précédentes soient interrompues. Inversement, interrompre systématiquement en cas de situation de demi-fermeture briserait un certain nombre d’applications TCP, ainsi que certaines applications HTTP sur les réseaux internes interagissant avec des agents hérités. L'option « abortonclose » permet de choisir le comportement souhaité : - lorsqu'elle est présente dans un frontend, elle empêche le traitement des échanges TLS en attente sur une connexion demi-fermée. Cela peut résulter d'un utilisateur qui clique sur « actualiser » pendant une requête HTTPS sous une charge élevée, par exemple lors d'un basculement VRRP entre un nœud HAProxy actif et son sauvegarde : tous les clients se reconnectent en même temps au nouveau nœud, et chacun doit effectuer une main-handshake TLS coûteuse et complète. Si cette opération prend plus de quelques secondes, il est probable que certains utilisateurs abandonnent, et il est inutile de gaspiller des cycles CPU sur leurs échanges. Étant donné le coût CPU des échanges TLS, il est recommandé de laisser cette option activée sur les frontaux exposés à Internet. C’est le comportement par défaut pour les connexions TLS entrantes. - quand présent dans un backend, il provoque l'abandon d'une requête qui n'a pas encore été envoyée au serveur (c'est-à-dire lorsqu'elle est en attente dans la file ou lors de la tentative de connexion). Si la requête est déjà en cours de traitement par un serveur, la connexion vers ce serveur est elle-même passée en demi-fermeture pour indiquer la même condition au serveur, qui décidera alors de la suite à donner. Ceci est la valeur par défaut pour les backends en mode HTTP. Il est recommandé d’activer cette option sur les points de terminaison TLS exposés à Internet et sur les services HTTP, et de la désactiver pour les services TCP purs ainsi que pour les environnements hérités non exposés. Elle est activée par défaut dans les backends HTTP et peut être désactivée de force en préfixant le mot-clé par « no », soit dans la section backend elle-même, soit dans la section « defaults » dont elle hérite. Elle est également activée par défaut pour les écouteurs TLS et peut être désactivée de force en spécifiant « no option abortonclose » dans le frontend ou dans la section « defaults » dont il hérite. Si cette option a été activée dans une section « defaults », elle peut être désactivée dans une instance spécifique en préfixant son nom par le mot-clé « no ». Voir également : « délai d'expiration de file d'attente » et les paramètres serveur « maxconn » et « maxqueue » **`option accept-invalid-http-request (deprecated)`** ```haproxy option accept-invalid-http-request (deprecated) no option accept-invalid-http-request (deprecated) ``` Activer ou désactiver la relaxation de l'analyse des requêtes HTTP Le mot-clé « accept-invalid-http-request » est obsolète ; utilisez plutôt « option accept-unsafe-violations-in-http-request ». **`option accept-invalid-http-response (deprecated)`** ```haproxy option accept-invalid-http-response (deprecated) no option accept-invalid-http-response (deprecated) ``` Activer ou désactiver la relaxation de l'analyse des réponses HTTP Le mot-clé « accept-invalid-http-response » est obsolète ; utilisez plutôt « option accept-unsafe-violations-in-http-response ». **`option accept-unsafe-violations-in-http-request`** ```haproxy option accept-unsafe-violations-in-http-request no option accept-unsafe-violations-in-http-request ``` Activer ou désactiver la relaxation de l'analyse des requêtes HTTP Peut être utilisé dans les contextes suivants : http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| oui \| oui \| non Arguments : aucun Par défaut, HAProxy respecte les différentes RFC HTTP en matière d’analyse des messages. Cela signifie que l’analyse des messages est assez stricte et provoque une erreur renvoyée au client pour les messages malformés. Ce comportement est souhaité, car de tels messages malformés sont essentiellement utilisés pour construire des attaques exploitant des faiblesses du serveur ou contourner les filtres de sécurité. Parfois, un navigateur défectueux ne respecte pas ces RFCs pour une raison quelconque (configuration, implémentation...) et le problème n’est pas immédiatement corrigé. Dans un tel cas, il est possible de relâcher le parseur HAProxy pour accepter certaines requêtes non valides en spécifiant cette option. La plupart des règles concernent l’analyse H1 pour des raisons historiques. Les versions plus récentes de HTTP ont tendance à être plus propres et les applications suivent plus strictement ces protocoles. Lorsque cette option est définie, les règles suivantes s'appliquent : * Dans H1 uniquement, les caractères non valides, y compris le caractère NULL, dans le nom d’en-tête ne seront pas rejetés ; toutefois, l’en-tête sera supprimé. * Dans H1 uniquement, un caractère NULL dans une valeur d’en-tête sera accepté ; * Dans H1 uniquement, les caractères dont la valeur est supérieure à 127 dans l'URI seront acceptés. La liste des caractères autorisés dans un URI est strictement définie par RFC3986. Les caractères 0 à 31, 32 (espace), 34 (« " »), 60 (« < »), 62 (« > »), 92 (« \ »), 94 (« ^ »), 96 (« ` »), 123 (« { »), 124 (« | »), 125 (« } »), 127 (suppression) et tous ceux dont la valeur est supérieure ne sont normalement pas autorisés. Dans H1, tous les caractères dont la valeur est comprise entre 0 et 32 ainsi que 127 seront systématiquement bloqués. Tous les caractères dont la valeur est supérieure à 127 (exclu) seront également bloqués, sauf lorsque cette option est activée. Les autres caractères (33 à 126) ne seront pas vérifiés du tout. * Dans H1 et H2, les URL contenant des références de fragment ('#' après le chemin) seront acceptées ; * En H1 uniquement, aucune vérification n'est effectuée sur l'autorité pour les requêtes CONNECT ; * Dans H1 uniquement, aucune vérification ne sera effectuée contre la valeur de l'en-tête authority et de l'en-tête Host. * Dans H1 uniquement, les contrôles de la version HTTP seront assouplis. Les requêtes GET HTTP/0.9 pourront ainsi être transmises sans version spécifiée, tout comme les requêtes utilisant d'autres noms de protocole, par exemple RTSP, ou plusieurs chiffres pour les versions majeure et mineure. * Dans H1 uniquement, les requêtes WebSocket (RFC6455) ne présentant pas de champ d'en-tête "Sec-Websocket-Key" valide seront acceptées. Cette option ne doit jamais être activée par défaut, car elle masque les bugs applicatifs et expose des failles de sécurité. Elle ne doit être déployée qu’après confirmation d’un problème. Lorsque cette option est activée, les requêtes H1 invalides mais acceptées sont capturées afin de permettre une analyse ultérieure à l’aide de la requête « show errors » sur le socket de statistiques UNIX. Cette action permet également de confirmer que le problème a été résolu. Si cette option a été activée dans une section « defaults », elle peut être désactivée dans une instance spécifique en préfixant son nom par le mot-clé « no ». Voir également : « option accept-unsafe-violations-in-http-response » et « show errors » sur la socket de statistiques. **`option accept-unsafe-violations-in-http-response`** ```haproxy option accept-unsafe-violations-in-http-response no option accept-unsafe-violations-in-http-response ``` Activer ou désactiver la relaxation de l'analyse des réponses HTTP Peut être utilisé dans les contextes suivants : http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| non \| oui \| oui Arguments : aucun De même que « option accept-unsafe-violations-in-http-request », cette option peut être utilisée pour assouplir les règles de parsing des réponses HTTP. Elle ne doit être activée que pour des serveurs hérités de confiance, afin d'accepter certaines réponses non conformes. La plupart de ces règles concernent le parsing H1 pour des raisons historiques. Les versions plus récentes de HTTP ont tendance à être plus rigoureuses, et les applications suivent désormais ces protocoles de manière plus stricte. Lorsque cette option est définie, les règles suivantes s'appliquent : * Dans H1 uniquement, les codes d’état de plus de 3 chiffres mais dont la valeur tient dans 16 bits ne sont pas rejetés. * Dans H1 uniquement, les caractères non valides, y compris le caractère NULL, dans le nom d’en-tête ne seront pas rejetés ; toutefois, l’en-tête sera supprimé. * Dans H1 uniquement, un caractère NULL dans une valeur d’en-tête sera accepté ; * Dans H1 uniquement, les valeurs vides ou plusieurs occurrences de valeurs « chunked » pour l’en-tête Transfer-Encoding seront acceptées ; * Dans H1 uniquement, aucune vérification ne sera effectuée contre la valeur de l'en-tête authority et de l'en-tête Host. * Dans H1 uniquement, les tests sur la version HTTP seront assouplis. Cela permettra des noms de protocole différents (par exemple RTSP) ainsi que des chiffres multiples pour les versions majeure et mineure. * Dans H1 uniquement, les réponses WebSocket (RFC6455) qui ne présentent pas un champ d'en-tête "Sec-Websocket-Accept" valide seront acceptées. Cette option ne doit jamais être activée par défaut, car elle masque les bugs applicatifs et expose des failles de sécurité. Elle ne doit être déployée qu’après confirmation d’un problème. Lorsque cette option est activée, les noms d’en-tête erronés seront toujours acceptés dans les réponses, mais la réponse complète sera capturée afin de permettre une analyse ultérieure à l’aide de la requête « show errors » sur le socket de statistiques UNIX. Cette action permet également de confirmer que le problème a été résolu. Si cette option a été activée dans une section « defaults », elle peut être désactivée dans une instance spécifique en préfixant son nom par le mot-clé « no ». Voir également : « option accept-unsafe-violations-in-http-request » et « show errors » sur la socket de statistiques. **`option allbackups`** ```haproxy option allbackups no option allbackups ``` Utilisez soit tous les serveurs de sauvegarde en même temps, soit uniquement le premier. Peut être utilisé dans les contextes suivants : tcp, http, log Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| non \| oui \| oui Arguments : aucun Par défaut, le premier serveur de secours opérationnel reçoit tout le trafic lorsque tous les serveurs normaux sont hors service. Parfois, il peut être préférable d'utiliser plusieurs serveurs de secours simultanément, car un seul ne serait pas suffisant. Lorsque l'option allbackups est activée, la répartition de charge est effectuée entre tous les serveurs de secours lorsque tous les serveurs normaux sont indisponibles. Le même algorithme de répartition de charge est utilisé et les poids des serveurs sont respectés. Ainsi, il n'y a plus d'ordre de priorité entre les serveurs de secours. Cette option est principalement utilisée avec des fermes de serveurs statiques destinées à renvoyer une page « désolé » lorsque l'application est complètement hors ligne. Si cette option a été activée dans une section « defaults », elle peut être désactivée dans une instance spécifique en préfixant son nom par le mot-clé « no ». **`option checkcache`** ```haproxy option checkcache no option checkcache ``` Analysez toutes les réponses des serveurs et bloquez les réponses comportant des cookies pouvant être mis en cache Peut être utilisé dans les contextes suivants : http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| non \| oui \| oui Arguments : aucun Certains frameworks de haut niveau définissent des cookies d'application partout et ne permettent pas toujours au développeur un contrôle suffisant sur la manière dont les réponses doivent être mises en cache. Lorsqu'un cookie de session est renvoyé pour un objet pouvant être mis en cache, le risque de croisement ou de vol de session entre utilisateurs empruntant les mêmes caches est élevé. Dans certaines situations, il est préférable de bloquer la réponse que de laisser des informations sensibles de session circuler librement. L'option « checkcache » active une inspection approfondie de toutes les réponses des serveurs afin de garantir une conformité stricte à la spécification HTTP en matière de cacheabilité. Elle vérifie soigneusement les en-têtes « Cache-control », « Pragma » et « Set-cookie » dans la réponse du serveur afin de détecter tout risque de mise en cache d'un cookie par un proxy côté client. Lorsque cette option est activée, les seules réponses pouvant être transmises au client sont : - toutes celles qui ne contiennent pas d’en-tête « Set-Cookie » ; - toutes celles dont le code de retour est différent de 200, 203, 204, 206, 300, 301, 404, 405, 410, 414, 501, à condition que le serveur n’ait pas défini un champ d’en-tête « Cache-control: public » ; - toutes celles résultant d’une requête utilisant une méthode autre que GET, HEAD, OPTIONS, TRACE, à condition que le serveur n’ait pas défini un champ d’en-tête « Cache-Control: public » ; - celles comportant un en-tête « Pragma: no-cache » ; - celles comportant un en-tête « Cache-control: private » ; - celles comportant un en-tête « Cache-control: no-store » ; - celles comportant un en-tête « Cache-control: max-age=0 » ; - celles comportant un en-tête « Cache-control: s-maxage=0 » ; - celles comportant un en-tête « Cache-control: no-cache » ; - celles comportant un en-tête « Cache-control: no-cache="set-cookie" » ; - celles comportant un en-tête « Cache-control: no-cache="set-cookie, » (permettant d’autres champs après « set-cookie »). Si une réponse ne respecte pas ces exigences, elle sera bloquée comme si elle provenait d'une règle « http-response deny », avec une réponse « HTTP 502 bad gateway ». L'état de session affiche « PH-- », ce qui signifie que le proxy a bloqué la réponse durant le traitement des en-têtes. En outre, une alerte sera envoyée dans les journaux afin d'informer les administrateurs qu'une correction est nécessaire. En raison de l'impact élevé sur l'application, celle-ci doit être testée de manière approfondie avec l'option activée avant de passer en production. Il est également recommandé d'activer toujours cette option lors des tests, même si elle n'est pas utilisée en production, car elle signale les comportements potentiellement dangereux de l'application. Si cette option a été activée dans une section « defaults », elle peut être désactivée dans une instance spécifique en préfixant son nom par le mot-clé « no ». **`option clitcpka`** ```haproxy option clitcpka no option clitcpka ``` Activer ou désactiver l'envoi de paquets TCP keepalive du côté client Peut être utilisé dans les contextes suivants : tcp, http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| oui \| oui \| non Arguments : aucun Lorsqu’un pare-feu ou tout composant sensible à la session se trouve entre un client et un serveur, et que le protocole implique des sessions très longues avec des périodes d’inactivité prolongées (par exemple, les bureaux distants), il existe un risque que l’un des composants intermédiaires décide d’expirer une session restée inactif trop longtemps. Activer les keep-alives TCP au niveau du socket fait que le système envoie régulièrement des paquets à l'autre extrémité de la connexion, la maintenant active. Le délai entre les sondes de keep-alive est contrôlé uniquement par le système et dépend à la fois du système d'exploitation et de ses paramètres de réglage. Il est important de comprendre que les paquets keep-alive ne sont ni émis ni reçus au niveau de l’application. Seuls les piles réseau les perçoivent. Pour cette raison, même si l’une des extrémités du proxy utilise déjà des keep-alive pour maintenir sa connexion active, ces paquets keep-alive ne seront pas transférés à l’autre extrémité du proxy. Veuillez noter que cela n’a rien à voir avec le keep-alive HTTP. L’option « clitcpka » active l’envoi de sondes TCP keep-alive côté client d’une connexion, ce qui devrait aider à détecter les expiration de session entre HAProxy et un client. Si cette option a été activée dans une section « defaults », elle peut être désactivée dans une instance spécifique en préfixant son nom par le mot-clé « no ». Voir aussi : « option srvtcpka », « option tcpka » **`option contstats`** ```haproxy option contstats ``` Activer la mise à jour continue des statistiques de trafic Peut être utilisé dans les contextes suivants : tcp, http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| oui \| oui \| non Arguments : aucun Par défaut, les compteurs utilisés pour le calcul des statistiques ne sont incrémentés qu’au moment où un flux se termine. Cela fonctionne assez bien lors de la mise à disposition d’objets de petite taille, mais avec des objets volumineux (par exemple des images ou archives importantes) ou lors du streaming A/V, le graphique généré à partir des compteurs HAProxy ressemble à un hérisson. Lorsque cette option est activée, les compteurs sont incrémentés fréquemment tout au long du flux, généralement toutes les 5 secondes, ce qui est souvent suffisant pour produire des graphiques nets. Le recalcule touche directement un chemin critique, aussi n’est-il pas activé par défaut, car il peut entraîner de nombreux réveils pour un très grand nombre de sessions et provoquer une légère baisse de performance. **`option disable-h2-upgrade`** ```haproxy option disable-h2-upgrade no option disable-h2-upgrade ``` Active ou désactive la mise à jour implicite HTTP/2 à partir d'une connexion client HTTP/1.x. Peut être utilisé dans les contextes suivants : http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| oui \| oui \| non Arguments : aucun Par défaut, HAProxy est capable de mettre implicitement à jour une connexion client HTTP/1.x en connexion HTTP/2 si la première requête qu’il reçoit sur une connexion HTTP donnée correspond à l’introduction de connexion HTTP/2 (c’est-à-dire la chaîne « PRI \* HTTP/2.0\r\n\r\nSM\r\n\r\n »). Ainsi, il est possible de prendre en charge des clients HTTP/1.x et HTTP/2 sur des connexions non chiffrées. Cette option doit être utilisée pour désactiver la mise à jour implicite. Notez que cette mise à jour implicite n’est prise en charge que pour les proxies HTTP, ce qui s’applique également à cette option. Notez également qu’il est possible de forcer le HTTP/2 sur des connexions claires en spécifiant « proto h2 » dans la directive bind. Enfin, cette option s’applique à toutes les directives bind. Pour désactiver les mises à jour implicites de HTTP/2 pour une directive bind spécifique, il est possible d’utiliser « proto h1 ». Si cette option a été activée dans une section « defaults », elle peut être désactivée dans une instance spécifique en préfixant son nom par le mot-clé « no ». **`option dontlog-normal`** ```haproxy option dontlog-normal no option dontlog-normal ``` Activer ou désactiver la journalisation des connexions normales et réussies Peut être utilisé dans les contextes suivants : tcp, http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| oui \| oui \| non Arguments : aucun Il existe des sites très volumineux traitant plusieurs milliers de connexions par seconde, pour lesquels la journalisation constitue un problème majeur. Certains sont même contraints de désactiver les journaux et ne peuvent pas déboguer les problèmes en production. L’activation de cette option garantit que les connexions normales, celles qui ne rencontrent aucune erreur, aucun délai d'expiration, aucune tentative de reconnexion ni aucun réacheminement, ne seront pas journalisées. Cela libère de l’espace disque pour les anomalies. En mode HTTP, le code d’état de la réponse est vérifié et les codes de retour 5xx seront toujours journalisés. Il est fortement déconseillé d'utiliser cette option, car la plupart du temps, la clé des problèmes complexes se trouve dans les journaux normaux, qui ne seront pas journalisés ici. Si vous devez séparer les journaux, utilisez plutôt l'option « log-separate-errors ». Voir aussi : « log », « dontlognull », « log-separate-errors » et [section 8](/fr/docs/haproxy/configuration-logging/) concernant la journalisation. **`option dontlognull`** ```haproxy option dontlognull no option dontlognull ``` Activer ou désactiver la journalisation des connexions nulles Peut être utilisé dans les contextes suivants : tcp, http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| oui \| oui \| non Arguments : aucun Dans certains environnements, des composants se connectent régulièrement à divers systèmes afin de vérifier qu’ils sont toujours actifs. Cela peut provenir d’un autre répartiteur de charge ou de systèmes de surveillance. Par défaut, même une simple vérification de port ou un balayage génère une entrée dans les journaux. Si ces connexions polluent trop les journaux, il est possible d’activer l’option « dontlognull » pour indiquer qu’une connexion sur laquelle aucune donnée n’a été transférée ne sera pas journalisée, ce qui correspond généralement à ces sondes. Notez que les erreurs seront toutefois renvoyées au client et prises en compte dans les statistiques. Si ce n’est pas le comportement souhaité, l’option « http-ignore-probes » peut être utilisée à la place. Il est généralement recommandé de ne pas utiliser cette option dans des environnements non contrôlés (par exemple, Internet), faute de quoi les scans et autres activités malveillantes ne seraient pas journalisés. Si cette option a été activée dans une section « defaults », elle peut être désactivée dans une instance spécifique en préfixant son nom par le mot-clé « no ». Voir aussi : « log », « http-ignore-probes », « monitor-uri », et la section [8](/fr/docs/haproxy/configuration-logging/) concernant la journalisation. **`option external-check`** ```haproxy option external-check ``` Utilisez des processus externes pour les contrôles d'état des serveurs Peut être utilisé dans les contextes suivants : tcp, http, log Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| non \| oui \| oui Il est possible de tester l'état de santé d'un serveur à l'aide d'une commande externe. Cela est réalisé en exécutant l'exécutable défini par la directive « external-check command ». Exige que l'option globale « external-check » soit définie. Voir aussi : « external-check », « external-check command », « external-check path » **`option forwarded [ proto ]`** ```haproxy option forwarded [ proto ] [ host | host-expr ] [ by | by-expr ] [ by_port | by_port-expr ] [ for | for-expr ] [ for_port | for_port-expr ] no option forwarded ``` Activer l'insertion de l'en-tête forwarded défini par le RFC 7239 dans les requêtes envoyées aux serveurs Peut être utilisé dans les contextes suivants : http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| non \| oui \| oui Arguments : ```text optional argument to specify a custom sample expression those result will be used as 'host' parameter value optional argument to specify a custom sample expression those result will be used as 'by' parameter nodename value optional argument to specify a custom sample expression those result will be used as 'for' parameter nodename value optional argument to specify a custom sample expression those result will be used as 'by' parameter nodeport value optional argument to specify a custom sample expression those result will be used as 'for' parameter nodeport value ``` Étant donné que HAProxy fonctionne en mode proxy inverse, les serveurs perdent une partie du contexte de la requête (origine de la requête : adresse IP du client, protocole utilisé...). Une manière courante de contourner cette limitation consiste à utiliser les en-têtes bien connus x-forward-for et x-forward-\* pour exposer une partie de ce contexte au niveau du servers/applications. sous-jacent. Bien que cette approche fonctionnait autrefois et soit largement déployée, elle n'est pas officiellement prise en charge par l'IETF et peut être à l'origine de problèmes d'interopérabilité ainsi que de failles de sécurité. Pour résoudre ce problème, une nouvelle extension HTTP a été définie par l'IETF : l'en-tête forwarded (RFC7239). Plus d'informations ici : L'utilisation de cet en-tête unique permet de transmettre de nombreuses informations au sein du même en-tête, et surtout, résout le problème de chaînage de proxy. (La RFC autorise plusieurs proxies en chaîne à ajouter leurs propres valeurs à un en-tête déjà existant). Cette option peut être spécifiée dans les sections defaults, listen ou backend, mais sera ignorée dans les sections frontend. Définir l'option forwarded sans argument entraîne l'utilisation du comportement implicite par défaut. Ce comportement par défaut active le paramètre proto et injecte l'adresse IP du client d'origine. La configuration équivalente explicit/manual serait : ```text option forwarded proto for ``` Le mot-clé « by » est utilisé pour activer le paramètre « by » (« nodename ») dans l’en-tête transféré. Il permet d’insérer des informations sur le proxy de la requête. La valeur de « by » sera définie sur l’adresse IP du proxy (adresse de destination) si disponible. Sinon (par exemple, avec un écouteur UNIX), « by » sera définie sur « unknown ». Le mot-clé « by-expr » est utilisé pour activer le paramètre « by » ("nodename") dans l’en-tête transféré. Il permet d’incorporer des informations sur le proxy de la requête. La valeur de « by » sera définie par le résultat de l’expression d’échantillonnage ``, si elle est valide, sinon elle sera définie à « unknown ». Le mot-clé « for » est utilisé pour activer le paramètre « for » (« nodename ») dans l’en-tête transféré. Il permet d’incorporer des informations sur le client de la requête. La valeur de « for » sera définie sur l’adresse IP du client (adresse source) si disponible. Sinon (par exemple, avec un écouteur UNIX), « for » sera définie sur « unknown ». Le mot-clé « for-expr » est utilisé pour activer le paramètre « for » (« nodename ») dans l’en-tête transféré. Il permet d’insérer des informations sur le client de la requête. La valeur de « for » sera définie sur le résultat de l’expression d’échantillonnage ``, si elle est valide, sinon elle sera définie sur « unknown ». Le mot-clé 'by_port' est utilisé pour fournir les informations « nodeport » au paramètre « by ». 'by_port' exige que « by » ou « by-expr » soit défini, sinon il sera ignoré. Le champ « nodeport » sera défini sur le port du proxy (destination) s'il est disponible, sinon il sera ignoré. Le mot-clé 'by_port-expr' est utilisé pour fournir les informations « nodeport » au paramètre « by ». 'by_port-expr' exige que « by » ou « by-expr » soit défini, sinon il sera ignoré. Le champ « nodeport » sera défini avec le résultat de l'expression d'échantillonnage ``, si celle-ci est valide, sinon il sera ignoré. Le mot-clé 'for_port' est utilisé pour fournir les informations « nodeport » au paramètre « for ». 'for_port' exige que « for » ou « for-expr » soit défini, sinon il sera ignoré. Le « nodeport » sera défini sur le port client (source) s'il est disponible, sinon il sera ignoré. Le mot-clé 'for_port-expr' est utilisé pour fournir les informations « nodeport » au paramètre « for ». 'for_port-expr' exige que « for » ou « for-expr » soit défini, sinon il sera ignoré. Le champ « nodeport » sera défini avec le résultat de l'expression d'échantillonnage ``, si celle-ci est valide, sinon il sera ignoré. Exemples : ```shell # Those servers want the ip address and protocol of the client request # Resulting header would look like this: # forwarded: proto=http;for=127.0.0.1 backend www_default mode http option forwarded #equivalent to: option forwarded proto for # Those servers want the requested host and hashed client ip address # as well as client source port (you should use seed for xxh32 if ensuring # ip privacy is a concern) # Resulting header would look like this: # forwarded: host="haproxy.org";for="_000000007F2F367E:60138" backend www_host mode http option forwarded host for-expr src,xxh32,hex for_port # Those servers want custom data in host, for and by parameters # Resulting header would look like this: # forwarded: host="host.com";by=_haproxy;for="[::1]:10" backend www_custom mode http option forwarded host-expr str(host.com) by-expr str(_haproxy) for for_port-expr int(10) # Those servers want random 'for' obfuscated identifiers for request # tracing purposes while protecting sensitive IP information # Resulting header would look like this: # forwarded: for=_000000002B1F4D63 backend www_for_hide mode http option forwarded for-expr rand,hex ``` Voir aussi : « option forwardfor », « option originalto » **`option forwardfor [ except ] [ header ] [ if-none ]`** ```haproxy option forwardfor [ except ] [ header ] [ if-none ] ``` Activer l'insertion de l'en-tête X-Forwarded-For dans les requêtes envoyées aux serveurs Peut être utilisé dans les contextes suivants : http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| oui \| oui \| oui Arguments : ```text is an optional argument used to disable this option for sources matching an optional argument to specify a different "X-Forwarded-For" header name. ``` Étant donné que HAProxy fonctionne en mode proxy inverse, les serveurs voient son adresse IP comme celle du client. Cela peut parfois être problématique lorsque l’adresse IP du client est attendue dans les journaux du serveur. Pour résoudre ce problème, HAProxy peut ajouter l’en-tête HTTP bien connu « X-Forwarded-For » à toutes les requêtes envoyées au serveur. Cet en-tête contient une valeur représentant l’adresse IP du client. Étant donné que cet en-tête est toujours ajouté à la fin de la liste d’en-têtes existante, le serveur doit être configuré pour ne jamais utiliser que la dernière occurrence de cet en-tête. Consultez le manuel du serveur pour savoir comment activer l’utilisation de cet en-tête standard. Notez que seule la dernière occurrence de l’en-tête doit être utilisée, car il est effectivement possible que le client ait déjà fourni cet en-tête. Le mot-clé « header » peut être utilisé pour spécifier un nom d’en-tête différent afin de remplacer le nom par défaut « X-Forwarded-For ». Cela peut être utile lorsque vous avez déjà un en-tête « X-Forwarded-For » provenant d'une autre application (par exemple, stunnel) et que vous devez le préserver. De même, si votre backend ne utilise pas l’en-tête « X-Forwarded-For » et nécessite un autre en-tête (par exemple, les serveurs Web Zeus exigent « X-Cluster-Client-IP »). Parfois, une même instance HAProxy peut être partagée entre un accès direct depuis un client et un accès via un proxy inverse (par exemple, lorsqu’un proxy inverse SSL est utilisé pour déchiffrer le trafic HTTPS). Il est possible de désactiver l’ajout de l’en-tête pour une adresse ou un réseau connu en ajoutant le mot-clé « except » suivi de l’adresse réseau. Dans ce cas, toute adresse IP source correspondant au réseau ne déclenchera pas l’ajout de cet en-tête. Les utilisations les plus courantes concernent les réseaux privés ou 127.0.0.1. Les versions IPv4 et IPv6 sont toutes deux prises en charge. Autrement, le mot-clé « if-none » indique que l’en-tête ne sera ajouté que s’il est absent. Cela ne doit être utilisé que dans un environnement entièrement fiable, car cela pourrait entraîner une faille de sécurité si les en-têtes parvenant à HAProxy sont contrôlés par l’utilisateur final. Cette option peut être spécifiée soit dans le frontal, soit dans le backend. Si au moins l’un d’eux l’utilise, l’en-tête sera ajouté. Notez que le paramètre d’en-tête défini dans le backend a priorité sur celui défini dans le frontal si les deux sont configurés. Dans le cas de l’argument « if-none », si au moins l’un du frontal ou du backend ne le précise pas, il impose que l’ajout soit obligatoire, et donc l’emporte. Exemple : ```shell # 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 ``` Voir également : « option httpclose », « option http-server-close », « option http-keep-alive » **`option h1-case-adjust-bogus-client`** ```haproxy option h1-case-adjust-bogus-client no option h1-case-adjust-bogus-client ``` Activer ou désactiver le réglage de la casse des en-têtes HTTP/1 envoyés aux clients malveillants Peut être utilisé dans les contextes suivants : http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| oui \| oui \| non Arguments : aucun Il n’existe pas de cas standard pour les noms d’en-têtes, car, comme indiqué dans RFC7230, ils sont insensibles à la casse. Les applications doivent donc les traiter de manière insensible à la casse. Toutefois, certaines applications incorrectes violent les normes et s’appuient erronément sur les cas les plus couramment utilisés par les navigateurs. Ce problème devient critique avec HTTP/2 car tous les noms d’en-têtes doivent être échangés en minuscules, et HAProxy adopte la même convention. Tous les noms d’en-têtes sont envoyés en minuscules aux clients et aux serveurs, indépendamment de la version HTTP. Lorsqu’HAProxy reçoit une réponse HTTP/1, ses noms d’en-têtes sont convertis en minuscules, manipulés et envoyés ainsi aux clients. Si un client est connu pour violer les normes HTTP et échouer à traiter une réponse provenant d’HAProxy, il est possible de transformer les noms d’en-têtes en minuscules vers un format différent lors de la mise en forme et de l’envoi de la réponse au client, en activant cette option et en précisant la liste des en-têtes à reformater à l’aide des directives globales « h1-case-adjust » ou « h1-case-adjust-file ». Ceci ne doit être qu’une solution de contournement temporaire, le temps que le client soit corrigé, car les clients nécessitant de telles solutions de contournement pourraient être vulnérables aux attaques d’envoi de contenu masqué et doivent être absolument corrigés. Veuillez noter que cette option n'affecte pas les clients conformes aux normes. Si cette option a été activée dans une section « defaults », elle peut être désactivée dans une instance spécifique en préfixant son nom par le mot-clé « no ». Voir également : « option h1-case-adjust-bogus-server », « h1-case-adjust », « h1-case-adjust-file ». **`option h1-case-adjust-bogus-server`** ```haproxy option h1-case-adjust-bogus-server no option h1-case-adjust-bogus-server ``` Activer ou désactiver le traitement de la casse des en-têtes HTTP/1 envoyés aux serveurs malveillants Peut être utilisé dans les contextes suivants : http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| non \| oui \| oui Arguments : aucun Il n’existe pas de cas standard pour les noms d’en-têtes, car, comme indiqué dans RFC7230, ils sont insensibles à la casse. Les applications doivent donc les traiter de manière insensible à la casse. Toutefois, certaines applications incorrectes violent les normes et s’appuient erronément sur les cas les plus couramment utilisés par les navigateurs. Ce problème devient critique avec HTTP/2 car tous les noms d’en-têtes doivent être échangés en minuscules, et HAProxy adopte la même convention. Tous les noms d’en-têtes sont envoyés en minuscules aux clients et aux serveurs, indépendamment de la version HTTP. Lorsqu’HAProxy reçoit une requête HTTP/1, les noms d’en-têtes sont convertis en minuscules, manipulés et envoyés de cette manière aux serveurs. Si un serveur est connu pour violer les normes HTTP et échouer à traiter une requête provenant d’HAProxy, il est possible de transformer les noms d’en-têtes en minuscules vers un format différent lors de la mise en forme et de l’envoi de la requête au serveur, en activant cette option et en précisant la liste des en-têtes à reformater à l’aide des directives globales « h1-case-adjust » ou « h1-case-adjust-file ». Ceci ne doit être qu’une solution de contournement temporaire, le temps que le serveur soit corrigé, car les serveurs nécessitant de telles solutions de contournement pourraient être vulnérables aux attaques d’envoi de contenu masqué et doivent absolument être corrigés. Veuillez noter que cette option n'affecte pas les serveurs conformes aux normes. Si cette option a été activée dans une section « defaults », elle peut être désactivée dans une instance spécifique en préfixant son nom par le mot-clé « no ». Voir aussi : « option h1-case-adjust-bogus-client », « h1-case-adjust », « h1-case-adjust-file ». **`option http-buffer-request`** ```haproxy option http-buffer-request no option http-buffer-request ``` Activer ou désactiver l'attente de la totalité du corps de la requête HTTP avant de poursuivre Peut être utilisé dans les contextes suivants : http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| oui \| oui \| oui Arguments : aucun Il peut parfois être souhaitable d’attendre la réception du corps d’une requête HTTP avant de prendre une décision. C’est précisément ce que fait « balance url_param », par exemple. Le premier cas d’utilisation consiste à tamponner les requêtes provenant de clients lents avant de se connecter au serveur. Un autre cas d’utilisation consiste à prendre la décision de routage en fonction du contenu du corps de la requête. Cette option, placée dans un frontal ou un backend, force le traitement HTTP à attendre jusqu’à réception intégrale du corps ou remplissage complet du tampon de requête. Elle peut entraîner des effets indésirables avec certaines applications qui abuse de HTTP en s’attendant à des transmissions non tamponnées entre le frontal et le backend ; elle ne doit donc certainement pas être utilisée par défaut. Voir aussi : « option http-no-delay », « timeout http-request », « http-request wait-for-body » **`option http-drop-request-trailers`** ```haproxy option http-drop-request-trailers no option http-drop-request-trailers ``` Supprimer les traînées HTTP de la requête lors de son envoi au serveur Peut être utilisé dans les contextes suivants : http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| non \| non \| oui Arguments : aucun Lorsque cette option est activée, tous les trailers HTTP trouvés dans une requête sont supprimés avant d’être envoyés au serveur. RFC9110#section-6.5.1 indique que les champs de bout de message peuvent être fusionnés avec les champs d'en-tête. Cette opération doit être effectuée intentionnellement, mais elle peut poser problème pour certaines applications, notamment si des clients malveillants masquent des champs d'en-tête sensibles dans la partie des champs de bout de message et que certains intermédiaires les fusionnent avec les en-têtes sans vérification spécifique. Dans ce cas, cette option peut être activée sur le backend afin de supprimer tout champ de bout de message détecté dans les requêtes avant leur envoi au serveur. Si cette option a été activée dans une section « defaults », elle peut être désactivée dans une instance spécifique en préfixant son nom par le mot-clé « no ». Voir également : « option http-drop-response-trailers » **`option http-drop-response-trailers`** ```haproxy option http-drop-response-trailers no option http-drop-response-trailers ``` Supprimer les traînées HTTP de la réponse lors de son envoi au client Peut être utilisé dans les contextes suivants : http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| oui \| oui \| non Arguments : aucun Cette option est similaire à « option http-drop-request-trailers », mais elle doit être utilisée pour supprimer les champs de bout de réponse avant de les envoyer aux clients. Si cette option a été activée dans une section « defaults », elle peut être désactivée dans une instance spécifique en préfixant son nom par le mot-clé « no ». Voir également : « option http-drop-request-trailers » **`option http-ignore-probes`** ```haproxy option http-ignore-probes no option http-ignore-probes ``` Activez ou désactivez la journalisation des connexions nulles et des délais d'expiration des requêtes Peut être utilisé dans les contextes suivants : http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| oui \| oui \| non Arguments : aucun Récemment, certains navigateurs ont commencé à implémenter une fonctionnalité de « pré-connexion », consistant à établir une connexion en avance à certains sites web récemment visités, au cas où l’utilisateur souhaiterait les visiter. Cela entraîne la création de nombreuses connexions vers des sites web, qui aboutissent à un code 408 Délai d'expiration de la requête si le délai d'expiration est atteint en premier, ou à un code 400 Requête incorrecte lorsque le navigateur décide de les fermer en premier. Ces événements polluent les journaux et alimentent les compteurs d'erreurs. Une option « option dontlognull » existait déjà, mais elle est insuffisante dans ce cas. À la place, cette option effectue les actions suivantes : - empêche l’envoi de tout message 400/408 au client si rien n’a été reçu sur une connexion avant sa fermeture ; - empêche l’émission de tout message de journalisation dans cette situation ; - empêche l’incrémentation de tout compteur d’erreur Ainsi, la connexion vide est ignorée silencieusement. Notez qu’il est préférable de ne pas utiliser cette option sauf si son utilité est claire, car elle masque des problèmes réels. La raison la plus courante d’une requête non reçue accompagnée d’un code 408 provient d’une incohérence de MTU entre le client et un élément intermédiaire tel qu’un VPN, qui bloque les paquets trop volumineux. Ces problèmes sont généralement observés avec les requêtes POST ainsi qu’avec les requêtes GET comportant de grandes cookies. Les journaux sont souvent la seule manière de les détecter. Si cette option a été activée dans une section « defaults », elle peut être désactivée dans une instance spécifique en préfixant son nom par le mot-clé « no ». Voir aussi : « log », « dontlognull », « errorfile » et la section [8](/fr/docs/haproxy/configuration-logging/) sur la journalisation. **`option http-keep-alive`** ```haproxy option http-keep-alive no option http-keep-alive ``` Activer ou désactiver la persistance HTTP du client vers le serveur pour les connexions HTTP/1.x Peut être utilisé dans les contextes suivants : http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| oui \| oui \| oui Arguments : aucun Par défaut, HAProxy fonctionne en mode keep-alive pour les connexions persistantes HTTP/1.x : pour chaque connexion, il traite chaque requête et réponse, puis laisse la connexion inactif des deux côtés. Ce mode peut être modifié par plusieurs options, telles que « option http-server-close » ou « option httpclose ». Cette option permet de rétablir le mode keep-alive, ce qui peut être utile lorsque un autre mode a été utilisé dans une section « defaults ». Paramètre « option http-keep-alive » active le mode keep-alive HTTP côté client et côté serveur. Cela permet d'obtenir la latence la plus faible côté client (réseau lent) et la réutilisation de session la plus rapide côté serveur, au prix de la maintenance de connexions inactives vers les serveurs. En général, il est possible, avec cette option, d'atteindre environ le double du débit de requêtes que l'option « http-server-close » permet sur des objets de petite taille. Deux situations principales rendent cette option utile : - lorsque le serveur n'est pas conforme à HTTP et authentifie la connexion au lieu des requêtes (par exemple, authentification NTLM) - lorsque le coût de l'établissement de la connexion au serveur est important par rapport au coût de récupération de l'objet associé depuis le serveur. Ce dernier cas peut survenir lorsque le serveur est un serveur statique rapide ou un cache. Actuellement, les journaux ne préciseront pas si les requêtes proviennent de la même session. La date d'acceptation indiquée dans les journaux correspond à la fin de la requête précédente, et le temps de requête correspond au temps passé en attente d'une nouvelle requête. Le délai d'expiration de la requête keep-alive reste lié au délai d'expiration défini par « timeout http-keep-alive » ou « timeout http-request », si ce dernier n'est pas configuré. Cette option désactive et remplace toute option précédente « option httpclose » ou « option http-server-close ». Voir également : « option httpclose », « option http-server-close », « option prefer-last-server » et « option http-pretend-keepalive ». **`option http-no-delay`** ```haproxy option http-no-delay no option http-no-delay ``` Instructez le système à privilégier les délais d'interaction faibles par rapport aux performances en HTTP Peut être utilisé dans les contextes suivants : http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| oui \| oui \| oui Arguments : aucun En HTTP, chaque charge utile est unidirectionnelle et ne comporte aucune notion d'interactivité. Tout agent doit être capable de mettre en file d'attente les données de manière à garantir un délai raisonnablement faible. Certains rares cas d'applications serveur-à-serveur abuse du protocole HTTP et s'attendent à ce que la phase de charge utile soit hautement interactive, avec de nombreuses tranches de données entrelacées dans les deux sens au sein d'une même requête. Cela n'est absolument pas pris en charge par la spécification HTTP et ne fonctionnera pas à travers la plupart des proxies ou serveurs. Lorsque de telles applications tentent de procéder ainsi via HAProxy, cela fonctionne, mais elles subiront des délais élevés dus aux optimisations réseau qui favorisent les performances en incitant le système à attendre que suffisamment de données soient disponibles afin d'envoyer uniquement des paquets complets. Les délais typiques s'élèvent à environ 200 ms par aller-retour. Notez qu'un tel comportement ne se produit qu'en cas d'utilisation anormale. Les utilisations normales, telles que les requêtes CONNECT ou les WebSockets, ne sont pas affectées. Lorsque l’option http-no-delay est présente dans le frontend ou le backend utilisé par une connexion, toutes ces optimisations sont désactivées afin de rendre les échanges aussi rapides que possible. Bien entendu, cela ne garantit en rien la fonctionnalité, car cela peut provoquer des dysfonctionnements ailleurs. Toutefois, si cela fonctionne via HAProxy, il fonctionnera à la vitesse maximale. Cette option ne doit jamais être utilisée par défaut, et ne doit jamais être utilisée du tout sauf si une application défectueuse est identifiée. L’usage de cette option entraîne une augmentation de la consommation de bande passante et de la charge CPU, ce qui peut réduire significativement les performances dans les environnements à forte latence. Voir également : « option http-buffer-request » **`option http-pretend-keepalive`** ```haproxy option http-pretend-keepalive no option http-pretend-keepalive ``` Définir si HAProxy doit annoncer keepalive pour la connexion HTTP/1.x au serveur ou non Peut être utilisé dans les contextes suivants : http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| non \| oui \| oui Arguments : aucun Lorsqu’il est exécuté avec l’option « option http-server-close » ou « option httpclose », HAProxy ajoute un en-tête « Connection: close » à la requête HTTP/1.x transmise au serveur. Malheureusement, certains serveurs, lorsqu’ils détectent cet en-tête, renoncent automatiquement à utiliser l’encodage par tronçons pour les réponses de longueur inconnue, ce qui est totalement sans rapport. Le résultat est qu’un client ou un cache pourrait recevoir une réponse incomplète sans s’en rendre compte, et considérer la réponse comme complète. En définissant « option http-pretend-keepalive », HAProxy fait croire au serveur qu'il maintiendra la connexion ouverte. Le serveur ne basculera alors pas vers le comportement anormal indésirable décrit ci-dessus. Une fois que HAProxy a reçu toute la réponse, il ferme la connexion avec le serveur exactement comme il le ferait avec « option httpclose ». Ainsi, le client reçoit une réponse normale et la connexion est correctement fermée côté serveur. Il est recommandé de ne pas activer cette option par défaut, car la plupart des serveurs ferment la connexion eux-mêmes de manière plus efficace après le dernier paquet, et libèrent leurs tampons légèrement plus tôt. En outre, le paquet supplémentaire sur le réseau pourrait réduire légèrement les performances maximales globales. Toutefois, il convient de noter qu’en activant cette option, HAProxy aura un travail légèrement moindre à accomplir. Ainsi, si HAProxy constitue le goulot d’étranglement de l’ensemble de l’architecture, l’activation de cette option pourrait économiser quelques cycles CPU. Cette option peut être définie dans les sections backend et listen. Son utilisation dans une section frontend sera ignorée, et un avertissement sera signalé au démarrage. Il s'agit d'une option liée au backend, aussi n'y a-t-il aucune raison réelle de la définir dans un frontend. Si cette option a été activée dans une section « defaults », elle peut être désactivée dans une instance spécifique en préfixant son nom par le mot-clé « no ». Voir également : « option httpclose », « option http-server-close » et « option http-keep-alive » **`option http-restrict-req-hdr-names { preserve | delete | reject }`** ```haproxy option http-restrict-req-hdr-names { preserve | delete | reject } ``` Définir la politique HAProxy concernant les noms d'en-tête de requête HTTP contenant des caractères en dehors de l'ensemble "[a-zA-Z0-9-]" Peut être utilisé dans les contextes suivants : http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| oui \| oui \| oui Arguments : ```text 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. ``` Cette option peut être utilisée pour restreindre les noms d’en-tête de requête aux caractères alphanumériques et au trait d’union ([A-Za-z0-9-]). Cela peut être obligatoire pour assurer l’interopérabilité avec des serveurs non conformes à HTTP qui échouent à traiter certains caractères dans les noms d’en-tête. Elle peut également être obligatoire pour les applications FastCGI, car tous les caractères non alphanumériques dans les noms d’en-tête sont remplacés par un trait de soulignement ('\_'). Il devient ainsi facile de confondre des noms d’en-tête et de contourner certaines règles. Par exemple, les en-têtes « X-Forwarded-For » et "X_Forwarded-For" sont tous deux convertis en "HTTP_X_FORWARDED_FOR" en FastCGI. Notez que cette option est évaluée par proxy et après l'évaluation des règles http-request. **`option http-server-close`** ```haproxy option http-server-close no option http-server-close ``` Activer ou désactiver la fermeture de la connexion HTTP/1.x côté serveur Peut être utilisé dans les contextes suivants : http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| oui \| oui \| oui Arguments : aucun Par défaut, HAProxy fonctionne en mode keep-alive pour les connexions persistantes HTTP/1.x : pour chaque connexion, il traite chaque requête et réponse, puis laisse la connexion inactif des deux côtés. Ce mode peut être modifié par plusieurs options, telles que « option http-server-close » ou « option httpclose ». L’activation de « option http-server-close » active le mode de fermeture de connexion HTTP côté serveur tout en conservant la capacité à supporter le keep-alive HTTP et le pipelining côté client. Cela permet d’obtenir la plus faible latence côté client (réseau lent) et la réutilisation de session la plus rapide côté serveur, afin de préserver les ressources serveur, de manière similaire à « option httpclose ». Cela permet également de servir des serveurs non capables de keep-alive en mode keep-alive aux clients, à condition qu’ils respectent les exigences de RFC7230. Veuillez noter que certains serveurs ne respectent pas toujours ces exigences lorsqu’ils reçoivent « Connection: close » dans la requête. Le résultat est qu’aucune connexion keep-alive ne sera utilisée. Une solution de contournement consiste à activer « option http-pretend-keepalive ». Actuellement, les journaux ne préciseront pas si les requêtes proviennent de la même session. La date d'acceptation indiquée dans les journaux correspond à la fin de la requête précédente, et le temps de requête correspond au temps passé en attente d'une nouvelle requête. Le délai d'expiration de la requête keep-alive reste lié au délai d'expiration défini par « timeout http-keep-alive » ou « timeout http-request », si ce dernier n'est pas configuré. Cette option peut être définie aussi bien dans un frontend que dans un backend. Elle est activée si au moins l’un des deux — frontend ou backend — qui gère une connexion l’a activée. Elle désactive et remplace toute option précédente « option httpclose » ou « option http-keep-alive ». Veuillez consulter la section [4](/fr/docs/haproxy/proxies/) ("Proxies") pour comprendre comment cette option s’combine avec les autres lorsque les options frontend et backend diffèrent. Si cette option a été activée dans une section « defaults », elle peut être désactivée dans une instance spécifique en préfixant son nom par le mot-clé « no ». Voir également : « option httpclose », « option http-pretend-keepalive » et « option http-keep-alive ». **`option http-use-proxy-header`** ```haproxy option http-use-proxy-header no option http-use-proxy-header ``` Utilisez l'en-tête Proxy-Connection non standard à la place de Connection Peut être utilisé dans les contextes suivants : http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| oui \| oui \| non Arguments : aucun Bien que RFC7230 indique explicitement que les agents HTTP/1.1 doivent utiliser l’en-tête Connection pour indiquer leur préférence concernant les connexions persistantes ou non persistantes, les navigateurs et les proxies ignorent cet en-tête pour les connexions proxyées et utilisent à la place l’en-tête Proxy-Connection, non documenté et non standard. Le problème survient lorsqu’on cherche à placer un répartiteur de charge entre les navigateurs et de tels proxies, car il y aura une différence entre ce que HAProxy comprend et ce que le client et le proxy ont convenu. En définissant cette option dans un frontal, HAProxy peut automatiquement passer à l'utilisation de cet en-tête non standard s'il détecte des requêtes proxyées. Une requête proxyée est définie ici comme une requête dont l'URI ne commence ni par '/' ni par '\*'. Cette option est incompatible avec le mode tunnel HTTP. Notez que cette option ne peut être spécifiée que dans un frontal et affecte la requête tout au long de sa durée de vie. En outre, lorsque cette option est définie, une requête nécessitant une authentification passe automatiquement à l’utilisation des en-têtes d’authentification du proxy si elle est elle-même une requête proxyée. Cela permet de vérifier ou d’imposer l’authentification devant un proxy existant. Cette option doit normalement ne jamais être utilisée, sauf devant un proxy. Voir également : « option httpclose », et « option http-server-close ». **`option httpchk`** ```haproxy option httpchk option httpchk option httpchk option httpchk option httpchk ``` Active le protocole HTTP pour vérifier l'état de santé des serveurs Peut être utilisé dans les contextes suivants : tcp, http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| non \| oui \| oui Arguments : ```text 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. 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. 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. is the optional HTTP Host header value. It is not set by default. It is a log-format string. ``` Par défaut, les contrôles d'état des serveurs se limitent à la tentative d'établissement d'une connexion TCP. Lorsque l'option « option httpchk » est spécifiée, une requête HTTP complète est envoyée une fois la connexion TCP établie, et les réponses 2xx et 3xx sont considérées comme valides, tandis que toutes les autres indiquent une défaillance du serveur, y compris l'absence de réponse. Associé aux directives « http-check », il est possible de personnaliser la requête envoyée lors des contrôles d'état HTTP ou les règles de correspondance sur la réponse. Il est également possible de configurer une séquence send/expect, tout comme avec la directive « tcp-check » pour les contrôles d'état TCP. La configuration du serveur est utilisée par défaut pour ouvrir des connexions afin d'effectuer des contrôles d'état HTTP. Il est également possible de remplacer les paramètres du serveur à l'aide de règles « http-check connect ». L'option « httpchk » n'exige pas nécessairement un backend HTTP ; elle fonctionne également avec des backends TCP brut. Cela est particulièrement utile pour vérifier des scripts simples liés à des ports dédiés via le démon inetd. Toutefois, elle s'appuie toujours internement sur un multiplexeur HTX. Cela implique que la mise en forme des requêtes et l'analyse des réponses seront strictes. Exemples : ```shell # 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 ``` Voir également : « option ssl-hello-chk », « option smtpchk », « option mysql-check », « option pgsql-check », « http-check » et les options serveur « check », « port » et « inter ». **`option httpclose`** ```haproxy option httpclose no option httpclose ``` Activer ou désactiver la fermeture de la connexion HTTP/1.x Peut être utilisé dans les contextes suivants : http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| oui \| oui \| oui Arguments : aucun Par défaut, HAProxy fonctionne en mode keep-alive concernant les connexions persistantes HTTP/1.x : pour chaque connexion, il traite chaque requête et réponse, puis laisse la connexion inactif des deux côtés. Ce mode peut être modifié par plusieurs options, telles que « option http-server-close » ou « option httpclose ». Si l'option « option httpclose » est définie, HAProxy fermera la connexion client ou serveur, selon l'emplacement où l'option est configurée. Le frontal est considéré pour les connexions client, tandis que le backend est considéré pour les connexions serveur. Si l'option est définie sur un écouteur, elle s'applique aux connexions client et serveur. Elle vérifiera si un en-tête « Connection: close » est déjà présent dans chaque sens, et l'ajoutera si nécessaire. Cette option peut également être combinée avec « option http-pretend-keepalive », ce qui empêche l’envoi de l’en-tête de requête « Connection: close », mais entraîne tout de même la fermeture de la connexion une fois la réponse entière reçue. Il désactive et remplace toute option précédente « option http-server-close » ou « option http-keep-alive ». Si cette option a été activée dans une section « defaults », elle peut être désactivée dans une instance spécifique en préfixant son nom par le mot-clé « no ». Voir également : « option http-server-close ». **`option httplog [ clf ]`** ```haproxy option httplog [ clf ] ``` Activer la journalisation des requêtes HTTP, de l'état du flux et des minuteries Peut être utilisé dans les contextes suivants : http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| oui \| oui \| non Arguments : ```text 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. ``` Par défaut, le format de sortie des journaux est très limité, ne comportant que les adresses source et destination, ainsi que le nom de l'instance. En spécifiant « option httplog », chaque ligne de journalisation adopte un format bien plus riche, incluant, sans s'y limiter, la requête HTTP, les temporisateurs de connexion, l'état du flux, le nombre de connexions, les en-têtes et cookies capturés, le nom du frontal, du backend et du serveur, ainsi que bien entendu l'adresse source et les ports. Spécifier uniquement « option httplog » efface automatiquement le mode « clf » s'il était défini par défaut. L'option httplog remplace toute directive log-format précédemment définie. Voir également : [section 8](/fr/docs/haproxy/configuration-logging/) concernant la journalisation. **`option httpslog`** ```haproxy option httpslog ``` Activer la journalisation des requêtes HTTPS, de l'état du flux et des compteurs Peut être utilisé dans les contextes suivants : http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| oui \| oui \| non Par défaut, le format de sortie des journaux est très limité, ne comportant que les adresses source et destination, ainsi que le nom de l'instance. En spécifiant « option httpslog », chaque ligne de journalisation adopte un format bien plus riche, incluant, sans s'y limiter, la requête HTTP, les temporisateurs de connexion, l'état du flux, le nombre de connexions, les en-têtes et cookies capturés, le nom du frontal, du backend et du serveur, les états de vérification du certificat SSL et de la négociation SSL, ainsi que bien entendu l'adresse source et les ports. L'option httpslog remplace toute directive log-format précédemment définie. Voir également : [section 8](/fr/docs/haproxy/configuration-logging/) concernant la journalisation. **`option idle-close-on-response`** ```haproxy option idle-close-on-response no option idle-close-on-response ``` Éviter de fermer les connexions frontend inactives si une interruption douce est en cours Peut être utilisé dans les contextes suivants : http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| oui \| oui \| non Arguments : aucun Par défaut, les connexions inactives seront fermées lors d'un arrêt doux. Dans certains environnements, un client communiquant avec le proxy peut avoir préparé certaines connexions inactives afin d'envoyer des requêtes ultérieurement. Si aucune tentative de nouvelle tentative en cas d'erreur d'écriture n'est effectuée, cela peut entraîner des erreurs pendant le rechargement de haproxy. Même si une implémentation correcte devrait réessayer en cas d'erreurs connection/write, cette option a été introduite afin de maintenir la compatibilité descendante avec les versions de HAProxy antérieures à la 2.4. En effet, avant la version 2.4, HAProxy attendait une dernière requête et réponse pour ajouter un en-tête « connection: close » avant de fermer la connexion, informant ainsi le client que la connexion ne serait pas réutilisable. Dans un exemple concret, ce comportement a été observé sur AWS en utilisant un ALB devant un HAProxy. Le résultat final était un code 502 envoyé par l'ALB lors des rechargements du HAProxy. Les utilisateurs sont avertis qu'utiliser cette option peut augmenter le nombre de processus anciens si les connexions restent inactives trop longtemps. Il se peut qu'il soit nécessaire d'ajuster les délais d'expiration client et/ou le paramètre « hard-stop-after » en cas de rechargements fréquents. Voir également : « timeout client », « timeout client-fin », « timeout http-request », « hard-stop-after » **`option independent-streams`** ```haproxy option independent-streams no option independent-streams ``` Activer ou désactiver le traitement indépendant des délais d'expiration dans les deux sens Peut être utilisé dans les contextes suivants : tcp, http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| oui \| oui \| oui Arguments : aucun Par défaut, lorsque des données sont envoyées via une socket, le délai d'expiration d'écriture et le délai d'expiration de lecture de cette socket sont actualisés, car nous considérons qu'il y a une activité sur cette socket, et nous ne disposons d'aucun autre moyen de deviner si nous devrions recevoir des données ou non. Bien que ce comportement par défaut soit souhaitable pour presque toutes les applications, il existe une situation où il est préférable de le désactiver, et de ne mettre à jour le délai d'expiration de lecture que si des données entrantes sont reçues. Cela se produit dans les flux avec des délais d'expiration élevés et de faibles quantités de données échangées, comme les sessions telnet. Si le serveur disparaît soudainement, les données de sortie s'accumulent dans les tampons de socket du système, les deux délais d'expiration sont correctement mis à jour, et il n'existe aucun moyen de savoir que le serveur ne les reçoit pas, aussi ne déclenchons-nous pas de délai d'expiration. Toutefois, lorsque le protocole sous-jacent échoe toujours les données envoyées, il suffirait à lui seul de détecter le problème en utilisant le délai d'expiration de lecture. Notez que ce problème ne se produit pas avec des protocoles plus verbeux, car les données ne s'accumulent pas longtemps dans les tampons de socket. Lorsque cette option est définie sur le frontal, elle désactive les mises à jour du délai d'expiration en lecture pour les données envoyées au client. Ce cas est probablement peu utile. Lorsqu'elle est définie sur le backend, elle désactive les mises à jour du délai d'expiration en lecture pour les données envoyées au serveur. Cette action risque généralement de rompre les grandes requêtes HTTP provenant de lignes lentes, utilisez-la donc avec précaution. Voir également : « timeout client », « timeout server » et « timeout tunnel » **`option ldap-check`** ```haproxy option ldap-check ``` Utilisez les contrôles d'état LDAPv3 pour le test des serveurs Peut être utilisé dans les contextes suivants : tcp Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| non \| oui \| oui Arguments : aucun Il est possible de vérifier que le serveur communique correctement en LDAPv3, et non seulement de tester qu’il accepte la connexion TCP. Lorsque cette option est activée, un message de liaison simple anonyme LDAPv3 est envoyé au serveur, et la réponse est analysée afin de détecter un message de réponse de liaison LDAPv3. Le serveur est considéré comme valide uniquement lorsque la réponse LDAP contient un resultCode success (). La journalisation des requêtes de liaison dépend du serveur ; consultez la documentation correspondante pour savoir comment la configurer. Exemple : ```text option ldap-check ``` Voir aussi : « option httpchk » **`option log-health-checks`** ```haproxy option log-health-checks no option log-health-checks ``` Activer ou désactiver la journalisation des mises à jour d'état des contrôles d'état Peut être utilisé dans les contextes suivants : tcp, http, log Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| non \| oui \| oui Arguments : aucun Par défaut, les échecs de contrôle d'état sont journalisés si le serveur est UP et les contrôles d'état réussis sont journalisés si le serveur est DOWN, de sorte que la quantité d'informations supplémentaires est limitée. Lorsque cette option est activée, tout changement d'état du contrôle d'état ou de la santé du serveur est journalisé, ce qui permet de savoir qu'un serveur a échoué à des contrôles d'état ponctuels avant de planter, ou précisément quand il a cessé de répondre avec un statut HTTP valide, puis quand le port a commencé à rejeter les connexions, enfin quand le serveur a cessé toute réponse. Notez que les changements d'état non provoqués par les contrôles d'état (par exemple, enable/disable en ligne de commande) ne sont pas intentionnellement journalisés par cette option. Voir aussi : « option httpchk », « option ldap-check », « option mysql-check », « option pgsql-check », « option redis-check », « option smtpchk », « option tcp-check », « log » et la section [8](/fr/docs/haproxy/configuration-logging/) sur la journalisation. **`option log-separate-errors`** ```haproxy option log-separate-errors no option log-separate-errors ``` Modifier le niveau de journalisation pour les connexions non entièrement réussies Peut être utilisé dans les contextes suivants : tcp, http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| oui \| oui \| non Arguments : aucun Parfois, il n’est pas facile de repérer les erreurs dans les journaux. Cette option permet à HAProxy d’augmenter le niveau des journaux contenant potentiellement des informations intéressantes, telles que les erreurs, les délais d’expiration, les tentatives de reconnexion, les redirigements, ou les codes d’état HTTP 5xx. Le niveau passe de « info » à « err ». Cela permet de les journaliser séparément dans un fichier différent avec la plupart des démons syslog. Prenez garde à ne pas les supprimer du fichier d’origine, sinon vous perdriez l’ordre des événements, qui fournit des informations très importantes. Avec cette option, les grands sites traitant plusieurs milliers de connexions par seconde peuvent journaliser le trafic normal dans un tampon tournant et ne sauvegarder que les journaux d'erreurs plus petits. Voir aussi : « log », « dontlognull », « dontlog-normal » et [section 8](/fr/docs/haproxy/configuration-logging/) concernant la journalisation. **`option logasap`** ```haproxy option logasap no option logasap ``` Active ou désactive la journalisation précoce. Peut être utilisé dans les contextes suivants : tcp, http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| oui \| oui \| non Arguments : aucun Par défaut, les journaux sont émis lorsque tous les alias de format de journal et les extraits d'échantillon utilisés dans la définition de la chaîne de format de journal renvoient une valeur, ou lorsque le flux est terminé. Cela permet aux chaînes de format de journal intégrées de tenir compte du temps de transfert ou du nombre d'octets dans les messages de journal. Lors de la gestion de connexions longues, telles que les transferts de fichiers volumineux ou RDP, il peut s’écouler un certain temps avant que la requête ou la connexion n’apparaisse dans les journaux. En utilisant « option logasap », le message de journalisation est généré dès que la connexion au serveur est établie en mode tcp, ou dès que le serveur envoie l’intégralité des en-têtes en mode http. Les informations manquantes dans les journaux seront le nombre total d’octets, qui ne reflétera que la quantité de données transférées avant la création du message, et le temps total, qui ne tiendra pas compte de la durée restante de la connexion ou du temps de transfert. Pour le cas HTTP, il est bon de capturer l’en-tête de réponse Content-Length afin que les journaux indiquent au moins le nombre d’octets attendus lors du transfert. Exemples : ```text listen http_proxy 0.0.0.0:80 mode http option httplog option logasap log 192.168.2.200 local3 ``` ```text >>> 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" ``` Voir également : « option httplog », « capture réponse en-tête » et [section 8](/fr/docs/haproxy/configuration-logging/) concernant la journalisation. **`option mysql-check [ user [ { post-41 | pre-41 | post-80 } ] ]`** ```haproxy option mysql-check [ user [ { post-41 | pre-41 | post-80 } ] ] ``` Utilisez les contrôles d'état MySQL pour tester les serveurs Peut être utilisé dans les contextes suivants : tcp Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| non \| oui \| oui Arguments : ```text 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 post-80 Send post v8.0 client compatible checks with CLIENT_PLUGIN_AUTH capability set and mysql_native_password as the authentication plugin. Use this option when connecting to MySQL 8.0+ servers where the health check user is created with mysql_native_password authentication. Example: CREATE USER 'haproxy'@'%' IDENTIFIED WITH mysql_native_password BY ''; ``` Si vous spécifiez un nom d'utilisateur, le test consiste à envoyer deux paquets MySQL : un paquet d'authentification client, puis un paquet QUIT pour fermer correctement la session MySQL. Nous analysons ensuite le paquet d'initialisation d'échange MySQL et/ou le paquet d'erreur. Il s'agit d'un test basique mais utile, qui ne génère ni erreur ni connexion interrompue côté serveur. Toutefois, il nécessite un utilisateur autorisé non verrouillé, sans mot de passe. Pour créer un utilisateur basique limité dans MySQL, avec des limites de ressources facultatives : ```text CREATE USER ''@'' /*!50701 WITH MAX_QUERIES_PER_HOUR 1 MAX_UPDATES_PER_HOUR 0 */ /*M!100201 MAX_STATEMENT_TIME 0.0001 */; ``` Si vous ne spécifiez pas de nom d'utilisateur (cela est obsolète et non recommandé), le contrôle se limite à l'analyse du paquet d'initialisation de handshake MySQL ou du paquet d'erreur ; aucun paquet n'est envoyé en ce mode. Il a été signalé qu'il peut provoquer un verrouillage si le contrôle est trop fréquent et/ou s'il y a une trafic insuffisant. En réalité, vous devez, dans ce cas, vérifier la valeur de MySQL "max_connect_errors" comme si une connexion était établie avec succès en moins de "max_connect_errors" tentatives après une interruption précédente de connexion, auquel cas le compteur d'erreurs pour l'hôte est réinitialisé à zéro. Si le serveur HAProxy est bloqué, la commande « FLUSH HOSTS » est la seule manière de le débloquer. N'oubliez pas que cela ne vérifie ni la présence de la base de données ni sa cohérence. Pour effectuer cette vérification, vous pouvez utiliser une vérification externe avec xinetd, par exemple. La vérification nécessite MySQL \>=3.22 ; pour les versions plus anciennes, utilisez la vérification TCP. Souvent, un serveur MySQL entrant doit voir l'adresse IP du client pour diverses raisons, notamment le contrôle des privilèges par IP et la journalisation des connexions. Lorsqu'il est possible de le faire, il est souvent judicieux de masquer l'adresse IP du client lors de la connexion au serveur en utilisant l'argument « usesrc » du mot-clé « source », ce qui nécessite que la fonctionnalité de proxy transparent soit compilée, ainsi qu'un serveur MySQL qui achemine le client via la machine hébergeant HAProxy. Voir aussi : « option httpchk » **`option nolinger`** ```haproxy option nolinger no option nolinger ``` Activer ou désactiver le nettoyage immédiat des ressources de session après fermeture Peut être utilisé dans les contextes suivants : tcp, http, log Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| oui \| oui \| oui Arguments : aucun Lorsque les clients ou les serveurs interrompent les connexions de manière inappropriée (par exemple, en étant physiquement déconnectés), les délais d'expiration de session sont déclenchés et la session est fermée. Toutefois, elle reste dans l'état FIN_WAIT1 pendant une certaine durée dans le système, consommant des ressources et pouvant limiter la capacité à établir de nouvelles connexions. Lorsque cela se produit, il est possible d’activer l’option *nolinger*, qui force le système à supprimer immédiatement les données en attente sur une socket lors de sa fermeture. Ainsi, un paquet TCP RST est émis, les données en attente sont tronquées, et la session est instantanément supprimée des tables du système. L’effet généralement observable par un client est que les réponses sont tronquées si la fermeture intervient avec le dernier bloc de données (par exemple, dans une réponse de redirection ou d’erreur). Du côté serveur, cela peut aider à libérer immédiatement les ports sources lors du transfert quand un client interrompt une connexion en tunnel. Dans les deux cas, des réinitialisations TCP sont émises, et comme la session est détruite instantanément, aucune retransmission ne sera tentée. Sur un réseau bruyant, cela peut aggraver les problèmes, notamment lorsqu’un pare-feu est présent du côté bruyant, car le pare-feu pourrait détecter et traiter la réinitialisation (et supprimer ainsi sa session), puis bloquer tout trafic ultérieur pour cette session, y compris les retransmissions provenant de l’autre côté. Ainsi, si l’autre côté ne reçoit pas cette réinitialisation, il ne recevra jamais de nouveau RST, et le pare-feu pourrait enregistrer de nombreux paquets bloqués. Pour toutes ces raisons, il est fortement recommandé de ne pas utiliser cette option, sauf si absolument nécessaire en dernier recours. Dans la plupart des cas, l'utilisation des délais « client-fin » ou « server-fin » permet d’obtenir des résultats similaires avec un comportement plus fiable. Sur Linux, il est également possible d’utiliser la configuration bind ou server « tcp-ut ». Cette option peut être utilisée aussi bien sur les frontaux que sur les backends, selon le côté où elle est requise. Utilisez-la sur le frontal pour les clients, et sur le backend pour les serveurs. Bien que cette option soit techniquement prise en charge dans les sections « defaults », elle ne doit en aucun cas être utilisée là-bas, car elle risque de se propager accidentellement à des sections qui ne doivent pas l'utiliser, provoquant ainsi des problèmes. Si cette option a été activée dans une section « defaults », elle peut être désactivée dans une instance spécifique en préfixant son nom par le mot-clé « no ». Voir également : « timeout client-fin », « timeout server-fin », mots-clés bind ou server « tcp-ut ». **`option originalto [ except ] [ header ]`** ```haproxy option originalto [ except ] [ header ] ``` Activer l'insertion de l'en-tête X-Original-To dans les requêtes envoyées aux serveurs Peut être utilisé dans les contextes suivants : http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| oui \| oui \| oui Arguments : ```text is an optional argument used to disable this option for sources matching an optional argument to specify a different "X-Original-To" header name. ``` Étant donné qu’HAProxy peut fonctionner en mode transparent, chaque requête provenant d’un client peut être redirigée vers le proxy, et HAProxy lui-même peut acheminer chaque requête vers un environnement SQUID complexe, ce qui fait perdre l’hôte de destination provenant de SO_ORIGINAL_DST. Cela est problématique lorsque l’on souhaite appliquer des règles d’accès basées sur les adresses IP de destination. Pour résoudre ce problème, HAProxy peut ajouter un nouvel en-tête HTTP « X-Original-To » à toutes les requêtes envoyées au serveur. Cet en-tête contient une valeur représentant l’adresse IP de destination d’origine. Cette fonctionnalité doit être configurée de manière à ne jamais utiliser que la dernière occurrence de cet en-tête. Notez qu’il ne faut utiliser que la dernière occurrence de cet en-tête, car il est effectivement possible que le client ait déjà fourni un tel en-tête. Le mot-clé « header » peut être utilisé pour spécifier un nom d’en-tête différent afin de remplacer le nom par défaut « X-Original-To ». Cela peut être utile lorsque vous avez déjà un en-tête « X-Original-To » provenant d'une autre application et que vous devez le préserver. De même, si votre serveur backend ne utilise pas l’en-tête « X-Original-To » et nécessite un autre en-tête. Parfois, une même instance HAProxy peut être partagée entre un accès direct depuis un client et un accès via un proxy inverse (par exemple lorsqu’un proxy inverse SSL est utilisé pour déchiffrer le trafic HTTPS). Il est possible de désactiver l’ajout de l’en-tête pour une adresse ou un réseau cible connus en ajoutant le mot-clé « except » suivi de l’adresse réseau. Dans ce cas, toute adresse IP de destination correspondant au réseau ne déclenchera pas l’ajout de cet en-tête. Les utilisations les plus courantes concernent les réseaux privés ou 127.0.0.1. Les versions IPv4 et IPv6 sont toutes deux prises en charge. Cette option peut être spécifiée soit dans le frontal, soit dans le backend. Si au moins l’un d’eux l’utilise, l’en-tête sera ajouté. Notez que le paramètre d’en-tête défini dans le backend a priorité sur celui défini dans le frontal si les deux sont configurés. Exemples : ```shell # 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 ``` Voir également : « option httpclose », « option http-server-close ». **`option persist`** ```haproxy option persist no option persist ``` Activer ou désactiver la persistance forcée sur les serveurs inaccessibles Peut être utilisé dans les contextes suivants : tcp, http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| non \| oui \| oui Arguments : aucun Lorsqu'une requête HTTP atteint un backend avec un cookie faisant référence à un serveur inactif, elle est, par défaut, redirigée vers un autre serveur. Il est possible de forcer la requête à être envoyée en premier au serveur inactif en utilisant « option persist », si cela est absolument nécessaire. Un cas d'utilisation courant est lorsque les serveurs sont sous une charge extrême et passent leur temps à basculer. Dans ce cas, les utilisateurs continuent d’être dirigés vers le serveur sur lequel ils ont ouvert la session, dans l’espoir qu’ils soient correctement servis. Il est recommandé d’utiliser « option redispatch » en conjonction avec cette option afin que, dans le cas où il serait impossible de se connecter au serveur (serveur définitivement inactif), le client soit finalement redirigé vers un autre serveur valide. Si cette option a été activée dans une section « defaults », elle peut être désactivée dans une instance spécifique en préfixant son nom par le mot-clé « no ». Voir aussi : « option redispatch », « retries », « force-persist » **`option pgsql-check user `** ```haproxy option pgsql-check user ``` Utilisez les contrôles d'état PostgreSQL pour le test des serveurs Peut être utilisé dans les contextes suivants : tcp Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| non \| oui \| oui Arguments : ```text This is the username which will be used when connecting to PostgreSQL server. ``` La vérification envoie un message StartupMessage PostgreSQL et attend soit un message de demande d'authentification, soit un message d'erreur. Il s'agit d'un test basique mais utile qui ne génère ni erreur ni connexion interrompue sur le serveur. Cette vérification est identique à celle de « mysql-check ». Voir aussi : « option httpchk » **`option prefer-last-server`** ```haproxy option prefer-last-server no option prefer-last-server ``` Permettre à plusieurs requêtes équilibrées de rester sur le même serveur Peut être utilisé dans les contextes suivants : tcp, http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| non \| oui \| oui Arguments : aucun Lorsque l'algorithme de répartition de charge utilisé n'est pas déterministe, et qu'une requête précédente a été envoyée à un serveur auquel HAProxy maintient encore une connexion, il peut être souhaitable que les requêtes ultérieures d'une même session soient dirigées vers le même serveur autant que possible. Notez que cela diffère de la persistance, car nous ne faisons qu'indiquer une préférence que HAProxy tente d'appliquer sans aucune garantie. L'utilisation réelle concerne les connexions keep-alive envoyées aux serveurs. Lorsque cette option est utilisée, HAProxy tentera de réutiliser la même connexion attachée au serveur au lieu de répartir la charge vers un autre serveur, ce qui provoquerait la fermeture de la connexion. Cela peut avoir un sens pour les serveurs de fichiers statiques. Il ne convient pas d'utiliser cette option en combinaison avec des algorithmes basés sur le hachage. Notez qu’HAProxy tente déjà automatiquement de rester attaché à un serveur qui renvoie un code 401 ou à un proxy qui renvoie un code 407 (authentification requise), lorsque l'algorithme de répartition de charge n'est pas déterministe. Cette fonctionnalité est obligatoire pour l'utilisation avec le défi d'authentification NTLM défectueux, et aide considérablement au dépannage de certaines applications défaillantes. L'option prefer-last-server peut également être souhaitable dans ces environnements afin d'éviter de redistribuer le trafic après chaque réponse. Il peut être utile de préciser ici quels algorithmes de répartition de charge sont considérés comme déterministes. Les algorithmes déterministes sélectionnent toujours le même serveur pour des données clientes données, à condition que l’ensemble des serveurs disponibles n’ait pas changé. En général, les algorithmes déterministes impliquent un hachage ou une recherche dans les requêtes entrantes pour choisir le serveur cible. Toutefois, ce n’est pas toujours le cas ; par exemple, « static-rr » peut également être considéré comme déterministe, car le choix du serveur repose sur le poids statique du serveur, rendant la sélection prévisible. L’algorithme « sticky » assure une routage déterministe pour les clients revenant. En ce qui concerne les algorithmes non déterministes, ces algorithmes choisissent un serveur en fonction de l’état dynamique du serveur ou d’une rotation simple, si bien que deux requêtes consécutives ne sont pas garanties d’être acheminées vers le même serveur. L’option prefer-last-server est spécifiquement conçue pour de tels cas. roundrobin et leastconn en sont des exemples. Si cette option a été activée dans une section « defaults », elle peut être désactivée dans une instance spécifique en préfixant son nom par le mot-clé « no ». Voir aussi : « option http-keep-alive » **`option redispatch`** ```haproxy option redispatch option redispatch no option redispatch ``` Activer ou désactiver la redistribution de session en cas d'échec de connexion Peut être utilisé dans les contextes suivants : tcp, http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| non \| oui \| oui Arguments : ```text 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. ``` En mode HTTP, si un serveur désigné par un cookie est hors service, les clients peuvent effectivement rester attachés à ce serveur, par exemple lors de l'utilisation de « option persist » ou de « force-persist », car ils ne peuvent pas supprimer le cookie, ce qui les empêche de nouveau d'accéder au service. Spécifier « option redispatch » permet au proxy de rompre la persistance basée sur les cookies ou le hachage constant, et de redistribuer les connexions vers un serveur fonctionnel. Les serveurs actifs sont sélectionnés à partir d'un sous-ensemble de la liste des serveurs disponibles. Les serveurs actifs qui ne sont ni hors service ni en maintenance (c'est-à-dire dont l'état n'est pas vérifié ou qui ont été vérifiés comme « up ») sont sélectionnés dans l'ordre suivant : ```text 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. ``` Lorsqu'une nouvelle tentative est effectuée, HAProxy tente de sélectionner un serveur différent du dernier utilisé. Le nouveau serveur est sélectionné à partir de la liste actuelle des serveurs. Parfois, si la liste est mise à jour entre deux tentatives (par exemple, si un grand nombre de tentatives ont lieu et que la durée est supérieure au temps nécessaire pour vérifier qu’un serveur est hors service, le supprimer de la liste et basculer sur la liste des serveurs de secours), les connexions peuvent être redirigées vers un serveur de secours, toutefois. Il permet également de réessayer la connexion à un autre serveur en cas d'échecs multiples. Bien entendu, cela nécessite que « retries » soit défini à une valeur non nulle. Si cette option a été activée dans une section « defaults », elle peut être désactivée dans une instance spécifique en préfixant son nom par le mot-clé « no ». Voir également : « option persist », « force-persist », « retries » **`option redis-check`** ```haproxy option redis-check ``` Utilisez les contrôles d'état Redis pour tester les serveurs Peut être utilisé dans les contextes suivants : tcp Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| non \| oui \| oui Arguments : aucun Il est possible de vérifier que le serveur communique correctement selon le protocole REDIS, et non seulement qu'il accepte la connexion TCP. Lorsque cette option est activée, une commande PING REDIS est envoyée au serveur, et la réponse est analysée afin de détecter le message de réponse "+PONG". Exemple : ```text option redis-check ``` Voir également : « option httpchk », « option tcp-check », « tcp-check expect » **`option smtpchk`** ```haproxy option smtpchk option smtpchk ``` Utilisez les contrôles d'état SMTP pour tester les serveurs Peut être utilisé dans les contextes suivants : tcp Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| non \| oui \| oui Arguments : ```text 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. ``` Lorsque l'option smtpchk est activée, les contrôles d'état consistent en une connexion TCP suivie d'une commande SMTP. Par défaut, cette commande est « HELO localhost ». Le code de réponse du serveur est analysé, et seuls les codes de réponse commençant par un « 2 » sont considérés comme valides. Toutes les autres réponses, ainsi qu'une absence de réponse, constituent une erreur et indiquent un serveur hors service. Ce test est destiné à être utilisé avec des serveurs ou relais SMTP. Selon la requête, il se peut que certains serveurs ne journalisent pas chaque tentative de connexion, vous devrez donc peut-être expérimenter pour améliorer le comportement. Utiliser telnet sur le port 25 est souvent plus simple que de modifier la configuration. Souvent, un serveur SMTP entrant doit voir l'adresse IP du client pour diverses raisons, notamment le filtrage du spam, la prévention de la falsification d'adresse et la journalisation. Lorsqu'il est possible de le faire, il est souvent judicieux de masquer l'adresse IP du client lors de la connexion au serveur en utilisant l'argument « usesrc » du mot-clé « source », ce qui nécessite que la fonctionnalité de proxy transparent soit compilée. Exemple : ```text option smtpchk HELO mydomain.org ``` Voir aussi : « option httpchk », « source » option socket-stats non option socket-stats Activer ou désactiver la collecte et la fourniture de statistiques séparées pour chaque socket. Peut être utilisé dans les contextes suivants : tcp, http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| oui \| oui \| non Arguments : aucun **`option splice-auto`** ```haproxy option splice-auto no option splice-auto ``` Activer ou désactiver l'accélération matérielle du noyau sur les sockets dans les deux sens Peut être utilisé dans les contextes suivants : tcp, http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| oui \| oui \| oui Arguments : aucun Lorsque cette option est activée, soit sur un frontal, soit sur un backend, HAProxy évalue automatiquement la possibilité d'utiliser le splice TCP du noyau pour transférer les données entre le client et le serveur, dans les deux sens. HAProxy utilise des heuristiques pour estimer si le splice du noyau pourrait améliorer les performances ou non. Les deux sens sont gérés indépendamment. Notez que les heuristiques utilisées ne sont pas très agressives afin de limiter une utilisation excessive du splice. Cette option nécessite que le splice soit activé au moment de la compilation et peut être désactivée globalement à l'aide de l'option « nosplice ». Étant donné que le splice utilise des tubes, son utilisation suppose qu'il y ait suffisamment de tubes disponibles. Note importante : la fusion TCP basée sur le noyau est une fonctionnalité spécifique à Linux, apparue pour la première fois dans le noyau 2.6.25. Elle permet d'accélérer le transfert de données entre sockets au niveau du noyau, sans copier ces données en espace utilisateur, offrant ainsi des gains de performance et des économies de cycles CPU significatifs. Étant donné que de nombreuses implémentations anciennes sont défectueuses, susceptibles de corrompre les données ou de fonctionner de manière inefficace, cette fonctionnalité n'est pas activée par défaut et doit être utilisée avec une extrême prudence. Bien qu'il ne soit pas possible de détecter la correction d'une implémentation, la version 2.6.29 est la première à proposer une implémentation correctement fonctionnelle. En cas de doute, la fusion peut être désactivée globalement à l'aide du mot-clé global « nosplice ». Exemple : ```text option splice-auto ``` Si cette option a été activée dans une section « defaults », elle peut être désactivée dans une instance spécifique en préfixant son nom par le mot-clé « no ». Voir également : « option splice-request », « option splice-response » et les options globales « nosplice » et « maxpipes » **`option splice-request`** ```haproxy option splice-request no option splice-request ``` Activer ou désactiver l'accélération automatique du noyau sur les sockets pour les requêtes Peut être utilisé dans les contextes suivants : tcp, http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| oui \| oui \| oui Arguments : aucun Lorsque cette option est activée, soit sur un frontal, soit sur un backend, HAProxy utilisera le transfert direct du noyau (tcp splicing) chaque fois que possible pour acheminer les données allant du client vers le serveur. Il peut toutefois recourir au schéma recv/send si aucun canal libre n'est disponible. Cette option nécessite que le transfert direct soit activé lors de la compilation et peut être désactivée globalement via l'option « nosplice ». Étant donné que le transfert direct utilise des canaux, son utilisation suppose la disponibilité de suffisamment de canaux libres. Remarque importante : consultez « option splice-auto » pour les limitations d'utilisation. Exemple : ```text option splice-request ``` Si cette option a été activée dans une section « defaults », elle peut être désactivée dans une instance spécifique en préfixant son nom par le mot-clé « no ». Voir également : « option splice-auto », « option splice-response » et les options globales « nosplice » et « maxpipes » **`option splice-response`** ```haproxy option splice-response no option splice-response ``` Active ou désactive l'accélération automatique du noyau sur les sockets pour les réponses Peut être utilisé dans les contextes suivants : tcp, http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| oui \| oui \| oui Arguments : aucun Lorsque cette option est activée, soit sur un frontal, soit sur un backend, HAProxy utilisera le transfert direct du noyau (tcp splicing) chaque fois que possible pour acheminer les données allant du serveur vers le client. Il peut toutefois recourir au schéma recv/send si aucun canal libre n'est disponible. Cette option nécessite que le transfert direct soit activé lors de la compilation et peut être désactivée globalement via l’option « nosplice ». Étant donné que le transfert direct utilise des canaux, son utilisation suppose la disponibilité de suffisamment de canaux libres. Remarque importante : consultez « option splice-auto » pour les limitations d'utilisation. Exemple : ```text option splice-response ``` Si cette option a été activée dans une section « defaults », elle peut être désactivée dans une instance spécifique en préfixant son nom par le mot-clé « no ». Voir également : « option splice-auto », « option splice-request » et les options globales « nosplice » et « maxpipes » **`option spop-check`** ```haproxy option spop-check ``` Utilisez les contrôles d'état SPOP pour tester les serveurs Peut être utilisé dans les contextes suivants : tcp Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| non \| oui \| oui Arguments : aucun Il est possible de vérifier que le serveur communique correctement selon le protocole SPOP, et non seulement qu'il accepte la connexion TCP. Lorsque cette option est activée, une négociation HELLO est établie entre HAProxy et le serveur, et la réponse est analysée afin de vérifier qu'aucune erreur n'est signalée. Exemple : ```text option spop-check ``` Voir aussi : « option httpchk » **`option srvtcpka`** ```haproxy option srvtcpka no option srvtcpka ``` Activer ou désactiver l'envoi de paquets TCP keepalive côté serveur Peut être utilisé dans les contextes suivants : tcp, http, log Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| non \| oui \| oui Arguments : aucun Lorsqu’un pare-feu ou tout composant sensible à la session se trouve entre un client et un serveur, et que le protocole implique des sessions très longues avec des périodes d’inactivité prolongées (par exemple, les bureaux distants), il existe un risque que l’un des composants intermédiaires décide d’expirer une session restée inactif trop longtemps. Activer les keep-alives TCP au niveau du socket fait que le système envoie régulièrement des paquets à l'autre extrémité de la connexion, la maintenant active. Le délai entre les sondes de keep-alive est contrôlé uniquement par le système et dépend à la fois du système d'exploitation et de ses paramètres de réglage. Il est important de comprendre que les paquets keep-alive ne sont ni émis ni reçus au niveau de l’application. Seuls les piles réseau les perçoivent. Pour cette raison, même si l’une des extrémités du proxy utilise déjà des keep-alive pour maintenir sa connexion active, ces paquets keep-alive ne seront pas transférés à l’autre extrémité du proxy. Veuillez noter que cela n’a rien à voir avec le keep-alive HTTP. L'option « srvtcpka » active l'envoi de sondes TCP keep-alive du côté serveur d'une connexion, ce qui devrait aider à détecter les expiration de session entre HAProxy et un serveur. Si cette option a été activée dans une section « defaults », elle peut être désactivée dans une instance spécifique en préfixant son nom par le mot-clé « no ». Voir aussi : « option clitcpka », « option tcpka » **`option ssl-hello-chk`** ```haproxy option ssl-hello-chk ``` Utilisez les contrôles d'état client hello SSLv3 pour tester les serveurs Peut être utilisé dans les contextes suivants : tcp, http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| non \| oui \| oui Arguments : aucun Lorsque certains protocoles basés sur SSL sont relayés en mode TCP via HAProxy, il est possible de vérifier que le serveur communique correctement en SSL, et non seulement qu’il accepte la connexion TCP. Lorsque l’option ssl-hello-chk est activée, un message client hello SSLv3 pur est envoyé une fois la connexion établie avec le serveur, puis la réponse est analysée afin de détecter un message server hello SSL. Le serveur est considéré comme valide uniquement si la réponse contient ce message server hello. Tous les serveurs ont été testés afin de s'assurer qu'ils répondent correctement aux messages de hello SSLv3, et la plupart des serveurs ne journalisent même pas les requêtes ne contenant que des messages hello, ce qui est appréciable. Notez que ce contrôle fonctionne même lorsque le support SSL n’a pas été inclus dans HAProxy, car il forge le message SSL. Lorsque le support SSL est disponible, il est préférable d’utiliser les contrôles d’état SSL natifs plutôt que celui-ci. Voir aussi : « option httpchk », « check-ssl » **`option tcp-check`** ```haproxy option tcp-check ``` Effectuez les contrôles d'état à l'aide des séquences tcp-check send/expect Peut être utilisé dans les contextes suivants : tcp, http, log Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| non \| oui \| oui Cette méthode de contrôle d'état est destinée à être combinée avec des listes de commandes « tcp-check » afin de prendre en charge des séquences de contrôle d'état de type send/expect. Les contrôles TCP prennent actuellement en charge 4 modes de fonctionnement : - absence de directive « tcp-check » : le contrôle d'état se limite à une tentative de connexion, ce qui constitue le mode par défaut. - « tcp-check send » ou « tcp-check send-binary » est indiqué : cela permet d'envoyer une chaîne lors de l'ouverture d'une connexion. Avec certains protocoles, cela permet d'envoyer un message « QUIT », par exemple, ce qui empêche le serveur de noter une erreur de connexion pour chaque contrôle d'état. Le résultat du contrôle reste fondé uniquement sur la capacité à ouvrir la connexion. - "tcp-check expect" est uniquement mentionné : il sert à tester une bannière. La connexion est établie et HAProxy attend que le serveur présente un contenu qui doit respecter certaines règles. Le résultat de la vérification repose sur la correspondance entre le contenu reçu et les règles définies. Cette fonctionnalité convient aux protocoles POP, IMAP, SMTP, FTP, SSH et TELNET. - à la fois « tcp-check send » et « tcp-check expect » sont mentionnés : cela permet de tester un protocole de type hello. HAProxy envoie un message, le serveur répond et la réponse est analysée. Le résultat de la vérification repose sur la correspondance entre le contenu de la réponse et les règles définies. Cette approche convient souvent aux protocoles qui nécessitent une liaison ou un request/response modèle. LDAP, MySQL, Redis et SSL sont des exemples de tels protocoles, bien qu’ils disposent déjà chacun de leurs vérifications dédiées, qui comprennent une compréhension plus poussée du protocole respectif. En ce mode, plusieurs questions peuvent être envoyées et plusieurs réponses peuvent être analysées. Un cinquième mode peut être utilisé pour insérer des commentaires à différentes étapes du script. Pour chaque règle tcp-check que vous créez, vous pouvez ajouter une directive « comment », suivie d'une chaîne. Cette chaîne sera rapportée dans les journaux et sur stderr en mode débogage. Elle est utile pour faciliter la génération de rapports d'erreurs conviviaux. La directive « comment » est bien entendu facultative. Pendant l'exécution d'un contrôle d'état, une portée de variables est mise à disposition pour stocker des échantillons de données, à l'aide de l'opération « tcp-check set-var ». La libération de ces variables est possible à l'aide de « tcp-check unset-var ». Exemples : ```shell # 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 ``` Voir également : « tcp-check connect », « tcp-check expect » et « tcp-check send ». **`option tcp-smart-accept`** ```haproxy option tcp-smart-accept no option tcp-smart-accept ``` Activer ou désactiver l'enregistrement d'un paquet ACK pendant la séquence d'acceptation Peut être utilisé dans les contextes suivants : tcp, http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| oui \| oui \| non Arguments : aucun Lorsqu'une requête de connexion HTTP arrive, le système l'acquitte en lieu et place de HAProxy, puis le client envoie immédiatement sa requête, que le système acquitte également tout en informant HAProxy de la nouvelle connexion. HAProxy lit ensuite la requête et envoie une réponse. Cela signifie que le système envoie une acknowledgement TCP inutile, car la requête aurait pu être acquittée par HAProxy lorsqu'il envoie sa réponse. Pour cette raison, en mode HTTP, HAProxy demande automatiquement au système d'éviter d'envoyer cet ACK inutile sur les plates-formes qui le supportent (actuellement au moins Linux). Cela ne devrait causer aucun problème, car le système l'envoie quand même après 40 ms si la réponse met plus de temps que prévu à arriver. Lors de sessions de dépannage réseau complexes, il peut être souhaitable de désactiver cette optimisation, car les accusés de réception différés peuvent compliquer le dépannage lorsqu'il s'agit d'identifier où les paquets sont retardés. Il est alors possible de revenir au comportement normal en spécifiant « no option tcp-smart-accept ». Il est également possible de forcer ce comportement pour les proxies non HTTP en spécifiant simplement « option tcp-smart-accept ». Par exemple, cela peut avoir un sens avec certains services tels que SMTP, où le serveur parle en premier. Il est recommandé d'éviter de forcer cette option dans une section defaults. En cas de doute, envisagez de la réinitialiser aux valeurs automatiques en préfixant l'option par le mot-clé default, ou de la désactiver en utilisant le mot-clé no. Voir également : « option tcp-smart-connect » **`option tcp-smart-connect`** ```haproxy option tcp-smart-connect no option tcp-smart-connect ``` Activer ou désactiver la sauvegarde d'un paquet ACK pendant la séquence de connexion Peut être utilisé dans les contextes suivants : tcp, http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| non \| oui \| oui Arguments : aucun Sur certains systèmes (au moins Linux), HAProxy peut demander au noyau de ne pas envoyer immédiatement une accusé de réception vide lors d'une requête de connexion, mais de transmettre directement la requête de tampon à la place. Cela permet d'économiser un paquet sur le réseau et améliore ainsi les performances. Cette fonctionnalité peut également être utile pour certains serveurs, car ils reçoivent immédiatement la requête accompagnant la connexion entrante. Cette fonctionnalité est activée lorsque « option tcp-smart-connect » est définie dans un backend. Elle n’est pas activée par défaut car elle complique le dépannage réseau. Il n’a de sens d’activer cette fonctionnalité que pour les protocoles où le client parle en premier, comme HTTP. Dans les autres cas, si aucune donnée ne peut être envoyée à la place de l’ACK, un ACK normal est transmis. Si cette option a été activée dans une section « defaults », elle peut être désactivée dans une instance spécifique en préfixant son nom par le mot-clé « no ». Voir aussi : « option tcp-smart-accept » **`option tcpka`** ```haproxy option tcpka ``` Activer ou désactiver l'envoi de paquets TCP keepalive des deux côtés Peut être utilisé dans les contextes suivants : tcp, http, log Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| oui \| oui \| oui Arguments : aucun Lorsqu’un pare-feu ou tout composant sensible à la session se trouve entre un client et un serveur, et que le protocole implique des sessions très longues avec des périodes d’inactivité prolongées (par exemple, les bureaux distants), il existe un risque que l’un des composants intermédiaires décide d’expirer une session restée inactif trop longtemps. Activer les keep-alives TCP au niveau du socket fait que le système envoie régulièrement des paquets à l'autre extrémité de la connexion, la maintenant active. Le délai entre les sondes de keep-alive est contrôlé uniquement par le système et dépend à la fois du système d'exploitation et de ses paramètres de réglage. Il est important de comprendre que les paquets keep-alive ne sont ni émis ni reçus au niveau de l’application. Seuls les piles réseau les perçoivent. Pour cette raison, même si l’une des extrémités du proxy utilise déjà des keep-alive pour maintenir sa connexion active, ces paquets keep-alive ne seront pas transférés à l’autre extrémité du proxy. Veuillez noter que cela n’a rien à voir avec le keep-alive HTTP. L’option « tcpka » active l’envoi de sondes TCP keep-alive côté client et côté serveur d’une connexion. Notez que cette option n’a de sens que dans les sections « defaults » ou « listen ». Si cette option est utilisée dans un frontend, seuls les clients recevront des keep-alives ; si elle est utilisée dans un backend, seuls les serveurs recevront des keep-alives. Pour cette raison, il est fortement recommandé d’utiliser explicitement les options « option clitcpka » et « option srvtcpka » lorsque la configuration est répartie entre frontends et backends. Voir aussi : « option clitcpka », « option srvtcpka » **`option tcplog [clf]`** ```haproxy option tcplog [clf] ``` Activer la journalisation avancée des connexions TCP avec l’état du flux et les compteurs Peut être utilisé dans les contextes suivants : tcp, http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| oui \| oui \| non Arguments : ```text clf if the "clf" argument is added, then the output format will be the CLF format instead of HAProxy's default TCP 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. Since this expects an HTTP format some of the values have been pre set. The http request will show as TCP and the response code will show as 000. ``` Par défaut, le format de sortie des journaux est très pauvre, ne contenant que les adresses source et destination, ainsi que le nom de l'instance. En spécifiant « option tcplog », chaque ligne de journal devient beaucoup plus riche, incluant, sans s'y limiter, les compteurs de connexion, l'état du flux, le nombre de connexions, le nom du frontal, du backend et du serveur, ainsi que l'adresse source et les ports. Cette option est utile pour les proxies TCP purs afin de déterminer si c’est le client ou le serveur qui se déconnecte ou expiré. Pour les proxies HTTP normaux, il est préférable d'utiliser « option httplog », qui est encore plus complet. L'option tcplog remplace toute directive précédente log-format. Voir également : « option httplog », et [section 8](/fr/docs/haproxy/configuration-logging/) concernant la journalisation. **`option transparent (deprecated)`** ```haproxy option transparent (deprecated) no option transparent (deprecated) ``` Activer le proxy transparent côté client Peut être utilisé dans les contextes suivants : tcp, http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| non \| oui \| oui Arguments : aucun Cette option a été introduite afin de permettre une persistance au niveau 7 aux répartiteurs de charge au niveau 3. L'idée consiste à utiliser la capacité du système d'exploitation à rediriger une connexion entrante provenant d'une adresse distante vers un processus local (ici HAProxy), et à faire en sorte que ce processus connaisse l'adresse initialement demandée. Lorsque cette option est utilisée, les sessions sans cookies seront acheminées vers l'adresse IP d'origine de la requête entrante (qui doit correspondre à celle d'un autre équipement), tandis que les requêtes avec cookies seront toujours acheminées vers le serveur approprié. Notez qu’en dépit d’une croyance répandue, cette option ne fait pas que HAProxy présente l’adresse IP du client au serveur lors de l’établissement de la connexion. À compter de la version 3.3, cette option est désormais obsolète car elle était sujet à plusieurs limitations techniques internes. Son utilisation génère un avertissement, qui peut être évité si nécessaire via le mot-clé global « expose-deprecated-directives ». L’approche correcte consiste à déclarer un serveur sur l’adresse 0.0.0.0, qui s’occupera de la connexion à l’adresse cible attendue. Un serveur gérera également correctement les connexions inactives vers les serveurs cibles. Exemple : ```shell # option transparent ## before 3.3 server transparent 0.0.0.0 ``` Voir également : l'argument « usesrc » du mot-clé « source », et l'option « transparent » du mot-clé « bind ». option use-small-buffers [ queue \| l7-retries \| check ]* Activer la prise en charge des tampons de petite taille pour les catégories données. Peut être utilisé dans les contextes suivants : tcp, http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| non \| oui \| oui Cette option peut être utilisée pour activer le support des petits tampons à divers emplacements afin de réduire la consommation de mémoire. Par défaut, sans paramètre, les petits tampons sont utilisés autant que possible à tous les emplacements possibles. Sinon, il est possible de les limiter aux emplacements suivants : - queue : Lorsqu'il est défini, des tampons de petite taille seront utilisés pour stocker les requêtes, si elles sont suffisamment petites, lorsque la connexion est mise en file d'attente. - l7-retries : Lorsqu'il est défini, des tampons de petite taille seront utilisés pour sauvegarder les requêtes lorsque les réessais L7 sont activés. - check : Lorsqu'il est défini, des tampons de petite taille seront utilisés pour les requêtes de vérification de santé. Lorsqu’il est activé, des tampons de petite taille sont utilisés, mais uniquement si cela est possible. Sinon, lorsque les données sont trop grandes, un tampon régulier est automatiquement utilisé. La taille des tampons de petite taille est configurable via le paramètre global "tune.bufsize.small". Si cette option a été activée dans une section « defaults », elle peut être désactivée dans une instance spécifique en préfixant son nom par le mot-clé « no ». Voir aussi : tune.bufsize.small **`persist rdp-cookie`** ```haproxy persist rdp-cookie persist rdp-cookie() ``` Activer la persistance basée sur les cookies RDP Peut être utilisé dans les contextes suivants : tcp Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| non \| oui \| oui Arguments : ```text 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. ``` Cette instruction active la persistance basée sur un cookie RDP. Le cookie RDP contient toutes les informations nécessaires pour identifier le serveur dans la liste des serveurs connus. Ainsi, lorsque cette option est configurée dans le backend, la requête est analysée ; si un cookie RDP est détecté, il est décodé. Si ce cookie correspond à un serveur connu qui est toujours actif (ou si l’option persist est définie), la connexion est acheminée vers ce serveur. Notez que cela n’a de sens que dans un backend TCP, mais pour que cela fonctionne, le frontal doit avoir attendu suffisamment longtemps pour garantir la présence d’un cookie RDP dans le tampon de la requête. Il s’agit de la même exigence que pour la méthode de répartition de charge « rdp-cookie ». Il est donc fortement recommandé de regrouper toutes les directives dans une seule section « listen ». En outre, il est important de comprendre que le serveur terminal émettra ce cookie RDP uniquement s’il est configuré en mode « redirection de jeton », ce qui signifie que l’option « redirection de l’adresse IP » est désactivée. Exemple : ```text 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 ``` Voir également : « balance rdp-cookie », « tcp-request » et l'ACL "req.rdp_cookie". **`quic-initial [ { if | unless } ]`** ```haproxy quic-initial [ { if | unless } ] ``` Effectuer une action sur un paquet Initial QUIC entrant. Contrairement à « tcp-request connection », cette directive est exécutée avant toute instanciation d'élément de connexion, avant le démarrage et la finalisation de l'échange SSL, ce qui est plus efficace lorsqu'il s'agit de rejeter des tentatives de connexion. Peut être utilisé dans les contextes suivants : http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui(!) \| oui \| oui \| non Arguments : ```text defines the action to perform if the condition applies. See below. is a standard layer4-only ACL-based condition (see section 7). However, QUIC initial rules are executed too early even for some layer4 sample fetch methods despite no configuration warning and may result in unspecified runtime behavior, although they will not crash. Consider that only internal samples and layer4 "src*" and "dst*" are considered as supported for now. ``` Cette action est exécutée tôt lors de l'analyse des paquets QUIC. En conséquence, seule une liste minimale d'actions est prise en charge : - accept - dgram-drop - reject - send-retry **`rate-limit sessions `** ```haproxy rate-limit sessions ``` Fixez une limite au nombre de nouvelles sessions acceptées par seconde sur un frontal Peut être utilisé dans les contextes suivants : tcp, http Peut être utilisé dans les sections : defaults \| frontal \| listen \| backend oui \| oui \| oui \| non Arguments : ```text The parameter is an integer designating the maximum number of new sessions per second to accept on the frontend. ``` Lorsque le frontal atteint le nombre spécifié de nouvelles sessions par seconde, il cesse d'accepter de nouvelles connexions jusqu'à ce que le taux redescende en dessous de la limite. Pendant cette période, les sessions en attente seront conservées dans la file d'attente du socket (dans les tampons système), et HAProxy ne sera même pas au courant de l'existence de ces sessions en attente. Lorsqu'on applique une limite très faible sur un service fortement sollicité, il peut être pertinent d'augmenter la taille de la file d'attente du socket en utilisant le mot-clé « backlog ». Cette fonctionnalité est particulièrement efficace pour bloquer les attaques basées sur les connexions ou l’abus de service sur des serveurs sensibles. Comme le taux de session est mesuré toutes les millisecondes, il est extrêmement précis. De plus, la limite s’applique immédiatement, aucune attente n’est nécessaire pour détecter le seuil. Exemple : limiter le débit des connexions SMTP à 10 par seconde au maximum écoute smtp mode tcp bind :25 taux-limité sessions 10 serveur smtp1 127.0.0.1:1025 Note : lorsque le débit maximal est atteint, l'état du frontal n'est pas modifié, mais ses sockets apparaissent comme « EN ATTENTE » dans les statistiques si l'option « socket-stats » est activée. Voir également : le mot-clé « backlog » et le critère ACL "fe_sess_rate". **`redirect location [code ]