网络排查应先确认物理层和网卡状态是否正常，再分层验证连通性、路由、ARP、DNS及应用层。
确认物理层和网卡状态是否正常
网络不通的第一反应不该是查路由或 DNS，而是看网线有没有松、光模块亮不亮、网卡有没有被系统识别。很多“网络异常”其实是网卡 down 了，或者驱动没加载。
- 用
ip link show查看网卡是否处于UP状态，注意看state DOWN或NO-CARRIER -
ethtool eth0（把eth0换成你的接口名）看链路是否Link detected: yes；如果显示no，基本就是物理连接断了 - 检查
dmesg | grep -i "eth\|network"，留意是否有驱动加载失败、PCIe link down、firmware missing 等报错
判断是本机连不出去，还是别人连不进来
方向错了，排查效率直接归零。先明确问题边界：是自己 ping 不通外网，还是 SSH 连不上这台机器？前者大概率出在本机路由/DNS/防火墙，后者优先查监听、端口、入向策略。
- 从本机执行：
ping -c 3 127.0.0.1→ 排除协议栈崩溃；ping -c 3 网关IP→ 判断是否能出内网；ping -c 3 8.8.8.8→ 绕过 DNS 测通外网能力 - 从外部机器执行：
telnet 目标IP 22或nc -zv 目标IP 22，验证端口是否可达。如果连不上，但ss -tlnp | grep :22显示sshd在监听，那八成是iptables/nftables或云平台安全组拦住了 - 别依赖
systemctl status firewalld判断防火墙是否生效——它可能 running 但规则全空，也可能 stopped 但nft list ruleset里有残留策略
抓包前先看路由表和 ARP 缓存
盲目 tcpdump 容易陷入数据洪流，尤其在高流量服务器上。先确认三层转发路径是否合理，二层地址是否已解析，能过滤掉大量无效猜测。
- 运行
ip route get 目标IP（例如ip route get 1.1.1.1），它会告诉你实际走哪条路由、用哪个源 IP、下一跳是谁、走哪个网卡——比翻ip route全表快得多 - 如果下一跳是本地子网 IP，再查
ip neigh show看对应 MAC 是否REACHABLE；若为INCOMPLETE，说明 ARP 请求发出去没回，可能是交换机 ACL、VLAN 配置错误，或对方主机禁用了 ICMP/ARP 响应 - 确认无误后再抓包：比如只抓去往网关的 ARP 和 ICMP，
tcpdump -i eth0 'arp or icmp and dst 网关IP'
，避免被其他流量淹没
DNS 和应用层连通性要分开验证
用户说“打不开网页”，90% 的人第一反应是 ping www.baidu.com，但这个命令成功只代表 DNS 解析+ICMP 路径通，完全不能说明 HTTP 服务可用。必须分层验证。
- 用
dig +short www.baidu.com @8.8.8.8直接指定公共 DNS，绕过本机resolv.conf配置，排除 DNS 服务器故障或污染 - 用
curl -v http://180.101.49.12 -m 5（填百度真实 IP）跳过 DNS，测试 TCP 握手和 HTTP 层是否工作；如果超时，说明不是 DNS 问题，而是目标端口屏蔽、TCP 被 reset、或中间设备限速 - 注意
curl默认走 IPv4，加-6才试 IPv6；有些环境 IPv6 路由未配好，但系统优先尝试 IPv6，导致看似“域名解析慢”或“连接失败”
真正耗时间的往往不是命令本身，而是没想清楚「这一行输出到底在证明什么」。比如 ping 通不代表应用端口开着，ss -l 显示监听不代表进程没挂、也没被 seccomp 或 cgroup 限制住网络能力——这些细节不盯住，查一整天也在线上兜圈子。
