Defining a default server for when vhost does not exist for requested hostname (including blank hostname), for http and https

Ben Johnson ben at
Fri Mar 28 14:31:55 UTC 2014


We run multiple vhosts in nginx. Occasionally, a vhost will be
mis-configured or disabled (via the website management software that we
use), and public requests for the domain will fall-back to nginx's
default vhost, which can have very unintended consequences (e.g., an
incorrect and completely unrelated website is displayed).

The nginx documentation suggests doing something like this to combat
this type of problem:

server {
    listen      *:80 default_server;
    server_name "";
    return      444;

server {
    listen *:443 default_server ssl;
    ssl_certificate /var/www/clients/client1/web1/ssl/;
    ssl_certificate_key /var/www/clients/client1/web1/ssl/;
    server_name "";
    return      444;

I've placed this snippet at the top of nginx's "default" vhost
configuration file and it does exactly what I want. But I'm wondering if
this is the "correct" and "best" approach to the problem I describe.

Also, I noticed that this doesn't seem to work for SSL when an SSL
certificate and key are not specified, with the following appearing in
nginx's error log:

no "ssl_certificate" is defined in server listening on SSL port while
SSL handshaking, client:, server:

That's fine; I just want to ensure that the certificate I've specified
in order to make this work will never be transmitted nor presented to
the user-agent. When I test this in a web browser, the browser never
seems to display or mention the certificate (no mismatch or anything;
just the 444 response).

However, when I test this with cURL, it does seem to be privy to the
certificate (disregard the fact that the cert verification fails; it's

$ curl
curl: (60) SSL certificate problem, verify that the CA cert is OK. Details:
error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate
verify failed
More details here:

Is there any way to avoid this certificate being presented, but still
return the 444 response under the conditions I've described?

Thanks for any tips here!


More information about the nginx mailing list