Slow VPS Network Troubleshooting: Latency, Packet Loss & Bandwidth Guide.

When you say "my VPS network is slow," my first reaction isn't to go blame the provider.

Because I've seen too many "slow" problems that ultimately came down to: slow DNS resolution, the browser going through a proxy, the server CPU maxed out, wrong MTU, or even your home router acting up in the middle of the night.

I wrote this article with one goal: if you follow along, in at most 20-30 minutes you can narrow the problem down to one scope (local / VPS / datacenter link / destination site).

0. First Break Down "Slow": Where Exactly Are You Stuck?

A slow network is usually not one problem, but four kinds of problems mixed together:

Symptom	Common root cause	What you should check first
Opening a website takes a long time before loading starts	Slow DNS, slow TLS handshake, slow destination site	`dig` / `curl -w`
Spinning forever, occasionally opens	Packet loss, route flapping, evening peak congestion	`mtr`
Opens but downloads are slow	Insufficient bandwidth, single-thread throttling, unsuitable TCP congestion control	`iperf3` / `speedtest`
SSH lags, noticeable typing delay	High latency or jitter	`ping` / `mtr`

Once you determine which category it falls into, you won't go running in circles afterward.

1. Rule Out "It's Not the VPS's Problem" (Done in 5 Minutes)

I usually do two things first:

1.1 Is Your Local Network Stable

# 直接 ping 公共 DNS（看丢包和抖动）
ping -c 20 1.1.1.1
ping -c 20 8.8.8.8

If your local ping to the public internet already shows packet loss (say 2%-5%), then the "packet loss" you measure on the VPS afterward is very likely carried over from your side.

1.2 Did You Accidentally Go Through a Proxy

This one is too real: I've stepped on this myself.

A proxy extension installed in the browser
System-wide proxy enabled
SSH's ProxyCommand not turned off

You can roughly verify with this:

# 本机直连 VPS
ssh -v root@你的VPS_IP

If -v shows strange hops or proxies, turn off the proxy completely before testing.

2. Feel Like "Opening Is Slow"? Test DNS and Handshake First

2.1 Is DNS Resolution Slow

Run on the VPS:

# Debian/Ubuntu
sudo apt-get update && sudo apt-get install -y dnsutils

# 看解析时间
/usr/bin/time -f "DNS time: %e s" dig +tries=1 +time=2 google.com @1.1.1.1
/usr/bin/time -f "DNS time: %e s" dig +tries=1 +time=2 google.com @8.8.8.8

If dig is fast (tens of milliseconds) but opening websites is still slow, then DNS can basically be set aside.

Also take a look at your VPS's default DNS:

cat /etc/resolv.conf

Some providers stuff in strange DNS by default (even cross-continent ones); changing to 1.1.1.1 / 8.8.8.8 often shows immediate results.

2.2 Is the TLS/HTTP Handshake Slow

curl -o /dev/null -s -w "dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n" https://example.com

Look at these metrics:

High dns: DNS problem
High connect: link latency/packet loss/routing problem
High tls: slow handshake (sometimes retransmission caused by packet loss)
High ttfb: the other side's service is slow (not your VPS network)

3. The Most Common: Packet Loss / Route Flapping (One mtr Tells You)

3.1 ping Only Gives You a Rough Idea

ping -c 50 你的VPS_IP

Packet loss > 1%: you'll noticeably feel the lag
Large latency jitter: SSH will "stick keys," web pages will load fast then slow

3.2 mtr Is the Proper Localization Tool

Test from local to VPS:

# macOS
brew install mtr
sudo mtr -rwzc 200 你的VPS_IP

# Linux
sudo apt-get install -y mtr
sudo mtr -rwzc 200 你的VPS_IP

How to read it? I use a simple principle:

Packet loss starts at a certain hop and every hop after it also loses packets: most likely that segment of the link has a problem
A middle hop shows high packet loss but later hops don't: often that router just rate-limits ICMP, not necessarily real packet loss

If you find packet loss only happens during "evening peak," that's more like a congestion problem. At that point, what you can basically do is: change datacenter / change route / put on a CDN / change provider.

