服务器网络完全不通，九成是链路、防火墙或配置问题，按物理层→系统层→服务层→云平台层的顺序排查，大部分故障能在十分钟内定位。网络完全断连时，表象都是“连不上”，但根因可能藏在网线松动、IP冲突、安全组规则或路由表异常里，下面这套排查路径,覆盖了从硬件到云控制台的每一个常见故障点。
服务器网络完全不通，先看链路和本机状态
网络完全中断时，第一步不是去查代码或应用，而是确认物理链路和操作系统网络栈是否正常，多数情况下,问题出在最基础的环节。
检查网卡和物理连接状态
登录服务器控制台（带外管理或VNC），执行 ip addr 或 ifconfig 查看网卡状态。
- 网卡没有IP地址：说明DHCP获取失败或静态配置丢失，检查
/etc/network/interfaces或/etc/sysconfig/network-scripts/ifcfg-eth0。 - 网卡状态显示DOWN：执行
ip link set eth0 up手动拉起，若仍DOWN,大概率是硬件故障或驱动异常。 - 网卡有IP但无法通信：查看
ethtool eth0输出，确认Link detected为yes，若为no，检查网线、光模块或交换机端口。
物理链路正常后，再验证IP配置，用 ip addr show 确认IP、掩码、网关三段信息都正确，常见错误是子网掩码写错导致网关不可达，或IP与同网段其他机器冲突，内网环境中，IP冲突是“网络完全不通”的高频原因,因为ARP表会不断抖动。
验证网关和路由表是否正常
链路和IP没问题，接着查路由，执行 ip route show 查看默认网关。
- 没有default路由：手动添加
ip route add default via 网关IP dev eth0,然后测试。 - 有默认路由但ping网关不通：用
arping 网关IP检测二层连通性，若不通，说明交换机端口或VLAN配置有问题,需联系网络管理员。
ping网关通了，说明本机到局域网出口没问题，这时执行 ping 8.8.8.8 或 ping 114.114.114.114 测试外网连通性，外网通而域名不通，问题在DNS；外网也不通,问题在路由器或运营商链路。
服务器网络连接超时怎么办，用MTR定位丢包节点
当服务器能ping通网关但访问公网超时，或者客户端能连服务器但响应极慢，需要用路由追踪工具看数据包走到哪里断了，行业共识认为，MTR结合了ping和traceroute的功能,是排查网络质量最有效的工具。
MTR命令的实操用法
在服务器上执行 mtr -n -c 100 目标IP,观察每一跳的丢包率和延迟。
输出结果中,重点关注两个数据：
- Loss%列：如果某一跳持续丢包超过10%，且后续节点也丢包,说明该节点是瓶颈。
- Last和Avg列：延迟突然从个位数跳到数百毫秒,说明跨运营商或国际链路拥塞。
常见情况是，前几跳（自家机房和运营商接入层）一切正常，到了某个骨干节点延迟飙升，这种情况属于运营商网络路由问题，代码层面无法解决，处理方式是提工单给服务器供应商，要求优化路由,或改用BGP多线线路的服务器避开拥堵节点。
用traceroute区分方向性故障
MTR返回结果正常不代表双向都正常，客户端访问服务器慢，而服务器主动访问客户端却很快，说明是下行链路问题，反过来，服务器ping公网超时但客户端能连服务器,是上行或回程路由问题。
区分方向性的方法是：在客户端也运行一次mtr，对比两端数据，如果只有服务器端mtr显示丢包，说明服务器到目标方向的链路异常，如果两端都正常但业务还是卡顿,问题可能在防火墙策略或带宽跑满。
服务器网络故障排查工具清单，从ping到tcpdump
确认链路层和路由层没问题后，开始查端口和服务状态，这里按排查顺序列出最实用的工具,每个都有明确的使用场景。
- ping：测连通性，丢包率和延迟能反映基础链路质量，ping不通时，先ping网关再ping外网,缩小故障范围。
- telnet：测端口连通性，执行
telnet 服务器IP 端口，能连上说明端口开放且服务监听正常,连不上则要检查服务状态和防火墙。 - ss或netstat：查看本机监听端口，执行
ss -lntp，确认目标服务确实在监听0.0.0.0或对应内网IP，而不是只监听127.0.0.1。 - curl：测试HTTP/HTTPS服务，执行
curl -v http://服务器IP，能看出TCP握手是否完成、TLS证书是否有效、HTTP状态码是多少。 - tcpdump：抓包分析，最典型场景是服务器能ping通但业务连不上，执行
tcpdump -i eth0 port 服务端口，看是否有SYN包到达服务器，有SYN但没回包，是防火墙丢弃；没SYN到达,是链路或安全组拦截。
服务监听状态的具体判断标准
执行 ss -lntp 后，看到类似 0.0.0:80 这样带0.0.0的监听地址，表示服务对所有IP开放，如果只看到 0.0.1:80，说明服务只在本机回环地址监听,外部无法访问。
修复方式是检查服务配置文件，把监听地址改为 0.0.0 或 ，然后重启服务，MySQL、Redis、Nginx这类服务经常因为默认配置只监听本地,导致网络通但应用连不上。
服务本身没监听对应端口时，先确认服务是否正常启动，执行 systemctl status 服务名 查看运行状态，若服务频繁崩溃，查 /var/log/messages 或应用日志下的错误堆栈。
云服务器和物理机排查差异：安全组不是防火墙
如果用的是云服务器，网络完全不通时有一个特殊排查点：安全组规则，与传统物理服务器的iptables防火墙不同，云平台的安全组在虚拟化层生效,控制台和系统内部是隔离的。
安全组规则优先级判断逻辑
云服务器安全组规则按以下顺序生效：
- 入方向规则,决定外部能否访问服务器端口。
- 出方向规则,决定服务器能否访问外网。
- 规则优先级数值,数值越小优先级越高。
常见的“网络完全不通”场景是：创建实例时只放通了22端口，用户后续部署了80和443端口的Web服务，但没在控制台配置对应规则，此时服务器内部服务正常,但外部完全无法访问。
处理方式是登录云平台控制台，在“安全组”或“防火墙”菜单中添加入方向规则，放通TCP协议的80和443端口，注意，安全组规则修改实时生效，无需重启服务器。服务器租用和云服务器购买时，务必在开通后第一时间检查默认安全组规则是否覆盖了业务端口。
iptables和firewalld的叠加效应
云服务器内部的firewalld或iptables规则，与外层安全组是叠加关系，两者都要放行对应端口，否则仍会不通，执行 iptables -L -n 查看当前规则,确认没有DROP策略拦截。
排查顺序建议：先检查外层安全组，再检查系统防火墙，若安全组已放通但系统防火墙拦了端口，执行 systemctl stop firewalld 临时关闭测试，能通就说明是防火墙规则问题，再按需放行具体端口,而不是直接永久关闭防火墙。
对于自建机房的物理服务器，跳过安全组，直接检查交换机和硬件防火墙的端口配置，很多企业机房在服务器上架时会做端口ACL绑定，换IP或迁移机柜后,ACL没有同步更新就会导致断网。
服务器网络完全不通时的最后防线：重启网络栈
链路、路由、防火墙、安全组全都查了一遍仍无法定位时，可能是系统网络栈状态异常，这时候用重启大法,能解决相当一部分顽固问题。
重启网络服务的三种方式
不同操作系统版本,重启网络服务的命令有差异：
| 系统类型 | 重启命令 | 适用场景 |
|---|---|---|
| CentOS 7/RHEL 7 | systemctl restart network |
传统network服务管理 |
| CentOS 8+/RHEL 8+ | nmcli c reload 或 nmcli c up 连接名 |
NetworkManager管理 |
| Ubuntu 18.04+ | systemctl restart systemd-networkd |
新版netplan配置 |
| 通用方案 | ip addr flush dev eth0 && dhclient eth0 |
强制重新获取DHCP地址 |
执行重启后，观察网络状态是否恢复正常，若网络服务启动失败，记录报错信息，常见报错是“Job for network.service failed”，此时执行 journalctl -xe 查看详细原因,通常是配置文件语法错误或网卡名不匹配。
用带外管理渠道强制恢复网络
有一种场景是：服务器网络完全断开，SSH连不上，而外网端口和远程管理服务也恰好没放行，此时云服务器的Web控制台VNC和物理服务器的IPMI/KVM就是救命通道。
通过带外管理登录服务器后，优先检查路由表和DNS配置，如果因为误改 /etc/resolv.conf 导致域名解析失败，直接写入正确的DNS服务器地址，因为误删默认路由导致断网，执行 ip route add default via 网关IP 临时恢复，然后修正网络配置文件让配置持久化，多数情况下，通过带外管理进入系统修正配置后,网络能在几分钟内恢复。
服务器网络完全不通排查步骤的完整路径回顾
把整套排查逻辑压缩成一条主线：先看网卡亮不亮，再看IP通不通，然后看路由对不对，接着看端口听不听话，最后看云平台拦没拦。
网络完全不通时，不要慌，也不要盲目重启服务器，重启造成的业务中断时间更长，而且不一定能解决问题，按照链路层、系统层、云平台层的顺序逐步缩小范围,多数故障都能在十五分钟内定位。
云服务器先查安全组，物理服务器先查交换机和VLAN配置，这是两条快速分流的关键判断，如果一切检查都正常但网络仍不通，检查一下是否绑定了弹性公网IP,以及该IP是否处于解绑或回收状态。
服务器网络完全不通常见疑问解答
服务器网络完全不通，但ping网关通，外网不通，是什么问题？
默认网关到外网之间的链路故障，通常是运营商路由问题或机房出口防火墙拦截，先ping公网IP确认是否真的不通，再用MTR追踪到目标IP的路由路径，找出丢包或中断的节点，如果前几跳正常但后面全丢,联系服务器供应商反馈路由问题。
服务器能ping通但SSH连不上，排查顺序应该是什么？
先执行 telnet 服务器IP 22 看端口是否通，端口不通时，检查云平台安全组是否放行22端口，再在服务器本地执行 ss -lntp 确认sshd服务是否监听，最后查看 systemctl status sshd 或 /var/log/secure 日志。
云服务器和物理服务器网络故障排查最大的区别是什么？
云服务器多一层安全组控制，且网络配置由虚拟化平台管理，排查时必须先在控制台确认安全组和弹性公网IP配置，物理服务器则多出物理硬件故障和交换机端口配置两个变量，据工信部相关指南，云服务器网络故障的排查优先级应优先放在安全组和虚拟网络结构上,物理服务器则优先关注硬件链路和机房网络配置。