先确认DNS解析是否正常，再验证基础连通性（ping/curl），接着检查路由路径（ip route/mtr），最后排查端口与服务监听状态（ss/docker ps）。
服务器网络故障排查不是靠猜，而是按逻辑分层推进。核心是先确认“通不通”，再查“通到哪一层”，最后定位“卡在哪一环”。下面四步直击要害，每步都带可执行命令和关键判断点。
DNS 解析是否正常
DNS 是所有域名访问的起点，它出问题，业务就全瘫。别急着 ping，先看解析能不能走通：
- 检查 /etc/resolv.conf 是否有有效 nameserver，比如
nameserver 114.114.114.114或8.8.8.8 - 运行
nslookup baidu.com，看是否返回 IP；若超时或报server can't find，说明 DNS 不通 - K8S 环境要额外确认容器内
/etc/resolv.conf是否指向 CoreDNS 的 ClusterIP（如10.96.0.10），而非宿主机 DNS
基础连通性是否成立
光 DNS 通还不够，得验证网络层和应用层都活：
宝塔Linux面板11.3.0
下载
宝塔面板11.3.0是一款针对Linux服务器设计的可视化管理工具，通过重构核心模块实现资源占用显著降低，尤其适合低配置服务器环境。它将复杂的命令行操作转化为直观的图形界面，帮助开发者快速完成网站部署、环境配置及日常运维工作，无需专业技术背景即可高效管理服务器。
-
ping -c 4 8.8.8.8：测试是否能发包出去。不通？可能是网卡 down、网关错、防火墙拦 ICMP -
ip addr：看主网卡（如 eth0）状态是否为 UP，IP 地址是否在预期网段 -
curl -I http://baidu.com：比 ping 更进一步，验证 TCP 建连 + HTTP 响应头是否可达。能 ping 通但 curl 超时，大概率是防火墙放行了 ICMP 却拦了 TCP 80/443
路由与路径是否正确
常见陷阱：能上外网，却连不上内网服务。问题往往出在“该走哪条路”没配对：
-
ip route get 172.16.10.20：查访问目标 IP 时内核选了哪个网关。如果返回的是默认网关（比如 192.168.1.1），而本该走专线网关（比如 10.0.100.1），说明缺明细路由 -
mtr -rw 172.16.10.20：对比访问百度和访问内网 IP 的路径。某跳突然 100% 丢包，就是断点——可能是中间设备 ACL、回程路由缺失，或防火墙拦截 - 云环境务必同步检查安全组、ACL、VPC 路由表，这些常比系统路由更早拦住流量
端口与服务是否就绪
网络通了，不等于服务能用。尤其容器、远程登录、Web 应用这类场景，端口映射和服务监听是最后一道关：
-
ss -tulnp | grep :22（或对应端口）：确认服务真正在监听，且监听地址不是127.0.0.1:22（只本机可连），而是0.0.0.0:22或[::]:22 - Docker 用户跑
docker ps，看-p 8080:80这类映射是否存在；没映射，宿主机 IP 就无法访问容器内服务 - telnet 或 nc 测试端口：
nc -zv 192.168.1.100 3306。连不上？先排除防火墙、安全组，再查服务是否启动、配置是否绑定正确网卡
