对于 CloudCone 这类海外 VPS，TCP 连接参数优化可以在一定程度上改善跨境访问的延迟体验，但需要先确认延迟来源是协议栈配置还是物理路由问题。
先说结论：TCP 参数调优适合已经确认网络路由正常、但连接建立和保持阶段存在损耗的场景，盲目调整可能适得其反。
- 先定位：用 traceroute 和 ping 确认延迟是路由问题还是本地协议栈问题
- 先做：调整 keepalive、tcp_tw_reuse 等基础参数，避免大幅改动拥塞控制算法
- 再验证：用 tcping 或 mtr 对比调整前后的连接建立时间和稳定性
命令速用版
以下是可以直接在 CloudCone VPS 上执行的检查和调整命令，每步都有回滚方案。
检查当前 TCP 参数：
sysctl -a | grep -E 'tcp_keepalive|tcp_tw_reuse|tcp_fastopen'
启用 TCP 快速打开（减少握手耗时）：
echo 3 > /proc/sys/net/ipv4/tcp_fastopen
启用 TIME_WAIT 连接复用：
echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse
调整 keepalive 探测间隔：
sysctl -w net.ipv4.tcp_keepalive_time=1800
永久生效需写入配置文件：
echo 'net.ipv4.tcp_keepalive_time = 1800' >> /etc/sysctl.conf
为什么会这样
跨境访问延迟高通常有两个原因：物理距离导致的光信号传输时间，以及协议层面的连接建立开销。TCP 参数优化只能解决后者。
默认的 Linux TCP 配置是为通用场景设计的，没有针对高延迟网络做特殊优化。比如三次握手在跨太平洋线路上可能消耗 300-500ms，而连接复用可以让后续请求跳过这个步骤。但要注意，这些优化对已经建立好的长连接效果有限，主要改善的是频繁短连接场景。
另外，CloudCone 等海外 VPS 的网络质量很大程度上取决于你访问时走的路由线路，这部分是服务器端参数无法控制的。如果路由本身绕路或拥堵，调 TCP 参数不会有明显效果。
分步处理
第一步：确认延迟来源
先在你本地电脑执行：
traceroute -n cloudcone_vps_ip
观察路由跳数和每跳延迟。如果前几跳就很高，问题在本地网络；如果中间某跳突然激增，可能是国际出口拥堵；如果全程平稳但总延迟高，那是物理距离导致的，参数优化空间有限。
第二步：检查当前连接状态
在 VPS 上执行：
netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'如果看到大量 TIME_WAIT 状态连接，说明连接回收不够快，可以启用 tcp_tw_reuse。
第三步：逐步调整参数
不要一次性改多个参数。每次改一个，观察效果后再继续。建议顺序是：先改 keepalive_time，再改 tcp_tw_reuse，最后考虑 tcp_fastopen。
修改后执行：
sysctl -p
让配置生效。
第四步：记录原始值
调整前先把原始参数记下来，方便回滚：
sysctl -a | grep tcp_keepalive_time > /root/tcp_backup.txt
怎么验证是否生效
用 tcping 测试连接建立时间：
tcping cloudcone_vps_ip 443
对比调整前后的平均响应时间。注意要测试足够多次（至少 20 次）取平均值，单次测试没有参考价值。
用 mtr 看路由稳定性：
mtr -n -c 10 cloudcone_vps_ip
关注丢包率和抖动变化。如果调整后丢包率反而上升，说明某些参数可能过于激进。
检查连接状态变化：
watch -n 5 'netstat -n | awk "/^tcp/ {++S[\$NF]} END {for(a in S) print a, S[a]}"'观察 TIME_WAIT 和 ESTABLISHED 的数量变化趋势。
常见坑
1. 不要随意改拥塞控制算法
网上有些教程推荐直接启用 BBR，但 BBR 在某些网络环境下可能导致吞吐量波动。公开资料中没有看到可靠的量化数据证明 BBR 对跨境延迟有稳定提升，建议先试用基础参数。
2. keepalive_time 不是越小越好
设置太短会增加无效探测流量，设置太长又无法及时发现断连。1800 秒是比较保守的起点，可以根据实际业务调整。
3. tcp_tw_reuse 在 NAT 环境下可能有问题
如果 VPS 后面还有负载均衡或 NAT 设备，启用这个参数可能导致连接冲突。确认你的架构后再开启。
4. 参数改了但没生效
有些云服务商的内核参数是锁定的，修改后会被自动还原。可以用
sysctl 参数名
确认修改是否真正应用。如果不行，可能需要联系服务商确认是否支持自定义内核参数。
5. 忽视应用层配置
服务器端的 TCP 参数只是其中一环，Nginx、MySQL 等应用也有自己的超时和连接池设置。如果只调系统参数而忽略应用配置，效果会打折扣。
原文链接：https://www.zjcp.cc/ask/10211.html