OpenClaw 巡检证书与域名到期：HTTPS 过期、域名续费、备案和 API 密钥怎么提前预警

网站出过的故障里，有一类特别难看：不是被攻击，不是流量暴涨，是忘了一件早就写在日历上的事。证书到期，浏览器给你一个醒目的大红警告；域名到期被人抢注，整个站的流量一夜之间归零；云资源套餐到期没续，服务直接停摆。这些故障的共同点是——它们提前几个月就已经确定了，只是没人去看。

更麻烦的是，这类事情天然适合被忽略：周期长、不出错、没有反馈。你续了一次能安睡一年，中间每一天都不会有任何提示告诉你「离出事还有 47 天」。

这篇在站内运维序列里的位置需要说清，避免和已有几篇重复：OpenClaw 网站安全巡检 管的是有没有人动手脚（后门文件、页面篡改、登录爆破）；全站死链巡检 管的是站内链接是不是已经坏了；服务器资源监控 管的是机器现在活得好不好；知识库陈旧内容巡检 管的是内容口径是不是过期了。这一篇管的是第四类对象——那些带有明确失效时间的外部凭证与资产。它的特点不是「坏了」，而是「到点了」。

一、五类会过期的东西，比你想的多

很多人以为要盯的只有 SSL 证书。实际上带着「到期日」的东西至少五类，而且往往落在不同人的手里：

1. TLS/SSL 证书：影响面最直接（浏览器拦截），也是唯一一个用户能立刻看到的。
2. 域名：到期后有赎回期，但一旦进入删除流程，抢注风险极高。域名还牵着一个隐性风险——持有人的联系邮箱如果已经失效，续费提醒根本收不到。
3. 备案、许可与资质：备案信息与实际不符、许可到期未换证，都会导致可访问性受限。这类流程通常涉及人工审批，提前量要留得比其他都长。
4. API 密钥与访问令牌：第三方服务（地图、支付、短信、模型 API）的密钥可能有有效期、试用期或额度期。密钥过期不会报警，只会开始返回错误。
5. 云资源与套餐：服务器、对象存储、CDN、短信包、模型调用包——按量转包年、包年到期的节点，往往是账单突然跳一档的时刻。

还有一小类是容易漏的：内部自签证书与客户端证书、对象存储的签名 URL 有效期、消息队列或数据库的凭据有效期。它们不出现在任何对外界面，坏了也不会有外部报警，只会表现为「某个定时任务突然失败」。

二、每类资产盯三个参数，不多不少

巡检的字段设计比巡检本身更重要。盯太多没人看，盯太少会漏。建议每一类只记三列：

• 到期时间：不管是绝对的日期，还是「剩余天数」，统一换算成「剩余天数」更好比较。
• 提前量阈值：这一类资产需要提前多久开始处理（下面第四节讲怎么定）。
• 责任人：到期要通知谁。这一列最容易被省掉，也是出事时最关键的一列——通知给一个没人看的群里，等于没通知。

再加两个辅助列会更好用：自动化程度（能不能一键续、还是必须人工走审批）和续费入口（在哪个后台、账号密码在谁手里）。很多次「提前发现了但还是过期了」，卡的就是这两列没写清楚。

三、三路探测：让 Agent 真的「看得见」到期时间

到期时间不会自己送上门，需要主动去取。按可靠性和成本排序，有三条路径：

1. 直接握手与查询（适合证书、域名）

TLS 证书可以在建立连接时直接读出有效期，这是最可靠的探测方式——它读的是线上真实生效的证书，不是你以为配置好的那份。这一点很重要：证书换过、回滚过、多台机器不一致，都是真实发生过的事故。域名则可以通过 WHOIS/RDAP 查询注册到期时间。

2. HTTP 响应与内容检查（适合备案、服务可用性）

部分平台会在站点或后台给出状态提示。可以做的是定期拉取关键页面，检查是否出现「即将到期」「请尽快续费」这类字样，或者检查返回码是否异常。这一路的价值在于能发现那些没有公开 API 的资产。

3. 管理台 API 或导出文件（适合云资源、密钥）

云厂商、DNS 服务商、第三方 API 平台通常都提供查询接口或账单导出。如果拿不到 API 权限，退而求其次是用固定格式的导出文件（CSV）定期喂给 Agent——手动导一次总比完全不知道强。

三条路各管一段，组合起来才完整。巡检任务本身的定时安排可以参考 定时任务巡检怎么做 里「不同对象走不同队列」的思路：证书和域名每天扫一次就够，备案类每周一次，云资源类跟着账单周期走。

四、提前量阶梯：别只设一个提醒

只设一个「提前 7 天提醒」的问题是：7 天可能不够走完流程，但你又觉得还早。更实用的是阶梯式提醒，每一级的语气和动作都不同：

