In many organizations, endpoints are no longer located on a single flat network. Employees work remotely, branch offices connect through WAN links, workloads run across multiple cloud providers, and production systems often reside behind firewalls or within isolated network segments. While this distributed architecture improves scalability and resilience, it also introduces challenges for securely connecting Wazuh agents to a centralized Wazuh manager. A Wazuh proxy helps solve this problem by acting as an intermediary between agents and the Wazuh manager.

Rather than exposing the manager directly to every remote endpoint, organizations can deploy one or more proxy servers to relay agent traffic across trusted network boundaries.

This approach improves security, simplifies firewall configuration, and enables large-scale deployments spanning multiple geographic locations.

In this guide, you’ll learn what a Wazuh proxy is, how it fits into the Wazuh communication architecture, when it should be deployed, and how to configure it correctly.

You’ll also learn deployment best practices, security considerations, troubleshooting techniques, and common mistakes to avoid when designing proxy-based Wazuh environments.

What Is a Wazuh Proxy?

A Wazuh proxy is an intermediary server that forwards communication between Wazuh agents and the Wazuh manager without requiring every endpoint to establish a direct connection.

The proxy sits between remote systems and the manager, relaying encrypted agent traffic while allowing the manager to remain protected behind internal network boundaries.

Unlike traditional HTTP web proxies, a Wazuh proxy is typically implemented using a TCP forwarding service such as HAProxy, NGINX Stream, or a layer-4 load balancer.

Because Wazuh agent communication uses encrypted TCP connections rather than HTTP, the proxy forwards packets at the transport layer instead of interpreting application data.

Organizations commonly deploy proxies with Wazuh to:

• Reduce direct exposure of the Wazuh manager
• Simplify firewall rule management
• Connect remote offices securely
• Support geographically distributed agents
• Improve scalability in large environments
• Centralize network ingress points

For example, instead of opening firewall access from dozens of branch offices to an internal Wazuh manager, each branch can communicate with a nearby proxy that securely forwards traffic to the manager.

This reduces administrative overhead while maintaining secure communications.

Benefits of Using a Wazuh Proxy

Deploying a proxy provides several operational and security advantages:

• Reduces the attack surface by limiting direct access to the Wazuh manager
• Simplifies firewall configurations across multiple locations
• Enables centralized ingress for thousands of agents
• Supports segmented and zero-trust network architectures
• Allows easier integration with cloud and hybrid deployments
• Makes future scaling and load balancing simpler

Large enterprise security teams frequently use reverse proxies and TCP load balancers to protect critical infrastructure rather than exposing management servers directly.

This layered network design aligns with guidance from organizations such as the National Institute of Standards and Technology (NIST), which recommends segmentation, boundary protection, and defense-in-depth architectures.

When You Should Deploy a Proxy

A proxy is recommended when:

• Agents are located in multiple geographic regions.
• Firewall policies prohibit direct manager access.
• Systems communicate across untrusted networks.
• The manager must remain isolated within an internal network.
• You expect the deployment to grow significantly over time.
• Regulatory or compliance requirements limit inbound connectivity.

When a Proxy May Not Be Necessary

Not every Wazuh deployment benefits from an additional proxy layer.

Small environments where all agents reside on the same trusted network often communicate directly with the manager without introducing unnecessary complexity.

Similarly, lab environments or proof-of-concept deployments generally do not require an intermediary unless they are specifically testing production-like network architectures.

Tip: A proxy improves network architecture and security, but it is not a replacement for TLS encryption, authentication, or proper firewall configuration.

How Wazuh Agent Communication Works

Before configuring a proxy, it’s important to understand how Wazuh components normally communicate.

A proxy does not replace any part of the Wazuh architecture, it simply forwards traffic between existing components.

Overview of the Wazuh Communication Architecture

A standard Wazuh deployment consists of several core components working together:

• Wazuh Manager
• Wazuh Agents
• Agent registration service
• Secure communication channel
• Wazuh Indexer
• Wazuh Dashboard

Related Guide: The Complete Wazuh Cluster Architecture Guide

In most deployments, the proxy sits between the agents and the manager while leaving the rest of the architecture unchanged.

Wazuh Manager

The Wazuh manager serves as the central security analysis engine. It:

• Receives events from agents
• Performs decoding and rule matching
• Executes active responses
• Generates alerts
• Sends data to the Wazuh Indexer

Related Guide: Step-by-Step Wazuh Manager Scaling Guide

Because the manager is responsible for security analysis, organizations generally avoid exposing it directly to the public Internet.

Wazuh Agents

Agents are installed on monitored endpoints such as:

• Windows servers
• Linux servers
• macOS systems
• Virtual machines
• Cloud instances
• Containers

They collect:

• Log files
• File integrity events
• Security configuration assessments
• Process information
• Rootcheck results
• Vulnerability data

The collected telemetry is securely transmitted to the manager over encrypted TCP connections.

Related Guide: The Ultimate Wazuh Agent Deployment Guide

Registration Service

Before an agent can communicate with the manager, it must first register and receive authentication credentials.

The registration process establishes trust between the agent and the manager by exchanging authentication keys that uniquely identify each endpoint.

After registration completes successfully, future communications use these credentials to authenticate the agent automatically.

Related Guide: Step-by-Step Guide to Wazuh Agent Auto-Enrollment

Secure TCP Communication

Wazuh agent communication relies on persistent TCP connections designed for secure and reliable event delivery.

These encrypted channels transport:

• Security events
• Integrity monitoring results
• Configuration updates
• Active response instructions
• Agent status information

Because communication occurs over TCP rather than HTTP, organizations typically deploy TCP-aware proxies or layer-4 load balancers instead of traditional web proxies.

Authentication and Encryption

Security is built directly into the communication process.

Each agent:

• Authenticates using unique keys
• Encrypts traffic before transmission
• Verifies the identity of the manager
• Maintains secure persistent sessions

A properly configured proxy forwards encrypted traffic without decrypting or modifying it, preserving end-to-end security.

The official Wazuh documentation emphasizes the importance of secure agent authentication and encrypted communications to protect management infrastructure.

Where a Proxy Fits Into the Communication Path

Without a proxy:

Agent
   │
Encrypted TCP
   │
Wazuh Manager

With a proxy:

Agent
   │
Encrypted TCP
   │
Proxy Server
   │
Encrypted TCP
   │
Wazuh Manager

The proxy forwards traffic without participating in event analysis or detection logic.

This design enables organizations to centralize network ingress while keeping security processing on the Wazuh manager.

Common Use Cases for a Wazuh Proxy

Although smaller deployments often communicate directly with the Wazuh manager, larger environments benefit significantly from introducing a proxy layer.

Remote Offices

Organizations with multiple branch offices often connect thousands of endpoints back to a central SOC.

Rather than exposing the manager to every remote location, each office can securely route agent traffic through one or more proxy servers.

Benefits include:

• Fewer firewall rules
• Centralized ingress
• Simplified routing
• Better network segmentation

Branch Locations

Retail stores, manufacturing facilities, warehouses, and regional offices frequently operate behind independent firewalls.

