企业官网建设流程全解析

1. 先搞清楚 nmcli 在管什么，不然全是瞎调

nmcli 这个命令，我最初是排斥的。理由很朴素：改配置文件多直观，vi /etc/sysconfig/network-scripts/ifcfg-eth0一行一行照着抄，改完重启网络服务，一切都在眼皮底下。nmcli 呢，一堆con-name、ifname、ipv4.method，参数记不住，敲错一个字母还不报错，直接生成一个名字奇怪的新连接。后面被现实教育了几次——反复重装、批量交付、远程改网卡把自己锁在门外——我才老老实实把 nmcli 用成了主力工具。这篇文章就把这些年攒下来的东西一次讲透：nmcli 配置网络的那些核心概念、从 DHCP 到静态 IP 的完整命令、WiFi 与网卡绑定、网桥和 VLAN 这类虚拟网络，以及最容易出事的排查环节。不管你是刚接手一批机器的新手，还是习惯改文件的老手，看完都能直接抄命令。

1.1 为什么命令行党最后都回到了 nmcli

先把定位说清楚：nmcli 是 NetworkManager 的命令行客户端，它不是另起一套网络体系，而是给 NetworkManager 这个守护进程发指令。所以你敲的每一条 nmcli，本质上都是在对 NetworkManager 说“按这个描述建一个连接”“把这个连接挂到那块网卡上”“现在就激活它”。真正干活的是后台的 NetworkManager，它负责拉地址、写路由、维护 DNS、监听链路状态。搞明白这层关系，很多“为什么我改完没生效”的疑问自然就通了——命令只是表达意图，激活才是让意图落地。

那为什么值得从 ifcfg 文件迁过来？我总结成三条实打实的理由。第一条是结构化。ifcfg 是一堆扁平键值对，写错字段名不报错，写重复了看运气，不同发行版字段还各玩各的。nmcli 的属性名是固定的、有层级关系的，ipv4.addresses、ipv4.gateway、ipv4.dns各司其职，敲错会直接给你报错，比默默生效要安全得多。第二条是原子性。改文件的时候，从你打开编辑器到保存退出，中间那段时间配置文件是半成品状态，如果这时候恰好网络重启，读到什么算什么。nmcli 的modify是一次性提交，不存在中间态。第三条是可脚本化。批量给几十台机器配同样的网络，把命令塞进脚本里跑，比 sed 正则替换配置文件要稳得多，也更容易回滚。

还有个容易被忽略的隐性收益：状态与配置分离。用文件方式的时候，你很难快速回答“现在这块网卡到底挂了几个地址、走的是哪条路由、DNS 从哪来”。nmcli 的查询子命令能一次性把这些摊开给你看，排查的时候这点极其重要。远程排障最怕的就是信息不全，一个nmcli打下去，配置意图和运行状态能对照着读，效率完全不是一个量级。

当然也不是没代价。nmcli 的学习曲线比改文件陡，参数命名长，而且不同版本的 NetworkManager 支持度有差异——老版本不支持某些ipv4.routes的写法，新版本又把ipv6.method的默认值改了。我现在的做法是：手里常备一份目标环境的nmcli --version输出，写命令之前先确认版本，避免拿新语法往老系统上怼。

1.2 连接（connection）与设备（device）是两套东西

这是初学 nmcli 最容易卡住的地方，必须一开始就掰开。device 是物理或虚拟的那块网卡，比如 eth0、ens33、wlan0，它代表硬件实体，有 MAC 地址、有链路状态、有插没插网线。connection 是一份配置档案，里面写着“如果挂到某块网卡上，就用这个 IP、这个网关、这个 DNS”。两者是多对一的关系：一块网卡上可以存好几份 connection，但同一时刻只有一份处于激活状态。

这个模型带来的最大好处是切换成本极低。我给笔记本的无线网卡建三份 connection：一份公司内网静态地址，一份家里 DHCP，一份调试用的固定地址。到地方了nmcli connection up 名字，一秒钟切过去，不用改任何文件。这在改文件的年代是不可想象的，你得备份、改、重启、发现改错了、再改回来。

