Linux网卡配置指南：从NetworkManager到ip命令的永久与临时配置

刚接触服务器运维那阵子，我最怕的就是改网卡配置。明明照着网上教程敲完了命令，重启之后网络又回到原点；或者照着 A 发行版的文章改了配置文件，放到 B 发行版上却完全不生效。后来时间长了才明白，Linux 网卡配置无非三件事：让系统识别网卡、给网卡配上正确的 IP 和路由、让配置在重启后依旧有效。难点不在某一条命令，而在你手里的系统到底由谁管理网络、临时配置和永久配置的分界线在哪、出了问题应该从哪一层开始查。这篇文章我会从这三点出发，把 Linux 网卡配置的完整方法论过一遍，覆盖 NetworkManager、netplan、ifcfg、systemd-networkd 几种主流方案，同时穿插 ip 命令族的实操细节。准备装系统、跑实验、或者正被服务器静态 IP 折腾的读者，都能直接照着操作。

1. 先搞清楚你手里的 Linux 到底由谁管网络

1.1 三种主流网络管理框架，选错方向就白折腾

市面上发行版虽多，网络配置方案无非三个流派。

第一个是 NetworkManager，RHEL/CentOS/Fedora、Ubuntu 桌面版默认都在用这套网络服务。它的特点是集中式管理网卡，带图形界面、nmtui 字符界面和 nmcli 命令行，虚拟机和桌面环境里最常见。很多企业服务器跑 RHEL 系，登录进去之后看到的默认网络管理服务基本都是它。NetworkManager 有个概念叫“连接”（connection），一份连接对应一套网卡的完整配置，可以把某个网卡在多个网络环境下的参数分别保存，用的时候切换即可。这个概念一开始不太好懂，但理解了之后会发现它确实比直接改文件灵活。

第二个是 systemd-networkd，systemd 自带的轻量网络管理组件。它在无桌面的服务器、容器镜像和 minimalist 系统里越来越流行。配置方式非常直接：在/etc/systemd/network/下放几个.network文件，systemd 启动时读取并生效。没有同事间传译，没有不同进程抢占，好处是干净、依赖少，坏处是缺少热插拔和多用户复杂场景的支持。对一台只跑了几个服务的轻量服务器来说，它几乎是性价比最高的选择。

第三个是传统脚本式配置，包括 Debian/Ubuntu 的/etc/network/interfaces和 CentOS 系的/etc/sysconfig/network-scripts/ifcfg-*文件。前者由 ifupdown 工具读取，后者由 initscripts 读取。这类方式最古老也最直接，很多老运维更习惯手写文件，一些最小化安装系统里也仍然保留着它们的痕迹。

为什么要先搞清楚归属？因为同一句“把 IP 改成 192.168.1.10”，在不同框架下的写法和生效机制完全不同。在 NetworkManager 管理下，你手工去改 netplan 或 ifcfg 文件，NM 可能完全不理会，甚至会在重启后用自己保存的配置覆盖回来。反过来，如果系统只装了 systemd-networkd，你却网卡管理依赖 NetworkManager，同样会出现“改了但没生效”的诡异现象。我见过太多同事栽在这个问题上：明明照着教程改了文件，重启后却一切如旧，最后才发现发行版默认用的根本是另一套管理机制。

提示：拿到陌生机器，第一件事确认当前运行的管理服务。systemctl status NetworkManager、systemctl status systemd-networkd或者ps aux | grep -E 'NetworkManager|systemd-networkd'都能帮你快速判断。这一步花不了十秒，能省下后面两小时的排查时间。

1.2 网卡名是怎么来的，为什么 ens33 不是 eth0

早年老系统里网卡名都是 eth0、eth1，很好认。现在的发行版普遍采用可预测命名规则，像 ens33、enp0s3、eno1 这类名字。这套命名逻辑来自 systemd 和 biosdevname：en 代表以太网，后面的 p、s、o 分别代表 PCI 总线位置、热插拔插槽、主板板载网卡。比如 ens33 通常表示一个插在 PCI 总线第 33 号插槽的以太网口，enp0s3 表示 0 号 PCI 总线、3 号插槽。这种命名方式是故意的，比 eth0 更能稳定描述物理位置，避免每次启动后网卡顺序错乱带来的“地址漂移”问题。

