Apache proxy redirect subdomain to subfolder

Hi, There are two configuration methods to achieve your main goal (proxying):

• virtual host configuration
• htaccess file configuration

The more convenient and recommended method is virtual host block configuration. Due to official Apache docs, this method is simpler and more efficient. However, because your prospective proxy is actually on shared hosting, it is quite likely that the only way you could configure proxy is with htaccess file. So, before you start, ensure with your hosting provider which configuration method is available for you. Anyway, let’s go through both of these configuration methods.

1. Vhost (an abbreviation for virtual host) configuration.

Prerequisites.

• Following Apache modules have to be loaded on blog.example.com: mod_proxy and mod_proxy_http.

The configuration of vhost on blog.example.com could look like that:

  <VirtualHost *:80>
    ServerName blog.example.com
    ErrorLog /var/www/blog.example.com/log/error.log
    CustomLog /var/www/blog.example.com/log/requests.log combined
    ProxyPass "/"  "http://example.com/blog/"
    ProxyPassReverse "/"  "http://example.com/blog/"
  </VirtualHost>

Reverse proxy configuration is highlighted. Some words of explanation for this configuration.

• A directive ProxyPass "/" "http://example.com/blog/" makes your blog.example.com a reverse proxy for example.com/blog/.
• ProxyPassReverse "/" "http://example.com/blog/" is needed in case of any redirection made on backend host (example.com), to ensure that proxy (blog.example.com) handles it correctly. For example, you redirected http://example.com/blog/rules/ to http://example.com/blog/rules-gdpr/. Requesting http://blog.example.com/rules you could get different results in your web browser’s address bar depending on ProxyPassReverse directive presence:

[secondary_label without ProxyPassReverse directive set up] 
http://example.com/blog/rules-gdpr/

[secondary_label with ProxyPassReverse directive set up] 
http://blog.example.com/rules-gdpr/

2. Htaccess configuration.

Prerequisites.

• Following Apache modules have to be loaded on blog.example.com: mod_rewrite, mod_proxy, mod_proxy_http, and mod_header.
• Apache configuration directive AllowOverride has to be set to ON in blog.example.com server configuration. That enables configuration with htaccess file.

Create (or modify if it already exists) an .htaccess file in web root directory of blog.example.com vhost. Note that this file is hidden (its name starts with a dot sign). If you use e.g. FTP client to transfer files to blog.example.com, make sure the visibility of hidden files is turned on in its configuration settings. Here are the directives you need to put into your .htaccess file:

RewriteEngine On
RewriteRule ^(.*) http://example.com/blog/$1 [P]
Header edit Location ^http://example\.com/blog/(.*) http://blog.example.com/$1

Some explanation for the content of this file.

• RewriteEngine On enables the runtime rewriting engine.
• RewriteRule ^(.*) http://example.com/blog/$1 [P] defines proxy behavior. Any requested URL ^(.*) will be rewritten as variable $1 to the end of the string http://example.com/blog/, creating new, absolute URL. The request will be redirected due to newly created URL but redirecting server will be acting as proxy, as it is defined with flag [P].
• Header edit Location ^http://example\.com/blog/(.*) http://blog.example.com/$1 is an equivalent of ProxyPassReverse directive in vhost configuration. In case of any redirection on backend host, proxy receives HTTP location header field containing new URL of redirected resource. Our Header directive replaces URL started with http://example.com/blog/ with http://blog.example.com/. Thanks to that our proxy behavior is consistent.

Do not forget to restart Apache service after modifying the configuration :)

in CentOS
sudo systemctl restart httpd

in Ubuntu
sudo systemctl restart apache2

Hint
Mind the web content caching when you will be testing the results of your settings. 
Web content might be cached by your web browser, network devices (e.g. home router), 
internet proxies, CDN etc. Minimize caching impact as much as possible during 
testing time.