我的 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 协议进行通信。至少这是我在后端网络服务器日志中看到的。从用户的角度来看，302 FOUND 重定向现在设置为 HTTPS，这似乎没问题。该网站似乎运行没有任何问题。nginx 反向代理和控制台中都没有错误。
那么nginx反向代理中的这种行为正常吗？当我不想使用有效的 HTTPS 连接到后端时，我应该实施哪个选项？当后端完全丢失 HTTPS 证书时，nginx 反向代理的行为是否与“proxy_redirect”选项相同？
所以我检查了nginx文档：https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_redirect
“proxy_redirect”指令的声明很明确：
据我了解，这种情况下的代理服务器响应是来自后端网络服务器的响应。这意味着端口 80 上的 HTTP 协议上的“proxy_pass”指令与“proxy_redirect”指令没有直接关系，反之亦然。
这意味着在这种情况下我可以自由地使用“proxy_redirect”指令来解决我的问题。第一种 CSP 方法也可用，但在这种情况下，将“Location”标头从 http 覆盖为 https 的工作依赖于用户的浏览器。我认为更好的解决方案是使用“proxy_redirect”指令将这个责任设置给 nginx。如果出现问题，我认为依赖正确的 nginx 设置比依赖多个不同的浏览器更好。