Aller au contenu
Outil gratuit

Codes de statut HTTP : liste et signification

Codes de statut HTTP dans une liste consultable : saisis 404, 403, 500, 502 ou « redirection » pour découvrir la signification du code, ses causes et comment résoudre le problème. 70 codes de 100 à 526, avec des exemples nginx et Apache à copier, les erreurs Cloudflare 520 à 526 et les codes nginx 444 et 499. Gratuit et sans inscription : la recherche s’effectue entièrement dans ton navigateur.

Créé par Dimitri Heissler

Tu gères ton propre projet ? Confie ton site à un hébergement web rapide.

Voir l’hébergement Web

La recherche porte sur le numéro, le nom, la description, les causes et les exemples de configuration, par exemple « timeout » ou « client_max_body_size ».

Recherches fréquentes :

70 codes de statut sur 70

Signification

Le serveur a reçu les en-têtes de la requête et n’y voit aucune objection. Le client peut envoyer le corps. Cela correspond à l’en-tête « Expect: 100-continue », qui permet au client de vérifier avant un transfert volumineux si le serveur l’acceptera.

Voir aussi :
Défini dans RFC 9110

Signification

Le serveur change de protocole à la demande du client, par exemple de HTTP à WebSocket. Le client a envoyé l’en-tête « Upgrade » à cet effet.

Voir aussi :
Défini dans RFC 9110

Signification

Le serveur traite encore la requête et ne l’a pas terminée. Ce code vient de WebDAV et évite un timeout lors des opérations longues. Il est considéré comme obsolète et n’apparaît presque plus.

Défini dans RFC 2518

Signification

Le serveur envoie des indications préliminaires, par exemple des en-têtes « Link » pour les feuilles de style ou les scripts, pendant qu’il prépare la réponse proprement dite. Le navigateur peut déjà charger ces fichiers. Il s’agit d’une indication, pas d’une erreur.

Défini dans RFC 8297

Signification

La requête a réussi. Avec GET, la réponse contient la ressource demandée ; avec POST, le résultat de l’action. C’est le cas normal pour toute page qui fonctionne.

Pour le référencement : Un code 200 indique seulement que le serveur répond, pas que le contenu est correct. Une page d’erreur renvoyée avec un code 200 est appelée « Soft 404 » et perturbe les moteurs de recherche.
Voir aussi :
Défini dans RFC 9110

Signification

La requête a réussi et créé une nouvelle ressource, généralement à la suite d’une requête POST vers une API. L’en-tête « Location » indique l’adresse de la nouvelle ressource.

Voir aussi :
Défini dans RFC 9110

Signification

Le serveur a accepté la requête, mais n’a pas encore terminé son traitement. Il fournira le résultat plus tard, par exemple via une consultation du statut ou un webhook. Cas fréquent pour les tâches en arrière-plan.

Voir aussi :
Défini dans RFC 9110

Signification

La requête a réussi, mais les données proviennent d’un proxy, et non directement du serveur d’origine. Ce proxy a pu les modifier. Cas rare.

Défini dans RFC 9110

Signification

La requête a réussi, mais la réponse ne contient volontairement aucun corps. C’est courant avec DELETE, PUT et les requêtes CORS preflight (OPTIONS). Pour lire la réponse comme du JSON, il faut gérer ce corps vide.

Voir aussi :
Défini dans RFC 9110

Signification

La requête a réussi. Le client doit réinitialiser la vue, par exemple vider un formulaire. La réponse ne contient aucun corps. Rarement utilisé.

Défini dans RFC 9110

Signification

Le serveur ne fournit que la partie demandée d’un fichier, car le client a envoyé un en-tête « Range ». Utilisé pour le streaming vidéo, les téléchargements interrompus et les fichiers volumineux.

Voir aussi :
Défini dans RFC 9110

Signification

La réponse contient plusieurs codes de statut pour plusieurs sous-opérations, au format XML. Issu de WebDAV, ce cas apparaît lors de la synchronisation de calendriers, de contacts et de fichiers.

Défini dans RFC 4918

Signification

Les membres d’une liaison WebDAV ont déjà été indiqués plus haut dans cette même réponse et ne sont pas affichés à nouveau. Cas très rare.

Défini dans RFC 5842

Signification

Le serveur a répondu à la requête avec un encodage delta : la réponse résulte d’une ou plusieurs modifications de l’instance de la ressource actuelle. Inutilisé en pratique.

Défini dans RFC 3229

Signification

Plusieurs réponses sont possibles pour la requête, par exemple le même fichier dans plusieurs formats ou langues. Le client ou l’utilisateur doit en choisir une. Rarement utilisé en pratique.

Voir aussi :
Défini dans RFC 9110

Signification

Redirection permanente : la ressource a une nouvelle adresse, indiquée dans l’en-tête « Location ». Les navigateurs et moteurs de recherche doivent désormais utiliser uniquement la nouvelle URL.

Causes typiques

  • Migration de domaine ou d’URL, par exemple de http vers https ou de www vers le domaine principal
  • Une page a été renommée ou déplacée
  • Une règle de redirection dans nginx, Apache ou le CMS s’applique

Comment tu peux résoudre le problème

  • Crée un lien direct vers l’URL cible pour éviter toute redirection.
  • Réduis les chaînes de redirection (A, B, C) à une seule étape.
  • En cas de boucle (ERR_TOO_MANY_REDIRECTS), vérifie que les règles http/https et www ne se contredisent pas : le serveur et le CMS sont souvent en conflit.
  • Les navigateurs conservent longtemps les redirections 301. Teste les modifications dans une fenêtre de navigation privée ou avec curl -I.

Configuration et commandes (exemples)

nginx
return 301 https://example.com$request_uri;
Apache
Redirect 301 /alte-seite https://example.com/neue-seite
Pour le référencement : Un code 301 transmet les signaux de classement de l’ancienne URL à la nouvelle. Utilise-le pour tout déplacement permanent et évite les chaînes de redirections.
Voir aussi :
Défini dans RFC 9110

Signification

Redirection temporaire : la ressource est provisoirement accessible à une autre adresse. Le client doit suivre l’en-tête « Location » pour cette requête, mais continuer à utiliser l’URL d’origine par la suite. Certains clients transforment alors un POST en GET.

Causes typiques

  • Redirection temporaire, par exemple pour une campagne ou une maintenance
  • Redirection vers une page de connexion
  • Redirection selon la langue ou le pays
  • Défini à tort alors que le déplacement est permanent

Comment tu peux résoudre le problème

  • Signale les déplacements permanents avec un code 301 ou 308, sinon les moteurs de recherche conservent l’ancienne URL.
  • Pour conserver la méthode, utilise 307 (temporaire) ou 308 (permanent).

Configuration et commandes (exemples)

nginx
return 302 https://example.com/sommer-angebot;
Apache
Redirect 302 /angebot https://example.com/sommer-angebot
Pour le référencement : Avec un code 302, l’ancienne URL reste dans l’index tant que la redirection est considérée comme temporaire. Si tu l’utilises pour un déplacement permanent, le classement se transfère lentement.
Voir aussi :
Défini dans RFC 9110

Signification

Redirection avec GET : le client doit récupérer le résultat à une autre URL via GET. Typique après un POST (Post/Redirect/Get), pour éviter qu’un rechargement de la page renvoie le formulaire.

Voir aussi :
Défini dans RFC 9110

Signification

La ressource n’a pas changé depuis la dernière requête. Le serveur n’envoie pas de corps de réponse et le navigateur utilise la copie en cache. Il a envoyé « If-None-Match » (ETag) ou « If-Modified-Since » à cet effet. Cela économise de la bande passante et accélère le chargement de la page.

Voir aussi :
Défini dans RFC 9110

Signification

Redirection temporaire comme 302, mais la méthode HTTP et le corps restent inchangés : un POST reste un POST.

