Linux网络故障排查应自下而上分层验证：先用ip link show检查物理层连通性，再通过ip addr show和ping本机IP确认IP配置与本地协议栈，接着测试网关可达性及DNS解析，最后用curl、mtr、nc等验证端到端服务连通性。
Linux网络状态检测不需要死记命令，关键在于分层排查——从物理层到应用层逐级验证，能快速定位绝大多数问题。下面这套流程覆盖有线、无线、容器、云主机等全部常见场景，不依赖特定工具，用系统自带命令就能完成。
检查物理连接与网卡基础状态
先确认硬件和驱动是否就绪，这是所有网络通信的前提。
- 运行 ip link show 查看网卡是否存在、是否 UP（注意不是“UP”而是“state UP”），比如 enp0s3:
表示链路已通 - 若显示 NO-CARRIER 或 DOWN，检查网线/Wi-Fi开关、网卡驱动（lspci | grep -i net）、或执行 sudo ip link set enp0s3 up 尝试启用
- 无线网卡额外用 iw dev 和 iw dev wlan0 link 确认是否已关联到AP
验证IP配置与本地连通性
有了物理连接，再看是否正确获取了IP地址并能响应本机请求。
- 用 ip addr show 检查是否有有效IPv4地址（非169.254.x.x或0.0.0.0），特别留意子网掩码是否匹配预期
- 执行 ping -c 3 127.0.0.1 测试协议栈；再 ping -c 3 [本机IP] 验证接口回环能力
- 若失败，可能是NetworkManager冲突、systemd-networkd未启动，或防火墙拦截了ICMP（临时关掉：sudo ufw disable 或 sudo systemctl stop firewalld）
测试网关可达性与DNS解析能力
能通本机不代表能上网，必须确认能否到达出口网关，并能将域名转为IP。
- 从 ip route | grep default 找出默认网关，然后 ping -c 3 [网关IP] ——不通说明路由或上联设备问题
- 用 nslookup google.com 或 dig +short github.com 测试DNS；若超时或返回空，检查 /etc/resolv.conf 内容是否合理（如含 nameserver 8.8.8.8）
- 容器或云主机中常见DNS被覆盖问题，可用 cat /run/systemd/resolve/resolv.conf 对比真实生效的解析配置
端到端服务连通性与路径分析
前面都正常，但业务仍不可用？需要模拟真实访问路径，区分是网络层阻断还是应用层拒绝。
- 用 curl -v http://example.com 查看HTTP响应头和连接阶段（DNS→TCP→TLS→HTTP），比单纯 ping 更贴近实际
- 怀疑中间设备限速或丢包？运行 mtr -rwc 10 example.com 获取全路径跳点延迟与丢包率，比 traceroute 更实用
- 若目标端口不通（如SSH 22、Web 80），用 nc -zv example.com 443 直接测端口连通性，避免被HTTP重定向干扰判断
基本上就这些。整套流程不复杂但容易忽略层级关系——比如DNS失败时反复 ping 域名毫无意义，因为根本没走到网络层。养成从下往上查的习惯，90% 的网络故障三分钟内可初判。
