+1 408-758-5757

In this post we’re going to show you how to achieve a technique called domain masking. Masking a domain behind a proxy may be used by app developers to direct their users through a desirable, nicely branded domain, hiding the “more ugly” domain/subdomain the app frontend may be residing on, without the end users ever knowing the difference. It may also be used as a layer of security, where certain features are blocked when accessed through the proxy domain. In our example case, we will only be exploring the aesthetics side of domain masking.

Like so many other “more advanced” bits of information on the web, this can be used for pure and malicious purposes both, so we implore you to educate yourself on the necessary steps required to secure your web-facing resources as well as your visitors’ sessions. We encourage you to analyze your website’s headers for free via securityheaders.io where you can also learn more about Apache/Nginx headers.

Disclaimer: FissionBlue Creative will not be held responsible for your use or misuse of the information contained in this post.

Now that we have that out of the way, let’s jump into the meat of it.

What You Will Need to Achieve Domain Masking with Nginx

We acquired a VPS, installed an Nginx web server, bought two domain names (one being the proxy domain and the other being the original masked domain), and then configured each with a vhost and free SSL/TLS certificate from Let’s Encrypt. Oh, and we installed one complete WordPress installation running out of the masked domain.

The Domain Masking Directives You’ll Need

Paste these in your proxy site nginx.conf file (frequently located inside /etc/nginx on Linux/Unix). Make sure you swap out darklotusdigital.com and thelotuslibrary.com with your own values, of course.

location / {
proxy_pass https://darklotusdigital.com$request_uri;
proxy_set_header Accept-Encoding "";
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
add_header Link "<https://darklotusdigital.com$request_uri>; rel=\"canonical\"";
proxy_ssl_verify off;
sub_filter "rel=\"canonical\" href=\"https://darklotusdigital.com/" "rel=\"canonical\" href=\"https://darklotusdigital.com/";
sub_filter "https://darklotusdigital.com/" "https://thelotuslibrary.com/";
sub_filter_once off;

Why We Included Each Directive

  • The proxy_pass directive forwards every single link found on Dark Lotus Digital’s site (not just the homepage).
  • The resolver directive uses Google’s DNS ( to properly identify and locate Dark Lotus Digital on the web.
  • The Accept-Encoding header decompresses the masked site, which has gzip enabled for pagespeed purposes.
  • The X-Real-IP and X-Forwarded-For headers allow any visitor data/logs to be recorded correctly by the masked site (instead of all incorrectly appearing to come from The Lotus Library).
  • The Link header with the canonical data is to make certain Google, Bing, and other search engines know which of the two sites to index, so that we don’t incur duplicate content penalties on the masked site (Dark Lotus Digital is a real, indexed website).
  • The proxy_ssl_verify directive controls whether or not the proxy site will check if the masked site has a valid certificate. This should not be used as a shortcut (we turned this off only because Dark Lotus Digital has both a valid certificate AND auto renewals enabled).
  • The sub_filter directives create a seamless UX, so that if a visitor clicks on an internal link while on the proxy site they will stay on the proxy site (instead of ending up on the masked site). Because this process also overwrites the canonical data from the Link header, we have to insert an extra sub_filter directive to “remove” it and then put it back.

We hope you found this domain masking technique useful and encourage you to share or leave a comment with feedback. One final note: The demo sites used for this exercise are no longer configured to function with domain masking.

Share This