nginx - client_max_body_size не имеет никакого эффекта

Nginx продолжает говорить client intended to send too large body. Google и 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, в соответствии с The 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-е на https, nginx фактически прервет соединение перед перенаправлением из-за того, что файл слишком велик для http-сервера, поэтому он должен быть в обоих .

Последние комментарии предполагают, что с SSL это связано с новыми версиями nginx, но я на 1.4.6 и все хорошо :)

Вам необходимо применить следующие изменения:

1. Update 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процесс, если он не обновлялся командой service должным образом. Для этого вы можете получить список процессов ( 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 {}, а не внутри блока location {}. Я установил его внутри блока 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 !! Это исправило это.

Я настраиваю dev-сервер для игры с тем, что отражает наш устаревший живой, я использовал The 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 запускается сервером узла. Узел использования коа разбирает тело. коа ограничивают длину urlencoded.

formLimit: предел urlencoded тела. Если тело оказывается больше этого предела, возвращается код ошибки 413. По умолчанию 56 КБ.

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

Была та же проблема, что client_max_body_size директива была проигнорирована.

Моя глупая ошибка заключалась в том, что я положил внутрь файл, /etc/nginx/conf.dкоторый не заканчивался .conf. Nginx не будет загружать их по умолчанию.

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