很多人说“VPS 网络慢”，第一反应就是：带宽太小。
但我更常见的是：
丢包（哪怕 1%-2% 都很难受）
抖动（jitter）很大，SSH 打字像抽风
队列堆积（bufferbloat），测速看着还行，但实际交互很卡
MTU/MSS 不匹配，HTTPS/下载莫名其妙卡
这篇不是“贴一堆 sysctl 就完事”。我按实战顺序写：先定位再优化，每一步都能验证、能回滚。
0）开局先做 4 个判断：慢在哪？0.1 是 DNS 慢，还是链路慢？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 高：链路延迟/丢包/绕路
ttfb 高：对方服务慢（不一定是你 VPS 网络）
0.2 有没有丢包/抖动？ping -c 50 1.1.1.1
ping -c 50 8.8.8.8
0.3 用 mtr 看“绕路/丢包”更直观Debian/Ubuntu 先装：
sudo apt-get update && sudo apt-get install -y mtr
本机测 VPS：
sudo mtr -rwzc 200
VPS 测目标站（比如你常访问的站点）：
sudo mtr -rwzc 200 example.com
怎么看（记住这两条就够）：
某一跳开始丢包，后面每一跳都跟着丢包：那段链路更可疑
中间某一跳丢包很高，但后面不丢：经常只是那台路由器限 ICMP，不一定是真丢包
0.4 带宽到底够不够？（用 iperf3 更靠谱）Debian/Ubuntu：
sudo apt-get update && sudo apt-get install -y iperf3
你需要一个 iperf3 server（可以是你另一台 VPS）。
# client
iperf3 -c
iperf3 -c
单线程低、多线程高，通常说明你受“延迟+拥塞控制”影响更大，而不是“带宽没给”。
需要更完整的定位路线，直接看这篇（先把锅甩到具体环节）：
VPS 网络慢如何排查：从测速到丢包定位
1）先做最划算的一步：BBR + FQ（别乱改一堆）如果你是跨境链路、延迟高，BBR 很多时候是“最便宜的提速”。
BBR 的完整教程站内已经有了，我这里不重复：
VPS BBR 加速教程
你只要记住一个组合：
tcp_congestion_control=bbr
default_qdisc=fq
验证：
sysctl net.ipv4.tcp_congestion_control
sysctl net.core.default_qdisc
2）处理 bufferbloat：测速不慢但“用起来卡”的元凶典型症状：
speedtest 看着不错
但网页打开、SSH、API 调用就是“卡一卡”
你可以边下载边 ping，看看延迟是不是突然飙升：
# 终端 A：持续 ping
ping 1.1.1.1
# 终端 B：随便跑个大下载/同步
# 例如 curl/wget/apt update 等
如果下载一开始 ping 延迟就从 30ms 飙到 300ms+，这就是典型的队列堆积问题。
fq 往往能明显改善这种交互卡顿。
3）DNS：别小看它，尤其是你在 VPS 上拉依赖/装包先看你现在用的 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
4）MTU/MSS：一堆“玄学卡顿”其实是它症状：
小文件没问题
一到 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
5）TCP 缓冲：别瞎调，先看你是不是“真的需要”在高延迟链路里，适当放大缓冲可以提高吞吐；但瞎调只会让问题更难定位。
建议原则：
你先用 iperf3 测到“带宽跑不满”
再考虑调 rmem/wmem
你可以先把当前值记下来（方便回滚）：
sysctl net.core.rmem_max net.core.wmem_max
sysctl net.ipv4.tcp_rmem net.ipv4.tcp_wmem
6）别忽略“不是网络”的慢：CPU/内存/磁盘/应用本身有些慢，根本不是网络。
先跑这几条，很多时候一眼就能看出来：
uptime
free -h
df -hT
CPU 跑满：一切都慢
内存爆了：开始 swap/触发 OOM，体感像“网络突然变慢”
磁盘满了：写不进去，服务各种异常
CPU 相关排查直接看这篇：
VPS CPU 跑满 100% 排查
磁盘相关救火看这篇：
VPS 硬盘满了怎么办：清理 + 扩容
7）最推荐的做法：小步迭代 + 每步验证我建议你按这个顺序来（每一步都能回滚）：
curl -w 分清 DNS/链路/TTFB
ping/mtr/iperf3 定位问题类型
BBR + FQ（最划算）
DNS 优化
MTU/MSS 排坑
需要时再动 TCP 缓冲
最后提醒一句：
如果你测出来是“晚高峰拥塞/绕路”，那你再怎么调 sysctl，也救不了物理链路。
这个时候最现实的解法就是：换地区、换线路、上 CDN。
Cloudflare CDN 加速设置