Erreur 413 Request Entity Too Large : ce que signifie ce refus serveur
Ce code HTTP signifie que le serveur a refusé la requête avant même de la traiter, uniquement parce que sa taille dépasse une limite fixée à l’avance. Contrairement à une erreur 500 qui survient pendant l’exécution du code, un 413 bloque la requête à la porte : WordPress, PHP, voire le thème ou le plugin concerné ne voient jamais le contenu envoyé, puisque la couche serveur qui reçoit la requête (Apache, Nginx, ou un proxy en amont) l’a déjà rejetée.
Le message affiché varie selon le serveur : « 413 Request Entity Too Large » côté Nginx, « 413 Payload Too Large » sur certaines configurations, ou une page blanche avec juste le code dans les journaux si le thème WordPress n’intercepte pas l’erreur. Dans les trois cas, le symptôme concret est le même : un envoi de fichier qui échoue net, la barre de progression restant bloquée à 100 % sans jamais confirmer l’envoi.
Où cette erreur apparaît le plus fréquemment sur un site WordPress
Le déclencheur le plus fréquent est l’ajout d’un média dans la bibliothèque WordPress : une image haute résolution non compressée, une vidéo de démonstration, ou un fichier PDF volumineux dépassant la limite définie côté serveur. Vient ensuite l’import de contenu (migration depuis un fichier XML volumineux, restauration d’une sauvegarde complète via un plugin dédié) et, plus rarement, un formulaire de contact ou de candidature qui autorise l’envoi de pièces jointes sans limite explicite côté plugin — l’utilisateur joint un fichier trop lourd et le serveur coupe la requête avant qu’elle n’atteigne le traitement du formulaire, ce qui rend le blocage silencieux plutôt qu’explicite pour le visiteur.
Trois couches indépendantes peuvent imposer cette limite, et les distinguer dans l’ordre évite de modifier la mauvaise configuration en premier.
Cause n°1 : les limites PHP, insuffisantes pour le fichier envoyé
upload_max_filesize et post_max_size sont les deux directives PHP qui plafonnent respectivement la taille d’un fichier téléversé et la taille totale de la requête POST qui le contient. post_max_size doit toujours être supérieur ou égal à upload_max_filesize — une erreur de configuration fréquente consiste à augmenter uniquement la première valeur sans ajuster la seconde, ce qui laisse le blocage inchangé.
Sur un hébergement mutualisé, ces valeurs se modifient la plupart du temps depuis le panneau d’hébergement (section PHP ou multi-PHP) plutôt que par un fichier php.ini accessible directement. Une alternative disponible dans WordPress lui-même consiste à ajouter un filtre dans le thème ou un plugin de personnalisation, mais cette directive reste indicative : certains hébergeurs bloquent sa prise en compte au niveau serveur, ce qui explique pourquoi une modification côté WordPress seule ne suffit parfois pas.
Le plafond réel dépend aussi de la configuration mutualisée du serveur : sur une offre partagée entre plusieurs sites, l’hébergeur fixe parfois une limite plancher commune à tous les comptes, qu’un simple réglage individuel dans le panneau ne peut pas dépasser sans intervention du support.
Cause n°2 : la limite du serveur web, en amont de PHP
Même avec des valeurs PHP correctement augmentées, la requête peut encore être coupée par le serveur web lui-même avant d’atteindre l’interpréteur PHP. Sous Nginx, la directive client_max_body_size (définie dans la configuration du bloc server ou http) impose sa propre limite, fixée à 1 Mo par défaut quand elle n’est pas explicitement relevée — une valeur nettement inférieure à ce que la plupart des sites WordPress attendent pour un envoi de média courant. Sous Apache, l’équivalent est LimitRequestBody, rarement activé par défaut mais parfois configuré de façon restrictive par un hébergeur mutualisé pour limiter la charge serveur.
C’est la cause la plus fréquemment oubliée, parce que le message d’erreur affiché ne précise jamais quelle couche a bloqué la requête : une augmentation des seules valeurs PHP sans vérifier cette limite serveur laisse l’erreur 413 identique, ce qui donne l’impression trompeuse que la correction n’a eu aucun effet.
Cause n°3 : un proxy ou CDN qui plafonne la taille en amont du serveur
Quand le site passe par un proxy inverse ou un CDN (Cloudflare étant le plus répandu), une troisième limite s’ajoute avant même que la requête n’atteigne le serveur d’hébergement. Le plan gratuit de Cloudflare plafonne par exemple la taille d’upload à 100 Mo, une limite indépendante de la configuration du serveur d’origine et invisible depuis le panneau d’hébergement : le fichier peut respecter toutes les limites PHP et Nginx configurées, et être malgré tout rejeté par le proxy avant d’atteindre le serveur. Ce mécanisme de blocage en amont est le même principe qui explique certains cas d’erreur 522 Cloudflare : une couche intermédiaire impose ses propres règles, indépendamment de ce qui est configuré côté hébergeur.
Diagnostiquer précisément quelle couche bloque la requête
Tester avec des fichiers de tailles croissantes (1 Mo, 10 Mo, 50 Mo) permet d’identifier approximativement le seuil réel, à comparer ensuite aux valeurs configurées à chaque couche plutôt que de deviner laquelle est en cause. Les journaux d’erreur du serveur web, accessibles depuis le panneau d’hébergement ou par SSH selon l’offre, désignent la couche responsable dans la plupart des cas : une entrée mentionnant client_max_body_size ou une limite Nginx explicite pointe vers le serveur web, l’absence totale d’entrée alors que PHP a bien reçu la requête indique plutôt un plafonnement en amont (CDN ou proxy).
Vérifier les valeurs actuelles sans deviner reste plus rapide qu’une correction à l’aveugle : la page d’informations PHP de WordPress (Outils > Santé du site > Informations) affiche upload_max_filesize et post_max_size tels qu’appliqués réellement, ce qui confirme si la modification effectuée côté panneau d’hébergement a bien été prise en compte avant de chercher plus loin du côté du serveur web ou du proxy.
Un test réalisé directement en ligne de commande, via curl -F "file=@test.zip" https://votredomaine.fr/wp-admin/async-upload.php avec un fichier de taille connue, isole le comportement du serveur indépendamment de l’interface d’administration : le code de retour HTTP obtenu confirme si le blocage survient avant même que WordPress ne traite la requête.
Augmenter les limites sans casser la configuration existante
Une fois la couche responsable identifiée, la correction reste ciblée : relever upload_max_filesize et post_max_size ensemble depuis le panneau d’hébergement pour la cause PHP, ajouter ou modifier client_max_body_size dans la configuration Nginx (ou solliciter le support de l’hébergeur si cette configuration n’est pas éditable directement sur une offre mutualisée) pour la cause serveur web, et relever explicitement la limite d’upload dans le tableau de bord Cloudflare pour la cause proxy. Faire une sauvegarde complète du site avant toute modification de configuration serveur reste la précaution la plus utile : une directive mal formatée dans un fichier de configuration Nginx ou Apache peut empêcher le serveur de redémarrer, un incident nettement plus lourd qu’un simple échec d’upload.
Prévenir la récidive au moment de choisir un hébergeur
Cette limite varie fortement d’un hébergeur à l’autre, y compris entre deux offres mutualisées de la même gamme de prix, sans que l’écart soit toujours mis en avant dans les fiches commerciales. Un site qui manipule régulièrement des fichiers volumineux (galeries photo haute résolution, vidéos, sauvegardes complètes à restaurer) gagne à vérifier ce point précis avant de signer une offre, plutôt qu’à le découvrir au premier envoi bloqué. Le comparatif des meilleurs hébergeurs WordPress détaille les limites techniques par défaut (PHP, taille de fichier, accès à la configuration serveur) à examiner en priorité pour ce type d’usage.