很多人第一次看到 ens33 会不习惯，但千万要忍住去手动改回 eth0 的冲动。如果你真的因为某些老脚本依赖 eth0 而必须改，可以在内核参数中加上net.ifnames=0 biosdevname=0，改完重启就能回到 eth0 命名。但这是一把双刃剑：多网卡机器上这种改法容易让设备识别顺序错乱，不做特殊需求的话，还是保留默认命名比较稳妥。看到 enp0s3 这种名字就头疼的同学，心里可以默默转译：en 是以太网，p 是 PCI 设备，s 是插槽，这样理解起来就不那么违和了。

确认当前网卡状态，三板斧就够了：

• ip link show看所有网卡是否 up/down，以及 MAC 地址和 MTU；
• ip addr show看每个网卡的 IP 地址和子网掩码；
• ethtool ens33看链路协商速度和双工模式，判断网线是否真的插好、对端端口是否起来了。

如果网卡显示 state DOWN，可以先ip link set ens33 up拉起。不过要注意，有些网卡在虚拟化环境里要求启动前先配置好桥接或 VLAN，单纯 up 不一定成功，这时候看 dmesg 输出会更直接的告诉你驱动和固件到底发生了什么事情。

1.3 远程操作前的一念之差，可能直接失联

这一条我想放在第一节就强调，是因为吃过亏。如果你是通过 SSH 远程登录服务器来改网卡配置，一定要意识到：网卡配置一旦出错，你可能是最后一个能碰到这台机器的人。尤其是云服务器、虚拟机里操作，IP 一旦改错或者网关写错，SSH 瞬间断开，而云控制台的网页终端又往往不一定能连通内网，这时候只能靠救盘、串口或者找机房同事帮忙，代价非常大。

所以远程操作前，我先做两件不起眼的小事。第一，确认当前 ssh 会话里自己的登录 IP 是不是准备保留的那个地址，别把正在用的地址删了。第二，准备好一条回滚命令，把原来的配置备份到一个文件里，改坏了一秒还原。如果条件允许，再开一个临时会话或者在 tmux 里保持一个会话窗口，这样即使网络短暂中断，会话不丢，断了可以直接重新连，变相降低了操作风险。

记住这个原则：远程改网络，永远给自己留条后路。用完任何配置都先确认能 ping 通网关，再确认 SSH 还能连，整个过程保持在几十秒内，别让中断窗口拉得太长。

2. ip 命令族：临时改网卡参数的正确姿势

2.1 三种命令：addr、link、route 各管一件事

ip 命令来自 iproute2 软件包，是 ifconfig 的现代替代品。现在很多教程还在用 ifconfig，但新系统上未必预装 net-tools 工具集，我更建议直接学 ip 命令。它把信息拆得非常清晰：链路层归ip link管，网络层地址归ip addr管，路由表归ip route管。这个分层逻辑和网络协议栈完全对应，记起来也特别容易。

高频用法先列出来：

• ip link show：查看所有网卡状态、MAC、MTU；
• ip -br addr show：用简洁输出查看所有接口的 IP，调试时一眼看清；
• ip addr show ens33：只看指定网卡；
• ip route show：查看路由表，确认默认路由是否存在；
• ip route get 8.8.8.8：查看访问某个目标地址时系统会走哪张网卡、哪个网关，这是诊断路由问题的一大利器。

对刚接触网络配置的人来说，容易混淆的是“IP 地址 + 掩码”和“网关 + DNS”这两组概念。IP 地址和子网掩码是设备的身份证，写在网卡上；默认网关是数据包出网时找的“下一跳”，写在路由表里；DNS 则决定域名怎么解析成 IP，它既不在网卡上，也不在路由表里，而是由/etc/resolv.conf或系统解析器决定。用生活场景类比：IP 是门牌号，网关是小区大门，DNS 是手机通讯录；你只贴了门牌号但没写大门位置，快递照样送不到你手里。很多人配了静态 IP 发现外网不通，就是因为只写了门牌号，没写小区大门。

