Nginx upstream max_conns 达限后，如何设置排队和丢弃策略？

本文共计964个文字，预计阅读时间需要4分钟。

要监控和限制Nginx服务器在高并发时的连接数，关键不是直接监控max_conns是否在命令中指定，而是通过组合配置、指标收集、日志分析和接口验证来确保其生效并定位瓶颈点。Nginx开源版本本身不提供max_conns参数，但可以通过其他方式控制并发连接，如调整worker进程数、连接超时设置等，并依赖配置文件来控制连接数。

启用并验证 queue 行为（仅限支持版本）

从 Nginx 1.23.3 起，开源版支持 queue 指令；更早版本或需 Nginx Plus。若使用该功能，排队动作才可被观测：

• 在 upstream 的 server 行中明确配置：server 192.168.1.10:8080 max_conns=100 queue=5 timeout=10s;
• queue=5 表示最多允许 5 个请求等待空闲连接，超出则返回 503（默认）
• 配合 proxy_next_upstream error timeout http_503; 可让 Nginx 在排队超时或被拒时尝试其他后端
• 此时可通过访问 /nginx_status 查看 Active connections 是否稳定在 max_conns 附近，同时观察错误日志中是否出现 upstream queue is full 或 no live upstreams 类提示

通过 stub_status 和 vts 模块观测连接状态

max_conns 的实际效果体现在“Nginx 到某台后端的活跃出向连接数”上，这是最核心的观测维度：

• 确保已开启 stub_status：在 server 块中配置 location /nginx_status { stub_status on; }
• 访问该地址，关注输出中的 Active connections 字段——它显示当前所有 worker 进程到各 upstream server 的活动连接总数
• 更精细地，使用 nginx-module-vts（推荐）：它能按 upstream 名、server IP 分组展示 Active、Max Fails、Down Time 等，直观对比是否贴近设定的 max_conns 值
• 若某 server 的 Active 长期卡在 100（你设的 max_conns），且 Requests 增速变缓、Response time 明显上升，说明限流已起作用

日志中捕获排队与失败信号

Nginx 不记录“因 max_conns 满而排队”的独立字段，但可通过关联日志线索推断：

• 在 log_format 中加入关键变量：$upstream_addr $upstream_status $upstream_response_time $request_time
• 当某台后端的 $upstream_addr 频繁出现 192.168.1.10:8080，且 $upstream_status 大量为 503 或 504，同时 $upstream_response_time 接近或超过 proxy_read_timeout，大概率是连接池满导致超时或排队失败
• 若启用了 queue，Nginx 会在 error_log 中写入类似：upstream queue is full while connecting to upstream（需开启 debug 日志级别才能看到详细排队信息）
• 搭配 log_subrequest on; 可记录内部重试过程，辅助判断是否因 max_conns 触发了 fallback 到 backup server

用压测工具反向验证限流边界

最可靠的方式是主动施加压力，观察系统响应拐点：

• 用 wrk 或 hey 对 Nginx 发起并发请求（例如 hey -z 30s -c 200 http://your-domain/）
• 同时实时刷新 /nginx_status 或 vts 页面，观察目标 upstream server 的 Active 连接数是否被钉死在 max_conns 值
• 检查 access log 中 503/504 比例是否随并发提升而陡增；error log 中是否出现连接拒绝（connect() failed (111: Connection refused)）或超时
• 若 Active 始终远低于 max_conns，说明后端响应太快、连接复用率高，或负载均衡算法未触发（确认是否用了 least_conn 或 ip_hash）