How to troubleshoot slow network speed

Quick answer: Work through the chain: (1) test with parallel streams (iperf3 -P 8) to rule out single-stream TCP limits, (2) check server load and disk, (3) measure latency and loss with MTR, (4) compare different endpoints to localize the slow segment. Most "slow network" cases turn out to be distance physics, an overloaded application, or the client's own line.

Overview

Throughput = window ÷ RTT: a single TCP stream physically cannot fill a 1G port across a 200 ms path unless windows are huge and loss is zero. Add disk bottlenecks, CPU steal, or a saturated home connection, and the network is often innocent. Methodical elimination beats guessing.

Before you start

• Define "slow" with a number: expected vs measured, which direction, single file or overall.
• Have speed-test tooling ready on the server (iperf3, wget) and know your port speed.

Step-by-step guide

1. Reproduce with parallel streams:

   iperf3 -c TARGET -P 8      # if -P 8 is fast but -P 1 is slow => latency, not capacity

2. Check the server isn't the bottleneck:

   uptime                      # load
   iostat -x 2 3               # disk busy? (sysstat package)
   top                         # CPU steal (st) on a busy host

3. Measure the path: mtr -rwc 100 TARGET — high RTT explains single-stream limits; loss explains stalls (see packet loss).
4. Triangulate: test to/from a second endpoint in another network. Slow everywhere = server side; slow from one ISP only = that path/client.
5. Check the application layer: TLS, PHP, database time dominate small-request latency — a fast port doesn't speed up a 900 ms backend response.

Common issues

• Single-stream over intercontinental path judged as "broken": 100–300 Mbps per stream at 200 ms RTT is expected; use CDN/parallelism for users far away.
• Client's own uplink: a 100 Mbps office line caps every test at 100 Mbps regardless of the server.
• Testing while backups run: nightly jobs eat the port — check vnstat -h for what else was flowing.

When to contact support

If multi-stream tests to close, well-connected endpoints stay far below port speed and the server itself is idle, send the evidence — commands, outputs, timestamps, endpoints.

Frequently asked questions

Why is a single download slow but parallel downloads fast?

TCP throughput per stream is limited by window size and round-trip time. Over long distances this is physics — CDNs and parallel streams are the fix.

How do I rule out the server itself?

Check uptime load, iostat for disk saturation and top for CPU steal. A busy server transfers slowly on any network.

What evidence should I collect before a ticket?

iperf3 results with -P 1 and -P 8, wget test-file speeds, MTR both directions, timestamps, and which endpoints you tested against.

Related articles

• How to test network speed
• How to troubleshoot packet loss
• What does a 1G / 10G / 20G port mean?
• How to report network issues to support

Need a hand? Contact Cloud2Y support →