最近折腾VPS加速这事，真是踩了不少坑。刚开始以为买个国外服务器，配好代理就完事了，结果晚高峰一到，网页加载慢得让人想砸键盘。后来慢慢查资料、试脚本，才搞明白VPS加速不是单一设置，而是一整套从内核到应用层的配合。
下面把我这段时间摸出来的东西整理一下。
先搞清楚一件事：VPS加速到底在加速什么
很多人以为VPS慢是因为服务器配置不够。其实大多数情况下，问题出在跨国链路上。数据包从国内到国外服务器，中间要经过十几个路由节点，物理距离摆在那，延迟很难低于150毫秒。更麻烦的是回程线路，去程可能走的是优化线路，回程却绕道欧洲或东南亚，实际延迟能飙到300毫秒以上。
所以VPS加速的核心思路就两个：一是让内核更聪明地处理高延迟链路的数据传输，二是通过协议和工具把流量“伪装”或“中转”成更顺畅的路径。
BBR：最值得先打开的一个开关
如果你只做一件事，那就开BBR。
BBR是Google搞的TCP拥塞控制算法，和Linux默认的cubic不一样。cubic一遇到丢包就大幅降速，而BBR会持续测量链路的实际带宽和往返时间，丢包了也不慌，该跑多快还跑多快。跨洋链路经常有轻微丢包，BBR在这种场景下的吞吐量提升很明显，实测能到20%到50%。
开启方法不复杂。Ubuntu 20.04以上、Debian 11以上都原生支持，SSH进去执行几条命令就行：
echo "net.core.default_qdisc=fq" >> /etc/sysctl.conf
echo "net.ipv4.tcp_congestion_control=bbr" >> /etc/sysctl.conf
sysctl -p
验证的话跑一下 sysctl net.ipv4.tcp_available_congestion_control，返回结果里有bbr就说明生效了。
有个细节值得注意：fq队列调度器配合BBR效果更好，所以上面两条命令是一起写的，别只加BBR那条。
TCP参数调优：别让缓冲区成为瓶颈
开完BBR之后，TCP参数也值得顺手调一下。Linux默认的网络参数是偏向局域网环境的，放到跨国高延迟链路上，缓冲区太小会导致数据包排队溢出，人为制造丢包。
在 /etc/sysctl.conf 末尾加一组参数：
net.ipv4.tcp_max_tw_buckets = 65536
net.ipv4.tcp_tw_reuse = 1
net.core.netdev_max_backlog = 32768
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
改完 sysctl -p 生效。这几行主要做的是放大收发缓冲区、加快TIME-WAIT回收、增加连接队列长度。对于代理和中转场景，效果比较直接。
如果你不想手动改，也有一些一键脚本可以选。比如vps-netpilot把调优拆成了“通用保守”和“中转增强”两档，代理和隧道节点选增强模式就行。BBRv3 Lite则更细分，会根据CPU、内存、网卡队列和实测RTT来算调优参数。用脚本的好处是省事，坏处是你不清楚它到底改了什么，万一出问题不好回退。所以手动改一遍再决定要不要用脚本，可能更稳妥。
代理协议的选择和搭建：这才是“加速器”的核心
内核调优只是打底，真正让你访问外网变顺畅的，还是代理服务本身。
目前比较主流的是Xray配合VLESS+REALITY协议。VLESS本身轻量，REALITY的作用是让流量看起来像正常的HTTPS访问，不容易被识别。搭建可以用3X-UI面板，装完之后通过网页界面管理入站和出站规则，比纯命令行友好不少。
如果你想走CDN线路，V2Ray的ws+tls方案也很成熟。流量经过Cloudflare中转，服务器的真实IP被隐藏，同时CDN的全球节点也能起到一定的加速作用。域名用Cloudflare的免费套餐就够，A记录指向VPS的IP，开橙云代理。
更省事的选择是v2ray-agent或者Sing-box的一键脚本。比如fscarmen的sba脚本，Argo+Sing-box+CDN打包在一起，运行一条命令就能完成安装。不过一键脚本的隐患在于，你不太清楚它在后台装了什么、开了哪些端口。如果对安全性有要求，手动搭一遍会更放心，多花的时间也就十几分钟。
DNS和缓存：容易被忽略但确实有用
代理配好之后，如果感觉解析域名还是慢，问题可能出在DNS上。
海外VPS默认的DNS服务器往往离你很远，解析一个域名要绕一圈。换成Cloudflare的1.1.1.1或者Google的8.8.8.8，延迟通常会好一些。也可以用dnsmasq或unbound在VPS本地跑一个缓存DNS，设置合理的TTL，重复查询就不用每次都往外跑了。
如果是建站或者跑Web服务，Nginx的proxy_cache也能帮上忙。把经常被请求的静态资源缓存在VPS本地，回源次数减少，对外响应速度自然快。不过缓存配置要考虑内存和SSD空间，小内存的VPS别把缓存开太大，容易把系统压垮。
中转加速：花小钱办大事的思路
还有一种情况值得单独说：你买的VPS线路本身就不行，回程走的是普通公网，晚高峰丢包严重。这时候光调内核参数解决不了根本问题，需要考虑中转。
思路很简单：在国内再买一台便宜的VPS或者用已有的国内服务器，把国外VPS的流量通过国内节点转发。国内到国内这一段走的是优质线路，速度有保障；国内到国外这一段虽然还是跨境，但至少去程和回程的路径更可控了。
iptables转发或者Brook脚本都能做这件事。配置好之后，客户端连接的是国内中转IP，实际上数据经过中转到达国外服务器，体验上会有明显改善。成本上国内中转服务器通常比国外优化线路的VPS便宜得多，算是性价比比较高的方案。
几个实际会用到的工具和脚本
折腾过程中收集了一些工具，列一下方便对照：
BBR一键脚本：adsorgcn/bbr-script支持自动升级内核，兼容CentOS、Ubuntu、Debian，选1就装BBR。
网络调优面板：vps-netpilot，把调优分成几档，普通Web选保守，代理节点选中转增强，还带一键回退功能。
代理搭建：3X-UI面板配合VLESS+REALITY，或者v2ray-agent的ws+tls方案。
测速诊断：MTR看路由每一跳的延迟和丢包，BestTrace识别线路类型，TCPing测实际连接延迟。这几个工具配合用，基本能定位出问题出在哪一段。
最后说两句实际感受
VPS加速这件事，没有“一键搞定”的万能方案。BBR和TCP调优是基础，代理协议决定稳定性和隐蔽性，DNS和缓存是锦上添花，中转则是线路实在不行时的补救手段。
顺序上建议先开BBR和调TCP参数，这两步五分钟能搞定，效果最直观。然后根据实际需求选代理方案，如果只是自己用，3X-UI或者v2ray-agent足够。如果发现晚高峰持续卡顿，再考虑中转。别一上来就堆各种脚本和工具，容易把系统搞乱，回头排查问题更麻烦。
对了，改完任何内核参数或者代理配置之后，记得重启一下相关服务再测。有时候不是配置没生效，是服务没重新加载。这个坑我踩过不止一次。