ESXi 8.0下瑞昱螃蟹卡断流排查与修复指南

手里一台退役台式机改成的ESXi 8.0宿主机，主板是B450M，板载一颗RTL8111H加一颗RTL8125BG，典型的“双螃蟹”组合。ESXi 8.0官方支持列表里根本没这两颗卡的影子，我按社区惯例把瑞昱驱动集成进安装ISO，忙活了一晚上终于装起来。结果用了不到两天问题就来了：宿主机的管理IP时不时失联，虚拟机里ping外网几十秒断一次，拔插网线也没用。这类故障在圈子里习惯叫“螃蟹卡断流”，表面看是网络不稳定，实际埋着网卡驱动、主板电源管理、虚拟交换机配置三层雷。这篇文章就是我逐一踩平这些坑的全过程，从BIOS到驱动参数再到换卡兜底，尽量一次说透。

先说背景。如果你组装的是基于AMD或Intel平台的DIY宿主机，而不是买品牌服务器，板载网卡十有八九是瑞昱的，也就是俗话说的“螃蟹卡”。ESXi对这类消费级网卡支持很差，8.0版本默认镜像不会加载相关驱动，所以必须手动把驱动VIB打进ISO，或者开机以后在线装驱动。但很多玩家到这里就放松警惕了，以为驱动识别到网卡就等于稳定。实际上“能用”和“好用”隔着很远，断流就是最常见的一关。它的难缠之处在于链路一直显示Up，可数据包就是时通时断，日志里还不一定有error，新手很容易被带偏方向。

1. 为什么ESXi 8.0里会有“螃蟹卡断流”这回事

1.1 官方不支持，驱动全靠“外挂”

ESXi 8.0的硬件兼容列表里主要收录的是Intel、Broadcom、Mellanox这些服务器网卡，瑞昱的消费级型号几乎全部缺席。为什么？服务器场景对网卡稳定性、队列数量、虚拟化卸载能力要求很高，瑞昱的消费级网卡在这些维度上确实差距明显。但DIY玩家不太纠结这些，板载螃蟹卡不额外花钱，扔进软路由、NAS、测试机里跑ESXi很常见。

想让ESXi识别螃蟹卡，唯一的办法是外挂驱动。当前常见来源有两个：一个是VMware社区的Fling页面会不定期放出net-r8168、net-r8125的VIB包，另一个是各种ESXi定制镜像论坛把驱动打好再分发。Fling版本通常更新，但要注意选对ESXi 8.0对应的包，7.0的VIB硬装到8.0上大概率提示兼容性错误。

集成驱动的做法我以前用PowerCLI重新打包ISO，操作路径长、出错面大。后来发现更直接的办法是开机后在线装VIB：把驱动ZIP包传到/tmp，进维护模式后用esxcli software vib install装上再重启。这里有个坑必须提醒：远程装驱动是有风险的，如果网卡驱动坏了，重启后主机可能彻底失联，没有IPMI或者物理显示器键盘的话会非常狼狈。

1.2 断流的具体表现，先对号入座

螃蟹卡断流不是只有一种样子，我见过至少四类症状，对应的根因差别很大。

第一类是管理端口间歇性失联。vCenter里显示“主机不可访问”，web界面打不开，等几十秒自己恢复。这种一般集中在电源管理，也就是EEE和ASPM在捣鬼。链路在低流量时进入低功耗状态，有流量进来时没有被及时唤醒，表现就是管理IP突然没了，过一会儿又自己好。

第二类是虚拟机网络周期性断开。VM里ping网关，正常几十秒后突然丢包几秒再恢复，严重时完全断开几分钟。这种情况多半是驱动中断处理能力弱，高负载下接收队列溢出了。esxtop里会看到丢包计数快速上涨。

第三类是只有高负载传输时才断流。比如虚拟机迁移、NAS备份、大文件拷贝，跑着跑着链路像被掐断一样。这可能是驱动Firmware或缓冲参数与ESXi网络栈不匹配，传输结束后又恢复正常，很容易被误判为交换机问题。

