尧图网页设计 
Caddy ECH 实操指南把访客的访问域名藏进加密信封【免费下载链接】caddyFast and extensible multi-platform HTTP/1-2-3 web server with automatic HTTPS项目地址: https://gitcode.com/GitHub_Trending/ca/caddy上次线上抓包时我发现一件扎心的事流量明明是 HTTPSSNI 字段却是明文的——链路上任何 observer 都能看到你访客正在访问哪个站点。Caddy 的 ECHEncrypted Client Hello功能加密的正是这个暴露面。它到底在解决什么信封上的收件人地址ECH 解决的问题只有一个传统 TLS 握手里客户端发出的第一个数据包ClientHello带着明文的域名SNI观察者偷看一眼就知道谁在访问哪个站。这个口子比想象的大行业调研显示约92%的 Web 流量仍把 SNI 明文暴露。最直观的理解是寄信。邮递员必须看到信封上的地址才能投递传统握手就是一层信封地址SNI大大咧咧写在外面。ECH 把它换成双层信封内层信封写真实域名叫inner ClientHello外层信封写一个通用的公共名称public name叫outer ClientHello。外层信封随 DNS 记录公布一份由 X25519 生成的公钥客户端用它把内层信封加密后塞进外层只有服务器能用私钥拆开外层、取出真实域名。邮递员网络观察者自始至终只看到那个公共名称。这条路走了好几年演进如下时间名称特点局限2018ESNIRFC 8744只加密 SNI 字段浏览器支持撤掉后已废弃2019–2022ECH 草案draft-ietf-tls-esni加密整个 ClientHello依赖特定 DNS 记录部署复杂2023ECH RFC 9460HTTPS/SVCB 记录发布机制标准化浏览器默认支持客户端需开启 DoH/DoT 才生效Caddy 的实现位于modules/caddytls/ech.go通过 TLS app 的encrypted_client_hello字段暴露密钥的生成、存储、轮换全在 Caddy 内部自动完成不需要你手写任何密钥。⚡ 一句话记住邮递员只能看到外层信封的地址ECH 加密的是整个 ClientHello而不只是 SNI。从零跑起来3 步让 ECH 上线你只需要两样东西一个自己控制的外层信封域名和一个能写记录的 DNS 服务商。✅ 动手前自检清单✅ Caddy ≥ 2.8.0该版本开始支持 ECH✅ 有一个可解析的域名且 A 记录已指向这台服务器✅ 手里有能写记录的 DNS 服务商 API如 Cloudflare且域名 DNS 由它托管 第三方 DNS provider 不在官方构建里需先用 xcaddy 构建xcaddy build --with github.com/caddyserver/dns-providers最小可运行 Caddyfile{ # 声明外层信封公共名称密钥由 Caddy 自动生成并存储 ech public.example.com { dns cloudflare { # 用来发布 HTTPS 记录的 DNS 服务商 api_token {env.CF_API_TOKEN} } } } # 真实业务域名观察者只会看到 public.example.com api.example.com, blog.example.com { reverse_proxy 127.0.0.1:8080 }caddy run之后Caddy 替你干完三件事生成 X25519 密钥对、为公共名称申请证书、把 ECH 配置写进每个受保护域名的 HTTPS 记录。两条配置建议公共名称越少越好通常一个就够。Caddy 源码注释里明确建议这么做多个域名共用同一个外层名称匿名集最大流量分析最难。公共名称选一个与业务无关的中性域名自己买块停车域名即可它的 DNS 也必须指向这台服务器——否则证书发不下来客户端会被迫退回明文暴露真实域名隐私反而更差。⚡ 一句话记住全局块里一行ech出键、发证书、发记录全自动公共名称要少、中性、能解析。验证与排坑3 层验证 3 个高频报错按本地 → 远程 → 浏览器三层验证全过了才算 ECH 真正生效。 本地层确认配置与密钥caddy adapt --config Caddyfile # JSON 中应出现 encrypted_client_hello日志里看到generated new ECH config说明密钥已生成。 远程层确认 DNS 发布结果dig short -t HTTPS api.example.com # 输出里应能看到 ech 参数 浏览器层打开chrome://net-internals/#ech访问一次站点可以看到握手实际使用的外层名称。三个高频问题都是现象 → 原因 → 解法现象日志出现domain does not have any existing records, so skipping publication。原因该域名原本没有任何 DNS 记录直接加 HTTPS 记录会破坏通配 A 记录的解析。解法先确保域名已有 A/AAAA 记录。现象日志出现domain has CNAME record, so unable to publish。原因CNAME 与 HTTPS 记录互斥无法共存。解法把 CNAME 改成 A 记录再重启 Caddy。现象浏览器里仍是明文 SNI。原因客户端没开 DoH/DoT拿不到记录或公共名称证书没发下来。解法浏览器开启 DoH并检查公共名称的 DNS 解析与 ACME 验证是否通过。⚡ 一句话记住服务器发布成功 客户端 DoH 开启缺一不可否则 ECH 会静默退回明文 SNI。值不值得上先给结论开销小、维护成本几乎为零但功能仍属实验阶段。数字说话性能开销每次握手多一次 HPKE 解密增加1ms体感为零维护成本30 天自动轮换密钥90 天后自动清理过期密钥全程零手工协议代价ECH 强制TLS 1.3Caddy 会自动把连接最低版本抬上去兼容度Chrome、Edge、Firefox 均已默认开启 ECH覆盖约90%的浏览器流量但客户端需启用 DoH/DoT 才生效。一个诚实的提醒源码里该功能标注着EXPERIMENTAL配置结构未来可能调整当前发布的记录 TTL 只有5 分钟是现阶段的临时值。适合面向公网、在意用户—域名关联被分析或域名本身敏感、属于隐私敏感行业的站点。不适合纯内网服务或 DNS 托管在无法写 HTTPS 记录的厂商上。下次抓包时你看到的明文 SNI 终于可以装进信封里了。建议先拿一个测试域名试水配一行ech发布后用一条dig验收。【免费下载链接】caddyFast and extensible multi-platform HTTP/1-2-3 web server with automatic HTTPS项目地址: https://gitcode.com/GitHub_Trending/ca/caddy创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Caddy ECH 实操指南：把访客的访问域名藏进加密信封
Caddy ECH 实操指南把访客的访问域名藏进加密信封【免费下载链接】caddyFast and extensible multi-platform HTTP/1-2-3 web server with automatic HTTPS项目地址: https://gitcode.com/GitHub_Trending/ca/caddy上次线上抓包时我发现一件扎心的事流量明明是 HTTPSSNI 字段却是明文的——链路上任何 observer 都能看到你访客正在访问哪个站点。Caddy 的 ECHEncrypted Client Hello功能加密的正是这个暴露面。它到底在解决什么信封上的收件人地址ECH 解决的问题只有一个传统 TLS 握手里客户端发出的第一个数据包ClientHello带着明文的域名SNI观察者偷看一眼就知道谁在访问哪个站。这个口子比想象的大行业调研显示约92%的 Web 流量仍把 SNI 明文暴露。最直观的理解是寄信。邮递员必须看到信封上的地址才能投递传统握手就是一层信封地址SNI大大咧咧写在外面。ECH 把它换成双层信封内层信封写真实域名叫inner ClientHello外层信封写一个通用的公共名称public name叫outer ClientHello。外层信封随 DNS 记录公布一份由 X25519 生成的公钥客户端用它把内层信封加密后塞进外层只有服务器能用私钥拆开外层、取出真实域名。邮递员网络观察者自始至终只看到那个公共名称。这条路走了好几年演进如下时间名称特点局限2018ESNIRFC 8744只加密 SNI 字段浏览器支持撤掉后已废弃2019–2022ECH 草案draft-ietf-tls-esni加密整个 ClientHello依赖特定 DNS 记录部署复杂2023ECH RFC 9460HTTPS/SVCB 记录发布机制标准化浏览器默认支持客户端需开启 DoH/DoT 才生效Caddy 的实现位于modules/caddytls/ech.go通过 TLS app 的encrypted_client_hello字段暴露密钥的生成、存储、轮换全在 Caddy 内部自动完成不需要你手写任何密钥。⚡ 一句话记住邮递员只能看到外层信封的地址ECH 加密的是整个 ClientHello而不只是 SNI。从零跑起来3 步让 ECH 上线你只需要两样东西一个自己控制的外层信封域名和一个能写记录的 DNS 服务商。✅ 动手前自检清单✅ Caddy ≥ 2.8.0该版本开始支持 ECH✅ 有一个可解析的域名且 A 记录已指向这台服务器✅ 手里有能写记录的 DNS 服务商 API如 Cloudflare且域名 DNS 由它托管 第三方 DNS provider 不在官方构建里需先用 xcaddy 构建xcaddy build --with github.com/caddyserver/dns-providers最小可运行 Caddyfile{ # 声明外层信封公共名称密钥由 Caddy 自动生成并存储 ech public.example.com { dns cloudflare { # 用来发布 HTTPS 记录的 DNS 服务商 api_token {env.CF_API_TOKEN} } } } # 真实业务域名观察者只会看到 public.example.com api.example.com, blog.example.com { reverse_proxy 127.0.0.1:8080 }caddy run之后Caddy 替你干完三件事生成 X25519 密钥对、为公共名称申请证书、把 ECH 配置写进每个受保护域名的 HTTPS 记录。两条配置建议公共名称越少越好通常一个就够。Caddy 源码注释里明确建议这么做多个域名共用同一个外层名称匿名集最大流量分析最难。公共名称选一个与业务无关的中性域名自己买块停车域名即可它的 DNS 也必须指向这台服务器——否则证书发不下来客户端会被迫退回明文暴露真实域名隐私反而更差。⚡ 一句话记住全局块里一行ech出键、发证书、发记录全自动公共名称要少、中性、能解析。验证与排坑3 层验证 3 个高频报错按本地 → 远程 → 浏览器三层验证全过了才算 ECH 真正生效。 本地层确认配置与密钥caddy adapt --config Caddyfile # JSON 中应出现 encrypted_client_hello日志里看到generated new ECH config说明密钥已生成。 远程层确认 DNS 发布结果dig short -t HTTPS api.example.com # 输出里应能看到 ech 参数 浏览器层打开chrome://net-internals/#ech访问一次站点可以看到握手实际使用的外层名称。三个高频问题都是现象 → 原因 → 解法现象日志出现domain does not have any existing records, so skipping publication。原因该域名原本没有任何 DNS 记录直接加 HTTPS 记录会破坏通配 A 记录的解析。解法先确保域名已有 A/AAAA 记录。现象日志出现domain has CNAME record, so unable to publish。原因CNAME 与 HTTPS 记录互斥无法共存。解法把 CNAME 改成 A 记录再重启 Caddy。现象浏览器里仍是明文 SNI。原因客户端没开 DoH/DoT拿不到记录或公共名称证书没发下来。解法浏览器开启 DoH并检查公共名称的 DNS 解析与 ACME 验证是否通过。⚡ 一句话记住服务器发布成功 客户端 DoH 开启缺一不可否则 ECH 会静默退回明文 SNI。值不值得上先给结论开销小、维护成本几乎为零但功能仍属实验阶段。数字说话性能开销每次握手多一次 HPKE 解密增加1ms体感为零维护成本30 天自动轮换密钥90 天后自动清理过期密钥全程零手工协议代价ECH 强制TLS 1.3Caddy 会自动把连接最低版本抬上去兼容度Chrome、Edge、Firefox 均已默认开启 ECH覆盖约90%的浏览器流量但客户端需启用 DoH/DoT 才生效。一个诚实的提醒源码里该功能标注着EXPERIMENTAL配置结构未来可能调整当前发布的记录 TTL 只有5 分钟是现阶段的临时值。适合面向公网、在意用户—域名关联被分析或域名本身敏感、属于隐私敏感行业的站点。不适合纯内网服务或 DNS 托管在无法写 HTTPS 记录的厂商上。下次抓包时你看到的明文 SNI 终于可以装进信封里了。建议先拿一个测试域名试水配一行ech发布后用一条dig验收。【免费下载链接】caddyFast and extensible multi-platform HTTP/1-2-3 web server with automatic HTTPS项目地址: https://gitcode.com/GitHub_Trending/ca/caddy创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考