nginx - client_max_body_size не впливає

nginx продовжує говорити client intended to send too large body. Гуглінг та RTM вказали на мене client_max_body_size. Я встановив це як 200mв, nginx.confтак і в vhost conf, перезапустивши Nginx кілька разів, але я все ще отримую повідомлення про помилку.

Я щось пропустив? Західний php-fpm( max_post_sizeі max_upload_file_sizeвстановлюється відповідно).

Дотримуючись документації nginx , ви можете встановити client_max_body_size 20м (або будь-яке необхідне вам значення) у наступному контексті:

context: http, server, location

Нарешті, великі завантаження NGINX успішно працюють на розміщених веб-сайтах WordPress (нарешті, відповідно до пропозицій nembleton & rjha94)

Я подумав, що це може бути корисним для когось, якщо я додати трохи пояснень до їх пропозицій. Для початку переконайтесь, що ви включили свою посилену директиву щодо завантаження у ВСІ ТРІ окремі блоки визначення (сервер, місцезнаходження та http). Кожен повинен мати окремий рядок. Результат сподобається щось подібне (де ... відображає інші рядки у блоці визначення):

http {
    ...
    client_max_body_size 200M;
}    

(у моїй установці ISPconfig 3 цей блок знаходиться у файлі /etc/nginx/nginx.conf)

server {
    ...
    client_max_body_size 200M;
}

location / {
    ...
    client_max_body_size 200M;
} 

(у моїй установці ISPconfig 3 ці блоки знаходяться у файлі /etc/nginx/conf.d/default.conf)

Також переконайтеся, що файл php.ini вашого сервера відповідає цим налаштуванням NGINX. У моєму випадку я змінив налаштування в розділі File_Uploads php.ini, щоб прочитати:

upload_max_filesize = 200M

Примітка: якщо ви керуєте установкою ISPconfig 3 (моя установка працює на CentOS 6.3, відповідно до Perfect Server ), вам потрібно буде керувати цими записами в декількох окремих файлах. Якщо ваша конфігурація схожа на налаштування покрокової настройки, файли конфіденційності NGINX, які потрібно змінити, розташовані тут:

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

Мій файл php.ini знаходився тут:

/etc/php.ini

Я продовжував оминати блок http {} у файлі nginx.conf. Мабуть, огляд на це призвів до обмеження завантаження до межі 1М за замовчуванням. Внісши пов’язані зміни, ви також хочете переконатись у перезапуску послуг NGINX та PHP FastCGI Process Manager (PHP-FPM). У наведеній конфігурації я використовую такі команди:

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

З березня 2016 року я зіткнувся з цим випуском, намагаючись POST json через https (з запитів python, не те, що це має значення).

Хитрість полягає в тому, щоб поставити "client_max_body_size 200M;" по крайней мере в двох місцях http {}іserver {} :

1.http каталог

• Зазвичай в /etc/nginx/nginx.conf

2.server каталог в віртуальному хості.

• Для користувачів Debian / Ubuntu, які встановили через apt-get (та інших менеджерів пакетів дистрибутивів, які встановлюють nginx з vhosts за замовчуванням), це /etc/nginx/sites-available/mysite.comдля тих, хто не має vhosts, ймовірно, це ваш nginx.conf або в тому ж каталозі, що і він.

3.location / каталогу в тому ж місці , як 2.

• Ви можете бути більш конкретним, ніж /, але якщо його взагалі не працює, я б рекомендував застосувати це, /а потім, коли його робота буде більш конкретною.

Пам'ятайте - якщо у вас є SSL, це вимагатиме від вас встановити вищезазначене для SSL, serverа locationтакож там, де це може бути (в ідеалі таке ж, як 2. ). Я виявив, що якщо ваш клієнт намагається завантажувати на http, і ви очікуєте, що вони перейдуть 301'd на https, nginx насправді перестане з'єднання перед перенаправленням через те, що файл занадто великий для http-сервера, тому він повинен бути в обох .

Останні коментарі говорять про те, що існує проблема з SSL з новішими версіями nginx, але я на 1.4.6, і все добре :)

