Nginx从原理到调优：如何真正支撑5万并发连接

1. 50,000并发这个数字，先把口径说清楚

先聊个很多团队都踩过的坑：老板要求"并发数到5万"，开发测出来对不上，测试说压测机已经撑不住了，运维说监控里连接数根本没那么高。最后发现，大家嘴里说的"并发"压根不是一个东西。

我见过太多团队把"并发连接数"和"QPS"混为一谈。Nginx官网那句"单机支持百万并发连接"说的是连接数，是TCP连接建好之后挂在那里的数量；而高并发业务场景里大家真正关心的往往是吞吐，单位时间能处理多少请求。这两个指标在Nginx的世界里差异巨大。

就拿50,000并发这个目标来说，如果5万指的是"同时有多少个TCP连接保持在Nginx上"，那这本身谈不上多极限，一台配置合理的机器完全扛得住；但如果5万指的是"每秒钟要处理5万个请求"，那这叫50,000 QPS，难度完全不是一个量级。这篇文章讲的"50,000并发"，我按互联网行业最常见的口径来定义：同时在线的客户端连接数，以及在这些连接上持续发生的请求流量，也就是一个比较真实的电商大促、抢票或直播弹幕场景。

那50,000并发连接下Nginx要面对什么？假设这些连接里有动态请求也有静态资源，每个连接平均每10秒发起一次请求，那么Nginx每秒要处理的请求数大约是50,000除以10，等于5,000 QPS。这个量级对Nginx本身来说非常轻松，真正的瓶颈在于内存、文件描述符、后端服务吞吐和内核网络参数。很多人一听到5万并发就想着要上多少台机器，实际上过早引入分布式反而是过度设计。

给新手一个基准感受：一台配置合理的Nginx服务器，只要内核参数和配置项调到位，静态文件场景下支撑十几万并发连接是常态，动态请求要看后端聚合能力。所以别被"5万"这个数字唬住，Nginx能处理，前提是你要知道它背后的工作方式，以及把操作系统级别的限制解开。

本文的阅读对象是那些已经会用Nginx做基本反代和静态服务、但遇到高并发场景就心里没底的同学。我会把Nginx能扛高并发的原理拆开讲清楚，再把从系统层到配置层的调优步骤完整走一遍，最后结合压测工具讲怎么验证"真5万"而不是"纸面5万"。

2. 事件驱动模型才是Nginx最核心的武器

2.1 从Apache的"一连接一线程"说起

要理解Nginx为什么能支撑超高并发，得先知道传统服务器是怎么被并发打垮的。Apache经典的prefork模式，来一个连接就fork一个进程去处理，这个进程在那个连接的生命周期内一直占着不放。如果5万连接同时进来，Apache就要创建5万个进程，光进程上下文切换就会把CPU耗尽，内存更是扛不住，每个进程几MB到几十MB，5万乘以几十MB根本不敢算。

改进版的worker模式采用线程池，比进程轻量一些，但本质上还是一连接一线程或者一连接一书签轮询，线程数量一旦上去，上下文切换和锁竞争照样拖垮性能。这个模型更适合连接数少、每个连接处理时间长的场景。

Nginx走的是完全不同的路线。我第一次看Nginx源码里那个ngx_event_accept的处理逻辑时，印象最深的是它一个工作进程能同时管理成千上万个socket，靠的不是创建无数线程，而是事件驱动。

2.2 epoll：内核帮你盯着所有连接

Nginx在Linux上默认使用epoll，这是Linux内核提供的高性能I/O多路复用机制。通俗理解：你有一个前台（Nginx worker进程），接待大厅里有几十万个客人（socket连接）。如果每来一个客人都要前台亲自招待，那前台累死也干不完；epoll相当于给前台配了几十个"事件传感器"，哪个客人招手（数据到达）、哪个客人要结账（连接关闭）、哪个客人进门（新连接），传感器实时汇报，前台只需要一个个处理有事件发生的人，没人找他的时候就休息。

用技术语言说，epoll维护了一个就绪事件列表，Nginx通过epoll_wait批量获取当前有事件发生的文件描述符，然后逐个处理。处理过程里所有I/O都是非阻塞的，读数据时如果内核缓冲区暂时没数据，立刻返回而不是傻等；写数据时如果socket发送缓冲区满了，先登记一个"可写事件"，等缓冲区有空间了内核再来通知。这样worker进程永远不会被某一个慢连接卡住。

