简体   繁体   中英

nginx proxy_pass doesn't work right when concatenating to variable

I have an NGINX server running as a reverse proxy for a service I host. I tried configuring it with this:

set $upstream_nzbget http://nzbget:6789;

location /nzbget/api/ {
    proxy_pass $upstream_nzbget/;
}

But the proxy_pass doesn't work properly when I try to add the slash / to the end of $upstream_nzbget . If I change it to this, it works properly:

location /nzbget/api/ {
    proxy_pass http://nzbget:6789/;
}

So I think it has something to do with variables in proxy_pass . In the first case (the one that isn't working), I'm not really sure what the URL ends up being. I haven't found a way to log the final URI that gets used by proxy_pass .

Can someone explain why the first case isn't working? What is the proper solution? Note that I need to keep the variable in proxy_pass so it uses the resolver.

Side note: I use a trailing slash in my location block because otherwise I get a 404 when I use this URL:

domain.com/nzbget/api/api:password/xmlrpc

This is why I use /nzbget/api/ instead of /nzbget/api .

EDIT 1

I played around with this some more, and I found that this also doesn't work:

location /nzbget/api/ {
    set $upstream_nzbget http://nzbget:6789/;
    proxy_pass $upstream_nzbget;
}

This one is really strange. It's the same string, the only difference is using a variable vs a string literal. I'm not doing any string concatenation here. I'm not sure why there's a behavioral difference.

EDIT 2

This SO question might be the same issue, but it has no helpful answers.

You need to pass $request_uri when using it with variable. It's there in the docs somewhere.

It'll be something like:

location /nzbget/api/ {
    set $upstream_nzbget http://nzbget:6789$request_uri;
    proxy_pass $upstream_nzbget;
}

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM