Wazuh agent "Never connected": four causes and the message each leaves, measured

Wazuh agent never connected

An agent that never shows up, or sits at Never connected, leaves a specific message on the agent and another on the manager. We produced four common causes on Wazuh 4.14.7 with real agents and wrote down both sides. One trap: an agent pointed at the wrong event port enrolls fine, then keeps retrying enrollment and reports Duplicate agent name, which sends people looking in the wrong place.

Dong Nguyen, ATK New Technology · 2 October 2026 · measured on Wazuh 4.14.7 (manager, indexer and temporary agent containers)

Stuck on this right now? Email your custom rules or decoders, one sample log line and your Wazuh version to dongnx@atkvn.com. We run them on that exact version and reply within 24 hours with what we find. Free. Remove hostnames, IPs and usernames first. Rather not send them? Run the free pre-check in your browser; your files never leave your machine. Rather have it fixed? USD 149 fixed price per problem, reproduced on your version, and you pay only after it works on your system. Our first three customers pay USD 49 for one fix, in exchange for an anonymised write-up we can publish.

How to check in one minute

On the agent (Linux path; on Windows the log is ossec.log in the agent's install folder):

grep -E 'ERROR|WARNING' /var/ossec/logs/ossec.log | tail -n 20
grep -A3 '<server>' /var/ossec/etc/ossec.conf

On the manager:

/var/ossec/bin/agent_control -l
grep -E 'wazuh-authd|wazuh-remoted' /var/ossec/logs/ossec.log | grep -E 'WARNING|ERROR' | tail -n 20

Then match the pair of messages to the table below.

What each cause looks like

Cause	Agent says	Manager shows
Manager address unreachable (wrong IP, routing, firewall)	`Requesting a key from server: <address>`, then, a few minutes later (not yet at 75 s, present at about 3.5 min), `ERROR: (1208): Unable to connect to enrollment service at '[<address>]:1515'`	nothing: the agent is not in the list
Wrong event port (enrollment on 1515 works, events go to a port nothing listens on)	`Valid key received`, then repeated `ERROR: (1216): Unable to connect to '[<ip>]:<port>/tcp'`, `Unable to connect to any server`, and `ERROR: Duplicate agent name: <name>. Unable to add agent (from manager)`	agent listed as Never connected; authd: `Duplicate name '<name>', rejecting enrollment. Agent '<id>' doesn't comply with the registration time to be removed.`
Agent's key removed on the manager (agent deleted, `client.keys` out of sync)	re-enrolls by itself: `Requesting a key`, `Valid key received`, `Connected to the server`	remoted: `WARNING: (1408): Invalid ID <old id> for the source ip`, then the agent back under a new ID
Name already used by an active agent (cloned VM, reused hostname)	repeated `ERROR: Duplicate agent name: <name>`	authd: `Duplicate name '<name>', rejecting enrollment. Agent '<id>' can't be replaced since it is not disconnected.` The original agent stays.

In the wrong-port case the agent did get its key; because it cannot reach the event port, it asks for a key again, and the manager refuses the name it has just registered. The real problem is the port in <server><port>, not the name.

Fix

Unreachable address: from the agent host, test TCP 1515 (enrollment) and 1514 (events) to the manager, for example nc -vz <manager> 1514 on Linux or Test-NetConnection <manager> -Port 1514 on Windows, and fix the address or the firewall.
Wrong event port: set <server><port> on the agent to the port of the manager's <connection>secure</connection> block (1514 by default) and restart the agent. Remove the stale Never connected entry if it does not recover.
Removed key: nothing to do if the agent re-enrolls, as ours did; delete the old entry if it stays. Expect a new agent ID.
Duplicate name: give each host a unique <agent_name> in its enrollment block, or remove the old agent first. Cloned VMs keep the hostname and the old client.keys.

Limits of what we measured

Measured on our Wazuh 4.14.7 lab with Linux agent containers (wazuh/wazuh-agent:4.14.7) and the default authd settings; Windows agents log the same daemon messages, but we did not run one for this note. We did not test password-protected enrollment, certificates, agents behind NAT or a proxy (see our note on agents that report 127.0.0.1), or other versions. The temporary agents were removed afterwards.