对比一下子就清晰了：阻塞式I/O模型下，5万连接可能得几万个线程；事件驱动模型下，几个worker进程就够了。Nginx默认worker_processes通常设置为CPU核心数，16核机器跑16个worker进程，每个进程单线程处理所有连接的事件，这就是5万并发的底气所在。

2.3 accept锁和惊群问题

用了epoll之后，还有一个细节很关键——惊群。多个worker进程都阻塞在epoll_wait上，一个新连接到达时，所有worker都会被唤醒去争抢accept，但最后只有一个能成功，其他进程白白被唤醒一轮，这就是惊群效应。

Nginx老版本用accept_mutex（accept锁）来解决这个问题：多个worker轮流持有锁，只有持锁的worker才会把新连接对应的socket加入自己的epoll监听列表。这样做牺牲了一点点多核并行度，但避免了无谓的进程唤醒开销。Nginx后来引入了EPOLLEXCLUSIVE标志，内核只在等待队列里唤醒一个进程，惊群问题进一步缓解。所以你在新版本Nginx里看到accept_mutex on;，默认开启，一般不用动。

不过这里有个坑：惊群问题主要集中在监听socket上的新连接事件，已经建立的连接上的读写事件本来就会精准分发到对应的worker，不存在惊群。所以不要为了追求极致的并发连接数，盲目把worker_processes调到特别大，超过CPU核心数反而会因为频繁上下文切换降低性能。

3. 你以为瓶颈在Nginx，其实第一道墙是操作系统

很多人在Nginx配置里加了各种优化参数，压测一跑还是大量连接失败，最后发现根本不是Nginx的问题，是Linux内核压根不许你建那么多连接。我在实战中踩过的第一道墙就是文件描述符限制。

3.1 文件描述符和ulimit

Linux里一切皆文件，一个TCP连接就是一个socket文件，对应一个文件描述符（file descriptor，FD）。系统默认单进程能打开的文件描述符数量通常是1024，这意味着你Nginx worker进程默认最多只能同时管理1024个连接——这还谈什么5万并发。

Nginx自己提供了worker_rlimit_nofile指令，建议直接设成65535或者更大：

nginx复制worker_rlimit_nofile 65535;

注意这个指令要放在events块外面，作用是提高Nginx进程的FD上限。但这还不够，因为操作系统层面的ulimit限制如果小于这个值，Nginx启动时就会被约束。所以还得改一下用户级的资源限制，编辑/etc/security/limits.conf：

bash复制* soft nofile 65535
* hard nofile 65535

同理，/etc/sysctl.conf里还有个fs.file-max，这是整个系统能打开的文件描述符总数。虽然现在的发行版一般默认值都挺大，但压测前还是得看一眼：

bash复制sysctl fs.file-max

如果这个值不到10万，建议调大，比如：

bash复制fs.file-max = 120000

修改后执行sysctl -p让配置生效。我见过太多压测报告里"Too many open files"的报错，十有八九就是这三层FD限制没有全部打开。

3.2 端口范围与TIME_WAIT

高并发压测还有一个经典瓶颈：客户端发起大量连接，服务端主动关闭后，socket会进入TIME_WAIT状态，默认要等60秒才彻底释放。压测机上如果端口不够用，新连接就建不起来，表现就是Cannot assign requested address。

服务端Nginx侧也要留意net.ipv4.ip_local_port_range，它决定了本机发起连接时能使用的源端口范围。如果是Nginx反向代理场景，Nginx往后端发起连接也要消耗端口，压测时必须保证这个范围足够宽：

bash复制net.ipv4.ip_local_port_range = 1024 65535

另外两个经常被提及的参数是net.ipv4.tcp_tw_reuse和net.ipv4.tcp_max_tw_buckets：

bash复制net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_max_tw_buckets = 5000

tcp_tw_reuse只对客户端发起连接场景有效，允许复用处于TIME_WAIT状态的连接；tcp_max_tw_buckets用来限制TIME_WAIT状态socket的堆积数量，超过后系统会尽快回收。注意tcp_tw_recycle这个老参数千万不要再开了，它在NAT环境下会导致严重的连接问题，很多老教程还在推荐它，纯属坑人。