理解了这个模型，很多“灵异现象”就有解释了。比如你nmcli connection add建了一个连接，网卡上却没反应——因为它只是被存下来了，没被激活。比如你nmcli connection delete删了一个连接，网络还在跑——因为删的是档案，已经在跑的配置还留在内核里，直到下次激活才会真正断开。又比如你改完ipv4.addresses发现ip addr没变——因为改的是档案，运行态没动。

还有一层概念是autoconnect。每份 connection 默认autoconnect yes，意思是只要对应设备出现（比如网线插上、无线网卡上电），NetworkManager 就自动尝试激活它。如果一块网卡上有多份 autoconnect 的连接，就会按autoconnect-priority抢，抢不到的那份就处于 standby。多网卡多网段的机器上，这个优先级设不对，就会出现“网线插了但地址是另一个网段的”这种诡异情况。我一般会给主用连接设autoconnect-priority 10，备用设 0 甚至关掉自动，让行为完全可预期。

2. 上手前的环境确认，三分钟省下三小时

动手改网络之前，有几件事必须先确认，顺序错了就会浪费时间。最典型的：机器上根本没装 NetworkManager，或者装了但没在跑，或者跑了但不管你这块网卡。这三种情况下 nmcli 都会“假装成功”——命令返回 0，连接也建出来了，但网卡纹丝不动。我曾经在容器里折腾了二十分钟才发现根本没有 NetworkManager 这个服务，纯属白给。

2.1 确认 NetworkManager 真的在管这块网卡

第一步，看服务状态。systemctl status NetworkManager，看到 active (running) 才继续往下走。没装的话各发行版的包名差不多，装完记得 enable，否则重启后网络全丢，远程机器直接失联，这个坑我吃过不止一次。

第二步，也是最关键的一步，看设备托管状态。执行nmcli device status，输出四列：DEVICE、TYPE、STATE、CONNECTION。重点看 STATE 这一列。connected表示已激活，disconnected表示空闲但可管理，unmanaged就是你要警惕的那个——它表示 NetworkManager 明确不管这块网卡。这时候你敲什么 nmcli 命令都没用，会直接告诉你 “device is strictly unmanaged”。

出现 unmanaged 的常见原因有这么几种：一是有别的服务在管这块网卡，比如某些系统里 network 服务还在跑，两套东西打架；二是配置文件里被标了NM_CONTROLLED=no；三是/etc/NetworkManager/NetworkManager.conf里[keyfile] unmanaged-devices=把这块卡排除了；四是网卡是某些特殊虚拟接口，默认就不在管理范围内。我处理的原则很简单：既然要用 nmcli，就让 NetworkManager 独占管理权，把旧的服务停掉并禁用，避免两个守护进程互相覆盖配置。

如果确认要接管，可以用nmcli device set eth0 managed yes临时接管（重启失效），或者直接改上面的配置文件做持久化。改完记得systemctl reload NetworkManager。

2.2 三个查询起手式，先摸清现状再动手

我形成了条件反射，只要登上一台不熟的机器，先敲这三条，把地形摸清楚再动手。

再补一条查明细的：nmcli connection show "连接名"，能把这份档案的所有属性全列出来，包括那些你没显式设过、用的是默认值的属性。这个信息量很大，排查时特别有用，比如你能看到ipv4.method到底是 auto 还是 manual，ipv4.dns是不是空，connection.autoconnect有没有被谁关掉。

三个小技巧顺手记一下。nmcli -p加不加差别很大，加了会用表格线排版，人眼看更舒服；nmcli -t输出用冒号分隔，适合管道和 awk 处理；nmcli -f可以只输出指定字段，比如nmcli -t -f NAME,DEVICE connection show一眼看全映射关系。写脚本的时候这三个选项组合起来用，比解析完整输出可靠得多。另外nmcli -g可以直接取单个属性值，比如nmcli -g IP4.ADDRESS device show eth0，拿来做判断条件很顺手。

3. 有线网络配置：从 DHCP 到静态 IP 的完整动作

有线是最常见的场景，也是把概念落实到命令上最好的练习场。这里我按使用频率排一下：先 DHCP，再静态 IP，然后是“改完为什么不生效”这个高频困惑，最后是多地址、多路由、DNS 优先级这些进阶操作。每一段都给可以直接复制粘贴的命令，参数换掉就能用。

