物理距离和线路质量决定了延迟下限，系统层面的优化主要用于缓解高负载下的拥堵，无法突破物理链路极限。

命令速用版

# 查看当前拥塞控制算法
sudo sysctl net.ipv4.tcp_congestion_control

# 开启 BBR（需要 Linux 内核 4.9+）
# 建议先临时生效测试，确认无误后再写入配置
sudo sysctl -w net.core.default_qdisc=fq
sudo sysctl -w net.ipv4.tcp_congestion_control=bbr

# 永久生效（避免重复追加，先检查是否存在）
if ! grep -q "net.core.default_qdisc=fq" /etc/sysctl.conf; then
  echo "net.core.default_qdisc=fq" | sudo tee -a /etc/sysctl.conf
fi
if ! grep -q "net.ipv4.tcp_congestion_control=bbr" /etc/sysctl.conf; then
  echo "net.ipv4.tcp_congestion_control=bbr" | sudo tee -a /etc/sysctl.conf
fi

# 测试延迟
ping -c 4 目标 IP

为什么会这样

甲骨文云免费 VPS 属于共享资源，尤其在亚太热门区域，晚间高峰期容易出现出口带宽拥堵。Linux 默认的 TCP 拥塞控制算法（如 CUBIC）在面对高丢包或高延迟链路时，可能不如 BBR 算法激进或平滑。优化本质是让系统更聪明地判断何时发送数据，减少排队等待时间，而不是增加物理带宽。

分步处理

1. 确认内核支持

执行 uname -r 查看内核版本。BBR 需要 4.9 及以上版本，甲骨文云默认镜像通常已满足。如果版本过低，不要强行编译内核，免费实例重置系统更方便。

2. 启用 BBR 拥塞控制

按上方命令速用版修改 /etc/sysctl.conf。修改后执行 sudo sysctl -p 生效。确认输出中包含 net.ipv4.tcp_congestion_control = bbr。使用 grep 检查后再追加可防止配置文件冗余。

3. 检查 MTU 设置（高风险）

甲骨文云虚拟化网络有时对 MTU 敏感。使用 ip link show 查看网卡 MTU。默认通常是 1500，如果遇到大包丢包，可尝试调整为 1460 或 1400 测试。

注意：修改 MTU 可能导致 SSH 连接中断。操作前请务必使用 tmux 或 screen 保持会话，并确保有控制台访问权限。公开资料中没有可靠数据表明固定值最优，需根据实际路由测试，测试无效请立即改回 1500。

怎么验证是否生效

1. 静态延迟测试

使用 ping 命令持续测试，观察平均延迟值。注意，BBR 主要改善的是吞吐量和高负载下的延迟，空闲 ping 值可能变化不大。

2. 负载下延迟测试

在使用 iperf3 或其他工具进行带宽测试的同时，开启另一个终端运行 ping。观察在带宽跑满时，ping 值是否出现剧烈跳动。优化后，延迟波动幅度（Jitter）通常会减小，丢包率可能降低。

3. 路由追踪

使用 mtr -rwC 100 目标 IP 查看中间节点丢包情况。如果丢包集中在甲骨文云内部或直连出口，系统优化效果有限；如果丢包在中间链路，BBR 可能有帮助。

4. 效果对比示例

记录优化前的最大延迟（max）和抖动（stddev），与优化后对比。例如在高负载下，若优化前延迟波动范围为 100ms-300ms，优化后可能稳定在 120ms-200ms 区间，虽平均延迟未必大幅下降，但网络稳定性会有所提升。

常见坑

1. 区域选择大于优化

免费实例不同区域网络质量差异巨大。如果亚太区延迟持续过高，更换到美西或美东区域可能比任何系统调优都有效，但需考虑物理距离带来的基础延迟增加。

2. 实例规格限制

免费 ARM 实例和 x86 实例的网络带宽上限不同，且受宿主机负载影响。不要期望通过软件优化突破实例规格的网络上限。

3. 过度调优风险

随意修改 TCP 缓冲区大小（如 net.ipv4.tcp_rmem）可能导致内存占用过高或连接不稳定。如果没有明确瓶颈，仅开启 BBR 即可，其他参数保持默认。

4. 网络 throttling

甲骨文云会对异常流量进行限速。如果短时间内产生大量连接或流量，可能会触发风控，导致网络暂时不可用，这与延迟优化无关，需注意使用频率。

5. 脚本使用谨慎

网上存在各类 BBR 一键脚本，使用前请确认脚本来源可信。手动配置虽然步骤稍多，但更可控且避免潜在的后门风险。