导航：首页 > 互联网科技 >

Nginx作为反向代理并以HTTP协议反向代理HTTPS服务

发表于：2024-11-18 作者：千家信息网编辑

千家信息网最后更新 2024年11月18日，这篇文章主要介绍"Nginx作为反向代理并以HTTP协议反向代理HTTPS服务"，在日常操作中，相信很多人在Nginx作为反向代理并以HTTP协议反向代理HTTPS服务问题上存在疑惑，小编查阅了各式资

千家信息网最后更新 2024年11月18日Nginx作为反向代理并以HTTP协议反向代理HTTPS服务

这篇文章主要介绍"Nginx作为反向代理并以HTTP协议反向代理HTTPS服务"，在日常操作中，相信很多人在Nginx作为反向代理并以HTTP协议反向代理HTTPS服务问题上存在疑惑，小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答"Nginx作为反向代理并以HTTP协议反向代理HTTPS服务"的疑惑有所帮助！接下来，请跟着小编一起来学习吧！

简单记录一下 Nginx 作为反向代理，以 HTTP 协议向下游客户端代理基于Spring Security 实现的HTTPS 服务时遇到的问题及解决办法。

背景

有个基于 Spring Security、Spring MVC 实现的 HTTPS Web 应用，需要通过 Nginx 作为反向代理向外提供服务。
Nginx 和 Web 应用部署在同一台机器，IP 为 10.115.6.165。Web 应用以 HTTPS 协议监听在端口 19026。

关于Nginx，因为我们会需要 headers more 模块中的 more_set_headers 指令。所以，如果是 Windows 环境，推荐在 http://nginx-win.ecsds.eu/ 下载，因为它的nginx编译进了更多模块。如果是 Linux 环境，也请确认 headers more 模块的 more_set_headers 指令可用。

Nginx 以 HTTP 的方式反向代理。

用以下配置运行 Ngnix，使Nginx用 HTTP 协议在 9080 端口反向代理 19026 上的 HTTPS 服务。

server {
    listen       9080;
    server_name  10.115.6.165;

    location /databoard/ {
        proxy_pass  https://10.115.6.165:19026/databoard/;
        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 REMOTE-HOST        $remote_addr;
        proxy_set_header X-Forwarded-Proto  $scheme;
        proxy_redirect off;
    }
}

但是如果我们用浏览器访问http://10.115.6.165:9080/databoard/login，就会发现如下图所示的两个问题：

1）后端服务使用 redirect 重定向导致的问题

浏览器地址栏上显示被重定向到了https://10.115.6.165/databoard/dataCmder。这是因为后端Web应用执行了redirect重定向语句，而重定向的协议、地址是基于web应用上下文的，而nginx并没有做特别的处理就转发给了浏览器，浏览器自然不能访问到这个地址。解决办法如下：

map $upstream_http_Location $location {
  ~https://10.115.6.165/(?.*) http://10.115.6.165:9080/$param;
  default $upstream_http_Location;
}

server {
    ... ...
    location /databoard/ {
        ... ...
        more_set_headers -s '301 302' 'Location $location';

2）Cookie 携带 Secure 属性导致浏览器不能在请求中携带 SessionID 的问题。

有 Secure 属性的 Cookie 意味着如果浏览器不是使用 HTTPS 与服务建立链接，那么这个 cookie 里的值不会随请求一起向服务器发送。要解决这个问题就需要在 Nginx 中把 cookie 中的 Secure 属性去掉再传给浏览器。解决办法如下：

map $sent_http_set_cookie $resp_cookie {
    ~*(?.+)Secure $CK_WITHOUT_SECURE;
}

server {
    ... ...
    location /databoard/ {
        ... ...
        more_set_headers 'Set-Cookie: $resp_cookie';

完整的相关配置

map $upstream_http_Location $location {
  ~https://10.115.6.165/(?.*) http://10.115.6.165:9080/$param;
  default $upstream_http_Location;
}

map $sent_http_set_cookie $resp_cookie {
    ~*(?.+)Secure $CK_WITHOUT_SECURE;
}

server {
    listen       9080;
    server_name  10.115.6.165;

    location /databoard/ {
        proxy_pass  https://10.115.6.165:19026/databoard/;

        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 REMOTE-HOST        $remote_addr;
        proxy_set_header X-Forwarded-Proto  $scheme;
        proxy_redirect off;

        more_set_headers -s '301 302' 'Location $location';
        more_set_headers 'Set-Cookie: $resp_cookie';
    }
}

Nginx 以 HTTPS 的方式反向代理。

如果 nginx 是以 HTTPS 协议向外提供反向代理，那么无论使用七层代理还是四层代理配置起来都很简单，如下：

3）四层反向代理。

stream {
    upstream databoardServer {
        hash $remote_addr consistent;
        server 10.115.6.165:19026 weight=5;
    }

    server {
        listen 9082;
        proxy_connect_timeout 1s;
        proxy_timeout 3s;
        proxy_pass databoardServer;
    }
}

4）七层反向代理。

server {
    listen       443 ssl;
    server_name  10.115.6.165;
    ssl_certificate D:\\tmp\\opensslCrt\\demoAppChain.crt;
    ssl_certificate_key D:\\tmp\\opensslCrt\\demoApp.key;

    location / {
        proxy_pass https://10.115.6.165:19026;
        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 Referer https://10.115.6.165;
    }
}

关于 Spring Session Cookie Secure 配置

当时为了不用在 Nginx 上处理 Cookie ，想通过直接配置 Spring Web 应用不让 Cookie 带上 Secure 属性。于是直接修改配置 application.properties 如下，但是返回给 nginx 的 Cookie 还是带 Secure 属性。（类似的还有cookie的HttpOnly也不仅仅是一个配置能决定的）