Slow VPS Network? Test Speed with Speedtest and Bidirectional MTR

Your VPS plan lists a bandwidth limit, but a download is much slower. Is the server capped, the route congested, the test endpoint busy, or the measurement being read incorrectly? Use Speedtest to measure throughput to selected endpoints, then use MTR from both ends to investigate the path. These tools answer different questions and work best together.

Scope: Linux VPS commands, with client-side guidance for Linux, macOS and Windows. Replace all example addresses and server IDs. Addresses in this article are documentation placeholders, not TudCloud test targets.

1. Check units and traffic direction first

Network plans normally use Mbps or Gbps: bits per second. Download applications often display MB/s or MiB/s: bytes per second. Divide Mbps by eight for the theoretical decimal MB/s equivalent, before protocol overhead.

Network rate	Theoretical decimal transfer rate
100 Mbps	12.5 MB/s
500 Mbps	62.5 MB/s
1 Gbps	125 MB/s

A 100 Mbps service transferring at about 11 MB/s is very different from one transferring at 11 Mbps. Also check whether your plan has different inbound and outbound limits, a monthly traffic allowance, or a reduced rate after that allowance is used. A virtual NIC reporting a high link speed does not establish your purchased bandwidth entitlement.

When Speedtest runs on the VPS, Download means test server → VPS, and Upload means VPS → test server. A customer downloading a file from your website primarily consumes the VPS’s outbound capacity. Running Speedtest on your laptop instead measures the laptop’s connection to the chosen test server—not directly to your VPS.

2. Install the correct Speedtest client

This guide uses Ookla Speedtest CLI, whose command is speedtest. The Python project commonly called speedtest-cli is a different program with different flags. Check what is already installed:

command -v speedtest
speedtest --version
speedtest --help

Use the installation instructions for your supported platform on Ookla’s CLI download page. The following repository setup follows the Ookla package repository, but downloads the setup script for review before executing it.

Ubuntu or Debian

sudo apt update
sudo apt install curl ca-certificates
curl -fsSLo /tmp/ookla-speedtest-repo.sh https://packagecloud.io/install/repositories/ookla/speedtest-cli/script.deb.sh
less /tmp/ookla-speedtest-repo.sh
sudo bash /tmp/ookla-speedtest-repo.sh
sudo apt install speedtest

Supported RPM-based distributions

sudo dnf install curl ca-certificates
curl -fsSLo /tmp/ookla-speedtest-repo.sh https://packagecloud.io/install/repositories/ookla/speedtest-cli/script.rpm.sh
less /tmp/ookla-speedtest-repo.sh
sudo bash /tmp/ookla-speedtest-repo.sh
sudo dnf install speedtest

Press q to leave less after reviewing the script. Repository support varies by OS release and CPU architecture. If your release is unsupported, use an appropriate official standalone build rather than forcing another distribution’s repository. If a package conflict occurs, identify the existing client before removing it. On first launch, read the displayed license/privacy terms and proceed only if your use is permitted.

3. Run a controlled throughput test

Pause optional backups and transfers, note any VPN/proxy, and use a quiet interval. A throughput test deliberately consumes bandwidth and traffic allowance; do not run an endless loop on a production service.

date -u +%FT%TZ
speedtest
speedtest --servers

Start with automatic selection, then select a real ID from the list for a repeatable comparison. Replace 12345 below. Choose at least one nearby endpoint and another on a different operator; include the affected region when an appropriate endpoint is available.

speedtest --server-id=12345
speedtest --server-id=12345 --format=json > speedtest-result.json

Each invocation performs a new test. The JSON command does not export the preceding run. Save timestamps, endpoint IDs, download/upload results and any reported packet loss. Keep raw JSON units in mind: do not assume every bandwidth field is already Mbps; consult your installed client’s manual before converting or graphing it.

Run two or three spaced samples rather than reporting only the best result. Compare peak and off-peak periods using the same endpoints. A fast nearby test demonstrates available throughput on that particular path at that time; it does not guarantee throughput to every ISP. A slow single endpoint can also be limited by that endpoint itself.

File transfers and Speedtest may use different connection counts and protocols. Long round-trip times, TCP behavior, application limits, encryption CPU cost and storage performance can all make a real transfer slower. If you need an exact A-to-B throughput experiment, a separately controlled iperf3 test between machines you manage is more appropriate than assuming a public Speedtest endpoint represents that path.

4. Install MTR and identify both endpoints

# Ubuntu / Debian
sudo apt update
sudo apt install mtr-tiny

# AlmaLinux / Rocky Linux and other compatible RPM systems
sudo dnf install mtr

# macOS, if Homebrew is already installed
brew install mtr

