Exploiter Cloudflare Load Balancing en toute sécurité

Publié le

14 juil. 2026

Mis à jour le

15 juil. 2026

Temps de lecture

21 min de lecture

Cloudflare Load Balancing s'insère directement dans le chemin de la requête : chaque pool, chaque monitor et chaque décision de steering configurés ici deviennent un signal que l'équipe d'astreinte doit pouvoir croire immédiatement, pas seulement lors d'une démonstration — la même discipline qu'applique une couche d'orchestration d'edge managée lorsqu'elle pilote l'équilibrage de charge pour de nombreux clients et fournisseurs à la fois.

Le fil rouge de ce guide est Acme Shop, une boutique en ligne qui veut créer des pools UE et US exploitables indépendamment, leur associer un monitor non mutateur, puis valider un hostname Layer 7 proxifié avant d'exposer un changement de production limité. À l'issue de ce travail, les opérateurs doivent savoir s'ils testent un routage au niveau de la requête ou de simples réponses DNS, ce que fait le cache dans chaque mode, et comment restaurer la configuration de steering précédente. Le hostname public shop.acme-shop.example d'Acme Shop privilégie le pool UE ; le pool US, testé en capacité, sert de repli. Son endpoint /healthz vérifie le process web et la dépendance catalogue requise, sans jamais passer de commande, modifier un stock ni réchauffer un cache coûteux.

Cloudflare Load Balancing peut router le trafic HTTP/S proxifié au niveau 7 vers des pools d'origine sains. Lorsque le load balancer reste en mode DNS uniquement, il renvoie l'adresse des endpoints sélectionnés dans les réponses DNS : un endpoint direct et non proxifié reçoit alors la connexion du client, tandis qu'un endpoint sélectionné qui demeure un CNAME Cloudflare proxifié peut continuer à traiter la requête HTTP suivante en mode proxifié. Aucun des deux modes n'est un commutateur de trafic instantané et universel : la cadence des monitors, l'interprétation de la santé, la capacité d'origine et, pour la sélection en DNS uniquement, le cache du résolveur récursif et la réutilisation des connexions client influencent tous l'expérience utilisateur. Exploitez Load Balancing comme un plan de contrôle de gestion du trafic, avec une sémantique de santé explicite et un comportement de dégradation testé.

Ce tutoriel fournit aux ingénieurs DevOps et plateforme un workflow de production conservateur. Il ne suppose pas que les contrôles de santé prouvent la justesse de l'application ni qu'un basculement se produira dans un délai fixe.

Prérequis

Préparez les éléments suivants avant de créer un load balancer de production :

• Un plan Cloudflare et une configuration de compte qui incluent les capacités Load Balancing que vous prévoyez d'utiliser. Confirmez les droits et contraintes produit actuelles dans Cloudflare Load Balancing. Plusieurs options utilisées plus loin dans ce guide — les régions de monitoring les plus larges, le steering Least Outstanding Requests et les surcharges géographiques pop_pools — sont réservées aux comptes Enterprise ; vérifiez leur disponibilité en premier.
• Au moins deux pools d'origine exploitables indépendamment lorsque la conception du service exige un basculement. Un second pool qui partage le même domaine de défaillance n'apporte pas une résilience significative.
• Un endpoint d'origine adapté aux contrôles de santé synthétiques, avec des exigences d'authentification documentées, un code de statut, un corps et un périmètre de dépendances attendus.
• Des données de capacité pour chaque pool d'origine, incluant charge normale, charge soutenue sûre, comportement en rafale, limites de connexion, délai d'autoscaling et limites de base de données ou aval.
• Un accès à la configuration Cloudflare DNS et Load Balancing, ainsi qu'aux métriques et logs d'origine, et une fenêtre de changement coordonnée.

Étape 1 : Cloudflare Load Balancing et les contrôles de santé d'origine

Commencez par le hostname visible par l'utilisateur et le chemin de requête exact à protéger. Décidez si le load balancer répond à l'apex, à un sous-domaine tel que api.example.com ou à un hostname de service dédié. Le hostname doit disposer d'une configuration Cloudflare DNS compatible avec la configuration du load balancer.

