error_log虽不描述事件驱动模型内部机制，但能暴露其高并发承压表现：如“worker_connections are not enough”表明事件队列积压、“upstream timed out”反映事件轮询被拖慢、“accept() failed (24: too many open files)”揭示epoll注册失败，结合后缀可定位事件流中断环节。
error_log 本身不直接描述 Nginx 的事件驱动模型（如 epoll/kqueue）内部运作，但它能暴露该模型在高并发下的实际承压表现——比如连接排队、资源耗尽、上游阻塞等现象，这些正是事件循环无法及时响应的外在信号。
看 error_log 中的连接类告警，反推事件循环负载
当 event loop 处理不过来时，Nginx 不会报“epoll_wait 超时”，而是通过具体行为发出提示：
- “worker_connections are not enough”：说明当前 worker 进程已满负荷处理连接（包括 client、upstream、keepalive 等所有 fd），事件队列积压，新连接被拒绝；这不是配置不够，而是事件分发器已无空闲槽位
- “accept() failed (24: Too many open files)”：系统级文件描述符耗尽，event loop 无法注册新 socket，直接卡在 accept 阶段
- “upstream timed out” 或 “no live upstreams”：后端响应慢或不可用，导致大量连接长期停留在 read/write 状态，占用事件监听资源，挤占其他请求的处理机会
结合日志后缀定位事件路径中断点
error_log 中的错误后缀揭示了事件流在哪一环断裂：
- “while connecting to upstream”：事件已成功接收 client 请求，但在发起 upstream 连接时失败——说明问题不在接入层，而在 outbound 连接建立阶段，可能受 ulimit、SYN 队列、后端健康检查影响
- “while reading response header from upstream”：事件已建立 upstream 连接，但等待响应头超时——说明 upstream 响应慢或网络延迟高，fd 长期处于 EPOLLIN 等待状态，拖慢整个 worker 的事件轮询效率
- 无后缀的 “client intended to send too large body”：事件在解析 request body 阶段就因缓冲区不足触发落盘或拒绝，反映内存分配与事件处理节奏不匹配
用 warn 级别捕捉事件模型的早期压力征兆
debug 级别不记录事件机制细节，但 warn 级别会暴露模型承压前的异常迹象：
- “could not add new connection to epoll”（需开启 debug 才见，warn 级少见但极关键）：epoll_ctl 失败，表明内核事件表已达上限，不是 Nginx 配置问题，而是系统级限制
- “zero length response from upstream”：上游快速关闭连接，Nginx 在事件回调中收到 EOF，若高频出现，说明 upstream 不稳定，导致事件频繁重调度
- “recv() failed (104: Connection reset by peer)”：客户端异常断连，事件循环需清理残留 fd 和上下文，高频发生会增加 event loop 开销
关联 stub_status 与 error_log 判断事件调度是否失衡
仅看 error_log 是静态快照，需配合实时指标验证事件模型运行状态：
- 访问
/nginx_status查 Active connections 数值，若远高于worker_connections × worker_processes，说明连接堆积严重，事件分发已滞后 - 对比 Reading / Writing / Waiting 三态比例：Waiting 过高（如 >80%）表示大部分连接处于 keepalive 空闲态，是正常；但若 Reading/Writing 持续高位且 error_log 出现 timeout，说明事件处理线程被阻塞
- 用
ss -s | grep "TCP:"查系统 TCP 连接总数，若接近系统net.ipv4.ip_local_port_range上限，说明 outbound 端口耗尽，事件无法新建 upstream 连接
