RHEL7.9环境下Nginx配置HTTPS代理同机器HTTP地图服务的技术咨询

嗨，我来帮你搞定这个混合内容的头疼问题——浏览器阻止HTTPS页面加载HTTP资源确实很烦人，完全不用开“允许不安全内容”这个临时开关，通过Nginx代理就能完美解决，我给你梳理两种可行的方案，还有关键配置细节：

问题背景回顾 #

你在RHEL7.9上跑着两个服务：

• WebApplicationA：通过Nginx以HTTPS运行在443端口，地址是https://a.b.c.d
• WebApplicationB：以HTTP运行在3650端口，提供地图瓦片，地址是http://a.b.c.d:3650
  WebApplicationA要加载WebApplicationB的资源，但浏览器因为混合内容安全策略拦截了请求，所以我们需要把WebApplicationB的HTTP请求转换成HTTPS的访问路径。

方案一：在现有443端口的Server块中添加路径代理（推荐） #

这种方案不用新开端口，直接在你现有的HTTPS Server块里加一个专属的location规则，把特定路径的请求转发到WebApplicationB的3650端口，这样WebApplicationA只要用https://a.b.c.d/[自定义路径]/就能访问地图瓦片了，完全符合浏览器的安全要求。

修改后的完整Nginx Server块配置如下：

server {
    listen       443 ssl;
    server_name  mapperapp;

    rewrite /login / redirect;

    ssl_certificate      nginx.crt;
    ssl_certificate_key  nginx.key;

    ssl_session_cache    shared:SSL:1m;
    ssl_session_timeout  60m;

    ssl_ciphers  HIGH:!aNULL:!MD5;
    ssl_prefer_server_ciphers  on;

    # WebApplicationA的原有根路径配置
    location / {
        root   html;
        index  index.html index.htm;
    }

    # 新增：代理WebApplicationB的地图服务
    location /map-tiles/ {
        # 转发请求到本地3650端口的WebApplicationB，注意末尾的/
        proxy_pass http://a.b.c.d:3650/;
        # 传递必要的头信息，让WebApplicationB识别HTTPS请求来源
        proxy_set_header X-Forwarded-Proto https;
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

配置关键点说明：

• location /map-tiles/：你可以自定义这个路径前缀（比如/tiles/也行），用来区分WebApplicationA和WebApplicationB的请求，避免路径冲突
• proxy_pass末尾的/：这个细节很重要，它会把/map-tiles/后面的路径直接拼到WebApplicationB的根路径下，比如请求https://a.b.c.d/map-tiles/abc/123.png会被转发到http://a.b.c.d:3650/abc/123.png
• proxy_set_header：这些头信息是让WebApplicationB知道请求是通过HTTPS代理过来的，避免它返回HTTP相关的错误路径或资源链接

配置修改完后，重载Nginx让配置生效：

sudo systemctl reload nginx

之后你只需要把WebApplicationA里的地图瓦片请求地址改成https://a.b.c.d/map-tiles/开头的路径即可。

方案二：新增独立HTTPS端口的Server块（你已尝试的方案） #

你自己新增的4653端口Server块是完全可行的，配置逻辑没问题，能直接通过https://a.b.c.d:4653/访问WebApplicationB的资源。不过这个方案需要额外开放4653端口，而且WebApplicationA里的地图请求要改成带端口的地址，相比方案一不够优雅，但如果你的业务有特殊需求（比如需要独立端口区分服务），这个方案也完全能用。

最后提醒 #

不管用哪种方案，都要确保Nginx有权限访问3650端口的本地服务（一般本地服务默认都能访问），而且修改配置后一定要重载或重启Nginx，避免配置不生效。

备注：内容来源于stack exchange，提问作者thornbe