Nginx 代理配置导致浏览器应用网页页面加载失败的分析与解决

Nginx 代理配置导致应用页面加载失败的分析与解决

前期部署信息：

部署DM数据库DEM时，配置了nginx代理，conf配置内容如下：

    charset utf-8;client_max_body_size 128M;listen 4567;server_name 192.168.1.156;root /opt/h5/;index index.html;location /tomcat {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;# 隐藏 /tomcat 路径rewrite ^/tomcat(.*)$ $1 break;}

问题现象

我遇到了一个问题：直接访问http://192.168.1.156:8080/dem/是正常的，但是访问 http://192.168.1.156:4567/tomcat/dem/ 时，页面却无法正常显示，表现为一个不停转圈的加载状态，无法进入登录界面。

在这里插入图片描述
或者报错“获取系统属性失败！加密响应失败！”

分析原因

经过多次排查和测试，我发现问题主要出在 Nginx 的代理配置上，可能的原因包括以下几点：

资源路径不一致
应用中的 JavaScript、CSS 等静态资源可能使用了相对路径或绝对路径。在代理过程中，如果 Nginx 没有正确映射这些路径，浏览器会无法加载资源，导致页面卡在加载状态。
路径重写配置问题
我尝试使用 rewrite 指令隐藏代理路径（如 /tomcat），但与 proxy_pass 结合使用时，可能会导致请求 URL 被错误解析，后端应用接收到的路径与预期不符，从而引发加载失败。
代理转发未完全适配应用需求
如果应用内部的 AJAX 请求或其他逻辑依赖特定的 URL 路径，而 Nginx 的代理配置没有正确处理这些请求，可能会导致功能异常。

处理方法

经过反复调整，我最终通过以下两种 Nginx 配置方案成功解决了问题：

方法一：精确代理到 `/dem/` 路径

server {charset utf-8;client_max_body_size 128M;listen 4567; # 监听 4567 端口，便于局域网访问server_name 192.168.1.156;root /opt/h5/;index index.html;location /dem/ {                                #修改了这一行proxy_pass http://127.0.0.1:8080/dem/;               #修改了这一行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;# 尝试隐藏 /tomcat 路径（可选，未完全生效时可移除）rewrite ^/tomcat(.*)$ $1 break;}
}

配置说明：
- 通过 location /dem/ 将请求直接代理到 http://127.0.0.1:8080/dem/，保持路径一致性。
- 添加了基本的代理头信息（如 Host、X-Real-IP 等），确保后端能正确识别请求来源。
- rewrite 指令用于隐藏 /tomcat 路径，但测试发现它对最终成功访问并非必要，可根据需求保留或移除。

方法二：代理根路径到 Tomcat

server {listen 7890;server_name 192.168.1.156;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;}
}

配置说明：
- 将所有请求代理到 http://127.0.0.1:8080/，适用于 Tomcat 应用部署在根路径下的场景。
- 这种方式简单直接，减少了路径匹配的复杂性，适合不需要额外路径前缀的情况。

结果

经过以上配置调整，我成功实现了目标：

方法一：访问 http://192.168.1.156:4567/dem/，页面正常加载并跳转到登录界面。
方法二：访问 http://192.168.1.156:7890/dem/，同样可以正常访问应用，页面加载和功能运行无异常。

两种方法都解决了页面加载失败的问题，具体选择取决于你的应用部署方式和访问需求。

总结

通过这次排查和解决，我总结了以下几点经验，供其他开发者参考：

保持路径一致性
在配置 proxy_pass 时，确保前端请求的路径与后端应用的实际路径一致，避免因路径不匹配导致资源加载失败。
谨慎使用路径重写
rewrite 虽然可以隐藏代理路径，但与 proxy_pass 结合使用时容易出错。如果不需要复杂的路径转换，建议直接使用简单代理。
调试技巧
在排查类似问题时，可以通过浏览器开发者工具（F12）检查网络请求，查看资源加载是否失败，或查看 Nginx 的 error_log 日志定位问题。