nginx - client_max_body_size nie ma wpływu

nginx ciągle mówi client intended to send too large body. Wskazały mnie Googling i RTM client_max_body_size. Ustawiłem go 200mna, nginx.confa także vhost confponownie uruchomiłem Nginx kilka razy, ale wciąż pojawia się komunikat o błędzie.

Czy coś przeoczyłem? Backend jest php-fpm( max_post_sizei max_upload_file_sizesą odpowiednio ustawione).

Postępując zgodnie z dokumentacją nginx , możesz ustawić client_max_body_size 20m (lub dowolną potrzebną wartość) w następującym kontekście:

context: http, server, location

W końcu duże pliki do przesyłania NGINX z powodzeniem działają na hostowanych stronach WordPress (zgodnie z sugestiami nembleton i rjha94)

Pomyślałem, że może to być pomocne dla kogoś, jeśli dodam trochę wyjaśnienia do ich sugestii. Na początek upewnij się, że umieściłeś dyrektywę zwiększonego przesyłania w WSZYSTKICH TRZY oddzielnych blokach definicji (serwer, lokalizacja i http). Każdy powinien mieć osobny wpis wiersza. Wynik polubi coś takiego (gdzie ... odzwierciedla inne linie w bloku definicji):

http {
    ...
    client_max_body_size 200M;
}    

(w mojej konfiguracji ISPconfig 3 ten blok znajduje się w pliku /etc/nginx/nginx.conf)

server {
    ...
    client_max_body_size 200M;
}

location / {
    ...
    client_max_body_size 200M;
} 

(w mojej konfiguracji ISPconfig 3 te bloki znajdują się w pliku /etc/nginx/conf.d/default.conf)

Upewnij się także, że plik php.ini twojego serwera jest zgodny z tymi ustawieniami NGINX. W moim przypadku zmieniłem ustawienie w sekcji File_Uploads php.ini, aby czytać:

upload_max_filesize = 200M

Uwaga: jeśli zarządzasz konfiguracją ISPconfig 3 (moja konfiguracja dotyczy CentOS 6.3, zgodnie z The Perfect Server ), będziesz musiał zarządzać tymi wpisami w kilku osobnych plikach. Jeśli twoja konfiguracja jest podobna do konfiguracji krok po kroku, pliki conf NGINX, które musisz zmodyfikować, znajdują się tutaj:

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

Mój plik php.ini znajdował się tutaj:

/etc/php.ini

Nadal przeoczyłem blok http {} w pliku nginx.conf. Najwyraźniej przeoczenie tego skutkowało ograniczeniem przesyłania do domyślnego limitu 1M. Po dokonaniu powiązanych zmian będziesz również musiał ponownie uruchomić usługi NGINX i PHP FastCGI Process Manager (PHP-FPM). W powyższej konfiguracji używam następujących poleceń:

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

W marcu 2016 r. Napotkałem ten problem, próbując POST json przez https (z żądań Pythona, ale to nie ma znaczenia).

Sztukąhttp {}server {} jest umieszczenie „client_max_body_size 200M;” w co najmniej dwóch miejscach i :

1.http katalogu

• Zazwyczaj w /etc/nginx/nginx.conf

2.server katalog w vhost.

• Dla użytkowników Debiana / Ubuntu, którzy zainstalowali się za pośrednictwem apt-get (i innych menedżerów pakietów dystrybucyjnych, którzy domyślnie instalują nginx z vhostami), to /etc/nginx/sites-available/mysite.comznaczy, dla tych, którzy nie mają vhostów, prawdopodobnie jest to twój nginx.conf lub w tym samym katalogu, co on.

3.location / katalog w tym samym miejscu co 2.

• Możesz być bardziej szczegółowy niż /, ale jeśli w ogóle nie działa, zaleciłbym zastosowanie tego do, /a następnie, gdy jego działanie będzie bardziej szczegółowe.

Pamiętaj - jeśli masz SSL, będziesz musiał ustawić powyższe dla SSL, servera locationtakże, gdziekolwiek to może być (najlepiej tak samo jak 2. ). Odkryłem, że jeśli twój klient spróbuje przesłać na http i oczekujesz, że dostanie 301 do https, nginx faktycznie porzuci połączenie przed przekierowaniem z powodu zbyt dużego pliku dla serwera http, więc musi to być w obu .

Ostatnie komentarze sugerują, że jest problem z SSL w nowszych wersjach nginx, ale mam 1.4.6 i wszystko jest dobrze :)

