Caddy反向代理健康检查默认不应跟随重定向

在Caddy服务器的反向代理功能中，主动健康检查(active health checks)是一个重要的特性，它通过定期向被代理的服务发送HTTP请求来验证其可用性。然而，当前实现中存在一个值得注意的行为问题：健康检查的HTTP客户端默认会跟随服务器返回的重定向响应。

问题分析

当配置了health_uri参数启用主动健康检查时，如果被检查的上游服务返回了HTTP重定向响应(如301/302状态码)，Caddy的健康检查客户端会自动跟随这个重定向。这种行为在实际使用中可能导致以下问题：

1. 意外协议切换：如果上游服务将HTTP请求重定向到HTTPS，而健康检查客户端没有配置为使用HTTPS，会导致协议不匹配错误。

2. 检查目标偏离：重定向可能将健康检查请求发送到完全不同的端点，使得健康检查结果不能真实反映配置的URI的健康状态。

3. 混淆错误信息：如示例中所示，可能产生"http: server gave HTTP response to HTTPS client"这类难以理解的错误信息，增加了故障排查难度。

技术解决方案

从技术实现角度来看，更合理的行为应该是：

1. 默认禁用重定向跟随：健康检查应该严格针对配置的URI进行，任何重定向响应都应被视为检查失败。

2. 明确错误报告：当收到重定向响应时，应记录明确的错误信息，指出健康检查因遇到重定向而失败。

3. 提供可选配置：虽然大多数情况下不应跟随重定向，但仍需提供health_follow_redirects这样的配置选项，以满足特殊场景的需求。

实现建议

在具体实现上，可以考虑：

1. 修改HTTP客户端的CheckRedirect策略，默认返回http.ErrUseLastResponse错误以阻止重定向跟随。

2. 当检测到重定向响应时，记录详细的诊断信息，包括原始URI和重定向目标URI。

3. 添加配置选项控制重定向行为，保持向后兼容性。

最佳实践

对于Caddy用户，在当前版本中可以通过以下方式规避此问题：

1. 确保健康检查URI不会返回重定向响应。

2. 如果必须检查可能重定向的URI，考虑在应用层实现自定义健康检查逻辑。

3. 关注Caddy版本更新，及时应用包含此修复的版本。

这个问题虽然看似简单，但它体现了基础设施组件设计中一个重要的原则：默认行为应该符合最常见的使用场景，同时为特殊需求提供明确的配置选项。Caddy团队对此问题的处理也展示了开源项目对用户体验细节的关注。