排查网络问题需分层验证：先用 ping/traceroute 初判连通性，再以 nc/telnet 测试端口可达性；用 ss 替代 netstat 查监听状态；tcpdump 抓包须精准过滤并保存分析；dns 与路由问题优先用 dig/ip route 定位。
排查网络连通性用 ping 和 traceroute，但别只看通不通
ping 看的是 ICMP 回包，很多防火墙会丢弃 ICMP，所以“ping 不通”不等于“端口不通”。真正要确认服务可达，得用 telnet 或 nc -zv 测试目标端口。比如：nc -zv example.com 443。如果超时，可能是路由问题、中间设备拦截，或目标服务根本没监听该端口。
traceroute（或 mtr）能暴露路径上哪一跳开始丢包或延迟突增。注意：某些节点会屏蔽 ICMP TTL-exceeded 响应，导致显示 * * *，这不是故障，是策略限制。实际定位时，优先在跳数变化点前后比对路由表和防火墙规则。
ss 比 netstat 更快更准，重点看监听状态和连接队列
netstat 已被标记为废弃，ss 是替代方案，输出更简洁、解析更快。查本机监听端口，用：ss -tuln（-t TCP, -u udp, -l listening, -n 数字地址）。特别留意 State 列：如果是 LISTEN 但无进程名（ss -tulpn 才能显示），说明可能没权限读取 /proc；若状态是 SYN-RECV 且堆积多，大概率是 SYN Flood 或应用 accept 队列溢出。
常见误判点：
- 看到
:80监听就认为 nginx 在跑——其实可能是其他进程绑定了 0.0.0.0:80，而 Nginx 配的只是 127.0.0.1:80 - 忽略
Recv-Q和Send-Q：非零值说明有数据积压，需结合应用日志判断是处理慢还是网络卡顿
抓包必须用 tcpdump，过滤条件写错等于白抓
直接 tcpdump -i any port 80 容易被海量包淹没。先缩小范围：指定网卡（如 eth0）、协议（tcp）、方向（src host 192.168.1.100）、甚至 TCP 标志位（'tcp[tcpflags] & tcp-syn != 0'）。保存到文件用 -w capture.pcap，之后用 wireshark 分析更可靠。
容易踩的坑：
- 没加
-s 0导致截断包体，默认只捕前 68 字节，看不到 http 头或 TLS Client Hello - 在虚拟化环境抓包，选错接口（比如抓了
docker0却想看宿主机外网流量） - 忘记
sudo权限，报错socket: Operation not permitted
路由和 DNS 问题优先查 ip route 和 dig，别依赖 nslookup
ip route get 8.8.8.8 能模拟内核选路过程，返回实际走哪条路由、用哪个源地址、是否经由 gateway。比 route -n 更贴近真实转发逻辑。DNS 方面，dig +short google.com @114.114.114.114 明确指定上游服务器，绕过系统 resolver 缓存干扰；而 nslookup 默认走 /etc/resolv.conf，还带交互式提示，脚本里难解析。
典型混淆场景：
-
curl报Could not resolve host，但ping域名却成功——说明 DNS 解析正常，问题在 curl 的 DNS over https 或自定义 resolv.conf 配置 -
ip route显示 default via，但curl -v http://example.com卡在 CONNECT——可能 MTU 不匹配或中间设备干扰 TCP MSS
真实网络问题往往跨层叠加，比如 DNS 解析慢（应用层）+ 本地路由错误（网络层）+ 连接队列满（传输层）同时发生。工具链不是顺序执行，而是根据现象快速交叉验证：一个 ss 发现端口未监听，就不用再 ping；dig 返回 NXDOMaiN，tcpdump 就该去抓 DNS 查询包而非 HTTP 流量。