What does "The provided host name is not valid for this server" mean?

I encountered this problem on a Debian Apache2 host after installing Drupal 9 with composer. Adding the trusted host line did not resolve the issue.

Instead, what I had to do was add a ServerAlias directive in my Apache2 config. Adding a site alias was mentioned in the comments of the accepted answer, but since that is a little buried, I wanted to post this answer here for anybody who was coming to this issue who still had problems.

$ head /etc/apache2/sites-enabled/unleashed.conf
<VirtualHost *:80>
    ServerName unleashed.local
    ServerAlias unleashed.local
    ServerAdmin webmaster@host
    ...

This happens because trusted_host_patterns variable in your settings file. If you're working on the local environment and you want to override this, define the following section in your settings.local.php file:

/*
 * Drupal Trusted Host Patterns
 */
$settings['trusted_host_patterns'] = [];

Or more generic pattern:

$settings['trusted_host_patterns'] = [ '.*' ];

Or more specific for the local environments:

$settings['trusted_host_patterns'] = array(
  '^172.20..3$',
  '^localhost$',
);

It's the simplest solution, but not recommended as you should set the proper values to avoid spoofing the HTTP Host header for nefarious purposes. If your website is running only on your local, then you should be fine.

See: New setting for trusted hostname configuration.

This error message is coming from a feature that was added to Drupal 8 to protect against HTTP Host header attacks. The feature is also described in the change record that was generated for the patch.

Essentially, it was possible to spoof the HTTP Host header for nefarious purposes, and trick Drupal into using a different domain name in several subsystems (particularly link generation). In other words, the HTTP Host header needs to be considered user input, and not trusted.

To combat this, a new setting, $settings['trusted_host_patterns'], was added to Drupal 8 to configure a list of "trusted" hostnames that the site can run from. The setting needs to be an array of regular expression patterns, without delimiters, representing the hostnames you would like to allow to run from.

For example, if you are running your site from a single hostname "www.example.com", then you should add this to your settings (usually found at ./sites/default/settings.php):

$settings['trusted_host_patterns'] = array(
  '^www.example.com$',
);

Note the ^, ., and $. These are PCRE Syntax. These just mean that you want to match "www.example.com" precisely, with nothing extra at the beginning and end, and that the dots should be treated as dots and not wildcard characters.

If you are running from "example.com", then just use:

$settings['trusted_host_patterns'] = array(
  '^example.com$',
);

If you need to run a site of multiple domains and/or subdomains, and are not doing canonical URL redirection, then your setting would look something like this:

$settings['trusted_host_patterns'] = array(
  '^example.com$',
  '^.+.example.com$',
  '^example.org',
  '^.+.example.org',
);

This allows the site to run off of all variants of example.com and example.org, with all subdomains included.

Once you adjust $settings['trusted_host_patterns'] to the proper value, you should be able to browse to your site again.

You can also check on the status of your trusted host settings from the status report page, which is at admin/reports/status

If you remove the setting altogether, the trusted host mechanism will not be used, and you will see an error on the status report page. In addition, your site may also be vulnerable HTTP Host header attacks.

If you have this setting configured and are seeing this message, then it probably means you have messed up the regular expression syntax. In this case, take the first example, and copy/paste into your settings, and then edit it to reflect the hostname your site runs from.