Codes de statut HTTP : la liste complète, expliquée et commentée

Par La rédaction de Mon-Adresse-IP.net·Publié le 21 août 2026·

Chaque page web que vous ouvrez commence par un nombre à trois chiffres que vous ne voyez jamais. Ce guide traduit et commente l'intégralité des codes HTTP : ce qu'ils signifient réellement, qui les a émis (serveur d'origine, proxy, CDN ou navigateur) et ce qu'il faut faire quand ils vous barrent la route.

L'essentiel

Comment lire un code en une seconde

Toute réponse HTTP commence par une ligne de statut contenant un entier à trois chiffres, défini aujourd'hui par la RFC 9110 publiée en juin 2022, et enregistré auprès de l'IANA. Le premier chiffre porte à lui seul l'essentiel de l'information : il classe la réponse dans l'une des cinq familles, et un client conforme doit savoir traiter un code inconnu comme le code « x00 » de sa famille. C'est pourquoi un navigateur confronté à un 499 fantaisiste le traitera comme un 400.

1xx : Information	Réponse provisoire, envoyée avant la vraie réponse. Le client doit pouvoir l'ignorer. Vous ne la verrez jamais dans un navigateur.
2xx : Succès	La requête a été reçue, comprise et acceptée. Ce n'est pas une garantie sur le contenu : seulement sur le déroulement de l'échange.
3xx : Redirection	Une action supplémentaire est nécessaire, presque toujours suivre l'en-tête Location. Les navigateurs limitent le nombre de sauts pour éviter les boucles.
4xx : Erreur du client	Le serveur estime que la requête est fautive : adresse erronée, droits manquants, format refusé, débit excessif.
5xx : Erreur du serveur	La requête paraît valide mais le serveur n'a pas pu la traiter. Réessayer plus tard a du sens, contrairement au 4xx.

Deux détails changent la lecture d'un code. D'abord, la phrase qui accompagne le nombre (« OK », « Not Found ») est purement décorative : aucun client ne s'en sert, et elle n'existe même plus en HTTP/2 et HTTP/3, où seul le pseudo-en-tête :status est transmis. Ensuite, le code renvoyé et le contenu affiché peuvent se contredire : une page qui affiche « erreur 404 » tout en répondant 200 est une soft 404, invisible à l'œil nu mais parfaitement visible pour un moteur de recherche.

Le second réflexe consiste à identifier l'émetteur. Un même 503 peut venir de l'application, du serveur web devant elle, d'un répartiteur de charge ou d'un CDN situé à des milliers de kilomètres du serveur d'origine. L'en-tête Server, la présence d'un identifiant de trace propre au CDN et l'apparence de la page d'erreur trahissent presque toujours le coupable. Notre outil mes en-têtes HTTP montre l'autre moitié de cet échange : ce que votre navigateur, lui, envoie à chaque requête.

Le tableau complet des codes HTTP

Le tableau ci-dessous couvre les codes normalisés par l'IETF, ceux hérités de WebDAV, et les codes propriétaires que l'on rencontre le plus souvent dans les journaux de serveurs. La colonne « Que faire » distingue systématiquement l'action côté visiteur et l'action côté administrateur. Utilisez la recherche pour un code précis, ou les filtres pour parcourir une famille entière.

Les codes qui ne sont pas dans la norme

Une partie des codes que l'on rencontre au quotidien n'existe dans aucune RFC. Nginx en a créé une série dans la plage 4xx pour ses propres besoins : le 444 ferme la connexion sans rien répondre, ce qui permet de jeter un robot sans lui offrir la moindre information, et le 499 signale simplement que le visiteur est parti avant la réponse. Ces valeurs ne circulent pas sur le réseau : elles ne servent qu'à remplir les journaux. Un pic de 499 sur un site n'indique donc pas une attaque, mais des pages trop lentes que les visiteurs abandonnent.

Cloudflare, de son côté, occupe la plage 520 à 527 pour décrire ses propres difficultés à joindre le serveur d'origine. La distinction est capitale pour le diagnostic : un 522 ou un 523 signifie que le CDN n'a jamais réussi à parler à votre serveur, alors qu'un 502 ou un 504 classique signifie qu'il lui a parlé sans obtenir de réponse exploitable. Le même service ajoute aussi des numéros d'erreur internes affichés dans le corps de la page (le 1015 pour une limitation de débit, le 1020 pour un refus décidé par une règle de filtrage) qui n'ont rien à voir avec le code HTTP transporté. Si l'un d'eux s'affiche systématiquement chez vous, notre guide mon IP est bloquée détaille la marche à suivre.

301 ou 302 : l'erreur qui coûte cher

Le choix entre redirection permanente et redirection temporaire paraît anodin. Il ne l'est pas, pour une raison technique : une réponse 301 est mise en cache par le navigateur, parfois durablement et sans que l'utilisateur puisse le deviner. Concrètement, si vous publiez par erreur une 301 de votre page d'accueil vers une adresse fautive, corriger le serveur ne suffira pas : les visiteurs qui ont déjà reçu la redirection continueront d'être renvoyés au mauvais endroit tant qu'ils n'auront pas vidé leur cache. Vous n'avez aucun moyen de le faire à leur place.

Deux précautions permettent d'éviter le piège. La première consiste à tester une nouvelle redirection en 302 pendant quelques jours, puis à la basculer en 301 une fois la cible confirmée. La seconde consiste à accompagner la 301 d'un en-tête Cache-Control avec une durée maîtrisée : la redirection reste permanente pour les moteurs, mais sa mémorisation par le navigateur est bornée.

Côté référencement, la distinction est tout aussi nette. Une 301 indique aux moteurs que l'ancienne adresse doit disparaître de l'index au profit de la nouvelle ; une 302 leur dit au contraire de conserver l'ancienne. Google indique traiter comme permanentes les redirections temporaires qui durent, mais le délai n'est ni documenté ni maîtrisable : mieux vaut envoyer le bon signal dès le départ.

Reste un piège plus discret. Historiquement, tous les navigateurs transforment un POST en GET lorsqu'ils suivent une 301 ou une 302, en contradiction avec le texte d'origine du protocole. Le corps de la requête est perdu au passage. Les codes 307 et 308 ont été créés précisément pour cela : ils garantissent que la méthode et le corps sont conservés. Le tableau ci-dessous résume le choix.

Déplacement définitif, page consultée en GET	301 : le cas le plus courant : changement de domaine, passage en HTTPS, refonte d'URL.
Déplacement définitif, URL recevant des POST	308 : conserve méthode et corps : indispensable pour une API ou un point d'envoi de formulaire.
Détour temporaire, méthode à préserver	307 : maintenance, bascule vers un serveur de secours, test A/B côté serveur.
Après une soumission de formulaire	303 : force un GET vers la page de confirmation et empêche le renvoi des données au rechargement.
Détour temporaire sans contrainte	302 : acceptable, mais 307 est plus explicite et plus sûr.

403 contre 404 : ce que le serveur dit vraiment

Trois codes servent à refuser l'accès, et ils ne disent pas la même chose. Le 401 signifie « je ne sais pas qui vous êtes » : la réponse doit contenir un en-tête WWW-Authenticate et une authentification valide règle le problème. Le 403 signifie « je sais qui vous êtes, ou cela m'est égal, et c'est non » : recommencer avec les mêmes identifiants ne changera rien. Le 404 signifie « je n'ai rien à cette adresse », sans préciser si la ressource a existé.

Sur un serveur que vous administrez, un 403 alors que le fichier existe vient presque toujours de l'une de ces cinq causes : des droits insuffisants sur le fichier ou l'un de ses dossiers parents, l'absence de page d'index dans un répertoire dont le listing est désactivé, une règle de refus dans un .htaccess, une protection anti-copie de liens directs, ou un pare-feu applicatif qui a jugé la requête suspecte. Les quatre premières se corrigent en quelques secondes ; la dernière demande de lire les journaux, car aucune trace n'en apparaît côté visiteur.

En tant que visiteur, un 403 sur un site public a d'autres explications : filtrage géographique, blocage d'une plage d'adresses d'hébergeur, réputation dégradée de votre IP. Les sorties de VPN et les nœuds de sortie Tor sont particulièrement concernés, ce que détaillent nos guides sur les VPN et sur le réseau Tor. Un test simple consiste à recharger la page depuis un autre réseau, par exemple le partage de connexion d'un téléphone : si le site s'ouvre, le refus visait votre adresse et non votre requête.

Reste une pratique déroutante : de nombreux services renvoient délibérément un 404 là où un 403 serait techniquement exact. La logique est défensive. Répondre « interdit » confirme que la ressource existe, ce qui constitue déjà une fuite d'information : on apprend qu'un dossier privé, un identifiant de compte ou un espace d'administration se trouve à cette adresse. Répondre « introuvable » ne révèle rien. C'est pour cette raison qu'un dépôt privé sur une plateforme de code apparaît généralement comme inexistant tant que vous n'y avez pas accès. Si vous administrez un site, appliquez le même principe aux zones sensibles ; en revanche, préférez un 410 explicite pour un contenu que vous avez volontairement supprimé, car il accélère la désindexation.

429 et 503 : quand c'est votre IP qui est en cause

Le 429 est le code de la limitation de débit. Un serveur compte les requêtes reçues sur une fenêtre de temps et refuse au-delà d'un seuil. La question décisive est : sur quoi porte ce compteur ? S'il est associé à un compte utilisateur ou à une clé d'API, la responsabilité est directe. Mais dans la majorité des cas, la clé de comptage est tout simplement l'adresse IP publique, et vous n'êtes pas forcément seul derrière la vôtre.

C'est là que la mécanique se retourne contre des utilisateurs parfaitement innocents. Chez la plupart des opérateurs mobiles français, et chez plusieurs fournisseurs d'accès fixe, une même adresse IPv4 publique est partagée entre de nombreux abonnés par le mécanisme de CGNAT. Le site que vous consultez voit alors le trafic cumulé de tout ce groupe. Si l'un d'eux se comporte mal, ou si vous êtes simplement nombreux à consulter le même service au même moment, le compteur explose et le 429 tombe sur tout le monde. Le même effet se produit derrière un VPN : des milliers d'abonnés sortent par une poignée d'adresses, que les services de sécurité identifient sans peine comme appartenant à un hébergeur.

Le 503 joue parfois le même rôle. Certaines protections anti-robots répondent 503 ou 403 avec une page de vérification intermédiaire plutôt qu'un franc 429 : du point de vue du visiteur, cela se traduit par des captchas à répétition ou une attente de quelques secondes à chaque page. Ce n'est pas une panne, c'est une mise à l'épreuve.

1. Cessez de recharger Chaque tentative alimente le compteur et prolonge la pénalité. Si l'en-tête Retry-After est présent, il donne le délai exact, en secondes ou sous forme de date.
2. Identifiez votre adresse de sortie Notre outil de recherche d'adresse IP vous indique l'opérateur et le numéro AS associés. Un nom d'hébergeur plutôt qu'un fournisseur d'accès grand public explique à lui seul la plupart des blocages.
3. Testez sans intermédiaire Désactivez temporairement VPN et proxy, ou passez par un autre réseau. Si le blocage disparaît, il visait l'adresse partagée et non vous.
4. Vérifiez si votre adresse est fixe Sans CGNAT, un redémarrage de la box suffit parfois à obtenir une nouvelle adresse dynamique. Derrière un CGNAT, cela ne change rien : l'adresse publique n'est pas la vôtre.
5. Contrôlez votre réputation Une adresse peut figurer sur une liste de blocage à la suite d'un appareil infecté sur votre réseau. La démarche complète est décrite dans mon IP est bloquée.

451 : le code créé pour la censure

Le code 451 est le seul de la liste dont le numéro a été choisi pour sa valeur symbolique. Normalisé par la RFC 7725 en février 2016, il signale qu'une ressource est inaccessible non pour une raison technique, mais parce qu'une autorité l'exige : décision de justice, injonction administrative, restriction réglementaire. Son numéro renvoie à Fahrenheit 451, le roman de Ray Bradbury publié en 1953, dont le titre désigne la température à laquelle le papier s'enflamme.

La RFC ne se contente pas d'attribuer un numéro. Elle recommande que la réponse identifie l'entité à l'origine du blocage, au moyen d'un en-tête Link portant la relation blocked-by, et qu'elle explique dans son corps qui est visé : l'auteur du site, le lecteur, ou les deux. L'objectif affiché est la transparence : rendre la censure mesurable par des outils automatisés plutôt que de la laisser se confondre avec une panne.

Dans la réalité, ce code reste peu employé. En France, les blocages ordonnés par la justice ou demandés par les autorités administratives sont le plus souvent mis en œuvre au niveau du DNS par les fournisseurs d'accès : le nom de domaine ne résout plus, ou renvoie vers une page d'information de l'opérateur. Le visiteur ne voit alors aucun code 451, mais une erreur de résolution que rien ne distingue d'une panne : d'où l'intérêt de comprendre ce que fait réellement un résolveur, sujet traité dans notre guide du DNS. L'usage le plus visible du 451 sur le web vient d'ailleurs : plusieurs sites d'information américains l'ont adopté pour refuser l'accès aux visiteurs européens plutôt que de se conformer au RGPD, un point que nous détaillons dans notre page sur l'adresse IP et le RGPD.

502, 503, 504 : proxy ou serveur ?

Ces trois codes se ressemblent à l'écran et désignent pourtant des pannes situées à des endroits différents. La clé est de comprendre qu'un site moderne empile plusieurs couches : le CDN reçoit la requête, la transmet à un serveur web, qui la transmet lui-même à un processus applicatif, qui interroge éventuellement une base de données. Chaque couche peut répondre à la place de la suivante.

Un 502 veut dire : « j'ai transmis votre requête, et ce que j'ai reçu en retour est inexploitable ». La couche suivante a coupé la connexion, planté, ou renvoyé des en-têtes malformés. Un 504 veut dire : « j'ai transmis votre requête, la connexion s'est bien établie, mais rien n'est revenu à temps ». Un 503 veut dire : « c'est moi qui refuse, je suis là mais indisponible », maintenance déclarée, file d'attente saturée, ou aucune destination valide dans un répartiteur de charge.

1. Regardez qui répond L'en-tête Server et l'allure de la page d'erreur trahissent l'émetteur. Une page aux couleurs d'un CDN signifie que la requête n'a jamais atteint votre serveur ; une page brute de Nginx ou d'Apache signifie l'inverse.
2. Chronométrez l'erreur Une erreur immédiate évoque une connexion refusée ou un processus mort, donc un 502. Une erreur au bout d'une minute environ évoque un dépassement de délai ; autour de cent secondes, le proxy du CDN est en cause.
3. Vérifiez la résolution du nom Un enregistrement pointant vers une ancienne adresse produit des symptômes trompeurs. Les types d'entrées concernés sont expliqués dans notre page sur les enregistrements DNS.
4. Interrogez l'origine directement En contournant le CDN, vous saurez immédiatement si le serveur applicatif répond. S'il répond correctement, le problème est dans la couche intermédiaire.
5. Mesurez le chemin réseau Une perte de paquets ou un routage anormal entre vous et le serveur se voit avec les commandes décrites dans notre guide ping et traceroute.

Voir les codes vous-même

Un code de statut ne s'affiche jamais spontanément : le navigateur montre la page, pas le nombre. Deux méthodes suffisent à le révéler.

La première est en ligne de commande. L'outil curl est installé d'origine sur macOS, sur les distributions Linux courantes et sur Windows 10 et 11, où il s'invoque sous le nom curl.exe pour ne pas être confondu avec l'alias PowerShell.

curl -I https://mon-adresse-ip.net/
# Envoie une requête HEAD et n'affiche que les en-têtes de réponse.

curl -sS -o /dev/null -D - https://mon-adresse-ip.net/
# Vraie requête GET : le corps est jeté, les en-têtes restent affichés.
# Utile car certains serveurs traitent HEAD différemment de GET.

curl -sIL -w "%{http_code} %{url_effective}\n" -o /dev/null https://exemple.fr/
# Suit toute la chaîne de redirections et affiche le code final.

curl -o /dev/null -s -w "%{http_code} en %{time_total}s\n" https://exemple.fr/
# Code de statut et durée totale : idéal pour repérer un 504 qui arrive
# systématiquement au bout de 60 secondes.

La seconde méthode se passe d'installation. Ouvrez les outils de développement du navigateur avec la touche F12, placez-vous dans l'onglet Réseau, puis rechargez la page : chaque ressource apparaît avec son code dans une colonne dédiée. Trois réflexes rendent la lecture fiable. Cochez « Désactiver le cache », faute de quoi vous verrez surtout des 304 et des mentions « from disk cache » qui affichent 200 sans que le serveur ait été sollicité. Activez la conservation du journal si vous analysez une redirection, sinon la première ligne disparaît au chargement de la seconde page. Enfin, souvenez-vous qu'une redirection produit toujours deux lignes : le 301 ou 302 d'abord, la réponse finale ensuite.

Pour compléter le tableau, notre outil mes en-têtes HTTP vous montre l'autre versant de l'échange : la liste exacte des en-têtes que votre navigateur transmet à chaque site, dont plusieurs contribuent à votre empreinte de navigateur. Et si un terme croisé dans ces en-têtes vous échappe, le glossaire du réseau le définit en une phrase.

Questions fréquentes