3.1 DHCP 场景：新建连接与切换现有连接

如果网卡上已经有一份自动获取地址的连接，最简单的方式是直接激活它：nmcli connection up "有线连接 1"，名字按实际情况换。想新建一份干净的 DHCP 连接，命令是这样的：

nmcli connection add type ethernet \ con-name office-dhcp \ ifname eth0 \ ipv4.method auto \ ipv6.method ignore \ connection.autoconnect yes

几个参数值得说透。con-name是这份档案的名字，你自己定，后面所有操作都靠它定位；ifname是绑定的网卡名，这个必须和nmcli device status里看到的完全一致，写错了会生成一份挂不上任何设备的孤儿档案。ipv4.method auto就是 DHCP。ipv6.method ignore是我个人的习惯——纯 IPv4 环境里，让 IPv6 去自动协商有时候会拖慢激活速度，而且部分环境里会生成一堆scope link的地址干扰阅读，明确关掉更清爽。如果确实要 IPv6，改成auto，静态的话用manual加ipv6.addresses。

还有一个细节：add只是把档案建出来，如果这份连接被标记为 autoconnect（默认就是），NetworkManager 通常会立刻尝试激活它。但请不要依赖这个行为，养成显式nmcli connection up office-dhcp的习惯，你才知道它到底有没有成功。激活成功后，用ip addr show eth0和ip route交叉验证地址、网关是否如期到位，这一步别省。

顺带说下切换。假设机器现在用的是静态地址的连接，你想临时切成 DHCP 抓包看看，直接nmcli connection up office-dhcp，NetworkManager 会自动把原来那份连接 down 掉再激活新的，因为同一块设备同一时刻只能有一份活动连接。切回去就反过来 up 原来那份。整个过程不需要重启任何服务，也不会有“配置文件改一半”的窗口期。

3.2 静态 IP：地址段怎么算，参数怎么填

静态 IP 是 nmcli 真正体现价值的地方，尤其是需要反复重建环境的场合。先给一个完整的命令模板：

nmcli connection add type ethernet \ con-name office-static \ ifname eth0 \ ipv4.method manual \ ipv4.addresses 192.168.10.50/24 \ ipv4.gateway 192.168.10.1 \ ipv4.dns "192.168.10.2,192.168.10.3" \ ipv4.dns-search "corp.local" \ ipv6.method ignore \ connection.autoconnect yes

改现有连接的话，用nmcli connection modify加同样的属性名，比如把 DHCP 改成静态就是先modify ... ipv4.method manual再补 addresses 和 gateway。

参数怎么定，这里展开讲一下计算过程，因为这是最容易拍脑袋的地方。假设运维给你的网段是192.168.10.0/24。/24意味着前 24 位是网络位，剩下 8 位是主机位，地址总数 2 的 8 次方等于 256 个。去掉网络号.0和广播地址.255，可用主机地址是 254 个，范围从.1到.254。掩码写法是255.255.255.0。一般网关会占.1或者.254，这两个是行业惯例，但别假设，问清楚。

具体给这台机器分哪个地址，我的习惯是从高位往低位避开：.1到.20留给网关、交换机、存储、打印机这类基础设施；.21到.199通常是 DHCP 池（具体范围要跟管 DHCP 的人确认）；.200往上留给服务器和需要固定地址的业务机。所以我会取.50或者.210这种明显不在冲突区的位置。这个习惯救过我——曾经随手用了.100，结果撞上 DHCP 池里的动态分配，两边抢地址，表现是网络时通时断，查了半天才定位到地址冲突。

再看一个非 24 位的例子，10.20.30.0/26。/26表示主机位是 6 位，地址总数 64，可用主机 62 个。地址块是 0 到 63，网络号.0，广播.63，可用范围.1到.62，掩码255.255.255.192。下一个子网从.64开始。这种情况下如果误写成/24，这台机器会认为.0到.255都是同网段，凡是访问.64以上的地址都不会走网关，直接发 ARP 找，结果当然是找不到，表现为“能通网关但通不了同楼层的其他机器”，特别迷惑。所以掩码这个数字，宁可不写也别写错，写完ip route一看就知道对不对——路由表里会显示这条直连路由的 scope，掩码错了立刻能看出来。

