ddclient 发布了 VPN 出口：修正探测来源

你的 DNS 名称现在解析到 VPN 服务商的地址，而更新日志看起来完全正常。这种组合本身没有问题。基于网页的探测向外部服务询问它看到的源地址，当请求经全隧道 VPN 出去时，答案就是 VPN 出口，而不是家里的 WAN 地址。更新程序完成了它的工作，只是工作被指向了错误的观测。

确认名称应当指向什么

为入站家庭服务准备的公网名称，需要一条能让已批准的入站连接抵达该服务的地址。发布共享的服务商出口并不会在那里安排入站转发，再多的 DNS 配置也造不出那项转发。在动手改更新程序之前先定下这一点，因为它决定了哪个地址才是对的。

给 VPN 客户端隧道地址用的私有名称是另一个问题，也有另一个答案：它属于私有 DNS，根本不需要公网探测服务。把两种需求混在一起，正是原本可用的配置开始发布没人要的地址的方式。

接口地址同样需要解读。家庭路由器后面的笔记本地址不是公网 WAN 地址，就连路由器的 WAN 地址也可能处在运营商级 NAT 之后，发布它并不能带来入站可达性。

先复现取值，再改任何东西

分别观察两条路径。隧道开启时，探测报告出口；隧道关闭时，或把探测绑定到物理接口时，它报告家庭地址：curl --interface eth0 https://ifconfig.me。如果这两个答案不同，你就在没有碰更新程序的情况下复现了故障。

然后用只检查配置、不执行更新的模式运行客户端，例如ddclient -verbose -noexec，并读出它选用了哪种探测方法。详细输出会写明方法和取到的值，而这正是你在编辑任何内容之前需要的事实。

把探测指向选定的路径

如果名称必须发布家庭 WAN 地址，探测就必须观测那条地址。有三种做法，大致按偏好排序：让路由器用它自己支持的更新程序发布；用 ddclient 的路由器状态探测去读路由器实际提供的页面；或者保留网页探测，但把它绑定到物理接口，让它绕开隧道。

对于路由器状态这条路径，较新的 ddclient 使用 usev4 与 fwv4 选项族，并可选用跳过模式处理页面周围的文字。查阅你所装版本的 README，因为旧版本用 use 与 fw 表达同一思路，而从错误版本抄来的选项名会在启动时失败。

如果保留网页探测，请记住：给探测选路由和给更新 API 调用选路由是两件独立的事。更新调用负责提交记录，探测决定提交什么值。

把密钥和版本理清楚

路由器凭据和服务商令牌应当放在受保护的配置文件里，而不是出现在会落入 shell 历史的命令行上。详细跟踪可能同时包含两者，所以在粘贴进工单前先做脱敏。需要抓取带认证的路由器页面的探测方法，也要求你在固件更新之后仍让那份凭据可用。请像对待服务商令牌一样谨慎保存它。

ddclient README 记录了各种探测途径及其选项名。不要在同一条记录里混用 IPv4 与 IPv6 结果，也不要假设某个版本里存在的选项在另一个版本里也有。

先核实取值，再核实可达性

在允许线上更新之前，把拟用地址与预期终结点对比；随后在一次获准的更新之后检查权威 DNS，并把解析器缓存算进去。较低的 TTL 只是缩短等待，并不能把错的值变对。

只有记录正确之后，才应当在防火墙与转发都已获批的前提下，从独立网络测试入站服务。正确的 A 记录并不能证明服务可达；静态 VPN 租约可以简化私有命名，却修不好指向错误 WAN 的公网主机名。