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 including something like this in your vcl_recv subroutine:

1if (req.http.Fastly-SSL) {
2    set resp.http.X-Is-SSL = "yes";
3  }

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:

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

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.