自动 HTTPS

Caddy 是第一个也是唯一一个默认自动使用 HTTPS 的 Web 服务器。

自动 HTTPS 为您的所有站点配置 TLS 证书并保持续订。它还会为您将 HTTP 重定向到 HTTPS！Caddy 使用安全和现代的默认设置——无需停机、额外配置或单独的工具。

这是一个 28 秒的视频，展示了它的工作原理

菜单

• 概述
• 激活
• 效果
• 主机名要求
• 本地 HTTPS
• 测试
• ACME 挑战
• 按需 TLS
• 错误
• 存储
• 通配符证书
• 加密客户端问候 (ECH)

概述

默认情况下，Caddy 通过 HTTPS 为所有站点提供服务。

• Caddy 使用自动本地信任的自签名证书，通过 HTTPS 为 IP 地址和本地/内部主机名提供服务（如果允许）。
  • 示例：localhost、127.0.0.1
• Caddy 使用公共 ACME CA（例如 Let's Encrypt 或 ZeroSSL ）的证书，通过 HTTPS 为公共 DNS 名称提供服务。
  • 示例：example.com、sub.example.com、*.example.com

Caddy 会保持所有托管证书的续订，并将 HTTP（默认端口 80）自动重定向到 HTTPS（默认端口 443）。

对于本地 HTTPS

• Caddy 可能会提示您输入密码，以将其唯一的根证书安装到您的信任存储中。这每个根证书只发生一次；您可以随时删除它。
• 任何未信任 Caddy 根 CA 证书的客户端访问该站点都将显示安全错误。

对于公共域名

• 如果您的域名的 A/AAAA 记录指向您的服务器，
• 端口 80 和 443 在外部是打开的，
• Caddy 可以绑定到这些端口（或 这些端口被转发到 Caddy），
• 您的 数据目录 是可写且持久的，
• 并且您的域名出现在配置中的相关位置，

那么站点将自动通过 HTTPS 提供服务。您无需对此做任何其他事情。它就是这样工作的！

由于 HTTPS 利用共享的公共基础设施，作为服务器管理员，您应该了解此页面上的其余信息，以便您可以避免不必要的问题，在发生问题时进行故障排除，并正确配置高级部署。

激活

当 Caddy 知道它正在服务的域名（即主机名）或 IP 地址时，它会隐式激活自动 HTTPS。有多种方法可以告诉 Caddy 您的域名/IP，具体取决于您运行或配置 Caddy 的方式

• Caddyfile 中的站点地址
• 主机匹配器 在 JSON 路由中的顶层
• 命令行标志，如 --domain 或 --from
• 自动化 证书加载器

以下任何一项都将阻止自动 HTTPS 被激活，无论是全部还是部分

• 通过 JSON 或 Caddyfile 显式禁用它
• 未在配置中提供任何主机名或 IP 地址
• 仅监听 HTTP 端口
• 在 Caddyfile 中使用 http:// 前缀 站点地址
• 手动加载证书（除非设置了 ignore_loaded_certificates）

特殊情况

• 以 .ts.net 结尾的域名将不由 Caddy 管理。相反，Caddy 将自动尝试在握手时从本地运行的 Tailscale 实例获取这些证书。这需要 在您的 Tailscale 帐户中启用 HTTPS ，并且 Caddy 进程必须以 root 身份运行，或者您必须配置 tailscaled 以授予您的 Caddy 用户 获取证书的权限。

效果

当自动 HTTPS 被激活时，会发生以下情况

• 为 所有符合条件域名 获取和续订证书
• HTTP 被重定向到 HTTPS（这使用 HTTP 端口 80）

自动 HTTPS 永远不会覆盖显式配置，它只会增强它。

如果您已经有一个 服务器 正在监听 HTTP 端口，则 HTTP->HTTPS 重定向路由将在您的路由之后插入，并带有一个主机匹配器，但在用户定义的 catch-all 路由之前。

如果需要，您可以自定义或禁用自动 HTTPS；例如，您可以跳过某些域名或禁用重定向（对于 Caddyfile，使用全局选项执行此操作）。

