Linux怎么查看具体的网络连接负载均衡失败

502表示负载均衡未收到后端有效响应，常见于后端进程宕机、端口未监听或防火墙拦截；504表示请求已抵达后端但响应超时，多因数据库慢查、线程池耗尽或依赖服务不可用。

怎么确认是负载均衡层失败而非后端服务问题

判断这类问题，最稳妥的办法还是先看返回状态码，再对照日志字段一起分析。502 和 504 虽然都是负载均衡层返回的状态，但指向的问题并不是一回事：502 Bad Gateway 说明负载均衡根本没拿到后端响应，常见原因包括进程已经挂掉、端口没有监听，或者防火墙把健康检查拦住了；504 Gateway Timeout 则意味着请求其实已经到了后端，只是后端迟迟没有返回响应头，比如数据库卡死、线程池打满、GC 暂停。别只盯着 HTTP 状态码本身，更关键的是结合 $upstream_connect_time 和 $upstream_header_time 这两个 Nginx 日志变量一起看：前者偏高，通常指向网络问题或后端进程还没就绪；后者持续升高，往往说明后端业务处理正在变慢。

如何查负载均衡器自身的连接与健康状态

登录对应平台控制台（如 AWS ALB、腾讯云 CLB、Nginx Ingress），重点看三项指标：

• TargetResponseTime（后端平均响应耗时）—— 超过你配置的超时阈值（比如 30s），就会触发 504
• HTTPCode_ELB_5XX（负载均衡自身错误数）—— 上升说明是 LB 层问题，不是后端
• 后端节点健康状态列表 —— 如果大量显示 DOWN，先检查健康检查路径（如 /health）是否返回 2xx，且监听地址是否为内网 IP（常见坑：服务只绑 127.0.0.1:80，LB 无法访问）

绕过负载均衡直连后端验证是否真有问题

用 curl -v http://<后端内网IP>:<端口>/health 直接测试。能通说明后端正常，问题在 LB 配置或转发链路；不通则分两步排查：

• 执行 ss -tuln | grep :<端口> —— 确认服务是否监听在 0.0.0.0 或具体内网 IP，而不是仅 127.0.0.1
• 执行 telnet <后端内网IP> <端口> —— 若连接拒绝，检查后端机器的本地防火墙（iptables -L -n 或 firewall-cmd --list-all）是否放行该端口

为什么 nginx -t 和 ss -s 必须一起查

很多“负载均衡失败”其实是低级配置或资源问题：

• nginx -t 验证配置语法 —— 少个分号、proxy_pass 写错域名、健康检查 uri 路径拼写错误，都会导致静默转发失败
• ss -s 查 socket 总数 —— 接近系统上限（如 65535）会触发 connect() failed (24: Too many open files)，需同步调大 net.core.somaxconn 和用户级 ulimit -n
• 云厂商 LB 还要核对安全组：传统账户类型下，后端 CVM 的安全组必须放行 LB 的健康检查源 IP（不是 0.0.0.0/0，而是 LB 实例的实际内网出口 IP）