Serving Multiple Domains/ Subdomains Through NGINX

Locating Configuration File

Usually located in /etc/nginx/nginx.conf

A bare configuration file looks like this

events {
    
}


http {


}

An empty configuration file should contain at least the http and events blocks

Adding a virtual host

http {
		# To include correct mime types to resolve different assets. The `mime.types` file usually exists in the same directory
    include mime.types;
    server {
				# port, can be left out if port 80
        listen 80;
				# server location
        server_name 142.47.92.9;
				# directory by which the files will be served
        root /sites/demo;
    }

}

Routing

Routing can be done via location blocks

server {
        listen 80;
        server_name 142.47.92.9;
        root /sites/demo;
				# location matchers can exact `=`
				# or regex `~`
				# or a prefix ``
				# and are prioritized in that order
        location = /hello {
            return 200 "Hello";
        }
    }

Simple usage of logic (conditionals and variables)

NGINX provides some variables out of the box, and we can se our own variables and conditionals

server {
        listen 80;
        server_name 142.47.92.9;
        root /sites/demo;

        set $weekend 'No';
        if ( $date_local ~ 'Saturday|Sunday' ) {
            set $weekend 'Yes';
        }

        location = /is_weekend {
            return 200 "Is it a weekend? $weekend\n$date_local";
        }
    }

Rewrites / Return Directives

The return directive allows to redirect a customer to another URL when given a 3** status code

location /logo {
    return 307 /blog.css;
}

This redirects the customer to another relative URL

The rewrite directive allows for manipulating the page URL so it stays the same

server {
        listen 80;
        server_name 142.47.92.9;
        root /sites/demo;

        rewrite ^/user/\w+ /greet;

        location /greet {
            return 200 'Hello User';
        }
    }

This makes it so when a customer lands on a matching URL, they would get the /greet page without redirection.

Rewrites also support regular expression with matching Regex groups

server {
        listen 80;
        server_name 142.47.92.9;
        root /sites/demo;

        rewrite ^/user/(\w+) /greet/$1;

        location /greet {
            return 200 'Hello User';
        }
				location ~ /greet/(\w+) {
            return 200 'Hello $1';
        }
    }

Landing on /user/anyone would take a customer to the greet page and prints their name

Having more than one rewrite will have the last one override the first

rewrite ^/user/(\w+) /greet/$1;
rewrite ^/user/yamen /blog.css;

In order to only resolve a preceding rewrite, the last flag will signal to NGINX to not resolve any follow-up rewrite for the same matcher

rewrite ^/user/(\w+) /greet/$1 last;
rewrite ^/user/yamen /blog.css;

Try-Files Directive

The try_files directive tells NGINX to try serving files in the provided order until one is found and is served

server {
        listen 80;
        server_name 142.47.92.9;
        root /sites/demo;

        try_files /blog.css /greet;

        location /greet {
            return 200 'Hello User';
        }
        location ~ /greet/(\w+) {
            return 200 'Hello $1';
        }
    }

This will serve the blog.css files on all requests to the server, given that it exists in the root directory. The last argument, however, if reached, will re-evaluate the route and serve the actual greet route/ location

To try matching the original request first, a variable $uri can be provided as a first argument

try_files $uri /blog.css /greet;

This makes the try_files directive ideal for serving 404 pages

server {
        listen 80;
        server_name 142.47.92.9;
        root /sites/demo;

       try_files $uri /friendly_404;

        location /greet {
            return 200 'Hello User';
        }

        location /friendly_404 {
            return 404 "Sorry, this file does not exist";
        }
    }

This only matches non-existing resources to the 404 page (without changing URL), but only because it’s the last argument

Named Locations

Locations can be named to be referenced later when they don't need to have an actual URL, building on the previous example:

server {
        listen 80;
        server_name 142.47.92.9;
        root /sites/demo;

       try_files $uri @friendly_404;

        location /greet {
            return 200 'Hello User';
        }

        location @friendly_404 {
            return 404 "Sorry, this file does not exist";
        }
    }

The 404 page does not need a URL and so the named location works nicely in this case

💡

To validate configuration file syntax, run the command: nginx -t

💡

The NGINX server needs to be reloaded for changes to the configuration file to take effect systemctl reload nginx Or nginx -s reload

👋🏻About Me

🛠️Tools

💌Contact