Performance & Haute Disponibilité : Configurer un Reverse Proxy / Load Balancer avec HAProxy pour vos applications web

Vous connaissez le scénario.

Votre application tourne nickel en local. Sur votre machine ça répond en 30 ms, tout le monde est content. Puis vous déployez en prod, arrive un pic de trafic, et là... les temps de réponse deviennent irréguliers. Des pages qui chargent vite, puis lentement. Quelques 502. Des connexions qui restent bloquées. Et le pire, c’est quand un seul serveur applicatif tombe et que tout le monde tombe avec lui.

C’est exactement le genre de moment où « juste mettre Nginx devant » ne suffit plus. Ou plutôt, ça suffit parfois, mais vous voulez quelque chose de plus précis sur le load balancing, les health checks, la tolérance aux pannes, et une visibilité claire sur ce qui se passe.

HAProxy est très bon là dedans. Très stable. Très utilisé. Et il sait faire du L4 et du L7, donc du TCP pur ou du HTTP avec des règles de routage. Il sait aussi vérifier l’état de vos backends, exposer des stats, gérer des timeouts correctement, et encaisser des volumes assez absurdes si on le configure proprément.

L’intention de cet article : vous donner une configuration HAProxy production-ready, simple, lisible, et surtout maintenable. Pas une usine à gaz. Un socle.

Ce que vous gagnez concrètement :

• Répartition de charge sur plusieurs serveurs.
• Failover automatique si un backend tombe.
• Temps de réponse plus stable, moins de saturation.
• Déploiements rolling plus sûrs, avec possibilité de drainer un serveur.
• Observabilité correcte, donc moins de « on devine ».

Pourquoi HAProxy (et pas juste un Nginx/Apache) quand on parle performance + haute disponibilité

Nginx et Apache savent faire reverse proxy et même load balancing, oui. Mais HAProxy a été pensé pour ça dès le départ. Il brille sur :

• Le load balancing avancé, très fin, avec des algorithmes adaptés à différents profils de charge.
• /healthfallrise
• La visibilité opérationnelle via la page stats et des logs vraiment orientés performance.
• La robustesse. HAProxy est souvent l’outil qui continue de respirer quand le reste panique.

Et sur des architectures où la haute dispo est une vraie exigence, HAProxy s’intègre naturellement avec Keepalived pour supprimer le SPOF (point unique de défaillance).

Proxy inversé vs répartition de charge : ce que vous devez comprendre avant de configurer

On pose les définitions, vite et bien.

Un reverse proxy, c’est un point d’entrée unique. Le client parle au proxy, le proxy parle à votre appli. Ça permet :

• Terminaison TLS (HTTPS) au niveau du proxy.
• Routage par hostname (Host header) ou par chemin (path).
• Ajout d’en-têtes utiles (X-Forwarded-For, X-Forwarded-Proto).
• Un peu de sécurité et d’hygiène, genre forcer HTTPS, gérer certains headers.

Un load balancer, c’est un reverse proxy qui distribue vers plusieurs serveurs. Il doit gérer :

• La distribution (roundrobin, leastconn, etc.).
• La détection de panne et le retrait automatique d’un backend.
• Parfois la persistance de session (sticky sessions) si votre appli est stateful.

Et L4 vs L7, c’est important.

• L4 (TCP) : HAProxy voit des connexions TCP, pas le HTTP. C’est rapide, simple, parfait pour des protocoles non HTTP ou quand vous voulez juste passer le flux. Moins d’observabilité, moins de routage fin.
• L7 (HTTP) : HAProxy comprend HTTP, peut router selon Host, path, headers, faire des redirections, des règles. Beaucoup plus flexible. En pratique, pour une appli web, vous êtes souvent en L7.

Schéma mental simple :

Client → HAProxy → pool de backends (web/app) → (optionnel) cache/DB

Architecture cible (simple mais solide) pour une appli web

Une architecture de référence très classique :

• 1 serveur HAProxy (dans un premier temps).
• 2 serveurs backend minimum (app1, app2).
• Vos backends parlent en HTTP interne (ou HTTPS interne si vous devez, mais on va commencer simple).

Prérequis à valider avant de toucher la config :

