Resolving Filebeat Connection Refused Errors in Wazuh Deployments

Filebeat connection refused errors are among the most common data ingestion problems encountered in Wazuh deployments.

When Filebeat cannot establish a connection to the Wazuh Indexer, security events stop flowing through the logging pipeline, preventing alerts, dashboards, and threat detection workflows from functioning correctly.

Because Wazuh relies on Filebeat to forward alerts and security events from the Wazuh Manager to the Wazuh Indexer, any disruption in this communication path can significantly impact visibility across your environment.

Administrators may notice missing alerts, empty dashboards, delayed detections, or indexing failures shortly after the error appears.

In most cases, a “connection refused” error indicates that Filebeat successfully reached the destination host but the target service rejected the connection attempt.

This differs from network timeouts, DNS failures, or SSL certificate issues, each of which points to a different root cause.

This guide explains what Filebeat connection refused errors mean in Wazuh deployments, how Filebeat interacts with the Wazuh Indexer, and the most common causes behind these failures.

You’ll also learn a systematic troubleshooting process to identify and resolve the issue quickly.

If you’re experiencing broader indexing or cluster health issues, you may also find our guide on How to Build a Wazuh Indexer Cluster helpful.

Likewise, if your indexer is reporting shard allocation problems, see How to Fix a Yellow Cluster Status in Wazuh Indexer.

Understanding the Filebeat Connection Refused Error

What Does “Connection Refused” Mean?

A connection refused error occurs when Filebeat successfully reaches the target host but the destination port is not accepting incoming TCP connections.

From a networking perspective, the operating system on the destination server immediately returns a TCP RST (reset) packet, indicating that no application is listening on the requested port or that the connection is being actively rejected.

This is fundamentally different from a network timeout.

With a timeout, packets never receive a response.

With a connection refused error, the remote system responds immediately and explicitly rejects the connection.

TCP Connection Rejection Explained

When Filebeat attempts to send data to the Wazuh Indexer, the following sequence normally occurs:

Filebeat opens a TCP connection.
The target server receives the SYN packet.
The Wazuh Indexer service accepts the connection.
TLS negotiation begins (if enabled).
Data transmission starts.

In a connection refused scenario:

Filebeat sends a SYN packet.
The destination host responds with a TCP RST packet.
The connection terminates immediately.
Filebeat logs an error and retries using its backoff mechanism.

According to networking guidance from the Internet Engineering Task Force (IETF), a TCP reset is commonly used when a destination port has no listening service or actively rejects a connection request.

Difference Between Timeout, SSL, and Connection Refused Errors

Understanding the distinction between common Filebeat connectivity errors can significantly speed up troubleshooting.

Error Type	Typical Cause	Behavior
Connection Refused	Service not listening, wrong port, service down	Immediate failure
Connection Timeout	Firewall, routing issue, network interruption	Connection attempt hangs
SSL/TLS Error	Certificate mismatch, trust issues, hostname verification failure	Connection established but handshake fails
DNS Error	Invalid hostname or DNS failure	Host cannot be resolved

A connection refused error generally points toward service availability or port configuration issues rather than network reachability problems.

Typical Error Messages

Administrators frequently encounter messages similar to the following in Filebeat logs:

