Why Does DNS Resolution Work on the Host but Fail Inside a Container?
Host DNS can work while container DNS fails because the container uses a different resolver path, namespace, firewall route, or Docker forwarding state.
On a home server, the host may query a router, Pi-hole, or VPN resolver directly while a bridge-network container sends requests through Docker’s embedded resolver or a copied resolv.conf. The fastest diagnosis tests an IP address first, then queries each resolver explicitly from the failing container so DNS failure is not confused with general outbound connectivity.
Separate DNS Failure From General Network Failure
From the failing container, test a known external IP and the IP address of the intended DNS server before testing any hostname. Record routes, packet loss, and whether TCP and UDP port 53 are reachable.
A Manjaro container case demonstrates the opposite branch: direct IP traffic failed as well, proving the problem was broader than DNS. This direct-IP connectivity test prevents resolver changes from masking a broken bridge, NAT, or firewall path.
If IP connectivity fails, repair container networking first. If IP works but names fail, continue with the resolver configuration and query path.
Inspect the Resolver Configuration Inside the Container
Read /etc/resolv.conf inside the container and compare it with the host. Note nameserver addresses, search domains, options, network mode, and whether the file changes after recreation.
An OpenMediaVault case reported container lookups failing through Docker’s embedded 127.0.0.11 resolver after a runtime update. That embedded resolver path can diverge from the host’s successful lookup.
Do not permanently edit the generated file inside a running container. Put intentional DNS servers and search domains in the compose or platform configuration so they survive recreation.
Query Docker DNS and the Upstream Resolver Separately
Run the same lookup against Docker’s embedded resolver, the router or local DNS server, and a known external resolver where policy permits. Compare timeout, refusal, NXDOMAIN, and returned address.
A TrueNAS community case traced container-only DNS failure to a router access profile that blocked the requests even though other host traffic worked. The decisive observation was DNS blocked for the container path rather than an invalid hostname.
If direct upstream queries work but the embedded resolver fails, restart or repair Docker’s resolver and network state. If every DNS server times out, inspect port 53 routing, firewall, VPN, and reply traffic.
Check for Local DNS Loops and Wrong Internal Answers
Determine whether the container is trying to query a DNS service on the same host, another container, or a hostname that resolves back through the reverse proxy. Capture the answer rather than assuming every successful lookup is correct.
A Traefik community case found that one container resolved a custom domain back to itself instead of the intended peer. That wrong container-side DNS answer passed a basic resolution test but still broke the API connection.
Use service names for same-network container traffic and split DNS for public hostnames only when the return path is deliberate. Avoid hairpin routes that send a container through the public proxy to reach a local dependency unless that path is explicitly tested.
Verify UDP Replies, NAT, and Network Isolation
Capture port 53 traffic on the container interface and host bridge. Confirm that the query leaves, the resolver receives it, and the reply returns from the address the client expects.
Pi-hole users have documented same-host container queries timing out because replies returned from an unexpected translated source. This unexpected DNS reply source distinguishes a response-path problem from a silent resolver.
If the request and response cross different Docker networks, add the correct shared network or route rather than moving every service to host networking. Check firewall zones and VPN policies that may treat bridge subnets differently from the host address.
Recreate the Network State and Prove the Fix
After correcting the resolver, firewall, or network definition, recreate one test container on the intended network and repeat IP, direct-resolver, embedded-resolver, service-name, and public-name tests.
The ZimaSpace guide to separating address and name failures provides the adjacent host-side diagnostic boundary.
The problem is resolved only when the DNS configuration survives recreation and reboot, internal service names and approved public names return the intended addresses, and application traffic succeeds through the same network path. If failure returns only after a Docker update, preserve the version and daemon logs as a runtime regression boundary.
Recommended products
Support & Tips
More to Read
Can Plex Share a GPU With Another Docker Container?
Plex and another container can often access the same GPU, but you must test driver support, device mapping, video-engine load, memory, and recovery behavior.
How to Tell Whether a Plex Error Comes From the Client or Server
Reproduce the same item on another client, compare the session path, then collect server evidence only after scope tells you where the failure actually...
How to Configure Plex Cache and Transcode Temporary Storage
Protect persistent Plex state while placing transcode temp files on suitable local storage, then verify cleanup, free space, and restart behavior.