• DNS pointant vers l’IP publique du HAProxy.
• Ports ouverts : 80 et 443 vers HAProxy.
• Accès admin au serveur HAProxy.
• Certificats TLS prêts (ou une stratégie pour les obtenir).
• Logs : savoir si vous utilisez journald ou rsyslog.
• Backends accessibles depuis HAProxy sur le réseau privé.

Où faire tourner HAProxy :

• VM dédiée : souvent le meilleur compromis.
• Bare-metal : top si vous avez de gros volumes et un réseau propre.
• Conteneur : possible, mais soyez attentif au réseau, aux logs, au reload, et à l’accès aux certificats.

Plan de nommage, ça a l’air bête, mais ça vous sauve la vie :

• public_httppublic_https
• app_poolapi_pool
• host_apppath_api

Installation de HAProxy et premières vérifications

Debian / Ubuntu

bash sudo apt update sudo apt install haproxy haproxy -v

RHEL / Alma / Rocky

bash sudo dnf install haproxy haproxy -v

Sur la version : sur certaines distros, la version packagée est très conservative. Ce n’est pas forcément un mal. En prod, une version stable et maîtrisée vaut souvent mieux qu’une version très récente. Si vous avez besoin d’une feature précise, là oui, vous regardez les backports ou les dépôts officiels HAProxy.

Activer et vérifier :

bash sudo systemctl enable --now haproxy sudo systemctl status haproxy

Fichiers utiles :

• /etc/haproxy/haproxy.cfg
• journalctl -u haproxy/var/log/haproxy.log

Valider une config avant reload :

bash sudo haproxy -c -f /etc/haproxy/haproxy.cfg

Si c’est OK, vous rechargez proprement (on y revient plus bas).

Test de base : dans un premier temps, vous pouvez même faire tourner deux backends très simples (un Nginx sur chaque serveur backend) juste pour valider le flux.

Configurer un reverse proxy HTTP (frontend) : le point d’entrée propre

Voici une base HAProxy lisible. On va commencer par le HTTP en 80, avec un backend par défaut.

haproxy global log /dev/log local0 log /dev/log local1 notice maxconn 4000 user haproxy group haproxy daemon

defaults log global mode http option httplog option dontlognull

timeout http-request 10s
timeout connect 5s
timeout client  30s
timeout server  30s

frontend public_http bind :80 mode http

http-request set-header X-Forwarded-For %[src]
http-request set-header X-Forwarded-Proto http

default_backend app_pool

Deux points importants ici :

• X-Forwarded-For
• X-Forwarded-Proto

Les timeouts : c’est un vrai sujet. Sans timeouts cohérents, vous pouvez vous retrouver avec des connexions zombies qui épuisent votre capacité. Ceux ci sont des valeurs « raisonnables » pour beaucoup d’apps, mais adaptez selon vos endpoints lents, vos websockets, etc.

Configurer le load balancing (backend) : algorithmes, checks, et tolérance aux pannes

Un backend avec deux serveurs, health checks activés.

haproxy backend app_pool mode http balance roundrobin

option httpchk GET /health
http-check expect status 200

default-server inter 2s fall 3 rise 2

server app1 10.0.1.11:8080 check
server app2 10.0.1.12:8080 check

Choix de l’algorithme :

• roundrobin
• leastconn
• source

Health checks :

• inter 2s
• fall 3
• rise 2

app1app2

Poids et canary simple :

haproxy server app1 10.0.1.11:8080 check weight 90 server app2 10.0.1.12:8080 check weight 10

Vous envoyez 10 % sur un nouveau build, vous observez, puis vous inversez.

Gérer les sessions (sticky sessions) sans se tirer une balle dans le pied

Les sticky sessions, c’est le truc qu’on active vite parce que « sinon ça bug ». Et parfois c’est vrai, si votre appli stocke la session en mémoire locale.

Mais franchement, si vous pouvez éviter, évitez. Une appli stateless avec sessions dans Redis ou une DB est beaucoup plus simple à scaler et à rendre résiliente.

Quand c’est nécessaire, trois options classiques :

