Why Is Your VPS CPU Being Throttled? Rules and Common “CPU Hogs” Explained

Applies to all BitsFlowCloud NOSLA shared VPS plans. For full rules and configuration thresholds, see the CPU Resource Policy.

Recently, many users have asked in support tickets:

“I only set up a proxy node, why did my CPU get throttled?”
“My CPU usage looks low in top, why does it say I exceeded the limit?”
“Why did my network speed slow down after being throttled?”

This article clearly explains how CPU throttling works and which usage patterns tend to spike CPU load.

First, an Analogy: A Shared VPS Is Like a Kitchen in a Shared Apartment

A physical server (host node) runs many users’ VPS instances simultaneously, with everyone sharing the machine’s CPU.

It is just like a kitchen in a shared apartment: anyone can walk in and cook at any time—frying a few dishes or boiling a pot of soup is completely fine. However, if someone hogs every single burner from morning to night, nobody else can cook.

Our CPU policy serves as the “house rules” for this kitchen:

Unrestricted daily use: CPU performance is never artificially capped under normal circumstances; you can burst to 100% whenever needed;
Brief full loads are fine: Installing software, compiling small projects, or running occasional scripts will not trigger restrictions;
Only sustained, prolonged high loads will require a VPS to temporarily “step away from the stove”—meaning its CPU performance will be throttled.

Workloads that require continuous, dedicated CPU usage—such as video transcoding, crypto mining, or sustained heavy-traffic services—should opt for our VDS (Virtual Dedicated Server) plans, which feature dedicated CPU cores and are completely exempt from these rules.

1. How Does the System Measure CPU Usage?

There are four key points that differ from many people’s intuition:

1. High-Precision Tracking: Directly Measured from Host Kernel CPU Time

Our metrics are not “estimated” inside your VPS. Instead, they are read directly from the host kernel, which records CPU time for every individual VPS.

Nanosecond precision: The host kernel tracks exactly how much CPU time your VPS consumes down to the nanosecond. This is an accumulative metric, not an instantaneous snapshot;
Calculated minute by minute: Average utilization is computed using the cumulative CPU time over each minute. Even a spike lasting just a few seconds between checks is fully accounted for—neither missed nor artificially magnified;
Visibility into the virtualization layer: This includes CPU time spent by the host processing network I/O and disk I/O on behalf of your VPS. This overhead is invisible from inside the guest OS.

Consequently, no in-guest tool can match this accuracy—including top, htop, control panel metrics, Nezha (or other server probes), and third-party monitoring services. These tools can only observe from within the VPS:

Most rely on periodic sampling, checking every few seconds or tens of seconds, missing fluctuations between intervals;
Metrics originate from internal virtual machine counters, which inherently carry error margins and cannot see virtualization overhead;
Different tools calculate differently—some measure per core, others across all cores—meaning different tools often show conflicting readings at the exact same moment.

Therefore, if your probe reports CPU utilization different from our metrics, that is completely normal. The host system’s records are the definitive source of truth.

2. Whole-VPS Accounting, Not Just Individual Processes

Beyond the processes you see in top, CPU consumed by the kernel handling network I/O, disk I/O, and data encryption/decryption is also factored in.

Hence, even if no single process stands out in top, overall CPU usage may still be substantial. Section 3 covers this in detail.

3. Averaged Across All Cores

For example, on a 2-core VPS, if one core runs at 100% while the other is idle, the overall calculated usage is 50%.

4. Low Loads Are Completely Excluded

As long as average CPU utilization remains below the “Ignore Threshold” (roughly 22%–40% depending on the plan; see the policy table), it will never be counted toward throttling, regardless of duration. Everyday website hosting, lightweight services, and moderately used proxies generally stay well within this baseline.

2. Under What Conditions Is CPU Throttled?

The process involves three stages—throttling is never triggered instantly upon a momentary spike:

Step 1: Observation
When a VPS experiences sustained elevated load, the system starts accumulating high-usage time. Brief spikes generally have no impact.

Step 2: Confirmation
Once high load accumulates past a certain threshold, the system observes the instance for several more minutes. If load drops during this window, no throttling occurs.

