17 台廉价 NAT 容器实测：为什么 80% 的便宜 VPS 一上手就废

背景

过去两个月我自费买了 17 台月付 0.3～0.8 美元的海外 NAT 容器，分布在东京、新加坡、法兰克福、伦敦、洛杉矶。动机很朴素：正规云厂商一台轻量机器二三十块一个月，而这些 NAT 小鸡宣称同样价格能买一年。

结论先行：17 台里真正可用的只有 1 台。这篇把失效模式拆开讲，重点是一个被普遍忽略的平台级缺陷。

一、测试方法

每台机器开出来先做三件事，任何一项不达标直接判死：

1. 宿主负载：容器内读 /proc/loadavg，5 分钟均值 > 2 直接退。该指标比机房名声可靠得多——同机房的机器负载能差一个数量级。

2. 端口转发是否真能传数据：很多人只测 SSH 通不通。SSH 走的是文本协议，小包能过就显示"连上了"，但代理的 TLS 大数据流可能在中途被截断。

3. 晚高峰带宽：19:00 和 21:00 各测一轮，记录 p50 和抖动。

第 2 点是这篇的核心，后面单独展开。

二、宿主超售有多离谱

其中一台新加坡实例，宿主 loadavg 从 20 一路涨到 58。表现是 SSH 连上去要等半分钟，free -m 偶尔超时。这类机器不需要再测网络，直接退订。

廉价 NAT 的商业模型决定了超售是必然的——平台把宿主的 CPU 和内存切给几十个容器，只要大部分用户是闲置状态就能撑住。你一旦真的跑流量，就会被邻居拖死。

三、那个平台级缺陷：80 端口只转 SYN

这是最值得写的一条，因为我踩了 6 次才识破。

现象：平台面板提供一个「端口转发」功能，比如把公网 44360 转到容器内的 80。配置完，ssh -L 转发测试是通的，HTTP 请求能返回内容。看起来很健康。

但只要换成 TLS 流量（代理的 REALITY/VLESS 握手），就会在中途被 RST，或者干脆超时。sing-box 日志显示：请求进来后 9 毫秒处理完，然后报 invalid address。

真相是：平台的 NAT 层只转发了 SYN，没有真正透传后续 payload。HTTP 明文的小响应能挤过去，TLS 二进制流就不行。已知中招的有 Clouvider（2 台）、Leaseweb 新加坡、ZOUTER 东京和洛杉矶、podcctv 阿尔卑斯——共 6 台，全部来自同一个 10.91.0.0/20 聚合面板。

更细的一层：我自己手动在面板加的转发规则同样失效，说明缺陷在平台的 NAT 层，不是某一台机器的问题。

这条给验收流程的启示：测"代理端口能不能真传数据"，不能只测 SSH 或 HTTP。必须用 curl --http2、或者直接用客户端建一次真实连接。

四、能用的那一台长什么样

第 14 台，东京，月付 0.78 美元，走聚合面板：

• 中国方向延迟 44ms，非常优秀
• 端口转发工作正常，REALITY 握手成功
• 但面板转发层限速约 1Mbps

即使这一台，短板也来自平台限速而非机房质量。1Mbps 约合 128KB/s，刷 Telegram 文字、跑 API 都够，看视频不行。

五、REALITY 在容器里为什么可能失效

法兰克福有一台容器内 REALITY 完全不起来，连回环地址都失败——排除了网络因素，是容器环境的问题（缺内核特性或用户命名空间限制）。同一台改 VLESS+TLS 就正常了。

所以选协议前先确认容器能力，别把时间花在错误的方向上。

六、给结论

如果要一句话总结这 17 台的教训：

**廉价 NAT 的瓶颈通常不在机房位置，而在平台转发层和宿主超售。**

实操心法：

• 开机器先看 `/proc/loadavg`，这一步能筛掉一半
• 验收代理必须建真实连接，别只看 SSH
• 晚高峰单独测一轮，跨运营商线路数据不可比
• 同一聚合面板下的机器共享基础设施，一台坏大概率台台坏

省下的钱买到的其实是排查时间。对真正需要稳定用的人来说，一台正规云的新加坡实例（二三十块一个月，直连、有带宽保障）比十台 NAT 更省心。

本文为实测记录，所有结论基于自费购买的实例，非软文。