第四类是固定时间、固定频率断流。比如每小时一次，持续几秒钟。这类往往和主板的C-State深度睡眠有关，也可能是Wake on LAN、网络唤醒等选项干扰了PCIe设备状态切换。

不同症状要采用不同手段，后面排查和解决部分我会对应展开。

1.3 断流的三个根因，把“为什么调一调就好”讲明白

很多人照着论坛上的经验改一通参数，发现好了，但不知道为什么。这里我把它拆成三个层次。

第一个层次是电源管理。瑞昱网卡的驱动默认经常开启EEE（Energy Efficient Ethernet，节能以太网）和ASPM（PCIe链路节能）。EEE会让网卡在无流量时降低发送功耗，ASPM会让PCIe链路进入低功耗模式。问题在于ESXi的虚拟化网络栈对消费级网卡的唤醒支持很差，进入低功耗以后，流量到达时响应延迟高，甚至直接唤醒失败，链路看起来是Up，实际已经“假死”。所以断流问题里，这类占比最高。

第二个层次是中断与唤醒的配合。网卡收到数据包后要通过中断通知CPU，ESXi再分发到对应VM。螃蟹卡驱动的中断参数如果默认值不合适，高流量下中断风暴会挤占CPU，或者中断合并过度导致延迟暴增。表现就是延迟时高时低，丢包不明显但体验很差。

第三个层次是驱动对ESXi网络栈的适配不足。ESXi上的vSwitch、NetQueue机制对网卡驱动有特定要求，社区驱动没有拿到瑞昱完整的硬件手册，某些功能实现得比较粗糙。这不是一个参数能解决的，往往要靠换驱动版本或换硬件来规避。

2. 排查断流的正确顺序：先定位，再动手

2.1 五分钟硬核体检：用esxcli查看真实链路状态

一上来就改参数是大忌。我先教大家怎么用命令快速掌握网卡的真实状态。

SSH登录宿主机后，第一件事是查看当前识别到的网卡和驱动信息：

esxcli network nic list

输出里能看到vmnic0、vmnic1这些设备名，以及各自的Driver列。Driver列会显示r8168或r8125，这就确认了当前驱动模块是谁。

然后查看单块网卡的详细状态：

esxcli network nic get -n vmnic0

重点看Link Status、Speed、Duplex和PCI信息。如果Link Status显示Up但Speed低于预期，比如2.5G网卡协商成了1000Mbps，甚至只有100Mbps，先不要怪驱动，很可能是网线或交换机端口问题。

还有一个容易被忽略的命令是查看收发统计：

esxcli network nic stats get -n vmnic0

关注rxErrors、txErrors、rxDrops、txDrops这几项。如果在断流发生的瞬间这几个数字跳涨，基本可以锁定丢包发生在物理网卡驱动层，而不是上面的虚拟交换机或虚拟机。

2.2 用esxtop看网络层丢包，找到断流发生的真实位置

esxtop是ESXi里最强大的实时监控工具，用来看网络丢包非常直观。进入esxtop后按下小写字母n，界面会切换到网络统计视图。

这个视图里每行对应一个物理网卡或虚拟交换机端口，其中DrvRx和DrvTx表示驱动层的收发包数量，RxErr、TxErr、RxDrop、TxDrop这几列是判断丢包位置的关键。如果RxErr增长很快，问题多半在物理层或者驱动层；如果RxDrop很高，可能是驱动缓冲不足或者虚拟机的接收队列没跟上。

用esxtop观察断流发生的实时状态，比事后看日志更有效。我一般是在一个终端里开着esxtop，另一个终端持续ping网关，断流出现时立刻切过去看计数。哪个计数器在跳，问题就在哪一层，后面处理就能有的放矢。

2.3 日志与打流测试：两个容易被忽略的验证手段

esxtop看到的是实时状态，日志则能还原事件过程。ESXi的日志在/var/log/vmkernel.log，排查断流时我常用这几条命令：

