Reverse Proxies and VIP Go

VIP Go Platform

This document is for sites running on our VIP Go platform.


Overview #

The speed and utility of the VIP Go edge cache service will cover many scenarios; however if you do wish to use a reverse proxy to cover a particular use case, we will be happy to discuss your situation and advise you.

There are some provisions you will need to make when you deploy a reverse proxy in front of VIP Go, to ensure that your application code and our platform functionality continues working as expected. Not making these provisions can result in side effects such as valid users being blocked at login.

↑ Top ↑

Terms #

  • End User: the person (or bot) which has requested a resource from your VIP Go hosted WordPress site.
  • Remote Proxy or (Reverse Proxy): a service which sits between the end user and the VIP Go service, either passing requests through, intervening in requests, caching requests, or all three. Akamai and Cloudflare are examples of remote or reverse proxy services you may have heard of.

↑ Top ↑

What we need from you (or your remote proxy provider) #

  • The remote proxy must set a True-Client-IP HTTP request headers with the IP of the end user
  • The remote proxy should set X-Forwarded-For with the IP of the end user, this will be used to populate the IP Trail
  • You should provide a whitelist of proxy IPs to validate remote proxy requests against (this is the safest validation method), alternatively…
  • …otherwise the remote proxy must set an X-VIP-Proxy-Verification header with an agreed secret string as the value (contact us to agree this string)

↑ Top ↑

Correcting the remote IP address #

VIP Go allows more securely forwarding the end user’s IP address when there is a remote proxy in play.

Example setup: User => Remote Proxy (e.g. Cloudflare) => VIP Go Edge Cache => Application (PHP/WP)

We need to ensure that the Application (i.e. WordPress, WordPress plugins, etc) is passed the IP Address for the End User, rather than the IP Address for the Remote Proxy. There are two options usually used to pass on the end user’s IP address: either an HTTP request header like X-IP-Trail ($_SERVER['HTTP_X_IP_TRAIL']) which contains a comma separated list of IP addresses with the end user IP as the first IP address in the list, or an HTTP request header containing just the end users IP address, e.g. True-Client-IP ($_SERVER['HTTP_TRUE_CLIENT_IP']).

If the HTTP request header you are using containers a comma separated list of IP addresses, the following code checks the Remote Proxy’s IP address matches a known whitelist, extracts the end user’s IP address from X-IP-Trail, and forwards the End User’s real IP address as REMOTE_ADDR:

$proxy_lib = ABSPATH . '/wp-content/mu-plugins/lib/proxy/ip-forward.php'; 
if ( ! empty( $_SERVER['HTTP_X_IP_TRAIL'] ) && file_exists( $proxy_lib ) ) { 
    require_once( __DIR__ . '/remote-proxy-ips.php' );
    require_once( $proxy_lib );


Alternatively if the HTTP request header you are using contains a single IP address, the following code checks the Remote Proxy’s IP address matches a known whitelist, extracts the end user’s IP address from True-Client-IP, and forwards the End User’s real IP address as REMOTE_ADDR:

$proxy_lib = ABSPATH . '/wp-content/mu-plugins/lib/proxy/ip-forward.php'; 
if ( ! empty( $_SERVER['HTTP_TRUE_CLIENT_IP'] ) && file_exists( $proxy_lib ) ) { 
    require_once( __DIR__ . '/remote-proxy-ips.php' ); 
    require_once( $proxy_lib ); 


One of above code blocks, or similar, should be added to vip-config/vip-config.php. The code assumes a file vip-config/remote-proxy-ips.php, which contains an array of IP addresses. The contents of the file should be similar to the example below:

// A constant defining an array of whitelisted IP addresses and/or CIDRs
// which equate to the possible IP addresses of your Remote Proxy
] );

The IPs can be provided as fully qualified IPv4 or IPv6 addresses, or in CIDR notation.

Note: It is very important that you maintain the whitelist code in sync with any IP changes from your remote proxy provider.

↑ Top ↑

Considerations #

Performance and simplicity of support #

We recognise that for some requirements it is necessary to employ a remote proxy, however it is also true that adding a reverse proxy is likely to decrease performance by some measure and also to increase the complexity of supporting the site to a degree.

Performance degradation is likely in several ways, for example:

  • Reverse proxies inherently add at least one hop to the network path for a request (i.e. from the proxy to VIP Go).
  • If the reverse proxy does not provide a globally distributed network of caching proxies (VIP Go does provide such a network) then it is likely that at least some of your site’s users will be routed suboptimally, increasing the time it takes for your pages to load.
  • Complexity is increased because the reverse proxy adds an additional layer of functionality to debug any issues, and because the VIP support team do not have direct control of the proxy meaning we may need to communicate with the reverse proxy provider.

We’re happy to help you weigh the benefits of using a reverse proxy, and we already support many sites which use this functionality to support their business requirements. Please do contact us to talk through your use cases, and we’ll be happy to help.

Ready to get started?

Tell us about your needs

Let us lead the way. We’ll help you select a top tier development partner. We’ll train your developers, operations, infrastructure, and editorial teams. We’ll coarchitect your deployment processes. We will provide live support for peak events. We’ll help your people avoid dark alleys and blind corners, and reduce wasted cycles.