企业官网建设流程全解析

简介：针对Ubuntu Server 20.04默认采用netplan管理网络、而部分用户更习惯Network Manager灵活配置的情况，这份PDF技术文档给出了完整的接管方案。内容面向Linux运维与服务器管理人员，系统讲解如何安装network-manager、将NetworkManager.conf中managed改为true、调整netplan渲染器为NetworkManager，并通过netplan apply与systemctl restart使配置生效。文档还整理了nmcli常用操作，如查看设备状态、列出与激活连接，便于后续进行DHCP、无线及有线网络的动态切换。资源共1个PDF文件，压缩包约25KB，内容精炼适合快速查阅，也适合需要动态网络配置或希望摆脱纯命令行编辑配置的用户作为参照。目前已有5253人学习下载，是服务器网络配置场景中一份实用的技术资料。

1. 先搞清楚NetworkManager和netplan的分工：为什么要"接管"

Ubuntu Server 20.04 默认用netplan管理网络，底层渲染器是systemd-networkd。很多人想换成NetworkManager，结果直接在/etc/network/interfaces里改配置，或者把managed改成true就以为完事了，重启后SSH直接断。这篇要解决的是一个具体问题：怎么把网络管理权从netplan+networkd切换到NetworkManager，同时保证IP不丢、连接不断、配置可回滚。适合刚接触Ubuntu Server、被netplan的YAML语法折腾过、又需要用nmcli查Wi-Fi或做动态网络切换的从业者。读完你不仅能完成切换，还能在翻车时自己把网络救回来。

2. 安装与启用：从netplan到NetworkManager的切换实录

2.1 安装network-manager：一条命令背后的依赖关系

在干净的Ubuntu Server 20.04上，默认没有安装network-manager这个包。直接在SSH会话里执行：

sudo apt update sudo apt install network-manager -y

第一行命令刷新软件源索引，避免系统拿着过期的包列表去解析依赖；第二行的-y参数跳过交互确认，防止安装过程卡在"是否继续"的提示上。安装时apt会自动带上依赖包，包括libnm、ModemManager等，这些是为Wi-Fi和移动宽带场景准备的，体积不大，不需要手动剔除。

有个常见的疑问是装完network-manager之后要不要再装network-manager-cli，实际上nmcli工具已经包含在network-manager包里了。装完建议用dpkg -l network-manager和nmcli --version确认版本，Ubuntu Server 20.04官方源里对应的版本通常在1.22.10左右，这个版本跟netplan的配合已经比较成熟。

注意：如果是在最小化安装或者裁剪过的容器镜像里操作，可能缺少systemctl服务文件。安装完成后执行一次systemctl daemon-reload，否则service列表里看不到network-manager，后面restart会报错。

安装完先别急着改配置，看一眼服务当前状态，执行systemctl status network-manager。如果显示inactive或者failed，说明服务还没接管任何接口，这正是动手改配置的最佳时机。如果是active状态也不用慌，只要还没改netplan，NetworkManager默认不会碰你已经配置好的网卡。

2.2 修改NetworkManager.conf：managed参数到底管什么

打开NetworkManager的主配置文件：

sudo vim /etc/NetworkManager/NetworkManager.conf

默认内容如下：

[main] plugins=ifupdown,keyfile [ifupdown] managed=false

需要把managed改成true：

[main] plugins=ifupdown,keyfile [ifupdown] managed=true

这里要解释清楚managed参数的作用范围。它控制的是NetworkManager是否接管/etc/network/interfaces里定义的接口。在Ubuntu Server上，interfaces文件通常是空的，但NetworkManager默认依然不会去碰任何未被自己创建的接口。改成true之后，NetworkManager会对所有内核可见的物理网卡进行管理，包括之前在netplan里配置过的以太网口。

有一个普遍存在的误区：觉得managed=true改完就万事大吉了。实际上这个参数只管ifupdown插件这一条路径，而netplan生成的配置是走另一条路径交给NetworkManager的。所以下面的netplan配置修改一步都不能跳过，两个文件是配合关系，不是替代关系。

