Linux网络异常快速定位_排查顺序与技巧解析【教程】_网络技术

网络排查应先确认物理层和网卡状态是否正常，再分层验证连通性、路由、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 里有残留策略

盲目 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'
```
，避免被其他流量淹没

用户说“打不开网页”，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 限制住网络能力——这些细节不盯住，查一整天也在线上兜圈子。