有没有观察过，你的 Nginx 配置里，server监听后有这么一段。

是不是觉得这个default_server没啥用，写或不写都不影响正常的使用。

其实并不是这样，在有些场景下，如果不写，可能会多吃5倍内存。

为什么这么说呢？

当一个 HTTP 请求到达 Nginx 时，它首先会根据请求的目标 IP 和端口，找到对应的监听，再去找对应的server_name，最后请求会到正确的server被处理。

但问题就出在，如果匹配失败，比如没有与请求匹配的server_name,那么就会去找配置了default_server的段。

如果没有单独配置default_server，那么nginx就会配置的第一个server段，这个动作是非常危险的。

比如下面的配置

不匹配 a.com 和 b.com 的请求，都会完整地走第一个 server 块的所有逻辑。

这个所有逻辑可不是小事,它包括了header 缓冲区的分配、所有 set 变量的初始化、location 匹配表的构建、 rewrite 规则的编译和执行、 root、index、error_page 等指令的加载等等。

如果第一个 server 块恰好是整个配置里最复杂的那一个，那么每一个不匹配的请求都会命中。

但实际上，这些请求根本就不是你站点需要处理的请求，可能来自扫描器、爬虫，或者干脆是攻击者的探测流量等。

实际上真的有这么夸张吗，我们模拟测试下。

写一常见的Nginx配置

上面就是模拟真实场景，一个比较复杂的站点，还有一个很简单的站点。由于没有显式指定 default_server，Nginx 会把第一个（复杂的那个）当作默认。

发送5000次不匹配请求

观察内存变化

未添加default_server输出结果

给第二段server加上配置(第二段处理逻辑比较简单)，再次进行压测观察输出结果

从结果能明显看出，加上default_server后，未匹配到的请求全部进入了第二段，第二段处理逻辑较为简单，内存占用显著下降。

由42M下降到9M，将近5倍的量，如果请求量再高一点，这个差值将会非常恐怖。

线上服务面对大量请求，来自扫描器、爬虫、DNS 重绑定攻击、配置错误的请求不可避免。它们一天可能打进来几万次、几十万次。

尝试修改下这个参数，说不定会让你的服务重新起飞。

阅读原文：点击这里​