HTTP 413 Request Entity Too Large : Causes Profondes, Solutions et Guide de Configuration Serveur

L’erreur HTTP 413 Request Entity Too Large est un code de statut de réponse côté serveur qui se produit lorsqu’un corps de requête entrant — le plus souvent un téléchargement de fichier — dépasse la taille de charge utile maximale configurée au niveau du serveur web, du proxy inverse ou de la couche applicative. Le serveur rejette activement la requête avant de la traiter, renvoyant un statut 413 au client.

Cette erreur n’est pas un bug côté client. Il s’agit d’un mécanisme d’application délibéré intégré aux serveurs web comme Nginx et Apache, aux configurations d’exécution PHP et aux middlewares au niveau applicatif. Comprendre exactement quelle couche applique la limite — et comment cibler la directive de configuration correcte — fait la différence entre une correction propre et des heures de dépannage.

Pourquoi les erreurs HTTP 413 se produisent : analyse couche par couche

Une requête de téléchargement de fichier passe par plusieurs couches de traitement avant d’atteindre votre application. N’importe laquelle de ces couches peut indépendamment rejeter la requête avec une réponse 413. Diagnostiquer correctement l’erreur nécessite d’identifier quelle couche en est responsable.

Couche 1 : Directives du serveur web

Nginx applique les limites de taille de téléchargement via la directive client_max_body_size. Sa valeur par défaut est 1 MB, ce qui est excessivement faible pour la plupart des applications modernes. Cette directive peut être définie dans le contexte de bloc http, server ou location, et le bloc le plus spécifique l’emporte.

Apache utilise la directive LimitRequestBody, dont la valeur par défaut est 0 (illimitée) dans la plupart des distributions — mais les hébergeurs la remplacent régulièrement par une valeur restrictive dans leurs configurations globales ou d’hôte virtuel. Apache traite également les fichiers .htaccess, ce qui signifie que la limite peut être appliquée au niveau du répertoire sans toucher à la configuration principale.

Couche 2 : Configuration d’exécution PHP

PHP introduit deux directives indépendantes qui doivent toutes deux être satisfaites pour qu’un téléchargement volumineux réussisse :

• upload_max_filesize — la taille maximale d’un seul fichier téléchargé
• post_max_size — la taille maximale du corps entier de la requête POST, qui doit être égale ou supérieure à upload_max_filesize

Une mauvaise configuration courante consiste à définir upload_max_filesize = 50M tout en laissant post_max_size à sa valeur par défaut de 8M. La limite du corps POST est évaluée en premier, de sorte que le téléchargement échoue silencieusement avant même que la limite de taille de fichier ne soit vérifiée.

Il existe également une troisième directive souvent négligée : max_input_time, qui définit combien de temps PHP attendra pour recevoir les données d’entrée. Sur des connexions lentes téléchargeant des fichiers volumineux, ce délai d’expiration peut déclencher un échec qui se manifeste par un 413 ou une réponse vide.

Couche 3 : Proxies inverses et équilibreurs de charge

Si votre infrastructure utilise un proxy inverse — HAProxy, Varnish, Cloudflare, ou une instance Nginx agissant comme proxy devant un autre serveur — cette couche proxy possède ses propres limites de taille de corps. Un 413 renvoyé par Cloudflare, par exemple, a une limite stricte de 100 MB sur les plans Free et Pro, et aucune configuration côté serveur ne peut la contourner. Vérifiez toujours les en-têtes de réponse de votre couche proxy pour identifier l’origine du 413.

Couche 4 : Restrictions applicatives et CMS

Les systèmes de gestion de contenu et les frameworks appliquent leurs propres restrictions de téléchargement en plus des couches serveur et PHP. WordPress lit la limite de téléchargement effective à partir des valeurs d’exécution de PHP, mais applique également ses propres contraintes de bibliothèque multimédia. Certains plugins WordPress ajoutent des couches de validation supplémentaires. Les applications PHP personnalisées peuvent utiliser une logique de validation $_FILES qui impose des limites plus strictes que ce que le serveur autorise.

Configuration Nginx : corriger le 413 au niveau du serveur web

