Nginx proxy_pass with $remote_addr

Question

I'm trying to include $remote_addr or $http_remote_addr on my proxy_pass without success.

The rewrite rule works

location ^~ /freegeoip/ {  
  rewrite ^ http://freegeoip.net/json/$remote_addr last;
}

The proxy_pass without the $remote_addr works, but freegeoip does not read the x-Real-IP

location ^~ /freegeoip/ {
  proxy_pass http://freegeoip.net/json/;
  proxy_set_header X-Real-IP $remote_addr;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_set_header Host $host;
}

Then, I'm adding the ip to the end of the request, like this:

location ^~ /freegeoip/ {
  proxy_pass http://freegeoip.net/json/$remote_addr;
}

but nginx report this error: no resolver defined to resolve freegeoip.net

does the error occur when you restart nginx, or when an http request hits the location block? — Rob Squires, Jul 16 '13 at 21:05

score 195 · Accepted Answer · edited Sep 02 '17 at 11:47

195

If the proxy_pass statement has no variables in it, then it will use the "gethostbyaddr" system call during start-up or reload and will cache that value permanently.

if there are any variables, such as using either of the following:

set $originaddr http://origin.example.com;
proxy_pass $originaddr;
# or even
proxy_pass http://origin.example.com$request_uri;

Then nginx will use a built-in resolver, and the "resolver" directive must be present. "resolver" is probably a misnomer; think of it as "what DNS server will the built-in resolver use". Since nginx 1.1.9 the built-in resolver will honour DNS TTL values. Before then it used a fixed value of 5 minutes.

edited Sep 02 '17 at 11:47

nbari

25,603
10
76
131

answered Mar 07 '14 at 19:33

Chris Cogdon

7,481
5
38
30

10

This is a _much_ more useful and informative answer. Thank you. – Kevin Cantwell Jan 29 '16 at 20:58
2

The key being any variable present in the proxy_pass value, thanks for the right answer and explanation. – Pablo Banderas Mar 23 '17 at 13:54
4

Some reference? – deFreitas Oct 22 '17 at 16:28
8

Fun fact: docker container's default nameserver is at `127.0.0.11`, see `cat /etc/resolv.conf`. – Richard Kiefer Aug 15 '19 at 11:08
2

What am I supposed to set the resolver to if it is running kubernetes? There is no resolv.conf file. – Arrow_Raider Mar 29 '21 at 15:55
1

I've been trying for a while to find out why the `resolver` was needed. Thanks! – Opus4210 Feb 28 '22 at 22:21
FYI -- when running in docker compose, based on the information in this answer/comment thread, we used: resolver 127.0.0.11; This allowed nginx to find the server that we needed. Super helpful. Thank you. – ajl May 14 '23 at 15:11

score 91 · Answer 2 · answered Jul 23 '13 at 09:03

91

It seems a bit strange that nginx is failing to resolve the domain name at runtime rather than at configuration time (since the domain name is hard coded). Adding a resolver declaration to the location block usually fixes dns issues experienced at runtime. So your location block might look like:

location ^~ /freegeoip/ {
  #use google as dns
  resolver 8.8.8.8;
  proxy_pass http://freegeoip.net/json/$remote_addr;
}

This solution is based on an article I read a while back - Proxy pass and resolver. Would be worth a read.

answered Jul 23 '13 at 09:03

Rob Squires

2,108
16
15

21

Do **NOT** use a publicly accessible DNS server such as `8.8.8.8`. [To prevent DNS spoofing, it is recommended configuring DNS servers in a properly secured trusted local network.](http://nginx.org/en/docs/http/ngx_http_core_module.html#resolver) – Tim Oct 07 '16 at 20:12
This should be the accepted answer because it cover other cases, like args, remote_addr, etc – onalbi Jan 20 '18 at 11:01
This is still valid with latest stable nginx/1.10.3. So `resolver` directive is required in conjunction with `proxy_pass` dynamic directive e.g. `proxy_pass http://$host;`. While this one works w/o resolver: ```server { listen 80; server_name myurl.com; location / {return 303 https://$host$request_uri;} } ``` – stamster May 09 '18 at 16:21
In my case (Google Cloud), I used the internal nameserver, 169.254.169.254, to resolve other instances in my tenant by hostname. – Daniel Watrous Feb 09 '19 at 03:41

score 17 · Answer 3 · answered Dec 25 '17 at 14:17

17

If anyone is stll experiencing trouble, for me it helped to move the proxy_pass host to a seperate upstream, so I come up with something like this

upstream backend-server {
  server backend.service.consul;
}

server {
  listen       80;
  server_name  frontend.test.me;

  location ~/api(.*)$  {
    proxy_pass http://backend-server$1;
  }
  location / {
    # this works mystically! backend doesn't...
    proxy_pass http://frontend.service.consul/;
  }
}

answered Dec 25 '17 at 14:17

AmazingTurtle

1,187
1
15
31

1

This is the easier answer if your proxied URI does not change, and no need to add additional resolver step! – theannouncer Jun 20 '20 at 01:53

score 1 · Answer 4 · answered Feb 09 '21 at 02:29

1

Another way is that you can provide your host ip address and port number instead of host URL in proxy_pass like below:

Your Code: proxy_pass http://freegeoip.net/json/;

Updated Code proxy_pass http://10.45.45.10:2290/json/;

answered Feb 09 '21 at 02:29

Rohit Gaikwad

3,677
3
17
40

This worked for me, was trying to proxy back to some Docker intstances on localhost, but localhost didn't work (couldn't be resolved for whatever reason) but 127.0.0.1 worked just fine. – OzzyTheGiant Jul 17 '22 at 15:14

score 1 · Answer 5 · edited Nov 01 '22 at 15:31

So you want this to work:

location ^~ /freegeoip/ {
  proxy_pass http://freegeoip.net/json/$remote_addr;
}

but as pointed out by Chris Cogdon, it fails because at run-time, nginx does not have the domain name resolved, and so proxy_pass requires a resolver (see also, proxy_pass docs).

Something that seems to work (though may be a hack!) is to do something that triggers nginx to resolve the domain name at start-up and cache this.

So, change the config to include a location (for the same host) without any variables (as well as your location with variables):

location = /freegeoip/this-location-is-just-a-hack {
  # A dummy location. Use any path, but keep the hostname.
  proxy_pass http://freegeoip.net/this-path-need-not-exist;
}

location ^~ /freegeoip/ {
  proxy_pass http://freegeoip.net/json/$remote_addr;
}

The host will now be resolved at start-up (and its cached value will be used in the second location at run-time). You can verify this start-up resolution behavior by changing hostname (freegeoip.net) to something that doesn't exist, and when you run nginx -t or nginx -s reload you'll have an emergency error ([emerg] host not found in upstream). And of course you can verify that the cached value is used at run-time by leaving out any resolver, hitting your location block, and observing no errors in the logs.

score 0 · Answer 6 · answered Dec 10 '14 at 06:19

0

You could also mention your nginx server port in the proxy_pass uri. This solved the issue for me.

answered Dec 10 '14 at 06:19

RijulB

565
1
4
10

score 0 · Answer 7 · answered Jan 10 '22 at 15:23

Try to use dig / nslookup to make sure this is still nginx issue. In my case the issue was that one of dns server between my nginx and root dns was not respecting TTL values that are as small as 1 second.

Nginx does not re-resolve DNS names in Docker

Nginx proxy_pass with $remote_addr

7 Answers7

Linked

Related