KpyVPS

Menu

Kpy
Published on 2026-11-09 / 1 Visits
0
0

How to Test VPS Bandwidth

#Ping#BBR#VPS Tutorial

Introduction

You just bought a new VPS, and the plan page says “1 Gbps bandwidth.” Great — but is that what you’re actually getting? Or maybe your VPS has been feeling slower lately and you want numbers instead of guesses. Either way, what you need is a proper VPS bandwidth test. This guide walks through three ways to run one — a speed test CLI, iperf3, and real-world downloads — and, more importantly, how to read the results without fooling yourself.

First, Know What You’re Testing: Bandwidth vs. Latency

Bandwidth and latency are different measurements that get mixed up constantly. Bandwidth is how much data can flow per second, measured in Mbps. Latency is how long the first byte takes to arrive, measured in milliseconds. A VPS can have excellent bandwidth and still feel sluggish in daily use if its latency is poor — latency has its own benchmarks and its own numbers to watch, which we covered in “What Is Good Latency? Realistic Numbers by Use Case.” This article is about the bandwidth side of the picture.

One trap to disarm before running anything: the Mbps vs. MB/s unit gap. Providers label bandwidth in megabits (Mbps); download tools report megabytes (MB/s). One byte equals eight bits, so 100 Mbps tops out around 12.5 MB/s. If you “only” see 12 MB/s on a 100 Mbps line, that’s not a problem — that’s arithmetic.

Method 1: Speed Test CLI — the Five-Minute Check

The quickest way to get a VPS speed test done is Ookla’s official CLI. Install it, run one command, get upload and download numbers:

# Debian / Ubuntu
curl -s https://packagecloud.io/install/repositories/ookla/speedtest-cli/script.deb.sh | sudo bash
sudo apt install speedtest 

# Run the test
speedtest 

Two caveats before you trust the output:

  • The CLI picks the nearest test server by default. That measures your VPS to some nearby datacenter — not to your users. Use speedtest -L to list nearby servers and speedtest -s <server_id> to pick one in the region your users actually live in.

  • Peak hours matter. Bandwidth on shared links gets crowded in the evening. Run the same test at different times of day before drawing any conclusions.

Method 2: iperf3 — Point-to-Point Throughput

iperf3 does exactly one thing: push as much traffic as possible between two endpoints and report the throughput. That focus makes it the honest way to measure raw VPS network speed — but you need a second machine with decent bandwidth on the other end (another VPS, or a server you control elsewhere).

# On the second machine (receiver)
iperf3 -s 

# On your VPS (sender) — tests upload direction
iperf3 -c <receiver_ip> 

# Add -R to test the download direction instead
iperf3 -c <receiver_ip> -R 

# Single stream not saturating the link? Try multi-stream
iperf3 -c <receiver_ip> -P 4 

Run both directions. Asymmetric results (fast one way, slow the other) are common and worth knowing about.

Method 3: Real-World Downloads

The third method skips synthetic tools entirely: download a large file from a well-connected mirror and watch the speed.

curl -o /dev/null https://<mirror-host>/<large-test-file> 

This measures what a user downloading from your VPS actually experiences, including the mirror’s own limits — so test against more than one source before blaming your line.

Reading the Results Without Fooling Yourself

Three rules for interpreting any VPS bandwidth test:

  • Convert units first. Mbps ÷ 8 = MB/s. Half of all “my VPS is slow” complaints dissolve at this step.

  • Cross-check with the right tool. Speed test CLI is a quick health check, iperf3 is raw point-to-point throughput, real downloads are what users feel. When the three disagree, trust the one closest to your actual use case.

  • No test hits 100% of the labeled number. Protocol overhead, routing distance, and peak-hour contention all take a bite. Occasional double-digit dips during evening hours on shared plans are normal; consistently poor results at off-peak hours, in the direction your users care about, are the real warning sign — that’s when it’s time to open a support ticket.

One practical note: full-speed tests burn real traffic. A handful of 1 Gbps tests can chew through gigabytes in minutes, and if your plan has a monthly traffic cap, that comes out of your allowance. Heavy-testing workloads are exactly what unmetered plans are for — VMRack’s unlimited-traffic cloud servers are one example of that product line.

Conclusion

A VPS bandwidth test isn’t one number from one tool — it’s three tools used together, run more than once, at more than one time of day, compared in the right units. Use the speed test CLI for a quick check, iperf3 for raw throughput, and real downloads for what users actually experience. And if the numbers all hold up but the VPS still feels slow, bandwidth probably isn’t your problem — that’s when you look at latency, or at TCP congestion control such as BBR, which we covered in “How to Enable BBR on Your VPS: Less Lag Without Upgrading.”

Thank you for reading to the end!

What Is Good Late...

Comment