跨境网络优化最容易掉进一个陷阱：端口能连、平均延迟下降，就被当成“加速成功”。但用户真正感受到的是下载吞吐、网页长尾、视频拖动和晚高峰停顿。一个入口即使 30 次握手全部成功，也可能在大流量传输时每隔几秒掉到 0 Mbps。
本文记录 MatchAll 对一组国内入口与海外节点进行优化时采用的方法。重点不是某个“万能参数”，而是如何建立可回滚的四层中转、怎样隔离变量，以及为什么一条线路上的成功方案不能直接复制到另一条线路。
文中的地址、端口、凭据与内部拓扑均已隐藏；数据仅用于说明测试方法和取舍。
从四层中转开始
整体路径可以抽象为：
用户设备 → 国内入口 → 海外节点 → 目标服务国内入口不解密用户协议，只负责四层转发：
- VLESS、VMess、AnyTLS、Shadowsocks 等 TCP 流量由 HAProxy
mode tcp转发； - Hysteria2、TUIC、HTTP/3 等 UDP/QUIC 流量使用内核 DNAT 与 MASQUERADE；
- 用户认证、TLS、Reality 与协议参数继续由海外源站处理。
这套边界比在入口终止所有协议更简单，也更容易回滚。TCP 选择 HAProxy 而不是长期运行大量 socat 进程，是因为 HAProxy 可以提供后端健康检查、连接统计、合理的 backlog 和统一的超时管理。UDP 则直接使用内核 NAT，避免用户态逐包转发带来的额外开销和会话问题。
先把基础参数调到合理范围
在协议 A/B 之前，我们先统一了几台中转与源站的基础网络参数：
- TCP 拥塞控制使用 BBR，默认队列使用
fq； - Socket 与 UDP 缓冲上限提高到 16 MiB；
- 扩大 SYN backlog、监听队列和网卡接收积压；
- 提高 conntrack 容量，并设置合理的 UDP 会话超时；
- 开启 TCP MTU probing，降低黑洞路径导致的卡顿风险。
这些参数解决的是容量和异常边界，不会凭空创造带宽。调优后连续观察错误计数：如果 UDP 接收缓冲溢出、TCP listen drop 和 conntrack 占用都不再增长，继续把数值翻倍通常没有意义，只会浪费小内存服务器的资源。
最终入口侧共承载 50 余个 TCP 四层入口和 20 余条 UDP NAT 规则，外部逐端口验证与后端健康检查均通过。这只能说明基础设施完整，仍不能证明每条路径都更快。
为什么要保留直连对照组
针对一条高抖动线路，我们保留原 TCP 直连入口，再增加独立的 Hysteria 2.12.2 QUIC 隧道入口。两个入口最终抵达同一个后端，客户端协议参数保持一致，唯一变化是“国内入口到海外节点”这一段的传输方式。
这样设计有三个好处：
- 新隧道失败时，原入口不受影响；
- 可以在同一时间窗口直接比较两条路径；
- 不会把源站版本、客户端参数和传输协议的变化混在一起。
第一轮真实 HTTP 长尾测试中，隧道路径的效果非常明显：
| 路径 | 平均响应 | P95 | 最大值 |
|---|---|---|---|
| 原 TCP 路径 | 526 ms | 2516 ms | 2862 ms |
| Hysteria 隧道 | 171 ms | 235 ms | 254 ms |
它证明 QUIC 隧道能够降低这条线路的长尾，但仍然没有回答“下载是否更快”。因此下一步必须启用官方吞吐测试，并记录每秒速度，而不是只看最终平均值。
Brutal 档位不是越高越好
在同一条测试隧道上，我们依次测试多个 Brutal 带宽档位，每次只修改这一项：
| Brutal 档位 | 下载 | 上传 | 逐秒表现 | 结论 |
|---|---|---|---|---|
| 70/50 Mbps | 44.35 Mbps | 48.83 Mbps | 下载出现 1 秒 0 Mbps | 淘汰 |
| 65/48 Mbps | 45.91 Mbps | 31.42 Mbps | 上传最低跌至 7.34 Mbps | 淘汰 |
| 60/45 Mbps | 45.49 Mbps | 43.31 Mbps | 20 秒内无归零 | 保留 |
提高声明带宽并没有提高实际下载，反而导致停顿或上传波动。最终保留的 60/45 不是数字最大的一组，却是双向吞吐和稳定性最平衡的一组。
Brutal 需要根据实际可用带宽设置。过高时发送端会表现得过于激进，丢包、重传和队列堆积反而让应用体验变差。评价标准应至少包含：
- 平均上下行吞吐；
- 每秒最低值和是否归零；
- P50/P95 响应时间；
- 隧道重连与异常退出次数；
- 晚高峰真实客户端体验。
PMTU 与 QUIC 窗口也要用数据决定
Path MTU Discovery 理论上能找到更大的安全数据报尺寸，但复杂跨云路径可能存在 ICMP 过滤、错误 MTU 或路由变化。我们在相同带宽档位下立即做了启用/关闭对比：
| 设置 | 下载 | 上传 |
|---|---|---|
| 开启 PMTU Discovery | 39.45 Mbps | 31.10 Mbps |
| 关闭 PMTU Discovery | 42.65 Mbps | 32.04 Mbps |
在这条具体路径上，开启后没有带来收益，因此继续保持关闭。这个结论不能推广到所有网络；更换云厂商、运营商或出口后应重新测量。
QUIC 流窗口与连接窗口已经处于中等偏大的范围，测试中没有流控受限证据，所以没有继续扩大。对只有约 1 GiB 内存的源站，盲目增加窗口会放大每条连接的内存占用，却未必提升吞吐。
失败实验比成功实验更重要
我们随后在另一条存在明显 TCP 长尾的线路上复制了同样的隔离 A/B，但结果相反：
| 路径 | 成功率 | 平均响应 | P95 |
|---|---|---|---|
| 原直连路径 | 16/20 | 599 ms | 1998 ms |
| Hysteria 隧道 | 17/20 | 996 ms | 2498 ms |
隧道没有解决超时，平均延迟还增加了约 400 ms。吞吐测试同样波动，因此该实验没有开放公网入口，双端服务、专用防火墙规则与临时配置全部撤下，原路径保持不变。
这次失败说明：Hysteria 适合高延迟、丢包和抖动网络，但无法修复所有路由问题。如果 QUIC 本身经过的路径更差，或者主要瓶颈是运营商拥塞与错误路由，再优秀的拥塞控制也无能为力。
一套可复用的上线流程
我们最终采用以下流程评估每一条候选加速路径：
- 盘点真实节点：区分源站、国内入口、传输别名和面板节点，避免漏端口或重复统计；
- 保留对照路径：新增备用端口，不直接替换生产入口；
- 建立回滚点：保存服务单元、HAProxy 配置、防火墙规则与相关状态；
- 只改一个变量：带宽档位、PMTU、窗口分别测试；
- 测真实业务：除了握手和延迟，还测 HTTP 长尾、双向吞吐与逐秒停顿；
- 从多个外部位置验证：排除“服务器本机能连”的假阳性；
- 效果不佳就完整撤下：不为了完成部署而保留更差的入口；
- 保留轻量监控：检查服务、端到端响应、后端健康和错误计数，但不持续跑大流量测速。
对于 Hysteria2 与 TUIC 等原生 QUIC 节点，不建议再套一层 Hysteria 隧道。QUIC-over-QUIC 会产生双重拥塞控制和额外开销。隧道更适合承载原本走 TCP 的 VLESS、VMess、AnyTLS 或 Shadowsocks 流量。
还能优化什么
当 HAProxy、NAT、BBR、缓冲、conntrack 和协议参数都已达到合理范围后，剩余提升主要来自线路与架构：
- 选择 CN2 GIA、联通 9929、移动 CMI 等更优跨境线路；
- 增加第二台不同运营商的国内入口，降低单点与单线路风险；
- 根据运营商和实时质量在直连、隧道与备用入口之间择优；
- 将多个 TCP 节点分散到 2–3 条独立隧道，避免单隧道故障全部中断；
- 用 24 小时 P50、P95、失败率和重连数据决定迁移，而不是依赖一次测速。
总结
网络优化不是把配置文件里的带宽、窗口和缓冲不断调大。正确的方法是先建立稳定、可观察、可回滚的四层基础设施，再用真实吞吐和长尾数据验证每一次变化。
本次测试中，同一个 Hysteria 方案在一条线路上显著降低 P95，在另一条线路上却明显退化；60/45 也比更激进的档位稳定。这些结果共同说明：协议没有普适最优，只有经过同时间、单变量、真实业务 A/B 后更适合当前路径的配置。
相关入口：