DNS 的写法有个小坑：多个地址在不同版本的 nmcli 里，有的用逗号分隔整体加引号，有的允许空格分隔多个参数，混乱的时候用+ipv4.dns追加最稳：

nmcli connection modify office-static +ipv4.dns 192.168.10.4

加号表示追加，减号表示移除，-ipv4.dns 192.168.10.4就把这一个删掉。这个语法对其他多值属性同样适用，比如多个地址、多条路由，值得记牢。

提示：ipv4.method manual之后如果没有配 gateway，这台机器只能跟同网段通信。跨网段访问会直接失败，但ip addr看起来一切正常，非常容易误判成“网络没问题，是对方服务挂了”。

3.3 改完为什么不生效：up、down 与 reload 的区别

这是 nmcli 新手期最大的困惑来源，我把这三个动作的区别掰开说。modify 改的是磁盘上的档案，运行中的网络完全不受影响，ip addr看到的还是老样子。up 是激活，用当前档案重新配置设备，会先清掉旧的地址路由再按新配置来一遍，这个动作会造成短暂断网。down 是取消激活，设备回到 disconnected 状态，地址路由全清。reload 是重读配置文件，当你手动编辑了/etc/NetworkManager/system-connections/下的文件，需要 reload 让 NetworkManager 重新加载，但 reload 本身不会去激活任何东西。

所以标准动作是：modify改配置，up让它生效。如果是远程操作，这里有个致命陷阱：你改的正是自己正在用的那条连接，down下去 SSH 立刻断，up上不来就只能去机房了。这种情况我的做法有两个。一是先建一份新连接，验证能用，再切过去，全程不 down 现有连接，靠 up 新连接自动顶掉旧的，中间断的是毫秒级。二是写个延时回滚脚本再用 at 或 nohup 挂着跑，改成 5 分钟后如果检测不到网络就自动恢复原配置。第二个方法听起来重，但在改默认路由这种危险操作时非常值。

还有一个细节要提：较新版本的 NetworkManager 里，修改活动连接的某些属性后会自动重新应用（reapply），不用手动 up。但哪些属性支持自动应用、哪些必须重新激活，不同版本行为不一致，我从不依赖这个特性。老老实实 up，行为可预期。

配置文件那层也顺便说一下。nmcli 建的连接最终会落到/etc/NetworkManager/system-connections/下的.nmconnection文件里，权限是 600，因为里面可能有 WiFi 密码这类敏感信息。手动改这些文件不是不行，但改完必须nmcli connection reload，而且格式错一个缩进就整份无效，NetworkManager 会静默忽略然后你一脸茫然。所以我现在的原则是：能用 nmcli 表达的，绝不手改文件；确实要手改的，改完立刻 reload 并nmcli connection show "名字"验证是否解析成功。

3.4 多地址、多路由、DNS 优先级这些细活

单地址单网关是入门，真正在工作里遇到的是多地址多路由。先说绑定多个 IP，这个在迁移场景特别有用——老地址不能立刻下线，新地址先加上，等业务都切过去了再摘老的。命令很简单，ipv4.addresses支持多个，用逗号分隔：

nmcli connection modify office-static \ ipv4.addresses "192.168.10.50/24,192.168.10.51/24"

第一个地址是主地址，出站流量的源地址默认用它，这个顺序有意义，别随意调。

多路由的场景更常见。假设这台机器默认走192.168.10.1，但需要访问10.0.0.0/8时走内网另一台路由器192.168.10.254，可以这样配：

nmcli connection modify office-static \ +ipv4.routes "10.0.0.0/8 192.168.10.254"

格式是“目标网段 下一跳”，可选再跟一个 metric。如果目标是直连的（同网段），下一跳可以省略，只写网段和掩码。添加成功后ip route里会多一行10.0.0.0/8 via 192.168.10.254，用nmcli connection up激活后才会出现。

