启用CloudFront CachingOptimized后HTTP转HTTPS循环重定向问题

问题背景 #

搭建了包含EC2、ELB、Route53和CloudFront的架构，启用CachingOptimized缓存策略后，Firefox提示「页面重定向不正确」，重定向检测显示19次循环。curl测试结果：

• 禁用缓存时，https://example.com返回200正常
• 启用缓存后，https://example.com返回301重定向到http://example.com，触发ERR_TOO_MANY_REDIRECTS

关键配置：

CloudFront配置 #

Origin: main-albxxxxxx-amazonaws.com 
Protocol: HTTPS only

行为设置 #

Origin and origin groups: main-albxxxxxx-amazonaws.com
Viewer protocol policy: Redirect HTTP to HTTPS
Cache policy:CachingOptimized
Origin request policy - optional: AllViewer

ELB监听器配置 #

HTTPS:443
Forward to
prod-tg-1 : 1 (100%)
Group-level stickiness: Off

HTTP:80
If (all match)
Request is not otherwise routed
Then
Redirect to HTTPS://#{host}:443/#{path}?#{query}
Status code: HTTP_301

Route53配置 #

别名指向CloudFront分发，需求为将www和HTTP请求重定向到HTTPS。

原因分析 #

1. 缓存了错误的重定向响应：配置变更前的异常301响应被CloudFront缓存，启用CachingOptimized后直接返回缓存内容，导致循环；
2. Origin请求策略缺失关键头：AllViewer策略未传递CloudFront生成的X-Forwarded-Proto头，后端EC2无法识别原始请求为HTTPS，错误返回HTTP重定向；
3. 冗余重定向配置冲突：CloudFront和ELB都配置了HTTP到HTTPS的重定向，增加了异常触发概率。

解决步骤 #

1. 清除CloudFront缓存 #

缓存的错误301是直接诱因，先手动失效所有缓存：

• 登录CloudFront控制台，选择对应分发
• 进入「Invalidations」标签页，点击「Create Invalidation」
• 在「Paths」输入/*，提交失效请求
• 等待失效完成（通常5-15分钟）后重新测试

2. 调整Origin请求策略 #

替换AllViewer为Managed-AllViewerAndCloudFront策略：

• 该策略会传递CloudFront生成的X-Forwarded-Proto、X-Forwarded-For等头，让后端EC2正确识别请求协议
• 若需自定义策略，确保明确添加X-Forwarded-Proto到Origin请求头列表中

3. 优化ELB监听器配置 #

CloudFront已处理HTTP到HTTPS的重定向，可简化ELB配置：

• 登录ELB控制台，选择对应负载均衡器
• 禁用或删除HTTP 80监听器的重定向规则（或直接删除HTTP 80监听器，避免直接暴露ELB）

4. 验证后端EC2配置 #

确保EC2应用不会错误重定向：

• 检查应用的强制HTTPS配置，确认重定向目标协议为HTTPS
• 直接访问ELB的HTTPS地址（https://main-albxxxxxx-amazonaws.com），确认返回200而非重定向

验证测试 #

完成配置后执行以下测试：

• 执行curl -v https://example.com，确认返回200状态码，无多余重定向
• 用浏览器访问，确认不再出现重定向错误
• 等待缓存生效后再次测试，确保响应正常缓存且无循环

内容的提问来源于stack exchange，提问作者caprio