• Cookie de persistance (souvent le meilleur en HTTP).
• Stick-table (plus avancé, utile aussi pour du rate limiting).
• Source IP (simple mais souvent faux dans la vraie vie à cause du NAT, des opérateurs mobiles).

Exemple de persistance par cookie :

haproxy backend app_pool mode http balance roundrobin

cookie SRV insert indirect nocache httponly secure samesite=strict

server app1 10.0.1.11:8080 check cookie app1
server app2 10.0.1.12:8080 check cookie app2

Notes importantes :

• secure
• samesite=strict
• Sticky sessions = risque opérationnel : si le serveur ciblé est lent, un utilisateur reste collé à lui.

Alternative recommandée : externaliser la session (Redis) et couper les sticky sessions. Là, le load balancer peut faire son travail correctement.

Terminaison TLS (HTTPS) : chiffrer à l’entrée, simplifier les backends

Principe : HAProxy termine TLS, puis parle en HTTP aux backends.

.pem

bash cat fullchain.pem privkey.pem > /etc/ssl/private/example.com.pem chmod 600 /etc/ssl/private/example.com.pem

Frontend HTTPS :

haproxy frontend public_https bind :443 ssl crt /etc/ssl/private/example.com.pem alpn h2,http/1.1 mode http

http-request set-header X-Forwarded-For %[src]
http-request set-header X-Forwarded-Proto https

default_backend app_pool

Redirection HTTP vers HTTPS (propre, en 301) :

haproxy frontend public_http bind :80 mode http http-request redirect scheme https code 301 if !{ ssl_fc }

Sécurité TLS : vous pouvez restreindre les versions, sans faire une liste interminable de ciphers ici. Exemple raisonnable :

haproxy frontend public_https bind :443 ssl crt /etc/ssl/private/example.com.pem ssl-min-ver TLSv1.2

HSTS, uniquement si vous êtes sûr de votre HTTPS partout :

haproxy http-response set-header Strict-Transport-Security "max-age=31536000; includeSubDomains" if { ssl_fc }

alpn h2

Routage avancé : multi-applications par hostname et par chemin (sans complexité inutile)

Vous avez une app web et une API. Deux domaines, ou un domaine avec des paths. HAProxy gère ça très bien.

Routage par hostname :

haproxy frontend public_https bind :443 ssl crt /etc/ssl/private/wildcard.pem alpn h2,http/1.1 mode http

acl host_app hdr(host) -i app1.example.com
acl host_api hdr(host) -i api.example.com

use_backend app_pool if host_app
use_backend api_pool if host_api

default_backend app_pool

Routage par path :

haproxy frontend public_https mode http

acl path_api path_beg /api
use_backend api_pool if path_api
default_backend app_pool

Attention à la priorité : vos règles les plus spécifiques d’abord. Et gardez des backends séparés si vos contraintes ne sont pas les mêmes. Une API n’a pas forcément les mêmes timeouts, ni les mêmes règles, ni les mêmes limites.

Bonnes pratiques toutes bêtes :

• Nommez clairement vos ACL.
• Commentez la config. Deux lignes de contexte valent mieux que 30 minutes de fouille plus tard.

Observabilité : logs, stats HAProxy et signaux à surveiller

httplog

Exemples de lecture :

bash journalctl -u haproxy -f

Ce que vous cherchez dans les logs HAProxy :

• Temps total de réponse, temps côté backend.
• Codes HTTP (surtout 5xx).
• Retries.
• Terminations (coupures côté client, timeouts, resets).

Page stats : très utile, mais à exposer proprement, pas sur Internet.

haproxy listen haproxy_stats bind 10.0.1.10:8404 mode http stats enable stats uri /stats stats refresh 10s stats auth admin:un_mot_de_passe_solide

Restreignez par réseau, ou mettez ça derrière un VPN. Vraiment.

KPIs concrets à surveiller :

• Backends DOWN, flapping (UP/DOWN).
• Erreurs 5xx.
• Queue (si vous voyez de la queue, vous commencez à saturer).
• Sessions actives.
• Latence, idéalement p95 (même si HAProxy ne vous donne pas tout seul un p95 parfait, vous pouvez l’obtenir via votre stack de métriques).

