Ce que le 503 promet, et ce qu'il ne promet pas
Un 503, c'est le serveur qui dit « j'existe, je vous ai compris, revenez plus tard ». Contrairement à un 500, il ne prétend pas que quelque chose s'est cassé, et contrairement à un 502, il ne s'agit pas d'une conversation ratée avec une machine plus en arrière. C'est un refus avec un « pour l'instant » implicite.
Ce « pour l'instant » est la raison pour laquelle le 503 est le bon code pour une maintenance planifiée et pour la surcharge, et le mauvais code pour tout ce qui est permanent. Les moteurs de recherche le traitent comme temporaire et reviendront, ce qui est exactement ce que vous voulez pendant un déploiement et exactement ce que vous ne voulez pas sur une page que vous avez retirée — celle-là, c'est un 410 ou un 301.
Cause 1 — l'origine est à court de capacité
Chaque serveur a un plafond de travail simultané : enfants PHP-FPM, workers d'application, connexions à la base de données. Quand le plafond est atteint, une stack bien configurée refuse rapidement le nouveau travail avec un 503 au lieu de l'accepter et de finir en timeout. C'est le système qui se comporte correctement sous pression, même si cela ressemble à une panne.
Comment le reconnaître. Les 503 suivent le trafic : ils apparaissent aux pics et s'arrêtent quand le pic passe. Votre origine est en ligne tout du long et répond instantanément à une requête que vous faites pendant un moment calme.
Ce qui aide vraiment. Augmenter le nombre de workers déplace le plafond et déplace généralement le goulet d'étranglement vers la mémoire ou la base de données. La correction durable, c'est d'arrêter d'envoyer du travail répété à l'origine : mettez en cache les pages qui peuvent l'être, donnez-leur un TTL assez long pour compter, et laissez la périphérie absorber le pic. Une campagne qui fait fondre une origine à 200 requêtes par seconde, c'est souvent 195 requêtes pour la même poignée de pages.
Cause 2 — le mode maintenance
Les outils de déploiement et les plugins CMS placent le site derrière une page de maintenance et renvoient un 503 pendant qu'ils travaillent. C'est un comportement correct et c'est le bon code.
Deux choses peuvent mal tourner. La première est un mode maintenance qui n'est jamais levé — un déploiement raté laisse le fichier drapeau en place et le site sert du 503 longtemps après la fin du travail. La seconde est une page de maintenance servie avec un 200, ce qui dit aux robots que l'avis de maintenance est votre contenu réel et mérite d'être indexé.
Si le mode maintenance est actif pendant plus de quelques minutes, ajoutez un en-tête Retry-After. Cela coûte une ligne et c'est la différence entre un robot qui recule poliment et un robot qui décide que votre site n'est pas fiable.
Cause 3 — une limite de débit a rejeté la requête
Le rate limiting refuse les requêtes qui arrivent plus vite que le seuil configuré. Selon le logiciel et sa configuration, le rejet arrive sous forme de 429 Too Many Requests ou de 503 — nginx, par exemple, refuse les requêtes limitées avec un 503 sauf si on lui dit d'utiliser un autre code.
Cela compte quand vous lisez des journaux : une rafale de 503 qui touche un client, un chemin, ou un user agent, pendant que tout le reste est servi normalement, c'est une limite de débit qui fait son travail plutôt qu'un problème de capacité. La solution consiste à regarder qui heurte la limite. Si c'est un scraper, la limite fonctionne. Si c'est votre propre application mobile qui interroge un endpoint chaque seconde, la limite est correcte et c'est l'application qui a tort.
Cause 4 — la périphérie n'a pas d'origine pour ce nom d'hôte
C'est celle qui fait perdre un après-midi, et elle n'a rien à voir avec votre serveur.
Quand le DNS d'un nom d'hôte pointe vers une périphérie CDN mais que ce nom d'hôte n'a pas été configuré sur la périphérie — le compte n'existe pas encore, le nom d'hôte de diffusion n'a pas été ajouté, ou une faute de frappe a placé l'enregistrement sur le mauvais nom — la périphérie n'a aucune origine à interroger. Elle ne peut pas renvoyer un 502, car il n'y a pas eu de conversation ratée. Elle renvoie un 503 avec une page disant qu'aucun service n'est configuré pour ce domaine.
La séquence qui produit cela est toujours la même : quelqu'un change le DNS d'abord et termine la configuration du panneau ensuite, ou change le DNS pour www alors que le nom d'hôte avait été ajouté comme domaine nu. Le site « tombe » au moment où le DNS se propage, l'origine est parfaitement saine, et la correction prend une minute une fois qu'on arrête de regarder la mauvaise machine.
Comment le reconnaître instantanément. Lisez la page d'erreur plutôt que le seul code de statut. La page « aucun service configuré » d'un CDN est sans équivoque et nomme le problème. Vérifiez ensuite que le nom d'hôte dans votre panneau correspond exactement au nom dans l'enregistrement DNS, www inclus.
Quoi envoyer, et ce que les visiteurs devraient voir
Si c'est vous qui renvoyez le 503, deux choses le rendent bien moins coûteux.
Envoyez Retry-After. Soit un nombre de secondes, soit une date HTTP. Les robots le respectent, les clients bien écrits le respectent, et cela convertit un refus en planning.
Servez quelque chose d'humain. La page d'erreur par défaut du proxy n'apprend rien au visiteur et a l'air cassée. Une page personnalisée avec une phrase sur ce qui se passe est un tout petit effort pour une grande différence dans la façon dont un incident est vécu.
Et si le contenu est cacheable, un CDN peut continuer à servir la copie en cache pendant que l'origine refuse — ce qui fait la différence entre « le site était lent pendant dix minutes » et « le site était en panne pendant dix minutes ».
FAQ 503 Service Unavailable
Le 503 est-il meilleur ou pire que le 502 ?
Il est plus informatif. Un 503 est un refus délibéré, donc quelque chose sur le chemin fonctionne assez bien pour décider. Un 502 signifie qu'une conversation avec la machine derrière a échoué. En pratique, un 503 est plus souvent une question de capacité ou de configuration que vous contrôlez, et un 502 plus souvent une origine cassée.
Un 503 nuit-il à mon classement dans les moteurs de recherche ?
Pas s'il est réellement temporaire. Les moteurs de recherche traitent le 503 comme « revenez plus tard », ce qui explique pourquoi c'est le bon code pendant une maintenance. Un 503 qui dure des jours est une autre affaire : les pages finiront par être abandonnées. Ajoutez Retry-After pour que le robot sache à quoi s'attendre.
J'obtiens un 503 juste après avoir pointé le DNS vers le CDN. Que faire ?
Vérifiez la page d'erreur. Si elle dit qu'aucun service n'est configuré pour le domaine, le nom d'hôte n'est pas encore configuré sur la périphérie — l'origine n'est pas concernée. Ajoutez le nom d'hôte exact dans le panneau, en incluant ou excluant www pour correspondre à l'enregistrement DNS, et le 503 disparaît dès que la configuration atteint les périphéries.
Puis-je mettre un 503 en cache ?
Vous ne devriez pas, ou seulement pour quelques secondes. Un 503 en cache continue de refuser les visiteurs après la disparition de la cause. Servez les réponses d'erreur avec un TTL très court et purgez le chemin une fois la correction en place.
Comment arrêter les 503 sous charge sans un serveur plus gros ?
Réduisez ce qui atteint l'origine. Mettez en cache ce qui peut l'être avec un TTL qui survit à un pic de trafic, assurez-vous que la clé de cache n'est pas fragmentée par des paramètres de suivi, et gardez des limites de débit sur les endpoints qui attirent du trafic automatisé. Un serveur plus gros relève le plafond ; la mise en cache retire la plupart des requêtes qui poussaient contre lui.