Documentation VIP Go Reverse Proxies and VIP Go

Reverse Proxies and VIP Go

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: 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 reverse proxy services you may have heard of.

↑ 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 );

    Automattic\VIP\Proxy\fix_remote_address_from_ip_trail( 
        $_SERVER['HTTP_X_IP_TRAIL'], 
        MY_PROXY_IP_WHITELIST 
        ); 
} 

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 ); 

    Automattic\VIP\Proxy\fix_remote_address( 
        $_SERVER['HTTP_TRUE_CLIENT_IP'], 
        $_SERVER['HTTP_X_FORWARDED_FOR'],
        MY_PROXY_IP_WHITELIST 
        ); 
} 

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:

<?php
// A constant defining an array of whitelisted IP addresses and/or CIDRs
// which equate to the possible IP addresses of your Remote Proxy
define( 'MY_PROXY_IP_WHITELIST', [
	'1.2.3.4/20',
	'5.6.7.8/20',
	'2.3.4.5',
] );

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.

Documentation is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.