The goal

Make all requests to a previously static page at https://www.example.com/sub/folder on server 1 (Proxy) ACTUALLY go to a Drupal site at https://other.example.com on server 2 (Origin)

This is also getting setup as a multisite, because there are sub/folder2, sub/folder3, etc. that will need to be converted to Drupal sites. I don't think this has anything to do with the problem, but for the sake of completeness, I'm adding the sites.php changes too below.

What I've done so far

Changes on Server 1 (Proxy): Apache config

RewriteCond %{HTTPS} off
RewriteCond %{REQUEST_URI} ^/sub/folder
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
SSLProxyEngine On
<Location /sub/folder>
  ProxyPass https://other.example.com/
  ProxyPassReverse https://other.example.com/
  ProxyPassReverseCookiePath / /sub/folder

Changes on Server 2 (Origin): settings.php and sites.php

sites.php (because of multisite; and sites/sitename/settings.php is the file I'll be referencing below)

$sites['other.example.com'] = 'sitename';
$sites['www.example.com.sub.folder'] = 'sitename'; // I don't think this one is necessary, but just in case?

Aside from the standard DB setup in settings.php, the following has been added:

// $base_url allows for links/URIs to be generated properly
// Changing the REQUEST_URI seems to have fixed form issues, like the search block/form
// Not sure if the cookie_domain is doing anything/working properly
if (isset($_SERVER['HTTP_X_FORWARDED_HOST']) && $_SERVER['HTTP_X_FORWARDED_HOST'] == 'www.example.com') {
  $base_url = 'https://www.example.com/sub/folder'; // NO trailing slash!
  $_SERVER['REQUEST_URI'] = '/sub/folder' . $_SERVER['REQUEST_URI'];
  // (Edit) note don't put 'http' in front of this
  $cookie_domain = '.other.example.com';
$conf['reverse_proxy'] = TRUE;
$conf['reverse_proxy_addresses'] = array('ip.of.origin.server');

The problems

  1. Trying to login through www.example.com/sub/folder/user validates (according to Drupal log)... but then it treats the page re-load as an anonymous user and fails access. Presumably, the cookie gets broke/lost/invalidated somehow in between. So, authenticated access to the server has to be done through other.example.com Not a huge problem (since the average Joe won't be logging in), but...
  2. There's just a lot of annoying things occuring having to deal with fixing user/content created links and URIs. Currently, links that are first viewed after a cache clear are cached as whatever domain they're being viewed from. (This happened from using Pathologic module to force absolute URLs.) I realize this might not have been the BEST solution--using Pathologic--but if I fix problem 1., this should become a moot point.

So, I think I've got some kind of SSL/Proxy cookie issue at this point... any suggestions?

  • Try the alternative from comment 25: (drupal.org/node/244593) Set your base_url to the actual path. Then use: $_SERVER['REQUEST_URI'] = str_replace('/actual-path/', '/proxy-path/', $_SERVER['REQUEST_URI']); Commented Jun 26, 2015 at 19:32
  • Won't changing the base_url (assuming "actual-path" means "other.example.com") in the settings.php cause links/URIs to be created as those? (And it did. So, when it should have gone to www.example.com/sub/folder/blah, it tried to go to www.example.com/blah.) Commented Jun 29, 2015 at 17:47

1 Answer 1


Drupal should be able to install into a sub-directory and "just work" without fiddling around with it. This question already answers this particular sub-directory issue:

How to get Drupal 7 installed in a sub-folder / sub-directory properly?

Try re-installing a fresh installation into the sub-directory. Can you login? The .htaccess of 2.site.com should have nothing to do with the issue at hand regarding 1.site.com.

The reason for your problem is likely something along the lines of a clean-url issue fighting against your configurations. A fresh install will be the easiest way to resolve this particular issue.

Regarding this line:

and I'd like only that subdirectory to go to an arbitrarily named server with a drupal install at, say "https://2.site.com"

The domain merely points to a directory. The domain ISN'T an actual file location. As such, this particular line doesn't seem to make any sense. If the issue is not resolved by simply clearing out and reinstalling Drupal in the sub-directory at hand, please re-state your question by providing more information, describe where these sub-directories are in the system root relative to each other and then describe which directory each domain points to. Don't describe domains AS directories because they aren't directories - they're pointers.

  • I don't want Drupal to be installed in a subdirectory. There's a proxy coming from another server (basically, an old site/subdirectory is being converted to Drupal), and in order to maintain the old links, the old server is acting as a proxy. The Drupal site itself is NOT set up in a subdirectory. I need 1.site.com/sub/folder to point to 2.site.com, but the links on the site still need to look like 1.site.com/sub/folder/link Commented Jun 23, 2015 at 17:46
  • Then this definitely isn't a Drupal question. This is a domain configuration issue that has nothing to do with Drupal itself. en.wikipedia.org/wiki/Domain_masking Commented Jun 23, 2015 at 18:10
  • If this is [entirely] not a Drupal question, why are there things like a whole section on "Reverse Proxy Configuration" in Drupal's settings.php file? Sorry, I seem to be able to get it to proxy to the site alright, and certain things work, but then there are just certain other areas of the site that act up (like the /user page) Commented Jun 23, 2015 at 18:44
  • Question: Are you USING apache reverse proxy or a similar proxy server Or are you simply pointing the URL domain record to the site and confusing that with an actual "proxy"? (If you've got a reverse proxy set up in settings.php then perhaps there's an issue with either that or the settings you've got configured. List your settings and we might be able to help you get this fixed! :-)...) Commented Jun 24, 2015 at 12:23
  • Yes. Using ProxyEngine On, then ProxyPass and ProxyPassReverse on the proxy server. (And by "proxy server", I just mean the server that's forwarding/proxying the requests to the remote Drupal server; it's not some kind of dedicated proxy/proxy only server. We seemed to have gotten it working, it's just that subirectory stuff that throws a wrench in. Commented Jun 24, 2015 at 18:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.