## 症状现象
端口明明放行了却连不上，防火墙两边都查过没毛病；或者服务偶尔丢包、握手慢，监控曲线看不出规律。这类"说不清"的网络问题，与其反复猜测，不如直接抓包看现场：数据到没到、回没回、谁先断，包不会说谎。应用层日志只能看到超时与失败的结果，看不到包的走向与内容，tcpdump 补上的正是这一层视角。
## 第一板斧：按端口抓
先抓最关心的端口流量，比如 80 或数据库的 3306：
bash tcpdump -i eth0 -nn port 80 -c 200
-i 指定网卡，-nn 禁止域名与端口名反解析，输出干净；-c 限制抓包数量，够看就行。观察要点：有没有看到客户端发来的 SYN；看到了 SYN 但没有 SYN ACK，说明请求到了本机但没人应答，往监听与防火墙查；连 SYN 都没有，请求根本没到，往上游链路查。一次抓包就能把问题切到"本机侧"或"链路侧"两半。重传与乱序同样值得盯：同一序号的包反复出现，说明链路质量差，叠加应用层的超时重试，耗时会被放大好几倍。
## 第二板斧：按主机抓
怀疑只与某个来源相关时，用 host 过滤盯着它看：
bash tcpdump -i eth0 -nn host 203.0.113.7
叠加端口条件可以进一步聚焦到这一台机器访问的某个服务。这个用法适合排查"个别客户连不上"的投诉：对方给了出口 IP，抓十分钟包，有 SYN 无回应、有回应无重传、还是三次握手后立刻被 RST，三种结论分别指向不同环节，比让对方反复重试高效得多。
## 第三板斧：落盘离线分析
现场复杂时把原始包存成文件，拿去用 Wireshark 图形界面慢慢看：
bash tcpdump -i eth0 -nn -w /tmp/issue.pcap port 443
-w 落盘保存完整报文，事后可以按协议、按流、按时间线过滤，跟踪一条 TCP 流的全过程，专家信息系统还会自动标出重传与乱序等异常，省去肉眼逐包翻找。抓包注意控制范围与时长，加上过滤条件与 -c 上限，避免文件膨胀；生产环境抓明文端口内容还涉及敏感信息，用完及时清理。在顺云的云服务器上做链路排查时，抓包结论与控制台流量监控曲线互相印证，定位会又快又稳。