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
Adding a reverse proxy to a site can prevent some of the security protections that are built into WPVIP’s infrastructure from functioning as expected.
Security features that rely on recognition of an end user’s IP address will be ineffective unless the reverse proxy is correctly configured to log the IP address of an end user.
Features that rely on the correctly logged IP address of an end user includes:
- Network-level site traffic monitoring that detects and dynamically responds to anomalous events such as Distributed Denial of Service (DDoS) attacks.
- Rate limiting for failed WordPress login attempts and protection against brute force attempts on the WordPress login endpoint.
In addition, adding a reverse proxy to a site increases complexity for troubleshooting issues and will restrict VIP’s ability to provide support. To improve VIP Support’s ability to help and respond more quickly, document the details of the reverse proxy’s architecture and configuration in the application’s /docs directory.
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: June 03, 2025