Musisz zastosować następujące zmiany:

1. Zaktualizuj php.ini(Znajdź odpowiedni plik ini z phpinfo();) i zwiększ post_max_sizei upload_max_filesizedostosuj do odpowiedniego rozmiaru:

   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. Aktualizacja nginx ustawienia swojej stronie i dodać client_max_body_sizewartość w swojej location, httplub serverkontekstu.

   location / {
       client_max_body_size 200m;
       ...
   }
   

3. Uruchom ponownie NginX i PHP-FPM:

   service nginx restart
   service php5-fpm restart
   

UWAGA: Kiedyś (w moim przypadku prawie za każdym razem) musisz zabić php-fpm proces, jeśli nie został poprawnie odświeżony poleceniem serwisowym. Aby to zrobić, możesz uzyskać listę procesów ( ps -elf | grep php-fpm) i zabijać jeden po drugim ( kill -9 12345) lub użyć następującego polecenia, aby zrobić to za Ciebie:

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

Sprawdź, czy ustawiasz dyrektywę client_max_body_size w bloku http {}, a nie wewnątrz bloku {}. Ustawiłem go w bloku http {} i działa

Ktoś mnie poprawi, jeśli to źle, ale lubię blokować wszystko tak bardzo, jak to możliwe, a jeśli masz tylko jeden cel do przesyłania (jak to zwykle bywa), po prostu skieruj zmiany do tego jednego pliku. Działa to dla mnie na pakiet Ubuntu nginx-extras mainline 1.7+:

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

Miałem ostatnio podobny problem i odkryłem, że client_max_body_size 0;można go rozwiązać. Spowoduje to ustawienie client_max_body_size na brak limitu. Ale najlepszą praktyką jest poprawa kodu, więc nie ma potrzeby zwiększania tego limitu.

Zakładając, że ustawiłeś już rozmiar klienta_max_body_size i różne ustawienia PHP (upload_max_filesize / post_max_size itp.) W innych odpowiedziach, a następnie ponownie uruchomiłeś lub ponownie załadowałem NGINX i PHP bez żadnego wyniku, uruchom ten ...

nginx -T

To da ci nierozwiązane błędy w twoich konfiguracjach NGINX. W moim przypadku walczyłem z błędem 413 przez cały dzień, zanim zdałem sobie sprawę, że były jeszcze inne nierozwiązane błędy SSL w konfiguracji NGINX (niewłaściwe ścieżki dla certyfikatów), które wymagały naprawy. Gdy naprawiłem nierozwiązane problemy, które otrzymałem z 'nginx-T', ponownie załadowałem NGINX i EUREKA !! To naprawiło to.

Konfiguruję serwer deweloperów, aby grać z tymi serwerami lustrzanymi naszego przestarzałego live, użyłem The Perfect Server - Ubuntu 14.04 (nginx, BIND, MySQL, PHP, Postfix, Dovecot i ISPConfig 3)

Po napotkaniu tego samego problemu natrafiłem na ten post i nic nie działało. Zmieniłem wartość w każdym zalecanym pliku (nginx.conf, ispconfig.vhost, / sites-available / default itp.)

Wreszcie, zmiana client_max_body_sizew moim /etc/nginx/sites-available/apps.vhosti restartowanie nginx jest tym, co załatwiło sprawę. Mam nadzieję, że pomaga komuś innemu.

Napotykam ten sam problem, ale nie znalazłem nic wspólnego z nginx. Używam nodejs jako serwera zaplecza, używam nginx jako odwrotnego proxy, kod 413 jest uruchamiany przez serwer węzła. użycie węzła koa parsuje ciało. koa ogranicza długość urlencoded.

formLimit: limit urlencodowanego ciała. Jeśli ciało ostatecznie przekroczy ten limit, zwracany jest kod błędu 413. Domyślnie jest to 56kb.

ustawienie formLimit na większe może rozwiązać ten problem.

Miałem ten sam problem, co client_max_body_size dyrektywa została zignorowana.

Mój głupi błąd polegał na tym, że włożyłem do niego plik, /etc/nginx/conf.dktóry się nie kończył .conf. Nginx nie ładuje ich domyślnie.

Jeśli używasz systemu Windows w wersji nginx, możesz spróbować zabić cały proces nginx i uruchomić go ponownie, aby zobaczyć. Napotkałem ten sam problem w moim środowisku, ale rozwiązałem go za pomocą tego rozwiązania.