Test a proxy configuration

Reverse proxy configurations should be tested extensively prior to a site launch.

Testing with cURL

A reverse proxy’s settings can be validated using cURL. Send a cURL request to a URI that is expected to be forwarded to VIP and inspect the response headers. The response should include x-hacker, x-powered-by, and other headers sent by VIP alongside the headers sent by the proxy server.

For example, if example.com is the proxy server, and the VIP application is at example.com/blog/, the following command should return headers identifying the proxy server as well as x-powered-by: WordPress VIP <https://wpvip.com>;:

curl -I https://example.com/blog/ 

Testing with a non-production domain

A test domain can be used for configuring and testing a reverse proxy’s settings by configuring a non-production site with the routes that are intended to be set in production. For example, a testing domain like staging.example.com can be pointed at a site on a non-production environment to test a reverse proxy that will route to staging.example.com/blog/.

Use the VIP Dashboard to add the test domain to the non-production environment, and a Let’s Encrypt TLS certificate for the domain can be installed. Once testing is ready to begin, a search-replace will need to be run on the target VIP site or network site (in the case of multisite) from the site’s previous domain value to staging.example.com. Confirm through testing that all reverse proxy configurations are able to successfully route to VIP.

Completing this process enables the launching of the production site to only require the reverse proxy configuration to be updated with the production domain value.

Testing with a hosts file

Some issues observed on sites with a reverse proxy in front of them require investigation to determine if the source of the issue is from the reverse proxy layer or the VIP Platform. This can be determined by managing the hosts file on a user’s local machine and bypassing the reverse proxy layer. If it is not possible to reproduce the issue with the updated hosts file, the issue is likely to originate from the reverse proxy layer.