Linux网卡配置：ifcfg、netplan、NetworkManager等主流方法详解

配过 Linux 网卡的人都懂真正难受的往往不是配置本身而是不同发行版、不同网络管理工具之间那点“隐蔽的差异”。前阵子帮朋友看一台 Rocky Linux 服务器他照着十年前的老教程改了/etc/sysconfig/network-scripts/ifcfg-eth0重启网络服务直接报错IP 还变成了 169.254 开头的临时地址整整折腾了一下午。我过去一看才发现系统里压根没有 ifcfg-eth0 这个文件网卡配置早就被 NetworkManager 接管了。这类问题几乎每个运维都遇到过核心原因就一条没弄清楚你的 Linux 到底由谁来管理网卡。这篇文章围绕 Linux 网卡配置这条主线把目前主流的 ifcfg、netplan、NetworkManager keyfile 三条配置路径讲透再重点拆解 DNS 被重置、多网卡命名、重启失败这类高频故障。适合刚接手服务器维护的新人也适合用 Linux 面试题来复习基础知识的朋友。就算你已经配过几年网卡里面大概率也有几个以前没留意的细节。1. 网卡配置的第一道门槛先搞清楚系统正在看哪份配置1.1 从 ifcfg 到 NetworkManager keyfile一次漫长的权力交接很多老教程还在教/etc/sysconfig/network-scripts/ifcfg-eth0这套东西但现实世界已经变了至少两轮。RHEL 6 及更早的 CentOS 6网络服务是network脚本配置目录就是/etc/sysconfig/network-scripts/ifcfg 文件写死一切改完执行service network restart就生效。那个年代确实简单粗暴一条网卡写一个文件DEVICE、BOOTPROTO、IPADDR 全在里面。但从 RHEL 7 开始NetworkManager 成了主角ifcfg 成了它读写的“兼容格式”。也就是说你改 ifcfg 文件NM 能识别但反过来NM 创建的很多新属性比如路由策略、DHCP 选项在 ifcfg 里根本表达不全。到了 RHEL 8、RHEL 9默认配置格式变成了 keyfile存放在/etc/NetworkManager/system-connections/目录下一个连接一个.nmconnection文件。这个格式跟 ifcfg 最大的区别是它按“连接”而不是按“网卡”来组织概念——同一块物理网卡可以保存多个连接配置不同的连接可以对应不同的使用场景。Ubuntu 这边则是另一套路径。18.04 之后默认用 netplan配置文件是/etc/netplan/*.yamlnetplan 本身不直接干活它只是把 YAML 翻译成 systemd-networkd 或 NetworkManager 的配置。Debian 系老一点的发行版还在用/etc/network/interfaces风格又是另一套。再加上一些国产发行版、openSUSE 这类各自都有自己的偏好但内核 netlink 接口是唯一的谁在用户态干活谁说了算。1.2 一条命令快速判断当前系统属于哪一派我不喜欢猜喜欢直接拿出来看。第一次登录未知环境时我会按顺序跑这几条基本十秒内就能定位配置体系ip a nmcli connection show ls /etc/sysconfig/network-scripts/ 2/dev/null ls /etc/NetworkManager/system-connections/ 2/dev/null ls /etc/netplan/ 2/dev/null readlink /etc/resolv.confip a负责告诉你有哪些网卡、现在是什么状态、IP 是多少。nmcli connection show告诉你 NetworkManager 认到了几个连接。后面三条ls是排查配置文件到底在哪。readlink /etc/resolv.conf这步很多人会忽略但它能直接告诉你 DNS 解析的控制权在谁手里后面我会单独展开。举几个实际例子CentOS 6 机器上network-scripts目录有一堆 ifcfg 文件nmcli大概率报错或什么都没输出说明就是老式 network 脚本在管。RHEL 8/9 或者 Rocky Linux 9system-connections目录里躺着几个.nmconnection文件nmcli能正常列出连接ifcfg 可能也存在但只是历史遗留说明大多数配置都是 NM 在管。Ubuntu 22.04 服务器上/etc/netplan/有.yaml文件system-connections目录通常是空的说明网络配置由 netplan 翻译给 systemd-networkd 或 NM。Debian 传统装机方式下/etc/network/interfaces存在netplan 不参与是 ifupdown 这一套在管。这个判断是后面所有改动的起点。如果你一上来就在错的文件里改后面所有操作都是白费。1.3 为什么老教程经常失效老教程失效的本质原因是 systemd 引入之后服务管理方式、设备命名方式、配置文件格式全部经历了换代。比如 eth0 这个名字在老系统里是内核按探测顺序分配的到了新系统里变成了 enp3s0 这种带硬件拓扑信息的名字。运维教程如果不更新读者在 Ubuntu 22.04 上找不到 eth0在 RHEL 9 上找不到 ifcfg-eth0在 Debian 12 上发现systemctl restart network是个不存在的服务这些都是正常的不是你操作错了而是时代的车已经开过去了。所以配置 Linux 网卡的第一课不是背参数而是学会“先看系统用的是什么管理方式”。做到这一点后面所有问题都顺了。2. 静态 IP 配置实战ifcfg、netplan、nmcli 三条路任选2.1 ifcfg 文件手工编辑的完整流程虽然 ifcfg 已经过时但存量服务器里它还是大头尤其 CentOS 7、部分国产化系统你绕不开它。假设网卡叫 ens160新命名规则下的常见名字要配一个静态地址 192.168.1.100/24网关 192.168.1.1备 DNS 用公共 DNS文件内容是这样vim /etc/sysconfig/network-scripts/ifcfg-ens160DEVICEens160 NAMEens160 TYPEEthernet ONBOOTyes BOOTPROTOstatic IPADDR192.168.1.100 NETMASK255.255.255.0 GATEWAY192.168.1.1 DNS1114.114.114.114 DNS2223.5.5.5有几个参数必须讲清楚为什么ONBOOTyes是灵魂。很多新手改完重启发现网卡没起来先看这个。它表示“开机时是否激活该网卡”不写或者写 no系统启动后网卡就是 DOWN 状态。BOOTPROTOstatic表示静态配置。如果用 DHCP就写dhcp并且不要写 IPADDR、NETMASK 这些写了也会被忽略。DNS1、DNS2是 NetworkManager 用来写入/etc/resolv.conf的 DNS 来源之一。在老系统里/etc/resolv.conf也可能单独由resolv.conf文件管理两者并存时以谁为准要看具体工具。如果文件是 NetworkManager 生成的通常还有一个UUID字段。多网卡环境里拷文件时必须小心两块网卡的 ifcfg 文件如果 UUID 完全一样NetworkManager 会把它们当成同一个连接配置会互相覆盖或干脆失效。改文件后忘了删 UUID 是我见过最多、也最隐蔽的问题。改完后建议用nmcli connection reload让它重新读取配置然后nmcli connection up ens160重新激活。CentOS 6 老系统没有 nmcli就执行service network restartCentOS 7 里systemctl restart network也能用但它调用的东西非常老出错率比 NM 高我现在基本不用。2.2 netplan 的 YAML 思路与常见误区Ubuntu 18.04 之后的服务器基本逃不开 netplan。它把配置收敛成一个 YAML 文件思路很现代但 YAML 的缩进错误会让新手崩溃。一个静态 IP 的典型写法vim /etc/netplan/01-netcfg.yamlnetwork: version: 2 renderer: networkd ethernets: ens33: dhcp4: false addresses: - 192.168.1.100/24 routes: - to: default via: 192.168.1.1 nameservers: addresses: [114.114.114.114, 223.5.5.5]这里有几个关键点renderer只能写networkdsystemd-networkd或者NetworkManager千万别混用。装 Ubuntu Server 时默认是 networkd装了桌面版或之后装了 NetworkManager可能需要改 renderer。dhcp4: false必须显式写只写addresses不代表关闭 DHCP。很多人在这个细节上翻车配了静态地址系统启动又发 DHCP 请求最后拿到一个不相干的 IP。写完后先执行sudo netplan try再执行sudo netplan apply。try会在 120 秒后自动回滚如果没确认。这在远程操作时能救命尤其当你正在改自己在用的那块网卡。假如配置有问题网络断了几分钟会自己恢复不至于把 SSH 搞死。如果你执行netplan generate想只生成后端配置而不应用记得它不会重连网卡。我经历的教训在 Ubuntu 20.04 上同时存在多个 netplan YAML 文件时netplan 会把它们合并。曾有一次我在01-netcfg.yaml里写 eth0又在99-custom.yaml里写了同网卡另一组地址最后网卡拿到两个 IP路由表一团乱。现在我在生产环境一律只维护一个 YAML 文件多个网卡就都写在这个文件里绝不拆成多个文件。2.3 nmcli命令行里最快、最适合脚本化的方案如果你用的是 NetworkManager 体系nmcli 是绕不开的瑞士军刀。它最大的优势是配置改动立刻持久化到配置文件不需要手工去编 ifcfg 或 keyfile也不会因为手删错一个字段导致整个网卡瘫痪。给现有连接改静态配置nmcli connection modify ens160 \ ipv4.method manual \ ipv4.addresses 192.168.1.100/24 \ ipv4.gateway 192.168.1.1 \ ipv4.dns 114.114.114.114 223.5.5.5 nmcli connection up ens160注意ipv4.dns的写法多个 DNS 之间用空格隔开并且要加引号不然会被 shell 拆成两个参数。modify是修改持久化连接配置up是重新激活并让改动生效。这里有一个很多人没搞清楚的底层区别nmcli device操作的是设备状态nmcli connection操作的是连接配置。临时 IP 可以用nmcli device modify ens160 ipv4.addresses ...但重启后丢失。真正要持久保存必须走 connection。还有一种更“临时”的调试手段直接用ip命令ip addr add 192.168.1.100/24 dev ens160 ip link set ens160 up ip route add default via 192.168.1.1这纯粹是临时手工配置不写任何配置文件重启全丢。但它好处是立刻生效适合你在排查问题想验证“此配置是否可行”时使用。比如 DNS 不通怀疑是网络层面还是配置层面先拿ip命令设一个干净的地址去测比反复改文件快得多。3. DNS 配置为什么总被重置resolv.conf 的管理权之争3.1 先看 resolv.conf 的链接再谈其他DNS 相关故障十个里有八个是同一句话“我明明改对了 /etc/resolv.conf重启又变回去了”。这个问题的根源在于/etc/resolv.conf在现代 Linux 上往往不是一个真实的文件而是由系统服务动态生成的链接文件。执行readlink /etc/resolv.conf可能有几种结果/run/systemd/resolve/stub-resolv.conf说明 systemd-resolved 在管 DNS。/run/NetworkManager/resolv.conf说明 NetworkManager 在管 DNS。一个普通文件可能由 ifupdown、resolvconf、或管理员手工维护。不管是哪种情况只要你在/etc/resolv.conf里手工改了几行等 NetworkManager 或 systemd-resolved 一刷新立刻被覆盖回去。这不是系统“bug”而是权限设计就是这样——谁接管网络谁就该负责生成 DNS 配置。你对抗的不是一个文件而是一个服务的管理逻辑。3.2 NetworkManager 体系下DNS 的正确落点NetworkManager 管 DNS 时你别碰 resolv.conf去改连接的 DNS 属性nmcli connection modify ens160 ipv4.dns 114.114.114.114 223.5.5.5 nmcli connection modify ens160 ipv4.ignore-auto-dns yes nmcli connection up ens160第二行ipv4.ignore-auto-dns yes非常关键。它的意思是即使 DHCP 服务器下发了一个 DNS比如 192.168.x.x 的网关地址也忽略掉只用你手工指定的 DNS。很多内网环境下DHCP 下发的内网 DNS 失效外网 DNS 又不该用这时候忽略自动 DNS 反而是正确做法。如果你用的是老式 ifcfg就在网卡配置文件里写 DNS1、DNS2然后让 NetworkManager reload。注意NetworkManager 接管后它写 resolv.conf 的顺序是有讲究的它会合并 DHCP 获取的 DNS 和手工配置的 DNS手工的排前面。所以即便你看到 resolv.conf 里的 DNS 顺序和预期不完全一致也别慌先跑nmcli connection show ens160 | grep dns看 NM 眼中的配置是什么。3.3 systemd-resolved 的缓存与转发机制Ubuntu 18.04 默认启用 systemd-resolved现象就是/etc/resolv.conf被链到 127.0.0.53 这个本地地址。这个 stub 地址本身不干活它只把本地进程的 DNS 请求转发给 systemd-resolved 真正管理的上游 DNS。在这个体系下你用cat /etc/resolv.conf看到的是nameserver 127.0.0.53这不代表系统用的就是 127.0.0.53 这个 DNS而是说系统把查询交给了 systemd-resolved由它转发。真正生效的 DNS 要看resolvectl status resolvectl dns如果/etc/resolv.conf指向 stub但你实际想直接用某台内网 DNS 排查问题有个很实用的方法用dig 目标DNS 域名直接指定服务器发起查询绕过本机解析机制。比如dig 114.114.114.114 example.com这种方法能直接区分“本机解析逻辑坏了”还是“上游 DNS 本身不可达”。在实际运维里如果我没必要通常会关闭 systemd-resolved 自己管理 DNS 的优先级直接让 NetworkManager 或手工维护 resolv.conf。怎么关修改/etc/systemd/resolved.conf里的DNSStubListenerno以及/etc/NetworkManager/NetworkManager.conf里的[main] dnsdefault具体配置因发行版而异。但记住一点搞清楚你当前环境是谁在管才能决定改哪里。别一上来就 disable resolved——有些系统服务依赖它。3.4 顺带解决一个搜索热词多台 DC 的网卡 DNS 怎么配这个话题被搜得很高频通常遇到的是三台域控制器组成的 AD 环境。域控的网卡 DNS 配置有一个不能乱来的铁律域控的主 DNS 必须指向自身或者另一台承担 DNS 角色的域控绝不能指向外网公共 DNS也不能指向网关地址或内网其他非域控设备。原因不复杂AD 域环境里的 SRV 记录、域控定位、站点拓扑乃至 Kerberos 认证都依赖 DNS。如果域控把自己网卡的 DNS 写成了 114.114.114.114它就无法正确解析_ldap._tcp.dc._msdcs.contoso.com这类内部记录域内其他机器也会因此找不到域控。三台 DC 的标准做法是每台 DC 的主 DNS 配成本机 IP或回环地址备 DNS 配成另一台 DC让三台 DC 互相形成解析拓扑。我见过不少“内部域名解析时好时坏”的案例最后根因都是 DC 网卡 DNS 指向了外部。这个例子说明一件事网卡上的 DNS 配置不只是“填个地址”那么简单它必须服务于这台机器在架构中的定位。4. 网卡命名规律与多网卡场景别再写 eth0 了4.1 从 eth0 到 enp3s0命名规则背后的可靠性考量老内核里网卡按探测顺序叫 eth0、eth1、eth2。听起来挺好记但有个致命问题顺序不一定稳定。如果你插了多块同型号网卡PCI 枚举顺序变了eth0 和 eth1 可能互换配置文件就会错位比如你把生产网段的配置应用到了管理网网卡上。systemd 的可预测命名规则就是为了消灭这种不确定性。它根据硬件拓扑来命名eno1板载网卡编号来自固件或 BIOS。ens1PCI 热插拔槽位编号。enp3s0PCI 总线号为 3、槽位为 0 的网卡。enx001c42...包含 MAC 地址的命名。这套规则保证了一块物理网卡到设备名之间的映射是稳定的拔插不会乱。刚开始看 enpXsY 这种名字会不习惯但配多了你会觉得它信息量很大——光看名字就知道这张卡挂在哪个 PCI 位置排查硬件问题时特别方便。如果某些特殊场景必须用 eth0 这种老名字可以在内核引导参数里加net.ifnames0 biosdevname0但这属于牺牲稳定性换兼容性正常情况下不建议。尤其是做自动化运维脚本里出现 eth0 这种名字换台机器就可能失效远不如用稳定的命名或者按 MAC 匹配。4.2 多网卡 Bond高可用网卡配置的思路服务器上常见的多网卡需求就是配置 bond把两块甚至四块物理网卡绑定成一个逻辑网卡实现链路冗余或带宽聚合。在 NetworkManager 体系下用 nmcli 一步步建 bond 比较稳妥# 创建 bond0主备模式 nmcli connection add type bond con-name bond0 ifname bond0 mode active-backup # 把两块物理网卡加进去 nmcli connection add type ethernet con-name bond0-port1 ifname ens160 master bond0 nmcli connection add type ethernet con-name bond0-port2 ifname ens161 master bond0 # 给 bond0 配 IP nmcli connection modify bond0 ipv4.method manual ipv4.addresses 192.168.1.200/24 nmcli connection up bond0这里 mode 是最关键的决策点。负载均衡模式modebalance-rr、balance-xor 等对交换机有特殊要求主备模式active-backup则最简单、兼容性最好两块网卡同一时刻只有一块在干活另一块 standby。大部分服务器链路上没那么大瞬时流量主备足够而且故障切换逻辑最简单也最容易排查。如果你用老式 ifcfgbond 配置写起来略繁琐需要 bond0、bond0-port1、bond0-port2 三个文件BONDING_OPTS 写在主文件里。现在新系统基本都有 nmcli我建议直接走 nmcli。4.3 双网卡指向不同网段时的路由策略还有一种多网卡场景非常容易踩坑一台机器有两块网卡一块接办公/管理网一块接业务网两个网段可能重叠也可能完全隔离。默认路由只有一个。如果两块网卡都配了默认网关系统会按配置顺序把默认路由指向其中一个另一个网关就是摆设。更麻烦的是Linux 的弱主机模型下从业务网进来打某个 IP 的包回包可能从管理网卡出去——源地址、目标地址全对不上流量就断了。处理这种场景要靠策略路由。基础思路是给每块网卡建一张独立的路由表用源地址匹配来决定走哪张表。以一个简单例子说明假设 eth0 是管理网eth1 是业务网业务网卡支持 192.168.20.100网关为 192.168.20.1# 在路由表 200 里添加业务网的默认路由 ip route add default via 192.168.20.1 dev eth1 table 200 # 从业务网 IP 发起的流量查路由表 200 ip rule add from 192.168.20.100/32 table 200 # 查看策略路由表 ip rule show ip route show table 200这里用到了table这个概念Linux 默认有 255 张路由表除了 main 表你还可以建自定义表。策略路由的核心是“数据包从谁出去回谁”。如果日志里看到大量“ARP 丢包”或者服务端访问异常先查ip rule show和两张网卡的路由表八成是默认路由打架了。5. 重启网卡的正确姿势与常见故障排查5.1 别再到处敲service network restart了不同配置体系有自己对应的激活命令敲错了有两种结果服务不存在直接报错或者平白无故把 NetworkManager 整个重启一次导致 SSH 瞬断。我把常用对照整理成表配置体系生效命令副作用与使用场景ifcfg network 脚本CentOS 6service network restart老系统专用整个网络服务重启NetworkManager nmclinmcli connection reload再nmcli connection up 连接名最精准只重载一个连接不断其他网卡NetworkManager keyfile同上用 nmcli 操作RHEL 8/9 首选netplansudo netplan apply只应用 netplan 管理的配置Debian interfacessystemctl restart networking或ifreload -a传统 Debian 体系ifreload 更温和systemd-networkdsystemctl restart systemd-networkdnetplan renderer 是 networkd 时也可用它我个人习惯只要条件允许优先nmcli connection up。它只影响指定连接不会同时把所有网卡断一遍。systemctl restart NetworkManager是最后手段因为每次 restart 都会把所有网卡重新配置一遍正在跑的 SSH 连接会短暂掉线生产环境里影响面太大。5.2 五类高发故障的排查链路故障一网卡变成 169.254.x.x也就是 APIPA 地址169.254 开头是系统在 DHCP 失败后给自己分配的“临时地址”它出现基本等价于 DHCP 没拿到 IP。排查顺序先ip a看是哪个网卡拿到这个地址再journalctl -u NetworkManager或dhclient -v看 DHCP 交互日志确认是 DHCP 服务器不可达、地址池耗尽还是网卡根本没接到交换机上。虚拟化环境里最常见原因是 VM 的网络模式改过或者交换机端口配置了 VLAN导致 DHCP 报文到不了服务器。故障二IP 冲突网络时断时续IP 冲突不会报红字往往表现为“能 ping 通但延迟忽高忽低”或“几分钟断一次”。主动探测方法在另一台机器上安装 arping然后对配置的 IP 发起探测arping -I ens160 -c 5 192.168.1.100如果收到多个 MAC 地址响应说明确有冲突常见于两台机器设置了相同静态 IP或者 DHCP 地址池范围跟静态 IP 重叠了。这时要么把静态地址改出 DHCP 范围要么在 DHCP 服务器上绑定 MAC。故障三能 ping 通同网段但出不了外网这种问题十有八九是默认路由丢了或者网关配置错。先跑ip route show看有没有 default route。没默认路由就按本文前面讲的方法补。有默认路由但出不去试ping 网关IP通网关后再ping 外网IP逐步收敛。如果是双网卡场景还要查ip rule看策略路由是否把外网流量引到了错误的网卡。故障四DNS 能连通 IP但域名解析不了表现是ping 8.8.8.8通、ping www.example.com报 unknown host。先cat /etc/resolv.conf看 nameserver再看它是不是链接文件然后按第 3 章的思路找到真正管的服务。多数情况下是 resolv.conf 被改过又被覆盖或者 DNS 指向了一个内网地址但目标服务已经挂掉。这类问题用dig 指定DNS 域名排查最快。故障五重启后网卡状态是 DOWN首先确认ip link里网卡是不是 DEAD/DOWN然后用journalctl -b -u NetworkManager看启动日志常见原因ifcfg 文件 UUID 重复导致 NM 认错连接、ONBOOTno、网卡驱动延迟加载导致启动时设备还没出现。虚拟环境里还有个特殊问题VM 模板克隆后新机器的网卡 MAC 变了但 udev 规则或 NetworkManager 连接里还留着旧 MAC也会导致网卡不被接管。5.3 我每次配完网卡必跑的验证清单配置完成后我不急着收工固定流程是ip a # 确认 IP 和掩码 ip route show # 确认默认路由 cat /etc/resolv.conf # 确认 DNS 是谁在管 ping -c 3 网关IP # 确认链路可达 ping -c 3 外网IP # 确认三层可达不带域名 dig 114.114.114.114 example.com # 确认 DNS 可用如果以上全通我才认为这次网卡配置是成功的。远程操作时我会提前写好回滚预案比如把旧配置备份到一个安全目录或者用nmcli connection记录下当前每个连接的状态。改配置这种事宁可慢一点也不要让自己被一根断掉的 SSH 连接困在机房外面。最后分享一个我自己的习惯所有配置改动我都会顺手在文件里加一行注释注明修改日期和用途。网卡配置文件是系统级文件经常被多人改动没有痕迹说明的配置三个月后就是一个无人敢动的黑盒。这个习惯帮我省掉了无数次“这行是谁加的”式的考古工作。