主机名要求

如果满足以下条件，则所有主机名（域名）都有资格获得完全托管的证书

• 非空
• 仅由字母数字、连字符、点和通配符 (*) 组成
• 不以点开头或结尾 (RFC 1034)

此外，如果满足以下条件，主机名有资格获得公共信任的证书

• 不是 localhost（包括 .localhost、.local 和 .home.arpa TLD）
• 不是 IP 地址
• 只有一个通配符 * 作为最左侧的标签

本地 HTTPS

Caddy 自动为所有指定了主机（域名、IP 或主机名）的站点使用 HTTPS，包括内部和本地主机。某些主机要么不是公共的（例如 127.0.0.1、localhost），要么通常不符合公共信任证书的资格（例如 IP 地址——您可以为它们获取证书，但只能从某些 CA 获取）。除非禁用，否则这些仍然通过 HTTPS 提供服务。

为了通过 HTTPS 为非公共站点提供服务，Caddy 生成自己的证书颁发机构 (CA) 并使用它来签署证书。信任链由根证书和中间证书组成。叶证书由中间证书签名。它们存储在 Caddy 的数据目录 中的 pki/authorities/local。

Caddy 的本地 CA 由 Smallstep 库 提供支持。

本地 HTTPS 不使用 ACME，也不执行任何 DNS 验证。它仅在本地计算机上工作，并且仅在安装了 CA 的根证书的地方受信任。

CA 根证书

根证书的私钥是使用加密安全的伪随机源唯一生成的，并以有限的权限持久化到存储中。它仅在执行签名任务时加载到内存中，之后离开作用域以进行垃圾回收。

虽然 Caddy 可以配置为直接使用根证书进行签名（以支持不兼容的客户端），但这在默认情况下是禁用的，并且根密钥仅用于签署中间证书。

首次使用根密钥时，Caddy 将尝试将其安装到系统的本地信任存储中。如果它没有这样做的权限，它将提示输入密码。如果不需要此行为，可以在配置中禁用它。如果由于以非特权用户身份运行而失败，您可以运行 caddy trust 以特权用户身份重试安装。

安装 Caddy 的根 CA 后，您将在本地信任存储中看到它为“Caddy 本地机构”（除非您配置了不同的名称）。如果您愿意，您可以随时卸载它（caddy untrust 命令使这变得容易）。

请注意，自动将证书安装到本地信任存储中仅是为了方便起见，并且不能保证有效，尤其是在使用容器或 Caddy 以非特权系统服务运行时。最终，如果您依赖内部 PKI，则系统管理员有责任确保 Caddy 的根 CA 已正确添加到必要的信任存储中（这超出了 Web 服务器的范围）。

CA 中间证书

还将生成中间证书和密钥，它们将用于签署叶（单个站点）证书。

与根证书不同，中间证书的生命周期短得多，并将根据需要自动续订。

测试

要测试或试验您的 Caddy 配置，请确保您更改 ACME 端点为暂存或开发 URL，否则您很可能会遇到速率限制，这可能会阻止您访问 HTTPS 长达一周，具体取决于您遇到的速率限制。

Caddy 的默认 CA 之一是 Let's Encrypt ，它有一个 暂存端点 ，不受相同的 速率限制 的约束

https://acme-staging-v02.api.letsencrypt.org/directory

ACME 挑战

获取公共信任的 TLS 证书需要来自公共信任的第三方机构的验证。如今，此验证过程通过 ACME 协议 自动化，并且可以通过以下三种方式之一（“挑战类型”）执行，如下所述。

默认情况下启用前两种挑战类型。如果启用了多个挑战，Caddy 会随机选择一个，以避免意外依赖于特定挑战。随着时间的推移，它会学习哪种挑战类型最成功，并将开始首先偏好它，但如有必要，将回退到其他可用的挑战类型。

HTTP 挑战

HTTP 挑战对候选主机名的 A/AAAA 记录执行权威 DNS 查找，然后使用 HTTP 通过端口 80 请求临时加密资源。如果 CA 看到预期的资源，则会颁发证书。