4. Bandwidth Not Maxed Out? Don't Rush to Say the Provider Is Faking It

Many people use a single speedtest, see only 20Mbps, and say "this VPS's bandwidth is no good."

But bandwidth tests are also easy to get wrong:

Single thread limited by TCP congestion
Test node too far away
What you're testing is "your bandwidth to the node," which is not equal to "your bandwidth to the whole world"

4.1 Run a Controlled Test with iperf3

You need an iperf3 server (could be another VPS of yours, or find a public speed test node).

On the server:

sudo apt-get install -y iperf3
iperf3 -s

On the client (your VPS or local machine):

# 单线程
iperf3 -c SERVER_IP -t 15

# 多线程（更接近真实下载）
iperf3 -c SERVER_IP -P 4 -t 15

If -P 4 suddenly goes from 50Mbps to 300Mbps, that means it's not that "bandwidth wasn't given," but that a single connection is limited (very common when link latency is high + packet loss).

4.2 Check Whether the VPS's Own CPU/IO Is Dragging It Down

# CPU、负载
uptime

# 网络吞吐实时
sudo apt-get install -y iftop
sudo iftop

# 磁盘 IO（网站慢也可能是 IO 慢）
sudo apt-get install -y iotop
sudo iotop

The most absurd case I've seen: the user complained about "slow network," but it turned out PHP was maxing out the CPU, page rendering was slow, and the browser looked like the network was slow.

5. A Very Sneaky Pitfall: Wrong MTU Makes HTTPS/Downloads Act Weird

The symptoms are usually:

Small files are fine
As soon as packets get a bit larger, it stalls
Some websites open, some absolutely won't

5.1 Test Path MTU

On the VPS:

# 1472 = 1500(MTU) - 28(IP+ICMP)
ping -c 3 -M do -s 1472 1.1.1.1

# 如果失败，就逐步减小，比如 1464/1452/1420...
ping -c 3 -M do -s 1452 1.1.1.1

