Setting up WordPress behind a reverse proxy

On By ntanya54In Technology

Task: put a WordPress blog/site behind a reverse proxy. So blog.mysite.com moves to supersite.com/blog.

Why? In our case, we do it for branding and also for SEO benefits: larger site supersite.com receives more traffic, and we want to fold our blog content into supersite.com/blog.

Let’s agree on a couple of terms before we start:
– original blog.mysite.com is A
– destination supersite.com/blog is B

I’m using the latest version of WordPress (4.2.2) and Apache (2.2) on Ubuntu.

Let’s get started!

  1. Server setup

    2. Before we even touch WordPress, we need to make sure that the server hosting B is ready to accept requests and forward requests for any URL to A.

    Assuming we have Apache setup and working, let’s make sure mod_proxy is enabled. With root or sudo privileges, run:

    a2enmod proxy_http
service apache2 restart

    Then, open the Apache virtual hosts config file, and add:

    ProxyPreserveHost On
ProxyRequests Off   
<Location /blog>
    ProxyPass http://blog.mysite.com 
    ProxyPassReverse http://blog.mysite.com  
    Order allow,deny   
     Allow from all
</Location>

    Quick explanation for each line:

    ProxyPreserveHost On: Off by default. I’m turning it On because I host multiple sites on this server and use virtual hosts. If you don’t need it, simply exclude this line

    ProxyRequests Off: should only be on for forward proxy, not for reverse proxies

    <Location /blog>: applies proxy directives to requests matching /blog

    ProxyPass http://blog.mysite.com: creates a mapping from a path within the local web site to a given remote URL

    ProxyPassReverse http://blog.mysite.com: rewrites URLs in HTTP headers
    Order allow,deny: allows access to all proxied content

    After that, restart apache again:

    service apache2 restart

    Result: If you got this right, when you load supersite.com/blog you should see your WordPress blog home page.

    Note: if you see errors 500 on interior pages, check .htaccess file for any rewrite rules, and adjust if necessary.

    If you run into issues, here are 2 great sources on how to setup reverse proxy on Apache:

  • Update WordPress settings

    Now we got to make sure that all URLs (category pages, single post pages) also display correctly on site B.

    For this, log into WordPress admin using the original login link: blog.mysite.com/wp-login.php.

    Go to Settings > General, and update the “Site address (URL)” field to B (supersite.com/blog).

    Screen Shot 2015-07-13 at 2.52.32 PM

    Result: All pages should be accessible and rendering correctly.

  • Update redirects, canonical tags, robots.txt

    • This is a pretty extensive area that I have not completed yet, so I’ll add to this section soon once I have this task completed. Stay tuned!

  • Fonts

    • If you use any font embedding services, make sure you have correct license to match your new domain (supersite.com), because it’s different than your original blog.mysite.com.

  • Administration

    • You should be able to login and administer all content via the original link blog.mysite.com/wp-login.php.

    3 thoughts on “Setting up WordPress behind a reverse proxy”

    1. juan

      With this configuration a .htaccess file is generated with the following code:

      RewriteEngine On
      RewriteBase /blog/
      RewriteRule ^index\.php$ – [L]
      RewriteCond %{REQUEST_FILENAME} !-f
      RewriteCond %{REQUEST_FILENAME} !-d
      RewriteRule . /blog/index.php [L]

      I need to delete “blog/” to work whenever I update the permalinks.

      Reply
    3. lukeburden

      Hi Tanya,

      We’ve taken a similar approach but using Nginx; thought that approach might be interesting to your readers, as we ended up pretty much treating WordPress as a black-box and keeping its settings simple.

      Would love your thoughts if you had a moment:

      https://www.poparide.com/blog/how-to-host-wpengine-blog-in-subdirectory-using-reverse-proxy/

      Finally – did you consider the security issues related to this approach? For example, if you have an application that requires authentication on supersite.com, then you are mostly using a Cookie to store a session ID on browsers. If not set with an appropriate path, Cookies may be being passed right through your reverse proxy to the blog, which at best is not great, but if your blog is hosted by a third party you’re basically sending them your users’ session IDs. :)

      Anyway, all the best!

      Luke

      Reply

    Leave a comment