证书过期这件事，通常没人会收到提醒
Let's Encrypt 签发的证书有效期是 90 天。这个设计的目的就是逼你自动化——三个月一换，手动续总有一次会忘。而忘了的后果很直接：浏览器直接拦下整个站点，访客看到一整页红色警告，转化率归零。
麻烦的是，自动续期配好之后往往就再没人看它了。续期脚本可能已经默默失败了好几个月，只是因为旧证书还没到期，站点一切正常。等到真过期的那天，才发现上次成功续期是半年前。
所以除了配置自动续期，还得配一套"续期失败能知道"的机制。下面按排查顺序列一遍常见故障点。
图片由 AI 生成
先确认验证方式是哪一种
Let's Encrypt 签发前要验证你确实控制这个域名，主流两种方式，出问题时排查方向完全不同。
HTTP-01
验证方访问 http://你的域名/.well-known/acme-challenge/随机串，能拿到约定内容就通过。要求 80 端口可达，且这个路径不能被重定向走。
最常见的失败原因就在这里：全站 HTTPS 强制跳转把验证请求 301 到了 HTTPS，而 HTTPS 这时候证书已经过期或者还没签，验证直接失败。解决办法是在 Nginx 里给 .well-known 路径单独开一个不走跳转的规则，放在所有跳转规则之前。
另一个常见原因是 CDN。如果域名走了 CDN，验证请求可能被 CDN 拦下或者缓存，源站根本收不到。要么在 CDN 上给 .well-known 配置不缓存、直接回源，要么换 DNS-01。
DNS-01
验证方查一条 _acme-challenge 的 TXT 记录。不要求 80 端口，也不受 CDN 影响。通配符证书只能用这一种，因为它证明的是你控制整个域名而不是某一台服务器。
DNS-01 的失败点在于 API 凭证。acme.sh 需要通过 DNS 服务商的 API 自动添加记录，凭证过期、权限变更、服务商改了接口，都会让续期在毫无征兆的情况下失败。而且 DNS 生效有延迟，acme.sh 默认会等待，但某些服务商的 TTL 设置会导致等待超时。
多域名证书的一个陷阱
一张证书里绑了五个域名，只要其中一个验证失败，整张证书就签不下来。站点改版时下线了某个子域名、DNS 记录删了但证书配置里还留着，续期就会卡在这个已经不存在的域名上。
排查时先看 acme.sh 的日志，它会明确指出哪个域名验证失败。删掉失效域名重新签发即可。长期做法是定期检查证书里的域名列表，跟实际在用的域名对齐。
图片由 AI 生成
证书签下来了，不等于生效了
这是另一个高频坑。acme.sh 续期成功，证书文件确实更新了，但 Nginx 没重载，进程里用的还是旧文件的内存副本——页面上的证书依然是旧的，到期照样报错。
正确做法是用 acme.sh 的 --reloadcmd 参数把重载命令挂上去，让续期成功后自动执行 nginx -s reload。别依赖默认的 cron 任务只做续期不做部署。
如果用的是 Docker 部署的 Nginx 或者其他反向代理，reloadcmd 要写进容器里执行，路径和权限都要对。这一步最容易在容器化之后被漏掉。
别忘了限流
Let's Encrypt 有签发频率限制，同一域名每周的重复证书签发次数、每个注册域名的证书数量都有上限。脚本配置错误导致每次 cron 都重新签发，很快就会撞上限流，然后你会看到"too many certificates already issued"这类报错，而这时候离真正需要续期可能还有两个月。
判断方法：acme.sh 默认只在证书剩余有效期不足 30 天时才真正续期，正常情况不会频繁签发。如果你看到日志里每次运行都在签发，检查是不是参数写错导致强制续期。
最后一步：让失败能通知到你
前面这些都做对了，也还需要一层兜底。推荐两个层面的监控。
- 脚本层面：acme.sh 支持通过
--set-notify配置通知，续期成功或失败都会推送到邮件、Telegram、钉钉等渠道。失败必须推，成功可以只记日志 - 外部层面：用第三方证书到期监控服务，从外部定期检查你域名的证书剩余天数，剩余不足 15 天就告警。这一层跟你的服务器完全独立，即使脚本、cron、通知全都失效，它仍然能报警
外部监控值得单独配。它的价值不在于替代脚本，而在于它是唯一一个不会因为"服务器内部出问题"而一起失效的检查点。
顺带一个建议：把证书到期时间记进运维日历，哪怕有自动续期。三个月一次的东西，人工留个印象不算负担，尤其是你手上不只一个站的时候。