Définissez ensuite ce que signifie « sain ». Un monitor vérifie la réponse observée depuis l'infrastructure de monitoring Cloudflare ; il ne prouve pas que chaque parcours applicatif, localisation utilisateur ou dépendance est sain. Cloudflare documente les champs des monitors et l'évaluation de statut dans Monitors.

Un endpoint de santé utile doit :

• Être rapide et non authentifié du point de vue du monitor, ou utiliser délibérément la configuration de requête prise en charge par le monitor.
• Valider les dépendances dont la perte doit déclencher un déplacement de trafic, sans rendre le contrôle si large qu'une dépendance non critique provoque un basculement inutile.
• Renvoyer systématiquement le statut attendu configuré et, lorsqu'il est utilisé, le corps de réponse attendu.
• Éviter de muter des données, de réchauffer des caches coûteux ou de créer une charge significative à l'intervalle du monitor.

Documentez séparément la sémantique de route et la sémantique de santé. Une réponse 200 de /healthz ne garantit pas que chaque route, tenant, flux d'authentification ou opération d'écriture est utilisable.

Comment Cloudflare détermine qu'un contrôle de santé d'origine a échoué

Les contrôles de santé d'origine s'exécutent depuis plusieurs points d'observation à la fois, pas un seul. Les sondes partent des data centers de la région de monitoring du monitor — trois par région par défaut — et Cloudflare applique une règle de majorité à deux niveaux : une région est saine quand la majorité de ses sondeurs réussissent, et l'endpoint est sain quand la majorité des régions participantes est d'accord. Les comptes Enterprise peuvent élargir la couverture à « All Regions » ou « All Data Centers », que certaines politiques de steering exigent explicitement ; mais une couverture plus large multiplie aussi le volume de requêtes envoyées à l'endpoint de santé. Recalculez ce débit attendu au lieu de supposer que le budget « peu coûteux et sans effet de bord » reste valable une fois chaque data center engagé.

Un en-tête Host, un SNI TLS ou un suivi de redirections mal alignés expliquent souvent qu'un monitor se déclare non sain alors qu'une requête lancée depuis le terminal d'un ingénieur réussit : le monitor et le trafic de production ne testent alors pas la même requête.

Étape 2 : créer des pools avec des limites de capacité

Un pool regroupe des origines et associe un comportement de monitor et des métadonnées d'origine. Créez un pool pour chaque destination de trafic ou domaine de défaillance, puis ajoutez les origines avec l'adresse, le port, le poids et l'état d'activation corrects. Utilisez Pools comme référence de configuration.

Pour chaque pool, consignez :

• Le rôle prévu du pool : primaire, primaire régional, standby, maintenance ou cible d'évacuation.
• Les origines qu'il contient et les dépendances partagées sur lesquelles elles reposent.
• Le comportement du monitor sain et non sain, y compris l'endpoint, la méthode, la réponse attendue, le timeout, l'intervalle, les retries et le critère de passages consécutifs à down.
• La capacité de réception sûre pour le trafic transféré depuis un autre pool.
• Le signal côté origine qui indique aux opérateurs que le pool approche de la saturation.

Ne dimensionnez pas un pool standby uniquement pour son faible trafic normal. S'il peut recevoir du trafic de basculement, validez sa capacité à l'accepter et tenez compte du délai d'autoscaling, des pools de connexions, des bases de données, des quotas tiers et des cold starts de cache. Cloudflare peut choisir un pool selon la configuration, mais ne peut pas créer de capacité d'origine.

Le pool d'essai acme-apac-secondary

Acme Shop ajoute plus tard un troisième pool, acme-apac-secondary, pour tester le steering géographique vers sa clientèle APAC sans engager cette région sur la totalité du trafic de production. Même un pool d'essai a besoin de son propre monitor, d'un plafond de capacité documenté et d'un état d'activation explicite : une origine laissée activée sans revue de capacité peut absorber du trafic réel dès qu'un changement de steering l'active involontairement.

Étape 3 : configurer le steering de Cloudflare Load Balancing

Créez le load balancer pour le hostname et attachez des pools de repli ordonnés. Configurez le steering selon l'objectif de gestion du trafic, puis examinez le comportement applicable dans les politiques de steering global. Les politiques de steering disponibles et leurs résultats dépendent de la configuration choisie ; vérifiez la représentation dashboard ou API Cloudflare au lieu de déduire un comportement depuis le nom d'une politique.

