如何解决nginx上传大文件的限制

通过设置nginx的client_max_body_size解决nginx+php上传大文件的问题：

用nginx来做webserver的时，上传大文件时需要特别注意client_max_body_size这个参数,否则会中断在nginx的请求中,在php中是无法记录到访问的

一般上传大文件流程：

首先修改phpini文件：

　　file_uploads on 是否允许通过HTTP上传文件的开关。默认为ON即是开

upload_tmp_dir – 文件上传至服务器上存储临时文件的地方，如果没指定就会用系统默认的临时文件夹

upload_max_filesize 8m 望文生意，即允许上传文件大小的最大值。默认为2M

post_max_size 8m 指通过表单POST给PHP的所能接收的最大值，包括表单里的所有值。默认为8M

　　一般来说，设置好上述四个参数后，在网络正常的情况下，上传<=8M的文件是不成问题

但如果要上传>8M的大文件的话，只设置上述四项还不一定能行的通。除非你的网络真有100M/S的上传高速，否则你还得继续设置下面的参数。

　　max_execution_time 600 每个PHP页面运行的最大时间值(秒)，默认30秒

max_input_time 600 每个PHP页面接收数据所需的最大时间，默认60秒

memory_limit 8m 每个PHP页面所吃掉的最大内存，默认8M

　　webserver用的是nginx，在nginx的conf中添加了一个参数：

默认是1M，需要增大的话。

在nginxconf中增加一句

　　client_max_body_size 30m;

　　重启即可

30m表示最大上传30M，需要多大设置多大。

问题：项目进行了前后端分离，同一台服务器下 后台使用docker 进行部署，并使用Nginx 进行代理访问后台，结果上传30M 文件用了1分钟，实际上10秒左右就可以了。

刚开始以为是 client_max_body_size proxy_send_timeout proxy_read_timeout 的问题，因为上传速度很快，但是就是在上传成功后，一直在等待服务器的响应。所以一开始就都在这个问题上纠结耗费挺多时间。

后面同事说是 proxy_pass http://ht-api:9001; 的问题,注意这个代理地址里面的这个 ht-api 这个其实是我部署docker 的容器名称，了解docker 的都知道，docker 容器在同一个bridge网络下可以通过名称进行访问的，当时我就觉得这个也相当于内网的访问的呀，并没有再经过其他网络层了。

说白还是对docker 不了解后面是更换了 proxy_pass http://1271703:9001; 容器的虚拟IP地址,才真正解决了问题。

有哪位大佬可以解释下这个问题么？

不能上传成功的原因大概有以下几种：

1、目录上传权限不够。

2、程序本身漏洞导致，或程序不完整导致。

3、操作系统问题。

检测目录权限

当 提示上传失败的时候，我首先检测的是文件权限是否足够。经过检测，文件夹的权限是755表示已经足够，并且已经重新创建了文件夹并赋予最高权限，依然 没有解决该问题，接着检测用户组权限是否足够，通过检测也没有发现任何的问题，因此文件夹权限导致不能正常上传的可能性被排除。

网站程序完整性

接着检测网站程序的完整性，发现十多个网站都不能正常上传，于是排除了网站程序完整性导致上传失败的可能性。

操作系统问题

于是检测 WEB NGINX 服务器，将上传文件夹的可执行权限开放，但任然不能成功上传。此时，忽然想起了之前配置过 phpini 配置文 档，将 open_basedir 配置成了网站程序所在根目录 /htdocs，于是将该行代码注释掉，之后便成功的上传了，问题被解决掉。但是， 这样做放弃了安全性，有些舍不得。

通过以下方法，不仅让安全性提高，也解决了上传失败的问题：

phpini 中的open_basedir 表示：php程序执行限制在了指定的目录中，这样可以限制入侵者继续提权到操作系统，安全性有更一步的保障。其 中 upload_tmp_dir 表示的是文件上传临时目录，如果设置了 open_basedir 参数，那么 upload_tmp_dir 必须 配置，否则文件上传将不能成功。

总结：遇到不能上传，表示相当棘手。需要从上传的类型、的尺寸、文件夹权限、程序完整性到最后 的系统环境一一分析，遇到问题不要焦急，相信经过透彻的分析与测试，问题总会被解决掉。本文最终解决方法就有两个，注释 open_basedir 该行 代码就能解决问题，如果配置了 open_basedir 那么需要设定文件上传临时目录，最后笔者将 upload_tmp_dir 设定 为 /tmp 后，就可以成功上传了！

使用springmvc做了一个文件上传的功能，上传到nginx目录下的一个文件夹，但是通过目录访问的时候却报403的错误

去服务器查看了一下文件的权限，发现没有可读权限，于是定位了问题，上传的文件全都没有可读权限。

网上查阅资料发现，linux默认umask为022，对应权限为755，其它用户可读可执行。可以 vim /etc/profile ，搜索umusk关键字查看

而tomcat8默认umask为027，对应权限为750，也就是说其它用户连可读的权限都没有。

可打开catalinash文件，搜索umask查看。

在catalinash文件的开篇可以看到

于是问题有了答案

登录到服务器，进入到tomcat的bin目录下

可以看到

接下来重启tomcat，重新上传即可香油可读权限。

解决办法

location ~ php$ {

root /var/www/html/public;

client_max_body_size 50M;

client_body_temp_path /tmp;

fastcgi_pass 127001:9000;

fastcgi_index indexphp;

fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

include fastcgi_params;

}

附：不要找了，网上说的很多我都试过!一直提示Firebug 达到了 Post 请求大小限制

修改PHPini中post_max_size upload_max_filesize max_execution_time max_input_time

打开phpini文件，修改完毕后重启服务器。测试下上传文件。。。。(嘻嘻，是不是传上了很大的文件)

1、文件上传时存放文件的临时目录。必须是 PHP 进程所有者用户可写的目录。如果未指定则 PHP 使用系统默认值phpini文件中upload_tmp_dir用来说明PHP上传的文件放置的临时目录。

要想上传文件，得保证服务器没有关闭临时文件和有对文件夹的写权限

2、max_execution_time

变量max_execution_time设置了在强制终止脚本前PHP等待脚本执行完毕的时间，此时间以秒计算。当脚本进入了一个无限循环状态 时此变量非常有用。然而，当存在一个需要很长时间完成的合法活动时(例如上传大型文件)，这项功能也会导致操作失败。在这样的情况下必须考虑将此变量值增 加，以避免PHP在脚本正在执行某些重要过程的时候将脚本关闭。

修改为：max_execution_time =800

3、file_uploads = On(原来问开就不用设置了)

4、upload_max_filesize =2M修改为800M

5、同表单提交相关的一个变量是post_max_size，它将控制在采用POST方法进行一次表单提交中PHP所能够接收的最大数据量。似乎不大 可能需要将默认的8 MB改得更大。相反，应当适当将其降到更为实际的数值。但如果希望使用PHP文件上传功能，则需要将此值改为比upload_max_filesize还 要大。

也修改为：post_max_size =900M

6、max_input_time

此变量可以以秒为单位对通过POST、GET以及PUT方式接收数据时间进行限制。如果应用程序所运行环境处在低速链路上，则需要增加此值以适应接收数据所需的更多时间

修改为：max_input_time =900

7、memory_limit =10M

为了避免正在运行的脚本大量使用系统可用内存，PHP允许定义内存使用限额。通过memory_limit变量来指定单个脚本程序可以使用的最大内存容量

变量memory_limit的值(不要超出服务器内寸最大值)

修改为：memory_limit =128M