nginx上传文件限制(nginx限制文件大小)

目录：

• 1、Nginx基础篇----虚拟主机、日志、模块、请求限制
• 2、Nginx上传时报413错误
• 3、上传文件失败,具体原因:上传的文件超过大小限制,请上传小于 1024k的文件？
• 4、上传图片过大时nginx报错
• 5、使用 Nginx 限流

Nginx基础篇----虚拟主机、日志、模块、请求限制

在企业中，我们有很多的业务服务A，B，C等等，按照最最传统的财大气粗方式就是在一台机器上搭建一个Nginx，并且一个Nginx只为一个业务进行服务，如下图所示，我们有3个业务服务，我们就在3个机器上搭建3个Nginx，这显然是很浪费资源的一种不合理方式。

  虚拟主机的方式是指，我们在同一个Nginx上运行多套单独服务，而且这些服务是独立的，如下图所示：

  基于主机多IP的方式有两种：

第一步 ：在单网卡上添加多个IP--ip a add ip地址 设备名

第二步 ：我们找到nginx.conf中的http中的include的配置，找到其include的文件路径

第三步 ：找到默认配置文件，进行复制，将server中的listen进行改动，改为ip:port，在这里如果我们要为3个业务服务的话，我们就设置三个.conf的配置文件，每个配置文件中的ip不同即可。

第四步 ：nginx -s stop -c /etc/nginx/nginx.conf

nginx -s表示给nginx的主进程发送信号，停止应用。-c表示启动的时候使用哪个配置文件。

第一步 ：我们找到nginx.conf中的http中的include的配置，找到其include的文件路径

第二步 ：找到默认配置文件，进行复制，将server中的listen 端口进行改动即可，每个配置文件中的端口不同即可。

第三步 ：nginx -tc /etc/nginx/nginx.conf 对刚才修改的配置文件进行语法检查

第四步 ：nginx -c /etc/nginx/nginx.conf 启动nginx

更改server_name ：

  Nginx的日志类型有error.log和access_log两类。error.log用于记录错误类型的日志，access_log记录的是请求访问的相关的日志。Nginx使用了log_format把各种类型的变量进行组织，然后记录到access_log当中去。

  log_format只能配置到http模块下，所以我们看到nginx.conf中，会看到log_format的使用方式如下图所示：

  Nginx的模块分为官方的模块和第三方的模块，我们可以通过命令行nginx -V看到很多的--with-XXXX，这些就是Nginx中的模块。

  编译选项--with-http_stub_status_module，用于展示Nginx当前处理连接的状态。这个模块默认是没有打开的，它必须要用户显示的server和location模块中进行配置。

  我们在nginx.conf中配置好后，通过IP:PORT/mystatus进行访问，会看到以下结果：

该模块使用的比较少，它表示是从目录中随机选取一个主页。语法规则 random_index on | off，默认情况下是random_index off;只能放在location的上下文中。

这个模块也用的不多，它主要用于对http的响应内容作替换。包含了很多用法：

  sub_filter string replacement 默认是不开启的，可以用在http,server,location中,作用是替换html中的字符。

  sub_filter_last_modified on | off，默认是off，可以用在http,server,location中，作用是否阻止response header中写入Last-Modified，防止缓存，默认是off，即防止缓存。

  sub_filter_once on | off，默认是on,可以用在http,server,location中，作用sub_filter指令是执行一次，还是重复执行，默认是只执行一次。

  Nginx中可以对连接频率和请求频率做限制。其中连接频率限制的模块是limit_conn_module，请求频率限制的模块是limit_req_module。

  请求和连接到底有什么区别呢？我们知道HTTP协议是建立在TCP协议之上的，客户端在向服务端发起请求的时候，必须先建立三次握手连接，建立完连接之后才开始发送请求，为了保持这个连接我们使用FIN和ACK，这样就可以在一个连接中多次发起请求，因此我们可以说HTTP请求建立在一次TCP连接基础上，一次TCP请求至少产生一次HTTP请求。

  连接限制的语法：

  定义空间：

  limit_conn_zone key zone=name:size 默认是没有的，只能在http中配置，如果说我们想对用户的IP地址做限制，那么这里的key我们可以配置成$remote_addr，这里的name可以随便命名，size设置大小

  limit_conn zone number;这里的zone必须和上面的limit_conn_zone中的name对应，number表示的是连接数，默认是没有的，可以在http,server,location中配置。

  请求限制的语法：

  定义空间：

  limit_req_zone key zone=name:size rate=rate默认是没有的，只能在http中配置

  limit_req zone name [burst=number] [nodelay];这里的zone必须和上面的limit_req_zone中的name对应，number表示的是连接数，默认是没有的，可以在http,server,location中配置;burst爆发的意思，这个配置的意思是设置一个大小为N的缓冲区，当有大量请求（爆发）过来时，超过了访问频次限制的请求可以先放到这个缓冲区内;nodelay，如果设置，超过访问频次而且缓冲区也满了的时候就会直接返回503，如果没有设置，则所有请求会等待排队.

  $binary_remote_addr是限制同一客户端ip地址,binary_remote_addr和remote_addr其实是一样的，但是binary_remote_addr要更节省空间。1m 可以储存 32000 个并发会话。zone=req_zone:1m表示生成一个大小为1M，名字为req_one的内存区域，用来存储访问的频次信息;rate=1r/s表示允许相同标识的客户端的访问频次，这里限制的是每秒1次，还可以有比如30r/m的。这里我使用abtest来演示一下各种情况：

