你的 VPS 为什么会被限制 CPU？一文讲清规则和常见"耗 CPU 大户"

老登 3093 字 · 约 8 分钟

适用于 BitsFlowCloud NOSLA 全系共享 VPS。完整规则与各配置阈值见 CPU 资源政策。

最近不少用户在工单里问：

  • “我就搭了个节点，怎么 CPU 被限制了？”
  • “我在 top 里看 CPU 明明不高，为什么说我超了？”
  • “被限制之后网速怎么也变慢了？”

这篇文章把 CPU 限制是怎么运作的、哪些使用方式容易让 CPU 升高，一次讲清楚。

先打个比方：共享 VPS 就像合租公寓的厨房

一台物理服务器（宿主机）上同时运行着很多用户的 VPS，大家共用这台机器的 CPU。

这就像合租公寓的厨房：谁都可以随时进去做饭，炒几个菜、煮一锅汤都没问题。但如果有人从早到晚一直占着所有灶台，其他人就没法做饭了。

我们的 CPU 规则就是这个厨房的"使用公约"：

  • 平时随便用：CPU 性能不打折，需要时可以跑满；
  • 短时间跑满没关系：装软件、编译个小项目、偶尔跑个脚本，都不会触发限制；
  • 只有长时间持续高负载，才会暂时"让出灶台"，也就是降低这台 VPS 的 CPU 性能。

需要长时间独占 CPU 的业务，比如视频转码、挖矿、长期大流量服务，应该选择独享 CPU 的 VDS 产品，不受本文规则限制。

一、系统是怎么"看" CPU 使用率的？

有四点和很多人的直觉不一样。

1. 高精度统计：直接读取宿主机的 CPU 时间

我们的统计不是在你的 VPS 里面"估算"出来的，而是直接读取宿主机内核为每台 VPS 记录的 CPU 使用时间。

  • 精度到纳秒级：宿主机内核精确记录你的 VPS 每一纳秒占用了多少 CPU，是累计值，不是某一瞬间的抽样；
  • 每分钟结算一次：用这一分钟的累计 CPU 时间计算平均使用率，两次统计之间哪怕只有几秒的尖峰，也都完整算进去，不会被"漏掉"或"放大"；
  • 看得见虚拟化层：包括宿主机为你这台 VPS 处理网络收发、磁盘读写所消耗的 CPU。这部分在 VPS 内部是看不到的。

因此，其他途径都无法保证这种精度，包括 VPS 内的 top、htop、面板监控、哪吒等各类探针，以及第三方监控服务。 它们只能从 VPS 内部观察：

  • 大多是定时抽样，每隔几秒甚至几十秒看一眼，两次抽样之间的波动看不到；
  • 数据来自虚拟机内部的系统计数，本身就有误差，而且看不到虚拟化层的开销；
  • 不同工具的计算口径不同，有的按单核算，有的按总核数算，同一时刻几个工具的读数往往都不一样。

所以，如果你的探针显示的 CPU 使用率和我们的统计有出入，这是正常的，以宿主机的统计为准。

2. 统计的是整台 VPS，不只是某个程序

除了你能在 top 里看到的程序，系统内核处理网络收发、磁盘读写、数据加解密所用的 CPU 也都算在内。

所以有时 top 里没有哪个进程特别高，但整机的 CPU 消耗其实不低。第三部分会详细说明这种情况。

3. 按所有核心平均计算

比如一台 2 核的 VPS，一个核心跑满、另一个核心空闲，计算结果是 50%。

4. 低负载完全不计

只要平均 CPU 使用率低于"忽略统计阈值"（不同配置约 22%～40%，见政策页表格），跑多久都不计入统计。日常建站、轻量服务、适度使用的代理，基本都在这个范围内。

二、什么情况下会被限制？

整个过程分三步，不是一超过某个数值就立刻限制：