此挑战需要端口 80 在外部可访问。如果 Caddy 无法监听端口 80，则来自端口 80 的数据包必须转发到 Caddy 的 HTTP 端口。

默认情况下启用此挑战，并且不需要显式配置。

TLS-ALPN 挑战

TLS-ALPN 挑战对候选主机名的 A/AAAA 记录执行权威 DNS 查找，然后使用包含特殊 ServerName 和 ALPN 值的 TLS 握手，通过端口 443 请求临时加密资源。如果 CA 看到预期的资源，则会颁发证书。

此挑战需要端口 443 在外部可访问。如果 Caddy 无法监听端口 443，则来自端口 443 的数据包必须转发到 Caddy 的 HTTPS 端口。

默认情况下启用此挑战，并且不需要显式配置。

DNS 挑战

DNS 挑战对候选主机名的 TXT 记录执行权威 DNS 查找，并查找具有特定值的特殊 TXT 记录。如果 CA 看到预期的值，则会颁发证书。

此挑战不需要任何打开的端口，并且请求证书的服务器不需要在外部可访问。但是，DNS 挑战需要配置。Caddy 需要知道访问您的域名 DNS 提供商的凭据，以便它可以设置（和清除）特殊的 TXT 记录。如果启用了 DNS 挑战，则默认情况下禁用其他挑战。

由于 ACME CA 在查找 TXT 记录以进行挑战验证时遵循 DNS 标准，因此您可以使用 CNAME 记录将挑战的应答委托给其他 DNS 区域。这可以用于将 _acme-challenge 子域委托给另一个区域。如果您的 DNS 提供商不提供 API，或者 Caddy 的 DNS 插件之一不支持它，这将特别有用。

DNS 提供商支持是一项社区努力。在我们的 Wiki 上了解如何为您的提供商启用 DNS 挑战。

按需 TLS

Caddy 开创了一种我们称之为 按需 TLS 的新技术，它在第一次需要它的 TLS 握手期间动态获取新证书，而不是在配置加载时。至关重要的是，这不需要在配置中预先硬编码域名。

许多企业依靠此独特功能来扩展其 TLS 部署，从而降低成本，并在服务数万个站点时消除运营难题。

如果满足以下条件，按需 TLS 非常有用

• 您在启动或重新加载服务器时不知道所有域名，
• 域名可能无法立即正确配置（DNS 记录尚未设置），
• 您无法控制域名（例如，它们是客户域名）。

启用按需 TLS 后，您无需在配置中指定域名即可获取它们的证书。相反，当收到 Caddy 尚未拥有证书的服务器名称 (SNI) 的 TLS 握手时，握手会保持，同时 Caddy 获取要用于完成握手的证书。延迟通常只有几秒钟，并且只有初始握手速度较慢。所有未来的握手都很快，因为证书被缓存和重用，并且续订在后台进行。未来的握手可能会触发证书的维护以保持续订，但如果证书尚未过期，则此维护会在后台进行。

使用按需 TLS

必须同时启用和限制按需 TLS，以防止滥用。

如果使用 JSON 配置，则在 TLS 自动化策略中启用按需 TLS；如果使用 Caddyfile，则在 带有 tls 指令的站点块中启用。

为了防止滥用此功能，您必须配置限制。这在 JSON 配置的 automation 对象或 Caddyfile 的 on_demand_tls 全局选项中完成。限制是“全局的”，并且无法按站点或按域配置。主要限制是“询问”端点，Caddy 将向其发送 HTTP 请求，以询问它是否有权获取和管理握手中域名的证书。这意味着您需要一些内部后端，例如，可以查询数据库的帐户表，以查看客户是否已使用该域名注册。

请注意您的 CA 发放证书的速度。如果超过几秒钟，这将对用户体验产生负面影响（仅针对第一个客户端）。

由于其延迟性质和防止滥用所需的额外配置，我们建议仅在您的实际用例如上所述时才启用按需 TLS。

有关有效使用按需 TLS 的更多信息，请参阅我们的 Wiki 文章。

错误

如果证书管理发生错误，Caddy 会尽力继续运行。