If you find you have to drop it very small before packets stop fragmenting, then you should suspect that some segment of the link has an MTU smaller than 1500 (such as certain tunnels, certain providers' strange networks).

5.2 Temporary Fix: MSS Clamp (Great for Emergencies)

If you're using iptables:

sudo iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

This trick can save a lot of "inexplicable stalls," but it's not a cure. The real cure is to match MTU properly in your network environment (tunnels, WireGuard, PPPoE).

6. Suspect It's a VPS Datacenter Problem? Keep "Evidence" for Yourself

I suggest you save the following three outputs:

# 1) mtr 报告
sudo mtr -rwzc 200 目标IP > mtr.txt

# 2) 网络接口信息
ip a > ip_a.txt
ip r > ip_r.txt

# 3) TCP 状态（看重传/拥塞也有用）
ss -s > ss_s.txt

Then when you open a ticket with the provider, don't say "I think it's slow"—throw mtr.txt at them, and communication efficiency will be much higher.

7. My Usual "Quick Troubleshooting Route" (You Can Copy It)

Local ping 1.1.1.1: first confirm it's not your home network
Local mtr VPS_IP: see if there's obvious packet loss/detour
VPS curl -w ...: distinguish DNS/handshake/TTFB
VPS iperf3 -P 4: confirm whether bandwidth is actually being provided
VPS uptime/iftop/iotop: rule out resource bottlenecks
Suspect MTU: test with ping -M do

Once you get to step 3, you can basically determine: is it a "network link problem" or a "server/application problem."

FAQ

Q1: In mtr, a certain hop shows 50% packet loss—does that mean that hop is definitely broken?

Not necessarily. Many routers rate-limit ICMP, which looks like packet loss, but forwarding is actually normal. Check whether subsequent hops also lose packets; if they don't, it's most likely just rate limiting.

Q2: It gets slow during evening peak—is there any hope?

There is hope, but usually not something "tuning parameters" can fix. More common solutions are: change datacenter, change route, put static assets on a CDN, or switch to a node closer to your target users' region.

Q3: My speedtest is very slow, but actually downloading GitHub Releases is okay—why?

Speed test nodes, protocols, and thread counts are all different. speedtest is not equal to real-world experience across the whole world. You should verify with "the target you actually need to access," such as downloading from the mirror source you commonly use.

Q4: Is there a single command that directly tells me where it's slow?

No. Network problems are just that annoying. But if you follow the route in this article, you can at least narrow the problem down to "local / link / VPS / destination site."

Symptom

Common root cause

What you should check first

Opening a website takes a long time before loading starts

Slow DNS, slow TLS handshake, slow destination site

dig / curl -w

Spinning forever, occasionally opens

Packet loss, route flapping, evening peak congestion

mtr

Opens but downloads are slow

Insufficient bandwidth, single-thread throttling, unsuitable TCP congestion control

iperf3 / speedtest

SSH lags, noticeable typing delay

High latency or jitter

ping / mtr

# Debian/Ubuntu sudo apt-get update && sudo apt-get install -y dnsutils # 看解析时间 /usr/bin/time -f "DNS time: %e s" dig +tries=1 +time=2 google.com @1.1.1.1 /usr/bin/time -f "DNS time: %e s" dig +tries=1 +time=2 google.com @8.8.8.8

0. First Break Down "Slow": Where Exactly Are You Stuck?

1. Rule Out "It's Not the VPS's Problem" (Done in 5 Minutes)

1.1 Is Your Local Network Stable

1.2 Did You Accidentally Go Through a Proxy

2. Feel Like "Opening Is Slow"? Test DNS and Handshake First

2.1 Is DNS Resolution Slow

2.2 Is the TLS/HTTP Handshake Slow

3. The Most Common: Packet Loss / Route Flapping (One mtr Tells You)

3.1 ping Only Gives You a Rough Idea

3.2 mtr Is the Proper Localization Tool

4. Bandwidth Not Maxed Out? Don't Rush to Say the Provider Is Faking It

4.1 Run a Controlled Test with iperf3

4.2 Check Whether the VPS's Own CPU/IO Is Dragging It Down

5. A Very Sneaky Pitfall: Wrong MTU Makes HTTPS/Downloads Act Weird

5.1 Test Path MTU

5.2 Temporary Fix: MSS Clamp (Great for Emergencies)

6. Suspect It's a VPS Datacenter Problem? Keep "Evidence" for Yourself

7. My Usual "Quick Troubleshooting Route" (You Can Copy It)

FAQ

Q1: In mtr, a certain hop shows 50% packet loss—does that mean that hop is definitely broken?

Q2: It gets slow during evening peak—is there any hope?

Q3: My speedtest is very slow, but actually downloading GitHub Releases is okay—why?

Q4: Is there a single command that directly tells me where it's slow?

Loading…

0. First Break Down "Slow": Where Exactly Are You Stuck?

1. Rule Out "It's Not the VPS's Problem" (Done in 5 Minutes)

1.1 Is Your Local Network Stable

1.2 Did You Accidentally Go Through a Proxy

2. Feel Like "Opening Is Slow"? Test DNS and Handshake First

2.1 Is DNS Resolution Slow

2.2 Is the TLS/HTTP Handshake Slow

3. The Most Common: Packet Loss / Route Flapping (One mtr Tells You)

3.1 ping Only Gives You a Rough Idea

3.2 mtr Is the Proper Localization Tool

4. Bandwidth Not Maxed Out? Don't Rush to Say the Provider Is Faking It

4.1 Run a Controlled Test with iperf3

4.2 Check Whether the VPS's Own CPU/IO Is Dragging It Down

5. A Very Sneaky Pitfall: Wrong MTU Makes HTTPS/Downloads Act Weird

5.1 Test Path MTU

5.2 Temporary Fix: MSS Clamp (Great for Emergencies)

6. Suspect It's a VPS Datacenter Problem? Keep "Evidence" for Yourself

7. My Usual "Quick Troubleshooting Route" (You Can Copy It)

FAQ

Q1: In mtr, a certain hop shows 50% packet loss—does that mean that hop is definitely broken?

Q2: It gets slow during evening peak—is there any hope?

Q3: My speedtest is very slow, but actually downloading GitHub Releases is okay—why?

Q4: Is there a single command that directly tells me where it's slow?