Hear from Slack, the ACLU, TED, & more at our customer summit in San Francisco Register
LOG IN SIGN UP
Documentation

TLS termination

  Last updated April 17, 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) {
    set resp.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:

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.

For more information about TLS-related issues, see our TLS guides or contact support@fastly.com with questions.


Back to Top