2.2 实战：临时给网卡配静态地址和默认路由

假设你刚装好一台 Linux，系统自动从 DHCP 拿了个地址，但你想固定成 192.168.10.10/24，网关是 192.168.10.1。临时方案就是三句话：

ip addr add 192.168.10.10/24 dev ens33 ip link set ens33 up ip route add default via 192.168.10.1 dev ens33

如果原来网卡上已经有 DHCP 分配的地址，先把它删掉，否则会出现多地址并存、路由表混乱的情况。删除命令是对称的：ip addr del 192.168.10.11/24 dev ens33。注意删除地址时要带上完整的 CIDR 掩码，写错了系统会报错或误删其他地址。

如果你做的是容器网络实验、临时网桥、或者只是验证一下网段通不通，这种临时配置非常合适，因为它不碰任何配置文件，改起来快、撤销也快。不过要时刻记住它的局限：重启后这些手工加入的地址和路由全部烟消云散。系统重启时只会根据“档案”里的配置重新初始化网络，不会记得你刚才敲过什么。

我建议临时配置的典型使用场景是“验证”。先用 ip 命令验证新 IP 能不能通、默认路由对不对，确认没问题之后，再用永久配置方案把同样的参数固化下来。这样能最大限度地避免直接改配置文件然后重启导致的问题。

2.3 临时和永久的界限，理清楚再动手

这条反复被新手踩坑：用 ip 命令配好地址，当前是通的，重启“啪”一下回到原点。原因很简单，ip 命令只作用于内核里的当前网络栈，不涉及任何开机脚本，系统重启后 netplan、ifcfg、NetworkManager 会按自己的配置重新初始化。换句话说：ip 命令是你在系统运行中手动调整的临时线路，永久配置是写在档案里的官方台账，重启等于重新读档，你手动接的临时线路当然不会出现在档案里。

这个设计其实很合理，它给了运维人员一套安全快速的热更改手段，用来验证网络参数，验证完再用配置文件固化下来。我的习惯是：先用 ip 命令做一轮验证，确认地址、路由无误后，立刻进入对应的配置文件或 nmcli 操作，把同样的参数写进持久化设置。这样做既能减少反复重启，也能避免“配置写错导致只能靠救盘进去改”的尴尬。千万别把 ip 命令当永久配置来用，不然每次重启你都要手动敲一遍，像在跟系统玩打地鼠。

3. 永久生效的主流配置方式，一次看清

3.1 nmcli 三步完成静态 IP 配置

NetworkManager 是目前使用范围最广的网络管理服务，绝大多数桌面发行版和部分服务器发行版默认启用它。用它配置网络最直观的方法是 nmcli。先看当前有哪些网络连接：

nmcli connection show

如果系统默认创建过一个名为 ens33 或“System eth0”的连接，你可以直接修改它。假设我要把 ens33 改成静态地址 192.168.1.20/24、网关 192.168.1.1、DNS 指向 223.5.5.5，完整命令如下：

nmcli connection modify ens33 \ ipv4.method manual \ ipv4.addresses 192.168.1.20/24 \ ipv4.gateway 192.168.1.1 \ ipv4.dns "223.5.5.5" \ connection.autoconnect yes nmcli connection up ens33

第三行重点是ipv4.method manual，它把网卡从 DHCP 模式切换到手工指定模式，不带这一行，你改了后面的地址也会被自动忽略。connection.autoconnect yes确保重启后网卡自动激活，很多人配完不生效，往往是这一项没设。如果你需要同时配置多个 IP，可以在 addresses 后面用空格拼多个；DNS 可以设置多个，也是一样用空格分隔。

验证配置是否生效，用nmcli connection show ens33查看当前值，或者ip addr show ens33、ip route show直接看内核状态。修改连接后，NM 会自动将配置同步写入/etc/sysconfig/network-scripts/下的 ifcfg-enxxx 文件，其他工具也能读到。所以你看，CentOS 7 上你用 nmcli 改完，再回头去看 ifcfg 文件，里面已经被同步更新了，这两套体系其实是打通的。