另外注意[main]段里的plugins行，如果看到除ifupdown、keyfile之外还有别的插件，不要随手删掉。在纯服务器场景里保持默认就好，多删一个插件可能导致NetworkManager无法识别已有连接，后续nmcli connection show里什么都看不到。

2.3 改netplan配置：renderer切换的本质

找到netplan配置文件，通常叫01-netcfg.yaml或者类似的名字：

sudo vim /etc/netplan/01-netcfg.yaml

切换前的内容大概长这样：

network: version: 2 renderer: networkd ethernets: ens33: dhcp4: true

切换后只需要保留核心声明：

network: version: 2 renderer: NetworkManager

关键在renderer字段。netplan本身不直接实现网络功能，它只负责把YAML翻译成后台服务能读懂的配置。renderer改成NetworkManager之后，netplan生成的配置会落到/etc/NetworkManager/system-connections/目录，以keyfile格式存在，而不是之前的systemd-networkd配置文件。

有个细节容易被忽略：如果YAML里保留着ethernets段，netplan依然会为那块网卡生成一份连接配置。这在多数情况下不会出问题，但如果你希望后续完全由nmcli接管IP、DHCP、DNS的设置，更干净的做法是只留renderer行，把ethernets段注释或删掉。否则每次netplan apply都可能用旧地址覆盖掉你用nmcli做的修改，形成配置打架。

改完先做语法预检，不要直接apply：

sudo netplan generate sudo netplan try --timeout=30

netplan try会让新配置在30秒内生效，如果这期间没有收到确认，自动回滚到上一个可用配置。这是防止SSH断连最有效的一招。确认输出显示配置正常后再执行apply，顺序问题下一章展开。

3. 应用与验证：netplan apply之后发生了什么

3.1 应用配置的正确顺序

网上很多教程的顺序是乱的，有人先重启network-manager再netplan apply，结果网卡直接消失。我实际操作下来，正确的顺序是：

sudo netplan apply sudo systemctl restart network-manager

如果前面已经用netplan try确认过配置无误，这里直接执行apply即可。netplan apply的作用是重新读取YAML、生成底层配置并触发应用。当renderer是NetworkManager时，netplan会把新的keyfile写入system-connections目录，然后通知NetworkManager重新加载连接。

但netplan的通知机制有时候不可靠，尤其是刚从networkd切到NetworkManager的第一个配置周期，服务可能没监听到文件变化。所以紧接着重启network-manager服务，强制所有接口按新配置重新走一遍接管逻辑，这样状态才稳定。

反过来执行会碰到什么情况？NetworkManager先启动，发现设备还没被释放，于是标记为unmanaged，等netplan apply之后设备的归属已经乱了，需要nmcli device reapply手动救回来。顺序问题不是玄学，是两个服务加载时序的真实差异。

3.2 用nmcli验证接管是否成功

配置应用完后，第一件事是看设备状态：

nmcli device status

输出是一个表格，重点看STATE列。如果显示connected，说明网卡已经被NetworkManager正常管理。如果显示unmanaged或者disconnected，说明接管没有完成，回到第2章检查managed参数和renderer配置。

接着看连接配置：

nmcli connection show

切换成功后，这里会出现类似Wired connection 1的连接条目。后面做静态IP、DHCP修改时，引用的就是这个NAME字段，注意不是网卡名ens33之类的DEVICE字段，这两个概念在nmcli里完全不同，搞混了会报"unknown connection"。

3.3 网卡状态和路由的完整验证

用传统命令确认实际效果：

ip addr show ip route show

对比切换前后的输出，确认IP地址、子网掩码、默认网关没有丢失。特别是默认路由，如果default via那行不见了，说明NetworkManager没有正常应用网关配置，需要回过去检查连接配置里的ipv4.gateway字段。

