Wordpress Blog Domain Reverse Proxy Configuration

We are using Netlify to deploy our sites & use that as the primary point of entering the site. We are also trying to host a blog on another domain using Wordpress. We wanted to Reverse proxy this blog domain using the Netlify Site due to SEO reasons instead of having it through a sub domain

Netlify Site: https://my-website.com (Primary Site where it is hosted on Netlify)
Wordpress Managed Blog: https://blog-website.com (Blog Hosed using WP)

Expectation:
When user navigates to “https://my-website.com/en/view/blog” it should 200 rewrite (i.e. having the same domain, but redirecting to different domain) to “https://blog-website.com

We are able to achieve this using as per document (Redirects and rewrites | Netlify Docs)

For the complete integration to work, we would require few additional information when this reverse proxy is triggered.

  1. We would require “X-Forwarded-For” header with the Client IP
  2. We would require the IP range of the proxy provider, to use the same on Wordpress as per the doc for security reasons.
  3. Can we pass custom header as per this doc (Custom headers | Netlify Docs) & pass dynamic value (like client ip which you can share via pre-defined variables / pointing to custom environment variable, etc… ?)

Attaching the referencing link here (Using a Reverse Proxy with WP Engine - Support Center) which describes the configuration to be made from Wordpress which are dependent on Netlify.

Let us know if you would require further details on the topic

We noticed few threads related to this & seems quite old… If we have introduced as any new features… Please feel free to provide us with the details.

Thanks.

Hi, @storefront. We can meet some of those requirements but not all of them.

  1. We would require “X-Forwarded-For” header with the Client IP

That header is sent and it contains several IP addresses one of which is the client IP address. There is a different header which contains just the client IP address which is the x-nf-client-connection-ip header.

Also, the other IP addresses in the X-Forwarded-For header which are not the client IP address will be in reserved IP address ranges. This means it is very easy to determine which IP addresses are not the client IP address. In other words, if you filter that list to remove the reserved IP addresses then the client IP address will be the only one that remains.

  1. We would require the IP range of the proxy provider, to use the same on Wordpress as per the doc for security reasons.

The IP addresses used for proxying will be the IP address of the individual CDN nodes. Those IP addresses are not in single network block and are also continually changing. We do not provide a static IP address list for the IP addresses is used for CDN nodes.

In other words, there is no list of IP addresses I can give you today which you can be guaranteed will work tomorrow. I could give you a list today but it can change at any time and without notice (and it would likely change in days not weeks). Because it will change so quickly we do not attempt to provide a list at this time. If we did so it would almost certainly create confusion that there is a static IP address list (there is not) and we don’t want to cause that misunderstanding.

There is a feature request for a static IP addresses list to be used for proxying. (There is another feature request for static IP addresses to be used by the build system for outbound HTTP requests.) Again, though, this isn’t possible at this time.

  1. Can we pass custom header as per this doc (Custom headers | Netlify Docs) & pass dynamic value (like client ip which you can share via pre-defined variables / pointing to custom environment variable, etc… ?)

You can pass static custom headers using the custom headers in proxy redirects instructions. So, if you have an environment variable defined you can use that at build time to hardcode that value into the redirects for that specific deploy. It will not be dynamic though.

For example, if you were to set the value in the header using an environment variable during the build and then triggered a new build the value would be used. However, if you now change that environment variable but don’t trigger a new build, the value from the previous deploy will continue to be used. Only once there was a new successful deploy would the new value be used. That is because the build code would be responsible for setting this value as a static value during the build itself.

Note, that “the build code would be responsible” phrase above. This means that (for example) environment variables placed in _redirects, _headers, or netlify.toml (the three places you can define headers), are not automatically evaluated. You could manually rewrite those file during the build however to replace text placeholders with the environment variable value using sed in the build command. There is an example in this post quoted below:

There are probably a million ways, but when I need to populate a file with a value, I do something like this in my build command:

sed -i s/PLACEHOLDER/${VARIABLENAME}/g webpack.js && my-usual-build-command

This way the value is put in place in the file before I need it. I don’t know how webpack runs things in its config file while you use it, so there may be a more elegant way but it comes back down to “populate the value in a file before you need it”.

The find and replace above is in a javascript file but the same can be applied to any text files being used during the build - _redirects, _headers, and netlify.toml included. This will allow you to hard code environment variables into headers or redirect rules at build time.

There is also a workaround which is that you can use a function to proxy. Instead of the default proxying our service provides, you could do this instead:

  • direct the path to a function
  • the function then created the dynamic header and makes the proxied request
  • the function then returns the proxied content as its own response

In other words, you proxy via a function. Then your function creates and sends the dynamic header when making its HTTP request to the proxy target.

If there are other question, please let us know.

1 Like

Thanks @luke for the detailed explanation. We understood our options. Will get back to you if we have any further queries. Thanks :+1: