Nginx proxy_pass 和绝对路径

mar*_*eli 6 nginx reverse-proxy paths node.js

我正在尝试使用 Nginx 在服务器(Ubuntu 14.04)上运行一些 nodejs 应用程序,我快完成了。这是我的服务器配置 ( /etc/nginx/sites-available/default):

server {
    listen 80;
    server_name my_domain.com;

    location /test1 {
        proxy_pass http://127.0.0.1:5000/;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_cache_bypass $http_upgrade;
    }

    location /test2 {
        proxy_pass http://127.0.0.1:5001/;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_cache_bypass $http_upgrade;
    }
}
Run Code Online (Sandbox Code Playgroud)

我有几个应用程序运行,它们都工作得很好,我可以与他们存取权限http://my_domain.com/test1http://my_domain.com/test2等等......

问题是,在其中一个应用程序中,我有几个绝对路径:
例如<a href="/">Home</a>
或(在快递内)
res.redirect('/');

此重定向不会转到,http://my_domain.com/test1但会转到http://my_domain.com/
有没有办法通过 nginx 配置告诉应用程序根位置实际上是http://my_domain.com/test1

我对 nginx 和一般的虚拟主机真的很陌生,我正在努力学习......任何帮助将不胜感激。
编辑:
结果curl -I http://127.0.0.1:5000是:

HTTP/1.1 200 OK
X-Powered-By: Express
Content-Type: text/html; charset=utf-8
Content-Length: 1376
ETag: W/"560-GGm/YYltkhKxiOVNZ99jqQ"
set-cookie: connect.sid=s%3AkZYCqLKvbhHhK3W8ECBN8G91s41paws4.ekLWefrd3NdQatT3VzFNozfnFs65YBEW9k9MNTdbQT0; Path=/; HttpOnly
Date: Sat, 15 Aug 2015 13:13:20 GMT
Connection: keep-alive  
Run Code Online (Sandbox Code Playgroud)

正如你所看到的,我没有得到位置标题......
顺便说一句,我设法使用子域解决了这个问题,这似乎按我的预期工作......无论如何,一个答案将不胜感激,因为我可能需要它在将来。

Chr*_*Wue 2

我发现实现这项工作的唯一方法是使用HttpSubModule并添加sub_filter指令。鉴于您的示例,它可能如下所示:

sub_filter 'href="/' 'href="/test1/';
sub_filter "redirect('/')" "redirect('/test1/')";
Run Code Online (Sandbox Code Playgroud)

显然,您的匹配越具体,您需要添加的选项就越多。如果你不那么具体,比如只是匹配"/,或者'/你需要更少的规则,但会遇到替换错误的危险。

您可能还需要添加:

sub_filter_types *;
Run Code Online (Sandbox Code Playgroud)

所以它不仅匹配text/html(这是默认的),还匹配 javascript 和 css 文件。显然*,这种懒惰的方法可能会破坏事情,并且应该首选使用特定的 mimetype。

最终正确的方法是修复Web应用程序。大多数 Web 框架都支持诸如基本 url/根 url/url 前缀之类的内容(似乎没有标准名称),您可以设置它来避免这个问题。