一、问题现象h2

这台 Linux Mint 主机之前一直通过 Wi-Fi 上网，改接网线后，网络开始出现明显的不稳定。进一步对比发现：

• 单独使用 Wi-Fi 时正常，不丢包。
• 有线和 Wi-Fi 同时开启时，网络表面上基本正常。
• 只使用有线时，网页访问和 DNS 解析不稳定。
• 有线网卡与交换机成功协商到 2.5Gbps、全双工。
• 通过 2.5G 交换机连接时，无论 Ping 路由器还是 NAS 都会丢包。
• 同一块网卡直连路由器千兆口时，Ping 路由器和 NAS 均不丢包。

问题并不是“网线未连接”或“网卡未获取地址”，而是链路看起来已经正常建立，实际传输却存在严重丢包。

二、确认接口与路由h2

首先查看网络接口：

ip -br link
ip -br addr

本文中的有线网卡名称为：

enp7s0

不同设备上的接口名可能是 eno1、enp3s0 等，执行后续命令时应替换成自己的实际接口名。

使用 ethtool 检查链路协商状态：

sudo ethtool enp7s0

关键输出如下：

Speed: 2500Mb/s
Duplex: Full
Auto-negotiation: on
Link detected: yes

如果系统尚未安装 ethtool，可以执行：

sudo apt update
sudo apt install ethtool

有线连接最终能够正常获取 IPv4 地址：

IP 地址：192.168.5.63/24
网关：192.168.5.1
默认路由 metric：100

继续检查默认路由：

ip route
nmcli device status

Wi-Fi 默认路由的 metric 为 600，而有线默认路由的 metric 为 100。metric 越小优先级越高，因此两者同时开启时，系统实际上仍然优先使用有线连接，不能据此认定有线链路正常。

三、复现丢包h2

为了排除 Wi-Fi 对测试结果的干扰，先关闭 Wi-Fi，再测试有线连接。

Ping 本地网关：

ping -c 20 192.168.5.1

结果出现约 30% 丢包：

20 packets transmitted, 14 received
30% packet loss

Ping 公网 DNS 时更加严重：

ping -c 20 223.5.5.5

20 packets transmitted, 6 received
70% packet loss

域名解析也会间歇性失败：

ping: www.baidu.com: 名称或服务未知

这里的 DNS 错误只是底层链路丢包带来的结果，并不是根本原因。既然连同一网段的网关都无法稳定访问，就应先排查本地二层链路，而不是急着修改 DNS 配置。

最初测试时曾使用较短的 Ping 间隔：

ping -c 20 -i 0.2 192.168.5.1

一度怀疑是路由器限制了 ICMP 响应频率，但几组对照测试排除了这一可能：

• Wi-Fi 使用相同参数时不丢包。
• 有线连接 2.5G 交换机时丢包。
• 有线直连路由器千兆口时不丢包。

四、通过拓扑缩小范围h2

发生丢包时的网络拓扑如下：

Linux Mint 主板 2.5G 网口
└─ 2.5G 交换机
   ├─ 路由器
   └─ NAS

此时 Ping 路由器和 NAS 都会丢包。两个目标的共同路径只有：

Linux Mint 2.5G 网卡
└─ 网线
   └─ 2.5G 交换机端口

因此，公网、DNS 和路由器上联都不是优先怀疑对象，排查范围可以收敛到网卡、网线、交换机端口以及 2.5G 链路协商相关功能。

同一块网卡直连路由器千兆口后完全正常，也说明网卡并非简单的硬件损坏。问题更可能只在 2.5G 工作模式下触发，例如：

• 网线或交换机端口在 2.5G 下信号质量不佳。
• 网卡驱动与交换机存在兼容问题。
• EEE 等节能功能在链路两端配合异常。

实际排查时仍建议先更换网线和交换机端口。如果问题依旧，再检查网卡统计信息：

ip -s link show enp7s0
sudo ethtool -S enp7s0

重点关注 errors、dropped、CRC、超时和重传相关计数是否持续增长。不同网卡驱动提供的统计字段并不完全相同。

五、定位 EEE 兼容问题h2