Step 3: Throttling
If sustained high load persists throughout the confirmation period, CPU performance will be restricted to:

Strict Mode nodes: 15%
Relaxed Mode nodes: 30%

The throttle remains active until automatically lifted at 00:00 (midnight) daily.

Under our published policies, any plan is allowed at least 45 cumulative minutes of 100% load per day; plans with more cores allow for longer durations.

⚠️ Network and Disk Performance Degrade When Throttled

This is an inherent mechanism of the virtualization platform (VirtFusion): when CPU performance is capped, disk I/O and network throughput will drop noticeably. That is why many users first notice that their “network speed suddenly tanked” rather than noticing CPU throttling directly.

Consequences of Repeated Violations

Condition	Consequence
Throttled 2 consecutive times within a rolling 48-hour window	Service suspended; can be restored via support ticket
Suspended twice for this reason within a rolling 7-day (168-hour) window	Deemed CPU abuse; account and all associated VPS instances terminated

The daily 00:00 reset only clears the current day’s throttle; it does not clear violation records within the 48-hour and 7-day rolling windows.

3. What Typically Causes High CPU Usage?

Common “CPU Hogs”

Scenario	Symptoms / Description
Compromised / Cryptominer injected	Most common. Unfamiliar processes hogging 100% CPU, often accompanied by unknown cron jobs or system services
Background tasks bundled with “one-click scripts”	Certain panels and scripts leave persistent background daemons for monitoring, speed testing, or auto-updates
Compiling, video transcoding, compression/archiving, backups	Inherently sustained full-load tasks
Slow database queries / Missing indexes	Under traffic spikes, the database maxes out the CPU
Infinite loops / Crash-restart loops	Application bugs or Docker containers constantly crashing and restarting
Scrapers, stress testing, traffic generation tools	Prolonged high-concurrency operations
Under attack / Being scanned	SSH brute-force attacks or small-packet floods; processing these connections consumes CPU cycles

The Most Overlooked Culprit: Encrypted Proxies Under Heavy Traffic

Many users assume proxies “just forward traffic” and barely touch the CPU. This is a misconception.

Every single byte passing through an encrypted proxy must be encrypted and decrypted:

VLESS and Trojan are typically paired with TLS or REALITY. While VLESS itself does not encrypt, encryption is handled by the TLS/REALITY layer—which still consumes CPU byte by byte;
VMess and Shadowsocks feature built-in encryption;
Hysteria and TUIC (QUIC/UDP-based), as well as WireGuard and OpenVPN, are also fully encrypted end-to-end.

The key point: CPU usage scales linearly with traffic throughput.

Under light traffic, it is barely noticeable. However, during sustained high-throughput downloads or uploads, such as:

Streaming 4K or 8K video
Large file downloads / BitTorrent / PT
Cloud drive syncing or backup uploads
Running repeated speed tests

Encryption and decryption will keep CPU load consistently elevated. This is especially pronounced on low-core plans.

Lighter Protocols Deliver the Same Speed with Less CPU

Protocol architectures and implementations vary widely; the CPU required to transfer the same amount of data can differ significantly. Consider this benchmark on identical hardware:

Protocol	Single-Core Bandwidth	Single-Core CPU Status
VLESS + REALITY	~400 Mbps	100% Maxed Out
AnyTLS (anytls-go)	~700 Mbps	Not yet maxed out

The data above is for reference on identical configurations. Actual performance varies with CPU model, client implementation, OS version, connection count, etc., and is intended solely to illustrate the order of magnitude.

From another perspective: at the same 400 Mbps throughput, a heavier protocol fully saturates one core, while a lighter protocol leaves ample headroom. Under our monitoring rules, the former quickly drifts into “sustained high load,” while the latter may remain entirely below the “uncounted threshold.”

Therefore, protocol weight matters for regular everyday users too, not just extreme power users:

When streaming HD video or downloading files, heavy protocols hit high CPU usage much sooner;
Over time, heavy protocols accumulate towards throttling thresholds much faster;
On the same plan, switching to a lighter protocol often significantly cuts CPU usage without sacrificing speed.

