error_log不能直接监控连接复用次数，仅在复用异常时报警；需结合debug日志中的keepalive复用行为、系统级ss命令指标及三项基础配置核查，才能准确判断复用是否生效。
不能直接靠 error_log 监控连接复用情况——它不记录“复用了多少次”，只会在复用异常时留下线索。真正有效的做法是：把 error_log 当作“复用失效的报警器”，结合 debug 日志关键词和系统级指标交叉验证。
盯住 error_log 中复用失败的关键信号
复用正常时，error_log 是安静的；一旦复用链路断裂，以下错误会高频出现：
- upstream connection is busy：说明 upstream keepalive 连接池已满，新请求被迫排队或新建连接，复用率实际已下降
- no live upstreams：健康检查连续失败，空闲连接被全部剔除，复用池清零
- connect() failed (111: Connection refused) 或 upstream timed out：后端不可达，Nginx 只能反复重试建连，复用完全中断
- worker process exited on signal 11：worker 崩溃会导致所有空闲连接丢失，复用状态归零
开启 debug 日志，捕获复用行为本身
默认 error_log 不输出复用动作，必须临时启用 debug 级别才能看到真实复用行为：
- 在
nginx.conf的http或server块中加：error_log /var/log/nginx/error.log debug; - 重载配置：
nginx -s reload - 观察日志中是否频繁出现：
keepalive: reuse connection（成功复用）或create connection（新建连接） - 若
reuse行极少、create行密集，说明复用未生效，需回查proxy_http_version 1.1、Connection ''和upstream keepalive三项是否配齐
关联系统指标，确认复用效果落地
仅看日志不够，要从操作系统层面验证复用是否真在发生：
- 在后端服务器执行：
ss -s | grep -i time_wait—— 复用提升后，TIME_WAIT 数量应明显下降（理想降幅 ≥50%） - 在 Nginx 服务器运行：
ss -t -o src :8080（替换为你的后端端口），观察同一源端口是否被多个请求复用（而非每次换端口） - 对比
stub_status输出中的Active connections和Waiting：若Waiting占比长期 >90%，说明客户端长连接复用良好；但若upstream复用差，后端仍会承受高并发建连压力
避免误判：error_log 里没有日志 ≠ 复用正常
安静的日志只是表象，不代表复用正在发生：
- 如果三项基础配置（
proxy_http_version 1.1、proxy_set_header Connection ''、upstream keepalive N）缺一，Nginx 会默默退化为 HTTP/1.0 短连接，error_log也不会报错 - 后端服务不支持 keepalive（如 Tomcat 未开
keepAlive="true"或connectionTimeout小于 Nginx 的keepalive_timeout），连接会被后端主动关闭，Nginx 日志可能只记upstream prematurely closed connection，而非明确提示复用失败 - 健康检查配置不当（如探测用 HTTP/1.0 或未设
match），会持续消耗空闲连接，导致复用池“看着有、实际空”，error_log同样无直接提示
