大概每个搞过 Web 后端的人都撞见过这么一幕：明明已经把证书挂到了 Nginx 上，浏览器地址栏也锁得严严实实，用户却在某个页面提交完表单后，啪地一下跳到了http://开头的地址，接着整个请求链路又变成明文。更气人的是，这种降级不是偶发的，有时候换个网络环境就出现，有时候清了缓存又恢复。排查一圈下来，问题往往不在证书、不在业务代码，而藏在你那个一直默默工作的反向代理配置里。这篇文章就围绕反向代理场景下的 HTTPS 降级问题，拆一拆最容易被忽略的几个坑，并附上我实际用过的排查方法和修复配置。适合正在用 Nginx 或同类组件做反代，又经常被“为什么又变 http 了”折磨的运维、后端和前端同学。
1. 先搞明白：反向代理为什么天然会造成“协议降级”
1.1 边缘加密模型：TLS 只保护外网这一段
先说一个最基础的事实：绝大多数反向代理在转发 HTTPS 请求时，并不会把 TLS 隧道整个打穿到后端。浏览器到 Nginx 这一段是加密的 HTTPS，Nginx 用私钥解密后，内部再通过普通 HTTP 去访问后端的应用服务。你去看 Nginx 配置，大部分是这种写法：
server { listen 443 ssl; server_name example.com; ssl_certificate /etc/nginx/ssl/example.com.pem; ssl_certificate_key /etc/nginx/ssl/example.com.key; location / { proxy_pass http://127.0.0.1:8080; } }proxy_pass指向的是http而不是https，这非常正常，因为 TLS 已经在边缘终止了。这种做法在工程上极其常见：后端不用关心证书，证书统一放在入口层管理，新加一台应用服务器也不需要拷贝私钥，性能还能通过 Nginx 的静态文件和处理能力得到提升。但代价就是，后端应用默认情况下完全不知道客户端实际是走 HTTPS 进来的。
这就带来一个认知上的误区：很多人以为“HTTPS 降级为 HTTP”一定是指握手被攻击或证书失效。实际上，在你自己的架构里，“降级”有两种完全不同的含义。第一种是连接层面的真实降级，也就是用户最终访问的 URL 是http://，浏览器和服务器之间确实没有加密。第二种是应用层返回的链接降级：用户请求的是https://example.com/login，后端在 302 响应的Location头里写了一个http://开头的地址，浏览器就跟着这个地址走了，于是地址栏从 https 变成了 http。第二种本质上是“引导降级”——加密本身没有问题，是反向代理把协议信息弄丢了。绝大多数线上的诡异降级都属于第二种。
1.2 需要区分开的两种“降级”：连接降级和地址降级
既然要排查，第一件事就是判断你碰到的是哪一种。你可以先做一个最简单的复现：手动打开 https 地址看 URL 是否保持；再在浏览器里提交一个表单或点击一个会触发重定向的按钮，观察跳转后的地址；最后看页面源码里有哪些http://的资源链接。如果 URL 一开始是正常的，跳转后变成 http，优先怀疑重定向和Location头。如果页面一开始加载就是 http，那要检查 80 端口的跳转规则、DNS 记录，甚至是不是有人在外部做了 URL 重写。
我遇到过不少同事，看到浏览器地址栏变成 http，第一反应就是吊销证书、换套件、关代理测试，结果越搞越乱。其实只要理解了反向代理是“边缘终止 TLS”这个模型，就很容易想明白：代理和后端之间的明文 HTTP 是不可消除的，你能控制的是“让后端知道真实协议”，以及“让代理返回给客户端的地址保持 https”。接下来的所有配置，本质上都在解决这两件事。
2. 四个隐形开关，最常导致 HTTPS 请求降级
2.1 重定向返回的 Location 头：absolute_redirect 与端口陷阱
Nginx 里有两个开关会影响自动生成的跳转地址：absolute_redirect和port_in_redirect。absolute_redirect默认是 on，也就是说当你写return 301 /login时，Nginx 不会返回一个相对地址，而是帮你拼出一个完整的Location: https://example.com/login。拼的时候用的 scheme 来自当前连接，host 来自请求头，端口则受port_in_redirect控制。默认情况下这个开关是 off，对于 80 和 443 这样的标准端口没问题，可一旦你的反代服务跑在 8443 这类非标准端口，生成的 Location 会丢掉端口，客户端拿到一个https://example.com/...，连过去直接失败。这个坑隐蔽性很高，因为页面能打开，但每次跳转就断一次。
如果你写的是return 301 https://$host$request_uri;，那端口写不写、写多少，都取决于你这段字符串本身，跟上面的开关无关。所以我个人推荐在 80 端口做跳转时，直接采用这种显式写法，避免依赖默认开关。类似的还有server_name_in_redirect，默认是 on，意思是如果请求的 Host 头里的域名和server_name不一致，Nginx 可能用server_name来拼 Location，导致用户明明访问的是一个临时域名，跳转后却到了主域名。处理方式同样是尽量用$host变量，不要依赖 Nginx 自动拼接。
2.2 后端生成绝对 URL 时，X-Forwarded-Proto 没传等于“瞎了”
另一个高频降级场景来自后端应用自己生成的链接。比如 Java 的 Spring Boot 用RedirectView做跳转，Python 的 Flask 用redirect(url_for(...))，Go 的 net/http 也会在设置 Location 时拼r.URL.Scheme。问题在于，后端在反向代理后面看到的请求行几乎永远是 HTTP/1.1，因为 Nginx 转发给它的就是明文 HTTP。如果后端没有拿到“客户端其实是走 HTTPS 来的”这个信号，它生成的绝对 URL 自然全是http://。这个信号就是X-Forwarded-Proto请求头。
Nginx 里对应的配置是：
proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Forwarded-Host $host;注意，光加这个头还不够。后端框架必须“信任”这个头，才会用它覆盖自己看到的 scheme。以 Flask 为例，不加ProxyFix的话，werkzeug 只认本机 socket 的 scheme；加了之后才会把X-Forwarded-Proto当成真实协议。Spring Boot 则需要显式配置server.forward-headers-strategy: framework，不是天然就认的。很多同学配了 Nginx 的头之后发现还是没用，十有八九是后端没启动代理信任机制。
2.3 80 与 443 两个 server 块互相打架
很多人配置 80 跳 443 时，喜欢在两个 server 块里同时塞业务逻辑。比如 80 端口也配了proxy_pass，结果用户从 https 页面点击某个链接时，Nginx 根据默认 server 把请求接到了 80 端口的 location，导致一个本应保持 https 的请求变成了 http。正确做法是 80 端口只保留一句话：return 301 https://$host$request_uri;，所有真实业务逻辑全部放到 443 的 server 块里。这样无论用户怎么进来，最终都只会落到 HTTPS 这一条路上。
还要避免一种隐蔽的循环：443 server 块里的某个 location 又配置了return 301 http://...，或者后端应用里写死了redirect('http://...')。这种“显式降级”比配置缺漏更容易被忽视，因为它不是偶发，是每次必现。一旦看到“明明配了 https 还是一直跳 http”，先全局搜索一下代码里有没有写死的 http 跳转，比在 Nginx 里折腾半天更快。
2.4 HSTS 与浏览器缓存的“延迟翻车”
HSTS 这个头值得单独说。它本质上是告诉浏览器：在某个时间范围内，这个域名只能用 HTTPS 访问，不需要先从 http 跳一次。这能治“首跳降级”的毛病，但前提是你的 301 处理必须保持正确。因为第一次访问http://example.com的时候，浏览器还没收到过 HSTS，它不知道该走 https，只能先发一个 http 请求出去，等反向代理把它 301 到 https，然后响应里的 HSTS 才会被记录。如果这个 301 配错了，比如跳到了一个 http 地址，浏览器就会把这次错误响应也缓存下来，后面把 https 请求错误地重定向到 http。
HSTS 的max-age设得越长，踩坑后的回滚时间就越长。我见过有人一上来就设max-age=31536000; includeSubDomains，结果没几天发现某个子域名还有 http 资源在跑，整个子域都打不开了。本地开发阶段，建议先设一个短值，比如：
add_header Strict-Transport-Security "max-age=300" always;等线上确认全站 HTTPS 资源完整后，再慢慢拉长。注意always参数很关键，否则 Nginx 默认可能只在部分响应码下输出这个头。
3. 完整实操：从复现降级到彻底修复
3.1 先复现一个最小化降级现场
说这么多不如动手一次。我搭一个最小环境：一个 Flask 应用跑在127.0.0.1:8080，前端 Nginx 监听 80/443，证书用自签的就行。先故意不配X-Forwarded-Proto，看看会发生什么。
Flask 代码：
from flask import Flask, redirect, url_for app = Flask(__name__) @app.get("/login") def login(): # 模拟登录成功后跳转到控制台 return redirect(url_for("dashboard")) @app.get("/dashboard") def dashboard(): return "<meta charset=utf-8><h1>Dashboard</h1>" if __name__ == "__main__": app.run(host="0.0.0.0", port=8080)Nginx 配置，先写成“有问题”的版本：
server { listen 80; server_name example.com; return 301 https://$host$request_uri; } server { listen 443 ssl; server_name example.com; ssl_certificate /etc/nginx/ssl/example.com.pem; ssl_certificate_key /etc/nginx/ssl/example.com.key; location / { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; } }这个配置里，80 跳 443 是没问题的。但你用 https 打开/login后，Flask 的redirect(url_for("dashboard"))会生成什么？Flask 根本不知道外部协议是 https，它会基于内部 socket 的明文 HTTP 来拼 URL，生成一个http://example.com/dashboard的 Location。浏览器看到 https 页面返回了 http 地址，二话不说就跳过去。于是地址栏轻轻松松从 https 掉到 http。
3.2 修复方案：协议透传、重定向归一、HSTS
修复的第一步是把协议信息传进内网。修改 Nginx 的 location 块：
location / { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Forwarded-Host $host; proxy_set_header X-Forwarded-For $remote_addr; }第二步是让 Flask 信任这个头：
from werkzeug.middleware.proxy_fix import ProxyFix app.wsgi_app = ProxyFix(app.wsgi_app, x_proto=1, x_host=1)x_proto=1表示信任第一层X-Forwarded-Proto头。如果你的链路前面还有 CDN，可能需要把这个数字调大，对应代理层数。改完之后，Flask 内部读取到的url_for就会生成 https 开头，Location 自然正确。这里多说一句：如果后端代码写死了绝对地址，比如redirect("http://example.com/dashboard")，那不管 Nginx 怎么传头都没用，属于业务代码层面的问题。所以我建议业务代码里统一用相对路径，或者基于request.url拼接。
第三步是给上游返回的 Location 做一个兜底改写。有些老后端你改不动，或者第三方系统不受控，它返回的Location: http://backend:8080/...，那可以在 Nginx 层强制改写：
proxy_redirect http:// http://;这句的意思是：如果上游响应的 Location 头以http://开头，就替换成https://。注意这是通用写法，遇到更具体的场景可以写成：
proxy_redirect http://127.0.0.1:8080/ /;把内部地址和端口直接抹掉，换成根路径，这样客户端拿到的是干净的相对路径，后续跳转全凭浏览器自己补全协议。
最后加上 HSTS：
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;完整修复后的配置大致是：
server { listen 80; server_name example.com; return 301 https://$host$request_uri; } server { listen 443 ssl; server_name example.com; ssl_certificate /etc/nginx/ssl/example.com.pem; ssl_certificate_key /etc/nginx/ssl/example.com.key; add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always; location / { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Forwarded-Host $host; proxy_set_header X-Forwarded-For $remote_addr; proxy_redirect http:// http://; } }到这里，这个最小案例就从“必现降级”变成了“稳定 HTTPS”。
3.3 验证方案：curl、日志和抓包观察
验证不要只看浏览器。我用这套流程：先curl -I http://example.com/login，预期返回 301，Location 是https://example.com/login；再curl -I -k https://example.com/login，预期返回 200，且任何后续请求都不再出现 http 的 Location。curl -I不带-L可以看到每一跳的响应头，而不是被浏览器静默带上，非常利于定位问题。
如果还需要确认代理层内部对协议的理解，可以在 Nginx 的 access_log 格式里加上$scheme变量：
log_format proxy_debug '$remote_addr [$time_local] "$request" ' '$status "$http_referer" ' 'scheme=$scheme xfp=$http_x_forwarded_proto'; access_log /var/log/nginx/proxy_debug.log proxy_debug;这样你能看到 Nginx 对每个请求理解到的 scheme 是不是 https。注意$http_x_forwarded_proto是读取外部传入的头，而$scheme是当前连接协议，两者正好可以对照。
关于抓包，我多提醒一句：如果你想观察反代链路，抓包位置决定结论。在浏览器到反向代理之间抓，看到的应该是 TLS 加密流量，能看到 SNI 和证书，但看不到明文；在反向代理到后端之间抓，看到的才是 HTTP 明文。有些人抓了内网段，看到一堆 http，误以为自己的 HTTPS 被降级了，其实是反向代理本来就这么工作。
4. 常见坑位速查与真实排查记录
4.1 常见降级症状速查表
我把平时最常遇到的几种“降级”表现整理成一张表，排查时可以按图索骥：
| 症状 | 最可能原因 | 排查核心 | 解决办法 |
|---|---|---|---|
| 浏览器地址从 https 被跳到 http | 后端生成的 Location 用了 http / 80 端口 301 写了 http | curl 跟踪重定向头 | 传 X-Forwarded-Proto；后端信任代理头；80 跳转显式写 https |
| 页面能开，接口全被 Mixed Content 拦掉 | HTML/JS 里写死了 http 资源 | 浏览器控制台看被 block 的 URL | 前端资源用相对或动态协议；检查 CDN 域名 |
| 跳转后端口丢失或错误 | port_in_redirect off / server_name_in_redirect 取错 | 看 Location 头中的端口字段 | 显式写return 301 https://$host:8443$request_uri; |
| 访问 http:// 疯转 301 但到不了 https | 多个 server 块互相代理 | 看 80 与 443 两个配置块 | 80 只保留 return 301 |
| 下载/安装器报“连接不安全” | 镜像站反代返回 http 的 302 | 抓 Location 头 | proxy_redirect 改写或后端处理协议头 |
| 反代到本地服务出现 502 | 目标端口不是 HTTP 服务 / keepalive 连接复用 | error log、本地 curl | 修 proxy_http_version 与后端 listener |
镜像站、Nexus 仓库这类场景很容易踩表中第四第五行的坑。客户端请求 https 的下载地址，反代返回一个 http 的 302，很多包管理器和命令行工具要么拒绝跟从，要么直接开始走明文下载，错误日志里常出现类似000 connection failed或者 502 的提示。大部分时候不是后端挂了，而是 Location 的协议写错了。
4.2 一次 502 与错误 Location 叠加的排查实录
有一次我配一个本地服务，Nginx 反代到http://127.0.0.1:1572，客户端直接报 “unexpected status 502 bad gateway: unknown error”。那次排查顺序是先撇开反代，直接在服务器上curl -v http://127.0.0.1:1572/health，发现能通；再看 Nginx error.log，发现一堆upstream prematurely closed connection。后来发现是 upstream 用了 HTTP/1.1 长连接复用，但 Nginx 没有正确配置 keepalive，proxy_set_header Connection ""没加，导致连接被后端提前关闭。补上proxy_http_version 1.1;和清空 Connection 头之后，502 就消失了。
这个案例本身不是降级，但它提醒我：遇到 502 先别急着往证书和 scheme 上想，反代与后端之间的连接配置同样会产生误导性的报错。之后我在另一个项目里又遇到类似情况，客户端从 https 页面下载 Nexus raw 仓库的文件，拿到的链接却是一段http://绝对地址，而且路径里还带着内部端口。排查时发现 Nexus 依据的是它自己看到的请求头，没收到X-Forwarded-Proto，于是它只管按内部地址拼链接。给 Nginx 加上协议透传，并用proxy_redirect把内部端口抹掉后，一切才恢复正常。
4.3 多级代理、Docker 与前端构建的额外注意点
如果你的链路是 CDN 到 Nginx，再到 Docker 容器里的应用，那每一层都要注意协议的传递。CDN 已经终止 TLS 后，Nginx 接收到的连接可能只是 http，如果 Nginx 再执行proxy_set_header X-Forwarded-Proto $scheme;，你传给后端的协议头就变成了 http，覆盖掉了客户端真正的 https。这种时候要判断最外层已存在的头：可以先把 CDN 传过来的$http_x_forwarded_proto读出来，再做一次性覆盖，保证后端拿到的永远是整个链路的真实协议。
Docker 环境里还有另一个坑：容器内应用拿到的 Host 可能是容器名，比如web:8000，所以proxy_set_header Host $host几乎必不可少。容器里哪怕你外部是 HTTPS，反代和容器之间也还是 HTTP，这是正常的，不要试图在容器里再配一层证书。
前端构建时也容易引入协议问题。很多人会把接口地址写死成http://api.example.com，一旦页面部署到 https 环境，Mixed Content 拦截就来了。更好的做法是接口地址用相对路径，或者用window.location.protocol动态拼。尤其是微前端、多域名 CDN 的场景，写死协议等于给自己埋雷。发布前用脚本扫一遍产物里的http://，比线上被拦截后再救要省事得多。
最后说点我个人的习惯。踩过太多次“为什么又变 http”的坑之后，我现在做反向代理基本固定一套动作：80 端口只留一句 301，443 里把X-Forwarded-Proto、X-Forwarded-Host老实传进去，后端框架显式信任代理头，业务代码里的跳转一律用相对路径或基于当前请求对象拼 URL；关键域名上 HSTS 但先用短 max-age 观察一两周，没问题再拉长。每次改完配置，用 curl 把关键跳转路线打一遍，比让用户去浏览器里点一遍靠谱太多。这套流程写在这里，希望能帮你省掉几次半夜排障。
