What does docker:io_timeout mean?

Docker hit an i/o timeout while contacting the registry, usually because of DNS, proxy, firewall, or slow network connectivity.

How do I prevent docker:io_timeout in CI?

Use a proxy/cache registry to reduce dependence on upstream availability. Keep runner network configuration consistent (DNS/proxy/firewall).

How can I manually validate docker:io_timeout?

Resolve the target host from the same machine, container, or CI runner that failed. Use `nslookup ` or `dig ` so you know DNS is pointing where you expect. Test the target port directly with `nc -vz ` or `curl -Iv https:// /` to separate routing and proxy issues from package-manager behavior. If the failure only happens in CI, run the same checks in that runner image or job environment instead of validating from your laptop.

Error response from daemon: i/o timeout

Fix it fast

Most likely: Docker can start the registry request, but DNS, proxy, VPN, firewall, or a slow/unhealthy registry path is taking too long to respond.

1. Confirm this is your error

Error response from daemon: i/o timeout

2. Check the cause

docker --debug pull <image>
nslookup <registry>
nc -vz <registry> 443
curl -vkI https://<registry>/v2/
docker info

3. Apply the safe fix

# Fix the same network path the Docker daemon uses: DNS, proxy, VPN, firewall, or registry health.

# If a proxy is required, configure it for Docker Desktop or the Docker daemon, not only for your shell.
docker --debug pull <image>

4. Verify it works

curl -vkI https://<registry>/v2/
docker pull <image>
docker push <image>

Don't use unsafe shortcuts

Do not treat an i/o timeout as a wrong tag or missing image until direct registry connectivity is proven.
Do not validate only shell proxy variables, Docker pulls may use daemon-level proxy settings.
Do not compare against your laptop if the failing daemon is in CI, Docker Desktop, WSL, or a remote context.

Where the Request Failed

Docker is telling you the request failed before it got a clean response back. Treat the connection path and the failing environment as the first suspects, not the package or image name.

Restore connectivity to the registry or daemon endpoint

Retry with debug logs:docker --debug pull <image>

Validate DNS and connectivity to the registry host from the same machine.

If you use a proxy, ensure Docker is configured to use it (daemon + CLI env).

If the registry is internal, confirm health and TLS cert validity.

Manual network checks

Resolve the target host from the same machine, container, or CI runner that failed. Use nslookup <host> or dig <host> so you know DNS is pointing where you expect.

Test the target port directly with nc -vz <host> <port> or curl -Iv https://<host>/ to separate routing and proxy issues from package-manager behavior.

If the failure only happens in CI, run the same checks in that runner image or job environment instead of validating from your laptop.

Why It Happens

Usually this comes down to DNS, firewall, proxy, or VPN is blocking registry traffic, the registry is temporarily unavailable or overloaded, or corporate proxies are interfering with TLS or long-lived connections.

Prove the Failing Environment Can Reach It

Re-run the original pull/push and confirm it completes, and confirm CI runners can reach the same registry endpoint.

How Docker pulls and pushes images

Docker has to resolve the host, open a route, and complete the network connection before it can read image metadata or transfer content from the registry or daemon endpoint. That is why these failures are usually solved at the environment layer first. Until the same machine or CI runner can reach the target cleanly, changing versions or names rarely helps.

Prevent Repeat Connectivity Failures

To prevent this, use a proxy/cache registry to reduce dependence on upstream availability, and keep runner network configuration consistent (DNS/proxy/firewall).