Nginx性能优化必须以stub_status模块为实时观测入口，需编译启用、安全配置访问控制，并通过Active connections、accepts/handled/requests、Waiting/Writing等指标闭环验证调优效果。
要让 Nginx 性能优化真正落地，必须把 stub_status 模块作为实时观测入口——它不依赖外部组件、开销极低，是验证调优效果的第一手依据。光改 worker_connections 或 keepalive_timeout 而不看状态页数据，等于闭着眼调参数。
确认模块已启用并验证可用性
stub_status 不是默认开启的模块，需编译时显式加入：--with-http_stub_status_module。验证是否生效，执行：
-
nginx -V 2>&1 | grep -o with-http_stub_status_module—— 有输出说明已支持 - 若无结果，需重新编译安装（yum/apt 安装的包通常不含该模块）
安全配置 /nginx_status 接口
在任一 server 块内添加受控 location，例如：
location /nginx_status {
stub_status on;
access_log off;
allow 127.0.0.1; # 仅本机采集
allow 192.168.31.100; # 或指定监控服务器IP
deny all;
}重点：关闭日志、限制访问 IP，避免暴露敏感运行信息或被恶意刷请求。
读懂返回的三行关键指标
访问 http://your-domain/nginx_status 得到类似输出：
Active connections: 245 server accepts handled requests 1823456 1823456 9127834 Reading: 2 Writing: 45 Waiting: 198
核心含义如下：
- Active connections：当前全部连接数（含 Reading + Writing + Waiting）
- accepts：Nginx 启动以来接受的 TCP 连接总数
- handled：成功处理完的连接数（理想情况下 ≈ accepts）
- requests：总 HTTP 请求次数 → 单位时间差值即为 QPS（吞吐量）
- Waiting：空闲 keepalive 连接数；占比长期 > 90%，说明连接复用率高但后端响应快；若突降+ Writing 激增，可能后端开始卡顿
-
Writing：正在向客户端发送响应的连接；持续偏高且响应体大，需检查
output_buffers或后端延迟
将指标用于优化决策闭环
监控不是摆设，而是优化的“仪表盘”：
- 调大
worker_connections后，观察Active connections是否接近新上限、Waiting是否下降 → 验证连接瓶颈是否缓解 - 缩短
keepalive_timeout，若accepts/handled比值明显上升（如从 1.001 → 1.03），说明连接复用变差，可能引发更多 TCP 握手开销 - 发现
handled < accepts，说明有连接被异常中断（如超时、客户端断连），需检查client_header_timeout等超时设置
