My Docker Container Has No Internet

I had it working allright but now it stopped. I tried the following commands with no avail:

docker run -dns 8.8.8.8 base ping google.com

docker run base ping google.com

sysctl -w net.ipv4.ip_forward=1 - both on the host and on the container

All I get is unknown host google.com. Docker version 0.7.0

Any ideas?

P.S. ufw disabled as well

6

32 Answers

First thing to check is run cat /etc/resolv.conf in the docker container. If it has an invalid DNS server, such as nameserver 127.0.x.x, then the container will not be able to resolve the domain names into ip addresses, so ping google.com will fail.

Second thing to check is run cat /etc/resolv.conf on the host machine. Docker basically copies the host's /etc/resolv.conf to the container everytime a container is started. So if the host's /etc/resolv.conf is wrong, then so will the docker container.

If you have found that the host's /etc/resolv.conf is wrong, then you have 2 options:

  1. Hardcode the DNS server in daemon.json. This is easy, but not ideal if you expect the DNS server to change.

  2. Fix the hosts's /etc/resolv.conf. This is a little trickier, but it is generated dynamically, and you are not hardcoding the DNS server.


1. Hardcode DNS server in docker daemon.json

  • Edit /etc/docker/daemon.json

    {
        "dns": ["10.1.2.3", "8.8.8.8"]
    }
    
  • Restart the docker daemon for those changes to take effect:
    sudo systemctl restart docker

  • Now when you run/start a container, docker will populate /etc/resolv.conf with the values from daemon.json.


2. Fix the hosts's /etc/resolv.conf

A. Ubuntu 16.04 and earlier

  • For Ubuntu 16.04 and earlier, /etc/resolv.conf was dynamically generated by NetworkManager.

  • Comment out the line dns=dnsmasq (with a #) in /etc/NetworkManager/NetworkManager.conf

  • Restart the NetworkManager to regenerate /etc/resolv.conf :
    sudo systemctl restart network-manager

  • Verify on the host: cat /etc/resolv.conf

B. Ubuntu 18.04 and later

  • Ubuntu 18.04 changed to use systemd-resolved to generate /etc/resolv.conf. Now by default it uses a local DNS cache 127.0.0.53. That will not work inside a container, so Docker will default to Google's 8.8.8.8 DNS server, which may break for people behind a firewall.

  • /etc/resolv.conf is actually a symlink (ls -l /etc/resolv.conf) which points to /run/systemd/resolve/stub-resolv.conf (127.0.0.53) by default in Ubuntu 18.04.

  • Just change the symlink to point to /run/systemd/resolve/resolv.conf, which lists the real DNS servers:
    sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf

  • Verify on the host: cat /etc/resolv.conf

Now you should have a valid /etc/resolv.conf on the host for docker to copy into the containers.

17

Fixed by following this advice:

[...] can you try to reset everything?

pkill docker
iptables -t nat -F
ifconfig docker0 down
brctl delbr docker0
docker -d

It will force docker to recreate the bridge and reinit all the network rules

Seems the interface was 'hung' somehow.

Update for more recent versions of docker:

The above answer might still get the job done for you but it has been quite a long time since this answer was posted and docker is more polished now so make sure you try these first before going into mangling with iptables and all.

sudo service docker restart or (if you are in a linux distro that does not use upstart) sudo systemctl restart docker

11

The intended way to restart docker is not to do it manually but use the service or systemctl command:

service docker restart

or

systemctl restart docker
6

Updating this question with an answer for OSX (using Docker Machine)

If you are running Docker on OSX using Docker Machine, then the following worked for me:

docker-machine restart

<...wait for it to restart, which takes up to a minute...>

docker-machine env
eval $(docker-machine env)

Then (at least in my experience), if you ping google.com from a container all will be well.

2

I do not know what I am doing but that worked for me :

OTHER_BRIDGE=br-xxxxx # this is the other random docker bridge (`ip addr` to find)    
service docker stop

ip link set dev $OTHER_BRIDGE down
ip link set dev docker0 down
ip link delete $OTHER_BRIDGE type bridge
ip link delete docker0 type bridge
service docker start && service docker stop

iptables -t nat -A POSTROUTING ! -o docker0 -s 172.17.0.0/16 -j MASQUERADE
iptables -t nat -A POSTROUTING ! -o docker0 -s 172.18.0.0/16 -j MASQUERADE

service docker start
4

I was using DOCKER_OPTS="--dns 8.8.8.8" and later discovered and that my container didn't have direct access to internet but could access my corporate intranet. I changed DOCKER_OPTS to the following:

DOCKER_OPTS="--dns <internal_corporate_dns_address"

replacing internal_corporate_dns_address with the IP address or FQDN of our DNS and restarted docker using

sudo service docker restart

and then spawned my container and checked that it had access to internet.

No internet access can also be caused by missing proxy settings. In that case, --network host may not work either. The proxy can be configured by setting the environment variables http_proxy and https_proxy:

docker run -e "http_proxy=YOUR-PROXY" \
           -e "https_proxy=YOUR-PROXY"\
           -e "no_proxy=localhost,127.0.0.1" ... 

Do not forget to set no_proxy as well, or all requests (including those to localhost) will go through the proxy.

More information: Proxy Settings in the Archlinux Wiki.

4

I was stumped when this happened randomly for me for one of my containers, while the other containers were fine. The container was attached to at least one non-internal network, so there was nothing wrong with the Compose definition. Restarting the VM / docker daemon did not help. It was also not a DNS issue because the container could not even ping an external IP. What solved it for me was to recreate the docker network(s). In my case, docker-compose down && docker-compose up worked.

Compose

This forces the recreation of all networks of all the containers:

docker-compose down && docker-compose up

Maya Lin-Takahashi

Maya Lin-Takahashi

Consumer Tech & Gadget Reviewer

Maya is a hardware enthusiast who tests and reviews smart home devices, smartphones, wearables, and audio gear. She focuses on practical consumer value and build quality.