Reverse proxy
A reverse proxy is a server that sits between the end-user requesting information from a site and the VIP application serving the content. VIP only recommends using a proxy if it is absolutely necessary due to application or policy requirements.
There are technical requirements and considerations to take into account before beginning to set up a reverse proxy.
A system administrator on the customer’s side should be involved early on, and the settings for a proxy should be tested on a non-production environment before a site launch. A sufficient amount of time—typically at least two weeks—should be allocated for thorough testing.
Note
WPVIP’s infrastructure has network-level site traffic monitoring that detects and dynamically responds to anomalous events such as Distributed Denial of Service (DDoS) attacks.
Adding a reverse proxy to a site severely limits the ability for these network-level protections to function. If a reverse proxy is added to a site, configurations for mitigating the effects of anomalous traffic events such as DDoS attacks must be implemented in the settings of the third-party reverse proxy provider.
In addition, adding a reverse proxy to a site:
- Will prevent some security features built in to the VIP Platform rely on IP address recognition (e.g., limits on failed login attempts, protection against brute force attempts) from working as expected. To restore some of these protections at the application layer, configure a reverse proxy to correctly log the IP address of an end user.
- Will restrict VIP’s ability to provide support and add complexity to troubleshooting issues. To improve VIP Support’s ability to help and respond more quickly, document the details of a reverse proxy architecture and configuration in the
/docsdirectory.
How a reverse proxy works
The most common use case for a reverse proxy is to enable more than one application to be served from the same domain. For example, if a non-WordPress application is served at example.com on a non-VIP host, and there is a need for a blog powered by WordPress, that blog application can be hosted on VIP, and a reverse proxy can forward example.com/blog/
- A request comes to
https://www.example.comfor the path/blog/2019/hello-world/. - The proxy server forwards the request to the VIP application’s convenience domain, along with the host header and request URI from the end-user’s browser. This sets the host header to
https://www.example.comand request URI to/blog/2019/hello-world/. - The VIP application returns the post as
https://www.example.com/blog/2019/hello-world/. - The user’s browser displays the VIP-powered content as
https://www.example.com/blog/2019/hello-world/.
Caching and content delivery networks (CDNs)
Content of a site hosted on VIP is already served and cached though the WordPress VIP Platform’s CDN. Using the CDN or caching features of a reverse proxy provider to serve a VIP site’s content instead of—or in addition to—VIP’s CDN is strongly discouraged. Enabling the CDN or caching features at the reverse proxy layer often results in having a double CDN, which if not carefully set up, may cause issues such as cache invalidation, accidental caching of authenticated requests or other private content, and possibly more.
If a caching feature or CDN other than VIP’s is being used for a site, it is essential that it is configured to coordinate cache purges at the proxy layer when caches are purged on VIP’s edge servers. VIP recommends that reverse proxy purges have low TTLs to avoid creating a cache juggling situation in which the reverse proxy’s cache clears before VIP’s and re-caches the older content.
Last updated: November 05, 2024