502表示负载均衡未收到后端有效响应，常见于后端进程宕机、端口未监听或防火墙拦截；504表示请求已抵达后端但响应超时，多因数据库慢查、线程池耗尽或依赖服务不可用。
怎么确认是负载均衡层失败而非后端服务问题
直接看返回状态码和日志字段最可靠。502 和 504 都是负载均衡返回的，但含义完全不同：502 Bad Gateway 表示负载均衡压根没收到后端响应（进程挂了、端口没监听、防火墙拦了健康检查）；504 Gateway Timeout 表示请求确实发到了后端，但后端迟迟不回响应头（数据库卡住、线程池满、GC 暂停）。别只盯着 HTTP 状态码，得结合 $upstream_connect_time 和 $upstream_header_time 这两个 Nginx 日志变量：前者高 → 网络或后端进程未就绪；后者持续升高 → 后端业务处理变慢。
如何查负载均衡器自身的连接与健康状态
登录对应平台控制台（如 AWS ALB、腾讯云 CLB、Nginx Ingress），重点看三项指标：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
-
TargetResponseTime（后端平均响应耗时）—— 超过你配置的超时阈值（比如 30s），就会触发504 -
HTTPCode_ELB_5XX（负载均衡自身错误数）—— 上升说明是 LB 层问题，不是后端 - 后端节点健康状态列表 —— 如果大量显示
DOWN，先检查健康检查路径（如/health）是否返回2xx，且监听地址是否为内网 IP（常见坑：服务只绑127.0.0.1:80，LB 无法访问）
绕过负载均衡直连后端验证是否真有问题
用 curl -v http://:/health 直接测试。能通说明后端正常，问题在 LB 配置或转发链路；不通则分两步排查：
- 执行
ss -tuln | grep :—— 确认服务是否监听在0.0.0.0或具体内网 IP，而不是仅127.0.0.1 - 执行
telnet—— 若连接拒绝，检查后端机器的本地防火墙（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）
