配置网卡

配置网卡这件事，看似简单，实则暗藏不少陷阱。核心结论是：配置网卡的本质是设置好IP地址、子网掩码、网关和DNS这四个要素，并确保配置在系统重启后依然生效。 只要把这条链路的核心逻辑理清，无论面对的是CentOS、Ubuntu还是国产化系统，都能从容应对，很多运维事故的根源，往往不是“不会配”，而是“配完就断网”或“重启后失效”，这通常源于对配置文件、网络管理工具叠加关系的不理解，本文将从实操角度出发,梳理一套从规划到验证的完整方法论。

配置前必须理清的三个维度

在动手敲命令前，你需要先明白操作对象是谁，市面上绝大部分的“配置网卡报错”，都源于系统里同时存在多套网络管理工具，现代的Linux发行版往往同时内置了NetworkManager和systemd-networkd，如果两套工具管理同一个接口，就会出现配置被覆盖、重启后回滚的诡异现象。

• 工具维度：确认你的系统用的哪套网络管理栈，可以用 systemctl status NetworkManager 或 systemctl status systemd-networkd 来看，不要凭感觉。
• 接口维度：使用 ip link show 确认物理网卡名称，常见的是 eth0、ens33 或 enp0s3，千万不能想当然写错名字。
• 模式维度：是动态获取（DHCP）还是静态指定？如果是云服务器，大多数情况需要在控制台配置弹性IP，但在操作系统内部依然要把网卡配置为静态或DHCP,这取决于虚拟化平台对接方式。

分层实操：两种主流配置方案

我强烈建议放弃直接编辑 /etc/resolv.conf 的习惯，因为该文件极容易被覆盖，以下两种方案足够覆盖95%的场景。

使用NetworkManager（适用桌面和动态环境）

对于多数云主机和现代化服务器，NetworkManager是默认守护进程，它的核心命令是 nmcli，推荐用交互式配置方式,回退安全。

• 先查看连接名称：nmcli connection show，注意，连接名可能叫 Wired connection 1，不一定是 eth0。
• 修改该连接的IP设置：

  nmcli connection modify "Wired connection 1" ipv4.method manual ipv4.addresses 192.168.1.100/24 ipv4.gateway 192.168.1.1 ipv4.dns "8.8.8.8 114.114.114.114"

• 重新激活连接：nmcli connection up "Wired connection 1"

特别提醒：ipv4.method manual 是静态配置的开关，如果不写这一句，即使填了IP地址，重启后也会变回DHCP，这个问题至少要占配置网卡报错比例的30%。

使用systemd-networkd（适用极简和容器环境）

如果你的系统为了精简，没有安装NetworkManager，那么就是.network文件在起作用，你需要创建 /etc/systemd/network/10-eth0.network 文件。

[Match]
Name=eth0
[Network]
Address=192.168.1.100/24
Gateway=192.168.1.1
DNS=8.8.8.8
[Route]
Destination=10.0.0.0/8
Gateway=192.168.1.2

配置完成后，执行 systemctl restart systemd-networkd。这里有一个独立见解：利用 [Route] 段配置静态路由，远比在传统 /etc/sysconfig/network-scripts/route-eth0 里写命令要更直观，且与systemd生态结合更紧密,不容易出现路由重启丢掉的坑。

酷番云经验案例：一次误删默认路由的深度复盘

这里分享一个在酷番云实际处理过的业务场景的经典案例。背景：某客户在酷番云上部署了双网卡ECS实例，主网卡绑定公网IP，辅助网卡接入内网VPC，客户为了做内网VXLAN隧道，手动修改策略路由

，临时在命令行敲了 ip route del default，结果瞬间公网失联,但VNC控制台还能登入。

• 专业诊断：通过VNC登录后发现，系统已经无法访问网关，此时我并没有直接去添加临时路由，而是检查了 ip rule 策略路由表，因为公网网关走了 main 表，而内网走了 table 100，客户当时只删了 main 表默认路由,内网流量却因为策略路由规则而存活。
• 权威解决方案：在酷番云控制台辅助网卡的安全组和路由表中核对了子网信息，随后在系统内执行：

  ip route add default via 172.16.0.1 dev eth0 table main

  同时，为了避免重启失效，将这条默认路由固化到了 /etc/sysconfig/network-scripts/route-eth0 文件中，这里最核心的经验是：云服务器的网卡配置文件里默认带有 NM_CONTROLLED=no 的兼容性开关，排查时一定要结合云控制台的“私有网络”底层逻辑，不能只盯着操作系统里的配置文件看。

配置后的自检三板斧

配置完网卡不要立刻走人，按下顺序强制验证,否则可能遗留无声的隐患。

• 检查连通性：ping -c 3 192.168.1.1（网关），如果网关不通，检查掩码和网线/安全组。
• 检查解析：dig +trace baidu.com 或 nslookup baidu.com，这里推荐用 dig，因为它能清晰地展示哪一步DNS解析慢。
• 重载验证：所有网卡配置修改后，必须重启机器或用 systemctl restart network 进行最终验证，这一步是为了确认配置没有藏在内存里,而是真正读写到了持久化存储。

相关问答模块

为什么我配置了静态IP地址和网关，但一重启网卡就失效，且 ifconfig 看到的IP是正确的，而 ip addr 看到的IP却是旧的？

解答：这通常是因为你直接用了 ifconfig eth0 192.168.1.100 netmask 255.255.255.0 up 这类命令。ifconfig 命令只修改了内核中的临时接口地址，并没有修改任何配置文件，当你执行 systemctl restart network 时，NetworkManager（或networkd）就会从 /etc/sysconfig/network-scripts/ifcfg-eth0 或 .network 文件里重新加载旧配置，把未持久化的IP覆盖掉。解决方案：所有配置一律通过 nmcli 或修改 .network 文件完成，不要用 ifconfig 做持久化配置。

云服务器 (如酷番云ECS) 的 /etc/resolv.conf 总是被自动覆盖，我修改了DNS却不起作用，该如何解决？

解答：在云服务器环境中，resolv.conf 由DHCP客户端或者systemd-resolved接管，手动编辑是无效的。正确的处理方式有两种：其一，在网卡配置文件中指定DNS（如DHCP协议下的 PEERDNS=no 加 DNS1=8.8.8.8）；其二，如果必须持久化自定义DNS，建议关闭本机DNS解析服务对它的管理，使用 chattr +i /etc/resolv.conf 加锁，但这属于非常规手段，会增加后续维护成本，在酷番云上，更推荐直接在控制台修改VPC的 DHCP 选项集，这样内网域名和公共DNS都能从源头统一分配,无需再在系统内和文件做持久化纠缠。

配置网卡是一个“失之毫厘，谬以千里”的活儿。欢迎你在评论区分享你曾经遇到过的奇葩网卡配置故障，或者对云服务器网络底层配置有哪些疑问，我们一起探讨，让运维之路走得更稳。