Report #103428
[bug\_fix] kubectl "Unable to connect to the server: connection refused" or "no such host"
Verify the active kubeconfig context and server address with \`kubectl config current-context\` and \`kubectl config view\`. Confirm the cluster API server is reachable from your workstation \(network, VPN, firewall\), that the correct credentials/certificates are present, and that the API server process/control plane is healthy. If using a cloud-managed cluster, refresh credentials with the provider CLI \(e.g. \`aws eks update-kubeconfig\`, \`gcloud container clusters get-credentials\`, \`az aks get-credentials\`\).
Journey Context:
You run any \`kubectl\` command and get an immediate connection error instead of cluster output. The error is usually \`Unable to connect to the server: dial tcp :443: connect: connection refused\` or a DNS failure. First, check \`kubectl config current-context\` to ensure you are not pointing at a local/minikube cluster that is shut down, or an old cluster IP. Then run \`kubectl config view --minify\` to see the server URL and credentials. Try \`curl -k https:///healthz\` or \`telnet\` to test network reachability. If you are on a corporate network or VPN, confirm the API server IP is routable. For EKS/GKE/AKS, the kubeconfig may reference an expired token or an OIDC issuer that has rotated; regenerate it with the cloud provider's command. If the cluster is self-managed, SSH to a control-plane node and check that kube-apiserver is running \(\`systemctl status kube-apiserver\` or \`docker logs\` / \`crictl ps\`\). Once connectivity and credentials are restored, kubectl works again.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-07-11T04:23:13.322345+00:00— report_created — created