家庭 VPN 服务器无法访问：逐段排查 NAT 链路

服务器在局域网内应答正常，端口转发规则看起来也没问题，外部客户端却仍然连不上。逐个边界往外排查，比第四次修改同一条规则更快，因为每处边界都留下自己的证据：路由器的 WAN 页面、运营商的转换，以及主机上的监听。请从已经打开的管理页面开始，最后用一台不在你控制下的网络做测试。每走一步就把结果记下来，因为顺序本身就是诊断，凭记忆的数字不算证据。如果你只需要一条出站隧道，转换就不是你的问题：被拦住的只是未经请求的入站流量。

从路由器的 WAN 页面开始

登录路由器，读状态页面而不是端口转发列表。记下 WAN 地址、它所属的接口，以及连接类型是 DHCP、PPPoE 还是运营商提供的其他方式。然后用手机流量上的外部服务来对照这个地址，让观测不必绕回同一台路由器。这两个数字回答的是不同的问题，把它们对上，才是这一步的全部意义。

WAN 地址与观测到的公网地址不一致，说明路由器上游至少有一台转换设备。这还不算故障，因为许多运营商按设计做转换，服务照样能用。如果两者一致，地址多半归路由器所有，问题就搬到了你的内网。无论哪种情况，都要连日期一起把这一对地址记下来，因为运营商会重新分配地址，和上个月的记录作比较毫无意义。

往上游走一跳

直接从路由器上运行 traceroute，读前几跳。重复出现的公网地址、第一跳以私有地址回应，或地址落在共享的 100.64.0.0/10 网段内，都指向某台上游转换设备。 RFC 6598 正是为这类部署定义了这个网段，所以在 WAN 字段里看到它是有力信号，而不是猎奇。路径上有两台转换设备时痕迹会变得不明显，所以要读模式，而不是只看一行。

有些运营商只在客户门户里显示分配到的地址，所以在断定路由器说谎之前，先去那里看一眼。门户里的地址与你的外部观测一致，而路由器报告的是另一回事，这就是上游存在转换设备最清楚的证据。把两个页面都收进变更记录，因为有了两张带日期的截图，关于边界归谁的争论会快得多。

确认监听与转发

在局域网里做测试只能证明服务本地可用，对从外部能否到达毫无证明力。许多路由器会从内部应答自己的转发规则，于是外部路径还关着，发夹测试却成功了。确认守护进程确实绑在你以为的地址和端口上，再从外部测试。以下操作全部只读。

ss -lunp | grep -E '1194|51820'
ip -4 addr show | grep -E 'inet '
curl -s --max-time 5 ifconfig.me
traceroute -n -m 5 1.1.1.1

如果外部测试显示数据包根本没有到达路由器，丢包发生在上游，任何本地规则都修不好。如果数据包到了却没有任何回应，下一处边界就是监听程序或主机防火墙。在主机上抓包能定下你面对的是哪一种，也比再猜一轮规则省时间。对比期间请保持监听及其传输方式不变，否则下一次测试回答的就是另一个问题。

改变拓扑，而不是同一条规则

当转换设备属于运营商时，解决办法是换一条路径，而不是再加一条转发。一台有公网地址的小型 VPS，从家庭一侧用出站隧道连上去，就在服务前面放了一个可达端点。运营商提供的公网地址在有条件时更简单，通常也比自建机器便宜。IPv6 能彻底去掉转换，前提是客户端网络、DNS 记录和防火墙策略都支持。

动态 DNS 只更新名字；它并不创造可达性，把它指向共享地址还会把客户端送到其他用户同样在用的运营商网关上。那种故障看起来和服务器死掉一模一样，所以前几步的记录才重要。记下测试失败时名字解析到了哪个地址，并把答案和测试结果放在一起。

围绕你真正掌控的边界重写方案：监听、隧道和路由。旧转发只在它仍然描述事实时才保留，因为一条与拓扑不再相符的规则，比没有规则更糟。记下实际是哪一层在拦截，以及什么证据说明了这一点。否则下一个打开管理页面的人，会把这一趟的每一步从头再走一遍。