Unbound DoT 断电后解析失败：先核对时钟与证书有效期

路由器断电重启后，网络已经接通，Unbound 的 DNS-over-TLS 转发却失败，日志指向证书尚未生效或已经过期。如果设备时间退回几个月，先恢复可信的系统时间，再检查同一条 DoT 连接。不要关闭证书验证来让解析暂时恢复。

这里针对启用上游 TLS 身份校验的 Unbound。时间错误只是一个可核实的分支；系统时间准确时，证书过期、信任链、验证名称和上游连通性仍需分别检查。OPNsense 的旧版服务配置与当前界面也可能不同，不应照搬历史版本的校时脚本。

先比较 UTC，避免把时区显示误差当成时钟回退

从设备控制台或已有管理入口查看当前日期、年份和时间，与独立可信的时间来源比较。可在设备上只读查看 UTC：

date -u

时区设置会改变本地显示，不会把证书校验所用的真实时间向前推进几个月。只差固定几个小时，先区分显示时区与实际时间；日期或年份明显错误，则应查看启动时钟、硬件时钟或虚拟机时间来源。

同时保留 Unbound 的具体 TLS 错误和发生时间。证书校验会把证书链的 notBefore、notAfter 与当前系统时间比较。时间过早，正常证书也可能被判断为尚未生效；时间过晚则可能被判断为过期。日志只写 certificate verify failed 时，还不足以单独证明时钟就是根因。

校时服务在运行，不等于已经同步

在当前 OPNsense 的 Services → Network Time 中，检查实际时间源与状态。上游是否有响应、最后接收时间、Reach、Offset，比服务图标显示运行更能说明同步情况。还要核对路由、防火墙和实际出站接口；能连接其他网站不代表时间源可达。

普通 NTP 时间源名称需要先解析。若设备自身所有 DNS 都依赖这条失败的 DoT 路径，可能出现“需要正确时间才能解析、需要解析才能校时”的启动依赖。使用 NTS 时，认证阶段也涉及 TLS。先确认自己的配置确有这条依赖，不要把所有 NTP 同步失败都归到证书问题。

应为启动校时准备独立且可信的路径，例如组织提供的可达时间服务或平台支持的初始时间来源。若需使用固定地址，确认它由服务方提供并允许这种用法，不能随手固定一个公共池名称当时解析出来的地址。时间源的信任要求与网络访问规则也应一并保留。

大幅校正安排在受控窗口，随后恢复自动同步

有控制台或独立管理通道时，先按当前系统支持的维护方法把时间恢复到可信范围，再检查既有时间服务能否正常同步。修改前保存时间服务与 DNS 转发设置，明确当前由 ntpd、chronyd 还是虚拟化平台管理时间，避免多个机制同时调整同一个时钟。

chronyd 通常通过加快或减慢时钟逐渐修正偏差。采用 Chrony 的环境可以评估启动阶段的 makestep 策略；大偏差达到配置阈值且处于允许的更新次数内时，才会直接跳变。它并不是“启动服务后必然立即对时”的保证。

如果当前确实使用 chronyd，已经确认可信时间源可用，并且业务允许立即跳变，可在维护窗口评估：

chronyc makestep

这条命令把当前已经估计出的剩余修正直接应用到系统时钟，不会凭空取得一个可信时间源。没有有效测量时，不能把执行成功当成时间已经正确。执行还需要当前环境允许控制 chronyd。

时间跳变会影响按墙上时间判断的任务、日志顺序和依赖时间的业务；向后跳变尤其需要评估。不要把每分钟以 root 执行这条命令作为通用修复，也不要为了校时另装一个服务却忘记原有时间管理。若启动时允许跳变，应尽量安排在依赖时间的业务启动前，并核对之后仍能持续同步。

保留 DoT 验证，重新确认实际转发结果

恢复时间后，检查 Unbound 实际采用的上游地址、TLS 验证名称和 CA 来源。forward-tls-upstream 开启 TLS 传输；认证还需要正确加载 CA 信任与相应身份配置。TLS 开启本身不等于已经完成身份校验。

若时间正确仍报证书问题，按当前返回的证书处理有效期、链或名称。不要用移除 CA 配置、忽略有效期或改用未验证的 TLS 来结束排查。平台生成的配置应从它支持的界面或扩展入口修改，直接编辑生成文件可能在下次重载后被覆盖。

验收应看到设备 UTC 正确、时间源持续同步，并且新的 DNS 查询确实经预期的 DoT 上游得到回复，TLS 日志不再出现同一项验证失败。缓存命中或浏览器使用别的 DNS，不能证明这条转发已经恢复。

最后检查下一次启动的时间来源与服务依赖，处理硬件时钟或虚拟化时间异常。配置需要回退时恢复本次调整的时间源、启动策略与转发设置；不必把设备时间重新调回错误日期。一次人工校正只解决当前偏差，启动后还能自动保持正确时间才算完成。