排查微服务调用超时关键在于精准捕获特定服务间tcp交互，重点验证三次握手、请求发出、响应返回、重传或rst；推荐在服务端用tcpdump -i eth0 -nn -s 0 -w timeout.pcap host ip and port 等组合抓包，并结合ss、netstat、iptables等命令交叉验证。

排查微服务调用超时，关键不是“抓所有包”，而是精准捕获**特定服务间通信的完整TCP交互过程**，重点看连接建立是否成功、请求是否发出、响应是否返回、有无重传或RST。tcpdump在无GUI的生产服务器上就是最直接的“网络听诊器”。

确认目标通信链路

先明确超时发生在哪两个服务之间：比如 service-a（10.12.3.4:8080）调用 service-b（10.12.3.5:9090），协议通常是HTTP/gRPC（走TCP）。确保你登录的是其中一端（推荐在service-b服务器上抓，能确认“包到底有没有到”）。

• 查本机监听端口：ss -tlnp | grep :9090，确认服务确实在运行且绑定正确地址
• 确认调用方IP真实存在，避免抓错网卡（如容器环境可能有docker0、vethxxx或cali*等虚拟接口）
• 若用Service Mesh（如Istio），优先在应用容器内或Sidecar代理旁抓包，而非宿主机物理网卡

基础抓包命令要带关键参数

别用sudo tcpdump裸跑——输出杂乱、解析慢、易丢关键信息。推荐组合：

Browser Setup (No-Root Linux)

在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...

下载

• -i eth0：指定业务流量经过的真实网卡（可用ip a确认）
• -nn：不解析域名和端口名，直接显示IP和数字端口（避免DNS延迟、显示更准）
• -s 0：捕获完整数据包（尤其对HTTP头、gRPC metadata很重要）
• -w timeout.pcap：保存为文件，便于后续用Wireshark深挖或多人协作分析
• host 10.12.3.4 and port 9090：过滤仅与调用方相关的双向流量（含SYN、ACK、DATA、FIN）

完整示例：
sudo tcpdump -i eth0 -nn -s 0 -w timeout.pcap host 10.12.3.4 and port 9090

抓包后重点看这四类现象

停止抓包后，用tcpdump -r timeout.pcap -nn快速扫读，或拖进Wireshark按时间轴分析：

• TCP三次握手失败：只有SYN，没收到SYN-ACK → 检查service-b防火墙、安全组、服务进程是否存活、端口监听范围（0.0.0.0 vs 127.0.0.1）
• 请求发出了但无响应：看到service-a的PSH/ACK（含HTTP POST或gRPC帧），但后续长时间无service-b的ACK或数据 → service-b处理卡住、OOM、线程池耗尽，或中间LB静默丢包
• 大量TCP重传（Retransmission）：同一seq反复出现 → 网络丢包、网卡驱动问题、交换机拥塞，或service-b接收缓冲区溢出
• 异常RST或FIN过早：service-b在收到完整请求前就发RST → 可能是反向代理（Nginx/Envoy）配置了短超时，或服务主动拒绝连接

配合其他命令交叉验证

tcpdump是“看见”，还需“印证”：

• 抓包同时执行：ss -i src :9090 查当前连接的RTT、丢失率、重传数
• 检查是否有SYN队列溢出：netstat -s | grep -i "listen overflows"
• 确认是否被iptables/nftables拦截：sudo iptables -L -n -v | grep DROP（云环境还要查安全组）
• 若用gRPC，加-A参数打印ASCII内容，搜grpc-status或content-type: application/grpc快速定位失败响应