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.

```text
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 HTTPS_PROXY/NO_PROXY set so cluster traffic bypasses the proxy.