Loading...

Bases · 7 min de lecture

Les codes de statut HTTP : à lire comme « qui a refusé, et où »

Toutes les références listent ce que signifient les codes. Presque aucune ne dit quelle machine les émet — et sur un site derrière un CDN, c'est la question qui raccourcit le débogage d'un après-midi à une minute. Voici la liste du point de vue du proxy.

Mis à jour

Les codes de statut HTTP : à lire comme « qui a refusé, et où »

Les classes, en bref

2xx — ça a fonctionné. 200 OK est la réponse normale. 204 No Content est une requête réussie sans rien à renvoyer, courant pour les API. 206 Partial Content est une requête de plage, c'est ainsi que fonctionnent la recherche dans une vidéo et les téléchargements reprenables.

3xx — allez voir ailleurs. 301 est permanent et transmet les signaux de classement ; 302 est temporaire et ne le fait pas. 304 Not Modified est le discret de la bande : le client a déjà une copie valide, donc le corps n'est pas envoyé du tout. Un site en bonne santé sert beaucoup de 304.

4xx — la requête a été refusée. 400 est malformée, 401 demande des identifiants, 403 est un refus délibéré, 404 est introuvable, 410 a disparu exprès, 429 est trop de requêtes.

5xx — le côté serveur a échoué. 500 est une erreur non gérée, 502 est une conversation rompue avec la machine derrière, 503 est un refus temporaire, 504 est un timeout en attendant la machine derrière.

Quel maillon a produit le code

Une requête derrière un CDN passe par au moins trois endroits capables d'y répondre : la périphérie, le serveur web de votre origine, et votre application. Chacun peut produire des codes que les autres ne peuvent pas.

Seule la périphérie peut produire : un hit de cache servi pendant que l'origine est en panne, un 502 ou 504 à propos de votre origine, un 403 issu d'une règle WAF ou d'un blocage géographique, et un 503 disant qu'aucun service n'est configuré pour le nom d'hôte.

Seul le serveur web de votre origine produit : un 403 issu des permissions de fichiers ou d'une règle de refus, un 404 pour un chemin qui n'existe pas sur le disque, un 413 pour un corps plus gros que ce qu'il accepte.

Seule votre application produit : 401 et 403 selon qui est connecté, 422 pour une validation, 500 issu d'une exception non gérée.

Donc la première question diagnostique n'est pas « que signifie 502 » mais « est-ce que cette requête a atteint mon origine, ne serait-ce qu'un peu ». Si elle n'apparaît pas dans le journal d'accès de l'origine, rien de ce que vous changerez sur l'origine ne l'affectera.

Lire les en-têtes pour trouver le maillon

La réponse vous dit qui l'a traitée, si vous regardez les en-têtes plutôt que la page.

curl -sI https://example.com/

Un en-tête de statut de cache — sur cdn.com.tr, X-Proxy-Cache-MT avec HIT ou MISS — signifie que la périphérie a traité la requête. Un HIT signifie que l'origine n'a pas du tout été consultée, ce qui est utile à savoir quand vous testez un changement et voyez encore l'ancien comportement.

Deux pièges se cachent ici. Le premier : curl -I envoie une requête HEAD, et certains serveurs et middlewares se comportent différemment pour HEAD que pour GET, donc un en-tête qui apparaît avec -I peut être absent sur un vrai GET, et vice versa. Quand cela compte, utilisez curl -sD - -o /dev/null avec un GET normal. Le second : une réponse d'erreur en cache continuera d'être servie après que vous ayez corrigé la cause. Si le code ne change pas après une correction, purgez le chemin avant de continuer à déboguer.

Les codes qui méritent d'être configurés exprès

301 contre 302. Utilisez 301 quand le déménagement est permanent — cela consolide le classement de l'ancienne URL dans la nouvelle. Un 302 garde l'ancienne URL comme canonique, ce que vous voulez pour une redirection de campagne temporaire, et pas ce que vous voulez après une restructuration du site. Les redirections se mettent en cache en périphérie, donc une mauvaise redirection survit au déploiement qui l'a introduite.

404 contre 410. Les deux disent « pas ici ». Un 410 dit « et ça ne reviendra pas », ce qui fait sortir l'URL de l'index plus vite. Pour des pages produit retirées, 410 est le code honnête.

503 avec Retry-After. Pendant une maintenance, c'est le duo qui garde les robots patients. Une page de maintenance servie avec un 200 leur dit que votre avis de maintenance est votre contenu.

429 pour les limites de débit. Plus honnête que 503 quand le refus concerne la vitesse à laquelle ce client demande. Toutes les stacks ne l'envoient pas par défaut — le rate limiting de nginx renvoie 503 sauf configuration contraire.

Les codes de statut sur lesquels vous allez vraiment passer du temps

En pratique, trois codes représentent l'essentiel du temps de débogage sur un site derrière un proxy, et chacun a son propre guide :

**502 Bad Gateway** — la périphérie n'a pas pu obtenir de réponse utilisable de votre origine. Quatre causes : connexion refusée, fermeture prématurée, échec de négociation TLS, réponse malformée.

**403 Forbidden** — quelque chose a refusé exprès. Cinq décideurs possibles : votre origine, une règle WAF, un blocage pays ou réseau, la protection hotlink, une liste d'IP. Un identifiant de référence sur la page d'erreur, c'est ce qui transforme le fait de deviner en fait de vérifier.

**503 Service Unavailable** — un refus temporaire : surcharge, maintenance, une limite de débit, ou une périphérie sans origine configurée pour ce nom d'hôte.

Le quatrième, 504, est le jumeau temporisé du 502 et il est couvert dans le guide du 502, parce que les distinguer est l'essentiel du travail.

FAQ codes de statut HTTP

Quels codes de statut affectent réellement le SEO ?

Ceux qui changent ce qui est indexé : 301 consolide une URL dans sa cible, 302 ne le fait pas, 404 et 410 retirent une URL, 410 étant plus rapide, et un 5xx qui dure finit par faire tomber la page. Un 200 servi sur une page d'erreur est le cas discrètement néfaste, car le texte de l'erreur se retrouve indexé comme contenu.

Pourquoi obtiens-je un code différent avec curl et avec mon navigateur ?

Les requêtes diffèrent. Votre navigateur envoie des cookies, un user agent différent et un en-tête Accept ; curl n'envoie généralement rien de tout cela. Sur un site avec un WAF ou un contournement par cookie de connexion, ces différences changent la décision. Comparez des éléments comparables avant de conclure quoi que ce soit.

Le 304 est-il une erreur ?

Non, c'est le meilleur résultat possible après un hit de cache : le client a déjà une copie valide et le serveur n'envoie aucun corps du tout. Beaucoup de 304 dans vos journaux signifie que les requêtes conditionnelles fonctionnent.

Que signifie un statut 000 ou vide dans ma supervision ?

Qu'il n'y avait aucune réponse HTTP à lire : le DNS ne s'est pas résolu, la connexion TCP a échoué, ou le TLS n'a pas négocié. C'est un problème de connectivité plutôt qu'un problème applicatif, et cela vaut la peine de le distinguer d'un 5xx dans votre système d'alerte, quel qu'il soit.