1. 项目概述为什么ECH是Caddy的“杀手锏”如果你用过Caddy肯定对它的“自动HTTPS”印象深刻——开箱即用零配置搞定证书。但今天要聊的是Caddy里一个更“酷”的功能加密的ClientHello。这玩意儿听起来有点技术但说白了它解决的是一个长期存在的隐私痛点当你访问一个HTTPS网站时你的浏览器在建立加密连接之前会先“喊”一嗓子“我要找谁”这个“喊话”就是ClientHello里面包含了你要访问的域名。问题在于这个“喊话”是明文的任何中间的网络设备都能看到你要去哪个网站。ECH要做的就是给这个“喊话”也加上一层加密让窥探者连你想访问哪个网站都看不到。Caddy作为第一个默认启用自动HTTPS的服务器在隐私保护上又走在了前面。它不仅能自动管理证书现在还能自动生成、发布和管理ECH所需的密钥配置把整个流程也“自动化”了。这意味着作为站长你不再需要去折腾复杂的密钥生成、DNS记录发布和轮换策略Caddy帮你全包了。这篇文章我就带你从零开始彻底搞懂Caddy的ECH功能从配置、证书管理到实战排障分享我踩过的坑和总结的经验让你也能轻松为自己的站点加上这层“隐身衣”。2. ECH核心原理与Caddy的实现机制2.1 ECH到底在保护什么要理解ECH的价值得先看看传统的TLS握手流程。当你访问https://my-secret-site.example.com时你的客户端比如浏览器会向服务器发起一个TLS握手。握手的第一步就是发送ClientHello消息。这个消息里有个关键字段叫SNI它的值就是my-secret-site.example.com。在ECH出现之前这个SNI是明文传输的。你的ISP、公共Wi-Fi提供者或者任何路径上的网络设备都能轻松看到你正在尝试连接my-secret-site.example.com。虽然后续的通信内容被加密了但“你要访问哪个网站”这个元信息已经泄露了。ECH的目标就是加密这个SNI。它通过一个巧妙的“套娃”结构来实现外层ClientHello客户端使用一个公开的、无害的域名称为public_name比如example.com生成一个常规的ClientHello。这个外层的SNI就是example.com对任何观察者都是可见的。内层ClientHello真实的、想要访问的域名比如my-secret-site.example.com被加密后作为一个特殊的扩展encrypted_client_hello放在外层ClientHello里。服务器收到后先用example.com对应的证书完成外层握手解密encrypted_client_hello扩展得到真实的内层ClientHello再用my-secret-site.example.com对应的证书继续完成整个TLS握手。这样一来网络上的旁观者只能看到你在和example.com通信而不知道你实际访问的是其下的哪个具体子站。2.2 Caddy如何自动化ECHCaddy的厉害之处在于它把ECH这个复杂协议的部署和管理变得和自动HTTPS一样简单。整个过程可以概括为“生成、发布、服务”三步闭环自动生成密钥对当你为站点启用ECH时Caddy会自动为你的域名生成ECH所需的公私钥对HPKE密钥。你完全不用关心密钥的格式、长度或存储位置。自动发布到DNSECH配置主要是公钥需要发布到DNS的HTTPS记录中以便客户端在连接前就能获取。Caddy集成了众多DNS提供商模块通过caddy-dns插件可以自动调用DNS提供商的API将生成的ECH配置写入对应域名的HTTPS记录。这是最关键也最容易出问题的一步后面会详细讲。自动提供服务当支持ECH的客户端如新版Chrome、Firefox发起连接时Caddy能正确识别并处理encrypted_client_hello扩展完成上述的“解密-再握手”流程。注意ECH的生效是一个系统性工程。仅仅服务器Caddy支持并配置了ECH是不够的。客户端必须也支持ECH并已启用同时客户端需要通过安全DNS如DoH或DoT查询到目标域名的HTTPS记录内含ECH配置才能发起加密的ClientHello。如果客户端通过不安全的DNS解析或者缓存了旧的没有ECH配置的DNS记录ECH也无法生效。2.3 密钥轮换与匿名集高级考量Caddy在自动化之外也妥善处理了ECH部署中的两个高级问题密钥轮换长期使用固定的ECH密钥存在风险。Caddy支持定期自动轮换密钥。更贴心的是在发布新密钥后的一段时间内Caddy会同时支持新旧两套配置。这个“重叠期”非常关键它考虑了DNS记录的传播延迟和客户端缓存能有效避免因密钥切换导致的连接失败。轮换策略和周期可以在配置中调整。Public Name与匿名集public_name的选择有讲究。理想情况下一个组织或服务下的所有子域名都使用同一个public_name例如所有*.example.com都用example.com作为public_name。这样做的好处是增大了“匿名集”——所有访问*.example.com的用户在旁观者看来都在访问同一个example.com使得追踪特定子域名的行为变得更加困难。Caddy的配置鼓励这种最佳实践。3. 实战配置从Caddyfile到JSON的完整指南理论讲完我们动手配置。Caddy支持通过Caddyfile和JSON两种方式配置ECH前者对人类友好后者功能更强大精准。我会以example.com和其子站app.example.com为例演示两种配置方法。3.1 使用Caddyfile配置推荐初学者Caddyfile的配置非常直观主要在全局选项块{ }中完成。# 首先配置你的DNS提供商。这里以Cloudflare为例。 # 你需要一个包含对应caddy-dns插件的Caddy版本。 { # 配置DNS提供商模块用于自动管理DNS记录包括HTTPS记录 dns cloudflare { # 这里填写你的Cloudflare API Token # 环境变量方式更安全{$CLOUDFLARE_API_TOKEN} api_token your_cloudflare_api_token_here } # 启用ECH并指定public_name。 # 这里我们选择根域名作为public_name以保护所有子域名。 ech example.com } # 定义你的站点 app.example.com { # 反向代理到本地的应用服务 reverse_proxy localhost:8080 # TLS/HTTPS由Caddy自动管理无需额外配置 } # 另一个站点也自动享受ECH保护 blog.example.com { file_server { root /var/www/blog } }配置解析与注意事项dns指令这是ECH能自动发布配置的前提。你必须使用一个Caddy内置了对应模块的DNS提供商如Cloudflare, Google Cloud DNS, Route53等。你需要提供该提供商认证所需的凭证如API Token。务必通过环境变量来管理这些敏感凭证不要直接写在配置文件中。ech指令指定public_name。这个域名必须是你能通过上面配置的DNS提供商权威管理的域名。通常使用你的根域名。站点定义你会发现在站点块内部我们完全没有提及TLS或ECH。这是因为一旦在全局启用了ECHCaddy会自动为所有通过它服务的、匹配public_name或其子域的站点应用ECH配置。这就是“约定优于配置”的魅力。一个我踩过的坑如果你只为子域名配置了DNS记录比如只有app.example.com的A记录但没有example.com的根域名记录Caddy在尝试为example.com发布HTTPS记录时可能会失败。虽然ECH可能仍会为子域名工作如果客户端通过其他方式获得了配置但为了可靠性建议确保你的public_name本例中的example.com在DNS中有一条有效的记录可以是A记录指向服务器或者CNAME甚至是一条显式的ALIAS/ANAME记录。3.2 使用JSON配置用于精细控制JSON配置提供了更底层的控制能力适合复杂场景或通过Caddy API动态管理。{ apps: { http: { servers: { srv0: { listen: [:443], routes: [ { match: [{host: [app.example.com]}], handle: [ { handler: reverse_proxy, upstreams: [{dial: localhost:8080}] } ] } ] } } }, tls: { automation: { policies: [ { subjects: [app.example.com], // 关键在TLS自动化策略中启用ECH encrypted_client_hello: { configs: [ { public_name: example.com // 指定public_name } ] } } ], // 配置DNS提供商用于发布ECH配置 dns: { provider: { name: cloudflare, api_token: your_cloudflare_api_token_here } } } } } }JSON配置的要点位置ECH配置位于apps.tls.automation.policies之下这意味着它可以针对不同的证书策略进行差异化设置。例如你可以只为*.internal.example.com启用ECH而为公开的*.example.com禁用。dns配置与Caddyfile不同JSON中的DNS提供商配置是tls.automation的一个子项专用于证书和ECH相关的DNS操作。灵活性你可以为不同的subjects域名列表配置不同的public_name甚至完全关闭某些域名的ECH。这在多租户或复杂域名结构下非常有用。3.3 构建带DNS插件的Caddy默认的Caddy二进制文件可能不包含你所需的DNS提供商模块。你需要使用Caddy的构建工具xcaddy来定制。# 安装 xcaddy go install github.com/caddyserver/xcaddy/cmd/xcaddylatest # 使用 xcaddy 构建包含 cloudflare DNS 模块的 Caddy xcaddy build --with github.com/caddy-dns/cloudflare # 或者如果你需要多个DNS模块 xcaddy build \ --with github.com/caddy-dns/cloudflare \ --with github.com/caddy-dns/route53 \ --with github.com/caddy-dns/digitalocean构建完成后使用./caddy list-modules命令确认dns.providers.cloudflare等模块已存在。4. 证书管理与ECH的协同工作流启用ECH后证书管理流程与标准的Caddy自动HTTPS基本一致但多了ECH配置的发布环节。4.1 完整的自动化流程启动/重载Caddy读取配置识别需要服务的域名app.example.com,blog.example.com。证书获取对于每个公网域名Caddy通过ACME协议默认使用Let‘s Encrypt申请证书。如果域名是*.example.com形式且配置了DNS质询则会申请通配符证书。ECH配置生成Caddy为指定的public_nameexample.com生成ECH密钥对。DNS记录发布Caddy调用配置的DNS提供商API执行两个关键操作ACME DNS质询如果是通配符证书会设置_acme-challenge.example.com的TXT记录。ECH配置发布在example.com的HTTPS记录中添加生成的ECH公钥配置。服务就绪证书和ECH配置都就绪后Caddy开始监听端口提供服务。此时它既能响应普通的TLS握手也能处理带encrypted_client_hello扩展的握手。4.2 存储与状态管理Caddy将所有状态存储在配置的存储后端默认是文件系统位于$HOME/.local/share/caddy或$CADDYPATH。证书存储在certificates目录下按ACME账户和域名组织。ECH配置存储在ech/configs目录下。这里会保存ECH的密钥材料和元数据。重要提示元数据文件记录了配置的发布时间。Caddy在重载时检查此元数据如果发现配置已发布且未过期则不会重复调用DNS API发布。如果你需要强制重新发布ECH配置例如DNS记录被意外删除可以删除对应的元数据文件然后重载Caddy。但要注意这可能会影响密钥轮换的计划。4.3 与“按需TLS”的配合“按需TLS”是Caddy的另一大特色它允许在首次收到某个域名的TLS握手时再动态申请证书非常适合托管大量未知域名的场景。ECH可以与按需TLS协同工作。配置要点在按需TLS的配置中你需要定义一个“询问”端点Caddy在收到未知域名的握手时会去查询该端点是否允许申请证书。ECH的考虑当按需TLS被触发时Caddy需要为该域名申请证书。同时它也需要处理ECH。这里的关键是public_name的确定。通常你需要预设一个或一组public_name。例如如果你托管*.customer.com你可以设置public_name为customer.com。Caddy会为这个public_name预生成ECH配置并发布到DNS。当按需获取xxx.customer.com的证书时ECH已经就绪。潜在挑战如果每个客户都有完全不同的根域名预定义public_name就比较困难。一种方案是为每个客户域名预先配置ECH可能通过自动化脚本另一种方案是评估是否真的需要为所有域名启用ECH或许可以仅对主要服务启用。5. 验证、排障与高级调试指南配置好了怎么知道ECH真的在工作出了问题怎么查这部分是真正的干货。5.1 如何验证ECH已生效不能只看浏览器地址栏的锁图标因为那只表示HTTPS连接成功。我们需要验证SNI是否被加密。方法一使用浏览器开发者工具以Chrome为例打开开发者工具F12切换到“网络”标签页。清空列表然后访问你配置了ECH的站点如https://app.example.com。点击该请求查看“安全”标签页。在“连接”部分寻找“加密的ClientHello”字段。如果显示“是”并且“服务器名称指示SNI”字段显示的是你的public_name如example.com而不是真实域名app.example.com那么恭喜ECH生效了注意如果SNI显示为真实域名说明ECH协商失败连接回退到了明文SNI模式。方法二使用命令行工具curl(需支持ECH)新版curl编译了ECH支持后可以使用。# 这是一个示例命令具体参数取决于你的curl版本和ECH实现 curl --ech-config ... https://app.example.com更通用的方法是使用专门的测试工具比如Cloudflare的ech-check工具在线或自托管。方法三网络抓包分析最可靠使用Wireshark或tcpdump抓取TLS握手包。在客户端机器上开始抓包过滤端口443。访问你的站点。在抓包结果中找到TLS Client Hello包。展开TLS协议详情查看“Extension: server_name”字段。ECH生效该字段显示的是public_name如example.com并且会存在一个“Extension: encrypted_client_hello”扩展。ECH未生效该字段直接显示真实域名如app.example.com且没有encrypted_client_hello扩展或者有扩展但协商失败。重要提示浏览器和操作系统有缓存。在测试ECH前请务必清理DNS缓存如chrome://net-internals/#dns并使用隐身模式或新的浏览器会话进行测试以避免旧连接的影响。5.2 常见问题排查表问题现象可能原因排查步骤Caddy日志报错无法发布HTTPS记录1. DNS提供商凭证错误或权限不足。2. 域名不在该DNS提供商处管理。3. 网络问题无法访问DNS提供商API。1. 检查dns配置中的API Token/Key确保其有修改DNS记录的权限。2. 使用dig short NS example.com确认域名的权威NS服务器是否匹配你配置的提供商。3. 查看Caddy日志详情通常会有来自DNS提供商API的错误信息。浏览器开发者工具显示SNI仍是真实域名1. 客户端不支持或未启用ECH。2. 客户端未通过安全DNSDoH/DoT解析获取不到HTTPS记录。3. DNS缓存导致客户端获取的是旧的、没有ECH配置的HTTPS记录。4. Caddy未成功发布ECH配置。1. 确认浏览器版本并检查chrome://flags/#encrypted-client-hello是否已启用。2. 检查操作系统或浏览器的DNS设置是否使用了DoH。3. 清理所有DNS缓存浏览器、OS。4. 使用dig short HTTPS example.com或kdig example.com typeHTTPS查询域名的HTTPS记录确认其中包含ech配置。连接失败出现SSL/TLS错误1. ECH密钥配置不匹配。2.public_name的证书有问题。3. 服务器不支持客户端发送的ECH版本或密码套件。1. 检查Caddy日志看是否有ECH相关的错误。2. 确认public_name如example.com本身有有效的TLS证书Caddy应已自动获取。3. 尝试在客户端暂时禁用ECH看连接是否恢复以确认问题是ECH引起。部分子域名ECH生效部分不生效1. 未使用通配符证书且部分子域名证书未包含ECH扩展(实际上ECH配置绑定于public_name的HTTPS记录与具体子域名证书无关)更正更可能的原因是客户端访问不同子域名时DNS解析路径或缓存状态不同导致一个获取到了HTTPS记录另一个没有。1. 核心检查点对所有子域名执行dig HTTPS subdomain看是否都能返回相同的、包含ECH配置的HTTPS记录理论上因为HTTPS记录在example.com这一级所有*.example.com都应继承。如果不一致可能是DNS配置或缓存问题。2. 确保所有子域名的DNS解析最终都指向同一个Caddy实例。5.3 高级调试深入Caddy日志Caddy的日志是排障的金矿。启动Caddy时通过--log参数调整日志级别。caddy run --config Caddyfile --log-level DEBUG在DEBUG级别的日志中关注以下关键词encrypted_client_hello或ech查看ECH配置的生成、发布过程。acme查看证书申请和续期过程这与ECH的DNS发布有时序关联。dns.providers查看与DNS提供商API的交互详情特别是发布HTTPS记录的成功或失败信息。on_demand_tls如果使用了按需TLS这里会有触发和询问端点的日志。一个实战案例我曾遇到ECH配置发布成功但客户端不生效的情况。DEBUG日志显示Caddy成功调用了Cloudflare API添加了HTTPS记录。但用dig查询却看不到。最后发现是Cloudflare的“代理”状态导致的。当域名的橙色云朵打开代理开启时Cloudflare会接管DNS并可能过滤或修改某些高级记录类型。将DNS记录状态改为“仅DNS”灰色云朵后HTTPS记录立即可以查询到ECH也随之生效。6. 生产环境部署建议与性能考量将ECH投入生产环境除了功能正确还需要考虑稳定性、安全性和性能。6.1 DNS提供商的选择与配置选择支持度高的提供商优先选择Caddy官方caddy-dns支持列表里成熟稳定的提供商如Cloudflare、Google Cloud DNS、Amazon Route 53等。社区维护的模块可能更新不及时。使用最小权限凭证不要使用账户全局API Key。为Caddy创建专用的API Token并只授予它“编辑DNS记录”的必要权限。在Cloudflare中可以创建一个自定义令牌权限选择“Zone.DNS” - “Edit”。考虑API限速大规模部署时频繁的配置重载可能导致大量DNS API调用。了解你的DNS提供商的API速率限制并在Caddy配置中适当调整dns模块的配置例如增加重试间隔和次数。6.2 监控与告警证书与ECH配置健康度监控Caddy的日志特别是错误日志。可以设置告警抓取“error”级别且包含“encrypted_client_hello”、“dns”、“acme”等关键词的日志条目。DNS记录验证定期例如每半小时从外部网络使用dig或kdig命令检查你的public_name的HTTPS记录是否存在且包含有效的ech值。记录丢失或配置错误是ECH失效的常见原因。客户端支持度统计如果你的应用有前端可以考虑通过JavaScript在安全上下文下检查window.connection或相关API来统计支持并成功使用ECH的连接比例这有助于评估ECH带来的实际隐私收益覆盖范围。6.3 性能影响评估启用ECH对服务器和客户端都会引入轻微的开销计算开销服务器需要多进行一次HPKE解密操作。对于现代服务器CPU而言单次握手增加的这点开销微乎其微但在超高并发每秒数万次新握手的场景下需要关注CPU使用率的变化。实测在主流云服务器上启用ECH对QPS的影响通常在1%以内。握手延迟理想情况下由于ECH需要客户端先获取HTTPS记录可能会增加首次连接的延迟多一次DNS查询。但HTTPS记录可以缓存TTL通常较长且客户端可以预取因此对后续连接和整体用户体验影响很小。更重要的是ECH握手本身比常规握手多一轮加密操作但这是在同一个RTT内完成的不会增加额外的网络往返。建议对于绝大多数网站可以毫不犹豫地启用ECH。对于极端性能敏感、且客户群高度可控例如内部API所有客户端已知且不支持ECH的场景可以评估是否必要。永远不要因为臆测的性能问题而放弃安全增强特性应该先测试。6.4 备份与灾难恢复ECH的密钥存储在Caddy的数据目录中。务必将其纳入你的备份策略。备份什么整个Caddy数据目录默认在$HOME/.local/share/caddy或者至少备份ech/configs子目录。恢复场景当你在新服务器上恢复Caddy时恢复整个数据目录可以保证ECH密钥不变。这意味着客户端缓存的旧ECH配置仍然有效避免了因密钥变更导致的连接失败。如果丢失了ECH私钥你需要重载配置以生成新密钥并发布到DNS这会导致使用旧配置的客户端在缓存过期前无法连接。因此备份ECH密钥和备份TLS证书私钥同等重要。最后保持Caddy版本更新。ECH协议和其实现仍在演进中更新版本通常会带来更好的兼容性、性能和安全性修复。在升级前务必在测试环境验证ECH功能是否正常。