很多人说“VPS 网络慢”，第一反应就是：带宽太小。
但我更常见的是：
- 丢包（哪怕 1%-2% 都很难受）
- 抖动（jitter）很大，SSH 打字像抽风
- 队列堆积（bufferbloat），测速看着还行，但实际交互很卡
- MTU/MSS 不匹配，HTTPS/下载莫名其妙卡
这篇不是“贴一堆 sysctl 就完事”。我按实战顺序写：先定位再优化，每一步都能验证、能回滚。
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高：先处理 DNSconnect高：链路延迟/丢包/绕路ttfb高：对方服务慢（不一定是你 VPS 网络）
ping -c 50 1.1.1.1
ping -c 50 8.8.8.8
Debian/Ubuntu 先装：
sudo apt-get update && sudo apt-get install -y mtr
本机测 VPS：
sudo mtr -rwzc 200 <VPS_IP>
VPS 测目标站（比如你常访问的站点）：
sudo mtr -rwzc 200 example.com
怎么看（记住这两条就够）：
- 某一跳开始丢包，后面每一跳都跟着丢包：那段链路更可疑
- 中间某一跳丢包很高，但后面不丢：经常只是那台路由器限 ICMP，不一定是真丢包
Debian/Ubuntu：
sudo apt-get update && sudo apt-get install -y iperf3
你需要一个 iperf3 server（可以是你另一台 VPS）。
# client
iperf3 -c <SERVER_IP> -t 15
iperf3 -c <SERVER_IP> -P 4 -t 15
单线程低、多线程高，通常说明你受“延迟+拥塞控制”影响更大，而不是“带宽没给”。
需要更完整的定位路线，直接看这篇（先把锅甩到具体环节）：
如果你是跨境链路、延迟高，BBR 很多时候是“最便宜的提速”。
BBR 的完整教程站内已经有了，我这里不重复：
你只要记住一个组合：
tcp_congestion_control=bbrdefault_qdisc=fq
验证：
sysctl net.ipv4.tcp_congestion_control
sysctl net.core.default_qdisc
典型症状：
- speedtest 看着不错
- 但网页打开、SSH、API 调用就是“卡一卡”
你可以边下载边 ping，看看延迟是不是突然飙升：
# 终端 A：持续 ping
ping 1.1.1.1
# 终端 B：随便跑个大下载/同步
# 例如 curl/wget/apt update 等
如果下载一开始 ping 延迟就从 30ms 飙到 300ms+，这就是典型的队列堆积问题。
fq 往往能明显改善这种交互卡顿。
先看你现在用的 DNS：
cat /etc/resolv.conf
验证 DNS 解析耗时（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
你可以临时换成 Cloudflare/Google（具体看你的环境管理方式）：
- IPv4:
1.1.1.1/8.8.8.8 - IPv6:
2606:4700:4700::1111/2001:4860:4860::8888
症状：
- 小文件没问题
- 一到 HTTPS 或大点的包就卡
测试 Path MTU：
# 1472 = 1500 - 28
ping -c 3 -M do -s 1472 1.1.1.1
# 不通就逐步减小
ping -c 3 -M do -s 1452 1.1.1.1
救急用 MSS clamp（不等于根治，但很多时候能立刻好转）：
sudo iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
在高延迟链路里，适当放大缓冲可以提高吞吐；但瞎调只会让问题更难定位。
建议原则：
- 你先用 iperf3 测到“带宽跑不满”
- 再考虑调
rmem/wmem
你可以先把当前值记下来（方便回滚）：
sysctl net.core.rmem_max net.core.wmem_max
sysctl net.ipv4.tcp_rmem net.ipv4.tcp_wmem
有些慢，根本不是网络。
先跑这几条，很多时候一眼就能看出来：
uptime
free -h
df -hT
- CPU 跑满：一切都慢
- 内存爆了：开始 swap/触发 OOM，体感像“网络突然变慢”
- 磁盘满了：写不进去，服务各种异常
CPU 相关排查直接看这篇：
磁盘相关救火看这篇：
我建议你按这个顺序来（每一步都能回滚）：
curl -w分清 DNS/链路/TTFBping/mtr/iperf3定位问题类型- BBR + FQ（最划算）
- DNS 优化
- MTU/MSS 排坑
- 需要时再动 TCP 缓冲
最后提醒一句：
如果你测出来是“晚高峰拥塞/绕路”，那你再怎么调 sysctl，也救不了物理链路。
这个时候最现实的解法就是：换地区、换线路、上 CDN。