MaxRetryError: HTTPSConnectionPool Max retries exceeded: Failed to establish a new connection [Errno 111]

TL;DR: Your code cannot open a TCP connection to the API server at all. The server address in your kubeconfig is wrong, the cluster is down, or a firewall blocks it. Fix the endpoint or the network path.

urllib3.exceptions.MaxRetryError: HTTPSConnectionPool(host='[cluster-host]', port=6443): Max retries exceeded with url: /api/v1/namespaces/default/pods (Caused by NewConnectionError('[urllib3.connection.HTTPSConnection object]: Failed to establish a new connection: [Errno 111] Connection refused'))

Fix it

1. Read the server URL from your kubeconfig: kubectl config view --minify | grep server. Expected: a host:port.
2. Test it directly: curl -k the /healthz endpoint on your cluster server URL with a 10 second timeout. Expected: ok. Connection refused here means the problem is network/cluster, not your code.
3. If the host is wrong (stale IP, old cluster), update it with kubectl config set-cluster, passing your cluster name and the correct server URL. Expected: the health check then succeeds.
4. Check firewalls, VPN, and that the cluster is actually running (minikube status / kind / cloud console). Expected: the endpoint answers.

When this applies

• The error is MaxRetryError / NewConnectionError with Errno 111 on the API server host.

When it doesn't

• The error is ApiException 401/403: you reach the server; auth is the problem.
• The error is a TLS certificate error: the server is reachable; fix certs.

Compatibility

• kubernetes client any version; urllib3 any.

Why it happens

Errno 111 means the SYN got an RST: nothing listens there. The client faithfully reports the kubeconfig's server address, so a stale or mistyped address looks exactly like a down cluster.

Edge cases

• Port-forwarded endpoints only work from the machine running the forward.
• Corporate proxies need HTTPSPROXY/NOPROXY set so cluster traffic bypasses the proxy.