503 Service Unavailable

Utilisation

Le code de statut 503 Service Unavailable signifie que le serveur ne peut pas satisfaire la requête HTTP pour une raison temporaire. Le serveur est saturé par une hausse soudaine du trafic, la ressource est verrouillée, le serveur redémarre, ou une mauvaise configuration du pare-feu bloque la requête.

De nombreux sites renvoient le code de statut 503 Service Unavailable pendant la maintenance du site, ce qui est l’approche recommandée pour garantir que le classement dans les moteurs de recherche n’est pas affecté.

Lorsque le serveur a connaissance du problème, par exemple une ressource verrouillée ou surchargée, l’en-tête HTTP Retry-After indique au client quand renvoyer la requête.

Amazon S3 renvoie 503 Slow Down lorsque le débit de requêtes dépasse les limites de débit par préfixe. Un pic soudain au-delà de ces seuils déclenche une limitation pendant que S3 redimensionne ses partitions en arrière-plan. Répartir les objets sur plusieurs préfixes, mettre en œuvre un backoff exponentiel et augmenter progressivement le débit de requêtes permet d’éviter l’erreur. S3 ne facture pas les réponses 503.

Fastly renvoie 503 Service Unavailable avec le texte de raison « Loop detected » lorsqu’une requête semble être réacheminée vers le même service Fastly ou a transité par trop de serveurs Fastly. Fastly suit les sauts de requête à l’aide des en-têtes Fastly-FF et CDN-Loop. Une requête est rejetée comme boucle lorsqu’elle dépasse l’une de ces limites : plus de trois passages antérieurs par le même POP pour le même service, plus de six services Fastly distincts dans le chemin de la requête, ou plus de vingt sauts au total sur l’ensemble des services. Les boucles surviennent couramment lorsque le même nom d’hôte est configuré à la fois comme domaine et comme backend d’un service, et que le DNS de ce nom d’hôte pointe vers Fastly. Utiliser un nom d’hôte d’origine distinct (par exemple origin.example.re) ou une adresse IP pour le backend évite la boucle.

Remarque

503 signifie que le serveur est temporairement indisponible pour tous les clients (surcharge, maintenance). 429 signifie qu’un client particulier a dépassé sa limite de débit. Utilisez 429 pour la limitation par client et 503 pour une indisponibilité à l’échelle du serveur.

Impact SEO

Googlebot interprète les erreurs 5xx comme un signal de réduire temporairement la vitesse d’exploration sur l’ensemble du site. Les URL déjà indexées sont d’abord conservées, mais une interruption prolongée amène Google à les retirer de l’index. Tout contenu renvoyé avec une réponse 503 est ignoré. Google traite 500, 502 et 503 de façon identique. 503 n’offre aucun avantage particulier par rapport aux autres codes 5xx pour une maintenance planifiée, contrairement à ce que suggèrent les conseils courants. Une erreur 5xx sur le fichier robots.txt est bien plus grave, même si toutes les autres pages du site renvoient 200. Google interrompt l’exploration pendant un maximum de 12 heures, puis se rabat sur une copie en cache pendant un maximum de 30 jours. Si l’erreur persiste, Google désindexe entièrement le site. Bingbot respecte Retry-After sur les réponses 503 pour planifier ses prochaines visites. Des réponses 503 persistantes empêchent l’indexation dans Bing.

Exemple

Le client demande une ressource et le serveur répond par un 503 Service Unavailable parce que la ressource est temporairement indisponible. L’en-tête Retry-After suggère de renvoyer la requête après 30 minutes.

Requête

GET /latest_quotes HTTP/1.1
Host: example.com

Réponse

HTTP/1.1 503 Service Unavailable
Content-Type: text/html; charset=UTF-8
Content-Length: 124
Retry-After: 1800

<html>
  <head>
    <title>Resource Busy</title>
  </head>
  <body>
    <p>Try again after 30 minutes.</p>
  </body>
</html>

Comment corriger

Déterminez si le 503 est intentionnel (mode maintenance) ou subi (surcharge, plantage). Un 503 intentionnel accompagné d’un en-tête Retry-After ne demande aucun débogage, seulement d’attendre la fin de la maintenance.

Pour les erreurs 503 non planifiées, vérifiez ces causes courantes :

Épuisement des ressources du serveur. Exécutez top, htop ou vmstat sur le serveur. Une utilisation élevée du CPU ou de la mémoire signifie que le serveur manque de capacité. Dans Apache, le journal d’erreurs affiche « server reached MaxRequestWorkers setting » lorsque tous les emplacements de workers sont occupés. Augmentez MaxRequestWorkers (et ServerLimit pour le MPM prefork) dans la configuration Apache. Dans nginx, augmentez worker_connections dans le bloc events.

Plantage du pool d’applications. PHP-FPM, Gunicorn ou un gestionnaire de processus similaire qui s’arrête sous la charge laisse le serveur web sans backend pour traiter les requêtes. Consultez les journaux du gestionnaire de processus, puis augmentez la taille du pool (pm.max_children dans PHP-FPM, —workers dans Gunicorn).

Épuisement du pool de connexions. Des pools de connexions vers la base de données ou vers une API externe qui se tarissent obligent l’application à rejeter les nouvelles requêtes. Augmentez la taille du pool dans la configuration de l’application et vérifiez que les connexions sont correctement libérées après usage.

Limitation de débit. Les modules nginx limit_req et limit_conn renvoient 503 (ou un statut personnalisé) lorsque les seuils sont dépassés. Examinez les directives limit_req_zone et limit_conn_zone. Augmentez les valeurs de burst ou ajoutez nodelay pour absorber les pics de trafic.

Échec du contrôle de santé du répartiteur de charge. Un contrôle de santé en échec retire le serveur de la rotation. Dans AWS ALB/NLB, vérifiez l’état des cibles dans la console. Dans les blocs upstream de nginx, examinez les réglages max_fails et fail_timeout.

Redémarrage déclenché par un déploiement. Des déploiements progressifs avec trop peu d’instances provoquent de brèves fenêtres de 503. Augmentez le nombre minimal d’instances saines ou utilisez des déploiements blue-green.

Limitation AWS S3 (503 Slow Down). S3 limite les requêtes qui dépassent les limites de débit par préfixe. Répartissez les objets sur plusieurs préfixes en utilisant des préfixes de clés aléatoires (par exemple hex-hash/original-key). Mettez en œuvre un backoff exponentiel démarrant à 1 seconde. Augmentez le débit de requêtes progressivement au lieu d’envoyer des rafales de trafic. Le SDK AWS réessaie automatiquement les réponses 503 SlowDown avec backoff lorsqu’il est correctement configuré.

Pour les pics de trafic, ajoutez un CDN ou une couche de cache afin de décharger les requêtes statiques. Mettez en place une supervision et des alertes sur le taux de 503 afin que les contraintes de ressources apparaissent avant une panne complète.

Références de code

.NET

HttpStatusCode.ServiceUnavailable

Rust

http::StatusCode::SERVICE_UNAVAILABLE

Rails

:service_unavailable

http.StatusServiceUnavailable

Symfony

Response::HTTP_SERVICE_UNAVAILABLE

Python3.5+

http.HTTPStatus.SERVICE_UNAVAILABLE

Java

java.net.HttpURLConnection.HTTP_UNAVAILABLE

Apache HttpComponents Core

org.apache.hc.core5.http.HttpStatus.SC_SERVICE_UNAVAILABLE

Angular

@angular/common/http/HttpStatusCode.ServiceUnavailable