- 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
- Large File Support
- Logging purge requests
- Making query strings agnostic
- Purging API cache with surrogate keys
- Request collapsing
- 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
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
Connecting to origins
Last updated July 09, 2019
To communicate with your origin servers, you can add and edit a host.
Adding a host
To add a host, 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 Origins link. The Origins page appears.
Click the Create a host button. The Hosts field appears.
- Fill out the Hosts field by typing the hostname or IP address of your origin server. Entering a hostname automatically enables Transport Layer Security (TLS) and assigns port 443. Entering an IP address disables TLS and assigns port 80.
- Click Add to add your host.
Editing a host
After you've created your host, you can edit the host's details by following the steps below:
In the Hosts area, click the pencil icon next to the host you want to edit. The Edit this host page appears.
Fill out the Edit this host fields as follows:
- In the Name field, type the name of your server (for example,
My Origin Server). This name is displayed in the Fastly web interface.
- In the Address field, type the IP address (or hostname) of your origin server.
See Understanding the difference between certificate hostname and SNI hostname values for more information about hostnames.
- In the Name field, type the name of your server (for example,
Fill out the Transport Layer Security (TLS) area as follows:
- Leave the Enable TLS? default set to Yes if you want to enable TLS to secure the connection between Fastly and your origin. To enable TLS, a valid SSL certificate must be installed on your origin server and port 443 (or the specified port) must be open in the firewall. You can select No if you do not want to use TLS.
Leave the Verify certificate? default set to Yes if you want to verify the authenticity of the TLS certificate. Selecting No means the certificate will not be verified.
WARNING: Not verifying the certificate has serious security implications, including vulnerability to man-in-the-middle attack. Consider uploading a CA certificate instead of disabling certificate validation.
- In the Certificate hostname field, type the hostname associated with your TLS certificate. This value is matched against the certificate common name (CN) or a subject alternate name (SAN) depending on the certificate you were issued.
- If you are specifying an SNI hostname, see the section below.
- If you are specifying a TLS CA certificate, see the section below.
Fill out the remaining Create a host fields as follows:
- From the Shielding menu, optionally select a POP to enable the shielding feature. For more information, see our guide on shielding.
- From the Health check menu, optionally select a health check for this origin server. For more information, see our guide on working with health checks.
- From the Auto load balance menu, optionally select Yes to enable load balancing for this origin server. For more information, see our guide on load balancing.
- If you enabled load balancing, type a weight in the Weight field.
- Click the Advanced options link and decide which of the optional fields to change, if any:
- In the Maximum connections field, optionally type the maximum number of connections for your backend. The default limit is 200 connections per cach node to protect your origins from being overloaded.
- In the Error threshold field, optionally type the number of errors allowed before an origin is considered down.
- In the Connection timeout field, optionally type how long, in milliseconds, to wait for a connection timeout. The default is 1000 milliseconds.
- In the First byte timeout field, optionally type how long, in milliseconds, to wait for a first byte timeout. The default is 15000 milliseconds.
- In the Between bytes timeout field, optionally type how long, in milliseconds, to wait between bytes. The default is 10000 milliseconds.
- In the Override host field, optionally type the hostname of your override host header based on the origin you’re using. The value in this field will take precedence over anything you've set using the override host quick configuration. Keep in mind the following:
- If you're using Amazon S3 as your origin, type
- If you're using Google Cloud Storage as your origin, type
<your bucket name>.storage.googleapis.com.
NOTE: To override the incoming host header on your origin using your Fastly service, refer to the Specifying the override host guide.
- If you're using Amazon S3 as your origin, type
- Click the Update button.
- Click the Activate button to deploy your configuration changes.
And that's all you need to do. Everything else is optional, but just in case you'd like to set them, we've included the information below.
Setting the TLS hostname
Normally we check the server certificate against the hostname portion of the address for your origin entered in the Create a host window. Checking the certificate is done by using the value of the Certificate Hostname field in your origin TLS settings. To have Fastly verify the certificate using a different hostname, specify it via the SNI Hostname field under Advanced options.
This information also gets sent to the server in the TLS handshake. If you are using Server Name Indication (SNI) to put multiple certificates on your origin, specifying it in the SNI Hostname field will select which one is used.
Understanding the difference between certificate hostname and SNI hostname values
The following explains the difference between a certificate and SNI hostname value:
The certificate hostname (ssl_cert_hostname). This hostname validates the certificate at origin. This value should match the certificate common name (CN) or an available subject alternate name (SAN). It displays as ssl_cert_hostname in VCL. This doesn't affect the SNI certification. You can set this value in Certificate hostname field of the TLS options page.
The SNI hostname (ssl_sni_hostname). This hostname determines which certificate should be used for the TLS handshake. SNI is generally only required when your origin is using shared hosting, such as Amazon S3, or when you use multiple certificates at your origin. SNI allows the origin server to know which certificate to use for the connection. This value displays as ssl_sni_hostname in VCL. This doesn't affect the certificate validation.
If you don't enter an actual value in your certificate hostname, the .host value is used by default to verify the certificate. The .host value is the actual IP address or virtual hostname you enter in the Address field on the Host area of the Origins page. This value is matched against the certificate common name (CN) or a subject alternate name (SAN).
The table below shows you what happens when you set the Certificate and SNI hostname values in the TLS settings:
|If Certificate hostname contains…||and SNI hostname contains…||then the Certificate Validation value will be…||and the SNI value will be…|
|nothing||www.example.org||the .host value from the Address field||www.example.org|
|nothing||nothing||the .host value from the Address field||nothing|
About the ssl_hostname value (deprecated). The ssl_hostname value has been deprecated and replaced with ssl_cert_hostname and ssl_sni_hostname. Use these two values instead.
IMPORTANT: If you use an IP address for your .host value (i.e., by not entering a value in your certificate hostname), this will generate an error where the certificate hostname specified in your service's origin TLS settings doesn't match either the Common Name (CN) or available Subject Alternate Names (SANs).
Using a wildcard certificate
If you're using a wildcard certificate, you can use any name that matches the wildcard certificate. The table below shows a variety of possible combinations of certificate and SNI hostnames that could be used with a wildcard certificate for
|Certificate hostname||SNI hostname|
If you set the certificate hostname to
*.example.com, Fastly will treat it as a literal. When using that as the certificate hostname,
*.example.com is the only option for the SNI hostname.
Specifying a TLS CA certificate
If you're using a certificate that is either self-signed or signed by a Certificate Authority (CA) not commonly recognized by major browsers (and unlikely to be in the Ubuntu bundle that we use), you can provide the certificate in PEM format via the TLS CA certificate field. The PEM format looks like this:
Specifying a TLS client certificate and key
To ensure TLS connections to your origin come from Fastly and aren't random, anonymous requests, set your origin to verify the client using a client certificate. Simply paste the certificate and private key in PEM form into the appropriate text boxes on the TLS options page.
IMPORTANT: The private key must not be encrypted with a passphrase.
Then configure your backend to require client certificates and verify them against the CA cert they were signed with. Here are some ways of doing that:
Specifying acceptable TLS protocol versions
If your origin server is configured with support for modern TLS protocol versions, you can customize the TLS protocols Fastly will use to connect to it by setting a Minimum TLS Version and Maximum TLS Version under Advanced options. We recommend setting both to the most up-to-date TLS protocol, currently 1.2, if your origin can support it.
openssl command to verify your origin supports a given TLS protocol version. For example:
openssl s_client -connect origin.example.com:443 -tls1_2
tls1_0 to test other protocol versions. Fastly does not support SSLv2 or SSLv3.
IMPORTANT: In line with security best practices, Fastly recommends enabling servers with version 1.2 of the TLS protocol by default. For backend connections from our edge nodes to customer origins, Fastly supports TLS 1.2, 1.1, and 1.0 depending on the versions of the protocol in use on the origin server. Fastly will continue to support TLS 1.0 based on the ServerHello message as described in RFC 5246 if the server selects TLS 1.0 as the highest supported version.
Specifying acceptable TLS cipher suites
Fastly supports configuring the OpenSSL cipher suites used when connecting to your origin server. This allows you to turn specific cipher suites on or off based on security properties and origin server support. The Ciphersuites setting under Advanced options accepts an OpenSSL formatted cipher list. We recommend using the strongest cipher suite your origin will support as detailed by the Mozilla SSL Configuration Generator.
openssl command to verify your origin supports a given cipher suite. For example:
openssl s_client -connect origin.example.com:443 -tls1_2 -cipher ECDHE-RSA-AES128-GCM-SHA256
-cipher ECDHE-RSA-AES128-GCM-SHA256 with the cipher suite to test.