Environment:
Plex Media Server on Windows
-
Pi-hole running in Docker
-
Unbound configured as the upstream resolver
The Issue
When accessing Plex via https://app.plex.tv/web, the browser failed to connect to the local server.
Developer console showed errors such as:
[Servers] Failed to request resources through plex.tv
[Connections] All connections to [Bundled] failed
analytics.plex.tv:1 ERR_CERT_AUTHORITY_INVALID
clients.plex.tv/api/v2/user 500 ()
Disabling Pi-hole immediately resolved the problem.
The Cause
Plex uses hostnames like xxxxxxxx.plex.direct to reach your local server over HTTPS.
These names resolve to private LAN IP addresses — intentionally.
However, Unbound and Pi-hole include DNS rebinding protection, which blocks “public” domains that resolve to private IPs.
That protection is great for security, but it breaks Plex discovery.
The Fix
1. Tell Unbound to trust
plex.direct
Edit your Unbound config file (mounted in Docker, often something like 10-local-zone.conf or pi-hole.conf under /etc/unbound/unbound.conf.d/).
Inside the server: section, add:
private-domain: "plex.direct"
Example:
server:
private-domain: "local.lan."
private-domain: "plex.direct"
Then restart Unbound:
docker restart unbound
(or if Unbound runs inside Pi-hole: docker exec -it pihole pihole restartdns)
2. (Optional) Tell Pi-hole’s dnsmasq the same thing
Create or edit a file such as /etc/dnsmasq.d/99-plex.conf
and add:
rebind-domain-ok=plex.direct
Restart Pi-hole:
docker restart pihole
The Result
Once these lines are in place, Plex connects immediately through Pi-hole and Unbound — no more 500 errors or failed connections.
Why It Works
Those directives disable DNS-rebind blocking only for plex.direct, allowing Plex’s legitimate local HTTPS connections while keeping the rest of your DNS protection intact.
Summary:
If Plex fails to connect when Pi-hole + Unbound are active, add
private-domain: "plex.direct"
to Unbound’s config (and optionally rebind-domain-ok=plex.direct for dnsmasq).
Restart both containers — Plex works again.