The following scenarios multiply CPU consumption:

Relays / Forwarding: Inbound traffic is decrypted, then re-encrypted upon outbound—doubling the CPU cost for the exact same throughput.
Multiple users sharing one node: Concurrent streaming and downloading stacks the load directly.
UDP/QUIC-based protocols (e.g., Hysteria, TUIC): Produce a higher volume of smaller packets, creating more overhead than TCP-based alternatives.
High-concurrency / Small packet floods: Such as gaming accelerators or dozens of simultaneous client connections, where every packet requires discrete processing.

Why Doesn’t This Show Up in `top`?

Encryption/decryption and network I/O are largely executed within the system kernel, so they may not show up as a single high-CPU user process. Instead, they typically manifest on the third line of top:

%Cpu(s): 5.0 us, 35.0 sy, 0.0 ni, 40.0 id, 0.0 wa, 0.0 hi, 20.0 si
(where sy = System/Kernel, si = Softirq for network packet handling)

If sy and si are noticeably elevated during high-traffic periods, the CPU is almost certainly being consumed by network operations and encryption. As stated earlier, this overhead is fully counted towards your CPU usage.

4. How to Avoid Being Throttled?

Self-Check: Inspect Where CPU Cycles Go

Monitor CPU usage in real-time (Press ‘P’ to sort by CPU; check ‘sy’ and ‘si’ on line 3): top
Check for unauthorized or unfamiliar cron jobs: crontab -l and ls /etc/cron.d/
Review running services and look for unfamiliar names: systemctl list-units --type=service --state=running

If you spot an unfamiliar process with high CPU usage, don’t rush to delete it—feel free to open a ticket, and we can help you assess it.

Recommendations for Proxy Users

Prefer lighter protocols: For identical throughput, lightweight protocols can require significantly less CPU (see the REALITY vs. AnyTLS comparison above);
Set a bandwidth limit on your node to prevent prolonged full-speed saturation;
Avoid sharing a node with many people, as concurrent loads aggregate;
Minimize multi-hop relays, since every hop adds another layer of encryption and decryption;
For protocols with selectable ciphers (e.g., Shadowsocks), prefer AES-GCM ciphers (such as aes-128-gcm), as almost all modern CPUs feature dedicated hardware acceleration;
If you genuinely have high-throughput demands—such as continuous downloading, multi-user sharing, or relaying—we strongly recommend choosing a VDS (Dedicated CPU).

Do You Truly Need Sustained High Load?

Workloads like video transcoding, compilation, and sustained high-bandwidth applications are fundamentally unsuited for shared VPS hosting. Choosing a VDS grants you dedicated CPU cores free from any restrictions mentioned in this article.

Frequently Asked Questions (FAQ)

Q: Is my CPU permanently capped at 40%?
No. Before triggering any throttle, you have access to 100% of CPU performance. Numbers like 40% in our policy pages represent the statistical threshold, not a performance ceiling.

Q: Why was I throttled when my probe / top showed low CPU usage?
In-guest tools rely on periodic sampling and cannot see virtualization layer overhead; their precision cannot match the host kernel’s nanosecond cumulative tracking. Typical causes include: the probe sampled every few seconds and missed short spikes; or CPU time was consumed by kernel network I/O and encryption, which doesn’t stand out under any single process. Enforcement is strictly based on host-level metrics.

Q: How long does the throttle last?
It is automatically lifted at 00:00 (midnight) daily without requiring any manual action.

Q: What should I do if my VPS is suspended?
Submit a support ticket to request restoration. We will also help inspect your instance to identify whether any background processes—such as injected miners or hidden tasks bundled with scripts—are consuming CPU without your knowledge.

Q: I only run a personal proxy node. Will I get throttled?
Normal personal usage (web browsing, streaming video, occasional downloads) will generally never trigger limits. However, prolonged full-speed saturation, sharing with multiple users, or running relays might. Please review the recommendations in Section 4.

If you have any questions, feel free to open a ticket. We want every customer to clearly understand the rules so everyone can enjoy a smooth experience on shared resources.