I've got a bit of a unique and interesting setup going on from what I can tell, with an interesting issue. I have a Windows Server 2012 box as my main web server hosting website.com. At http://website.com/sites/ I have a reverse proxy setup with ARR to point everything back to a Wordpress WPMU install on a Debian box running Apache. Here's the rewrite rule configuration:
Now, everything works properly but the one thing messing up is that if I go to any wp-admin/ page through the reverse proxy, I get a redirect loop:
For the sake of being accurate with what I'm describing, here is my .htaccess file and my wp-config.php file (obvious stuff omitted).
What I find interesting is that if I change my local hosts file to point my domain to the Debian IP address and bypass the IIS ARR, then wp-admin/ works just fine, no issues. It just seems that my issue is somewhere with the translation between IIS and Apache? I'm at a loss for what to look at and debug this any further.
Any help would be super appreciated!
Possibly it happens because Host header is modified by ARR.
Use preserveHostHeader setting to keep the header unchanged.
https://stackoverflow.com/a/7180527/991267
I'm wondering if the regex is getting confused by the rewrite engine in apache. have you tried disabling the .htaccess file and visiting the actual file in ".../wp-admin/" as ".../wp-admin/admin.php" instead?
The methodology for resolving this would include identifying the actual problem.
I would temporarily disable
https
for the admin site, in a test or staging network if required due to security requirements.Then I would sniff the relevant traffic from the IIS/ARR host or from the Apache host, to see what in fact happens between the hosts when you call the admin page. Control dumps for traffic between client and IIS as well as client and Apache probably helps too. Use your favourite sniffer, else let me suggest Wireshark for Windows or tcpdump for Linux.
I am quite sure you would quickly see if there is a redirect problem, a regex url interpretation problem or something else. The solution would of course depend on what you actually find.
This is the best way I know of debugging reverse proxy weirdnesses, as one works with facts which narrow down the problem scope instead of speculations that widen it.
To get help with the analysis I would post two filtered packet dumps: one for going through the IIS reverse proxy and one for connecting directly to the Apache, differences highlighted.