# Invalid domains are resolving to existing ones

**URL:** <https://www.ruby-forum.com/t/invalid-domains-are-resolving-to-existing-ones/209426>\
**Category:** NGINX\
**Created:** [July 13, 2011, 8:55pm UTC](https://www.ruby-forum.com/t/invalid-domains-are-resolving-to-existing-ones/209426 "2011-07-13T20:55:56Z")\
**Posts on this page:** 2\
**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:** [July 13, 2011, 8:55pm UTC](https://www.ruby-forum.com/t/invalid-domains-are-resolving-to-existing-ones/209426/1 "2011-07-13T20:55:56Z")

</div>

Hi All,

It appears that nginx is resolving invalid domains to existing ones, and  
I’m  
not entirely sure why. Any help would be much appreciated. 🙂

As an example, I have deployed an application and when I go to the link  
of  
the app, it works as expected (for example:  
[MuleSoft | Automate anything. Empower everyone.](http://swetatest1.unit-test.muleion.com/hellorest)). I also have valid  
test  
apps with the numbers 2, 3, and 4, and those links work as expected as  
well.  
However, when I go to [MuleSoft | Automate anything. Empower everyone.](http://swetatest5.unit-test.muleion.com/hellorest)  
, it  
still resolves instead of throwing an error. Even a completely random  
pattern, such as [MuleSoft | Automate anything. Empower everyone.](http://abc.unit-test.muleion.com/hellorest) resolves to  
an  
existing one and it shouldn’t (there’s not even a config file for  
[abc.unit-test.muleion.com](http://abc.unit-test.muleion.com) or all of the other invalid domains) – the  
server\_name field below should be looking for an exact match for the  
name  
(according to the nginx docs), so why are other ones resolving?

Here is the relevant part of the nginx config for one of the apps (X’d  
out  
both the IP and ports but those are valid):  
server {  
listen 80;  
server\_name [swetatest1.unit-test.muleion.com](http://swetatest1.unit-test.muleion.com);  
location / {  
proxy\_pass http://swetatest1.unit-test.muleion.com\_http;  
include /etc/nginx/proxy.conf;  
}  
}  
server {  
listen 443;  
server\_name [swetatest1.unit-test.muleion.com](http://swetatest1.unit-test.muleion.com);  
ssl on;  
ssl\_certificate /etc/nginx/server.crt;  
ssl\_certificate\_key /etc/nginx/server.key;  
location / {  
proxy\_pass https://swetatest1.unit-test.muleion.com\_https;  
include /etc/nginx/proxy.conf;  
}  
}  
upstream swetatest1.unit-test.muleion.com\_http {  
server XX.XXX.XX.XX:PORT;  
}  
upstream swetatest1.unit-test.muleion.com\_https {  
server XX.XXX.XX.XX:PORT;  
}

Has anybody else seen this issue before, and if so, how did you fix it?  
Any  
suggestions or feedback would be greatly appreciated.

Thanks!  
-Sweta

---

<div class="post-metadata">

**Author:** ![Sweta\_Vajjhala](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/839c29/32.png) [@Sweta\_Vajjhala](https://www.ruby-forum.com/u/Sweta_Vajjhala)\
**Post date:** [July 14, 2011, 12:08am UTC](https://www.ruby-forum.com/t/invalid-domains-are-resolving-to-existing-ones/209426/2 "2011-07-14T00:08:29Z")

</div>

Hello!

On Wed, Jul 13, 2011 at 11:55:20AM -0700, Sweta Vajjhala wrote:

> still resolves instead of throwing an error. Even a completely random  
> pattern, such as [See Every Agent. Govern Every Agent. Control AI Costs.](http://abc.unit-test.muleion.com/hellorest) resolves to an  
> existing one and it shouldn’t (there’s not even a config file for  
> [abc.unit-test.muleion.com](http://abc.unit-test.muleion.com) or all of the other invalid domains) – the  
> server\_name field below should be looking for an exact match for the name  
> (according to the nginx docs), so why are other ones resolving?

If there is no server\_name match found, nginx will use default  
server (either first one defined, or explicitly marked with  
“listen … default\_server”) for a listen socket in question to  
process a request.

Please refer here for details:

> **[How nginx processes a request](http://nginx.org/en/docs/http/request_processing.html)**

Maxim D.