Skip to content

NGINX Reverse Proxy Initial Installation

Last updated on November 23, 2019

PLEASE NOTE: This is not designed to be an exact step-by-step tutorial on how to install and/or configure an NGINX server or Reverse Proxy. This is simply to document my personal experience installing and configuring NGINX. Posts like this should be considered “rough notes”, and are shared on the premise of helping others to problem solve and also to reinforce a logical means to troubleshooting – no matter what the context.

– Michael Giesen

PREFACE

As I continue to challenge myself as an engineer (and level-up on our home-lab skills) I’ve learned to try new things by simply jumping in. I had just finished installing NetData on a test server for Unvetica. Now anytime I wanted to view real-time hardware statistics I can simply view them at: http://13.xxx.xx.xxx:19999/.

After a brief moment basking in my own pride of completing this task, a thought came to mind: “wouldn’t it be cool to have the IP address resolved to a domain name?”

“Indeed” was the answer I gave myself.

This would be ideal as I continue to build web apps the ports will be impossible to memorize. Without some means to resolve IP Addresses + Ports to URL-Friendly Domain Names, I’d be forced to to memorize things like this:

IP/Port Address

http://13.539.35.003:19999

http://13.539.35.003:13579

http://35.971.55.001:8080

http://99.999.35.259:11

http://99:999:35:259:777

Unfortunately, you can’t simply add a new DNS record to rout IP addresses + Ports to Domain Names. Instead, what I did was install and configure an NGINX Reverse Proxy Server. NGINX will do the ‘handshaking’ for us and provide a more granular platform to assign specific port numbers to a domain name, making the end result look like this:

IP/Port Address

http://13.539.35.003:19999

http://13.539.35.003:13579

http://35.971.55.001:8080

http://99.999.35.259:11

NGINX

<==== Go Here ====>

<==== Go Here ====>

<==== Go Here ====>

<==== Go Here ====>

Friendly URL

netstat.unvetica.com

admin.unvetica.com

analytics.unvetica.com

upload.unvetica.com

There are a lot of additional benefits to implementing a Reverse Proxy on your home network, we’ll dive into those details more in a future post, but today I’m simply outlining my initial experience setting up, configuring, and troubleshooting an NGINX Reverse Proxy on our Unvetica Test Server.

Initial Installation

To maintain good engineering practices, I made sure to update the test server before starting anything:

sudo yum update -y

Next, I added the NGINX Repository and ran the Install command:

sudo yum install epel-release

sudo yum install nginx

Anxious to start-up and play around with the new service, I ran the start command and also ran the enable command so the service auto-starts after reboot.

sudo systemctl start nginx

sudo systemctl enable nginx

Configuration / Troubleshooting

The installation process was painless enough, now it’s time to add an A-Record to our DNS on unvetica.com. This way we have an active ‘friendly URL’ for us to use with NGINX. You can see below we have our original root domain A-Record and the newly added sub-domain A-Record which points to our Unvetica Test Server at netstat.unvetica.com.

Now that we have a functioning A-Record we’re going to begin the configuration process for our NGINX Reverse Proxy. From the documentation and tutorials I’ve read, all of the configuration files and pertinent details should be located under /etc/nginx. So I go there – and voila:

One thing that immediately gives me pause are two missing directories. From all of the tutorials I read previously stated there should also be /sites-available and /sites-enabled directories under /etc/nginx. Those directories were clearly missing. Concerned, I manually created both directories and then continued by creating a new configuration file under /sites-available to be used to route our IP Address + Port to netstat.unvetica.com.

sudo nano unvetica-rproxy.conf

To configure our newly installed NGINX server so that it resolves our NetData URL from http://13.539.35.003:19999 to netstat.unvetica.com is actually fairly straight forward, though that wasn’t apparent initially. I was fumbleing around with the correct syntax when coding the configuration file.

With a few adjustments I was able to develop a correctly functioning configuration file.

server {
        server_name netstat.unvetica.com;
        listen 80;
        location / {
                proxy_pass http://13.539.35.003:19999;

        }
}

I then saved the file, and restarted the NGINX server for the changes to take effect:

sudo systemctl restart nginx

Error message upon startup:

Nov 20 13:10:45 test-server.localdomain nginx[30799]: nginx: [emerg] "server" directive is not allowed here in /etc/nginx/sites-available/unvetica-rproxy.conf:1

Nov 20 13:10:45 test-server.localdomain nginx[30799]: nginx: configuration file /etc/nginx/nginx.conf test failed

Nov 20 13:10:45 test-server.localdomain systemd[1]: nginx.service: control process exited, code=exited status=1

Nov 20 13:10:45 test-server.localdomain systemd[1]: Failed to start The nginx HTTP and reverse proxy server.

