一个线上 Nginx 配置，我改了 3 个参数，性能稳定了很多
当前位置：点晴教程→知识管理交流
→『 技术文档交流 』
前几天我处理了一个线上 Nginx 问题。 问题不算特别复杂，但挺典型。 业务同事反馈说： 网站大部分时间正常，但是一到访问量上来，就会偶尔卡一下。 不是完全打不开，也不是一直慢，就是有时候请求会突然抖一下。 这种问题其实挺苦恼的。 因为它不像服务挂了那样明显，也不像数据库慢查询那样一眼能看出来。 它更像是系统在某个地方“憋住了”。 我先看了一圈：
机器 CPU 没爆，内存也还够，磁盘也没满。 后端服务也没有明显报错。 最后问题落到了 Nginx 配置上。 这次我主要改了 3 个地方，改完以后，接口抖动明显少了很多。 当然，这不是说所有线上 Nginx 都照抄这 3 个参数。 生产环境没有万能配置，只有适合当前业务的配置。 但这 3 个点，确实是很多中小项目最容易忽略的地方。 一、worker_connections 太小，连接数上来就容易顶住 很多人装完 Nginx 后，配置基本不动。 默认配置可能是这样：
这在测试环境没问题。 但是到了线上，如果并发请求多一点，就可能不够。 Nginx 能处理多少连接，大概和这两个配置有关：
简单理解： 最大连接能力 ≈ worker_processes × worker_connections 如果机器是 4 核，worker_processes auto 大概会启动 4 个 worker。 如果 worker_connections 是 8192，理论连接能力就比默认高很多。 但这里有一个坑。 你不能只改 Nginx，还要看系统文件句柄限制。 可以这样看：
如果这里还是 1024，那 Nginx 配得再高也没有意义。 可以在 Nginx 主配置里加：
然后系统层面也要配好，比如：
可以加类似：
这一步解决的是： Nginx 不要在连接数稍微上来时就先扛不住。
二、keepalive_timeout 太长，空闲连接会占资源 第二个参数是： keepalive_timeout 这个参数很容易被忽略。 它的作用简单说就是： 客户端请求完之后，连接先不马上断开，可以继续复用。 这当然有好处。 不用每次都重新建立连接，性能会更好。 但是如果设置太长，也有问题。 比如：
如果访问量不大，没事。 但如果很多客户端都连上来，然后连接一直挂着不释放，就会占用 Nginx 的连接资源。 所以我一般不会把它设置得太夸张。 比如普通 Web / API 服务，可以先这样：
这个值并不是标准答案。 如果你的网站是普通后台系统、接口系统，15 到 30 秒通常够用。 如果是特殊长连接场景，就不能这么配。 这一步解决的是： 不要让大量空闲连接一直占着 Nginx 的连接资源。
三、后端 upstream 没开 keepalive，Nginx 到后端反复建连接 第三个地方，是 Nginx 到后端服务的连接。 很多配置是这样写的：
这个能跑。 但是在请求多的时候，Nginx 到后端服务之间可能会频繁建立连接、关闭连接。 如果后端是 Java、Go、Node、Python 服务，都可能受到影响。 特别是 Java 服务，有时候连接抖动、线程池压力、网关超时会一起出现。 我会把 upstream 改成这样：
这里重点是：
这几个配置配合起来，Nginx 到后端可以复用连接。 好处是： 减少 TCP 建连 减少后端连接抖动 减少接口突然卡顿 降低后端线程压力 这一步解决的是： Nginx 到后端服务之间不要每次请求都重新建立连接。 改完之后，我一般会观察这些指标 改配置不是拍脑袋。 改完后一定要观察。 修改之后 reload 下
然后看连接：
看 Nginx 错误日志和接口耗时：：
如果你有 Prometheus / Grafana，最好看这些：
很多时候，配置改完以后，不是看“能不能访问”，而是看： 高峰期有没有继续抖 P99 延迟有没有下降 错误日志有没有减少 后端连接数有没有稳定 一个比较通用的参考配置 下面这个不是万能配置，但可以作为中小项目的起点：
最后说一句 Nginx 很多时候不是不能扛，而是配置一直停留在“能跑就行”。 测试环境能跑，不代表生产环境稳定。 低峰期能跑，不代表高峰期稳定。 接口能打开，不代表链路没有抖动。 这次我改的 3 个点，其实都是大家很容易忽略的参数：
但线上问题很多时候就是这样。 不是靠多高级的技术解决，而是把基础配置认真检查一遍。 运维最重要的不是炫技。 是系统真的稳定。 阅读原文：https://mp.weixin.qq.com/s/AMUz4_wevq_rGBOyAxiV3A 该文章在 2026/5/15 19:10:28 编辑过 |
关键字查询
相关文章
正在查询... 
|
400 186 1886
