HAProxy : rôle et répartition du trafic

Auteur : Rédaction Domeny.ForSale Publié le 27.09.2026

En bref : HAProxy est un logiciel qui reçoit le trafic réseau et le transmet à des serveurs sélectionnés pour faire fonctionner l’application. Il agit comme un proxy inverse et un répartiteur de charge : il sert d’intermédiaire pour les connexions et distribue le trafic entre les instances du service. Il aide à absorber une charge plus importante et à éviter les serveurs défaillants, mais son déploiement ne garantit pas à lui seul une disponibilité ininterrompue.

Comment HAProxy intervient entre l’utilisateur et l’application

Un proxy inverse, ou reverse proxy, reçoit les connexions pour le compte des serveurs applicatifs. L’utilisateur se connecte à l’adresse du service, derrière laquelle se trouve HAProxy, plutôt que directement à un serveur précis de l’infrastructure. HAProxy choisit la destination et lui transmet le trafic ; la réponse revient par cette même couche intermédiaire.

La répartition de charge, ou load balancing, consiste à distribuer le trafic entre les serveurs disponibles. Elle n’implique pas nécessairement une répartition parfaitement égale : une machine plus puissante peut recevoir davantage de tâches, tandis qu’un serveur en maintenance peut être exclu du traitement des nouvelles requêtes.

Deux notions importantes interviennent dans la configuration de HAProxy. Le frontend définit où le programme reçoit les connexions, par exemple sur le port 443 pour HTTPS. Le backend décrit un groupe de serveurs cibles et les règles permettant de les sélectionner. Un même frontend peut diriger le trafic vers différents backends selon le domaine ou le chemin de l’adresse.

Prise en charge de TCP, de HTTP et du chiffrement

HAProxy peut fonctionner à différents niveaux de communication. En mode TCP, il transmet les connexions sans prendre de décisions en fonction du contenu des requêtes HTTP. Cette approche est également utile pour des services autres que les sites web, dès lors qu’ils utilisent TCP.

En mode HTTP, HAProxy comprend les éléments de la requête, comme le nom d’hôte, le chemin et les en-têtes. Il peut ainsi diriger le trafic destiné à /api vers les serveurs API, et les autres requêtes vers l’application qui affiche le site. Ces règles prennent souvent la forme d’ACL, c’est-à-dire de conditions qui associent le trafic à des règles précises.

Avec HTTPS, il est important de déterminer où se termine TLS, le protocole qui sécurise la connexion :

Terminaison de TLS dans HAProxy : le programme gère le certificat et déchiffre le trafic, ce qui lui permet d’analyser HTTP. La connexion vers les serveurs en arrière-plan peut être chiffrée à nouveau.
Transmission de la connexion chiffrée : le serveur cible prend en charge TLS. HAProxy ne voit alors ni les chemins ni les en-têtes HTTP et ne peut donc pas les utiliser pour le routage.

Terminer TLS dans HAProxy ne signifie pas que la connexion avec l’application est automatiquement chiffrée. Ce segment doit être configuré séparément, en prévoyant aussi la vérification du certificat du serveur cible.

Comment la répartition du trafic aide en cas de panne

Imaginez une boutique en ligne fonctionnant sur trois serveurs applicatifs. HAProxy reçoit les requêtes des clients et les distribue selon la méthode round robin, c’est-à-dire à tour de rôle entre les serveurs disponibles. Une autre méthode, least connections, privilégie par exemple le serveur qui compte le moins de connexions actives. Le choix dépend de la nature du trafic.

HAProxy peut effectuer des health checks, c’est-à-dire des contrôles périodiques de disponibilité des serveurs en arrière-plan. Lorsqu’un serveur ne satisfait plus à ces contrôles, le programme peut cesser de lui attribuer du nouveau trafic et laisser les autres machines assurer le service. Les connexions actives avec le serveur défaillant peuvent toutefois être interrompues.

Vérifier simplement qu’un port est ouvert ne prouve pas que la boutique peut traiter une commande. Un contrôle HTTP portant sur un point de contrôle dédié de l’application, qui indique si elle est prête à fonctionner, est souvent plus pertinent. Il faut choisir soigneusement la portée du test : trop superficiel, il passera à côté d’une panne ; trop strict, il risque d’écarter inutilement des instances opérationnelles.

La répartition du trafic exige aussi une architecture applicative adaptée. Si le panier d’un client est enregistré uniquement dans la mémoire d’un serveur, une requête suivante envoyée à une autre machine risque de ne pas pouvoir le retrouver. Un stockage partagé des sessions peut aider. En revanche, l’affectation d’un client à un serveur précis, appelée sticky sessions, ne protège pas les données de session contre une panne de cette machine.

En quoi HAProxy diffère d’un serveur web

Le rôle principal de HAProxy est de servir d’intermédiaire dans les communications et de gérer le trafic, et non de servir les fichiers d’un site ou d’exécuter le code de l’application comme le ferait habituellement un serveur web. En pratique, il se place devant les serveurs web ou les processus applicatifs qui produisent les réponses. Il ne remplace pas non plus la base de données ni son mécanisme de réplication.

NGINX et Apache HTTP Server peuvent également agir comme des proxys inverses tout en remplissant le rôle de serveur web. Le choix ne se résume donc pas à déterminer quel outil est globalement le meilleur. HAProxy est un candidat pertinent lorsqu’on a besoin d’une couche distincte pour répartir le trafic TCP ou HTTP, contrôler l’état des serveurs en arrière-plan et appliquer des règles d’acheminement des connexions.

Pour un seul petit site, le serveur web existant ou le répartiteur de charge du fournisseur cloud peut suffire. Ajouter HAProxy introduit un composant supplémentaire dont il faut assurer les mises à jour, la surveillance et la maintenance de la configuration.

Que vérifier avant le déploiement

Une seule instance de HAProxy peut devenir un point unique de défaillance : si elle est indisponible, les utilisateurs ne pourront plus accéder aux serveurs applicatifs, même si ceux-ci fonctionnent. Un système exigeant une haute disponibilité a donc également besoin d’instances de proxy redondantes et d’un mécanisme de basculement du trafic entre elles.

Avant la mise en production, vérifiez quatre points :

Contrôles des serveurs en arrière-plan : détectent-ils que l’application n’est pas prête à fonctionner, au lieu de vérifier seulement qu’un port répond ?
Limites et délais d’attente : combien de connexions le système acceptera-t-il et combien de temps attendra-t-il une réponse ?
Adresse du client : comment l’application recevra-t-elle l’adresse IP réelle du client, et à quels en-têtes du proxy peut-elle se fier ?
Observabilité : les journaux et les métriques permettent-ils de repérer les erreurs, les latences et les surcharges ?

Vérifiez la disponibilité des fonctionnalités et la syntaxe de configuration dans la documentation officielle de la version de HAProxy utilisée. Effectuez un premier test avec deux instances de l’application : arrêtez-en une pendant que vous générez un trafic contrôlé, puis vérifiez à la fois la réaction du proxy et le comportement de la session utilisateur.

À lire aussi : Qu’est-ce que le 2FA ?