Caddy ECH 实战指南三步隐藏 TLS 握手中的真实域名【免费下载链接】caddyFast and extensible multi-platform HTTP/1-2-3 web server with automatic HTTPS项目地址: https://gitcode.com/GitHub_Trending/ca/caddy如果你在企业代理的访问日志、运营商的流量分析里看到过自己并不想暴露的域名被逐条明文记录ECH 要解决的就是这种处境。从 v2.6 版本开始Caddy 内置了 ECHEncrypted Client Hello加密客户端问候支持把 TLS 握手里你在访问哪个站这件事变成只有客户端和服务端能解开的内容。本文沿着一个请求的完整旅程带你走完配置、验证与排错内容基于仓库当前代码的实测行为。 不用 Caddy ECH 会暴露什么SNI 明文问题没有 ECH你的域名在每次握手时都是明文的暴露的是你在访问谁而不是你在说什么。客户端连接时发出的第一封包 ClientHello握手开场包携带目标域名与偏好加密套件里SNIServer Name Indication服务器名称指示以明文传输链路上的任何人——运营商、企业网关、公共 Wi-Fi——都能读到。那没有它会怎样三件事浏览习惯被画像内部系统域名如内网监控台、运维入口被探测在流量管控严格的地区连接可能直接被降级或阻断。ECH 的作用是把观察者看到的真实域名替换成一个对外公开的公共名public name。可以这么理解包裹面单上写的是投递到某个公共提货点收件人真名封在内层——快递员只认得到提货点。记住这三点暴露的是域名不是内容观察者视角变成公共名暴露窗口是握手最初几毫秒️ 如何配置最小可用的 Caddy ECH2 行 Caddyfile最短可用配置只有两行一个公共名 一个 DNS 发布。公共名是对外展示的外层名字Caddy 会自动为它申领证书发布则让 Caddy 把 ECH 公钥写进 DNS 的 HTTPS 记录浏览器正是从那里读取配置。下面的 Caddyfile 就是完整写法替换为你的 DNS 提供商即可{ ech echo.example.com { dns cloudflare } }这段选项的解析逻辑在仓库的caddyconfig/httpcaddyfile/options.go里。想理解每个字段适配后的去向可对照下面这份 JSON 结构挂在tls应用的encrypted_client_hello键下tls: { encrypted_client_hello: { configs: [ { public_name: echo.example.com } ], publication: [ { domains: [site.example.com], publishers: { dns: {} } } ] } }两处关键事实密钥不用你手写Caddy 自动生成、存储并轮换domains列出受保护的站点不填时默认包含该服务器注册的全部站点。记住这三点公共名证书自动申领密钥自动生成无需手写发布配置必配否则浏览器发现不了 验证 Caddy ECH 生效的 3 种方式与 3 个高频坑按DNS 记录 → 浏览器握手 → 命令行客户端的顺序验证哪一步卡住就排哪一步。失败了先看哪里先看记录——多数不生效其实是记录压根没发出去。DNS 层执行dig short HTTPS site.example.com输出里若出现以BQ开头的 base64 串说明 ECHConfigList 已就位发布成功。浏览器层在启用了 DoHDNS over HTTPS把 DNS 查询本身也加密的浏览器里打开chrome://net-internals/#ech能看到 ECH 配置的获取与握手使用情况。命令行层openssl s_client -connect site.example.com:443 -ech需 OpenSSL 3.5握手中会回显 ECH 配置。三个高频坑各一句解法公共名的 DNS 没指向本服务器Caddy 领不到公共名证书客户端会退回明文 SNI保护直接失效。解法先把公共名的解析记录指到服务器再开 ECH。漏配发布DNS 里没有记录浏览器根本不会启用 ECH。解法补上dns子指令或publishers.dns。on-demand TLS 的域名没列出按需 TLS 的域名只在握手时才知道发布来不及首次连接会暴露域名。解法把它们显式写进publication.domains。另外一件 Caddy 替你做的事ECH 依赖 TLS 1.3它会直接把连接策略的最小规模版本抬到 1.3无需你手动设置。记住这三点DNS 没记录等于没生效公共名领不到证书就降级on-demand 域名要显式列出 Caddy ECH 原理回看一个请求的加密旅程那它到底怎么做到把机制放回请求里全过程只有三步取公钥、包内层、按内层继续握手。客户端先查目标域名的 DNS HTTPS 记录RFC 9460拿到 ECHConfigList里面是公钥和公共名。客户端用 X25519Caddy 固定采用的密钥封装方案与公钥派生共享密钥把真实 ClientHello含真实域名加密为内层再用外层 ClientHello 携带公共名包裹发送。服务端先完成外层握手再用私钥解开内层按真实域名继续后续握手。观察者自始至终只看到公共名。内层 ClientHello 相当于一张密封的房号卡只有服务端有钥匙。这套逻辑的源码在modules/caddytls/ech.go注释中明确标注 EXPERIMENTAL字段名跨版本可能调整升级大版本时建议核对一次配置。密钥生命周期则完全自动化Caddy 每 30 天轮换一次密钥旧密钥保留一段时间以兼容还没拿到新配置的客户端满 90 天后删除全程零手工操作。记住这三点配置分发靠 DNS HTTPS 记录内层仍带真实域名只是加密30 天轮换、90 天删除全自动 Caddy ECH 进阶方向匿名集、加密 DNS 与 QUIC跑通最小链路后值得调优的是三件事匿名集大小、客户端加密 DNS 覆盖、协议演进。匿名集尽量做大规格建议公共名越少越好Caddy 默认每台服务器一个。共用同一公共名的域名越多观察者看到的匿名人群越大流量分析越难。客户端侧依赖加密 DNS浏览器只有在 DoH/DoT 开启时才能可靠读到记录评估落地效果时要把客户端加密 DNS 的占比算进去。QUIC 握手ECH 同样可覆盖 QUIC 的 ClientHello配合 0-RTT 能同时改善隐私与首包延迟是下一步值得关注的组合。下一步动作很具体挑一个测试域名把公共名的解析指到服务器写两行ech选项并重启dig确认记录出现再用浏览器的 net-internals 看到 ECH 点亮。先跑通最小配置再谈调优。记住这三点公共名越少匿名集越大客户端需要 DoH/DoT 覆盖先跑通最小链路再谈调优【免费下载链接】caddyFast and extensible multi-platform HTTP/1-2-3 web server with automatic HTTPS项目地址: https://gitcode.com/GitHub_Trending/ca/caddy创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