默认路由冲突是多网卡机器上最经典的问题。两块网卡都配了网关，都写默认路由，内核按 metric 小的优先，结果就是网络时通时不通，或者流量乱走。解决办法是：只让一块网卡提供默认路由，另一块明确标记不抢默认网关：

nmcli connection modify backup-nic ipv4.never-default yes

或者更精细地控制优先级，给主链路设小 metric、备链路设大 metric：

nmcli connection modify primary-nic ipv4.route-metric 100 nmcli connection modify backup-nic ipv4.route-metric 600

metric 值的规划我一般留出足够间隔：有线主用 100，有线备用 200，无线 600，虚拟网桥 400。间隔大是为了后面插入新链路时不用重排。无线设大的理由很直白——无线延迟抖动明显，有线在的情况下不该让无线抢默认路由。

DNS 优先级这块，ipv4.dns里的顺序就是查询顺序，但真正生效还取决于系统用哪个解析框架。如果/etc/resolv.conf被别的组件接管（比如本地缓存服务），你在 nmcli 里设的 DNS 可能被覆盖掉。遇到“配了 DNS 但不生效”，先看cat /etc/resolv.conf里的实际内容，再看nmcli connection show "名字" | grep dns里配的是什么，两边对不上就说明中间有一层接管了。这个排查顺序我踩过不止一次坑，值得记住。

4. 无线、绑定、网桥与 VLAN：虚拟网络的几种高频姿势

有线之外，这四类场景在实战中出现的频率最高：无线连接（笔记本、边缘设备）、网卡绑定（服务器冗余）、网桥（虚拟化宿主机）、VLAN（多网段隔离）。把它们放在一起讲，是因为它们都遵循同一套 connection/device 模型，学会一个，其余都是换参数。

4.1 WiFi 命令行连接与隐藏热点

命令行连 WiFi 我一开始觉得没必要，直到有一次在一台没有图形界面的小机器上，只能靠命令行连。流程分两步：先扫描，再连接。

nmcli device wifi list nmcli device wifi connect "热点名称" password "密码"

第一条列出周边可见的热点，包含信号强度、加密方式、信道等信息。第二条直接连上去，会自动创建一份对应的 connection 档案，名字就是热点名。如果信号弱或者扫描不到，可以加--rescan yes强制重扫，有时候缓存里的列表是几分钟前的，热点早就挪位置了。

隐藏热点（不广播 SSID）需要手动建连接：

nmcli connection add type wifi \ con-name hidden-office \ ifname wlan0 \ ssid "热点名称" nmcli connection modify hidden-office \ 802-11-wireless.hidden yes \ wifi-sec.key-mgmt wpa-psk \ wifi-sec.psk "密码" nmcli connection up hidden-office

这里的wifi-sec.key-mgmt要根据热点实际加密方式选，家用和办公环境绝大多数是wpa-psk，企业环境用 802.1X 的话配置复杂得多，需要证书和账号，那属于另一个话题。密码写在命令行里会留在 shell 历史中，我一般会先history -c或者用nmcli connection edit的交互模式来录入，敏感环境要注意这点。另外802-11-wireless.hidden yes只在连接隐藏热点时需要，普通热点加上反而会让激活变慢，因为客户端要主动去探。

还有个实用技巧：无线和有线同时存在时，用ipv4.route-metric压住无线的优先级（前面说的 600），这样插着网线时流量不会莫名其妙走无线。我在会议室里被这个坑过——笔记本连着有线，但默认路由飘到了无线，访问内网服务器全部超时，查了半天才发现是 metric 的问题。

4.2 双网卡绑定：模式选择与配置顺序

网卡绑定（bond）的目的有两个：冗余和带宽。选哪个模式决定了怎么配。

我默认推荐active-backup，理由很实在：它不需要交换机配合，任何环境都能上，故障切换通常在毫秒级到秒级，配好miimon之后足够用。802.3ad看起来诱人，但要交换机那边同步配好聚合组，两边模式不匹配的话直接起不来，而且排查起来很痛苦——链路状态看着正常，就是不通。