grep -i "vmnic\|r8168\|r8125" /var/log/vmkernel.log | tail -100 grep -i "link\|reset\|drop\|timeout" /var/log/vmkernel.log | tail -100

这里有个经验提醒：不要只搜error，很多电源管理导致的问题在日志里只是以warning或info级别出现，比如Link Down、Link Up反复出现，或者EEE、ASPM触发的状态切换记录。宁可把关键词放宽，也不要只看严重级别。

然后是打流传唤。管理网络用小包ping发现不了问题，因为断流往往在连续流量下才会触发。我习惯用虚拟机里的iperf3做双向压力测试：

iperf3 -c 192.168.1.10 -t 60 -i 5

如果双向打流时出现吞吐骤降或连接重置，基本能复现断流。复现这个动作很重要，没有稳定复现就改参数，改完也不知道到底有没有用。

2.4 别忘了最朴素的检查：网线和接口

调试到怀疑人生的时候，回头看看物理链路。螃蟹卡对网线质量非常敏感，六类线用六类线，超五类用超五类，不要拿偏偏的垃圾线凑合。我遇到过一张千兆螃蟹卡在一个网口上反复断流，换了一个交换机端口就完全正常，最终确认是那个交换机端口的PHY芯片有问题。

另一个常被忽略的是水晶头压接质量。很多断流是时断时续的，换线后立刻恢复，这时候不要怀疑驱动。建议在排错初期就做一次“换线+换端口”对照实验，成本极低，却能把一大类物理问题直接排除掉。

3. 从BIOS到命令行的完整解决路径

3.1 第一步：BIOS里的“省电三兄弟”全关

先把主板的节能相关选项逐项排查一遍，这是解决断流性价比最高的动作。不同BIOS叫法不一，但核心就三类。

第一类是CPU电源管理，常见叫C-State、C6、C7、Package C-State Limit。ESXi对消费级主板的深睡状态支持不好，CPU进入深睡后PCIe设备唤醒协作会出现延迟。第二类是PCIe节能，常见叫ASPM、PCIe Express Power Management、Link State Power Management。AMD主板尤其在锐龙平台上对PCIe链路功耗管理非常激进，网卡挂在PCIe总线上，链路省电模式一开，断流概率直线上升。第三类是整机节能选项，比如ErP、EuP、Deep Sleep、Wake on LAN，这些会禁止主板在待机状态下为网卡供电，或者让网卡进入低功耗等待唤醒，对服务器用途来说都应该关闭。

进BIOS后找Allen这些选项，全部设为Disabled。如果找不到具体选项，就找主板说明书，或者搜索“主板型号+ASPM Disable”。有些品牌机BIOS把ASPM藏得很深，可能需要解锁隐藏菜单，这一步比较折腾，但一次关闭往往就能根治断流。操作完保存重启，先观察个半天，很多只开这一步就能解决的问题不需要再往下看。

3.2 第二步：用esxcli给网卡驱动“脱敏”

BIOS层面搞定之后，如果断流还在，就要对驱动下刀了。先确认当前加载的模块名，刚才esxcli network nic list的输出里Driver列就是模块名，比如r8168或r8125。

查看这个模块支持哪些参数：

esxcli system module parameters list -m r8168

不同驱动版本暴露的参数并不一致，有的叫eee_enable，有的叫green_ethernet，有的驱动参数列表里根本没有省电选项。所以先看list的真实输出再决定改什么，这一步很关键。

普通情况下优先调整以下两类参数：

esxcli system module parameters set -m r8168 -p "eee_enable=0 aspm_support=0"

如果驱动支持中断模式参数，比如int_mode，也可以通过同样的语法调整：

esxcli system module parameters set -m r8168 -p "int_mode=0"

改完以后必须重启宿主机才生效。模块参数是在驱动加载时读取的，不是热更新。重启后再次运行esxcli system module parameters list -m r8168检查参数是否变成设置值。

如果改了参数导致网卡彻底起不来，也不要慌。通过物理控制台进入ESXi的Direct Console界面，或者从第二个网口连进去，把参数改回原值再重启。这也是为什么我反复强调远程裸奔操作有风险的原因。

