Recently viewed X

TLS termination

Last updated December 12, 2017

Identifying TLS terminated requests

To maintain optimal caching performance, Fastly uses a TLS terminator separate from the caching engine. This means, however, that the caching engine doesn't know that it was originally a TLS request. As a result, we set the Fastly-SSL header when fetching the content from your servers.

Because we set this header, you can check for its presence on your backend by doing something like:

if(req.http.Fastly-SSL){setresp.http.X-Is-SSL="yes";}

and that should tell you if the request was a TLS request or not.

When using WordPress

If you're using Fastly TLS services with WordPress, you'll want to add a check for the HTTP_FASTLY_SSL header so that WordPress can build URLs to your CSS or JS assets correctly. Do this by placing a check in your wp-config.php file to override the SSL flag that is checked later:

if(!empty($_SERVER['HTTP_FASTLY_SSL'])){$_SERVER['HTTPS']='on';}

As usual, this must be placed anywhere before the require_once line with wp-settings.php.

Finding the original IP when using TLS termination

Because Fastly uses a TLS terminator, separate from the caching engine for performance, the engine overwrites the original IP briefly due to the re-request to your origin servers once decrypted and causes anything that references the original IP to show up as 127.0.0.0/8 IPs. To find the original IP via VCL:

use req.http.Fastly-Client-IP if you're using shielding

use client.ip if you're not using shielding or if you're building an ACL

Fastly also sends along the client IP to the origin in a HTTP header, Fastly-Client-IP, which can be used by server software to adjust as needed.