企业网站完成 HTTPS 部署以后，有时会出现一种比较容易让人误判的问题：
证书已经正常安装，浏览器也能建立 HTTPS 连接，但页面访问时却反复跳转，或者首页能够打开，部分接口和登录状态却出现异常。
这类情况并不一定是证书本身有问题。
在使用反向代理的网站架构中，更常见的原因是浏览器、Nginx 和后端应用对“当前请求到底是不是 HTTPS”的判断不一致。
一、先弄清网站真实的访问链路
一个常见的企业网站部署结构可以简化为：
浏览器
→ HTTPS
→ Nginx
→ 内部 HTTP
→ 后端应用
用户访问网站时，浏览器与 Nginx 之间使用的是 HTTPS。
但 Nginx 向同一台服务器上的后端程序转发请求时，为了简化内部通信，可能继续使用 HTTP。
这时就会形成一个容易被忽略的情况：
用户访问的是 HTTPS，但后端程序收到的内部连接却是 HTTP。
如果后端只根据当前连接判断访问协议，就可能认为用户仍然使用 HTTP。
二、为什么会形成重复跳转
假设后端程序设置了一条规则：
如果发现当前访问不是 HTTPS，就自动跳转到 HTTPS。
实际过程可能变成：
用户通过 HTTPS 访问网站；
Nginx 接收到 HTTPS 请求；
Nginx 通过内部 HTTP 转给后端；
后端判断当前连接是 HTTP；
后端要求浏览器重新进入 HTTPS；
浏览器再次访问 HTTPS；
请求又经过同样的内部 HTTP 转发。
如果每次都执行相同判断，就可能不断重复这个过程。
所以排查这类问题时，不能只确认“证书有没有安装”，还要确认协议状态能否正确传递到后端应用。
三、先从浏览器观察是否真的在循环跳转
排查时可以打开浏览器开发者工具，在 Network 面板观察页面请求。
重点检查：
页面请求是否连续出现 301 或 302；
Location 指向的地址是否重复；
HTTP 与 HTTPS 是否来回切换；
登录后是否重新进入原来的地址；
接口请求是否被再次跳转。
如果短时间内连续出现多个跳转请求，就应该优先检查协议判断和重定向逻辑。
还可以观察最终页面有没有正常返回 200 状态。
如果请求一直停留在跳转状态，就说明页面没有真正进入正常业务处理。
四、检查代理层有没有传递原始协议
反向代理不仅要把请求转给后端，还应该把用户原始请求的一些重要信息一起传递。
其中一个常见字段是：
X-Forwarded-Proto
它主要用于告诉后端：
用户最初使用的是 HTTP 还是 HTTPS。
如果用户通过 HTTPS 访问，代理层应该让后端能够识别到 HTTPS 状态。
在 Nginx 环境中，可以重点检查代理配置中是否存在与 X-Forwarded-Proto 相关的设置，并确认它传递的是当前真实访问协议。
这里没有必要同时修改大量配置。
先确认代理有没有正确传递协议，再继续检查后端是否读取，是比较清晰的顺序。
五、代理已经传递，后端仍然判断错误怎么办
还有一种情况：
Nginx 已经正确传递了 HTTPS 信息，但后端程序仍然认为当前请求是 HTTP。
这时问题可能出现在应用框架。
不同开发框架对反向代理的处理方式不同。
有些框架会自动识别代理头，有些需要单独开启：
代理信任；
Forwarded Header 支持；
反向代理模式；
外部协议识别。
排查时可以临时检查后端实际读取到的几个信息：
当前程序判断的协议；
X-Forwarded-Proto 的值；
Host；
当前请求路径。
如果代理传递的是 HTTPS，但程序仍然识别成 HTTP，就应该继续检查框架本身，而不是反复修改 SSL 证书。
六、检查 HTTPS 跳转到底设置了几层
网站从 HTTP 切换到 HTTPS 后，通常需要保留 HTTP 到 HTTPS 的跳转。
但实际项目中容易出现一个问题：
多个位置同时执行跳转。
例如：
Nginx 设置一次；
后端程序设置一次；
CDN 设置一次；
负载均衡再设置一次；
前端脚本又进行协议判断。
单独看每一条规则都可能合理，但组合起来以后，就容易出现互相冲突。
网站建设和部署时可以尽量确定一个主要的跳转处理位置。
其他层主要负责正确传递协议信息，而不是重复执行相同规则。
七、首页正常还要继续检查接口
有些网站看起来已经完成 HTTPS 切换，但只是 HTML 页面使用了 HTTPS。
前端接口配置仍然可能保留原来的 HTTP 地址。
这种情况下可能出现：
网页正常打开；
部分接口请求失败；
浏览器控制台出现安全提示；
表单无法提交；
登录状态无法正常保持。
排查时可以在 Network 面板检查实际接口地址。
重点确认：
页面是 HTTPS；
API 请求也是 HTTPS；
静态资源没有继续调用 HTTP；
图片、脚本和其他资源没有混合使用旧协议。
如果前端与接口属于同一站点，也可以结合实际架构减少固定协议地址的重复配置。
八、如果网站前面还有 CDN
实际企业网站可能采用更长的访问链路：
浏览器
→ CDN
→ 负载均衡
→ Nginx
→ 后端程序
这时不能只检查 Nginx。
需要沿着真实访问链路逐层确认：
浏览器最初使用什么协议；
CDN向下游传递什么信息；
负载均衡有没有重新设置协议字段；
Nginx最终收到什么；
后端程序最终识别成什么。
如果某一层把原来的 HTTPS 状态覆盖成 HTTP，后续程序就可能得到错误判断。
九、调整后怎样验证
完成修改以后，可以重新从几个位置验证。
浏览器
确认：
页面不再连续出现 301、302；
最终页面正常返回；
接口请求没有反复重定向；
控制台没有明显的混合内容异常。
代理层
确认：
HTTPS访问时能够正确传递协议状态；
Host 和请求路径没有异常变化。
后端应用
确认：
程序识别到的访问协议与浏览器实际访问一致。
HTTP入口
使用普通 HTTP 地址访问时，可以正常进入 HTTPS 页面，并且只执行符合预期的跳转过程。
十、网站建设阶段可以怎样减少这类问题
协议切换不要只看证书部署。
项目上线前可以把整个请求链路画出来：
用户
→ CDN
→ Web服务器
→ 应用程序
然后明确每一层负责：
接收什么协议；
传递什么信息；
在哪一层完成跳转；
后端怎样识别真实访问状态。
这样后续增加 CDN、负载均衡或者调整服务器架构时，更容易判断协议信息在哪一层发生变化。
总结
HTTPS上线以后出现重复跳转，真正需要检查的是完整请求链路，而不是只查看 SSL 证书。
武汉网站建设进入服务器部署阶段后，可以按照：
浏览器请求
→ 反向代理
→ 协议传递
→ 后端识别
→ 接口请求
→ 结果验证
逐层排查。
其中重点关注 X-Forwarded-Proto、代理信任和 HTTPS 跳转位置。
把协议识别关系理顺以后，通常比同时修改多处跳转规则更容易定位问题。
本文由梓彤超越（武汉）科技有限公司整理。
