# 反代不想再盯证书到期，Caddy 自动 HTTPS 默认会做什么、On-Demand 哪类要加限制？

**URL:** <https://www.shiqidu.com/t/topic/1978>\
**Category:** 开发调优\
**Tags:** Linux, 服务器, Caddy, 问与答, 信息安全\
**Created:** [2026 年11 月 8 日 06:48 UTC](https://www.shiqidu.com/t/topic/1978 "2026-11-08T06:48:43Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

作者： ![shiqidu\_editor](https://www.shiqidu.com/user_avatar/www.shiqidu.com/shiqidu_editor/32/528_2.png) [@shiqidu\_editor](https://www.shiqidu.com/u/shiqidu_editor)\
发布日期： [2026 年11 月 8 日 06:48 UTC](https://www.shiqidu.com/t/topic/1978/1 "2026-11-08T06:48:43Z")

</div>

证书到期那几天，反代机器上总要有人盯一眼续期。[站内那篇 IIS 四十七天证书](https://www.shiqidu.com/t/topic/1842) 写的也是续证痛点。换到 Caddy 这边，[Automatic HTTPS](https://caddyserver.com/docs/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](https://caddyserver.com/docs/automatic-https#on-demand-tls) 的意思是：不必事先把所有域名写死在配置里。第一次握手需要某张还没有的证时，再当场申请。适合「启动时还不知道全部域名」「客户自带域名」「DNS 还没配齐」这类场景。第一次握手会慢几秒，之后走缓存。续期仍在后台。官方也写：只有真实落在这些场景时才建议开。

官方原文里有一句：On-Demand **必须同时启用并加以限制** ，否则会被滥用。限制写在 JSON 的 automation，或 Caddyfile 全局选项 `on_demand_tls` 里，且是全局的，不能按站点各写一套。主限制是 **ask 端点** ：Caddy 向你配置的 URL 发请求，询问「这个域名允不允许出证」。[`tls` 指令](https://caddyserver.com/docs/caddyfile/directives/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 才会按集群协调续期。你现在是固定几个站名，还是已经碰到「客户域名随时加进来」？