3.3 第三步：把管理网络单独隔离，别和业务流量挤一条道

在断流问题里，管理网络失联的优先级最高。如果宿主机里同时跑着虚拟机、NAS存储、监控系统，所有流量都挤在同一块螃蟹卡上，那问题会被放大一倍。ESXi的vSwitch本质上是把物理网卡的带宽和中断能力共享给多个上层对象，消费级网卡只有有限的队列和中断资源，突发流量很容易把管理网络拖垮。

有条件的建议把管理网络和虚拟机业务网络拆到两个物理网口上。如果主板有两颗螃蟹卡，就用一颗专门承载管理网络，另一颗专门跑虚拟机流量。做法是在ESXi里新建虚拟交换机，把管理网络的VMkernel端口绑定到vmnic0，把虚拟机流量绑定到vmnic1。这样即使业务流量把网卡打满，管理通道也还能存活，至少能保证你还能SSH进去救火。

如果只有一块物理网卡，这步做不了。没有物理隔离，软件层面的优先级设置其实帮助有限，只能尽量保证断流时管理还能用，最终还是要靠参数调整和硬件兜底。

3.4 MTU与速率协商：不要迷信9000大包

很多教程喜欢教人把ESXi的MTU改成9000以提升性能，但在螃蟹卡断流场景下，我强烈建议保持默认1500。Jumbo Frame需要从交换机、存储网络到虚拟机的全链路配合，任何一环不支持都会导致mtu协商失败，出现很隐蔽的“能通但大包丢”的问题。在驱动本身不稳的时候，巨型帧只会给排除增加变量，收益又有限，别动它。

速率协商也是类似思路。如果网卡和交换机之间频繁自动协商导致链路抖动，可以直接强制速率：

esxcli network nic set -n vmnic0 -S 1000 -D full

这个命令把vmnic0强制锁定在千兆全双工。如果卡是2.5G的而交换机端口只有千兆，或者网线不支持2.5G协商，强制到千兆反而更稳定。损失一点理论速度，换来链路状态的确定性和稳定性，对家用场景是划算的。

3.5 驱动版本不对，怎么安全换VIB

如果以上参数都调了依然断流，就要怀疑驱动本身了。先查看当前装的是哪个版本的驱动VIB：

esxcli software vib list | grep -i r8168

如果版本较老，可以去Fling或社区找更新版，也可以试着换一个替代模块，比如r8168换r8125驱动分支，或者反过来。具体下载哪个取决于你的网卡型号和ESXi小版本，安装前先看驱动包注释里标注的兼容范围。

装新驱动的流程是：把VIB ZIP传到/tmp，进入维护模式：

esxcli software vib install -d /tmp/net-r8125-1.0.0-xxx.zip --no-sig-check -f

装完重启宿主机。重启后看到网卡恢复正常，再退出维护模式。这里有一个差点让我翻车的细节：如果不先进入维护模式，直接装驱动，ESXi可能因为文件被占用而报错，或者装到一半网络断掉。所以顺序必须严格是：进维护模式、装驱动、重启、退出维护模式。

如果新驱动反而更差，卸载它也很简单：

esxcli software vib remove -n r8125

卸载后重启，确认回退成功。这种反复尝试方式比较费时间，但有时候驱动版本不对，参数再怎么调都是白搭。

3.6 实在没条件，写一个应急自愈脚本

上面方法都试过之后，如果断流频率不高但依然偶发，我建议顺手做一个应急自愈脚本，至少保证断流时能在几分钟内自动恢复网络，不用半夜爬起来拔网线。

思路是定时ping管理网关，连续失败就重启物理网卡。脚本放在/usr/local/bin/nic_watchdog.sh：

#!/bin/sh GW=192.168.1.1 IF=vmnic0 if ! vmkping -I $IF -s 64 -c 3 -W 2 $GW > /dev/null 2>&1; then esxcli network nic down -n $IF sleep 5 esxcli network nic up -n $IF echo "$(date '+%Y-%m-%d %H:%M:%S') $IF restart by watchdog" >> /var/log/nic_watchdog.log fi

