/ Management  

Supercharge your AppWorks experience; Unleash the power of NGINX as the ultimate reverse proxy

Hi there AppWorks fans,

Welcome to a new installment of AppWorks tips.

Isn’t that an interesting header!? What on earth has this NGINX (pronounce as “engine-x”, “engine-ex”, or “EN-jin-EKS”…whatever!) to do with our beloved platform? Well, maybe you saw already our new proposition on “AppWorks strategic hosting” where we help you with a supported AppWorks demo environment for your customer proof of concepts or building that fabulous demo to showcase your offerings. When we do things, we do it right; And because this hosting happens publicly on the interwebs it’s time for me to make it secure with a so-called “Reverse Proxy”. If you never heard of it (as I did since last month), continue reading…you’ll learn the why?, when?, what?, where?, and how? on this interesting technique…

Let get right into it…

Let’s first dive into some basic questions before doing all the sweaty work (It’s currently too hot 🌡️ here at my place!)

What is a reverse proxy?

A proxy server is a go‑between or intermediary/gateway server that 
forwards requests for content from multiple clients to different
servers across the Internet.


This is the resource of my information

Why do we even want a reverse proxy?

Protection from attacks - With a reverse proxy in place, a web site or 
service never needs to reveal the IP address of their original server(s).
This makes it much harder for attackers to leverage a targeted attack
against them, such as a DDoS attack.

This is the resource of my information

Who can deliver a reverse proxy?

In my opinion there is only one package delivering a reverse proxy best; And that’s NGINX. I see it also in use at big companies, so it’s time to do some research on it. We use the open-source version which is free of charge…As far as I can see.

What about load balancing?

Well, as we’re in the NGINX comparison space we might as well dive into the load balancing part too. Not for this post, but I will place it on my backlog for a future post.

The plan

My images run locally on “Oracle VirtualBox”, and I can access AppWorks/OTDS via these URLs:

AppWorks platform:


What I want to accomplish is to ‘Hide’ the port and IP address here; We would like to work with a nice URL like this: http://demo.myawpdomain.nl/home/appworks_tips

The installation part

My posts always start with a clean VM image based on RHEL, so boot it up and login with MobaXTerm (I have a sysadmin account to work with)

Just to inform you, my local images don’t have any firewall applied as I want to have an open play field. On the internet that’s a different story (not for this post), but make sure you tighten all barrels as it’s a big bad world out there…

Time for the installation of NGINX (or is it Nginx?, or nginx?…whatever!)…

sudo dnf install nginx
sudo systemctl enable --now nginx

Now NGINX will present you the introduction page on: (default on port 80!)


Great, “one small step for mankind, …”! 🚀

The configuration part

The first thing is to set (locally) your ‘hosts’ file with a value like this: demo.myawpdomain.nl. After saving it, you can type demo.myawpdomain.nl in your browser which shows you again that NGINX introduction page like before.

In Windows 10 your hosts file is found here: c:\Windows\System32\Drivers\etc\hosts; Edit it with administration permission!
On the global internet, you do this exact same trick in the DNS settings of your domain provider; This will be a new A-record pointing to your public IP!

Now, let’s try to call this URL: http://demo.myawpdomain.nl/home/appworks_tips ; The result is an NGINX error: The page you are looking for is not found.

So, NGINX requires some configuration…I guess? Let’s start with this CYA move-command: sudo mv /etc/nginx/nginx.conf /etc/nginx/nginx.conf-distro; After it, you create a new configuration file with sudo vi /etc/nginx/nginx.conf where we need to make this content in place:

worker_processes  1;

events {
worker_connections 1024;

http {
server {
listen 80;
server_name demo.myawpdomain.nl;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $remote_addr;

location /home/appworks_tips {
} # end location
location /cordys {
} # end location
location /otdsws/login {
} # end location
location /otdsws {
} # e
} # end server
} # end http

What does this file do? Well, really simple! It listens for an HTTP request with this URL demo.myawpdomain.nl:80; Looks familiar…correct? Then it passes the correct header element from the request into it (which are received from your remote call…Your browser!); It then searches for a matching location; Like /home/appworks_tips and plots the remote requests to its internal server name which is (from the server perspective) our localhost (or

worker_processes is (I think) the number processes on the server to manage parallel incoming requests (should equal the number of CPUs)
worker_connections is (I think) the number of simultaneous open connection possible.

See here for more options

Let’s save this file and have a check if the file is in a correct format: sudo nginx -t; If so, you can restart the service: sudo systemctl restart nginx
Now go back to your browser and type: demo.myawpdomain.nl/home/appworks_tips…Ohwwwww mama!! 😍

BUT!!! Boy-o-boy…there we go again!

Because I’m behind an OTDS instance, my page gets forwarded to OTDS; To be more specific, this URL:! That wasn’t part of the plan…The IP and port should be hidden! So, now what? Well, that’s part of the security administration of your organization! So, login the old way…Via the IP URL:, open the ‘Security Administration’ artifact, and edit the ‘Authenticators’ details:


Update the public OTDS login URL with this value: http://demo.myawpdomain.nl/otdsws/login


Now, hit the logout button and see your request being redirected nicely to the correct domain URL!



Have also a look in the developer console of the browser. A closer look at the request headers tells me we’re on a good track here:



Yes please…

sudo tail -999f /var/log/nginx/access.log
sudo tail -999f /var/log/nginx/error.log

Yes, that’s a “DONE” where we implemented an amazing technique called “Reverse Proxy”. I have a much better understanding and feeling why that’s a feature you want to be familiar with; especially when you’re publicly exposing services on the internet. You can also use this within your own local network what I also see happening at larger companies. There is nothing more to add for this post, so have a great weekend and I see you in the next one.

Don’t forget to subscribe to get updates on the activities happening on this site. Have you noticed the quiz where you find out if you are also “The AppWorks guy”?