Aller au contenu

AWS Mis à jour le 2026-07-04

Erreurs CloudFront 502 et 504 depuis l'origine : la liste de contrôle côté origine

Un 502 CloudFront signifie que la connexion ou la poignée de main TLS avec l'origine a échoué; un 504, que l'origine a dépassé le délai. Voici la liste de contrôle côté origine qui trouve la cause, dans l'ordre.

Un 502 ou un 504 CloudFront n’est presque jamais la faute de CloudFront. Un 502 Bad Gateway signifie que CloudFront a tendu la main à votre origine et que la conversation a échoué — le plus souvent un certificat TLS sur l’origine qui ne correspond pas au nom de domaine d’origine, un certificat expiré, ou une connexion réinitialisée. Un 504 Gateway Timeout signifie que l’origine n’a pas répondu à temps : soit la connexion TCP ne s’est jamais établie dans le délai de connexion, soit la réponse n’a pas commencé dans le délai de réponse de l’origine (30 secondes par défaut). Les deux se diagnostiquent pareil : sortez CloudFront du portrait et parlez directement à l’origine.

Ce qui se passe

Quand une requête manque le cache, CloudFront ouvre une connexion depuis un emplacement de périphérie vers votre origine en utilisant le nom de domaine d’origine configuré sur la distribution — pas le nom d’hôte du visiteur. Cette distinction cause le 502 le plus courant : CloudFront se connecte à origin.example.com en HTTPS, l’origine présente un certificat pour *.example.com ou carrément pour le mauvais site, la vérification du nom échoue, et CloudFront retourne 502 au visiteur. Certificats autosignés, certificats expirés, chaînes incomplètes (intermédiaires manquants) et origines qui ne parlent que des versions TLS ou des chiffrements que CloudFront n’offre pas tombent tous dans le même panier.

La famille des 504 est temporelle. CloudFront tente la connexion TCP avec un délai configurable (10 secondes par défaut) et un nombre de tentatives (3 par défaut), puis attend les premiers octets jusqu’au délai de réponse de l’origine. Les origines surchargées, occupées à du travail de base de données lent, ou derrière un groupe de sécurité qui laisse tomber silencieusement le trafic de CloudFront produisent des 504. Un cas plus subtil : le délai d’inactivité keep-alive HTTP de l’origine plus court que le délai keep-alive d’origine de CloudFront, de sorte que l’origine raccroche des connexions réutilisées en plein vol et que des requêtes échouent par intermittence — habituellement des 502 sporadiques sous trafic constant.

Chacun de ces cas se voit du côté origine, et c’est pourquoi la liste de contrôle ci-dessous commence là.

Quoi vérifier en premier

  • L’origine elle-même est-elle saine? Si l’origine est un ALB, vérifiez ses propres 5xx et l’état de ses cibles avant de blâmer le CDN — un ALB qui retourne 502/504 est relayé tel quel.
  • Le certificat de l’origine correspond-il au nom de domaine d’origine configuré sur la distribution — pas au domaine visiteur?
  • L’échec est-il constant ou intermittent? Constant pointe vers le TLS ou les groupes de sécurité; intermittent pointe vers les délais, la discordance keep-alive ou une origine surchargée.
  • Quelque chose a-t-il changé? Renouvellements de certificats, modifications de groupes de sécurité et déploiements côté origine sont les suspects habituels au jour un d’une tempête de 502.

Comment vérifier

Reproduisez la vue que CloudFront a de l’origine depuis votre propre machine :

# Parler à l'origine exactement comme CloudFront : nom de domaine d'origine, HTTPS
curl -svo /dev/null https://origin.example.com/health --max-time 35

# Inspecter le certificat que l'origine présente, chaîne incluse
echo | openssl s_client -connect origin.example.com:443 \
  -servername origin.example.com 2>/dev/null \
  | openssl x509 -noout -subject -issuer -enddate

# Temps jusqu'au premier octet sur le chemin lent que CloudFront échoue
curl -so /dev/null -w 'connect=%{time_connect}s ttfb=%{time_starttransfer}s\n' \
  https://origin.example.com/slow-endpoint

Une discordance de nom de certificat, un notAfter expiré ou un ttfb au-dessus de 30 secondes reproduit l’erreur CloudFront localement, et vous arrêtez de deviner. Confirmez ensuite ce que la périphérie enregistre : les journaux standards CloudFront portent un x-edge-result-type à Error et un x-edge-detailed-result-type comme OriginConnectError, OriginTimeout ou OriginSSLError — ce champ à lui seul sépare les causes de 502 de celles de 504. La métrique 5xxErrorRate de la distribution vit dans CloudWatch sous us-east-1, visible à CloudFront > Distributions > (id) > Monitoring.

