企业官网建设流程全解析

《回购协议掉线重连真的只是网卡吗》这个标题我记了很久。掉线重连这几个字，干过运维的人听到就头大，但我处理过的这类报障里，真正坏在网卡芯片和网口硬件上的其实不到三成。剩下七成，锅在驱动电源管理、系统 DNS 配置、交换机协商、虚拟化平台，甚至就是一根网线的质量问题。这篇文章我会把“掉线重连”从故障形态、硬件线缆、驱动电源管理、系统配置到虚拟化场景一层层拆开，最后给一套我自己实测有效的定位流程。适合被断网折腾过的运维、刚入行的网络管理员，以及家里网卡总掉线的朋友。

1. 掉线重连的四种“长相”，先分清再动手

很多人在看到“掉线重连”四个字时，脑子里的画像只有一种：网络突然没了，过几秒自己好。但真到现场去定位，你会发现同样一句“掉线重连”，背后的故障长相至少有四种区别。这四种情况对应的排查方向完全不同，一上来就盯着网卡，大概率白忙。

1.1 端口闪断：网口灯能直接告诉你答案

这种形态最典型：设备正在跑着，突然断线，几秒或几十秒后自动恢复。交换机上对应端口的状态日志会留下 link down / link up 的记录，间隔就是那几秒。

如果能在故障瞬间看到物理网口指示灯熄灭，问题基本可以圈在链路物理层——网线、水晶头、模块、端口弹片、或者交换机端口老化。以前处理过一个机房案例，一台服务器每天凌晨某个固定时间闪断一次，查了整整三天，最后发现是机柜门的合页刚好压在网线上，晚上保洁推门整理线缆时就把网线夹出一个瞬断。这种问题换十张网卡也不会好。

1.2 驱动断流：设备还在，连接已经没了

第二种更坑：系统托盘的网络图标全程显示“已连接”，网口灯也亮着，但实际 ping 网关已经丢包或完全不通。远程连接断开，人还没走到机器面前，网络自己又恢复了。

这种“假连接”状态大多是驱动层、电源管理层或协议栈的问题。常见凶手包括：

• 网卡驱动的节能模式在流量空闲时把设备状态切到了低功耗档，唤醒不及时；
• 驱动启用了“环保以太网” EEE 之类的协商特性，和交换机端口匹配不好；
• 网卡固件有断流 bug，常见于某些 Realtek 2.5G 芯片的早期批号。

遇到这类情况，简单换网卡硬件往往无效，需要从驱动、电源策略和协商特性入手。

1.3 协商掉速：2.5G 变成 100M 的经典现场

有些报障不会写“掉线”，而是写“网络变卡”“文件拷贝速度上不去”。现场一看，网卡协商速率已经从 2.5Gbps 降到了 100Mbps，甚至 10Mbps。这也是掉线重连的一种变种——链路没有彻底断开，只是协商到了一个很低的速率。

千兆以上的传输要用到双绞线内的全部四对线，而百兆只需要两对。如果网线、水晶头、面板模块其中任意一环节接触不良，网卡协商时会自动降级。这个机制本意是保证链路不死，但体感上就是“好好的机器突然变成龟速网络”。

1.4 网卡消失：重装系统才能回来的那种

还有一种情况比较毛骨悚然：设备管理器里网卡整个消失了，或者出现黄色感叹号，怎么刷新都不回来，非要重启、禁用再启用，甚至重装驱动。

这种问题通常是设备枚举层面的故障——PCIe 链路不稳定、驱动被系统回滚、虚拟机网卡驱动不匹配。它在物理服务器、老笔记本升级网卡、虚拟化平台新装系统时特别常见。别把它当成简单的硬件损坏，先查驱动版本和 BIOS 节能选项。

表格整理一下，方便对照自己遇到的情况：

2. 硬件与线缆层：网卡芯片背锅之前，先查这四样

硬件层是掉线重连里最容易用肉眼确认、也最常被冤枉的一层。很多运维一听到“网卡掉线”，第一反应是换网卡，结果换了新的还是掉，最后发现是根网线的问题。这层排查不需要什么高深工具，但要有顺序。

2.1 网线、水晶头、接口：链路不稳的第一战场

网线和水晶头是链路层最容易出问题的地方，而且问题非常隐蔽。比如水晶头压线时没有把线芯顶到底，插上去当时能用，过一段时间热胀冷缩，某根线芯接触变差，就开始间歇性闪断。再比如屏蔽线如果接地不良，反而会比非屏蔽线更容易引入噪声。