如果你不喜欢记长命令，还有个交互式工具 nmtui。它按 TAB 切换按钮、方向键移动，对新手友好，能完成大部分基础配置。对于不熟悉 CLI 的运维同学，nmtui 反而比手动改文件安全得多，至少不会因为缩进错误直接断网。但 nmtui 有个小坑：某些版本里它会让你选择设备，而不是连接本身，如果你有两个连接绑在同一块网卡上，修改的时候容易搞混。使用时注意先把连接名和网卡名对照清楚。

3.2 netplan：Ubuntu 简洁但容错低的 YAML

新版 Ubuntu 从 18.04 起默认使用 netplan 统一管理网络后端，底层可以切换到 NetworkManager 或 systemd-networkd。netplan 的配置都放在/etc/netplan/目录下，通常是一个00-installer-config.yaml或01-network-manager-all.yaml文件。

下面是一个典型的静态配置示例：

network: version: 2 ethernets: ens33: dhcp4: no addresses: - 192.168.1.30/24 routes: - to: default via: 192.168.1.1 nameservers: addresses: - 223.5.5.5 - 114.114.114.114

写完文件后要执行netplan apply才能生效。在这步上踩过的坑有三个，逐一提醒。

第一是 YAML 缩进。netplan 对缩进极其严格，哪怕少一个空格，apply 时直接报错，网络完全不动。解决的办法是保持 2 空格缩进的一致，不要在文件里混用 TAB 和空格。如果你用的是 Vim，可以打开set expandtab避免按到 TAB，省得麻烦。

第二是dhcp4: no必须和addresses一起出现。如果你忘记关闭 DHCP，netplan 会同时尝试 DHCP 和静态地址，系统启动时地址可能飘忽不定。有时候你会发现明明配置了静态地址，却还是拿到一个奇怪的 DHCP 地址，十有八九就是这里出了问题。

第三是 routes 配置里用to: default而不是gateway4: ...。旧写法 gateway4 在较新的 netplan 版本里已经废弃，很多老教程用的是旧格式，复制到新系统会触发警告或直接忽略。用to: default / via: 网关是更规范的写法，也能兼容老版本。

netplan 的优势是配置文件简洁、可读性好，适合把网络配置当成基础设施代码来管理。缺点是它只是“翻译器”，最终还是要调用 systemd-networkd 或 NetworkManager 来执行，出问题时你需要再往下挖一层，检查对应后端的实际运行状态。如果 netplan apply 后没有报错，但网络还是不对，别只看 YAML，直接systemctl status systemd-networkd或者看 journalctl 里 network 相关日志，通常能找到真正的错误。

3.3 ifcfg 文件：CentOS 系运维的传家宝

CentOS 7 及更早版本中，网络配置落在/etc/sysconfig/network-scripts/ifcfg-ens33。文件内容是 KEY=VALUE 形式的声明式配置，没有缩进问题，但字段名较多，让人容易眼花。一个典型静态配置如下：

DEVICE=ens33 BOOTPROTO=static ONBOOT=yes IPADDR=192.168.1.40 NETMASK=255.255.255.0 GATEWAY=192.168.1.1 DNS1=223.5.5.5 DNS2=114.114.114.114

其中 BOOTPROTO 可选 static、dhcp，ONBOOT 控制开机自动启用。写完文件后执行systemctl restart network或ifup ens33让配置生效。CentOS 8 以后受 NetworkManager 接管更彻底，传统 ifcfg 文件虽然还在，但推荐直接使用 nmcli 去修改。

如果你手头还在维护老版本 CentOS，务必记住一条习惯：修改 ifcfg 文件前先cp ifcfg-ens33 ifcfg-ens33.bak，改完一定要检查 ONBOOT=yes，否则服务器重启后网卡不会自动启用。我见过不少生产故障就是 ONBOOT 被某次修改改成了 no，重启后整台机器直接失联。另外，GATEWAY 字段就算只有一个网卡需要默认路由，也建议写得明明白白，别用一个via命令代替，因为网络服务脚本不一定认得你的额外设置。

