- English
- 日本語
TLS termination
Last updated 2022-04-07
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.
Do not use this form to send sensitive information. If you need assistance, contact support. This form is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.