nginx - client_max_body_size non ha alcun effetto

continua nginx client intended to send too large body. Googling e RTM mi hanno indicato client_max_body_size. Ho impostato su 200min nginx.confcosì come in vhost conf, riavviato Nginx un paio di volte ma sto ancora ricevendo il messaggio di errore.

Ho trascurato qualcosa? Il backend è php-fpm( max_post_sizee max_upload_file_sizeimpostato di conseguenza).

A seguito della documentazione di nginx , è possibile impostare client_max_body_size 20m (o qualsiasi valore necessario) nel seguente contesto:

context: http, server, location

I caricamenti di grandi dimensioni di NGINX stanno funzionando con successo sui siti WordPress ospitati, finalmente (secondo i suggerimenti di nembleton e rjha94)

Ho pensato che potrebbe essere utile per qualcuno, se ho aggiunto un piccolo chiarimento ai loro suggerimenti. Per i principianti, assicurati di aver incluso la tua direttiva di upload aumentata in TUTTI I TRE blocchi di definizione separati (server, posizione e http). Ognuno dovrebbe avere una riga separata. Al risultato piacerà qualcosa del genere (dove il ... riflette altre linee nel blocco di definizione):

http {
    ...
    client_max_body_size 200M;
}    

(nella mia installazione di ISPconfig 3, questo blocco si trova nel file /etc/nginx/nginx.conf)

server {
    ...
    client_max_body_size 200M;
}

location / {
    ...
    client_max_body_size 200M;
} 

(nella mia installazione di ISPconfig 3, questi blocchi si trovano nel file /etc/nginx/conf.d/default.conf)

Inoltre, assicurati che il file php.ini del tuo server sia coerente con queste impostazioni NGINX. Nel mio caso, ho modificato l'impostazione nella sezione File_Uploads di php.ini per leggere:

upload_max_filesize = 200M

Nota: se si sta gestendo un'installazione ISPconfig 3 (la mia installazione è su CentOS 6.3, come per The Perfect Server ), sarà necessario gestire queste voci in diversi file separati. Se la configurazione è simile a una nell'installazione passo-passo, i file di configurazione di NGINX che è necessario modificare si trovano qui:

/etc/nginx/nginx.conf
/etc/nginx/conf.d/default.conf 

Il mio file php.ini si trovava qui:

/etc/php.ini

Ho continuato a trascurare il blocco http {} nel file nginx.conf. Apparentemente, trascurare questo ha avuto l'effetto di limitare il caricamento al limite predefinito di 1 milione. Dopo aver apportato le modifiche associate, sarà anche necessario riavviare i servizi NGINX e PHP FastCGI Process Manager (PHP-FPM). Nella configurazione precedente, utilizzo i seguenti comandi:

/etc/init.d/nginx restart
/etc/init.d/php-fpm restart

A partire da marzo 2016 , ho riscontrato questo problema provando a POST json su https (dalle richieste di Python, non importa).

Il trucco è mettere "client_max_body_size 200M;" in almeno due posti http {}eserver {} :

1. la httpdirectory

• In genere /etc/nginx/nginx.conf

2. la serverdirectory nel tuo vhost.

• Per gli utenti Debian / Ubuntu che hanno installato tramite apt-get (e altri gestori di pacchetti distro che installano nginx con vhosts di default), questo è /etc/nginx/sites-available/mysite.com, per quelli che non hanno vhosts, è probabilmente il tuo nginx.conf o nella stessa directory di esso.

3. la location /directory nello stesso posto di 2.

• Puoi essere più specifico di /, ma se non funziona affatto, consiglierei di applicarlo a /e poi una volta che il suo funzionamento sarà più specifico.

Ricorda : se disponi di SSL, ciò richiederà di impostare quanto sopra per SSL servere locationovunque, idealmente uguale a 2. ). Ho scoperto che se il tuo client tenta di caricare su http e ti aspetti che ottengano 301 in https, nginx interromperà effettivamente la connessione prima del reindirizzamento a causa del file troppo grande per il server http, quindi deve essere in entrambi .

Recenti commenti suggeriscono che c'è un problema con questo su SSL con le nuove versioni di nginx, ma io sono su 1.4.6 e tutto è buono :)

È necessario applicare le seguenti modifiche:

