刚接CDN的新站特别容易碰到这个问题：控制台里把HTTPS打开，证书也用CDN的托管证书配好，刷新页面，浏览器直接报ERR_TOO_MANY_REDIRECTS，地址栏里的https一闪一闪。把CDN一关，直连源站又一切正常。老站反而很少遇到，因为回源协议早就配过了。
这类故障基本都出在两段链路的协议不一致。用户到CDN这一跳是HTTPS，CDN到源站这一跳走的是HTTP，而源站上又配了一条强制跳HTTPS的规则。三个条件凑齐，就成死循环了。
循环过程不复杂。CDN收到HTTPS请求，按回源配置用HTTP去源站取。源站看到$scheme是http，命中301规则，返回Location响应头，指向https://同域名。CDN把这个301响应原样交给浏览器，浏览器再发一次HTTPS请求，CDN再回源，还是HTTP，还是301。每一轮都是一个完整来回，浏览器数到二十次左右就停手了。
确认办法就是看Location响应头。命令行跑curl -I http://你的域名/，-I只取HTTP响应头。如果返回301，且Location响应头指向https，说明源站在跳。再跑curl -I https://你的域名/，如果仍然返回301，且Location响应头还是同一个地址，循环就坐实了。用curl -sIL最多跟五跳，能直接看到它在哪里打转。
最省事的改法，是把CDN的回源协议也改成HTTPS。大多数CDN控制台里这一项叫回源协议、回源方式或者源站协议，选HTTPS之后，CDN到源站这一跳也加密，源站看到的$scheme是https，那条301规则不再命中，循环自然就没了。代价是源站也要装证书，源站的443端口要对CDN的回源节点开放。
如果源站不方便上证书，那就得让源站认得出这一跳其实是CDN代劳的HTTPS。CDN回源时会带一个HTTP请求头（header），常见的是X-Forwarded-Proto请求头，值写http或https；阿里云、腾讯云、Cloudflare都支持，个别厂商叫X-Forwarded-Scheme或者X-Forwarded-Protocol。具体叫什么、是否透传，查一下控制台文档就能确认。源站配置里先用map把X-Forwarded-Proto请求头映射成一个变量，默认取$scheme，请求头为https时取https：
map $http_x_forwarded_proto $real_scheme {
default $scheme;
https https;
}
然后在server块里写：
if ($real_scheme = http) {
return 301 https://$host$request_uri;
}
这里用if是安全的，因为里面只有return，没有其他指令。nginx文档里说的if有问题，指的是在if里放rewrite、proxy_pass这类会打乱配置顺序的指令。
改之前先验一件事：确认CDN真的透传了X-Forwarded-Proto请求头。有些免费套餐只透传固定的几个请求头，X-Forwarded-Proto不一定在透传范围内。验证办法是在源站的access日志格式里加$http_x_forwarded_proto，刷新一次页面再看日志，这一列有值，就说明CDN透传了该请求头；如果全是减号，那就别绕了，还是走改回源协议那条路。
改完记得清一次CDN缓存。301在浏览器和CDN两侧都可能被缓存，不清的话改完还是看到旧行为。另外，如果你用的是宝塔防火墙反代，那个场景的规则不太一样，要先确认跳转到底是nginx发的，还是反代层发的，别一上来就改源站配置。
申请创业报道，分享创业好点子。点击此处，共同探讨创业新机遇！
