企业官网建设流程全解析

1. 先把虚拟机的网络模式捋清楚，再决定静态IP往哪填

装完 CentOS 7 虚拟机，很多人第一件事就是打开/etc/sysconfig/network-scripts/ifcfg-ens33改BOOTPROTO=static，然后重启网络，结果 SSH 断了、ping不通、心里一凉。我见过太多次这种情况了，根子不在配置文件写得对不对，而在于根本没确认虚拟机跑在哪种网络模式上。桥接模式、NAT 模式、仅主机模式这三种，网关地址、网段来源、能不能上网完全是两码事，照抄别人的教程，大概率就是把 A 模式的网关填进了 B 模式的配置里。

这篇文章面向的是刚接触 CentOS 7 虚拟机、或者之前一直用 DHCP 自动分配、现在想把 IP 固定下来的同学。我会把 VMware 侧的网段查看、网卡配置文件每个字段的含义、配置生效的两种方式、DNS 被覆盖这类经典问题，以及实测中真正会卡住人的几个点全部拆开讲，步骤都能直接照着敲。目标只有一个：配完之后 IP 是固定的，重启不丢，宿主机能连，外网能通。

1.1 NAT、桥接、仅主机三种模式的本质差异

先用一句话说清楚这三种模式的定位。桥接模式是把虚拟机的虚拟网卡直接接到你家的物理交换机（或路由器的 LAN 口）上，虚拟机会从你家路由器拿一个和手机、笔记本同网段的地址，对外部设备来说它就是一台独立的电脑。NAT 模式是 VMware 在宿主机上虚拟出一块 VMnet8 网卡和一个独立的私有网段，虚拟机在这个私有网段里，出去上网要经过宿主机的地址转换，外部设备默认看不到它。仅主机模式更封闭，只有宿主机能和虚拟机通信，虚拟机上不了外网，一般做离线实验用。

这三种模式在配置文件里的最大区别就是网关（GATEWAY）和网段。桥接模式下网关通常是你家路由器的地址，比如192.168.1.1；NAT 模式下网关是 VMware 给 VMnet8 分配的地址，通常是192.168.x.2。如果你在 NAT 模式里把网关填成192.168.1.1，那路由表里指向的下一跳根本不在你的网段里，包发不出去，表现就是能 ping 通本机 IP、ping 不通网关。

这张表建议存下来，以后每换一个环境，先对照它确认自己在哪一栏，再去写配置。我个人做实验环境基本都用 NAT，原因是宿舍和公司的网段经常变，桥接模式一换网络环境 IP 就废了，NAT 的私有网段相对稳定。

1.2 用几条命令摸清当前环境，别凭记忆猜

动手之前，先在虚拟机里敲这几条命令，把现状摸清楚：

ip addr # 看网卡名和当前拿到的地址 ip route # 看默认网关（default via 后面那个） cat /etc/resolv.conf # 看当前用的 DNS nmcli device show ens33 # 看这块网卡被哪个连接管理、当前是 dhcp 还是 manual

ip 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（仅主机）、VMnet8（NAT）等。选中你实际使用的那一个，通常是 NAT 模式对应的 VMnet8。下面会显示三块关键信息：子网 IP 和子网掩码、NAT 设置里的网关地址、以及DHCP 设置里的起始和结束地址。

我截图里记录的这台机器，VMnet8 的子网是192.168.126.0，掩码255.255.255.0，NAT 网关是192.168.126.2，DHCP 地址池是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 关掉，然后启动虚拟机 B，B 通过 DHCP 恰好拿到了192.168.126.200。这时你再开 A，A 用的是写死的192.168.126.200，两台机器地址撞车。症状是 A 和 B 的网络都不稳定，一会儿通一会儿不通，ARP 表里同一个 IP 对应两个 MAC。这种问题不报错，只能靠抓包或者看 ARP 才能发现，特别浪费时间。

选定之后把这些值记下来，后面写配置文件要用：网段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 相同，交换机层面就会混乱。第二是配置文件里的 UUID，ifcfg-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 还是 eth0

CentOS 6 时代网卡叫eth0，CentOS 7 默认启用了 biosdevname 和 net.ifnames 这两个机制，网卡名变成了ens33、ens160、eno16777736这种形式。用ip addr或ls /etc/sysconfig/network-scripts/就能看到实际名字。有些老教程还在讲eth0，如果你的机器是ens33而你照着eth0去改，改的是一个不存在的文件，当然不生效。

顺便说一个很多人会问的点：能不能改回eth0？可以，在 GRUB 的启动参数里加net.ifnames=0 biosdevname=0，但我不推荐在生产或者学习环境里折腾这个。一来改了之后所有涉及网卡名的脚本、监控、防火墙规则都要跟着改；二来这个改动对解决问题没有实际帮助，属于纯粹的“习惯问题”。除非你有明确的历史包袱，否则跟着系统默认走就好。