DNS验证容易被漏掉。Ubuntu Server上netplan阶段用的DNS是交给systemd-resolved处理的，切换后NetworkManager会自动往resolved写入配置。用resolvectl status看一下当前DNS，如果还是旧地址，执行systemctl restart systemd-resolved再查一次。

这张表可以作为切换完成后的验收清单，每一行都过一遍再继续往下操作。

4. 用nmcli管理连接：静态IP和DHCP的配置案例

4.1 查看现有连接和设备对应关系

接管成功之后，日常管理基本都围着nmcli转。先看清楚当前的连接和设备关系：

nmcli connection show --active nmcli -f NAME,DEVICE,TYPE connection show

-f参数用来指定输出字段，NAME是连接配置的名字，DEVICE是实际绑定的网卡，TYPE是连接类型（ethernet、wifi等）。修改连接时用的是NAME，不是DEVICE名。很多人在这一步把ens33当成连接名去执行nmcli connection up ens33，结果直接报错，因为ens33是设备名，不是连接名。

如果系统里有多个连接配置，可以用nmcli connection show --active只看当前活跃的那几个。调整网络前先确认自己在改哪个连接，这个习惯能省掉大半的配置错乱问题。

4.2 配置静态IP的完整命令

假设连接名叫Wired connection 1，要配成静态IP，执行：

sudo nmcli connection modify "Wired connection 1" \ ipv4.method manual \ ipv4.addresses 192.168.1.50/24 \ ipv4.gateway 192.168.1.1 \ ipv4.dns "223.5.5.5 8.8.8.8"

逐项说明参数含义：ipv4.method manual表示关闭DHCP、启用静态配置；ipv4.addresses里192.168.1.50是IP地址，/24是子网掩码，这个前缀不能省略，否则NetworkManager不知道网段范围；ipv4.gateway是默认网关地址，必须跟IP在同一个网段内；ipv4.dns可以填多个DNS，用空格分隔，整体加引号防止shell拆成多个参数。

执行完这条命令后，配置只是写进了keyfile文件，还没有真正下发到网卡。需要激活连接使配置生效：

sudo nmcli connection up "Wired connection 1"

如果执行后IP没立刻变化，先检查连接是否处于活跃状态。nmcli modify在连接活跃时支持热更新，但某些场景下需要先down再up，比如改了网卡的MAC地址或者VLAN设置。遇到IP不生效的情况，最直接的办法是：

sudo nmcli connection down "Wired connection 1" sudo nmcli connection up "Wired connection 1"

4.3 DHCP和DNS切换的实操

切回DHCP比配静态简单：

sudo nmcli connection modify "Wired connection 1" ipv4.method auto sudo nmcli connection up "Wired connection 1"

ipv4.method auto表示使用DHCP获取地址，同时之前手动设置的ipv4.gateway和ipv4.dns会被清空，因为DHCP服务器会下发这些信息。如果你不想让DHCP下发的DNS覆盖本地配置，再加一行参数：

sudo nmcli connection modify "Wired connection 1" ipv4.ignore-auto-dns true

这个参数在混合网络环境里很有用。比如公司内网DHCP下发的DNS解析不了外网域名，但静态配置里又指定了公共DNS，设成true之后NetworkManager会优先使用手动配置的DNS，忽略DHCP下发的DNS。反过来想恢复默认行为，把true改成false即可。

5. 接管过程的常见问题与避坑排查

5.1 问题：网卡显示unmanaged，IP地址全没了

现象：执行nmcli device status，状态列显示unmanaged，ip addr里网卡上没有任何地址。

原因：最常见的是两个配置文件只改了一个。要么netplan里的renderer还是networkd，要么NetworkManager.conf里的managed还是false。这两处是配合关系，缺一个NetworkManager都不碰那块网卡。

