# 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 [``] [ from `` ] - frontend `` [ from `` ] - backend `` [ from `` ] - listen `` [ from `` ] 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 frontend et backend regroupées dans une même section. Elle est généralement utile pour le trafic TCP uniquement. Une section « defaults » réinitialise tous 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, basculant, 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 circulant 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 est seulement possible de savoir 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 : Certaines 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 mot-clé 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 -- mot-clé -------------------------- 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 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 - -- mot-clé -------------------------- 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 -- mot-clé -------------------------- 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 -- mot-clé -------------------------- 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 -- mot-clé -------------------------- 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 ------------------------------------+----------+----------+---------+--------- mot-clé 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 \| frontend \| 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 \| frontend \| listen \| backend oui \| oui \| oui \| non Arguments : ```text est le nombre de connexions en attente. Selon le système d'exploitation, il peut s'agir des connexions déjà acquittées, des connexions non acquittées, ou des deux. ``` 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 de main actives et le nombre de connexions en attente d'acceptation. La phase de poignée de main 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 \| frontend \| listen \| backend oui \| non \| oui \| oui Arguments : ```text est l'algorithme de sélection du serveur pour la répartition de charge. Il s'applique seulement lorsqu'aucune information de persistance n'est disponible ou lorsqu'une connexion est redistribuée vers un autre serveur. Valeurs de : roundrobin Chaque serveur est utilisé à tour de rôle, selon son poids. C'est l'algorithme le plus régulier et le plus équitable si les temps de traitement des serveurs restent uniformément répartis. Il est dynamique : les poids peuvent être ajustés à la volée, par exemple pour un démarrage progressif. Sa conception le limite à 4095 serveurs actifs par backend. Dans certains grands groupes de serveurs, un serveur redevenu disponible après une très brève indisponibilité peut attendre quelques centaines de requêtes avant d'être réintégré et de recevoir du trafic. Ce comportement est normal, mais très rare ; il est signalé pour éviter toute inquiétude si vous l'observez. Les poids sont ignorés pour les backends en mode LOG. static-rr Chaque serveur est utilisé à tour de rôle, selon son poids. Cet algorithme ressemble à roundrobin, mais il est statique : modifier un poids à la volée n'a aucun effet. En revanche, sa conception ne limite pas le nombre de serveurs. Lorsqu'un serveur redevient disponible, il est immédiatement réintégré une fois la table complète recalculée. L'algorithme consomme également un peu moins de CPU (environ -1%). Il ne peut pas être utilisé en mode LOG. leastconn Le serveur ayant le moins de connexions reçoit la connexion. Une sélection à tour de rôle au sein des groupes de même charge garantit l'utilisation de tous les serveurs. Cet algorithme convient aux sessions très longues, comme LDAP, SQL ou TSE, mais peu aux protocoles à sessions courtes comme HTTP. Il est dynamique : les poids peuvent être ajustés à la volée, par exemple pour un démarrage progressif. Il prend aussi en compte les connexions en file d'attente, en plus de celles établies, afin de réduire l'attente. Il ne peut pas être utilisé en mode LOG. first Le premier serveur ayant une place de connexion disponible reçoit la connexion. Les serveurs sont parcourus par ordre croissant d'identifiant numérique (paramètre serveur "id"), qui correspond par défaut à leur position dans le groupe. Dès qu'un serveur atteint maxconn, le suivant est utilisé. Cet algorithme n'a pas de sens sans maxconn. Il vise à utiliser le moins de serveurs possible pour pouvoir éteindre les autres aux heures creuses. Il ignore le poids et profite davantage aux sessions longues, comme RDP ou IMAP, qu'à HTTP, bien qu'il puisse y être utile aussi. Pour l'utiliser efficacement, un contrôleur cloud devrait vérifier régulièrement l'utilisation des serveurs pour éteindre ceux inutilisés, ainsi que la file du backend pour en démarrer d'autres lorsqu'elle grossit. "http-check send-state" peut aussi informer les serveurs de la charge. Cet algorithme ne peut pas être utilisé en mode LOG. hash Prend une expression d'échantillon ordinaire en argument. Elle est évaluée pour chaque requête, puis hachée selon hash-type. Le résultat est divisé par le poids total des serveurs disponibles pour désigner le serveur destinataire. Il peut remplacer "source", "uri", "hdr()", "url_param()" ou "rdp-cookie" pour utiliser un convertisseur, affiner l'évaluation ou extraire des variables locales, par exemple. Si les données ne sont pas disponibles, la sélection se fait à tour de rôle. Par défaut, il est statique : modifier un poids à la volée n'a aucun effet, mais "hash-type" permet de changer ce comportement. Pour les backends en mode LOG, utilisez "log-hash" à sa place. source L'adresse IP source est hachée, puis divisée par le poids total des serveurs disponibles pour désigner le serveur destinataire. Une même IP cliente rejoint ainsi toujours le même serveur tant qu'aucun serveur ne devient indisponible ou disponible. Si le nombre de serveurs change et modifie le résultat du hachage, de nombreux clients changent de serveur. Cet algorithme sert généralement en mode TCP, où aucun cookie ne peut être inséré. Sur Internet, il peut fournir une affinité sans garantie aux clients refusant les cookies de session. Par défaut, il est statique : modifier un poids à la volée n'a aucun effet, mais "hash-type" permet de changer ce comportement. Voir aussi "hash". Il ne peut pas être utilisé pour les backends en mode LOG. uri Hache la partie gauche de l'URI (avant le point d'interrogation) ou l'URI entière si "whole" est présent, puis divise ce hachage par le poids total des serveurs disponibles. Le résultat désigne le serveur destinataire. Une même URI rejoint toujours le même serveur tant qu'aucun serveur ne devient disponible ou indisponible. Les caches de proxy et les proxies antivirus l'utilisent pour maximiser le taux de succès du cache. Il ne peut servir que dans un backend HTTP. Par défaut, il est statique : modifier un poids à la volée n'a aucun effet, mais "hash-type" permet de changer ce comportement. Il accepte les paramètres facultatifs "len" et "depth", chacun suivi d'un entier positif. Ils permettent de répartir la charge selon le début de l'URI seulement. "len" limite le calcul du hachage à ce nombre de caractères au début de l'URI. Une valeur de "len" de 1 est rarement pertinente, car la plupart des URI commencent par "/". "depth" définit la profondeur maximale de répertoires prise en compte. Chaque barre oblique compte pour un niveau. Si les deux paramètres sont présents, l'évaluation s'arrête dès que l'une des deux limites est atteinte. "path-only" fait commencer la clé de hachage au premier '/' du chemin. Cela ignore la partie authority des URI absolues et garantit le même hachage pour les URI HTTP/1 et HTTP/2. Voir aussi "hash" ci-dessus. url_param Recherche le paramètre d'URL fourni en argument dans la chaîne de requête de chaque requête HTTP GET. Avec "check_post", si le paramètre n'est pas trouvé après le point d'interrogation ('?') de l'URL, il est recherché dans l'entité d'une requête HTTP POST. Le corps n'est analysé qu'après réception de la quantité de données annoncée ou lorsque le tampon de requête est plein. Si le codage par blocs est utilisé, cas peu probable, seul le premier bloc est parcouru. Une valeur de paramètre coupée entre deux blocs peut être répartie aléatoirement, voire pas du tout. L'ancien paramètre facultatif est désormais ignoré. Si le paramètre est suivi de '=' et d'une valeur, celle-ci est hachée, puis divisée par le poids total des serveurs disponibles. Le résultat désigne le serveur destinataire. Cela suit les identifiants utilisateur dans les requêtes et garantit qu'un même ID rejoint toujours le même serveur tant qu'aucun serveur ne devient disponible ou indisponible. Si le paramètre ou sa valeur est absent, la sélection se fait à tour de rôle. Cet algorithme est réservé aux backends HTTP. Par défaut, il est statique : modifier un poids à la volée n'a aucun effet, mais "hash-type" permet de changer ce comportement. Voir aussi "hash" ci-dessus. hdr() Recherche l'en-tête HTTP dans chaque requête HTTP. Comme pour la fonction ACL 'hdr()', le nom entre parenthèses n'est pas sensible à la casse. Si l'en-tête ou sa valeur est absent, l'algorithme roundrobin est utilisé. Le paramètre facultatif 'use_domain_only' réduit le hachage au domaine principal pour certains en-têtes, comme 'Host'. Ainsi, dans "haproxy.1wt.eu", seul "1wt" est pris en compte. Par défaut, il est statique : modifier un poids à la volée n'a aucun effet, mais "hash-type" permet de changer ce comportement. Voir aussi "hash" ci-dessus. random random() Un nombre aléatoire sert de clé au hachage cohérent. Les poids des serveurs sont donc respectés ; leur modification dynamique et l'ajout de serveurs prennent effet immédiatement. Cette répartition convient aux grands groupes ou aux ajouts et retraits fréquents, car elle peut éviter les afflux brutaux de requêtes produits par roundrobin ou leastconn dans ces situations. hash-balance-factor peut améliorer l'équité, surtout si les temps de réponse varient beaucoup. , s'il est présent, est un entier supérieur ou égal à un : il indique le nombre de tirages avant de sélectionner le serveur le moins chargé parmi les serveurs tirés. Choisir le moins chargé de deux serveurs suffit à améliorer nettement l'équité : cela évite toujours le serveur le plus chargé et supprime les biais de répartition de la liste cohérente. Avec une valeur N plus élevée, N-1 des serveurs les plus chargés sont écartés, au prix des performances. Pour des valeurs très élevées, le résultat tend vers celui de leastconn, mais bien plus lentement. Dans les grands groupes peu chargés ou parfaitement équilibrés, les charges sont souvent égales. Si tous les serveurs examinés ont la même charge, leur taux de requêtes sur la dernière seconde est comparé : cela équilibre l'utilisation au fil du temps, comme roundrobin, et atténue les inégalités du hachage cohérent. La valeur par défaut est 2, généralement efficace et bien répartie. Pour les grands groupes peu chargés (moins de quelques requêtes par seconde et par serveur), 3 ou 4 peut être préférable. Cet algorithme, appelé Power of Two Random Choices, est décrit ici : http://www.eecs.harvard.edu/~michaelm/postscripts/handbook2001.pdf Pour les backends en mode LOG, le nombre de tirages est ignoré et un seul tirage est effectué, car la notion de charge n'y existe pas. Cette répartition convient aux grands groupes ou aux ajouts et retraits fréquents du pool disponible, car elle peut éviter les afflux brutaux produits par roundrobin. rdp-cookie rdp-cookie() Recherche et hache le cookie RDP (ou "mstshash" si le nom est absent) pour chaque requête TCP entrante. Comme pour la fonction ACL 'req.rdp_cookie()', le nom n'est pas sensible à la casse. C'est une persistance dégradée permettant d'envoyer le même utilisateur ou ID de session au même serveur. Si le cookie est absent, roundrobin est utilisé. Le frontend doit garantir que le cookie RDP est déjà dans le tampon de requête. Utilisez pour cela une règle 'tcp-request content accept' avec une ACL 'req.rdp_cookie_cnt'. Par défaut, il est statique : modifier un poids à la volée n'a aucun effet, mais "hash-type" permet de changer ce comportement. Voir aussi "hash" ci-dessus. log-hash Prend une liste de convertisseurs séparés par des virgules. Ils sont appliqués successivement au message de journal, puis le résultat est converti en chaîne et haché selon hash-type. Ce hachage sélectionne le serveur destinataire parmi ceux du backend de journalisation. Le but est d'extraire une clé du message final avec des convertisseurs de chaînes, puis de conserver le même serveur grâce au hachage. Seuls les hachages "map-based" sont pris en charge. Réservé aux backends en mode LOG ; ailleurs, utilisez "hash". sticky Tente de conserver le même serveur aussi longtemps que possible. Le premier serveur disponible reçoit tous les messages de journal. S'il passe à DOWN, le suivant prend sa place. Un serveur précédemment DOWN qui repasse à UP est ajouté à la fin de la liste : le serveur utilisé ne change donc que lorsqu'il passe à DOWN. est une liste facultative d'arguments nécessaires à certains algorithmes. Seuls "url_param", "uri" et "log-hash" prennent actuellement en charge un argument facultatif. ``` 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. - L'en-tête « Expect: 100-continue » n'est pas pris 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, l'utilisation de "check_post" peut tenter de scanner l'intégralité du 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 ``` Indique au backend de démarrer dans l'état non publié. Peut être utilisé dans les contextes suivants : tcp, http, log Peut être utilisé dans les sections : defaults \| frontend \| 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. Ce 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éfinir 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 \| frontend \| listen \| backend non \| oui \| oui \| non Arguments : ```text
est facultatif : nom d'hôte, adresse IPv4, adresse IPv6 ou '*'. Il désigne l'adresse d'écoute du frontend. Sans valeur, toutes les adresses IPv4 du système sont écoutées, comme avec '*' ou l'adresse spéciale "0.0.0.0". L'équivalent IPv6 est '::'. Pour UDP, l'écoute sur plusieurs adresses nécessite des fonctions de l'OS assurant la bonne interface et la bonne adresse source dans les réponses. Pour les listeners QUIC, n'écoutez plusieurs adresses que sur un système assez récent. Un préfixe facultatif peut imposer la famille d'adresses, quel que soit le format. Cela permet notamment un chemin de socket unix sans barre oblique ('/'). Préfixes pris en charge : - 'ipv4@' -> toujours une adresse IPv4. - 'ipv6@' -> toujours une adresse IPv6. - 'udp@' -> résolution IPv4 ou IPv6, protocole UDP. Ces listeners sont actuellement réservés à log-forward. - 'udp4@' -> toujours IPv4, protocole UDP. Ces listeners sont actuellement réservés à log-forward. - 'udp6@' -> toujours IPv6, protocole UDP. Ces listeners sont actuellement réservés à log-forward. - 'unix@' -> chemin d'un socket unix local. - 'abns@' -> espace de noms abstrait (Linux seulement). - 'abnsz@' -> espace de noms abstrait (Linux seulement), explicitement terminé par zéro. Aucun remplissage \0 ne complète sun_path. Cela facilite l'interconnexion avec les programmes n'implémentant pas la convention de nommage abns utilisée par haproxy. - 'fd@' -> descripteur hérité du parent. Il doit être lié à une adresse et peut déjà être en écoute ou non. - 'sockpair@' -> comme fd@, mais avec le descripteur d'un socket unix connecté ou d'une socketpair. Le bind attend un FD sur le socket unix et l'utilise comme un FD obtenu par accept(). À utiliser avec prudence. - 'quic4@' -> résolution IPv4, protocole UDP. Pour les meilleures performances sous forte charge, conservez "tune.quic.fe.sock-per-conn default-on". Sinon les connexions QUIC seront multiplexées sur le socket d'écoute. On peut aussi dupliquer les listeners QUIC sur plusieurs threads, par exemple avec "shards", pour au moins réduire la contention des threads. - 'quic6@' -> résolution IPv6, protocole UDP. La remarque sur les performances QUIC en IPv4 s'applique aussi ici. - 'rhttp@' [ EXPERIMENTAL ] -> HTTP inversé. L'adresse doit être un serveur au format '/'. Il sert à établir les connexions vers une adresse distante. Le listener tente de maintenir "nbconn" connexions. Cette fonction expérimentale exige une ligne "expose-experimental-directives" avant ce bind. Des variables d'environnement peuvent être référencées dans l'adresse ; voir la section 2.3 sur ces variables. est un port TCP unique ou une plage de ports sur lesquels le proxy accepte les connexions pour l'adresse IP ci-dessus. Le port est obligatoire pour les listeners TCP. Avec IPv6, c'est toujours le nombre après le dernier deux-points (':'). Une plage peut être : - un port numérique, par exemple '80' ; - une plage séparée par un tiret, avec bornes basse et haute explicites et incluses, par exemple '2000-2100'. Attention aux plages : chaque paire consomme un socket (= un descripteur de fichier). Une simple plage peut donc consommer beaucoup de descripteurs et épuiser les sockets. Chaque paire doit aussi être utilisée une seule fois parmi toutes les instances d'un même système. Les ports inférieurs à 1024 exigent généralement des privilèges de démarrage particuliers, indépendants du paramètre 'uid'. est un chemin de socket UNIX commençant par '/'. Il remplace le port d'écoute TCP. HAProxy reçoit alors les connexions UNIX sur le socket à cet emplacement. Le chemin doit commencer par une barre oblique et est absolu par défaut. Il peut être relatif au préfixe "unix-bind" de la section global. La longueur totale du préfixe et du chemin ne peut pas dépasser les limites système des sockets UNIX, généralement 107 caractères. est une liste de paramètres communs à tous les sockets de la même ligne. Ces nombreux paramètres dépendent de l'OS et des options de compilation de HAProxy ; une section entière leur est consacrée. Voir la section 5 pour les détails. ``` 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 ``` Capturer et enregistrer 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 \| frontend \| listen \| backend non \| oui \| oui \| non Arguments : ```text est le début du nom du cookie à capturer. Pour un nom exact, ajoutez simplement '=' à la fin. Le nom complet figure dans les journaux, ce qui est utile pour les serveurs d'application ajustant le nom et la valeur du cookie (par exemple ASPSESSIONXXX). est le nombre maximal de caractères dans les journaux, incluant le nom du cookie, le signe égal et la valeur au format "name=value". La chaîne est tronquée à droite si elle dépasse . ``` 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 peuvent généralement 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, un « - » est indiqué 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 request header », « capture response header » ainsi que la section [8](/fr/docs/haproxy/configuration-logging/) concernant la journalisation. **`capture request header len `** ```haproxy capture request header len ``` Capturer et enregistrer 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 \| frontend \| listen \| backend non \| oui \| oui \| non Arguments : ```text est le nom de l'en-tête à capturer. Les noms ne sont pas sensibles à la casse, mais on les écrit généralement comme dans les requêtes, avec une majuscule au début de chaque mot. Le nom n'apparaît pas dans les journaux : seule la valeur y figure, en conservant sa position dans le journal. est le nombre maximal de caractères à extraire de la valeur et à inscrire dans les journaux. La chaîne est tronquée à droite si elle dépasse . ``` 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" lorsque les téléversements sont 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. Soyez donc prudent quant à ce que vous journalisez, 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 sage 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 response header » ainsi que la [section 8](/fr/docs/haproxy/configuration-logging/) concernant la journalisation. **`capture response header len `** ```haproxy capture response header len ``` Capturer et enregistrer 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 \| frontend \| listen \| backend non \| oui \| oui \| non Arguments : ```text est le nom de l'en-tête à capturer. Les noms ne sont pas sensibles à la casse, mais on les écrit généralement comme dans les réponses, avec une majuscule au début de chaque mot. Le nom n'apparaît pas dans les journaux : seule la valeur y figure, en conservant sa position dans le journal. est le nombre maximal de caractères à extraire de la valeur et à inscrire dans les journaux. La chaîne est tronquée à droite si elle dépasse . ``` 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 sage 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 request header », ainsi que la [section 8](/fr/docs/haproxy/configuration-logging/) concernant la journalisation. **`clitcpka-cnt `** ```haproxy clitcpka-cnt ``` Définit le nombre maximal de sondes 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 \| frontend \| listen \| backend oui \| oui \| oui \| non Arguments : ```text est le nombre maximal de sondes keepalive. ``` 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 inactive 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 \| frontend \| listen \| backend oui \| oui \| oui \| non Arguments : ```text est la durée d'inactivité avant que TCP commence à envoyer des sondes keepalive. L'unité par défaut est la seconde. Une autre unité peut suivre le nombre, comme expliqué au début de ce 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 \| frontend \| listen \| backend oui \| oui \| oui \| non Arguments : ```text est l'intervalle entre les sondes keepalive. L'unité par défaut est la seconde. Une autre unité peut suivre le nombre, comme expliqué au début de ce 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 \| frontend \| listen \| backend oui \| oui \| oui \| oui Arguments : ```text algo est suivi de la liste des algorithmes de compression pris en charge pour les réponses (ancien mot-clé). algo-req est suivi de l'algorithme de compression des requêtes (un seul peut être fourni). algo-res est suivi de la liste des algorithmes de compression des réponses. type est suivi de la liste des types MIME à compresser dans les réponses (ancien mot-clé). type-req est suivi de la liste des types MIME à compresser dans les requêtes. type-res est suivi de la liste des types MIME à compresser dans les réponses. ``` Les algorithmes actuellement pris en charge sont : ```text identity Sert surtout au débogage et a été utile au développement de la compression. Identity ne modifie aucune donnée. gzip Applique la compression gzip. Disponible seulement si zlib ou libslz a été inclus à la compilation. deflate Comme "gzip", mais avec l'algorithme deflate et le format zlib. Sa prise en charge est ambiguë dans de nombreux navigateurs et absente des navigateurs récents. Son usage est fortement déconseillé sauf pour des expériences. Disponible seulement si zlib ou libslz a été inclus à la compilation. raw-deflate Comme "deflate", sans l'enveloppe zlib ; sert d'alternative lorsque le navigateur demande "deflate". Tous les principaux navigateurs le comprennent. Bien qu'il enfreigne les normes, il fonctionne mieux que "deflate", au moins avec MSIE et certaines versions de Safari. N'utilisez pas "deflate" et raw-deflate ensemble : choisissez l'un ou l'autre, car ils répondent au même jeton Accept-Encoding. Disponible seulement si zlib ou libslz a été inclus à la compilation. ``` 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 « compression offload ») - 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 que la compression soit appliquée. Peut être utilisé dans les contextes suivants : http Peut être utilisé dans les sections : defaults \| frontend \| listen \| backend oui \| oui \| oui \| oui Les charges utiles 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 que déchargeur de compression uniquement. Peut être utilisé dans les contextes suivants : http Peut être utilisé dans les sections : defaults \| frontend \| 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. Il est alors recommandé d'utiliser l'option « offload » 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 l'ancien filtre « filter compression » était activé, car avec les filtres explicites 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 ]* ``` Activer 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 \| frontend \| listen \| backend oui \| non \| oui \| oui Arguments : ```text est le nom du cookie surveillé, modifié ou inséré pour assurer la persistance. Il est envoyé au client par "Set-Cookie" dans la réponse et renvoyé dans "Cookie" avec toutes les requêtes. Choisissez un nom sans conflit avec les cookies de l'application. Si les mêmes clients utilisent plusieurs backends (HTTP/HTTPS, par exemple), utilisez des noms distincts si la persistance ne doit pas s'étendre d'un backend à l'autre. rewrite Le serveur fournit le cookie et HAProxy en modifie la valeur pour y inscrire l'identifiant du serveur. Ce mode est utile lorsque l'application gère les combinaisons complexes de "Set-cookie" et "Cache-control" et décide quand émettre un cookie de persistance. Toutes les réponses devant être surveillées, il ne fonctionne pas en mode tunnel HTTP. Sauf application très complexe ou défectueuse, ce mode est déconseillé pour un nouveau déploiement. Incompatible avec "insert" et "prefix". insert HAProxy insère le cookie de persistance dans la réponse du serveur si le client n'a pas déjà un cookie lui permettant d'accéder à ce serveur. Sans "preserve", tout cookie du même nom émis par le serveur est supprimé avant le traitement. Ce mode permet donc de faire évoluer une configuration utilisant "rewrite". Le cookie est un cookie de session, non stocké sur le disque du client. Par défaut, sans "indirect", le serveur voit les cookies émis par le client. En raison des effets du cache, il est généralement prudent d'ajouter "nocache" ou "postonly" (ci-dessous). "insert" est incompatible avec "rewrite" et "prefix". prefix Complète un cookie existant au lieu d'utiliser un cookie dédié à la persistance. Cela peut servir si le client ne prend en charge qu'un seul cookie, déjà nécessaire à l'application. Lorsque le serveur définit le cookie , son identifiant et un séparateur sont ajoutés en préfixe. Ce préfixe est retiré de toutes les requêtes clientes : le serveur retrouve son cookie original. Toutes les requêtes et réponses devant être modifiées, ce mode ne fonctionne pas en mode tunnel. "prefix" est incompatible avec "rewrite" et "insert". L'association de "indirect" et "prefix" est fortement déconseillée : les mises à jour du cookie par le serveur ne seraient pas envoyées aux clients. indirect Aucun cookie n'est émis vers un client qui possède déjà un cookie valide pour le serveur ayant traité la requête. Si ce serveur émet lui-même ce cookie, il est supprimé, sauf avec "preserve". En mode "insert", les cookies sont aussi retirés des requêtes transmises au serveur, rendant la persistance entièrement transparente pour l'application. L'association de "indirect" et "prefix" est fortement déconseillée : les mises à jour du cookie par le serveur ne seraient pas envoyées aux clients. nocache Recommandé avec insert lorsqu'un cache sépare le client de HAProxy. Une réponse normalement admissible au cache est marquée comme non admissible si un cookie doit être inséré. Sans cela, si les cookies de persistance sont ajoutés à une page d'accueil mise en cache, par exemple, tous les clients obtiennent le même cookie depuis ce cache externe et un serveur reçoit beaucoup plus de trafic que les autres. Voir aussi "insert" et "postonly". postonly Insère les cookies uniquement dans les réponses aux requêtes POST. C'est une alternative à "nocache" : les réponses POST ne pouvant être mises en cache, le cookie de persistance ne le sera jamais. La plupart des sites ne nécessitent aucune persistance avant le premier POST, généralement une connexion utilisateur. Cette méthode optimise donc efficacement le cache sans risquer d'y retrouver un cookie de persistance. Voir "insert" et "nocache". preserve Utilisable seulement avec "insert" et/ou "indirect". Autorise le serveur à émettre lui-même le cookie de persistance. Si un cookie est trouvé dans la réponse, HAProxy le laisse intact. Cela permet par exemple de terminer la persistance après une déconnexion : le serveur émet une valeur invalide (par exemple vide) ou une date passée. Avec l'option de contrôle "disable-on-404", on peut arrêter entièrement un serveur en douceur, car les utilisateurs le quitteront définitivement après leur déconnexion. httponly Ajoute l'attribut "HttpOnly" au cookie inséré. L'agent utilisateur ne partage ainsi pas ce cookie avec les composants non HTTP. Voir RFC6265 pour les détails. secure Ajoute l'attribut "Secure" au cookie inséré. L'agent utilisateur ne l'envoie jamais sur un canal non sécurisé : un cookie reçu avec cet attribut n'est présenté que sur des connexions SSL/TLS. Voir RFC6265 pour les détails. domain Définit le domaine du cookie inséré. Exige exactement un paramètre : un nom de domaine valide. Si ce nom commence par un point, le navigateur peut utiliser le cookie pour tout hôte se terminant par ce nom. Plusieurs domaines peuvent être définis en répétant l'option. Certains navigateurs limitent leur nombre : soyez prudent. À titre indicatif, 10 domaines fonctionnent comme prévu avec MSIE 6 ou Firefox 2. maxidle Ignore les cookies insérés après une durée d'inactivité. Fonctionne seulement en mode insert. La date d'émission est envoyée avec le cookie. Lorsqu'il est présenté à nouveau, si cette date est plus ancienne que le délai indiqué en secondes, le cookie est ignoré. Sinon il est renouvelé si nécessaire dans la réponse. Cela évite que les utilisateurs ne fermant jamais leur navigateur restent trop longtemps sur le même serveur, après un changement de taille du groupe, par exemple. Un cookie sans date est toujours accepté, mais renouvelé dans la réponse, préservant l'accès des administrateurs à leurs sites. Une date dépassant de plus de 24 heures l'heure actuelle fait ignorer le cookie. Les administrateurs peuvent ainsi corriger les problèmes de fuseau horaire sans risquer d'exclure les utilisateurs du site. maxlife Ignore les cookies insérés après une durée de vie donnée, qu'ils soient utilisés ou non. Fonctionne seulement en mode insert. La date de première émission est envoyée avec le cookie. S'il est présenté à nouveau avec une date plus ancienne que le délai en secondes, il est ignoré. Sans date, il est accepté et reçoit une date. Les dates dépassant de plus de 24 heures l'heure actuelle font ignorer le cookie, permettant de corriger les fuseaux horaires sans exclure les utilisateurs. Contrairement à maxidle, la valeur n'est pas renouvelée : seule la première visite compte. maxidle et maxlife peuvent être employés ensemble. Cela évite notamment que les utilisateurs ne fermant jamais leur navigateur restent trop longtemps sur le même serveur après un changement du groupe. Plus strict que maxidle, maxlife impose une redistribution après un délai absolu. dynamic Active les cookies dynamiques. Un cookie de session est créé pour chaque serveur à partir de son IP, de son port et de la clé secrète définie par "dynamic-cookie-key" dans le backend. Il est régénéré à chaque changement d'IP et seulement pour IPv4/IPv6. attr Ajoute un attribut supplémentaire au cookie inséré. Sa valeur accepte tous les caractères sauf les caractères de contrôle et ";". Cette option peut être répétée. ``` 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 un emplacement de capture. Peut être utilisé dans les contextes suivants : tcp, http Peut être utilisé dans les sections : defaults \| frontend \| listen \| backend non \| oui \| oui \| non Arguments : ```text est la longueur autorisée pour la 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 un emplacement de capture destiné à être utilisé dans la requête, et le mot-clé « response » alloue un emplacement de capture destiné à être utilisé 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 \| frontend \| listen \| backend oui \| non \| oui \| oui Arguments : ```text est la liste des paramètres de ce serveur. "default-server" accepte de nombreuses options, détaillées dans une section complète. Voir la section 5 pour les détails. ``` 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écifier le backend à utiliser lorsqu'aucune règle « use_backend » n'a correspondu. Peut être utilisé dans les contextes suivants : tcp, http Peut être utilisé dans les sections : defaults \| frontend \| listen \| backend oui \| oui \| oui \| non Arguments : ```text est le nom du backend à utiliser. ``` Lorsque l'on effectue une commutation 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écrire un écouteur, un frontal ou un backend. Peut être utilisé dans les contextes suivants : tcp, http, log Peut être utilisé dans les sections : defaults \| frontend \| 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ésactiver un proxy, un frontal ou un backend. Peut être utilisé dans les contextes suivants : tcp, http, log Peut être utilisé dans les sections : defaults \| frontend \| 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 aucun trafic et n'enverra ni contrôles d'état ni 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 la commutation 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 \| frontend \| listen \| backend non \| non \| oui \| oui Arguments : ```text
est l'adresse IPv4 du serveur par défaut. Un nom d'hôte résolvable est aussi accepté, mais sera résolu au démarrage. est un port obligatoire. Toutes les connexions y sont envoyées. Les décalages de port, possibles avec les serveurs ordinaires, ne sont pas autorisés ici. ``` 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 répartiteur de charge 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 de cookie dynamique pour un backend. Peut être utilisé dans les contextes suivants : http Peut être utilisé dans les sections : defaults \| frontend \| 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 ``` Activer un proxy, un frontal ou un backend. Peut être utilisé dans les contextes suivants : tcp, http, log Peut être utilisé dans les sections : defaults \| frontend \| 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 \| frontend \| listen \| backend oui \| oui \| oui \| oui Arguments : ```text est le code de statut HTTP. HAProxy peut actuellement générer les codes 200, 400, 401, 403, 404, 405, 407, 408, 410, 413, 414, 425, 429, 431, 500, 501, 502, 503 et 504. désigne le fichier contenant la réponse HTTP complète. Il est recommandé d'ajouter ".http" au nom, selon l'usage courant, pour éviter de le confondre avec une page d'erreur HTML. Utilisez des chemins absolus : les fichiers sont lus avant chroot. ``` 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 devraient 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 sage 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 [ ...] ``` Importer, 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 \| frontend \| listen \| backend oui \| oui \| oui \| oui Arguments : ```text est le nom d'une section http-errors existante. est un code de statut HTTP. Plusieurs codes peuvent être listés. HAProxy peut actuellement générer les codes 200, 400, 401, 403, 404, 405, 407, 408, 410, 413, 414, 425, 429, 431, 500, 501, 502, 503 et 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 \| frontend \| listen \| backend oui \| oui \| oui \| oui Arguments : ```text est le code de statut HTTP. HAProxy peut actuellement générer les codes 200, 400, 401, 403, 404, 405, 407, 408, 410, 413, 414, 425, 429, 431, 500, 501, 502, 503 et 504. est le contenu exact de l'en-tête "Location". Il peut être une URI relative vers une page d'erreur du même site, ou une URI absolue vers une page d'erreur d'un autre site. Attention aux URI relatives : si l'URI peut produire la même erreur (par exemple 500), elle risque de créer une boucle de redirection. ``` 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 \| frontend \| listen \| backend oui \| oui \| oui \| oui Arguments : ```text est le code de statut HTTP. HAProxy peut actuellement générer les codes 200, 400, 401, 403, 404, 405, 407, 408, 410, 413, 414, 425, 429, 431, 500, 501, 502, 503 et 504. est le contenu exact de l'en-tête "Location". Il peut être une URI relative vers une page d'erreur du même site, ou une URI absolue vers une page d'erreur d'un autre site. Attention aux URI relatives : si l'URI peut produire la même erreur (par exemple 500), elle risque de créer une boucle de redirection. ``` 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 \| frontend \| listen \| backend oui \| oui \| oui \| oui Arguments : ```text est l'adresse d'expédition des alertes par courriel. ``` 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 \| frontend \| listen \| backend oui \| oui \| oui \| oui Arguments : ```text est l'un des 8 niveaux syslog : emerg alert crit err warning notice info debug Ces niveaux sont classés du plus faible au plus élevé. ``` 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 alert ou inférieur - Un serveur mis en pause est marqué comme hors service lorsque `` est notice ou inférieur - Un serveur est marqué comme opérationnel ou passe en état de vidage lorsque `` est notice ou inférieur - L'option « option log-health-checks » est activée, `` est info 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 \| frontend \| listen \| backend oui \| oui \| oui \| oui Arguments : ```text est le nom de la section mailers envoyant les alertes. ``` 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 \| frontend \| listen \| backend oui \| oui \| oui \| oui Arguments : ```text est le nom d'hôte utilisé pour communiquer avec les 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éclarer à 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 \| frontend \| listen \| backend oui \| oui \| oui \| oui Arguments : ```text est l'adresse destinataire des alertes par courriel. ``` 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 \| frontend \| listen \| backend oui \| oui \| oui \| non Cette 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 réacheminements ou aux codes d'état HTTP 5xx. En résumé, ce format sera 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 \| frontend \| 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 effectue un réacheminement 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 ajouté/supprimé dans 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 à lancer lors de la réalisation d'un contrôle externe Peut être utilisé dans les contextes suivants : tcp, http, log Peut être utilisé dans les sections : defaults \| frontend \| listen \| backend oui \| non \| oui \| oui Arguments : ```text est la commande externe à exécuter. ``` Les arguments passés à la commande sont : `` `` `` `` Les `` et `` sont dérivés du premier é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". Certaines valeurs sont également fournies via des variables d'environnement. Variables d'environnement : ```text HAPROXY_PROXY_ADDR Première adresse bind disponible (vide si non applicable, par exemple dans une section "backend"). HAPROXY_PROXY_ID Identifiant du backend. HAPROXY_PROXY_NAME Nom du backend. HAPROXY_PROXY_PORT Premier port bind disponible (vide si non applicable, par exemple en section "backend" ou pour un socket UNIX). HAPROXY_SERVER_ADDR Adresse du serveur. HAPROXY_SERVER_CURCONN Nombre actuel de connexions sur le serveur. HAPROXY_SERVER_ID Identifiant du serveur. HAPROXY_SERVER_MAXCONN Nombre maximal de connexions du serveur. HAPROXY_SERVER_NAME Nom du serveur. HAPROXY_SERVER_PORT Port du serveur, si disponible (vide pour un socket UNIX). HAPROXY_SERVER_SSL "0" sans SSL, "1" sinon. HAPROXY_SERVER_PROTO Protocole utilisé par ce serveur : "cli" (CLI haproxy), "syslog" (serveur syslog TCP), "peers" (serveur peers TCP), "h1" (serveur HTTP/1.x), "h2" (serveur HTTP/2) ou "tcp" (tout autre serveur TCP). PATH La variable d'environnement PATH utilisée pour la commande peut être définie par "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 \| frontend \| listen \| backend oui \| non \| oui \| oui Arguments : ```text est le chemin utilisé lors de l'exécution de la commande externe. ``` 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 à la commutation de contenu de sélectionner une instance backend même si elle est désactivée ou non publiée. 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 \| frontend \| listen \| backend non \| oui \| oui \| non Voir aussi : « be-unpublished », « disabled » **`filter [param*]`** ```haproxy filter [param*] ``` Ajouter 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 \| frontend \| listen \| backend non \| oui \| oui \| oui Arguments : ```text est le nom du filtre. Les filtres officiellement pris en charge sont répertoriés à la section 9. est la liste des paramètres acceptés par le filtre . Le filtre est responsable de leur analyse. Voir sa documentation (section 9) pour les détails des paramètres pris en charge. ``` 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/). **`fullconn `** ```haproxy fullconn ``` Spécifier à 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 \| frontend \| listen \| backend oui \| non \| oui \| oui Arguments : ```text est le nombre de connexions au backend à partir duquel les serveurs utilisent leur nombre maximal de connexions. ``` 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écifier 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 \| frontend \| 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écifier 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 \| frontend \| listen \| backend oui \| non \| non \| oui Arguments : ```text contrôle le nombre maximal de requêtes simultanées envoyées à un serveur, en pourcentage du nombre moyen de requêtes simultanées sur l'ensemble des serveurs actifs. ``` 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. Définir `` à 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 premier choix est écarté, 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écifier 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 \| frontend \| 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écifier 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 \| frontend \| listen \| backend oui \| non \| oui \| oui Arguments : ```text est la méthode de sélection du serveur à partir du hachage calculé par : map-based La table de hachage est un tableau statique contenant tous les serveurs disponibles. La répartition est très régulière et respecte les poids, mais reste statique : les modifications de poids d'un serveur disponible sont ignorées. Le démarrage progressif n'est donc pas possible. Le serveur étant choisi par sa position dans le tableau, la plupart des associations changent si le nombre de serveurs change. Lorsqu'un serveur devient disponible, indisponible ou rejoint le groupe, la plupart des connexions sont redistribuées vers d'autres serveurs, ce qui peut gêner les caches, par exemple. consistent La table est un arbre contenant de nombreuses occurrences de chaque serveur. La clé est recherchée dans l'arbre et le serveur le plus proche est choisi. Ce hachage est dynamique, accepte les changements de poids des serveurs disponibles et permet le démarrage progressif. Lorsqu'un serveur devient disponible ou indisponible, seules ses associations changent. Un ajout ne redistribue qu'une petite partie des associations, ce qui convient particulièrement aux caches. La répartition reste cependant irrégulière par principe : il faut parfois ajuster le poids ou l'ID d'un serveur pour mieux l'équilibrer. Pour obtenir la même répartition sur plusieurs répartiteurs, tous les serveurs doivent avoir exactement les mêmes ID. Sans fonction explicite, le hachage cohérent emploie sdbm et avalanche. est la fonction de hachage utilisée : sdbm Créée pour la bibliothèque de bases de données sdbm (réimplémentation de ndbm dans le domaine public). Elle mélange bien les bits, répartit mieux les clés et réduit les divisions. C'est aussi une bonne fonction générale, sauf si le poids total est un multiple de 64 ; dans ce cas, le modificateur avalanche peut aider. djb2 Proposée par Dan Bernstein sur comp.lang.c il y a de nombreuses années. Pour certaines charges, elle répartit mieux que sdbm. Elle convient généralement aux entrées textuelles, mais peut fonctionner très mal pour des entrées purement numériques ou un poids total multiple de 33, sauf avec le modificateur avalanche. wt6 Conçue pour HAProxy lors d'essais d'autres fonctions. Moins régulière, elle est beaucoup moins sensible aux données ou au nombre de serveurs. Elle peut remplacer sdbm+avalanche ou djb2+avalanche pour le hachage cohérent ou des données numériques, comme une IP source ou un identifiant visiteur dans un paramètre d'URL. crc32 Implémentation CRC32 courante, utilisée par Ethernet, gzip, PNG, etc. Plus lente, elle peut offrir une meilleure répartition ou des résultats moins prévisibles, surtout sur des chaînes. none Ne hache pas la clé ; elle sert directement de hachage. On peut ainsi la hacher soi-même avec un convertisseur, puis laisser haproxy utiliser le résultat. La clé est convertie en chaîne si nécessaire, puis analysée comme un entier servant de clé. Certains types d'entrée, comme les adresses IP, ne conviennent pas. est une méthode facultative appliquée après le hachage : avalanche Applique au résultat un hachage à effet avalanche complet sur 4 octets au lieu de l'utiliser brut. Cela mélange les bits pour éviter des effets indésirables lorsque les entrées ont peu de valeurs possibles ou que le nombre de serveurs est un multiple d'une composante du hachage (64 pour SDBM, 33 pour DJB2). Le résultat devient moins prévisible, mais moins régulier qu'avec la fonction originale. Des essais peuvent être nécessaires selon la charge. Ce hachage fait partie des nombreuses fonctions proposées par 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 devrait ê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 \| frontend \| 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 \| frontend \| listen \| backend oui \| non \| oui \| oui Arguments : ```text est le commentaire à ajouter aux journaux si la règle http-check suivante échoue. ``` 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 \| frontend \| listen \| backend oui \| non \| oui \| oui Arguments : ```text comment définit le message à signaler si l'évaluation échoue. default Utilise les options par défaut de la ligne server pour les contrôles de santé, seulement si elles ne sont pas redéfinies. port Sans valeur, utilise le port de contrôle ou le port serveur. Définit où HAProxy ouvre la connexion. doit être un entier représentant un port TCP valide de 1 à 65535, ou une expression de récupération d'échantillon. addr définit l'adresse IP du contrôle de santé. send-proxy envoie une chaîne au format du protocole PROXY. via-socks4 utilise le proxy socks4 amont pour les contrôles sortants. ssl ouvre une connexion chiffrée. sni spécifie le SNI des contrôles de santé sur SSL. alpn définit les protocoles annoncés par ALPN : une liste de noms séparés par des virgules, comme "h2,http/1.1". Sans valeur, l'ALPN du serveur est utilisé. proto impose le protocole du multiplexeur pour cette connexion. Il doit être un protocole de multiplexage HTTP utilisable côté backend. haproxy -vv liste les protocoles disponibles. linger ferme proprement la connexion au lieu d'un seul 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 devrait é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, la première é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 contrôles d'état Peut être utilisé dans les contextes suivants : tcp, http Peut être utilisé dans les sections : defaults \| frontend \| listen \| backend oui \| non \| oui \| oui Arguments : aucun Lorsque cette option est activée, un serveur renvoyant un code HTTP 404 est exclu de la répartition de charge, 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 dans 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 dans ce mode. Il est important 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 un arrêt progressif. 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 ] [!] ``` Faire en sorte que les contrôles d'état HTTP prennent en compte le contenu de la réponse ou des codes d'état spécifiques Peut être utilisé dans les contextes suivants : tcp, http Peut être utilisé dans les sections : defaults \| frontend \| listen \| backend oui \| non \| oui \| oui Arguments : ```text comment définit le message à signaler si l'évaluation échoue. min-recv définit facultativement la quantité minimale de données nécessaire à l'évaluation de la règle expect. En dessous de ce nombre d'octets, le contrôle attend davantage de données. Cela lève l'ambiguïté de certaines règles ou évite des expressions régulières coûteuses sur des données encore incomplètes. Pour une chaîne exacte, le minimum entre sa longueur et ce paramètre est utilisé. Le paramètre est ignoré à -1. Si expect ne correspond pas, le contrôle attend davantage de données. À 0, le résultat est toujours définitif. ok-status définit facultativement le statut si expect réussit et est la dernière règle de tcp-check. Statuts acceptés : "L7OK", "L7OKC", "L6OK" et "L4OK". - L7OK : contrôle réussi en couche 7. - L7OKC: réussite conditionnelle en couche 7 ; serveur placé dans l'état NOLB. - L6OK : contrôle réussi en couche 6. - L4OK : contrôle réussi en couche 4. Valeur par défaut : "L7OK". error-status définit facultativement le statut en cas d'erreur durant l'évaluation de expect. Statuts acceptés : "L7OKC", "L7RSP", "L7STS", "L6RSP" et "L4CON". - L7OKC: réussite conditionnelle en couche 7 ; serveur placé dans l'état NOLB. - L7RSP: réponse invalide en couche 7 ; erreur de protocole. - L7STS: erreur de réponse en couche 7, par exemple HTTP 5xx. - L6RSP: réponse invalide en couche 6 ; erreur de protocole. - L4CON: problème de connexion en couches 1-4. Valeur par défaut : "L7RSP". tout-status définit facultativement le statut en cas d'expiration du délai durant expect. "L7TOUT", "L6TOUT" et "L4TOUT" sont acceptés : - L7TOUT: délai dépassé en couche 7 (HTTP/SMTP). - L6TOUT: délai dépassé en couche 6 (SSL). - L4TOUT: délai dépassé en couches 1-4. Valeur par défaut : "L7TOUT". on-success personnalise facultativement le message des journaux si expect réussit et est la dernière règle de tcp-check. est une chaîne de format de journal personnalisé (section 8.2.6). on-error personnalise facultativement le message des journaux en cas d'erreur durant expect. est une chaîne de format de journal personnalisé (section 8.2.6). status-code définit facultativement le code de statut du contrôle dans les journaux, en cas de réussite ou d'erreur. est une expression HAProxy standard : récupération d'échantillon suivie de convertisseurs. indique comment rechercher un motif dans la réponse : "status", "rstatus", "hdr", "fhdr", "string" ou "rstring". Un préfixe "!" inverse la correspondance. Des espaces peuvent séparer le point d'exclamation du mot-clé. Voir les détails ci-dessous. est le motif recherché : chaîne, expression régulière ou motif plus complexe à plusieurs arguments. Les espaces dans une chaîne doivent être échappés par la barre oblique inverse habituelle ('\'). ``` 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 si le délai d'expiration est atteint, le contrôle échoue évidemment. Les correspondances disponibles sont : ```text status : teste les codes extraits de , une liste de codes ou de plages séparés par des virgules. La réponse HTTP est valide si son code correspond à un code ou appartient à une plage de la liste. Avec "!" devant "status", une correspondance rend la réponse invalide. rstatus : teste une expression régulière sur le code de statut HTTP. La réponse est valide si son code correspond. Avec "!" devant "rstatus", une correspondance la rend invalide. Sert surtout à vérifier plusieurs codes. hdr { name | name-lf } [ -m ] [ { value | value-lf } [ -m ] : teste le motif d'en-tête dans la réponse HTTP. Le motif du nom est obligatoire, celui de la valeur facultatif. Sans valeur, seule la présence est vérifiée. définit la méthode sur le nom ou la valeur : "str" (exacte), "beg" (préfixe), "end" (suffixe), "sub" (sous-chaîne) ou "reg" (expression régulière). Par défaut, la correspondance est exacte. Avec "name-lf", est évalué comme un format de journal personnalisé (section 8.2.6). Avec "value-lf", est évalué comme une chaîne log-format. Ces paramètres ne peuvent pas être utilisés avec la méthode par expression régulière. La valeur est considérée comme une liste séparée par des virgules. Les noms d'en-têtes sont insensibles à la casse. fhdr { name | name-lf } [ -m ] [ { value | value-lf } [ -m ] : teste l'en-tête complet de la réponse HTTP. Identique à "hdr", mais teste toute la valeur : les virgules ne sont pas considérées comme des séparateurs. string : recherche une chaîne exacte dans le corps de réponse HTTP. La réponse est valide si le corps contient cette chaîne. Avec "!" devant "string", sa présence rend la réponse invalide. Sert à chercher un mot obligatoire à la fin d'une page dynamique ou à détecter une erreur précise sur la page de contrôle, comme une trace de pile. rstring : teste une expression régulière dans le corps de réponse HTTP. La réponse est valide si le corps correspond. Avec "!" devant "rstring", une correspondance la rend invalide. Sert à chercher un mot obligatoire à la fin d'une page dynamique ou à détecter une erreur précise sur la page de contrôle, comme une trace de pile. string-lf : recherche dans le corps une chaîne de format de journal personnalisé (section 8.2.6). La réponse est valide si le corps contient le résultat de , évalué selon les règles log-format. Avec "!", sa présence rend la réponse invalide. ``` 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 contrôles 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 ] ``` Ajouter 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 \| frontend \| listen \| backend oui \| non \| oui \| oui Arguments : ```text comment définit le message à signaler si l'évaluation échoue. meth est la méthode HTTP facultative. Par défaut, "OPTIONS" est utilisée : elle coûte généralement peu au serveur et se filtre facilement dans les journaux. Toute méthode est possible, mais inventer des méthodes non standard est déconseillé. uri définit facultativement l'URI des requêtes HTTP à . Par défaut, "/" est accessible sur presque tous les serveurs. Toute autre URI et les chaînes de requête sont autorisées. uri-lf définit facultativement l'URI avec le format de journal personnalisé (section 8.2.6). Par défaut, "/" est accessible sur presque tous les serveurs. Toute autre URI et les chaînes de requête sont autorisées. ver est la version HTTP facultative. Par défaut : "HTTP/1.0". Certains serveurs fonctionnent mal en HTTP 1.0 : passer à HTTP/1.1 peut aider. Host est obligatoire en HTTP/1.1 ; utilisez "hdr" pour l'ajouter. hdr ajoute l'en-tête HTTP avec la valeur , suivant les règles de format de journal personnalisé (section 8.2.6). body ajoute le corps à la requête du contrôle HTTP. L'en-tête "Content-Length" est alors ajouté automatiquement. body-lf ajoute le corps HTTP défini par le format de journal personnalisé (section 8.2.6) à la requête du contrôle HTTP. L'en-tête "Content-Length" est alors ajouté automatiquement. ``` 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 devrait 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. Gardez à l'esprit qu'un en-tête « Connection: close » sera 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 devriez 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 \| frontend \| 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, lorsqu'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 du nombre de contrôles valides sur le nombre total 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 lorsqu'un serveur est contrôlé 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 inline. Peut être utilisé dans les contextes suivants : tcp, http Peut être utilisé dans les sections : defaults \| frontend \| listen \| backend oui \| non \| oui \| oui Arguments : ```text est le nom de la variable. Seules les portées "proc", "sess" et "check" sont autorisées. Voir la section 2.8. est un ensemble de conditions devant toutes être vraies pour définir la variable ("ifnotempty", "ifgt", etc.). La description du convertisseur set-var donne la liste complète. est une expression de récupération d'échantillon, éventuellement suivie de convertisseurs. est la valeur en format de journal personnalisé (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 sa portée. Peut être utilisé dans les contextes suivants : tcp, http Peut être utilisé dans les sections : defaults \| frontend \| listen \| backend oui \| non \| oui \| oui Arguments : ```text est le nom de la variable. Seules les portées "proc", "sess" et "check" sont autorisées. Voir la section 2.8. ``` 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 \| frontend \| listen \| backend oui \| oui \| oui \| oui Arguments : ```text status est le code de statut HTTP obligatoire. HAProxy peut actuellement générer les codes 200, 400, 401, 403, 404, 405, 407, 408, 410, 413, 414, 425, 429, 431, 500, 501, 502, 503 et 504. content-type est le type de contenu de la réponse HTTP, par exemple "text/plain". Ignoré et à omettre avec errorfile ou un corps vide. Sinon, il doit être défini. default-errorfiles réinitialise le message d'erreur du proxy pour . Sur un backend, utilise le message du frontend s'il est défini. Sur un frontend, utilise le message par défaut. errorfile désigne le fichier de réponse HTTP complète. Ajoutez ".http" au nom, selon l'usage, pour éviter de le confondre avec une page d'erreur HTML. Utilisez un chemin absolu : le fichier est lu avant chroot. errorfiles désigne la section http-errors d'où importer le message pour . S'il n'est pas trouvé, les messages d'erreur du proxy sont pris en compte. file définit le fichier utilisé comme corps de réponse. S'il n'est pas vide, son type doit être fourni par "content-type". Sinon "content-type" est ignoré. est considéré comme une chaîne brute. string définit la chaîne brute servant de corps de réponse. "content-type" doit toujours être fourni. lf-file définit le fichier utilisé comme corps de réponse. S'il n'est pas vide, son type doit être fourni par "content-type". Sinon "content-type" est ignoré. est évalué en format de journal personnalisé (section 8.2.6). lf-string définit la chaîne log-format servant de corps de réponse. "content-type" doit toujours être fourni. hdr ajoute l'en-tête de réponse , de valeur , suivant les règles de format de journal personnalisé (section 8.2.6). Ignoré avec errorfile. ``` Cette 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é devrait ê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 \| frontend \| 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 \| frontend \| 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 \| frontend \| 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 inactive 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é que cela est strictement équivalent au mode keep-alive normal, il ne devrait y avoir aucun effet secondaire. 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 devrait ê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 devrait être utilisé que lorsqu'il améliore la situation par rapport à "aggressive". Notez également que les connexions utilisant certains mécanismes d’authentification douteux (reposant sur 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 inactive 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 de transfert), 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 [
] ``` Ajouter le nom du serveur à une requête. Utiliser la chaîne d'en-tête fournie par `
` Peut être utilisé dans les contextes suivants : http Peut être utilisé dans les sections : defaults \| frontend \| listen \| backend oui \| non \| oui \| oui Arguments : ```text
est la chaîne d'en-tête servant à envoyer le nom du serveur. ``` 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 réacheminements, 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 \| frontend \| 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 \| frontend \| 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 \| frontend \| listen \| backend oui \| non \| oui \| oui Cette 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 charge le fichier indiqué par "server-state-file" dans global. local charge le fichier indiqué par "server-state-file-name" s'il est défini ; sinon, utilise le nom du backend comme nom de fichier. none ne charge aucun état pour ce 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 ``` Activer 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 \| frontend \| listen \| backend oui \| oui \| oui \| oui Préfixe : ```text no vide la liste des destinations de journalisation, par exemple pour ne pas hériter de la liste par défaut. N'accepte aucun argument. ``` Arguments : ```text global utilise les mêmes paramètres de journalisation que global. C'est le cas le plus courant. "global" remplace tous les arguments par ceux des entrées log de la section "global". Une seule instruction "log global" est permise par instance, sans autre paramètre. indique la destination des journaux, au même format que dans "global". Valeurs possibles : - Adresse IPv4, éventuellement suivie de ':' et d'un port UDP. Sans port, utilise 514, le port syslog standard. - Adresse IPv6 suivie de ':', puis éventuellement d'un port UDP. Sans port, utilise 514, le port syslog standard. - Chemin d'un socket de domaine UNIX. Il doit être accessible dans chroot et avoir les permissions d'écriture uid/gid requises. - Descripteur de fichier au format "fd@", pointant vers un tube, terminal ou socket. Les journaux ne sont pas tamponnés ; chaque message entraîne un appel writev(). Le coût est un peu élevé, mais acceptable pour la plupart des charges. Les messages ne sont pas tronqués, mais peuvent être perdus ; DroppedLogs est alors incrémenté. Même sur un tube, writev() est atomique jusqu'à PIPE_BUF, au moins 512 selon POSIX et généralement 4096 octets sur les systèmes récents. Un message plus long peut se mêler à ceux d'autres processus. Exceptionnellement, pour déboguer, le descripteur peut pointer vers un fichier, mais cela ralentit nettement HAProxy, les appels non bloquants étant ignorés. Impossible de vider ou faire tourner ce fichier sans redémarrage. Le format syslog configuré est conservé : la sortie convient à un serveur syslog TCP. Voir "short" et "raw". - "stdout" / "stderr", alias respectifs de "fd@1" et "fd@2" décrits ci-dessus. - Tampon circulaire "ring@", en mémoire et accessible via la CLI par "show events", qui liste aussi les tampons et leurs tailles. Perdu au rechargement ou redémarrage, il est utile en complément pour disposer immédiatement des journaux lors du diagnostic. Voir la section 12.5. - Backend de journalisation "backend@". Il distribue les messages au serveur approprié selon ses paramètres de répartition. C'est une section backend avec "mode log" ; voir "mode" pour les détails. - Préfixe d'adresse de flux explicite, comme "tcp@", "tcp6@", "tcp4@" ou "uxst@". Alloue un tampon circulaire implicite avec un serveur de transfert en mode flux vers cette adresse. L'adresse peut référencer des variables d'environnement ; voir la section 2.3. est la longueur maximale facultative. Les lignes plus longues sont tronquées avant l'envoi. Les serveurs syslog diffèrent : tous acceptent 1024, la valeur par défaut, mais certains rejettent les lignes plus longues et d'autres les enregistrent. Si le serveur accepte les longues lignes, augmentez cette valeur pour éviter leur troncature. S'il les rejette, mieux vaut les tronquer avant l'envoi. Valeurs acceptées : 80 à 65535 inclus. Le défaut de 1024 convient généralement, sauf certaines captures longues ou des journaux JSON. Si les URI sont tronquées, il peut aussi falloir augmenter "tune.http.logurilen". est une liste de plages séparées par des virgules, désignant les journaux à échantillonner pour répartir leur charge d'envoi au serveur de journaux. Les bornes ne peuvent pas être nulles et sont numérotées à partir de 1. La taille ou période de l'échantillon, en nombre de messages, est donnée par . est la taille de l'échantillon, en nombre de messages, utilisée pour répartir la charge envoyée au serveur syslog. Elle doit être supérieure ou égale à la plus grande borne haute des plages. Voir aussi . est le format des messages syslog générés : local Analogue à rfc3164 sans le champ de nom d'hôte. C'est le défaut. "log-send-hostname" fait passer le défaut à rfc3164. rfc3164 Format syslog RFC3164. (https://tools.ietf.org/html/rfc3164) rfc5424 Format syslog RFC5424. (https://tools.ietf.org/html/rfc5424) priority Niveau et facility syslog entre chevrons, comme '<63>', puis texte. PID, date, heure, noms du processus et du système omis. Conçu pour un serveur de journaux local. short Niveau entre chevrons, comme '<3>', puis texte. PID, date, heure, noms du processus et du système omis. Conçu pour un serveur local ; compatible avec la journalisation de systemd. timed Niveau entre chevrons, comme '<3>', puis date ISO et texte. PID, noms du processus et du système omis. Conçu pour un serveur local. iso Date ISO, puis texte. PID, noms du processus et du système omis. Conçu pour un serveur local. raw Texte seulement. Niveau, PID, date, heure et noms du processus et du système omis. Conçu pour les conteneurs ou le développement, où la gravité dépend seulement du descripteur (stdout/stderr). est le nom de la section facultative "log-profile" examinée lors de la construction du journal pour remplacer certaines options. Voir "8.3.5. Log profiles". est l'une des 24 facilities syslog standard : kern user mail daemon auth syslog lpr news uucp cron auth2 ftp ntp audit alert cron2 local0 local1 local2 local3 local4 local5 local6 local7 Ignorée pour "short" et "raw", mais toujours obligatoire comme champ positionnel. "daemon" est recommandé pour rendre clair que l'utilisation doit rester locale. est facultatif et filtre les messages sortants. Par défaut, tous sont envoyés. Si un niveau est indiqué, seuls les messages de gravité au moins égale sont envoyés. Un niveau minimal facultatif peut plafonner la gravité des messages plus graves à ce niveau. Cela évite l'envoi de messages "emerg" à tous les terminaux avec certaines configurations syslog par défaut. Huit niveaux existent : emerg alert crit err warning notice info debug ``` Il est important de garder à l’esprit que c’est le frontal qui détermine 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 \| frontend \| listen \| backend oui \| oui \| oui \| non Cette 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 \| frontend \| 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 \| frontend \| listen \| backend oui \| oui \| oui \| non Pendant le traitement des transactions tcp/http, HAProxy peut produire des journaux à différentes étapes du traitement (c'est-à-dire : accept, connect, request, response, close). 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 \| frontend \| 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 \| frontend \| 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 \| frontend \| listen \| backend oui \| oui \| oui \| non **`maxconn `** ```haproxy maxconn ``` Définir le nombre maximal de connexions simultanées sur un frontal Peut être utilisé dans les contextes suivants : tcp, http Peut être utilisé dans les sections : defaults \| frontend \| listen \| backend oui \| oui \| oui \| non Arguments : ```text est le nombre maximal de connexions simultanées acceptées par le frontend. Les connexions excédentaires attendent dans la file d'écoute du socket système et sont servies dès qu'une connexion ferme. ``` 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 devrait pas dépasser le 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 \| frontend \| listen \| backend. oui \| oui \| oui \| oui Arguments : ```text tcp Mode TCP pur. Une connexion bidirectionnelle simultanée relie clients et serveurs, sans inspection en couche 7. Mode par défaut, à utiliser pour SSL, SSH, SMTP, etc. http Mode HTTP. La requête cliente est analysée en détail avant toute connexion serveur. Toute requête non conforme aux RFC est rejetée. Filtrage, traitement et aiguillage en couche 7 sont possibles. C'est ce mode qui apporte l'essentiel de la valeur de HAProxy. haterm Le frontend sert au banc de mesure HTTP haterm. Non pris en charge par les backends. Voir doc/haterm.txt. log Dans une section backend, active un backend de journalisation. Il peut être la destination de toute directive "log" avec "backend@". Les messages sont répartis selon les paramètres définis par "balance". Les serveurs UDP sont acceptés avec le préfixe "udp@". Les fonctions communes de backend et de serveur sont prises en charge, mais pas celles propres à TCP ou HTTP. spop Dans une section backend, active le mode spop, obligatoire pour les serveurs SPOA. Si le mode est tcp, il devient automatiquement spop lorsque de tels serveurs sont détectés. ``` 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 } ``` Ajouter 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 \| frontend \| listen \| backend non \| oui \| oui \| non Arguments : ```text if la requête de surveillance échoue si la condition est vraie, sinon elle réussit. La condition devrait combiner des tests provoquant l'échec s'ils sont tous satisfaits, par exemple peu de serveurs à la fois dans un backend et son secours. unless la requête de surveillance ne réussit que si la condition est vraie ; sinon elle échoue. On peut tester la présence d'un nombre minimal de serveurs actifs dans une liste de backends. ``` Cette instruction ajoute une condition qui peut forcer la réponse à une requête de surveillance à signaler une erreur. Par défaut, lorsqu'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 ``` Intercepter 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 \| frontend \| listen \| backend oui \| oui \| oui \| non Arguments : ```text est l'URI exacte à intercepter pour renvoyer l'état de santé de HAProxy au lieu de transmettre la requête. ``` Lorsqu'une requête HTTP référençant `` est 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 \| frontend \| 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 évitera de traiter les poignées de main 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 poignée de main TLS complète et coûteuse. 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. - lorsqu'elle est présente dans un backend, elle 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 : « timeout queue » 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 \| frontend \| 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 devrait jamais être activée par défaut, car elle masque les bugs applicatifs et expose des failles de sécurité. Elle ne devrait ê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 \| frontend \| 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 devrait jamais être activée par défaut, car elle masque les bugs applicatifs et expose des failles de sécurité. Elle ne devrait ê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 ``` Utiliser soit tous les serveurs de secours 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 \| frontend \| 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 ``` Analyser toutes les réponses des serveurs et bloquer 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 \| frontend \| 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 ») ; - celles qui ne comportent ni information de fraîcheur (un en-tête « Cache-control » avec « max-age » ou « s-maxage », ou un en-tête « Expires »), ni validateur (un en-tête « ETag » ou « Last-Modified »), car une réponse de ce type n’est pas stockée par un cache conforme. 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 devrait ê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 \| frontend \| 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 inactive 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. Seules 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 lorsque des expirations de session sont constatées 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 \| frontend \| 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 ``` Activer ou désactiver la mise à niveau 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 \| frontend \| 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 au préambule 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 » sur la ligne bind. Enfin, cette option s’applique à toutes les lignes bind. Pour désactiver les mises à niveau implicites de HTTP/2 pour une ligne 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 \| frontend \| 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 \| frontend \| 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 ``` Utiliser 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 \| frontend \| 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 \| frontend \| listen \| backend oui \| non \| oui \| oui Arguments : ```text expression d'échantillon personnalisée facultative dont le résultat sert de valeur au paramètre 'host'. expression facultative dont le résultat sert de valeur nodename au paramètre 'by'. expression facultative dont le résultat sert de valeur nodename au paramètre 'for'. expression facultative dont le résultat sert de valeur nodeport au paramètre 'by'. expression facultative dont le résultat sert de valeur nodeport au paramètre 'for'. ``` É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 aux serveurs/applications sous-jacents. 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 explicite/manuelle serait : ```text option forwarded proto for ``` Le mot-clé « by » est utilisé pour activer le paramètre « by » (« nodename ») dans l’en-tête forwarded. 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 forwarded. 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 forwarded. 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 forwarded. 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 \| frontend \| listen \| backend oui \| oui \| oui \| oui Arguments : ```text désactive facultativement cette option pour les adresses sources correspondant à . définit facultativement un autre nom d'en-tête "X-Forwarded-For". ``` É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 toujours utiliser uniquement 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 n'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 défectueux Peut être utilisé dans les contextes suivants : http Peut être utilisé dans les sections : defaults \| frontend \| listen \| backend oui \| oui \| oui \| non Arguments : aucun Il n’existe pas de casse 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 défectueux Peut être utilisé dans les contextes suivants : http Peut être utilisé dans les sections : defaults \| frontend \| listen \| backend oui \| non \| oui \| oui Arguments : aucun Il n’existe pas de casse 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 \| frontend \| 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 abusent 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 trailers 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 \| frontend \| 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 trailers 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 \| frontend \| 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 message des réponses 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 ``` Activer ou désactiver 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 \| frontend \| 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 gros 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 \| frontend \| 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 inactive 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 lorsqu'un autre mode a été utilisé dans une section « defaults ». La définition de « 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 ``` Indiquer au système de 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 \| frontend \| 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 abusent 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, cela fonctionnera aussi vite que possible. Cette option ne devrait jamais être utilisée par défaut, et ne devrait 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 \| frontend \| 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 \| frontend \| listen \| backend oui \| oui \| oui \| oui Arguments : ```text preserve désactive le filtrage. Mode par défaut des proxies HTTP sans application FastCGI configurée. delete supprime les en-têtes de requête dont le nom contient un caractère hors de "[a-zA-Z0-9-]". Mode par défaut des backends HTTP avec une application FastCGI configurée. reject rejette la requête avec une réponse 403-Forbidden si un nom d'en-tête contient un caractère hors de "[a-zA-Z0-9-]". ``` 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 \| frontend \| 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 inactive 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 ``` Utiliser 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 \| frontend \| 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 ne devrait normalement 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 ``` Activer 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 \| frontend \| listen \| backend oui \| non \| oui \| oui Arguments : ```text est la méthode HTTP facultative. Par défaut, "OPTIONS" coûte peu au serveur et se filtre facilement dans les journaux. Toute méthode est possible, mais inventer des méthodes non standard est déconseillé. est l'URI des requêtes HTTP. Par défaut : " / ", accessible sur presque tous les serveurs. Toute autre URI et les chaînes de requête sont autorisées. est la version HTTP facultative, "HTTP/1.0" par défaut. Certains serveurs fonctionnent mal en HTTP 1.0 ; HTTP/1.1 peut aider. Le champ Host est obligatoire en HTTP/1.1. est la valeur facultative de l'en-tête HTTP Host. Non définie par défaut ; il s'agit d'une chaîne log-format. ``` 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ée 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 \| frontend \| 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 inactive 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 temporisateurs Peut être utilisé dans les contextes suivants : http Peut être utilisé dans les sections : defaults \| frontend \| listen \| backend oui \| oui \| oui \| non Arguments : ```text clf avec l'argument "clf", utilise le format CLF plutôt que le format HTTP par défaut de HAProxy. Cela sert aux analyseurs de journaux spécifiques, non extensibles, n'acceptant que CLF. ``` 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 temporisateurs Peut être utilisé dans les contextes suivants : http Peut être utilisé dans les sections : defaults \| frontend \| 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 un arrêt progressif est en cours Peut être utilisé dans les contextes suivants : http Peut être utilisé dans les sections : defaults \| frontend \| listen \| backend oui \| oui \| oui \| non Arguments : aucun Par défaut, les connexions inactives seront fermées lors d'un arrêt progressif. 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 aucun mécanisme de nouvelle tentative approprié n'existe en cas d'erreur d'écriture, 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 de connexion ou d'écriture, 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 \| frontend \| 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 renvoie toujours en écho 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 POST 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 ``` Utiliser 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 \| frontend \| 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 \| frontend \| 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 \| frontend \| 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 réacheminements, 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 ``` Activer ou désactiver la journalisation précoce. Peut être utilisé dans les contextes suivants : tcp, http Peut être utilisé dans les sections : defaults \| frontend \| 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 response header » 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 } ] ] ``` Utiliser 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 \| frontend \| listen \| backend oui \| non \| oui \| oui Arguments : ```text est le nom d'utilisateur de la connexion au serveur MySQL. post-41 envoie des contrôles compatibles avec les clients après v4.1 (valeur par défaut). pre-41 envoie des contrôles compatibles avec les clients avant v4.1. post-80 envoie des contrôles compatibles avec les clients après v8.0, avec CLIENT_PLUGIN_AUTH et le plugin mysql_native_password. À utiliser avec MySQL 8.0+ si l'utilisateur de contrôle a été créé avec l'authentification mysql_native_password. Exemple : 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 un 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 \| frontend \| 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 avec pertes, cela peut aggraver les problèmes, notamment lorsqu'un pare-feu se trouve du côté avec pertes, 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 d'expiration « timeout client-fin » ou « timeout 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 \| frontend \| listen \| backend oui \| oui \| oui \| oui Arguments : ```text désactive facultativement cette option pour les adresses sources correspondant à . définit facultativement un autre nom d'en-tête "X-Original-To". ``` É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 pour toujours utiliser uniquement 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 n'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 \| frontend \| 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, réacheminé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 à osciller entre les états. 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 acheminé 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 ``` Utiliser 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 \| frontend \| listen \| backend oui \| non \| oui \| oui Arguments : ```text est le nom d'utilisateur utilisé pour se connecter au serveur PostgreSQL. ``` 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 \| frontend \| 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 un routage déterministe pour les clients qui reviennent. 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 qu'il n'est pas garanti que deux requêtes consécutives soient 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 \| frontend \| listen \| backend oui \| non \| oui \| oui Arguments : ```text est l'entier facultatif réglant la fréquence de redistribution lors des nouvelles tentatives de connexion. Une valeur positive P redistribue à chaque P-ième tentative ; une valeur négative N redistribue à la N-ième tentative avant la dernière. Le défaut -1 conserve le comportement historique : redistribution à la dernière tentative. Avec 1, chaque tentative redistribue ; avec 3, une tentative sur trois redistribue. La valeur 0 désactive les redistributions. ``` 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 définitivement d'accéder au service. Spécifier « option redispatch » permet au proxy de rompre la persistance basée sur les cookies ou le hachage cohérent, 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. Tout serveur actif non de secours, s'il en existe, sinon : 2. Si "allbackups" n'est pas activée, le premier serveur de secours de la liste, sinon : 3. Si "allbackups" est activée, tout serveur de secours. ``` 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 ``` Utiliser 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 \| frontend \| 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 ``` Utiliser 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 \| frontend \| listen \| backend oui \| non \| oui \| oui Arguments : ```text est la commande "hello" facultative : "HELO" pour SMTP ou "EHLO" pour ESMTP. Toute autre valeur devient la commande par défaut "HELO". est le domaine présenté au serveur. Il ne peut être spécifié, et devient obligatoire, que si hello est spécifié. Par défaut : "localhost". ``` 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 » ```haproxy option socket-stats no 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 \| frontend \| 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 automatique par le noyau sur les sockets dans les deux sens Peut être utilisé dans les contextes suivants : tcp, http Peut être utilisé dans les sections : defaults \| frontend \| 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 : le splice TCP basé 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, le splice peut être désactivé 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 \| frontend \| 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 splice TCP du noyau 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 tube libre n'est disponible. Cette option nécessite que le splice soit activé lors de la compilation et peut être désactivée globalement via l'option « nosplice ». Étant donné que le splice utilise des tubes, son utilisation suppose la disponibilité de suffisamment de tubes 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 \| frontend \| 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 splice TCP du noyau 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 tube libre n'est disponible. Cette option nécessite que le splice soit activé lors de la compilation et peut être désactivée globalement via l’option « nosplice ». Étant donné que le splice utilise des tubes, son utilisation suppose la disponibilité de suffisamment de tubes 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 ``` Utiliser 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 \| frontend \| 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 poignée de main HELLO est effectuée 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 \| frontend \| 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 inactive 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. Seules 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 lorsque des expirations de session sont constatées 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 ``` Utiliser 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 \| frontend \| 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 testés à ce jour répondent correctement aux messages client hello SSLv3, et la plupart des serveurs testés 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 ``` Effectuer 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 \| frontend \| 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 modèle requête/réponse. 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 Construire une requête HTTP, puis analyser la réponse (envoyer plusieurs en-têtes avant l'analyse) 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'économie 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 \| frontend \| 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 un acquittement TCP pour rien, car la requête aurait très bien 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 l'économie 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 \| frontend \| 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 un accusé de réception vide lors d'une requête de connexion, mais d'envoyer directement le tampon de requête à 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 \| frontend \| 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 inactive 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. Seules 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 temporisateurs Peut être utilisé dans les contextes suivants : tcp, http Peut être utilisé dans les sections : defaults \| frontend \| listen \| backend oui \| oui \| oui \| non Arguments : ```text clf avec l'argument "clf", utilise CLF plutôt que le format TCP par défaut de HAProxy. Cela sert aux analyseurs spécifiques, non extensibles, n'acceptant que CLF. Ce format attendant HTTP, certaines valeurs sont prédéfinies : la requête HTTP apparaît comme TCP et le code de réponse comme 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 temporisateurs 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 dont le délai expire. 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 \| frontend \| 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 sujette à 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 \| frontend \| 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 : lorsque ce paramètre 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 : lorsque ce paramètre est défini, des tampons de petite taille seront utilisés pour conserver les requêtes lorsque les réessais L7 sont activés. - check : lorsque ce paramètre est défini, des tampons de petite taille seront utilisés pour les requêtes des contrôles d'état. 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 \| frontend \| listen \| backend oui \| non \| oui \| oui Arguments : ```text est le nom facultatif du cookie RDP à vérifier. Sans valeur, le nom par défaut "msts" est utilisé. Il n'y a actuellement aucune raison valable de changer ce nom. ``` 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 \| frontend \| listen \| backend oui(!) \| oui \| oui \| non Arguments : ```text définit l'action si la condition est vraie. Voir ci-dessous. est une condition ACL standard de couche 4 seulement (section 7). Les règles initiales QUIC sont exécutées trop tôt même pour certaines méthodes de récupération en couche 4, sans avertissement de configuration. Elles peuvent produire un comportement indéfini à l'exécution, sans provoquer de plantage. Seuls les échantillons internes et ceux de couche 4 "src*" et "dst*" sont actuellement considérés comme pris en charge. ``` 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 ``` Définir 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 \| frontend \| listen \| backend oui \| oui \| oui \| non Arguments : ```text le paramètre est l'entier fixant le nombre maximal de nouvelles sessions acceptées par seconde sur le 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 fragiles. 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 taux de connexions SMTP à 10 par seconde au maximum ```haproxy listen smtp mode tcp bind :25 rate-limit sessions 10 server smtp1 127.0.0.1:1025 ``` Note : lorsque le taux maximal est atteint, l'état du frontal n'est pas modifié, mais ses sockets apparaissent comme "WAITING" 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 ]