Dissection of an Nginx Reverse Proxy Configuration

Really, just the Server Blocks portion (equivalent to VirtualHosts for Apache challenged folks)

Below is the configuration file for this blog/web application which sits within /etc/nginx/conf.d/ known as

devopsblog.conf

Line by line let's review its functionality.

You might first recognize that these blocks are not defined in the default nginx.conf, this was done for the sake of separation of concerns. The highlighted line below was added within nginx.conf to source the server blocks found in files within /etc/nginx/conf.d/

include /etc/nginx/conf.d/*.conf;

this is set within the http block

Now, back to our primary task.

server { server_name mylesdomain.com;

location = /favicon.ico { access_log off; log_not_found off; }

location / {
    include proxy_params;
    proxy_pass http://unix:/run/gunicorn.sock;
}

Within the first server block we define

1. server name: rather self-expanatory, but for clarity enter the hostname of the server hosting the web application
2. location: this refers the path of the favicon AKA the little icon in your browser tab for the site. I didn't bother adding one yet. In curly braces the access_log off; log_not_found off, prevent any logging of errors due to nginx not finding an favicon file to load.
   • Note: the difference between the = and / characters found after the location directive
     • Sign: = is for an exact match to the location
     • Sign: / is a catch all for any request
3. location (2): this is where things get interesting.
   • We first source the proxy_params files (defines what header information is passed with requests)
   • Second we enable the reverse proxy functionality by setting the directive proxy_pass paired with a URL to access the named unix socket we configured to LISTEN and pass requests onward to our application web server program - gunicorn
     • the functionality above made possible by binding gunicorn to our aptly named gunicorn.sock socket file, which handled automatically through a nifty little custom systemd service I defined. Shown below:

Back to the block configs the remaining values are pretty straight forward and very nicely managed through certbot scripts provided by LetsEncrypt a completely free nonprofit SSL certificate provider.

listen 443 ssl; # managed by Certbot ssl_certificate /etc/letsencrypt/live/mylesdomain.com/fullchain.pem; # managed by Certbot ssl_certificate_key /etc/letsencrypt/live/mylesdomain.com/privkey.pem; # managed by Certbot include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

1. Listen: a directive - port 443 - SSL parameter added for HTTPS support
2. ssl_certificate - refers the LetsEncrypt CA certificate file
3. ssl_certificate_key -refers to the certificate generated for us by LetsEncrypt
4. include - sources the configurations set by LetsEncrypt scripts
5. Refers to parameters used during the Diffie-Hellman key-exchange