3.3 半连接队列和accept队列

TCP建连过程里，服务器端有两个队列：一个是SYN半连接队列（tcp_max_syn_backlog），存放收到SYN但还没完成三次握手的连接；另一个是accept队列（listen的backlog参数），存放已完成握手但还没被应用accept的连接。两个队列的深度直接决定并发建连时是否会丢包。

Nginx默认监听socket的backlog由指令listen后面的backlog参数控制：

nginx复制server {
    listen 80 backlog=65535;
}

内核侧对应设置：

bash复制net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 65535

压测时如果出现大量超时，很可能是backlog满了。注意这里有个细节：somaxconn是内核允许的最大backlog，Nginx配置里写的backlog值超过它也会被截断。所以两边必须同时调大，只调Nginx不调内核，等于白调。

顺带提一个经常被忽略的优化项：net.core.netdev_max_backlog，这是网卡接收队列的长度，高并发且流量大的时候也需要加大：

bash复制net.core.netdev_max_backlog = 65535

系统的网络调优参数非常多，但攻下5万并发不一定每个都要动，先把上面这几个关系到连接建立和文件描述符的关键项调好，成功率就已经很高了。

4. Nginx自身的配置细节决定上限

系统层解开限制之后，回到Nginx的主配置文件nginx.conf。很多人上来就抄各种"高并发配置模板"，但不知道每个参数背后的逻辑，出了问题根本不会调。我把实战中验证过的核心配置逐个拆开讲。

4.1 worker进程与连接数的关系

worker进程的数量设置，黄金法则是等于CPU核心数，而不是越多越好。每个worker是单线程的，多了以后CPU时间片切来切去，反而降低效率：

nginx复制worker_processes auto;
worker_cpu_affinity auto;

worker_cpu_affinity auto把每个worker进程绑定到独立的CPU核心上，进一步减少缓存失效和调度开销。这个在高并发且CPU密集的场景下收益明显。

接下来是events块：

nginx复制events {
    worker_connections 65535;
    multi_accept on;
    use epoll;
}

worker_connections是每个worker进程能同时打开的最大连接数。Nginx总并发连接数的理论值约等于worker_processes * worker_connections，16核机器配65535，理论并发上限就是一百多万。为什么实际达不到？因为还要留一部分连接给Nginx到后端的转发请求，以及文件描述符上限的约束。一般建议worker_connections的值不要超过worker_rlimit_nofile，否则有连接分配出去了但FD不够用。

multi_accept on的意思是每次收到accept事件通知后，尽量把所有待处理的连接一次性全accept掉，而不是一次只处理一个，这样能显著降低高并发下的accept次数。这里还有一个小陷阱：如果连接数特别高且CPU核心数多，multi_accept反而可能导致某个worker瞬间接受的连接过多，造成不均衡。实际使用中我通常还是开着，配合accept_mutex的默认设置基本能平衡。

4.2 sendfile、tcp_nopush与tcp_nodelay

这三个参数是静态文件性能的关键，我很少看到有人把它们讲透。

sendfile on让静态文件直接在内核态从磁盘读到socket，不用经过Nginx进程的内存拷贝，这就是"零拷贝"思想在Nginx里的最直接应用。

tcp_nopush on在Linux上实际对应socket的TCP_CORK选项，作用是把多个小包攒成一个大包再发出去，减少网络报文数量，适合大文件传输。但注意它和tcp_nodelay在语义上是冲突的：tcp_nodelay是禁用Nagle算法，有数据立刻发，适合交互性强的小响应；tcp_nopush是尽肯能凑满包，适合静态大资源。Nginx官方建议静态资源场景两者都开着，实际效果是：大包走tcp_nopush的攒包策略，但首字节还是能尽快发出，两者的作用域不完全重叠。

动态API的反代场景，我更倾向于关闭tcp_nopush、开启tcp_nodelay，换更快的小包响应速度。别照抄别人配置，得看你服务的资源类型。

4.3 keepalive：高并发里最容易忽视的隐形级联

HTTP keepalive是个双刃剑，利用好了连接复用能大幅降低握手开销，用不好就是白占连接数。

