Azure Application Gateway : diagnostiquer les erreurs 502 sans mélanger DNS, TLS et backend health

Une erreur 502 sur Azure Application Gateway donne rarement la cause complète. Elle signale que le gateway n’a pas obtenu une réponse exploitable du backend, mais plusieurs couches peuvent produire ce résultat : DNS, routage, NSG, probe, certificat, hostname, timeout, backend arrêté, WAF mal interprété ou simple endpoint de santé mal choisi.

Le scénario traité ici est celui d’une application métier publiée derrière Application Gateway avec un listener HTTPS, un backend privé et des probes dédiées. L’objectif est de diagnostiquer sans tout mélanger. Un 502 ne doit pas déclencher directement une modification WAF, un changement de certificat ou un redémarrage applicatif. Il faut d’abord savoir quelle couche est en défaut.

Lire le modèle Application Gateway comme une chaîne

Application Gateway est plus simple à diagnostiquer quand on suit ses objets dans l’ordre. Le listener reçoit une requête pour un nom. La règle l’envoie vers un backend pool avec un backend setting. Le backend setting définit le protocole, le port, le hostname et la probe associée. La probe détermine si le backend est considéré sain.

Client HTTPS
-> listener app.example.com
-> rule app-prd
-> backend pool bp-app-prd
-> backend setting bhs-app-prd
-> probe probe-app-prd
-> backend HTTPS app.example.com:443

Le diagnostic doit suivre cette chaîne. Si la probe utilise un hostname différent du backend setting, le résultat peut être trompeur. Si le backend pool contient une IP privée mais que le certificat backend attend un nom DNS, le TLS peut échouer même si le serveur répond. Si la probe teste / alors que l’application exige une authentification, le backend peut être marqué unhealthy alors que l’application est disponible.

Commencer par backend health

La vue backend health donne le premier indice utile. Elle indique si Application Gateway considère le backend sain, et souvent le message associé : probe failed, certificate mismatch, timeout, forbidden, connection refused ou DNS issue selon le cas. Ce message n’est pas une preuve définitive, mais il oriente la couche à vérifier.

az network application-gateway show-backend-health -g rg-network-hub-prod -n agw-internet-prod-001 -o table

Si le backend est unhealthy, il faut traiter la probe avant de tester le flux complet depuis Internet. Si le backend est healthy mais que le client reçoit 502, il faut regarder les règles, les listeners, les timeouts, les logs d’accès et le comportement applicatif sous requête réelle.

Vérifier le hostname backend

Le point le plus fréquent dans les publications HTTPS est le hostname utilisé côté backend. Quand le backend pool contient une adresse IP privée, Application Gateway ne peut pas deviner le nom que le serveur doit présenter dans son certificat. Le backend setting doit donc définir explicitement le hostname attendu.

az network application-gateway http-settings show -g rg-network-hub-prod --gateway-name agw-internet-prod-001 -n bhs-app-prd --query '{protocol:protocol, port:port, hostName:hostName, pickHostNameFromBackendAddress:pickHostNameFromBackendAddress, probe:probe.id}' -o json

Le résultat attendu doit montrer un protocole HTTPS, un port cohérent et un hostName explicite comme app.example.com. Appeler le backend par IP peut fonctionner en HTTP, mais devient fragile en HTTPS parce que la validation du certificat repose sur un nom.

Tester depuis un point proche du gateway

Un test depuis un poste administrateur ne prouve pas que le gateway atteint le backend. Il faut tester depuis une source qui partage le chemin réseau avec Application Gateway : une VM de diagnostic dans le hub ou le spoke concerné, selon le design. Le test doit utiliser le hostname backend, pas seulement l’adresse IP.

nslookup app.example.com
curl -vk https://app.example.com/health
curl -vk --resolve app.example.com:443:10.10.54.8 https://app.example.com/health

La dernière commande force l’adresse IP tout en gardant le hostname TLS. Elle permet de vérifier le serveur et le certificat sans dépendre de la résolution DNS locale. Si ce test échoue, la cause est souvent côté backend : certificat, reverse proxy, application arrêtée, port fermé ou chemin de health check incorrect.

Choisir une probe représentative mais stable

Une probe doit tester la disponibilité technique du backend, pas un parcours métier complet. Elle doit être rapide, stable, peu coûteuse et ne pas dépendre d’un service tiers. Une page protégée par authentification n’est pas toujours un bon choix. Un endpoint /health peut être pertinent s’il reflète l’état minimal attendu par le gateway.

az network application-gateway probe show -g rg-network-hub-prod --gateway-name agw-internet-prod-001 -n probe-app-prd --query '{protocol:protocol, host:host, path:path, interval:interval, timeout:timeout, match:match}' -o json

Une probe trop stricte crée des indisponibilités artificielles. Une probe trop permissive laisse passer un backend partiellement cassé. Le bon compromis dépend de l’application, mais il doit être documenté. Si /health ne vérifie que Nginx, le gateway protège seulement la disponibilité du reverse proxy. Si /health vérifie aussi une base distante, une panne de base peut sortir l’application du pool même si le frontal fonctionne.

Distinguer WAF et backend

Le WAF peut bloquer une requête avant qu’elle n’atteigne l’application, mais il ne doit pas devenir le suspect par défaut de chaque 502. Un blocage WAF produit normalement des traces dans les logs WAF et un comportement différent d’un backend unhealthy. Il faut regarder les journaux associés à la même période et, si possible, au même identifiant de corrélation.

Si backend unhealthy
Lire backend health
Vérifier probe, hostname, TLS, port et routage

Si backend healthy mais client en erreur
Vérifier listener, rule, logs d'accès, timeout et application

Si suspicion WAF
Chercher un blocage explicite dans les logs WAF
Ne pas créer d'exception avant d'avoir identifié la règle

Les exceptions WAF doivent rester ciblées. Une exception globale créée pour faire disparaître une erreur masque souvent un problème de publication ou d’application.

Conclusion

Diagnostiquer un 502 Application Gateway demande de suivre la chaîne dans l’ordre : listener, rule, backend setting, pool, probe, réseau, TLS et application. Les erreurs deviennent plus lisibles quand le hostname backend est explicite, que la probe teste un endpoint stable et que les logs sont consultés par couche.

Le bon runbook ne dit pas seulement quoi relancer. Il dit quelle hypothèse chaque commande valide. C’est cette discipline qui évite les corrections hasardeuses : changer le WAF pour un problème TLS, modifier le DNS pour une probe mal choisie, ou redémarrer une application alors que le backend setting appelle le mauvais nom.