web-dev-qa-db-ja.com

Nginx proxy_passと絶対パス

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;
    }
}
_

私はいくつかのアプリを実行していますが、それらはすべて正常に動作し、_http://my_domain.com/test1_、_http://my_domain.com/test2_などを使用してそれらにアクセスできます...

問題は、このアプリの1つにいくつかの絶対パスがあることです。
例えば。 _<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  
_

ご覧のように、ロケーションヘッダーが表示されません...
ところで、私はサブドメインを使用して問題を解決することができましたが、期待通りに機能しているようです...とにかく答えは、将来必要になる可能性があるので、ありがたいです。

nginxreverse-proxynode.jspaths
6
marco.marinangeli

これを機能させるための唯一の方法は、 HttpSubModule を使用し、sub_filterディレクティブを追加することです。あなたの例を考えると、それは次のようになるでしょう：

sub_filter 'href="/' 'href="/test1/';
sub_filter "redirect('/')" "redirect('/test1/')";

明らかに、あなたのマッチングがより具体的であるほど、あなたが追加しなければならないより多くのオプションです。 "/または'/に一致するなど、具体性を低くすると、必要なルールは少なくなりますが、間違ったものに置き換えられる危険があります。

おそらく次も追加する必要があります：

sub_filter_types *;

したがって、text/html（デフォルト）だけでなく、javascriptおよびcssファイルにも一致します。明らかに*は、物事を壊す可能性がある遅延アプローチであり、特定のMIMEタイプを使用することをお勧めします。

最終的に正しい方法は、Webアプリケーションを修正することです。ほとんどのWebフレームワークは、ベースurl /ルートurl/urlプレフィックス（これの標準名ではないようです）のようなものをサポートしており、この問題を正確に回避するために設定できます。

2
ChrisWue