Lors du choix d'une politique de steering, définissez la question opérationnelle à laquelle elle répond : le steering géolocalisé guide vers des pools désignés sans prouver qu'ils sont les plus rapides pour chaque chemin réseau ; le steering dynamique s'appuie sur les mesures Cloudflare, mais la latence observée inclut aussi le DNS, la connexion, l'application et l'origine ; les approches aléatoires ou pondérées distribuent le trafic entre pools intentionnellement équivalents, si les poids reflètent la capacité réelle ; un ordre de repli fixe convient à une relation claire primaire/standby.

Configurez délibérément les pools de repli et confirmez le comportement attendu lorsqu'une origine, puis un pool entier, puis tous les pools candidats deviennent non sains. Les concepts Load Balancing décrivent la relation entre load balancers, pools, monitors et steering.

Le steering géographique et ses limites en mode DNS uniquement

Un load balancer Layer 7 proxifié applique le steering géographique sur le data center Cloudflare qui a reçu la requête, suivant fidèlement la localisation réelle du demandeur. Un load balancer en mode DNS uniquement déduit plutôt la localisation depuis le résolveur qui émet la requête, sauf si celui-ci relaie un indice EDNS Client Subnet (ECS) et que location_strategy le privilégie (prefer_ecs: always|proximity|geo, avec mode: pop|resolver_ip en repli). Les grands résolveurs publics ne relaient pas tous l'ECS : un hostname géo-piloté en DNS uniquement peut donc orienter silencieusement les utilisateurs selon la localisation de leur résolveur plutôt que la leur. Testez avec les résolveurs réellement utilisés par la clientèle d'Acme Shop avant de faire confiance à ce résultat.

Le steering dynamique a besoin d'une montée en charge et d'un signal RTT propre

Le steering dynamique (« latency ») choisit le pool au temps d'aller-retour le plus faible, via une moyenne mobile pondérée exponentielle construite à partir des sondes du monitor de santé — les mêmes contrôles de santé d'origine que ceux de l'étape 1 servent aussi de capteur de latence. La région de monitoring doit être « All Regions », ou « All Data Centers » en Enterprise, sans quoi la moyenne manque d'échantillons. À la première activation, laissez environ dix minutes à Cloudflare pour construire un profil RTT ; le trafic suit l'ordre de repli durant cette montée en charge, d'où la fausse alerte classique de tester trop tôt et de déclarer le routage cassé. Un monitor TCP ajoute une réserve : si une origine se termine derrière l'edge d'un autre fournisseur, le RTT mesuré reflète ce saut réseau, pas le chemin applicatif réel.

Least Outstanding Requests et l'ordre de repli des pools

Least Outstanding Requests dirige les nouvelles requêtes vers le pool traitant le moins de requêtes en vol, pondéré par le poids de steering et la santé de chaque pool ; réservé aux load balancers proxifiés, il se réduit silencieusement à un steering pondéré aléatoire en DNS uniquement, faute de suivi des requêtes en vol. Préférez-le au steering géo ou dynamique quand un pool mélange lectures peu coûteuses et opérations onéreuses — rapports, export en masse — susceptibles de saturer la capacité avant que le RTT ou la localisation seuls ne le révèlent. Définissez par ailleurs l'ordre de repli explicitement quelle que soit la politique retenue : il régit le trafic pendant la montée en charge du steering dynamique et chaque fois que tous les pools candidats sont non sains. La base d'Acme Shop reste default_pools: [acme-eu-primary, acme-us-standby], avec acme-us-standby comme fallback_pool ; pour tester le steering géographique vers acme-apac-secondary sans y toucher, Acme Shop ajoute une surcharge régionale region_pools — et, à grain plus fin, country_pools ou le pop_pools réservé aux comptes Enterprise — qui ne remplace default_pools que pour la région correspondante. Vérifiez le schéma actuel de l'API avant de vous y appuyer en production.

Étape 4 : choisir le mode proxifié avant de raisonner sur le cache ou le TTL

