负载均衡分配失败日志通常不在系统默认日志中，而由反向代理（如Nginx的/var/log/nginx/error.log）、HAProxy或云LB组件生成；Nginx需开启error_log ... debug才能记录完整分配链路，关键错误包括no live upstreams、connect() failed (111)等。
负载均衡分配失败的日志通常不在系统默认日志里
Linux 内核和 systemd 不会记录“负载均衡分配失败”这类业务层决策，它本身不参与应用级负载均衡。真正产生这类日志的，是反向代理（如 Nginx、HAProxy）、服务网格（如 Envoy）、或云厂商 LB 的后端 agent（如 AWS ALB Target Group Health Check 日志）。/var/log/messages 或 /var/log/syslog 里几乎找不到“分配失败”字样的原始记录，除非你手动在 upstream 模块里加了 error_log 或启用了详细 debug 级别。
Nginx 中排查 upstream 分配失败的关键日志路径和配置
如果你用的是 Nginx 做反向代理，分配失败一般表现为 upstream prematurely closed connection、no live upstreams、connect() failed (111: Connection refused) 这类错误。它们默认写入 Nginx 的 error.log，而不是系统日志。
- 确认日志位置：
/var/log/nginx/error.log（Debian/Ubuntu）或/var/log/nginx/error.log（RHEL/CentOS），具体以nginx.conf中error_log指令为准 - 必须开启
error_log ... debug;才能看到连接被丢弃、重试次数、选中哪台 upstream 的完整链路；否则只有最终失败结果 - 检查
upstream块是否配置了health_check或max_fails/fail_timeout，这些参数触发的踢除行为会在error.log中记为upstream server temporarily disabled - 用
grep -i "upstream\|health\|connect.*refused\|prematurely" /var/log/nginx/error.log快速定位线索
HAProxy 的分配失败日志比 Nginx 更直接
HAProxy 默认把连接拒绝、server offline、retry 超限等事件全量记进 /var/log/haproxy.log（需 rsyslog 配置支持），且字段明确：
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
-
srv_conn_fail表示连接后端失败（目标端口未监听、防火墙拦截） -
srv_hana_fail表示健康检查失败导致 server 被标记为 down -
retries字段显示重试次数，conn_reuse为 0 说明连接未复用、可能是新建连接失败 - 确保
log global和option http-server-close已启用，否则部分上下文信息会被截断 - 用
tail -f /var/log/haproxy.log | grep -E "(DOWN|SHUT|fail|retry)"实时盯住分配异常
别漏掉内核和连接跟踪层的底层线索
有时分配失败不是应用层逻辑问题，而是连接根本发不出去——比如 conntrack 表满、SYN 包被 DROP、或 netfilter 规则误判。这类问题不会出现在 Nginx/HAProxy 日志里，但会留在：
-
dmesg -T | grep -i "nf_conntrack.*full\|drop"：确认是否因nf_conntrack_max耗尽导致新连接被丢弃 -
journalctl -k | grep -i "iptables\|drop\|reject"：查看 kernel 是否记录了 netfilter 显式丢包 -
ss -s输出中的tcp行里orphan数值异常高，可能意味着 TIME_WAIT 或 FIN_WAIT2 积压，间接影响新连接分配 -
cat /proc/net/nf_conntrack | wc -l对比sysctl net.netfilter.nf_conntrack_max，判断是否接近阈值
真正难查的，往往是上游服务没响应（比如 Java 应用卡 GC），导致健康检查超时，而日志只写“check failed”，却不告诉你为什么——这时候得结合 curl -v 直连 upstream、tcpdump -i any port 抓包，才能确认是网络层不通，还是应用层静默挂起。