ls /etc/sysconfig/network-scripts/ifcfg-* # 输出通常是 ifcfg-ens33 和 ifcfg-lo

如果目录里出现了多个ifcfg-开头的文件指向同一块网卡，那就是出过问题的痕迹，需要清理掉多余的，只保留一个有效的。

3.2 ifcfg-ens33 每个字段的含义与取值

下面是我实际在用的一个完整配置，每一行都加了说明：

TYPE=Ethernet # 连接类型，以太网固定写 Ethernet BOOTPROTO=static # 关键：static 表示使用静态地址，dhcp 表示自动获取 DEFROUTE=yes # 是否把这个连接设为默认路由 IPV4_FAILURE_FATAL=no # IPv4 配置失败时是否禁用整个连接 NAME=ens33 # 连接名，建议和网卡名保持一致 DEVICE=ens33 # 必须和实际网卡名完全一致 ONBOOT=yes # 关键：开机自动启用这块网卡 IPADDR=192.168.126.100 # 你选定的静态地址 PREFIX=24 # 前缀长度，等价于 NETMASK=255.255.255.0 GATEWAY=192.168.126.2 # VMware VMnet8 的 NAT 网关 DNS1=223.5.5.5 # 首选 DNS DNS2=119.29.29.29 # 备用 DNS UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx # 连接唯一标识

逐条说几个容易踩坑的。BOOTPROTO有人写static，有人写none，这两个在 CentOS 7 里效果基本一致，都表示不用 DHCP。但如果写dhcp又同时配了IPADDR，结果就是地址会被 DHCP 覆盖掉，你以为配了静态，实际还是动态的，这个坑很常见。

ONBOOT必须改成yes。默认情况下 CentOS 7 安装时的网卡配置就是ONBOOT=no，很多人装完系统第一件事就是发现上不了网，原因就是这个。改配置的时候如果这一行忘了改，重启之后网卡不启用，SSH 直接连不上，还得回到 VMware 窗口里救。

PREFIX和NETMASK是等价的，写一个就行，不要两个都写，虽然写了也不会报错，但会让配置文件看起来混乱。我习惯用PREFIX=24，因为现在 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 默认两个都装，默认启用的是NetworkManager，network服务通常是启用的但由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]段里加一行dns=none，然后重启 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 绕过 DNS）：

ping -c 2 223.5.5.5

第四步，确认域名解析正常：

ping -c 2 www.baidu.com

我把这张表贴在笔记里，配静态 IP 的时候对着走一遍，基本五分钟内能定位问题。这个流程的价值在于它把“网络不通”这个模糊的问题拆成了四层，每层只对应少数几个原因，比漫无目的地重启服务高效得多。

5. 实测中最容易卡住的五个坑和完整排查链路

前面讲的是标准流程，但实际动手时总会遇到各种意外。这一节我把这些年踩过、以及帮别人排查过的典型问题整理出来，每一个都给出完整的排查链路，而不只是结论。这样你以后遇到类似的症状，也能自己顺着查下去。

5.1 改完配置重启，SSH 直接断了连不回来

这是最高频的事故。排查链路应该是这样的：先回到 VMware 的虚拟机窗口，用本地终端登录，因为网络已经没了，SSH 进不去。登录后第一步看ip addr，如果ens33那行显示的状态里没有UP，说明网卡根本没启用，多半是ONBOOT=no没改，或者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-port=8080/tcp firewall-cmd --reload

如果加了端口还是不通，再看SELinux。getenforce返回Enforcing就是开的。临时关闭用setenforce 0，永久关闭改/etc/selinux/config里的SELINUX=disabled然后重启。我个人在实验环境里会临时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 一条命令改完静态 IP

nmcli把改配置、生效、查看三步压缩成了两条命令，非常适合记不住字段名的人：

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=.*/IPADDR=192.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 auto，autoconnect no。当静态 IP 那套出问题时，用nmcli connection up ens33-dhcp临时切回动态，能立刻恢复网络去查资料，查完再切回来。这个思路我在几台实验机上一直在用，比在操作系统界面里手忙脚乱地改文件从容多了。

网络配置这件事，本质上不是背字段，而是理解“虚拟机在哪个网段、网关是谁、DNS 谁在管”这三个问题。把这三件事想清楚，剩下的就是照着字段填。我自己在配了几十台 CentOS 7 之后，最大的体会是：每次动手前多花两分钟确认 VMware 侧的网段和地址池，比事后排查半小时要划算得多。