Specifying an override host

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, if the domain your origin is expecting is different than one specified in your Fastly service, or if the Host header being sent to your origin is different from the Host used in the initial request. 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 or by specifying a host on the Origins page for a specific Host.

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.com must be re-written to <BUCKET>.s3.<REGION>.amazonaws.com, or else the request is denied.

  • You have a service that contains three sites: www.abc.com, www.myexample.com, and www.mysite.com and 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.abc.com, www.myexample.com, or www.mysite.com returns content from origin.example.com.

Overriding a host at the origin level

You can add an override Host per origin if you're using an origin that requires a specific hostname to be passed to it. Once you’ve added a host, follow the steps below:

  1. Log in to the Fastly web interface.
  2. From the All services page, select the appropriate service. You can use the search box to search by ID, name, or domain.
  3. Click the Edit configuration button and then select the option to clone the active version. The Domains page appears.
  4. Click the Origins link. The Origins page appears.
  5. In the Hosts area, click the pencil icon next to the Host you want to edit. The Edit this Host page appears.
  6. Towards the bottom of the Edit this host page, click the Advanced options link.
  7. In the Override host field, enter 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 global override Host configuration. For example:

    • If you're using Amazon S3 as your origin, enter <BUCKET>.s3.<REGION>.amazonaws.com.
    • If you're using Google Cloud Storage as your origin, enter <BUCKET>.storage.googleapis.com.
  8. Click the Update button. The new override Host appears under the Show all details field of the Override host section and a code block is added to the origin definition in your VCL that will look similar to the following:

    1
    2
    3
    4
    5
    6
    
       Backend F_Host_1 {
          .host = "..."; # IP or hostname
          .host_header = "example.com";
          .always_use_host_header = true;
           ...
        }
    
  9. Click the Activate button to deploy your configuration changes.

Overriding a host globally

You can globally override a Host if your service has multiple domains to serve but they are all same assets (e.g., assets1.example.com and assets2.example.com) and you want to normalize them (e.g., assets.example.com). To globally override a host, follow the steps below:

  1. Log in to the Fastly web interface.
  2. From the All services page, select the appropriate service. You can use the search box to search by ID, name, or domain.
  3. Click the Edit configuration button and then select the option to clone the active version. The Domains page appears.
  4. Click the Settings link. The Settings page appears.
  5. Click the Override host switch. The Override host header field appears.

    Setting Override host

  6. In the Override host header field, enter the hostname of your override Host based on the origin you are using:
    • If you are using Amazon S3 as your origin, enter <yourbucket>.s3.amazonaws.com.
    • If you are using Google Cloud Storage as your origin, enter <your bucket name>.storage.googleapis.com.
  7. Click the Save button. The new override host header appears in the Override host section.
  8. Click the Activate button to deploy your configuration changes.

Caveats about using the global 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.

  • 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.

Back to Top