我的处理习惯是准备一根已知良好的成品网线，直接把原设备两端断开，用这根线重新连一次，观察一两个小时。如果故障消失，问题基本在老线缆上。如果故障还在，再往交换机端口和网卡接口方向查。

还有一种细节：网线插到网口里后，用手轻轻晃动一下尾巴，看网口灯会不会闪动或熄灭。会的话，要么是水晶头弹片不行了，要么是网口内部的金属弹片疲劳了。这个动作基本两三秒就能判断，比任何工具都直观。

2.2 协商速率与信道宽度：为什么好好的 2.5G 变成 100M

“网卡被限制在百兆”是热搜词里出现频率很高的问题。很多人以为是网卡坏了，实际上多数情况是线缆质量问题。

百兆只使用 1、2、3、6 四根线芯，千兆及以上需要 4、5、7、8 也全部连通。四对线中任何一对断开或接触不良，网卡就自动降到百兆。如果连百兆都不稳定，会继续降到 10M。

用测线仪能直接看出线序通断，但很多现场没有测线仪。更实用的办法是让网卡固定在全双工千兆模式下强制协商，看是否报错——不过这有风险，链路对端也必须支持千兆，否则直接不通。日常使用中，我更推荐先换一根质量合格的六类成品线做交叉测试。

无线网络也有个类似概念叫“信道宽度”，指的是 Wi-Fi 在 20MHz、40MHz、80MHz 之间选择信道带宽。2.4G 频段如果强制 40MHz 带宽，和隔壁 AP 干扰时反而会频繁掉线；改成 20MHz 后虽然理论速率降了，但连接却更稳定。很多“家里只有某个 WiFi 掉线，其他 WiFi 正常”的问题，就是信道宽度和干扰导致的，跟网卡本身关系不大。

顺便提醒一句：如果用过网卡监听模式做抓包，结束之后一定要把网卡切回正常的 managed 模式。不少“网卡突然没网”的诡异故障，其实是网卡还停在监听模式，系统协议栈根本没在收包。

2.3 网卡硬件和固件的“慢性病”

确实有一部分掉线是网卡硬件的问题，但不是所有问题都表现为“芯片坏了”。我在热搜词里看到 RTL8125、YT6801、Dell R730 网卡驱动下载，这些都是典型场景。

Realtek RTL8125 这类 2.5G 网卡，前期有些批次的固件在 Windows 驱动下会有随机断流问题，表现就是所谓的“掉网卡”，重启后恢复。排查时不要急着退货，先去官网更新到最新驱动，然后把驱动设置里的“环保以太网”和“绿色以太网”相关选项全部关掉再观察。

Dell R730 这类服务器网卡，驱动不是越新越好。服务器厂商的定制网卡驱动往往和 iDRAC、固件版本联动，最好从服务器厂商官网支持页面下载对应系统版本驱动，而不是直接去芯片厂商下公版。我用公版驱动取代 OEM 驱动后出过兼容性问题，回滚才恢复。

OCP 网卡、FPGA 网卡这类专业板卡也有自己的“慢性病”。OCP 卡散热片小、紧贴交换机风道路径，机房温度高时很容易过热降速甚至断链。FPGA 网卡则对 PCIe 链路和中断处理敏感，测速程序跑满时握手异常，看起来像是网卡掉线，实际是 PCIe 链路进入降速或复位。

给个判断硬件问题的简单方法：做一次持续打流测试。用 iperf3 或本地大文件拷贝，跑十几分钟以上。如果故障只在打流过程中出现，硬件性能问题的可能性大；如果故障跟负载无关，而是定时出现，那更要怀疑电源管理、调度或外部链路。

3. 驱动与电源管理：真正让网卡“假死”的重灾区

如果说硬件层是“第一背锅侠”，那电源管理就是“隐藏真凶”。我遇到过太多案例，故障表现一模一样，重启就好；机房的人直接换网卡，换完还掉；最后定位到电源管理策略，关掉之后机器几年都没再掉过线。

3.1 Windows 网卡的“允许计算机关闭此设备以节约电源”

Windows 下几乎所有网卡驱动程序都自带一个选项：设备管理器 → 网络适配器 → 找到对应网卡 → 属性 → 电源管理 → “允许计算机关闭此设备以节约电源”，默认勾选。