Run only the installation section for your OS. On Windows, a trusted WinMTR build can collect an ICMP report; export text after at least 100 samples. WSL can run Linux tools, but its additional virtual networking may affect observations. Record which environment produced the report.

Call the affected client A and the VPS B. Use the VPS’s actual public IP, not a hostname proxied by a CDN. For the reverse test, establish A’s public address from its router or ISP information. A private LAN address such as 192.168.x.x is not reachable from the VPS.

5. Collect A → B and B → A reports

On the affected client A, replace the example address with the VPS IP:

date -u +%FT%TZ
sudo mtr -4 -n -r -w -c 100 -i 1 203.0.113.10 | tee mtr-client-to-vps.txt

On the VPS B, replace the example address with the client’s reachable public IP:

date -u +%FT%TZ
sudo mtr -4 -n -r -w -c 100 -i 1 198.51.100.20 | tee mtr-vps-to-client.txt

Each report takes roughly two minutes including final waits. These options select IPv4, numeric addresses, report mode, wide output, 100 cycles and a one-second interval. Use -6 with actual IPv6 endpoints for a separate IPv6 comparison. Full option definitions are in the upstream MTR manual.

Collect both directions close together while the problem is occurring. Run a baseline before deliberately saturating the link with Speedtest; otherwise your test traffic can create queueing that was absent beforehand. A separately labeled under-load trace can be useful, but should not be mixed with the baseline.

Bidirectional does not mean one-way measurement. Each hop’s time includes the probe journey and its reply journey. Those replies can take another route. A reverse report originates at the other end; it is not the first report read backward, nor does it reveal every reply path.

What if the client is behind NAT or CGNAT?

The client’s public IP may terminate on a router or a shared carrier gateway rather than the computer. That device may not answer probes, so a reverse trace may stop before the intended client. This does not prove that the VPS cannot send normal response traffic to the client.

Use a reachable endpoint you control on the affected network, ask the ISP for a suitable test, or provide the available partial trace with its limitation stated. Do not disable the entire firewall to obtain a screenshot. A looking glass can add another vantage point, but only represents the network and source from which it runs.

6. Compare ICMP with a relevant TCP probe

If the problem involves an HTTPS service you control, test its listening port from A:

sudo mtr -4 -n -r -w -c 100 -i 1 --tcp -P 443 203.0.113.10 | tee mtr-client-to-vps-tcp443.txt

TCP probes can expose differences in filtering, but intermediate routers still generally send ICMP TTL-expired replies. TCP MTR does not measure HTTPS throughput or complete the application’s TLS transaction. For a reverse TCP test, A needs an appropriate reachable service; choosing port 443 on a home connection where nothing listens is not an equivalent test. State the protocol and port in every report.

7. Interpret loss and latency without blaming the wrong hop

Observation	Interpretation
An intermediate hop shows 70% loss, but later hops and the destination show 0%	Often probe-response rate limiting or deprioritization. This does not demonstrate 70% loss of forwarded application traffic.
One hop has high latency, but subsequent hops are fast	The router may answer diagnostic probes slowly while forwarding traffic normally.
Loss persists through later hops and the destination during application failures	Stronger evidence of a path problem, but reply-path loss and endpoint filtering still prevent precise fault attribution from MTR alone.
Several hops show ??? but the destination responds	Some routers do not answer these probes. The path still forwards traffic to the destination.
Destination loss is zero, but transfers are slow	MTR probes do not saturate the connection. Capacity limits, TCP behavior or application bottlenecks can still exist.

Loss% is the fraction of unanswered probes at that row. Avg is average round-trip time; Wrst is the worst observed sample; StDev describes variation. A single worst sample is not a sustained latency level. Load balancing and route changes can also complicate hop-to-hop comparison. Never subtract adjacent hop averages and present the difference as a precise physical-link delay.

8. Send a support report that can be investigated

For a TudCloud support ticket, include the following privately. Do not post customer IPs or access credentials in public screenshots.

Service / VPS identifier:
Expected inbound and outbound rate:
Actual result, including Mbps or MB/s:
UTC start/end time:
Client ISP and public IP / VPS public IP:
IPv4 or IPv6:
VPN, Wi-Fi, CDN or proxy involved:
Speedtest client version and test server IDs:
Two or three timestamped Speedtest results:
Client-to-VPS MTR text report:
VPS-to-client MTR text report (or reachability limitation):
Probe protocol and TCP port, if used:
Affected application and reproduction steps:

Good measurements narrow the issue to a particular direction, time and path. They are more useful than a claim that “the line is slow” or a screenshot highlighting one intermediate router. If the network path looks healthy, continue with Linux VPS resource-pressure diagnosis and TCP connection and queue troubleshooting.