nginx worker_connections 达上限时会静默降级，需通过分层响应机制实现优雅处理：一是用 limit_conn/limit_req 做连接准入限流；二是收紧 client_header_timeout 等五类超时快速释放无效连接；三是配置 upstream 熔断与重试避免后端阻塞；四是结合监控、worker_shutdown_timeout 和日志告警实现可控降级。
当 Nginx 的 worker_connections 达到上限，新连接无法被 accept，但 Nginx 不会主动返回 503 或报错，而是静默降级——连接可能被内核丢弃、排队超时或直接拒绝。真正的“优雅处理”，不是等它满了才补救，而是提前配置好分层响应机制：从连接准入、请求分流，到超时熔断和日志感知，形成一套自动退让、可控兜底的策略。
用连接准入限流提前拦住超额流量
在连接到达 worker 前就做第一道过滤，避免无效连接挤占槽位：
- 使用
limit_conn按客户端 IP 或 key（如 $binary_remote_addr）限制并发连接数，例如：limit_conn_zone $binary_remote_addr zone=addr:10m; server { limit_conn addr 20; # 单 IP 最多 20 个并发连接 } - 配合
limit_req控制请求速率，防突发短连打满连接池，尤其适合 API 或 H5 秒杀类场景 - 注意：
limit_conn作用于 accept 之后，但开销极低；真正压测中它能显著延缓worker_connections触顶时间
靠超时策略快速释放“假活跃”连接
大量连接卡在 reading/sending 状态，是比连接数满更隐蔽的瓶颈。必须收紧五类超时：
-
client_header_timeout 5s：头部收不完就断，防 Slowloris -
client_body_timeout 8s：POST 体传输慢就放弃，不等全量上传 -
send_timeout 10s：两次响应间隔超时即关连接，防客户端读取卡死 -
keepalive_timeout 15s 30s：空闲长连只保 15 秒，向客户端声明 timeout=30 -
reset_timedout_connection on：超时后发 RST，加速端口回收，减少 TIME_WAIT 积压
这些设置让“无效占用”连接快速退出，腾出 worker_connections 给新请求，比单纯调大数值更有效。
通过 upstream 熔断与重试避免连接淤积
后端响应慢时，Nginx 连接会长期停留在 proxy_read 状态，看似活跃实则阻塞。需让 upstream 主动避让：
-
proxy_read_timeout 12s：后端响应头+首块数据必须在 12 秒内到达 -
proxy_next_upstream error timeout http_502 http_504：允许失败时换节点重试（注意幂等性） -
max_fails=2 fail_timeout=15s：同一后端连续失败 2 次，15 秒内不再调度 -
slow_start=30s：故障恢复后逐步加量，防雪崩重启
这样即使某个后端卡住，Nginx 也能快速切换，不把连接耗死在单点上。
配合监控与平滑退出实现可控降级
真到临界状态，要让系统“有感知、可收敛、不中断”：
- 开启
stub_status或 Prometheus exporter，实时看Active connections是否持续 > 90%worker_connections × worker_processes - 设置
worker_shutdown_timeout 15s：reload 时旧 worker 最多再服务 15 秒，强制释放挂起连接 - 在 access_log 中标记异常连接，例如用
$status+$request_time > 10过滤慢请求，触发告警 - 日志里出现大量
503或客户端报Connection refused/timeout时，优先查ss -s中synrecv和established分布，确认是 accept 队列满还是 fd 耗尽
不复杂但容易忽略。