这个选项的想法很好：网卡空闲时让系统把设备切到低功耗状态，省电。但在服务器、NAS、长时间远程办公的机器上，它带来的问题远大于省下的那点电。设备在低功耗状态下切换回满速运行需要时间，驱动稍有兼容性问题，切换过程就直接掉了。

处理方式很简单：把网卡驱动属性里的这个勾取消掉。如果是笔记本、台式机，把“电源计划”里的 PCI Express 链接状态电源管理也一并改为“关闭”。

3.2 Windows 11 没有电源管理选项？三个替代办法

热搜词里有一条“win11 网卡没有电源管理选项”。很多人在 Windows 11 的设备管理器里翻半天，发现网卡属性里根本没有“电源管理”这个标签页。这不是系统坏了，而是这个选项在部分驱动和硬件组合下根本不显示。

替代办法有三条：

• 在“控制面板 → 电源选项 → 更改计划设置 → 更改高级电源设置”里，找到“PCI Express → 链接状态电源管理”，改成“关闭”。
• 对无线网卡，在“设置 → 系统 → 电源 → 网络连接”里，把“使用电池时保持网络连接”调整一下；这套设置在不同 Windows 版本的路径不太一样，关键词是“网络连接”和“电源”。
• 如果以上都找不到，可以改注册表：在HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4d36e972-e325-11ce-bfc1-08002be10318}下找到对应该网卡的子项，右侧新建 DWORD 值PnPCapabilities，数据填24，然后重启。这个值对应的就是“不允许系统关闭该设备以节约电源”。

注册表方式有风险，操作前先备份网卡的驱动设置项，或记下子项路径，避免改错了系统启动后找不到网卡。

3.3 Linux 下的 ASPM、WOL 和节能参数

Linux 下也有同类的坑。现代的笔记本和服务器主板默认开启 PCIe ASPM（活动状态电源管理），网卡在 PCIe 链路上会进入低功耗状态。问题在于，很多 Linux 发行版的默认内核参数并没有针对特定网卡做兼容性适配。

排查时一条条看：

# 查看网卡当前协商状态和节能特性 ethtool eth0 ethtool --show-eee eth0

如果 EEE 支持是启用的，可以试着关闭：

ethtool --set-eee eth0 eee off

还需要检查 WOL（网络唤醒）的设置。很多设备在关机状态依然保持着网络唤醒的侦听能力，这也会影响一些驱动在运行时的电源状态判断：

ethtool -s eth0 wol d

如果问题依旧，可以在 grub 内核参数里临时加pcie_aspm=off试试。注意这不是长期最优解，但能快速判断问题是否真的由 PCIe 电源管理引起。

3.4 无线网卡：连接某个 WiFi 掉线，换一个正常

“连接某一个特定的 WiFi 掉网卡，连接其他 WiFi 正常”——这是无线网卡场景里非常典型的情况。它的原因通常不是网卡坏了，而是这个 AP 让你不想吐槽吗？

• AP 所在信道的干扰太大，尤其在 2.4G 频段；
• AP 开启了 802.11 省电模式，客户端驱动对省电帧处理不好；
• AP 的加密方式或认证协议与网卡驱动兼容性差，比如 Wi-Fi 6 的某些特性协同有问题；
• 这个 WiFi 本身做了频段限制，比如固定在某个 DFS 信道，客户端雷达检测后切换频率失败。

Windows 下可以打开无线网卡的高级属性，找到“首选频段”设为“仅 5GHz”或“仅 2.4GHz”，把“漫游灵敏度”调低。更重要的是，换一个信道干扰最少的 SSID 做交叉测试，确认到底是“只对这个 AP 掉线”还是“对所有 Wi-Fi 都掉”。

4. 系统配置与域控环境：掉线之后，系统自己背了一半锅

有一类故障最容易被误解：网卡显示“已连接但无法访问互联网”，或者是网络隔一段时间断一次，重启就好了。这类问题排查时，很多人盯着网卡和驱动，实际上问题出在系统的 IP 配置、DNS 配置和路由表上。系统层面的配置错误，会让网卡看起来像在“掉线重连”。

4.1 DNS 配置错了，为什么表现成掉线

一个常见的场景：内网机器 ping 网关能通，ping 域名偶尔通偶尔不通，业务系统报“网络断开”。实际上链路一直正常，只是 DNS 解析超时，应用层以为掉线了。

如果网卡的 DNS 指向配置成了不可达的 IP，系统解析每个域名都要等超时，表现出来就是网页打不开、远程连接中断、过一阵子自动恢复。尤其是服务器配置了多个 DNS 服务器，第一个超时时间很长，第二个又不通，整体体验就是“网络频繁掉线”。

