Docker pull results in "Request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)"

If you are behind a home wifi router that is acting as a firewall, plug your computer directly into the cable modem via ethernet cable. do a docker login . You will get an error message about saving your password in plain text (base64 actually) in ~/.docker/config.json and it will log you in.
Go back to WiFi.
Take appropriate precautions to protect your credentials by specifying a credentials store in $HOME/. docker / config . json

This is the solution worked for me too.

None of these solutions work for me. From one to the other day the problem occured and there we are. I could use the solution of @efranelas for one or two times. But a day later the proxy was already broke again. And until then none of the listed proxies on the website works. One of them worked totally random but just for a few hours.

I really don’t know what to do. The errors I get with a added proxy vary very much. Sometimes it tells me
Forbidden or Bad Request or unexpected EOF or net/http: TLS handshake timeout and many more…

Any ideas?

1 Like

I was having the same issue connecting to a private repository (in Azure). I’ve seen other forums suggesting the change of DNS. I query using my DNS and 8.8.8.8 and both returned exactly the same.

Doing docker login didn’t work(Client.Timeout). But after I changed /etc/resolve.conf and put 8.8.8.8 there, it worked (even tho it returned exactly the same info as my default DNS).

It also works if you use 1.1.1.1 (DNS from CloudFlare).

So my suspicion is that the docker client has some issue resolving names when going thru the OS provided mechanism. But specifying a direct DNS server, it seems to work.

1 Like

I retract that it has to do with the docker client. It has to do with the DNS resolver in Ubuntu 18 (my system). I started noticing some requests taking a long time in Postman for something else and that’s when I realized that DNS lookup was taking the longest time.
I put a hard-coded DNS in resolve (as mentioned before) and that fixed it.

1 Like

First of all, try to open a new terminal window. It helped me

What worked for us is preventing network manager from modifying /etc/resolv.conf

remove this link:
/etc/resolv.conf -> …/run/systemd/resolve/stub-resolv.conf
and make resolv.conf a static file

only entry we have in /etc/resolv.conf
nameserver 8.8.8.8

/etc/NetworkManager/NetworkManager.conf
[main]
dns=none
rc-manager=unmanaged

You may also need to run a connection specific DNS config (might not be necessary)
nmcli con show
nmcli con mod ipv4.dns “8.8.8.8”
nmcli con mod ipv4.ignore-auto-dns yes
nmcli con down
nmcli con up

restart network manager and check resolv.conf to see that your changes are still in place.

1 Like

For me it worked after proxy policies were updated, it was not a docker problem

I cannot delete my private or public repository from docker hub

When i trying to delete public or private repository from docker hub i got error

Command which i was trying to delete from terminal
curl -s -v -H “Authorization: JWT ${HUB_TOKEN}” -X DELETE “https://hub.docker.com/v2/repositories/mohd/test2/”

After execute i got error
image
Mark bundle as not supporting multiuse
< HTTP/1.1 401 UNAUTHORIZED
< Date: Tue, 14 Jul 2020 08:42:48 GMT
< Content-Type: application/json
< Transfer-Encoding: chunked
< Vary: Cookie

  • Connection #0 to host hub.docker.com left intact
    {“detail”: “Authentication credentials were not provided.”}

For me the solution was to switch to another wifi network

This worked here! Thanks

In my case, setting the proxy configuration in the Docker systemd service file worked as mentioned in https://docs.docker.com/config/daemon/systemd/#httphttps-proxy
I am using the docker in a ubuntu machine under corporate setting.

I’ve implemented the proxy conf fix before, and found it to give me problems on another internet connection. I had to remove the proxy line from /etc/systemd/system/docker.service.d to fix the issue again

Original fix:

# File: /etc/systemd/docker.service.d/http-proxy.conf
[Service]
Environment="HTTP_PROXY=208.123.76.34:8080"
Environment="NO_PROXY=localhost,127.0.0.1"

Updated fix on a new internet connection:

# File: /etc/systemd/docker.service.d/http-proxy.conf
[Service]
Environment="NO_PROXY=localhost,127.0.0.1"
1 Like

If you’re running on macOS Big Sur, disable “Use new virtualization framework” within “Experimental Features.”

7 Likes

Thank you. It works for me

Thanks! This worked here. :slight_smile:

For me it was my own fault.

I’d been setting up pihole in Docker in Mac, and I’d set DNS on the Mac to look at an incorrect IP. Everything else appeared to be working, but when I checked my DNS seeings and then changed them to my pihole’s correct IP, everything worked correctly.

For MacOS BigSur the proxy breaks docker push.

The error is:

Get “https://gcr.io/v2/”: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)

The same fix can be achieved by disabling Manual proxy configuration in Resources → PROXIES

I was also facing the same issue.
Then I restarted the docker by command sudo systemctl restart docker and then again tried docker pull hello-world and then it worked. I think whenever you face this issue you should try to restart docker first or do as per given in this docker configuration doc.

Same problem with docker login, close session in docker desktop, change password in docker hub, and try docker login in CLI again, that works for me!