引子端口转发 2 秒延迟拉满怎么救最近服务器 IP 被墙临时做了本地端口转发。跑curl请求 2-3 秒才拿到响应SSH 连接 8 秒才能敲命令。究其原因直连 TCP 丢包率 15%RTT 波动在 200ms-800ms 之间TCP 本身就靠重传和拥塞控制干活高丢包下直接被拖死。整个排查和优化的过程端口转发 → SSH 隧道 → WireGuard → 最终是 kcptun 救场。这篇文章按时间顺序还原每一步的问题、思路和实际配置。一、第一阶段端口转发能通但不可用初始方案最朴素——本地监听 TCP 端口HTTP CONNECT 方式转发到海外服务器# 本地转发 1080 → 海外服务器 3128 ssh -L 1080:localhost:3128 useroverseas-server -N或者用socat做中转socat TCP-LISTEN:1080,fork,reuseaddr TCP:overseas-server:3128问题很快暴露指标直连端口转发HTTP 首字节时间200ms2.1sSSH 命令响应即时3-8s丢包率15%15%穿透大文件下载速度理论线速100-300KB/s根因TCP over TCP 是经典的性能陷阱。外层 TCP 在丢包时触发超时重传 → 内层 TCP 也在重传 → 双重重传导致超时爆炸。而且 TCP 拥塞控制CUBIC/BBR在高丢包环境收敛极慢——发送窗口刚涨一点就被丢包打回去。二、第二阶段BBR 开启略有改善但不根本第一反应是开启 BBR 拥塞控制算法# 检查当前拥塞控制算法 sysctl net.ipv4.tcp_congestion_control # 输出: net.ipv4.tcp_congestion_control cubic # 开启 BBR echo net.core.default_qdiscfq /etc/sysctl.conf echo net.ipv4.tcp_congestion_controlbbr /etc/sysctl.conf sysctl -p # 验证 sysctl net.ipv4.tcp_congestion_control lsmod | grep bbrBBR 比 CUBIC 好在哪里CUBIC 靠丢包信号来判断拥塞高丢包环境直接废了。BBR 靠自己测算带宽和 RTT 来判断瓶颈不完全依赖丢包信号。开启后改善了一些指标CUBICBBRHTTP 首字节2.1s1.2sSSH 响应3-8s1.5-3s大文件300KB/s800KB/s但离可用还很远。原因是 BBR 虽然对 TCP 友好但端口转发的本质还是 TCP over TCP——两个独立的拥塞控制算法在打架BBR 也救不了。三、第三阶段WireGuard减少 TCP over TCPWireGuard 是 UDP 隧道不存在 TCP over TCP 的问题# 服务端 /etc/wireguard/wg0.conf [Interface] Address 10.0.0.1/24 ListenPort 51820 PrivateKey server-private-key PostUp iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE PostDown iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE [Peer] PublicKey client-public-key AllowedIPs 10.0.0.2/32 # 客户端 /etc/wireguard/wg0.conf [Interface] Address 10.0.0.2/24 PrivateKey client-private-key [Peer] PublicKey server-public-key Endpoint overseas-server:51820 AllowedIPs 0.0.0.0/0 PersistentKeepalive 25WireGuard 确实比 SSH 转发快很多指标SSH 转发BBRWireGuardHTTP 首字节1.2s400ms大文件800KB/s3MB/s但问题依然存在UDP 协议本身在高丢包环境下也会丢包。WireGuard 的 UDP 没有内置的可靠传输机制上层 TCP 仍然在重传。虽然比 TCP over TCP 好但 15% 丢包下 WireGuard 仍不稳定——网页加载断断续续、SSH 长连接半小时左右断开一次。四、第四阶段kcptun 救场 — 用策略化重传对抗丢包真正扭转局面的是 kcptun。它基于 KCP 协议核心思路是用带宽换延迟——即增加了约 20-30% 的冗余带宽开销但换来了丢包环境下的可靠低延迟传输。为什么 KCP 比 TCP 更适合高丢包机制TCPKCP重传策略超时触发 快速重传3 dup ACK主动选择重传 更快的超时流量控制滑动窗口 拥塞窗口滑动窗口可独立配置确认模式延迟 ACK等 200ms 或 2 个段立即 ACKRTO 计算保守的 Jacobson/Karels 算法激进的快速恢复流控 vs 拥塞控两者合一流控和拥塞控分离KCP 比 TCP 多 30-50% 带宽开销但在丢包 15% 的网络中延迟只有 TCP 的 1/5 到 1/10。核心差异在于TCP 为了公平性处处让步KCP 为了速度全力以赴。部署步骤Step 1服务端下载二进制文件# 下载最新版本xtaci/kcptun curl -L https://raw.githubusercontent.com/xtaci/kcptun/master/download.sh | bash # 或者直接 wget https://github.com/xtaci/kcptun/releases/download/v20251124/kcptun-linux-amd64-20251124.tar.gz tar xzvf kcptun-linux-amd64-20251124.tar.gzStep 2优化系统参数# /etc/sysctl.conf 中加入以下 UDP 优化参数 net.core.rmem_max 26214400 net.core.rmem_default 26214400 net.core.wmem_max 26214400 net.core.wmem_default 26214400 net.core.netdev_max_backlog 2048 # 立即生效 sysctl -p # 提高文件描述符限制 ulimit -n 65535rmem_max和wmem_max设置 UDP 接收和发送缓冲大小到 25MB针对高 BDP带宽延迟积链路至关重要。netdev_max_backlog控制网卡接收队列深度配置足够大防止高速 UDP 环境下丢包。Step 3服务端启动命令./server_linux_amd64 \ -t 127.0.0.1:8388 \ -l :4000 \ -mode fast3 \ -mtu 1350 \ -sndwnd 1024 \ -rcvwnd 1024 \ -crypt aes \ -key your-password \ -nocomp \ -sockbuf 16777217 \ -dscp 46Step 4客户端启动命令./client_darwin_amd64 \ -r overseas-server:4000 \ -l :8388 \ -mode fast3 \ -mtu 1350 \ -sndwnd 1024 \ -rcvwnd 1024 \ -crypt aes \ -key your-password \ -nocomp \ -sockbuf 16777217 \ -dscp 46核心参数详解参数推荐值作用-modefast3预设模式。fast3 重传最激进丢包 15% 环境首选-mtu1350最大传输单元比标准 1500 小以留裕度给隧道开销-sndwnd1024发送窗口大小带宽 wnd * mtu / rtt-rcvwnd1024接收窗口大小和 sndwnd 对称-sockbuf16777217每 socket 缓冲区 16MB低速 CPU 必要-cryptaes加密算法AES 有硬件加速慢设备用 salsa20-nocomp—关闭 snappy 压缩高带宽链路节省 CPU-dscp46IP DSCP 标记让路由器优先转发带宽计算wnd * mtu / rtt。例如 sndwnd1024, mtu1350, rtt400ms理论带宽 1024 * 1350 / 0.4 3.46MB/s。实际中还有 KCP 协议开销打 7 折约 2.4MB/s——对日常使用足够了。性能对比实测数据指标WireGuard 直连kcptun 加速HTTP 首字节400ms80ms大文件下载3MB/s12MB/sSSH 响应1.5-3s即时丢包 15% 环境稳定性间歇性断开稳定 24h额外带宽开销5-10%20-30%五、进阶kcptun 的调优细节5.1 FEC前向纠错的取舍kcptun 内置 Reed-Solomon 纠错码在--datashard和--parityshard参数中配置如--datashard 10 --parityshard 3。但在我的环境丢包 15%偶尔突发到 30%测试发现FEC 开启带宽占用高 30-50%但丢包恢复效果好FEC 关闭CPU 占用降低 40-60%但丢包率 30% 时不稳定我的最终配置FEC 默认关闭因为 ARM 路由器的 CPU 太弱FEC 编码耗时超过网络延迟改善。如果你用的是 x86 服务器可以开启--datashard 10 --parityshard 3。5.2 Head-of-Line Blocking 解决多流复用smux下如果所有流共享一个物理通道会发生 Head-of-Line Blocking# 开启 smux v2 调大缓冲区 ./client_darwin_amd64 \ ... \ -smuxver 2 \ -smuxbuf 8388608 \ -streambuf 2097152 \ ...-smuxver 2开启 smux v2客户端和服务端必须一致-smuxbuf 8388608总缓冲区 8MB-streambuf 2097152每流限制 2MB防止单流占满所有缓冲5.3 Docker 化部署systemd 服务# /etc/systemd/system/kcptun-server.service [Unit] Descriptionkcptun server Afternetwork.target [Service] Typesimple Usernobody ExecStart/opt/kcptun/server_linux_amd64 \ -t 127.0.0.1:8388 \ -l :4000 \ -mode fast3 \ -mtu 1350 \ -sndwnd 1024 \ -rcvwnd 1024 \ -crypt aes \ -key your-password \ -nocomp \ -sockbuf 16777217 Restartalways RestartSec10 [Install] WantedBymulti-user.targetsystemctl daemon-reload systemctl enable kcptun-server systemctl start kcptun-server systemctl status kcptun-server5.4 DNS 泄露防护kcptun 本身不处理 DNS。配合dnsmasq或直接设置 DNS over HTTPS 防止 DNS 泄露# 客户端 /etc/resolv.conf nameserver 127.0.0.1再用 dnsmasq 转发到 8.8.8.8 或 1.1.1.1 通过 kcptun 通道。六、回看整个旅程四个阶段的演进整个优化过程可以用下面这个表来总结方案技术栈核心问题最终指标SSH 端口转发TCP over TCP双重重传导致超时爆炸HTTP 2.1s, 大文件 300KB/s BBRTCP BBR 拥塞控制BBR 对 TCP over TCP 救不了根本HTTP 1.2s, 大文件 800KB/sWireGuardUDP 隧道UDP 丢包无可靠传输, 间歇断连HTTP 400ms, 大文件 3MB/skcptunKCP over UDP额外带宽 20-30%HTTP 80ms, 大文件 12MB/s关键经验总结TCP over TCP 永远不可取——这是整个问题的起点。即使 BBR 再强大双重拥塞控制的内耗是绕不过去的。UDP 隧道WireGuard是起点不是终点——UDP 丢包后没有可靠传输保障仍然会导致上层 TCP 重传。KCP 的信令开销值得——额外 20-30% 带宽换来了 5-10 倍的延迟改善对日常开发和远程办公来说完全值得。服务端 CPU 瓶颈——KCP 的 Reed-Solomon 编解码 加密在 ARM 设备上可能成为瓶颈。低性能设备建议关闭 FEC 使用 salsa20 轻量加密。总结如果你也在为被墙后的网络问题困扰推荐直接跳过端口转发和 SSH 隧道一步到位用 kcptun。核心命令就两条——服务端和客户端各一条10 分钟就能部署完。参数方面记住-mode fast3 -mtu 1350 -sndwnd 1024 -rcvwnd 1024这四个关键参数就够了。
)