配置顺序很关键：先建 bond 主接口，再加从接口，最后配 IP。顺序错了，从接口会找不到主人。

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-slave1 \ ifname eth1 master bond0 nmcli connection add type ethernet con-name bond0-slave2 \ ifname eth2 master bond0 nmcli connection modify bond0 \ ipv4.method manual \ ipv4.addresses 192.168.10.60/24 \ ipv4.gateway 192.168.10.1 nmcli connection up bond0

miimon=100是每 100 毫秒检测一次链路状态，单位是毫秒。这个值的取舍：设太小，链路偶尔抖动就触发切换，造成不必要的闪断；设太大，真断了要等好几秒才切。100 毫秒是绝大多数场景的平衡点，我基本不调。如果是跨机柜的长链路，可能调到 200 到 500 更稳。

从接口配置完成后要注意：不要让从接口自己有 IP。它们只是 bond 的成员，地址应该只配在 bond0 上。如果从接口上还残留着之前配的地址和默认路由，会出现路由冲突。建完从接口后我一般会用nmcli -f IP4.ADDRESS device show eth1确认一下是空的。

验证绑定状态不用猜，cat /proc/net/bonding/bond0里信息很全：当前主链路是谁、每块成员卡的状态（up/down）、切换次数。做冗余演练的时候，拔一根网线，看这个文件里的Active Slave是否切换过去，比 ping 更直接。

4.3 网桥与 VLAN：虚拟化与多网段隔离的常规操作

网桥的典型场景是虚拟化宿主机——虚拟机要通过桥接直接拿到物理网段的地址，就得让物理网卡作为桥的成员，IP 配在桥上。配置思路和 bond 类似：

nmcli connection add type bridge con-name br0 ifname br0 \ bridge.stp no nmcli connection add type ethernet con-name br0-port1 \ ifname eth0 master br0 nmcli connection modify br0 \ ipv4.method manual \ ipv4.addresses 192.168.10.70/24 \ ipv4.gateway 192.168.10.1 nmcli connection up br0

bridge.stp no是关闭生成树协议。为什么关？在只有一条上行链路的宿主机上，STP 起不到防环作用，反而会让桥口进入 listening/learning 状态，白白等上几十秒才转发。虚拟机启动后网络要等半分钟才好，很多人以为是虚拟机的问题，其实是 STP 在等。只有多桥互联、存在环路风险的环境才需要开 STP，那种情况另说。

VLAN 用来在一条物理链路上划出多个逻辑网段，交换机侧配好 trunk 之后，主机侧也要对应建子接口：

nmcli connection add type vlan con-name vlan100 \ dev eth0 id 100 \ ipv4.method manual \ ipv4.addresses 10.100.0.20/24 nmcli connection up vlan100

dev eth0指定父接口，id 100是 VLAN 标签。这里有个容易被忽略的点：父接口 eth0 本身不需要配 IP，它可以是一份 DHCP 连接，也可以完全不激活。VLAN 子接口是独立的 connection，有自己的地址和路由，和父接口互不干扰。VLAN 标签会在以太网帧里占 4 个字节，所以理论上 MTU 会比父接口小 4，一般不用手动调，但如果链路上跑着对 MTU 敏感的业务（比如某些隧道协议），就得留意这个细节，必要时把父接口 MTU 调到 1504、子接口保持 1500。

虚拟网络这块我的经验是：先把最简单的跑通，再往上叠。先确认裸网卡能通，再建 VLAN 验证，再套网桥。一次性把 bond + vlan + bridge 三层叠起来配，出问题时根本不知道是哪一层挂的，排查时间成倍增长。

5. 故障排查实录与高频坑位速查

网络配置出问题的特点是一旦错了，往往连远程都连不上，只能靠控制台。所以排查能力比配置能力更重要。这一节我按“遇到什么现象、往哪查、怎么修”的顺序整理，都是真实踩过的。

5.1 我遇到过的典型故障与排查路径

现象一：nmcli connection up报 “Connection 'xxx' is not available on device eth0 because device is strictly unmanaged”。这个前面提过，设备没被托管。查nmcli device status确认 STATE 是 unmanaged，然后看是不是有别的网络服务在跑，或者配置文件里排除了这块卡。修法是停掉冲突服务、清掉排除规则，然后systemctl reload NetworkManager。有次我怎么改都不生效，最后发现是安装系统时留下的一个旧服务还在后台跑着，两个守护进程抢同一块网卡，谁后启动谁赢，行为完全随机。

