Drupal's `trusted_host_patterns` setting controls which hostnames the site accepts. After a domain change, update this array in `sites/default/settings.php` or the included settings file that defines it. Each entry is a regular expression, not a plain hostname. If the new domain does not match any entry, Drupal can reject the request with a trusted-host error before serving the site.
Table of Contents
- Where to change the allowed hostnames
- Which hostname variants should be included?
- Why Drupal rejects the new domain
- How to apply and test the change safely
- Settings that do not solve this error
- Frequently Asked Questions
Where to change the allowed hostnames
Find the active `$settings['trusted_host_patterns']` declaration. A typical configuration for `example.com` looks like this: “`php $settings['trusted_host_patterns'] = [ '^example\.com$', '^www\.example\.com$', ]; “` Replace the old domain with the new one.
Escape each literal dot as `\.` and use `^` and `$` to require an exact hostname match. Drupal projects sometimes split configuration across `settings.php`, `settings.local.php`, hosting-platform files, or environment-specific includes. Check later assignments because they can replace an array defined earlier.
Which hostname variants should be included?
Allow only hostnames that must reach Drupal. The bare domain and its `www` version are separate hosts, so list both when the site uses both. “`php $settings['trusted_host_patterns'] = [ '^newsite\.com$', '^www\.newsite\.com$', '^staging\.newsite\.com$', ]; “` Do not add staging, preview, load-balancer, or internal hostnames unless they legitimately send requests to the site.
DNS records and web-server aliases do not automatically add hosts to Drupal's trusted list. If every first-level subdomain must work, a controlled wildcard pattern can cover them: “`php '^([a-z0-9-]+\.)?newsite\.com$', “` That pattern accepts `newsite.com` and one subdomain such as `www.newsite.com`. Explicit entries remain easier to audit when only a few hosts are required.
Why Drupal rejects the new domain
The browser sends the requested hostname in the HTTP `Host` header. Drupal compares that value with `trusted_host_patterns` to reduce the risk of hostile or unexpected host headers influencing generated URLs and other request handling. A domain migration can update DNS, TLS certificates, redirects, and web-server configuration while leaving Drupal's host allowlist unchanged.
The request reaches the application, but Drupal refuses it because the new hostname fails the configured pattern. The setting matches hostnames, not full URLs. Do not include `https://`, a path, or a trailing slash:.
- Correct: `^example\.com$`
- Incorrect: `https://example.com/`
- Incorrect: `example.com/blog`
How to apply and test the change safely
Update the configuration through the project's normal deployment process. Avoid weakening the pattern simply to make the error disappear.
The PHP syntax must remain valid. A missing comma, quote, or bracket can cause a PHP error instead of a trusted-host error.
- Back up the current settings file or commit the change in version control.
- Add the production hostname and any required variants.
- Confirm that no later settings file overwrites the array.
- Deploy the change and rebuild Drupal's caches if the error persists.
- Test the canonical domain, redirects, and any approved staging hostname.
Settings that do not solve this error
Changing Drupal's site name, front-page path, base URL in contributed code, or search-engine settings does not update the trusted-host allowlist. DNS decides where a hostname points, while `trusted_host_patterns` decides whether Drupal accepts that hostname. Web-server configuration still matters.
Apache, Nginx, a reverse proxy, or a hosting platform must route the new domain to the correct Drupal installation before Drupal can evaluate it. Redirects also need careful ordering. Drupal must accept the incoming old hostname if Drupal itself performs the redirect. If the web server or proxy redirects the old domain before PHP runs, Drupal does not need to trust that old hostname.
Frequently Asked Questions
Should the old domain remain in `trusted_host_patterns`?
Keep it only if requests using the old hostname must reach Drupal, such as when Drupal handles the redirect. Remove it after that need ends.
Does the pattern include the port number?
Configure the hostname pattern rather than a full URL. Ports are handled separately from the trusted hostname comparison.
Is `.*` a suitable temporary fix?
No. A broad match defeats the purpose of restricting accepted hostnames; add exact production and staging patterns instead.