第 1 步：观察
VPS 持续处于较高负载时，系统开始累计。短暂的峰值一般不会有影响。

第 2 步：确认
高负载累计到一定程度后，系统会再观察几分钟。如果这几分钟里负载降下来了，就不会限制。

第 3 步：限制
如果确认期间仍然是持续高负载，CPU 性能会被限制到：

  • 严格模式节点：15%
  • 宽松模式节点：30%

限制一直持续到当天 00:00 自动解除。

按公开规则，任何配置每天至少可以累计满负载运行 45 分钟，核心越多，这个时间越长。

⚠️ 被限制时，网络和磁盘也会变慢

这是虚拟化平台（VirtFusion）自身的机制：CPU 性能被压低后，磁盘读写和网络速度也会明显下降。所以很多用户最先察觉到的不是 CPU，而是"网速突然变慢了"。

反复触发的后果

情况 结果
滑动 48 小时内，连续 2 次被限制 暂停服务，可提交工单申请恢复
滑动 7 天（168 小时）内，连续 2 次因此被暂停 判定为 CPU 滥用，删除账号及其下所有 VPS

每天 00:00 的重置只解除当天的限制，不会清除 48 小时和 7 天窗口内的记录。

三、哪些情况容易让 CPU 升高？

常见"耗 CPU 大户"

场景 表现
被入侵、被植入挖矿程序 最常见。有陌生进程长期占满 CPU，常伴随陌生的定时任务或系统服务
“一键脚本"附带的后台任务 部分面板和脚本会常驻监控、测速、自动更新等后台进程
编译、视频转码、打包压缩、备份 天生就是持续满负载的工作
数据库慢查询、缺索引 网站访问量一大，数据库就把 CPU 吃满
程序死循环、崩溃后反复重启 程序有 bug，或者 Docker 容器不停重启
爬虫、压测、刷流量工具 长时间高并发
被攻击、被扫描 SSH 暴力破解、大量小包攻击，处理这些连接本身也要消耗 CPU

最容易被忽视的：加密代理在大流量时"很吃 CPU”

很多用户觉得代理只是"转发一下流量"，不怎么耗 CPU。其实不是这样。

加密代理的每一个字节都要经过加密和解密：

  • VLESS、Trojan 通常搭配 TLS 或 REALITY 使用。VLESS 协议本身不加密，加密由 TLS/REALITY 这一层完成，但这一步同样逐字节消耗 CPU；
  • VMess、Shadowsocks 协议自带加密；
  • Hysteria、TUIC（基于 QUIC/UDP）、WireGuard、OpenVPN 也都全程加密。

关键在于：CPU 消耗和流量大小成正比。

流量小的时候几乎感觉不到。但当你持续大流量上传或下载时，比如：

  • 看 4K 或 8K 视频
  • 下载大文件、BT/PT
  • 网盘同步、备份上传
  • 反复跑测速

加解密会让 CPU 一直处于高位。核心数少的套餐尤其明显。

协议选得轻，同样的网速更省 CPU

不同协议的设计和实现方式不同，传输同样的流量需要的 CPU 可能差很多。举一个同配置下的对比：

协议 单核跑到多少带宽 单核 CPU 状态
VLESS + REALITY 约 400 Mbps 已经打满
AnyTLS（anytls-go） 约 700 Mbps 仍未打满

以上为同一配置下的参考数据，实际数值会受 CPU 型号、客户端、系统版本、连接数等因素影响，仅用于说明差距的量级。

换个角度看：同样跑 400 Mbps，较重的协议已经把一个核心占满，较轻的协议还留有明显余量。 放到上面讲的统计规则里，前者更容易进入"持续高负载"，后者则可能一直留在"不计入统计"的范围内。

所以，协议轻不轻，对日常上网的普通用户同样有影响，并不只是"大流量用户才需要关心"：

  • 看高清视频、下载文件时，重协议的 CPU 占用会更早冲高；
  • 日积月累，重协议更容易累计到限制门槛；
  • 同样的套餐，换一个更轻量的协议，往往就能在不降低网速的前提下明显降低 CPU 占用。

