Fix the Sonarr/Radarr Allowed Hosts warning

What the Allowed Hosts warning means

Sonarr and Radarr show "Allowed Hosts is not configured" when two things are true: the Allowed Hosts field in Settings > General is empty, and Authentication Required is not set to Enabled. To fix it, type every hostname and IP address you use in the browser to reach the app into Allowed Hosts, separated by commas, then restart the app. If you would rather keep accepting any hostname, set Authentication Required to Enabled instead. That also clears the warning.

The exact text in Sonarr is:

Allowed Hosts is not configured, Sonarr will accept requests for any hostname or IP address. Set Allowed Hosts in General settings to restrict which hostnames can be used to reach Sonarr.

Radarr's version is shorter. It ends at "will accept requests for any hostname" and then gives the same instruction. The setting, the check and the fix are the same in both apps.

The risk in this setting is locking yourself out. As soon as the list holds one entry, every name that is not on the list is refused. The sections below show what to enter for each common setup, and how to get back in if you got it wrong.

Which Sonarr and Radarr release added Allowed Hosts?

Both apps got the feature from the same upstream change, titled "New: Add hostname validation". In Sonarr it landed on the v4.0.19 pre-release channel in late August 2026 and reached the stable channel in v4.0.20.3014 on 16 September 2026. In Radarr it first shipped in the 6.4.3.10645 pre-release on 31 August 2026, and reached stable in 6.4.4.10685 on 16 September 2026.

A second change followed: "Don't skip health check if Allowed Hosts is set to *". It shipped in Sonarr v4.0.19.3011 and Radarr 6.4.4. Before it, a bare * in the list silenced the warning. Now the check treats * the same as an empty field. If you cleared the warning with * in early September and it came back after an update, this is the reason.

What does Allowed Hosts protect against?

Every HTTP request carries a Host header. It holds the name the client used to reach the server, such as sonarr.example.com or 192.168.1.50. Sonarr and Radarr now pass every request through the host filtering middleware that ships with ASP.NET Core, the web framework they are built on. The middleware compares the Host header with your list. It removes the port first and ignores upper and lower case. A request whose host is not on the list gets HTTP status 400 and a short page that says:

Bad Request - Invalid Hostname
HTTP Error 400. The request hostname is invalid.

This happens before the login page and before the API key check, so it applies to the web interface and to the API alike.

Upstream calls the feature "hostname validation". The commit does not name a specific attack. A host allowlist of this kind is the standard defence against DNS rebinding. In that attack, a web page you visit makes its own domain name resolve to a private address on your network. Your browser then sends requests to your Sonarr, but the Host header still carries the attacker's domain name. A list that holds only your own names refuses those requests.

The code only raises the warning when Authentication Required is not Enabled, which in practice means "Disabled for Local Addresses". That matches the attack. In that mode, a request that comes from your own browser on your own network reaches Sonarr with no password at all.

What values does Allowed Hosts accept?

The rules below come from the parser in the Sonarr and Radarr source.

• Separate entries with commas. Semicolons also work. Spaces around an entry are trimmed.
• An entry can be a hostname, an IPv4 address, or an IPv6 address. A bare IPv6 address such as ::1 is wrapped in brackets for you.
• *.example.com matches any subdomain, such as sonarr.example.com. It does not match example.com itself, so list the bare domain separately if you use it.
• Do not add a port or a scheme. Write sonarr.example.com, not https://sonarr.example.com:443. The port is removed from the Host header before the comparison, so a plain name already matches sonarr.example.com:8989.
• Subnets in CIDR (classless inter-domain routing) notation, such as 192.168.1.0/24, are not valid. List each address you use.
• An empty field means every host is accepted.

When the list holds at least one entry, the app adds some names on its own: localhost, 127.0.0.1, [::1] and the machine name of the server. You never need to type these, and you cannot lock them out.

The settings page also enforces one rule on save. When Authentication Required is not Enabled, an empty Allowed Hosts field is rejected with this message:

Allowed Hosts is required when 'Authentication Required' is not 'Enabled'

This means you may meet the field while trying to save a different setting on the General page. A change to Allowed Hosts only takes effect after a restart, and the interface asks you to restart after you save.

Setup 1: LAN access by IP address

