nginx-proxy uses default host without DEFAULT_HOST set

[bluepuma77]

We use nginx-proxy in front of about 25 containers with different sub-domains each.

If a container dies or is stopped, requests are just redirected to a different (other sub-domain) container.

We would rather expect a blank error page. Why is this happening? DEFAULT_HOST is not set.

docker run
  --name nginx-proxy 
  --restart always 
  --publish 80:80 
  --publish 443:443 
  --volume /system/nginx/proxy.conf:/etc/nginx/conf.d/my_proxy.conf:ro 
  --volume /system/nginx/htpasswd:/etc/nginx/htpasswd 
  --volume /system/certs:/etc/nginx/certs 
  --volume /var/run/docker.sock:/tmp/docker.sock:ro 
  --log-opt max-size=100m --log-opt max-file=1000 
  --detach jwilder/nginx-proxy

docker run 
  --name nginx-crypt 
  --restart always 
  --volumes-from nginx-proxy 
  --volume /var/run/docker.sock:/var/run/docker.sock:ro 
  --env "DEFAULT_EMAIL=abc@domain.tld" 
  --detach jrcs/letsencrypt-nginx-proxy-companion

docker run \
  --name demo-instance \
  --restart always \
  --env NODE_ENV=production \
  --env CUSTOMER=demo \
  --env VIRTUAL_HOST=demo.domain.tld \
  -d registry.domain.tld:443/system:latest

docker run \
  --name demo2-instance \
  --restart always \
  --env NODE_ENV=production \
  --env CUSTOMER=demo2 \
  --env VIRTUAL_HOST=demo2.domain.tld \
  -d registry.domain.tld:443/system:latest

proxy.conf:

  server_tokens off;
  client_max_body_size 1024m;
  proxy_connect_timeout       300;
  proxy_send_timeout          300;
  proxy_read_timeout          300;
  send_timeout                300;

[tkw1536]

This is the default nginx behavior. When an unknown host is encountered, nginx either picks the default_server to answer requests from or, in the absence of that, the first server in the config file. First server in this case means that it will pick whichever container the Docker API returned first.

If you would like a custom error page, I guess you could add a 'server {}' block with 'default_server' variable set. That could then be customized to return whatever error page you like. See Proxy-Wide Configuration.

[bluepuma77]

Thanks @tkw1536 for your response.

I would call this unexpected behaviour. If DEFAULT_HOST is not set, I would not expect it to be random.

If you think this is a feature and not a bug, please feel free to close the issue.

[bluepuma77]

I am currently toying around with traefik. If the web container for a domain is not present it will automatically respond with a plain 404 instead of an arbitrary site that is listening to a different hostname.

Easy use-case: When multiple clients are on one server and a container dies, then I should not show the website of the competition.

If there is a DEFAULT_HOST functionality, then nginx-proxy should not just use an arbitrary service when the variable is not defined, but rather respond with a 404 or similar.

[Samhamsam]

For me this is also a unexpected behaviour. If i update my website and docker down my container, all people will get redirected to my other website. This redirection does stay, even if i up my container again. Or do i miss something?

[junderw]

For now it seems wise to add a small container serving just a 502 page, set it as 502.yourdomain.com and set it as your DEFAULT_HOST.

Since this is the default behavior of nginx, the only way this could really be "fixed" is by making the above process more automated by adding DEFAULT_502 etc. option that will add a default_server which returns 502, and turn it off by default.

[stephtr]

Similar to #992; what I commented there:

This unfortunately can be a severe issue. In our case, we had to reboot our webserver, which also runs a couple of Wordpress pages. During reboot we noticed that some traffic was routed to the wrong container. Unfortunately, Wordpress by default is programmed to send a permanent 301 redirect if the hostname doesn't match. This redirection (from site A to a totally unrelated site B), besides being served for only a few seconds, got cached by a couple of browsers.

[stephtr]

In case someone by chance ends up having the same issue as I did, I posted my finding/solution at #992 (comment).