How to Load Your WordPress Site Over a Reverse Proxy

Updated on July 19, 2018
2.2K
Shares

A reverse proxy can be used to load a WordPress site from a subdirectory while a completely separate site loads at the root domain.

A reverse proxy consists of a set of rules added to a web server which instruct the server to send requests for a given subdirectory to a separate server.

Let’s consider an example to better understand what a reverse proxy can be used for. Imagine that you have a non-WordPress website which loads at example.com and you wish to use WordPress to power a blog. You want that blog to load at example.com/blog and you want to host your blog with a managed WordPress host like Kinsta.

In order to make this happen reverse proxy rules would need to be configured on the web server hosting example.com instructing the web server to send any requests for the /blog subdirectory to another web server hosting the WordPress-powered /blog website.

Reverse Proxy Add-On

Kinsta does allow and support the use of reverse proxies to load WordPress from a subdirectory or to point a subdirectory of your site to an external server. However, reverse proxies are often challenging to configure and support, and sites that make use of reverse proxies typically require considerably more support than standard WordPress installs.

For this reason, a $50 monthly add-on subscription is applied for each reverse proxy that Kinsta assists in setting up or is called upon to support.

In addition, please allow up to one full business day for initial setup of a reverse proxy. In some cases additional time and collaboration with the Kinsta support team may be needed to get the reverse proxy working properly in non-standard use cases.

Reverse Proxy Use Cases

There are three possible use cases for reverse proxies here at Kinsta. In order to understand these use cases we first need to define two terms: main site and proxied site.

  • The main site is the site that loads at the root domain.
  • The proxied sites is the site that loads from a subdirectory over a reverse proxy.

Going back to our example above, example.com would be the main site while example.com/blog would be the proxied site.

With those definitions in mind, here are the three possible use cases for reverse proxies at Kinsta:

  • Main and proxied sites both hosted by Kinsta: The main site, example.com, and the proxied site, example.com/blog, are both hosted at Kinsta. This would allow for one WordPress installation to power example.com while a completely separate WordPress installation was used at example.com/blog.
  • Proxied site hosted by Kinsta: The main site, example.com, is not hosted by Kinsta while the proxied site, example.com/blog is hosted by Kinsta. This would allow a WordPress installation hosted at Kinsta to be used at example.com/blog, while the main site was hosted elsewhere.
  • Main site hosted by Kinsta: The main site, example.com, is hosted by Kinsta while the proxied site, example.com/blog is not hosted by Kinsta. This would allow a WordPress installation hosted at Kinsta to be used at example.com, while the blog subdirectory was hosted elsewhere.

Let’s review the implications of each option, in particular, we’ll cover the limits of Kinsta’s support for each scenario.

Reverse proxy server example

Reverse proxy server example

Main and Proxied Sites Hosted by Kinsta

If both sites are hosted at Kinsta then Kinsta’s support team can set up the necessary reverse proxy rules on the main site and also configure the proxied site to load over the reverse proxy. Please note that both the main site and the proxied site must be located in the same data center. Further, short downtime is possible during setup of the reverse proxy as Kinsta moves the sites into place.

In this scenario, the client’s responsibilities would include the following:

  • Migrate both sites to Kinsta’s environment (or submit migration requests to have Kinsta migrate the sites).
  • Provide Kinsta’s support team with a clear description of the domain configuration.
  • Allow approximately one business day for each reverse proxy setup.

In this scenario, Kinsta’s responsibilities would include the following:

  • Set up the necessary reverse proxy rules on the main site.
  • Configure the proxied site to load over the reverse proxy.

Only the Proxied Site Hosted by Kinsta

Important note: If only the proxied site is hosted at Kinsta we require that you provide us with the proxy server IP addresses and configure the proxy server to set the headers listed in our standard Nginx reverse proxy rule. These steps are required to ensure that our analytics system works properly and that we don’t blacklist your proxy server IP addresses. 

If just the proxied site is hosted by Kinsta then setting up the reverse proxy itself is not something Kinsta will be able to do since the reverse proxy must be configured on the server that hosts the main site. In this scenario Kinsta’s responsibility is limited to configuring the proxied site so that it is ready to be loaded over a reverse proxy.

