Linux网卡命令实战：从链路状态到驱动排查的运维指南
1. 网卡命令不是背出来的，是用出来的
刚入行那会儿，带我的师傅扔过来一台装好系统的测试机，说“把网卡信息摸清楚，半小时后告诉我这台机器能不能上业务”。我当时的第一反应是打开图形界面找网络设置，结果那台机器连桌面环境都没装，纯命令行。硬着头皮敲了几个命令，输出信息一大片，MAC地址、速率、双工模式、驱动版本混在一起，根本分不清哪个是哪个。后来师傅过来，三条命令下去，网卡型号、链路状态、IP配置、驱动模块全出来了，前后不到两分钟。
这件事让我明白一个道理：网卡基础命令的价值不在于“知道有这个命令”，而在于“知道在什么场景下用哪条命令、看哪个字段”。很多人学命令的方式是背参数表，ip link有哪些子命令、ethtool支持哪些选项，背了一堆，真到排查问题时还是不知道从哪下手。原因很简单——命令是工具，排查思路才是主线。
这篇内容面向的是刚接触Linux网络配置的运维新手、需要经常在服务器上定位网络问题的开发人员，以及准备面试但只会背命令不会讲场景的朋友。我会把网卡基础命令拆成几个真实的使用场景来讲：怎么快速摸清一台机器的网卡底细、怎么判断链路是不是通的、怎么确认驱动和固件有没有问题、怎么在不动配置的前提下做诊断。每个命令都会说清楚“为什么用这条”“输出里哪个字段是关键”“什么情况下这条命令会骗你”。
需要提前说明的是，不同发行版和内核版本下命令的输出格式会有差异，我下面给出的示例基于常见的现代Linux环境，老版本系统上部分命令可能不存在或参数不同，遇到这种情况优先查man手册确认当前系统的实际支持情况。另外，涉及修改配置的操作我会单独标注风险等级，纯查看类命令可以放心执行。
2. 摸清网卡底细：从“有哪些网卡”到“每块网卡什么状态”
2.1 第一层：确认系统认到了哪些网卡
拿到一台陌生机器，第一步不是急着配IP，而是确认系统到底认到了几块网卡、分别叫什么名字。这里最直接的工具是ip link：
ip link show输出里每一行开头的数字加冒号后面就是网卡名称，比如1: lo:、2: eth0:、3: eth1:。lo是回环接口，不用管它，剩下的才是物理或虚拟网卡。每块网卡后面跟着的<BROADCAST,MULTICAST,UP,LOWER_UP>这一串尖括号里的标志位信息量很大：UP表示管理层面已启用，LOWER_UP表示物理链路层检测到载波信号，这两个标志同时存在才说明网卡真正处于“可工作”状态。
我见过不少新手看到UP就以为网卡正常了，结果网线根本没插。区别就在于LOWER_UP——它对应的是物理层信号，网线没接、对端设备没开机、光模块没插好，这个标志都不会出现。所以判断一块网卡是否“物理上通了”，看LOWER_UP比看UP靠谱得多。
如果想看更简洁的列表形式，可以用：
ip -br link show-br是 brief 模式，输出压缩成“网卡名 + 状态 + MAC地址”三列，适合快速扫一眼。状态列显示UP或DOWN，配合后面的 MAC 地址，一眼就能看出哪块网卡是活跃的。
还有一个老命令ifconfig -a也能列出所有网卡，包括未启用的。但ifconfig属于 net-tools 套件，很多新系统默认不装了，而且它的输出里不直接体现LOWER_UP这类链路层标志，排查物理链路问题时不如ip link直观。我的习惯是：日常查看用ip -br link，需要看详细标志位用ip link show，ifconfig只在老系统上作为备选。
2.2 第二层：网卡名称背后的命名逻辑
现代Linux系统上网卡名字可能是eth0、ens33、enp3s0、eno1等各种形式，这不是随意起的。eth0是老式命名，按内核探测顺序分配，问题是多网卡机器上顺序可能不稳定，重启后eth0和eth1对调的情况时有发生。后来引入了可预测命名规则：en开头表示以太网，后面的p3s0表示PCI总线3槽位0，o1表示主板板载第一个，s0表示热插拔槽位0。
这个知识点的实际价值在于：当你看到enp3s0这种名字时，能大致判断它是插在PCIe插槽上的独立网卡，而不是板载网卡。排查硬件问题时，这个信息能帮你快速定位到物理位置。如果系统用的是老式eth0命名，而你又有多块网卡，建议在GRUB配置里加上net.ifnames=0之外的命名策略参数来固定名称，避免重启后网卡顺序漂移导致配置错位。不过这个操作涉及引导参数修改，属于中等风险，改之前务必确认有带外管理或本地控制台可用。
查看网卡命名相关的持久化配置，可以检查：
ls /etc/systemd/network/以及 udev 规则目录下的网卡命名规则文件。不过对于日常排查来说，知道当前网卡叫什么、对应哪个物理口，比深究命名规则本身更实用。物理口对应关系可以通过ethtool -p让网卡指示灯闪烁来确认（需要网卡和驱动支持），这个后面会细说。
2.3 第三层：MAC地址与厂商信息的交叉验证
ip link输出里link/ether后面那串就是MAC地址。MAC地址的前三个字节（OUI）对应厂商代码，虽然现在虚拟化和容器环境下MAC地址可以随意设置，但在物理机上，通过OUI能大致判断网卡品牌。这个信息在资产盘点和驱动匹配时有实际意义——比如你发现某台机器MAC前缀对应的厂商和采购记录对不上，可能意味着网卡被更换过。
查看MAC地址还有一个更直接的命令：
ip link show eth0 | grep link/ether把eth0换成实际网卡名即可。如果只想拿MAC地址做脚本处理，可以用：
cat /sys/class/net/eth0/address这个方式不依赖ip命令的输出格式解析，在脚本里更稳妥。/sys/class/net/目录下每块网卡对应一个子目录，里面除了address还有operstate（运行状态）、speed（速率）、mtu等文件，直接读文件比解析命令输出更可靠，这是写自动化脚本时的一个实用技巧。
3. 链路通不通：物理层与数据链路层的判断方法
3.1 速率和双工：最容易被忽略的协商问题
网卡灯亮着、LOWER_UP也在，不代表链路质量没问题。速率和双工协商不一致是导致“网络时通时断、大流量下丢包严重”的经典原因。查看当前协商结果：
ethtool eth0输出里重点看两行：Speed和Duplex。正常千兆环境应该显示Speed: 1000Mb/s、Duplex: Full。如果显示Speed: 100Mb/s而你知道这条链路两端都是千兆设备，那说明协商降速了，常见原因是网线质量不达标（比如用了只支持百兆的旧线）、水晶头压制不良、或者对端端口配置有问题。
更隐蔽的情况是双工不匹配：一端强制全双工、另一端自协商成半双工，链路能起来，小流量测试也正常，但一跑大流量就出现大量冲突和丢包。这种问题用ping测不出来，得看网卡统计：
ethtool -S eth0 | grep -i -E "error|drop|collision"不同驱动的统计项名称不一样，常见的有rx_errors、tx_errors、rx_crc_errors、collisions等。如果collisions持续增长，基本可以锁定双工协商问题。修复方式是把两端都改成自协商，或者两端都强制相同的速率和双工模式，切忌一端强制一端自协商。
注意：用
ethtool -s修改速率和双工属于配置变更，可能导致链路短暂中断，远程操作时有断连风险。修改前确认有本地或带外访问手段。
3.2 用指示灯定位物理口：ethtool -p 的实战用法
机房现场排查时，面对一台插了四块网卡的服务器，怎么确认enp3s0对应的是哪根网线？最笨的办法是拔线看哪个口断，但生产环境不允许随便拔。ethtool -p可以让指定网卡的指示灯闪烁：
ethtool -p eth0 10后面的数字是闪烁秒数，执行后对应网口的LED会闪烁10秒，现场人员一眼就能定位到物理口。这个功能依赖网卡硬件和驱动支持，不是所有网卡都实现了，执行后如果灯没反应，说明该网卡不支持此特性，只能回到拔线或查资产标签的老办法。
我个人的经验是：新机器上架时就把网卡名和物理口位置的对应关系记录下来，贴标签或者记在资产表里，后面排查问题时能省大量时间。等到故障现场再去确认对应关系，压力大、容易出错。
3.3 MTU 与分片：一个隐蔽的连通性杀手
ip link输出里有个mtu 1500，这是最大传输单元。大部分场景下1500没问题，但在overlay网络、隧道封装、存储网络等环境下，MTU配置不当会导致“小包通、大包不通”的诡异现象——ping能通，但ssh连不上或者文件传输卡死。
验证方法是用指定大小的包做连通性测试：
ping -M do -s 1472 192.0.2.1-M do表示禁止分片，-s 1472是数据部分大小，加上28字节的IP和ICMP头正好1500。如果这个能通，说明路径MTU至少1500；如果提示“Message too long”或“Fragmentation needed”，说明路径上某段MTU小于1500，需要逐跳排查或者调整本端MTU。
查看和修改MTU：
ip link show eth0 | grep mtu ip link set eth0 mtu 1400修改MTU是即时生效的配置变更，会影响该网卡上所有流量，生产环境操作前要评估影响。临时验证可以用ping带不同-s值逐步逼近，找到实际路径MTU后再决定是否调整。
4. 驱动与固件：网卡“认到了但不工作”的排查路径
4.1 确认驱动模块加载状态
网卡在ip link里能看到，但状态异常或者速率不对，下一步要确认驱动是否正常加载。查看网卡使用的驱动：
ethtool -i eth0输出里driver字段是驱动名称，version是驱动版本，firmware-version是固件版本，bus-info是PCI总线地址。这几个信息在排查兼容性问题时非常关键——比如某型号网卡在特定内核版本下驱动有bug导致丢包，升级驱动或固件是解决方案，而ethtool -i就是确认当前版本的入口。
查看驱动模块是否已加载：
lsmod | grep <驱动名>比如驱动是ixgbe，就lsmod | grep ixgbe。如果模块没加载但网卡能被识别，可能是驱动编译进了内核而非模块形式，这种情况lsmod看不到但网卡仍工作。反过来，如果ip link里根本看不到某块网卡，而lspci能看到对应PCI设备，那基本可以判断是驱动缺失：
lspci | grep -i ethernetlspci列出的是PCI总线上的硬件设备，能看到网卡但ip link里没有对应接口，说明硬件在、驱动没起来。这时候需要确认内核是否包含该驱动、是否需要安装额外的驱动包。这个排查顺序很重要：先lspci确认硬件，再ip link确认接口，最后ethtool -i确认驱动，三步下来能快速定位问题出在硬件识别、驱动加载还是接口配置层面。
4.2 固件版本与已知问题
ethtool -i输出的firmware-version在某些网卡上可能显示N/A，这不一定是问题，部分驱动不通过这个接口暴露固件版本。如果需要更准确的固件信息，可以用：
ethtool --show-firmware eth0或者查看dmesg里驱动加载时的日志：
dmesg | grep -i <驱动名>驱动初始化时会打印固件版本、队列数量、特性开关等信息。我遇到过一块网卡在特定固件版本下开启多队列后出现偶发丢包，dmesg里能看到队列初始化相关的告警，升级固件后问题消失。这类问题的特点是“没有明显报错但性能不达标”，靠ping和常规连通性测试发现不了，得结合ethtool -S的统计数据和dmesg日志交叉分析。
提示：
dmesg输出可能很长，用grep过滤驱动名或网卡名能快速定位相关行。如果日志已经被环形缓冲区覆盖，可以查/var/log/下的系统日志文件。
4.3 中断与队列：高性能场景下的调优入口
普通办公场景不太需要关注中断和队列，但在高吞吐场景下，网卡中断分配不均会导致单核跑满、整体吞吐上不去。查看网卡队列和中断情况：
ethtool -l eth0输出显示当前队列数和最大支持队列数。再看中断分布：
cat /proc/interrupts | grep <网卡名>如果所有队列的中断都集中在CPU0上，说明中断亲和性没配好，需要调整irqbalance服务或者手动设置中断亲和性。这个操作属于性能调优范畴，风险等级中等——改错了会影响网络性能但不至于断网，建议在业务低峰期操作并做好记录。
查看网卡是否开启了多队列和RSS：
ethtool -S eth0 | grep -i queue统计项里能看到每个队列的收发包计数，如果某个队列计数明显偏高而其他队列接近零，说明流量分发不均，可能需要检查RSS配置或中断亲和性。这些内容已经超出“基础命令”的范畴，但作为排查思路的延伸，知道往哪个方向查是有价值的。
5. 地址与路由：从网卡到网络层的衔接
5.1 查看IP地址的正确姿势
ip addr show是查看IP地址的标准命令：
ip addr show eth0输出里inet后面是IPv4地址和掩码，inet6后面是IPv6地址，link/ether后面是MAC地址。相比老式的ifconfig，ip addr的输出结构更清晰，而且能同时显示IPv4和IPv6信息。
一个常见误区是只看inet行确认有IP就认为网络配置没问题。实际上还要看地址后面的scope字段：scope global表示全局可路由地址，scope link表示仅链路本地有效，scope host是回环地址。如果一块对外服务的网卡上IP显示scope link，那这个地址只能在本地链路通信，跨网段访问是不通的。
查看地址的获取方式（静态配置还是DHCP）：
ip addr show eth0 | grep -E "inet|valid_lft"DHCP获取的地址后面会带valid_lft和preferred_lft租期信息，静态配置的地址没有这两个字段。这个细节在排查“IP莫名其妙变了”的问题时很有用——如果地址带租期且租期较短，说明是DHCP下发的，地址变化要找DHCP服务器侧的原因。
5.2 路由表与网卡的关系
有IP不代表能通外网，还得看路由表：
ip route show输出里default via <网关地址> dev <网卡名>这一行是默认路由，决定了非本地流量的出口。如果默认路由指向的网卡和你预期的不一致，流量就会从错误的网卡出去。多网卡机器上这个问题特别常见——两块网卡都有默认路由时，内核按metric值选择，metric小的优先。查看metric：
ip route show default输出里metric后面的数字就是优先级，数值越小优先级越高。如果发现流量走错了网卡，检查各条默认路由的metric值，调整到符合预期的顺序。
还有一个实用命令是查某个目标地址实际走哪条路由：
ip route get 192.0.2.1这个命令会告诉你到目标地址的具体路径：从哪块网卡出、源IP是什么、经过哪个网关。排查“为什么走这个网卡不走那个”的问题时，ip route get比盯着路由表猜要高效得多。我处理过多网卡策略路由的案例，表面看路由表配置正确，但ip route get显示实际选路和预期不符，最后发现是策略路由规则优先级的问题。
5.3 ARP缓存：局域网连通性的最后一环
同网段通信依赖ARP解析，查看ARP缓存：
ip neigh show输出里每行是“IP地址 + 对应网卡 + MAC地址 + 状态”。状态REACHABLE表示缓存有效，STALE表示缓存过期但未验证，FAILED表示解析失败。如果到某个同网段地址不通，先看ip neigh里有没有对应的有效条目——没有条目说明ARP请求没得到响应，问题可能在对端没开机、IP冲突、或者中间有隔离；有条目但状态FAILED，说明解析尝试失败了，可以尝试清除缓存后重试：
ip neigh flush dev eth0清除后再次通信会触发重新解析。这个操作风险很低，只影响本机ARP缓存，但要注意清除瞬间可能有短暂解析延迟。
6. 几个容易踩的坑和我的处理习惯
6.1 命令输出会“骗人”的几种情况
第一种情况：ip link显示UP但实际不通。前面说过，UP只是管理状态，不代表链路层就绪，必须结合LOWER_UP判断。第二种情况：ethtool显示Link detected: yes但速率是100Mb/s，链路是通的但降速了，性能问题容易被忽略。第三种情况：ping通但业务不通，可能是MTU问题、可能是防火墙规则、也可能是应用层绑定到了错误的地址上，ping只验证了ICMP层面的连通性。
我的习惯是：任何“网络不通”的问题，按物理层→链路层→网络层→传输层的顺序逐层确认，每一层用对应的命令拿到确凿证据再往下走，不跳层猜测。物理层看LOWER_UP和ethtool的Link detected，链路层看速率双工和错误统计，网络层看IP、路由、ARP，传输层看端口监听和连接状态。这个顺序能避免大量无效排查。
6.2 脚本化采集信息的实用组合
排查问题时经常需要把信息一次性收集全，我常用的组合是：
ip -br link; ip -br addr; ip route show; ethtool eth0 | grep -E "Speed|Duplex|Link detected"; ethtool -S eth0 | grep -i -E "error|drop"这一串命令覆盖了接口状态、地址、路由、链路协商、错误统计五个维度，输出量不大但信息密度高。写成脚本时建议把网卡名作为参数传入，避免硬编码。另外ethtool -S的统计项名称因驱动而异，脚本里用grep -i做模糊匹配比精确匹配更通用。
6.3 修改类命令的风险分级
纯查看类命令（ip link show、ip addr show、ip route show、ethtool不带-s、ip neigh show）可以随时执行，无风险。低风险修改（ip neigh flush）影响范围限于本机缓存。中等风险修改（ip link set mtu、ethtool -s改速率双工）会导致链路短暂中断，远程操作需谨慎。高风险修改（修改IP地址、删除路由、禁用网卡）可能导致管理连接中断，必须有带外访问或本地控制台兜底。
我个人的原则是：在生产环境执行任何修改类网络命令前，先确认三个问题——这条命令影响哪些流量、中断持续多久、出问题怎么回滚。三个问题都有明确答案再动手，答不上来就先在测试环境验证。这个习惯帮我避免过好几次远程操作把自己锁在门外的尴尬。
网卡基础命令看着简单，真正拉开差距的是对输出字段的理解深度和排查时的分层思路。命令本身查手册就能会，但“看到什么现象该往哪个方向查”这个判断力，只能靠一次次实际排查积累。上面这些内容里，LOWER_UP和UP的区别、ethtool -S错误统计的解读、ip route get的实际选路验证，是我认为最值得优先掌握的三个点，日常排查中出场频率最高。