企业官网建设流程全解析

Caddy ECH 支持完整指南：隐藏 TLS 握手里的域名

【免费下载链接】caddyFast and extensible multi-platform HTTP/1-2-3 web server with automatic HTTPS项目地址: https://gitcode.com/GitHub_Trending/ca/caddy

握手刚开始，浏览器就把"我要访问哪个域名"（SNI，Server Name Indication，服务器名称指示）用明文写在第一个数据包里。公司网关、运营商、同一 Wi-Fi 下的人扫一眼就知道你打开了哪个站点，哪怕后续流量全程加密。Caddy 的 Encrypted Client Hello（ECH，加密客户端问候）功能就是为堵住这个洞而做的：它把真实握手内容整体加密，外面套一层用公共域名冒充的握手，让旁路观察者只看到那个公共名。

这是什么

ECH 是 Caddy TLS 应用内置的一个子功能，官方目前将其标记为实验性。

它接管了三件事：自动生成 ECH 密钥并定期轮换，把 ECH 配置写入 DNS 记录，以及让服务器按 RFC 9180 标准响应带 ECH 扩展的客户端。你只管声明一个公共名称，剩下的密钥管理全部自动化。

解决了什么问题

• SNI 不再明文暴露：真实域名藏在加密的 ClientHello 里，旁路只看到公共名称
• 密钥不用你管：HPKE（一种基于 X25519 的轻量密钥封装方案）密钥对由 Caddy 生成，每 30 天轮换，90 天后清除旧密钥
• 配置自动发布：Caddy 把 ECH 配置写进各受保护域名的 HTTPS 类型 DNS 记录（RFC 9460），大多数现代浏览器会直接从 DNS 里读取
• 业务无感：站点仍按原域名正常访问，不需要为每个客户端单独准备配置

上手路径

前置条件

• 一个你能控制 DNS 写入的域名（Caddy 需要调 DNS 提供商接口，通常用 xcaddy 构建时内置对应模块）
• 一个用作公共名称的域名，且它的 DNS 记录指向这台服务器（Caddy 会为它申请证书）

关键配置

下面这段 JSON 是核心：声明公共名称，并指定通过 DNS 发布 ECH 配置。

{ "apps": { "tls": { "encrypted_client_hello": { "configs": [{ "public_name": "shared.example.org" }], "publication": [{ "publishers": { "dns": {} } }] } } } }

dns发布器会复用你在 TLS 应用里配置的全局 DNS 提供商。如果你习惯写 Caddyfile，也可以在全局选项中启用 ECH，再用caddy adapt检查生成的 JSON 是否与上面等价。

从零构建时，用 xcaddy 把需要的 DNS 提供商模块编进二进制：

xcaddy build --with <你的dns提供商模块路径>

启动后 Caddy 会生成密钥、为公共名称申请证书，并向每个受保护域名的 HTTPS 记录里追加ech参数。

验证是否生效

先用 dig 查询某个受保护域名的 HTTPS 记录，确认里面带 ech 参数：

dig +short example.com TYPE65

输出长这样即说明发布成功：

. 300 https 2 . alpn="h3,h2,http/1.1" ech="AAAA..."

再用支持 ECH 的浏览器（建议同时开启 DoH 或 DoT）访问站点，在开发者工具的网络面板查看 TLS 信息，SNI 应显示为公共名称而不是真实域名。

常见坑

1. 现象：dig 查不到 ech 参数。原因：HTTPS 记录发布后本地 DNS 缓存还没过期，或该域名没有任何已存在的记录（Caddy 会主动跳过发布，避免打破通配解析）。处理：等缓存过期后重查；域名解析走通配记录的，先给它加一条明确的 A/AAAA 记录。
2. 现象：日志出现 "domain has CNAME record, so unable to publish ECH data"。原因：CNAME 与 HTTPS 记录互斥，Caddy 不会覆盖 CNAME。处理：该域名改用 A/AAAA 记录解析，或另选子域。
3. 现象：日志提示为公共名称获取证书失败。原因：公共名称的 DNS 没指向服务器，或它根本不存在记录。处理：把公共名称的 A/AAAA 记录指到本机；注意公共名称只用于握手，不会承载应用流量。
4. 现象：客户端依旧走明文 SNI。原因：浏览器不支持 ECH，或没开 DoH/DoT 导致读不到可靠的 HTTPS 记录。处理：换用最新版主流浏览器并启用加密 DNS；未发布的域名会自动回落到普通 TLS，服务不受影响。

适用边界

适合：拥有域名 DNS 管理权、希望隐藏访问行为（比如敏感业务入口、面向特定群体的站点）的运营者。

暂时不需要：内网服务、一次性测试站点，或者不想让 Caddy 代管 DNS 记录的团队——没有发布渠道，绝大多数客户端根本不会启用 ECH，功能形同虚设。

已知限制：ECH 要求 TLS 1.3 起步，Caddy 会把相关连接策略的最低版本自动抬高；部分域名（CNAME、无记录的域名）会被跳过发布；客户端侧依赖 DoH/DoT 时才能稳妥读到配置。协议层面开销很小，主要成本在于多维护一个公共名称域名。功能标记为实验性，字段名和密钥管理细节后续版本可能调整，生产上建议跟进更新说明。

实现核心在 ECH 模块源码，Caddyfile 全局选项到 JSON 的转换逻辑见 httpcaddyfile 适配层。密钥的生成、轮换与发布状态都记录在 Caddy 的存储里，重启后自动恢复，不需要手工备份。

【免费下载链接】caddyFast and extensible multi-platform HTTP/1-2-3 web server with automatic HTTPS项目地址: https://gitcode.com/GitHub_Trending/ca/caddy