必须先确认实际网络管理机制:运行ip -br a查网卡名、ip route | grep default看dhcp痕迹、cat /etc/resolv.conf辨dns来源,再依ls /etc/netplan/、nmcli connection show、ls /etc/sysconfig/network-scripts/ifcfg-*等判断后端服务,避免误配。

静态 IP 配置失败,90% 是因为没搞清系统实际用的是哪套网络管理机制——硬套教程改错文件,轻则不生效,重则断网。
怎么快速确认当前网络管理机制
别急着打开配置文件,先跑这三行命令看真实状态:
-
ip -br a—— 找出真实网卡名(比如ens33、enp0s3),别选lo或带@的虚拟接口 -
ip route | grep default—— 看默认网关走哪个接口,同时留意输出里有没有dhcp字样(有就说明当前是 DHCP 模式) -
cat /etc/resolv.conf—— 如果开头是# Generated by NetworkManager或# systemd-resolved,说明 DNS 是动态注入的,不能直接改这个文件
再查后端服务:
-
ls /etc/netplan/有文件 → Ubuntu 17.10+ / Debian 11+ / CentOS Stream 默认走 Netplan -
nmcli connection show有输出且systemctl is-active NetworkManager返回active→ 优先用nmcli -
ls /etc/sysconfig/network-scripts/ifcfg-*存在 → RHEL/CentOS/Fedora/Alibaba Cloud Linux 风格 -
cat /etc/network/interfaces有iface块 → Debian/Ubuntu Server 传统 ifupdown
netplan 配置后 netplan apply 不生效
Netplan 本身不干活,它只是把 YAML 翻译给后端(systemd-networkd 或 NetworkManager)。常见静默失败点:
- YAML 缩进用了 Tab 键 → 必须全用空格,
sudo netplan --debug apply会报具体哪行解析失败 -
addresses:写成192.168.1.100/24(无括号/破折号)→ 必须是列表:[192.168.1.100/24]或换行加- -
gateway4:写成gateway:→ 后者是无效字段,会被忽略 -
nameservers:下漏掉addresses:键 → 正确写法是:nameservers: {addresses: [8.8.8.8, 114.114.114.114]} -
renderer:值和实际运行服务不一致 → 比如设了renderer: networkd,但systemctl is-active systemd-networkd是inactive,那就白配
nmcli 修改后 ping 不通网关
这是 NetworkManager 场景下最典型的“配置写了但没生效”问题。只改 ipv4.method manual 不够,缺一不可:
- 必须配套设置
ipv4.addresses、ipv4.gateway、ipv4.dns,三者少一个,NM 就 fallback 回 DHCP - 改完必须执行
nmcli connection down "连接名" && nmcli connection up "连接名",不能只 reload - 连接名要严格匹配
nmcli connection show输出的名称(含空格或引号,比如"System ens33") - 如果之前用
ip addr add临时加过地址,先ip addr flush dev ens33清掉,避免冲突
CentOS/RHEL 7–8 改 ifcfg-xxx 文件后不生效
这类系统靠 network.service 读取配置,失效往往不在 IP 字段本身:
-
BOOTPROTO必须是static或none(二者等效),不能留dhcp -
ONBOOT=yes缺失 → 开机不启用该接口 - 改完必须
systemctl restart network(CentOS 7)或nmcli connection reload && nmcli connection down "连接名" && nmcli connection up "连接名"(如果 NM 管理了该接口) - 不要用
ifconfig ens33 192.168.1.100临时改 —— 这种方式重启即丢,且可能和配置文件冲突
复杂点在于:同一台机器上可能同时存在 NetworkManager 和 network.service,它们会互相覆盖配置。真要持久化,必须停掉其中一个,否则永远在“改了又回滚”的循环里。











