Le code 499 est propre à nginx et apparaît dans les journaux d’accès lorsque le client a fermé la connexion alors que nginx traitait encore la requête. Aucune réponse n’est envoyée, puisqu’il n’y a plus personne pour la recevoir.
Il signifie généralement que l’application en amont était lente : l’utilisateur a quitté la page, un répartiteur de charge ou un client d’API a atteint son propre délai d’attente, ou un contrôle de disponibilité (health check) a abandonné. Un pic de 499 associé à des temps de requête longs révèle un backend lent, alors que quelques 499 dus à des utilisateurs qui annulent le chargement d’une page sont normaux.
Lorsqu’un proxy placé devant nginx atteint son délai d’attente en premier, nginx consigne un 499 tandis que le proxy signale sa propre erreur, comme 504 ou le 524 de Cloudflare.
Exemple de réponse
# The client gave up before nginx had a response; nothing is sent.
# nginx access.log (last field: $request_time in seconds)
198.51.100.23 - - [06/Nov/2026:10:15:32 +0000] "GET /report?year=2026 HTTP/1.1" 499 0 "-" "Mozilla/5.0" 30.001SEO et vérification des redirections
Les robots d’exploration ne reçoivent jamais de 499, mais si Googlebot renonce à attendre une page lente, vos journaux affichent 499 pour ses requêtes. C’est le signe de temps de réponse du serveur trop longs, ce qui réduit le volume d’exploration de Google. Les vérificateurs de redirections abandonnent eux aussi sur des sauts très lents ; le Testeur de latence des redirections indique quel saut est lent.
Causes fréquentes et cas d’usage
- Le backend applicatif met plus de temps que ce que le client, le CDN ou le répartiteur de charge accepte d’attendre.
- Des utilisateurs annulent ou quittent une page lente avant qu’elle se charge.
- Les outils de supervision et les contrôles de disponibilité utilisent des délais d’attente courts.