遇到这种情况，建议先暂时切换回默认的 CUBIC 算法观察，因为 BBR 的主要设计目标是提升吞吐量而非降低 ICMP 延迟，在某些网络环境下确实可能出现延迟波动。
先说结论：BBR 并不保证降低 Ping 值，若延迟敏感业务受影响，应优先恢复默认算法。
- 先定位：确认当前生效的拥塞控制算法是否为 BBR。
- 先做：临时切换回 CUBIC 算法对比测试。
- 再验证：通过长周期 Ping 和业务实际体验确认效果。
为什么会这样
BBR 是 Google 提出的 TCP 拥塞控制算法，核心目的是在高丢包或高延迟链路上最大化带宽利用率。它通过估算带宽和往返时间来控制发送速率，但这并不等同于降低 ICMP 协议的 Ping 值。
在某些场景下，BBR 可能会更积极地占用缓冲区，导致交互式小包的排队延迟增加。此外，Ubuntu 20.04 默认内核版本对 BBR 的支持虽然成熟，但若队列调度策略（qdisc）配置不当，也可能引发延迟波动。
实操步骤
1. 确认当前状态
执行以下命令，确认当前是否启用了 BBR：
sysctl net.ipv4.tcp_congestion_control如果返回 bbr，说明已生效。同时检查队列策略，BBR 通常建议配合 fq 使用：
sysctl net.core.default_qdisc2. 临时切换测试
为了不重启服务器，可以先临时切换回 CUBIC 观察 Ping 值变化：
sudo sysctl -w net.ipv4.tcp_congestion_control=cubic切换后立即进行 Ping 测试，对比之前的数值。
3. 永久配置修改
如果确认 CUBIC 更适合你的网络环境，需要修改配置文件永久生效。编辑 /etc/sysctl.conf：
net.core.default_qdisc=fq
net.ipv4.tcp_congestion_control=cubic保存后执行 sudo sysctl -p 加载配置。
怎么验证是否生效
修改完成后，再次执行 sysctl net.ipv4.tcp_congestion_control 确认返回值。同时使用 ping 命令对主要访问地域进行持续测试，建议使用 ping -c 100 -i 0.2 <目标 IP> 进行持续测试并观察平均延迟和抖动情况，测试时长建议至少 10 分钟。
还可以使用 ss -i 查看具体连接的内部状态，确认 TCP 栈行为是否符合预期。
常见坑
- 内核版本限制：BBR 需要 Linux 内核 4.9 及以上，Ubuntu 20.04 默认满足，但若自行降级内核需注意。
- 服务商限制：部分云服务商可能在底层网络做了限制，修改内核参数效果有限。
- MTU 问题：有时候延迟升高并非算法问题，而是 MTU 设置不当导致分片，建议检查网络接口 MTU 值。
- 盲目跟风：BBR 适合高带宽、高延迟或有一定丢包的场景，对于低延迟局域网或优质线路，默认算法可能更稳。