Customer Egress Visibility Behind CWS Cloud Proxy
See the customer’s traffic as originating from the CWS proxy's egress IP address
A common question customers have about CWS is whether or not a destination web server would be able to ‘see’ the customer’s egress IP or the CWS cloud proxy’s egress IP.
When a customer's web traffic is redirected to a CWS cloud proxy the destination web server will see the customer’s traffic as originating from the CWS proxy's egress IP address. However, CWS inserts the customer's egress IP address into the XFF Header (X-Forwarded-For) and the X-ProxyUser-IP header. The destination web server would have to be capable of reading either header to retrieve the customer’s egress IP address.
Why is CWS adding the X-ProxyUser-IP header in addition to the XFF header?
Some parts of Google, and perhaps other web service or content providers, use the XFF header while other parts use the X-ProxyUser-IP header. The solution to this inconsistency is to include both headers in the request. This will allow the Google service to read whichever header is appropriate to obtain the IP address needed.
Why are the XFF and X-ProxyUser-IP headers needed?
- Web content providers may need to identify requests that are originating from different organizations sharing the same CWS cloud proxy. This helps to prevent the scenario where a content provider, such as Google, displays CAPTCHA messages to all customers sharing the same CWS cloud proxy.
- Web content providers may use these headers to deliver regional content based on the IP address recorded in the header. This is particularly relevant where a customer’s web request originates from a different country than the CWS cloud proxy they are forwarding their traffic to.
Note: The XFF and X-ProxyUser-IP headers are not added to HTTPS requests unless HTTPS inspection is enabled.
Download the Customer Egress Visibility Behind CWS Cloud Proxy Datasheet (PDF).