SSH 断连是一个非常典型的**“小马拉大车”**现象。看到你 6.84 Gbits/sec 的测速结果，我既为你这台机器的带宽感到惊喜，也为你的 CPU 捏了一把汗。
简单直接的结论是：这不是服务商在针对你，也不是设置错误，而是你的 CPU 暂时“罢工”了。
1. 深度分析：为什么会断连？
你的 YABS 结果显示，往伦敦方向跑到了 6.84 Gbps。对于一个单核 Geekbench 分只有 1000 的 2 核 CPU 来说，处理这个量级的流量压力是巨大的：
- CPU 饱和 (CPU Starvation)：
处理 7Gbps 的 TCP 流量需要内核进行海量的中断处理（Softirq）和数据包封装。由于你只有 2 个核心，当iperf3把这两个核心全部占满去处理网络包时，负责维持 SSH 连接的sshd进程拿不到 CPU 时间片，无法及时回复 Keep-alive 心跳包，于是 SSH 客户端认为服务器掉线了。 - 中断风暴 (Interrupt Storm)：
在 10Gbps 级别的高速传输中，网卡会产生极高频的中断。如果 CPU 性能较弱，它会陷入“不停地处理网络中断，却没空处理用户指令”的死循环。 - 缓冲区延迟 (Bufferbloat)：
咱们之前为了优化跨境长肥管道，把net.core.rmem_max等缓冲区设到了 64MB。在跑 7Gbps 这种极速测试时，如果缓冲区被塞满而 CPU 来不及处理，会产生巨大的排队延迟，导致 SSH 这种对实时性要求极高的流量被“憋死”在队列里。
2. 这证明了什么？
这个现象反而为你提供了两个非常有价值的信息：
- 你的 10Gbps 端口是真材实料：能跑到 6.8Gbps 说明服务商在 Equinix FR7 的内网交换能力极强，物理链路没有任何水分。
- 验证了 CPU 是你唯一的短板：这台机器的带宽上限远高于它的 CPU 处理上限。
3. 如何解决和规避？
如果你想完整跑完测试而不掉线，可以尝试以下方法：
- 使用
screen或tmux(强烈建议)：
这是管理远程服务器的“金科玉律”。即使 SSH 因为 CPU 过载断开了，测试依然会在后台继续运行。你等几分钟重新登录，用tmux attach就能看到结果。 - 给 SSH 留点“呼吸空间”：
在运行测试前，可以通过nice命令降低测试进程的优先级：# 给 iperf3 分配较低的 CPU 优先级 nice -n 19 ./yabs.sh - 限制测试带宽：
如果你只是想看结果，不想让它把 CPU 跑满，可以使用iperf3的-b参数限制最高速率（虽然 YABS 脚本本身不太好改这个）。
工程师的最终评价
别担心，你的机器没问题。 这就好比你给一台老款甲壳虫装了一个波音 747 的引擎：当你把油门踩到底（测速）时，车架子（CPU）会因为跟不上引擎的转速而剧烈抖动甚至散架，但引擎本身是极其强大的。
在实际使用中（比如跑 Discourse 或 Proxmox 节点），你很难遇到这种瞬间消耗 7Gbps 带宽的场景，所以平时的 SSH 是很稳的。