以下几种情况会让消耗成倍增加：

  • 中转（relay）：流量进来要解密一次，出去再加密一次，同样的流量付出两倍的 CPU。
  • 多人共用一个节点：几个人同时看视频、下载，负载直接叠加。
  • 基于 UDP/QUIC 的协议（如 Hysteria、TUIC）：数据包更多、更碎，额外开销比 TCP 类协议大。
  • 大量小包、高并发连接：比如游戏加速、很多设备同时连接，每个包都要单独处理。

为什么 top 里看不出来？

加解密和网络收发大多在系统内核里完成，不一定显示为某个进程的 CPU 很高。它们通常体现在 top 第三行的这两项：

%Cpu(s):  5.0 us, 35.0 sy,  0.0 ni, 40.0 id,  0.0 wa,  0.0 hi, 20.0 si
                  ^^^^^^^                                      ^^^^^^^
                sy = 系统内核                             si = 软中断（网络收包）

如果大流量时 sy 和 si 明显偏高，CPU 大概率就消耗在网络和加解密上。前面说过，这部分同样计入你的 CPU 使用。

四、怎么避免被限制？

自查：看看 CPU 花在哪了

# 实时查看 CPU 占用（按 P 按 CPU 排序；注意第三行的 sy、si）
top

# 查看有没有陌生的定时任务
crontab -l
ls /etc/cron.d/

# 查看正在运行的服务，留意不认识的名字
systemctl list-units --type=service --state=running

发现不认识、占用又高的进程，先别急着删，可以提交工单，我们协助你判断。

代理用户的建议

  1. 优先选择更轻量的协议：同样的网速，轻量协议的 CPU 占用可能明显更低（见上文 REALITY 与 AnyTLS 的对比）；
  2. 给节点设置带宽上限，避免长时间满速跑大流量；
  3. 不要把节点分享给很多人，负载会叠加；
  4. 尽量避免多层中转，每多一层就多一次加解密；
  5. Shadowsocks 等可以选加密方式的协议，优先选 AES-GCM 系列（如 aes-128-gcm），绝大多数 CPU 对它有硬件加速；
  6. 流量需求本来就很大，比如长期下载、多人共享、做中转，建议直接选择 VDS（独享 CPU）。

确实需要长期高负载？

转码、编译、长期大流量服务这类业务，本来就不适合共享 VPS。选择 VDS 可以获得独享的 CPU，不受本文任何限制。

常见问题

Q：CPU 是不是被固定限制在 40% 了？
不是。触发限制之前，你可以使用 100% 的 CPU 性能。政策页里的 40% 这类数字是统计阈值，不是性能上限。

Q：我的探针 / top 显示 CPU 没那么高，为什么还是被限制了？
VPS 内部的工具只能定时抽样，而且看不到虚拟化层的开销，精度无法和宿主机内核的纳秒级累计统计相比。常见的情况是：探针每隔几秒抽样一次，刚好错过了负载高的时刻；或者 CPU 花在内核的网络收发、加解密上，某个进程的数值并不显眼。判定以宿主机的统计为准。

Q：被限制后要等多久？
当天 00:00 自动解除，不需要任何操作。

Q：被暂停了怎么办？
提交工单申请恢复。我们会顺便帮你排查一下，看是否有程序在你不知情的情况下持续占用 CPU，比如被植入的挖矿程序或脚本附带的后台任务。

Q：我只是搭了个节点自己用，也会被限制吗？
自己日常用（浏览网页、看视频、偶尔下载）一般不会。长时间满速跑大流量、多人共享或者做中转，就可能触发。可以参考第四部分的建议。

如有疑问，欢迎提交工单。我们希望每位用户都能清楚了解规则，在共享资源里各自用得顺畅。

相关文章