What the connector is
The connector is a single static Go binary that runs on a Linux host with systemd inside your own network. It dials out to Fleet over mTLS, reports that the host is online, and runs the Fleet services you enable on it. It opens no inbound port and it sends nothing about your Wazuh data to Fleet: it relays no reads and performs no writes against your indexer or Wazuh server API.
Every host in Fleet is reached this way, your own machines and Wazuh Cloud alike. Install the connector is the procedure. This page is what it does once it is running, and what it will not do.
Nothing ever connects in
The connector dials wss://connect.fleet.wazuh.com/connect, presents its client
certificate, and holds that session open. You open no inbound port and publish
no address.
The certificate is minted at enrolment from a key pair generated on the host, which never leaves it, and its subject carries the connector's own id, its tenant and its host. The gateway scopes every frame from that certificate alone, so a connector cannot ask for, or be handed, another host's traffic. Certificates are issued for 90 days and the connector renews its own at two thirds of that life. Connector lifecycle covers renewal, updates and revocation.
What travels on the session
The connector sends one thing unprompted: a heartbeat, every 30 seconds by default. It carries the connector's own id and version, the host's name, operating system, distribution, architecture and kernel, and the status of any services running on it. Nothing about the host beyond that: no CPU, disk or process list, and nothing about your Wazuh data.
Fleet answers each heartbeat, and its answer may ask the host to install or remove a service and to move to a newer connector version. That is the whole of what comes back. If a session goes quiet the gateway drops it after 75 seconds, and the connector ends a session itself once three heartbeat intervals pass with no acknowledgement, then redials. That watchdog arms only after the first acknowledgement, so a gateway that never acknowledges cannot turn into a redial storm.
There is no direct path from Fleet to a Wazuh deployment. The console holds no Wazuh credentials and the connector proxies no Wazuh reads, so Fleet reads nothing from a deployment. The heartbeat never carries the Wazuh login the installer may have found on the host. What Fleet shows is which hosts you have and what each one and its services report about themselves.
The connector relays nothing
Earlier connectors proxied read queries from Fleet to the local indexer and
Wazuh server API, holding your Wazuh credentials to do it. That path is gone.
The connector no longer relays reads, probes neither upstream, and performs no
writes. Active Response, the one write an earlier connector could carry, is
configured from Mobius now, not from Fleet: the connector ignores an
active_response block left in its configuration and says so once in its log.
The running connector discovers no Wazuh credentials. The installer looks, once, for the login a Wazuh node keeps, and the connector hands it only to the services installed on that host through Fleet. A service can also get its login from its own console, with its enrolment token, and that login replaces the one the installer found. Either way the service reaches its own upstream directly. The login stays on that machine and never travels to Fleet. See The Wazuh login the installer finds.
Egress and ports
| Direction | Endpoint | Port | What for |
|---|---|---|---|
| Outbound | connect.fleet.wazuh.com | 443 | Enrolment and certificate renewal over HTTPS, then the mTLS WebSocket session |
| Outbound | dl.fleet.wazuh.com | 443 | The installer, the binary and its checksum, and self-update artifacts |
| Inbound | none | none | Nothing connects in |
A Wazuh node is the convenient host, not a requirement: the connector opens no
Wazuh connection of its own, and a service you enable reaches whatever upstream
it needs. Behind a proxy the connector honours the standard HTTPS_PROXY,
HTTP_PROXY and NO_PROXY variables, for enrolment, renewal and the long-lived
session.
Two things can add an outbound destination to that table. A mirror install names its own download host in the configuration, and a host running a service fetches that service's artifacts from that service's own download site, never from a host named on the wire.
What Fleet can and cannot do
Making Fleet able to read or change a Wazuh deployment, rather than run services beside one, is a separate decision with a separate risk conversation, not an incremental feature. What Fleet can do is the honest list.