Une alerte simple et efficace : « un serveur backend passe DOWN », et « taux de 5xx > x % sur 5 minutes ». Ça vous évite d’apprendre par Twitter que votre site est en panne.

Optimisations performance « qui comptent vraiment » (sans sur-optimiser)

On évite la micro chirurgie inutile. Les choses qui comptent souvent :

Timeouts et keep-alive

Des timeouts bien réglés évitent les connexions qui restent ouvertes trop longtemps. Et gardez des connexions réutilisables quand c’est pertinent. HAProxy gère ça bien, mais si votre appli est très lente, vous devez aligner les timeouts proxy et serveur.

Limites et protections

Protéger l’appli des pics, c’est parfois juste limiter un peu au niveau HAProxy :

• maxconn
• limites par frontend, par backend.

Exemple :

haproxy frontend public_https maxconn 2000

Vous pouvez aussi faire du rate limiting avec stick-table, mais c’est un sujet à part. L’idée ici : éviter l’effondrement total.

Compression

HAProxy peut compresser, mais ce n’est pas toujours le bon endroit. Souvent, vous compressez côté serveur applicatif ou, encore mieux, via CDN. La compression coûte du CPU. Si votre HAProxy devient le bottleneck, vous avez gagné un nouveau problème.

Réglages noyau (haut niveau)

Sans entrer dans une checklist sans fin : vérifiez au minimum les file descriptors et la capacité à gérer beaucoup de connexions. Et testez avant, testez après. Sinon vous ne savez pas si vous avez amélioré quoi que ce soit.

Choisir le bon algo

• leastconn
• roundrobin
• Ne compliquez pas tant que vous n’avez pas un signal clair.

Haute disponibilité du load balancer : éviter le SPOF avec deux HAProxy

Le vrai problème d’un seul HAProxy : c’est un SPOF. S’il tombe, tout tombe.

Architecture HA classique :

• 2 serveurs HAProxy.
• Une IP virtuelle (VIP) gérée par Keepalived (VRRP).
• Actif/passif : un seul sert le trafic, l’autre attend. En cas de panne, la VIP bascule.

Comportement en failover :

• La VIP change de machine.
• Convergence rapide, mais pas instantanée.
• Les sessions existantes peuvent être impactées, surtout si vous n’avez pas externalisé les sessions. D’où l’intérêt d’éviter la state locale.

Conseils pratiques :

• Même config HAProxy des deux côtés (Git, déploiement identique).
• Synchroniser les certificats TLS.
• Tester la bascule pour de vrai. Pas juste « ça devrait marcher ».

Alternative : un load balancer managé (cloud). Souvent très bien, et ça vous enlève une couche d’exploitation. Mais ce n’est pas toujours possible selon contraintes, budget, conformité, ou infra on-prem.

Déploiement et maintenance : recharger sans couper, tester sans casser

Différence importante :

• restart
• reload

Avant reload : validez.

bash sudo haproxy -c -f /etc/haproxy/haproxy.cfg

Reload :

bash sudo systemctl reload haproxy

Tests basiques :

bash curl -I http://votre-domaine curl -I https://votre-domaine curl -I https://votre-domaine/health

heyab

Rolling update côté backends : drain un serveur.

Vous pouvez désactiver temporairement un serveur dans le backend (via stats socket ou en modifiant la config), faire la mise à jour, le remettre. Le but : zéro downtime, ou en tout cas downtime très réduit.

Gestion de config :

• Versionnez dans Git.
• Commentez.
• Évitez le copier-coller opaque de snippets trouvés au hasard.

Plan de reprise :

• /etc/haproxy/haproxy.cfg
• Procédure de rollback claire.
• Et un rappel simple : ne déployez pas une config HAProxy non validée. Une virgule au mauvais endroit et vous vous coupez vous même.

Conclusion : une config HAProxy simple, mesurable, et prête pour la prod

Une bonne mise en place HAProxy, ce n’est pas « plein d’options ». C’est plutôt :

• Des frontends propres, avec headers et timeouts cohérents.
• Des backends équilibrés avec health checks fiables.
• Une terminaison TLS nette, avec redirection HTTP vers HTTPS.
• Du routage clair si vous avez plusieurs apps.
• De l’observabilité via logs et stats.
• Et si vous voulez vraiment dormir tranquille, deux HAProxy avec une VIP pour éviter le SPOF.

