戈玄白今天要做题1. 先搞清楚Linux网络管理的整体骨架：配置路径与数据流
我最早接触Linux网络管理的时候，第一个感受就是"命令怎么这么多，文件怎么这么乱"。ifconfig还在用，ip又出来了，改IP有时候用nmtui，有时候又得直接编辑配置文件，改完还经常不生效。这种混乱感其实不是Linux本身的问题，而是网络管理涉及的用户态工具、内核接口和配置存储方式有好几套体系，它们并存且各有各的使用方式。你不需要把所有体系都搞懂，但至少得知道当前这个系统里"配置走哪条路、生效靠什么机制"。
一台普通的Linux机器要正常访问网络，数据路径大概是这样：应用进程通过socket发数据，内核的网络协议栈处理路由与封装，网卡驱动把数据帧送出去。但是"系统怎么知道该用哪个IP、网关是谁、DNS往哪填"，这些信息不是内核天生自带的，而是需要用户态工具去配置并告知内核。
以最常见的发行版为例，配置数据有两种形态。一种是静态配置文件，比如RHEL系在/etc/sysconfig/network-scripts/ifcfg-<网卡名>，Debian系在/etc/network/interfaces或者/etc/netplan/下。另一种是运行时状态，也就是内核里实际生效的配置，可以通过ip addr、ip route等命令查看。两者之间并不是自动同步的——改配置文件不一定会立刻通知内核，直接敲命令改运行时配置也不会自动回写文件，必须用工具或手动触发。
所以在Linux网络管理里，你永远要记住一条主线：查看用运行时命令，永久配置要落在配置文件上，变更生效要触发相应的机制。下面每一步实操都围绕这个主线展开。
提示：
ip命令属于iproute2软件包，绝大多数现代发行版默认自带。ifconfig属于net-tools，很多新系统没装，装完也不推荐优先使用。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 查看网络状态：先学会用ip命令族替代ifconfig
很多老教程还在用ifconfig展示网络状态，但ifconfig的输出格式和信息量在今天都不够用了。ip命令族才是现代Linux网络运维的日常主力。最常用的三个子命令是ip addr、ip link和ip route。
2.1 ip addr：看IP地址分配情况
ip addr show可以简写为ip a，输出每一块网卡的链路状态、MAC地址和IPv4/IPv6地址。示例输出：
bash复制$ ip addr
2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:0c:29:5a:1e:07 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.100/24 brd 192.168.1.255 scope global noprefixroute ens33
inet6 fe80::20c:29ff:fe5a:1e07/64 scope link
括号里的UP表示网卡处于工作状态，对应的还有DOWN或UNKNOWN。其中UNKNOWN常出现在刚创建的虚拟网卡或没有接线的物理网卡上，不一定代表故障，得结合ip link再看。inet一行就是IPv4地址，/24表示掩码，brd是广播地址，scope global说明这个地址是全局可路由的，scope link一般指链路本地地址。
如果你只想看某个网卡，可以加网卡名过滤：
bash复制$ ip addr show ens33
这条命令适合定位"我这台机器现在是什么IP"的问题。尤其是新装系统找不到IP的时候，第一件事就是ip addr看网卡状态是UP还是DOWN。
2.2 ip link：查链路层状态
ip link show显示的是网卡的物理状态，比地址信息更底层。它同样支持过滤：
bash复制$ ip link show ens33
2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
link/ether 00:0c:29:5a:1e:07 brd ff:ff:ff:ff:ff:ff
这里state UP表示网卡已被激活，LOWER_UP是物理层链路已经建立——网线插着、交换机端口正常。如果你看到NO-CARRIER或state DOWN，基本可以判断是物理链路或驱动问题，而不是IP配置问题。很多初学者拿到一个"网络不通"的问题就急着改IP，这属于没分清故障层次，改半天当然没用。
2.3 ip route：看路由表，理解网关是怎么生效的
路由表决定数据包"往哪个方向走"。ip route是必查项：
bash复制$ ip route
default via 192.168.1.1 dev ens33 proto static metric 100
192.168.1.0/24 dev ens33 proto kernel scope link src 192.168.1.100 metric 100
第一条default via 192.168.1.1就是默认网关，所有去往非本网段目标的数据都交给192.168.1.1转发。第二条是本网段直连路由，表示目标在192.168.1.0/24内的直接走网卡。如果你发现default这一行丢失或指向错误，外网基本不通，但内网可能还正常——这是"能上内网不能上外网"最常见的根因之一。
2.4 补充一个很常用的查看工具：ss和ping
netstat在老教材里频繁出现，作用是查看端口监听和连接状态。现代系统里更推荐ss，输出更快且默认就装：
bash复制$ ss -tulnp
State Local Address:Port Peer Address:Port
LISTEN 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=873,fd=3))
-t看TCP，-u看UDP，-l只看监听状态，-n不做域名反解（能明显加快速度），-p显示进程信息。网络是否通、端口是否在听，ss一条命令比什么工具都好使。
ping不需要多介绍，但有几个细节值得注意。ping通不代表网络服务健康，它只表示ICMP报文能往返；有些云主机的安全组会屏蔽ICMP，这时候ping不通但业务TCP端口却正常。所以判断连通性不能只看ping，要结合具体端口去测，telnet <ip> <port>或者nc -vz <ip> <port>更准确。
3. 永久配置网络的核心：网卡配置文件字段拆解
改IP这种事，如果只是临时调试，直接用ip addr add就行；但重启之后配置就没了。生产环境要的是永久生效，这就得回到配置文件。
以RHEL/CentOS系的ifcfg-*文件为例，它位于/etc/sysconfig/network-scripts/目录。文件名通常是ifcfg-ens33这种ifcfg-<网卡名>格式。看一个完整的静态IP配置：
bash复制TYPE=Ethernet
PROXY_METHOD=none
BROWSER_ONLY=no
BOOTPROTO=none
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_FAILURE_FATAL=no
IPV6_ADDR_GEN_MODE=stable-privacy
NAME=ens33
UUID=3a7feb22-8b0c-4def-a01c-85e13d941e57
DEVICE=ens33
ONBOOT=yes
IPADDR=192.168.1.100
PREFIX=24
GATEWAY=192.168.1.1
DNS1=8.8.8.8
DNS2=114.114.114.114
逐行拆解重点字段：
BOOTPROTO：取值none、static、dhcp。none和static效果基本一样，就是手动静态配置；dhcp则交给DHCP服务器自动分配。ONBOOT：系统启动时是否激活该网卡。新装的虚拟机经常出现网卡配好了却上不了网，八成是这里写了no。DEVICE和NAME：逻辑上关联到哪块网卡。DEVICE对应内核里的接口名，NAME是NetworkManager显示名，两者必须匹配实际网卡名。IPADDR/PREFIX/GATEWAY：这是静态配置三件套。PREFIX是CIDR前缀长度，直接写24比单独写NETMASK=255.255.255.0更简单。DNS1/DNS2：DNS服务器。需要注意，手动配置的DNS在NetworkManager管理下会写入系统的resolved或/etc/resolv.conf，但是如果有其他服务（比如dhclient或systemd-resolved）在改这个文件，可能会产生覆盖。
3.1 为什么改了配置文件不生效
改完ifcfg-*文件，直接用systemctl restart network或nmcli connection reload？这里有一个很常见的误区：systemctl restart network在部分新版本中已经被废弃或不推荐，而且直接把配置文件重启网络服务不一定能正确加载新配置。
正确的做法是针对NetworkManager管理的连接执行：
bash复制$ nmcli connection reload
$ nmcli connection up ens33
第一条命令让NetworkManager重新读取配置文件，第二条命令让连接按新配置重新激活。如果你的网卡不是NetworkManager管理的，则用systemctl restart network（旧系统）或ifdown ens33 && ifup ens33。
3.2 多网卡多网关的坑
生产环境常遇到一台机器有两个网卡，比如一个内网一个外网。这种情况下，每个网卡配置文件里都写了GATEWAY，会出现什么现象？系统路由表只会保留一条默认路由——谁后激活谁生效。这会导致你本以为"内网流量走内网网卡、外网流量走外网网卡"，实际上所有默认流量都挤在一个口。
解决方案有两种。一种是在一个网卡上不写GATEWAY，只靠另一个网卡设置默认网关；另一种是写策略路由，这就比较复杂了，需要用到ip rule和路由表。对于入门阶段，先记住：默认网关是全局唯一的，不要让两张物理网卡同时声明GATEWAY字段，否则必有隐性路由冲突。
4. nmcli操作实践：用命令行工具完成网络变更
ifcfg-*文件可以直接手改，但手动编辑容易写错字段名。NetworkManager提供了nmcli这个命令行工具，它既能查看状态，也能修改配置并立即生效，还自动检查字段合法性。我个人建议初学者尽早用nmcli而不是直接去改文件。
4.1 查看已有的连接
bash复制$ nmcli connection show
NAME UUID TYPE DEVICE
ens33 3a7feb22-8b0c-4def-a01c-85e13d941e57 ethernet ens33
如果不带connection参数只敲nmcli device status，可以看设备状态：
bash复制$ nmcli device status
DEVICE TYPE STATE CONNECTION
ens33 ethernet connected ens33
STATE列是connected表示网卡已由NetworkManager接管，disconnected表示识别到了但还没有可用连接。nmcli的最大优势是它能保证"显式配置和运行时状态的一致性"。
4.2 把一个网卡改成静态IP
假设ens33当前是DHCP获取地址，想改成静态192.168.1.100/24，网关192.168.1.1，DNS为114.114.114.114。用nmcli这样才能全程命令化：
bash复制$ nmcli connection modify ens33 ipv4.method manual ipv4.addresses 192.168.1.100/24 ipv4.gateway 192.168.1.1 ipv4.dns "114.114.114.114 8.8.8.8"
$ nmcli connection up ens33
第一条命令改配置，第二条命令让连接重新激活。注意ipv4.dns支持双引号括住多个DNS，空格分隔。ipv4.method manual表示不用DHCP。改完再用ip addr和ip route验证，确保配置真实生效。
如果想切回DHCP：
bash复制$ nmcli connection modify ens33 ipv4.method auto ipv4.addresses "" ipv4.gateway "" ipv4.dns ""
$ nmcli connection up ens33
注意把之前填的地址和网关清空，否则DHCP模式下残留静态配置信息会引发混乱。
4.3 nmtui：给还不习惯命令行的人一个半图形界面
nmtui是NetworkManager提供的文本交互界面，打开后可以编辑连接、启停连接、设置主机名。它本质上是生成一样的nmcli操作，但交互方式更适合巡检或讲解时使用。对不想背命令的初学者，nmtui是很好的过渡工具；但脚本化运维还是要掌握nmcli。
提示：
nmcli修改完，配置最终会写回/etc/sysconfig/network-scripts/ifcfg-*（也可能在/etc/NetworkManager/system-connections/，取决于发行版设置）。所以用nmcli并不代表可以完全忽略配置文件，排查时两个地方都要看。
5. DNS解析与resolv.conf的现代管理方式
网络通了不代表域名解析正常。ping 114.114.114.114通，ping baidu.com不通，十有八九是DNS出了问题。
5.1 手动维护resolv.conf的时代已经过去了
很久以前，只要编辑/etc/resolv.conf这个文件就能设置DNS。但现在的发行版里，这个文件往往被systemd-resolved、NetworkManager或dhclient动态管理，你手动写的配置可能过几分钟就被覆盖。
查看当前DNS设置，可以用：
bash复制$ resolvectl status
如果系统用的是systemd-resolved，它会按连接显示每个网卡关联的DNS。NetworkManager管理的连接里配置的DNS，会通过resolved统一处理。手动测试解析可以用：
bash复制$ nslookup www.example.com
$ dig +short www.example.com
如果没有dig，nslookup通常自带。排查顺序建议是：先确认路由能到DNS服务器，再用dig指定服务器测解析，最后才查配置文件。
5.2 常见DNS故障模式和修复方法
现象一：ping内网IP正常，ping www.example.com提示Name or service not known。先看一下resolvectl status里有没有拿到DNS地址，如果没有，需要给连接配置DNS或用nmcli设置。现象二：能解析域名但打开网页很慢，可能是配置了不可用的DNS优先项，比如第一个DNS超时导致尝试时间很长，遇到这种情况可以调整DNS顺序，把常用且稳定的写在前面。
还有一个冷门但真实存在的坑：网络连接配置文件里的DNS字段和/etc/resolv.conf里的search域。如果公司内部有私有域名解析需求，需要在连接配置里加上ipv4.dns-search，否则访问内部主机名时无法自动补齐域名后缀。
6. 实战案例：一台服务器重启后网卡没起来，完整排查链路
前面的内容都是基础工具，现在把它们串起来，讲一个典型的运维场景。之前有一台服务器重启后，业务访问全部异常。登录控制台后，发现系统能进去，但ip addr看不到IP地址。这个案例的排查过程，几乎覆盖了上面所有知识点。
6.1 第一步：确认网卡状态
先执行：
bash复制$ ip addr
输出里只看到lo回环接口，物理网卡ens33没有分配到IP。再执行ip link show ens33，发现状态是state DOWN。这一步已经缩小了范围：不是地址配置问题，而是网卡压根没启用。
6.2 第二步：检查ONBOOT是否失效
手动先把网卡拉起来试试：
bash复制$ ip link set ens33 up
$ ip addr show ens33
网卡状态变成了UP，但是依然没有IP地址。这就说明问题不在物理层面，而在配置层面。查看/etc/sysconfig/network-scripts/ifcfg-ens33，发现ONBOOT=yes写的是对的，BOOTPROTO=dhcp也正常。
6.3 第三步：怀疑NetworkManager没接管
执行nmcli device status：
bash复制$ nmcli device status
DEVICE TYPE STATE CONNECTION
ens33 ethernet disconnected --
状态显示disconnected——设备被识别但没有加载任何连接。再查连接配置是否还存在：
bash复制$ nmcli connection show
发现连接列表是空的。也就是说，虽然ifcfg-ens33文件还在，但NetworkManager没有把它注册为一个连接。这种情况在手动编辑过配置文件但没执行nmcli connection reload时经常发生。
6.4 第四步：重新加载连接
解决办法很简单：
bash复制$ nmcli connection reload
$ nmcli connection up ens33
第一条让NetworkManager重新扫描配置文件并注册连接，第二条激活它。执行后再看ip addr，网卡拿到了DHCP地址，网络恢复。后续我让这台服务器保持NetworkManager接管网络，所有的配置变更都通过nmcli操作，避免再次出现配置文件与NetworkManager状态不同步的问题。
6.5 这条排查链路说明了什么
这个案例不是罕见故障，而是很多人都会踩的坑——重启后网卡没自动起来，原因常常是NetworkManager没有正确加载连接配置，甚至有些人是直接停用了NetworkManager、自己在ifcfg-*里配置，却又没有常驻网络服务来拉网卡。排查网络问题的思路，本质上就是"链路层→地址层→路由层→DNS层"这样一层层往上看，不要一上来就改配置。
7. 网络连通性的验证方法：从ping到端口测试的完整清单
验证网络是否正常，不能只会ping。整理一个我在日常排障时常用的验证清单，按顺序执行，基本能定位90%的连通性故障。
7.1 链路层与地址层验证
bash复制$ ip link show <网卡名> # 查看物理链路是否UP、有没有NO-CARRIER
$ ip addr show <网卡名> # 查看是否获取到IP地址
如果网卡是NO-CARRIER，说明线没插好、交换机端口没开或网线坏了。如果是DOWN，则可能是驱动没加载或接口被手动down了。
7.2 路由层验证
bash复制$ ip route show
$ ip route get 8.8.8.8
ip route get 8.8.8.8很实用，它会告诉你发往这个IP的数据包实际走哪条路径、源地址是什么。如果返回值里出现unreachable，说明没有到达目标的路由。这条命令比单纯看路由表更直接，因为路由选择受策略路由影响，肉眼盯表容易漏判。
7.3 连通性与服务端口验证
先判断到目标IP是否通：
bash复制$ ping -c 4 8.8.8.8
如果ping不通但有业务，则要测端口：
bash复制$ telnet 192.168.1.100 22
$ nc -vz 192.168.1.100 22
nc -vz执行完会提示Connection succeeded或succeeded!之类的信息。端口通就说明TCP层没有问题，接下来查的就是应用层。我在前面也提醒过：云环境里ICMP被屏蔽是常态，ping不通不能直接判死刑，一定要用端口测试补充。
7.4 DNS验证
bash复制$ resolvectl status
$ dig @114.114.114.114 www.example.com +short
dig @<指定DNS服务器>可以绕过系统默认DNS，直接问某台服务器，这样能区分是"本地DNS配置错了"还是"DNS服务器本身解析不了"。
这套清单的好处是每一步都有明确的判断标准，不会让人对着屏幕发慌。实际操作中把每层命令执行一遍，网络故障基本能锁定到具体环节。
8. 关于网络管理"上篇"的总结与下一步方向
这次的内容偏基础，把Linux网络管理的核心概念、常用命令和配置文件串了一遍。基于我自己的经验，有几点特别值得再次强调：
第一，命令查看的永远是运行时状态，配置文件是持久化状态，两者不同步是很多故障的根源。所以改完东西一定要触发重载或重新激活，千万别以为改了文件任务就完成了。
第二，能用ip就别用ifconfig，能用ss就别用netstat。不是说老命令不能用，而是新命令输出更清晰、信息更完整，排查效率差很多。
第三，遇到网络故障先分层，不要急着动配置。链路层、地址层、路由层、DNS层逐层确认，每层都有对应的查看命令，排错效率翻倍。
上篇就说到这。像策略路由、多网卡绑定（bonding）、VLAN、网桥、tcpdump抓包分析、NetworkManager深入调优这些内容，都属于网络管理中进阶的部分，后续可以在中篇和下篇里展开讲。配置文件的细节很多，但核心思路不外乎这几条——理解状态、理解协议、理解工具，剩下的都是组合运用。