Pour shop.acme-shop.example, utilisez un load balancer Layer 7 proxifié (nuage orange) si l'objectif est un routage HTTP/S au niveau de la requête, avec le WAF, les Workers et les contrôles de cache Cloudflare disponibles. Un HIT de cache peut être servi en périphérie sans contacter un pool d'origine ; un MISS poursuit à travers la décision de routage Layer 7 en cours. L'éligibilité au cache et la clé de cache relèvent de décisions séparées de Cache Rules ou d'en-têtes d'origine, pas d'une propriété fournie par Load Balancing. Si le Tiered Cache est actif sur la zone, Smart Tiered Cache choisit un seul data center de niveau supérieur pour l'ensemble du pool équilibré, et non un par origine : évaluez ce comportement au niveau du pool, pas origine par origine.

Le mode DNS uniquement (nuage gris) renvoie l'adresse de l'endpoint sélectionné. Si cet endpoint est direct et non proxifié, le client s'y connecte directement et la requête ne bénéficie ni du cache, ni du WAF, ni des Workers. Si l'endpoint sélectionné est lui-même un CNAME Cloudflare proxifié, l'adresse renvoyée est celle de Cloudflare et la requête HTTP suivante peut toujours être proxifiée selon la configuration propre à cet endpoint. Le TTL DNS et le comportement du résolveur influencent le moment où une nouvelle réponse est demandée, tandis que les connexions existantes peuvent rester épinglées à une destination antérieure. Testez explicitement le type d'endpoint sélectionné ; ne déduisez pas le comportement du proxy HTTP du seul réglage DNS uniquement.

Définissez le TTL du load balancer comme un compromis entre agilité et volume de requêtes DNS, pour le seul comportement DNS uniquement qu'il régit — Cloudflare impose un plancher proche de 30 secondes en Enterprise et de 60 secondes ailleurs — puis vérifiez la valeur retenue par rapport aux conseils DNS TTL pour Load Balancing actuels de Cloudflare. Ne promettez pas un délai de basculement exact fondé uniquement sur l'intervalle du monitor ou le TTL.

Prévoyez ces effets :

• Les résolveurs récursifs peuvent conserver une réponse jusqu'à l'expiration de son TTL en cache ; le comportement du client et du résolveur peut ajouter une variation supplémentaire.
• Les utilisateurs disposant de connexions persistantes existantes peuvent ne pas observer une réponse DNS modifiée tant que la connexion n'est pas réessayée ou remplacée.
• Des TTL plus courts peuvent rendre de nouvelles réponses DNS disponibles plus tôt, mais n'éliminent pas le délai de détection du monitoring, le comportement du résolveur ou les contraintes de récupération côté origine.
• Les changements DNS guidés par la santé ne réparent pas les requêtes en cours déjà envoyées à une origine dégradée.

Pour les services Layer 7 proxifiés, validez l'affinité sélectionnée et la conception de drain d'endpoint là où c'est nécessaire. Pour les services en DNS uniquement, ne supposez jamais que des TTL courts produisent un routage, un cache ou un comportement de session équivalents à ceux d'un mode proxifié.

Étape 5 : affinité de session et basculement du répartiteur de charge

L'affinité de session et le basculement automatique du répartiteur de charge sont deux contrôles distincts que les opérateurs confondent régulièrement. L'affinité décide avec quelle origine un client continue de parler ; le basculement décide de ce qui arrive à une requête donnée lorsque cette origine échoue brièvement. Les deux sont réservés aux load balancers proxifiés, pour la même raison que le WAF, le cache et les Workers : Cloudflare ne peut ni suivre un cookie ni relancer une connexion qu'il ne termine jamais lui-même. Un hostname en DNS uniquement qui a besoin d'un routage collant signale en réalité qu'il devrait plutôt être proxifié.