Causes typiques

  • Chrome affiche « 307 Internal Redirect » dans les outils de développement pour les redirections HSTS de http vers https, sans que le serveur ait envoyé quoi que ce soit
  • Un serveur redirige temporairement une requête API et veut conserver la méthode

Comment tu peux résoudre le problème

  • Si la redirection est permanente, utilise 308 plutôt que 307.

Configuration et commandes (exemples)

nginx
return 307 https://example.com$request_uri;
Apache
Redirect 307 /alt https://example.com/neu
Voir aussi :
Défini dans RFC 9110

Signification

Redirection permanente comme la 301, mais la méthode HTTP et le corps restent inchangés : un POST reste un POST. Adaptée aux migrations définitives d’API et aux formulaires dont les données ne doivent pas être perdues.

Configuration et commandes (exemples)

nginx
return 308 https://example.com$request_uri;
Apache
Redirect 308 /alt https://example.com/neu
Pour le référencement : Pour les moteurs de recherche, 308 se comporte comme 301 et transfère le classement vers la nouvelle adresse.
Voir aussi :
Défini dans RFC 9110

Signification

Le serveur ne comprend pas la requête, car elle est mal formée : syntaxe invalide, en-têtes incorrects ou cookie trop volumineux. Pour le serveur, l’erreur vient du client.

Causes typiques

  • Caractères invalides ou URL mal encodée, par exemple un espace ou un % non suivi de deux chiffres hexadécimaux
  • Cookies trop volumineux ou corrompus ; avec nginx, l’erreur « Request Header Or Cookie Too Large »
  • Corps JSON invalide ou champs obligatoires manquants dans une API
  • En-têtes Host ou Content-Length incorrects, souvent à cause d’un proxy

Comment tu peux résoudre le problème

  • Supprime les cookies du domaine dans ton navigateur et recharge la page.
  • Vérifie l’URL et encode les caractères spéciaux, par exemple avec l’URL Encoder.
  • Compare le corps de la requête à la documentation de l’API.
  • Si les en-têtes sont trop volumineux : augmente la taille des tampons du serveur.

Configuration et commandes (exemples)

nginx
large_client_header_buffers 4 16k;
Voir aussi :
Défini dans RFC 9110

Signification

La requête nécessite une authentification valide. Le client ne s’est pas connecté ou ses identifiants sont invalides. Le serveur envoie l’en-tête « WWW-Authenticate », qui indique la méthode attendue. Le nom prête à confusion : il signifie « non authentifié », et non « non autorisé » (ce qui correspond à 403).

Causes typiques

  • Token, mot de passe ou clé API absent ou expiré
  • En-tête Authorization incorrect, par exemple « Bearer » manquant avant le token
  • Protection HTTP Basic (.htpasswd) de la page ou du répertoire

Comment tu peux résoudre le problème

  • Vérifie les identifiants et la date d’expiration du token.
  • Vérifie le format de l’en-tête Authorization.
  • Pour Basic Auth : vérifie l’utilisateur dans le fichier .htpasswd et le chemin de ce fichier dans la configuration.

Configuration et commandes (exemples)

nginx
auth_basic "Geschützter Bereich";
auth_basic_user_file /etc/nginx/.htpasswd;
Apache
AuthType Basic
AuthName "Geschützter Bereich"
AuthUserFile /etc/apache2/.htpasswd
Require valid-user
Voir aussi :
Défini dans RFC 9110

Signification

Réservé aux futurs systèmes de paiement et jamais normalisé. Certains services l’utilisent néanmoins, par exemple lorsqu’un abonnement a expiré ou qu’un quota d’API doit être payé.

Comment tu peux résoudre le problème

  • Vérifie le statut de la facture ou de l’abonnement auprès du fournisseur.
  • Consulte la documentation de l’API du service : elle en définit la signification.
Voir aussi :
Défini dans RFC 9110

Signification

Le serveur comprend la requête, mais la refuse. Contrairement à une erreur 401, se reconnecter ne suffit généralement pas : l’accès n’est pas autorisé pour cette identité ou cette adresse.

Causes typiques

  • Les permissions ou le propriétaire du fichier sont incorrects : l’utilisateur du serveur Web ne peut pas lire le fichier
  • Aucun document d’index n’est présent dans le répertoire et l’affichage de son contenu est désactivé
  • Blocage d’IP, règle de pare-feu ou de WAF, ou géoblocage
  • Une règle dans .htaccess ou dans la configuration nginx interdit l’accès (deny all, Require all denied)
  • Un module de sécurité comme ModSecurity ou Fail2ban bloque la requête

Comment tu peux résoudre le problème

  • Vérifie les permissions : généralement 755 pour les répertoires et 644 pour les fichiers, avec un propriétaire correspondant à l’utilisateur du serveur web. Le calculateur CHMOD convertit les valeurs.
  • Crée un fichier d’index (index.html, index.php) ou définis la directive index.
  • Consulte le journal d’erreurs du serveur web : il indique la cause exacte, par exemple « directory index of … is forbidden ».
  • Vérifie les blocages d’IP et les règles WAF.

Configuration et commandes (exemples)

Shell
namei -l /var/www/html/index.html
nginx
index index.html index.php;
Apache
<Directory /var/www/html>
    Require all granted
</Directory>
Voir aussi :
Défini dans RFC 9110

Signification

Le serveur est accessible, mais ne connaît pas l’adresse demandée. La ressource est introuvable. Le serveur ne précise pas si elle n’a jamais existé ou si elle est simplement absente pour le moment.

Causes typiques

  • Faute de frappe ou lien obsolète
  • Page supprimée, déplacée ou renommée sans redirection
  • Chemin des documents incorrect sur le serveur web (root ou alias) ou casse incorrecte, car Linux distingue les majuscules des minuscules
  • Règles de réécriture manquantes, par exemple pour les permaliens WordPress ou une application monopage
  • Le fichier n’a pas été téléversé lors du déploiement

Comment tu peux résoudre le problème

  • Vérifie le chemin et le nom du fichier, y compris la casse.
  • Configure try_files dans nginx pour que les permaliens et les applications monopages fonctionnent : try_files $uri $uri/ /index.php?$args; ou /index.html.
  • Redirige les pages déplacées vers leur nouvelle adresse avec une redirection 301.
  • Crée une page 404 personnalisée avec une recherche et des liens.

Configuration et commandes (exemples)

nginx
error_page 404 /404.html;
Apache
ErrorDocument 404 /404.html
Pour le référencement : Quelques pages 404 isolées ne nuisent pas au classement. Pour les pages avec des backlinks ou du trafic, configure une redirection 301. Évite les pages d’erreur renvoyées avec un code 200 (« Soft 404 »).
Voir aussi :
Défini dans RFC 9110

Signification

La ressource existe, mais pas pour cette méthode HTTP (GET, POST, PUT, DELETE, etc.). La réponse doit contenir un en-tête « Allow » indiquant les méthodes autorisées.

Causes typiques

  • Requête POST vers une route qui n’accepte que GET, ou inversement
  • nginx répond 405 à une requête POST sur un fichier statique
  • Une redirection 301 ou 302 a transformé la requête POST en requête GET
  • Le serveur web ou le WAF bloque les méthodes comme PUT et DELETE

Comment tu peux résoudre le problème

  • Consulte l’en-tête « Allow » : il indique les méthodes autorisées.
  • Vérifie la route et le contrôleur dans l’application.
  • Utilise 307 ou 308 plutôt que 301 ou 302 si la méthode doit être conservée lors de la redirection.
  • Utilise directement l’adresse https définitive pour éviter qu’une redirection ne modifie la méthode.
Voir aussi :
Défini dans RFC 9110

Signification

