I'm fairly new to Docker and spent most of a day debugging a containerized web app. The frontend was running in a Caddy image on a DigitalOcean droplet, but it stopped responding to requests. Initially the container had crashed because it was trying to use an occupied port. After fixing that, it still failed, and the logs contained vague errors about being unable to connect to the internet.
Running `nslookup web1` inside the container produced:
`Server: 127.0.0.53`
`Address: 127.0.0.53#53`
`server can't find web1: SERVFAIL`
Adding `dns: [1.1.1.1, 8.8.8.8]` to the Compose configuration fixed the problem. I'd like to understand what diagnostic process an experienced Docker or Linux user would follow in this situation. Was there an important piece of documentation or foundational knowledge I missed, or is this simply the kind of networking issue that becomes familiar after encountering it?
2 Answers
The `127.0.0.53` address is normally systemd-resolved’s local stub resolver, not an external DNS server. It indicates that the container ended up with a resolver configuration pointing at a loopback address that wasn’t usable from inside the container. A good first-pass diagnosis would be to check the container’s `/etc/resolv.conf`, run `cat /etc/resolv.conf`, test name resolution with `nslookup` or `getent hosts`, and compare that with the host’s resolver configuration. Docker commonly provides its own internal resolver, often at `127.0.0.11`, and forwards queries to configured upstream servers. On some systems or images, the host’s resolver setup can be incomplete or incompatible, so explicitly configuring working DNS servers fixes it. You definitely didn’t miss an obvious beginner step—this is a layering issue involving the host, Docker’s networking, systemd-resolved, and the container image.
A useful general debugging approach is to test each layer separately instead of starting with the application. First confirm the container is running and listening on the expected port with `docker ps` and `ss` or `netstat`. Then check whether the service is reachable locally and through the published port. After that, test connectivity from inside the container: inspect routes, try an IP address directly, and test DNS resolution separately. If an IP works but a hostname fails, you’ve narrowed the problem to DNS rather than Caddy or the application. Also inspect the container’s actual resolver file instead of assuming it matches the host. The exact failure is often environment-specific, so learning a short set of checks is more useful than memorizing one particular fix.
That helps clarify the confusing part: the loopback address was meaningful on the host but not necessarily reachable from inside the container. I’ll add checking `/etc/resolv.conf` and testing DNS early to my normal troubleshooting routine.