Caddy服务器慢速HTTP请求导致的DoS漏洞分析

问题背景

Caddy作为一款现代化的Web服务器，以其易用性和自动HTTPS特性广受欢迎。然而，近期发现其存在一种经典的慢速HTTP请求问题，恶意用户可通过占用服务器有限的进程池资源，导致服务不可用。这类问题并不依赖高带宽消耗，而是利用协议特性进行低成本的资源占用。

技术原理

进程池资源限制

Caddy采用基于CPU核心数的进程池模型处理并发请求。每个HTTP连接会占用一个工作进程，直到请求完全处理完毕。当恶意用户以极低速率发送请求头部或故意延迟发送请求体时，这些连接会长时间占用进程槽位。

测试表明，默认配置下仅需约50个并发慢速请求（具体数值与CPU核心数相关）即可耗尽进程池，导致服务器无法响应正常流量。

两种问题变体

1. 慢速头部问题
   恶意用户以极低速率（如每秒1KB）发送HTTP请求头部，使服务器保持连接等待后续数据。

2. Content-Length异常问题
   发送包含异常Content-Length标头的请求但不提交完整请求体，服务器将持续等待缺失的数据部分。

影响范围

该问题直接影响服务可用性：

• 资源占用成本极低，单台普通机器即可实施
• 对静态资源服务器和API服务影响尤为显著
• 默认配置下无有效防护机制

解决方案

官方推荐配置

Caddy团队建议通过以下超时参数缓解风险（需在Caddyfile中手动配置）：

timeouts {  
    read_header 10s    # 头部读取超时  
    read_body   60s    # 请求体读取超时  
    write       60s    # 响应写入超时  
    idle        75s    # 连接空闲超时  
}  

技术权衡

值得注意的是，严格的超时设置可能产生副作用：

• 用户体验影响：高延迟网络用户（如偏远地区）可能被误判为异常行为
• 性能折损：过短的idle超时会增加TCP连接重建开销
• 防护局限性：仅能提高资源占用成本，无法彻底防御分布式问题

深度防护建议

对于关键业务系统，应实施多层防护：

1. 基础设施层：部署反向代理（如Nginx）前置过滤慢速连接
2. 架构层：采用弹性伸缩的云服务自动应对流量激增
3. 监控层：实时检测异常连接模式并自动处理

总结

Caddy的这一设计特性反映了安全与可用性的经典权衡。虽然通过调整超时参数可缓解风险，但企业用户仍需结合自身业务场景设计纵深防护体系。对于普通用户，建议至少配置基础超时值，并在生产环境中进行兼容性测试。