Le serveur ne peut pas fournir de réponse dans un format autorisé par les en-têtes « Accept » du client, qu’il s’agisse du type de média, de la langue ou du jeu de caractères. Certaines Web Application Firewalls (ModSecurity) bloquent également les requêtes avec ce code.

Causes typiques

  • L’en-tête Accept demande uniquement application/xml, par exemple, alors que le serveur ne fournit que du JSON
  • Une règle ModSecurity a jugé la requête suspecte, souvent dans le cas de scripts sans User-Agent

Comment tu peux résoudre le problème

  • Modifie l’en-tête Accept ou omets-le.
  • Pour ModSecurity, consulte le journal d’audit et vérifie la règle déclenchée.
Voir aussi :
Défini dans RFC 9110

Signification

Comme 401, mais c’est un serveur proxy, et non le serveur cible, qui exige une authentification. Le proxy envoie alors l’en-tête « Proxy-Authenticate ».

Causes typiques

  • Un proxy d’entreprise ou d’établissement scolaire exige une connexion
  • Identifiants du proxy incorrects dans les paramètres système ou dans curl

Comment tu peux résoudre le problème

  • Saisis les identifiants du proxy, par exemple avec curl en utilisant -x benutzer:passwort@proxy:port.
  • Demande les bons identifiants au service informatique ou au fournisseur du proxy.
Voir aussi :
Défini dans RFC 9110

Signification

Le serveur a attendu trop longtemps la requête complète du client et a fermé la connexion.

Causes typiques

  • Connexion du client lente ou instable
  • Une importation volumineuse s’interrompt
  • Un proxy ou un équilibreur de charge ferme les connexions trop tôt
  • Le navigateur a ouvert une connexion à l’avance, mais ne l’a jamais utilisée

Comment tu peux résoudre le problème

  • Vérifie la connexion et réessaie la requête.
  • Augmente les délais d’expiration sur le serveur.
  • Pour les envois : réduis la taille des fichiers ou envoie-les en plusieurs parties.

Configuration et commandes (exemples)

nginx
client_header_timeout 60s;
client_body_timeout 60s;
Apache
RequestReadTimeout header=20-40,MinRate=500 body=20,MinRate=500
Voir aussi :
Défini dans RFC 9110

Signification

La requête entre en conflit avec l’état actuel de la ressource, par exemple en cas de modifications simultanées ou si une entrée existe déjà. Le client peut résoudre le conflit et réessayer.

Causes typiques

  • Une valeur unique existe déjà, par exemple une adresse e-mail, un nom d’utilisateur ou un nom de domaine
  • Deux utilisateurs modifient la même ressource ; la version ne correspond plus
  • La ressource ne peut être ni modifiée ni supprimée dans son état actuel

Comment tu peux résoudre le problème

  • Recharge l’état actuel et applique de nouveau ta modification.
  • Consulte le corps de la réponse : les bonnes API y précisent la nature du conflit.
Voir aussi :
Défini dans RFC 9110

Signification

La ressource a existé, mais a été supprimée volontairement et ne reviendra pas. Contrairement à 404, le serveur indique ainsi qu’elle a disparu définitivement.

Causes typiques

  • Le contenu a été supprimé volontairement, par exemple une offre expirée
  • Une règle serveur renvoie le code 410 pour les anciennes URL

Comment tu peux résoudre le problème

  • S’il existe un successeur, effectue une redirection 301.
  • Pour les URL supprimées définitivement, renvoie volontairement un code 410.

Configuration et commandes (exemples)

nginx
location = /alte-seite {
    return 410;
}
Apache
Redirect gone /alte-seite
Pour le référencement : Avec le code 410, tu indiques clairement aux moteurs de recherche que la page a été supprimée volontairement. Google traite toutefois les codes 404 et 410 de façon similaire ; la différence est minime.
Voir aussi :
Défini dans RFC 9110

Signification

Le serveur exige l’en-tête « Content-Length », absent de la requête. Il n’accepte le corps que si sa longueur est connue.

Causes typiques

  • Un client envoie le corps de la requête par fragments (chunked) à un serveur qui ne l’accepte pas
  • Un script ou un proxy omet l’en-tête

Comment tu peux résoudre le problème

  • Définis Content-Length ou utilise un client HTTP qui envoie automatiquement cet en-tête.
  • Vérifie les paramètres de mise en tampon des requêtes du proxy.
Voir aussi :
Défini dans RFC 9110

Signification

Une condition dans l’en-tête de la requête (If-Match, If-Unmodified-Since, etc.) n’est pas remplie. Le serveur n’effectue donc pas la modification, ce qui évite d’écraser d’autres changements.

Causes typiques

  • La ressource a changé depuis que le client a chargé l’ETag
  • ETag obsolète dans If-Match

Comment tu peux résoudre le problème

  • Recharge la ressource, récupère le nouvel ETag et renvoie la modification.
Voir aussi :
Défini dans RFC 9110

Signification

Le corps de la requête dépasse la taille acceptée par le serveur. Cela arrive souvent lors de l’envoi de fichiers. Ce code s’appelait auparavant « Payload Too Large », et avant cela « Request Entity Too Large ».

Causes typiques

  • nginx : client_max_body_size est limité à 1 MB par défaut
  • Apache : LimitRequestBody est défini
  • PHP : upload_max_filesize ou post_max_size est trop faible
  • Un CDN ou un proxy en amont limite la taille

Comment tu peux résoudre le problème

  • Augmente la limite dans la configuration et recharge le serveur (nginx -s reload).
  • Augmente upload_max_filesize et post_max_size dans php.ini. post_max_size doit être au moins égal à upload_max_filesize.
  • Vérifie chaque maillon de la chaîne : CDN, proxy, serveur web et PHP. La limite la plus basse s’applique.

Configuration et commandes (exemples)

nginx
client_max_body_size 50M;
Apache
LimitRequestBody 52428800
Voir aussi :
Défini dans RFC 9110

Signification

L’URL est trop longue pour être traitée par le serveur. Il s’agit généralement d’une erreur dans l’application, et non d’une adresse réelle.

Causes typiques

  • Trop de paramètres dans une requête GET
  • Une boucle de redirection ajoute de nouveaux paramètres à chaque passage
  • Les grandes quantités de données sont transmises par URL plutôt que par POST

Comment tu peux résoudre le problème

  • Envoie les données volumineuses par POST.
  • Élimine la boucle de redirection.
  • Augmente la limite du serveur si nécessaire.

Configuration et commandes (exemples)

nginx
large_client_header_buffers 4 16k;
Apache
LimitRequestLine 16384
Voir aussi :
Défini dans RFC 9110

Signification

Le serveur ne reconnaît pas le format du corps envoyé (en-tête « Content-Type »). Par exemple, il ne traite que le JSON, mais reçoit des données de formulaire.

Causes typiques

  • L’en-tête Content-Type est absent ou incorrect, par exemple application/json au lieu de text/plain
  • Le serveur attend multipart/form-data pour les transferts de fichiers

Comment tu peux résoudre le problème

  • Définis le Content-Type adapté au corps de la requête.
  • Consulte la documentation de l’API.
Voir aussi :
Défini dans RFC 9110

Signification

La plage demandée (en-tête « Range ») dépasse les limites du fichier. Le serveur indique la taille réelle dans « Content-Range ».

Causes typiques

  • Un téléchargement reprend à partir d’un offset, mais le fichier a rétréci ou a été remplacé
  • Un gestionnaire de téléchargement défectueux

Comment tu peux résoudre le problème

  • Supprime le téléchargement partiel et recommence.
Voir aussi :
Défini dans RFC 9110

Signification

Le serveur ne peut pas satisfaire l’attente indiquée dans l’en-tête « Expect ». Il s’agit généralement de « 100-continue », non pris en charge par un proxy ou un serveur.

Causes typiques

  • Un ancien proxy ou serveur ne prenant pas en charge Expect
  • curl envoie automatiquement Expect: 100-continue pour les requêtes POST volumineuses

