Nginx - client_max_body_size не влияет

Ответ 1

Следуя документации nginx, вы можете установить client_max_body_size 20m (или любое значение, которое вам нужно) в следующем контексте:

context: http, server, location

Ответ 2

Крупные загрузки 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. В моем случае я изменил настройку в разделе php.ini File_Uploads, чтобы прочитать:

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. По-видимому, упускать из виду это привело к ограничению загрузки до предела по умолчанию 1M. После внесения связанных изменений вы также захотите перезапустить службы NGINX и PHP FastCGI Process Manager (PHP-FPM). В приведенной выше конфигурации я использую следующие команды:

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

Ответ 3

По состоянию на март 2016, я столкнулся с этой проблемой, пытаясь выполнить POST json через https (из запросов python, а не в том, что это важно).

Хитрость заключается в том, чтобы поставить "client_max_body_size 200M;" по крайней мере в двух местах http {} и server {}:

1. каталог http

• Обычно в /etc/nginx/nginx.conf

2. каталог server в вашем vhost.

• Для пользователей Debian/Ubuntu, которые установили с помощью apt-get (и других менеджеров пакетов дистрибутива, которые по умолчанию устанавливают nginx с vhosts), thats /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, и все хорошо:)

Ответ 4

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

• Обновить 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```
  

• Обновите настройки NginX для вашего сайта и добавьте значение client_max_body_size в контекст location, http или server.

  location / {
      client_max_body_size 200m;
      ...
  }
  

• Перезапустите 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

Ответ 5

Обратите внимание, что вы устанавливаете директиву client_max_body_size внутри блока http {}, а не внутри {} block. Я установил его внутри блока http {}, и он работает

Ответ 6

Кто-то исправит меня, если это плохо, но мне нравится блокировать все как можно больше, и если у вас есть только одна цель для загрузки (как это обычно бывает), тогда просто нацеливайте свои изменения на этот файл. Это работает для меня в пакете 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";
    (...)
}

Ответ 7

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

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

Установите значение FormLimit на большее, чтобы решить эту проблему.

Ответ 8

Предполагая, что вы уже установили client_max_body_size и различные настройки PHP (upload_max_filesize/post_max_size и т.д.) В других ответах, затем перезапустили или перезагрузили NGINX и PHP без какого-либо результата, запустите это...

nginx -T

Это даст вам любые неразрешенные ошибки в ваших конфигах NGINX. В моем случае я боролся с ошибкой 413 в течение всего дня, прежде чем понял, что в конфигурации NGINX есть некоторые другие неразрешенные ошибки SSL (неправильный путь для сертификатов), которые необходимо исправить. После того, как я исправил нерешенные проблемы, я получил от 'nginx -T', перезагрузил NGINX и EUREKA !! Это исправило это.

Ответ 9

Я настраиваю 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 - вот что /etc/nginx/sites-available/apps.vhost. Надеюсь, это поможет кому-то еще.

Ответ 10

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

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

Ответ 11

Недавно у меня была похожая проблема, и я обнаружил, что client_max_body_size 0; может решить такую проблему. Это установит client_max_body_size без ограничений. Но лучшая практика заключается в улучшении вашего кода, поэтому нет необходимости увеличивать этот лимит.

Ответ 12

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