先看客户端侧的keepalive：

nginx复制keepalive_timeout 65s;
keepalive_requests 1000;

有些教程把keepalive_timeout调成特别大，觉得连接多挂一会就能少建连。但别忘了，一个连接只要keepalive着，就占用一个FD和一个worker的连接配额。5万并发目标下，如果keepalive_timeout是300秒，那些低频请求的连接会一直占着坑不释放，很快就把连接数顶满，但实际吞吐并不高。我的做法是：面向公网的静态资源服务，keepalive_timeout设到30-60秒即可；后端API反代，keepalive_requests要调大，让单个连接尽量多做几次请求再断。

再看upstream侧的keepalive，这可能是全篇最值钱的一条经验。默认情况下Nginx作为反向代理，每收到一个来自客户端的请求，就会向后端服务器新建一个TCP连接，请求结束后关闭。高并发下这意味着后端要承受巨量短连接，三次握手开销全打在负载上。启用upstream keepalive后，Nginx会维护一个到后端的连接池，反复复用：

nginx复制upstream backend_servers {
    server 10.0.0.11:8080 max_fails=3 fail_timeout=10s;
    server 10.0.0.12:8080 max_fails=3 fail_timeout=10s;
    keepalive 64;
}

location /api/ {
    proxy_pass http://backend_servers;
    proxy_http_version 1.1;
    proxy_set_header Connection "";
}

注意两个关键点：upstream必须开启proxy_http_version 1.1，并且必须把Connection头清空，否则后端不认keepalive，连接用完就断，白配置。keepalive 64指的是每个worker进程保留多少个空闲连接在池子里，16个worker就是最多16×64个复用连接，足够覆盖正常吞吐。

我曾在生产环境碰到过很奇怪的现象：Nginx负载很低，后端Tomcat线程数却逼近上限，大量连接处于TIME_WAIT，最后排查就是upstream keepalive没配。加上之后后端压力肉眼可见地降了一截，这个优化在高并发反代场景里性价比极高，一定要做。

4.4 静态文件缓存与日志裁剪

高并发下还有一个常被忽略的点：日志写入是同步阻塞的。访问量一大，access_log每行都写磁盘，磁盘I/O就成了瓶颈。优化思路有两个：一是把日志级别调低，生产环境用warn及以上；二是用buffer参数把日志攒一批再写：

nginx复制access_log /var/log/nginx/access.log main buffer=64k flush=5s;

这样日志事件凑满64KB或者5秒周期才刷一次盘，性能影响小很多。

静态文件场景强烈建议开open_file_cache，把文件描述符、文件大小、修改时间等元数据缓存起来，避免每次请求都去磁盘stat一遍：

nginx复制open_file_cache max=200000 inactive=20s;
open_file_cache_valid 30s;
open_file_cache_min_uses 2;
open_file_cache_errors on;

max=200000表示最多缓存20万个文件句柄，超过后按LRU淘汰。文件不常变的静态资源服务器，这个缓存的效果非常明显，磁盘I/O减少一半以上不是梦。

5. gzip、缓存和SSL的取舍：做好这步，5万并发才敢说稳定

并发量上了5万以后，你会发现Nginx的工作不光是"转发"和"返回文件"，它还承担着流量整形和协议终结的角色。这一节讲三个在高并发实测中影响很大的配置维度。

5.1 gzip压缩是双刃剑

gzip能大幅减小响应体体积，节省带宽，看起来是好事。但是gzip是CPU密集操作，在高并发实时压缩时CPU占用飙升。5万并发场景下如果后端返回的是大段JSON，开启gzip可能直接把worker进程的CPU打满。

实践经验是这样的：

• API动态请求：建议看响应体大小决定，超过1KB的响应开启压缩收益明显，低于1KB的开压缩反而浪费时间。
• 静态资源：预先用gzip -9级别压缩好文件，直接让Nginx读取 .gz版本，用gzip_static on，Nginx就不再实时压缩了，只是把预压缩文件发出去，CPU耗用几乎为零。静态资源缓存时间设长一点，让CDN和浏览器缓存帮忙扛住大部分请求更划算。

配置示例：

