千兆网卡只协商到百兆：四对线、自协商与连接器的分层排查

现象：先分清三种"百兆"

现场说"这个网口只有百兆"，实际往往是三件不同的事，排查方向也完全不同：

• 链路协商结果就是 100 Mb/s——物理层只跑到了百兆，属于本文讨论的范围；
• 协商显示 1000 Mb/s，但实测吞吐只有百兆量级——物理层没问题，瓶颈在主机侧（PCIe 插槽、中断、CPU 占用、卸载设置）；
• 链路在 1000 与 100 之间反复跳变——通常伴随误码，属于线缆、干扰或接地问题。

判定方法很简单：Windows 下用 PowerShell 执行 Get-NetAdapter | Format-Table Name,Status,LinkSpeed；Linux 下执行 ethtool eth0，看 Speed、Duplex、Supported link modes 三项；交换机侧再看一次端口速率与双工。如果网卡的 Supported link modes 里明确列着 1000baseT/Full，而当前 Speed 是 100Mb/s，那结论很清楚：设备有能力，是链路没协商上去，问题在物理层或协商过程，而不在网卡本身。

为什么千兆对线缆的要求比百兆严一档

要理解"为什么总是掉到 100M 而不是别的速率"，得先看 1000BASE-T（IEEE 802.3ab）和 100BASE-TX 在物理层的差别：

• 100BASE-TX 只用两对线：1-2 脚发送、3-6 脚接收，收发各占一对，方向是分开的。
• 1000BASE-T 用全部四对线：每一对线上都要同时双向收发——回波消除（echo cancellation）负责分离同一对线上方向相反的两个信号，近端串扰消除（NEXT）负责压制相邻线对之间的串扰；四对线各以 125 Mbaud 的符号速率工作，配合 PAM-5 电平编码与 4D 网格编码，合计承载 1000 Mb/s。
• 千兆是主从结构：链路两端分为 Master 和 Slave，Master 提供时钟源，Slave 从收到的信号里恢复时钟，再用于收发。谁做 Master 由自协商决定，不是随便哪端都行。
• 指标更严：标准的目标是在 Cat5 平衡电缆上、最长 100 m 范围内达到误码率不高于 10^-10。

这条差别直接决定了最典型的现场故障：4-5、7-8 这两对线断了、没压接、或者根本没接，链路照样能建立，只是自动落到 100BASE-TX。设备不会报错，用户只会感觉"变慢了"。需要说明的是，"降速回退"是多数商用 PHY 的常见行为，并非标准强制；也有实现会持续尝试千兆而干脆不建立链路。无论哪种表现，根源都在这两对线上。

工业现场还有一个更隐蔽的原因：M12 连接器的编码。D-coded 是 4 芯、2 对线，按设计只承载 10/100 Mb/s，是 PROFINET、EtherNet/IP 百兆段的常见选择；X-coded 是 8 芯、4 对线，内部用十字屏蔽隔开各线对，才支持千兆及更高速率。用 D-coded 的线缆和接口去接千兆端口，无论交换机多好都只能跑百兆——这不是故障，而是接口本身的能力上限。

原因树：四组可能

A. 物理介质不具备四对线能力

• A1 线缆只有 4 芯，或两端是 M12 D-coded 接口；
• A2 8 芯线但 4-5、7-8 线对断芯；水晶头只压了 1-2、3-6 四根；端子排只接了两对；
• A3 线对在端子排或接线柱处被拆开走线，双绞结构被破坏，串扰与回波损耗超出千兆可容忍范围，链路训练不通过；
• A4 长度超过 100 m、护套被压伤、弯折半径过小、连接器触点氧化。

B. 协商过程没有走到千兆

• B1 一端把 Speed & Duplex 固定为 100 Mb/s（Windows 驱动高级选项，或 Linux 下 ethtool -s 写死了 speed）；
• B2 链路中间夹着只能跑百兆的设备：百兆交换机、百兆规格的光电转换器或 PoE 注入器、百兆网络隔离器。端到端可用速率受每一段的能力限制，任一段只有百兆，整条路径就上不去（注意：千兆规格的 PoE 注入器不属于此类）；
• B3 在 10/100 速率段上，一端关闭了自协商，另一端只能做并行检测（parallel detection）：能匹配上速率，但无法判断双工能力，一律按半双工假设。千兆则无法通过并行检测建立——这正是千兆链路两端都必须开启自协商的原因；
• B4 主从冲突：两端都被手工强制成 master，或都强制成 slave，千兆链路无法建立；
• B5 千兆能力与主从种子值是通过自协商的 next page（消息页 + 未格式化页）交换的，base page 本身只覆盖 10/100 的能力位。两端只要有一端没能完成 next page 交换，千兆能力就没有被通告出去，链路只能在 10/100 之间挑选；

C. 电气与干扰

• C1 屏蔽层两端接地形成地环流，或网线与变频器输出、伺服动力线长距离并行敷设，误码率上升，千兆训练反复失败；
• C2 连接器、端子氧化或压接不实，接触电阻不稳定。

D. 主机侧（只影响吞吐，不影响协商速率）

• D1 PCIe 插槽代数或通道数不足、MSI-X 未启用、中断集中到单核、CPU 占用已满。这类问题下 ethtool 仍显示 1000 Mb/s，不要和协商问题混为一谈。

排查顺序

原则：从最便宜、最快能证伪的一层开始；先确认现象类型，再动物理层，最后才碰配置。特别提醒：不要一上来就把网卡钉死在 1000 Mb/s 全双工，那会掩盖真正的故障，还可能引入双工不匹配。

第 1 步：记录基线

