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 自动签发 HTTPS 证书就完事了。其实客户端要访问的域名SNITLS 握手中的服务器名称仍走明文网络上的人一眼就能看出你访问了哪个站。ECHEncrypted Client Hello加密客户端问候就是为堵住这个口子而生的而 Caddy 把它做成了近乎全自动的功能密钥生成、轮换、发布都能由服务器自己完成。先用一个比喻看懂 ECH 怎么工作 把写着真实域名的信装进一个通用信封封面上写的是多个站点共用的公共域名public name。旁观者只看到你访问了这个通用域名看不到真实目标。Caddy 会自动生成 X25519 密钥对、存进持久化存储每 30 天轮换一次、轮换 90 天后删除旧密钥并把配置发布到域名的 HTTPS DNS 记录里供客户端读取逻辑都在 ECH 核心源码 中。快速上手先配公共名再开发布最后查记录先做什么选一个你权威管理、且能签发证书的域名作为公共名。Caddy 会为它获取证书这是 ECH 的前提。在 Caddyfile 全局选项中加一行{ ech cdn.example.com }再做什么没有发布大多数客户端根本不会使用 ECH。给全局选项加一个dns块指定一个 DNS 提供商需要带 DNS 提供商模块的自定义构建解析逻辑见 Caddyfile 选项{ ech cdn.example.com { dns cloudflare token } }最后确认什么服务器日志里出现 successfully published ECH configuration list并且域名的 HTTPS DNS 记录里带上了ech参数。常用字段速查public_name外层信封上的域名必须解析到本服务器——每个服务器建议只用 1 个publication 的 configs要发布哪些配置——留空即全部publication 的 domains要保护的内层域名——留空即自动使用全部站点域名publishers.dns 的 provider负责写 DNS 记录的提供商——选支持 HTTPS 记录写入的最容易踩的 3 个细节第一公共名拿不到证书就别勉强。如果该域名的 DNS 不指向这台服务器Caddy 签不了证书客户端反而可能被逼到用明文暴露真实域名比不开 ECH 更糟。第二TLS 版本会被强制拉到 1.3。ECH 依赖 TLS 1.3Caddy 会把你配置的连接策略自动升级到最低 1.3即使你原来写的是更低版本。第三On-Demand TLS 的域名必须显式列出来。Caddy 只在握手时才知道要服务哪个域名那时再发布已经晚了不把它们写进 publication 的 domains首次连接照样明文泄露域名。另外公共名越少越好——共享同一外名的站点集合越大隐私保护越强。没生效怎么排查三种常见现象现象一HTTPS 记录里没有ech参数。原因通常是该域名是 CNAME 记录与其他记录互斥Caddy 会跳过或者域名下没有任何已有记录贸然写入可能让通配符解析失效也会跳过。处理换成 A/AAAA 记录并保留至少一条已有记录等下次发布。现象二浏览器显示 ECH 未启用。原因客户端主要从 DNS 读取配置且通常只在 DoH 或 DoT 场景下才认为它可信。处理用开启 DoH 的浏览器再测一次。现象三日志报发布失败。原因一般是 DNS 提供商模块不可用或凭据没有写权限。处理确认使用带对应提供商的自定义构建并检查 API 密钥权限。Caddy 的 ECH 适合谁又劝退谁 适合你同一批服务器后面挂着多个子域名或多个站点希望具体站点对公网观察者隐身域名在自己手里能签证书、能写 DNS 记录。不适合你只有单一站点且域名本身就是品牌的一部分没有隐藏需求或 DNS 服务商不支持写 HTTPS 记录。还要提醒一句这个功能在 TLS 模块 中标记为实验性接口可能随版本变化。下一步可以关注 ECH 草案的最终定稿、更多 DNS 提供商的支持情况以及 On-Demand TLS 域名是否需要手工枚举。【免费下载链接】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 实战：隐藏真实域名，只需 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 自动签发 HTTPS 证书就完事了。其实客户端要访问的域名SNITLS 握手中的服务器名称仍走明文网络上的人一眼就能看出你访问了哪个站。ECHEncrypted Client Hello加密客户端问候就是为堵住这个口子而生的而 Caddy 把它做成了近乎全自动的功能密钥生成、轮换、发布都能由服务器自己完成。先用一个比喻看懂 ECH 怎么工作 把写着真实域名的信装进一个通用信封封面上写的是多个站点共用的公共域名public name。旁观者只看到你访问了这个通用域名看不到真实目标。Caddy 会自动生成 X25519 密钥对、存进持久化存储每 30 天轮换一次、轮换 90 天后删除旧密钥并把配置发布到域名的 HTTPS DNS 记录里供客户端读取逻辑都在 ECH 核心源码 中。快速上手先配公共名再开发布最后查记录先做什么选一个你权威管理、且能签发证书的域名作为公共名。Caddy 会为它获取证书这是 ECH 的前提。在 Caddyfile 全局选项中加一行{ ech cdn.example.com }再做什么没有发布大多数客户端根本不会使用 ECH。给全局选项加一个dns块指定一个 DNS 提供商需要带 DNS 提供商模块的自定义构建解析逻辑见 Caddyfile 选项{ ech cdn.example.com { dns cloudflare token } }最后确认什么服务器日志里出现 successfully published ECH configuration list并且域名的 HTTPS DNS 记录里带上了ech参数。常用字段速查public_name外层信封上的域名必须解析到本服务器——每个服务器建议只用 1 个publication 的 configs要发布哪些配置——留空即全部publication 的 domains要保护的内层域名——留空即自动使用全部站点域名publishers.dns 的 provider负责写 DNS 记录的提供商——选支持 HTTPS 记录写入的最容易踩的 3 个细节第一公共名拿不到证书就别勉强。如果该域名的 DNS 不指向这台服务器Caddy 签不了证书客户端反而可能被逼到用明文暴露真实域名比不开 ECH 更糟。第二TLS 版本会被强制拉到 1.3。ECH 依赖 TLS 1.3Caddy 会把你配置的连接策略自动升级到最低 1.3即使你原来写的是更低版本。第三On-Demand TLS 的域名必须显式列出来。Caddy 只在握手时才知道要服务哪个域名那时再发布已经晚了不把它们写进 publication 的 domains首次连接照样明文泄露域名。另外公共名越少越好——共享同一外名的站点集合越大隐私保护越强。没生效怎么排查三种常见现象现象一HTTPS 记录里没有ech参数。原因通常是该域名是 CNAME 记录与其他记录互斥Caddy 会跳过或者域名下没有任何已有记录贸然写入可能让通配符解析失效也会跳过。处理换成 A/AAAA 记录并保留至少一条已有记录等下次发布。现象二浏览器显示 ECH 未启用。原因客户端主要从 DNS 读取配置且通常只在 DoH 或 DoT 场景下才认为它可信。处理用开启 DoH 的浏览器再测一次。现象三日志报发布失败。原因一般是 DNS 提供商模块不可用或凭据没有写权限。处理确认使用带对应提供商的自定义构建并检查 API 密钥权限。Caddy 的 ECH 适合谁又劝退谁 适合你同一批服务器后面挂着多个子域名或多个站点希望具体站点对公网观察者隐身域名在自己手里能签证书、能写 DNS 记录。不适合你只有单一站点且域名本身就是品牌的一部分没有隐藏需求或 DNS 服务商不支持写 HTTPS 记录。还要提醒一句这个功能在 TLS 模块 中标记为实验性接口可能随版本变化。下一步可以关注 ECH 草案的最终定稿、更多 DNS 提供商的支持情况以及 On-Demand TLS 域名是否需要手工枚举。【免费下载链接】caddyFast and extensible multi-platform HTTP/1-2-3 web server with automatic HTTPS项目地址: https://gitcode.com/GitHub_Trending/ca/caddy创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考