La méthode qui marche presque toujours : partir simple, mesurer (stats, logs, erreurs, latence), et optimiser ensuite. Pas l’inverse.

Prochaine étape, si vous sentez que ça grandit : ajouter un CDN, un WAF, de l’autoscaling, ou penser multi région. Mais honnêtement, déjà avec une base HAProxy bien faite, vous allez éliminer pas mal de chaos. Et ça, c’est précieux.

Questions fréquemment posées

Pourquoi HAProxy est-il préférable à Nginx ou Apache pour la haute disponibilité et la performance ?

HAProxy a été conçu spécifiquement pour le load balancing avancé et la haute disponibilité. Il offre des algorithmes de répartition de charge très fins, des health checks approfondis (comme vérifier une URL /health avec des critères précis), une excellente visibilité opérationnelle via une page de statistiques et des logs orientés performance, ainsi qu'une robustesse éprouvée qui lui permet de rester stable même en cas de forte charge ou de panne partielle. En outre, HAProxy s'intègre naturellement avec Keepalived pour éliminer les points uniques de défaillance (SPOF).

Quelle est la différence entre un reverse proxy et un load balancer ?

Un reverse proxy agit comme un point d'entrée unique qui reçoit les requêtes clients et les transmet à votre application. Il gère notamment la terminaison TLS, le routage par hostname ou chemin, l'ajout d'en-têtes utiles, et améliore la sécurité. Un load balancer est un reverse proxy spécialisé qui distribue les requêtes vers plusieurs serveurs backend selon différents algorithmes (roundrobin, leastconn...), détecte automatiquement les pannes et retire les serveurs défaillants, et peut gérer la persistance de session si nécessaire.

Quelles sont les différences entre le mode L4 (TCP) et L7 (HTTP) dans HAProxy ?

En mode L4 (TCP), HAProxy gère uniquement les connexions TCP sans analyser le protocole HTTP, ce qui est plus rapide et adapté aux protocoles non-HTTP ou au simple passage de flux. Cependant, cela offre moins d'observabilité et moins de possibilités de routage fin. En mode L7 (HTTP), HAProxy comprend le protocole HTTP, permettant un routage basé sur l'hostname, le chemin ou les headers, des redirections, et des règles complexes. Pour une application web classique, le mode L7 est généralement privilégié.

Quels bénéfices concrets apporte HAProxy dans une architecture web en production ?

HAProxy permet une répartition efficace de la charge sur plusieurs serveurs backend, assure un failover automatique en cas de panne d'un serveur, stabilise les temps de réponse en évitant la saturation, facilite des déploiements rolling sûrs grâce à la possibilité de drainer un serveur avant arrêt, et offre une bonne observabilité grâce à ses statistiques intégrées. Cela améliore significativement la résilience et la performance globale de votre application.

Quelle architecture simple mais solide recommandez-vous pour déployer HAProxy avec une application web ?

Une architecture classique consiste à avoir au minimum un serveur HAProxy dédié exposé publiquement sur lequel pointe votre DNS, avec au moins deux serveurs backend applicatifs accessibles via un réseau privé interne. Les backends communiquent en HTTP ou HTTPS interne selon vos besoins. Le serveur HAProxy doit avoir les ports 80 et 443 ouverts pour recevoir le trafic public ainsi que l'accès administratif configuré. Des certificats TLS valides doivent être prêts pour sécuriser les connexions.

Quels prérequis faut-il valider avant de configurer HAProxy en production ?

Avant toute configuration il faut s'assurer que : votre DNS pointe vers l'adresse IP publique du serveur HAProxy ; que les ports 80 (HTTP) et 443 (HTTPS) sont ouverts vers ce serveur ; que vous avez accès administrateur au serveur HAProxy ; que vous disposez des certificats TLS nécessaires ou d'une stratégie pour les obtenir ; que vous savez quel système de logs vous utilisez (journald ou rsyslog) ; enfin que vos serveurs backend sont accessibles depuis HAProxy via votre réseau privé.