If you want to rewrite the host header being sent to your origin regardless of the host used in the initial request, specify an override host. Use this if you have multiple domains tied to a service and want them all served by the same origin, or if the domain your origin is expecting is different than one specified in your Fastly service. You most likely won't need to use this feature.
You can override the host header being sent to your origin by specifying the domain name of your override host on the Settings page for a specific service.
Here are some examples of when to use an override host:
When using backends such as Amazon S3, Google Cloud Storage, or Heroku, you want to ensure you use the proper host header so these providers know how to route requests directly to your content. Each provider uses the host header to associate requests with your account's storage location. For example, if you set up your origin using Amazon S3, you send the name of your S3 bucket as your host header. Amazon is set up so that it only accepts host headers that have the same name as the bucket hosting your content. A request to
your-domain.commust be re-written to
<your-bucket>.s3.amazonaws.com, or else the request is denied.
You have a service that contains three sites:
www.mysite.comand you have one origin. You can have the same origin respond to each domain by overriding the host header to one accepted by your origin, for example,
origin.example.com. The result will be that a request to
www.mysite.comreturns content from
Overriding a host
- 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 Override host switch. The Override host header field appears.
- In the Override host header field, type the hostname of your override host based on the origin you are using:
- Click the Save button. The new override host header appears in the Override host section.
- Click the Activate button to deploy your configuration changes.
Caveats about using the override host
There are situations when you may not want to use an override host:
Forcing TLS and enabling HSTS. You may experience problems if you enable this setting along with the force TLS and enable HSTS setting. Instead of enabling this setting, create a new request setting and specify the override host in the advanced options.
Using multiple origins. When you specify a host override, you're specifying what hostname is actually sent to your origin. If you have a service with two different origins and each origin requires a different hostname, specifying a host override for all requests results in one origin not returning valid responses. If you specify a default hostname that matches only one of the origins, then no content is returned from the other origin requests.
NOTE: If you want to serve content from multiple backends, you should conditionally route to them. Refer to Routing assets to different origins for more information.
Shielding is enabled. If you enable a host override along with shielding and the specified override host doesn't match to a domain within the service, the shield won't route the request properly and an error of 500 is expected. Refer to Shielding for more information.