EEE（Energy Efficient Ethernet）即节能以太网。链路空闲时，EEE 可以让设备进入低功耗状态；需要传输数据时，再从低功耗空闲状态恢复。

部分 2.5G 网卡与交换机组合在进入或退出低功耗状态时存在兼容问题。即使链路已经成功协商到 2.5Gbps，也可能出现间歇性丢包、延迟抖动或短暂断流。

先查看当前 EEE 状态：

sudo ethtool --show-eee enp7s0

然后临时关闭 EEE：

sudo ethtool --set-eee enp7s0 eee off

关闭后立即重新测试：

ping -c 20 192.168.5.1
ping -c 20 <NAS_IP>

测试结果如下：

• Ping 路由器不再丢包。
• Ping NAS 不再丢包。
• 网卡仍保持 2.5Gbps、全双工协商。
• DNS 解析和网页访问恢复正常。

结合“千兆直连正常、2.5G 交换机链路丢包、关闭 EEE 后立即恢复”三项对照结果，最终可以确认这是主板 2.5G 网卡与交换机之间的 EEE 兼容问题，而不是网卡硬件损坏。

如果 ethtool 提示网卡不支持 EEE 设置，则不能使用此方案，应继续检查网线、端口、驱动、固件以及网卡的 offload 功能。

六、让 NetworkManager 自动关闭 EEEh2

直接执行 ethtool 只对当前链路状态生效，重启系统或重新插拔网线后可能恢复默认设置。Linux Mint 使用 NetworkManager 管理网络，可以通过 Dispatcher 脚本在接口每次上线时自动关闭 EEE。

创建脚本：

sudo tee /etc/NetworkManager/dispatcher.d/90-disable-eee-enp7s0 >/dev/null <<'EOF'
#!/bin/sh

if [ "$1" = "enp7s0" ] && [ "$2" = "up" ]; then
    /usr/sbin/ethtool --set-eee enp7s0 eee off
fi
EOF

添加执行权限：

sudo chmod 755 /etc/NetworkManager/dispatcher.d/90-disable-eee-enp7s0

如果自己的网卡名称不是 enp7s0，需要同时修改脚本文件名、判断条件和 ethtool 命令中的接口名。

手动模拟接口上线，确认脚本可以执行：

sudo /etc/NetworkManager/dispatcher.d/90-disable-eee-enp7s0 enp7s0 up

检查 EEE 状态：

sudo ethtool --show-eee enp7s0

正常情况下会看到：

EEE status: disabled

输出中可能仍然包含：

Supported EEE link modes
Advertised EEE link modes

这些内容只表示网卡支持或能够通告哪些 EEE 模式，不代表 EEE 当前处于启用状态。实际状态以 EEE status 为准。

七、最终验证h2

永久配置不能只验证一次。重新插拔网线，等待有线连接恢复后再次检查：

sudo ethtool --show-eee enp7s0

结果仍然为：

EEE status: disabled

最后分别测试网关、NAS 和公网地址：

ping -c 50 192.168.5.1
ping -c 50 <NAS_IP>
ping -c 50 223.5.5.5

三组测试均不再丢包，说明 Dispatcher 脚本能够在有线连接重新上线时自动关闭 EEE，问题得到解决。

八、排障经验总结h2

遇到类似问题时，不要只看以下状态：

Link detected: yes
Speed: 2500Mb/s
Duplex: Full

它们只能证明物理链路已经完成协商，不能证明数据传输没有丢包。更有效的排查顺序是：

确认 IPv4 地址和默认路由
└─ Ping 本地网关
   └─ 对比 Wi-Fi 和有线
      └─ 对比千兆和 2.5G 链路
         └─ 更换网线和交换机端口
            └─ 检查错误计数
               └─ 关闭 EEE 测试
                  └─ 检查驱动、固件和 offload 功能

本次排障最关键的三个证据是：

直连路由器千兆口正常
连接 2.5G 交换机持续丢包
关闭 EEE 后立即恢复正常

最终解决方案是在每次有线接口上线时，自动关闭 enp7s0 的 EEE，同时保留 2.5Gbps 的链路速率。