默认情况下，证书管理在后台执行。这意味着它不会阻止启动或减慢您的站点速度。但是，这也意味着即使在所有证书都可用之前，服务器也会运行。在后台运行允许 Caddy 在很长一段时间内以指数退避重试。

如果获取或续订证书时发生错误，则会发生以下情况

1. Caddy 在短暂暂停后重试一次，以防万一只是侥幸
2. Caddy 短暂暂停，然后切换到下一个启用的挑战类型
3. 在尝试所有启用的挑战类型后，它会尝试下一个配置的颁发者
   • Let's Encrypt
   • ZeroSSL
4. 在尝试所有颁发者后，它会呈指数退避
   • 尝试之间最多 1 天
   • 最多 30 天

在使用 Let's Encrypt 重试期间，Caddy 会切换到他们的 暂存环境 以避免速率限制问题。这不是一个完美的策略，但总的来说它很有帮助。

ACME 挑战至少需要几秒钟，内部速率限制有助于缓解意外滥用。除了您或 CA 配置的速率限制之外，Caddy 还使用内部速率限制，以便您可以向 Caddy 提供包含一百万个域名的盘子，它将逐步但尽可能快地为所有域名获取证书。Caddy 的内部速率限制目前为每个 ACME 帐户每 10 秒 10 次尝试。

为了避免泄漏资源，当配置更改时，Caddy 会中止正在进行的任务（包括 ACME 事务）。虽然 Caddy 能够处理频繁的配置重新加载，但请注意此类操作注意事项，并考虑批量配置更改以减少重新加载，并让 Caddy 有机会实际完成在后台获取证书。

颁发者回退

Caddy 是第一个（也是目前唯一一个）支持完全冗余、自动故障转移到其他 CA 的服务器，以防万一无法成功获取证书。

默认情况下，Caddy 启用两个与 ACME 兼容的 CA：Let's Encrypt 和 ZeroSSL 。如果 Caddy 无法从 Let's Encrypt 获取证书，它将尝试使用 ZeroSSL；如果两者都失败，它将退避并在稍后重试。在您的配置中，您可以自定义 Caddy 用于获取证书的颁发者，无论是通用还是特定名称。

存储

Caddy 会将其 配置的存储设施（或默认设施，如果未配置——有关详细信息，请参阅链接）中存储公共证书、私钥和其他资产。

使用默认配置时，您需要知道的主要事项是 $HOME 文件夹必须是可写且持久的。 为了帮助您进行故障排除，如果指定了 --environ 标志，Caddy 会在启动时打印其环境变量。

任何配置为使用相同存储的 Caddy 实例都将自动共享这些资源，并作为集群协调证书管理。

在尝试任何 ACME 事务之前，Caddy 将测试配置的存储以确保它是可写的并且具有足够的容量。这有助于减少不必要的锁争用。

通配符证书

当 Caddy 配置为服务于具有符合条件的通配符名称的站点时，它可以获取和管理通配符证书。如果站点名称只有其最左侧的域标签是通配符，则该站点名称符合通配符的条件。例如，*.example.com 符合条件，但以下这些不符合：sub.*.example.com、foo*.example.com、*bar.example.com 和 *.*.example.com。（这是 WebPKI 的限制。）

如果使用 Caddyfile，Caddy 会按字面意思理解站点名称，并将其视为证书主题名称。换句话说，定义为 sub.example.com 的站点将导致 Caddy 管理 sub.example.com 的证书，而定义为 *.example.com 的站点将导致 Caddy 管理 *.example.com 的通配符证书。您可以在我们的 常用 Caddyfile 模式页面上看到此演示。如果您需要不同的行为，JSON 配置使您可以更精确地控制证书主题和站点名称（“主机匹配器”）。

从 Caddy 2.10 开始，当自动化通配符证书时，Caddy 将对配置中的单个子域使用通配符证书。除非明确配置为这样做，否则它不会获取单个子域的证书。