Les réglages de délais et de keep-alive se trouvent à CloudFront > Distributions > (id) > Origins > Edit > Additional settings — délai de réponse, délai keep-alive, tentatives et délai de connexion sont tous par origine.

Le correctif

  1. Réparez le certificat de l’origine. Le certificat doit être valide, non expiré, chaîné à une autorité de confiance avec les intermédiaires inclus, et couvrir exactement le nom de domaine d’origine. Sur une origine ALB, ça veut dire que le certificat de l’ALB couvre origin.example.com; sur un serveur maison, vérifiez l’hôte virtuel qui sert réellement ce nom. C’est la cause numéro un des 502 francs.
  2. Ouvrez le chemin. Le groupe de sécurité ou le pare-feu de l’origine doit accepter le trafic de CloudFront. Pour une origine ALB, le motif pratique est d’autoriser la liste de préfixes gérée de CloudFront côté origine sur le 443. Une règle à moitié ouverte produit des délais dépassés, pas des refus — ce qui se lit comme un 504.
  3. Montez le délai de réponse pour les points de terminaison réellement lents. La génération de rapports ou les gros téléversements qui exigent légitimement plus de 30 secondes justifient de monter le délai de réponse par origine. C’est un réglage par origine : montez-le pour l’origine API lente, pas pour la statique.
  4. Alignez les délais keep-alive. Réglez le délai d’inactivité de l’origine plus long que le délai keep-alive d’origine de CloudFront, pour que l’origine ne raccroche jamais en premier. Sur un ALB, c’est l’attribut de délai d’inactivité du répartiteur; sur nginx, keepalive_timeout.
  5. Réglez la surcharge de l’origine au lieu de la masquer. Si le TTFB se dégrade sous la charge, des délais plus longs ne font que mettre la douleur en file. Faites grossir l’origine, ajustez l’application, et assurez-vous que les vérifications de l’état du répartiteur évincent les mauvaises cibles assez vite pour que l’ALB ne relaie pas vers l’instance mourante.
  6. Accordez les attentes de protocole. Une politique de protocole d’origine HTTPS-only contre une origine qui n’écoute que sur le 80 (ou l’inverse, avec des redirections que CloudFront ne suivra pas côté origine) échoue proprement. Vérifiez la politique de protocole d’origine contre ce que l’origine sert vraiment.

Quand c’est la mauvaise approche

Si la page d’erreur dit 500 ou 503 plutôt que 502/504, l’origine a répondu — déboguez l’application, pas la connexion. Si les erreurs coïncident avec un événement côté AWS, consultez le tableau de bord AWS Health avant de réarchitecturer quoi que ce soit. Et ne « réglez » pas des 504 en allongeant indéfiniment le délai devant le point de terminaison lent : passé un point, le correctif honnête est le traitement asynchrone, parce qu’un visiteur qui attend 60 secondes une réponse synchrone, c’est un défaut de produit, pas un réglage d’infrastructure.

Erreurs fréquentes

  • Tester l’URL visiteur (qui frappe le cache et fonctionne) au lieu du nom de domaine d’origine, et conclure que l’origine va bien.
  • Renouveler le certificat de l’origine en oubliant la chaîne intermédiaire, ce qui passe les tests navigateur contre le domaine visiteur pendant que CloudFront continue d’échouer contre l’origine.
  • Monter le délai de réponse sur toutes les origines par réflexe, cachant un arrière-plan qui se dégrade pendant des mois.
  • Oublier qu’une origine ALB a ses propres délais et ses propres 5xx — deux mandataires, donc deux endroits à aligner.

Prévention

  • Créez des alarmes sur le 5xxErrorRate de la distribution et sur les percentiles de latence de l’origine, pour que la dérive soit visible avant de franchir les 30 secondes.
  • Surveillez l’expiration des certificats d’origine avec la métrique DaysToExpiry d’ACM quand c’est applicable, et une vérification externe sinon.
  • Gardez le TLS d’origine et les certificats côté visiteur dans le même calendrier de renouvellement — sinon ils échouent sur des horaires différents.
  • Activez les journaux standards CloudFront vers S3 avant l’incident; x-edge-detailed-result-type vaut peu si la journalisation commence après le feu.
  • Retestez le chemin d’origine après chaque changement de groupe de sécurité ou de WAF.

La référence des délais par origine et les définitions des types de résultat sont dans la documentation CloudFront. Si personne dans votre équipe ne possède vraiment l’environnement AWS de bout en bout, c’est la racine de la plupart de ces problèmes — Stack Harbor opère des comptes AWS au quotidien sous Opérations AWS, et vous pouvez réserver une revue AWS.