凌晨两点收到告警：证书只剩 12 天，ACME 客户端却记录“续期成功”。若直接归因于浏览器缓存、运营商线路或 Nginx 异常，就会修错层。真正风险可能是调度没有触发、域名验证失败，也可能是新证书签发后部署钩子未执行，让线上继续使用旧证书。
如果你正在选机器，或者想先把线路和配置跑通再谈长期方案，可以先看看这几家的线路说明和技术参数：vps（全球云服务器），先看清带宽线路、流量策略和退款条款，再决定要不要迁。
ACME续期通常由定时任务提前触发，调度禁用、时区错误、容器休眠或锁文件残留都会让任务根本没运行。先查调度日志、下次执行时间和退出码，再看签发记录；若日志停在到期前很久，应先修复触发链路，而不是反复刷新网页。
任务启动后，HTTP域名验证要求从公网访问指定路径，非预期重定向、CDN 拦截、代理鉴权或转发错误都会使响应不合规。DNS验证链路则依赖解析记录与 API 权限，CNAME 委派、权限最小化和 TTL 延迟都可能中断链路。验证请求来自 CA，不是用户浏览器；应从外部网络核对状态码、响应内容与具体失败原因。
若账户显示已签发，排查重点应立即转到证书文件：签发成功不等于线上已部署。
沿着“签发证书→写入目标路径→执行证书部署钩子→重载服务”逐段检查。目标文件未更新、属主权限错误、钩子路径或退出码异常，都可能留下旧证书。ServLlama 可集中查看域名、证书与到期状态，便于确认异常对象，但它不能替代服务器上的文件和命令核验。
Nginx平滑重载前应先做配置校验；重载后不能只看文件修改时间，还要核对线上端口返回的证书指纹、序列号和有效期，并确认工作进程已加载新证书。典型陷阱包括服务读取了另一条路径、钩子只复制文件却未 reload、多台机器只更新一台，以及旧进程仍在承接流量。
最后用三项证据闭环：本次调度有执行记录，订单有明确终态，线上证书指纹与目标文件一致。排查顺序应是未触发、验证失败、未部署、未重载；浏览器显示和线路质量只能放在证据闭环之后判断。
不要把 CA 返回的 Issued 当作链路终点。证书签发后仍要经过落盘、证书部署钩子和 Web 服务加载。先确认 ACME续期调度 的 timer 或 cron 是否触发、是否被并发锁或上次失败阻断，并用目标账户与域名复现。核对日志中的新证书序列号、到期时间、实际文件路径；dry-run 成功不等于生产证书已被替换，多域名订单还要确认每个域名都在证书覆盖范围内。
HTTP域名验证 的判断标准，是 CA 从公网读取 /.well-known/acme-challenge/ 中的 token，而不是首页是否可访问。应从外部网络检查状态码和响应正文，并排查 80/443 端口、防火墙、WAF、CDN 缓存、跳转、IPv6 解析及反代路径改写；多节点环境应让本次 token 在所有可能接收验证的入口上可读。
DNS验证链路 应拆成“API 鉴权→定位 Zone→写入 TXT→权威查询可见→清理旧值”逐段验证。常见问题是凭证无权新增或删除记录、写错父 Zone、受分区权限限制，或同名 TXT 未及时清理；容器中的插件也可能读取了旧环境变量。
部署阶段要单独执行钩子，检查目录、权限、证书与私钥是否匹配，以及命令退出码。钩子成功后先运行 nginx -t，再触发 Nginx平滑重载，并从 error log、worker 进程和线上握手确认新证书已加载。更新文件但 reload 错实例、配置仍指向旧路径，或只重启一个 worker，都会造成“续期成功、线上未变”。
可执行检查清单：① 查看调度器最近运行时间、退出码和续期日志；② 核对新旧证书序列号、到期日、落盘路径及线上握手；③ 从公网请求验证地址并比对 token，查询权威 DNS 中的 TXT；④ 检查 DNS API 权限、Zone 与插件配置；⑤ 执行 dry-run 后手动触发部署钩子并保存输出；⑥ 运行 nginx -t，reload 后检查进程和错误日志；⑦ 若仍失败，汇总订单 ID、验证响应、钩子退出码与证书指纹，据此定位断点。
