刚接手一台Linux服务器或者自己折腾虚拟机的时候第一件事几乎都是敲ip addr看IP。这个命令确实好用几秒钟就能拿到当前接口的地址、掩码、MAC。但真正要干活的时候尤其是要改静态IP、排查网络起不来、或者给新机器做预配置你就得去翻IP配置文件。可问题来了不同发行版、不同网络管理工具配置文件的位置和格式天差地别。有人在/etc/sysconfig/network-scripts/下翻了半天什么都没找到有人对着netplan的yaml文件一头雾水还有人改了配置文件重启后IP不但没变反而整个网络都瘫了。这篇我就把这些年查看IP配置文件这件事的实操经验梳理一遍适合刚入门想搞懂IP到底存在哪的人也适合那些遇到配置文件改完不生效想快速定位问题的人。这篇文章不是要带你把ip addr、ifconfig这类查看IP的命令重新背一遍而是要解决一个更本质的问题IP地址是怎么来的、存在哪、由谁加载。只有把这条链路摸清楚你才能在遇到网络故障的时候不用靠猜。1. 为什么ip addr查到的地址不能代替配置文件1.1 运行态与持久态先搞清两个IP开始之前必须先把一个概念掰扯清楚你通过ip addr看到的是运行态的地址文件里写的是持久态的配置。这两个状态由内核和网络管理工具分别维护中间通过服务联动但绝不是同一个东西。举个最直接的例子你执行ip addr add 192.168.1.100/24 dev eth0地址立刻生效ip addr立刻能看到新地址但配置文件一个字没动。反过来你编辑配置文件加了一行IPADDR192.168.1.100只要不重启网络服务或者执行netplan applyip addr里就什么都看不到。这是两套数据靠network服务、NetworkManager或者systemd-networkd来做同步。理解了这一点后面遇到配置文件里看到的内容和实际IP不一致就不会慌。不是配置坏了而是运行态和持久态没有同步而已。1.2 配置文件回答的是IP从哪来命令只回答IP是什么网上搜linux查看IP百分之八十的教程停在ip addr、ifconfig、hostname -I就结束了。这些命令回答的是现在这个网卡上挂着哪些地址。但在真正的运维场景里你需要回答的往往是另一个问题这个地址是静态写死的还是DHCP分配的如果是静态的网关和DNS写在哪里重启以后会不会丢这些问题命令答不了只能靠配置文件回答。尤其是虚拟机克隆、系统迁移、模板部署这类场景你拿到一台新机器想知道网卡原来是怎么配的总不能靠猜。我见过太多人用ip addr看到地址后直接上手改配置结果改的不是同一块网卡或者配置文件里还残留着一个废弃的IP导致线上出现两个IP都能通的诡异现象。所以在这篇文章里我刻意把重点放在配置文件而不是查IP命令上就是想让读者养成一个习惯看网络先看源再看果。1.3 搞懂谁在管网络才能找到对的配置文件我建议你在上手查任何配置文件之前先花十秒钟确认这台机器上到底是谁在管理网络。不同管理栈决定了系统会去读取哪一套文件。常见的几类NetworkManager绝大多数桌面发行版和RHEL/CentOS 8服务器默认使用systemd-networkd很多精简服务器、容器基础镜像、ArchLinux默认使用ifupdown传统Debian系、CentOS 6时代遗留直接读取/etc/network/interfacesnetplanUbuntu 18.04的渲染层本身不直接管理网络而是生成后端配置文件再交给NetworkManager或systemd-networkd你如果不先确认这一点很可能找错目录。比如Ubuntu 20.04默认走netplan你去/etc/network/interfaces里加配置虽然也能写但大概率不会生效反过来在纯Debian 11上默认是ifupdown管理你去/etc/netplan/目录底下可能整个目录都不存在。怎么确认三条命令最简单systemctl status NetworkManager systemctl status systemd-networkd ps -ef | grep -E NetworkManager|systemd-networkd看到哪个服务在跑就基本知道该去哪个目录找配置文件了。这一步虽然简单却是我见过翻车最多的地方。2. 三大主流体系的配置文件路径与格式全梳理2.1 RHEL/CentOS/Fedora系列ifcfg-* 家族不能死记RHEL和CentOS系传统网卡配置文件放在/etc/sysconfig/network-scripts/目录下文件名以ifcfg-开头后面跟着接口名比如ifcfg-eth0、ifcfg-enp3s0。查看方法很直接ls /etc/sysconfig/network-scripts/ cat /etc/sysconfig/network-scripts/ifcfg-ens33一个典型的静态IP配置长这样TYPEEthernet BOOTPROTOstatic NAMEens33 DEVICEens33 ONBOOTyes IPADDR192.168.122.15 PREFIX24 GATEWAY192.168.122.1 DNS1192.168.122.1几个关键项我单独拎出来说因为这些字段直接影响了你查看时对配置的判断BOOTPROTOstatic表示静态配置如果写成dhcp表示这台机器的IP是开机时从DHCP服务器租来的。注意DHCP模式下配置文件里不会有IPADDR这一行这是正常现象。ONBOOTyes决定开机是否启用这个接口。很多人改了配置发现不生效最后查出是ONBOOTno网卡根本没起来。GATEWAY和DNS1是单独的行和Windows里的高级TCP/IP设置完全是两种逻辑别指望它们自动补全。但这里有一个重要提醒RHEL/CentOS 8以后系统默认用NetworkManager管理网络。NM在激活连接的时候处理ifcfg文件的逻辑和早期的network服务不完全一样。更关键的是NM自己还有一份连接配置存放在/etc/NetworkManager/system-connections/下用keyfile格式保存。在某些情况下你可能在ifcfg文件里改了配置但NM实际加载的却是keyfile导致改了半天不生效。所以在RHEL系查看配置时别只看ifcfg最好配合这条命令一起看nmcli connection show它会把NetworkManager当前认到的所有连接、类型、设备、状态列出来你一眼就能分辨出到底哪个文件是有效的配置文件。2.2 Debian/Ubuntu系interfaces与netplan的两种时代传统Debian和Ubuntu 18.04之前网络配置集中在/etc/network/interfaces以及/etc/network/interfaces.d/目录下。查看方式cat /etc/network/interfaces静态IP的典型写法auto eth0 iface eth0 inet static address 192.168.1.10 netmask 255.255.255.0 gateway 192.168.1.1 dns-nameservers 8.8.8.8注意这里的缩进不是可选的它是语法的一部分。auto eth0表示开机自动拉起这块网卡少了这一行网卡配置了也可能不会生效。这和RHEL系的ONBOOT是一个作用。而Ubuntu 18.04起默认网络栈换成了netplan配置文件在/etc/netplan/下通常是01-network-manager-all.yaml或者00-installer-config.yaml。查看方式ls /etc/netplan/ cat /etc/netplan/01-network-manager-all.yamlnetplan的yaml格式缩进极其敏感一个空格错位配置就废了。典型的DHCP配置长这样network: version: 2 ethernets: ens3: dhcp4: true静态IP的写法network: version: 2 ethernets: ens3: dhcp4: false addresses: - 192.168.1.10/24 gateway4: 192.168.1.1 nameservers: addresses: [8.8.8.8, 1.1.1.1]有一个细节很多人容易忽略netplan只是一个渲染层它会把yaml转换成systemd-networkd或NetworkManager能直接使用的配置。所以在netplan体系下查看配置不能只读yaml还要理解后端实际加载的是渲染后的结果。运行netplan get能看当前解析出来的配置netplan apply能让新配置立刻生效。如果遇到yaml改完不生效先别怀疑语法先跑一次netplan generate看看有没有报错。另外怎么判断当前系统用的是interfaces还是netplan很简单就看/etc/netplan/目录存不存在。存在就是netplan体系不存在则大概率还在用老的interfaces方式。2.3 systemd-networkd精简系统里的第三极现在很多精简系统、容器基础镜像、ArchLinux、甚至一部分国产发行版走的都是systemd-networkd。它的配置文件放在/etc/systemd/network/文件名以.network结尾例如10-eth0.network。查看方式ls /etc/systemd/network/ cat /etc/systemd/network/10-eth0.network格式是INI风格分段明确[Match] Nameeth0 [Network] Address192.168.1.10/24 Gateway192.168.1.1 DNS8.8.8.8 [DHCP] UseDNSfalse[Match]是匹配条件告诉systemd-networkd这块配置管哪张网卡[Network]下面是要应用的网络参数[DHCP]是DHCP相关策略。这种配置的优点是简洁、和systemd生态整合紧密缺点是如果机器上同时跑了NetworkManager两边很容易抢网卡。所以看到.network文件时第一件事是先确认systemd-networkd是否真的在跑systemctl status systemd-networkd如果服务是死的那配置文件写了也是白写。这个第三极体系在传统教程里讲得少但实际遇到的概率越来越高尤其是云原生环境里的基础镜像。下表总结一下这三类体系方便对照体系配置文件路径典型文件名核心工具适用发行版ifcfg/etc/sysconfig/network-scripts/ifcfg-ens33network, nmcliRHEL/CentOS/Fedorainterfaces/etc/network/interfacesinterfacesifup/ifdownDebian, Ubuntu 18.04前netplan/etc/netplan/01-netcfg.yamlnetplanUbuntu 18.04systemd-networkd/etc/systemd/network/10-eth0.networknetworkctlArch、容器镜像、精简系统3. 查看配置时最容易误判的三种场景3.1 文件里明明写了静态IP系统却还是用了DHCP这类问题我接到过不止一次。现象很典型cat ifcfg-ens33里面BOOTPROTOstaticIPADDR、GATEWAY都写得清清楚楚但ip addr看到的却是一个随机地址明显是DHCP分配的。为什么配置文件写了等于没写我排查下来的原因主要有三种按出现频率排序NetworkManager没有真正加载这个ifcfg文件。NM在/etc/NetworkManager/system-connections/下维护着一份keyfile优先级比ifcfg更高。NM启动时以keyfile为准ifcfg反而只是参考。接口名写错。配置文件里DEVICEeth0但系统里实际接口名已经变成了ens33。udev重命名网卡后配置文件没跟着改文件就跟废了一样。cloud-init或图形工具覆盖了配置。云服务器、虚拟机模板上尤其常见cloud-init在启动时把网络配置重新生成了一遍你手动改的ifcfg被顶掉。排查思路不是一上来就改配置文件而是先问NetworkManager你到底认到的是什么nmcli connection show nmcli device show ens33看到connection里记录的连接方式和IP参数再去对比ifcfg内容基本就能定位是哪一类覆盖导致的。3.2 DHCP模式下配置文件里当然没有IP地址有的朋友查看IP配置文件期望看到一行IPADDR192.168.x.x结果翻遍整个文件只看到BOOTPROTOdhcp就以为配置丢了、文件坏了。这是概念没转过弯。DHCP模式下IP地址是网卡启动时从DHCP服务器租来的租约不写进网卡配置文件而是缓存在/var/lib/NetworkManager/或/var/lib/dhcp/目录下。这是运行态信息不是持久态配置。所以DHCP模式下查看配置文件你永远找不到IP地址那几行这是正常的不代表配置丢失。那DHCP模式下的IP租约、过期时间去哪看两个途径nmcli device show eth0或者直接看DHCP客户端租约文件cat /var/lib/NetworkManager/eth0.lease如果你只是想确认这台机器确实用DHCP那么配置文件里的BOOTPROTOdhcp或netplan里的dhcp4: true已经给了你答案不需要再纠结IP在哪。3.3 多网卡多配置文件看错了对象服务器多网卡太常见了。/etc/sysconfig/network-scripts/下可能躺着ifcfg-ens1、ifcfg-ens2、ifcfg-br0还有回环接口的ifcfg-lo。如果只凭文件名猜很容易把ens2的IP当成ens1的导致排查问题时完全跑偏。我自己的习惯是先ip addr把接口和MAC对应起来再lspci或者用ethtool -i eth0确认物理位置和驱动最后才去碰配置文件。查看多个文件时不逐个cat用一条命令批量处理cd /etc/sysconfig/network-scripts grep -H ^IPADDR\|^DEVICE\|^NAME ifcfg-*输出会明确标出每个文件里的设备名和IP方便对号入座。-H参数会把文件名打出来这是比grep默认输出更适合排查多文件的写法。4. 从配置文件反推网络故障一次完整排查链路4.1 故障现象虚拟机克隆后网络不通有次我帮同事排查一台虚拟机现象很清晰这台机器是从模板克隆出来的开机后ping 网关不通ssh外部也连不上。同事的第一反应是查防火墙但我觉得克隆机器的网络问题大概率出在网卡和配置文件上。我在现场的操作顺序是这样的ip addr ip linkip addr显示ens33上有IP地址而且地址看起来正常。但ip link之后我发现ens33的MAC地址和一个旧值对不上——虽然我当时还没查配置文件但心里已经有个大概方向了。4.2 顺着链路往下摸从网卡状态到配置文件接着执行ethtool -i ens33 nmcli connection show cat /etc/sysconfig/network-scripts/ifcfg-ens33关键问题在最后一条命令里露出了马脚文件里有一行HWADDR00:0C:29:xx:xx:xx这个MAC是模板机器上的旧MAC。虚拟机克隆时虚拟网卡通常会被分配一个新的MAC地址但ifcfg文件里还是克隆前的HWADDR。NM加载配置时发现文件里指定的MAC和实际网卡MAC不一致于是拒绝把这个配置作为ens33的有效配置网卡就处于有地址但不完全受管的诡异状态。这类问题在VMware、KVM的克隆场景里非常典型很多人都栽过。4.3 修复改配置还是改MAC当时我的处理方式是直接注释或删除ifcfg文件里的HWADDR行sed -i /^HWADDR/d /etc/sysconfig/network-scripts/ifcfg-ens33 systemctl restart network重启后ping 网关就通了。这个操作背后的逻辑是新环境里MAC已经变了与其让配置去约束MAC不如让配置跟随当前网卡。如果你确实希望MAC保持不变那应该在虚拟化平台里给虚拟机固定MAC地址而不是反过来在Linux里改配置。这次排查链路走下来就是一套标准的从现象到配置方法先看网卡状态再看管理工具认到的连接最后才落到配置文件内容。每一步都能过滤掉一批可能性最终精准定位。这也正是我前面反复强调不要只依赖ip addr的原因。5. 我平时查看网络配置的固定套路和几个实用技巧5.1 我的固定查看顺序现在不管遇到什么Linux网络问题我基本都按下面这个顺序来基本上十五分钟之内都能定位到问题方向ip addr看当前网卡和IP现状建立印象。systemctl status NetworkManager或systemctl status systemd-networkd确认谁在管网络。nmcli connection show或networkctl list看管理工具视角里的连接状态。根据管理栈去对应路径找配置文件/etc/sysconfig/network-scripts/、/etc/netplan/、/etc/network/interfaces或/etc/systemd/network/。cat /etc/resolv.conf看DNS这块是不是也被某个服务接管了。这套流程看起来多但每一步都有明确的过滤作用省下的时间远比多敲几条命令多。5.2 几个能提速的命令组合我平时会刻意用一些组合命令来快速提取关键信息避免在文件堆里一个一个翻grep -R IPADDR\|NETMASK\|GATEWAY /etc/sysconfig/network-scripts/networkctl list cat /etc/systemd/network/*.networknetplan get另外查看bond和team这种聚合链路时配置文件只是入口最终还得看内核状态cat /proc/net/bonding/bond05.3 改完配置后怎么确认真的生效了改配置文件不是改完就大功告成建议按这个顺序验证ip addr确认新地址已经挂上。ip route查看默认路由是否指向新网关。cat /etc/resolv.conf确认DNS解析正常。ping 网关IP通说明二层三层没问题。ping 一个外网域名通说明DNS和出口都正常。还有一个我踩过好几次坑后的铁律不要在业务高峰期远程改网卡IP。改IP一旦断连本地人又不在机房就只能靠IPMI或者控制台慢慢折腾那种情况真的很痛苦。如果必须远程操作建议至少同时准备好带外管理通道并且提前把reboot前的自动恢复方案想好。查看IP配置文件这件事说难不难说简单也不简单。难的不是命令本身而是你得先搞清楚系统里是谁在管理网络、配置散落在哪几个文件、每个字段什么含义。把这套脉络摸清楚以后再遇到配置文件改了不生效克隆后网卡起不来IP和配置对不上这类问题心里就有底了。
Linux IP配置文件全解析：三大体系与排查实战
刚接手一台Linux服务器或者自己折腾虚拟机的时候第一件事几乎都是敲ip addr看IP。这个命令确实好用几秒钟就能拿到当前接口的地址、掩码、MAC。但真正要干活的时候尤其是要改静态IP、排查网络起不来、或者给新机器做预配置你就得去翻IP配置文件。可问题来了不同发行版、不同网络管理工具配置文件的位置和格式天差地别。有人在/etc/sysconfig/network-scripts/下翻了半天什么都没找到有人对着netplan的yaml文件一头雾水还有人改了配置文件重启后IP不但没变反而整个网络都瘫了。这篇我就把这些年查看IP配置文件这件事的实操经验梳理一遍适合刚入门想搞懂IP到底存在哪的人也适合那些遇到配置文件改完不生效想快速定位问题的人。这篇文章不是要带你把ip addr、ifconfig这类查看IP的命令重新背一遍而是要解决一个更本质的问题IP地址是怎么来的、存在哪、由谁加载。只有把这条链路摸清楚你才能在遇到网络故障的时候不用靠猜。1. 为什么ip addr查到的地址不能代替配置文件1.1 运行态与持久态先搞清两个IP开始之前必须先把一个概念掰扯清楚你通过ip addr看到的是运行态的地址文件里写的是持久态的配置。这两个状态由内核和网络管理工具分别维护中间通过服务联动但绝不是同一个东西。举个最直接的例子你执行ip addr add 192.168.1.100/24 dev eth0地址立刻生效ip addr立刻能看到新地址但配置文件一个字没动。反过来你编辑配置文件加了一行IPADDR192.168.1.100只要不重启网络服务或者执行netplan applyip addr里就什么都看不到。这是两套数据靠network服务、NetworkManager或者systemd-networkd来做同步。理解了这一点后面遇到配置文件里看到的内容和实际IP不一致就不会慌。不是配置坏了而是运行态和持久态没有同步而已。1.2 配置文件回答的是IP从哪来命令只回答IP是什么网上搜linux查看IP百分之八十的教程停在ip addr、ifconfig、hostname -I就结束了。这些命令回答的是现在这个网卡上挂着哪些地址。但在真正的运维场景里你需要回答的往往是另一个问题这个地址是静态写死的还是DHCP分配的如果是静态的网关和DNS写在哪里重启以后会不会丢这些问题命令答不了只能靠配置文件回答。尤其是虚拟机克隆、系统迁移、模板部署这类场景你拿到一台新机器想知道网卡原来是怎么配的总不能靠猜。我见过太多人用ip addr看到地址后直接上手改配置结果改的不是同一块网卡或者配置文件里还残留着一个废弃的IP导致线上出现两个IP都能通的诡异现象。所以在这篇文章里我刻意把重点放在配置文件而不是查IP命令上就是想让读者养成一个习惯看网络先看源再看果。1.3 搞懂谁在管网络才能找到对的配置文件我建议你在上手查任何配置文件之前先花十秒钟确认这台机器上到底是谁在管理网络。不同管理栈决定了系统会去读取哪一套文件。常见的几类NetworkManager绝大多数桌面发行版和RHEL/CentOS 8服务器默认使用systemd-networkd很多精简服务器、容器基础镜像、ArchLinux默认使用ifupdown传统Debian系、CentOS 6时代遗留直接读取/etc/network/interfacesnetplanUbuntu 18.04的渲染层本身不直接管理网络而是生成后端配置文件再交给NetworkManager或systemd-networkd你如果不先确认这一点很可能找错目录。比如Ubuntu 20.04默认走netplan你去/etc/network/interfaces里加配置虽然也能写但大概率不会生效反过来在纯Debian 11上默认是ifupdown管理你去/etc/netplan/目录底下可能整个目录都不存在。怎么确认三条命令最简单systemctl status NetworkManager systemctl status systemd-networkd ps -ef | grep -E NetworkManager|systemd-networkd看到哪个服务在跑就基本知道该去哪个目录找配置文件了。这一步虽然简单却是我见过翻车最多的地方。2. 三大主流体系的配置文件路径与格式全梳理2.1 RHEL/CentOS/Fedora系列ifcfg-* 家族不能死记RHEL和CentOS系传统网卡配置文件放在/etc/sysconfig/network-scripts/目录下文件名以ifcfg-开头后面跟着接口名比如ifcfg-eth0、ifcfg-enp3s0。查看方法很直接ls /etc/sysconfig/network-scripts/ cat /etc/sysconfig/network-scripts/ifcfg-ens33一个典型的静态IP配置长这样TYPEEthernet BOOTPROTOstatic NAMEens33 DEVICEens33 ONBOOTyes IPADDR192.168.122.15 PREFIX24 GATEWAY192.168.122.1 DNS1192.168.122.1几个关键项我单独拎出来说因为这些字段直接影响了你查看时对配置的判断BOOTPROTOstatic表示静态配置如果写成dhcp表示这台机器的IP是开机时从DHCP服务器租来的。注意DHCP模式下配置文件里不会有IPADDR这一行这是正常现象。ONBOOTyes决定开机是否启用这个接口。很多人改了配置发现不生效最后查出是ONBOOTno网卡根本没起来。GATEWAY和DNS1是单独的行和Windows里的高级TCP/IP设置完全是两种逻辑别指望它们自动补全。但这里有一个重要提醒RHEL/CentOS 8以后系统默认用NetworkManager管理网络。NM在激活连接的时候处理ifcfg文件的逻辑和早期的network服务不完全一样。更关键的是NM自己还有一份连接配置存放在/etc/NetworkManager/system-connections/下用keyfile格式保存。在某些情况下你可能在ifcfg文件里改了配置但NM实际加载的却是keyfile导致改了半天不生效。所以在RHEL系查看配置时别只看ifcfg最好配合这条命令一起看nmcli connection show它会把NetworkManager当前认到的所有连接、类型、设备、状态列出来你一眼就能分辨出到底哪个文件是有效的配置文件。2.2 Debian/Ubuntu系interfaces与netplan的两种时代传统Debian和Ubuntu 18.04之前网络配置集中在/etc/network/interfaces以及/etc/network/interfaces.d/目录下。查看方式cat /etc/network/interfaces静态IP的典型写法auto eth0 iface eth0 inet static address 192.168.1.10 netmask 255.255.255.0 gateway 192.168.1.1 dns-nameservers 8.8.8.8注意这里的缩进不是可选的它是语法的一部分。auto eth0表示开机自动拉起这块网卡少了这一行网卡配置了也可能不会生效。这和RHEL系的ONBOOT是一个作用。而Ubuntu 18.04起默认网络栈换成了netplan配置文件在/etc/netplan/下通常是01-network-manager-all.yaml或者00-installer-config.yaml。查看方式ls /etc/netplan/ cat /etc/netplan/01-network-manager-all.yamlnetplan的yaml格式缩进极其敏感一个空格错位配置就废了。典型的DHCP配置长这样network: version: 2 ethernets: ens3: dhcp4: true静态IP的写法network: version: 2 ethernets: ens3: dhcp4: false addresses: - 192.168.1.10/24 gateway4: 192.168.1.1 nameservers: addresses: [8.8.8.8, 1.1.1.1]有一个细节很多人容易忽略netplan只是一个渲染层它会把yaml转换成systemd-networkd或NetworkManager能直接使用的配置。所以在netplan体系下查看配置不能只读yaml还要理解后端实际加载的是渲染后的结果。运行netplan get能看当前解析出来的配置netplan apply能让新配置立刻生效。如果遇到yaml改完不生效先别怀疑语法先跑一次netplan generate看看有没有报错。另外怎么判断当前系统用的是interfaces还是netplan很简单就看/etc/netplan/目录存不存在。存在就是netplan体系不存在则大概率还在用老的interfaces方式。2.3 systemd-networkd精简系统里的第三极现在很多精简系统、容器基础镜像、ArchLinux、甚至一部分国产发行版走的都是systemd-networkd。它的配置文件放在/etc/systemd/network/文件名以.network结尾例如10-eth0.network。查看方式ls /etc/systemd/network/ cat /etc/systemd/network/10-eth0.network格式是INI风格分段明确[Match] Nameeth0 [Network] Address192.168.1.10/24 Gateway192.168.1.1 DNS8.8.8.8 [DHCP] UseDNSfalse[Match]是匹配条件告诉systemd-networkd这块配置管哪张网卡[Network]下面是要应用的网络参数[DHCP]是DHCP相关策略。这种配置的优点是简洁、和systemd生态整合紧密缺点是如果机器上同时跑了NetworkManager两边很容易抢网卡。所以看到.network文件时第一件事是先确认systemd-networkd是否真的在跑systemctl status systemd-networkd如果服务是死的那配置文件写了也是白写。这个第三极体系在传统教程里讲得少但实际遇到的概率越来越高尤其是云原生环境里的基础镜像。下表总结一下这三类体系方便对照体系配置文件路径典型文件名核心工具适用发行版ifcfg/etc/sysconfig/network-scripts/ifcfg-ens33network, nmcliRHEL/CentOS/Fedorainterfaces/etc/network/interfacesinterfacesifup/ifdownDebian, Ubuntu 18.04前netplan/etc/netplan/01-netcfg.yamlnetplanUbuntu 18.04systemd-networkd/etc/systemd/network/10-eth0.networknetworkctlArch、容器镜像、精简系统3. 查看配置时最容易误判的三种场景3.1 文件里明明写了静态IP系统却还是用了DHCP这类问题我接到过不止一次。现象很典型cat ifcfg-ens33里面BOOTPROTOstaticIPADDR、GATEWAY都写得清清楚楚但ip addr看到的却是一个随机地址明显是DHCP分配的。为什么配置文件写了等于没写我排查下来的原因主要有三种按出现频率排序NetworkManager没有真正加载这个ifcfg文件。NM在/etc/NetworkManager/system-connections/下维护着一份keyfile优先级比ifcfg更高。NM启动时以keyfile为准ifcfg反而只是参考。接口名写错。配置文件里DEVICEeth0但系统里实际接口名已经变成了ens33。udev重命名网卡后配置文件没跟着改文件就跟废了一样。cloud-init或图形工具覆盖了配置。云服务器、虚拟机模板上尤其常见cloud-init在启动时把网络配置重新生成了一遍你手动改的ifcfg被顶掉。排查思路不是一上来就改配置文件而是先问NetworkManager你到底认到的是什么nmcli connection show nmcli device show ens33看到connection里记录的连接方式和IP参数再去对比ifcfg内容基本就能定位是哪一类覆盖导致的。3.2 DHCP模式下配置文件里当然没有IP地址有的朋友查看IP配置文件期望看到一行IPADDR192.168.x.x结果翻遍整个文件只看到BOOTPROTOdhcp就以为配置丢了、文件坏了。这是概念没转过弯。DHCP模式下IP地址是网卡启动时从DHCP服务器租来的租约不写进网卡配置文件而是缓存在/var/lib/NetworkManager/或/var/lib/dhcp/目录下。这是运行态信息不是持久态配置。所以DHCP模式下查看配置文件你永远找不到IP地址那几行这是正常的不代表配置丢失。那DHCP模式下的IP租约、过期时间去哪看两个途径nmcli device show eth0或者直接看DHCP客户端租约文件cat /var/lib/NetworkManager/eth0.lease如果你只是想确认这台机器确实用DHCP那么配置文件里的BOOTPROTOdhcp或netplan里的dhcp4: true已经给了你答案不需要再纠结IP在哪。3.3 多网卡多配置文件看错了对象服务器多网卡太常见了。/etc/sysconfig/network-scripts/下可能躺着ifcfg-ens1、ifcfg-ens2、ifcfg-br0还有回环接口的ifcfg-lo。如果只凭文件名猜很容易把ens2的IP当成ens1的导致排查问题时完全跑偏。我自己的习惯是先ip addr把接口和MAC对应起来再lspci或者用ethtool -i eth0确认物理位置和驱动最后才去碰配置文件。查看多个文件时不逐个cat用一条命令批量处理cd /etc/sysconfig/network-scripts grep -H ^IPADDR\|^DEVICE\|^NAME ifcfg-*输出会明确标出每个文件里的设备名和IP方便对号入座。-H参数会把文件名打出来这是比grep默认输出更适合排查多文件的写法。4. 从配置文件反推网络故障一次完整排查链路4.1 故障现象虚拟机克隆后网络不通有次我帮同事排查一台虚拟机现象很清晰这台机器是从模板克隆出来的开机后ping 网关不通ssh外部也连不上。同事的第一反应是查防火墙但我觉得克隆机器的网络问题大概率出在网卡和配置文件上。我在现场的操作顺序是这样的ip addr ip linkip addr显示ens33上有IP地址而且地址看起来正常。但ip link之后我发现ens33的MAC地址和一个旧值对不上——虽然我当时还没查配置文件但心里已经有个大概方向了。4.2 顺着链路往下摸从网卡状态到配置文件接着执行ethtool -i ens33 nmcli connection show cat /etc/sysconfig/network-scripts/ifcfg-ens33关键问题在最后一条命令里露出了马脚文件里有一行HWADDR00:0C:29:xx:xx:xx这个MAC是模板机器上的旧MAC。虚拟机克隆时虚拟网卡通常会被分配一个新的MAC地址但ifcfg文件里还是克隆前的HWADDR。NM加载配置时发现文件里指定的MAC和实际网卡MAC不一致于是拒绝把这个配置作为ens33的有效配置网卡就处于有地址但不完全受管的诡异状态。这类问题在VMware、KVM的克隆场景里非常典型很多人都栽过。4.3 修复改配置还是改MAC当时我的处理方式是直接注释或删除ifcfg文件里的HWADDR行sed -i /^HWADDR/d /etc/sysconfig/network-scripts/ifcfg-ens33 systemctl restart network重启后ping 网关就通了。这个操作背后的逻辑是新环境里MAC已经变了与其让配置去约束MAC不如让配置跟随当前网卡。如果你确实希望MAC保持不变那应该在虚拟化平台里给虚拟机固定MAC地址而不是反过来在Linux里改配置。这次排查链路走下来就是一套标准的从现象到配置方法先看网卡状态再看管理工具认到的连接最后才落到配置文件内容。每一步都能过滤掉一批可能性最终精准定位。这也正是我前面反复强调不要只依赖ip addr的原因。5. 我平时查看网络配置的固定套路和几个实用技巧5.1 我的固定查看顺序现在不管遇到什么Linux网络问题我基本都按下面这个顺序来基本上十五分钟之内都能定位到问题方向ip addr看当前网卡和IP现状建立印象。systemctl status NetworkManager或systemctl status systemd-networkd确认谁在管网络。nmcli connection show或networkctl list看管理工具视角里的连接状态。根据管理栈去对应路径找配置文件/etc/sysconfig/network-scripts/、/etc/netplan/、/etc/network/interfaces或/etc/systemd/network/。cat /etc/resolv.conf看DNS这块是不是也被某个服务接管了。这套流程看起来多但每一步都有明确的过滤作用省下的时间远比多敲几条命令多。5.2 几个能提速的命令组合我平时会刻意用一些组合命令来快速提取关键信息避免在文件堆里一个一个翻grep -R IPADDR\|NETMASK\|GATEWAY /etc/sysconfig/network-scripts/networkctl list cat /etc/systemd/network/*.networknetplan get另外查看bond和team这种聚合链路时配置文件只是入口最终还得看内核状态cat /proc/net/bonding/bond05.3 改完配置后怎么确认真的生效了改配置文件不是改完就大功告成建议按这个顺序验证ip addr确认新地址已经挂上。ip route查看默认路由是否指向新网关。cat /etc/resolv.conf确认DNS解析正常。ping 网关IP通说明二层三层没问题。ping 一个外网域名通说明DNS和出口都正常。还有一个我踩过好几次坑后的铁律不要在业务高峰期远程改网卡IP。改IP一旦断连本地人又不在机房就只能靠IPMI或者控制台慢慢折腾那种情况真的很痛苦。如果必须远程操作建议至少同时准备好带外管理通道并且提前把reboot前的自动恢复方案想好。查看IP配置文件这件事说难不难说简单也不简单。难的不是命令本身而是你得先搞清楚系统里是谁在管理网络、配置散落在哪几个文件、每个字段什么含义。把这套脉络摸清楚以后再遇到配置文件改了不生效克隆后网卡起不来IP和配置对不上这类问题心里就有底了。
