先看物理层和网卡是否真“在线”
很多“内外网都访问不了”的问题，根源其实在最底层：网线松了、光模块不亮、网卡没被识别。别急着查DNS或防火墙，先确认硬件链路是否成立。
运行 ip link show，重点看目标接口（如 eth0）状态是否为 UP，且没有 NO-CARRIER 标记；再用 ethtool eth0 查 Link detected: yes —— 若为 no，基本可断定物理连接中断。
顺手跑一句：dmesg | grep -i "eth\|firmware"，留意驱动加载失败、PCIe link down 或 missing firmware 等内核报错，这类问题常导致网卡存在但无法工作。
分方向验证：是出不去？还是进不来？
问题边界不清，排查就容易南辕北辙。必须第一时间区分：本机发不出请求（如 curl 失败），还是外部连不到本机（如 SSH 超时）。
- 从本机出发测试：
• ping -c 3 127.0.0.1 → 验证协议栈是否崩溃
• ping -c 3 $(ip route | awk '/default/ {print $3}') → 测试能否抵达网关
• ping -c 3 8.8.8.8 → 绕开 DNS，验证三层外网可达性 - 从外部发起探测：
• nc -zv 目标IP 22 或 telnet 目标IP 22 → 检查端口是否真正可达
• 若 ss -tlnp | grep :22 显示 sshd 在监听，但 nc 连不通，大概率是 iptables/nftables 规则或云平台安全组拦截
路由与二层转发路径要亲手“问”出来
别靠猜，用系统自带命令直接问它怎么走。盲目抓包前，先确认数据包的出口逻辑是否合理。
执行 ip route get 1.1.1.1（换成你要访问的目标 IP），它会明确告诉你：走哪条路由、用哪个源地址、下一跳是谁、从哪个网卡发出——比翻完整路由表快得多、准得多。
如果下一跳是同网段地址（比如网关 192.168.1.1），再查 ip neigh show，看对应 MAC 是否为 REACHABLE。若显示 INCOMPLETE，说明 ARP 请求发出去没响应，常见于交换机 ACL 限制、VLAN 配置错位，或对方主机禁用了 ARP 响应。
DNS 和应用层必须拆开验，不能混为一谈
“打不开网页”不等于“网络不通”。ping www.baidu.com 成功，只代表 DNS 解析成功 + ICMP 路径通，完全不保证 HTTP 服务可用。
务必分步验证：
• 先用 dig +short www.baidu.com @8.8.8.8 绕过本地 resolv.conf 和缓存，直连公共 DNS，确认解析本身没问题；
• 再用 curl -v http://114.114.114.114（用已知 IP）测试 TCP 连接与 HTTP 层是否正常；
• 若前者失败后者成功，就是 DNS 配置或污染问题；若前者成功后者失败，问题就在目标服务、代理、TLS 证书或应用自身。
注意：/etc/resolv.conf 可能被 NetworkManager 或 systemd-resolved 动态覆盖，临时改完记得验证是否生效，必要时修改 /etc/systemd/resolved.conf 并重启服务。
