TLS termination

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:

1
2
3
  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:

1
2
3
  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 address 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.