You open http://192.168.1.50:8989 on a laptop at home. The browser sends Host: 192.168.1.50:8989, and the port is removed, so the entry you need is the address alone. If you also reach the box by a local name, add that name too.

192.168.1.50, mediabox.lan

On a native install, the machine name of the server is allowed already. In Docker it is not, because the machine name inside a container is the container's own hostname. That is a random ID unless you set hostname: in your compose file. If you are unsure which port belongs to which app, the default ports for every app in the arr stack lists them.

Setup 2: behind a reverse proxy on a domain

Here the answer depends on the Host header the proxy sends to Sonarr. A common nginx block looks like this:

location / {
    proxy_pass http://127.0.0.1:8989;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
}

The proxy_set_header Host $host; line forwards the domain the browser asked for. Sonarr then sees sonarr.example.com, so that name must be on the list. Without that line, nginx sends the address from proxy_pass instead, which is 127.0.0.1:8989. That address is always allowed, so this setup works with any list. Caddy and Traefik forward the original Host header by default, so with them you always list the domain. For what each of those nginx headers does, see how an nginx reverse proxy config works, line by line.

A safe value for a proxied Sonarr that you also open on the LAN:

sonarr.example.com, 192.168.1.50

Do not forget the other containers

In a Docker arr stack, other apps call Sonarr and Radarr by their service name. Prowlarr, Bazarr, Jellyseerr and dashboards such as Homepage use addresses like http://sonarr:8989 and http://radarr:7878. Those requests carry Host: sonarr or Host: radarr. The service name is not the container's machine name, so it is not added for you. Once you set Allowed Hosts without it, the connection test in those apps fails with HTTP 400. The help text under the field says this directly: include the "docker container name".

sonarr.example.com, 192.168.1.50, sonarr

If you wired the apps together by following connecting Prowlarr, Sonarr, Radarr and a download client, check which address each app uses and list that name.

Setup 3: over Tailscale and MagicDNS

Tailscale gives each device an address in the 100.64.0.0/10 range. MagicDNS, its built-in name service, adds a short name such as mediabox and a full name such as mediabox.tail1234.ts.net. Each one is a different Host value, so list every form you actually type.

100.64.0.10, mediabox, mediabox.tail1234.ts.net

The short MagicDNS name usually matches the server's machine name, so a native install accepts it already. A Docker install does not, for the reason given in setup 1. If you put HTTPS in front with Tailscale Serve, list the full ts.net name. Serve then passes on either that name or a loopback address, and both are accepted.

Setting Allowed Hosts from Docker Compose

Sonarr and Radarr read settings from environment variables named after the config section, with double underscores. For this setting the names are SONARR__SERVER__ALLOWEDHOSTS and RADARR__SERVER__ALLOWEDHOSTS.

services:
  sonarr:
    environment:
      - SONARR__SERVER__ALLOWEDHOSTS=sonarr.example.com,192.168.1.50,sonarr
  radarr:
    environment:
      - RADARR__SERVER__ALLOWEDHOSTS=radarr.example.com,192.168.1.50,radarr

The environment variable wins over config.xml. While it is set, a value you save in the web interface has no effect, because the app reads the variable first. This is a common reason for "I changed it and nothing happened". For the rest of a compose-based setup, see running the arr stack with Docker Compose.

How to check that it worked

Sonarr writes one line to its log at startup that shows the final list, including the names it added for you.

docker logs sonarr 2>&1 | grep -i "requests for"
sudo journalctl -u sonarr | grep -i "requests for"

Use the first command for a container named sonarr and the second for a native systemd install. A configured app prints a line that starts with Accepting requests for hosts: followed by the full list. An unconfigured one prints Allowed Hosts is not configured, accepting requests for any host.

Then test it from the server itself. curl lets you send any Host header you like.

curl -s -o /dev/null -w '%{http_code}\n' -H 'Host: not-my-server.example' http://127.0.0.1:8989/
curl -s -o /dev/null -w '%{http_code}\n' -H 'Host: sonarr.example.com' http://127.0.0.1:8989/

The first command should print 400. The second should print some other code, for example 200 or 401, depending on your authentication settings. For Radarr, use port 7878.

The test also shows the limit of the feature. Anyone who can reach the port can send any Host header they want, exactly as curl just did. Allowed Hosts stops a browser from being tricked into talking to your app. It does not stop a person who targets your server directly. Keep the port off the public internet, and if you publish it from Docker, read why Docker-published ports bypass ufw.