Windows 用 Get-NetAdapter 记录 LinkSpeed；Linux 用 ethtool eth0 记录当前 Speed / Duplex / Auto-negotiation，以及 Supported link modes、Advertised link modes 是否包含 1000baseT/Full。同时看交换机侧端口速率与双工：一侧 1000 一侧 100，或一侧 full 一侧 half，基本就把问题锁定在中间链路或配置上了。

第 2 步：旁路中间链路

用一根确认良好的 Cat6 成品跳线，让工控机与交换机直接对接，跳过面板、端子排、延长线、光电转换器。如果此时协商到 1000 Mb/s，说明主机与交换机都没问题，问题在被跳过的那一段。反向验证同样有效：把这根可疑线缆接到另一台已知能跑千兆的机器上，如果那台也掉到 100 Mb/s，线缆或中间设备的问题就被锁定在这一段。

第 3 步：核对线对与连接器

• 用线缆测试仪做线序与线对测试，重点确认 4-5、7-8 是否导通、是否成对；
• 现场常见：8 芯电缆只用了 4 芯；端子排把同一对线拆到两个不相邻的端子；水晶头只压了 1-2、3-6；
• 核对 M12 编码：D-coded（4 芯）不可能跑千兆，要千兆必须换 X-coded（8 芯），线缆相应按 Cat6/Cat6A 选。

第 4 步：检查配置与中间设备

• Windows：设备管理器 → 网卡属性 → 高级 → Speed & Duplex，必须是 Auto Negotiation。以 Intel 以太网驱动为例，其驱动里并没有"1.0 Gbps 全双工"这个选项，设成 Auto Negotiation 才是得到千兆的正确做法；
• Linux：确认 Auto-negotiation: on，并检查 NetworkManager 或 systemd 网络单元没有写入固定 speed；需要恢复时执行 ethtool -s eth0 autoneg on；
• 千兆的主从角色交给自协商决定，两端都不要手工指定；
• 逐段确认链路里每一台设备的端口能力，尤其是工业交换机上的百兆口与光电转换器。

第 5 步：看误码计数

Linux 用 ethtool -S eth0 过滤 crc / align / err 等计数，配合 ip -s link show eth0；交换机侧看端口的 CRC、align 错误。判断要点：CRC、align 这类计数随时间持续增长，对物理层问题（线对、接头、干扰）指向性最强；而单纯的 err/drop 增长也可能来自拥塞、队列或主机侧。另外要交叉核对两端双工——如果一端 full、一端 half，全双工一侧同样会累积 FCS/CRC 错误，那属于协商配置问题而不是线缆问题。驱动支持时可用 ethtool --cable-test eth0 做 TDR 定位，不支持就上外部线缆测试仪。

第 6 步：排除干扰与接地

屏蔽层与接地按设备手册和现场等电位联结要求核查（工业现场对单端/双端接地、屏蔽层如何引入 PE 的做法并不统一，不要套用某一种接法当通用结论）；网线与动力线分开走线，不要让网线与变频器输出线并行捆扎。若链路在 1000 与 100 之间反复跳变，可以在测试中临时关闭 EEE（节能以太网）观察是否稳定——这只是缩小范围的试验手段，不是结论，稳定后仍应回到线缆与接地去处理根因。

第 7 步：区分吞吐问题

如果 Speed 已经是 1000Mb/s 而吞吐上不去，协商环节已经完成，此时瓶颈可能落在主机侧（PCIe 插槽代数与通道数、MSI-X 是否启用、CPU 单核占用、卸载设置）、对端设备，也可能是测试方法或存储/应用本身的限制。把这一类问题和协商问题分开，能省掉大量无效换线。

处置建议

1. 先修物理层，再动配置。四对线不通的链路，任何软件设置都换不来千兆。
2. 千兆链路保持自协商，两端都不要固定速率与双工。1000BASE-T 只有全双工一种形态，能力交换与主从确定都依赖自协商，手工固定成 1000 全双工的典型结果是链路干脆不建立，而不是"更快"。真正会出现双工不匹配的是 10/100 场景：一端强制 100 全双工、另一端自协商，自协商端走并行检测、按半双工处理，于是半双工侧报 late collisions、全双工侧报 FCS 错误，ping 通但吞吐塌陷，而且极难在现场靠经验判断。
3. 连接器按速率选型。100 Mb/s 段用 D-coded 足够；需要千兆就用 X-coded 8 芯，线缆按 Cat6/Cat6A 配。
4. 端子排接线保持线对完整。不要在接线柱处把一对线拆开走两个方向，双绞被破坏后千兆训练会不稳定甚至直接失败。
5. 把基线写进验收记录。两端协商速率、双工、误码计数、线缆型号与长度。下次"变慢"时才有对比依据。
6. 老线缆不要靠"再压一次水晶头"续命。Cat5e 在被踩踏、压伤、过度弯折之后掉回百兆，是现场"昨天还好今天只有百兆"最常见的原因，换一根成品跳线对比最快。

速查：按现象定位

常见误区

• "网卡不支持千兆"：先看 Supported link modes，里面有 1000baseT/Full 就说明支持，问题在链路。
• "把 Speed & Duplex 设成 1000 全双工能强制提速"：千兆依赖自协商完成能力交换与主从确定，手工固定通常直接导致链路不建立；而在 10/100 场景下强制一端全双工、另一端自协商，才会造成双工不匹配。
• "百兆只是慢一点，不影响业务"：对 GigE 相机、多路串口服务器这类持续流量场景，链路速率就是吞吐上限；但也要先确认瓶颈是否真在链路上，别把主机侧问题当成线缆问题。

一句话总结：百兆优先怀疑"少了两对线"，其次怀疑"没协商到千兆"，最后才怀疑网卡和驱动。按"记录基线 → 旁路链路 → 核对线对 → 检查配置 → 看误码 → 排干扰 → 分吞吐"的顺序走，绝大多数现场问题在前三步就能定位。