Les load balancers proxifiés proposent trois types d'affinité : uniquement par cookie (un cookie __cflb, sécurisé et HttpOnly, avec une session par défaut de 23 heures sauf TTL personnalisé) ; par cookie avec repli sur l'IP (même cookie, mais l'IP client choisit l'endpoint initial avant qu'un cookie n'existe) ; et par en-tête HTTP (une clé de session dérivée d'en-têtes configurés). Cette dernière a un cas limite marquant : si la valeur de l'en-tête change en cours de conversation — un client qui fait tourner un jeton d'authentification ou un identifiant d'appareil — la clé de session change avec elle, et le client peut être silencieusement réaffecté à une autre origine sans aucune erreur visible.

Le basculement zero-downtime ne concerne qu'une seule requête heurtant une erreur de connexion Cloudflare-vers-origine (HTTP 521, 522, 523, 525 ou 526) : si une autre origine saine existe dans le même pool, Cloudflare la retente une fois avant de retomber sur la logique de steering et de repli. Cette relance est délibérément étroite — une tentative, une origine alternative, uniquement pour ces codes de connexion — afin d'absorber une requête malchanceuse isolée pendant que le monitor rattrape son retard ; elle ne remplace en rien une détection fondée sur le monitor. Réglez le mode de basculement (none, temporary ou sticky) pour qu'il corresponde à l'affinité utilisée : le mode sticky met à jour le cookie vers la nouvelle origine, ce que la plupart des services souhaitent, mais il n'est pas pris en charge pour l'affinité par en-tête ; un service qui en dépend doit prévoir un mode temporary ou none et traiter cette combinaison comme une limite connue, pas comme un bug à chasser.

Étape 6 : tester le chemin de défaillance complet en toute sécurité

Utilisez d'abord un hostname de staging et des pools représentatifs. Testez avec un volume de trafic contrôlé et un responsable de rollback présent. Ne commencez jamais par désactiver la seule origine de production saine.

Exécutez ce plan de test :

1. Confirmez que chaque origine sert directement la route applicative attendue et que son endpoint de monitor renvoie la réponse de succès configurée.
2. Confirmez que le hostname équilibré renvoie une réponse DNS associée au pool actif prévu et que les requêtes réelles l'atteignent.
3. Introduisez une défaillance réversible et visible par le monitor sur une origine. Vérifiez que le monitor la marque non saine selon ses seuils configurés, puis que la sélection de trafic évite cette origine lorsque la configuration l'exige.
4. Restaurez l'origine. Vérifiez la récupération du monitor et le comportement de retour configuré ; ne supposez pas que la récupération déplace nécessairement le trafic immédiatement ou automatiquement sans vérifier les règles de steering et repli choisies.
5. Introduisez une défaillance réversible affectant le pool actif uniquement après avoir confirmé que le pool de repli dispose d'une capacité suffisante. Observez à la fois les réponses DNS et les résultats applicatifs dans plusieurs contextes de résolveur ou clients contrôlés.
6. Faites un load test du pool récepteur au niveau de trafic transféré prévu, y compris les lectures, écritures, authentifications et appels aval critiques.
7. Testez une dégradation partielle qui renvoie 200 depuis l'endpoint de santé tandis qu'une route critique échoue. Utilisez le résultat pour décider si le monitor est intentionnellement étroit ou insuffisant pour l'objectif du service.
8. Si l'affinité de session est activée, confirmez que le cookie ou l'en-tête d'affinité survit sans changement à une seule relance zero-downtime, puis se repointe correctement après un basculement complet de pool.
9. Si le steering dynamique ou géographique est activé, répétez le test à la fois pendant la montée en charge du RTT et après qu'elle est terminée, ainsi qu'avec des résolveurs qui relaient et qui ne relaient pas l'ECS.

Consignez les horodatages de l'injection de défaillance, du changement d'état du monitor, des observations DNS, des premières erreurs client, des signaux de capacité de repli et de la récupération. Cela établit une plage observée pour cette architecture, et non un engagement de basculement universel.

Étape 7 : observer la santé, le trafic et la capacité

Surveillez trois couches pendant le déploiement et les incidents :

• La santé des monitors et pools Cloudflare : quelles origines et quels pools Cloudflare considère sains, et les échecs de monitor qui ont changé l'état.
• La sélection DNS et trafic : réponses de requête de résolveurs représentatifs, distribution du trafic de pool et requêtes atteignant chaque origine.
• La santé de l'application et de l'infrastructure : taux de succès des requêtes, latence, saturation, impact sur le budget d'erreur, capacité de base de données, profondeur de file et disponibilité des dépendances.

Cloudflare fournit des workflows opérationnels propres au produit dans Load Balancing analytics. Associez ces signaux à la télémétrie d'origine ; un monitor vert associé à une origine saturée n'est pas un service sain.

Déclenchez des alertes sur des conditions actionnables telles qu'un pool actif qui perd de la capacité, un pool de repli qui reçoit du trafic inattendu, le flapping de monitor, des erreurs d'origine qui augmentent après un changement de steering et une capacité standby qui tombe sous la marge de transfert requise. Incluez la version de configuration active ou la référence de changement dans la chronologie opérationnelle.

Rollback

Avant de modifier un pool, monitor ou une politique de steering de production, capturez la configuration actuelle et nommez l'action de rollback. Gardez les changements suffisamment petits pour qu'une régression observée ait une cause claire.

Les choix de rollback dépendent du changement :

• Restaurez la politique de steering ou l'ordre des pools de repli antérieurs si un changement de politique envoie le trafic de manière inattendue.
• Réactivez une origine auparavant saine uniquement après avoir confirmé qu'elle peut recevoir le trafic en toute sécurité.
• Rétablissez un monitor à son endpoint ou à ses seuils antérieurs si un nouveau contrôle crée de faux états non sains, tout en examinant si l'ancien contrôle masquait un risque de service réel.
• Déplacez le trafic hors d'un pool uniquement après avoir confirmé la capacité de destination et les limites de dépendance.
• Revenez sur le type d'affinité de session ou le mode de basculement si un changement laisse des clients épinglés à une origine en cours de drain ou fragmente les sessions ; vérifiez le comportement réel du cookie ou de l'en-tête après le retour arrière, pas seulement le réglage affiché dans le dashboard.

Après le rollback, vérifiez les observations DNS, la distribution des requêtes d'origine, le statut des monitors, les flux utilisateur représentatifs et la saturation du pool récepteur. Ne déclarez pas le rétablissement uniquement parce que la mise à jour de configuration Cloudflare a réussi.

Pièges fréquents

• Utiliser un endpoint uniquement de liveness pour prendre des décisions de basculement pour une application riche en dépendances.
• Configurer un pool standby sans tester sa capacité à absorber le transfert.
• Supposer que le TTL configuré équivaut à une durée de basculement client garantie.
• Traiter un monitor sain comme la preuve que toutes les routes applicatives fonctionnent.
• Modifier monitors, pools, poids et steering dans une même release, rendant les régressions difficiles à isoler.
• Effectuer le basculement vers des origines qui partagent la même base de données, réseau, fournisseur d'identité ou dépendance tierce que le pool en échec.
• Comparer un monitor déclaré non sain à une requête directe réussie sans vérifier que Host, SNI TLS et suivi des redirections sont identiques entre le contrôle et le trafic réel.
• Piloter un hostname en mode DNS uniquement alors que le service a besoin d'une affinité de session ou d'un comportement de proxy que seul un load balancer proxifié peut fournir, ou activer son steering géographique sans vérifier si les résolveurs des clients relaient un indice ECS.
• Interpréter les toutes premières minutes du steering dynamique comme un échec de routage alors que le monitor construit encore son profil RTT, ou choisir une affinité par en-tête HTTP avec un mode de basculement sticky qu'elle ne prend pas en charge.

Réserves techniques

Le comportement de Load Balancing est façonné par le monitor configuré, la santé des pools, la politique de steering, l'ordre de repli, l'affinité de session, le mode de basculement, le DNS TTL, le cache du résolveur, les connexions client, les paramètres produit Cloudflare et le comportement d'origine. Consultez la documentation Cloudflare actuelle avant de vous engager sur la disponibilité d'une politique, la détection de santé, le mouvement de trafic ou le temps de récupération. Définissez les objectifs de service à partir de résultats utilisateur mesurés et d'une capacité testée plutôt que d'une valeur de configuration fournisseur seule.

Sources principales

• Cloudflare Load Balancing overview
• Cloudflare Load Balancing concepts
• Cloudflare Load Balancing pools
• Cloudflare Load Balancing monitors
• Cloudflare Load Balancing proxy status
• Cloudflare Load Balancing traffic steering policies
• Cloudflare Load Balancing dynamic steering
• Cloudflare Load Balancing session affinity
• Cloudflare Load Balancing adaptive routing and zero-downtime failover
• Cloudflare Load Balancing DNS records and TTL
• Cloudflare Load Balancing analytics