413 Request Entity Too Large. Le message s’affiche brut, sans détail, souvent dans une page blanche générée par nginx et non par WordPress lui-même. L’import échoue avant même que PHP n’ait eu l’occasion de traiter le fichier, ce qui explique pourquoi augmenter upload_max_filesize dans le tableau de bord ou dans php.ini ne change strictement rien au comportement observé.
Ce symptôme touche particulièrement les hébergements mutualisés où l’accès aux réglages du serveur web est restreint, mais aussi les VPS mal configurés après une migration : le réglage par défaut de nginx limite les téléversements à 1 Mo, une valeur pensée pour des formulaires classiques, pas pour des exports vidéo ou des PDF illustrés.
Symptôme
Le formulaire d’ajout de média de la bibliothèque WordPress affiche une erreur générique (« Erreur HTTP » ou un écran blanc) dès qu’un fichier dépasse un certain seuil, souvent 1 Mo. Les petits fichiers passent sans problème, ce qui égare le diagnostic vers un souci de plugin ou de thème alors que la cause est entièrement côté serveur.
- Le fichier refuse de s’importer au-delà d’une taille précise, toujours la même
- Aucune erreur PHP dans les journaux de l’application : normal, PHP n’est jamais atteint
- Le comportement est identique en navigation privée et sur un autre navigateur
Diagnostic
Trois couches peuvent bloquer une requête volumineuse, et il faut les vérifier dans l’ordre où la requête les traverse : le proxy ou reverse-proxy en frontal (souvent nginx même devant Apache), PHP-FPM, puis WordPress lui-même via ses propres filtres.
Correctif : les trois réglages à aligner
Sur un bloc serveur nginx, la directive client_max_body_size fixe la limite avant que la requête n’atteigne PHP :
server {
client_max_body_size 64M;
location ~ \.php$ {
fastcgi_pass unix:/run/php/php8.1-fpm.sock;
}
}
Côté PHP-FPM, deux réglages dans php.ini (ou dans le pool spécifique) doivent suivre la même valeur, voire la dépasser légèrement pour absorber l’encodage multipart :
upload_max_filesize = 64M
post_max_size = 72M
Sur un hébergement mutualisé, ces réglages passent parfois par un fichier .user.ini déposé à la racine du site, lu automatiquement par PHP-FPM sans redémarrage nécessaire. Sur un VPS, un redémarrage du service est requis après modification :
sudo systemctl restart php8.1-fpm
sudo systemctl reload nginx
Si un proxy applicatif comme Cloudflare est aussi présent devant le serveur, il impose sa propre limite de téléversement selon le forfait souscrit, indépendamment de la configuration nginx. C’est un piège fréquent : le serveur est correctement réglé, mais le proxy en amont refuse la requête avant qu’elle n’atteigne l’infrastructure.
Prévention
Une checklist courte évite de reproduire l’incident sur le prochain site du parc :
- Documenter la taille maximale de fichier attendue dès le cahier des charges du site
- Aligner
client_max_body_size,upload_max_filesizeetpost_max_sizedans le même commit d’infrastructure - Vérifier la limite du CDN ou du proxy tiers avant d’accuser le serveur d’origine
- Tester l’import d’un fichier représentatif de la taille maximale annoncée avant la mise en production
Un import qui échoue sans message clair mérite toujours d’être testé en ligne de commande avec
curl -Favant de suspecter un plugin : cela isole immédiatement la couche fautive.
Le cas particulier d’Apache
Sur un hébergement encore basé sur Apache seul, sans nginx en frontal, la directive équivalente se règle via LimitRequestBody dans la configuration du site ou dans un fichier .htaccess à la racine, avec une valeur exprimée en octets plutôt qu’en unités lisibles :
# .htaccess
LimitRequestBody 67108864
Un mutualisé cPanel expose parfois ce réglage directement dans l’interface MultiPHP INI Editor, sans nécessiter d’accès SSH, ce qui simplifie la correction pour une équipe sans accès root au serveur.
En résumé
L’erreur 413 n’est jamais un problème WordPress : c’est un désaccord entre plusieurs couches serveur qui doivent partager la même limite de taille. Aligner nginx, PHP-FPM et l’éventuel proxy en frontal résout le problème dans l’immense majorité des cas, sans toucher à une ligne de code applicatif. Sur un parc de sites hébergés chez plusieurs prestataires différents, documenter ce triplet de réglages dans une fiche technique par serveur évite de redécouvrir le même diagnostic à chaque nouvel incident.