排查时先做两个小动作：

# Windows ipconfig /all # 看 DNS 服务器地址是不是可达、是不是正确 # Linux cat /etc/resolv.conf

然后直接解析一个常用域名看耗时：

nslookup example.com

解析耗时超过几秒甚至超时，说明 DNS 配置大概率有问题。

4.2 DHCP 租约、静态 IP 冲突和“重启才恢复”

还有一种非常隐蔽的“掉线”：DHCP 分配的租约快到期了，续租请求失败，网络连着连着突然失效。重启机器后重新获得地址，网络恢复，所以给人“重启就好”的印象。

检查方法很直接：看网卡获取到的 IP 租约时间。Windows 下执行ipconfig /all，找“租约获取时间”和“租约过期时间”；Linux 看 DHCP 客户端日志或/run/systemd/netif/leases/下的租约文件。

如果租约时间很短，比如几分钟到半小时，建议在 DHCP 服务端把租约时间调长，或直接给服务器配置静态 IP。另一个更麻烦的问题是 IP 地址冲突：两个设备配了同一个 IP，后上线的设备把前一个挤掉线。Windows 右下角会弹“网络地址冲突”，但有些版本弹窗一闪而过。用arp -a查看网关 MAC 是否频繁变化，能辅助判断。

4.3 AD 域内三台 DC 的 DNS 到底怎么配

“ad 域内 3 台 dc 域控制器，dc 的网卡 dns 应该如何配置”也是热搜词里出现的问题。这个配置如果错了，域控之间复制会失败，客户端加域、登录、组策略下发都会出问题，看起来就像“网络断断续续”。

先说结论：域控的 DNS 配置不能随意指。每台域控既要能解析其他域控的 SRV 记录，又要避免 DNS 递归查询形成死循环。

在三台 DC 的场景下，推荐做成循环交叉指向：

如果把所有域控都指向自己，会因为 DNS 服务还没完全起来或服务故障，导致解析失败。如果把三个都指向同一台 DC，那这台 DC 就是单点，它一挂，域内 DNS 全挂。

单台 DC 的情况下，一般把首选 DNS 设为本机静态 IP，备用 DNS 可为空，或指向公共服务 DNS 以做外部解析兜底。注意不要把外部公共 DNS 直接写进域控网卡，否则 SRV 记录解析会跑到外部去，域内查询直接出错。

4.4 Rocky、麒麟这类 Linux 的开机自启与多 IP 配置

Linux 发行版里，网卡开机自启是个老生常谈的问题。热搜词里既有“rocky linux 网卡文件”，也有“麒麟 v10 命令重启后为什么网卡不启动”，这些都是同一个坑。

Rocky Linux 这类 RHEL 系发行版，传统网卡配置文件在/etc/sysconfig/network-scripts/ifcfg-<接口名>。很多人在里面写好了 IP、掩码、网关，但忘了关键一行：

ONBOOT=yes

如果这行是no，重启后网卡不会自动加载配置，表现为“开机后没有网络”，得手动 up 一下才有。麒麟 V10 也是基于类似体系，排查时先执行：

systemctl status NetworkManager nmcli device status

看管理工具是否正常，再检查 ifcfg-* 文件中的ONBOOT参数。

还有“麒麟 v10 一个网卡设置多个 IP”的需求，这种场景在 RHEL 系下有两种做法。一种是在 ifcfg 文件里追加：

IPADDR2=192.168.10.2 PREFIX2=24

另一种是用 NetworkManager 直接加：

nmcli con mod eth0 +ipv4.addresses 192.168.10.2/24 nmcli con up eth0

修改后记得验证：

ip addr show eth0

4.5 Windows 多网卡怎么设定顺序

热搜词里还有一条“win10 多网卡怎么设定顺序”。多网卡机器同时连着无线和有线，系统会自己选一个默认网卡，选错就会出现“网络时通时断、业务系统连不上”的诡异现象。

Windows 里网卡优先级由路由的接口跃点决定。在“网络连接 → 网卡属性 → IPv4 → 高级 → IP 设置”里可以手动设置“接口跃点数”。数值越小优先级越高。比如有线网卡设为 10，无线网卡设为 20，系统会优先走有线。

用 PowerShell 也能改：

