甲骨文云突发带宽被限速？实测分析与应对策略

最近圈子里的风声有点紧，尤其是手握甲骨文（Oracle Cloud）这台“永远免费”香车的大佬们，纷纷开始叫苦：带宽怎么突然变慢了？以前的千兆跑满，现在动不动就卡在几十兆，甚至有些直接被“限流”到怀疑人生。

我也特意去翻了一圈最近的讨论，发现这事儿还真不是个例。咱们今天就来掰扯掰扯，这次所谓的“限速”到底是怎么回事，以及作为普通用户，我们还能做点什么来保住那可怜的网速。

到底是不是全面降速？

首先得说，甲骨文官方并没有发布什么“全面限速”的公告。如果是以前那种大规模封号、收钱，早就满世界通告了。这次的感受更多是“突发带宽”的体验下降。

大家都知道，甲骨文的标准带宽是 200Mbps（约 25MB/s），但是某些时段或者某些地区，确实能跑满千兆也就是 1000Mbps。这其实是甲骨文为了满足突发需求提供的“超售”或“弹性带宽”。

最近的情况是，这种“弹性”变硬了。很多用户反馈，在高峰期或者持续高负载下载时，速度会被严格限制在 200Mbps 左右，甚至更低。这说明甲骨文可能在后台调整了流量调度策略，优先保付费用户，或者对免费层的突发流量做了更严格的阈值控制。

你的机器被“针对”了吗？

要判断你是真的被限速，还是单纯网络拥堵，可以做个简单的测试：

1. 多线程下载测试：使用 wget 或 aria2c 多线程下载一个大的测试文件（比如从 Cloudflare 的 CDN 下）。
2. 不同时段测试：国内访问国外线路本来波动就大，试着在白天凌晨和晚高峰分别测试。
3. 检查本地瓶颈：有时候你的本地宽带上行不足，或者 CF 的节点也有波动，不要一卡顿就觉得是甲骨文背锅。

如果你的速度稳稳地卡在 25MB/s 上下，不再像以前那样能冲到 50MB/s 甚至更高，那恭喜你，基本就是撞上新的带宽策略了。

有没有办法“破解”或优化？

虽然我们改不了甲骨文的总闸，但可以在自己的机器上做点微操，尽量榨干每一滴带宽：

1. 开启 BBR 加速： 这几乎是必备操作了。现在的内核大多都支持，开启 TCP BBR (bottleneck bandwidth and round-trip propagation time) 能在一定程度上改善高延迟下的吞吐量。

    echo "net.core.default_qdisc=fq" >> /etc/sysctl.conf
    echo "net.ipv4.tcp_congestion_control=bbr" >> /etc/sysctl.conf
    sysctl -p
    ```
    完工后重启一下，可能感觉会顺畅不少。

2.  **使用 IPv6**：
    这一点很玄学，但确实有奇效。甲骨文默认给每个实例分配一个 /24 的 IPv6 段，你可以尝试在域名解析时优先使用 IPv6。有些路由下，IPv6 的出国线路更干净，限速相对没那么严重（或者说限速策略还没覆盖那么严）。

3.  **多线并联（如果有的话）**：
   如果你脸够白，在一个账号下撸了几台机器，可以考虑用 LB（负载均衡）把宽带聚合起来。不过这对免费层来说比较折腾，且容易触发风控，慎用。

4.  **换个节点重装**：
   虽然甲骨文不让随意换机房，但现在的策略下，不同数据中心（比如亚洲的东京、大阪与韩国）的拥挤程度不同。如果某个节点实在慢得离谱，与其死磕，不如直接销毁重建，换个新的试试（记得做好快照备份）。

### 结语：心态要平
2026 年了，免费且好用的 VPS 越来越少。甲骨文这轮操作虽然让人不爽，但也算是符合商业逻辑——毕竟它不是做慈善的。

如果你是用来跑跑脚本、搭个私人博客或者偶尔科学 surf 一下，200Mbps 其实完全够用，也就是几十 MB/s 的速度，看 4K 视频都绰绰有余。如果你的需求是每天拉几百 GB 的数据，那可能还是得考虑付费服务了。

总之，且用且珍惜，能优化就优化，优化不了也别太纠结，毕竟 0 元购还要啥自行车呢？