现象二：配置全对，ip addr也有地址，就是 ping 不通网关。先查链路层：ip link show eth0看是不是state DOWN，网线没插或者对端端口没启用的话，地址配得再对也没用。再查 ARP：ip neigh show看网关的 MAC 有没有解析出来，一直是INCOMPLETE说明二层不通，可能是 VLAN 标签不匹配、交换机端口划错 VLAN，或者对端做了端口安全限制。这个排查路径我按顺序走，基本三分钟内能定位到是三层还是二层的问题。

现象三：能通内网，上不了外网。九成是默认路由或者 DNS 的问题。ip route看有没有default via，没有就是网关没配上或者被never-default挡住了；有的话ping 8.8.8.8（一个公网地址）测试，能通说明是 DNS 问题，cat /etc/resolv.conf看解析器配的什么。DNS 不生效最常见的原因是配置文件里的 DNS 被别的组件覆盖了，或者ipv4.dns里写了但连接的ipv4.ignore-auto-dns没处理好导致 DHCP 下发的 DNS 混进来。修法是明确指定ipv4.ignore-auto-dns yes然后用ipv4.dns写死。

现象四：改了配置，重启后变回去了。大概率是改的不是持久化配置——比如用ip addr add临时加的地址，重启当然没了。或者改的连接没有设autoconnect yes，重启后没自动激活，NetworkManager 挑了一份老的连上去了。还有一种情况是机器上有多个网络管理工具，重启时另一个先跑起来把配置覆盖了。查法是重启后立刻nmcli connection show --active看激活的是哪份，跟自己改的对不对得上。

现象五：双网卡机器，SSH 时断时续。典型的默认路由冲突或者 ARP flux。两块网卡在同一个二层网络里，回包可能从另一块卡出去，源地址不一样，对端就认为连接异常。修法是给不承担默认路由的那块卡设ipv4.never-default yes，必要时再用策略路由控制回包路径。

5.2 高频问题速查表

5.3 几条压箱底的实操习惯

第一条，动网络之前先留后路。远程机器上改网络，我一定会先确认有没有带外管理或者第二套可用的接入方式。没有的话，就挂一个定时回滚脚本：把当前nmcli connection show "名字"的输出存一份，写个脚本在 5 分钟后检查连通性，不通就把旧配置恢复并重新激活。这个习惯让我少跑了太多趟机房。

第二条，配置命名要带语义。别用eth0-1、Wired connection 2这种自动生成的名字，全部改成能读懂用途的，比如office-static-10.50、backup-dhcp、vlan100-db。半年后回来看，一眼就知道哪份是干什么的。批量环境里这一点尤其重要，脚本里引用连接名的时候也不会因为自动编号变化而翻车。

第三条，每次改完都做三件套验证：ip addr看地址、ip route看路由、ping网关和一个跨网段地址看连通性。别只看 nmcli 返回成功就完事，命令成功只代表档案写对了，运行态对不对是另一回事。这三条命令加起来不到五秒，能省掉后面半小时的困惑。

第四条，用nmcli connection show做配置快照。把关键连接的完整属性输出存到文件里，出问题时跟当前状态 diff 一下，差异一目了然。这个方法在对比“昨天还好今天不行”的场景里特别好用，比凭记忆猜测靠谱得多。

第五条，批量环境下先在一台上跑通全流程再复制。把命令写成一个脚本，参数化连接名、IP、网关，先在测试机上完整跑一遍，包括重启验证。跑通了再批量推。网络配置不像应用配置，错了就是失联，没有第二次机会。

最后分享一个我常用的交互式写法：nmcli connection edit "连接名"。进入之后是个提示符界面，set ipv4.addresses 192.168.10.50/24逐条设置，print随时看当前状态，save提交，activate直接激活。参数记不全的时候用这个模式比翻文档快，而且它会在你敲错属性名的时候给出提示，适合还不熟悉属性命名的人过渡。熟练之后我还是回到一行命令的模式，毕竟能写进脚本、能进版本库，可追溯性更好。