很多人上线系统后，发现压测一过几千并发，Nginx 就开始顶不住了，动不动就 502 或者响应特别慢。其实大多数时候，并不是 Nginx “不行”，而是配置和环境没跟上。
连接数限制
Nginx 默认 worker_connections 大概就 1024，一个请求占一个连接，这么算下来，单进程能处理的并发就很有限。如果机器是 8 核，你开了 8 个 worker，理论上能跑 8 * 1024 ≈ 8k 并发，但这是理想情况，遇到长连接或者慢请求很快就被占满。
// 简单模拟：假设一个接口里 sleep 了 2 秒
@GetMapping("/demo")
public String demo() throws InterruptedException {
Thread.sleep(2000); // 假装下游服务很慢
return "ok";
}
如果 1000 个请求一齐打过来，这些连接就会被锁住，后面的请求只能排队，Nginx 端看就是“卡死”。
文件描述符（FD）耗尽
Linux 系统默认一个进程能打开的文件句柄数才几千个。每个连接都要占 FD，Nginx 处理连接用的 epoll 也靠 FD。如果 ulimit -n 没调大，再多的 worker_connections 配置都白搭。
# 临时修改
ulimit -n 65535
生产里要写到 limits.conf，不然重启就没了。
上游服务的瓶颈
Nginx 本身是异步非阻塞的，几万并发都没问题。真正扛不住的往往是后面的应用。比如 Tomcat 默认最大线程数才 200，超过就排队。所以你看 Nginx 明明转发了，但后面 Java 应用没响应，用户依旧感觉是挂了。
server:
tomcat:
max-connections: 10000
threads:
max: 800
min-spare: 100
类似的，数据库连接池如果最大连接只有 10 个，也一样会拖死整体。
长连接和慢请求
Nginx 的 keepalive_timeout 默认比较长，如果有很多客户端连上来不走，就会挂着连接占资源。慢请求（比如上传大文件）也会让 worker 卡着。配置合理的 keepalive_timeout、client_body_timeout 很重要。
keepalive_timeout 15;
client_body_timeout 10;
内核参数调优
高并发场景还要看看 Linux 内核的 TCP 参数，比如 net.core.somaxconn、net.ipv4.ip_local_port_range。默认值很保守，端口用完了 Nginx 也没法建立新连接。
# /etc/sysctl.conf
net.core.somaxconn = 65535
net.ipv4.ip_local_port_range = 1024 65000
小结
所以当你说“Nginx 撑不住高并发”，大概率是：
Nginx 本身设计得很强大，核心逻辑几乎不会成为瓶颈。真要抗万级并发，光靠默认配置肯定不行，应用和系统得全链路一起调优才行。
-END-
我为大家打造了一份RPA教程，完全免费：songshuhezi.com/rpa.html
