Network i/o timeout on 192.168.65.1 when trying to push an image

When trying to push images to artifact registry, I occasionally get this error:

Head "https://us-west1-docker.pkg.dev/v2/[snip]": proxyconnect tcp: dial tcp 192.168.65.1:3128: i/o timeout

How do I try to debug this? Is this an issue with the local docker daemon? Is the i/o timeout on the pkg.dev side? Is it my ISP/network?

Looking at the message it seems like an issue with my local docker process but I want to be sure that’s actually true.

Diagnostics ID: 816F413F-9D43-422B-9F7E-6DE20C7CF4DF/20240618033605

diagnose check output
❯ /Applications/Docker.app/Contents/MacOS/com.docker.diagnose check
Starting diagnostics

[2024-06-18T03:37:01.882413000Z][com.docker.diagnose.ipc] d4ccd383-diagnose -> <HOME>/Library/Containers/com.docker.docker/Data/backend.sock BackendAPI
[2024-06-18T03:37:01.882620000Z][com.docker.diagnose.ipc] (68fe52e5) d4ccd383-diagnose C->S BackendAPI POST /idle/make-busy
[2024-06-18T03:37:01.883661000Z][com.docker.diagnose.ipc] (68fe52e5) d4ccd383-diagnose C<-S d891ad54-BackendAPI POST /idle/make-busy (1.039875ms): 0x1400058e0f8
[2024-06-18T03:37:02.884081000Z][com.docker.diagnose.ipc] (6962d5b1) d4ccd383-diagnose C->S BackendAPI GET /idle
[2024-06-18T03:37:02.889232000Z][com.docker.diagnose.ipc] (6962d5b1) d4ccd383-diagnose C<-S d891ad54-BackendAPI GET /idle (4.973291ms): {"apisInFlight":{},"booted":true,"busyReason":["2 container(s)","timed activities: map[/idle/make-busy:28.996940417s]"],"containers":2,"idle":"bool","kubernetesEnabled":false,"reduced":false,"services":0,"timedActivities":{"/idle/make-busy":"float64"},"vmPaused":false,"vmRunning":true,"vmStopped":false,"windowsContainers":false}
[PASS] DD0027: is there available disk space on the host?
[PASS] DD0028: is there available VM disk space?
[PASS] DD0018: does the host support virtualization?
[PASS] DD0001: is the application running?
[PASS] DD0017: can a VM be started?
[PASS] DD0016: is the LinuxKit VM running?
[PASS] DD0004: is the Docker engine running?
[PASS] DD0015: are the binary symlinks installed?
[PASS] DD0031: does the Docker API work?
[PASS] DD0013: is the $PATH ok?
[PASS] DD0003: is the Docker CLI working?
[PASS] DD0038: is the connection to Docker working?
[PASS] DD0014: are the backend processes running?
[PASS] DD0007: is the backend responding?
[SKIP] DD0009: is the vpnkit API responding?
[PASS] DD0010: is the Docker API proxy responding?
[SKIP] DD0030: is the image access management authorized?
[PASS] DD0033: does the host have Internet access?
[PASS] DD0018: does the host support virtualization?
[PASS] DD0001: is the application running?
[PASS] DD0017: can a VM be started?
[PASS] DD0016: is the LinuxKit VM running?
[PASS] DD0004: is the Docker engine running?
[PASS] DD0015: are the binary symlinks installed?
[PASS] DD0031: does the Docker API work?
[PASS] DD0032: do Docker networks overlap with host IPs?
No fatal errors detected.

We have no access to the submitted diagnostics, only the Docker support. The “proxyconnect” error could be anywhere, but 192.168.65.1 is indeed in the default subnet of Docker Desktop.

Which version are you using? In the latest version there were new proxy-related features, but I have no idea if it has anything to do with that.

docker desktop 4.31.0, docker 26.1.4.
This has been happening since before 4.31.0 so I am not sure if its related to changes in the newest version.

How would I root cause to local vs external connection? This started happening after I switched ISPs (and city) so there is some reason to believe it may be external connection.