tech

3条命令解决跨境VPS卡成狗的问题，亲测有效

📅 2026/7/22 👁️ 1 阅读 ✏️ 2026/7/22 更新

3条命令解决跨境VPS卡成狗的问题，亲测有效

1Gbps的海外VPS实测只有110kbps？不是机器烂，是TCP拥塞算法cubic在跨境链路上反复降速。3步开启BBR，网速直接飙到20Mbps+。

我买了一台海外 VPS，用来跑一些需要访问外网的服务。

商家标的是 1Gbps 端口，听起来很够用。

结果实际体验很离谱：

  • 打开 Google 要等半天

  • YouTube 1080P 卡成 PPT

  • 服务能连上，但速度慢到怀疑人生

    • 我先用 Fast.com 测了一下。

    结果只有：110kbps。

    110kbps 是什么概念？差不多是 2005 年拨号上网的体验。

    这篇记录一下完整排查过程。如果你的 VPS 也是"配置看着不差，但实际网速很慢"，可以按这个思路先查一遍。

    一、先判断：是不是 VPS 本身太烂

    遇到网速慢，第一反应不要直接改参数。

    先确认一件事：到底是 VPS 本身带宽不行，还是你到 VPS 的链路不行。

    我先在 VPS 上测了两个东西。

    1. 测 VPS 到 Google 的连接时间

    bash
    # 测试延迟
ping -c 4 www.google.com

# 测试网页响应时间
curl -o /dev/null -s -w "Time Connect: %{time_connect}
Time TTFB: %{time_starttransfer}
Total Time: %{time_total}
" https://www.google.com

    结果里 Total Time 大概是 0.05s。

    这说明 VPS 访问 Google 本身没问题。换句话说，Google 没慢，VPS 出去也没慢。

    ping测试结果

    2. 测 VPS 自己的带宽上限

    然后继续测 VPS 出口带宽：

    bash
    wget -O speedtest-cli https://raw.githubusercontent.com/sivel/speedtest-cli/master/speedtest.py
chmod +x speedtest-cli
./speedtest-cli

    结果能跑到 300Mbps+。

    这说明 VPS 自身带宽也不是瓶颈。

    speedtest测速结果

    到这里基本可以判断：

    问题不在 VPS 本身，而在我访问 VPS 这条链路上。

    二、定位问题：cubic 在跨境链路上拖了后腿

    接下来我查了一下 TCP 拥塞控制算法：

    bash
    sysctl net.ipv4.tcp_congestion_control

    输出是：

    text
    net.ipv4.tcp_congestion_control = cubic

    问题大概率就在这里。

    cubic 是传统的 TCP 拥塞控制算法。 它的核心逻辑比较保守：一旦检测到丢包，就认为网络拥塞，然后立刻降速。

    这个逻辑在普通网络里没问题。但跨境链路经常有高延迟、抖动、偶发丢包。cubic 会把这些丢包当成拥塞信号，于是反复减速。

    最后表现就是：VPS 明明带宽不差，但你实际用起来只有几百 kbps。

    三、解决思路：把 cubic 换成 BBR

    BBR 是 Google 提出的 TCP 拥塞控制算法。

    它和 cubic 最大的区别是：cubic 主要看丢包，BBR 主要看带宽和延迟。

    所以在跨境、高延迟、偶发丢包的链路上，BBR 经常比 cubic 更适合。

    这次我的处理方式很简单：

  • 升级内核

  • 开启 BBR

  • 再用 Fast.com 验证网速

    • 注意一下：BBR 从 Linux 4.9 起可用。

    我这台机器是 CentOS 7，默认内核太老，所以这里升级到了 5.4.225。如果你的系统已经是新内核，不一定需要照抄升级内核这一步。

    四、第1步：升级内核

    我这里用的是 5.4 LTS 内核：

    bash
    # 下载内核
wget --no-check-certificate https://mirrors.coreix.net/elrepo-archive-archive/kernel/el7/x86_64/RPMS/kernel-lt-5.4.225-1.el7.elrepo.x86_64.rpm

# 安装
yum localinstall -y kernel-lt-5.4.225-1.el7.elrepo.x86_64.rpm

# 设为默认启动内核
grub2-set-default 0 && grub2-mkconfig -o /boot/grub2/grub.cfg

    然后重启：

    bash
    reboot

    重启后确认内核版本：

    bash
    uname -r

    我这里确认已经变成了 5.4.225。

    五、第2步：开启 BBR

    重启完成后，执行这 3 条命令：

    bash
    echo "net.core.default_qdisc=fq" >> /etc/sysctl.conf
echo "net.ipv4.tcp_congestion_control=bbr" >> /etc/sysctl.conf
sysctl -p

    然后再确认一次：

    bash
    sysctl net.ipv4.tcp_congestion_control

    如果输出里看到 bbr，就说明已经生效。

    这一步真正改的是 TCP 拥塞控制算法。简单理解：让系统用 BBR 来控制 TCP 发包节奏。

    六、第3步：用 Fast.com 验证效果

    最后回到 Fast.com 再测一次。

    结果从 110kbps 变成了 20Mbps+。

    Fast.com测速结果

    这个提升非常明显。体感上也一样：

  • Google 打开变快了

  • YouTube 1080P 不再卡

  • 4K 基本也能看

    • 七、为什么 BBR 能提速这么多

    一句话解释：BBR 不会因为偶发丢包就立刻怂。

    cubic 更像是：

    看到丢包，就先降速保命。

    BBR 更像是：

    我先估算这条链路真实能跑多快，再按这个速度发。

    它会持续测量两个关键指标：

  • Bottleneck Bandwidth：瓶颈带宽

  • Round-trip propagation time：往返传播时间

    • 所以 BBR 的全称是：Bottleneck Bandwidth and Round-trip propagation time

    在跨境链路这种"不是带宽不够，而是链路质量不稳定"的场景里，BBR 往往能把速度拉回来。

    八、最终效果

    | 指标 | 开 BBR 前 | 开 BBR 后 |
    |------|-----------|-----------|
    | Fast.com 测速 | 110kbps | 20Mbps+ |
    | YouTube 1080P | 卡顿 | 流畅 |
    | YouTube 4K | 不用想 | 基本可以 |

    这次的问题本质不是 VPS 太差。而是：VPS 带宽没问题，但跨境链路在 cubic 下跑不起来。

    如果你也遇到类似情况，可以按这个顺序排查：

  • 先在 VPS 上测目标站响应时间

  • 再测 VPS 自身出口带宽

  • 最后看 TCP 拥塞控制是不是 cubic

    • 如果前两项都正常，而当前算法还是 cubic，那么可以试试开启 BBR。

    很多时候，网速慢不一定是机器不行。可能只是一个 TCP 参数没调对。

    💬 评论区 (0)

    0/500

    暂无评论，快来抢沙发吧！