Get-NetIPInterface | Where-Object {$_.InterfaceAlias -like "*以太网*"} | Set-NetIPInterface -InterfaceMetric 10

改完直接看路由表确认：

route print -4

5. 虚拟化与专业网卡：在这些环境下“没有网卡”才是常态

虚拟化场景下的掉线重连，又完全换了一套逻辑。物理机上的网卡是好用的，但虚拟机里经常“找不到网卡”“网卡驱动装不上”，或者双网卡跨网段半天不通。这类问题换硬件没有意义，得从虚拟交换机、虚拟网卡型号和路由表入手。

5.1 VMware 虚拟机新装完找不到网卡

VMware 里新建虚拟机，装完 Windows 后发现没有网络，设备管理器里网卡名字可能带感叹号，甚至完全看不到网卡。

最常见的原因是虚拟网卡型号太新，客户机系统本身没有带驱动。VMware 默认给 Windows 虚拟机用的是 VMXNET3，性能确实好，但 Windows 安装镜像里没自带这个驱动，装完系统自然不认。最简单的办法是把虚拟网卡临时改成 e1000e：

• 关机后在虚拟机设置里把网络适配器类型改成“e1000e”；
• 开机确认网络通了；
• 再安装 VMware Tools，让 VMXNET3 驱动装上；
• 再关机改回 VMXNET3。

如果安装完系统后连修改网卡型号这一步都没反应，还要检查“网络适配器”前面的“已连接”和“启动时连接”两个复选框有没有勾上。这是虚拟机设置里最容易被忽略的点。

5.2 VirtualBox 找不到网卡的排查

VirtualBox 的问题通常不在虚拟机内部，而在主机侧的虚拟网络配置。装了 VirtualBox 但虚拟机里没有网卡，先别急着装系统里的驱动，按顺序查：

• VirtualBox 的“主机网络管理器”里是不是有可用的 Host-Only 网络；
• 虚拟机设置的“网络”里是否选择了正确的“连接方式”，比如“桥接网卡”；
• 桥接模式时，名称是否选对了真实物理网卡；
• Windows 主机上是否安装了 VirtualBox 扩展包，桥接驱动是否被安全软件禁用。

我见过有人把桥接网卡选到了“VirtualBox Host-Only Ethernet Adapter”，结果虚拟机里一会儿通一会儿不通，因为选的根本不是上联物理网络。

5.3 Ubuntu 下 USB 网卡和板载网卡跨网段互通

热搜词里有一条“ubuntu22.04 实现 usb 网卡和板载网卡有限不同网段互通”。这个问题的难点其实不在网卡掉线，而在路由策略。

假设板载网卡 eth0 接的是 192.168.1.0/24，USB 网卡 usb0 接的是 192.168.2.0/24，目标是让两个网段内的设备都能通过这台 Ubuntu 互通。最基本的配置是给两张网卡分别设置静态 IP：

network: version: 2 ethernets: eth0: addresses: - 192.168.1.20/24 routes: - to: default via: 192.168.1.1 usb0: addresses: - 192.168.2.20/24

然后开启 IP 转发：

sudo sysctl -w net.ipv4.ip_forward=1

但要注意：两个网段如果都要访问外网，默认网关只有一个。如果两张网卡同时获得默认路由，系统可能从错误的出口转发数据，表现就是“网络通一下断一下”。这时候要有策略路由：

ip rule add from 192.168.2.0/24 lookup 100 ip route add default via 192.168.2.1 dev usb0 table 100

在服务器上做跨网段转发，还要考虑防火墙放行规则，否则包到了但被内核防火墙丢弃，看起来也是“掉线重连”。

5.4 服务器专用网卡：OCP、FPGA 网卡和测速/延时

Dell R730 这类服务器上常见 OCP 网卡，Intel 或 Broadcom 芯片都有。OCP 卡出问题时，另一个容易忽略的因素是散热。OCP 槽位离 CPU 和硬盘背板都很近，机箱风道稍有不足，网卡芯片温度一高就自动降速。用ethtool -S看温度信息能发现端倪，但很多 crd 驱动不直接报告温度，只能通过持续打流观察掉线时间点来佐证。

FPGA 网卡更特殊，比如热搜词里的“xmda 325t pcie 网卡”和“fpga 网卡测速程序”。这类卡更多用于数据面开发，驱动、固件和高层应用往往是配套的。测速时发现连接中断，很多时候不是网络链路问题，而是 PCIe 带宽不足或中断绑定不对。跑测速程序之前，先用lspci -vvv确认 PCIe 链路协商速度和带宽，再调整网卡队列数量和中断绑定。