• 90 天（知悉级）：只在周报里出现一行，目的是让责任人知道有这么回事。
• 30 天（准备级）：进入待办清单，确认续费方式、金额和审批路径。
• 14 天（动作级）：开始执行——提交审批、准备材料、申请维护窗口。
• 7 天（告警级）：如果还没完成，升级到直接通知责任人本人，而不是发进群里。
• 3 天与 1 天（红色级）：每天提醒一次，并同步给上一级。

不同资产的阶梯要不一样：证书可以走全流程自动化（很多平台支持自动续期），域名和备案必须留 30 天以上（涉及实名、审核、人工审批），API 密钥要看能不能自助重置，能自助的留 7 天就够，需要走合同的要拉到 30 天。

五、两级预警与升级对象

预警要不要升级、升级给谁，是这套流程能不能落地的分水岭。建议只做两级，做多了会麻痹：

• 一级（常态提醒）：进入提前量窗口的资产，合并成一条每日简报。合并很重要——十条单独通知没人看，一条汇总反而会被读。合并和降噪的做法可以参考 告警降噪怎么做。
• 二级（超期升级）：已经进入红色级仍未处理的，或者同一项连续三天出现在简报里没有变化的，升级到上级并单独通知。升级条件的定义方式可以沿用 失败升级规则 那套思路：什么情况重试、什么情况暂停、什么情况必须找人。

这里有一个很实用的附加判断：无人认领的资产要单独列出来。如果一个域名或一个密钥连续几轮巡检都找不到责任人，本身就是一次需要上报的风险——它意味着有东西在无人看管地运行。

六、处置预案：发现之后谁做什么

巡检只负责发现，处置要有预案，否则发现了也只是多一条焦虑。按类型给三条常用路径：

• 证书：优先走自动续期（ACME 一类方案），把人工介入降到「续期失败时才处理」。续期后要验证线上生效的是新证书，而不是只看签发了。手动替换的流程要写进手册，包含重启服务的步骤。
• 域名与备案：核心动作是核对持有人信息和联系邮箱是否有效——很多「没收到续费提醒」的根因在这里。同时开启注册商的自动续费和多年续费。
• 密钥与套餐：提前准备好新的密钥并完成灰度切换，再停用旧的。切换过程要有一条完整的核对步骤，建议直接沿用 变更后验证清单 里「权限、队列、结果一起验」的做法。

凭证类的更新，本质上是一次轮换，原则和 凭证轮换怎么做好 里写的一样：新旧并存、灰度切换、确认无引用后再撤销旧凭证。直接替换是最容易引发突发故障的做法。

七、防误报：让告警只在需要动手时响

到期类巡检最大的敌人不是漏报，是长期存在的「已知项」把注意力磨掉。一条已经躺了 200 天的提醒，和没有提醒是等价的。三个做法能救回来：

1. 状态要能标注。「已知且已安排」的资产应该被打上标记并移出日常提醒，只在临近时回归。标记要有有效期，过期自动回到列表。
2. 已完成的要真正消失。续费完成后，同一条提醒必须在下一次巡检中就消失——做不到这一点，用户会在第三天开始忽略全部提醒。
3. 区分「需要注意」和「需要动手」。简报里只保留后者，前者放进月报。这条原则和 升级规则 是同一个内核：分级的意义就是把有限的注意力留给真正要紧的那几条。

八、优缺点和适合人群

优点：把一类「靠人记」的事变成每天自动跑一遍的检查；给出的结论非常硬——剩余天数是一个不会含糊的数字；能提前发现「持有人邮箱失效」这类隐性问题；日报可以直接作为运维交接材料。

缺点：依赖外部查询接口，接口变更或限流会影响巡检（WHOIS 尤其容易限速）；只能发现「到点」，不能发现「配错了」；需要有人维护责任人和提前量这两个字段，否则清单会慢慢失真；对纯静态、无域名的内部系统意义不大。

适合谁：手上有多个域名或子域名的人；给客户代管站点、服务器、证书的服务商；有备案和资质类时效要求的单位；以及任何「曾经因为忘记续费出过事」的团队——这类团队通常是最有动力把这件事做起来的。

不适合谁：所有资产都在一个云账号里、且已经全部开启自动续期的场景，手动再建一套巡检属于重复建设；以及资产数量个位数、日历提醒就能覆盖的小站点。

总结

1. 定位：这是「时效性资产」的巡检，和文件层安全巡检、链接层死链巡检、资源层服务器监控四方互补。它的特点是——问题通常提前几个月就已确定。
2. 五类资产：证书、域名、备案与资质、API 密钥、云资源套餐；每类只记三个参数（剩余天数、提前量、责任人）。
3. 三路探测：直接握手读证书 / 查 WHOIS，抓页面提示，拉管理台 API 或导出文件。
4. 提前量阶梯：90 / 30 / 14 / 7 / 3 / 1 天，分级的意义是让动作和提醒的语气一起升级。
5. 底线：提醒要能升级到具体的人，已完成的提醒要真的消失——否则再准的巡检也会被忽略。

最后一句：这类巡检的价值不在于多聪明，而在于它从不偷懒。人会因为「还有一个月呢」而拖延，脚本不会。