1. 先把虚拟机的网络模式捋清楚再决定静态IP往哪填装完 CentOS 7 虚拟机很多人第一件事就是打开/etc/sysconfig/network-scripts/ifcfg-ens33改BOOTPROTOstatic然后重启网络结果 SSH 断了、ping不通、心里一凉。我见过太多次这种情况了根子不在配置文件写得对不对而在于根本没确认虚拟机跑在哪种网络模式上。桥接模式、NAT 模式、仅主机模式这三种网关地址、网段来源、能不能上网完全是两码事照抄别人的教程大概率就是把 A 模式的网关填进了 B 模式的配置里。这篇文章面向的是刚接触 CentOS 7 虚拟机、或者之前一直用 DHCP 自动分配、现在想把 IP 固定下来的同学。我会把 VMware 侧的网段查看、网卡配置文件每个字段的含义、配置生效的两种方式、DNS 被覆盖这类经典问题以及实测中真正会卡住人的几个点全部拆开讲步骤都能直接照着敲。目标只有一个配完之后 IP 是固定的重启不丢宿主机能连外网能通。1.1 NAT、桥接、仅主机三种模式的本质差异先用一句话说清楚这三种模式的定位。桥接模式是把虚拟机的虚拟网卡直接接到你家的物理交换机或路由器的 LAN 口上虚拟机会从你家路由器拿一个和手机、笔记本同网段的地址对外部设备来说它就是一台独立的电脑。NAT 模式是 VMware 在宿主机上虚拟出一块 VMnet8 网卡和一个独立的私有网段虚拟机在这个私有网段里出去上网要经过宿主机的地址转换外部设备默认看不到它。仅主机模式更封闭只有宿主机能和虚拟机通信虚拟机上不了外网一般做离线实验用。这三种模式在配置文件里的最大区别就是网关GATEWAY和网段。桥接模式下网关通常是你家路由器的地址比如192.168.1.1NAT 模式下网关是 VMware 给 VMnet8 分配的地址通常是192.168.x.2。如果你在 NAT 模式里把网关填成192.168.1.1那路由表里指向的下一跳根本不在你的网段里包发不出去表现就是能 ping 通本机 IP、ping 不通网关。网络模式网段来源典型网关能否上外网宿主机能否访问虚拟机常见用途桥接物理路由器 DHCP路由器地址如 192.168.1.1能能直接访问集群、对外提供服务、模拟真实服务器NATVMware VMnet8192.168.x.2能经宿主机转发需端口映射个人学习、不宜占用真实网段仅主机VMware VMnet1192.168.x.1 附近不能能离线实验、纯内网测试这张表建议存下来以后每换一个环境先对照它确认自己在哪一栏再去写配置。我个人做实验环境基本都用 NAT原因是宿舍和公司的网段经常变桥接模式一换网络环境 IP 就废了NAT 的私有网段相对稳定。1.2 用几条命令摸清当前环境别凭记忆猜动手之前先在虚拟机里敲这几条命令把现状摸清楚ip addr # 看网卡名和当前拿到的地址 ip route # 看默认网关default via 后面那个 cat /etc/resolv.conf # 看当前用的 DNS nmcli device show ens33 # 看这块网卡被哪个连接管理、当前是 dhcp 还是 manualip addr的输出里你会看到类似2: ens33: BROADCAST,MULTICAST,UP,LOWER_UP这样一行ens33就是网卡名UP表示网卡已经启用。如果显示的是DOWN说明网卡没起来这时候改什么 IP 都没意义。下面的inet 192.168.126.128/24是当前 DHCP 分配到的地址/24就是子网掩码 255.255.255.0。ip route里如果有一行default via 192.168.126.2 dev ens33那192.168.126.2就是你现在这个环境的网关192.168.126.0/24就是你的网段。这个信息非常关键静态 IP 必须落在同一个网段里网关必须和它一致。很多教程里的192.168.1.x、192.168.10.x只是作者当时环境的示例直接抄下来必错。1.3 DHCP 在实验环境里迟早会给你添麻烦有人会问DHCP 用得好好的为什么非要改静态因为你迟早会遇到下面这些情况。你保存好的 SSH 会话第二天连不上了因为 IP 变了你在虚拟机里装了个 Web 服务或者数据库宿主机上的客户端配置写死了 IP重启一次全废你做了两台虚拟机搭集群节点之间靠 IP 互相注册重启后互认失败再比如你配了 NFS 挂载、Redis 主从、Docker 的-p映射只要 IP 一变全都要重来。更隐蔽的是地址冲突。实验室里几个人同时开机DHCP 池不够用或者有人手动写了个静态地址占用了池里的位置就会出现两台机器抢同一个 IP表现出来是网络时通时断排查起来非常痛苦。所以只要不是临时用完就删的机器我的习惯是第一时间改成静态 IP并把地址选在 DHCP 地址池之外。具体怎么避让下一节讲。2. VMware 侧的前置动作网段、地址池和克隆遗留问题很多人配静态 IP 失败问题不在 CentOS 里而在 VMware 的虚拟网络编辑器。CentOS 那边只是把 IP 写进配置文件真正决定这个 IP 能不能用、能不能出去上网的是 VMware 给这块虚拟网卡准备的网络环境。所以顺序应该是先在 VMware 里确认网段和地址池再回到 CentOS 里写配置最后验证。顺序反了就得来回改。2.1 打开虚拟网络编辑器看 VMnet8 的真实网段在 VMware Workstation 顶部菜单点“编辑”选“虚拟网络编辑器”。注意这一步需要管理员权限如果点开后是灰色的点右下角的“更改设置”按钮提权。打开之后你会看到一张列表里面有 VMnet0桥接、VMnet1仅主机、VMnet8NAT等。选中你实际使用的那一个通常是 NAT 模式对应的 VMnet8。下面会显示三块关键信息子网 IP 和子网掩码、NAT 设置里的网关地址、以及DHCP 设置里的起始和结束地址。我截图里记录的这台机器VMnet8 的子网是192.168.126.0掩码255.255.255.0NAT 网关是192.168.126.2DHCP 地址池是192.168.126.128到192.168.126.254。这些数字是因机而异的你必须在自己的 VMware 里看到实际值不能照搬。有些版本的 VMware 默认给的是192.168.10.0/24有些是192.168.240.0/24取决于安装时随机分配的结果。顺便说一下宿主机上会多出来的那块虚拟网卡。打开 Windows 的“网络连接”你会看到一个叫“VMware Network Adapter VMnet8”的适配器它的地址通常是192.168.126.1。这块网卡就是宿主机和虚拟机私有网段通信的入口如果你把它禁用了虚拟机虽然还能上网走 NAT 转发但宿主机就连不上虚拟机了。有些同学清理网络适配器时误删了它表现就是宿主机 ping 不通虚拟机重新在虚拟网络编辑器里点“还原默认设置”能恢复。2.2 静态地址怎么选避开 DHCP 池是第一条原则知道了 DHCP 池是192.168.126.128到192.168.126.254那静态地址就应该选在192.168.126.3到192.168.126.127这个区间里。我一般用.100这样的地址好记又不靠边。为什么不选.2因为那是网关地址占了会冲突。为什么不选.1那是宿主机侧的虚拟网卡地址。为什么不选.255那是广播地址。这里有个细节值得展开为什么一定要避开 DHCP 池。假设你把静态地址设成了192.168.126.200这个地址在 DHCP 池范围内。某天你先把虚拟机 A 关掉然后启动虚拟机 BB 通过 DHCP 恰好拿到了192.168.126.200。这时你再开 AA 用的是写死的192.168.126.200两台机器地址撞车。症状是 A 和 B 的网络都不稳定一会儿通一会儿不通ARP 表里同一个 IP 对应两个 MAC。这种问题不报错只能靠抓包或者看 ARP 才能发现特别浪费时间。地址用途能不能用作静态 IP192.168.126.1宿主机侧 VMnet8 虚拟网卡不能192.168.126.2NAT 网关不能192.168.126.3 ~ .127静态地址可用区间能192.168.126.128 ~ .254DHCP 地址池不建议192.168.126.255广播地址不能选定之后把这些值记下来后面写配置文件要用网段192.168.126.0/24、掩码255.255.255.0、网关192.168.126.2、目标静态地址比如192.168.126.100。2.3 克隆出来的虚拟机会带来 MAC、UUID、IP 三重冲突用 VMware 的“克隆”功能批量造机器是很常见的做法但克隆出来的虚拟机如果不处理会埋下三个雷。第一是MAC 地址如果克隆时选了“创建完整克隆”并勾选了重新生成 MAC这个没问题如果没勾两块网卡 MAC 相同交换机层面就会混乱。第二是配置文件里的 UUIDifcfg-ens33里的UUID字段如果两台机器一样NetworkManager 会认为这是同一个连接出现奇怪的行为。第三就是IP 地址本身克隆出来的机器IP和源机器一模一样必然冲突。我的处理流程是克隆后先在 VMware 里对每台机器的网卡执行一次“生成新的 MAC 地址”虚拟机设置 → 网络适配器 → 高级 → 生成然后在 CentOS 里用nmcli connection modify或直接改ifcfg文件把 IP 和 UUID 换掉主机名也一并改掉。UUID 可以直接用uuidgen命令生成一个也可以干脆把UUID那一行删掉让系统重新生成。主机名则用hostnamectl set-hostname node2修改别去手动改/etc/hostname之外的地方容易漏。3. CentOS 7 网卡配置文件的写法与逐字段拆解前面的准备工作做完才轮到真正改配置文件。CentOS 7 的网络配置文件放在/etc/sysconfig/network-scripts/目录下文件名格式是ifcfg-网卡名比如ifcfg-ens33。这一节我把完整的配置示例、每个字段的含义、以及三个最容易改错的字段单独拎出来讲。3.1 先确认网卡名到底是 ens33 还是 eth0CentOS 6 时代网卡叫eth0CentOS 7 默认启用了 biosdevname 和 net.ifnames 这两个机制网卡名变成了ens33、ens160、eno16777736这种形式。用ip addr或ls /etc/sysconfig/network-scripts/就能看到实际名字。有些老教程还在讲eth0如果你的机器是ens33而你照着eth0去改改的是一个不存在的文件当然不生效。顺便说一个很多人会问的点能不能改回eth0可以在 GRUB 的启动参数里加net.ifnames0 biosdevname0但我不推荐在生产或者学习环境里折腾这个。一来改了之后所有涉及网卡名的脚本、监控、防火墙规则都要跟着改二来这个改动对解决问题没有实际帮助属于纯粹的“习惯问题”。除非你有明确的历史包袱否则跟着系统默认走就好。ls /etc/sysconfig/network-scripts/ifcfg-* # 输出通常是 ifcfg-ens33 和 ifcfg-lo如果目录里出现了多个ifcfg-开头的文件指向同一块网卡那就是出过问题的痕迹需要清理掉多余的只保留一个有效的。3.2 ifcfg-ens33 每个字段的含义与取值下面是我实际在用的一个完整配置每一行都加了说明TYPEEthernet # 连接类型以太网固定写 Ethernet BOOTPROTOstatic # 关键static 表示使用静态地址dhcp 表示自动获取 DEFROUTEyes # 是否把这个连接设为默认路由 IPV4_FAILURE_FATALno # IPv4 配置失败时是否禁用整个连接 NAMEens33 # 连接名建议和网卡名保持一致 DEVICEens33 # 必须和实际网卡名完全一致 ONBOOTyes # 关键开机自动启用这块网卡 IPADDR192.168.126.100 # 你选定的静态地址 PREFIX24 # 前缀长度等价于 NETMASK255.255.255.0 GATEWAY192.168.126.2 # VMware VMnet8 的 NAT 网关 DNS1223.5.5.5 # 首选 DNS DNS2119.29.29.29 # 备用 DNS UUIDxxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx # 连接唯一标识逐条说几个容易踩坑的。BOOTPROTO有人写static有人写none这两个在 CentOS 7 里效果基本一致都表示不用 DHCP。但如果写dhcp又同时配了IPADDR结果就是地址会被 DHCP 覆盖掉你以为配了静态实际还是动态的这个坑很常见。ONBOOT必须改成yes。默认情况下 CentOS 7 安装时的网卡配置就是ONBOOTno很多人装完系统第一件事就是发现上不了网原因就是这个。改配置的时候如果这一行忘了改重启之后网卡不启用SSH 直接连不上还得回到 VMware 窗口里救。PREFIX和NETMASK是等价的写一个就行不要两个都写虽然写了也不会报错但会让配置文件看起来混乱。我习惯用PREFIX24因为现在 IPv6 时代用前缀更通用。DNS1和DNS2一定要写在 ifcfg 文件里不要直接去改/etc/resolv.conf。原因在 4.2 节详细说简单讲就是 NetworkManager 会重写resolv.conf你手写的会被冲掉。3.3 UUID、DEVICE、NAME 这三个字段为什么不能乱动DEVICE是硬件层面的绑定值必须和ip addr看到的网卡名一模一样。如果写错比如实际是ens33你写成ens34重启网络时会报错“找不到设备”网络起不来。这个错误信息在journalctl -u network或者/var/log/messages里能看到。NAME是 NetworkManager 里的连接名字正常情况下和DEVICE一致。如果你用nmcli con show看过会看到连接列表里的名字就是这个名字。改它不会导致网络不通但会让你用nmcli操作时找不到对不上号。UUID是最容易被忽视的一个。同一台机器上一个网卡对应一个 UUID克隆虚拟机、或者手工复制配置文件时如果没有同步修改会出现两个连接共享同一个 UUID 的情况NetworkManager 会随机激活其中一个导致你改的配置文件时灵时不灵。遇到这种诡异现象第一反应就是检查 UUID 是否重复。# 生成一个新的 UUID uuidgen # 或者直接问 NetworkManager 当前连接的信息 nmcli connection show ens33 | grep uuid如果实在不想管 UUID把它那一行从配置文件里删掉也可以NetworkManager 会自己生成一个。这个做法在个人实验环境里完全够用。4. 让配置生效的两种方式以及 DNS 被覆盖的经典问题配置文件写完只是存了个盘还没真正作用到内核的网络栈上。CentOS 7 里有两个东西在管网络传统的network服务和后来的NetworkManager。这两个同时存在、互相抢活是很多“改了不生效”“重启后又变回去”问题的根源。搞清楚用哪个、怎么重启能省掉一半的排查时间。4.1 systemctl restart network 还是 nmcli connection up先看你的机器上装了哪些服务systemctl status network # 传统网络服务 systemctl status NetworkManager # 现代网络管理服务CentOS 7 默认两个都装默认启用的是NetworkManagernetwork服务通常是启用的但由NetworkManager接管。这时候你有两种重启方式。第一种是传统方式systemctl restart network这条命令会把network服务重启让它重新读取ifcfg文件。它的好处是一条命令搞定坏处是如果你的机器同时启用了NetworkManager两个服务重启时会短暂争夺控制权偶尔出现“重启完了但没生效再等几秒才生效”的情况。第二种是nmcli方式我个人更推荐nmcli connection reload # 重新加载所有配置文件 nmcli connection up ens33 # 激活名为 ens33 的连接reload负责把磁盘上的配置文件读进内存up负责实际激活。整个过程只走NetworkManager一条链路不会有争抢。配合nmcli connection show ens33就能看到当前生效的 IP、网关、DNS一目了然。还有一个坑要提醒不要在 SSH 会话里执行ifdown ens33。这个命令会先把网卡关掉等你敲下一句ifup ens33之前SSH 已经断了命令也发不出去了。如果是通过 VMware 窗口在操作虚拟机没事如果是远程 SSH 就要先想好兜底方案比如用nohup或者(sleep 3; ifup ens33) 这种写法。稳妥的做法是提前准备好一条“网络挂了也能救回来”的后路保留一个 DHCP 的连接作为备用。可以用nmcli con add再加一个连接或者干脆在改之前把原配置文件备份一份出问题用 VMware 控制台恢复。4.2 resolv.conf 被 NetworkManager 覆盖是怎么回事这个问题的现象很典型你在/etc/resolv.conf里手动加了nameserver 223.5.5.5当时能用重启之后一看文件内容又变回去了或者被清空了。原因是 CentOS 7 的NetworkManager会接管这个文件根据各个连接的DNS1、DNS2字段自动生成。所以正确的做法是把 DNS 写进ifcfg文件的DNS1、DNS2字段而不是改resolv.conf。改了 ifcfg 之后NetworkManager 激活连接时会自动把这些 DNS 写进resolv.conf。如果你确实有特殊需求必须手动维护resolv.conf可以在/etc/NetworkManager/NetworkManager.conf的[main]段里加一行dnsnone然后重启 NetworkManager。这样它就不再接管这个文件了。至于网上流传的chattr i /etc/resolv.conf给文件加不可变属性我不建议新手用因为之后你想改却改不了的时候会很麻烦容易忘了解锁。判断 DNS 有没有生效用cat /etc/resolv.conf看有没有nameserver行再用nslookup www.baidu.com或ping -c 2 www.aliyun.com试试解析。注意ping报的错不一样Destination Host Unreachable是路由或网关问题Name or service not known是 DNS 问题两种错的排查方向完全不同。4.3 三步验证法按顺序排除问题配置生效后不要急着ping baidu.com网络排查应该由近到远一步一步来。下面这个顺序可以帮你快速定位问题出在哪一层。第一步确认本机地址绑上了ip addr show ens33 ping -c 2 192.168.126.100 # 自己 ping 自己第二步确认能到网关ping -c 2 192.168.126.2第三步确认能出外网用 IP 绕过 DNSping -c 2 223.5.5.5第四步确认域名解析正常ping -c 2 www.baidu.com卡在哪一步最可能的原因排查方向第一步失败网卡没启用或地址没绑上检查 ONBOOT、DEVICE 是否写对第二步失败网关填错或不在同网段对比 ip route 和实际网关第三步失败路由没生效或 NAT 服务异常检查 DEFROUTE、重启 NetworkManager第四步失败DNS 没生效或被覆盖检查 ifcfg 里的 DNS1/DNS2 和 resolv.conf我把这张表贴在笔记里配静态 IP 的时候对着走一遍基本五分钟内能定位问题。这个流程的价值在于它把“网络不通”这个模糊的问题拆成了四层每层只对应少数几个原因比漫无目的地重启服务高效得多。5. 实测中最容易卡住的五个坑和完整排查链路前面讲的是标准流程但实际动手时总会遇到各种意外。这一节我把这些年踩过、以及帮别人排查过的典型问题整理出来每一个都给出完整的排查链路而不只是结论。这样你以后遇到类似的症状也能自己顺着查下去。5.1 改完配置重启SSH 直接断了连不回来这是最高频的事故。排查链路应该是这样的先回到 VMware 的虚拟机窗口用本地终端登录因为网络已经没了SSH 进不去。登录后第一步看ip addr如果ens33那行显示的状态里没有UP说明网卡根本没启用多半是ONBOOTno没改或者DEVICE写错了。如果网卡是UP但没拿到地址用journalctl -xe或者systemctl status network看服务报错信息。常见的报错有“Error: Connection activation failed”“Device ens33 does not exist”前者通常是配置文件语法问题后者是网卡名写错。还有一种是配置文件格式问题比如IPADDR前面多了空格、值里混进了中文标点。用cat -A ifcfg-ens33可以把不可见字符都显示出来行尾应该是$如果看到M-BM-之类的乱码就是编码问题。我遇到过一次值后面跟了个中文空格肉眼完全看不出来用cat -A才现原形。经验上改网络配置之前先做三件事备份原文件、拍一个快照、确认自己能通过 VMware 窗口登录。这三条都做完出问题也就是回滚一下的事。5.2 IP 能 ping 通域名死活解析不了症状是ping 223.5.5.5通ping www.baidu.com报Name or service not known。链路很清晰网络层没问题卡在 DNS。第一步cat /etc/resolv.conf如果里面是空的或者只有nameserver 127.0.0.1那就是 DNS 没配。如果是空的说明ifcfg文件里没写DNS1或者写了但连接没重新激活。补上之后执行nmcli connection up ens33让配置重新生效再看resolv.conf。如果resolv.conf里有nameserver 127.0.0.1说明机器上跑了个本地 DNS 缓存服务比如 dnsmasq、systemd-resolved 的残留而那个服务没正常工作。检查systemctl status dnsmasq要么修好它要么直接在 ifcfg 里指定外部 DNS。还有一个小概率情况firewalld或者 iptables 规则把 53 端口封了。用firewall-cmd --list-all看一眼正常情况不会有针对 DNS 的拦截除非你之前手动加过规则。5.3 重启之后 IP 又变回去了现象是重启前ip addr看到的地址是对的重启后又变回 DHCP 分配的地址或者直接没地址。这种“改完不持久”的问题排查方向有三条。第一条是连接被NetworkManager覆盖。用nmcli connection show看当前所有连接如果发现有两个连接对应同一块网卡一个是dhcp一个是manual那就要把多余的那个删掉或者把autoconnect关掉。命令是nmcli connection delete 连接名。第二条是有多个ifcfg文件。ls /etc/sysconfig/network-scripts/ifcfg-*看看如果有ifcfg-ens33.bak这种文件注意备份文件的扩展名不能是系统会识别的格式否则可能被一起加载。正确做法是把备份放到别的目录或者用.bak但不要让它匹配ifcfg-*模式有些版本会忽略但不保险。第三条跟镜像有关。如果你用的是某些云服务商提供的 CentOS 7 镜像或者 cloud 镜像里面可能装了cloud-init它会在每次启动时根据元数据重新生成网络配置。这种情况下要改的是 cloud-init 的配置改ifcfg会被覆盖。检查systemctl status cloud-init就能确认。5.4 宿主机访问不到虚拟机里的服务你在一台 NAT 模式的虚拟机里跑了个 Web 服务监听 8080然后在宿主机的浏览器里访问http://192.168.126.100:8080打不开。这个问题有两层原因往往同时存在。第一层是 VMware 的 NAT 特性。NAT 模式下虚拟机可以主动访问外部但外部包括宿主机默认无法直接访问虚拟机虚拟机在这个私有网段里是“隐身”的。解决办法是在虚拟网络编辑器里选中 VMnet8点“NAT 设置”在弹出的对话框里点“添加”把宿主机的某个端口映射到虚拟机的192.168.126.100:8080。比如把宿主机 8888 映射到虚拟机 8080之后在宿主机访问http://127.0.0.1:8888就能通。桥接模式没这个问题因为虚拟机和宿主机在同一个真实网段直接可达。第二层是虚拟机的防火墙。CentOS 7 默认启用firewalld只放行了 SSH 等少数端口。执行firewall-cmd --list-all看ports那一栏如果 8080 不在列表里服务其实是通的但被挡在门外。放行命令是firewall-cmd --permanent --add-port8080/tcp firewall-cmd --reload如果加了端口还是不通再看SELinux。getenforce返回Enforcing就是开的。临时关闭用setenforce 0永久关闭改/etc/selinux/config里的SELINUXdisabled然后重启。我个人在实验环境里会临时setenforce 0来快速确认问题是不是 SELinux 引起的确认之后再决定是加策略还是保持关闭。5.5 克隆后 SSH 报 Host key 变更警告克隆出来的虚拟机和源机器 IP 相同SSH 客户端记录的指纹对不上连接时会报一大段红字警告REMOTE HOST IDENTIFICATION HAS CHANGED。第一次遇到会以为是安全问题其实只是同一 IP 换了台机器。解决办法是删掉本机known_hosts里对应的旧记录用ssh-keygen -R 192.168.126.100一条命令搞定。之后重新连接确认新指纹即可。如果之前用 Xshell、FinalShell 这类工具也要去工具里把旧会话的密钥删掉重新连接。从这个坑延伸出来一个习惯克隆虚拟机之后第一件事就是改主机名和 IP不要两台机器同时开着。我一般克隆完立刻改 IP 再开机避免地址冲突。6. 用 nmcli 偷懒以及这套配置后续怎么维护配置文件改熟了之后你会发现用nmcli比手改文件快得多尤其是需要配一批机器的时候。这一节讲讲工具化的做法和长期维护的一些习惯。6.1 一条命令改完静态 IPnmcli把改配置、生效、查看三步压缩成了两条命令非常适合记不住字段名的人nmcli connection modify ens33 \ ipv4.method manual \ ipv4.addresses 192.168.126.100/24 \ ipv4.gateway 192.168.126.2 \ ipv4.dns 223.5.5.5,119.29.29.29 nmcli connection up ens33第一条命令直接把值写进内存里的连接配置它同时会更新/etc/sysconfig/network-scripts/ifcfg-ens33文件所以你之后去看文件会发现已经被改好了。第二条命令重新激活让改动生效。用完对比一下ip addr和cat /etc/sysconfig/network-scripts/ifcfg-ens33你会看到文件的写法和你手改的几乎一样。我现在的习惯是临时调试用nmcli需要交付给别人或者写文档时手改文件两种方式产出的结果是一致的可以放心混用。6.2 批量部署时的模板化和冲突检测思路如果你要一次性配十台虚拟机一台一台改就太低效了。可以先把一份配好的ifcfg-ens33存成模板用脚本替换 IP 那几行#!/bin/bash BASE/etc/sysconfig/network-scripts for i in $(seq 101 110); do sed s/^IPADDR.*/IPADDR192.168.126.$i/ $BASE/ifcfg-ens33.tpl $BASE/ifcfg-ens33 nmcli connection reload nmcli connection up ens33 sleep 1 done这个脚本只是示意实际用的时候要注意两点。一是每台机器上执行完之后要确认新地址没有被占用。可以在改之前用ping -c 1 -W 1 192.168.126.$i快速探测一下有响应说明被占了。二是在批量环境下最好先规划好 IP 分配表把哪台机器用哪个地址记录下来避免几周后自己都记不清。我习惯在虚拟机宿主机上放一个文本文件格式是“主机名 - IP - 用途”简单但非常管用。6.3 改网络前的备份习惯和快照策略最后分享两个我认为最值钱的小习惯。第一改任何网络配置之前先把当前文件备份一份cp /etc/sysconfig/network-scripts/ifcfg-ens33 /root/ifcfg-ens33.$(date %F)放一份在/root下文件名带上日期。如果配置改挂了通过 VMware 窗口登录进去cp /root/ifcfg-ens33.2024-xx-xx /etc/sysconfig/network-scripts/ifcfg-ens33再重启网络就恢复了比重新回忆原来写了什么快得多。第二在 VMware 里改网络相关配置之前拍一个快照。尤其是虚拟机已经装了很多软件、环境配置很复杂的时候一个快照能省掉几个小时的重装时间。快照名字写清楚比如“改静态IP前”别写成“snapshot1”过两周自己都忘了是什么。还有个进阶玩法是保留一个 DHCP 备胎连接。在nmcli里再建一个连接交换机名换成ens33-dhcp配置成ipv4.method autoautoconnect no。当静态 IP 那套出问题时用nmcli connection up ens33-dhcp临时切回动态能立刻恢复网络去查资料查完再切回来。这个思路我在几台实验机上一直在用比在操作系统界面里手忙脚乱地改文件从容多了。网络配置这件事本质上不是背字段而是理解“虚拟机在哪个网段、网关是谁、DNS 谁在管”这三个问题。把这三件事想清楚剩下的就是照着字段填。我自己在配了几十台 CentOS 7 之后最大的体会是每次动手前多花两分钟确认 VMware 侧的网段和地址池比事后排查半小时要划算得多。