使用 Nginx 从同一服务器为多个 Angular 应用程序提供服务 [英] Serve multiple Angular apps from the same server with Nginx

问题描述

我从 Nginx 中的同一个 server 块为多个 angular 应用程序提供服务.因此，为了让用户直接浏览我声明的某些自定义 Angular 路由而不必通过主页(并避免 404 页面)，我将这些路由从 nginx 转发到每个 Angular 应用程序的 index.html，我在每个 location 中添加了一个 try_files:

I'm serving multiple angular apps from the same server block in Nginx. So in order to let the user browse directly to certain custom Angular routes I've declared without having to go through the home page (and avoid the 404 page), I'm forwarding these routes from nginx to each angular app's index.html, I've added a try_files to each location:

server {
    listen 80;
    server_name website.com;

    # project1
    location / {
        alias /home/hakim/project1/dist/;
        try_files $uri /index.html;
    }

    # project2
    location /project2/ {
        alias /home/hakim/project2/dist/;
        try_files $uri /index.html;
    }

    # project3
    location /project3/ {
        alias /home/hakim/project3/dist/;
        try_files $uri /index.html;
    }
}

此解决方案在转到 Angular 路由时避免了 404 错误，但问题是当我浏览到 /project2/ 或 /project3/ 时，它会重定向到/project1/.这显然不是预期的，因为我希望每个位置都转发到适当项目的 /project-i/index.html.

This solution avoids the 404 error when going to an Angular route, but the problem is that when I browse to /project2/ or /project3/ it redirects to the /project1/. That's obviously not what is expected, since I want to have each location to forward to the /project-i/index.html of the adequate project.

推荐答案

在一个域上拥有多个独立的应用程序通常是一种糟糕的安全做法.

It is generally a bad security practice to have multiple independent apps on a single domain.

但是，我相信您在这里面临的是 try_files 工作方式的特殊性——根据 http://nginx.org/r/try_files,

However, I believe what you're facing here is the peculiarity of the way that try_files works -- according to http://nginx.org/r/try_files,

如果没有找到任何文件，则内部重定向到最后一个参数中指定的 uri.

If none of the files were found, an internal redirect to the uri specified in the last parameter is made.

实际上，这意味着如果在您的 /index.html 规范之后有一个额外的参数(即，基本上，任何东西)，那么您的代码就会像您预期的那样工作；然而，由于缺少任何这样的最终参数，在每种情况下发生的情况是所有内容都被重定向回 / location，就像 GET/index.html HTTP/1.1 请求应该已经发出(除了它都是在 nginx 内部完成的).

Effectively, this means that if there would have been an extra parameter after your /index.html specification (i.e., basically, anything at all), then your code would have worked as you expected; however, due to the lack of any such final parameter, what happens in each case is that everything gets redirected back to the / location, as if a GET /index.html HTTP/1.1 request was to have been made (except it's all done internally within nginx).

因此，作为一种解决方案，您可以修复内部重定向的路径以保持在同一 location 内(例如，/projectX/index.html)，或保留路径，但让最后一个参数返回错误代码(例如，=404，只要您的文件始终存在，就永远不会触发).

So, as a solution, you can either fix the path for the internal redirect to remain within the same location (e.g., /projectX/index.html), or leave the paths alone, but make the last parameter return an error code (e.g., =404, which should never be triggered as long as your file always exists).

• 例如，try_files $uri/projectX/index.html;,

或者，try_files $uri/index.html =404;.

如:

location /projectX/ {
    alias /home/projectX/dist/;
    try_files $uri /projectX/index.html; # last param is internal redirect
}

或者:

location /projectX/ {
    alias /home/projectX/dist/;
    try_files $uri /index.html =404;
}

总而言之，请注意 /projectX/index.html 只能用作最后一个参数，而 /index.html 只能用作非最终参数一个.

In summary, note well that /projectX/index.html would only work as the last parameter, and /index.html would only work as a non-final one.

这篇关于使用 Nginx 从同一服务器为多个 Angular 应用程序提供服务的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！