我的 nginx 充当反向代理时出现了一个奇怪的情况。当我的后端网站通过 nginx 反向代理响应用户（用户的浏览器）请求时，用户将在 302 FOUND 重定向中获得 http 协议，而不是 https 协议。
我遇到了这样一种情况，nginx 反向代理上的两件事可以帮助我解决重定向中协议错误的这种情况：
add_header Content-Security-Policy "upgrade-insecure-requests";
或者
proxy_redirect http:// https://;
然而这些命令的方法却非常不同。
我更愿意使用第一个 CSP 选项，因为它似乎是解决这个问题的最佳方法。但是，我不太确定使用第二个“proxy_redirect”选项时会发生什么。
更具体地说，我的后端正在监听 HTTP (80) 和 HTTPS (443)。但是，我后端的 HTTPS (TLS) 证书已过期。在 nginx 反向代理配置中，我使用 HTTP 协议将“proxy_pass”传递到后端。
在这种情况下，当我使用“proxy_redirect”时，nginx 反向代理似乎无法创建 TLS 握手。但是，它不会终止“proxy_pass”连接，而是继续通过 HTTP 协议进行通信。至少这是我在后端的 Web 服务器日志中看到的内容。从用户的角度来看，302 FOUND 重定向现在设置为 HTTPS，这似乎没问题。该网站似乎运行正常，没有任何问题。nginx 反向代理和控制台中都没有错误。
那么，nginx 反向代理中的这种行为正常吗？当我不想使用有效的 HTTPS 连接到后端时，我应该实现哪个选项？当后端完全缺少 HTTPS 证书时，nginx 反向代理是否会以相同的方式使用“proxy_redirect”选项？
答案1
因此我查看了 nginx 文档：https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_redirect
“proxy_redirect”指令的声明很明确：
Sets the text that should be changed in the “Location” and “Refresh” header fields of a proxied server response.
据我了解，在这种情况下，代理服务器响应是来自后端 Web 服务器的响应。这意味着端口 80 上的协议 HTTP 上的“proxy_pass”指令与“proxy_redirect”指令没有直接关系，反之亦然。
这意味着在这种情况下，我可以自由地使用“proxy_redirect”指令来解决我的问题。第一种 CSP 方法也可用，但在这种情况下，将“Location”标头从 http 覆盖为 https 的工作依赖于用户的浏览器。我认为更好的解决方案是使用“proxy_redirect”指令将此责任设置为 nginx。如果出现问题，我认为最好依靠适当的 nginx 设置，而不是依靠多个不同的浏览器。