Comment tu peux résoudre le problème

  • Désactive l’en-tête dans curl avec -H 'Expect:'.
  • Mets à jour le proxy.

Configuration et commandes (exemples)

Shell
curl -H 'Expect:' -d @datei.json https://example.com/api
Voir aussi :
Défini dans RFC 9110

Signification

Un poisson d’avril issu de la RFC 2324 (Hyper Text Coffee Pot Control Protocol) : une théière refuse de préparer du café. Ce code est réservé et sert, en pratique, de plaisanterie ou à bloquer les bots.

Défini dans RFC 2324

Signification

La requête a été envoyée à un serveur incapable de répondre pour cette combinaison de schéma et d’hôte. Cela se produit avec HTTP/2 lorsqu’un navigateur réutilise une connexion pour plusieurs noms d’hôte.

Causes typiques

  • Plusieurs domaines sur une même adresse IP avec un certificat commun, mais une configuration différente pour chaque hôte
  • SNI et en-tête Host ne correspondent pas

Comment tu peux résoudre le problème

  • Harmonise les certificats et les hôtes virtuels des domaines concernés.
  • Utilise curl --resolve pour vérifier quel hôte répond.
Voir aussi :
Défini dans RFC 9110

Signification

Le serveur comprend la requête et son format est correct, mais son contenu est invalide, par exemple parce qu’un champ obligatoire manque ou qu’une valeur est hors de la plage autorisée. Ce code s’appelait auparavant « Unprocessable Entity ». De nombreux frameworks l’utilisent pour les erreurs de validation.

Causes typiques

  • La validation échoue, par exemple à cause du format de l’adresse e-mail, de la longueur ou d’un champ obligatoire
  • Une erreur logique, par exemple une date de fin antérieure à la date de début

Comment tu peux résoudre le problème

  • Consulte le corps de la réponse : il contient les champs et les messages d’erreur.
  • Compare tes saisies à la documentation de l’API.
Voir aussi :
Défini dans RFC 9110

Signification

La ressource est verrouillée, par exemple parce qu’elle a été extraite pour modification dans WebDAV.

Comment tu peux résoudre le problème

  • Lève le verrou (UNLOCK) ou attends que l’autre utilisateur ait terminé.
Voir aussi :
Défini dans RFC 4918

Signification

La requête a échoué parce qu’une autre requête dont elle dépend a échoué. Ce code provient de WebDAV et est aussi utilisé par des outils d’orchestration.

Voir aussi :
Défini dans RFC 4918

Signification

Le serveur refuse de traiter une requête qui pourrait être rejouée (attaque par rejeu). Cela se produit avec TLS 1.3 Early Data (0-RTT).

Défini dans RFC 8470

Signification

Le serveur exige un autre protocole, indiqué dans l’en-tête « Upgrade ». Par exemple, une requête utilise HTTP/1.1 alors que le serveur exige TLS ou HTTP/2.

Causes typiques

  • Version de TLS obsolète
  • L’API n’est accessible que via WebSocket ou HTTPS

Comment tu peux résoudre le problème

  • Mets à jour le client et la bibliothèque.
  • Envoie la requête avec le protocole requis.
Voir aussi :
Défini dans RFC 9110

Signification

Le serveur exige une condition (If-Match) pour éviter d’écraser par erreur une ancienne version.

Causes typiques

  • Une requête PUT sans If-Match sur une ressource protégée

Comment tu peux résoudre le problème

  • Récupère l’ETag de la ressource et place-le dans l’en-tête If-Match.
Voir aussi :
Défini dans RFC 6585

Signification

Le client a envoyé trop de requêtes dans un délai donné (limitation du débit). L’en-tête « Retry-After » indique quand il peut réessayer.

Causes typiques

  • Limite d’API ou de connexion dépassée, par exemple à cause d’une boucle dans le script
  • Un bot, un crawler ou un scraper génère une forte charge
  • Une protection contre les attaques par force brute (Fail2ban, WAF) intervient
  • Plusieurs utilisateurs partagent une adresse IP (NAT, VPN) et sont comptés ensemble

Comment tu peux résoudre le problème

  • Attends la durée indiquée par Retry-After, puis réessaie en augmentant progressivement l’intervalle (backoff exponentiel).
  • Regroupe les requêtes et mets les réponses en cache.
  • En tant qu’exploitant : définis des limites par IP ou clé API et réponds avec 429 ; nginx utilise 503 par défaut.
  • Autorise les robots d’exploration légitimes.

Configuration et commandes (exemples)

nginx
limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;

server {
    location /api/ {
        limit_req zone=api burst=20 nodelay;
        limit_req_status 429;
    }
}
Pour le référencement : Googlebot traite une erreur 429 comme une erreur de serveur et ralentit l’exploration. Définis les limites de façon à ne pas bloquer durablement les moteurs de recherche.
Voir aussi :
Défini dans RFC 6585

Signification

Les en-têtes de la requête sont trop volumineux, individuellement ou dans leur ensemble. La cause la plus fréquente est un nombre excessif de cookies ou des cookies trop volumineux.

Causes typiques

  • Cookies accumulés (suivi, sessions) sur un domaine
  • Un en-tête Authorization très long, par exemple un gros JWT
  • Une boucle de redirection ajoute toujours de nouveaux cookies

Comment tu peux résoudre le problème

  • Supprime les cookies du domaine.
  • Augmente la taille des tampons d’en-tête du serveur.
  • Garde les JWT et les en-têtes légers.

Configuration et commandes (exemples)

nginx
large_client_header_buffers 4 16k;
Apache
LimitRequestFieldSize 16384
Voir aussi :
Défini dans RFC 6585

Signification

Un code propre à nginx qui n’est jamais envoyé au client : nginx ferme la connexion sans réponse. Il apparaît uniquement dans le journal d’accès. Les administrateurs utilisent return 444; pour bloquer les bots et les requêtes adressées à un hôte invalide.

Causes typiques

  • return 444; dans la configuration nginx, par exemple dans le serveur par défaut

Comment tu peux résoudre le problème

  • Si c’est voulu, tu n’as rien à faire.
  • Si ce n’est pas voulu, vérifie la règle avec nginx -T et recherche return 444.

Configuration et commandes (exemples)

nginx
server {
    listen 80 default_server;
    return 444;
}
Voir aussi :
Défini dans nginx

Signification

L’accès à la ressource est bloqué pour des raisons juridiques, par exemple à la suite d’une décision de justice, d’une censure ou d’un géoblocage. Le code fait référence au roman « Fahrenheit 451 » de Ray Bradbury.

Causes typiques

  • Blocage sur ordre, par exemple pour des raisons de droit d’auteur ou à la demande d’une autorité
  • Le fournisseur bloque certaines régions en raison d’obligations légales

Comment tu peux résoudre le problème

  • L’exploitant indique généralement la raison dans le corps de la réponse.
  • Contacte l’exploitant : contourner le blocage peut être illégal.
Voir aussi :
Défini dans RFC 7725

Signification

Le client a fermé la connexion avant que nginx puisse envoyer la réponse. Ce code n’apparaît que dans le journal nginx ; ce n’est pas un véritable code HTTP.

Causes typiques

  • Un utilisateur interrompt le chargement de la page ou ferme l’onglet
  • Le délai d’expiration du client est plus court que le temps de réponse du serveur
  • Un équilibreur de charge ou un proxy en amont interrompt la connexion trop tôt

Comment tu peux résoudre le problème

  • Réduis le temps de réponse de l’application, notamment pour les requêtes lentes à la base de données.
  • Harmonise les délais d’expiration du client, du proxy et du serveur.
Voir aussi :
Défini dans nginx

Signification

