必须透传原始协议，即在Nginx中配置proxy_set_header X-Forwarded-Proto $scheme（或优先复用$http_x_forwarded_proto），并配合Host、X-Forwarded-For等头，后端再主动信任该头，才能让后端准确识别客户端真实协议。
要让后端准确识别客户端原始协议（HTTP 或 HTTPS），关键是在 Nginx 反向代理中用 proxy_set_header X-Forwarded-Proto $scheme 正确透传，而不是靠猜测或硬编码。
为什么必须透传原始 Schema
用户通过 HTTPS 访问 Nginx，但 Nginx 通常以 HTTP 协议转发请求给后端（如 Python Flask、Django 或 Node.js 应用）。后端只看到内部 HTTP 连接，就会误判为不安全请求，导致：
- 重定向反复跳转到 HTTPS，触发
ERR_TOO_MANY_REDIRECTS - 生成的绝对 URL 使用
http://，造成混合内容警告 - Secure Cookie 未正确标记，登录态丢失
- CSRF Token 校验失败或权限逻辑异常
正确配置 proxy_set_header X-Forwarded-Proto
该指令必须放在 location 或 server 块内——$scheme 是请求级变量，在 http 全局块中无效，会为空或错误。
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
- 基础写法：
proxy_set_header X-Forwarded-Proto $scheme;（自动取值 http 或 https） - 若前端有 CDN（如 Cloudflare、阿里云 CDN），它通常已设置
X-Forwarded-Proto，应优先复用：proxy_set_header X-Forwarded-Proto $http_x_forwarded_proto; - 为防 CDN 未传该头，可用
map指令兜底：
default $http_x_forwarded_proto;
"" $scheme;
}
proxy_set_header X-Forwarded-Proto $real_scheme;
配套透传其他关键上下文头
单传协议不够。后端构建完整请求上下文还需：
-
proxy_set_header Host $host;——确保后端生成的链接使用用户访问的域名 -
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;——传递真实客户端 IP 链 -
proxy_set_header X-Forwarded-Host $host;和X-Forwarded-Port $server_port;——辅助还原原始访问地址
后端必须主动信任并使用该头
Nginx 传了，后端不认等于白传。常见框架启用方式：
-
Django：设置
SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https')，并开启USE_X_FORWARDED_HOST = True -
Flask：用
ProxyFix中间件，如app.wsgi_app = ProxyFix(app.wsgi_app, x_proto=1) -
Express（Node.js）：设置
app.set('trust proxy', true)，之后req.protocol将自动读取X-Forwarded-Proto