3.4 systemd-networkd：轻量服务器场景的性价比之选

systemd-networkd 不需要复杂管理服务，配置就是/etc/systemd/network/下的.network文件。拿静态配置举例：

[Match] Name=ens33 [Network] Address=192.168.1.50/24 Gateway=192.168.1.1 DNS=223.5.5.5 DNS=114.114.114.114

文件名建议以编号开头，比如10-ens33.network，方便排序。要启用这套方案，先把 NetworkManager 禁掉，再启动 systemd-networkd：

systemctl disable NetworkManager systemctl enable --now systemd-networkd systemctl restart systemd-networkd

systemd-networkd 另一个亮点是支持.netdev文件配置 VLAN、bond、bridge，把物理网卡和虚拟网卡的配置分文件放，逻辑清晰。如果你的机器是纯服务器、追求最小依赖，我很推荐它。缺点是没有像 nmcli 那样灵活的“连接”概念，修改配置文件后必须systemctl restart systemd-networkd才会生效，不适合频繁热改，不过对那些常年不动的服务器，这反而是个优点。

还有一个值得注意的设计：systemd-networkd 必须依赖 systemd 的 udev 规则来识别接口名，如果在[Match]里写错了 Name，服务不会报错，但网卡就一直配不上。排查时多看一眼networkctl list输出，它会告诉你 systemd-networkd 实际识别了哪些接口。

4. 进阶玩法：bonding、策略路由与网卡调优

4.1 bonding 是什么，为什么要配

生产环境里一块网卡挂了网络就断，这是谁都不愿看到的。Linux 的 bonding 功能可以让多块物理网卡聚合成一块逻辑网卡，既提高了吞吐量，也提供了链路冗余。常见模式有 balance-rr（mode 0）、active-backup（mode 1）、balance-xor（mode 2）和 802.3ad 动态链路聚合（mode 4）。

如果你是接到交换机上并希望两条线同时工作，优先考虑 mode 4（802.3ad），但它要求交换机端口开启 LACP。如果只是想冗余备份，mode 1 就够用，配置也最简单。用 nmcli 创建 bond 的命令是这样的：

nmcli connection add type bond con-name bond0 ifname bond0 bond.options "mode=active-backup,miimon=100" nmcli connection add type ethernet con-name bond0-eth1 ifname eth1 master bond0 nmcli connection add type ethernet con-name bond0-eth2 ifname eth2 master bond0 nmcli connection up bond0

配上之后，建议立刻测试剪断一根网线（或禁用一块网卡）时业务是否仍然正常。bonding 的坑主要在交换机侧：有的交换机端口没有配置聚合口，链路会反复协商导致网络时断时续。遇到这种情况，第一件事去查交换机的端口聚合配置，而不是盲目改 Linux 参数。还有个小细节，bond0 的 MAC 地址会沿用第一块备用网卡的 MAC，如果你做了 MAC 白名单，记得把 bond 的 MAC 也加进去。

4.2 多网关和策略路由：让流量按你指定的规则走

一台机器装了双网卡、接了两个不同的网络时，默认路由通常只会指向其中一个网关，另一个网段就成了“孤岛”。更科学的做法是配置策略路由，让来自不同网卡的流量走不同路由表。

假设有两块网卡 ens33（192.168.1.10）和 ens34（192.168.2.10），对应网关分别为 192.168.1.1 和 192.168.2.1。先用 ip 命令创建两张独立路由表：

echo "100 lan1" >> /etc/iproute2/rt_tables echo "200 lan2" >> /etc/iproute2/rt_tables ip route add default via 192.168.1.1 dev ens33 table lan1 ip route add default via 192.168.2.1 dev ens34 table lan2 ip rule add from 192.168.1.10 lookup lan1 priority 100 ip rule add from 192.168.2.10 lookup lan2 priority 200 ip route flush cache

这样源地址是 192.168.1.10 的流量走 lan1 表，源地址是 192.168.2.10 的流量走 lan2 表，彼此不再抢占默认路由。如果你希望某个网段固定走某一出口，也可以把from换成to段，例如ip rule add to 10.20.0.0/16 lookup lan1。

