Routing traffic to Fastly
Fastly's global edge network is the first stop for users making requests to your website. Routing traffic to Fastly requires that the hostname requested by the end user resolves to a Fastly IP address, and that Fastly is able to serve a TLS certificate that is valid for that hostname.
You can also choose to use a Fastly-assigned domain or serve exclusively non-TLS (insecure HTTP) traffic. If neither of these applies to you, then routing traffic to Fastly on your own domain requires the following steps:
- Associate the domain with a Fastly service.
- Create a TLS configuration in your Fastly account (or use the default).
- Provision a TLS certificate for the domain you want to use.
- Update your DNS settings to activate the TLS certificate, and to direct traffic to Fastly.
Before you direct traffic to Fastly, it's important that we know which service owns the requested domain, so that incoming requests for that domain invoke the correct service. There are two ways to map inbound requests to a service: attaching domains explicitly (the most common), and an IP-to-service pin with dedicated IP.
Domains can be attached explicitly to a Fastly service using fastly domain create in the CLI, the create domain API endpoint or in the web interface. Fastly will use the
Host header to determine which hostname the end user is trying to reach and then invoke the service that has that hostname as an attached domain.
It is possible to attach wildcard domains to a service (e.g.,
*.example.com) which will cause any hostname that matches the pattern (e.g.,
accounts.example.com) to be handled by that service.
HINT: It's possible to determine the value of the
Host header on a request from inside a Fastly service configuration. In VCL services, this is exposed as
req.http.host, while in Compute services, all supported languages have SDK methods for reading inbound request headers. This can be useful where multiple domains are attached to the same service, but some element of the request handling should differ based on the hostname used for a particular request (common in the case of services with a large number of regional domains such as
Sometimes it is not possible to list all the domains that should invoke a particular service as attached domains on the service configuration. This is often the case for customers who operate hosting services where there might be thousands of domains associated with the same Fastly service, or where new domains are added and removed very frequently.
In these cases, it is possible to dedicate a set of Fastly IP addresses to a single service, causing that service to be invoked for every request arriving on those IPs, regardless of the value in the
Host header. Known as IP-to-service pinning, this feature allows you to direct traffic on any domain to your Fastly service without attaching the domain to the service. You will still require a TLS certificate on your account that's valid for any domain you want to use.
Dedicated IPs can also be useful in cases where a web property is 'zero rated' by internet service providers.
This feature must be provisioned for you by a Fastly employee. To learn more, contact firstname.lastname@example.org.
HINT: If the default TLS configuration satisfies your technical needs and you aren't using dedicated IPs, skip to provisioning certificates.
TLS configurations are associated with a set of IP addresses in Fastly's IP space and determine which features are supported by the connection. When you create a Fastly account, a TLS configuration will be created for you and shared by all the services you set up within your account. These automatically provisioned TLS configurations use shared IP address space; therefore, the settings cannot be edited. If you purchase a TLS service package, however, settings can be adjusted to your needs.
|Min TLS version||1.0-1.3||1.2||Offset|
|Max TLS version||1.0-1.3||1.3||Offset|
|IP version||IPv4 only|
IPv4 and IPv6
|IPv4 and IPv6||DNS name|
|Maximum billing zone||Global|
Each Fastly POP has many IP addresses, some of which will participate in various offsets, the Fastly term for a pool of IP addresses that can be used together in routing for a TLS configuration. TLS and HTTP versions are properties of the offset. Conversely, the IP version and maximum billing zone are controlled by DNS settings attached to a custom DNS name (e.g.,
mycompany.customer.fastly.net). These are all surfaced through the TLS configuration.
Maximum billing zones are subsets of Fastly POPs, grouped based on IP transit cost, as follows:
- MBZ100: This zone includes North America, Hawaii and European POPs only. They have the lowest egress charges.
- MBZ200: This zone includes all Fastly POPs except those in Africa, India, and South Korea where egress charges are highest.
- Global: This zone includes all POPs throughout Fastly's entire global network.
If you want Fastly to obtain and manage a certificate for you, create a TLS Subscription for each domain. You will need to verify ownership by adding a
CNAME DNS record to your domain's zone file with your DNS provider. This is the most common method for a small number of domains. To set up a TLS subscription, use the web interface or the TLS subscriptions API.
If you prefer to provide your own TLS certificates, we offer two options:
- Custom certificates: Included with all paid plans, and suitable for a small number of certificates. To set up custom certificates, use the web interface or the appropriate API endpoints.
- Platform TLS: Optimized for high-volume applications that require thousands of individual certificates. Platform TLS is available exclusively via the Fastly API and requires a plan upgrade.
With both Custom certificates and Platform TLS, you generate a private key and certificate using the certification authority (CA) of your choice and upload them to Fastly, then add the domains to specific TLS Configurations. If you do not upload the intermediates with your certificate, Fastly retrieves the necessary intermediate certs from the CA which has issued your certificate. You are responsible for certificate renewals and must ensure that replacement certificates are uploaded before the previous ones expire.
Regardless of the option you choose, all TLS certificates attach to your TLS configuration. This ensures that the IPs we assign to you are configured based on the preferences associated with the TLS configuration and also ensures that these IPs host a valid TLS certificate for the domains you intend to use.
Configure your domain's DNS settings with the CNAME or the anycast IPs associated with the domain's associated Fastly TLS configuration. Fastly does not provide a managed DNS service. Instead, we list a set of DNS records on your TLS configuration, allowing you to select the DNS provider of your choice.
The DNS settings that you need can be found displayed as part of the TLS configuration in the web interface and are also returned by the API (see TLS configurations).
Each TLS configuration will provide three types of DNS records: A CNAME, a set of IPv4 A records, and a set of IPv6 A records.
- CNAME hosts: The preferred method of connecting a domain to Fastly,
CNAMErecords allow for both IPv4 and IPv6 support in one record and enable smart routing powered by Fastly Insights for non-apex domains (e.g.,
www.example.com). The CNAME host you see listed on your TLS configuration may take a number of forms, including:
<something>.customer.fastly.net: A DNS name specific to your account, the most flexible type of DNS configuration.
<something>.map.fastly.net: A name assigned by Fastly to enable you to use a non-default TLS configuration. May be shared by multiple customers.
<something>.shared.global.fastly.net: One of a set of DNS names that offer commonly used combinations of TLS configuration settings and are shared by a large number of customers.
- Anycast IPv4 and anycast IPv6: A set of IPv4 and IPv6 IP addresses that may be installed as the DNS
AAAArecords for apex domains (e.g.,
example.com). When using anycast IPs, connections select a Fastly POP based on routing decisions made outside of Fastly and over which Fastly has less ability to direct traffic for best performance.
IMPORTANT: If your TLS configuration supports HTTTP/3, consult the Supporting HTTP/3 section below to learn how to advertise HTTP/3 support in your service.
When someone types
www.example.com into their web browser and presses enter, the name
www.example.com needs to be translated into an IP address. If a
CNAME is configured for that domain, then the CNAME will allow a Fastly authoritative name server to answer the DNS query by taking advantage of a vast store of data collected by the Fastly insights program, to route the user to the POP that offers the most consistently high performance for that specific end user. The IP the client eventually receives will usually be a unicast address specific to a single POP location.
Conversely, if an anycast
AAAA record is configured, then the client will receive the anycast IP, which is advertised by multiple Fastly POPs. Standard internet routing will take the user to a nearby POP.
NOTE: Anycast is required for apex domains (e.g.,
example.com) because they do not support
CNAMEs in DNS. Some DNS providers offer an
ALIAS record type or other mechanism that attempts to provide a
CNAME-like behavior on apex domains. Fastly recommends against using these solutions because they often result in inferior performance or interfere with the ability of records to update automatically.
Once you have obtained the CNAME, A, and AAAA records listed on your TLS configuration, determine whether your domain is an apex or not. If it is an apex domain like
example.com, add the A and AAAA records to your DNS provider (use the values you get from your TLS configuration, not the example addresses shown below):
example.com. 3600 IN A 18.104.22.168example.com. 3600 IN A 22.214.171.124example.com. 3600 IN A 126.96.36.199example.com. 3600 IN A 188.8.131.52example.com. 3600 IN AAAA 2a04:4e42::729example.com. 3600 IN AAAA 2a04:4e42:200::729example.com. 3600 IN AAAA 2a04:4e42:400::729example.com. 3600 IN AAAA 2a04:4e42:600::729
Otherwise, if the domain is not an apex (e.g.,
www.example.com), add the one
CNAME record instead (use the value you get from your TLS configuration, not the example address shown below):
www.example.com. 3600 IN CNAME dualstack.e.sni.global.fastly.net.
Your DNS provider may have an application or web interface that prompts for these items individually. In this example,
www.example.com) are the hostname;
3600 is the TTL (in seconds);
CNAME are the record type; and the address at the end of the line is the value (an IP address in the case of
AAAA records, and a hostname in the case of
HINT: If your domain's existing DNS records have a large TTL value (e.g., 86400), it may take a long time for all traffic to migrate over to Fastly when you change the DNS. One way to avoid this and to achieve a faster migration is to lower the TTL on the existing record (e.g., to 60), wait for a period equal to the longer TTL, and then update the record to point to Fastly. Then all traffic should migrate within 60 seconds. We recommend you set the TTL on your new Fastly records initially to a low value to enable rapid rollback but, following a successful migration, consider increasing it to an hour or more.
To test that your DNS provider is correctly serving the new DNS records, you can use the dig tool in a terminal:
$ dig www.example.com +shortdualstack.e.sni.global.fastly.net.184.108.40.206
This will query your local DNS resolver. To check results from multiple points around the internet, consider using a third-party tool such as OpenDNS's Cache Check.
To serve exclusively non-TLS traffic, specific TLS configuration is not required. Use the following DNS names to direct traffic to Fastly:
|Billing region||CNAME||Anycast IPv4||Anycast IPv6|
|US and Europe||220.127.116.11|
Non-SSL hosts refuse TLS traffic and accept only HTTP/1.1. They are not compatible with HTTP/2 or HTTP/3 (QUIC), both of which require TLS as a prerequisite.
If you wish to use a Fastly-assigned domain instead of your own, you can direct traffic to your service without performing any TLS or DNS setup.
For Compute services, add a domain to your service of the form
example.edgecompute.app). This domain will immediately receive traffic and route it to your service.
edgecompute.app domains do not support insecure HTTP traffic and are configured to support HTTP/2 and global distribution across our network.
|Domain||Billing region||HTTP/2 ?||TLS versions||IPv6?|
For VCL services, you can append
.global.prod.fastly.net to any domain name associated with your service to get a hostname that will direct traffic to your service immediately. For example, if your service has the domain
example.com, then requests to
example.com.global.prod.fastly.net will be handled by your service. However, this method does not support TLS.
For TLS support, explicitly add a domain to your service of the form
example.global.ssl.fastly.net). Once configured, this enables access to the service via two hostnames with different TLS configurations.
|Domain||Billing region||HTTP/2 ?||TLS versions||IPv6?|
|Global||No||1.0, 1.1, 1.2||No|
Note that it is not possible to attach a domain ending
...freetls.fastly.net directly to a VCL service, but it is enabled automatically as a result of adding a domain ending with
Fastly supports HTTP/3, which is currently the fastest, most reliable protocol for serving content on the web. If your TLS configuration supports H3, compatible clients can use it to connect to your Fastly service. However, even clients that support H3 will initially connect using an earlier HTTP version and only switch to HTTP/3 if the server offers an upgrade via the
Alt-Svc HTTP header. You must serve that header as part of your edge logic. In VCL services, you can do this by calling the
h3.alt_svc function in
vcl_recv, while in Compute services you must add the full header text to the response:
- Fastly VCL
HINT: To test that your browser or other HTTP client supports HTTP/3, navigate to https://http3.is and the resulting page will let you know whether or not HTTP/3 was successfully used to request the page.
Even if your site and the client browser are correctly configured, the first request from the client will always use a lower version of HTTP because it has not yet seen the
Alt-Svc header in a response. If you don't see the HTTP/3 success page on your first request, be sure to perform a reload in the browser to give it an opportunity to use HTTP/3 for subsequent requests.
The following VCL variables provide information about HTTP/3 connections: