Caddy ECH 完整指南：3 步开启加密客户端问候，隐藏网站真实域名

Caddy ECH 完整指南：3 步开启加密客户端问候，隐藏网站真实域名

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

Caddy 的 ECH（Encrypted Client Hello，加密客户端问候）功能，能隐藏你正在访问的是哪个网站。为什么需要它？因为每次建立 HTTPS 连接，浏览器都会以明文报出要访问的域名（SNI）——你在公共 Wi-Fi 下刷网页，ISP、公司网关和任何路上的观察者都能直接列出"你在访问哪些站点"。ECH 把真正的域名加密藏进 TLS 握手内部，外面的人只能看到一个通用的"公共门面"域名。🔒

原理速览：套了公共信封的加密信件

打个比方：普通 HTTPS 像把信塞进快递箱，箱子上贴着"寄往 example.com"，谁路过都看得清。启用 ECH 后，相当于再套一层外层信封——外面写着公开的通用地址（比如shared.example.com），真实收件人写在里面并用密码封好。📮

和以前的区别可以归纳为三点：

• 以前：TLS 只加密"信件内容"，不加密"收件人"，SNI 始终明文。
• 现在：浏览器把真实域名的 ClientHello（TLS 握手第一个报文）整体加密，外面再包一层用公共域名伪装的 ClientHello。
• 收益逻辑：所有挂在这个公共名下的站点共享同一个匿名集合，观察者分不清具体访问了哪一家；公共名越少，集合越大，隐私越强。

动手起步：最简 ECH 配置

ECH 目前通过 JSON 配置启用（Caddyfile 暂不直接支持），写在tls应用的encrypted_client_hello字段下。

1. 准备一个你能控制证书的"公共名"域名（如shared.example.com），并把它的 DNS 解析指向你的 Caddy 服务器。
2. 在 JSON 配置中加入下面内容，其余保持不变：

{ "apps": { "tls": { "encrypted_client_hello": { "configs": [ { "public_name": "shared.example.com" } ], "publication": [ { "publishers": { "dns": { "name": "cloudflare", "api_token": "<你的令牌>" } } } ] } } } }

3. 执行caddy reload --config config.json重新加载配置，Caddy 会生成 ECH 密钥、为公共名自动申请证书，并把 ECH 配置写入你各站点的 DNS HTTPS 记录。

三个关键行各管一件事：

• public_name：外层"信封"上的通用域名，Caddy 会自动为它签发证书。
• publication：告诉 Caddy 把 ECH 配置发布到 DNS。浏览器正是靠读取这条 HTTPS 记录，才知道该用什么参数加密连接。
• DNS 服务商若已配置在 TLS 应用的全局dns字段中，publication可以整个省略，Caddy 会自动用它发布。

自动化与进阶：上线后它自己会干嘛

你只管配置，剩下交给 Caddy 的后台循环（核心逻辑见源码文件modules/caddytls/ech.go）：

• 密钥生成与存储：自动生成 X25519 密钥对，私钥、配置、元数据分别存入 Caddy 持久化存储的ech/configs/<id>/目录下。
• 自动轮换：密钥每 30 天轮换一次，轮换后旧密钥保留兼容期（还在用它的客户端不受影响），90 天后自动删除。
• 自动发布：服务启动时立即把 ECH 配置写入各域名的 DNS HTTPS 记录，之后每小时检查一次，需要轮换或补发布就补一次；已发布成功的域名不会重复发布。
• 集群同步：轮换和发布操作都带存储锁，多台 Caddy 实例共享同一存储时不会互相覆盖。
• 证书联动：公共名若还没有证书，Caddy 会自动把它加入自动签发名单，省去手工申请。
• 强制 TLS 1.3：ECH 依赖 TLS 1.3，涉及 ECH 的连接策略会自动把最低 TLS 版本提到 1.3，即使你配置了更低的版本。

按规模怎么配

• 个人站点：一个public_name保护你的整个域名即可。值得开——配置只有几行，却能防住 ISP 级别的浏览记录窥探。
• 小团队：多个域名统一挂在同一个公共名下，匿名集合最大；只有当域名分属不同 DNS 服务商时，才需要按服务商分多条publication。
• 多域名企业：内部服务域名全部纳入保护，但公共名数量控制在最少（源码注释明确建议每台服务器通常只配一个）；跨服务商场景下，为每组域名单独配一条发布规则即可。

避坑与收尾

这三点能避开大多数"配置成功但没效果"的情况：

1. 不发布就没有 ECH。浏览器从 DNS 的 HTTPS 记录获取 ECH 参数，不配置publication（或全局 DNS 服务商）时，绝大多数客户端根本不会走 ECH。另外要注意：Caddy 不会对 CNAME 域名、或尚无任何 DNS 记录的域名发布记录，日志里会有提示。
2. 公共名必须能拿到证书。把public_name的 DNS 解析指到这台服务器，Caddy 才能为它自动申请证书；拿不到证书时，客户端可能被迫回退到明文 SNI，隐私直接漏掉。
3. 客户端也要支持。ECH 要求 TLS 1.3，且浏览器需支持 ECH（Chrome、Firefox 等主流浏览器已支持），客户端启用 DoH/DoT 时从 DNS 读取配置才更安全。该功能目前在源码中标注为实验性（EXPERIMENTAL），配置字段可能随版本调整。

如果你的站点开始在意"谁在看着我访问了什么"，现在就给 Caddy 加上这几行 ECH 配置，把 SNI 藏进加密里——等 ECH 标准完全成熟、成为浏览器默认能力时，今天配置过的站点将率先享受它的全部红利。

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