配置每秒钟最多一次请求：

使用abtest发起请求，设置并发数20，发起20次请求。测试结果，成功1次，失败19次，符合预期：

查看nginx错误日志，图中刚好有19个error记录，而且是被限制了，符合预期：

设置一个大小为3的缓冲区，超过访问频次限制的请求将会放入到缓冲区中：

使用abtest发起请求，设置并发数20，发起20次请求。测试结果，成功4次，失败16次，符合预期，因为第一次成功后，超过了请求限制，放了3个请求到缓冲区中，所以总共成功4个：

查看nginx错误日志，图中刚好有16个error记录，而且是被限制了，符合预期：

设置最大连接数为1：

使用abtest发起请求，设置并发数20，发起20次请求。测试结果，成功20次，失败0次，符合预期：

查看nginx错误日志，无任何错误日志，符合预期。

  nginx的http_access_module模块实现的，相关语法如下图所示：

~表示模式匹配，这里我们表示凡是访问admin.html的请求，阻止180.158.232.219的访问，同时允许所有的IP访问。结果如下图所示：

请求成功：

  是nginx的http_auth_basic_module模块实现的，使用方式可以具体参考 这里不再赘述

  Nginx的基础篇就讲到这里，欢迎大家指正，下一篇文章我将介绍如何使用Nginx作为静态资源Web服务。

Nginx上传时报413错误

使用nginx转发的OwnCloud网盘，在上传大文件的时候出现了 ochttpstatuserrordomain 413 错误。在网上查询了一下资料，发现nginx默认上传大小是1MB，大于1MB的文件就会报413错误。

找到nginx的配置文件，在 server 中或在 server 的 location 配置中，添加 client_max_body_size 1g; ,后面的数字是需要的大小，这里为1g。

然后重启nginx或重新加载nginx配置

上传文件失败,具体原因:上传的文件超过大小限制,请上传小于 1024k的文件？

服务器默认设置没改导致的

NGINX、Tomcat都有相关设置

百度搜一下 上传文件超过1M报错 就知道了，改下参数并重启服务就行了。

上传图片过大时nginx报错

项目用到spring cloud，前端项目使用nginx进行代理，在上传大图片时时间过长，在页面的F1中查看接口状态，发现报500的错误，这是在后台服务中的网关服务的日志中发现报连接后台上传服务超时没有返回，这时去查看网关zuul的配置文件，修改一下相关的时间超时配置。修改后如下，将超时时间适当的配置大一些。

hystrix:

  command:

    default:

      execution:

        isolation:

          thread:

            timeoutInMilliseconds: 300000

ribbon:

  ConnectTimeout: 300000

  ReadTimeout: 300000

修改了如上配置后，在zuul中不报超时的错误了，但是上传大文件的时候还是失败，但是错误变成了504超时，这时发现是nginx配置的超时时间过小导致的，对nginx的配置文件添加相应的超时配置。

#该指令设置与upstream server的连接超时时间

    proxy_connect_timeout 750;

#该指令设置与代理服务器的读超时时间。它决定了nginx会等待多长时间来获得请求的响应。这个时间不是获得整个response的时间，而是两次reading操作的时间

proxy_read_timeout 6000;

    fastcgi_connect_timeout 300;

fastcgi_send_timeout 300;

fastcgi_read_timeout 300;

这两个选项.

        fastcgi_read_timeout是指fastcgi进程向nginx进程发送response的整个过程的超时时间

        fastcgi_send_timeout是指nginx进程向fastcgi进程发送request的整个过程的超时时间

这两个选项默认都是秒(s),可以手动指定为分钟(m),小时(h)等

通过上面的配置之后图片可以正常上传上去，虽然花费的时间较长，但总算是传上去了。

使用 Nginx 限流

Nginx不仅可以做Web服务器、做反向代理、负载均衡，还可以做限流系统。此处我们就Nginx为例，介绍一下如何配置一个限流系统。

Nginx使用的限流算法是漏桶算法。

（1）安装Nginx。

如果你的Linux是Ubuntu或Debian，使用apt-get安装，在命令行中输入以下命令：

如果是CentOS，使用yum安装，在命令行中输入以下命令：

（2）找到Nginx所使用的配置文件所在的位置。在Ubuntu和Debian是在如下位置：

而CentOS则是在如下位置：

（3）在http块中，配置基础的限流配置：

其中4到8行定义的是一个服务器接口。而第2行和第6行配合完成了一个限流设置，下面解释一下这两行做的事情：

limit_req_zone命令在Nginx的配置文件中专门用于定义限流，它必须被放在http块中，否则无法生效，因为该命令只在http中被定义。

该字段包含三个参数：

