证书到期那几天，反代机器上总要有人盯一眼续期。站内那篇 IIS 四十七天证书 写的也是续证痛点。换到 Caddy 这边，Automatic HTTPS 页把默认行为写得很满：站点名够格时，它会帮你申请、续期，并把 HTTP 重定向到 HTTPS。省心的前提是 DNS、端口和数据目录按文档就绪。再往后，On-Demand TLS 是另一档能力，官方自己标了滥用风险，生产要加限制。
默认自动 HTTPS 实际会干什么
文档写：Caddy 默认用 HTTPS 提供站点。本机名、内网主机名走本地自签并尽量装进本机信任库。公网 DNS 名则向 Let’s Encrypt、ZeroSSL 这类 ACME CA 要证书。证书会后台续期，默认端口 80 的 HTTP 会跳到 443 的 HTTPS。自动 HTTPS 只在配置之上「补强」，不会覆盖你已经写死的监听和证书加载方式。
激活条件也很具体：配置里出现了主机名或 IP（Caddyfile 站点地址、JSON 路由的 host matcher、命令行 --domain / --from 等）。反过来，显式关掉、配置里没有任何主机名、只听 HTTP 口、站点地址写成 http://…、或者手工加载证书（除非开了忽略已加载证书那一类选项），都可能让自动 HTTPS 整段或部分不生效。
公网域名要顺利出证，常见前提包括：A/AAAA 指到这台机器，外网能通 80 / 443（或正确转发到 Caddy），数据目录可写且持久，域名出现在相关配置位置。这些是生产站的基本面，不是 Caddy 独有的玄学。本地实验文档建议改用 CA 的 staging 目录，避免打满生产额度。HTTP 与 TLS-ALPN 挑战默认可用。要走 DNS 挑战拿通配符等能力，需要另配 DNS 插件，那是进阶路径，日常几个固定域名通常不必先碰。
On-Demand：握手时再出证，但必须先收口
On-Demand TLS 的意思是：不必事先把所有域名写死在配置里。第一次握手需要某张还没有的证时，再当场申请。适合「启动时还不知道全部域名」「客户自带域名」「DNS 还没配齐」这类场景。第一次握手会慢几秒，之后走缓存。续期仍在后台。官方也写：只有真实落在这些场景时才建议开。
官方原文里有一句：On-Demand 必须同时启用并加以限制，否则会被滥用。限制写在 JSON 的 automation，或 Caddyfile 全局选项 on_demand_tls 里，且是全局的，不能按站点各写一套。主限制是 ask 端点：Caddy 向你配置的 URL 发请求，询问「这个域名允不允许出证」。tls 指令 里的 on_demand 子指令也写了安全警告：生产环境若不同时配置 on_demand_tls 来缓解滥用，就是不安全的。
全局选项页把 ask 写清楚：请求带 ?domain=，端点返回 2xx 才允许出证，其它状态码取消签发并让握手失败。官方还提醒 ask 要尽量快（毫秒级、按域名做常量时间查找），别在 ask 里拖 DNS 或慢网络。也可用 permission 模块做自定义判定。旧的 interval / burst 限流写法官方标了不推荐，还在配置里的话应去掉。允许列表可以落在你们自己的账号库或域名表里，由 ask 去查——这是 hardening 方向，不是教人对外批发证书。
哪些站适合默认路径，哪些别裸开 On-Demand
自己的几个固定域名、DNS 已经指好、只想少操心续期：走默认自动 HTTPS 就够，不必开 On-Demand。域名集合事先未知、或要代管大量客户域名时，才考虑 On-Demand，而且先有 ask / 允许列表一类后端，再在站点块里开 tls { on_demand }。文档举例里，对任意域名开放、又没有限制的内部 On-Demand，明确写了公网可达时攻击者可以耗尽资源——这是警告，不是「怎么搭开放中继」的教程。
不要把 On-Demand 当成「免费证书批发口」。限制没配好之前，宁可域名写死在 Caddyfile 里。数据目录要持久，证书和私钥都在 Caddy 的 storage 里，多实例共用同一 storage 才会按集群协调续期。你现在是固定几个站名，还是已经碰到「客户域名随时加进来」？