通配符证书代表了广泛的权限，只有当您有如此多的子域以至于为它们管理单个证书会给 PKI 带来压力或导致您达到 CA 强制的速率限制时，或者如果隐私权衡值得冒着在密钥泄露的情况下暴露 DNS 区域的风险时，才应使用通配符证书。请注意，通配符证书本身并不能提供隐藏特定子域的隐私：除非启用加密客户端问候 (ECH)，否则它们仍然在 TLS ClientHello 数据包中公开。（见下文。）

注意： Let's Encrypt 要求 DNS 挑战才能获得通配符证书。

加密客户端问候 (ECH)

通常，TLS 握手涉及以明文形式发送 ClientHello，包括服务器名称指示 (SNI；正在连接到的域)。这是因为其中包含加密握手后连接所需的参数。当然，这会暴露域名，这是 ClientHello 中最敏感的部分，暴露给任何可以窃听连接的人，即使他们不在您的直接物理范围内。它会揭示您正在连接到哪个服务，而目标 IP 可能服务于许多不同的站点，并且这就是一些政府审查互联网的方式。

使用加密客户端问候，客户端可以通过将真实的 ClientHello 包装在“外部”ClientHello 中来保护域名，该“外部”ClientHello 建立了解密“内部”ClientHello 的参数。但是，许多移动部件需要完美地结合在一起才能使其工作并提供实际的隐私优势。

首先，客户端需要知道要使用哪些参数或配置来加密 ClientHello。此信息包括公钥和“外部”域名（“公共名称”）等。此配置必须以可靠的方式发布或分发。

从理论上讲，您可以将其写在纸上并分发给所有人，但大多数主要浏览器都支持在连接到站点时查找包含 ECH 参数的 HTTPS 类型 DNS 记录。因此，您需要：(1) 生成 ECH 配置（公钥/私钥对，以及其他参数），然后 (2) 创建一个 HTTPS 类型 DNS 记录，其中包含 base64 编码的 ECH 配置。

或者... 您可以让 Caddy 为您完成这一切。Caddy 是第一个也是唯一一个可以自动生成、发布和提供 ECH 配置的 Web 服务器。

发布 HTTPS 记录后，客户端需要在连接到您的站点时执行 HTTPS 记录的 DNS 查找。通常，DNS 查找是以明文形式进行的，这会损害生成的 ECH 握手的安全性，因此浏览器需要使用安全的 DNS 协议，如 DNS-over-HTTPS (DoH) 或 DNS-over-TLS (DoT)。根据浏览器，这可能需要手动启用。

客户端安全下载 ECH 配置后，它会使用嵌入的公钥加密 ClientHello，并继续连接到您的站点。然后，Caddy 解密内部 ClientHello 并继续为您的站点提供服务，而域名永远不会以明文形式出现在网络上。

部署注意事项

ECH 是一项细致入微的技术。即使 Caddy 完全自动化了 ECH，为了获得最大的隐私优势，也需要考虑很多事情。您还应该了解各种权衡。

发布

如果域名已经存在记录，Caddy 将仅为该域名创建 HTTPS 记录。这可以防止破坏可能被通配符覆盖的子域的 DNS 查找。确保您的站点至少有一个指向您的服务器的 A/AAAA 记录。如果您仅对 DNS 记录使用通配符，则通配符域也需要出现在您的 Caddy 配置中。

Caddy 不会为具有 CNAME 记录的域名发布 HTTPS 记录。

ECH GREASE

如果您打开 Wireshark，然后连接到任何站点（即使是不支持 ECH 的站点），在现代版本的 Firefox 或 Chrome 等主要浏览器中（即使禁用 ECH），您可能会注意到它的握手包括 encrypted_client_hello 扩展

这样做的目的是使真实的 ECH 握手与明文握手无法区分。如果 ECH 握手看起来与普通握手不同，审查员可以仅阻止 ECH 握手，而将附带损害/附带损害降到最低。但是，如果他们阻止任何具有合理 ECH 扩展的握手，他们实际上会关闭大部分互联网。（目标是增加广泛审查的成本。）

这主要在对连接进行故障排除时很重要。

密钥轮换

