1. 优化前必须想清楚的事你的Nginx到底慢在哪接手OpenEuler系统上的Nginx性能调优很多人第一反应就是去改配置、加参数我在实际项目里见过太多这种操作。某次线上压测一位同事直接把worker_processes改成128结果负载不降反升CPU在中断处理上烧掉一大半——这事儿说明一个道理调优前提是定位瓶颈不是堆配置。我需要先明确一个概念Nginx性能优化不是单点问题。它涉及系统内核参数、Nginx自身配置、后端服务处理能力、网络链路质量四个层面。你在OpenEuler上装好Nginx、能跑通业务这只是起点离“高性能”还差着十万八千里。1.1 先做压测画出性能基线动任何配置之前先花半小时测出当前系统的基准数据。我推荐的压测工具是wrk或者ab注意压测机和Nginx服务器要分开部署否则压测请求本身会消耗被测试机的CPU和网络资源数据完全失真。我常用的压测命令是wrk -t8 -c100 -d60s --latency http://your-server-ip/test.html重点看三个指标QPS每秒请求数、平均延迟、P99延迟。压测完成后记录一份基线数据后续每改一个参数就重测一次对比数据变化。没有基线的调优等于闭着眼睛开车。1.2 看清硬件底子再定策略OpenEuler系统跑的机器配置千差万别。先执行lscpu看核数、free -h看内存、df -h看磁盘类型再用iostat确认磁盘IO能力。我遇到过一台机器磁盘IO能力弱静态文件读取直接成为瓶颈这时候怎么调Nginx参数都白搭只能上缓存或者换存储。CPU核数是Nginx worker进程数配置的核心依据不是随便填的数字。内存大小决定你能开多大的文件缓存、多长的keepalive连接池。磁盘类型决定静态文件的高性能策略——SSD和机械盘的优化方向完全不同。把这些信息记在纸上心里有数再动手。2. OpenEuler系统底层调优内核参数决定天花板很多人调Nginx只看nginx.conf忽略了操作系统层面。实际上大量连接卡住、TIME_WAIT堆积、文件句柄耗尽这些问题根源都在内核参数。OpenEuler基于Linux内核参数体系和其他主流发行版基本一致但有几个默认值需要特别留意。2.1 文件句柄限制连接数上限的隐形阀门Nginx处理每个连接都要占用一个文件句柄file descriptor系统默认的1024上限意味着你的Nginx最多同时处理几百个连接。我在生产环境踩过这个坑——压测一上量日志里全是“too many open files”Nginx直接拒绝服务。调整分两步。第一步改系统级限制编辑/etc/security/limits.conf追加* soft nofile 65535 * hard nofile 65535第二步在Nginx配置里同步提升worker进程的句柄上限worker_rlimit_nofile 65535;这里多说一句worker_rlimit_nofile的值要略小于系统nofile限制否则Nginx启动时会报错。改完必须重启Nginx进程才生效不是reload。2.2 TCP栈参数突破连接和端口的限制高并发场景下服务器要处理大量短连接。默认的TCP参数往往不够用我常用的内核参数调整如下写入/etc/sysctl.confnet.ipv4.tcp_tw_reuse 1 net.ipv4.tcp_tw_recycle 0 net.ipv4.tcp_fin_timeout 30 net.ipv4.ip_local_port_range 1024 65535 net.core.somaxconn 65535 net.core.netdev_max_backlog 65535逐条解释背后的逻辑tcp_tw_reuse1允许客户端复用TIME_WAIT状态的连接。压测时大量短连接会导致TIME_WAIT堆积连接数一多端口就被占满了。但注意tcp_tw_recycle在较新的内核里已经废弃开启会导致NAT环境连接异常务必设置为0。ip_local_port_range扩大本地端口范围避免端口耗尽。默认值经常从32768开始压测时成千上万的外部连接打进来本地端口很快被耗光。somaxconn和netdev_max_backlog分别控制TCP连接队列长度和网卡接收队列长度高并发下默认值128的somaxconn会让accept队列溢出表现是客户端连接超时或重置。改完之后执行sysctl -p生效。这个环节我在多个项目上验证过效果立竿见影压测时TIME_WAIT堆积导致连接失败的问题基本消失。2.3 CPU亲和性和网卡多队列让中断分摊出去Nginx默认情况下内核会把网卡中断集中丢给某一个CPU核心处理导致单个核心满载、其他核心闲着。这种现象在单队列网卡上尤其明显。解决方法有两个方向。一个是设置worker_cpu_affinity让每个Nginx worker进程绑定到固定的CPU核心减少进程在核心间切换的开销。配置方式是在nginx.conf中指定worker_processes 4; worker_cpu_affinity 0001 0010 0100 1000;这里四个掩码分别对应前四个CPU核心。我的经验是多核机器上绑定CPU能减少约10%的开销性能损耗主要来自上下文切换。另一个方向是网卡多队列。检查网卡是否支持RSSReceive Side Scalingethtool -l eth0如果Combined队列数大于等于CPU核数就用ethtool -L eth0 combined N把队列数设置为CPU核数让各队列的中断分散到不同核心。开启RPSReceive Packet Steering也能在软件层面分摊软中断处理但配置相对复杂生产环境看需求选择。3. Nginx配置层性能调优参数背后是取舍系统层改完真正的重头戏在Nginx配置。这个环节我不建议直接抄网上的“最佳配置”因为每个业务场景的模型不同——静态文件服务和反向代理的优化方向差异很大必须先搞清楚自己属于哪一种。3.1 worker进程数和连接数不是越大越好worker_processes最稳妥的设置是等于CPU核心数。早些年有观点说设为核数的两倍更好实际压测表明Nginx是事件驱动模型worker进程数超过核数反而增加上下文切换开销收益为负。我常用的设置方案worker_processes auto; worker_cpu_affinity auto;OpenEuler上Nginx支持auto参数自动检测核数配置更省心。如果机器还跑着其他核心服务建议手动设置为核数-1给系统调度留出余地。worker_connections指的是每个worker进程能同时打开的最大连接数Nginx官方建议公式是events { worker_connections 10240; use epoll; multi_accept on; }理论上最大并发连接数 worker_processes × worker_connections前提是系统文件句柄上限足够。use epoll是Linux高并发场景下最有效的事件驱动模型OpenEuler默认支持。multi_accept on让worker进程一次性接受所有新连接而不是一个一个来压测下吞吐能提升不少。这里有个细节worker_connections不是随便拉高就行的。每个连接背后都有内存开销连接数拉满而业务处理跟不上内存直接告急。我用压测的方式逐步调整比如先设10240、压测观察内存和延迟再决定要不要上调。3.2 静态文件处理sendfile和open_file_cache是主角如果业务以静态文件为主Nginx的静态文件处理能力通常直接决定性能上限。核心配置如下sendfile on; tcp_nopush on; tcp_nodelay on; keepalive_timeout 65;sendfile开启后Nginx直接从磁盘到网卡传输文件省去用户态和内核态之间的数据拷贝。这个过程可以类比成快递直发——不经过中转站时间自然缩短。open_file_cache是很多人忽略的参数它缓存文件元数据路径、大小、修改时间减少重复打开文件的开销open_file_cache max10000 inactive20s; open_file_cache_valid 30s; open_file_cache_min_uses 2; open_file_cache_errors on;这几个参数的含义分别是缓存最多10000个文件信息20秒内未被访问的条目淘汰每30秒检查一次缓存条目是否过期文件被访问2次以上才缓存。这部分对高流量静态资源站点效果特别明显我在一个图片服务上实测配置后CPU占用率下降了约30%。3.3 gzip压缩带宽换CPU还能提升首屏速度带宽小的场景开启gzip能让传输体积缩小60%-80%尤其对文本类资源效果显著但压缩消耗CPU需要在两者之间平衡。gzip on; gzip_comp_level 5; gzip_min_length 1k; gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xmlrss image/svgxml;gzip_comp_level是最值得注意的参数5是性能和压缩率的平衡点6以上压缩率提升不明显CPU消耗却成倍增加。gzip_min_length 1k是防止压缩小文件——小于1KB的文件压缩后体积反而更大得不偿失。另外如果客户端通过代理访问还需要在gzip_http_version 1.1和Vary头方面测试确认否则可能出现压缩不生效或重复压缩的问题。3.4 连接超时和keepalive连接复用大幅提升吞吐Nginx处理HTTP短连接时每次请求都要经历TCP三次握手和四次挥手连接建立和释放的耗时占比很重。开启keepalive让客户端复用TCP连接是提升吞吐性价比最高的操作之一。keepalive_timeout 65; keepalive_requests 1000;keepalive_timeout 65是服务端关闭空闲连接前的等待时间单位是秒。这个值太小连接被频繁关闭复用率低太大则占用文件句柄资源timeout单位是秒65是一个常用平衡点。keepalive_requests是单条连接上最多能处理的请求数默认100不够用高并发场景建议提升到1000左右。连接被复用越充分握手次数越少CPU开销越小。这个参数在压测中的提升效果经常会让第一次接触的人惊讶。4. 反向代理场景优化upstream配置不能照抄默认值如果Nginx承担的是反向代理角色性能瓶颈往往不在Nginx本身而在Nginx和后端服务之间的连接管理、超时控制和负载均衡策略。这块的优化空间非常大我踩过的坑也最多。4.1 upstream keepalive连接池让后端喘口气很多人在upstream配置里只写几个server地址然后就不管了。默认情况下Nginx每个请求都会向上游重新建立TCP连接压测时后端服务器被握手请求淹没表现为CPU飙升但业务处理量却不高。正确的做法是配置upstream连接池。首先在http块内设置upstream backend { server 10.0.0.1:8080 weight3 max_fails2 fail_timeout10s; server 10.0.0.2:8080 weight2 max_fails2 fail_timeout10s; keepalive 32; }然后在location里协调好请求头location /api/ { proxy_pass http://backend; proxy_http_version 1.1; proxy_set_header Connection ; }第proxy_http_version 1.1是关键keepalive需要HTTP/1.1协议支持。proxy_set_header Connection 是清空Connection头让上游连接保持复用。keepalive 32表示每个worker进程缓存32个上游连接。这个值不用太大连接池太大占内存、太小缓存命中率低32在绝大多数场景都够用。配置完成后后端服务的CPU占用会明显下降因为不再频繁创建和销毁TCP连接。4.2 超时重试和负载均衡策略区分业务场景反向代理场景下超时设置直接影响用户体验和服务器压力。四个关键超时参数含义容易混淆但实际分工明确proxy_connect_timeout 5s; proxy_read_timeout 30s; proxy_send_timeout 30s;proxy_connect_timeout是Nginx和后端建立连接的超时时间太短容易在高峰时报504proxy_read_timeout是两次读操作之间的间隔超时不是总耗时上限这个很多人理解错proxy_send_timeout类似是写操作间隔超时。负载均衡策略方面默认是轮询round-robin后端服务能力不一致时需要按权重调整weight参数。least_conn策略适合上游服务处理能力不均的场景会把请求分发给当前连接数最少的服务器。我处理高并发接口时还会加一层主动健康检查。Nginx自带的max_fails和fail_timeout是被动检查——请求失败次数超阈值后标记该服务器为不可用。这块建议配合upstream块的zone指令在主备切换和故障隔离时体验会好很多。4.3 SSL性能优化如果走HTTPS这步是最大的性能杠杆越来越多的业务全站HTTPS但SSL握手开销远超很多人的预期。压测时经常看到HTTP跑10万QPS的机器加了HTTPS直接掉到2万。优化SSL性能是所有使用HTTPS业务的重中之重。ssl_protocols TLSv1.2 TLSv1.3; ssl_session_cache shared:SSL:10m; ssl_session_timeout 10m; ssl_buffer_size 4k; ssl_session_tickets on;ssl_session_cache是SSL会话缓存分布式环境中推荐共享缓存10m可以缓存大约几万个会话。会话复用后客户端在缓存期间内重新连接时跳过完整握手直接把握手时间省掉。ssl_session_timeout 10m控制会话有效期。太短则缓存命中率低、加速效果不明显太长则存在安全风险。10-30分钟是常用区间。ssl_buffer_size 4k控制SSL发送数据大小。改为4k可以减少每条记录的填充开销在响应体较小的API场景里提升明显。另外如果证书链完整、后端能响应OCSP请求一定要开启ssl_stapling on这会把证书状态验证从客户端负担转移到服务端减少一次网络往返。5. 压测复盘与问题排查实战记参数改完不算结束我的习惯是再跑一轮完整压测对比基线和调优后的数据。有次在OpenEuler系统上做优化基线QPS 3万调优后跑到7.5万延迟还降了一半。但这个数字不是凭空来的——中间经历了几轮问题和调整。5.1 三个高频问题速查表现象可能原因排查方法解决措施连接数一高就报too many open files文件句柄限制未调ulimit -n、cat /proc/sys/fs/file-max调limits.conf和worker_rlimit_nofile压测大量TIME_WAIT状态连接TCP栈参数不合适netstat -an | grep TIME_WAIT | wc -l开启tcp_tw_reuse、调小tcp_fin_timeoutworker进程CPU占用不均CPU亲和性未设top按1查看各核使用率配置worker_cpu_affinityQPS提不上去、延迟忽高忽低keepalive未开启抓包确认是否有频繁TCP握手配置upstream keepalive偶发502/504错误后端超时或连接池耗尽查error.log、后端日志调proxy_connect_timeout、加大keepalive连接池这个表是我踩坑的浓缩版建议收藏。遇到问题先查表能少走很多弯路。5.2 压测过程中的两次教训第一次教训是压测目标接口选择失误。我当时压的是PHP动态页面结果QPS上不去调整各种Nginx参数都无效。后来发现瓶颈在PHP-FPM进程数太低Nginx配置怎么改都白搭。性能调优一定要先确认瓶颈层级不要只盯着Nginx这一层。第二次教训是keepalive配置了但没生效。配置后重新压测发现后端连接的创建和销毁依然频繁。排查发现我写的是proxy_set_header Connection close;直接把keepalive废掉了。改成proxy_set_header Connection ;才恢复正常。这里特别提醒空字符串必须双引号包裹写成不设值或各版本格式不一致效果完全不同。5.3 优化效果的复盘逻辑优化后的压测数据需要多维度对比。除了QPS和延迟我还会关注以下几个方面压测期间用top观察CPU使用率分布用户态、内核态、软中断占比用vmstat看上下文切换次数cs字段用ss -s看连接状态分布。QPS上去了但上下文切换次数飙升说明进程调度成为新瓶颈CPU大部分消耗在软中断上说明网卡队列或驱动需要调整。产出对比报告时我会把基线、优化一版、二版的数据放一起每一版标明改了哪些参数、数据变化多少。这样做的好处是后续线上出问题时能通过对比回溯是哪次变更引发的问题定位效率高很多。6. 一个完整的可参考配置模板写到这里我把前面所有内容整合成一份可落地的Nginx核心配置。直接抄这个模板可以应付大多数业务场景但生产环境务必根据你的实际业务调整。user nginx; worker_processes auto; worker_rlimit_nofile 65535; events { use epoll; worker_connections 10240; multi_accept on; } http { include mime.types; default_type application/octet-stream; sendfile on; tcp_nopush on; tcp_nodelay on; keepalive_timeout 65; keepalive_requests 1000; open_file_cache max10000 inactive20s; open_file_cache_valid 30s; open_file_cache_min_uses 2; gzip on; gzip_comp_level 5; gzip_min_length 1k; gzip_types text/plain text/css application/json application/javascript text/xml application/xml image/svgxml; upstream backend { server 10.0.0.1:8080 weight3 max_fails2 fail_timeout10s; server 10.0.0.2:8080 weight2 max_fails2 fail_timeout10s; keepalive 32; } server { listen 80; server_name your-domain.com; location /static/ { alias /data/static/; expires 7d; access_log off; } location /api/ { proxy_pass http://backend; proxy_http_version 1.1; proxy_set_header Connection ; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_connect_timeout 5s; proxy_read_timeout 30s; proxy_send_timeout 30s; } } }第expires 7d是静态资源的浏览器缓存策略适合图片、CSS、JS这类不常变化的资源。access_log off是针对高频静态资源访问关闭访问日志防止IO成为瓶颈。这两项在生产环境中收益不小但要根据资源更新频率调整过期时间否则用户拿到的是过期的旧文件。根据我个人项目的经验这套配置在4核8G的OpenEuler服务器上压测静态文件的QPS大概在6-8万反向代理场景大约能跑到3-4万具体数据受网络环境和后端服务性能影响较大。你拿到的数字只要在自己机器上比基线有明显提升目标就达到了——性能优化从来不是追求一个绝对数字而是让系统资源得到合理利用、各项指标达到平衡。优化的空间通常还有不少但先把这份配置跑熟练遇到流量增长时再逐参数微调比一上来就追求极限稳妥得多。 
长河君 · 2026/10/15 1:37:18 · 阅读 1.2k Nginx性能调优实战：OpenEuler系统内核与配置全面优化指南
1. 优化前必须想清楚的事你的Nginx到底慢在哪接手OpenEuler系统上的Nginx性能调优很多人第一反应就是去改配置、加参数我在实际项目里见过太多这种操作。某次线上压测一位同事直接把worker_processes改成128结果负载不降反升CPU在中断处理上烧掉一大半——这事儿说明一个道理调优前提是定位瓶颈不是堆配置。我需要先明确一个概念Nginx性能优化不是单点问题。它涉及系统内核参数、Nginx自身配置、后端服务处理能力、网络链路质量四个层面。你在OpenEuler上装好Nginx、能跑通业务这只是起点离“高性能”还差着十万八千里。1.1 先做压测画出性能基线动任何配置之前先花半小时测出当前系统的基准数据。我推荐的压测工具是wrk或者ab注意压测机和Nginx服务器要分开部署否则压测请求本身会消耗被测试机的CPU和网络资源数据完全失真。我常用的压测命令是wrk -t8 -c100 -d60s --latency http://your-server-ip/test.html重点看三个指标QPS每秒请求数、平均延迟、P99延迟。压测完成后记录一份基线数据后续每改一个参数就重测一次对比数据变化。没有基线的调优等于闭着眼睛开车。1.2 看清硬件底子再定策略OpenEuler系统跑的机器配置千差万别。先执行lscpu看核数、free -h看内存、df -h看磁盘类型再用iostat确认磁盘IO能力。我遇到过一台机器磁盘IO能力弱静态文件读取直接成为瓶颈这时候怎么调Nginx参数都白搭只能上缓存或者换存储。CPU核数是Nginx worker进程数配置的核心依据不是随便填的数字。内存大小决定你能开多大的文件缓存、多长的keepalive连接池。磁盘类型决定静态文件的高性能策略——SSD和机械盘的优化方向完全不同。把这些信息记在纸上心里有数再动手。2. OpenEuler系统底层调优内核参数决定天花板很多人调Nginx只看nginx.conf忽略了操作系统层面。实际上大量连接卡住、TIME_WAIT堆积、文件句柄耗尽这些问题根源都在内核参数。OpenEuler基于Linux内核参数体系和其他主流发行版基本一致但有几个默认值需要特别留意。2.1 文件句柄限制连接数上限的隐形阀门Nginx处理每个连接都要占用一个文件句柄file descriptor系统默认的1024上限意味着你的Nginx最多同时处理几百个连接。我在生产环境踩过这个坑——压测一上量日志里全是“too many open files”Nginx直接拒绝服务。调整分两步。第一步改系统级限制编辑/etc/security/limits.conf追加* soft nofile 65535 * hard nofile 65535第二步在Nginx配置里同步提升worker进程的句柄上限worker_rlimit_nofile 65535;这里多说一句worker_rlimit_nofile的值要略小于系统nofile限制否则Nginx启动时会报错。改完必须重启Nginx进程才生效不是reload。2.2 TCP栈参数突破连接和端口的限制高并发场景下服务器要处理大量短连接。默认的TCP参数往往不够用我常用的内核参数调整如下写入/etc/sysctl.confnet.ipv4.tcp_tw_reuse 1 net.ipv4.tcp_tw_recycle 0 net.ipv4.tcp_fin_timeout 30 net.ipv4.ip_local_port_range 1024 65535 net.core.somaxconn 65535 net.core.netdev_max_backlog 65535逐条解释背后的逻辑tcp_tw_reuse1允许客户端复用TIME_WAIT状态的连接。压测时大量短连接会导致TIME_WAIT堆积连接数一多端口就被占满了。但注意tcp_tw_recycle在较新的内核里已经废弃开启会导致NAT环境连接异常务必设置为0。ip_local_port_range扩大本地端口范围避免端口耗尽。默认值经常从32768开始压测时成千上万的外部连接打进来本地端口很快被耗光。somaxconn和netdev_max_backlog分别控制TCP连接队列长度和网卡接收队列长度高并发下默认值128的somaxconn会让accept队列溢出表现是客户端连接超时或重置。改完之后执行sysctl -p生效。这个环节我在多个项目上验证过效果立竿见影压测时TIME_WAIT堆积导致连接失败的问题基本消失。2.3 CPU亲和性和网卡多队列让中断分摊出去Nginx默认情况下内核会把网卡中断集中丢给某一个CPU核心处理导致单个核心满载、其他核心闲着。这种现象在单队列网卡上尤其明显。解决方法有两个方向。一个是设置worker_cpu_affinity让每个Nginx worker进程绑定到固定的CPU核心减少进程在核心间切换的开销。配置方式是在nginx.conf中指定worker_processes 4; worker_cpu_affinity 0001 0010 0100 1000;这里四个掩码分别对应前四个CPU核心。我的经验是多核机器上绑定CPU能减少约10%的开销性能损耗主要来自上下文切换。另一个方向是网卡多队列。检查网卡是否支持RSSReceive Side Scalingethtool -l eth0如果Combined队列数大于等于CPU核数就用ethtool -L eth0 combined N把队列数设置为CPU核数让各队列的中断分散到不同核心。开启RPSReceive Packet Steering也能在软件层面分摊软中断处理但配置相对复杂生产环境看需求选择。3. Nginx配置层性能调优参数背后是取舍系统层改完真正的重头戏在Nginx配置。这个环节我不建议直接抄网上的“最佳配置”因为每个业务场景的模型不同——静态文件服务和反向代理的优化方向差异很大必须先搞清楚自己属于哪一种。3.1 worker进程数和连接数不是越大越好worker_processes最稳妥的设置是等于CPU核心数。早些年有观点说设为核数的两倍更好实际压测表明Nginx是事件驱动模型worker进程数超过核数反而增加上下文切换开销收益为负。我常用的设置方案worker_processes auto; worker_cpu_affinity auto;OpenEuler上Nginx支持auto参数自动检测核数配置更省心。如果机器还跑着其他核心服务建议手动设置为核数-1给系统调度留出余地。worker_connections指的是每个worker进程能同时打开的最大连接数Nginx官方建议公式是events { worker_connections 10240; use epoll; multi_accept on; }理论上最大并发连接数 worker_processes × worker_connections前提是系统文件句柄上限足够。use epoll是Linux高并发场景下最有效的事件驱动模型OpenEuler默认支持。multi_accept on让worker进程一次性接受所有新连接而不是一个一个来压测下吞吐能提升不少。这里有个细节worker_connections不是随便拉高就行的。每个连接背后都有内存开销连接数拉满而业务处理跟不上内存直接告急。我用压测的方式逐步调整比如先设10240、压测观察内存和延迟再决定要不要上调。3.2 静态文件处理sendfile和open_file_cache是主角如果业务以静态文件为主Nginx的静态文件处理能力通常直接决定性能上限。核心配置如下sendfile on; tcp_nopush on; tcp_nodelay on; keepalive_timeout 65;sendfile开启后Nginx直接从磁盘到网卡传输文件省去用户态和内核态之间的数据拷贝。这个过程可以类比成快递直发——不经过中转站时间自然缩短。open_file_cache是很多人忽略的参数它缓存文件元数据路径、大小、修改时间减少重复打开文件的开销open_file_cache max10000 inactive20s; open_file_cache_valid 30s; open_file_cache_min_uses 2; open_file_cache_errors on;这几个参数的含义分别是缓存最多10000个文件信息20秒内未被访问的条目淘汰每30秒检查一次缓存条目是否过期文件被访问2次以上才缓存。这部分对高流量静态资源站点效果特别明显我在一个图片服务上实测配置后CPU占用率下降了约30%。3.3 gzip压缩带宽换CPU还能提升首屏速度带宽小的场景开启gzip能让传输体积缩小60%-80%尤其对文本类资源效果显著但压缩消耗CPU需要在两者之间平衡。gzip on; gzip_comp_level 5; gzip_min_length 1k; gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xmlrss image/svgxml;gzip_comp_level是最值得注意的参数5是性能和压缩率的平衡点6以上压缩率提升不明显CPU消耗却成倍增加。gzip_min_length 1k是防止压缩小文件——小于1KB的文件压缩后体积反而更大得不偿失。另外如果客户端通过代理访问还需要在gzip_http_version 1.1和Vary头方面测试确认否则可能出现压缩不生效或重复压缩的问题。3.4 连接超时和keepalive连接复用大幅提升吞吐Nginx处理HTTP短连接时每次请求都要经历TCP三次握手和四次挥手连接建立和释放的耗时占比很重。开启keepalive让客户端复用TCP连接是提升吞吐性价比最高的操作之一。keepalive_timeout 65; keepalive_requests 1000;keepalive_timeout 65是服务端关闭空闲连接前的等待时间单位是秒。这个值太小连接被频繁关闭复用率低太大则占用文件句柄资源timeout单位是秒65是一个常用平衡点。keepalive_requests是单条连接上最多能处理的请求数默认100不够用高并发场景建议提升到1000左右。连接被复用越充分握手次数越少CPU开销越小。这个参数在压测中的提升效果经常会让第一次接触的人惊讶。4. 反向代理场景优化upstream配置不能照抄默认值如果Nginx承担的是反向代理角色性能瓶颈往往不在Nginx本身而在Nginx和后端服务之间的连接管理、超时控制和负载均衡策略。这块的优化空间非常大我踩过的坑也最多。4.1 upstream keepalive连接池让后端喘口气很多人在upstream配置里只写几个server地址然后就不管了。默认情况下Nginx每个请求都会向上游重新建立TCP连接压测时后端服务器被握手请求淹没表现为CPU飙升但业务处理量却不高。正确的做法是配置upstream连接池。首先在http块内设置upstream backend { server 10.0.0.1:8080 weight3 max_fails2 fail_timeout10s; server 10.0.0.2:8080 weight2 max_fails2 fail_timeout10s; keepalive 32; }然后在location里协调好请求头location /api/ { proxy_pass http://backend; proxy_http_version 1.1; proxy_set_header Connection ; }第proxy_http_version 1.1是关键keepalive需要HTTP/1.1协议支持。proxy_set_header Connection 是清空Connection头让上游连接保持复用。keepalive 32表示每个worker进程缓存32个上游连接。这个值不用太大连接池太大占内存、太小缓存命中率低32在绝大多数场景都够用。配置完成后后端服务的CPU占用会明显下降因为不再频繁创建和销毁TCP连接。4.2 超时重试和负载均衡策略区分业务场景反向代理场景下超时设置直接影响用户体验和服务器压力。四个关键超时参数含义容易混淆但实际分工明确proxy_connect_timeout 5s; proxy_read_timeout 30s; proxy_send_timeout 30s;proxy_connect_timeout是Nginx和后端建立连接的超时时间太短容易在高峰时报504proxy_read_timeout是两次读操作之间的间隔超时不是总耗时上限这个很多人理解错proxy_send_timeout类似是写操作间隔超时。负载均衡策略方面默认是轮询round-robin后端服务能力不一致时需要按权重调整weight参数。least_conn策略适合上游服务处理能力不均的场景会把请求分发给当前连接数最少的服务器。我处理高并发接口时还会加一层主动健康检查。Nginx自带的max_fails和fail_timeout是被动检查——请求失败次数超阈值后标记该服务器为不可用。这块建议配合upstream块的zone指令在主备切换和故障隔离时体验会好很多。4.3 SSL性能优化如果走HTTPS这步是最大的性能杠杆越来越多的业务全站HTTPS但SSL握手开销远超很多人的预期。压测时经常看到HTTP跑10万QPS的机器加了HTTPS直接掉到2万。优化SSL性能是所有使用HTTPS业务的重中之重。ssl_protocols TLSv1.2 TLSv1.3; ssl_session_cache shared:SSL:10m; ssl_session_timeout 10m; ssl_buffer_size 4k; ssl_session_tickets on;ssl_session_cache是SSL会话缓存分布式环境中推荐共享缓存10m可以缓存大约几万个会话。会话复用后客户端在缓存期间内重新连接时跳过完整握手直接把握手时间省掉。ssl_session_timeout 10m控制会话有效期。太短则缓存命中率低、加速效果不明显太长则存在安全风险。10-30分钟是常用区间。ssl_buffer_size 4k控制SSL发送数据大小。改为4k可以减少每条记录的填充开销在响应体较小的API场景里提升明显。另外如果证书链完整、后端能响应OCSP请求一定要开启ssl_stapling on这会把证书状态验证从客户端负担转移到服务端减少一次网络往返。5. 压测复盘与问题排查实战记参数改完不算结束我的习惯是再跑一轮完整压测对比基线和调优后的数据。有次在OpenEuler系统上做优化基线QPS 3万调优后跑到7.5万延迟还降了一半。但这个数字不是凭空来的——中间经历了几轮问题和调整。5.1 三个高频问题速查表现象可能原因排查方法解决措施连接数一高就报too many open files文件句柄限制未调ulimit -n、cat /proc/sys/fs/file-max调limits.conf和worker_rlimit_nofile压测大量TIME_WAIT状态连接TCP栈参数不合适netstat -an | grep TIME_WAIT | wc -l开启tcp_tw_reuse、调小tcp_fin_timeoutworker进程CPU占用不均CPU亲和性未设top按1查看各核使用率配置worker_cpu_affinityQPS提不上去、延迟忽高忽低keepalive未开启抓包确认是否有频繁TCP握手配置upstream keepalive偶发502/504错误后端超时或连接池耗尽查error.log、后端日志调proxy_connect_timeout、加大keepalive连接池这个表是我踩坑的浓缩版建议收藏。遇到问题先查表能少走很多弯路。5.2 压测过程中的两次教训第一次教训是压测目标接口选择失误。我当时压的是PHP动态页面结果QPS上不去调整各种Nginx参数都无效。后来发现瓶颈在PHP-FPM进程数太低Nginx配置怎么改都白搭。性能调优一定要先确认瓶颈层级不要只盯着Nginx这一层。第二次教训是keepalive配置了但没生效。配置后重新压测发现后端连接的创建和销毁依然频繁。排查发现我写的是proxy_set_header Connection close;直接把keepalive废掉了。改成proxy_set_header Connection ;才恢复正常。这里特别提醒空字符串必须双引号包裹写成不设值或各版本格式不一致效果完全不同。5.3 优化效果的复盘逻辑优化后的压测数据需要多维度对比。除了QPS和延迟我还会关注以下几个方面压测期间用top观察CPU使用率分布用户态、内核态、软中断占比用vmstat看上下文切换次数cs字段用ss -s看连接状态分布。QPS上去了但上下文切换次数飙升说明进程调度成为新瓶颈CPU大部分消耗在软中断上说明网卡队列或驱动需要调整。产出对比报告时我会把基线、优化一版、二版的数据放一起每一版标明改了哪些参数、数据变化多少。这样做的好处是后续线上出问题时能通过对比回溯是哪次变更引发的问题定位效率高很多。6. 一个完整的可参考配置模板写到这里我把前面所有内容整合成一份可落地的Nginx核心配置。直接抄这个模板可以应付大多数业务场景但生产环境务必根据你的实际业务调整。user nginx; worker_processes auto; worker_rlimit_nofile 65535; events { use epoll; worker_connections 10240; multi_accept on; } http { include mime.types; default_type application/octet-stream; sendfile on; tcp_nopush on; tcp_nodelay on; keepalive_timeout 65; keepalive_requests 1000; open_file_cache max10000 inactive20s; open_file_cache_valid 30s; open_file_cache_min_uses 2; gzip on; gzip_comp_level 5; gzip_min_length 1k; gzip_types text/plain text/css application/json application/javascript text/xml application/xml image/svgxml; upstream backend { server 10.0.0.1:8080 weight3 max_fails2 fail_timeout10s; server 10.0.0.2:8080 weight2 max_fails2 fail_timeout10s; keepalive 32; } server { listen 80; server_name your-domain.com; location /static/ { alias /data/static/; expires 7d; access_log off; } location /api/ { proxy_pass http://backend; proxy_http_version 1.1; proxy_set_header Connection ; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_connect_timeout 5s; proxy_read_timeout 30s; proxy_send_timeout 30s; } } }第expires 7d是静态资源的浏览器缓存策略适合图片、CSS、JS这类不常变化的资源。access_log off是针对高频静态资源访问关闭访问日志防止IO成为瓶颈。这两项在生产环境中收益不小但要根据资源更新频率调整过期时间否则用户拿到的是过期的旧文件。根据我个人项目的经验这套配置在4核8G的OpenEuler服务器上压测静态文件的QPS大概在6-8万反向代理场景大约能跑到3-4万具体数据受网络环境和后端服务性能影响较大。你拿到的数字只要在自己机器上比基线有明显提升目标就达到了——性能优化从来不是追求一个绝对数字而是让系统资源得到合理利用、各项指标达到平衡。优化的空间通常还有不少但先把这份配置跑熟练遇到流量增长时再逐参数微调比一上来就追求极限稳妥得多。