“linux 网卡增加延时”也是测试场景里常用的手段。用tc给网卡增加模拟延迟，便于复现应用层面的超时表现：

sudo tc qdisc add dev eth0 root netem delay 100ms

这个工具和问题定位不冲突，反而能帮你验证“掉线重连”是真实链路断开，还是应用层响应超时。

6. 遇到掉线重连，我的一套四步定位流程

这部分直接给可执行的顺序。不管你是运维工程师还是个人用户，按这个顺序走一遍，绝大多数“掉线重连”都能缩小到具体原因。

6.1 先记数据，再动硬件

我的习惯永远是：先记录故障时间、故障表现、网络速率、系统日志时间戳，然后再动手。没有数据支撑的排查就是猜。

一个最简单的故障记录样例：

记录三天后一对比，如果故障总在固定时段或固定负载下出现，原因范围缩小得非常快。

6.2 Windows 与 Linux 各看什么日志

Windows 下打开“事件查看器”，重点看“系统”日志，时间范围对齐故障时间。网卡驱动、WLAN 自动配置、DNS 客户端事件都会在这里留痕。与其截图给厂商猜，不如直接把这段时间的系统日志导出来，按来源分组看一下。

Linux 下也是同样思路：

journalctl --since "今天 03:00" --until "今天 04:00" -u NetworkManager -u systemd-networkd dmesg -T | grep -i -E "eth|link|error|down"

dmesg里如果出现“link is down”和“link is up”的成对输出，物理链路大概率有瞬断；如果只有网卡驱动报错，没有链路状态变化，则更像驱动层问题。

抓关键数据：

ip -s link show eth0 ethtool eth0

ip -s会显示接收和发送的丢包、错误计数。如果错误计数持续增长，物理层信号质量就有问题；如果计数不涨但实际业务断断续续，问题更可能在协议栈或上层。

6.3 抓包：物理链路断与协议超时的区别

很多人判断掉线就靠“ping 不通了”，但 ping 只能告诉你“不通”，不能告诉你“哪一段断了”。抓包是区分物理链路问题和协议问题的最有效手段。

Windows 下可以用 Wireshark，Linux 下直接 tcpdump：

sudo tcpdump -i eth0 -c 100

如果 tcpdump 在“不通”期间完全没有任何帧出来，说明网卡的接收侧已经收不到数据，物理链路或对端可能有问题。如果 tcpdump 能抓到持续的 ARP 请求、TCP 重传、DHCP 续约失败，说明链路是通的，只是三层以上在反复消耗连接。

还可以做一个 MTU 测试。有时候“掉线重连”其实是 MTU 不匹配导致的：

# Windows ping -f -l 1472 192.168.1.1 # Linux ping -M do -s 1472 192.168.1.1

如果数据包超过 1472 就不通，说明链路上有 MTU 限制，大包全部需要分片或丢弃，表现为文件传输或视频通话掉线。

6.4 替换法：怎么换才不是瞎换

替换法是排查硬件故障最朴素也最有效的方法，但要守规矩：一次只换一件，换完观察，确认无效再换下一件。

顺序可以是：

1. 换网线，用一根人品好的成品线；
2. 换交换机端口，避开端口弹片老化；
3. 更新或回滚网卡驱动，驱动版本造成的掉线时常见；
4. 换网卡硬件，这步放到最后。

很多人一上来就换网卡，换完无用又换交换机，最后发现是驱动没更新。需求单上多写几行日志，比多换几次硬件强得多。

6.5 一个让我印象深刻的排障案例

最后说个真实的案例。有台服务器报“每个小时掉线一次，重启就好”，换了两次网卡后依旧。我去现场时没有直接动硬件，先把故障时间点对齐到系统日志，发现每次掉线前网卡驱动都记录了一条关于节能状态的警告。接着进驱动高级设置，把“环保以太网”和“绿色以太网”全部关闭，再顺手把 Windows 电源计划里的 PCIe 链接状态电源管理改成关闭。机器跑了三个月，这个故障再没出现过。

掉线重连这件事，很多时候不是网卡不努力，而是它周围的电源、驱动、线缆、配置全在跟它捣乱。如果只留一条经验，我建议大家先记录故障时间点，再检查电源管理和 DNS 配置，最后才轮到换硬件。这套顺序帮我少跑了太多冤枉路，分享出来希望也对你有用。