Pour Nginx, la correction nécessite de modifier client_max_body_size dans le contexte de configuration approprié. Modifier le bloc http applique la limite globalement ; modifier un bloc server ou location l’applique uniquement à cet hôte virtuel ou point de terminaison.

# Global setting — applies to all virtual hosts
http {
    client_max_body_size 100M;
}

# Per-virtual-host setting — preferred for multi-tenant environments
server {
    listen 80;
    server_name example.com;
    client_max_body_size 100M;

    # Granular control — apply only to the upload endpoint
    location /wp-admin/async-upload.php {
        client_max_body_size 256M;
    }
}

Après modification, validez la syntaxe de la configuration avant de recharger :

nginx -t && systemctl reload nginx

Cas limite critique : Si Nginx agit comme proxy inverse devant PHP-FPM ou un autre serveur d’application, vous devez également vérifier les directives proxy_read_timeout et proxy_send_timeout. Un téléchargement volumineux qui prend plus de temps que le délai d’expiration sera interrompu en cours de transfert, produisant une erreur 413 ou 504 selon le comportement du proxy.

Configuration Apache : corriger le 413 au niveau du serveur web

La directive LimitRequestBody d’Apache accepte une valeur en octets. La directive peut être placée dans httpd.conf, un bloc VirtualHost, un bloc Directory, ou un fichier .htaccess.

# In httpd.conf or VirtualHost block
LimitRequestBody 104857600

# In .htaccess (if AllowOverride is enabled for the directory)
LimitRequestBody 104857600

La valeur 104857600 équivaut à 100 MB (100 × 1024 × 1024). Après avoir modifié httpd.conf ou un fichier d’hôte virtuel, redémarrez Apache :

apachectl configtest && systemctl restart apache2

Nuance importante : Sur les environnements d’hébergement partagé, les modifications de .htaccess peuvent être ignorées si l’hébergeur a défini AllowOverride None dans sa configuration au niveau serveur. Dans ce cas, seul l’hébergeur peut modifier la limite. C’est l’une des principales raisons techniques d’envisager de migrer vers un environnement VPS Hosting où vous disposez d’un accès root complet à la configuration du serveur.

Configuration PHP : corriger le 413 au niveau de l’exécution

Le fichier php.ini est la source faisant autorité pour les limites de téléchargement PHP. Le fichier correct à modifier dépend de votre modèle d’exécution PHP (mod_php, PHP-FPM, CLI). Utilisez phpinfo() ou php --ini pour identifier quel php.ini est réellement chargé.

; Minimum required changes for large file uploads
upload_max_filesize = 128M
post_max_size = 128M
max_input_time = 300
max_execution_time = 300
memory_limit = 256M

Après avoir modifié php.ini, redémarrez le service approprié :

# For PHP-FPM
systemctl restart php8.2-fpm

# For Apache with mod_php
systemctl restart apache2

Méthodes alternatives lorsque php.ini est inaccessible :

Si vous êtes sur un plan d’hébergement partagé sans accès direct à php.ini, vous pouvez peut-être remplacer les paramètres PHP en utilisant :

1. Un fichier .user.ini dans la racine web (fonctionne avec PHP-FPM) :

upload_max_filesize = 64M
post_max_size = 64M

1. Une directive .htaccess (fonctionne uniquement avec mod_php) :

php_value upload_max_filesize 64M
php_value post_max_size 64M

1. Du code PHP à l’exécution (efficacité limitée, non recommandé en production) :

@ini_set('upload_max_filesize', '64M');
@ini_set('post_max_size', '64M');

Notez que ini_set() ne peut pas remplacer upload_max_filesize ou post_max_size à l’exécution dans PHP 7.x et versions ultérieures — ces directives sont évaluées avant le début de l’exécution du script. Les méthodes .user.ini ou .htaccess sont bien plus fiables.

Correction spécifique à WordPress pour les erreurs 413

WordPress affiche sa limite de téléchargement effective dans l’écran Médias > Ajouter. Si la limite affichée est inférieure à ce que vous avez configuré dans php.ini, le problème vient généralement du fait que WordPress lit depuis un processus PHP différent ou qu’une couche de cache sert des données de configuration obsolètes.

Ajoutez ce qui suit à wp-config.php pour définir explicitement la taille de téléchargement :

