nginx - client_max_body_size не имеет никакого эффекта - PullRequest
179 голосов
/ 13 января 2010

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 установлены соответственно).

Ответы [ 12 ]

121 голосов
/ 17 февраля 2012

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

context: http, server, location
88 голосов
/ 16 января 2013

Большие загрузки 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, согласно Идеальный сервер ), вам нужно будет управлять этими записями в нескольких отдельных файлах. Если ваша конфигурация аналогична конфигурации в пошаговой настройке, конфигурационные файлы 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
56 голосов
/ 04 марта 2016

По состоянию на Март 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 по умолчанию), то есть /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 и все хорошо:)

20 голосов
/ 02 ноября 2014

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

  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 процесс, если он не обновлялся командой service должным образом. Для этого вы можете получить список процессов (ps -elf | grep php-fpm) и убить одного за другим (kill -9 12345) или использовать следующую команду, чтобы сделать это за вас:

ps -elf | grep php-fpm | grep -v grep | awk '{ print $4 }' | xargs kill -9
11 голосов
/ 12 сентября 2011

Пожалуйста, посмотрите, устанавливаете ли вы директиву client_max_body_size внутри блока http {}, а не внутри блока location {}. Я установил его внутри блока http {}, и он работает

10 голосов
/ 16 мая 2014

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

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

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

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

2 голосов
/ 24 июля 2018

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

2 голосов
/ 09 июля 2018

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

nginx -T

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

0 голосов
/ 13 мая 2019

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...