简介针对 Ubuntu Server 20.04 默认使用 netplan 管理网络、但部分运维场景需要 NetworkManager 接管的需求这份 PDF 文档提供了从安装到切换的完整操作指南。内容围绕安装 network-manager、修改 NetworkManager.conf 启用托管、将 netplan renderer 改为 NetworkManager、执行 netplan apply 并重启服务等关键环节展开同时附有 nmcli 常用命令示例适合负责 Linux 服务器网络配置的运维人员、系统管理员以及需要接入 DHCP、无线等动态网络环境的开发者参考。资源为单一 PDF 文件压缩包仅 25KB轻量便携核心步骤与 YAML 配置片段一目了然便于本地保存或打印对照操作。已有 5253 人学习说明该方法在实践中具有较高的需求度。通过阅读读者可避开常见的 renderer 冲突与 managed 参数遗漏问题快速让 NetworkManager 接管网络接口并利用 nmcli 完成连接查看、激活与切换从而提升服务器网络维护效率。1. Ubuntu Server 20.04 为什么需要 network-manager 接管网络管理如果你在一台 Ubuntu Server 20.04 上插了 USB 无线网卡或者装了桌面环境后发现右上角网络图标一直显示「设备未托管」大概率会怀疑是不是系统坏了。其实都不是问题出在默认网络管理栈上这个版本的服务器默认用 netplan systemd-networkd 管理网络它在固定网线的云主机上很稳但遇到动态网络环境就力不从心。用 network-manager 接管网络管理就是把这个默认组合替换成 NetworkManager 守护进程让 WiFi 连接、USB 网卡热插拔、网络切换这些「桌面级需求」也能在服务器上顺滑跑起来。适合谁虚拟机里跑的测试机、放在宿舍或办公室连 WiFi 的小主机、以及任何不满足于「网线插上就不管」的 Ubuntu Server 20.04 用户。2. 接管之前netplan 与 network-manager 的分工和四个冲突点2.1 netplan 是「配置翻译层」它自己不干活netplan 做的事情用一个词概括是「翻译」。它在 /etc/netplan/*.yaml 里读一段声明式配置再根据 renderer渲染器字段把配置转译给后端程序执行。Ubuntu Server 20.04 服务器版默认的 renderer 是 systemd-networkd也就是说 netplan 本身不碰网卡真正负责拉起设备、跑 DHCP、维护路由的是 systemd-networkd 这个守护进程。netplan 的配置文件长得像下面这样# /etc/netplan/01-netcfg.yaml network: version: 2 renderer: systemd-networkd ethernets: eth0: dhcp4: true这段配置的含义是 eth0 用 DHCP 获取 IPv4 地址。netplan 会先把它转换成 systemd-networkd 能识别的 .network 文件然后交给 systemd-networkd 执行。命令行上你只需要记住两个动词netplan generate 只做转换不生效netplan apply 才会把转换结果真正应用下去。在云主机上 /etc/netplan 下通常还有 cloud-init 生成的 yaml名字常带 50- 开头它本质也是同一套机制接管前一起处理就行不用区别对待。这套设计在服务器场景下的价值是启动快、配置确定。没有多余守护进程yaml 写成什么样网络就是什么样出问题可以逐行排查。但它的短板也非常明显netplan 只管「启动时」和「apply 时」这两个瞬间不关注网卡热插拔、无线网络扫描、连接自动切换这些动态事件。你在服务器上插一张 USB 无线网卡netplan 不会弹出 WiFi 列表给你选因为它压根没有「扫描无线信号」这个功能。这就是为什么一台 Ubuntu Server 20.04 想灵活管理网络时第一反应是换掉整个管理栈而不是在 netplan 里继续加补丁。2.2 network-manager 的价值在「事件驱动」不只是替代NetworkManager 是一整套网络管理架构核心守护进程 NetworkManager.service 负责设备发现、连接管理和状态上报nmcli 是它的命令行前端D-Bus 接口可以被桌面环境和第三方工具调用。它和 systemd-networkd 最大的区别在于NM 是事件驱动的——网卡插入、WiFi 信号变化、DHCP 租约更新它都能主动感知并做出反应。拿「拔掉网线自动切 WiFi」这种场景来说systemd-networkd 需要你写一堆逻辑才能实现NM 的 connection.autoconnect 机制原生就能做。把 Ubuntu Server 20.04 的网络交给 NM 后你能立刻用上的具体能力包括无线网络的创建和自动重连、同一块网卡上多个连接的自动切换、USB 网卡和 4G 模组的即插即用、以及和 GNOME 桌面共用同一个网络状态入口。我认识的一个开发者把家里一台旧笔记本刷成 Ubuntu Server 20.04 放在弱电箱网线到不了就靠 NM 连 WiFi。热点密码变了之后他直接一条 nmcli 命令切换完全不用重新配置。另外很多人在意的一点是NM 的配置是运行时累积的不像 netplan 那样每次改动都要 apply 后重启网络。这对长年不重启的服务器来说非常友好。改一个 DNS、加一条静态路由都只是针对那一条连接做修改不会像 netplan apply 那样可能把整张网卡拉下来再拉上去这就是它适合生产服务器的核心原因。2.3 动手前必须理清的四个冲突点第一个冲突点在「设备归属」。同一个物理网卡理论上只能被一个网络管理守护进程持有。systemd-networkd 还在跑NetworkManager 再来管同一个接口轻则状态错乱重则两个服务在 /run 下争抢运行时文件。所以接管的第一步永远是让 systemd-networkd 让位而不是先启动 NetworkManager。第二个冲突点是 netplan 的 renderer 字段。如果你保留 /etc/netplan 下的 yaml但没把 renderer 改成 NetworkManager那 netplan apply 之后 systemd-networkd 会重新上场NM 直接靠边站。反过来也有坑renderer 改成 NetworkManager 后netplan 会生成一套它自己的 NM 连接配置这套配置和你手动用 nmcli 建的连接会同时存在同一个设备出现多份连接定义谁生效全看优先级。第三个冲突点是 DNS。Ubuntu Server 20.04 默认开着 systemd-resolved/etc/resolv.conf 是指向 /run/systemd/resolve/stub-resolv.conf 的软链接。NetworkManager 默认的 dnsdefault 模式会把 DNS 信息转交给 systemd-resolved两者是合作关系而不是替代关系。但如果你在配置里手滑写成 dnsnone就不再有服务维护 resolv.conf表现为域名解析突然失败而 IP 却是通的。第四个冲突点在服务自启状态。systemd-networkd.service 和配套的 systemd-networkd-wait-online.service 默认都是 enabled接管时就算你 stop 了不 disable 的话下一次重启它们还会回来。网络管理权交接不是一锤子买卖开机自启的开关得一起关掉否则你辛苦半天一次重启就全部还原。这四个冲突点决定了下文所有操作步骤的走向。搞清楚了再动手后面就不是试错而是按图索骥。3. 把 network-manager 扶正Ubuntu Server 20.04 网络接管完整步骤3.1 第一步备份这台服务器改动之前必须有后悔药无论你打算怎么折腾网络先把 /etc/netplan 备份。这不需要多少时间但能在配置被改乱后给你一条明确的回滚路径。远程服务器不像本地机器断网你连不回去只能跑机房或叫别人帮忙备份就是你的最后一颗后悔药。sudo apt update sudo apt install -y network-manager # 备份 netplan 配置先建目录再整体复制 sudo mkdir -p /root/netplan-backup sudo cp -r /etc/netplan/* /root/netplan-backup/ ls -la /root/netplan-backup/apt install network-manager 会同时装上 NetworkManager 服务、nmcli/nmtui 工具和 wpa_supplicant无线认证组件。mkdir 和 cp 两步是为了保证备份目录存在且不覆盖同名文件最后的 ls 确认备份内容。如果这台机器是云主机/etc/netplan 下大概率还有 cloud-init 生成的配置一起备份即可。本地物理服务器没有云控制台兜底备份的价值在这里会被放大。3.2 第二步让 systemd-networkd 完全退场装好 network-manager 后不要急着碰它先处理旧的网络管理服务。操作分两段停掉当前进程、禁止开机自启。# 停掉当前运行中的服务 sudo systemctl stop systemd-networkd.service sudo systemctl stop systemd-networkd-wait-online.service # 禁止开机自启防止重启后回来抢设备 sudo systemctl disable systemd-networkd.service sudo systemctl disable systemd-networkd-wait-online.service # 确认两个服务现在的状态 systemctl status systemd-networkd.service --no-pager | head -5 systemctl status systemd-networkd-wait-online.service --no-pager | head -5stop 让当前网络管理动作立刻停止disable 则是把这两项从 systemd 的启动链上摘除。systemd-networkd-wait-online.service 的作用是开机时等待网络就绪它如果不关启动时可能拖慢整台机器甚至把网卡重新拉起来。检查时两个服务都应显示 inactive (dead) 且 disabled如果不是说明服务名没找对或者系统里还有别的网络服务在接管网卡先解决这个再往下走。注意一个现实风险此刻这台 Ubuntu Server 20.04 的网络可能瞬间掉线。如果人是坐在服务器前操作就没有任何问题如果是 SSH 远程操作我建议先把下面的 NM 配置步骤一次性准备好再执行 stop或者使用云控制台提供的虚拟终端功能因为这个入口不依赖 SSH 链路断了也能重连。3.3 第三步清理 netplan 配置避免 NM 设备被标记为 unmanaged这是整个接管流程里最容易翻车的一步。只要 /etc/netplan 下还有配置文件且 renderer 指向 systemd-networkdnetplan generate 就会在后端运行时目录里给网卡打上「被其他管理器持有」的标记。NetworkManager 启动后看到这个标记直接把这个设备列入 unmanaged 名单表现就是 nmcli 里看不到网卡或无法操作。处理方式我推荐「整体移走旧配置 新建一个最小声明配置」# 把现有 netplan 配置全部移到备份目录 sudo mv /etc/netplan/*.yaml /root/netplan-backup/ # 生成一个极小配置声明网络渲染交给 NetworkManager sudo tee /etc/netplan/99-nm.yaml /dev/null EOF network: version: 2 renderer: NetworkManager EOF # apply 让 netplan 把渲染结果落到运行目录 sudo netplan apply这里保留 netplan 这个「翻译层」但让它把渲染目标指向 NetworkManager 而不是 systemd-networkd。99-nm.yaml 只声明 renderer、不声明任何网卡具体连接全部由 NM 自己管理。mv 把旧配置归档防止 systemd-networkd 模式的后端配置残留在运行目录里。apply 执行后检查 /run/systemd/network/ 目录是否还有 .network 文件残留有就删掉再 apply 一次。为什么不推荐直接在 netplan 里写网卡配置然后 renderer 指到 NetworkManager因为那样 netplan 和 NM 各自维护一份连接定义netplan 生成的连接描述会和你用 nmcli 创建的 connection 在优先级上互相干扰。对这种接管场景最省心的结构是「netplan 只当宣告员NM 是唯一的执行者」。3.4 第四步确认 NetworkManager 接管设备并重建连接重启 NetworkManager 让它重新扫描设备sudo systemctl restart NetworkManager nmcli dev status正常的输出里你的网卡设备eth0 或 ens33/ens160 之类的 STATE 应该是 connectedCONNECTION 列有对应的连接名。如果显示 unmanaged回去查 /etc/NetworkManager/conf.d 下是否有 unmanaged-devices 配置如果显示 disconnected说明设备被 NM 看到了但没有可用连接执行下面的命令创建。DHCP 环境的服务器nmcli con add type ethernet con-name server-eth0 ifname eth0 \ ipv4.method auto ipv6.method auto nmcli con up server-eth0静态 IP 的服务器机房固定 IP 或内网分配nmcli con add type ethernet con-name server-eth0-static ifname eth0 \ ipv4.method manual \ ipv4.addresses 192.168.10.20/24 \ ipv4.gateway 192.168.10.1 \ ipv4.dns 223.5.5.5 119.29.29.29 nmcli con up server-eth0-static第一段命令中 con-name 是这条连接的名称ifname 绑定网卡设备ipv4.method auto 表示 DHCP 获取地址。第二段是手动配置重点说三个参数ipv4.addresses 的 /24 必须写NM 不接受不带掩码的裸 IPipv4.gateway 如果不写默认路由不会生成跨网段访问直接失败ipv4.dns 支持多个 DNS 用空格分隔必须用引号包住。地址和网关按你自己环境替换照抄的话只会抄出一个不通的网络。创建连接后务必确认「开机自动连接」开关nmcli con mod server-eth0-static connection.autoconnect yes nmcli con show server-eth0-static | grep -E autoconnect|ipv4.method|ipv4.addressesconnection.autoconnect yes 让这条连接在网络设备出现时自动上线否则重启后 NM 能看到设备但不会主动拉起连接。grep 核验刚才配置的关键字段确认地址、掩码、方法都写对了。3.5 DHCP 拿不到地址的补救NM 内置 DHCP 客户端与 dhclient 的选择NetworkManager 默认使用自己实现的 DHCP 客户端internal它在绝大多数网络环境里没问题但也存在兼容性盲区。我在一台老交换机下的服务器就遇到过netplan 时代用 DHCP 正常切到 NM 后怎么都要不到地址排查半天发现是 internal 客户端和那台设备的 DHCP 响应报文不对付。解决办法是在连接级别指定用 dhclientnmcli con mod server-eth0 ipv4.dhcp-client dhclient nmcli con up server-eth0ipv4.dhcp-client 这个参数有两个值internal 是 NM 自带实现启动快、依赖少dhclient 是传统的 ISC DHCP 客户端兼容性更好但会多跑一个进程。遇到「NM 接管后拿不到 IP但 netplan 时代一切正常」的玄学网络问题第一个要改的就是这个参数。反过来说如果 dhclient 也拿不到才需要去看交换机的 DHCP 池和端口配置问题基本不在 NM 这一侧了。DNS 方面还有一个配置需要确认。Ubuntu Server 20.04 默认用 systemd-resolved 做本地 DNS 缓存转发NM 的 dnsdefault 模式会和它配合而不是冲突。接管后检查一下grep -r ^dns /etc/NetworkManager/NetworkManager.conf /etc/NetworkManager/conf.d/ 2/dev/null || echo dnsdefault如果没有显式配置默认就是 dnsdefaultNM 会把 DNS 信息交给 systemd-resolved由它统一维护 /etc/resolv.conf。这也意味着你以前「直接编辑 /etc/resolv.conf」的习惯要改掉接管后正确改 DNS 的途径是 nmcli con mod 或 resolvectl直接改文件会在下一次 NM 事件到来时被覆盖。4. 接管后 5 个高频踩坑现场现象、原因与排查方法4.1 远程 SSH 断连NM 重启的时机不对现象在某台远程 Ubuntu Server 20.04 上执行 systemctl restart NetworkManagerSSH 窗口卡住几秒后连接被拒绝重新登录发现 IP 变了。原因NM 重启时重新识别设备并重新跑 DHCP旧 IP 被释放新 IP 与旧 IP 不同SSH 链路自然断裂。这不是配置错误而是「远程改网」的通用风险。解决远程环境下避免直接重启 NM 整个服务。首选方案是只操作单条连接nmcli con up/down 一个连接时 NM 会尽量保留已建立的网络状态风险小得多。如果必须重启服务用 systemd-run 做一个延迟任务给自己留出操作窗口sudo systemd-run --on-active120 systemctl restart NetworkManager这条命令的意思是等 120 秒后自动执行重启。你可以在这个窗口内确认自己准备好了就算 SSH 断掉等服务起来后网络会自动恢复。但注意这个技巧救不了 IP 变化导致的断连它只能在 NM 服务卡死或配置异常时帮你自动拉起来别把它当成远程改完配置后的万能保险。4.2 网卡设备一直 unmanagednetplan 残留没清干净现象按步骤做完接管nmcli dev status 里网卡的 STATE 仍然是 unmanaged怎么 restart 都没用。原因最常见的是 /etc/netplan 的旧配置文件没有全部移走netplan generate 在后端运行时目录/run/systemd/network 或 /run/NetworkManager生成了残留标记NM 认为这个设备被别的管理工具持有。另一个来源是 /etc/NetworkManager/conf.d/ 下有人写过 unmanaged-devices 配置。解决按顺序排查。先看 netplan 目录里还有没有文件ls /etc/netplan/有文件就按 3.3 的做法全部移走只留 99-nm.yaml。再查 NM 自己的 unmanaged 标记grep -r unmanaged /etc/NetworkManager/conf.d/ /etc/NetworkManager/NetworkManager.conf 2/dev/null有输出就把对应配置行删掉或注释然后 systemctl restart NetworkManager。排查时用 nmcli dev status 看变化这一步不需要重启系统确认干净后设备状态应该立刻变成 disconnected 或 connected。4.3 重启后域名解析失败DNS 配置没有迁到 NM现象接管当天一切正常重启服务器后 curl 外网报无法解析域名但 ping IP 是通的。原因netplan 里原本配了 DNSdns: 8.8.8.8 之类的字段但你按 3.3 把整个 netplan 配置移走了DNS 信息跟着消失。NM 这边如果没在连接里显式配置 DNS并且 dns 模式又不是 defaultresolv.conf 就没人维护了。解决确认三个点。第一/etc/resolv.conf 是不是软链接ls -l /etc/resolv.conf正常情况应该指向 /run/systemd/resolve/stub-resolv.conf。第二NM 的 dns 模式nmcli general status | grep dns显示 default 就没问题。第三在连接里补上 DNSnmcli con mod server-eth0 ipv4.dns 223.5.5.5 119.29.29.29 nmcli con up server-eth0这里 ipv4.dns 的优先级高于 systemd-resolved 从 DHCP 自动获取的 DNS。如果 DHCP 下发的 DNS 本身是对的这条命令可以跳过如果 DHCP 的 DNS 不可用比如内网 DNS 不解析外网必须手动在连接里覆盖。4.4 出现两条默认路由systemd-networkd 没真正退场现象接管后 ip route show 看到两条 default 路由都指向同一个网关网络时通时不通ping 外网丢包严重。原因systemd-networkd.service 在 3.2 步骤里只停了没 disable或者 disable 失败重启后它又回来把网卡拉起来和 NM 各写了一条默认路由。两个守护进程同时持有同一个网卡路由表就乱了。解决确认服务状态systemctl is-enabled systemd-networkd.service systemctl is-enabled NetworkManager.service第一条必须输出 disabled第二条必须输出 enabled。如果第一条是 enabled立刻补上 disable。再看路由表ip route show正常情况应该只有一条 default。多余的用 ip route del 删掉然后重启 NM 让链路重新收敛。这个坑的根源在于「接管」没有做完整光是装上 NM 不等于 systemd-networkd 会让位服务自启状态才是决定权最后的归属。4.5 虚拟机克隆后网卡起不来连接文件绑定了旧 MAC现象一台 KVM 虚拟机做完接管后正常使用后来基于它的镜像克隆了新虚拟机新机器开机后网卡没 IPnmcli 显示网卡是 disconnected。原因NM 的 connection 文件里默认记录了创建时的接口名和 MAC 地址。克隆机的网卡 MAC 变了连接因为匹配不上旧 MAC 而不生效。接口名如果也从 ens 系变成了 ensX同样会导致匹配失败。解决把连接改成不绑定具体设备让 NM 靠接口名和系统当前状态匹配nmcli con mod server-eth0-static connection.interface-name nmcli con mod server-eth0-static 802-3-ethernet.mac-address nmcli con up server-eth0-static第一条清空连接的接口名绑定第二条清空 MAC 绑定相当于让这条连接对「是哪块网卡」不设限制。这样改之后虚拟机迁移或克隆后的网卡只要能正常识别连接就会自动匹配上。代价是一台机器上如果有多块网卡所有网卡都会随机匹配这条连接所以这个改法只适合单网卡场景。多网卡还是老老实实按接口名绑定。5. 确认接管成功的验证命令与 nmcli 进阶技巧5.1 用三个命令确认 NetworkManager 真的接管了接管完别急着收工用三条命令从设备、DNS、服务三个维度确认没有漏网之鱼# 1. 网卡设备和连接状态 nmcli -t -f DEVICE,STATE,CONNECTION device | grep -E ethernet|wifi # 2. resolv.conf 指向 readlink /etc/resolv.conf # 3. 服务自启状态 systemctl is-enabled NetworkManager.service systemd-networkd.service第一条输出里设备的 STATE 应该是 connectedCONNECTION 列有连接名如果显示 unmanaged 或 disconnected回去看第 4 章。第二条应该输出 /run/systemd/resolve/stub-resolv.conf如果输出别的东西说明有别的程序在写 resolv.conf排查它。第三条的输出应该是 enabled 和 disabled顺序不能反。三条都过了才算真正把 Ubuntu Server 20.04 的网络管理权交到了 NetworkManager 手里。5.2 nmcli 的日常维护习惯接管之后的日常操作我习惯只走 nmcli不碰 /etc/NetworkManager/system-connections 下的连接文件。改 IP 用 nmcli con mod切连接用 nmcli con up/down加静态路由用 nmcli con mod ipv4.routes查看状态用 nmcli dev status。这套命令的完整度已经覆盖了服务器网络管理的几乎所有场景。一个值得养成的习惯是每建一条 connection 前先给 con-name 取一个语义明确的名称比如 server-eth0-static、server-eth0-dhcp而不是默认生成的「Wired connection 1」。连接名在以后写脚本、排查问题时就是人肉眼可读的标识能省下大量对照时间。命名规范的回报率在 nmcli 这个工具里高得离谱我见过太多人在一堆默认连接名里找哪条对应哪块网卡。5.3 一个进阶技巧dispatcher 脚本处理连接事件nmcli 能完成的是「手动操作」而 NetworkManager 的 dispatcher 机制能完成「事件响应」。你可以在 /etc/NetworkManager/dispatcher.d/ 下放脚本NM 在连接 up、down、dhcp-change 等事件发生后会按文件名顺序执行这些脚本。举个例子某台 Ubuntu Server 20.04 接入了一个特殊内网需要在网络就绪后自动追加一条静态路由到独立路由表#!/bin/bash # /etc/NetworkManager/dispatcher.d/99-route-fix # 参数 $1 是接口名$2 是事件名 if [ $2 up ] || [ $2 dhcp-change ]; then if [ $1 eth0 ]; then ip route add 10.0.0.0/8 via 192.168.10.1 table 100 ip rule add from 10.0.0.0/8 table 100 fi fi写完要加执行权限否则 dispatcher 不会调用它sudo chmod x /etc/NetworkManager/dispatcher.d/99-route-fix$2 是事件名dispatcher 脚本里能收到的关键事件包括 up连接建立、down连接断开、dhcp-changeDHCP 租约变化。把自定义路由放到 dispatcher 里比放在 rc.local 更可靠因为它能精确绑定到网络事件而不是开机这个单一时间点。网卡重连、DHCP 续约后脚本都会重新执行路由表不会因为网络抖动而丢失。最后说一个教训。我早期在一台测试机上做过一次接管当时偷懒没备份 netplan 配置改完 NM 一重启网卡直接 unmanaged机器就摆在那但网络不通。那次靠带外管理口救回来之后我在哪台机器上做网络变更都先把备份目录建好命令写成一段可回滚的脚本再执行。接管这件事本身不难但每一步都留有退路才是做服务器网络改动该有的习惯。希望帮到你。本文还有配套的精品资源点击获取