排查微服务调用超时关键在于精准捕获特定服务间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快速定位失败响应
