Question

Setting up nginx on the Dokku droplet to show 404 errors

Posted November 8, 2014 4.4k views

Building on top of the question here:

https://www.digitalocean.com/community/questions/dokku-and-preventing-random-domains

I figured out how to have a landing page for my main host as well as still serve my vhosts, e.g. 

example.com        -> index.html
app1.example.com   -> app1

Those two things work OK, but I’m curious about how to setup a 404 page for invalid vhosts, e.g.

NonExistentApp.eample.com  -> 404

instead of 

NonExistentApp.example.com -> example.com

The location section of my /etc/nginx/sites-enabled/default does look like its supposed to serve a 404 if it cant find what the URL is requesting, but I think there’s some issue where it still tries to serve the main index.html, even if there’s an invalid vhost

location / {
    # First attempt to serve request as file, then
    # as directory, then fall back to displaying a 404.
    try_files $uri $uri/ =404;
}

Any help would be appreciated!

Add a comment
joshuasandlin
By:
joshuasandlin

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

×
2 answers
memnochxx November 8, 2014

Just return 404 in whatever block you want.

server {
        listen 80 default_server;

        return 404;
}
Reply Report
  • samholmes1337 March 16, 2016

    I’ve run into an issue with this though when working with SSL certificates.

    The following occurs based on this setup:

    http://example.com                 ->  example.com app
http://app1.example.com            ->  app1
http://non-existant.example.com    ->  404
https://non-existant.example.com   ->  example.com app

    How would I go about making the 404 behaviour work for the https apps with SSL enabled as opposed to the just the http apps?

    Thank you!

    Reply Report
    • memnochxx March 16, 2016

      You also need to listen 443 ssl in the dummy block, a cert and key are also required but these can be bogus/self signed.

      FYI you can return 444 which will just close the connection without returning any data.

      Reply Report
      • samholmes1337 March 16, 2016

        Annoyingly, this still delivers a privacy warning:
        Chrome Window
        When I bypass the warning, I do see the 404 page.

        I am aware that the HTTPS negotiation takes place before anything else, so this behaviour does make sense. Is there any way to avoid this behaviour and simply show a 404 page though?

        Reply Report
samholmes1337 April 19, 2016

Thanks to help from @memnochxx, I’ve been able to get a working dokku nginx configuration that can deliver 404 pages for both http and https requests for any unknown pages or vhost’s (this is on Ubuntu 14.04 running Dokku v0.5.5).

Firstly, the /etc/nginx/nginx.conf is the file that needs to be modified in order to return 404. As explained in the dokku nginx documentation, you’ll need to place the 404 return before the virtual hosts config in the primary http block. The result should look like this:


##
# Custom 404 return for requests made to any URL or vhost
# that doesn't exist or match a dokku application.
#
# Make sure that this goes above "Virtual Host Configs"
##

server {
    listen 80 default_server;
    listen [::]:80 default_server ipv6only=on;
    listen 443 default_server ssl;
    ssl_certificate /etc/nginx/ssl/fake.crt;
    ssl_certificate_key /etc/nginx/ssl/fake.pem;
    return 404;
}

##
# Virtual Host Configs
##

include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;

We’ll also need to generate some dummy self-signed SSL certificates to get the https 404 working. We’ll throw those in the /etc/nginx/ssl directory. Run the following commands to do that:

cd /etc/nginx
mkdir ssl
cd ssl
openssl req -x509 -newkey rsa:2048 -keyout fake.pem -out fake.crt -days 365

The days for the openssl command don’t really matter, as the certificate will be invalid anyway. Just run through the default options and don’t worry about the content of the certificate. We’re only putting them there to make nginx happy because it requires a certificate and an associated key to listen on 443. Hope this helped, and thank you again @memnochxx for your help earlier!

Reply Report
Submit an Answer

Looking for something else?

Ask a new question Search for more help