与证书密钥一样，长时间使用相同的密钥不是一个好习惯（并且可能完全不安全）。因此，ECH 密钥应定期轮换。与证书不同，ECH 配置不会严格过期。但是，服务器仍应轮换它们。

密钥轮换很棘手，因为客户端需要了解更新后的密钥。如果服务器只是将旧密钥替换为新密钥，则所有 ECH 握手都会失败，除非立即通知客户端新密钥。但是，仅仅发布更新后的密钥是不够的。现实情况是，DNS 记录具有 TTL，并且解析器会缓存响应等。客户端可能需要几分钟、几小时甚至几天才能查询更新后的 HTTPS 记录并开始使用新的 ECH 配置。

出于这个原因，服务器应该在一段时间内继续支持旧的 ECH 配置。不这样做可能会大规模地暴露服务器名称的明文。

然而，这可能还不够。一些客户端由于各种原因仍然无法获取更新的密钥，并且每次发生这种情况时，都存在暴露服务器名称的风险。因此，需要另一种方法在连接过程中带内向客户端提供更新的配置。这就是外部名称的用途。

外部名称

“外部” ClientHello 是一个正常的 ClientHello，但有两个细微的差异，只有源服务器知道

1. SNI 扩展是伪造的
2. ECH 扩展是真实的

该“外部” SNI 扩展包含保护您的真实域名的公共名称。这个名称可以是任何东西，但您的服务器必须是公共名称的权威，因为 Caddy 将为其获取证书。

如果客户端尝试建立 ECH 连接，但服务器无法解密内部 ClientHello，它实际上可以使用外部 ClientHello 完成握手，并使用外部名称的证书。此安全连接严格仅用于向客户端发送当前的 ECH 配置；即，它是临时的 TLS 连接，仅用于完成初始 TLS 连接的目的。不传输任何应用程序数据：只有 ECH 密钥。一旦客户端拥有更新的密钥，它就可以按预期建立 TLS 连接。

通过这种方式，真实的服务器名称仍然受到保护，并且不同步的客户端仍然能够连接，这都是安全性的重要要素。

外部名称可以是您网站的域名之一、子域名或指向您服务器的任何其他域名。我们建议选择一个通用名称。例如，Cloudflare 为数百万个站点提供服务，幕后名称为 cloudflare-ech.com。这对于增加您的匿名集的大小非常重要。

匿名集

为了最大限度地提高 ECH 的隐私优势，请努力最大化您的匿名集的大小。本质上，此集合由对观察者具有相同行为的面向客户端的服务器组成。其理念是观察者无法轻易减少/推断客户端正在连接的可能站点或服务。

在实践中，我们建议为您的所有站点仅使用一个公共名称。（每个 ECH 配置只有一个公共名称，因此这意味着在任何给定时间只有一个活动的 ECH 配置。）如果您在集群中运行 Caddy，Caddy 会自动与其他实例共享和协调 ECH 配置，这为您解决了这个问题。

推到极端，这意味着互联网上的每个站点都可能或应该位于单个 IP 地址和一个公共名称之后...

中心化

... 这将我们带到下一个主题：中心化。对 ECH 的批评之一是它倾向于促使中心化。它至少以两种方式做到这一点：(1) 客户端倾向于使用 DoH/DoT 进行 DNS 查询，这会将所有 DNS 查询通过少数提供商发送，以及 (2) 最大化大规模匿名集的大小。

当使用 DoH 或 DoT 时，DNS 查询都通过 DoH/DoT 提供商。在客户端和提供商之间，DNS 数据是加密的，但在提供商和 DNS 服务器之间，数据未加密。全局 DoH/DoT 有效地将所有重要的明文 DNS 流量汇集到少数几个大的管道中，这些管道很容易被观察到... 或发生故障。

同样，如果我们真正最大限度地扩大匿名集，所有站点都将受到单个公共名称（如 cloudflare-ech.com）的保护。这对隐私有利，但整个互联网都将受制于 Cloudflare 和该域名。现在，最大限度地扩大到那种程度并非必要或实用，但理论上的含义仍然有效。

