NGINX proxy_pass 重写资产 uri答案

【问题标题】：NGINX proxy_pass rewrite asset uriNGINX proxy_pass 重写资产 uri
【发布时间】：2019-05-26 16:34:13
【问题描述】：

我正在尝试通过 subdomian 对 localhost/文件夹进行基本的 NGINX 反向代理，但我很难让它重写我的资产+链接。

我的http://localhost:8080/myapp/ 工作起来就像一个魅力，但通过 NGINX+子域它在子文件夹资产上失败了。

我相信我对 NGINX 的“重写”条款感到困惑。

如何重写进入客户端浏览器的 HTML 以删除 /myapp/ 上下文？

server {
    listen       443 ssl;
    server_name  app1.domain.com;
    location / {
        rewrite ^/myapp/(.*) /$1 break; # this line seems to do nothing
        proxy_pass http://localhost:8080/myapp/;
    }
}

我希望在没有子文件夹 /myapp/ 的情况下重写生成的 HTML（通过 https://app1.domain.com），因此当请求资产时，可以找到它们而不是针对 https://app1.domain.com/myapp/assets/ 的 404。它应该只是https://app1.domain.com/assets/（如果我手动去那里他们工作）

--谢谢。

【问题讨论】：

标签： nginx url-rewriting subdomain reverse-proxy

【解决方案1】：

作为 nginx proxy_pass 文档 states:

在某些情况下，无法确定要替换的请求 URI 部分：

...

当使用 rewrite 指令在代理位置内更改 URI 时，将使用相同的配置来处理请求（中断）：
location /name/ {
    rewrite    /name/([^/]+) /users?name=$1 break;
    proxy_pass http://127.0.0.1;
}
在这种情况下，指令中指定的 URI 将被忽略，并将完整更改的请求 URI 传递给服务器。

因此，在您将 /myapp/assets/some_asset URI 重写为 /assets/some_asset 并使用 break 标志之后，使用此配置块，nginx 会忽略 proxy_pass 指令上的 /myapp/ 后缀并将 /assets/some_asset 请求传递到您的后端。不管多么奇怪，你需要的是改用这个重写规则：

rewrite ^(/myapp/.*)$ $1 break;

另一个（可能更好）的解决方案是使用两个 location 块：

location / {
    proxy_pass http://localhost:8080/myapp/;
}
location /myapp/ {
    proxy_pass http://localhost:8080;
}

【讨论】：

这个简介修复了我的资产 [[[[rewrite ^(/myapp/.*)$ $1 break;]]]]，但没有重写客户端以隐藏子文件夹/上下文.谢谢。它解决了“最”烦人的问题。现在我只需要弄清楚如何让它隐藏所有 /myapp/ 链接并将其视为子域的根。理想情况下，tnis 也会解决之前的资产问题。如果 /login 实际上是 /login 而不是 /myapp/login（例如）。
这是一项复杂得多的任务。如果您不能让您的应用程序只生成相对链接（这可能是不可能的），那么唯一的方法是即时更改您的后端响应，用新链接重写所有生成的链接。有一个ngx_http_sub_module 可以做到这一点，但它不是默认构建的，所以为了使用它，你必须从源代码手动构建 nginx。
使用nginx -V 命令检查您的 nginx 构建参数。如果存在字符串--with-http_sub_module，则无需重新编译nginx即可使用该模块。
我可能会回到我的旧设置。我的后端是 Tomcat，我曾经为我的所有子域拥有虚拟服务器。效果很好，每个“应用程序”都以自己的根目录运行。我真的不喜欢在共享页眉/页脚代码方面肯定会遇到困难的相对链接。但是上周我对 Tomcats 的处理感到沮丧，因为它开始在我所有的其他应用程序库中部署我的所有应用程序。超级烦。但是允许 Tomcat 查看完整的域请求工作正常。我希望使用 NGINX 和 Tomcat 中的通用子应用程序来简化它。
顺便说一句，如果您继续使用 nginx，请考虑直接使用 nginx 提供静态文件而不向后端传递额外的请求，这样效率会高得多。

【解决方案2】：

从 Ivan 的回复中得到反馈并将我的解决方案最终确定为：

server {
    listen       443 ssl;
    server_name  app1.domain.com;
    location / {
        sub_filter '/myapp/'  '/'; # rewrites HTML strings to remove context
        sub_filter_once off; # ensures it loops through the whole HTML (required)
        proxy_pass http://localhost:8080/myapp/;
    }
}

【讨论】：