网络故障排查应自底向上：先确认网卡识别与启用（ip link show）、再验 IP 及子网配置（ip addr show 与配置文件比对）、接着查路由与网关可达性（ip route 与 ping 网关）、然后排除 DNS 问题（绕过 DNS 测试连通性）、最后抓包分析中间链路。
确认网卡是否被识别且已启用
很多网络不通的问题，其实卡在最底层：系统压根没看到网卡，或者识别了但处于 DOWN 状态。别急着查 DNS 或路由，先看硬件和驱动层面。
- 运行
ip link show，检查目标网卡（如eth0、ens33）是否存在，且状态为UP；若显示NO-CARRIER，说明物理链路未连通（网线没插、交换机 端口 down、光模块故障） - 若网卡名是
enp0s3这类新命名规则，可临时用ip link set enp0s3 up启用；但若执行后仍不 UP，大概率是驱动未加载，查dmesg | grep -i eth看内核是否有报错 - 某些云主机或 虚拟机 可能使用
virtio_net驱动，需确认内核模块已加载：lsmod | grep virtio_net；缺失则需安装对应内核包或重启启用
验证 IP 地址与子网配置是否正确
IP 配置错误是高频问题，尤其在多网卡、DHCP 与静态混用、或网卡重命名后未同步更新配置文件的场景下。
- 用
ip addr show查当前实际生效的地址，注意区分inet（IPv4）和inet6（IPv6），别只看ifconfig—— 它可能不显示别名或新接口 - 对比配置文件：
/etc/sysconfig/network-scripts/ifcfg-eth0（CentOS/RHEL）或/etc/netplan/*.yaml（Ubuntu 18.04+），确认IPADDR、NETMASK、GATEWAY与实际网络规划一致；NetPlan 配置后必须执行sudo netplan apply才生效 - 常见陷阱：子网掩码写成
255.255.255.0但实际应为/24（NetPlan 要求 CIDR 格式）；或网关 IP 不在本机所属子网内，导致ip route中默认路由不可达
检查路由表与网关可达性
即使 IP 配好了，没有正确路由，出向流量照样发不出去。重点不是“有没有默认路由”，而是“这条路能不能走到网关”。
- 执行
ip route show，确认存在类似default via 192.168.1.1 dev eth0的条目；若缺失，手动添加：ip route add default via 192.168.1.1 dev eth0（仅临时生效） - 用
ping -c 3 192.168.1.1测试网关连通性；失败时再查 ARP 表：ip neigh show，若对应网关 IP 显示FAILED，说明二层无法解析 MAC —— 可能是网关宕机、VLAN 配错、或 防火墙 丢弃了 ARP 请求 - 多网卡环境务必确认流量从预期接口发出：
ip route get 8.8.8.8会返回实际选中的出口设备和下一跳，比盲目猜更可靠
排查 DNS 解析与连接级故障
DNS 不通 ≠ 网络不通。很多运维误判源于直接用 ping www.baidu.com 失败就断定网络挂了，其实可能是 DNS 没响应或配置错误。
- 先绕过 DNS：
ping -c 3 110.242.68.66（百度 IP），若通，说明网络层正常，问题在 DNS；若不通，再回溯前几步 - 查 DNS 配置：
cat /etc/resolv.conf，确认nameserver条目有效；注意某些发行版（如 systemd-resolved 管理的 Ubuntu）会覆盖该文件，真实配置在resolvectl status - 测试 DNS 查询：
dig @114.114.114.114 www.qq.com +short或nslookup www.taobao.com 8.8.8.8；超时说明上游 DNS 不可达，需结合telnet 114.114.114.114 53或nc -zv 114.114.114.114 53判断端口级连通性
真正棘手的是中间链路问题：ICMP 允许但 TCP 被限速、策略路由干扰、conntrack 表溢出、或 iptables/nftables 默认 DROP 了 OUTPUT 链。这些得结合 tcpdump -i eth0 port 53 抓包才能定位，不能只靠 ping 和 curl 下结论。
