Let’s Encrypt 服务降级：该盯紧续期任务，但别误读成全站宕机

Let’s Encrypt 这次最容易被误读的地方，是第三方标题里的 down。

从官方状态页能看到的事实更窄：生产环境 ACME v2 API，也就是 acme-v02.api.letsencrypt.org，显示 Degraded Performance。门户服务 portal.letsencrypt.org 也一样。两者都出现在 High Assurance Datacenter 1 和 High Assurance Datacenter 2。

但同一张状态页也显示，staging 环境、官网、证书透明度日志，以及 c.lencr.org 相关分发服务仍是 Operational。

所以这不是一个“Let’s Encrypt 全面宕机”的故事。它更像是生产签发入口和门户服务的性能降级。对普通网页访问者，未必马上有感；对依赖 ACME 自动签发、自动续期的人，才是需要立刻看日志的事。

状态页到底显示了哪些异常

状态页给出的异常集中在两个生产服务：ACME v2 API 和门户。

ACME v2 API 是证书申请、续期和账户操作会碰到的关键入口。门户服务则更多影响查看和管理相关信息。两者降级，说明自动化链路可能变慢、超时或不稳定。

但 Degraded Performance 不是 Down。它不等于所有请求失败，也不等于所有证书无法签发。

这个对比很重要。

Let’s Encrypt 的核心价值在自动化。很多团队平时不会登录门户，也不会手工点签发。真正跑在后台的是 Certbot、acme.sh、lego，或者 Kubernetes Ingress、CDN、CI/CD 里的自动续期任务。

所以状态页的含义要翻译成运维语言：入口没显示完全不可用，但它可能已经足够慢，慢到让一些自动化任务失败、排队或反复重试。

最该受影响的是谁，应该做什么

最相关的两类人，是依赖 Let’s Encrypt 自动续期的运维人员，以及把 ACME 客户端接进部署流程的开发者。

他们要看的不是“网站现在能不能打开”。很多现有证书还在有效期内，网页访问可能完全正常。要看的，是下一次续期会不会按时完成。

更具体一点，可以把动作压到三件事：

• 查 ACME 客户端日志，看是否出现超时、5xx、连接失败、重试异常等记录。
• 查临近到期证书，尤其是未来几天内到期、且依赖自动续期的域名。
• 查定时任务或流水线状态，确认续期任务有没有卡住、重跑、跳过或被限流策略影响。

如果团队有多集群、多地域部署，还要确认每个节点拿到的新证书是否一致。证书续期很怕“主节点成功，边缘节点没更新”。这种问题不一定马上爆，但到期时会一次性暴露。

这里也有一个现实约束。

Let’s Encrypt 免费、开放、自动化程度高，这是它被大量采用的原因。但它不是商业 CA 的企业支持服务。DigiCert、Sectigo 这类商业 CA 通常会把 SLA、企业支持和人工响应做进付费方案里。

Let’s Encrypt 状态页也提示，服务支持以社区为基础，当前状态和故障信息主要通过 community.letsencrypt.org 获取。对小团队来说，这不是要不要换 CA 的简单题，而是要不要给证书续期留出缓冲、监控和降级预案。

临期才续，是把风险压到最后一天。

现在不能下哪些结论

目前能确认的事情不多，但已经够做一次风险排查。

能确认的是：生产 ACME v2 API 和门户服务显示性能降级；staging、官网、CT 日志和 c.lencr.org 相关服务显示正常。

不能确认的是：根因是什么、持续了多久、影响了多少用户、失败比例有多高。也不能把第三方标题里的 down most of today，直接当作官方状态页已经完整证实的事实。

接下来最该观察的不是情绪化标题，而是三个信号：

• 状态页里的 Degraded Performance 是否恢复为 Operational。
• 社区论坛是否出现官方补充，包括影响范围、根因和恢复说明。
• 自己的 ACME 客户端失败率是否下降，临期证书是否已经完成续期。

我更在意的是第三个信号。

公共状态页告诉你大盘有没有异常，但不会告诉你自己的证书有没有续上。证书这件事，平时看起来无声无息；一旦到期，就是用户浏览器里红色警告。

这次事件的判断边界要守住：它不是全站宕机，但也不是可以忽略的小波动。对依赖自动化续期的团队，正确动作不是恐慌迁移，而是马上把续期链路当生产依赖检查一遍。