@ini_set( 'upload_max_size', '128M' );
@ini_set( 'post_max_size', '128M' );
define( 'WP_MEMORY_LIMIT', '256M' );

Pour les installations WordPress Multisite, la taille de téléchargement au niveau du réseau est contrôlée séparément sous Administration réseau > Réglages > Réglages du réseau > Taille maximale du fichier téléversé. Ce paramètre est indépendant des limites PHP et doit être configuré en plus des modifications au niveau serveur.

Comparaison : où corriger le 413 selon l’environnement d’hébergement

Diagnostiquer quelle couche renvoie le 413

Avant d’appliquer un correctif, confirmez la source de la réponse 413. Utilisez curl avec une sortie détaillée pour inspecter les en-têtes de réponse :

curl -v -X POST -F "file=@/path/to/largefile.zip" https://example.com/upload

Examinez l’en-tête de réponse Server et tout en-tête X-Powered-By ou CF-RAY. Un en-tête CF-RAY indique que le 413 provient de Cloudflare, et non de votre serveur. Une réponse de nginx/1.x.x pointe vers la couche Nginx. L’absence d’en-tête Server peut indiquer un équilibreur de charge ou un WAF en amont de votre application.

Vérifiez également vos journaux d’erreurs serveur immédiatement après avoir déclenché le 413 :

# Nginx
tail -f /var/log/nginx/error.log

# Apache
tail -f /var/log/apache2/error.log

# PHP-FPM
tail -f /var/log/php8.2-fpm.log

Quand la configuration serveur ne suffit pas : considérations d’infrastructure

Pour les applications qui gèrent régulièrement des transferts de fichiers volumineux — plateformes vidéo, systèmes de sauvegarde, imagerie médicale, catalogues de produits e-commerce à grande échelle — coder en dur des limites de téléchargement élevées dans une configuration de serveur partagé n’est pas une architecture viable. Envisagez ces alternatives :

• Téléchargements fragmentés : Divisez les fichiers volumineux en fragments plus petits côté client à l’aide de bibliothèques comme Resumable.js ou Uppy. Chaque fragment respecte la limite du serveur, et le serveur les réassemble. Cela contourne entièrement le 413.
• Téléchargements directs vers le stockage objet : Générez une URL pré-signée pour un stockage compatible S3 et laissez le client télécharger directement, contournant entièrement votre serveur web. Le serveur web ne gère que la transaction de métadonnées.
• Points de terminaison de téléchargement dédiés : Configurez un bloc location séparé dans Nginx avec un client_max_body_size plus élevé spécifiquement pour les routes de téléchargement, en maintenant la limite par défaut restrictive pour tous les autres points de terminaison.

Pour les charges de travail intensives en calcul impliquant le traitement de fichiers volumineux — transcodage vidéo, inférence d’apprentissage automatique sur des données téléchargées — un environnement GPU Hosting fournit la capacité de traitement nécessaire pour gérer à la fois le téléchargement et le calcul ultérieur sans goulots d’étranglement.

Si votre application nécessite un environnement de panneau de contrôle géré avec un accès complet à la configuration PHP, un VPS avec cPanel vous donne accès à l’éditeur MultiPHP INI dans WHM, permettant des remplacements de directives PHP par domaine sans toucher à la ligne de commande.

Considérations de sécurité lors de l’augmentation des limites de téléchargement

Augmenter les limites de téléchargement sans renforcement de sécurité correspondant introduit une véritable surface d’attaque. Un serveur qui accepte des requêtes POST de 500 MB est une cible viable pour des attaques par déni de service qui épuisent les E/S disque, la mémoire ou les pools de connexions.

Mettez en œuvre les contrôles suivants parallèlement à toute augmentation de limite :

• Limitation du débit sur les points de terminaison de téléchargement : Dans Nginx, utilisez limit_req_zone pour restreindre la fréquence de téléchargement par IP.
• Validation du type de fichier : Ne vous fiez jamais au type MIME fourni par le client. Validez les signatures de fichiers (octets magiques) côté serveur.
• Permissions du répertoire de téléchargement : Le répertoire recevant les téléchargements ne doit pas être accessible via le web ni exécutable. Stockez les téléchargements en dehors de la racine du document.
• Analyse antivirus : Intégrez ClamAV ou un scanner similaire dans le pipeline de téléchargement pour tout point de terminaison de téléchargement accessible au public.
• Téléchargements authentifiés uniquement : Exigez une authentification avant d’accepter des charges utiles volumineuses. Les points de terminaison de téléchargement volumineux non authentifiés sont trivialement exploités.

