I noticed downloads being particular slow when building and running containers that pull in relatively big artifacts from the internet.
As an experiment I tried running speedtest-cli (apt install speedtest-cli):
From my local machine (Ubuntu 20.04.6 LTS):
❯ speedtest-cli
Retrieving speedtest.net configuration...
Testing from Telenet (84.195.66.19)...
Retrieving speedtest.net server list...
Selecting best server based on ping...
Hosted by NewsXS B.V. (Amsterdam) [162.03 km]: 24.149 ms
Testing download speed................................................................................
Download: 255.20 Mbit/s
Testing upload speed......................................................................................................
Upload: 28.52 Mbit/s
From a docker container (ubuntu:22.04) running on the same local machine
❯ docker run -it ubuntu:22.04 /bin/bash
root@6e877f0efff1:/# apt update && apt install --yes speedtest-cli
...
root@6e877f0efff1:/# speedtest-cli
Retrieving speedtest.net configuration...
Testing from Telenet (84.195.66.19)...
Retrieving speedtest.net server list...
Selecting best server based on ping...
Hosted by Claranet Benelux B.V. (Amsterdam) [162.03 km]: 2532.721 ms
Testing download speed................................................................................
Download: 2.25 Mbit/s
Testing upload speed......................................................................................................
Upload: 2.94 Mbit/s
Has anyone run into a similar issue before? And how did you resolve it?
I ran into this potential MTU Issue but I don’t think it’s it, the MTU of my default network interface is the same as the MTU of the docker interface:
❯ ip link | grep mtu
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
2: wlp0s20f3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DORMANT group default qlen 1000
3: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default
I run docker-ce 26.1.0 and have a 1000/200 fiber connection. I use speedtest-tracker - LinuxServer.io to measure the bandwidth. It measures roughly ~940 Mbps down and ~220 Mbps up. The download bandwidth was slightly better before I switched to an OpenWRT based router.
It’s safe to say that it’s not a general docker problem
Thanks for testing, although it doesn’t fully rule out it’s not a docker issue.
There is definitely an issue on my side, and it’s related to docker, so I suspect it might be a configuration problem
I went back to speedtest-cli and got the same results (docker container having much slower internet) as before. I run each of them a few times and the results both (speedtest being ok and speedtest-cli being slow in the container but not on my local machine seem to be consistently replicable)
This is caused by the dns setting of your host. While containers attached to the default bridge network will mount the host’s /etc/resolv.conf, containers attached to a user defined bridge network will use docker’s internal dns server, which uses the configuration from the host’s /etc/resolv.conf as upstream.
The setting you made just bypasses the default behavior, which shouldn’t be necessary if the host’s configuration is okay.
Personally, I would investigate what dns resolver was configured and fix the problem at the source. For instance, on Ubuntu I use systemd-resolved without the stub resolver, so that my /etc/resolv.conf actually points to a dns resolver available in my network. The stub resolver can be deactivated in the responsible config file in /etc/systemd/resolved.conf.d/ and then requires a restart of the service systemctl restart systemd-resolved.service.
.