Quick answer: Test correctly before concluding: use iperf3 or a multi-connection download, because a single TCP stream over a long distance never fills a gigabit port — that is physics (latency × window), not a fault. Compare results to nearby and distant targets and check your own uplink; the plan's port speed is a ceiling, not a guarantee for one stream across the planet.
Overview
Most "slow network" reports are measurement artifacts: single-threaded tests, distant endpoints, busy local Wi-Fi or a VPN in the path. This guide produces numbers that actually mean something before you escalate.
Before you start
- SSH access to the server;
iperf3andmtrinstalled (apt install iperf3 mtr-tiny).
Step-by-step guide
- Test with parallel streams to a nearby public iperf3 server:
Run both directions; note the totals.iperf3 -c IPERF_SERVER -P 8 -t 20 iperf3 -c IPERF_SERVER -P 8 -t 20 -R - Compare single vs parallel: a big jump from
-P 1to-P 8confirms latency-limited TCP, not a port problem. - Check the path quality — loss ruins throughput:
See packet loss first steps if loss starts mid-path.mtr -rwzbc 100 TARGET_IP - Rule out your side: test from a wired connection without VPN; home Wi-Fi and ISP shaping cap many "server" complaints.
- Check the server is not busy: saturated CPU or disk I/O throttles network throughput too (CPU check).
Common issues
- Single-stream test to another continent: 100–300 Mbps on a 1G port is normal TCP behavior.
- Speedtest to a random far server: pick a geographically close target for meaningful numbers.
- VPN/proxy in the path: encrypts and reroutes — test without it.
- Peak-hour transit congestion: compare off-peak; persistent asymmetry is worth reporting.
When to contact support
If parallel-stream tests to nearby targets stay far below the plan port, and MTR shows a clean path, open a ticket with the iperf3 outputs (both directions), MTR both ways and test times — see how to report network issues.
Frequently asked questions
Why does one download never reach my full port speed?
Single TCP streams are limited by latency and window size, so one connection across a continent tops out far below a gigabit. Parallel streams (iperf3 -P 8) show the real capacity.
What evidence should a speed complaint include?
iperf3 results in both directions with parallel streams to a nearby target, MTR reports both ways, exact test times with timezone, and whether the client side was wired or on Wi-Fi.
Related articles
- How to troubleshoot slow network speed
- How to check traceroute / MTR
- Packet loss: first steps
- How to report network issues to support
Need a hand? Contact Cloud2Y support →
