Unable to connect to the server: kubectl found a cluster address and could not reach it

Unable to connect to the server: dial tcp …: i/o timeout means the configuration is fine and the network path is not. The API server is unreachable, not misconfigured.

Applies to: All Kubernetes versions

What it means

This error means kubectl resolved a server address from the kubeconfig and could not establish a connection to it. Configuration is therefore not the problem — the address exists in the config and the failure is at the network layer. The distinctions in the error text matter: a timeout means packets vanished, which points at a firewall, a VPN, or a private endpoint; no such host means DNS did not resolve the API server's name; and connection refused means something answered and rejected the connection, which usually means the API server is down rather than unreachable.

Most common causes

• The API server is genuinely down or restarting.
• A private cluster endpoint reachable only from a specific network, with no VPN connected.
• A firewall or security group blocking the client's address.
• DNS failing to resolve the API server's hostname.
• A stale kubeconfig pointing at an address the cluster no longer uses.
• A proxy configuration interfering, or a proxy that is required and not set.
• The cluster having been deleted while the kubeconfig remains.

How to diagnose it

1. Read which address is being used: kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}'.
2. Test reachability independently: curl -k https://ADDRESS/version or nc -vz HOST PORT.
3. Distinguish the failure mode — timeout, no such host, or refused — since each points somewhere different.
4. Check whether a VPN or bastion is required for this cluster and is connected.
5. Check proxy environment variables, which can silently redirect or block the connection.
6. Confirm the cluster still exists in the provider's console.

How to fix it

1. Connect to the network the private endpoint requires.
2. Permit your address in the API server's authorised networks if the cluster restricts access.
3. Update the kubeconfig if the endpoint has changed.
4. Fix DNS resolution, or use the address directly to confirm that is the issue.
5. Set or unset proxy variables as the environment requires, including NO_PROXY for internal addresses.
6. Wait and retry if the control plane is being upgraded, which briefly interrupts access on some managed platforms.

Notes

On managed platforms the control plane can be genuinely unavailable during upgrades and maintenance while every workload keeps running normally. An unreachable API server is not the same as a down cluster, and confirming whether traffic is still being served answers a different and often more urgent question.

Related

• The connection to the server localhost:8080 was refused — kubectl has no kubeconfig
• couldn't get current server API group list — Discovery against the API server failed

Sources

• Kubernetes documentation — Organizing Cluster Access Using kubeconfig Files
• Kubernetes documentation — Troubleshooting Clusters
• Kubernetes documentation — kubectl config