老实说只要管过 CentOS 7 的运维十有八九都撞见过这个场景虚拟机刚开机右上角网络图标是个叉或者 ssh 进去想装个东西yum install 一跑就是一大串 Could not resolve host随后要么无限卡住要么直接报错退出。这个“没网络 yum 失败”的组合拳几乎是所有 Linux 新手都会遇到的坎。我这些年排查这类问题不下几十次从虚拟机到物理机都碰过今天就把完整的排查思路、修复步骤、以及那些文档里不会写的坑一次性摊开讲清楚。这篇文章适合谁看刚接触 CentOS 7 的初学者、在公司维护内网服务器的新手运维还有那些被虚拟机网络搞得一头雾水、正准备重新装系统的朋友。看完你会明白这类问题大多不是系统坏了而是网卡、路由、DNS、yum 源这四层里某一层出了岔子。只要按顺序排查基本上都能在十分钟内救回来。1. 故障边界先判断是网络断了还是 yum 源挂了1.1 报错不一样故障点完全不一样很多人一看见 yum 报错就急着换源这其实是本末倒置。yum 失败只是表象根因可能是网络不通也可能是源失效两者处理方式截然不同。先把报错类型分清楚才能少走弯路。最常见的几类报错信息对应关系大致是这样的报错特征典型信息大概率故障点域名解析失败Could not resolve host: mirrors.aliyun.comDNS 配置有问题或上行链路不通连接超时Connection timed out / Failed to connect网络不通、防火墙拦截、镜像站不可达连接被拒绝Connection refused目标端口未监听或仓库地址本身不对找不到路由No route to host网关配置错误或路由表缺失证书错误SSL certificate problem / Peers Certificate issuer is not recognized系统时间不对或证书链更新滞后举个例子如果跑 yum install 立刻报 Could not resolve host那基本可以断定是 DNS 层面的问题和 yum 源本身没关系如果报 Failed to connect那就要先确认 ping 能不能通、防火墙有没有挡。很多新手一看到 yum 失败就去找源换完还是报错就是因为没搞明白报错背后的真正含义。1.2 我习惯用的“三连测”定位法遇到这种问题我不会直接改配置而是先花两分钟做一组快速测试把故障边界圈出来。第一步ping 网关ping -c 3 192.168.188.2这里换成你实际的网关地址。网关通了说明物理链路和网卡基本没问题网关不通问题大概率出在网卡配置或者虚拟网络设备上。第二步ping 公网 IPping -c 3 223.5.5.5IP 能通但域名不通说明网络通了是 DNS 解析的问题IP 也不通说明路由或者外网出口有问题。第三步用 curl 试探镜像站curl -I --connect-timeout 5 http://mirrors.aliyun.com/centos/这一步直接验证 yum 源到底能不能访问。能返回状态码说明源没坏问题在缓存或者 repo 配置连不上那就是网络层还有东西没解决。这三步跑完基本就能确定问题在哪一层了。后面的修复工作才有针对性。2. 网络层排查网卡、路由、DNS、防火墙逐个过关2.1 网卡配置里最容易被忽视的 ONBOOTCentOS 7 的网卡配置文件在 /etc/sysconfig/network-scripts/ 目录下文件名一般是 ifcfg-eth0 或者 ifcfg-ens33。打开之后重点看两个字段ONBOOT 和 BOOTPROTO。vim /etc/sysconfig/network-scripts/ifcfg-ens33ONBOOT 这个字段决定了系统启动时要不要激活这张网卡。默认值在很多环境里是 no尤其是虚拟机模板和克隆出来的系统这个字段经常是关着的。系统起来了网卡却没被激活你当然没网络。这是 CentOS 7 没网络问题里最高频的原因没有之一。BOOTPROTO 字段则决定 IP 怎么来。如果是在 VMware、VirtualBox 这类环境里用 NAT 模式最简单省事的方式是直接改成 DHCP 自动获取BOOTPROTOdhcp ONBOOTyes如果公司内网要求固定 IP那就得改成 static 或者 none同时补上 IPADDR、PREFIX、GATEWAY、DNS1 这些字段。改完之后重启网络服务让配置生效systemctl restart network systemctl status network这里提前打个预防针执行 systemctl restart network 的时候如果终端输出类似 “Job for network.service failed” 的报错别慌后面第 4 章有专门讲这个坑。总之记住ONBOOTyes 是底线很多所谓的“网卡起不来”其实就是这一行没写。2.2 网关和路由表的坑比你想的更多网卡配置没问题但依然上不了网下一个怀疑对象就是路由。用一条命令看当前默认路由ip route show default正常输出应该是类似default via 192.168.188.2 dev ens33 proto static metric 100如果没有 default 开头的行说明系统根本没有默认路由数据包不知道往哪儿送。这种情况要么是 GATEWAY 字段没写要么写了但网卡没正确加载。多网卡场景下的坑更隐蔽。服务器上有两块网卡比如内网网卡和备份网卡同时处于活动状态系统有时会把默认路由指向其中一块不该走的网卡上。判断方法很简单看路由表里带 default 的那条 dev 后面的设备名是不是你真正要用的那张网卡。ip route show table all如果默认路由走错了网卡可以用 ip route 命令临时纠正ip route del default ip route add default via 192.168.188.2 dev ens33这个方法不写配置文件重启就失效但用来应急、验证“是不是路由问题”很有效。确认是路由问题之后再去修改网卡配置文件里的 GATEWAY并重启网络服务才是正确的持久化做法。2.3 DNS 解析异常yum 第一个遭殃网络通、路由也对但 yum 还是报 Could not resolve host那基本就是 DNS 的问题了。在 CentOS 7 上DNS 配置最常见的坑是你改了 /etc/resolv.conf结果一重启网络文件就被 NetworkManager 重写了或者你干脆没配 DNS1 字段。最简单的验证方法是用 getent 直接测解析getent hosts mirrors.aliyun.com如果没有输出说明解析失败。再检查当前实际的解析配置cat /etc/resolv.conf如果里面只有一行 nameserver而且指向 127.0.0.1 之类的本地地址却并没有起本地 DNS 服务那解析必然失败。正确的做法是把 DNS 配到网卡配置文件里而不是直接改 resolv.conf。这样重启网络后NetworkManager 会按照网卡配置重新生成 resolv.conf配置不会被冲掉。DNS1223.5.5.5 DNS2114.114.114.114配置好后重启网络服务再 ping 一下域名试试。这里有个小经验很多人喜欢用 8.8.8.8但在国内网络环境下这个地址经常被干扰时通时不通。我自己更习惯用 223.5.5.5 和 114.114.114.114解析速度稳定对国内镜像站的解析结果也更准确。2.4 防火墙和 SELinux两个“隐藏拦截者”网络配置看着都正常但就是连不上外网还得考虑防火墙。CentOS 7 默认是装了 firewalld 的虽然出方向网络默认放行但万一有人改过规则或者之前配置过一些复杂的富规则出方向的流量也可能被挡。排查方式很简单systemctl status firewalld firewall-cmd --state如果是 running 状态而你已经排除了其他所有可能可以临时停掉试试systemctl stop firewalld注意这只是临时关闭重启系统会恢复。如果确认是防火墙的问题再去动规则不要一直裸奔着跑服务。至于 SELinux说实话它对纯出方向网络连接的影响很小但的确存在某些场景下因为文件上下文标签不对导致服务起不来、端口不监听的情况。遇到 yum 报错和网络问题叠加的时候可以用 setenforce 0 临时切到 Permissive 模式做对照测试但不建议长期关闭毕竟生产环境你不想把自己暴露在风险里。3. yum 源修复从失效的默认源切换到国内镜像3.1 为什么 CentOS 7 的 yum 用了几年突然就废了如果你在网上搜“centos7 yum 源”大概率会看到 2024 年之后的大量求助帖。原因其实很明确CentOS 7 在 2024 年 6 月 30 日已经正式停止维护官方软件仓库里那些 mirrorlist 链接彻底失效不再返回可用的镜像列表。你执行 yum makecache 的时候系统会去请求 mirrorlist.centos.org而这个地址已经退役了自然拿不到元数据。这个问题最典型的报错是Could not retrieve mirrorlist http://mirrorlist.centos.org/?release7archx86_64repoosinfrastock error was 14: curl#6 - Could not resolve host: mirrorlist.centos.org就算网络完全正常这个报错也会一直出现。很多朋友以为是自己网络坏了折腾了大半天才发现是源的问题。所以当你的网络明明通着ping 外网也返回正常yum 却一直报错的时候先去查看系统时间和源配置再考虑网络问题。打开 CentOS-Base.repo 看一下就会发现问题cat /etc/yum.repos.d/CentOS-Base.repo默认文件里写的是 mirrorlist 开头的一行。只要这行指向的是 mirrorlist.centos.org那基本就没救了必须换成可用的镜像源。3.2 换阿里云源的具体步骤照着做就行我个人的建议是既然 CentOS 7 已经 EOL与其折腾官方 vault 源不如直接换成国内活跃维护的镜像站。阿里云、清华、腾讯、华为都有 CentOS 7 的镜像但配置逻辑大同小异。下面以阿里云为例完整走一遍。先把原 repo 文件备份别直接删以防后悔mkdir -p /etc/yum.repos.d/bak mv /etc/yum.repos.d/*.repo /etc/yum.repos.d/bak/然后下载新的 Base 源配置curl -o /etc/yum.repos.d/CentOS-Base.repo https://mirrors.aliyun.com/repo/Centos-7.repo如果你的系统连 curl 都还没装最小化安装有时确实没有可以用 wget再不行就从能联网的机器上把文件下载后传过来。拿到 repo 文件后确认一下里面的 baseurlgrep baseurl /etc/yum.repos.d/CentOS-Base.repo正常情况下会看到baseurlhttps://mirrors.aliyun.com/centos/$releasever/os/$basearch/ ...$releasever 和 $basearch 是系统变量yum 在运行时自动替换成 7 和 x86_64不需要手工改。接下来清理缓存并重建yum clean all yum makecache这一步如果顺利跑完你会看到类似 “metadata cache created” 的输出。然后验证一下仓库列表yum repolist能看到 base、extras、updates 三个仓库都带着数量说明源已经可以正常用了。这时候再去安装软件比如 yum install -y vim就能顺畅跑完。如果你还需要 EPEL 源里面有大量常用软件包可以再下载一份curl -o /etc/yum.repos.d/epel.repo https://mirrors.aliyun.com/repo/epel-7.repo之后再 makecache 一次。注意EPEL 源和 Base 源必须同时可用否则某些软件依赖拉不齐。3.3 彻底没网的环境用本地 ISO 搭个离线源有些内网服务器完全隔离外网连镜像站都访问不了。这种情况下再怎么污染源都没用必须走本地源方案。核心思路很简单把 CentOS 7 的安装 ISO 挂载到系统里做成一个 file:// 协议的 yum 源。假设你有 CentOS-7-x86_64-Minimal-2009.iso把它上传到服务器或者直接插光驱。先挂载mkdir -p /mnt/cdrom mount -o loop /path/to/CentOS-7-x86_64-Minimal-2009.iso /mnt/cdrom如果用的是虚拟机光驱可以简化成mount /dev/cdrom /mnt/cdrom然后创建本地源配置文件vim /etc/yum.repos.d/local.repo写入以下内容[local] nameLocal CentOS 7 ISO baseurlfile:///mnt/cdrom enabled1 gpgcheck0保存后清理缓存yum clean all yum makecache这种离线源有个明显短板ISO 里带的软件包只是安装介质的基础集合远不如在线源全。很多软件还是会提示找不到包。所以这个方案主要用来解决基础依赖和紧急安装场景想让它完全替代在线源是不现实的。4. 高频坑实录重启网络失败、VMware 断网、证书过期4.1 修改网卡后重启网络直接报错怎么办改完网卡配置执行 systemctl restart network 时经常看到这样的报错Job for network.service failed because the control process exited with error code.遇到这个先别急着瞎猜。看日志才是正路journalctl -u network -e --no-pager日志里最常见的信息是Bringing up interface ens33: Error: Connection activation failed: No suitable device found for this connection.这句话的意思是配置文件名是 ifcfg-ens33但系统在硬件层面找不到对应的网卡设备。这种情况经常出现在克隆虚拟机之后——原本的网卡是 eth0你复制出来的系统里网卡被识别成 ens33 或者 enp2s0但配置文件还叫 ifcfg-eth0或者反过来。解决办法是先用 ip addr 看真实的网卡名然后修改配置文件名和里面的 DEVICE 字段让两边对得上。还有一个高频问题NetworkManager 和 network 服务互相冲突。CentOS 7 里两套网络管理工具默认都在如果你一会儿用 nmcli 修改一会儿又手动改配置文件重启 network很容易出现配置不一致。我的习惯是二选一要么全用 NetworkManager 管理用 nmcli 命令操作不再碰 network 服务要么停掉 NetworkManager老老实实用配置文件。混用是自找麻烦。4.2 VMware 和 VirtualBox 里的虚拟机网络特殊问题虚拟机里没网络往往和宿主机虚拟网络配置有关属于最容易让人崩溃的一类问题。VMware 的 NAT 模式下虚拟机的网关要指向 VMware 虚拟网络的网关地址不是宿主机局域网的路由器地址。常见的默认网关是 192.168.x.2具体要打开 VMware 的“虚拟网络编辑器”确认。DNS 可以临时用网关地址顶上通网后再换正式 DNS。桥接模式下虚拟机会被当作宿主机所在局域网里的一台独立设备IP 必须和宿主机同网段网关也是局域网的网关。VirtualBox 的 NAT 模式默认网关一般是 10.0.2.2DNS 可以配 10.0.2.3。这个和 VMware 完全不一样直接抄 VMware 的配置是行不通的。云服务器比如各大云厂商的 ECS出现“没网络”的情况排查重点反而在控制台安全组出方向规则、实例是否绑定了公网 IP、网络 ACL 是否放行。这些在系统内部看不到很多运维新手在服务器里折腾半天最后发现是安全组没放行白忙一场。4.3 换了新源还是 yum 失败多半是时间和证书的问题这个坑我踩过好几次在这里多说两句。更换源配置后yum makecache 仍然报错而且报错里带了 SSL certificate problem 字样那基本可以断定是系统时间和现实时间差太远。https 连接要校验证书有效期你系统时间如果停在 2020 年访问 2024 年的镜像站证书自然校验失败。解决办法很简单date -s 2025-01-01 12:00:00或者装 chrony 做时间同步yum install -y chrony systemctl start chronyd systemctl enable chronyd时间同步完成后再跑一次 yum makecache大概率就通了。这个坑之所以隐蔽是因为很多人看到 SSL 报错就以为是网络加密问题完全没想到是系统时钟在捣鬼。4.4 其他会让你怀疑人生的“小毛病”多仓库冲突系统里残留了多个 repo 文件比如 CentOS-Base.repo、epel.repo 还有各种第三方的 repo相互之间版本冲突导致 makecache 报错。处理方式是统一整理到备份目录只留自己需要的。yum lock 被占用报错 “Another app is currently holding the yum lock”。后台有 yum 进程卡死了用 ps -ef | grep yum 找到进程 IDkill 掉再把 /var/run/yum.pid 删掉。repo 文件里的 gpgcheck 问题如果源本身没有开启 GPG 签名但配置里写的是 gpgcheck1yum 就会报签名验证失败。可以查看源文件里的 gpgkey 是否存在确实没有签名的话临时改成 gpgcheck0测试用可以生产环境要谨慎。DNS 被 NetworkManager 反复覆盖明明 resolv.conf 改好了重启网卡又变回原样。解决方法是把 DNS 写进网卡配置文件的 DNS1 字段或者在 nmcli 里设置 ipv4.dns 参数。5. 我的排障习惯和小技巧排查了这么多最后分享几个我常年用的习惯希望能让你少踩几个坑。第一每次排查都按“网卡 → 网关 → DNS → yum源”的顺序走不跳步。这个顺序是我被坑多了总结出来的。先确认基础网络通不通再谈源的问题不要一上来就换源否则问题根源可能永远找不到。第二用几条命令快速定位把排查过程变成肌肉记忆ip addr ip route show default getent hosts mirrors.aliyun.com curl -I --connect-timeout 5 http://mirrors.aliyun.com这四条命令跑完80% 的问题都能锁定在一个很小的范围内。剩下 20% 再看日志用 journalctl 配合系统消息基本都能找到线索。第三important每次修改配置文件之前先备份原文件。这个习惯看起来笨但真的能救命。尤其是在生产环境里出了问题可以直接回滚不至于让业务多停一分钟。第四如果你想长期管理 CentOS 7 这类存量系统建议把常用的网络命令整理成自己的速查表ip addr、ip route、nmcli、ethtool、ss、journalctl、yum repolist。这些命令平时不常用真到用的时候又容易手忙脚乱有张速查表看着心里不慌。最后说点实际的体会。CentOS 7 作为一个个已经走到生命周期末端的系统它的问题不会越来越少只会以各种意想不到的方式冒出来。但只要你掌握了“网络层定位 源修复”这套方法论绝大多数问题都能在半小时内解决。我见过太多朋友一遇到这类问题就想着重装系统其实完全没有必要。冷静下来按顺序排查你会发现所谓“没网络 yum 失败”的组合拳其实就是纸老虎。