MERN应用迁移AWS后HTTPS跳转异常求助（仅Chrome出现）
这问题我之前碰到过类似的，Chrome对HTTPS的安全校验逻辑确实比Firefox更严格，结合你的MERN+Cloudflare+ALB配置，大概率是下面几个环节出了问题，咱们一步步排查解决：
1. 后端响应/重定向的协议问题
Chrome对混合内容（页面里同时存在HTTPS和HTTP资源）或者HTTP重定向的容忍度极低，而Firefox可能会自动修复这类问题。你访问根路径正常，但二级路径跳HTTP，很大概率是：
- 后端在处理
/articles请求时，返回了HTTP协议的重定向（比如响应头Location: http://example.com/articles）； - 页面里的资源（图片、脚本、API请求）用了硬编码的
http://开头链接，触发Chrome的安全降级。
排查方法：
打开Chrome开发者工具（F12）→ 切换到「网络」标签，刷新https://example.com/articles：
- 看第一个请求的响应状态码，如果是3xx重定向，检查
Location头是不是HTTP开头； - 浏览所有加载的资源，看有没有
http://开头的请求。
解决办法：
- 把后端所有重定向逻辑里的URL改成HTTPS，或者用相对路径；
- 页面中的资源引用统一用相对路径（比如
/images/article.jpg）或者协议相对路径（//example.com/images/article.jpg），避免硬编码HTTP。
2. Cloudflare页面规则的覆盖范围
你设置了「始终重定向至HTTPS」的页面规则，要确认规则的匹配模式是*example.com/*，而不是只匹配根路径example.com/。如果规则只覆盖根路径，二级路径的请求不会被Cloudflare强制重定向，一旦后端返回HTTP链接，Chrome就会跳转到不安全的HTTP。
检查方法：
登录Cloudflare后台→「页面规则」，查看你那条重定向规则的URL匹配是否为*example.com/*，并且优先级设置为最高（避免被其他规则覆盖）。
3. ALB的代理头与后端信任配置
Cloudflare会把用户的原始请求协议（HTTPS）通过X-Forwarded-Proto: https头传给你的ALB。如果你的MERN后端（尤其是Express服务器）没有配置信任代理，会误以为请求是通过HTTP到达的，从而生成HTTP格式的链接或重定向。
解决办法：
- 在ALB的目标组属性中，开启「Forward headers」里的
X-Forwarded-Proto（确保这个头能传给后端）； - 在你的Express应用中添加信任代理的配置：
// Express 应用入口文件 app.set('trust proxy', true);
这样Express会优先使用X-Forwarded-Proto头来判断请求协议，生成正确的HTTPS链接。
4. Cloudflare与ALB的SSL链路验证
你用了Cloudflare的Full SSL模式，这要求Cloudflare和ALB之间必须用HTTPS通信，且Cloudflare能信任ALB的AWS CA证书。如果ALB的HTTP:80监听器还在接收请求，或者证书域名不匹配，可能导致二级路径的请求被异常处理。
排查方法：
- 确认ALB的HTTP:80监听器是否配置了强制重定向到HTTPS（即使Cloudflare处理了前端重定向，源站的HTTP入口也应该关闭或重定向，避免绕过Cloudflare的请求）；
- 检查Cloudflare「SSL/TLS」→「Origin Server」中的配置，确认Cloudflare能正常验证ALB的证书（AWS CA颁发的域名证书是被信任的，只要域名匹配就没问题）。
5. Chrome的缓存与HSTS冲突
Chrome可能缓存了旧的HTTP响应或者HSTS（HTTP Strict Transport Security）规则，导致二级路径被强制跳转到HTTP。
解决办法：
- 清除Chrome缓存：「设置」→「隐私和安全」→「清除浏览数据」，勾选「缓存的图片和文件」「Cookie和其他网站数据」，清除后重启浏览器；
- 重置Chrome的HSTS规则：在地址栏输入
chrome://net-internals/#hsts，在「Delete domain security policies」输入框中填入example.com，点击「Delete」，然后重启浏览器。
如果以上步骤都试过还没解决，可以把Chrome开发者工具里「网络」标签的请求记录截图发出来，或者后端的重定向逻辑代码贴出来，我再帮你细化排查。
内容的提问来源于stack exchange，提问作者Rahul Sharma