Une erreur générale du serveur : le serveur a rencontré un problème inattendu et n’a pas pu traiter la requête. Le code n’indique pas ce qui s’est passé ; la cause figure dans le journal d’erreurs.

Causes typiques

  • Erreur dans le code de l’application, par exemple une erreur fatale PHP ou une exception non interceptée
  • Fichier .htaccess incorrect ou configuration du serveur Web incorrecte
  • Permissions de fichier ou propriétaire des scripts incorrects
  • La base de données est inaccessible ou les identifiants sont incorrects
  • La limite de mémoire PHP (memory_limit) ou max_execution_time a été atteinte
  • Il manque une extension PHP ou la version de PHP est incompatible avec le plugin

Comment tu peux résoudre le problème

  • Consulte le journal d’erreurs : il indique le fichier et la ligne de l’erreur.
  • Annule les modifications des dernières minutes (plugin, mise à jour, .htaccess).
  • Teste la configuration avec nginx -t ou apachectl configtest.
  • Active le mode débogage (WP_DEBUG, APP_DEBUG) uniquement en local ou brièvement, jamais en permanence sur un système de production.

Configuration et commandes (exemples)

nginx
tail -n 50 /var/log/nginx/error.log
Apache
tail -n 50 /var/log/apache2/error.log
Pour le référencement : Googlebot passe moins souvent en cas d’erreurs 5xx persistantes. Si une erreur dure plusieurs jours, des URL peuvent disparaître de l’index.
Voir aussi :
Défini dans RFC 9110

Signification

Le serveur ne reconnaît pas la méthode demandée ou ne peut pas l’exécuter. Contrairement au code 405, le problème ne concerne pas cette seule ressource, mais l’absence de prise en charge générale.

Causes typiques

  • Une méthode HTTP inhabituelle ou mal orthographiée
  • Le serveur ou le proxy ne prend pas en charge cette fonction, par exemple si le logiciel est ancien

Comment tu peux résoudre le problème

  • Vérifie la méthode utilisée.
  • Mets à jour le logiciel serveur.
Voir aussi :
Défini dans RFC 9110

Signification

Un serveur agissant comme passerelle ou proxy (nginx, Apache, équilibreur de charge, CDN) a reçu une réponse invalide du serveur en amont, ou aucune réponse. L’erreur se situe entre les serveurs, pas chez le visiteur.

Causes typiques

  • Le service backend (PHP-FPM, Node.js, Gunicorn, conteneur Docker) ne fonctionne pas ou a planté
  • Upstream incorrect : le port ou le socket dans proxy_pass ou fastcgi_pass est erroné
  • Le backend ferme la connexion prématurément, par exemple à cause d’un problème de mémoire ou d’un plantage
  • Un pare-feu ou SELinux bloque la connexion au backend
  • Un CDN ne parvient pas à joindre correctement le serveur d’origine

Comment tu peux résoudre le problème

  • Vérifie l’état du service backend et redémarre-le (systemctl status, docker ps).
  • Vérifie si un service écoute à l’adresse upstream (ss -tlnp).
  • Consulte le journal d’erreurs du serveur web : « connect() failed (111: Connection refused) while connecting to upstream » indique la cible.
  • Vérifie le chemin du socket et les permissions de PHP-FPM.
  • La mémoire vive est-elle suffisante ? L’OOM Killer met souvent fin au processus backend en premier.

Configuration et commandes (exemples)

Shell
ss -tlnp | grep :3000
nginx
tail -n 50 /var/log/nginx/error.log
Shell
dmesg | grep -i "out of memory"
Pour le référencement : Une brève erreur 502 perturbe peu les moteurs de recherche. Si elle persiste, Googlebot traite la page comme pour toute autre erreur 5xx et réduit sa fréquence d’exploration.
Voir aussi :
Défini dans RFC 9110

Signification

Le serveur ne peut temporairement pas traiter la requête, généralement en raison d’une surcharge ou d’une maintenance. Il peut utiliser « Retry-After » pour indiquer quand réessayer.

Causes typiques

  • Mode maintenance, par exemple de WordPress ou Laravel, ou maintenance planifiée
  • Surcharge : trop de requêtes ou de processus simultanés ; par exemple, pm.max_children est atteint dans PHP-FPM
  • Un service backend derrière un proxy ou un Load Balancer est inaccessible
  • nginx répond par défaut 503 en cas de dépassement de limit_req ou limit_conn
  • Les limites de ressources de l’hébergement (CPU, RAM, processus) sont atteintes

Comment tu peux résoudre le problème

  • Désactive le mode maintenance. Vérifie la présence d’un fichier .maintenance (WordPress) ou l’utilisation de php artisan down (Laravel).
  • Vérifie l’utilisation des ressources (top, free -m) et augmente les limites des processus, comme pm.max_children.
  • Lors d’une maintenance planifiée, renvoie volontairement une réponse 503 avec Retry-After.
  • Consulte le journal du serveur web pour repérer les erreurs upstream.

Configuration et commandes (exemples)

nginx
error_page 503 /wartung.html;

location / {
    return 503;
}

location = /wartung.html {
    root /var/www/wartung;
    internal;
    add_header Retry-After 3600 always;
}
Apache
ErrorDocument 503 /wartung.html
Header always set Retry-After "3600"

RewriteEngine On
RewriteCond %{REQUEST_URI} !=/wartung.html
RewriteRule ^ - [R=503,L]
Pour le référencement : Une brève erreur 503 accompagnée de Retry-After est la bonne solution pour signaler une maintenance aux moteurs de recherche. Si elle dure plusieurs jours, les URL risquent d’être retirées de l’index.
Voir aussi :
Défini dans RFC 9110

Signification

La passerelle ou le proxy n’a pas reçu à temps de réponse du serveur situé derrière. Contrairement à une erreur 502, la réponse n’est pas invalide : elle est trop lente.

Causes typiques

  • Une application lente : requête de base de données lourde, rapport, importation ou appel à une API externe
  • Le backend est surchargé, tous les workers PHP-FPM sont occupés
  • Les délais d’expiration du proxy sont inférieurs à la durée de la requête
  • Un problème réseau entre le proxy et le backend

Comment tu peux résoudre le problème

  • Repère les requêtes et scripts lents et accélère-les (Slow Query Log, profiler).
  • Exécute les tâches longues en arrière-plan.
  • Augmente les délais d’expiration de façon cohérente : proxy_read_timeout, fastcgi_read_timeout et max_execution_time dans PHP.
  • Vérifie la capacité du backend (workers, mémoire vive).

Configuration et commandes (exemples)

nginx
proxy_read_timeout 120s;
fastcgi_read_timeout 120s;
Apache
ProxyTimeout 120
Voir aussi :
Défini dans RFC 9110

Signification

Le serveur ne prend pas en charge la version HTTP utilisée dans la requête.

Causes typiques

  • Un client ou un proxy très ancien ou défectueux utilise une version HTTP inhabituelle
  • Le système cible ne prend en charge qu’une version précise

Comment tu peux résoudre le problème

  • Mets à jour le client ou force HTTP/1.1, avec --http1.1 pour curl.
Voir aussi :
Défini dans RFC 9110

Signification

La configuration du serveur pour la négociation de contenu est incorrecte : la variante choisie renvoie elle-même vers une négociation. Ce cas ne se présente pratiquement qu’en cas de mauvaise configuration.

Voir aussi :
Défini dans RFC 2295

Signification

Le serveur n’a pas assez d’espace de stockage pour terminer la requête.

Causes typiques

  • Le disque dur, le quota ou les inodes sont saturés
  • Le téléversement ne peut plus être enregistré

Comment tu peux résoudre le problème

  • Vérifie l’espace disque avec df -h et df -i, puis supprime les anciens journaux, Backups et caches.
  • Augmente le quota.

Configuration et commandes (exemples)

Shell
df -h && df -i
Voir aussi :
Défini dans RFC 4918