In this scenario, the client’s responsibilities would include the following:

  • Migrate the proxied site to Kinsta (or submit a migration request to have Kinsta migrate the site).
  • Add a domain to the site which will be used by the reverse proxy. The reverse proxy needs to be pointed at a domain in order to access the proxied site. Typically, a subdomain is used for this purpose. For example, blog.example.com would typically be used for a reverse proxy loading at example.com/blog.
  • Provide Kinsta’s support team with a clear description of domain configuration.
  • Allow approximately one business day for the proxied site to be configured to load over a reverse proxy.
  • Once the proxied site has been configured, create the reverse proxy on the server hosting the main site.

In this scenario, as mentioned, Kinsta’s responsibility is limited to configuring the proxied site so that it is properly set up to load over a reverse proxy.

Only the Main Site Hosted by Kinsta

If just the main site is hosted at Kinsta then Kinsta’s responsibility is limited to setting up a reverse proxy to load the proxied site (hosted elsewhere). Kinsta will add the standard reverse proxy rule listed in this article. Customizations to this rule can be made at the customer’s request.

In this scenario, the client retains responsibility for configuring the proxied site so that it loads properly over the reverse proxy and for requesting adjustments to the reverse proxy rule should it fail to properly load the proxied site.

Limitations of Proxied Sites

There are some limitations inherent to the use of reverse proxies at Kinsta.

First, please note that Kinsta does not support the use of multisite over a reverse proxy.

In addition, restoring backups or pushing staging sites live on sites that load over a reverse proxy can cause the proxied site to stop loading properly. When working with a proxied site it is always advisable to schedule changes such as these for times of low traffic and to consult with Kinsta’s support team prior to taking action.

At Kinsta, when dealing with proxied sites, the best use of staging is as a test environment. Following testing in staging, the simplest workflow is to duplicate those changes on the live site rather than pushing staging live. In addition, restoring backups of proxied sites should only be done in an emergency when rolling back changes manually is not possible.

Because of these limitations, we do not recommend the use of proxied sites if you anticipate restoring backups or pushing staging sites live on a routine basis.

One alternative to proxied sites worth considering is the use of a WordPress subdirectory multisite installation.

Main Site Reverse Proxy Configuration

There are two major implications for the main site when loading subdirectories over reverse proxies.

  • Reverse proxy rules must be added for each proxied subdirectory.
  • The main site will not be able to use the proxied subdirectories for any purpose whatsoever since all requests for that subdirectory will be forwarded to the proxied site.

This is the standard Nginx reverse proxy rule used by Kinsta to load a site over a reverse proxy:

location ^~ /subdirectory/ {
  proxy_pass http://subdirectory.domain.com;
  proxy_set_header X-Real-IP $remote_addr;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_set_header X-Forwarded-Proto $scheme;
}

The actual subdirectory would be substituted for the /subdirectory/ placeholder. In addition, http://subdirectory.domain.com would be changed to match the domain used to point the reverse proxy at the proxied site.

Proxied Site Configuration

In order to load a site over a reverse proxy the following changes have to be made:

  • A subdirectory needs to be added to the directory path on the server, matching the subdirectory used to load the site and all website files moved to this subdirectory.
  • Updates to the web server configuration need to be made to update the website root to include the new subdirectory. In addition, a rewrite needs to be added to the server configuration to remove the subdirectory from the request URI for each incoming request.
  • All URLs in the proxied site database need to be updated to match the live site URLs (for example, example.com/blog).
  • The site’s wp-config.php file needs to be updated with a $_SERVER['HTTP_HOST'] definition pointing at the main site URL (example.com in the example we’ve been considering).
  • If the site is forced to load over https additional definitions need to be added to wp-config.php to avoid redirection loops.

Note that because of the necessary rewrite rules, a proxied site should avoid creating URLs that duplicate the same subdirectory under which the proxied site loads. For example, a proxied site at example.com/blog should avoid creating a page or directory at example.com/blog/blog.

Summary

The use of reverse proxies at Kinsta is possible and we have a number of clients who have opted to use our infrastructure in this way. However, it’s important to understand the additional technical complexity this arrangement introduces as well as the implications for the use of Kinsta’s staging and backup systems.

If you believe a reverse proxy is the best solution to your present need feel free to contact Kinsta’s support team via chat in MyKinsta to get the process started!

Was this article helpful?
No, or there was something off

Hand-picked related articles

Use WordPress?

Use WordPress?

Join 20,000+ others who get our FREE weekly newsletter with WordPress tips on how to drive more traffic and revenue to your business!

Consent

You have Successfully Subscribed!

Send this to a friend