@Livid 感谢
@cnbatch Rx Overflow 发生在交换设备的高速端口处，按理说只要交换机和端口上游（即 NAS 的网卡和系统）支持并启用（我使用的 ESXi 虚拟化方案和 CX4 网卡，应该都默认启用了），就可以暂停这条链路上的发送了。

启用后确实遏制了万兆口处 Rx Overflow 的进一步增长，但对速度的提升效果没预期那么好。有可能这个时候卡点变成了 AP 的无线链路本身，这里的 Flow Control 行为我就不太能控制了，Unifi App 里自己的 Flow Control 设置似乎是针对它家交换机的。

而且 802.3x 还有另外的副作用，就是会无差别暂停掉整个链路的发送，在多设备重负载场景下对链路稳定性有负面影响。这个特性行为简单，应该是用来减缓一些没有流控和完整性保证能力的简单协议的丢包的。像 TCP 这种传输层协议，最好还是传输层自己做流控的保证，选用合适的拥塞控制算法。

可能是 hairpin nat 配置不正确的问题

我在思考这个贴是不是应该移动到宽带症候群…
@Livid 合适的话 麻烦帮忙移动下

@titanium98118 亲测是不能完全解决的，问题的核心在发送方做合理的拥塞控制。更换 BBR 后我尝试关闭了链路层流控，此时也不会再大量出现 RX Overflow 的现象。也有可能是我链路上某些设备未能正确配置，但排查起来成本太高，不打算细究了。

单槽半高 没啥卡可选

节哀

问问那些做取证的公司吧，没有漏洞可利用的情况下想保留数据解锁是非常困难的

办卡早点去 小心排不到

至今理解不了 CentOS 和 RHEL 好在哪

我喜欢看 因为会有实时反馈 表情的信息量是很大的

EPYC Rome 的垃圾捡一套就行了 非常便宜

*像场

同样的相场 裁切不同….

在用 Mikrotik 的网关、TP-LINK 的交换机、Unifi 的 AP ，超级缝合怪

强迫伴焦虑 应该还有惊恐障碍

私企并不是不行，但是你这个不行

正在用 说不上特别好用 但也够用

利息只和利率和欠的钱有关，和还款方式无关

….问题依旧