网络不通首要排查网卡状态与ip配置：执行ip addr show确认主网卡up且ipv4非169.254.x.x或0.0.0.0，再用ethtool或nmcli验证物理连接，配置修改后务必应用（如netplan apply）。
确认网卡UP且有合法IP，别被169.254.x.x骗了
很多“网络不通”其实卡在第一步：网卡根本没配好。Linux拿到一个 169.254.x.x（链路本地地址）或 0.0.0.0，说明DHCP失败或静态配置没生效，此时连局域网都出不去。
- 立刻执行
ip addr show，找主网卡（如eth0、ens33、enp0s3），确认状态是UP，且 IPv4 地址不是169.254.x.x - 物理层要同步验证：
ethtool eth0看Link detected: yes；无线用户用nmcli dev status确认connected - 常见坑：改完
/etc/netplan/*.yaml或/etc/sysconfig/network-scripts/ifcfg-ens33后忘了sudo netplan apply或sudo ifdown && sudo ifup，配置压根没加载
逐级 ping：从回环→本机IP→网关→8.8.8.8，跳步等于白查
ping 不是随便挑个域名试试，它是一把分层诊断尺子。每一步失败，指向的故障层级完全不同，跳过中间环节会直接误判。
-
ping -c 4 127.0.0.1失败 → 内核网络栈异常，检查dmesg | grep -i network -
ping -c 4失败 → IP未生效或存在地址冲突（arp -a可辅助看） -
ping -c 4 $(ip route | grep default | awk '{print $3}')失败 → 局域网断开：查网线、交换机、网关设备是否存活，或目标禁ICMP -
ping -c 4 8.8.8.8成功但ping www.baidu.com失败 → 100% DNS问题，不用再往下查路由或防火墙
查路由和DNS时，/etc/resolv.conf常被systemd-resolved悄悄覆盖
你明明在 /etc/resolv.conf 里写了 nameserver 114.114.114.114，但 nslookup google.com 还是超时——大概率是 systemd-resolved 在后台接管并生成了空或错误的文件。
- 先看真实生效的DNS：
resolvectl status（systemd系统）或cat /run/systemd/resolve/resolv.conf - 临时绕过干扰：
dig @8.8.8.8 google.com +short，若返回IP，则确认是本地DNS服务或配置问题 - 不要直接编辑
/etc/resolv.conf，它可能是符号链接；正确做法是改/etc/systemd/resolved.conf中的DNS=行，再sudo systemctl restart systemd-resolved
防火墙拦截ICMP或DNS端口，关掉再试是最高效的验证手段
云服务器、加固过的生产环境，默认防火墙往往静默丢弃ICMP和UDP 53，导致ping不通、nslookup超时，但业务日志里却看不到任何拒绝记录。
- Ubuntu：
sudo ufw disable；CentOS/RHEL：sudo systemctl stop firewalld；临时关闭后立刻重试ping和nslookup - 若关闭后恢复，说明规则有问题；别急着加一堆放行规则，先用
sudo ufw status verbose或sudo firewall-cmd --list-all看当前策略 - 注意：云平台还有安全组（Security Group）这一层，它在防火墙之外，必须单独检查——比如阿里云控制台里是否放行了出方向UDP 53
真正卡住人的，往往是物理链路灯不亮却去调DNS，或是 /etc/resolv.conf 被覆盖了还不知道该查 resolvectl。排查顺序一旦乱，时间就花在无效操作上。