Still locked out? How to recover access

You see Bad Request - Invalid Hostname in the browser because your list does not contain the name in the address bar. There are two ways back in.

Use localhost through an SSH tunnel

localhost and 127.0.0.1 are always allowed, whatever the list says. Forward the port over SSH and open the app as localhost:

ssh -L 8989:127.0.0.1:8989 user@your-server

Leave that session open and browse to http://localhost:8989. The browser sends Host: localhost:8989, which passes the check. Fix the list in Settings > General, save, and restart. This works for Docker too, as long as the container publishes port 8989 on the host.

Edit config.xml directly

The setting is stored in config.xml as an <AllowedHosts> element. On a native install from the official install script, the file is /var/lib/sonarr/config.xml or /var/lib/radarr/config.xml. In the LinuxServer.io images it is /config/config.xml inside the container, which is the folder you mounted on the host. If you are not sure where yours is, search for it:

sudo find / -ipath '*sonarr*' -name config.xml 2>/dev/null

Stop the app first, so it does not write over your edit. Then open the file:

sudo systemctl stop sonarr
sudo grep -n AllowedHosts /var/lib/sonarr/config.xml
sudo nano /var/lib/sonarr/config.xml

Change the line so it holds the right names, or empty it to accept every host again:

<AllowedHosts>sonarr.example.com,192.168.1.50,sonarr</AllowedHosts>

Start the app with sudo systemctl start sonarr, or docker start sonarr for a container, and check the log line from the previous section. If the log still shows the old list, an environment variable is overriding the file. Check with docker exec sonarr printenv | grep -i allowedhosts.

How Allowed Hosts differs from Authentication Required and External

These settings answer different questions. Allowed Hosts checks the name in the request. Authentication checks who is making the request. Allowed Hosts runs first, and authentication runs only on requests that pass it.

Authentication Required has two values. "Enabled" asks every request for a login. "Disabled for Local Addresses" skips the login for requests from private network addresses. Authentication Method decides how the login happens. Forms and Basic make the app check a username and password itself. External means the app does no login at all and trusts a proxy in front of it, such as Authelia or Authentik, to have done it. With External, Allowed Hosts does not make a direct connection safe, because a direct request can still claim any Host value.

The trade-offs of turning the login off, and how to do it without exposing the app, are covered in how to disable Sonarr and Radarr authentication safely. If the problem is a forgotten password and not a refused hostname, see the Sonarr and Radarr default login and how to reset the password.

FAQ

Does putting 0.0.0.0 in Allowed Hosts allow every host?

No. Some older advice says to enter 0.0.0.0, but the Sonarr and Radarr source has no special case for it. It is a valid IPv4 address, so it clears the warning, and then only a request whose Host header is literally 0.0.0.0 matches it. Requests by your LAN IP or your domain are refused with HTTP 400. To accept every host, leave the field empty and set Authentication Required to Enabled.

Why do I get "Bad Request - Invalid Hostname" after setting Allowed Hosts?

The name in your browser's address bar is not on the list. The check removes the port, so 192.168.1.50:8989 needs the entry 192.168.1.50. Add the missing name through an SSH tunnel to localhost, which is always allowed. You can also edit the <AllowedHosts> element in config.xml while the app is stopped.

Can I clear the warning without setting Allowed Hosts?

Yes. The warning only appears when Authentication Required is not Enabled. Set it to Enabled, so every request needs a login, and the warning goes away while the field stays empty. A bare * no longer works, because since Sonarr v4.0.19.3011 and Radarr 6.4.4 the check treats it as not configured.

Can I put a subnet like 192.168.1.0/24 in Allowed Hosts?

No. The field takes hostnames and single IP addresses only. A CIDR range is not a valid host, so the settings page rejects it. List each address you type into the browser. For domains, *.example.com covers every subdomain, but not example.com itself.

Why did Prowlarr stop connecting to Sonarr after I set Allowed Hosts?

Prowlarr calls Sonarr by the address you gave it, often http://sonarr:8989 in Docker. That sends Host: sonarr, and the compose service name is not added to the list for you. Add sonarr to Sonarr's Allowed Hosts and radarr to Radarr's, then restart both apps.