我们建议每个组织或个人为其所有站点选择一个名称并使用该名称，在大多数情况下，这应该提供足够的隐私。但是，请针对您的具体情况咨询专家，了解您的个人威胁模型。

子域名隐私

借助 ECH，如果部署正确，现在理论上可以对侧信道保持子域名的秘密/私密性。

大多数站点不需要这样做，因为一般来说，子域名是公开信息。我们建议不要将敏感信息放在域名中。尽管如此...

为了避免将敏感子域名泄露到证书透明度 (CT) 日志，请改用通配符证书。换句话说，不要在您的配置中放入 sub.example.com，而是放入 *.example.com。（有关重要信息，请参阅通配符证书。）

然后，在 Caddy 中启用 ECH。通配符证书与 ECH 结合使用应正确隐藏子域名，只要尝试连接到它的每个客户端都使用 ECH 并具有强大的实现。（您仍然受制于客户端以保护隐私。）

启用 ECH

由于功能性 ECH 需要将配置发布到 DNS 记录，因此您需要一个内置了 caddy-dns 模块的 Caddy 构建版本，用于您的 DNS 提供商。

然后，使用 Caddyfile，在全局选项中指定您的 DNS 提供商配置，以及您想要使用的 ECH 公共名称

{
	dns <provider config...>
	ech example.com
}

记住

• DNS 提供商模块必须已插入，并且您必须具有适用于您的提供商/帐户的正确配置。
• ECH 公共名称应指向您的服务器。Caddy 将为其获取证书。它不必是您网站的域名之一。

如果使用 JSON，请将这些属性添加到 tls 应用程序

"encrypted_client_hello": {
	"configs": [
		{
			"public_name": "example.com"
		}
	]
},
"dns": {
	"name": "<provider name>",
	// provider configuration
}

这些配置将为您的所有站点启用 ECH 并发布 ECH 配置。如果您需要自定义行为或具有高级设置，JSON 配置提供更大的灵活性。

验证 ECH

围绕 ECH 的工具仍然不多，因此在撰写本文时，验证其是否工作的最佳和最通用的方法是使用 Wireshark 并在 ServerName 字段中查找您的公共名称。

首先，启动您的服务器，并查看日志中是否提到针对您的域名的“已发布 ECH 配置列表”之类的消息。（如果您在发布时遇到任何错误，请确保您的 DNS 提供商模块支持 libdns 1.0，并且如果您遇到问题，请在您的提供商的存储库中提交问题。）Caddy 还应获取公共名称的证书。

接下来，确保您的浏览器已启用 ECH；这可能需要启用 DoH/DoT。清除浏览器（或系统）的 DNS 缓存也是一个好主意，以确保它将获取新发布的 HTTPS 记录。我们还建议关闭浏览器，或者至少打开一个新的隐私标签页，以确保它不会重用现有连接。

然后，打开 Wireshark 并开始监听适当的网络接口。在 Wireshark 收集数据包时，在浏览器中加载您的站点。然后您可以暂停 Wireshark。找到您的 TLS ClientHello，您应该在 ServerName 字段中看到公共名称，而不是您连接的实际域名。

请记住：即使未使用 ECH，您仍然可能会看到 encrypted_client_hello 扩展。关键指标是 SNI 值。如果 ECH 工作正常，您永远不应在 Wireshark 中看到明文的真实站点名称。

如果您在 ECH 部署中遇到问题，请首先在我们的论坛中提问。如果是错误，您可以在 GitHub 上提交问题。

ECH 在存储中

ECH 配置存储在配置的存储模块（默认为文件系统）的 数据目录 中，位于 ech/configs 文件夹下。

下一个文件夹是 ECH 配置 ID，它是随机生成的，相对而言并不重要。规范建议使用随机性来帮助缓解指纹识别/跟踪。

元数据辅助文件帮助 Caddy 跟踪上次发布发生的时间。这可以防止在每次配置重新加载时对您的 DNS 提供商进行轰炸式请求。如果您必须重置此状态，您可以安全地删除元数据文件。但是，这也可能会重置密钥轮换的时间。您也可以进入该文件并清除有关发布的信息。