vSphere Client Won't Connect to Host: Top 3 Fixes
Lost connection to your ESXi host? Usually it's a broken hostd service, a firewall blocking port 443, or a certificate issue. Here's how to fix each.
You open the vSphere Client, type the host IP, and it just sits there spinning. Or you get a scary error like An unknown connection error occurred or Cannot connect to host. I've been there more times than I can count, usually on a Friday evening right before a maintenance window.
What's actually happening here is the vSphere Client (the web UI or the old C# client) can't reach the ESXi host's management APIs on port 443. The reasons are surprisingly limited. Let's walk through the three big ones in order of likelihood.
1. Broken hostd Service
This is the #1 cause. The hostd service is the main management agent on your ESXi host. It handles all the API calls from the vSphere Client. Sometimes it crashes, hangs, or gets into a bad state after a patch or a resource crunch. The fix is to restart it.
How to check if hostd is the culprit: SSH into your ESXi host (you need SSH enabled — if it's not, enable it from the DCUI, the direct console). Then run:
/etc/init.d/hostd status
If it says hostd is stopped or just hangs, it's dead. Restart it:
/etc/init.d/hostd restart
Wait about 30–60 seconds. Then try connecting again. If that doesn't work, also restart the vpxa service if your host is managed by vCenter:
/etc/init.d/vpxa restart
The reason restarting hostd works most of the time is because the service reloads all its config and re-establishes connections. I've seen it fix stubborn connection failures after a host ran out of memory and the kernel killed hostd. If it still fails after restart, move to the next step.
2. Firewall Blocking Port 443
The ESXi firewall has a default rule that allows incoming HTTPS on port 443. But sometimes that rule gets disabled — either manually, by a script, or by a misconfigured lockdown mode. Or your network firewall between the client and the host is blocking the port.
Check the ESXi firewall from SSH:
esxcli network firewall ruleset list | grep -i web
Look for a rule named vSphere Web Client or httpClient. The output should show true under Enabled. If it's false, enable it:
esxcli network firewall ruleset set -r vSphereWebClient -e true
Also check if the firewall is globally enabled. Run:
esxcli network firewall get
If Enabled is true and the rule is enabled but you still can't connect, try temporarily disabling the firewall to rule it out:
esxcli network firewall set -e false
Then try connecting. If it works now, you know the firewall is the issue — re-enable it and then dig into the specific rule. The real fix is to identify which rule or policy is blocking. Also check your physical network — I've spent 30 minutes debugging a host that was fine, only to realize the client laptop was on a different VLAN that blocked port 443. Use telnet host-ip 443 from your client to test if the port is open.
3. SSL Certificate Expired or Corrupt
ESXi generates self-signed certificates on first boot. They last about 2 years. When they expire, the vSphere Client refuses to connect because it can't validate the SSL handshake. You'll see an error like SSL certificate verification failed or certificate has expired in the browser or the vSphere Client log.
Fix: Regenerate the certificates from the DCUI or SSH. Easiest way: power on the host's direct console (DCUI) — press F2, log in, go to Troubleshooting Options, then Restart Management Agents. This regenerates the certs and restarts hostd. If you prefer SSH:
/etc/init.d/hostd restart --force-reload-certs
That option tells hostd to regenerate the SSL certificates from scratch. After the restart, clear your browser cache and try connecting. If you're using the vSphere Client (the old C# one), you might need to add an exception or manually trust the new cert.
A quick way to verify expiry without SSH: open a browser and go to https://your-host-ip. Click the padlock icon to see the certificate details. If it's expired, that's your problem. On ESXi 6.5 and earlier, the default cert lasts 10 years. On 6.7 and later, it's reduced to 2 years — so this bug hits more often on newer versions.
Quick-Reference Summary
| Cause | Symptom | Fix | Time |
|---|---|---|---|
| hostd crashed | Connection hangs, no error, or generic timeout | /etc/init.d/hostd restart | 1 min |
| Firewall blocks 443 | Connection refused, port not open from client | Enable vSphereWebClient rule | 2 min |
| SSL cert expired | Certificate error in browser, can't connect | Restart hostd with --force-reload-certs | 2 min |
Was this solution helpful?