A local proxy allows all endpoints within the branch to communicate through a single outbound connection, reducing network complexity while maintaining encrypted communications.

Cloud-to-On-Premises Deployments

Many organizations run workloads in public cloud platforms while maintaining their Wazuh manager on-premises.

Instead of exposing the manager directly to cloud networks, a proxy can securely relay traffic from cloud-based agents into the internal environment.

This architecture is particularly useful when monitoring:

• AWS EC2 instances
• Azure virtual machines
• Google Cloud workloads
• Kubernetes clusters

Related Guide: How to Monitor Kubernetes Using Wazuh

DMZ Environments

Internet-facing systems located inside a DMZ are intentionally isolated from internal infrastructure.

Deploying a proxy within or adjacent to the DMZ allows these systems to communicate with the Wazuh manager without granting direct access into the internal management network.

This layered approach aligns with widely accepted network security principles promoted by NIST and the Center for Internet Security (CIS).

Segmented Enterprise Networks

Large enterprises commonly divide networks into separate security zones for:

• Servers
• Workstations
• Development
• Production
• Finance
• Healthcare
• OT/ICS systems

Instead of creating numerous direct firewall exceptions, a proxy provides a controlled communication point between isolated network segments.

High-Security Environments

Organizations operating under strict compliance requirements, such as finance, healthcare, government, and critical infrastructure, often minimize direct connectivity into sensitive management networks.

Using a proxy supports a defense-in-depth strategy by reducing the number of externally reachable systems while maintaining secure telemetry collection from distributed endpoints.

Hybrid Cloud Architectures

Hybrid infrastructures combine on-premises data centers with one or more public cloud providers.

A proxy helps unify communications from diverse environments into a single, consistent entry point for the Wazuh manager, simplifying network administration as deployments scale.

Managed Service Providers (MSPs)

Managed Service Providers frequently monitor multiple customer environments from centralized security operations centers.

Deploying dedicated proxies for individual customer networks helps isolate traffic, simplify onboarding, and improve scalability while avoiding direct exposure of the core Wazuh management infrastructure.

Prerequisites

Before configuring a Wazuh proxy, verify that the required infrastructure is in place.

Since the proxy becomes part of the communication path between agents and the Wazuh manager, proper planning helps avoid connectivity, authentication, and performance issues later.

Installed Wazuh Manager

Your Wazuh manager should already be installed, configured, and functioning normally before introducing a proxy.

Verify that:

• The manager is running without errors.
• Agents can register successfully.
• Existing agents are reporting events.
• Required communication ports are open internally.
• TLS and authentication are functioning correctly.

It’s much easier to troubleshoot proxy-related issues when the manager has already been validated.

Related Guide: The Complete Wazuh Cluster Architecture Guide

Installed Wazuh Agents

Agents should already be installed on the endpoints that will communicate through the proxy.

Confirm that:

• The agent service is running.
• The agent is properly registered.
• Authentication keys are valid.
• Logs are being collected locally.
• Existing direct communication (if available) works correctly.

Once the proxy is deployed, agents can be reconfigured to communicate with the proxy instead of directly with the manager.

Related Guide: The Ultimate Wazuh Agent Deployment Guide

Linux Server to Act as the Proxy

Most Wazuh proxy deployments use a Linux server because of its stability, performance, and wide support for networking tools.

Common operating systems include:

• Ubuntu Server
• Debian
• Rocky Linux
• AlmaLinux
• Red Hat Enterprise Linux
• CentOS Stream

The server should have:

• Static IP address
• Reliable network connectivity
• Low latency to the manager
• Adequate CPU and memory
• Sufficient bandwidth for expected agent traffic

The proxy does not perform event analysis, so resource requirements are generally much lower than those of the Wazuh manager.

Network Connectivity Between Proxy and Manager

The proxy must maintain reliable connectivity to the Wazuh manager.

Before deployment, verify:

• Routing exists between both systems.
• Firewalls allow required TCP traffic.
• Packet filtering devices are not interrupting connections.
• Latency is acceptable.
• No network address translation (NAT) issues interfere with communication.

Testing with tools such as ping, traceroute, nc, or telnet can help validate connectivity before configuring the proxy.

Firewall Access Requirements

Firewall rules should allow traffic only where necessary.

A typical deployment permits:

• Agents → Proxy
• Proxy → Wazuh Manager

Avoid exposing the manager directly to remote networks whenever possible.

Apply the principle of least privilege by restricting:

• Source IP addresses
• Destination ports
• Management access
• Administrative protocols

Proper firewall segmentation is recommended by NIST as part of a defense-in-depth architecture.

DNS Resolution

Although IP addresses can be used directly, DNS simplifies long-term management.

Using DNS names allows administrators to:

• Replace proxy servers without reconfiguring every agent.
• Implement load balancing.
• Perform failover more easily.
• Simplify certificate management.

Verify that:

• Agents resolve the proxy hostname.
• The proxy resolves the manager hostname.
• Internal DNS zones are consistent across sites.

TLS Certificates (If Applicable)

Many organizations secure proxy communications using TLS.

If encryption is terminated or established at the proxy, ensure that:

• Certificates are valid.
• Certificate chains are complete.
• Private keys are securely stored.
• Certificates have not expired.
• Hostnames match certificate Subject Alternative Names (SANs).

Even when using TCP forwarding, maintaining encrypted communication between agents and the manager remains a security best practice.

Related Guide: How to Fix Wazuh Certificate Errors

Administrative Privileges

You’ll need administrative access to configure both the proxy server and the Wazuh infrastructure.

Typical tasks include:

• Installing proxy software
• Editing configuration files
• Restarting services
• Opening firewall ports
• Testing network connectivity
• Reviewing system logs

Ensure you also have access to any firewalls, load balancers, or cloud networking components involved in the deployment.

Proxy Deployment Architecture

There is no single “correct” way to deploy a Wazuh proxy.

The ideal architecture depends on your organization’s size, geographic distribution, security requirements, and availability goals.

Below are the most common deployment models.

Single Proxy Deployment

A single proxy sits between all remote agents and one or more Wazuh managers.

Remote Agents
      │
      ▼
  Proxy Server
      │
      ▼
 Wazuh Manager

This is the simplest architecture and works well for:

• Small businesses
• Single data centers
• Test environments
• Small cloud deployments

Advantages

• Simple configuration
• Low operational overhead
• Easy troubleshooting
• Minimal infrastructure cost

Disadvantages

• Single point of failure
• Limited scalability
• Maintenance causes service interruptions
• Not ideal for global deployments

Multiple Regional Proxies

Large organizations often deploy proxies close to their regional offices.

North America Agents ─┐
                      │
                 NA Proxy
                      │
                      ├────► Wazuh Manager
                      │
Europe Agents ────────┘

Asia Agents ─► APAC Proxy ─►

Each geographic region forwards traffic through its local proxy.

Advantages

• Lower latency
• Better scalability
• Reduced WAN traffic
• Regional fault isolation
• Improved user experience

Disadvantages

• More servers to manage
• Additional monitoring
• More complex routing
• Increased operational cost

This architecture is commonly used by multinational enterprises with distributed offices.