nginx复制gzip on;
gzip_static on;
gzip_comp_level 5;
gzip_min_length 1024;
gzip_types text/plain text/css application/json application/javascript application/xml;

gzip_comp_level 5是性价比比较高的档位，再往上压缩率提升不明显，CPU开销却涨得快。

5.2 SSL终结与session缓存

现在HTTPS基本是标配，但TLS握手是个开销大户，尤其新连接高并发建立时，CPU要做非对称加密计算，这是非常昂贵的操作。

Nginx作为HTTP边缘节点时，可以用ssl_session_cache把SSL会话参数缓存起来，客户端在复用session ID或者TLS 1.3的session ticket时，可以跳过完整的握手流程：

nginx复制ssl_session_cache shared:SSL:20m;
ssl_session_timeout 60m;

这里的20m大概能缓存约20万个session，实测对密集短连接场景的握手性能提升非常明显。

硬件层面如果并发和吞吐要求特别高，可以考虑在Nginx前置加一层SSL卸载设备或者用专门支持异步SSL加速的网卡。但这是成本较高的方案，大多数业务场景优化到session cache和TLS 1.3就已经足够。

5.3 限流和防滥用：越能抗并发，越要防穿透

并发能力提升之后，最怕的就是有人恶意用大流量打穿你。Nginx内置的limit_req和limit_conn模块在高并发场景下是很有用的防护手段。

limit_req用来限制请求速率，经典的令牌桶算法。下面这个配置限制每个IP每秒最多10个请求：

nginx复制limit_req_zone $binary_remote_addr zone=req_per_ip:10m rate=10r/s;

server {
    location /api/ {
        limit_req zone=req_per_ip burst=20 nodelay;
        proxy_pass http://backend_servers;
    }
}

burst=20相当于允许瞬间多放20个请求进桶，nodelay让桶里的请求不排队而是立刻转发，超出部分直接返回503。这个配置对于防止接口被刷很有用，但要留意合理的伸缩余地，别把正常用户流量给误伤了。

limit_conn限制同IP并发连接数：

nginx复制limit_conn_zone $binary_remote_addr zone=conn_per_ip:10m;

server {
    limit_conn conn_per_ip 20;
}

高并发场景下这两个模块的作用不只是"防攻击"，更是保护后端不被打垮的最后一道闸门。即使前端Nginx能扛5万并发，后端数据库往往扛不住，限流是架构中必须存在的一层。

6. 压测那点事：别让JMeter成为你验证路上的最大瓶颈

配置都调整完了，怎么证明你的Nginx真的能扛5万并发？这一节说实测的经验。很多人在这一步翻车，压测机的资源先被打满了，结果误判为Nginx不行。

6.1 确认压测目标并估算资源

压测前先想清楚你要压的是并发连接数，还是QPS。如果目标是5万并发连接，压测机需要用分布式负载生成器，因为单台JMeter默认最多也就撑几千个并发线程，每台负载机还要消耗大量端口和FD。

压测前先看压测机自身资源：

bash复制ulimit -n
sysctl net.ipv4.ip_local_port_range
sysctl net.ipv4.tcp_tw_reuse

压测机的FD上限、端口范围、TIME_WAIT复用，都要照着前面Nginx系统调优的思路同样设置一遍。我见过太多人压测结果不理想，查了半天发现是压力源自己先挂了。

6.2 JMeter里怎么配置和验证并发数

JMeter里线程数设置成5万不等于真实并发就是5万，因为线程启动需要时间，而且每台压测机的端口数是有限资源。正确的做法是使用"步进线程组"（jp@gc - Stepping Thread Group），在几十秒内逐步加压到5万线程，而不是一口气全起。这样既能看清系统在哪个连接数附近开始出现拐点，也不至于把压测机瞬间打爆。

JMeter压测完怎么看：

• Active Threads Over Time监听器能看到实际同时运行的线程数，确认是否真的到了5万。
• Response Times Over Time看响应时间是否随着并发升高而劣化。
• Aggregate Report看Error百分比和吞吐量，Error超过0.1%就要警惕。

另外，响应时间里的超时，别一股脑归因到Nginx。先用ss -s看服务端TCP连接状态分布：

bash复制ss -s
ss state time-wait | wc -l

