重定向循环怎么排查
当边缘节点终止加密连接而源站又按自身看到的协议状况判断是否跳转时，会出现重定向循环，浏览器报错为跳转次数过多。正确做法是让源站依据边缘转发头中标注的原始协议来判断，并把跳转动作统一放在边缘层承担。观察时用打印跳转链的方式逐跳查看响应的状态码与位置字段，即可定位是哪一层在反复跳转。
基本信息
| 典型诱因 | 边缘到源站为明文，源站无条件跳转加密 |
|---|---|
| 正确依据 | 边缘设置的转发头标注原始协议 |
| 排查方式 | 逐跳打印响应的状态码与位置字段 |
| 设计建议 | 跳转动作统一由边缘承担 |
典型使用场景
- 上线后浏览器报跳转次数过多
- 接入边缘加速后出现循环跳转
- 排错：区分服务端跳转与应用层重定向
- 改造：把跳转逻辑收敛到边缘层
- 回归验证：确认各入口的跳转行为一致
按转发头判断协议
按转发头判断协议
map $http_x_forwarded_proto $is_https {
default 0;
https 1;
}
server {
listen 80;
if ($is_https = 0) { return 301 https://$host$request_uri; }
}逐跳观察重定向
逐跳观察重定向
curl -sIL http://example.com/ | grep -i '^HTTP\|^location'
curl -sIL https://example.com/ | grep -i '^HTTP\|^location'
# 逐跳对比可定位是哪一层在反复跳转配置组合与结果
| 边缘模式 | 源站判断依据 | 结果 |
|---|---|---|
| 边缘终止加密 | 按转发头判断 | 正常 |
| 边缘终止加密 | 按本地监听端口判断 | 循环跳转 |
| 边缘回源加密 | 源站强制跳转 | 正常 |
复杂跳转用条件指令写在受限位置容易产生意外行为；建议用映射变量或独立服务块表达，并同时检查边缘的加密模式设置。
落地建议
- 统一由边缘层负责跳转
- 源站只信任显式配置的转发头
- 变更后逐跳验证两种入口
- 把跳转链检查纳入发布清单
只查看源站日志会看不到循环的全貌，因为跳转可能发生在边缘层；逐跳观察与边缘日志对照才能确定责任边界。
定位步骤
- 先逐跳打印两种入口的响应链
- 对比每一跳的状态码与位置字段
- 确认边缘的加密模式与转发头配置
- 修改后重新逐跳验证直到只有一跳跳转
反向代理场景下，源站不应直接信任客户端可伪造的转发头；只接受来自受控边缘的头部，并对其做来源校验，否则既可能触发异常跳转，也可能被用于伪造访问来源。