What this error means
Drupal returns this message when the HTTP Host header does not match the configured trusted host patterns. It is an application host-security check, so a domain can resolve correctly and still be rejected by Drupal. The browser or proxy message describes the symptom, not necessarily the root cause. HostWithShery therefore checks the application host configuration evidence that can be observed publicly before recommending a configuration change.
Most likely causes
These are the first explanations to test because each can produce this exact symptom. Treat them as hypotheses until the matching public evidence is present.
- The apex or www hostname is missing from trusted_host_patterns — Verify the apex or www hostname is missing from trusted_host_patterns from the public Internet and compare it with the value the responsible provider says should be live.
- A newly added domain was not added to the Drupal trusted-host configuration — Verify a newly added domain was not added to the Drupal trusted-host configuration from the public Internet and compare it with the value the responsible provider says should be live.
- A manually defined trusted-host list overrides platform-managed values — Verify a manually defined trusted-host list overrides platform-managed values from the public Internet and compare it with the value the responsible provider says should be live.
- A reverse proxy forwards a Host value different from the expected public hostname — Verify a reverse proxy forwards a Host value different from the expected public hostname from the public Internet and compare it with the value the responsible provider says should be live.
What to check on your domain
Use the embedded scan to compare the failing layer with adjacent layers that can produce the same visible error. This prevents a DNS change from being used to “fix” a TLS problem, or an SSL-mode change from masking an origin failure.
- The apex or www hostname is missing from trusted_host_patterns — Verify the apex or www hostname is missing from trusted_host_patterns from the public Internet and compare it with the value the responsible provider says should be live.
- A newly added domain was not added to the Drupal trusted-host configuration — Verify a newly added domain was not added to the Drupal trusted-host configuration from the public Internet and compare it with the value the responsible provider says should be live.
- A manually defined trusted-host list overrides platform-managed values — Verify a manually defined trusted-host list overrides platform-managed values from the public Internet and compare it with the value the responsible provider says should be live.
- A reverse proxy forwards a Host value different from the expected public hostname — Verify a reverse proxy forwards a Host value different from the expected public hostname from the public Internet and compare it with the value the responsible provider says should be live.
- Confirm the exact hostname producing the 400 response — Record the public status, final URL and relevant response headers. A working DNS answer does not prove that the application is serving a genuine website response.
Fixes in the recommended order
Change the smallest confirmed layer first. Preserve working DNS and mail records, document the current value, apply one repair, and then retest before moving to the next possibility.
- 1. Confirm the exact hostname producing the 400 response. Confirm the public result after this step before making another unrelated change.
- 2. Compare it with the trusted_host_patterns in the active Drupal settings. Confirm the public result after this step before making another unrelated change.
- 3. Add only the intended hostname pattern with correctly escaped dots and anchored regular expressions. Confirm the public result after this step before making another unrelated change.
- 4. If a managed platform owns trusted-host configuration, follow its current platform-specific domain process before editing settings manually. Confirm the public result after this step before making another unrelated change.
Why DNS can look healthy while Drupal still rejects the request
Drupal trusted-host validation happens after the request reaches the application. A correct A/AAAA/CNAME answer and valid TLS certificate therefore do not prove Drupal will accept the Host header. Confirm the public network layer, then inspect the active trusted_host_patterns rather than repeatedly editing DNS.
Safer trusted-host patterns
Allow the real production hostnames you operate rather than using an unrestricted catch-all. Drupal documents trusted_host_patterns as regular expressions, so dots in a hostname must be escaped and start/end anchors help avoid accidentally matching unintended hosts.
How to confirm the repair
The same public test that exposed the problem should now return a healthy result, without creating a new DNS, TLS, mail or redirect regression.
If the error remains
Capture the checked hostname, exact timestamp, final DNS addresses, redirect/TLS result and the failing public status before escalating. That evidence gives a hosting or provider support team something testable instead of only the browser message. If results differ by resolver or network, include those differences rather than assuming the failure is universal.
What not to change
Do not replace nameservers, delete unrelated mail records, disable security controls, remove IPv6 blindly or purge the entire configuration merely because this message appears. Diagnose the failing layer first; broad changes can turn one isolated fault into several independent faults.
Technical references
These primary standards and provider documents are used to verify the behavior described on this page. Provider dashboards can change, so use the current official value for tenant-specific DNS records rather than copying an example from another account.