第一个参数，就是键（key），即值$binary_remote_addr所在的位置，它代表的是我们的限流系统限制请求所用的键。

此处，我们使用了$binary_remote_addr，它是Nginx内置的一个值，代表的是客户端的IP地址的二进制表示。因此换言之，我们的示例配置，是希望限流系统以客户端的IP地址为键进行限流。

对Nginx有经验的读者可能还知道有一个Nginx内置值为binary_remote_addr是Nginx的社区推荐用值，因为它是二进制表达，占用的空间一般比字符串表达的$remote_addr要短一些，在寸土寸金的限流系统中尤为重要。

第二个参数是限流配置的共享内存占用（zone）。为了性能优势，Nginx将限流配置放在共享内存中，供所有Nginx的进程使用，因为它占用的是内存，所以我们希望开发者能够指定一个合理的、既不浪费又能存储足够信息的空间大小。根据实践经验，1MB的空间可以储存16000个IP地址。

该参数的语法是用冒号隔开的两个部分，第一部分是给该部分申请的内存一个名字，第二部分是我们希望申请的内存大小。

因此，在该声明中，我们声明了一个名叫mylimit（我的限制）的内存空间，然后它的大小是10M，即可以存储160000个IP地址，对于实验来说足够了。

第三个配置就是访问速率（rate）了，格式是用左斜杠隔开的请求数和时间单位。这里的访问速率就是最大速率，因此10r/s就是每秒10个请求。通过这台Nginx服务器访问后端服务器的请求速率无法超过每秒10个请求。

注意到第5行声明了一个资源位置/test/，因此我们第6行的配置就是针对这个资源的，通俗地说，我们在第6行的配置是针对特定API的，这个API就是路径为/test/的API，而其真正路径就是第8行声明的 。注意，这个URL是不存在的，实际操作中，读者需要将它换成你已经开发好的业务逻辑所在的位置，Nginx在这里的作用只是一个反向代理，它自己本身没有资源。

第6行中，我们使用limit_req命令，声明该API需要一个限流配置，而该限流配置所在位置（zone）就是mylimit。

这样一来，所有发往该API的请求会先读到第6行的限流配置，然后根据该限流配置mylimit的名称找到声明在第2行的参数，然后决定该请求是否应该被拒绝。

但是这样还不够。不要忘了，Nginx使用的漏桶算法，不是时间窗口算法，我们前文介绍中说过，漏桶算法是有两个参数可以配置的！

（4）配置峰值。Nginx漏桶算法的峰值属性在API中设置。参数名为burst。如下：

在第6行中，我们只需要在声明limit_req的同时，指定burst就可以了，此处我们指定burst为20，即漏桶算法中我们的“桶”最多可以接受20个请求。

这样一个Nginx的限流系统就配置完毕了，但实际操作中，我们还可能需要很多别的功能，下面笔者就介绍几个很有用的配置技巧。

相对于传统的漏桶算法慢吞吞地转发请求的缺陷，Nginx实现了一种漏桶算法的优化版，允许开发者指定快速转发，而且还不影响正常的限流功能。开发者只需要在指定limit_req的一行中指定burst之后指定另一个参数nodelay，就可以在请求总数没有超过burst指定值的情况下，迅速转发所有请求了。如下所示：

您可能会担忧：这种情况下，会不会出现所有请求都被快速转发，然后接下来又有没有超过burst数量的请求出现，再次被快速转发，就好像固定窗口算法的漏洞一样，从而超过我们本来希望它能限制到的上限数量呢？答案是不会。Nginx的快速转发是这样实现的：

举例而言，配置如上所示，假如在某个瞬时有25个请求进入系统，Nginx会先转发20个（或21个，取决于瞬时情况），然后拒绝剩下的4个请求，并将当前桶中数量标为0，然后接下来的每100毫秒，缓慢恢复1个空位。

这样我们可以看到，Nginx既做到了快速转发消息，又不会让后端服务器承担过多的流量。

限流系统会提前拒绝请求，因此，我们在业务服务器上是肯定看不到这些请求的。假如我们收到一个报告说某用户在使用网站的时候出现错误，但是我们在业务服务器上又找不到相关的日志，我们如何确定是不是限流造成的呢？

只有限流系统的日志才能说明问题。因此，我们需要Nginx打印出它拒绝掉的请求的信息。但同时，Nginx打印的限流日志默认是错误（error），如果我们设置了一个基于日志错误扫描的警报，它扫到的限流错误，真的是我们希望给自己发警报的情况吗？

配置请求的位置就在资源中，使用的命令是limit_req_log_level，如下：

在第7行中，我们将Nginx的日志改为了警告（warn）。

限流的HTTP标准响应状态码是429，但是如果读者拿上述的配置文件直接去测试，会发现Nginx返回的是503（服务不可用）。到底应该返回什么状态码，是一个偏程序哲学的问题，此处我们不讨论，我们只讨论：如何让Nginx返回我们指定的状态码？

答案也是在同一个资源中，它的配置命令是limit_req_status，然后我们指定它为429即可：

除了以上功能以外，Nginx还支持很多复杂先进的限流功能，可以访问 作进一步的了解。