I check the NGINX error logs, which point to an authentication issue. At this point – having no experience with NGINX – I’m stumped. It doesn’t make sense to make sense to be having an authentication error/issue when everything (at the moment) is being transmitted over HTTP which requires no authentication.

This is when I reached out to my favorite sub-reddits and posted on r/HomeLab, r/NGINX, and r/HomeNetworking. A few people were willing to help me out and suggested I review my /nginx.conf settings.

I owe a round of thanks to u/TheCoffeeGuy and u/StudentDeveloper7 for helping me when I posted on Reddit that I was having routing issues.

Incorrect Configuration File Syntax:

  # Load modular configuration files from the /etc/nginx/conf.d directory.
    # See http://nginx.org/en/docs/ngx_core_module.html#include
    # for more information.
    include /etc/nginx/sites-enabled/*.conf;

    server {
        listen       80 default_server;
        listen       [::]:80 default_server;
        server_name  _;
        root         /usr/share/nginx/html;

        # Load configuration files for the default server block.
        include /etc/nginx/sites-enabled/*.conf;

        location / {
        }

        error_page 404 /404.html;
            location = /40x.html {
        }

        error_page 500 502 503 504 /50x.html;
            location = /50x.html {
        }
    }

Correct Configuration File Syntax:

# Load modular configuration files from the /etc/nginx/conf.d directory.
    # See http://nginx.org/en/docs/ngx_core_module.html#include
    # for more information.
    include /etc/nginx/conf.d/*.conf;

    server {
        listen       80 default_server;
        listen       [::]:80 default_server;
        server_name  _;
        root         /usr/share/nginx/html;

        # Load configuration files for the default server block.
        include /etc/nginx/default.d/*.conf;

        location / {
        }

        error_page 404 /404.html;
            location = /40x.html {
        }

        error_page 500 502 503 504 /50x.html;
            location = /50x.html {
        }
    }

That’s when u/TheCoffeeGuy made a great observation, suggesting that I temporarily disable SELinux. The theory being it was blocking the port :19999 by default. I issued the following command to temporarily disable SELinux:

setenforce 0

The mistake I made was coding two separate include directories: /etc/nginx/conf.d/*.conf; and /etc/nginx/default.d/*.conf; into one single directory: /etc/nginx/sites-enabled/*.conf;. With the confidence lost on the initial installation having /sites-enabled and /sites-available missing, and further confidence lost with these messed up configuration files, I decided to start over by re-installing NGINX to ensure proper installation before continuing.

With the NGINX package re-installed I notice that /sites-available and /sites-enabled are still not present, and someone had also mentioned in a Reddit post that those directories are no longer used (depreciated) – though I haven’t researched specifically with the NGINX documentation to corroborate if that’s true. I went ahead and decided to instead use /conf.d directory per the nginx.conf default parameters.

I created a new unvetica-rproxy.conf file under /conf.d:

server {
        server_name netstat.unvetica.com;
        listen 80;
        location / {
                proxy_pass http://65.101.xx.xxx:19999;

        }
}

And this is what the nginx.conf is configured as:


    # Load modular configuration files from the /etc/nginx/conf.d directory.
    # See http://nginx.org/en/docs/ngx_core_module.html#include
    # for more information.
    include /etc/nginx/conf.d/*.conf;

    server {
        listen       80 default_server;
        listen       [::]:80 default_server;
        server_name  _;
        root         /usr/share/nginx/html;

        # Load configuration files for the default server block.
        include /etc/nginx/default.d/*.conf;

        location / {
        }

        error_page 404 /404.html;
            location = /40x.html {
        }

        error_page 500 502 503 504 /50x.html;
            location = /50x.html {
        }
    }

I restarted the NGINX service after making the updates – success!

Now when I access netstat.unvetica.com I see the data from 65.101.xx.xxx:19999.

Conclusion

The installation and configuration of NGINX was pretty straight forward after becoming more acclimated with the program. I’m going to do some additional research to determine if /sites-available and /sites-enabled directories are actually depreciated.

That aside, having the convenience of user-friendly URLS is really great – but that’s such a small capability of what NGINX can do as a whole. With this system installed I can now enable Load Balancing across Unvetica’s Data Center, deploy advanced security via SSL Termination, serve static content, cache content, compress content, and centralize logging to name a few things.

I’d also like to give a shout-out to u/TheCoffeeGuy, u/StudentDeveloper7, and u/LinuxHostSupport for the technical guidance. Collectively providing enough technical-breadcrumbs for me to understand NGINX and get me running.

Be First to Comment

Leave a Reply

Your email address will not be published. Required fields are marked *