Nginx 反代后协议错乱：X-Forwarded-Proto 排查与修复

发布时间：2026-09-24 12:31 更新时间：2026-09-24 12:31 阅读量：0

网站挂上 Nginx 反向代理之后，浏览器地址栏明明是 https，页面里的跳转却指向 http，或者点一次登录就被反复重定向、最后报“重定向次数过多”。这类问题多半不是证书配错，而是后端应用拿到的“当前协议”是 http，于是它按 http 拼出了 Location 头或静态资源地址。解决问题的关键，在于把客户端真实协议一路带到应用层，并让应用愿意相信这个信息。

本文按“现象 → 原理 → 配置 → 验证”的顺序展开，命令和配置都可以直接照抄到测试环境验证，具体参数含义以 Nginx 与所使用框架的官方文档为准。

一、为什么后端会认为请求是 http

Nginx 与后端之间通常是明文 HTTP 通信，TCP 连接本身没有 TLS。对后端来说，它看到的请求就是从 127.0.0.1 或内网地址发来的普通 HTTP 请求，scheme 自然是 http。Nginx 默认会补上几个头：X-Forwarded-For 记录客户端 IP，X-Forwarded-Proto 记录原始协议，X-Forwarded-Host 记录原始 Host。但这些头只是“告知”，后端框架不一定采信。

很多框架出于安全考虑，默认只信任来自本机或白名单代理的转发头；如果代理不在白名单里，框架会忽略 X-Forwarded-Proto，继续用连接本身的协议。另一种情况是 Nginx 根本没传这个头，或者传了固定值，后端自然无从判断。

还有一种容易被忽略的链路：CDN 或负载均衡在前、Nginx 在后。此时客户端到 CDN 是 https，CDN 回源到 Nginx 可能又是 http，如果中间环节没有把 X-Forwarded-Proto 继续往后传，Nginx 的 $scheme 就会变成 http，错误会一路传导到应用。

二、Nginx 侧如何正确传递协议

最基础的配置是显式设置这个头。下面这段可以放在 server 或 location 块里，注意变量要用 $scheme，它表示 Nginx 与客户端（或上一跳代理）之间实际使用的协议：

location / {
    proxy_pass http://127.0.0.1:8080;

    proxy_set_header Host              $host;
    proxy_set_header X-Real-IP         $remote_addr;
    proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-Port  $server_port;
}

如果 Nginx 前面还有一层可信代理（比如自家 CDN 或四层负载），它会送来一个 X-Forwarded-Proto，此时更稳妥的写法是“有则沿用、无则用当前协议”，避免把上游信息覆盖掉：

map $http_x_forwarded_proto $real_proto {
    default $http_x_forwarded_proto;
    ""      $scheme;
}

server {
    listen 443 ssl;
    server_name www.example.com;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host              $host;
        proxy_set_header X-Forwarded-Proto $real_proto;
        proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
    }
}

需要提醒的是，不能无条件相信客户端传来的 X-Forwarded-Proto。这个头是普通 HTTP 头，任何人都能伪造。只有当请求确实来自你信任的代理地址时，才应该沿用上游值，否则应当强制用 $scheme。在 Nginx 侧可以通过 allow/deny 或防火墙限制回源来源，具体策略结合自身拓扑决定。

另外，如果站点同时监听 80 和 443，想统一跳转到 https，可以在 80 的 server 块里做 301 跳转，而不是让应用自己判断协议去跳，这样能减少一层不确定性。

三、后端应用要“信任”代理头

Nginx 传对了，问题只解决一半。主流框架都要求显式声明信任的代理，否则会忽略转发头。以下写法只作示意，具体配置项名称与写法以对应框架官方文档为准。

以常见的 Java 应用为例，可以在配置中开启对转发头的识别，并限定可信代理网段，例如只信任本机和内网段。PHP 应用如果自己拼重定向地址，通常要读取 $_SERVER['HTTP_X_FORWARDED_PROTO'] 来判断协议；如果用的是框架自带的重定向助手，一般有对应开关或中间件需要启用。Node.js 的 Express 系应用常通过设置信任代理层级来让 req.protocol 返回正确值。

这里有个常见坑：信任层级设成“全部信任”虽然省事，但等于把伪造协议头的风险完全交给客户端，公网直连场景下不建议这么做。更稳妥的做法是指定可信 IP 段或代理跳数。

四、验证与排查顺序

改完配置别急着下结论，按下面的顺序验证一遍，能快速定位问题卡在哪一层。

第一步，直接看后端收到的头。如果后端有调试接口或日志能打印请求头，先确认 X-Forwarded-Proto 是否到达且值正确。没有的话，用 curl 模拟带头的请求，观察应用返回的 Location：

curl -sI -H 'Host: www.example.com' \
     -H 'X-Forwarded-Proto: https' \
     http://127.0.0.1:8080/login | grep -i '^location'

如果返回的 Location 是 https 开头，说明应用逻辑本身没问题，问题在 Nginx 没把头传过去；如果仍是 http，说明应用没有采信这个头，需要回去检查框架的信任代理配置。

第二步，在 Nginx 侧确认发出去的头。可以临时打开调试日志，或用一个带 echo 模块的 location 回显请求头，也可以直接抓包看明文 HTTP 请求：

tcpdump -i lo -A -s 0 'tcp port 8080 and (tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x47455420)' -c 10

这条命令抓取发往 8080 的 GET 请求明文，能在输出里看到实际发送的请求头。抓包需要 root 权限，生产环境请短暂执行并注意脱敏，具体过滤表达式以 tcpdump 官方手册为准。

第三步，检查整条链路。如果前面还有 CDN 或负载均衡，逐段确认 X-Forwarded-Proto 是否被覆盖、清空或写死成 http。很多“Nginx 配置明明没错”的案例，问题其实出在更前面那一跳。

最后提醒几个避坑点：一是不要同时用 X-Forwarded-Proto 和自定义头（比如 X-Forwarded-Scheme）却只配了一处；二是重定向地址里的域名和端口要跟外部访问一致，反代改了端口时尤其容易出错；三是修改后记得 reload 而不是 restart，用 nginx -t 先检查语法。

小结

协议错乱的本质是“真实协议信息在链路上丢失或被应用忽略”。处理思路很清晰：Nginx 用 $scheme 或可信上游值设置 X-Forwarded-Proto，后端框架把代理加入信任列表并读取该头来生成链接与跳转。配置完成后用 curl 验证 Location、必要时抓包确认请求头，再逐段检查上游代理，绝大多数重定向错乱都能定位到具体环节。上线前建议在测试环境完整走一遍登录与跳转流程，避免改完只在首页看着正常、进到业务页面又出问题。

继续阅读