NAT VPS 不转发 UDP 导致 QUIC 类协议全废 (NAT VPS Without UDP Forwarding Blocks QUIC Protocols)

2026-09-21 暂无评论

1. 触发场景

共享 IP / NAT 小鸡（公网 IP 由几十上百人共用，机器自己是内网地址如 192.168.x.x）上部署 Hysteria2 / TUIC / 任何 QUIC 系协议。服务端一切正常启动，客户端连不上。

2. 症状

服务端 ss -ulnp 显示正常监听，systemctl is-active 是 active，日志无报错。客户端只给一句：

FATAL  failed to initialize client
  {"error": "connect error: timeout: no recent network activity"}

这条报错长得像「节点挂了」或「密码错了」，不会提示你「是 NAT 没转发 UDP」。 换端口、换密码、换 SNI、关掉防火墙，全都不起作用。

实测：UDP 443 / 8443 / 59420 / 59422 / 29651 五个端口全部同样超时。

3. 决定性判据：看内核计数器，不看日志

ICMP 和 UDP 的转发规则互不相干——有的 NAT 转发 ICMP，有的不转发 UDP。所以 ping 通完全说明不了问题。用 /proc/net/snmp 的 InDatagrams 数：

# 1. 记录前值
ssh vps 'grep "^Udp:" /proc/net/snmp | tail -1'

# 2. 从另一台机器发 30 个 UDP 包（bash 内置 /dev/udp，不用装工具）
ssh other 'for i in $(seq 1 30); do echo x > /dev/udp/<域名或IP>/<端口>; done'

# 3. 再看
ssh vps 'grep "^Udp:" /proc/net/snmp | tail -1'

InDatagrams 一个都不涨 = 包根本没进机器，端口是服务商在宿主机上静态映射的，没给你 UDP 就是一个都没有。

对照实验：同一台 other 发 UDP 到 223.5.5.5:53 正常，排除本机出 UDP 的能力问题。

4. 根因

NAT / 共享 IP VPS 的端口映射由服务商在宿主机上配好。他们通常只映射 TCP；UDP 要么要单独申请，要么压根不提供。这是购买决策的一部分，不是部署时能绕过去的东西。

5. 修法

去服务商面板找端口映射 / 端口转发设置，看能不能开 UDP（部分商家是工单申请）。
开不了就换机器——要有独立公网 IP 的，或商品页明确写了支持 UDP 的。
在那之前，Hysteria2 / TUIC / HTTP/3 反代这类方案在这台机器上是死路，别再花时间调客户端。

6. 下次如何识别

买机器前看商品页有没有写 UDP；「共享 IP」「NAT」「端口映射」这几个词出现时，默认假设只有 TCP。
部署前先做第 3 节那个计数器测试，30 秒，比装完服务再排查快得多。
客户端报 timeout: no recent network activity 且服务端确实在监听 → 优先怀疑 UDP 没进来，而不是密码/证书/防火墙。
反过来：独立公网 IP 的机器不会有这个问题，症状相同就要往别处找（运营商 UDP QoS、GFW 对 QUIC 的干扰）。

7. 相关

自建 AI 中转带宽实测方法 (Bandwidth Benchmarking for Self-Hosted AI Relay) —— 第「三段延迟法」一节判定了该不该换 UDP 协议：真丢包才值得换，只有 RTT 高则不换。
自建代理 VPS 选购与流量计价 (VPS Selection for Self-Hosted Proxy) —— 选型阶段把 UDP 支持纳入考量。
mihomo 节点拨不通排查 (Mihomo Node Connection Failure Diagnosis) —— 客户端侧的分层排查；本文是服务端侧的一层。

来源：2026-09-21 在 LA 共享 IP 小鸡上部署 Hysteria2（v2.12.3）。服务端起得来、客户端永远超时；/proc/net/snmp 计数器前后无变化，确认 UDP 未转发。事后查服务商面板：压根没有 UDP 端口映射这个选项——不是没配置，是不提供。同机 TCP 侧的 VLESS + WS + TLS 一切正常。

本文归档于个人知识库 · 领域：CS & AI · 模块：04 Project_CS_AI/Network