DMZ Proxy Architecture

Organizations frequently place proxy servers inside a DMZ while keeping the Wazuh manager on an internal network.

Internet
    │
Remote Agents
    │
Firewall
    │
DMZ Proxy
    │
Internal Firewall
    │
Wazuh Manager

The proxy becomes the only externally reachable component.

Advantages

• Reduced attack surface
• Strong network segmentation
• Easier compliance
• Better protection for the manager
• Supports zero-trust principles

Disadvantages

• Additional firewall configuration
• More complex routing
• Increased deployment complexity

This architecture is commonly recommended for security-sensitive environments.

Cloud Proxy Deployment

Organizations running cloud workloads often deploy proxy servers within the same cloud provider or virtual private cloud (VPC).

Examples include:

• AWS
• Microsoft Azure
• Google Cloud Platform

Cloud agents communicate with a nearby proxy, which forwards traffic back to the on-premises Wazuh manager.

Advantages

• Lower cloud latency
• Reduced bandwidth costs
• Improved reliability
• Easier cloud networking

Disadvantages

• Additional cloud infrastructure
• Cross-network routing
• VPN or Direct Connect dependencies
• More components to monitor

Related Guide: How to Monitor AWS CloudTrail Logs Using Wazuh

High Availability Proxy Design

Mission-critical deployments often eliminate single points of failure by deploying multiple proxy servers behind a load balancer.

               Load Balancer
             /              \
       Proxy A            Proxy B
             \              /
             Wazuh Manager

If one proxy fails, traffic automatically shifts to another healthy instance.

Advantages

• High availability
• Fault tolerance
• Maintenance without downtime
• Horizontal scalability
• Better resilience

Disadvantages

• Additional infrastructure
• More complex configuration
• Load balancer management
• Higher operational cost

High availability is especially important for enterprise SOCs monitoring thousands of endpoints.

Choosing the Right Architecture

The appropriate deployment depends on your environment:

As your deployment grows, it’s common to evolve from a single proxy to multiple regional or highly available proxy clusters.

Supported Proxy Options

Wazuh does not include a dedicated proxy component.

Instead, administrators typically use proven networking technologies to securely forward agent traffic to the manager.

The best option depends on your performance, availability, and security requirements.

NGINX TCP Stream Proxy

NGINX is widely known as a web server, but its Stream module also supports layer-4 TCP proxying, making it well suited for forwarding Wazuh agent traffic.

It offers:

• High performance
• Efficient TCP forwarding
• SSL/TLS passthrough
• Connection logging
• Health checks (NGINX Plus)
• Load balancing capabilities

NGINX is a good choice when:

• You already use NGINX elsewhere.
• You need lightweight TCP proxying.
• You want simple configuration.
• You plan to add load balancing later.

The official NGINX documentation provides examples of TCP and UDP stream proxying.

HAProxy

HAProxy is one of the most popular TCP load balancers for enterprise environments.

It provides:

• Extremely high performance
• Advanced health checking
• Session persistence
• Detailed metrics
• Load balancing
• High availability features

HAProxy is particularly well suited for:

• Large Wazuh deployments
• Enterprise SOCs
• MSP environments
• Multi-manager architectures
• High availability deployments

Related Guide: Step-by-Step Wazuh Manager Scaling Guide

stunnel

Unlike NGINX or HAProxy, stunnel focuses on creating encrypted TLS tunnels between systems.

It is commonly used when:

• Additional encryption layers are required.
• Legacy applications need TLS support.
• Secure TCP tunneling is needed.
• Minimal proxy functionality is sufficient.

Advantages include:

• Lightweight deployment
• Simple configuration
• Strong TLS support
• Low resource usage

However, stunnel lacks the advanced load balancing and monitoring capabilities found in HAProxy or NGINX.

Reverse Proxies vs TCP Proxies

This distinction is important because the terms are often confused.

A reverse proxy typically operates at the application layer (Layer 7), understanding protocols such as HTTP or HTTPS.

Examples include reverse proxies used to protect web servers or web applications.

A TCP proxy, on the other hand, operates at the transport layer (Layer 4), forwarding TCP connections without interpreting the application payload.

Since Wazuh agent communication relies on encrypted TCP sessions rather than HTTP requests, a TCP proxy is generally the appropriate choice.

In most deployments:

• Reverse proxies are used for web applications such as the Wazuh Dashboard.
• TCP proxies are used for Wazuh agent-to-manager communication.

Related Guide: Fixing Nginx Upstream Timeouts When Proxying Wazuh Dashboard Traffic

Load Balancers Acting as Proxies

Many enterprise load balancers can also function as TCP proxies while distributing connections across multiple backend managers or proxy instances.

Examples include:

• HAProxy
• NGINX
• F5 BIG-IP
• AWS Network Load Balancer (NLB)
• Azure Load Balancer

These solutions provide additional capabilities such as:

• Automatic failover
• Health monitoring
• Connection distribution
• Horizontal scaling
• Improved availability

This approach is recommended for large deployments where maintaining continuous agent connectivity is critical.

Which Proxy Option Should You Choose?

Configure an NGINX TCP Proxy for Wazuh

NGINX is one of the most popular choices for implementing a Wazuh proxy because it provides fast, reliable Layer 4 (TCP) forwarding with minimal overhead.

Unlike its more common HTTP reverse proxy use case, Wazuh requires the Stream module so that NGINX forwards encrypted TCP traffic without inspecting it.

The official NGINX Stream documentation explains the available directives and TCP proxying behavior.

Install NGINX

On Ubuntu or Debian:

sudo apt update
sudo apt install nginx

On RHEL, Rocky Linux, AlmaLinux, or CentOS:

sudo dnf install nginx

Verify the installation:

nginx -v

Example output:

nginx version: nginx/1.26.0

Enable the Stream Module

Many Linux distributions ship the Stream module separately.

Verify it is available:

nginx -V

Look for output similar to:

--with-stream

or

--with-stream=dynamic

If using the dynamic module, load it inside nginx.conf:

load_module modules/ngx_stream_module.so;

Create the Stream Configuration

Rather than editing the main configuration directly, create a dedicated configuration file.

Example:

sudo mkdir -p /etc/nginx/stream.d
sudo nano /etc/nginx/stream.d/wazuh.conf

Example configuration:

stream {

    upstream wazuh_manager {

        server 10.10.10.20:1514;

    }

    server {

        listen 1514;

        proxy_pass wazuh_manager;

        proxy_timeout 600s;

        proxy_connect_timeout 10s;

    }

}

This forwards every incoming TCP connection on port 1514 to the internal Wazuh manager.

Forward Wazuh Agent Traffic

If multiple Wazuh managers are available, the upstream block can include multiple backend servers.

Example:

stream {

    upstream wazuh_cluster {

        server 10.10.10.20:1514;

        server 10.10.10.21:1514;

    }

    server {

        listen 1514;

        proxy_pass wazuh_cluster;

    }

}

NGINX will distribute new connections across available backend servers according to its load-balancing policy.

Related Guide: How to Build a Wazuh Indexer Cluster

Configure Listening Ports

