分享一个Nginx反向代理的另类应用案例
内容提要
文章介绍用Nginx反向代理解决OA区无法直接访问第三方应用的问题：约定访问格式为代理地址/IP:端口/路径，Nginx从URI提取后端节点和路径进行动态代理，并用subs_filter替换HTML、JS、CSS中的资源及Ajax地址，以https-前缀兼容HTTPS后端。最终用户只需访问统一代理地址，通过导航页点击即可打开各应用控制台。
延伸解读
动态代理的核心：从URI提取后端节点
文章方案的关键在于利用Nginx的$request_uri变量，通过正则提取第一段路径作为后端节点（IP:端口），剩余部分作为后端路径。这样无需为每个应用单独配置location或端口，实现了“一个代理地址适配多个后端”的动态路由。这种设计特别适合后端应用框架统一、页面路径无唯一性的场景，避免了端口映射的维护负担。
资源地址替换：subs_filter的用武之地
由于后端HTML、JS、CSS中大量使用相对路径或绝对路径引用资源，直接代理会导致资源加载失败。文章使用subs_filter模块，将href、src、Ajax请求地址等替换为符合代理约定的完整URL。需要注意的是，替换规则需根据实际调试结果逐步补充，例如针对XMLHttpRequest的特殊路径。同时要关闭gzip压缩，否则替换可能失效。
HTTPS后端的兼容处理：https-前缀约定
实际测试发现部分后端使用HTTPS协议（伪证书模式），原设计无法直接访问。文章通过约定在路径第一段IP前添加“https-”前缀来区分协议，Nginx据此设置proxy_scheme为https。这种约定简单有效，但要求用户或导航页生成正确的访问链接。对于HTTP后端，前缀可加可不加，保持了灵活性。
调试与导航页：提升可用性的小技巧
文章建议集成echo模块打印变量以辅助调试，便于排查代理规则问题。最终在Nginx的/html目录放置导航页，用户只需访问统一代理地址即可点击进入各应用控制台，无需记忆复杂路径。这种设计降低了用户操作门槛，也减少了跳板机的维护工作量，体现了运维手段解决实际问题的思路。
Q&A
OA区无法直接访问第三方应用，用Nginx反向代理怎么解决？
约定访问格式为代理地址/IP:端口/路径，Nginx从URI提取后端节点和路径进行动态代理，并用subs_filter替换HTML、JS、CSS中的资源及Ajax地址，以https-前缀兼容HTTPS后端。最终用户只需访问统一代理地址，通过导航页点击即可打开各应用控制台。
Nginx动态反向代理时，如何从URL中提取后端节点和路径？
使用正则表达式从$request_uri中提取：if ( $request_uri ~* "^/(https-|)([^/]+)/(.*)$" ) { set $proxy_scheme_url "$1"; set $node "$2"; set $proxy_url "$3"; }，其中$1为协议前缀（https-或空），$2为后端节点（IP:端口），$3为后端路径。
为什么需要替换HTML、JS、CSS中的资源地址？怎么替换？
因为应用页面使用相对路径，直接代理会导致资源请求无法正确路由。使用Nginx的subs_filter模块，将href/src等属性中的相对路径替换为代理格式，如将href="/js/jquery.min.js"替换为href="http://myproxy.oa.com/192.168.2.100:8080/js/jquery.min.js"，同时替换JS中的Ajax请求地址。
如何让Nginx反向代理同时支持HTTP和HTTPS后端？
在URL约定中增加协议标识：对于HTTPS后端，在IP前加https-前缀，如http://myproxy.oa.com/https-192.168.2.101:8080/path；Nginx通过正则提取该前缀，若为https-则设置$proxy_scheme为https，否则为http，从而动态选择代理协议。
配置Nginx反向代理时有哪些注意事项？
需要关闭gzip压缩（proxy_set_header Accept-Encoding ""），以防subs_filter无法替换内容；如果被代理地址是域名，需配置resolver指令避免502错误；调试时可集成echo模块打印变量；替换规则需根据实际请求逐步完善。
最终用户如何访问这些被代理的应用？
用户只需访问统一的代理地址http://myproxy.oa.com/，Nginx会返回/html目录下的index.html导航页面，展示所有后端节点链接，点击即可访问对应应用的控制台，无需再登录跳板机。