Pour les environnements de production gérant des données téléchargées sensibles, associer votre infrastructure d’hébergement à des SSL Certificates correctement configurés garantit que les transferts de fichiers sont chiffrés en transit, empêchant l’interception du contenu téléchargé.

Matrice de décision technique : choisir le bon correctif

Liste de contrôle pratique pour résoudre HTTP 413

• Identifiez la couche renvoyant le 413 en utilisant curl -v et les journaux d’erreurs serveur avant d’effectuer tout changement
• Sur Nginx, définissez client_max_body_size dans le bloc applicable le plus spécifique (location préféré à server à http)
• Assurez-vous que post_max_size est toujours supérieur ou égal à upload_max_filesize dans php.ini
• Augmentez max_input_time et max_execution_time pour les fichiers volumineux sur les connexions lentes
• Vérifiez que les remplacements .htaccess sont autorisés (AllowOverride All ou AllowOverride Options) avant de vous y fier
• Vérifiez toutes les couches proxy indépendamment — CDN, équilibreur de charge et serveur d’application appliquent chacun des limites séparément
• Après tout changement de configuration, rechargez (ne redémarrez pas simplement) le service concerné et videz tout cache d’opcode ou de page
• Pour WordPress Multisite, configurez la limite de téléchargement au niveau réseau en plus des directives PHP
• Mettez en œuvre la limitation du débit et la validation du type de fichier avant d’augmenter les limites sur les points de terminaison de téléchargement accessibles au public
• Si l’hébergement partagé empêche l’accès à la configuration, migrez vers un environnement VPS Hosting ou Dedicated Servers pour un contrôle total

Foire aux questions

Quelle est la limite de téléchargement par défaut dans Nginx qui cause une erreur 413 ?

Nginx définit client_max_body_size à 1 MB par défaut. Tout corps de requête dépassant 1 MB renverra un 413 à moins que cette directive ne soit explicitement augmentée dans la configuration Nginx.

Puis-je corriger une erreur 413 sans accès root au serveur ?

Sur l’hébergement partagé, vous pouvez tenter des corrections via .htaccess (Apache uniquement, si AllowOverride le permet) ou un fichier .user.ini (PHP-FPM uniquement). Cependant, si l’hébergeur a défini des limites globales restrictives, ces méthodes seront inefficaces et vous devrez contacter le support ou passer à un plan VPS.

Pourquoi mon téléchargement échoue-t-il même après avoir augmenté upload_max_filesize dans php.ini ?

La cause la plus courante est que post_max_size reste à sa valeur par défaut inférieure. PHP évalue la limite de taille du corps POST avant la limite de taille de fichier individuelle, de sorte que le téléchargement est rejeté avant même que upload_max_filesize ne soit vérifié. Augmentez toujours les deux directives simultanément.

Cloudflare cause-t-il des erreurs 413 ?

Oui. Cloudflare applique ses propres limites de taille de corps de requête : 100 MB sur les plans Free et Pro, 200 MB sur Business, et 500 MB sur Enterprise. Si votre requête dépasse ces limites, Cloudflare renvoie un 413 avant que la requête n’atteigne votre serveur d’origine. Aucun changement de configuration côté serveur ne résoudra ce problème — vous devez soit passer à un plan Cloudflare supérieur, utiliser le contournement par téléchargement direct (URL pré-signées), soit mettre en œuvre des téléchargements fragmentés.

Comment corriger définitivement le 413 dans WordPress sur un serveur cPanel ?

Utilisez l’éditeur MultiPHP INI de WHM pour augmenter upload_max_filesize et post_max_size pour la version PHP et le domaine spécifiques. Vérifiez ensuite que le changement est reflété dans WordPress sous Médias > Ajouter. Pour WordPress Multisite, mettez également à jour la taille maximale de téléchargement sous Administration réseau > Réglages. Aucune modification de .htaccess ou wp-config.php n’est requise lors de l’utilisation directe de l’éditeur INI de WHM.