Wazuh commonly uses:

If forwarding both communication and registration traffic:

stream {

    upstream wazuh_manager {

        server 10.10.10.20:1514;

    }

    upstream wazuh_registration {

        server 10.10.10.20:1515;

    }

    server {

        listen 1514;

        proxy_pass wazuh_manager;

    }

    server {

        listen 1515;

        proxy_pass wazuh_registration;

    }

}

Ensure any firewalls allow inbound connections on the listening ports and outbound connections from the proxy to the manager.

Reload NGINX

Before applying the configuration, test it.

sudo nginx -t

Example:

nginx: configuration file /etc/nginx/nginx.conf test is successful

Reload NGINX:

sudo systemctl reload nginx

Verify the service:

sudo systemctl status nginx

Verify Connectivity

Confirm that NGINX is listening:

ss -tln | grep 1514

Example:

LISTEN 0 511 *:1514

Test connectivity from another machine:

nc -vz proxy.example.com 1514

Expected output:

Connection to proxy.example.com 1514 port [tcp/*] succeeded!

You should also verify that new agent events appear in the Wazuh dashboard after traffic begins flowing through the proxy.

Related Guide: How to Test Wazuh Rules

Configure HAProxy for Wazuh

HAProxy is a popular enterprise-grade TCP load balancer that can also function as a high-performance Wazuh proxy.

It provides health checks, detailed logging, connection balancing, and high availability features that make it well suited for medium and large deployments.

The official HAProxy configuration documentation provides detailed information on TCP mode and backend configuration.

Installing HAProxy

Ubuntu/Debian:

sudo apt update
sudo apt install haproxy

RHEL-based distributions:

sudo dnf install haproxy

Verify installation:

haproxy -v

Backend Configuration

The backend defines where HAProxy forwards Wazuh traffic.

Example:

backend wazuh_backend

    mode tcp

    balance roundrobin

    server manager1 10.10.10.20:1514 check

    server manager2 10.10.10.21:1514 check

This configuration:

• Enables TCP forwarding
• Performs health checks
• Uses round-robin load balancing
• Automatically removes failed servers

Frontend Configuration

The frontend accepts incoming agent connections.

Example:

frontend wazuh_frontend

    bind *:1514

    mode tcp

    default_backend wazuh_backend

Every incoming connection on port 1514 is forwarded to the backend servers.

Health Checks

Health checks prevent agents from connecting to unavailable managers.

Example:

backend wazuh_backend

    mode tcp

    option tcp-check

    server manager1 10.10.10.20:1514 check

    server manager2 10.10.10.21:1514 check

HAProxy continuously verifies backend availability and automatically routes traffic only to healthy servers.

TCP Mode Configuration

Unlike HTTP applications, Wazuh requires Layer 4 forwarding.

Always configure:

mode tcp

Do not configure HTTP mode for Wazuh agent traffic.

Logging

Enable connection logging for troubleshooting.

Example:

global

    log /dev/log local0

defaults

    log global

    option tcplog

Logging helps identify:

• Failed connections
• Backend failures
• Timeouts
• Connection resets
• High connection rates

Complete HAProxy Example

global

    log /dev/log local0

defaults

    log global

    mode tcp

    option tcplog

    timeout connect 10s

    timeout client 1m

    timeout server 1m

frontend wazuh_frontend

    bind *:1514

    default_backend wazuh_backend

backend wazuh_backend

    balance roundrobin

    option tcp-check

    server manager1 10.10.10.20:1514 check

    server manager2 10.10.10.21:1514 check

Restart the Service

Validate the configuration:

sudo haproxy -c -f /etc/haproxy/haproxy.cfg

Restart:

sudo systemctl restart haproxy

Enable automatic startup:

sudo systemctl enable haproxy

Verify status:

sudo systemctl status haproxy

Testing the Configuration

Verify HAProxy is listening:

ss -tln | grep 1514

Test connectivity:

nc -vz proxy.example.com 1514

Review logs:

journalctl -u haproxy

Once agents begin reconnecting, verify that alerts continue to appear in the Wazuh dashboard.

Related Guide: Wazuh Dashboard Not Loading? Complete Troubleshooting Guide

Configure Wazuh Agents to Use the Proxy

After the proxy has been configured and tested, update each Wazuh agent so that it connects to the proxy instead of directly to the Wazuh manager.

The proxy becomes the agent’s communication endpoint while transparently forwarding traffic to the manager.

Modify ossec.conf

The primary agent configuration file is:

Linux:

/var/ossec/etc/ossec.conf

Windows:

C:\Program Files (x86)\ossec-agent\ossec.conf

Locate the <client> section.

Example:

<client>

  <server>

    <address>proxy.example.com</address>

    <port>1514</port>

    <protocol>tcp</protocol>

  </server>

</client>

Replace the manager hostname with the proxy hostname or IP address.

Related Guide: How to Configure ossec.conf for Log Monitoring in Wazuh

Specify the Proxy Endpoint

Using DNS is recommended.

Example:

<address>wazuh-proxy.company.local</address>

instead of:

<address>192.168.10.50</address>

DNS simplifies:

• Future migrations
• High availability
• Failover
• Certificate management

Configure Registration Through the Proxy

If agents register through the proxy, ensure registration traffic is also forwarded.

Example registration configuration:

<client>

    <server>

        <address>proxy.example.com</address>

        <port>1515</port>

        <protocol>tcp</protocol>

    </server>

</client>

The proxy should forward registration requests to the manager’s registration service while preserving the secure authentication process.

Related Guide: Step-by-Step Guide to Wazuh Agent Auto-Enrollment

Restart the Agent

Linux:

sudo systemctl restart wazuh-agent

Windows (PowerShell):

Restart-Service WazuhSvc

Verify the service:

sudo systemctl status wazuh-agent

Verify Successful Registration

Review the agent log.

Linux:

tail -f /var/ossec/logs/ossec.log

You should see messages indicating a successful connection and authentication with the manager via the proxy.

On the manager, confirm the agent appears in the list:

sudo /var/ossec/bin/agent_control -l

The registered agent should be displayed with an Active status.

Validate Secure Communications

Finally, confirm that communication is functioning as expected:

• The agent remains connected without repeated disconnects.
• New security events appear in the Wazuh dashboard.
• File Integrity Monitoring events are received.
• Active response actions function correctly.
• No TLS or authentication errors appear in the logs.
• Proxy logs show stable TCP connections without excessive resets or timeouts.

You can generate a test event and verify it reaches the manager successfully.

Related Guide: How to Test Wazuh Rules

Best Practice: Before migrating large numbers of agents, update a small pilot group to use the proxy and monitor connectivity, registration, and event flow. Once validated, roll out the configuration in phases to minimize operational risk.

Firewall Configuration

Proper firewall configuration is essential for a successful Wazuh proxy deployment.

Every component in the communication path must be able to establish the required TCP connections while exposing as few ports as possible.

A good security practice is to allow only the specific hosts and ports required for communication rather than permitting unrestricted access.

This follows the principle of least privilege and reduces the attack surface.

Agent Registration

Before an agent can begin sending security events, it must register with the Wazuh manager (or through the proxy).

Typical communication flow:

Agent
   │
1515/TCP
   │
Proxy
   │
1515/TCP
   │
Wazuh Manager

Ensure that:

• Agents can reach the proxy on the registration port.
• The proxy can forward registration traffic to the manager.
• Registration traffic is restricted to trusted source networks whenever possible.

Related Guide: Step-by-Step Guide to Wazuh Agent Auto-Enrollment

Agent Communication

After registration, agents establish a persistent encrypted connection for event transmission.

Typical communication flow:

Agent
   │
1514/TCP
   │
Proxy
   │
1514/TCP
   │
Manager

Firewall rules should allow:

• Agent → Proxy
• Proxy → Manager

Direct Agent → Manager communication is generally unnecessary once the proxy is deployed.

Proxy Listener Ports

The proxy server must accept incoming connections from agents.

Typical listener ports include:

If custom ports are used, ensure they are consistently configured on:

• The proxy
• The Wazuh agents
• Firewalls
• Load balancers

Manager Ports

The Wazuh manager should generally accept incoming traffic only from trusted proxy servers rather than from every endpoint.

A simplified firewall policy might resemble:

Allow:
Proxy IPs  ---> Manager TCP 1514
Proxy IPs  ---> Manager TCP 1515

Deny:
All other external sources

This approach significantly reduces the manager’s exposed attack surface.

Internal Network Rules

In segmented enterprise environments, internal firewalls often exist between:

• Branch offices
• DMZs
• Data centers
• Production networks
• Cloud environments

Verify that every network segment permits the required TCP connections in both directions where applicable.

Document each firewall rule to simplify future maintenance and troubleshooting.

Cloud Security Groups

If the proxy or manager is hosted in a public cloud, review the associated network security controls.

For example:

• AWS Security Groups
• Azure Network Security Groups
• Google Cloud Firewall Rules

Only permit trusted source IP ranges rather than allowing unrestricted Internet access.

Related Guide: How to Monitor AWS CloudTrail Logs Using Wazuh

NAT Considerations

Network Address Translation (NAT) is common in branch offices and cloud environments.

When using NAT:

• Ensure return traffic is properly routed.
• Verify stateful firewall behavior.
• Confirm session timeouts are long enough for persistent TCP connections.
• Avoid asymmetric routing whenever possible.

Large deployments should carefully document NAT boundaries to simplify troubleshooting.

Best Practice: Create a network diagram showing agents, proxies, firewalls, NAT devices, load balancers, and managers. Even a simple diagram can dramatically reduce troubleshooting time when diagnosing connectivity issues.

Verifying the Proxy Configuration

After deploying the proxy, verify that each stage of the communication process is functioning correctly.

Validation should begin with basic network connectivity before progressing to agent registration, encrypted communications, and event delivery.

Check Agent Registration Status

First, confirm that agents successfully register with the manager.

On the manager:

sudo /var/ossec/bin/agent_control -l

Example output:

ID: 001
Name: webserver01
IP: 10.20.30.40
Status: Active

If the agent does not appear or remains disconnected, review the proxy and registration configuration.

Related Guide: Step-by-Step Guide to Wazuh Agent Auto-Enrollment

Review Manager Logs

The Wazuh manager log provides valuable information about incoming agent connections.

Common log location:

/var/ossec/logs/ossec.log

Monitor the log in real time:

sudo tail -f /var/ossec/logs/ossec.log

Look for messages indicating:

• Successful agent registration
• Authentication
• Connection establishment
• TLS negotiation
• Communication failures

Review Agent Logs

The agent log often reveals connection or authentication problems before they appear on the manager.

Linux:

tail -f /var/ossec/logs/ossec.log

Windows:

C:\Program Files (x86)\ossec-agent\ossec.log

Typical errors include:

• Unable to connect
• Registration failed
• Authentication failed
• TLS handshake failed
• Connection timeout

Related Guide: Wazuh Agent Not Connecting to Manager? 12 Proven Fixes

Perform Connection Tests

Verify basic network reachability.

Example:

ping proxy.company.com

Check DNS resolution:

nslookup proxy.company.com

or

dig proxy.company.com

Successful name resolution eliminates one common source of connection failures.

Perform TCP Connectivity Tests

Confirm the proxy is accepting TCP connections.

Using Netcat:

nc -vz proxy.company.com 1514

Example output:

Connection to proxy.company.com 1514 succeeded.

Alternatively:

telnet proxy.company.com 1514

These tests verify that the listener is reachable through the network and firewall.

Verify TLS with OpenSSL

If TLS is used, verify certificate negotiation.

Example:

openssl s_client -connect proxy.company.com:1514

Review:

• Certificate chain
• Expiration dates
• Subject Alternative Names (SANs)
• Cipher suite
• TLS version

Certificate validation helps identify trust or configuration issues before agents attempt to connect.

Related Guide: How to Fix Wazuh Certificate Errors

Review NGINX or HAProxy Logs

The proxy itself provides valuable diagnostic information.

For NGINX:

journalctl -u nginx

or

tail -f /var/log/nginx/error.log

For HAProxy:

journalctl -u haproxy

Review for:

• Failed backend connections
• Connection resets
• Timeouts
• Health check failures
• Listener errors

Validate in the Wazuh Dashboard

Finally, verify that events successfully reach the Wazuh platform.

Check that:

• Agents appear as Active.
• Recent events are visible.
• Security alerts continue to arrive.
• Active Response functions normally.
• File Integrity Monitoring events are received.
• No communication errors appear in the dashboard.

Generate a test event on one of the connected endpoints to confirm the complete communication path is functioning correctly.

Related Guide: How to Test Wazuh Rules

Troubleshooting Common Wazuh Proxy Problems

Even a correctly configured proxy deployment can experience issues related to networking, authentication, or infrastructure changes.

The following sections describe some of the most common problems, how to diagnose them, and the recommended resolution steps.

Agent Cannot Register

Symptoms

• Agent never appears in the manager.
• Registration requests fail.
• Authentication cannot complete.

Possible causes

• Registration port blocked
• Incorrect proxy configuration
• Manager not accepting registrations
• Authentication service unavailable

Diagnosis

• Verify port 1515 is open.
• Review manager logs.
• Check proxy forwarding configuration.
• Test TCP connectivity.

Resolution

• Correct firewall rules.
• Confirm the proxy forwards registration traffic.
• Restart registration services if necessary.
• Verify the configured manager or proxy address in ossec.conf.

Connection Refused

Symptoms

• Immediate connection failures.
• Netcat reports “Connection refused.”

Possible causes

• Proxy not listening
• Service stopped
• Incorrect port
• Firewall rejection

Diagnosis

ss -tln

Verify that the expected listening ports are active.

Resolution

• Start the proxy service.
• Correct the listener configuration.
• Open the required firewall ports.
• Confirm the configured port matches the agent configuration.

TLS Handshake Failures

Symptoms

• TLS negotiation errors
• Authentication failures
• Secure sessions never establish

Possible causes

• Invalid certificates
• Unsupported TLS versions
• Certificate trust issues
• Expired certificates

Diagnosis

openssl s_client -connect proxy.company.com:1514

Review the certificate chain and handshake output.

Resolution

• Replace expired certificates.
• Install the correct CA certificates.
• Verify certificate hostnames.
• Ensure supported TLS versions are configured consistently.

Related Guide: How to Fix Wazuh Certificate Errors

Firewall Blocking Traffic

Symptoms

• Timeouts
• Intermittent communication
• Agents remain disconnected

Diagnosis

Test connectivity with:

nc -vz proxy.company.com 1514

Review firewall logs to identify dropped packets.

Resolution

• Permit required TCP ports.
• Restrict access to trusted networks.
• Verify stateful inspection rules.
• Confirm cloud firewall policies.

Proxy Forwarding Failures

Symptoms

• Proxy accepts connections but the manager never receives them.
• Backend connection errors appear in proxy logs.

Diagnosis

Review:

• NGINX Stream configuration
• HAProxy backend configuration
• Proxy logs
• Manager reachability

Resolution

• Correct backend server addresses.
• Verify routing.
• Confirm backend ports.
• Restart the proxy after configuration changes.

DNS Issues

Symptoms

• Hostnames cannot be resolved.
• Intermittent connection failures.
• Delayed connections.

Diagnosis

nslookup proxy.company.com

or

dig proxy.company.com

Resolution

• Correct DNS records.
• Update internal DNS zones.
• Verify DNS server availability.
• Flush local DNS caches if necessary.

Certificate Errors

Symptoms

• Certificate validation failures
• TLS warnings
• Authentication errors

Diagnosis

Review:

• Certificate expiration
• CA trust chain
• Subject Alternative Names
• File permissions

Resolution

• Replace expired certificates.
• Install the correct CA bundle.
• Regenerate certificates if required.
• Verify permissions on certificate and key files.

High Latency

Symptoms

• Slow event delivery
• Delayed alerts
• Intermittent disconnects

Possible causes

• Long WAN links
• Network congestion
• Oversubscribed proxy server
• Cloud routing issues

Diagnosis

Use:

ping
traceroute
mtr

Monitor CPU, memory, and network utilization on the proxy.

Resolution

• Deploy regional proxies.
• Increase proxy resources.
• Optimize network routing.
• Reduce unnecessary WAN hops.

Proxy Service Not Running

Symptoms

• All connections fail immediately.
• No listening ports are available.

Diagnosis

For NGINX:

systemctl status nginx

For HAProxy:

systemctl status haproxy

Resolution

• Restart the service.
• Correct configuration syntax errors.
• Enable automatic startup.
• Review service logs for startup failures.

Incorrect Listening Ports

Symptoms

• Agents cannot connect despite the proxy running.

Diagnosis

Verify active listeners:

ss -tln

Ensure that the configured ports match those defined in:

• ossec.conf
• NGINX or HAProxy configuration
• Firewall rules

Resolution

Correct any mismatched port numbers and reload the proxy configuration.

Connection Timeouts

Symptoms

• Connections establish briefly before dropping.
• Agents repeatedly reconnect.
• Alerts stop arriving intermittently.

Possible causes

• Firewall idle session limits
• Load balancer timeouts
• Proxy timeout settings
• Network instability

Diagnosis

Review:

• Proxy timeout configuration
• Firewall session timers
• Proxy logs
• Network packet captures (if necessary)

Resolution

• Increase TCP idle timeouts.
• Tune proxy timeout values.
• Verify stable routing between the proxy and manager.
• Monitor for packet loss or excessive retransmissions.

Expert Insight: The maintainers of HAProxy and NGINX recommend validating connectivity layer by layer, client to proxy, proxy to backend, then application-level communication, rather than troubleshooting the entire path at once. This incremental approach helps isolate configuration and network issues more efficiently and reduces time to resolution.

Performance Considerations

A Wazuh proxy is typically lightweight because it does not analyze security events or execute detection rules.

Its primary responsibility is forwarding TCP connections between agents and the Wazuh manager.

However, large deployments with thousands of endpoints still require careful performance planning.

Poorly sized proxies, inefficient connection handling, or excessive logging can introduce delays, dropped connections, and unnecessary operational overhead.

Proxy Sizing

Proxy resource requirements depend primarily on:

• Number of connected agents
• Event volume
• Network throughput
• Connection duration
• Encryption overhead
• Number of proxied services

Unlike the Wazuh manager, the proxy does not require significant CPU or storage resources because it is not processing security data.

Typical proxy resources:

These values are general guidelines.

Real requirements depend heavily on event volume and network conditions.

Related Guide: Step-by-Step Wazuh Manager Scaling Guide

Connection Limits

Each Wazuh agent maintains a persistent connection with the proxy. As the number of agents increases, the proxy must support more simultaneous TCP sessions.

Monitor:

• Maximum open files
• TCP connection limits
• Operating system limits
• Proxy software connection limits

Check current limits:

ulimit -n

For large deployments, increase the maximum number of open connections.

Example:

sudo nano /etc/security/limits.conf

Add:

nginx soft nofile 100000
nginx hard nofile 100000

The exact values depend on your operating system and expected connection volume.

Keepalive Settings

Persistent connections reduce unnecessary connection establishment overhead.

For NGINX:

stream {

    server {

        listen 1514;

        proxy_pass wazuh_manager;

        proxy_connect_timeout 10s;

        proxy_timeout 1h;

    }

}

For HAProxy:

defaults

    timeout client 1h

    timeout server 1h

    timeout connect 10s

Longer timeout values help prevent unnecessary disconnects in environments with intermittent traffic.

However, excessively long idle connections can consume resources, especially in very large environments.

Buffer Tuning

Buffers temporarily store network data while traffic moves between agents and managers.

Improper buffer settings can cause:

• Increased memory usage
• Delayed event delivery
• Connection instability

For NGINX:

stream {

    proxy_buffer_size 16k;

}

For HAProxy:

tune.bufsize 32768

Buffer tuning should be performed based on observed traffic patterns rather than arbitrary increases.

Load Balancing

Large Wazuh environments often deploy multiple proxies or managers behind a load balancer.

Example:

              Load Balancer

              /          \

        Proxy 1        Proxy 2

              \          /

          Wazuh Managers

Benefits include:

• Higher availability
• Better fault tolerance
• Increased connection capacity
• Easier maintenance

Common load-balancing methods include:

• Round robin
• Least connections
• Source IP persistence

HAProxy is frequently used in enterprise deployments because of its TCP load-balancing capabilities.

Related Guide: How to Build a Wazuh Indexer Cluster

Geographic Latency

Network distance between agents, proxies, and managers affects performance.

A common design pattern is:

Remote Office
      |
      |
Regional Proxy
      |
      |
Central Wazuh Manager

Regional proxies reduce:

• WAN latency
• Packet loss impact
• Long-distance TCP sessions
• Branch office dependency on central networks

For global organizations, placing proxies closer to endpoints improves reliability.

Scaling for Thousands of Agents

When monitoring thousands of endpoints, avoid creating a single overloaded proxy.

Recommended strategies:

• Deploy multiple regional proxies.
• Use load balancers.
• Monitor connection counts.
• Separate environments when necessary.
• Increase proxy resources gradually.

A large deployment may look like:

                 Load Balancer

              /       |        \

        Proxy A   Proxy B   Proxy C

              \       |        /

             Wazuh Manager Cluster

Scaling horizontally is often more effective than continuously increasing the size of one proxy server.

Related Guide: The Complete Wazuh Cluster Architecture Guide

Monitoring Proxy Performance

A proxy should be monitored like any other production infrastructure component.

Track:

• CPU usage
• Memory consumption
• Network bandwidth
• Active connections
• Connection failures
• Backend availability
• Packet retransmissions

Useful Linux commands:

top

ss -s

iftop

netstat -an

For HAProxy:

echo "show info" | socat stdio /var/run/haproxy.sock

For NGINX:

nginx -V

or use monitoring integrations.

Logging Overhead

Detailed proxy logging is valuable during troubleshooting, but excessive logging can create unnecessary disk and performance overhead.

High-volume logging can cause:

• Increased disk usage
• Higher I/O utilization
• Larger log rotation requirements

Recommended practices:

• Enable detailed logs during troubleshooting.
• Use log rotation.
• Retain only necessary connection data.
• Forward logs to centralized monitoring platforms.

Related Guide: How to Configure Wazuh Log Retention

Wazuh Proxy Security Best Practices

A proxy becomes a critical communication gateway between endpoints and the Wazuh manager.

Because it handles security telemetry, it should be hardened and monitored as part of the overall security architecture.

A secure proxy deployment should follow defense-in-depth principles by limiting exposure, protecting communications, and continuously monitoring suspicious activity.

Use TLS Encryption

All Wazuh agent communication should remain encrypted.

TLS protects against:

• Traffic interception
• Man-in-the-middle attacks
• Unauthorized monitoring
• Data manipulation

Ensure that:

• Certificates are valid.
• Private keys are protected.
• Encryption protocols are updated.
• Weak ciphers are disabled.

Restrict Exposed Ports

Only expose the ports required for Wazuh communication.

Typical ports:

Avoid exposing unnecessary services such as:

• SSH publicly
• Web administration interfaces
• Unused network services

Limit Source IP Addresses

Do not allow unrestricted Internet access to the proxy.

Instead:

• Allow known branch office networks.
• Restrict cloud IP ranges.
• Use firewall allowlists.
• Block unauthorized connection attempts.

Example firewall policy:

Allow:
Branch Networks → Proxy TCP 1514

Deny:
All Other Sources

This reduces the likelihood of unauthorized connection attempts.

Harden the Proxy Server

Apply standard Linux security practices:

• Remove unnecessary packages.
• Disable unused services.
• Apply security updates.
• Use SSH key authentication.
• Restrict administrator access.
• Enable host-based firewall rules.

Security hardening guides from organizations such as the Center for Internet Security provide recommended server configuration practices.

Keep Proxy Software Updated

Outdated proxy software can introduce vulnerabilities.

Regularly update:

• NGINX
• HAProxy
• Operating system packages
• TLS libraries

Before upgrades:

• Test configuration changes.
• Review release notes.
• Maintain backups.
• Plan maintenance windows.

Enable Detailed Logging

Proxy logs provide visibility into:

• Connection attempts
• Failed sessions
• Backend failures
• Unexpected traffic patterns

Recommended logging includes:

• Source IP address
• Destination endpoint
• Connection status
• Error messages
• Timestamps

Avoid disabling logs completely, especially in production environments.

Monitor Failed Connections

Repeated failed connections may indicate:

• Misconfigured agents
• Firewall problems
• Network issues
• Unauthorized access attempts

Monitor for:

• Excessive connection failures
• Repeated authentication attempts
• Unknown source addresses
• Unexpected geographic locations

Use High Availability

A single proxy creates a potential single point of failure.

For critical environments, deploy:

• Multiple proxies
• Load balancers
• Automated failover

Example:

             Load Balancer

            /             \

       Proxy A          Proxy B

            \             /

          Wazuh Manager

High availability ensures monitoring continues during maintenance or hardware failures.

Rotate Certificates

Expired certificates can immediately disrupt agent communication.

Maintain a certificate lifecycle process:

• Track expiration dates.
• Replace certificates before expiration.
• Validate new certificates.
• Remove old keys securely.

Automating certificate renewal reduces unexpected outages.

Perform Regular Security Audits

Regular reviews should evaluate:

• Firewall rules
• Proxy configurations
• TLS settings
• User permissions
• Software versions
• Logging configuration

Security audits help identify configuration drift and ensure the proxy continues meeting organizational security requirements.

Real-World Example

Scenario

A global organization operates hundreds of branch offices across multiple regions.

Each location contains Windows workstations, Linux servers, and network devices that require centralized monitoring through a Wazuh deployment.

The organization’s Wazuh manager infrastructure is hosted inside a secure data center protected by multiple firewall layers.

Due to security policies, branch networks are not permitted to establish direct connections to internal management systems.

The security team initially faces several challenges:

• Hundreds of firewall exceptions would be required.
• Remote endpoints have inconsistent network paths.
• Expanding to new offices requires complex networking changes.
• Direct exposure of the Wazuh manager increases security risk.

To solve these challenges, the security team deploys regional NGINX TCP proxies.

Proxy Deployment Architecture

The final architecture becomes:

Branch Offices
      |
      |
Regional NGINX Proxies
      |
      |
Firewall Boundary
      |
      |
Central Wazuh Manager

Each regional proxy accepts encrypted agent connections from nearby offices and forwards the traffic securely to the centralized Wazuh manager.

Implementation Process

The security team completes the deployment in several stages:

1. Deploy Regional Proxies

Linux servers are deployed in strategic locations close to branch networks.

Each proxy is configured with:

• NGINX Stream module
• TCP forwarding rules
• Firewall restrictions
• Monitoring agents

2. Configure Secure Forwarding

The proxies forward:

• Agent registration traffic on TCP 1515
• Agent communication traffic on TCP 1514

Encrypted communication remains enabled between agents and the manager.

3. Update Agent Configurations

Agents are updated to communicate with the regional proxy instead of the internal manager address.

Example:

<client>

    <server>

        <address>wazuh-proxy.company.com</address>

        <port>1514</port>

    </server>

</client>

4. Validate Connectivity

The security team verifies:

• Successful agent registration
• TLS certificate validation
• Stable TCP connections
• Event delivery
• Dashboard visibility

After testing a pilot group of endpoints, the configuration is rolled out across all branch offices.

Operational Benefits

Simplified Network Architecture

Instead of maintaining hundreds of firewall rules, each branch only communicates with its designated regional proxy.

This reduces:

• Firewall complexity
• Administrative effort
• Deployment time

Secure Communications

The architecture maintains:

• Encrypted agent communication
• Authentication controls
• Segmented network access
• Reduced manager exposure

The Wazuh manager remains protected inside the secure data center.

Improved Reliability

Regional proxies improve resilience by reducing dependence on long-distance network connections.

Benefits include:

• Lower latency
• Better fault isolation
• Easier troubleshooting
• Improved connectivity stability

Easier Expansion

When the organization opens a new branch office, deployment becomes simpler:

1. Deploy or assign a regional proxy.
2. Allow firewall access.
3. Install Wazuh agents.
4. Point agents to the proxy.

No changes are required to expose the internal Wazuh manager.

Final Result

After implementing regional NGINX TCP proxies, the organization successfully centralizes security monitoring for thousands of endpoints while maintaining a secure network architecture.

The proxy-based design provides:

• Reduced firewall complexity
• Secure encrypted communications
• Improved scalability
• Higher availability
• Easier onboarding of new locations

The organization now has a Wazuh deployment capable of expanding globally without redesigning its core security infrastructure.

Frequently Asked Questions

Question: What Is a Wazuh Proxy?

A Wazuh proxy is an intermediary server that forwards communication between Wazuh agents and the Wazuh manager.

Instead of every agent connecting directly to the manager, agents communicate with the proxy, which securely relays registration requests and security event data to the manager.

A Wazuh proxy is commonly used in:

• Distributed enterprise networks
• Branch office environments
• Cloud deployments
• DMZ architectures
• Large-scale security monitoring environments

The proxy improves network segmentation, reduces firewall complexity, and limits direct exposure of the Wazuh manager.

Question: Does Wazuh Include a Built-In Proxy?

No. Wazuh does not provide a dedicated proxy component.

Instead, organizations typically deploy standard TCP proxy technologies such as:

• NGINX Stream
• HAProxy
• stunnel
• Enterprise load balancers

These solutions forward Wazuh agent communication traffic while preserving the encrypted TCP connection between agents and the manager.

Related Guide: The Complete Wazuh Cluster Architecture Guide

Question: Can I Use NGINX as a Wazuh Proxy?

Yes. NGINX can be used as a Wazuh proxy by using its Stream module for TCP forwarding.

NGINX is suitable because it can:

• Forward TCP connections
• Handle large numbers of connections
• Provide reliable network performance
• Support load-balancing architectures

A typical NGINX Wazuh proxy listens on port 1514 and forwards traffic to the Wazuh manager.

Example:

stream {

    upstream wazuh_manager {

        server 10.10.10.20:1514;

    }

    server {

        listen 1514;

        proxy_pass wazuh_manager;

    }

}

For enterprise environments, NGINX can also be combined with multiple backend managers or additional proxy nodes.

Question: Can HAProxy Forward Wazuh Traffic?

Yes. HAProxy is commonly used as a Wazuh TCP proxy, especially in large deployments requiring:

• Load balancing
• Health checks
• High availability
• Connection monitoring

HAProxy should operate in TCP mode because Wazuh agent communication is based on encrypted TCP sessions.

Example:

frontend wazuh_frontend

    bind *:1514

    mode tcp

    default_backend wazuh_backend


backend wazuh_backend

    mode tcp

    server manager1 10.10.10.20:1514 check

HAProxy is particularly useful for environments with thousands of agents or multiple Wazuh manager nodes.

Question: Which Ports Need to Be Opened?

The required ports depend on whether you are forwarding only agent communication or also handling registration.

Common ports include:

A typical firewall design allows:

Agents → Proxy: 1514/TCP
Agents → Proxy: 1515/TCP

Proxy → Wazuh Manager: 1514/TCP
Proxy → Wazuh Manager: 1515/TCP

Only required source networks should be allowed to access the proxy.

Question: Can Agents Register Through a Proxy?

Yes. Wazuh agents can register through a proxy as long as the proxy forwards registration traffic correctly.

The proxy must allow:

• TCP 1515 connections from agents
• TCP 1515 forwarding to the manager
• Proper authentication communication

After registration completes, agents use their assigned authentication keys for ongoing communication.

Question: Does Using a Proxy Affect Performance?

A properly configured proxy usually has minimal performance impact because it only forwards TCP traffic.

Performance depends on:

• Number of connected agents
• Network latency
• Proxy hardware resources
• Connection limits
• Logging configuration
• Load-balancing design

For small deployments, a single lightweight proxy is usually sufficient.

Large deployments should use multiple proxies, regional placement, or load balancing.

Question: How Do I Troubleshoot Proxy Connection Issues?

Start troubleshooting from the lowest network layer and move upward.

Recommended troubleshooting order:

1. Verify DNS resolution.

nslookup proxy.example.com

2. Test TCP connectivity.

nc -vz proxy.example.com 1514

3. Check proxy service status.

NGINX:

systemctl status nginx

HAProxy:

systemctl status haproxy

4. Review proxy logs.
5. Review Wazuh agent logs.
6. Review Wazuh manager logs.
7. Verify firewall rules.

Common causes include:

• Incorrect ports
• Firewall restrictions
• Invalid certificates
• Proxy misconfiguration
• DNS failures
• Backend connectivity problems

Question: Can Multiple Proxies Connect to One Wazuh Manager?

Yes. Multiple proxies can forward traffic to a single Wazuh manager.

This is a common architecture for:

• Multi-region deployments
• Large enterprises
• Distributed branch networks
• Cloud environments

Example:

Branch A
   |
Proxy A
   |
   |

Branch B
   |
Proxy B
   |
   |

Wazuh Manager

Multiple proxies allow organizations to scale without exposing the manager directly to every network segment.

Question: How Do I Make a Wazuh Proxy Highly Available?

To create a highly available proxy architecture, deploy multiple proxy servers behind a load balancer.

Example:

             Load Balancer

             /          \

        Proxy A       Proxy B

             \          /

          Wazuh Manager

Recommended practices include:

• Deploy multiple proxy nodes.
• Use health checks.
• Monitor backend availability.
• Configure automatic failover.
• Avoid single points of failure.

HAProxy, NGINX Plus, cloud load balancers, and enterprise appliances can all provide high availability capabilities.

Conclusion

A Wazuh proxy provides a secure and scalable way to connect distributed endpoints to a centralized Wazuh manager without requiring direct communication from every agent to the management infrastructure.

By placing a proxy between agents and the manager, organizations can simplify firewall management, improve network segmentation, reduce exposure of critical security systems, and support large deployments across branch offices, cloud environments, and geographically distributed networks.

Configuring a Wazuh proxy involves several key steps:

• Planning the proxy architecture.
• Selecting an appropriate proxy technology such as NGINX or HAProxy.
• Configuring TCP forwarding for Wazuh communication.
• Opening the required firewall ports.
• Updating Wazuh agents to use the proxy endpoint.
• Validating registration, authentication, and event delivery.

A successful deployment depends on careful attention to security and reliability.

Organizations should maintain encrypted TLS communications, restrict access to required networks, keep proxy software updated, rotate certificates, and continuously monitor proxy performance.

For production environments, regularly review:

• Connection health
• Proxy resource usage
• Firewall rules
• Failed connection attempts
• Certificate expiration
• Network latency

When properly designed and maintained, a Wazuh proxy becomes an important component of a scalable security monitoring architecture.

It allows organizations to expand Wazuh deployments across thousands of endpoints while maintaining secure communication, simplified networking, and reliable threat detection capabilities.