解决：按顺序排查。先看/etc/netplan/*.yaml里renderer是不是NetworkManager，再看/etc/NetworkManager/NetworkManager.conf里managed是不是true。确认无误后执行netplan apply，再systemctl restart network-manager。注意是先apply再重启服务，顺序反了可能出现unmanaged残留。

5.2 问题：SSH断开后连不上，服务器失联

现象：远程修改网络配置，执行netplan apply之后当前SSH会话立刻掉线，之后ping不通这台机器。

原因：这个场景通常不是NetworkManager本身的问题，而是新配置里IP地址变了，或者网关配错导致网络不可达。很多人图省事直接netplan apply，跳过了netplan try的30秒确认期，配置错误时没有自动回滚的机会。

解决：如果机器有IPMI或物理控制台，登录进去用ip addr看当前地址。网卡有地址但路由不对，用nmcli connection modify改网关，别急着改整个YAML。没有带外控制台的话，只能安排现场处理，这也是我反复强调用netplan try的原因。

预防：所有涉及远程网络的变更，先netplan try --timeout=30试一遍，确认不会断连再apply。timeout可以按需加大到60秒，给足确认时间。

5.3 问题：IP地址反复跳变，重启后跟设置的不一样

现象：静态IP配置好后过一段时间变成DHCP分配的地址，或者重启后IP不是自己在nmcli里设置的值。

原因：netplan的YAML里既有renderer行又有ethernets段，netplan每次generate都会生成一份keyfile配置文件，把你用nmcli做的修改覆盖掉。两个配置来源作用于同一块网卡时，后执行的会赢，表现就是IP来回跳。

解决：切换完成后，把netplan的ethernets段彻底删掉，只留最小化的renderer声明。之后的IP、DHCP、DNS全部交给nmcli管，不要混用两种配置来源。如果已经出现覆盖，重新用nmcli connection modify设置一遍，然后nmcli connection up激活。

5.4 问题：NetworkManager服务启动失败，日志报keyfile解析错误

现象：systemctl status network-manager显示active (failed)，日志里出现无法打开或解析某个连接配置文件的记录。

原因：多半是手动编辑过/etc/NetworkManager/system-connections/目录下的文件，YAML格式或者INI格式写错了，或者文件权限不对。NetworkManager对这个目录权限要求严格，连接文件的owner必须是root，权限位不能开放给其他用户读写。

解决：先看具体是哪个文件报错：

sudo nmcli connection show

报错的连接不会出现在列表里。把出问题的文件删掉或者修复权限：

sudo chmod 600 /etc/NetworkManager/system-connections/* sudo systemctl restart network-manager

如果是格式问题，用nmcli connection reload让NetworkManager重新读取配置，比重启服务快，也不会中断当前活跃的连接。

6. 让NetworkManager接管更顺滑：备份与验证的技巧

6.1 把关键配置沉淀成文件，不靠记忆

nmcli命令式的修改是一次性的，适合临时调整。想沉淀配置，可以把连接导出：

sudo nmcli connection show "Wired connection 1" > /root/network-backup/conn.txt sudo cp -r /etc/NetworkManager/system-connections/ /root/network-backup/

system-connections目录里的keyfile可以看到完整的IP、DNS、权限位设置。备份这个目录等于给网络配置吃了颗后悔药，后续在哪台机器上复现同样配置，直接把文件拷过去、改一下网卡名、重启服务就行。

6.2 切换前记录基线，回滚只用两步

动手之前，把当前网络配置完整记下来：

mkdir -p /root/network-backup cp /etc/netplan/*.yaml /root/network-backup/ ip addr > /root/network-backup/ip-addr-before.txt ip route > /root/network-backup/ip-route-before.txt

回滚时只需要把备份的YAML拷回去，把renderer改回networkd，执行netplan apply重启一次网卡即可。这套基线记录在切换后第二天验证仍然有用，能快速对比出配置漂移。

我第一次在机房远程切换时就是直接netplan apply翻的车，那台机器没有带外管理，最后只能安排人现场接显示器处理。从那以后我每次改服务器网络配置都强制先走一遍netplan try加备份这套流程，确认无误才动手。NetworkManager接管本身不复杂，坑全在操作顺序和配置来源上，先验证再执行，希望帮到你。

本文还有配套的精品资源，点击获取