Signification

Le serveur a détecté une boucle infinie pendant le traitement.

Causes typiques

  • Une liaison WebDAV circulaire
  • Une arborescence de répertoires contenant une boucle de liens symboliques

Comment tu peux résoudre le problème

  • Vérifie les montages et les liens symboliques.
Voir aussi :
Défini dans RFC 5842

Signification

La requête ne contient pas l’extension exigée par le serveur selon la RFC 2774. Ce code est historique et pratiquement jamais rencontré.

Défini dans RFC 2774

Signification

Le client doit se connecter au réseau avant d’obtenir l’accès. Ce message est envoyé par un portail captif, par exemple sur le Wi-Fi d’un hôtel, d’un aéroport ou d’un café.

Causes typiques

  • Un portail captif sur le Wi-Fi exige une connexion ou une acceptation

Comment tu peux résoudre le problème

  • Ouvre n’importe quelle page en http, par exemple http://neverssl.com, pour afficher le portail.
  • Connecte-toi au portail.
Voir aussi :
Défini dans RFC 6585

Signification

Cloudflare a reçu du serveur d’origine une réponse qu’il ne peut pas traiter : vide, interrompue ou avec des en-têtes invalides. Il s’agit d’une erreur générique de Cloudflare.

Causes typiques

  • Le serveur d’origine plante lors de la requête, par exemple à cause d’une erreur PHP
  • Les en-têtes de réponse dépassent 32 KB, souvent à cause d’un trop grand nombre de cookies
  • La réponse est vide ou la connexion a été fermée sans réponse
  • Un pare-feu bloque certaines adresses IP de Cloudflare

Comment tu peux résoudre le problème

  • Consulte le journal d’erreurs du serveur d’origine.
  • Autorise les plages d’adresses IP de Cloudflare dans le pare-feu et Fail2ban.
  • Réduis la taille des en-têtes et des cookies.
Voir aussi :
Défini dans Cloudflare

Signification

Cloudflare n’a pas pu établir de connexion avec le serveur d’origine : celui-ci a refusé la connexion. Le site et Cloudflare sont accessibles, mais pas ton serveur derrière.

Causes typiques

  • Le serveur web (nginx, Apache) ne fonctionne pas
  • Un pare-feu ou l’hébergeur bloque les adresses IP de Cloudflare
  • Adresse IP d’origine ou port incorrect dans les paramètres Cloudflare

Comment tu peux résoudre le problème

  • Démarre le serveur web et vérifie qu’il écoute sur les ports 80 et 443.
  • Autorise les plages d’adresses IP de Cloudflare.
  • Vérifie l’enregistrement DNS A et le port du serveur d’origine.

Configuration et commandes (exemples)

Shell
ss -tlnp | grep -E ':(80|443)\b'
Voir aussi :
Défini dans Cloudflare

Signification

Cloudflare a tenté de se connecter au serveur d’origine, mais la négociation TCP n’a pas abouti à temps. La connexion a expiré avant même l’envoi d’une requête.

Causes typiques

  • Le serveur d’origine est surchargé ou hors ligne
  • Un pare-feu rejette les paquets provenant de Cloudflare
  • Adresse IP incorrecte ou problème de routage

Comment tu peux résoudre le problème

  • Vérifie l’accessibilité et la charge du serveur.
  • Autorise les plages d’adresses IP de Cloudflare dans le pare-feu.
  • Vérifie l’adresse IP dans l’enregistrement DNS.
Voir aussi :
Défini dans Cloudflare

Signification

Cloudflare ne peut pas joindre le serveur d’origine, par exemple à cause d’une erreur DNS ou d’une route manquante.

Causes typiques

  • Adresse IP incorrecte dans l’enregistrement DNS
  • Serveur ou centre de données hors ligne, problème de routage

Comment tu peux résoudre le problème

  • Vérifie l’enregistrement DNS.
  • Contacte l’hébergeur et vérifie le réseau.
Voir aussi :
Défini dans Cloudflare

Signification

Cloudflare a pu se connecter, mais le serveur d’origine n’a pas fourni de réponse HTTP dans les 100 secondes.

Causes typiques

  • Scripts, exports ou imports longs
  • Un serveur surchargé

Comment tu peux résoudre le problème

  • Exécute les tâches longues en arrière-plan.
  • Réduis le temps de réponse.
  • Pour les tâches longues, utilise le streaming ou interroge le statut plutôt que d’envoyer une seule requête.
Voir aussi :
Défini dans Cloudflare

Signification

La négociation TLS entre Cloudflare et le serveur d’origine a échoué.

Causes typiques

  • Le serveur d’origine ne propose pas HTTPS sur le port 443
  • Aucune suite de chiffrement ni version TLS commune
  • SNI manquant ou certificat non correspondant

Comment tu peux résoudre le problème

  • Vérifie la configuration TLS du serveur d’origine.
  • Choisis dans Cloudflare le mode SSL/TLS adapté au serveur d’origine.
Voir aussi :
Défini dans Cloudflare

Signification

Cloudflare n’a pas pu vérifier le certificat du serveur d’origine. Se produit en mode « Full (strict) ».

Causes typiques

  • Certificat expiré, autosigné ou non émis pour le domaine
  • Il manque un certificat intermédiaire

