Error response from daemon: Get https://registry-1.docker.io/v2/: proxyconnect tcp: dial tcp 192.168.65.5:3128: connect: connection refused

[bsnote]

• I have tried with the latest version of Docker Desktop
• I have tried disabling enabled experimental features
• I have uploaded Diagnostics
• Diagnostics ID: 18C06B83-84A6-4E83-97D3-C4A527040AB4/20210427135201

Expected behavior

Docker pull should result in pulling an image from dockerhub or private registry. It should use proxy when set to "Manual proxy configuration".

Actual behavior

Docker pull results in Error response from daemon: Get https://registry-1.docker.io/v2/: proxyconnect tcp: dial tcp 192.168.65.5:3128: connect: connection refused when I try to pull an image.

Information

After upgrade to version 3.3.1 of Docker Desktop, I get the message Error response from daemon: Get https://registry-1.docker.io/v2/: proxyconnect tcp: dial tcp 192.168.65.5:3128: connect: connection refused when I try to pull an image.

The error message indicates that there is a problem with a proxy, though the proxy settings are correct. If Manual Proxy Configuration is disabled in Docker Settings, it still doesn't work showing Error response from daemon: Get https://registry-1.docker.io/v2/: Bad Gateway error, even though system proxy settings are correct.

• macOS Version: 10.14.6
• Intel chip or Apple chip: Intel chip
• Docker Desktop Version: 3.3.1 (63152)
• This is behind a corporate network

Steps to reproduce the behavior

1. Upgrade Docker Desktop to 3.3.1
2. Make sure Manual Proxy Settings are set and correct.
3. Try to pull an image.

[stephen-turner]

Thanks for the report, I think this is probably a dupe of #5572. Could you try the build my colleague @djs55 posted at #5572 (comment) and see if it fixes the problem?

[karaarda]

@stephen-turner I am having a similar issue after updating to MacOS 11.3 on docker for mac 3.3.1, I tested several things.

On 63151 (I guess this was the build number) with hyperkit I get the following error (it means it cannot connect NFS):

UnixHTTPConnectionPool(host='localhost', port=None): Read timed out. (read timeout=60)

On 63151 with apple virtualization framework I get the following:

Response body:
dial unix docker.raw.sock: connect: connection refused

On 63310 (build you provided) it works all fine with hyperkit and nfs.

It does not work with apple virtualization and nfs giving the following error again:

UnixHTTPConnectionPool(host='localhost', port=None): Read timed out. (read timeout=60)

It is important for me to be able to use both NFS and apple virtualization. Any idea why NFS does not work with apple virtualization? My exports file is as follows.

For hyperkit
/Projects -alldirs -mapall=501:20 localhost

For apple virtualization
/Projects -network 192.168.0.0 -mask 255.255.0.0 -alldirs -mapall=501:20

[karaarda]

@stephen-turner I managed to solve the problem by adding an alias for my localhost as I suggested here

It was previously possible to only use the solution in my previous answer on the same issue

[stephen-turner]

It is important for me to be able to use both NFS and apple virtualization.

@karaarda Why is it important to you to use the Apple virtualization framework? As far as we're concerned, it should be a black box. I'd be interested to know why the hypervisor framework is not suitable for you.

[karaarda]

@stephen-turner, Apple virtualization framework has better file access times and uses less CPU. Which together results in a cooler Macbook and a better development experience. Our build times are reduced to less than 1/2 of hyperkit, docker-compose up is 1/4 of it and CPU utilization is really low compared to hyperkit. When using hyperkit our MBP16 devices' fans run at 5000 rpm to keep it cool and it has spikes in power consumption from 30W to 90W. We don't encounter these when using Apple virtualization.

[stephen-turner]

That's fair. It does have lower CPU. But you have to accept the caveats that we've documented at https://docs.docker.com/docker-for-mac/troubleshoot/#known-issues.

[karaarda]

Thanks for sharing the link, I was not aware of those problems. It is still a better experience for us as we are running several containers running ffmpeg, imagemagick, meteorjs and some other CPU intensive tasks. Adding an alias for the localhost is a simple workaround for now. Let me know if I can help in any way.

[stephen-turner]

Assuming the original bug was a dupe of #5572, it should now be fixed so I'm going to close this ticket.

[docker-robott]

Closed issues are locked after 30 days of inactivity.
This helps our team focus on active issues.

If you have found a problem that seems similar to this, please open a new issue.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows.
/lifecycle locked