NAT 机器部署 Hysteria2 无法连接？排查端口映射与防火墙的正确姿势

最近在折腾低成本的 NAT VPS，图个省事直接用了一键脚本安装 Hysteria2。本以为这已经是“傻瓜式”操作了，结果却遇上了能安装却不能连接的怪事：内网测试一切正常，一旦走公网 IP 加端口映射就彻底失联。如果你也在 Alpine 系统的 NAT 机上栽过跟头，这篇排查笔记或许能帮你省下几个小时的抓狂时间。

问题描述：内网通，公网不通

环境是市面上常见的廉价托管 NAT 机器，系统版本为 Alpine Linux 3.21。部署脚本选的是网上很火的 alpine-hysteria2 一键包。

安装过程很顺利，服务跑起来了。为了确认服务端是否监听，我在机器里执行了经典的 echo 测试和 tcpdump 抓包：

tcpdump -i any udp port 40443
echo test | nc -u 10.10.1.x 40443

结果显示内网通信完全没问题，UDP 包抓取正常。但在服务商后台做好了端口映射（内网端口 40443，公网端口随机），再次用公网 IP 进行测试时，却怎么也连不上。此时检查系统防火墙，发现规则也是空的，看似完全没有限制。

核心排查思路

遇到这种“内网 OK、公网的挂”的情况，通常是网络传输链路中的某一层“失明”了。我们可以按照以下步骤逐步排查。

1. 确认服务商的端口映射类型

首先，很多 NAT 提供商在后台只开放了 TCP 端口映射，而 Hysteria2 默认是基于 UDP 协议的（虽然它也可以伪装成 TCP 或利用其他传输层，但纯 UDP 依然是测试基准）。

检查点：回到服务商控制面板，仔细查看端口映射规则。确认你添加的规则中，协议类型是否勾选了 UDP 或 TCP/UDP 全选。如果你的 Hysteria2 服务端监听的是 40443 UDP，而映射规则只打开了 TCP，那么公网流量进来会被直接丢弃，自然无法连接。

2. 检查 Alpine 的 iptables/nftables

很多人检查防火墙只看 ufw 或者 firewall-cmd，但 Alpine Linux 默认使用的通常不是这些。

检查规则：执行 iptables -L -n -v 或者 nft list ruleset。如果没有输出或只有基本规则，说明防火墙确实是开放的。
潜在陷阱：有时候一键部署脚本会写入一些复杂的 NAT 规则或 ipset，可能会限制来源 IP。如果不懂输出含义，可以尝试临时清空规则测试（生产环境慎用）：iptables -F。

3. 抓包定位断点

这是最硬核也最有效的一步。不要瞎猜，直接看数据包走到了哪里。

在服务器上开启抓包，这次不要只监听内网接口，要尽量覆盖全面：

tcpdump -i any host <你的客户端公网IP> and udp port <公网映射端口>

情况 A：如果你能抓到来自客户端的数据包，说明服务商的端口映射是通的，数据已经成功进入服务器内部。此时连接不上，大概率是 Hysteria2 的配置问题（比如认证密码、SNI 不匹配）或者服务端虽然在运行但处于异常状态。
情况 B：如果抓包一片死寂，什么都收不到。那问题一定出在映射层或者服务商处。可能是数据包被服务商的上层防火墙拦截，或者是端口映射根本没有生效。

4. 验证服务监听地址

还有一个常见坑是监听地址（Bind Address）。Hysteria2 默认可能只监听了 127.0.0.1 或者内网 IP。

检查配置文件（通常在 /etc/hysteria/ 下），确认 listen 字段是否为 0.0.0.0:40443。0.0.0.0 表示监听所有网卡接口，这对于 NAT 机器尤为重要，否则请求只能通过本地回环访问，无法响应外部映射进来的流量。

解决方案与总结

经过上述排查，如果确认服务商映射规则正确（包含 UDP）、防火墙已放行、且 tcpdump 能抓到包，那么大概率需要修改服务端配置文件，将监听地址调整为 0.0.0.0 并重启服务：

# 重启服务命令视具体安装方式而定，通常是：
rc-service hysteria2 restart
# 或者
systemctl restart hysteria2

如果在服务商后台抓不到任何包，且确认协议没选错，建议直接联系服务商，有时他们的后台面板虽然显示“映射成功”，但后台内核转发规则可能并未及时生效，需要人工重置一下。

折腾 VPS 就是这样，很多时候问题不在于技术本身，而在于环境细节的微妙差异。遇到 NAT 连接问题，别慌，手里握着 tcpdump，就是握着照妖镜。