终极实战 - 全链路排查一次“502 Bad Gateway”

《网络迷踪：SRE的TCP/IP故障排查艺术》

系列最终篇：终极实战 - 全链路排查一次“502 Bad Gateway”

“案发现场”：

现在是周二上午10点，正值业务高峰。监控系统突然亮起一片红色，同时，你的即时通讯软件开始被雪片般的报警信息淹没：“核心业务webapp.mycompany.com出现大量502错误！”

用户反馈，网站时而可以打开，时而显示一个冰冷的错误页面，上面写着“502 Bad Gateway”。

“502”是所有运维工程师的噩梦，因为它的成因非常复杂。它不像“404 Not Found”那样明确（找不到资源），也不像“503 Service Unavailable”那样直接（服务不可用）。“502”的本质是“网关错误”，意思是作为网关或代理的服务器（通常是Nginx或负载均衡器），尝试从上游（后端）服务器获取响应时，收到了一个无效的回应。

这意味着，从用户到你的应用服务器，这条漫长的链路上，任何一个环节都可能是“犯罪嫌疑人”。现在，我们将化身总指挥，启动全链路排查。

---

第一步：勘察现场，缩小范围 (DNS & 网络链路)

我们的排查永远从最外层开始，逐步向内收缩。

1. DNS是否指向正确？

侦察工具： dig
目的： 确认域名是否解析到了我们预期的“大门”——负载均衡器（LB）或CDN的IP地址。

输入（在你的本地电脑执行）：

dig webapp.mycompany.com

预期输出与分析：

;; ANSWER SECTION:
webapp.mycompany.com.	600	IN	CNAME	lb-cluster.mycompany-cdn.com.
lb-cluster.mycompany-cdn.com. 60 IN A	111.222.1.50

• 分析： 域名首先通过CNAME指向了CDN的负载均衡地址，最终解析到了IP 111.222.1.50。这个IP是你预期的线上入口IP吗？如果是，则DNS层面没有问题。如果不是，或者解析失败，那么问题出在DNS配置。（本案中，我们假设DNS正确）

2. 到“大门”的路是否通畅？

侦察工具： ping, traceroute
目的： 确认从客户端到入口IP的网络链路是否存在问题。

输入：