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设置为20m（或所需的任何值）：

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设置一致。就我而言，我将php.ini的File_Uploads部分中的设置更改为：

upload_max_filesize = 200M

注意：如果要管理ISPconfig 3设置（根据The Perfect Server，我的设置在CentOS 6.3上），则需要在几个单独的文件中管理这些条目。如果您的配置与逐步设置中的配置类似，则需要修改的NGINX conf文件位于以下位置：

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

我的php.ini文件位于此处：

/etc/php.ini

我继续忽略了nginx.conf文件中的http {}块。显然，忽略此限制将上传限制为1M默认限制。进行相关更改后，您还需要确保重新启动NGINX和PHP FastCGI流程管理器（PHP-FPM）服务。在以上配置中，我使用以下命令：

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

从2016年3月开始，我遇到了这个问题，试图通过https（从python请求发出json来发布json，并不重要）。

诀窍是将“ client_max_body_size 200M”http {}server {}放进去。至少在两个地方 和：

1.该http目录

• 通常在 /etc/nginx/nginx.conf

2.server虚拟主机中的目录。

• 对于通过apt-get安装的Debian / Ubuntu用户（以及默认情况下使用vhost安装nginx的其他发行版软件包管理器）而言，多数民众赞成/etc/nginx/sites-available/mysite.com在没有虚拟主机的情况下，可能是您的nginx.conf或与之位于同一目录中。

3.该location /目录与2.相同。

• 您可以比更加具体/，但是如果它根本不起作用，我建议将此方法应用于/，然后使其更具体。

记住 -如果你有SSL，这将需要您设置上述供SSL server和location也可以是任何地方（最好是同2）。我发现，如果您的客户端尝试在http上上传，并且您希望他们将301链接到https，则由于文件对于http服务器而言太大，nginx实际上会在重定向之前删除连接，因此必须在两个。

最近的评论表明，在使用较新的nginx版本的SSL上存在此问题，但我使用的是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

请查看您是否在http {}块内而不是location {}块内设置client_max_body_size指令。我已经将其设置在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获得了！这样就解决了。

我正在设置一个开发服务器以与我们过时的实时服务器进行镜像，我使用了完美服务器-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解析正文。koa限制urlencoded长度。

formLimit：urlencode主体的限制。如果主体最终大于此限制，则会返回413错误代码。默认值为56kb。

将formLimit设置为更大可以解决此问题。

遇到与client_max_body_size忽略指令相同的问题。

我的愚蠢错误是，我在/etc/nginx/conf.d其中放了一个不以结尾的文件.conf。Nginx默认不会加载它们。

如果您使用的是Windows版本的nginx，则可以尝试杀死所有nginx进程并重新启动以查看。我在我的环境中遇到了相同的问题，但是使用此解决方案解决了该问题。