Caddy服务器SNI匹配问题分析与解决方案

问题背景

在使用Caddy服务器作为反向代理时，一个常见但容易被忽视的问题是服务器名称指示(SNI)的匹配问题。近期有用户在部署基于Symfony-Docker的项目时遇到了TLS握手失败的情况，具体表现为HAProxy返回503错误，而Caddy日志显示"no matching certificates and no custom selection logic"。

问题现象分析

在正常情况下，Caddy服务器的TLS连接策略配置应该是简单的证书选择逻辑：

[{"certificate_selection":{"any_tag":["cert0"]}}]

但在问题案例中，配置变成了：

[{"certificate_selection":{"any_tag":["cert0"]},"match":{"sni":["project.tcoch.local"]}},{}]

这种配置变化导致了TLS握手失败，因为客户端(这里是HAProxy)没有正确发送SNI信息。

技术原理

SNI(Server Name Indication)是TLS协议的扩展，允许客户端在握手初期指明它要连接的主机名。这对于一个IP地址托管多个域名的情况尤为重要：

1. 当客户端不发送SNI时，Caddy会尝试从所有可用证书中选择
2. 当客户端发送SNI时，Caddy会优先匹配与该主机名相符的证书
3. 当配置中明确指定了SNI匹配规则但客户端未发送SNI时，握手会失败

解决方案

针对这类问题，可以从以下几个层面进行解决：

1. HAProxy配置调整

确保HAProxy在向后端(Caddy)转发请求时携带SNI信息。这通常需要在backend配置中添加以下参数：

server caddy_backend 172.28.0.2:443 ssl verify none sni str(project.tcoch.local)

2. 证书配置优化

如果使用通配符证书(如*.tcoch.local)，需要确保：

1. 证书包含所有可能访问的主机名
2. 如果通过IP直接访问，证书中应包含IP SAN(Subject Alternative Name)

3. Caddy配置检查

验证Caddy的自动HTTPS功能是否被正确配置。在Docker环境中，可能需要明确设置：

CADDY_DOMAIN=project.tcoch.local

最佳实践建议

1. 始终确保客户端发送正确的SNI信息
2. 在反向代理场景下，检查各层代理的TLS透传配置
3. 对于内部服务，考虑使用包含IP地址的证书或禁用SNI检查
4. 定期检查Caddy的日志，特别是TLS握手相关的调试信息

通过理解SNI在TLS握手过程中的作用，以及Caddy服务器的证书选择逻辑，可以有效避免类似连接问题，确保HTTPS服务的稳定运行。