# Bad Hostname Error?

**URL:** <https://www.ruby-forum.com/t/bad-hostname-error/214859>\
**Category:** NGINX\
**Created:** [December 13, 2011, 11:54pm UTC](https://www.ruby-forum.com/t/bad-hostname-error/214859 "2011-12-13T23:54:59Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![dubstep](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/cdc98d/32.png) [@dubstep](https://www.ruby-forum.com/u/dubstep)\
**Post date:** [December 13, 2011, 11:54pm UTC](https://www.ruby-forum.com/t/bad-hostname-error/214859/1 "2011-12-13T23:54:59Z")

</div>

Hi everyone,

Every once in a while, requests to my NGINX server are giving 500  
errors as with bad hostname responses for http://:

Can’t connect to [sub.mydomain.com:80](http://sub.mydomain.com:80) (Bad hostname: [sub.mydomain.com](http://sub.mydomain.com))

It turned out to be an issue with the DNS server, i.e. my ubuntu box  
is failing to resolve this [sub.mydomain.com](http://sub.mydomain.com) address.

What I don’t understand is that why is NGINX making an ns lookup for  
these requests??? Basically, when I make a request to this subdomain,  
it should be resolving the request using the request header and proxy  
it to localhost:81 or serving from local directory. And, I don’t see  
any reason to perform an nslookup here?

My config file is as follows:

server {  
listen 80;  
listen [::]:80 default ipv6only=on; ## listen for ipv6

```
    server_name sub.mydomain.com;
    server_tokens off;

    access_log /var/log/nginx/access.log;
    error_log /var/log/nginx/error.log info;

    location / {
            proxy_pass http://localhost:81;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For

```

$proxy\_add\_x\_forwarded\_for;  
proxy\_set\_header Host $http\_host;  
}

```
    location /html {
            alias /home/user/html/
            expires max;
    }

```

}

DNS lookups will slow the server down, and trying to understand what  
is going on here  
Thanks…

---

<div class="post-metadata">

**Author:** ![Cabbar\_D](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/e495f1/32.png) [@Cabbar\_D](https://www.ruby-forum.com/u/Cabbar_D)\
**Post date:** [December 14, 2011, 12:50am UTC](https://www.ruby-forum.com/t/bad-hostname-error/214859/2 "2011-12-14T00:50:32Z")

</div>

Hello!

On Wed, Dec 14, 2011 at 12:54:28AM +0200, Cabbar D. wrote:

> What I don’t understand is that why is NGINX making an ns lookup for  
> these requests??? Basically, when I make a request to this subdomain,  
> it should be resolving the request using the request header and proxy  
> it to localhost:81 or serving from local directory. And, I don’t see  
> any reason to perform an nslookup here?

The message you’ve provided suggests it’s from your browser  
(proxy?), not from nginx.

> ```
> error_log /var/log/nginx/error.log info;
> alias /home/user/html/
> expires max;
> }
> 
> ```
> 
> }
> 
> DNS lookups will slow the server down, and trying to understand what  
> is going on here  
> Thanks…

With such configuration nginx will only do a “localhost” name  
lookup once during configuration parsing.

Maxim D.

---

<div class="post-metadata">

**Author:** ![Cabbar\_D](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/e495f1/32.png) [@Cabbar\_D](https://www.ruby-forum.com/u/Cabbar_D)\
**Post date:** [December 14, 2011, 9:56am UTC](https://www.ruby-forum.com/t/bad-hostname-error/214859/3 "2011-12-14T09:56:55Z")

</div>

On Wed, Dec 14, 2011 at 1:50 AM, Maxim D. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
wrote:

> > 
> 
> (proxy?), not from nginx.  
> It is actually a perl script on the same machine that is doing the  
> HTTP GET. And, the fact that it is giving a 500 error with an html  
> response made me think that it was NGINX that was replying, not the  
> browser / perl script ? But, I guess you are right… Thanks for  
> clarifying this.

> > ```
> > access_log /var/log/nginx/access.log;
> > location /html {
> > 
> > ```
> 
> lookup once during configuration parsing.  
> Ah cool! So, there is no performance hit here.

Thanks a ton for the explanation.