Sonarr's local-address authentication exception is a network policy test
Sonarr exposes a web interface and an API for managing television libraries, indexers and download clients. The application can be useful behind a reverse proxy, but the authentication setting that works for a home LAN does not automatically work for a public or shared network.
The Servarr FAQ recommends enabling an authentication method when the UI is accessible from outside the local network. It also documents a setting that disables authentication for local addresses. That exception depends on what Sonarr considers local. A reverse proxy, container network or VPN can change the effective client address and invalidate the operator's assumption.
Measurement evidence
On 2026-11-07 UTC, page-one count-only ZoomEye probes with sub_type=all returned zero matches for app="Sonarr", 139,616 for title="Sonarr" and 966,065 for http.body="Sonarr". The broad title and body counts likely include guides, dashboards and pages that mention the application. They do not measure exposed Sonarr instances, and the zero application result is not proof that none exist.
Map the actual client address
Test unauthenticated access from the console, from a workstation on the LAN, from the VPN and through the reverse proxy. Record the address Sonarr sees for each path. If the proxy is trusted, configure the real-IP handling carefully and strip client-provided forwarding headers before adding the trusted value.
Do not publish Sonarr directly. Put it behind a VPN or an identity-aware proxy, and require authentication for every route that can change settings. The API key in the X-Api-Key header is an administrator credential, not a read-only token. Store it outside source control and give each automation job its own inventory record.
Review the automation graph
Sonarr can reach indexers, download clients, root folders and notification services. Record those endpoints and their credentials. Test what a compromised API key can do, including changing a download client or deleting a series. Restrict filesystem permissions so the service account cannot write outside the media and configuration paths it needs.
Monitor setting changes, authentication failures, API calls from new addresses and deletions. If an instance is exposed, rotate the API key, review indexer and download-client credentials, inspect root-folder changes and preserve logs before cleanup.
The inventory needs more than a URL. It needs the authentication mode, the effective client-address path and the external systems the service can control.
