Setting up IIS Reverse Proxy for WordPress isn’t as straight forward primarily due to the fact that WordPress generates absolute URLs in its HTML output, so while IIS Inbound rule works fine: => http://linux/wordpress

The outbound HTML contains absolute links as follows:


…which is obviously unreachable from beyond the intranet.


We need to create Outbound URL Rewrite rules to change all instances of:



So after creating an Inbound rule as we normally do, we create an Outbound rule as follows:

Note the ‘Precondnition:’ option? This is where you restrict the application of this rule only to specific type of content. For example, we do not want the URL ReWrite rule running on Zip files, or images, etc. We only want to target HTML pages by this rule where we change all references from http://linux/wordpress to /ResourceName

So if an appropriate Precondition doesn’t already exist, create one by clicking on ‘View Preconditions’:

And add a condition named appropriately: ResponseIsHtml with the following conditions:

This ensures that the rule is applied only to:

  1. Files whose content type is text/html, and;
  2. are originating from internal domain name: linux, to exclude other applications/servers from this rule.

NB: Where an application needs Outbound rules, create both Inbound AND Outbound rules at RDS > Sites > Default Web Site level, and NOT at RDS level.

But hold your horses, we’re not done yet!

So while we successfully managed to rewrite all references from http://linux/wordpress to /ResourceName, there are other references to linux/wordpress encoded in inline Javascript content as follows:


which the Outbound rule obviously could not detect. To deal with these, we have to create yet another Outbound rule which looks for the string above and replaces it with something appropriate like this:


To do this we create yet another Outbound rule as follows:

This will get all the Javascripts working.

Lastly, always look at the browser console for any issues with loading content, or javascript error. For example, if your public url is https, while your wordpress installation is simply http, the end user’s browser will complain of ‘Mixed Content’ and that some content “was loaded over HTTPS, but requested an insecure resource ‘’. This request has been blocked; the content must be served over HTTPS”. You will need to add yet another Outbound rule to fix this.

Point in case: Gravatar. It tries to load content through unsecure HTTP protocol, if wordpress is actually being served from an unsecure http protocol, which is perfectly reasonable. It doesn’t know that it’s being served by a proxy using HTTPS. So we create an Outbound rule which looks like this:

This simply makes turns HTTP into HTTPS and problem solved!

Keep checking the browser’s console and apply the same technique where needed.

Another link of interest:

IIS as a reverse proxy for Apache and wordpress

Leave a Reply