1. 一次深夜告警引发的排查复盘凌晨两点机房值班的同事发来消息一台跑了三年多的 CentOS 7 业务机重启之后彻底失联ping 不通、SSH 连不上只能通过带外管理口进去看。登进去一看系统本身活得好好的登录正常、磁盘正常、CPU 内存都没异常唯独网络不通。ip addr一看网卡没有 IPsystemctl status network一看服务是 failed 状态。手动systemctl restart network一把网络立刻恢复业务也跟着回来了。这个场景我相信做过运维的人都遇到过而且不止一次。CentOS 7 启动后网络服务挂掉是一个非常经典、非常高频、也非常容易被忽视的问题。它不像磁盘满了、内存爆了那样有明确的告警它往往是重启之后才发现而重启这件事本身就意味着你可能已经失去了远程排查的手段。更麻烦的是这类问题有时候是偶发的——你重启十次可能只挂一次但就是那一次可能发生在最不该发生的时间点。这篇文章我想把这个问题彻底讲透。从 CentOS 7 的网络管理机制讲起说清楚为什么网络服务会在启动后挂掉再给出可复现的排查路径和修复方案最后分享一些我在实际环境里踩过的坑和总结出来的预防手段。不管你是刚接触 Linux 运维的新手还是已经管着几十上百台机器老手这篇内容应该都能给你一些可以直接抄作业的东西。需要先说明一点CentOS 7 的网络管理体系和 CentOS 6 有本质区别和现在主流的 CentOS Stream、Rocky、Ubuntu 也不一样。CentOS 7 默认用的是传统的network.service也就是network-scripts那一套同时 systemd 又引入了NetworkManager。这两套东西如果配置不当就会互相打架这是很多网络启动问题的根源。理解这一点后面的排查才有方向。2. CentOS 7 网络服务机制拆解2.1 network.service 与 NetworkManager 的双轨制CentOS 7 最让人困惑的地方就是它同时存在两套网络管理服务。一套是传统的network.service配置文件在/etc/sysconfig/network-scripts/ifcfg-*另一套是NetworkManager.service它也能读取同样的 ifcfg 文件但管理逻辑完全不同。默认情况下CentOS 7 最小化安装后network.service是 enabled 的NetworkManager也是 enabled 的。这就埋下了一个隐患两个服务都想管同一块网卡谁先起来、谁说了算取决于启动顺序和配置。如果两个服务对同一块网卡的处理结果不一致就可能出现服务显示启动成功但网卡没 IP或者服务直接 failed的情况。我个人的建议很明确在一台机器上只保留一套网络管理服务。要么用network.service要么用NetworkManager不要两个都开着。对于传统的服务器环境尤其是用 ifcfg 文件静态配置 IP 的场景我倾向于禁用 NetworkManager只用 network.service行为最可预测。# 查看两个服务的状态 systemctl status network systemctl status NetworkManager # 如果决定只用 network.service systemctl stop NetworkManager systemctl disable NetworkManager systemctl enable network注意禁用 NetworkManager 之前确认你的网络配置不依赖它。比如某些云主机的元数据服务、某些动态网络配置场景是依赖 NetworkManager 的。盲目禁用可能导致网络彻底起不来。2.2 启动顺序与依赖关系network.service在 systemd 里的启动时机是在基本系统初始化之后、多用户目标之前。它依赖network-pre.target并且被network.target所依赖。听起来很规整但问题在于如果网卡驱动加载慢、或者网卡本身在启动时还没就绪network.service就会启动失败。这种情况在虚拟化环境里特别常见。比如某台虚拟机挂载了多块网卡其中一块是后来热添加的或者网卡绑定了 SR-IOV、bonding、teaming 这类需要额外初始化时间的特性。系统启动时network.service尝试去配置这块还没准备好的网卡就会报错退出。还有一个容易被忽略的点NetworkManager-wait-online.service。这个服务的作用是等待网络真正可用很多依赖网络的服务比如 NFS 挂载、某些数据库会依赖它。如果网络服务本身挂了这个 wait-online 服务会一直等到超时拖慢整个启动过程严重的时候能拖几分钟。2.3 ifcfg 文件的关键参数要理解网络服务为什么挂必须看懂 ifcfg 文件。一个典型的静态 IP 配置长这样TYPEEthernet BOOTPROTOstatic DEFROUTEyes NAMEens33 DEVICEens33 ONBOOTyes IPADDR192.168.1.100 PREFIX24 GATEWAY192.168.1.1 DNS1223.5.5.5这里面有几个参数是排查问题的关键ONBOOTyes这个必须为 yes否则开机不会自动启用这块网卡。很多人手动配完网卡忘了改这个重启就失联。BOOTPROTO可以是static、dhcp、none。如果写成dhcp但环境里没有 DHCP 服务器网卡会一直等 DHCP 超时表现为网络服务启动很慢甚至失败。DEVICE和NAME这两个要和实际网卡名一致。CentOS 7 用了可预测网卡命名ens33、eno1 这种如果你从 CentOS 6 迁移过来配置里还写着 eth0那肯定起不来。UUID有时候复制虚拟机或者克隆系统ifcfg 文件里的 UUID 会重复导致网络服务行为异常。我见过最离谱的一个案例某台机器 ifcfg 文件里HWADDR写的是旧网卡的 MAC 地址换了网卡之后没更新结果 network.service 启动时找不到匹配的网卡直接 failed。这种问题不看日志根本想不到。3. 网络服务挂掉的六大典型原因3.1 网卡名与配置文件不匹配这是最高频的原因没有之一。CentOS 7 引入可预测网卡命名之后网卡名从 eth0 变成了 ens33、eno1、enp0s3 这种。如果你是从旧系统迁移、或者手动复制了别人的配置文件DEVICE 和 NAME 对不上实际网卡名网络服务就会启动失败。排查方法很简单# 查看实际网卡名 ip link show # 或者 ls /sys/class/net/ # 查看配置文件里的 DEVICE grep DEVICE /etc/sysconfig/network-scripts/ifcfg-*两边一对不一致就是问题所在。修复方式是把 ifcfg 文件里的 DEVICE 和 NAME 改成实际网卡名同时文件名也要对应比如ifcfg-ens33。3.2 ONBOOT 被改成 no这个坑我踩过。有一次为了临时禁用一块网卡把ONBOOTyes改成了no后来忘了改回来重启之后那块网卡没起来而业务恰好走的是那块网卡。排查的时候第一反应是网络服务挂了其实是配置本身就没让它开机启动。ONBOOTno的表现和网络服务挂掉很像网卡存在、驱动正常、但就是没 IP。区别在于systemctl status network可能是 active 的只是那块网卡没被启用。所以排查时一定要先确认 ONBOOT 的值。3.3 DHCP 获取超时或失败如果BOOTPROTOdhcp而网络环境里 DHCP 服务器不可达、或者 DHCP 地址池耗尽网卡会一直处于获取地址的状态。network.service默认会等待一段时间超时后可能报 failed也可能显示 active 但网卡没 IP。这种情况在云环境里尤其常见。某些云主机的 IP 是通过 DHCP 下发的如果 DHCP 服务本身出问题或者网卡的 DHCP 请求被安全组、防火墙拦了就会卡住。排查思路# 查看 DHCP 客户端日志 journalctl -u network -b | grep -i dhcp # 手动触发 DHCP 看结果 dhclient -v ens33如果手动 dhclient 能拿到地址说明 DHCP 服务本身没问题可能是启动时机的问题如果手动也拿不到那就是 DHCP 服务或网络链路的问题。3.4 NetworkManager 与 network 冲突前面提过两个服务同时管一块网卡会打架。典型表现是systemctl status network显示 active但ip addr看不到 IP或者 network 服务启动时报Device ens33 is already managed by NetworkManager之类的错误。判断方法# 看 NetworkManager 是否在管这块网卡 nmcli device status # 如果显示 ens33 是 connected 或 managed说明 NM 在管解决办法就是二选一。要么禁用 NetworkManager要么把网卡从 NM 的管理中排除在 ifcfg 文件里加一行NM_CONTROLLEDno。3.5 网卡硬件或驱动问题这个相对少见但一旦遇到就很棘手。网卡本身故障、驱动没加载、或者 PCI 设备在启动时没被正确识别都会导致网络服务起不来。排查# 看网卡是否被内核识别 lspci | grep -i ethernet dmesg | grep -i eth dmesg | grep -i ens # 看驱动是否加载 lsmod | grep -i e1000 lsmod | grep -i virtio如果 lspci 能看到网卡但 ip link 看不到多半是驱动问题。虚拟化环境里常见的是 virtio 驱动没装好或者 VMware 的 vmxnet3 驱动缺失。3.6 配置文件语法错误ifcfg 文件虽然简单但也有语法要求。比如等号两边不能有空格、值不能加引号某些字段除外、不能有中文标点。我见过有人从网页复制配置把英文冒号复制成了中文冒号结果网络服务死活起不来日志里报的错还很模糊。排查方法# 用 network-scripts 自带的检查工具 systemctl status network -l # 或者直接看详细日志 journalctl -xe -u network日志里通常会指出是哪一行、哪个参数有问题。4. 从失联到恢复的完整排查流程4.1 带外管理是最后的救命稻草网络挂了、SSH 连不上这时候你唯一的手段就是带外管理。物理机用 IPMI、iDRAC、iLO虚拟机用宿主机的控制台或者云服务商的 VNC。这一步没什么技术含量但必须提前准备好。我见过太多人平时不配带外、不记带外地址真出事的时候抓瞎。提示带外管理口本身也可能依赖网络配置建议带外口和业务口走不同的网络路径避免一挂全挂。4.2 登录后先确认系统状态进到系统之后不要急着重启网络服务先做一轮快速体检# 系统是否正常 uptime dmesg | tail -50 # 网卡是否被识别 ip link show lspci | grep -i ethernet # 网络服务状态 systemctl status network systemctl status NetworkManager # 看启动日志 journalctl -b -u network这一轮下来基本能定位到问题的大方向是网卡没识别、还是服务没起来、还是配置有问题。4.3 手动拉起网络并观察报错确认系统正常后手动启动网络服务重点看报错信息systemctl restart network如果报错仔细读。常见的报错和含义报错信息含义处理方向Device ens33 does not seem to be present网卡名不对或网卡没识别检查网卡名和驱动Bringing up interface ens33: Error: Connection activation failed配置有问题或 NM 冲突检查 ifcfg 和 NM 状态Determining IP information for ens33... failedDHCP 获取失败检查 DHCP 服务或改静态RTNETLINK answers: File exists路由或 IP 冲突检查是否有重复配置4.4 逐层验证网络连通性网络服务起来之后不要以为就完事了要逐层验证# 第一层网卡有没有 IP ip addr show ens33 # 第二层能不能 ping 通网关 ping -c 3 192.168.1.1 # 第三层能不能解析 DNS nslookup www.example.com # 第四层能不能访问外网 curl -I https://www.example.com这四层任何一层不通问题范围就缩小了。比如有 IP 但 ping 不通网关可能是 VLAN、交换机端口、或者 ARP 问题能 ping 通网关但解析不了 DNS就是 DNS 配置问题。4.5 固化修复结果并验证重启问题解决之后一定要做一次重启验证。很多人修完当下能用就不管了结果下次重启又挂。重启验证是确认修复是否真正生效的唯一标准。# 重启前先确认配置 cat /etc/sysconfig/network-scripts/ifcfg-ens33 # 重启 reboot # 重启后第一时间检查 ip addr systemctl status network ping -c 3 网关如果重启后网络正常才算真正修好。如果还是挂说明根因没找对回到前面的步骤继续排查。5. 高频问题速查与避坑经验5.1 常见问题速查表现象可能原因快速验证解决网卡无 IP服务 failed网卡名不匹配ip link对比 ifcfg改 DEVICE/NAME网卡无 IP服务 activeONBOOTnogrep ONBOOT改为 yes启动卡很久后 failedDHCP 超时journalctl -u network改静态或修 DHCP服务 active 但无 IPNM 冲突nmcli device status禁用 NM 或加 NM_CONTROLLEDno网卡完全不显示驱动/硬件问题lspci、dmesg装驱动或换网卡配置改了不生效语法错误systemctl status network -l修正语法5.2 我踩过的三个坑第一个坑克隆虚拟机后 UUID 重复。用模板克隆出来的机器ifcfg 文件里的 UUID 是一模一样的。单机看没问题但在某些网络管理逻辑里UUID 重复会导致网卡识别混乱。解决办法是删掉 UUID 那一行或者用uuidgen重新生成一个。第二个坑改了网卡名但没改文件名。ifcfg 文件的文件名和里面的 DEVICE 最好保持一致。我试过文件名是ifcfg-ens33但 DEVICE 写的是ens34结果 network 服务启动时行为诡异有时候能起有时候不能。后来统一改成一致就稳了。第三个坑防火墙规则导致 DHCP 失败。有一次在机器上配了 iptables 规则把 DHCP 的 UDP 67/68 端口给拦了结果重启后 DHCP 拿不到地址。这种问题特别隐蔽因为防火墙规则本身是正常的只是和 DHCP 冲突了。排查的时候要看iptables -L和firewall-cmd --list-all。5.3 预防性配置建议与其等出问题再排查不如提前做好预防。以下是我在生產环境里固定会做的几件事统一网络管理服务明确用 network 还是 NetworkManager不要两个都开。关键机器配静态 IP除非有完善的 DHCP 高可用否则服务器一律静态 IP。保留带外管理通道物理机配好 IPMI/iDRAC虚拟机记好控制台入口。变更前备份配置改 ifcfg 之前先cp一份出问题能快速回滚。重启验证纳入流程任何网络配置变更都要经过一次重启验证才算完成。监控网络服务状态用监控系统盯住network.service的状态和网卡 IP异常及时告警。6. 自动化检测脚本与长期防护6.1 一个开机自检脚本与其每次出问题手动排查不如写个脚本在开机后自动检查网络状态发现问题自动尝试修复并记录日志。下面这个脚本我用了很久逻辑简单但很实用#!/bin/bash # net-check.sh - 开机网络自检脚本 # 放在 /usr/local/bin/ 下通过 systemd 或 cron reboot 调用 LOG/var/log/net-check.log IFACE$(ls /sys/class/net/ | grep -E ^(ens|eno|enp) | head -1) echo $(date) - 开始网络自检网卡: $IFACE $LOG # 检查网卡是否有 IP IP$(ip addr show $IFACE | grep -oP inet \K[\d.]) if [ -z $IP ]; then echo $(date) - 网卡 $IFACE 无 IP尝试重启网络服务 $LOG systemctl restart network sleep 5 IP$(ip addr show $IFACE | grep -oP inet \K[\d.]) if [ -z $IP ]; then echo $(date) - 重启网络服务后仍无 IP请人工介入 $LOG exit 1 else echo $(date) - 网络服务重启成功当前 IP: $IP $LOG fi else echo $(date) - 网卡 $IFACE 状态正常IP: $IP $LOG fi # 检查网关连通性 GW$(ip route | grep default | awk {print $3}) if [ -n $GW ]; then if ping -c 2 -W 2 $GW /dev/null 21; then echo $(date) - 网关 $GW 连通正常 $LOG else echo $(date) - 网关 $GW 不可达 $LOG fi fi这个脚本的核心思路是开机后检查网卡有没有 IP没有就尝试重启网络服务还不行就记录日志等人工处理。它不能解决所有问题但能覆盖网络服务偶发启动失败这一类场景把机器从失联状态拉回来。6.2 用 systemd 单元固化自检把脚本挂到 systemd 上比 cron reboot 更可靠因为可以控制启动顺序和依赖# /etc/systemd/system/net-check.service [Unit] DescriptionNetwork Self Check Afternetwork.target Wantsnetwork.target [Service] Typeoneshot ExecStart/usr/local/bin/net-check.sh RemainAfterExityes [Install] WantedBymulti-user.target启用chmod x /usr/local/bin/net-check.sh systemctl daemon-reload systemctl enable net-check.service这样每次开机网络自检都会在 network.target 之后运行检查并尝试修复网络状态。6.3 监控层面的长期防护脚本是兜底监控才是长期防护。我一般会在监控系统里配这几条规则network.service状态不是 active 就告警关键网卡的 IP 地址发生变化或消失就告警到网关的 ping 延迟或丢包率超过阈值就告警系统 uptime 重置说明重启了就触发一次网络状态检查这几条规则配合起来基本能在网络出问题的第一时间发现而不是等业务方来报障。7. 一些个人体会CentOS 7 虽然已经进入维护末期但存量环境依然巨大很多企业的核心业务还跑在上面。网络服务启动失败这个问题看起来是个小问题但它发生在重启之后这个特殊时间点往往意味着你已经失去了远程手段排查成本极高。我个人的经验是这类问题的重点不在修复而在预防。修复本身通常就是改个配置、重启个服务的事几分钟就能搞定但发现问题的过程、恢复访问的过程可能耗费几个小时。所以与其研究怎么修不如把精力放在怎么让它不出问题、以及出了问题怎么快速发现上。具体来说统一网络管理服务、关键机器用静态 IP、配好带外管理、加一个开机自检脚本、监控盯住网络状态这几件事做下来能把这类问题的发生概率和影响范围都压到很低。剩下的偶发情况有自检脚本兜底也基本能自动恢复。最后分享一个小技巧如果你不确定某台机器的网络配置改完会不会出问题可以先不重启而是用systemctl restart network模拟一次。如果重启网络服务后网络正常那重启系统大概率也没问题如果重启网络服务就挂了那说明配置本身有问题先别重启系统把配置改对再说。这个习惯帮我避免了好几次重启即失联的尴尬。