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@Edge 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.
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 email@example.com.
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 US 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.
Once Fastly starts hosting a TLS certificate for the domain you plan to use, that domain's DNS settings can be updated to return either the CNAME or the anycast IPs associated with the TLS configuration. Fastly does not provide a managed DNS service. Instead, we list a set of DNS records against 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 you intend to support HTTP/3 before it enters general availability, ensure that your TLS configuration is HTTP/3-enabled. See Supporting HTTP/3 for details.
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 220.127.116.11example.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 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.188.8.131.52
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||184.108.40.206|
Non-SSL hosts refuse TLS traffic and accept only HTTP/1.1. They are not compatible with HTTP/2 or 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@Edge 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
WARNING: This information is part of a limited availability release. Portions of this API may be subject to changes and improvements over time. Fields marked deprecated may be removed in the future and their use is discouraged. For more information, see our product and feature lifecycle descriptions.
Fastly supports HTTP/3 on client connections for the purposes of limited customer testing.
Like HTTP/2, HTTP/3 allows clients to reuse connections between different domains as long as the domains are on the same TLS certificate, a mechanism sometimes referred to as "connection coalescing." To restrict your HTTP/3 testing to just some of your Fastly-hosted domains, and guarantee your intended domain separation will be honored by end user clients:
- create a new Fastly service specifically dedicated to the domains with which you will be testing HTTP/3.
- configure that dedicated test service to support HTTPS for end user connections. See use a TLS configuration for details.
- use a unique and valid TLS certificate dedicated only to the domains you will be using for HTTP/3 testing.
- ask your Fastly contact or firstname.lastname@example.org to enable HTTP/3 on your TLS configuration.
You can now update the DNS records of your HTTP/3 test domains with the DNS records provided in the TLS configuration, so that requests to them are routed to your Fastly HTTP/3 test services.
Even though these routes support HTTP/3, clients 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
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: