你说“VPS 网络慢”，我第一反应不是去喷商家。
因为我见过太多“慢”的锅，最后落在：DNS 解析慢、浏览器走了代理、服务器 CPU 打满、MTU 不对、甚至是你家路由器半夜抽风。
这篇文章我按一个目标写：你照着做，最多 20-30 分钟能把问题缩小到一个范围（本地 / VPS / 机房链路 / 目标站点）。
网络慢通常不是一个问题，是四类问题混在一起：
| 现象 | 常见根因 | 你该先看什么 |
|---|---|---|
| 打开网站要等很久才开始加载 | DNS 慢、TLS 握手慢、目标站点慢 | dig / curl -w |
| 一直转圈、偶尔能打开 | 丢包、路由抖动、晚高峰拥塞 | mtr |
| 能打开但下载慢 | 带宽不够、单线程限速、TCP 拥塞控制不合适 | iperf3 / speedtest |
| SSH 卡、敲字延迟明显 | 高延迟或抖动（jitter） | ping / mtr |
你只要先判断属于哪一类，后面就不会乱跑。
我一般先做两件事：
# 直接 ping 公共 DNS（看丢包和抖动）
ping -c 20 1.1.1.1
ping -c 20 8.8.8.8
如果你本地 ping 公网都丢包（比如 2%-5%），那你后面在 VPS 上测到的“丢包”，很可能就是你这边带过去的。
这条太真实了：我自己就踩过。
- 浏览器装了代理插件
- 系统开了全局代理
- SSH 的
ProxyCommand没关
你可以用这条粗暴验证：
# 本机直连 VPS
ssh -v root@你的VPS_IP
-v 里如果出现奇怪的跳板、代理，那先把代理关干净再测。
在 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
如果 dig 很快（几十毫秒），但你打开网站还是慢，那 DNS 基本可以放一边。
顺手看一下你 VPS 的默认 DNS：
cat /etc/resolv.conf
有些商家默认塞了奇怪的 DNS（甚至是跨洲的），改成 1.1.1.1 / 8.8.8.8 往往立竿见影。
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
看这几个指标：
dns高：DNS 问题connect高：链路延迟/丢包/路由问题tls高：握手慢（有时是丢包导致重传）ttfb高：对方服务慢（不是你的 VPS 网络）
ping -c 50 你的VPS_IP
- 丢包 > 1%：体感就会明显卡
- 延迟抖动很大：SSH 会“粘键”、网页加载会一阵快一阵慢
本地测 VPS：
# macOS
brew install mtr
sudo mtr -rwzc 200 你的VPS_IP
# Linux
sudo apt-get install -y mtr
sudo mtr -rwzc 200 你的VPS_IP
怎么看？我用一个简单原则：
- 某一跳开始丢包，后面每一跳都跟着丢包：大概率就是那一段链路有问题
- 中间某一跳丢包很高，但后面不丢：经常只是那台路由器限 ICMP，不一定是真丢包
如果你发现丢包只发生在“晚高峰”，那更像拥塞问题。这个时候你能做的，基本就是：换机房 / 换线路 / 上 CDN / 换服务商。
很多人用一个 speedtest 看到只有 20Mbps，就说“这 VPS 带宽不行”。
但带宽测试也很容易测错：
- 单线程被 TCP 拥塞限制
- 目标测速节点太远
- 你测的是“你到节点”的带宽，不等于“你到全世界”的带宽
你需要一个 iperf3 server（可以是你另一台 VPS，或者找公网测速节点）。
在 server 上：
sudo apt-get install -y iperf3
iperf3 -s
在 client（你的 VPS 或本地）上：
# 单线程
iperf3 -c SERVER_IP -t 15
# 多线程（更接近真实下载）
iperf3 -c SERVER_IP -P 4 -t 15
如果 -P 4 一下从 50Mbps 变 300Mbps，那说明不是“带宽没给”，而是单连接被限制（链路延迟大 + 丢包时很常见）。
# CPU、负载
uptime
# 网络吞吐实时
sudo apt-get install -y iftop
sudo iftop
# 磁盘 IO（网站慢也可能是 IO 慢）
sudo apt-get install -y iotop
sudo iotop
我见过最离谱的一次：用户抱怨“网络慢”，结果是 PHP 把 CPU 跑满，页面渲染慢，浏览器看起来像网络慢。
症状通常是：
- 小文件正常
- 一到大点的包就卡
- 有些网站能开，有些死活打不开
在 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
如果你发现必须降到很小才不碎包，那就要怀疑链路里某段 MTU 比 1500 小（比如某些隧道、某些商家奇怪的网络）。
如果你用的是 iptables：
sudo iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
这招能救很多“莫名其妙的卡”，但不是根治。根治还是要把你的网络环境（隧道、WireGuard、PPPoE）里 MTU 配对。
我建议你把下面三份输出存下来：
# 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
然后你去找商家工单，别说“我觉得慢”，你把 mtr.txt 扔过去，沟通效率会高很多。
- 本地
ping 1.1.1.1：先确认不是你家网络 - 本地
mtr VPS_IP：看有没有明显丢包/绕路 - VPS
curl -w ...：分清 DNS/握手/TTFB - VPS
iperf3 -P 4：确认带宽到底给没给 - VPS
uptime/iftop/iotop：排除资源瓶颈 - 怀疑 MTU：
ping -M do测一下
你做到第 3 步，基本就能判断：是“网络链路问题”还是“服务器/应用问题”。
不一定。很多路由器对 ICMP 限速，表现出来像丢包，但实际转发正常。看后续跳是不是也丢，如果后续不丢，大概率只是限速。
有救，但通常不是“调参数”能救。更常见的解法是：换机房、换线路、把静态资源放 CDN，或者换一个在你目标用户地区更近的节点。
测速节点、协议、线程数都不同。speedtest 不等于全世界的真实体验。你应该用“你真实要访问的目标”做验证，比如下载你常用的镜像源。
没有。网络问题就是这样烦人。但你按本文的路线做，至少能把问题范围缩小到“本地 / 链路 / VPS / 目标站点”。