Nginx 不记录“worker_connections 满载”日志，但通过 accept() failed (24)、connect() failed (24)、upstream timed out 等错误日志及 stub_status、ss、/proc/limits 等运行时指标可识别真实连接瓶颈，并触发三级自动降级策略。
worker_connections 本身不产生“满载日志”，Nginx 不会主动记录“连接即将用尽”的预警日志。所谓“满载日志”，实际是指系统资源耗尽时由内核或 Nginx 触发的错误日志线索，需从中识别连接瓶颈，并据此触发集群级流量降级策略。关键不是等日志写满才响应，而是把这几类日志当作实时信号源，联动监控与调度系统快速干预。
从错误日志中识别真实满载信号
Nginx 不会说“worker_connections 已 95%”，但会在资源触底时留下明确痕迹：
accept() failed (24: Too many open files)
这是最直接证据，说明当前 worker 进程已无法accept()新连接——不是配置不够，而是 进程级文件描述符（fd）真正耗尽。此时ulimit -n或worker_rlimit_nofile必定低于worker_connections × worker_processes。connect() failed (24: Too many open files)（出现在 upstream 场景）
表示 Nginx 尝试新建后端连接失败，常见于反向代理高并发+短连接场景。说明不仅客户端连接吃紧，本地端口和 fd 也同时告急。upstream timed out (110: Connection timed out)大量集中出现
并非后端慢，而是 upstream 连接池（keepalive 缓存）枯竭，Nginx 被迫频繁建连，触发内核连接限制或 TIME_WAIT 堆积。本质是keepalive N设置过小 +worker_connections未预留足够槽位给复用连接。/var/log/nginx/error.log中epoll_wait()相关警告（极少见，但出现即严重）
暗示事件模型底层异常，往往伴随worker_connections配置远超epoll支持上限或内存严重不足，需立即限流保底。
结合运行时指标确认是否需降级
单看日志易误判，必须交叉验证实时状态：
启用
stub_status，每 5 秒采集Active connections值；若持续 ≥worker_processes × worker_connections × 0.85，且Waiting状态连接占比 > 40%，说明连接池长期饱和，新请求已在排队。执行
ss -s | grep "tcp:"，关注inuse（当前 TCP 连接数）与orphans（未归属 socket 数）。若orphans>inuse × 0.3，大概率存在连接异常中断或回收卡顿，应降低keepalive_timeout并触发降级。查看
cat /proc/$(pgrep nginx)/limits | grep "Max open files"，确认Limit值是否等于你期望的worker_rlimit_nofile。若明显偏低，说明 limits.conf 未生效或 systemd 服务未重载LimitNOFILE。
动态触发集群流量降级的三级响应策略
发现上述信号后，不应只调大 worker_connections（来不及且可能失效），而应分级启动防御动作：
-
一级：秒级限流（自动）
- 检测到
accept() failed出现频次 ≥ 3 次/分钟，自动在http块启用全局limit_req zone=global burst=100 nodelay; - 对
/api/、/upload/等高消耗路径，临时将limit_req burst压至原值 30%，并返回503 Service Unavailable带Retry-After: 1。
- 检测到
-
二级：连接级熔断（5–30 秒内）
- 若
Waiting连接数连续 3 次采样 > 理论上限 90%，自动对当前节点上游upstream块添加max_fails=1 fail_timeout=10s，并调低keepalive 8（释放复用连接槽位）。 - 同时通知集群 LB（如 Nginx+Consul 或 Kubernetes Ingress），将该节点权重临时设为 0。
- 若
-
三级：服务级降级（人工可选或自动）
- 当
Active connections连续 2 分钟 ≥ 95% 上限，且错误日志中connect() failed占比超 15%，自动关闭非核心功能：-
access_log off;（停访问日志） -
proxy_buffering off;（避免缓冲区占内存） - 对静态资源 location 加
add_header X-Downgraded "true";，前端可据此隐藏非必要模块。
-
- 当
降级后必须做的验证动作
降级不是终点，而是争取恢复窗口：
检查
error.log是否停止新增Too many open files；若仍在增长，说明ulimit或fs.file-max仍不足，需紧急扩内核句柄池。用
ab -n 1000 -c 200 http://test/快速压测，观察stub_status中Reading和Writing是否回落，Waiting是否低于 10%。查看
dmesg | tail -20，确认无TCP: too many of orphaned sockets类内核警告，否则需调net.ipv4.tcp_max_orphans。
不复杂但容易忽略。
