Le serveur ne peut pas traiter de requêtes pour le moment.
Quand l’utiliser
Maintenance ou surcharge. Incluez Retry-After si vous savez quand le service sera rétabli.
Causes courantes et solutions
Le serveur refuse les requêtes volontairement ou temporairement : mode maintenance, surcharge, tous les backends en échec aux health checks, ou limite de débit, puisque limit_req de nginx renvoie 503 par défaut. Sur un répartiteur de charge, 503 signifie généralement qu’aucune cible n’est enregistrée ou saine : vérifiez l’état des cibles, le chemin et le port du health check, et si les nouveaux déploiements le passent. L’ingress Kubernetes affiche la même chose quand un Service n’a aucun endpoint prêt.
Pour une maintenance planifiée, renvoyez un 503 avec Retry-After plutôt qu’un 200 avec une page de maintenance, afin que les moteurs de recherche gardent vos pages indexées ; Google tolère un 503 pendant un jour ou deux, mais des pannes plus longues peuvent faire disparaître des URL de l’index. Les clients doivent réessayer avec un backoff et respecter Retry-After. Gardez des health checks légers, pour qu’une seule base de données lente ne retire pas toutes les instances de la rotation en même temps.
Erreur serveur (5xx)
Les codes 5xx sont des erreurs serveur : la requête est peut-être correcte, mais le serveur ou un composant derrière lui a échoué. Ils méritent une alerte.
À quoi ça ressemble
HTTP/1.1 503 Service UnavailableComment l’envoyer
| Node.js / Express | res.status(503).end() |
|---|---|
| Python / Flask | return '', 503 |
| nginx | return 503; |
Comment le vérifier
curl -s -o /dev/null -w "%{http_code}\n" https://example.com/