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