那个诡异的502错误：一次抓包排查网络问题的实战记录

上周五临下班时，公司内部系统突然报502错误。作为团队里”最懂网络”的人（其实就是背锅侠），我被拉进了这个坑。今天就把这次排查过程记录下来，希望能帮到遇到类似问题的朋友。

一、问题现象：间歇性502的玄学现场

系统前端时不时弹出502 Bad Gateway，但刷新几次又能正常访问。最诡异的是：

• 开发环境100%复现，生产环境偶尔出现
• Nginx错误日志里能看到大量upstream prematurely closed connection
• 后端服务监控显示CPU和内存都很健康

二、第一反应：常规三板斧

我首先尝试了常规检查：

# 检查服务状态
systemctl status nginx
systemctl status backend-service

# 查看连接数
ss -s | grep ESTAB

# 检查防火墙规则
iptables -L -n

结果一切正常，这时候我才意识到：该祭出抓包大法了。

三、Wireshark实战：发现异常TCP重置

在Nginx服务器上抓包（注意要加sudo）：

sudo tcpdump -i eth0 -w nginx.pcap port 8080

用Wireshark分析时，我特别注意了TCP流的完整性和标志位。果然发现了猫腻：

• 后端服务在返回HTTP 200后，立即发送了TCP RST
• RST包出现在响应体传输到约8KB时
• 时间间隔非常规律，约30秒一次

四、真相大白：Keepalive的坑

结合日志和抓包数据，终于定位到问题：

1. Nginx配置了keepalive_timeout 60s
2. 后端服务的Tomcat默认connectionTimeout=20s
3. 当响应较大时，Tomcat认为连接空闲超时主动断开

解决方案很简单（但排查过程很痛苦）：

# 调整Nginx配置
proxy_read_timeout 300s;
keepalive_timeout 75s;

五、经验总结

这次排查给我几个重要启示：

• 抓包时要同时抓客户端和服务端流量（这次我漏抓了后端出口流量，多花了半小时）
• 超时配置要形成完整链条：客户端→LB→服务端
• Wireshark的”Follow TCP Stream”功能是神器

最后说句掏心窝的：网络问题排查就像破案，证据（抓包数据）比直觉可靠得多。下次遇到玄学问题，别犹豫，直接上tcpdump吧！