1. Aggiorna php.ini(trova il file ini giusto da phpinfo();) e aumenta post_max_sizee upload_max_filesizealle dimensioni desiderate:

   sed -i "s/post_max_size =.*/post_max_size = 200M/g" /etc/php5/fpm/php.ini
   sed -i "s/upload_max_filesize =.*/upload_max_filesize = 200M/g" /etc/php5/fpm/php.ini```
   

2. Aggiornamento Nginx impostazioni per il tuo sito e aggiungere client_max_body_sizevalore nella vostra location, httpo servercontesto.

   location / {
       client_max_body_size 200m;
       ...
   }
   

3. Riavvia NginX e PHP-FPM:

   service nginx restart
   service php5-fpm restart
   

NOTA: a volte (nel mio caso quasi ogni volta) è necessario interrompere il php-fpmprocesso se non è stato aggiornato correttamente dal comando di servizio. Per fare ciò puoi ottenere un elenco di processi ( ps -elf | grep php-fpm) e uccidere uno per uno ( kill -9 12345) o usare il comando seguente per farlo per te:

ps -elf | grep php-fpm | grep -v grep | awk '{ print $4 }' | xargs kill -9

Verifica se stai impostando la direttiva client_max_body_size all'interno del blocco http {} e non all'interno del blocco location {}. L'ho impostato all'interno del blocco http {} e funziona

Qualcuno mi corregga se questo è male, ma mi piace bloccare tutto il più possibile, e se hai solo un target per i caricamenti (come di solito accade), quindi scegli come target le tue modifiche su quel file. Questo funziona per me sul pacchetto Ubuntu nginx-extra mainline 1.7+:

location = /upload.php {
    client_max_body_size 102M;
    fastcgi_param PHP_VALUE "upload_max_filesize=102M \n post_max_size=102M";
    (...)
}

Ho avuto un problema simile di recente e ho scoperto che client_max_body_size 0;può risolvere un tale problema. Ciò imposterà client_max_body_size su nessun limite. Ma la migliore pratica è migliorare il tuo codice, quindi non è necessario aumentare questo limite.

Supponendo di aver già impostato client_max_body_size e varie impostazioni PHP (upload_max_filesize / post_max_size, ecc.) Nelle altre risposte, quindi riavviato o ricaricato NGINX e PHP senza alcun risultato, eseguire questo ...

nginx -T

Questo ti darà eventuali errori irrisolti nelle tue configurazioni NGINX. Nel mio caso, ho lottato con l'errore 413 per un giorno intero prima di rendermi conto che c'erano altri errori SSL non risolti nella configurazione NGINX (percorso errato per certificati) che dovevano essere corretti. Una volta risolti i problemi irrisolti che ho ricevuto da "nginx -T", ricaricato NGINX ed EUREKA !! Ciò l'ha risolto.

Sto configurando un server dev per giocare con quello che rispecchia il nostro live obsoleto, ho usato The Perfect Server - Ubuntu 14.04 (nginx, BIND, MySQL, PHP, Postfix, Dovecot e ISPConfig 3)

Dopo aver riscontrato lo stesso problema, mi sono imbattuto in questo post e non funzionava nulla. Ho modificato il valore in ogni file consigliato (nginx.conf, ispconfig.vhost, / sites-available / default, ecc.)

Infine, cambiare il client_max_body_sizemio /etc/nginx/sites-available/apps.vhoste riavviare nginx è quello che ha fatto il trucco. Spero che aiuti qualcun altro.

Incontro lo stesso problema, ma non ho trovato nulla a che fare con nginx. Sto usando nodejs come server back-end, uso nginx come proxy inverso, il codice 413 è attivato dal nodo server. nodo usa koa analizza il corpo. koa limita la lunghezza codificata.

formLimit: limite del corpo codificato. Se il corpo finisce per essere più grande di questo limite, viene restituito un codice di errore 413. L'impostazione predefinita è 56kb.

impostare formLimit su più grande può risolvere questo problema.

Aveva lo stesso problema che la client_max_body_sizedirettiva era stata ignorata.

Il mio sciocco errore è stato quello di inserire un file all'interno del /etc/nginx/conf.dquale non è finito .conf. Nginx non li caricherà per impostazione predefinita.

Se stai utilizzando la versione di Windows nginx, puoi provare a terminare tutto il processo di nginx e riavviarlo per vedere. Ho riscontrato lo stesso problema nel mio ambiente, ma l'ho risolto con questa soluzione.