Caddy服务器中通配符证书与HTTPS记录的配置要点解析

在Caddy服务器的使用过程中，通配符证书的配置方式在2.10版本前后存在重要差异。本文将通过一个典型场景分析配置要点，帮助用户正确实现全域名覆盖的HTTPS服务。

问题现象

当用户使用通配符域名配置（如*.example.com）并启用ECH（Encrypted Client Hello）功能时，发现只有根域名（example.com）能正常建立加密连接，而子域名（如www.example.com）却无法获取HTTPS记录。通过curl测试可见，根域名能成功完成ECH握手，但子域名会返回"no ECHConfig available"错误。

技术原理

Caddy处理通配符证书的逻辑经历了重要演进：

1. 2.10版本前：通配符证书（如*.example.com）仅覆盖显式声明的域名，不会自动包含所有子域名
2. 2.10版本后：通配符证书自动涵盖所有子域名，但HTTPS记录仍需单独配置

ECH功能需要依赖DNS中的HTTPS记录，而Caddy默认只为配置块中明确列出的域名生成这些记录。

解决方案

要实现全域名覆盖，推荐采用以下配置结构：

example.com {
    # 根域名配置
}

*.example.com {
    # 通配符配置
}

www.example.com {
    # 特定子域名配置（可选）
}

这种分层配置方式确保：

1. 根域名获得独立的HTTPS记录
2. 通配符范围覆盖所有未明确声明的子域名
3. 重要子域名可单独定制配置

最佳实践

1. 对于生产环境，建议为关键子域名（如www）建立独立配置块
2. 定期检查DNS记录，确认HTTPS RR已正确发布
3. 使用caddy validate命令测试配置语法
4. 通过在线ECH检测工具验证各域名的加密握手状态

理解这些配置差异和原理，可以帮助管理员构建更安全、可靠的HTTPS服务体系。Caddy的模块化设计让这种分层配置既保持了灵活性，又不失管理便利性。