核心是停用低效配置、释放资源瓶颈、重设符合当前负载的连接管理逻辑：需检查限流配置冲突、合理设置keepalive与后端匹配、同步系统级参数、启用least_conn调度及健康检查。
清理和重构 Nginx 过时的连接限制策略，核心不是“手动清理连接”，而是**停用低效配置、释放资源瓶颈、重设符合当前负载的连接管理逻辑**。Nginx 本身不维护“过期连接列表”，所谓“过时限制”通常指：keepalive 值失配、limit_conn 区域滥用、系统级参数未同步、或长连接策略与后端实际承载脱节。
检查并停用无效或冲突的限流配置
很多线上问题源于多层限流叠加却未评估叠加效果：
- 确认 limit_conn_zone 是否按真实业务粒度定义——例如用 $binary_remote_addr 限单 IP，但业务走 CDN 时所有请求都来自几个边缘 IP，导致大面积 503；应改用 $http_x_forwarded_for 或结合 header 中的真实标识
- 检查是否在 server 和 location 多处重复启用 limit_conn，造成双重限制（如全局限 10，接口层再限 5），实际生效的是更严者，但日志难定位
- 删除已下线服务残留的 limit_req_zone 定义（即使没被调用，也会占用共享内存），避免 zone 内存碎片化
重设 keepalive 与连接池容量匹配后端真实能力
keepalive 不是越大越好，它直接决定空闲连接在 Nginx 侧的驻留数量，必须与后端处理节奏对齐：
- 计算合理 keepalive 值：取“后端单节点平均并发连接数 × 1.2”，比如后端 Tomcat maxConnections=200，则 upstream keepalive 可设为 240，而非盲目填 1024
- 验证总连接池容量是否溢出：worker_processes × keepalive × 后端服务器数 ≤ worker_connections × 并发系数（建议 0.7~0.8），否则空闲连接会挤占活跃槽位
- 配合 upstream 的 keepalive_requests（默认 1000）和 keepalive_timeout（默认 60s）做压测验证——若后端平均请求耗时 200ms，1000 次请求约需 200 秒，timeout 设 60s 就会导致频繁重建，应调高至 120s+
同步操作系统与 Nginx 的文件描述符及队列参数
很多“连接拒绝”实为内核级静默丢弃，表面看是 Nginx 配置问题，根源在系统层未对齐：
- 确保 worker_rlimit_nofile ≥ worker_processes × worker_connections，且该值不能超过系统 ulimit -n 实际生效值（用 cat /proc/$(pgrep nginx)/limits | grep "Max open files" 验证）
- net.core.somaxconn 必须 ≥ listen 指令后的 backlog 值（如 listen 80 backlog=4096），否则 accept 队列满时 SYN 包被内核丢弃，客户端表现为 Connection refused
- 启用 net.ipv4.tcp_tw_reuse = 1（反向代理 outbound 场景有效）和 net.ipv4.tcp_fin_timeout = 30，加速 TIME_WAIT 和 FIN_WAIT2 状态释放，缓解连接复用阻塞
用动态调度降低连接积压风险
固定权重或轮询容易让某台后端因瞬时负载高而堆积连接，间接触发连接回收：
- 将 upstream 调度算法从默认 round-robin 改为 least_conn，使新连接优先落到当前活跃连接数最少的节点，平衡连接分布
- 搭配健康检查（health_check interval=3 fails=2 passes=2）及时剔除响应迟缓节点，避免连接持续打到异常实例
- 对关键 upstream 显式设置 max_conns（如 max_conns=500），防止单节点连接数暴涨拖垮整个池
