过期的 DDNS 记录与损坏的 VPN 端点：如何区分

从外部看，过期的记录和损坏的 VPN 一模一样。客户端解析一个名字，名字指向某处，连接要么超时，要么被拒绝。一个是 DNS 更新问题，另一个是认证或转发问题，只有把公布的地址和线路实际拥有的地址对比，差别才会显现。

两种表现相同的故障

第一种故障是记录里仍写着昨天的 WAN 地址。第二种是记录正确，而隧道出于自身原因拒绝你。两者在客户端上给出同样的提示，让人忍不住开始重新生成证书。

顺序在这里很重要。检查 DNS 只要一分钟，而且可以回退。重新生成 CA 两样都不是。

问网络所有者线路当前是什么地址，再问 DNS 公布的是什么。dig +short vpn.example.com 给出客户端会拿到的答案，dig @1.1.1.1 vpn.example.com 则显示另一个解析器是否看到别的东西。如果两者不一致，你看到的是缓存行为，而不是坏掉的更新器。

递归答案可能比更新晚一个 TTL，所以把权威记录和笔记本缓存的内容放在两个不同的盒子里。

老式 DDNS 设备常常直接用账户密码认证，所以改掉那个密码会让它们悄无声息地失效。它们继续用旧值重试，也不报告任何有用的信息。No-IP 的设备密码指南记录的正是老旧硬件上的这个兼容性问题，而合理的做法是使用范围受限的更新凭据，而不是用更弱的账户密码。

较新的机制会签发独立的更新令牌或密钥，有自己的生命周期。那才是要轮换进路由器的值，也是要记进凭据清单的值。它同样不是调试时该粘贴到聊天里的值。

查看更新器的非机密状态：上次成功时间、响应类别，以及它认为自己拥有的主机名。凭据被拒和连接失败需要不同的修法。

改对记录并不会带来入站可达性。如果线路位于运营商级 NAT 之后，再好的主机名也无法让入站连接工作。它也不会打开防火墙规则或转发端口。它也从来不是关闭客户端服务器校验的理由——那正是人们认定证书一定有问题时会做的事。

反过来，改 VPN 密码并不能修好过期的 DNS。它只是给同一张工单加了第二个故障。

权威记录正确之后，客户端可能还保留着旧的查询结果。用它支持的重连或端点刷新，给它一点时间，而不是猛点连接。然后用四步证明通路：解析名字、确认地址、检查监听端口是否可达、完成认证。四个独立结果，四个独立答案。

把更新器放进轮换清单，和 VPN 账户放在一起。一个有明确归属的记录所有者、一份有效凭据、一次可观察到的成功，才能避免这张工单的下一个版本。