脚本赋予执行权限后，再写进cron定时执行。注意ESXi默认的cron计划在重启后会丢失，需要配合其他方式让宿主机启动后自动重建cron条目，否则重启一次脚本就没了。这个脚本是治标手段，不是根本解法，起到的是“断流后尽早恢复”的兜底作用，不要用它的存在来原谅驱动和硬件层的隐患。

4. 常见问题与避坑实录

4.1 断流问题速查表

断流的排查过程信息很碎，我把它整理成一张速查表，方便以后遇到类似问题直接对照。

表格里的解法不是互斥的，现场场景往往是多个原因叠加。建议从头到尾过一遍，而不是只挑一条做。

4.2 四个我亲自踩过的坑

第一个坑是改完驱动参数没重启，就以为自己调了没用。模块参数在加载时读取，不是热更新的，设完之后看不到任何反馈，所以很多人会怀疑自己命令写错了。正确做法是改完就重启，起来后再检查list确认。

第二个坑是只关BIOS里的ASPM，忽略了驱动层还有独立的省电逻辑。BIOS关闭的是PCIe链路的省电入口，但驱动内部还有EEE逻辑，这两个是不同层面的东西。只关一个，问题照样会出现。所以BIOS和驱动参数必须配合起来，一起关才干净。

第三个坑是远程装驱动时没有备用通道，导致那台机器的唯一网口失效后彻底失联。我的建议是，凡是涉及驱动替换、模块参数调整、重启网络服务的操作，先确认有IPMI、物理显示器、或第二块网卡里的任意一项能救急，否则别轻易动手。

第四个坑是被网线坑了。有一次我折腾了整整一晚上，换驱动、调BIOS、改参数全试了一遍，最后发现是水晶头接触不良。这个经验让我后来排错时，永远先做完物理层对照实验再动软件层。

4.3 白折腾清单：这些操作对断流基本没用

有些帖子建议的操作我在实际测试中发现对断流场景作用甚微，写在这里给大家避坑。

比如反复修改vSwitch的负载均衡策略，把route based on origination port来回切换，对单物理网卡的断流没有意义。单卡场景根本不存在负载均衡问题，问题在驱动层。

再比如打开vSwitch的巨帧支持然后把全网MTU都改成9000，前面说过，这反而会引入新的兼容性风险。家用交换机和网线没有万兆全链路支持的情况下，巨型帧的收益可以忽略，麻烦倒是实实在在。

还有修改虚拟机的网卡类型，把e1000e换成vmxnet3。这个动作对提升虚拟网络性能有帮助，但改的是虚拟机到虚拟交换机之间的链路，螃蟹卡断流发生在物理网卡层面，换虚拟机网卡帮不上忙。当然，如果排查发现丢包点在虚拟交换机或虚拟机驱动，那另当别论。

排错时要抓住主矛盾，不要被网上各种“优化技巧”带偏方向。

最后再分享一点我的经验

断流问题折腾到最后，我的体会是：螃蟹卡跑ESXi不是不能用，但要给它定位。我的这台宿主机现在已经把RTL8125降级成管理口，虚拟机流量由一张Intel I225双口网卡承担，稳定性厅堂级提升。这套组合用了半年多，我没再在凌晨爬起来排查过网络。

如果你也打算长期稳定跑虚拟机、搭NAS或者软路由，我的建议很直接：先花一晚上把BIOS和驱动参数调好，让螃蟹卡能稳定工作，然后趁有精力的时候，花个百来块钱上一张Intel或Broadcom的服务器网卡作为主力口。省下来的时间成本，远远大于那张网卡的价格。

调试过程中记得给ESXi做一次配置备份，折腾驱动之前把当前状态留个底。后续就算改坏了也能快速回滚，不用对着失联的主机干瞪眼。这算是踩过无数次坑以后，我觉得最值得养成的习惯。