error_log 是并发能力的预警红灯而非计数器，通过高频“Connection refused”“Too many open files”等错误揭示后端或系统资源已达临界点，需结合access.log、stub_status及系统指标交叉验证并发瓶颈。
error_log 本身不直接反映并发承载量，但它是判断并发能力是否触顶的关键预警信号。 它不记录连接数或请求吞吐，而是忠实记载当 Nginx 在高负载下“扛不住”时发生的各类失败事件。真正评估并发承载量，需结合 access.log 的 QPS 峰值、stub_status 的实时连接状态，以及系统资源指标；而 error.log 的价值，在于告诉你：当前配置或后端支撑，已经逼近或突破了稳定运行的边界。
高危错误反复出现 = 并发已超负荷临界点
以下错误不是偶发异常，而是并发压力压垮某环节的明确证据：
- “connect() failed (111: Connection refused)” 大量出现：上游服务（如 PHP-FPM、后端 API）进程池耗尽，无法响应新连接，说明后端并发处理能力已达上限；
-
“accept() failed (24: Too many open files)” 或 “open() failed (24: Too many open files)”：Nginx 自身或系统文件描述符（fd）用尽，是
worker_rlimit_nofile或ulimit -n配置不足的直接体现； - “recv() failed (104: Connection reset by peer)” 在短时间密集爆发：常因后端超时断连或网络抖动，本质是请求积压后连接被强制中断，反映处理链路已拥塞。
错误频次趋势比单条日志更重要
并发承载能力不是静态值，而是随配置、流量模式、后端健康度动态变化的。仅看某条 error 没意义，要看它是否在恶化：
- 用脚本按小时统计
alert和error数量，若连续 3 小时上升，基本可判定当前并发模型已无法消化流量增长； - 对比不同时间段（如大促前 vs 大促中）的
error.log中 “upstream timed out” 出现密度，能验证proxy_read_timeout等参数是否与实际响应延迟匹配； - 若
worker process exited on signal 11在高并发时段规律性复现，大概率是内存泄漏或模块兼容问题，导致 worker 崩溃，有效并发容量被动缩水。
与 access.log 和 stub_status 联动交叉验证
单靠 error_log 无法定量，并发承载量必须多源印证：
- 当
error.log中 “Connection refused” 激增时，立刻查stub_status的Active connections是否接近worker_connections × worker_processes理论上限； - 同步分析
access.log同一时段的 5xx 率是否同步跃升——若 error 日志报错 + 访问日志大量 502/504，即确认是反向代理层并发瓶颈； - 若 error 日志无明显高危错误，但
access.log显示 P95$request_time突然翻倍，且stub_status中Waiting连接长期 >80%，说明连接堆积在 keepalive 空闲队列，真实并发压力已被掩盖，需调低keepalive_timeout或增加 worker 数。
不复杂但容易忽略：error_log 是并发能力的“红灯”，不是“计数器”。它不告诉你现在有多少人在线，但会清晰指出——哪一根弦，正在崩断。