如果time-wait数量巨大，说明要么keepalive没生效，要么连接生命周期太短。如果服务端存在大量syn_recv状态的连接，说明backlog队列满了或者tcp_tw_reuse之类的参数没调好。

6.3 实测中我踩过的几个"假并发"场景

第一次做5万并发压测时，我盯着JMeter的报告看，明明显示5万并发全部成功，延迟也低得吓人，后来发现压测机和Nginx服务器在同一台物理机上——所有请求都没走网卡，全在回环接口里打转了。压测结果不具备参考价值。压测机必须单独部署，最好跨机器、跨交换机，才能测出真实网络链路。

第二次遇到的坑是加密流量。压测时如果全走HTTPS，JMeter单机本身就成了加解密瓶颈，测出来的数字根本反映不出Nginx的真实水平。正确做法是先压HTTP验证基线，再用HTTPS压出SSL开销下的真实水位。

第三次是响应体太小。如果接口只返回几十字节，那么压测瓶颈几乎永远在满吞吐量之前先打到CPU中断上限或连接数上限，链接建连的耗时占比变得很大，这不能体现业务真实负载。压测数据的请求体、响应体规模，要尽量贴近线上的真实分布。

7. 5万并发之后的瓶颈接力：带宽、后端与架构演进

当Nginx实例真的在压测环境里稳稳扛住了5万并发，很多人会以为大功告成，其实这只是起点。生产环境里局域网的压测结果放到公网，首先要面对的是带宽约束。

做个简单计算：假设平均每个请求响应体是20KB，5万并发下如果每个连接平均每秒产生1个请求，那么每秒就要吐出5万×20KB等于大约1GB流量，折合带宽是8Gbps。普通机房单机给到的带宽一般是几百Mbps到1Gbps，这意味在大响应体场景下，网络带宽先成为瓶颈，Nginx再能扛也白搭。这也是为什么很多高并发架构要引入CDN，把大流量静态资源推到离用户更近的节点，源站只需要处理动态API，流量立刻小一个数量级。

后端服务的处理能力是另一道接力瓶颈。Nginx反代模式下，它的极限远高于大多数业务后端：Tomcat单机可能也就扛个几千QPS，数据库更弱。所以架构演进上，三步走是我个人比较推荐的：

• 第一步：Nginx做静态资源与动态API分离，静态全交给Nginx直接处理，动态才反代到后端。
• 第二步：后端服务做水平扩展，Nginx upstream配置多台后端，用least_conn或ip_hash负载均衡策略分摊流量。
• 第三步：部署多级缓存，Nginx层的proxy_cache缓存热点接口的响应，配合Redis缓存后端数据，把真正的请求打到后端数据库的比例降到最低。

到这一步，你会发现5万并发这个目标其实是被拆解掉的——Nginx只负责扛住连接和边缘流量，真正的业务压力被缓存和后端集群分而治之。高并发从来不是单点软件的性能炫技，而是整个链路里每一环的协同工作。

8. 最后一次压测后的几点体会与扩展思路

配置优化到最后，我能分享的更多是方法论层面的东西。

别迷信单个参数。有一次我看到网上有人把worker_connections调成10万，结果连接数上去了，系统内存全被socket缓冲区吃光。单独调大任何一个数字都是危险的，性能优化必须是一个整体：内核参数、Nginx配置、后端容量、压测方法，四条线同时推进，每一步都要有压测数据支撑。

压测要控制变量。每次只改一个参数，对比前后的吞吐、延迟、错误率变化，才能知道哪个配置真正起了作用。别一次性把十个参数全改了，压测结果变好了你都不知道是哪一步起效的；如果变差了，排查起来更是灾难。

多关注长尾指标。5万并发下平均响应时间可能很低，但P99甚至P999可能已经高得离谱。Nginx日志里记录上游响应时间，配合监控系统做分位数统计，才能真实反映用户体验。有些连接超时、重试增多，平均值是看不出来的。

最后说一句：50,000并发不是目的，稳定地服务好真实用户才是。与其纠结能不能多扛几千个并发，不如多花时间优化业务的响应体大小、缓存命中率和后端查询效率。真遇到大促流量洪峰，教用户的按钮少加载100KB图片，比Nginx多扛5万并发实在得多。祝你们压测顺利，少踩我踩过的坑。