策略路由配置在不少发行版里不会自动持久化，需要把它和网卡配置放到同一个开机脚本或 systemd unit 里，最好写成 up 脚本，防止重启后规则消失。我自己比较懒，通常会写个/etc/rc.local或者 systemd service 来做，但更符合规范的做法是放到 NetworkManager dispatcher 或 netplan 的 routing-policy 里。如果你用的是 netplan，可以在接口配置里加 routing-policy 字段，这样配置文件和策略路由就放在一起管理了，netplan apply一次性生效。

4.3 ethtool 与网卡性能参数调整

配置好地址只是第一步，性能调优往往被忽略。用 ethtool 可以查看和修改网卡参数：

ethtool ens33 ethtool -s ens33 speed 1000 duplex full

如果网卡自动协商出来的速度不是你想要的，可以强制指定。但要注意，强制指定速度时网线、交换机端口都得支持，否则直接链路不通。另一个常用参数是关闭或开启 offload，比如ethtool -K ens33 tx-checksum-ipv4 off，这类调整更适合在专项压测时临时使用，平时不建议乱改。

查看网卡统计信息可以用ethtool -S ens33，主要关注 dropped、errors、collisions 等计数是否异常增长。如果 dropped 持续增加，可能是环形缓冲区太小，可以临时调大 rx/tx 的 ring size。要注意，这类参数同样是重启即失效的，想长期生效得写进 rc.local 或者 systemd service。想彻底优化网络，还需要结合 NUMA、CPU 亲和性、队列数等系统级参数通盘考虑，网卡配置只是其中的一块拼图。

4.4 让配置和脚本一起版本化

进阶玩法做多了，我逐渐养成一个习惯：把所有网卡相关的配置文件、脚本和开机自启条目都纳入版本管理，哪怕只是本地 git 仓库。原因很简单，网卡配置出错不仅影响网络，还影响你追踪问题的思路。如果你能快速 diff 出上一次正常配置和当前配置的差异，排查时间会缩短一大截。

我用三个命令快速备份当前网络配置：

mkdir -p ~/netconfig-backup-$(date +%F) cp -a /etc/network /etc/netplan /etc/sysconfig/network-scripts /etc/systemd/network ~/netconfig-backup-$(date +%F)/ 2>/dev/null ip addr show > ~/netconfig-backup-$(date +%F)/ip-addr.txt

这是很土但极其实用的一招。发生问题的时候，对比备份和当前文件，基本能定位是谁、什么时候、改了什么。配置乱改在生产环境里是大忌，多留一份快照能让你放心大胆去试错。

5. 常见问题速查与排查实录

5.1 重启之后配置全部丢失

这是排在第一位的新手问题。排查步骤：先确认系统到底由哪个网络服务管理，再看对应的持久化配置文件是否存在、是否生效，最后检查 NetworkManager 是否覆盖了手工修改。如果是 nmcli 管理的连接，需要connection.autoconnect yes；如果是 netplan，就要看 YAML 是否被正确 apply；老 CentOS 则重点检查 ONBOOT=yes。经验法则：修改配置文件后，先重启网络服务验证一次，再重启整机验证一次，双保险。

还有一个容易被忽视的点：有些云服务器的 cloud-init 会在每次启动时根据云平台的元数据重置网卡配置。如果你在云厂商的虚拟机里改了网卡配置，下次重启后又被 cloud-init 还原成厂商默认值，那说明网卡配置的优先级被 cloud-init 接管了。解决办法要么在 cloud-init 配置里禁用网络模块，要么把地址改成厂商期望的值，这属于云环境特有的坑，排查时要把这个可能性排在前面。

5.2 配置了静态 IP 但外网 ping 不通

这个问题我排查过很多案例，从最常发生的几个原因按顺序排查通常能解决。第一，默认路由是否存在：ip route show default，没有 default 路由就加一条。第二，DNS 是否能解析：用nslookup baidu.com或getent hosts baidu.com，不行就检查/etc/resolv.conf，确认 nameserver 地址可达。第三，防火墙是否拦了出站：systemctl status firewalld或iptables -L -n。第四，源地址策略路由冲突，双网卡机器尤其要检查 ip rule。第五，还是不通的话，用tcpdump -i ens33 icmp抓一下包，看请求是否发出去、是否能收到回包，这一步能最快地把问题缩小到链路、路由还是防火墙。

