99.999% my config works - then default_server is used

[Michal Kralik]

Hi Ruslan,

Thank you for your answer. This makes complete sense and is the reason why
this was happening.
It didn't occur to me before asking the question - thank you for your help!

On Thu, Apr 6, 2017 at 11:50 PM, Ruslan Ermilov <ru at nginx.com> wrote:

> On Thu, Apr 06, 2017 at 11:18:02PM +0200, Michal Kralik wrote:
> > Hi,
> >
> > We're facing super strange issues with nginx 1.10.3 (CentOS 7,
> > 3.10.0-327.36.3.el7.x86_64). Our config works ok, we get a lot of
> traffic,
> > but every day a couple of requests (5-10) don't get processes correctly
> by
> > a server directive with the defined server_name, but rather by a server
> > directive with listen's "default_server". Here's the config
> > https://paste.ngx.cc/29345124359e0447
> >
> > Most of the time a request to 01.app.example.com gets processed
> correctly,
> > but every day a couple of requests get processed by the server directive
> > from file conf.d/01-default.conf. There's nothing in the nginx system
> logs
> > around the time when this issue happens.
> >
> > The access.log from the default_server shows this
> > (/data/logs/nginx/access.log):
> > 1.1.1.1 - - [06/Apr/2017:12:20:57 +0000] "01.app.example.com" "GET
> > /robots.txt HTTP/1.1" 302 161 "-" "Mozilla/5.0 (compatible;
> Googlebot/2.1; +
> > http://www.google.com/bot.html)" "-"
> >
> > It's clearly a redirect processed by the default_server, but the request
> > should be rather processed by server directive in conf.d/02-apps.conf
> > because the host header clearly states "01.app.example.com".
> >
> > Any ideas what's going on?
>
> Given the provided configuration snippet, this should happen
> with all HTTPS requests to 01.app.example.com.
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20170407/3a38b0b3/attachment.html>