NGINX proxy_pass remove path prefix & resolve DNS

2020-05-27 15:20发布

I'd like to proxy a request to another server using proxy_pass while removing the matched path prefix. I believe that one way of doing this is as follows;

location /a/ {
  proxy_pass https://website.com/
}

E.g. a request to http://localhost/a/b.html would be proxied to https://website.com/b.html.

As far as I am aware the issue with this in non-commercial versions on NGINX is that the DNS A record for website.com would be loaded and cached forever on startup. I've seen a technique to workaround this by using a variable such as $request_uri in the proxy_pass directive, thus forcing NGINX to re-resolve the DNS according to the TTL of the record.

E.g.

location /a/ {
  rewrite ^/a/(.*) /$1  break;
  proxy_pass https://website.com/$request_uri
}

Unfortunately, it seems that the above doesn't work as it seems to still pass the /a/ prefix to the upstream.

Essentially all I want to achieve here is to proxy a request while removing the path prefix in such a way that DNS records are not cached forever.

Thanks.

1条回答
祖国的老花朵
2楼-- · 2020-05-27 16:04

I'm not sure where you've seen it, but just using specifically $request_uri is certainly not going to magically make nginx resolve the domain names for you dynamically.

Perhaps what was suggested was explicitly using the variables, such as $uri (which is a different variable), on the assumption that when the variables are in use, then the domain name is resolved individually each time, without any caching? I don't confirm or deny whether such assumption is correct, but the following will at least get rid of /a for you.

location /a/ {
  rewrite ^/a/(.*) /$1  break;
  proxy_pass https://website.com/$uri$is_args$args;
}

(Note that if it's indeed implemented not to cache the domain name, then you might as well want to run a local resolver, otherwise, the extra latency and downtime of your hosting provider's DNS will immediately affect your site, not to mention the possible DNS query limits of their servers.)


Perhaps a better solution would be to periodically restart nginx to automatically pick up the changes in DNS? E.g., nginx -s reload or kill -HUP? As explained in http://nginx.org/en/docs/beginners_guide.html#control and http://nginx.org/en/docs/control.html#reconfiguration, nginx never stops processing any requests during reload, so it should be a safe operation; and it'll most likely result in DNS being flushed, too.

查看更多
登录 后发表回答