讲讲我经历过的经典案例：有一台服务器配置了双 IP，结果从某个网段来 ping 它总是超时。检查发现问题出在rp_filter反向路径过滤上，系统默认会检查入包源地址是否能从同一个网卡返回去，如果不对称，包就直接被丢弃了。这类问题在单网卡环境下很难遇到，双网卡、策略路由机器上尤其应该留意。排查时先看sysctl net.ipv4.conf.all.rp_filter，如果值是 1 且配置复杂路由，建议先临时设为 0 对比验证，再决定是否长期调整。

5.3 DHCP 获取不到地址

虚拟环境里很常见：网卡状态 UP 但一直拿不到 DHCP 地址。先看 dmesg 有没有网卡初始化日志，再用dhclient ens33 -v手动发起一次 DHCP 请求，观察服务端是否有回应。原因通常集中在三处：宿主机 DHCP 服务没开、虚拟网卡 MAC 地址被过滤、或者网卡驱动处于半残状态。手动 dhclient 成功后，再排查持久化配置里是否把 BOOTPROTO 或 dhcp4 设成了 no，这类误设会阻止系统开机时自动续约。

有个小经验：在 VMware 或 VirtualBox 里，如果你复制了虚拟机，MAC 地址也可能被复制，新机器和旧机器在同一个 DHCP 网段里“撞地址”的概率极大。建议复制完虚拟机后马上重置网卡 MAC（在虚拟化设置里都有“重新生成 MAC 地址”的选项），然后再启动网络服务。这种问题通常表现为：两台机器都能拿到地址，但总有其中一台断断续续失联，因为 DHCP 服务器把同一个 IP 分给了两个不同 MAC 的租约。

5.4 网卡名奇怪或有多个 ethX 乱跳

老旧物理机和某些特殊驱动环境下，网卡名可能不稳定。解决思路有三个：一是改内核参数net.ifnames=0回退到 ethX 命名；二是通过 udev 规则绑定 MAC 地址与固定网卡名；三是在 netplan 或 NM 配置里显式指定匹配条件。对单网卡机器，我通常建议不动这一步，保持默认命名即可，不必要的重命名反而会带来新的问题。

如果你在多网卡机器上做绑定，我推荐用 udev 规则来固定顺序，防止拔插网线或驱动加载顺序变化导致 eth1 和 eth2 互换。写 udev 规则时要绑定 MAC 和接口名，这样即使内核重新枚举设备，接口名也稳定。不过要注意，主板自带的多个网口 MAC 可能非常接近，写规则时一定要逐个ip link确认，别把两个网卡搞混。

5.5 高频排查命令速查表

6. 两点个人实践心得

最后聊点自己比较受益的操作习惯。

第一，改任何网络配置前，先备份相关配置文件，并顺手加个日期。不只是网卡，包括 SSH、防火墙这类“一改就失联”的配置都建议这么做。生产环境里更要养成小步变更、快速验证的习惯，别一口气改掉五六个参数然后统一重启，这样一旦出问题，根本不知道是哪条配置导致的不通。

第二，每次配置完，至少做三个验证：ping 网关验证链路，ping 外网 IP验证路由，再解析一个域名验证 DNS。只有三关都过了才算完事。如果你发现 ping 网关通、但外网域名解析不出来，问题八成在 DNS 而不是网卡。把这些验证固化成一个脚本，每次改完都跑一遍，能省下大量无谓的排查时间。

Linux 网卡配置的难度其实不高，真正劝退人的是发行版之间的配置方式和各种隐性条件。只要按本文的思路先识别管理框架、分清楚临时与永久配置、再按三要素顺序排查，绝大多数网卡问题都能在半小时内解决。下次再遇到“配了不生效”的问题时，先问问自己：系统到底是谁在管网络？我改的是不是它正在看的那份配置？想清楚这两点，问题就已经解决一半了。