Running Optimizely CMS behind NGINX Reverse Proxy

A reverse proxy is a server that acts as a single point of entry to as many services (e.g. web sites) as you like on your internal network. The reverse proxy typically sits behind the firewall and directs requests to the appropriate backend server. The firewall is configured to allow certain traffic to be transmitted from and to the reverse proxy. Reverse proxies are typically implemented to scale different types of services, increase security, performance, and reliability.

Problem

Some of the most common problems website producers try to solve is

• You have a limited number of public IP:s but want to host the websites on multiple internal servers.
• Centralised SSL handling, without having to deal with SSL certificates on the internal servers.
• You want to increase and intercept requests, restricting or requiring which headers are allowed.
• Centralised caching, forcing cache headers and adding a layer of content cache closer to the requesting client.

Configuration of NGINX

In this blog post, I'll be using NGINX and Certbot to handle Let's Encrypt certificates. NGINX can be run on bare metal, in virtualized environments, in a container (e.g. Docker) and to my knowledge NGINX is compatible with most Linux distributions. Due to the many options, I won't cover that in this post, simply install NGINX using your preferred method and include Certbot.

The goal of this config is to configure an Optimizely CMS web with an external hostname to an internal host, to complicate things the internal host uses an internal host domain, is unencrypted and doesn't use the standard port.

In this config, we'll set up the external host on port 80 allowing Certbot to configure SSL and port 443. This is the config of any typical Optimizely CMS site I use with NGINX. 

server {
	# External host names to proxy
	server_name www.herlitz.io herlitz.io;

	# Listen to port 80, this will be reconfigured by certbot
	listen 80;

	# Redirect APEX to www, this can be reversed if you prefer https://domain.com
	if ($host = herlitz.io) {
		return 301 https://www.herlitz.io$request_uri;
	}

	# The internal address, this can be an IP or whatever the proxy can access
	location / {
		proxy_pass http://herlitz.home:82;
	}

	# To allow dynamic updates of the Optimizely GUI, we'll setup websockets redirection
	location /EPiServer/Shell/socket/endpoint/ {
		proxy_pass http://herlitz.home:82;
		proxy_http_version 1.1;
		proxy_set_header Upgrade $http_upgrade;
		proxy_set_header Connection "upgrade";
		proxy_read_timeout 86400;

		# Having issues with websockets over https?
		# Try clearing the Origin header. (Thanks Jonas and Fernando)
		#proxy_set_header Origin "";
	}
}

As can be seen in the config have a few sections.

• Server: This is a configuration block in NGINX, best described in the official documentation.
• server_name: The external host address
• listen: The port you expose, in any normal web this is 80 or 443, in this example, we configure port 80 and let Certbot handle the reconfiguration to 443.
• location: Sets configuration depending on a request URI, in this configuration, we have two location blocks set
• The root (/) with proxy_pass: This block will map or "connect" the host address with the internal address. It will only handle normal HTTP protocol operations.
• The location block /EPiServer/Shell/socket/endpoint/ will handle the configuration to that specific path, the configuration in the example will allow WebSockets from the CMS. This path must reflect your edit UI.

Save your config, test and reload NGINX

$ sudo nginx -t
$ sudo systemctl reload nginx

To enable SSL using Certbot in the above example 

$ sudo certbot --nginx -d herlitz.io -d www.herlitz.io

The location block can be simplified or if you want WebSockets for the entire site

location / {
	proxy_pass http://herlitz.home:82;
	proxy_http_version 1.1;
	proxy_set_header Upgrade $http_upgrade;
	proxy_set_header Connection "upgrade";
	proxy_read_timeout 86400;
}