Comment tu peux résoudre le problème

  • Installe un certificat valide (Let's Encrypt ou un certificat Cloudflare Origin).
  • Fournis la chaîne complète des certificats.
Voir aussi :
Défini dans Cloudflare

Exemple de résultat

Ce que t’apprend la référence des codes de statut HTTP

Saisis un numéro ou un mot-clé pour afficher immédiatement les codes de statut correspondants, chacun avec sa signification, ses causes courantes, une solution et, le cas échéant, un exemple prêt à l’emploi pour nginx ou Apache. Trois exemples :

Exemple 1 : rechercher un numéro

Saisie :

502

Résultat : une entrée avec ces informations

Code de statut et nom
502 Bad Gateway
Classe
5xx Erreur du serveur
Signification
Un serveur agissant comme passerelle ou proxy (nginx, Apache, équilibreur de charge, CDN) a reçu une réponse invalide du serveur en amont, ou aucune réponse. L’erreur se situe entre les serveurs, pas chez le visiteur.
Première cause fréquente
Le service backend (PHP-FPM, Node.js, Gunicorn, conteneur Docker) ne fonctionne pas ou a planté
Première étape de résolution
Vérifie l’état du service backend et redémarre-le (systemctl status, docker ps).
Exemple à copier (nginx)
tail -n 50 /var/log/nginx/error.log

Résultat en clair : avec 502 Bad Gateway, le serveur derrière le proxy ne répond pas ou renvoie une réponse invalide. L’entrée présente 5 causes fréquentes et 5 étapes de résolution, comme vérifier le service backend et consulter le journal des erreurs. Le problème se situe entre les serveurs, pas chez le visiteur.

Exemple 2 : rechercher une classe

Saisie :

3xx

Résultat : tous les codes de la classe 3xx de la liste

Résultats de recherche 3xx
Code de statutNom
300Multiple Choices
301Moved Permanently
302Found
303See Other
304Not Modified
307Temporary Redirect
308Permanent Redirect

Résultat en clair : la liste contient 7 codes de la classe 3xx, les codes obsolètes 305 et 306 n’y figurent pas. Tous ne redirigent pas : 304, par exemple, renvoie au cache. Les plus importantes sont 301 (déplacement permanent), 302 (redirection temporaire) et 304 (contenu inchangé, utiliser le cache). Chaque entrée explique quand elle apparaît et comment tu peux l’utiliser correctement.

Exemple 3 : rechercher un mot-clé

Saisie :

timeout

Résultat : les meilleures correspondances en premier

  1. 408 Request Timeout
  2. 504 Gateway Timeout
  3. 524 A Timeout Occurred
  4. 102 Processing

Résultat en clair : 4 entrées contiennent le mot-clé. Les résultats dont le nom correspond apparaissent en premier : 408 Request Timeout, 504 Gateway Timeout, 524 A Timeout Occurred. Viennent ensuite les entrées où « timeout » figure uniquement dans l’explication, les causes ou les exemples de configuration.

Comment ça fonctionne

Comment tu recherches un code de statut

Quatre étapes du numéro à l’exemple final – sans compte ni téléchargement.

Étape 1

Saisir un code de statut ou un mot-clé

Saisis dans le champ de recherche un numéro comme 502, un nom comme « bad gateway » ou un mot-clé comme « timeout » ou « redirection ». Les résultats apparaissent dès la saisie.

Étape 2

Filtrer par classe

Utilise les filtres pour limiter l’affichage à une catégorie : 3xx pour les redirections, 4xx pour les erreurs client et 5xx pour les erreurs serveur. « Recherches fréquentes » affiche les codes les plus courants.

Étape 3

Développer l’entrée

Clique sur un code pour voir sa signification et, selon le cas, les causes fréquentes, les étapes de résolution et son effet sur le référencement. « Voir aussi » te mène aux codes associés.

Étape 4

Copier et adapter l’exemple

Un exemple pour nginx, Apache ou le shell est fourni lorsque cela peut aider. Copie-le, adapte les chemins et les valeurs à ton serveur, puis recharge le serveur web.

Erreurs fréquentes

404, 403, 500, 502, 503 : les erreurs HTTP les plus courantes expliquées brièvement

Une réponse courte pour chaque code d’erreur. Clique sur « Toutes les causes et solutions » pour ouvrir l’entrée complète dans la référence ci-dessus.

400

Bad Request

Le serveur ne comprend pas la requête. Les causes fréquentes sont une adresse incorrecte, des cookies trop volumineux ou endommagés et un en-tête de requête invalide. Supprime les cookies du site et vérifie l’adresse.

Toutes les causes et solutions

401

Unauthorized

Cette page nécessite une authentification, mais tes identifiants sont absents ou invalides. Utilise des identifiants valides, par exemple pour une protection par mot de passe via .htaccess ou une API avec token.

Toutes les causes et solutions

403

Forbidden

Le serveur connaît l’adresse, mais te refuse l’accès. Causes fréquentes : des droits d’accès incorrects, l’absence de document d’index, un blocage d’IP ou une règle de pare-feu.

Toutes les causes et solutions

404

Not Found

Rien à cette adresse : erreur de saisie, page supprimée ou déplacée, ou problème de majuscules et de minuscules. Redirige les pages déplacées avec une redirection 301. Quelques erreurs 404 isolées ne nuisent pas au classement.

Toutes les causes et solutions

429

Too Many Requests

Tu as envoyé trop de requêtes en peu de temps. Attends la durée indiquée dans l’en-tête Retry-After, puis réessaie en espaçant davantage tes tentatives.

Toutes les causes et solutions

500

Internal Server Error

Une erreur générale sur le serveur. Sa cause figure dans le journal d’erreurs du serveur web. Il s’agit souvent d’une erreur de code, d’un fichier .htaccess défectueux, de droits incorrects ou d’une base de données inaccessible.

Toutes les causes et solutions

502

Bad Gateway

Le proxy ou le répartiteur de charge ne reçoit aucune réponse valide du backend, généralement parce que PHP-FPM, Node.js ou le serveur d’application ne fonctionne pas ou a planté. Vérifie le service et son journal.

Toutes les causes et solutions

503

Service Unavailable

Le serveur est surchargé ou en maintenance et indique que la situation est temporaire. Pour une maintenance, le code approprié est 503 avec l’en-tête Retry-After.

Toutes les causes et solutions

504

Gateway Timeout

Le backend répond trop lentement : le proxy abandonne après son délai d’attente. Recherche les requêtes ou scripts lents et augmente le délai d’expiration si nécessaire, avec proxy_read_timeout pour nginx.

Toutes les causes et solutions

Vue d’ensemble

Les cinq classes de codes de réponse HTTP

Le premier chiffre indique la nature du problème. Tu peux ainsi savoir sans recherche si l’erreur vient du visiteur ou du serveur.

1xx

Informations

La requête a été reçue et son traitement se poursuit. Il s’agit d’une réponse intermédiaire, pas encore d’un résultat.

Fréquent :

4 codes dans cette référence

2xx

Succès

La requête a été comprise et traitée avec succès. 200 est le cas normal.

Fréquent : 200, 201, 204

10 codes dans cette référence

3xx

Redirection

Le client doit effectuer une étape supplémentaire, généralement suivre une nouvelle adresse ou utiliser le cache.

Fréquent : 301, 302, 304, 307, 308

7 codes dans cette référence

4xx

Erreur client

La requête est incorrecte ou non autorisée. Pour le serveur, l’erreur vient du client, par exemple 404 pour une adresse inconnue.

Fréquent : 400, 401, 403, 404, 405, 410, 413, 422, 429

31 codes dans cette référence

5xx

Erreur du serveur

La requête était valide, mais le serveur n’a pas pu la traiter. L’erreur vient de l’exploitant, par exemple 500, 502 ou 503.

Fréquent : 500, 502, 503, 504

18 codes dans cette référence

Redirections

301 ou 302 ? Comparaison des codes de redirection

Cinq codes déclenchent une redirection. Ils diffèrent sur deux points : la redirection est-elle permanente et le client conserve-t-il la méthode HTTP ?

Comparaison des codes de statut de redirection 301, 302, 303, 307 et 308
Code de statutDuréeLa méthode reste inchangée
301 Moved PermanentlyMigration d’une page ou d’un domaine, de http vers https ou de www vers le domaine principal. La norme pour le SEO.permanentnon garanti
302 FoundRedirection temporaire, par exemple pour une campagne, une connexion ou un choix de langue.temporairementnon garanti
303 See OtherRediriger vers une page de résultats après une requête POST (Post/Redirect/Get). Le navigateur la récupère par GET.temporairementnon garanti
307 Temporary RedirectRedirection temporaire d’une API ou d’un formulaire qui doit conserver la méthode.temporairementoui
308 Permanent RedirectMigration définitive d’une API ou de la destination d’un formulaire, sans changement de méthode.permanentoui

Règle pratique : 301 pour les pages ordinaires déplacées définitivement, 302 pour les déplacements temporaires. Si une API ou un formulaire doit conserver la méthode POST, utilise 308 au lieu de 301 et 307 au lieu de 302. « Non garanti » signifie que les navigateurs transforment souvent une requête POST en GET.

Pratique

Comment tu trouves le code de statut d’une page

Dans le navigateur, ouvre les outils de développement (F12) : l’onglet « Réseau » affiche le code de chaque requête. Sur le serveur ou dans le terminal, ces quatre commandes t’aideront :

Affiche uniquement les en-têtes de réponse ; la première ligne contient le code de statut.

curl -I https://example.com/seite

Affiche uniquement le code de statut, pratique pour les scripts et la surveillance.

curl -s -o /dev/null -w "%{http_code}\n" https://example.com/seite

Suit les redirections et affiche chaque étape avec son code de statut et sa destination.

curl -sIL https://example.com/alt | grep -iE '^(HTTP|location)'

Compte les codes de statut dans le journal d’accès de nginx ou Apache (format combined) et les trie par fréquence.

awk '{print $9}' /var/log/nginx/access.log | sort | uniq -c | sort -rn

Découvrir plus

Autres outils

Vérificateur de disponibilité de site web

Vérifie si un site web est en ligne, lent ou hors ligne : statut HTTP, temps de réponse et cause des erreurs, comme un problème DNS, un délai d’attente dépassé, une erreur TLS ou une erreur 5xx.

Créé par Eric Mager

Vérificateur SSL

Vérifie d’un coup d’œil le statut, l’émetteur, la période de validité et la date d’expiration d’un certificat SSL/TLS.

Créé par Sebastian Rademacher

Redirect Checker

Vérifie les chaînes de redirections d’une URL étape par étape : codes de statut (301/302/307/308), en-têtes HTTP, IP du serveur et temps de réponse pour chaque redirection.

Créé par Luca Stanek

Vérificateur de ports

Vérifie si certains ports sont ouverts sur une adresse IP ou un nom d’hôte : sélectionne un protocole ou un jeu plutôt que d’analyser tous les ports.

Créé par Sebastian Rademacher

Calculateur CHMOD

Définis les permissions de fichiers Unix/Linux à l’aide de cases à cocher pour obtenir la valeur octale et la notation symbolique, ou décode-les dans l’autre sens. Inclut setuid/setgid/sticky bit et une commande chmod prête à copier.

Créé par Justin Schuessler

Générateur .htaccess et générateur htpasswd

Crée des fichiers Apache .htaccess et .htpasswd en ligne : redirections 301, HTTPS, protection par mot de passe avec bcrypt, règles WordPress, pages d’erreur, mise en cache, GZIP et protection contre le hotlinking. Fonctionne entièrement dans le navigateur.

Créé par Dimitri Heissler

FAQ

Questions fréquentes

Des réponses courtes sur les codes HTTP les plus courants, leurs causes et cette référence.

Un code de statut HTTP est un nombre à trois chiffres qu’un serveur renvoie pour chaque requête. Il indique si la requête a réussi et, sinon, pourquoi. Le premier chiffre désigne la classe : 1xx information, 2xx succès, 3xx redirection, 4xx erreur côté client, 5xx erreur côté serveur. Les codes d’erreur HTTP que tu rencontreras le plus souvent sont 400, 401, 403, 404 et 429 côté client, ainsi que 500, 502, 503 et 504 côté serveur. Le filtre « Les plus recherchés » les regroupe avec d’autres codes courants.

200 OK signifie que la requête a réussi et que le serveur renvoie la page ou les données. C’est la réponse normale pour toute page destinée aux visiteurs et aux moteurs de recherche. Veille à ce que les pages d’erreur ne soient pas renvoyées avec 200, sous peine de créer des « soft 404 ». Codes associés : 201 Created signale une ressource nouvellement créée, 204 No Content une réponse réussie sans corps, et 304 Not Modified indique que le fichier n’a pas changé et que le navigateur utilise sa copie.

Le serveur ne comprend pas la requête et la rejette avant de la traiter. Les causes fréquentes sont une adresse mal formée contenant des caractères invalides, des cookies trop volumineux ou corrompus, un en-tête trop volumineux ou un corps de requête mal formaté pour une API. Si tu visites le site, supprime ses cookies. Si tu l’exploites, vérifie la requête, les en-têtes et les journaux. Lorsque le format est correct mais qu’une valeur est invalide, par exemple si un champ obligatoire manque, de nombreuses API renvoient plutôt 422 Unprocessable Content (anciennement « Unprocessable Entity »).

Le serveur est accessible, mais ne connaît pas cette adresse. Vérifie d’abord les fautes de frappe et la casse du nom de fichier, car Linux en tient compte. Vérifie ensuite le chemin sur le serveur web et, pour WordPress ou une application monopage, les règles de réécriture (try_files avec nginx). Redirige les pages déplacées avec une redirection 301. Quelques erreurs 404 isolées ne nuisent pas au classement, contrairement aux pages importantes ayant des backlinks qui ne mènent plus nulle part.

401 Unauthorized signifie « non authentifié » : des identifiants valides permettent d’accéder à la ressource. 403 Forbidden signifie « authentifié ou non, l’accès est interdit » : le serveur refuse l’accès dans tous les cas. Les causes fréquentes d’un 403 sont des droits ou un propriétaire de fichier incorrects, l’absence de page d’index, un blocage d’IP ou des règles WAF. Le calculateur CHMOD convertit les permissions telles que 755 pour les répertoires et 644 pour les fichiers. Accéder au calculateur CHMOD

Le code ne révèle pas la cause : elle figure dans le journal d’erreurs du serveur web (pour nginx : /var/log/nginx/error.log ; pour Apache : /var/log/apache2/error.log) ou dans le journal PHP. Les causes fréquentes sont une erreur de code, un fichier .htaccess incorrect, des droits d’accès aux fichiers inadaptés, une base de données inaccessible ou une limite de mémoire PHP atteinte. Annule la dernière modification (plugin, mise à jour, règle) et teste la configuration avec nginx -t ou apachectl configtest.

502 Bad Gateway : le proxy reçoit une réponse invalide du backend, ou aucune réponse, généralement parce que le service (PHP-FPM, Node.js) ne fonctionne pas. 503 Service Unavailable : le serveur est surchargé ou en maintenance et le signale lui-même. 504 Gateway Timeout : le backend répond, mais trop lentement, souvent à cause d’une requête lourde ou d’une surcharge. Dans les trois cas, commence par consulter le journal d’erreurs et vérifier le service backend. Pour une maintenance planifiée, le bon code est 503 avec l’en-tête « Retry-After », et non une page de maintenance renvoyée avec 200.

301 signale un déplacement permanent : les moteurs de recherche adoptent la nouvelle adresse et lui transfèrent le classement. 302 signale une redirection temporaire : l’ancienne adresse reste dans l’index. Utilise 301 pour les changements de domaine ou d’adresse de page, et 302 pour les situations temporaires, comme les campagnes. Si la méthode (POST) d’un formulaire ou d’une API doit être conservée, utilise 308 au lieu de 301 et 307 au lieu de 302.

Ces codes ne font pas partie de la norme HTTP. Les codes 520 à 526 viennent de Cloudflare et indiquent que Cloudflare, et non ton visiteur, rencontre un problème avec ton serveur d’origine : 520 erreur inconnue, 521 connexion refusée, 522 connexion non établie, 523 serveur d’origine inaccessible, 524 aucune réponse dans les 100 secondes, 525 échec de la négociation TLS, 526 certificat invalide. En général, autoriser les plages d’adresses IP de Cloudflare dans le pare-feu et vérifier le serveur web et le certificat permet de résoudre le problème. Les codes 444 et 499 n’apparaissent que dans les journaux nginx : avec 444, nginx ferme volontairement la connexion sans répondre ; avec 499, le client a fermé la connexion avant de recevoir la réponse.

Dans ton navigateur, appuie sur F12 pour ouvrir les outils de développement, puis regarde la colonne « Statut » de l’onglet « Réseau ». Dans le shell, curl -I https://example.com affiche les en-têtes et le code de statut, tandis que curl -s -o /dev/null -w "%{http_code}" https://example.com n’affiche que le nombre. Avec curl -sIL, tu vois aussi chaque redirection du parcours. Cette référence ne contacte elle-même aucune adresse : elle fonctionne entièrement dans ton navigateur. Seuls le terme recherché et le filtre de classe figurent dans l’URL pour que tu puisses partager une recherche. Pour vérifier une chaîne de redirections, utilise le Redirect Checker. Accéder au Redirect Checker

D’autres questions ?

Contacter le support
Tu gères ton propre projet ?

Code de statut 200 au lieu de 502 : un hébergement qui assure la disponibilité de ton application

Un VPS ZAP-Hosting met ton application ou ton projet en ligne de manière fiable.

4,4/5 Trustpilot32 000+ Serveurs actifsDepuis 2010
Voir l’hébergement

Sans configuration. Sans risque. En ligne en quelques secondes.

Durée flexibleRésiliable à tout momentEn ligne en 60 secondes

Tu cherches d’autres outils ? Voir tous les outils de développement