Вам потрібно застосувати наступні зміни:

1. Оновіть php.ini(знайдіть потрібний файл ini з phpinfo();) та збільшить post_max_sizeі upload_max_filesizeдо потрібного розміру:

   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. Оновлення Nginx настройки для вашого веб - сайту і додати client_max_body_sizeцінність у вашій location, httpабо serverконтексту.

   location / {
       client_max_body_size 200m;
       ...
   }
   

3. Перезапустіть NginX та PHP-FPM:

   service nginx restart
   service php5-fpm restart
   

ПРИМІТКА: Іноді (в моєму випадку майже кожного разу) вам потрібно вбити php-fpmпроцес, якщо він не оновився командою служби належним чином. Для цього ви можете отримати список процесів ( ps -elf | grep php-fpm) і вбити один за одним ( kill -9 12345) або скористатися наступною командою, щоб зробити це для вас:

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

Перевірте, чи ви встановлюєте директиву client_max_body_size всередині блоку http {}, а не всередині блоку {}. Я встановив його всередині блоку http {} і він працює

Хтось мене виправить, якщо це погано, але я люблю максимально заблокувати все, і якщо у вас є лише одна ціль для завантажень (як це зазвичай буває), то просто націліть свої зміни на цей один файл. Це працює для мене на пакунку 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";
    (...)
}

Нещодавно у мене була подібна проблема, і я з'ясував, що client_max_body_size 0;може вирішити таке питання. Це встановить client_max_body_size без обмежень. Але найкраща практика - покращити свій код, тому не потрібно збільшувати цей ліміт.

Припускаючи, що ви вже встановили client_max_body_size та різні параметри PHP (upload_max_filesize / post_max_size тощо) в інших відповідях, потім перезавантажте або перезавантажте NGINX та PHP без жодного результату, запустіть це ...

nginx -T

Це дасть вам будь-які невирішені помилки у ваших конфігураціях NGINX. У моєму випадку я боровся з помилкою 413 цілий день, перш ніж зрозумів, що в конфігурації NGINX (неправильний шлях до сертів) є деякі інші невирішені помилки SSL, які потрібно виправити. Як тільки я виправив невирішені проблеми, отримані від 'nginx -T', перезавантажив NGINX та EUREKA !! Це і виправило.

Я налаштовую сервер розробників, щоб грати з цим дзеркалом нашого застарілого живого, я використовував Perfect Server - Ubuntu 14.04 (nginx, BIND, MySQL, PHP, Postfix, Dovecot та ISPConfig 3)

Переживши те саме питання, я натрапив на цю посаду, і нічого не вийшло. Я змінив значення у кожному рекомендованому файлі (nginx.conf, ispconfig.vhost, / sites-available / default тощо)

Нарешті, зміна client_max_body_sizeмого /etc/nginx/sites-available/apps.vhostта перезапуск nginx - це те, що зробило трюк. Сподіваємось, це допомагає комусь іншому.

Я зустрічаюся з тією ж проблемою, але я не знайшов нічого спільного з nginx. Я використовую nodejs як резервний сервер, використовую nginx як зворотний проксі, код 413 спрацьовує сервер вузлів. вузол використовують коа- синтаксичний аналіз тіла. koa обмежують довжину, кодовану урленом.

formLimit: межа тіла, що кодується урленом. Якщо тіло в кінцевому підсумку перевищує цю межу, повертається код помилки 413. За замовчуванням - 56 кб.

встановити formLimit на більше може вирішити цю проблему.

Було те саме питання, що client_max_body_sizeдиректива була проігнорована.

Моя дурна помилка полягала в тому, що я помістив файл, всередині /etc/nginx/conf.dякого не закінчився .conf. Nginx не завантажує їх за замовчуванням.

Якщо ви використовуєте Windows версію nginx, ви можете спробувати вбити весь процес nginx і перезапустити його, щоб побачити. У моєму оточенні я зіткнувся з тією ж проблемою, але вирішив це рішення.