Failed to connect to backoff(elasticsearch(http://localhost:9200))

dial tcp 127.0.0.1:9200: connect: connection refused

ERROR pipeline/output.go

Failed to connect to Elasticsearch

These messages indicate that Filebeat attempted to connect to the configured output destination but the target endpoint rejected the connection.

You can typically find these errors in:

/var/log/filebeat/filebeat

or by using:

journalctl -u filebeat

How Filebeat Communicates in Wazuh Deployments

Understanding the communication flow helps narrow down where failures occur.

The standard architecture looks like this:

Endpoints
    ↓
Wazuh Agent
    ↓
Wazuh Manager
    ↓
Filebeat
    ↓
Wazuh Indexer
    ↓
Wazuh Dashboard

In this workflow:

Wazuh agents send events to the Wazuh Manager.
The Wazuh Manager processes and stores alerts.
Filebeat reads alert data from local files.
Filebeat forwards events to the Wazuh Indexer.
The Wazuh Dashboard retrieves indexed data for visualization.

When Filebeat cannot reach the indexer, data accumulates locally and dashboards stop receiving fresh security events.

Default Ports and Protocols

Typical Wazuh Indexer deployments use:

Service	Default Port
Wazuh Indexer HTTPS API	9200
OpenSearch Transport Layer	9300
Wazuh Dashboard	5601

Filebeat generally communicates with the Wazuh Indexer through HTTPS on port 9200.

The official Wazuh documentation recommends validating connectivity to the indexer endpoint before investigating higher-level configuration issues.

Role of Wazuh Manager, Filebeat, and Wazuh Indexer

Each component serves a distinct purpose:

Wazuh Manager

Collects and analyzes security events
Applies detection rules
Generates alerts

Filebeat

Reads generated alert files
Packages events for transport
Sends events to the Wazuh Indexer

Wazuh Indexer

Stores and indexes security data
Supports search operations
Provides data to the Wazuh Dashboard

Because Filebeat acts as the bridge between the Manager and Indexer, a connection refused error effectively breaks the entire alert ingestion pipeline.

Common Causes of Filebeat Connection Refused Errors

Wazuh Indexer Service Is Not Running

The most common cause is a stopped or failed Wazuh Indexer service.

If the indexer process is not listening on port 9200, Filebeat immediately receives a connection refused response.

Check service status:

systemctl status wazuh-indexer

Verify port availability:

ss -tulpn | grep 9200

If no process is listening on port 9200, restart the indexer:

systemctl restart wazuh-indexer

For environments experiencing crashes or unexpected process termination, see Troubleshooting Wazuh Manager Core Dumps for broader service stability guidance.

Incorrect Hostname or IP Address Configuration

A surprisingly common issue is an incorrect host definition in filebeat.yml.

Example:

output.elasticsearch:
  hosts:
    - https://localhost:9200

If the indexer resides on another server, localhost points to the wrong machine.

Verify the configured host:

grep hosts /etc/filebeat/filebeat.yml

Ensure the address matches the actual Wazuh Indexer node.

Wrong Port Configuration

Administrators occasionally configure Filebeat to use:

https://server:9300

instead of:

https://server:9200

Port 9300 is reserved for cluster transport communications and should not be used by Filebeat.

Verify the configured output port and compare it against the indexer’s listening ports.

Firewall Blocking Connections

Firewalls can block inbound access even when services are healthy.

Common examples include:

firewalld
iptables
nftables
Cloud security groups
Network ACLs

Test connectivity:

telnet indexer-host 9200

or:

nc -zv indexer-host 9200

If the connection cannot be established, review firewall policies on both systems.

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) recommends regularly validating network paths between security monitoring components to prevent telemetry disruptions.

SSL/TLS Misconfiguration

A certificate issue can occasionally appear similar to a connection problem, particularly when Filebeat repeatedly retries failed connections.

Common causes include:

Expired certificates
Incorrect CA files
Hostname mismatches
Invalid certificate chains

Validate the endpoint manually:

openssl s_client -connect indexer-host:9200

If certificate-related errors appear, review your SSL configuration.

For certificate-specific troubleshooting, see Internal Link: How to Fix Wazuh Certificate Errors.

DNS Resolution Problems

If Filebeat references a hostname that resolves incorrectly, connections may be directed to the wrong destination.

Verify resolution:

nslookup indexer-host

or:

dig indexer-host

Confirm that the returned IP address matches the intended Wazuh Indexer node.

Network Connectivity Failures

Routing issues can prevent Filebeat from reaching the indexer.

Useful diagnostics include:

ping indexer-host

traceroute indexer-host

mtr indexer-host

Network interruptions are especially common after infrastructure changes, VLAN migrations, or cloud networking modifications.

Container or Kubernetes Networking Issues

In containerized environments, networking introduces additional complexity.

Potential causes include:

Incorrect Kubernetes Service definitions
NetworkPolicy restrictions
Misconfigured ingress rules
Expired service endpoints
Pod-to-pod communication failures

Verify service availability:

kubectl get svc

kubectl get endpoints

kubectl describe service wazuh-indexer

If you’re running Wazuh on Kubernetes, you may also want to review How to Monitor Kubernetes Using Wazuh.

Resource Exhaustion on the Indexer Node

An overloaded indexer may stop accepting connections even though the service remains technically running.

Warning signs include:

High CPU utilization
Memory exhaustion
Disk saturation
Excessive garbage collection activity
OpenSearch heap pressure

Check system health:

top

free -h

df -h

curl -k -u admin:password https://localhost:9200/_cluster/health?pretty

OpenSearch experts generally recommend keeping JVM heap utilization below critical thresholds and maintaining sufficient free disk space to avoid service degradation.

For environments experiencing memory-related instability, review How to Tune OpenSearch Heap Size to Stop Wazuh High Memory Crashes.

Additional OpenSearch operational guidance can be found in the official documentation.

Step 1: Verify Wazuh Indexer Status

Before investigating networking, SSL, or Filebeat configuration issues, verify that the Wazuh Indexer is actually running.

A stopped indexer service is the most common reason behind Filebeat connection refused errors.

Check Service Status

Start by checking whether the indexer service is active:

systemctl status wazuh-indexer

A healthy service should show output similar to:

Active: active (running)

If you see:

Active: inactive

or:

Active: failed

Filebeat will be unable to establish a connection.

Pay special attention to:

Service state
Recent error messages
Startup failures
Resource-related warnings
Java exceptions

Start the Service if Necessary

If the service is stopped, start it manually:

systemctl start wazuh-indexer

To ensure the service starts automatically after reboot:

systemctl enable wazuh-indexer

After starting the service, verify its status again:

systemctl status wazuh-indexer

If the service immediately exits or fails to start, investigate the logs before proceeding.

Review Indexer Logs

Indexer logs often reveal the exact reason the service is unavailable.

Monitor logs in real time:

journalctl -u wazuh-indexer -f

Look for messages related to:

JVM heap exhaustion
Disk space shortages
Corrupted indices
Cluster formation failures
Certificate validation errors
Permission problems

Common examples include:

OutOfMemoryError

Failed to bind to port

Cluster health status RED

SSL handshake failed

If the node is part of a multi-node deployment, cluster formation issues may prevent the service from becoming fully operational.

Confirm the Listening Port

Even if the service appears healthy, verify that it is actually listening on the expected port.

Check active listeners:

ss -tulpn | grep 9200

Expected output should resemble:

tcp LISTEN 0 128 0.0.0.0:9200

tcp LISTEN 0 128 [::]:9200

If nothing is returned, the indexer is not accepting connections on port 9200.

You can also verify using:

netstat -tulpn | grep 9200

If the indexer is listening on a different port, update the Filebeat configuration accordingly.

Step 2: Test Connectivity from the Filebeat Host

Once you’ve confirmed that the Wazuh Indexer is running, the next step is verifying that the Filebeat server can actually reach it over the network.

This helps determine whether the issue lies with networking, firewall rules, DNS resolution, or service availability.

Verify Basic Network Reachability

Start with a simple ICMP test:

ping <indexer-host>

Example:

ping wazuh-indexer.example.com

Successful responses indicate that the destination host is reachable.

Example:

64 bytes from 10.0.1.15

If the host cannot be reached:

Destination Host Unreachable

Request timed out

you likely have a routing, firewall, or DNS problem.

Keep in mind that some environments intentionally block ICMP traffic, so a failed ping alone does not prove connectivity is broken.

Test Port Accessibility

After confirming the host is reachable, test whether port 9200 is accepting connections.

Using Telnet:

telnet <indexer-host> 9200

Example:

telnet wazuh-indexer.example.com 9200

A successful connection usually produces:

Connected to host

Alternatively, use Netcat:

nc -zv <indexer-host> 9200

Example output:

Connection to 10.0.1.15 9200 port [tcp/*] succeeded!

If you receive:

Connection refused

the indexer is either:

Not running
Not listening on port 9200
Listening on a different interface
Being blocked by a security control

Validate HTTP/HTTPS Responses

Since Wazuh Indexer typically uses HTTPS, test the API endpoint directly:

curl -k https://<indexer-host>:9200

Example:

curl -k https://wazuh-indexer.example.com:9200

A healthy response generally returns JSON data similar to:

{
  "name": "indexer-node-1",
  "cluster_name": "wazuh-cluster"
}

This confirms:

DNS resolution works
Network connectivity works
Port accessibility works
The service is accepting requests

You can also verify authentication:

curl -k -u admin:password https://<indexer-host>:9200

Interpret the Results

The results can quickly narrow down the root cause:

Result	Likely Cause
Host unreachable	Routing or network issue
Ping works, port closed	Service not running
Connection refused	Port not listening
Timeout	Firewall or ACL blocking traffic
SSL error	Certificate problem
HTTP response returned	Connectivity is healthy

If connectivity tests succeed but Filebeat still reports failures, the problem is likely within the Filebeat configuration itself.

Step 3: Review Filebeat Configuration

A large percentage of Filebeat connection refused errors are caused by configuration mistakes.

Even a single incorrect hostname, port number, SSL setting, or credential can prevent successful communication with the Wazuh Indexer.

Locate the Filebeat Configuration File

The primary configuration file is usually located at:

/etc/filebeat/filebeat.yml

Open the file using your preferred editor:

nano /etc/filebeat/filebeat.yml

vim /etc/filebeat/filebeat.yml

Always create a backup before making changes:

cp /etc/filebeat/filebeat.yml /etc/filebeat/filebeat.yml.bak

Verify Output Settings

Locate the Elasticsearch output section:

output.elasticsearch:
  hosts:
    - https://indexer.example.com:9200

Confirm that:

The hostname is correct
The protocol is correct
The port number is correct
The destination matches the active indexer node

Many administrators accidentally leave:

https://localhost:9200

after migrating the indexer to another server.

This causes Filebeat to attempt connecting to itself instead of the intended destination.

Check for Hostname and Port Errors

Review the configured host carefully.

Common mistakes include:

https://indexer:9300

https://indexer:9201

https://localhost:9200

Port 9200 is typically used for Filebeat-to-Indexer communications.

You can compare the configured port against the actual listening port:

ss -tulpn | grep 9200

Validate SSL Settings

Most Wazuh deployments use TLS encryption.

Typical configuration:

output.elasticsearch:
  hosts:
    - https://indexer.example.com:9200

  ssl.certificate_authorities:
    - /etc/filebeat/certs/root-ca.pem

Verify:

CA certificate paths
Certificate permissions
File existence
Certificate validity

You can inspect certificates with:

openssl x509 -in root-ca.pem -text -noout

For certificate-specific troubleshooting, see:

Internal Link: How to Fix Wazuh Certificate Errors

Verify Authentication Credentials

Confirm that Filebeat is using valid credentials:

output.elasticsearch:
  username: admin
  password: strongpassword

Authentication failures generally produce HTTP 401 or HTTP 403 errors rather than connection refused errors.

However, it’s worth validating credentials while reviewing the configuration.

You can manually test authentication:

curl -k -u admin:password https://indexer.example.com:9200

The official Filebeat documentation provides additional examples for output configuration and authentication settings.

Step 4: Validate Filebeat Configuration Syntax

Even if the configuration appears correct, syntax errors can prevent Filebeat from loading settings properly.

Before restarting services, always validate the configuration.

Run Configuration Validation

Filebeat includes a built-in validation tool:

filebeat test config

Expected output:

Config OK

If errors exist, Filebeat reports the exact line number.

Example:

Exiting: error loading config file

Common causes include:

Missing spaces
Incorrect YAML indentation
Invalid field names
Missing quotation marks

YAML formatting issues are particularly common because indentation is significant.

Test Connectivity Through Filebeat

Once the configuration passes validation, test actual connectivity:

filebeat test output

A successful test typically returns:

Connection to backoff(elasticsearch(...)) established

This command verifies:

Hostname resolution
Port connectivity
SSL negotiation
Authentication
Output configuration

Because the test uses Filebeat’s own configuration, it is often more reliable than standalone curl tests.

Understanding Common Validation Errors

Here are some common examples:

Invalid YAML

yaml: line 45: did not find expected key

Cause:

Broken indentation
Missing colon

Connection Refused

dial tcp 10.0.1.15:9200: connect: connection refused

Cause:

Service unavailable
Wrong port

SSL Errors

x509: certificate signed by unknown authority

Cause:

Incorrect CA configuration

Authentication Errors

401 Unauthorized

Cause:

Invalid username or password

If configuration validation succeeds but Filebeat still cannot connect, continue with firewall and network security inspections.

Step 5: Inspect Firewall and Security Controls

Security controls frequently block Filebeat communications even when both systems are configured correctly.

Modern environments often include multiple layers of filtering, including host firewalls, cloud security groups, network ACLs, and segmentation policies.

Linux Firewall Rules

If you’re using firewalld, inspect active rules:

firewall-cmd --list-all

Verify that port 9200 is permitted.

To allow the port:

firewall-cmd --permanent --add-port=9200/tcp
firewall-cmd --reload

Then retest connectivity.

UFW Configuration

Ubuntu-based systems commonly use UFW.

Check active rules:

ufw status

Example:

9200/tcp ALLOW Anywhere

If the port is not allowed:

ufw allow 9200/tcp

Reload and retest.

Cloud Security Groups

Cloud providers often introduce additional filtering layers that override local firewall settings.

AWS Security Groups

Verify:

Inbound TCP 9200 is allowed
Source IP includes the Filebeat host
Security group associations are correct

The AWS networking documentation recommends validating both security groups and network ACLs when troubleshooting application connectivity.

Azure NSGs

Review:

Network Security Group rules
Priority ordering
Source and destination restrictions
Deny rules overriding allow rules

Google Cloud Firewall Rules

Check:

Firewall policies
Target tags
Service account restrictions
VPC routing configuration

Network Segmentation Issues

Large enterprises frequently isolate workloads using:

VLANs
Microsegmentation
Zero Trust policies
Software-defined networking controls

In these environments, connectivity can fail even when:

DNS works
Ping succeeds
Firewall rules appear correct

Coordinate with network administrators to verify:

East-west traffic policies
Inter-subnet routing
Access control lists
Security appliance rules

The U.S. National Institute of Standards and Technology (NIST) notes that network segmentation improves security but can inadvertently disrupt monitoring pipelines if connectivity requirements are not explicitly documented and maintained.

Step 6: Troubleshoot SSL/TLS Connectivity Problems

In many Wazuh environments, Filebeat communicates with the Wazuh Indexer over HTTPS. When certificates, trust chains, or TLS settings are misconfigured, Filebeat may fail to establish a secure connection and repeatedly retry.

Although SSL errors often produce certificate-related messages rather than explicit connection refused errors, they are frequently encountered during connectivity troubleshooting and should be verified early in the process.

Verify Certificates

Start by confirming that all required certificates exist and are accessible.

Common certificate locations include:

/etc/filebeat/certs/
/etc/wazuh-indexer/certs/

Verify files:

ls -lah /etc/filebeat/certs/

Ensure:

Files exist
Permissions are correct
The Filebeat service account can read them
Certificate paths match the configuration

Review your Filebeat SSL configuration:

output.elasticsearch:
  hosts:
    - https://indexer.example.com:9200

  ssl.certificate_authorities:
    - /etc/filebeat/certs/root-ca.pem

Test TLS Handshake

One of the most useful SSL troubleshooting tools is OpenSSL.

Run:

openssl s_client -connect <indexer-host>:9200

Example:

openssl s_client -connect wazuh-indexer.example.com:9200

A successful handshake should display:

Server certificate information
Certificate chain details
Negotiated TLS version
Cipher suite information

Look for:

Verify return code: 0 (ok)

This indicates that certificate validation succeeded.

Common failure messages include:

certificate verify failed

unable to get local issuer certificate

handshake failure

certificate has expired

Check Certificate Expiration

Expired certificates are a common cause of communication failures.

Inspect a certificate directly:

openssl x509 -in server.pem -noout -dates

Example output:

notBefore=Jan 1 00:00:00 2025 GMT
notAfter=Jan 1 00:00:00 2027 GMT

If the current date exceeds the notAfter value, replace the certificate immediately.

The official TLS guidance from the Internet Security Research Group emphasizes proactive certificate lifecycle management to prevent unexpected service outages.

Outbound Link: https://letsencrypt.org/

Validate CA Trust Configuration

Filebeat must trust the certificate authority that issued the indexer’s certificate.

Verify the configured CA:

ssl.certificate_authorities:
  - /etc/filebeat/certs/root-ca.pem

Then confirm the certificate chain:

openssl verify -CAfile root-ca.pem server.pem

Expected result:

server.pem: OK

Any validation error indicates a trust-chain issue that must be corrected before Filebeat can establish a secure connection.

Common SSL Mistakes in Wazuh Deployments

The following mistakes are frequently encountered:

Expired certificates
Incorrect certificate paths
Wrong CA certificates
Hostname mismatches
Missing intermediate certificates
Self-signed certificates not trusted by Filebeat
Mixing HTTP and HTTPS configurations

If you’re already troubleshooting certificate-related errors, review:

How to Fix Wazuh Certificate Errors

Step 7: Analyze Filebeat Logs

Filebeat logs often contain the exact error message needed to identify the root cause.

Whenever a connection refused issue persists, detailed log analysis should be one of your highest priorities.

Locate Filebeat Log Files

Depending on your operating system and deployment method, logs may be stored in:

/var/log/filebeat/

or accessible through systemd:

journalctl -u filebeat

You can continuously monitor logs using:

journalctl -u filebeat -f

This allows you to observe events as Filebeat retries failed connections.

Enable Debug Logging

Standard logging may not provide enough detail.

Launch Filebeat with full debugging enabled:

filebeat -e -d "*"

This increases verbosity and exposes:

Connection attempts
SSL negotiation details
Authentication failures
Output pipeline errors
DNS lookups

Elastic engineers frequently recommend enabling debug output when troubleshooting persistent connectivity problems because it reveals internal connection state changes that are hidden in standard logs.

Key Log Messages to Look For

Pay close attention to messages such as:

Connection Refused

dial tcp 10.0.1.15:9200: connect: connection refused

Usually indicates:

Service down
Wrong port
Listener unavailable

DNS Failure

lookup indexer.example.com: no such host

Usually indicates:

DNS misconfiguration
Invalid hostname

SSL Failure

x509: certificate signed by unknown authority

Usually indicates:

Incorrect CA configuration

Authentication Failure

401 Unauthorized

Usually indicates:

Invalid credentials

Connection Timeout

context deadline exceeded

Usually indicates:

Firewall restrictions
Routing issues

Correlating Filebeat and Indexer Logs

One of the fastest ways to identify problems is to compare Filebeat and Indexer logs simultaneously.

For example:

Filebeat Log	Indexer Log
Connection refused	No listener available
SSL handshake failed	Certificate validation failure
Authentication failed	Invalid credentials
Timeout	No incoming connection observed

Checking both sides of the connection often reveals exactly where communication is breaking down.

For additional indexing-related troubleshooting, see:

Fix Wazuh Logcollector Dropped Messages

Step 8: Troubleshooting Wazuh Docker Deployments

Containerized Wazuh environments introduce additional networking layers that can create connectivity problems even when service configurations appear correct.

Verify Container Status

Start by confirming that all required containers are running.

docker ps

You should see containers similar to:

wazuh.manager
wazuh.indexer
filebeat
wazuh.dashboard

If the indexer container is stopped, Filebeat will immediately encounter connection failures.

Inspect container status:

docker inspect <container>

Check Docker Network Connectivity

Verify that Filebeat and the Wazuh Indexer are attached to the same Docker network.

View available networks:

docker network ls

Inspect network membership:

docker network inspect <network-name>

Common issues include:

Containers on different networks
Missing bridge configuration
Incorrect DNS aliases
Custom network isolation

Inspect Container Logs

Container logs frequently reveal startup or connectivity issues.

Review Filebeat logs:

docker logs filebeat

Review Indexer logs:

docker logs wazuh.indexer

Look for:

SSL errors
Port binding failures
Authentication failures
Memory exhaustion
Cluster initialization problems

Common Docker Networking Misconfigurations

Some of the most common Docker-related causes include:

Incorrect container hostname references
Missing Docker network attachments
Unpublished ports
Incorrect Compose configuration
DNS resolution failures within containers

Verify hostname resolution from inside the Filebeat container:

docker exec -it filebeat ping wazuh.indexer

If the hostname cannot be resolved, Docker DNS configuration is likely the problem.

Step 9: Troubleshooting Wazuh Kubernetes Deployments

Kubernetes deployments introduce additional networking abstractions that can complicate troubleshooting.

Verify Pod Health

Begin by confirming that all pods are healthy.

kubectl get pods

Look for:

Running

and avoid pods showing:

CrashLoopBackOff

Error

Pending

If the indexer pod is restarting continuously, Filebeat will not maintain a stable connection.

Check Service Configuration

Verify Kubernetes services:

kubectl get svc

Inspect the Wazuh Indexer service:

kubectl describe svc wazuh-indexer

Confirm:

Port mappings
Service selectors
Endpoint assignments
ClusterIP configuration

Validate Cluster Networking

Check whether endpoints exist:

kubectl get endpoints

Missing endpoints typically indicate:

Selector mismatches
Unhealthy pods
Service misconfiguration

If you’re using Network Policies, verify that traffic between Filebeat and the indexer is permitted.

Examine Pod Logs

Review Filebeat logs:

kubectl logs <filebeat-pod>

Example:

kubectl logs filebeat-58f8d9f9

Review Indexer logs:

kubectl logs <indexer-pod>

Look for:

TLS failures
Authentication problems
Service startup failures
Resource constraints

For broader Kubernetes monitoring guidance, see:

How to Monitor Kubernetes Using Wazuh

Step 10: Check Resource Availability

Resource exhaustion can prevent the Wazuh Indexer from accepting new connections, even when the service appears to be running.

Verify Available Memory

Check system memory:

free -h

Pay attention to:

Available memory
Swap usage
Cached memory
Memory pressure

Warning signs include:

Available: < 500 MB

or excessive swap utilization.

Check Disk Space

Disk exhaustion is a common cause of indexing failures.

Inspect storage utilization:

df -h

Critical usage levels:

90%+

95%+

can cause OpenSearch-based services to reject indexing operations.

The OpenSearch project recommends maintaining sufficient free disk space to avoid triggering cluster protection mechanisms.

Monitor CPU Utilization

Check CPU activity:

top

or:

htop

Look for:

Sustained CPU saturation
Excessive Java processes
High load averages
Resource contention

High CPU utilization may delay or prevent network request processing.

Identify Resource-Related Service Failures

Common symptoms include:

Frequent service restarts
Cluster instability
Slow query responses
Delayed indexing
Rejected connections

Useful diagnostic commands:

dmesg | grep -i oom

journalctl -xe

systemctl status wazuh-indexer

If memory pressure is causing instability, see:

How to Tune OpenSearch Heap Size to Stop Wazuh High Memory Crashes

and

Why Is Wazuh Using High CPU? Troubleshooting Guide

Advanced Diagnostics

If the previous troubleshooting steps have not resolved the issue, advanced diagnostics can help identify subtle networking and infrastructure problems.

Use Packet Capture to Analyze Connections

Packet captures reveal exactly what happens during connection attempts.

Capture traffic on port 9200:

tcpdump -i any port 9200

During a failed connection, you may observe:

TCP SYN packets
TCP RST packets
TLS handshake failures
Firewall interference

A TCP reset immediately after the SYN packet usually confirms a connection refused condition.

Verify Listening Interfaces

Confirm which interfaces the indexer is listening on:

ss -tulpn

Example:

0.0.0.0:9200

accepts connections from any interface.

However:

127.0.0.1:9200

only accepts local connections and commonly causes remote Filebeat failures.

Check DNS Resolution

Verify hostname resolution:

nslookup <indexer-host>

Example:

nslookup wazuh-indexer.example.com

Also verify reverse lookups:

dig -x <ip-address>

DNS inconsistencies frequently appear after migrations, failovers, and infrastructure changes.

Investigate Reverse Proxy Configurations

Some deployments place a reverse proxy in front of the Wazuh Indexer.

Examples include:

NGINX
HAProxy
Traefik
Apache HTTP Server

Potential issues include:

Incorrect backend targets
SSL termination problems
Missing port mappings
Timeout settings
Access control restrictions

Review proxy logs alongside Filebeat and Indexer logs to determine whether requests are reaching the backend service.

For production environments, maintaining visibility across every layer.

Filebeat, network, proxy, and indexer is often the fastest way to isolate persistent connection refused errors.

Best Practices to Prevent Filebeat Connection Refused Errors

While most Filebeat connection refused errors can be resolved through systematic troubleshooting, preventing them from occurring in the first place is far more effective.

Implementing operational best practices can significantly reduce downtime and improve the reliability of your Wazuh logging pipeline.

Implement Service Health Monitoring

Continuous monitoring helps identify service failures before they impact security visibility.

At a minimum, monitor:

Wazuh Indexer service status
Filebeat service status
Port 9200 availability
Cluster health status
JVM memory utilization
Disk consumption

Useful monitoring methods include:

systemctl is-active wazuh-indexer

systemctl is-active filebeat

You can also create automated health checks that periodically test the indexer API endpoint:

curl -k https://indexer.example.com:9200

Security monitoring platforms should alert administrators immediately when connectivity failures occur rather than waiting for users to notice missing alerts.

Configure High Availability for Wazuh Indexer

Single-node deployments create a single point of failure.

If the only indexer node becomes unavailable:

Filebeat cannot send data
Alerts stop being indexed
Dashboards stop updating

For production environments, consider:

Multi-node Wazuh Indexer clusters
Redundant storage
Load balancing
Automated failover mechanisms

Organizations following high-availability best practices typically experience significantly fewer ingestion outages than single-node deployments.

For deployment guidance, see:

Internal Link: How to Build a Wazuh Indexer Cluster

Use Consistent DNS and Naming Standards

Many connection failures occur after infrastructure changes.

Common examples include:

Server migrations
IP address changes
Cloud instance replacements
Kubernetes redeployments

Using DNS names rather than hard-coded IP addresses makes environments easier to maintain.

Recommended naming practices:

wazuh-indexer.company.local

instead of:

10.10.15.23

Consistent naming standards reduce configuration drift and simplify troubleshooting.

Regularly Audit Firewall Rules

Firewall changes are one of the most common causes of unexpected connectivity failures.

Regularly review:

Host firewalls
Cloud security groups
Network ACLs
Kubernetes network policies
Segmentation policies

Document required communication paths, including:

Source	Destination	Port
Filebeat	Wazuh Indexer	9200
Dashboard	Wazuh Indexer	9200
Indexer Nodes	Indexer Nodes	9300

Periodic firewall audits help prevent accidental service disruptions.

Monitor Certificate Expiration

Certificate-related outages are entirely preventable.

Track:

Certificate expiration dates
Intermediate certificate validity
CA certificate validity
Certificate renewal schedules

Check expiration manually:

openssl x509 -in server.pem -noout -dates

Automated certificate monitoring tools can alert administrators weeks before expiration.

The official guidance from Let’s Encrypt recommends automating certificate renewal wherever possible to eliminate human error.

Perform Connectivity Validation After Changes

Any infrastructure change can potentially break connectivity.

Examples include:

Upgrades
Firewall modifications
Certificate renewals
DNS changes
Cluster migrations

After every change, verify connectivity:

filebeat test output

curl -k https://indexer.example.com:9200

nc -zv indexer.example.com 9200

Post-change validation frequently identifies problems before they impact production operations.

Maintain Capacity Planning and Resource Monitoring

Resource exhaustion is often overlooked until services begin failing.

Monitor:

CPU utilization
Memory usage
JVM heap usage
Storage consumption
Index growth rates

The OpenSearch project recommends proactive capacity planning to avoid indexing bottlenecks and service instability caused by resource shortages.

As environments grow, regular capacity reviews become increasingly important.

Use the following checklist whenever a connection refused error occurs:

Confirm Wazuh Indexer Is Running

systemctl status wazuh-indexer

Verify:

Service is active
Port 9200 is listening
No startup failures exist

Verify Hostname and Port Settings

Review:

output.elasticsearch:
  hosts:
    - https://indexer.example.com:9200

Confirm:

Correct hostname
Correct protocol
Correct port

Test Network Connectivity

Verify reachability:

ping indexer.example.com

nc -zv indexer.example.com 9200

Review Firewall Rules

Check:

firewall-cmd --list-all

ufw status

Also review cloud security controls.

Validate SSL Certificates

Verify certificates:

openssl s_client -connect indexer.example.com:9200

Check:

Expiration
Trust chain
Hostname validation

Check Filebeat Configuration Syntax

Validate configuration:

filebeat test config

Test connectivity:

filebeat test output

Inspect Logs on Both Systems

Review:

journalctl -u filebeat -f

journalctl -u wazuh-indexer -f

Correlating logs often reveals the root cause quickly.

Verify Resource Availability

Check:

free -h

df -h

top

Resource shortages can indirectly trigger service failures and connection errors.

Frequently Asked Questions (FAQ)

Question: What causes Filebeat connection refused errors in Wazuh?

The most common causes include:

Wazuh Indexer service not running
Incorrect hostname configuration
Incorrect port configuration
Firewall restrictions
DNS resolution failures
Container networking issues
Resource exhaustion

In most environments, the issue is ultimately traced to an unavailable indexer service or incorrect Filebeat output settings.

Question: How do I test if Wazuh Indexer is accepting connections?

You can test connectivity using:

curl -k https://<indexer-host>:9200

or:

nc -zv <indexer-host> 9200

A successful response confirms that the service is reachable and accepting connections.

Question: What port does Filebeat use to connect to Wazuh Indexer?

By default, Filebeat communicates with the Wazuh Indexer using:

TCP 9200

Port 9300 is typically reserved for internal cluster communications and should not be used for Filebeat output traffic.

Question: Can firewall rules cause connection refused errors?

Yes.

Host firewalls, cloud security groups, network ACLs, and segmentation policies can all prevent Filebeat from reaching the Wazuh Indexer.

Always verify firewall configurations when troubleshooting connectivity issues.

Question: How do I verify Filebeat output connectivity?

Use the built-in Filebeat test command:

filebeat test output

This verifies:

DNS resolution
Network connectivity
SSL configuration
Authentication
Output settings

It is often the fastest way to validate end-to-end communication.

Question: What is the difference between connection refused and connection timeout?

A connection refused error means:

The destination host responded.
The requested port was not accepting connections.

A connection timeout means:

No response was received.
Packets were dropped or blocked somewhere along the network path.

Connection refused errors generally indicate service availability issues, while timeouts typically indicate networking or firewall problems.

Question: Can SSL certificate issues trigger connection refused errors?

Typically no.

SSL certificate problems usually generate:

certificate verify failed

or:

x509 errors

However, SSL misconfigurations are frequently investigated alongside connection issues because they affect the same communication path.

Question: How do I troubleshoot Filebeat in Docker deployments?

Start by verifying:

docker ps

Then inspect:

docker logs filebeat

Also verify:

Docker network membership
Container hostname resolution
Port mappings
Compose configuration

Container networking issues are among the most common causes of Docker-related connectivity failures.

Question: How do I troubleshoot Filebeat in Kubernetes environments?

Check:

kubectl get pods

kubectl get svc

kubectl logs <filebeat-pod>

Additionally verify:

Network policies
Service endpoints
DNS resolution
Pod health

Question: Why does Filebeat connect successfully but later lose connectivity?

Intermittent connectivity often indicates:

Resource exhaustion
Service crashes
Cluster instability
Network interruptions
Certificate expiration
Firewall policy changes

Monitoring both Filebeat and Wazuh Indexer logs can help identify the exact failure point.

Question: Can resource exhaustion cause Filebeat connection failures?

Yes.

If the Wazuh Indexer becomes overloaded, it may stop accepting new connections or become unstable.

Common causes include:

Memory exhaustion
Full disks
Excessive CPU utilization
JVM heap pressure

Resource monitoring should be part of every production deployment.

Question: How can I proactively monitor Filebeat-to-Indexer connectivity?

Recommended approaches include:

Automated API health checks
Port availability monitoring
Synthetic transaction testing
Service health monitoring
Cluster health monitoring
Log-based alerting

Useful checks include:

filebeat test output

curl -k https://indexer.example.com:9200

systemctl status filebeat

Proactive monitoring dramatically reduces mean time to detection (MTTD) and minimizes the impact of ingestion failures.

Conclusion

Filebeat connection refused errors in Wazuh deployments typically occur when Filebeat cannot establish a TCP connection to the Wazuh Indexer.

Although the error itself appears simple, the underlying causes can range from stopped services and incorrect configuration settings to firewall restrictions, SSL problems, networking issues, and resource exhaustion.

A structured troubleshooting approach is the most effective way to resolve these incidents.

Start by confirming that the Wazuh Indexer is running and listening on the expected port.

Next, validate network connectivity, review Filebeat output settings, verify SSL certificates, inspect firewall policies, and analyze logs on both systems. In containerized and Kubernetes deployments, additional attention should be given to service discovery and networking configuration.

To minimize future outages, organizations should implement continuous service monitoring, maintain high-availability indexer deployments, monitor certificate expiration, perform routine firewall audits, and regularly validate connectivity after infrastructure changes.

Capacity planning and resource monitoring are equally important to ensure that the indexer remains healthy as data volumes grow.

Ultimately, maintaining continuous visibility into both Filebeat and Wazuh Indexer health is essential for reliable log ingestion.

By combining proactive monitoring with disciplined operational practices, you can prevent most Filebeat connection refused errors before they impact your security operations and ensure that critical security events continue flowing through your Wazuh environment without interruption.

For related troubleshooting topics, you may also find these guides useful: