核心是分层验证、逐级缩小范围：先确认物理链路与网卡状态（ip a、ethtool），再验二层连通性（ping同网段）、三层路由（ip route）和DNS（nslookup），接着查防火墙（ufw/iptables）与服务监听（ss -tuln），最后用tcpdump抓包定位真实通信问题。
Debian 服务器网络故障排查，核心是“分层验证、逐级缩小范围”——从物理链路到应用层，一层层确认是否正常，避免盲目重启或重装。
先看网卡和基础连通性
登录服务器后第一件事不是查服务，而是确认网卡是否存在、是否启用、有没有获取到 IP：
- 运行 ip a 或 ifconfig -a（需安装 net-tools），检查对应网卡（如 eth0、ens3）是否 UP，是否有 IPv4 地址
- 若无 IP，检查 /etc/network/interfaces 或 /etc/netplan/*.yaml（取决于 Debian 版本和配置方式），确认接口配置正确，尤其 static 地址的 gateway 和 DNS 是否写错
- 用 ping -c 3 127.0.0.1 测试本地协议栈；再 ping 同网段另一台机器，验证二层可达性；最后 ping 网关，确认三层出口正常
查路由和 DNS 是否生效
能 ping 通网关但打不开网页或连不上远程主机？大概率是路由或 DNS 问题：
宝塔Linux面板11.3.0
下载
宝塔面板11.3.0是一款针对Linux服务器设计的可视化管理工具，通过重构核心模块实现资源占用显著降低，尤其适合低配置服务器环境。它将复杂的命令行操作转化为直观的图形界面，帮助开发者快速完成网站部署、环境配置及日常运维工作，无需专业技术背景即可高效管理服务器。
- 运行 ip route show，确认默认路由指向正确网关；若缺失，用 ip route add default via X.X.X.X 临时添加（重启失效）
- 检查 /etc/resolv.conf 是否有可用 nameserver（如 8.8.8.8 或内网 DNS）；测试 nslookup debian.org 或 dig google.com +short，看能否解析域名
- 若 resolv.conf 被 systemd-resolved 或 dhclient 覆盖，可固定配置：在 /etc/systemd/resolved.conf 中设置 DNS=，然后 systemctl restart systemd-resolved
检查防火墙和服务端口
外部无法访问服务（如 SSH、HTTP），不等于网络不通，可能是拦截或监听配置问题：
- 运行 sudo ufw status verbose（如果启用 UFW）或 sudo iptables -L -n -v 查当前规则，确认入站相关端口（如 22、80）未被 DROP
- 用 ss -tuln 或 netstat -tuln 查服务是否真在监听，比如 ss -tuln | grep :22；注意监听地址是 0.0.0.0（所有接口）还是 127.0.0.1（仅本地）
- 若服务启动但没监听，检查其配置文件（如 /etc/ssh/sshd_config 的 ListenAddress 和 Port）、日志（journalctl -u ssh）是否有绑定失败报错
抓包定位真实通信行为
前面都正常却仍不通？直接看数据包走向最可靠：
- 在服务器上运行 sudo tcpdump -i eth0 host 8.8.8.8 and port 53（替换为实际目标），观察 DNS 请求是否发出、是否有响应
- 若请求发出去但没回包，说明中间设备（路由器、宿主机、云平台安全组）可能丢弃了流量
- 对比客户端抓包（如 Wireshark）与服务器端结果，可明确问题是出在出向、入向，还是双向中断
不复杂但容易忽略：很多故障其实源于配置文件拼写错误（比如 address 写成 adress）、服务未 reload、或云服务器额外的安全组限制。动手前先看 journalctl -b | grep -i network，往往一行报错就指明了方向。
