- About the web interface controls
- Always-on DDoS mitigation
- Browser recommendations when using the Fastly web interface
- Content and its delivery
- Fastly POP locations
- Getting started with Fastly
- How caching and CDNs work
- How Fastly's CDN Service works
- HTTP status codes cached by default
- Self-provisioned Fastly services
- Sign up and create your first service
- Working with services
Domains & Origins
Domains & Origins
- Changing origins based on user location
- Connecting to origins
- Enabling global POPs
- Failover configuration
- IPv6 support
- Maintaining separate HTTP and HTTPS requests to origin servers
- Routing assets to different origins
- Setting up redundant origin servers
- Specifying an override host
- Using Fastly with apex domains
- About Dynamic Servers
- Authenticating URL purge requests via API
- Cache control tutorial
- Caching configuration best practices
- Controlling caching
- Creating and using pools with Dynamic Servers
- Creating and using server entries with Dynamic Servers
- Enabling API caching
- Enabling automatic gzipping
- Failure modes with large files
- Getting started with surrogate keys
- HTTP/2 server push
- Implementing API cache control
- Logging purge requests
- Making query strings agnostic
- Purging API cache with surrogate keys
- Request collapsing
- Segmented Caching
- Serving stale content
- Setting Surrogate-Key headers based on a URL
- Setting Surrogate-Key headers for Amazon S3 origins
- Single purges
- Soft purges
- Streaming Miss
- Wildcard purges
- Accept-Language header VCL features
- Authenticating before returning a request
- Basic authentication
- Creating location-based tagging
- Custom responses that don't hit origin servers
- Delivering different content to different devices
- Enabling URL token validation
- Guide to VCL
- Isolating header values without regular expressions
- Manipulating the cache key
- IP geolocation variables: Migrating to the new dataset
- Overriding which IP address the geolocation features use
- Response Cookie handling
- Support for the Edge-Control header
- Understanding the different PASS action behaviors
- Using edge side includes (ESI)
- VCL regular expression cheat sheet
Access Control Lists
Monitoring and testing
- Domain validation for TLS certificates
- Enabling HSTS through Fastly
- Forcing a TLS redirect
- Managing domains on TLS certificates
- Serving HTTPS traffic using certificates you manage
- Serving HTTPS traffic using Fastly-managed certificates
- Setting up free TLS
- TLS key and certificate replacement
- TLS termination
Web Application Firewall
- Log streaming: Amazon S3
- Log streaming: Microsoft Azure Blob Storage
- Log streaming: Cloud Files
- Log streaming: Datadog
- Log streaming: DigitalOcean Spaces
- Log streaming: Elasticsearch
- Log streaming: FTP
- Log streaming: Google BigQuery
- Log streaming: Google Cloud Storage
- Log streaming: Honeycomb
- Log streaming: Kafka
- Log streaming: Log Shuttle
- Log streaming: LogDNA
- Log streaming: Logentries
- Log streaming: Loggly
- Log streaming: Heroku's Logplex
- Log streaming: OpenStack
- Log streaming: Papertrail
- Log streaming: Scalyr
- Log streaming: SFTP
- Log streaming: Splunk
- Log streaming: Sumo Logic
- Log streaming: Syslog
User access and control
Last updated October 15, 2019
When we store your content in cache, we calculate a Time to Live (TTL). The TTL is the maximum amount of time we will use the content to answer requests without consulting your origin server. After the TTL expires, we may keep the content in storage, but we won't use it to answer requests unless we're able to revalidate it with your origin.
There's no guarantee that the content will stay cached for the length of time specified in the TTL. Depending on the size of the object and how popular it is relative to other objects, we may delete it before its TTL expires.
For more information about controlling how long Fastly caches your resources, start with our Cache Control Tutorial. In general, we will honor any cache-control headers you send to us from your origin.
Determining the TTL of an object
You can determine the TTL of an individual object as follows:
- If you've set the
Cache-Control: max-age, or
Expiresheaders, the TTL is whatever you specified in those headers
- If you've specified the TTL in the web interface or custom VCL, the TTL is whatever you specified
- If you've specified the TTL in the web interface or custom VCL and you've set the
Cache-Control: max-age, or
Expiresheaders, the TTL specified in the web interface might override the TTL specified in the origin response
- If you haven't specified the TTL in the web interface or custom VCL and you haven't set the
Cache-Control: max-age, or
Expiresheaders, the TTL is 3600 seconds
You can change this limit on the Configuration page.
Setting different TTLs for Fastly cache and web browsers
Purging objects from the Fastly cache is easy. Clearing the caches of users' web browsers is much harder. For that reason, it can make sense to set different TTLs for content in the Fastly cache versus users' web browsers. You can set different TTLs for the Fastly cache and web browsers through Surrogate-Control headers defined by the W3C. For example, if you wanted Fastly to cache something for a year but you also wanted to set a maximum age of a single day for users viewing that object in a web browser, then you could return the following HTTP headers:
1 2 Surrogate-Control: max-age=31557600 Cache-Control: max-age=86400
The Surrogate-Control header in this example tells Fastly to cache the object for a maximum of 31557600 seconds (one year). The Cache-Control header in this example tells the browser to cache the object for a maximum of 86400 seconds (1 day).
For Surrogate-Control, Fastly supports the
For more information about controlling caching, see our Cache Control Tutorial.
Conditionally preventing pages from caching
To conditionally prevent pages from caching, follow the steps below.
- Log in to the Fastly web interface and click the Configure link.
- From the service menu, select the appropriate service.
- Click the Configuration button and then select Clone active. The Domains page appears.
- Click the Settings link. The Settings page appears.
Click the Create cache setting button to create a new cache setting. The Create a cache setting page appears.
- Create a new cache setting and then click the Create button. The new cache setting you created appears on the Settings page.
Click the Attach a condition link to the right of the newly created cache setting. The Create a new cache condition window appears.
In the Apply if field, create a condition that matches the URLs you want.
In this example, we created
req.url!~ "^/(cacheable|images|assets)"to set the condition to look for URLs containing
/assets. If the condition finds them, the URLs should be cached. If the condition doesn't find them, the cache setting that is set to
Passensures the URLs are explicitly not cached.
- Click the Save and apply to button.
- Click the Activate button to deploy your configuration changes.
TIP: You can use these steps to override default caching based on a backend response.