Published July 13, 2026 by

Fixing Nginx Upstream Timeouts When Proxying Wazuh Dashboard Traffic

Many organizations deploy the Wazuh Dashboard behind an Nginx reverse proxy to simplify TLS termination, centralize authentication, and expose the dashboard through a single public endpoint.

While this architecture is reliable, it also introduces another component that can become a bottleneck when communication between Nginx and the Wazuh Dashboard is interrupted.

One of the most common problems administrators encounter is an upstream timeout.

An upstream timeout occurs when Nginx forwards a request to the Wazuh Dashboard but does not receive a response before the configured timeout expires.

Instead of displaying the requested page, Nginx returns an error such as 504 Gateway Timeout, 502 Bad Gateway, or a connection timeout message.

These errors often appear intermittently during periods of high load but can also persist indefinitely when there is a configuration or networking issue.

For Wazuh deployments, upstream timeout problems affect far more than the web interface.

Since the dashboard communicates extensively with the Wazuh API and the Wazuh Indexer to retrieve alerts, inventory data, agent status, and security events, proxy failures can prevent users from logging in, viewing dashboards, executing searches, or managing agents.

In severe cases, the dashboard may appear completely unavailable even though the underlying Wazuh services remain operational.

According to the official Nginx documentation, upstream timeouts are generally caused by slow upstream applications, network latency, overloaded backend services, or proxy timeout values that are too restrictive.

Throughout this guide, you’ll learn how Wazuh traffic flows through an Nginx reverse proxy, where upstream timeouts occur, how to identify the exact cause using logs and diagnostic tools, and the configuration changes that reliably resolve these errors.

You’ll also learn preventative best practices to ensure stable dashboard performance as your Wazuh deployment grows.

Process of Fixing Nginx Upstream Timeouts

In general, you should follow this process:

  1. Verify that the Wazuh Dashboard service is running.
  2. Confirm the dashboard is listening on the expected port.
  3. Test connectivity between Nginx and the dashboard.
  4. Review Nginx and Wazuh Dashboard logs for specific errors.
  5. Validate proxy configuration, headers, and WebSocket support.
  6. Check Wazuh Indexer health and search performance.
  7. Optimize timeout values only when backend performance is confirmed.

Understanding How Nginx Proxies Wazuh Dashboard Traffic

Before troubleshooting timeout errors, it’s important to understand how requests travel through a typical Wazuh deployment.

An upstream timeout can occur at several points in the request chain, and identifying the failing component dramatically shortens troubleshooting time.

Typical Wazuh Deployment Architecture

A common production deployment looks similar to the following:

User Browser
      │
      ▼
    Nginx
      │
      ▼
Wazuh Dashboard
      │
      ▼
Wazuh Indexer
      │
      ▼
Indexed Security Data

In many environments, Nginx is the only publicly accessible service.

The Wazuh Dashboard listens on an internal interface, while the Wazuh Indexer and Wazuh Manager remain isolated from direct internet access.

This layered architecture improves security but also means every dashboard request depends on multiple backend services responding within acceptable time limits.

Role of Nginx as a Reverse Proxy

Nginx acts as an intermediary between users and the Wazuh Dashboard.

Rather than serving dashboard content itself, it forwards HTTP or HTTPS requests to the backend application.

Its responsibilities typically include:

  • SSL/TLS termination
  • Load balancing (when multiple dashboard instances exist)
  • URL routing
  • Request buffering
  • Compression
  • Access control
  • Reverse proxying to the Wazuh Dashboard

Because Nginx sits between clients and Wazuh, any communication delay beyond configured timeout values causes Nginx to terminate the request and return an error.

The official Nginx documentation explains that directives such as proxy_connect_timeout, proxy_read_timeout, and proxy_send_timeout govern how long Nginx waits for upstream responses before closing the connection.

Communication Between Components

 

Client Browser

The user’s browser sends requests for:

  • Dashboard pages
  • JavaScript assets
  • CSS files
  • API requests
  • Authentication requests
  • Live dashboard updates

Most modern browsers issue many simultaneous requests when loading the Wazuh Dashboard.

Nginx

Nginx receives every browser request and determines where it should be forwarded.

If configured correctly, it:

  • Accepts HTTPS connections
  • Validates SSL certificates
  • Applies proxy rules
  • Opens a connection to the Wazuh Dashboard
  • Waits for a response
  • Returns that response to the browser

Wazuh Dashboard

The dashboard processes requests from Nginx and performs actions such as:

  • Authenticating users
  • Rendering dashboards
  • Executing searches
  • Calling the Wazuh REST API
  • Querying the Wazuh Indexer

Some operations, particularly complex searches involving large numbers of security events, naturally require more processing time.

Wazuh Indexer

The Wazuh Dashboard depends heavily on the Wazuh Indexer for retrieving indexed security data.

If the indexer responds slowly because of:

  • heavy disk I/O,
  • insufficient heap memory,
  • overloaded CPU,
  • large queries,
  • or unhealthy cluster status,

the dashboard cannot respond quickly enough to Nginx, resulting in an upstream timeout.

Related Guide: How to Fix a Yellow Cluster Status in Wazuh Indexer

Related Guide: How to Fix circuit_breaking_exception Data Overloads in Wazuh Indexer

Common Proxy Request Flow

A simplified request typically follows this sequence:

  1. The browser requests a dashboard page.
  2. Nginx accepts the request.
  3. Nginx forwards it to the Wazuh Dashboard.
  4. The dashboard authenticates the user.
  5. The dashboard queries the Wazuh Indexer.
  6. The indexer returns matching data.
  7. The dashboard generates the response.
  8. Nginx sends the completed response back to the browser.

Every stage introduces a potential delay.

Where Upstream Timeouts Occur

Most timeout errors occur because Nginx waits longer than its configured limits for one of these operations:

  • Establishing the initial TCP connection to the dashboard
  • Waiting for the dashboard to begin responding
  • Waiting for the dashboard to finish generating a response
  • Receiving data from the dashboard
  • Waiting for long-running Indexer queries to complete
  • Waiting for authentication requests to finish

The Nginx creators recommend treating timeout errors as indicators of backend performance or configuration problems rather than simply increasing timeout values.

Raising timeout settings without investigating the underlying cause may temporarily hide the issue while allowing performance problems to worsen over time.

Common Symptoms of Wazuh Nginx Reverse Proxy Timeouts

Upstream timeout problems rarely appear in only one place.

They usually generate a combination of browser errors, Nginx log entries, and application failures that together point toward proxy communication problems.

Recognizing these symptoms early helps determine whether the issue originates in Nginx, the Wazuh Dashboard, the Wazuh Indexer, or the underlying operating system.

504 Gateway Timeout

This is the classic upstream timeout error.

Instead of loading the requested page, Nginx returns:

504 Gateway Timeout

This indicates that Nginx successfully connected to the upstream server but did not receive a complete response before the configured timeout expired.

The dashboard service may still be running, but it is responding too slowly.

502 Bad Gateway

Sometimes Nginx reports:

502 Bad Gateway

Although commonly associated with backend failures, a 502 error can also occur after repeated upstream communication failures or when the backend unexpectedly closes the connection.

See our Fixing Wazuh 502 Bad Gateway: Troubleshooting Guide for more information.

upstream timed out Errors in error.log

One of the strongest indicators appears inside the Nginx error log:

upstream timed out (110: Connection timed out)
while reading response header from upstream

or

upstream timed out

These messages indicate that Nginx waited longer than the configured timeout while expecting a response from the Wazuh Dashboard.

According to the official Nginx documentation, these log entries should be correlated with backend application logs to determine whether the upstream application is overloaded or unresponsive.

Connection Refused Messages

Administrators may also encounter messages such as:

connect() failed (111: Connection refused)

Unlike timeout errors, these indicate that the dashboard service is not accepting connections at all.

Possible causes include:

  • Dashboard service stopped
  • Incorrect upstream IP address
  • Incorrect port number
  • Firewall blocking connections
  • Local socket failures

Dashboard Pages Loading Indefinitely

Users often report that:

  • the home page never finishes loading,
  • visualizations remain blank,
  • dashboards partially render,
  • loading indicators never disappear.

This usually means some API requests are succeeding while others are timing out.

API Requests Failing

The browser’s Developer Tools may show numerous failed requests to backend APIs, including:

  • HTTP 502
  • HTTP 504
  • HTTP 499
  • Network timeout errors

Since the Wazuh Dashboard depends heavily on asynchronous API calls, even a few failed requests can make the interface appear unusable.

Related Guide: Wazuh API Authentication Failed? Causes and Solutions

Login Page Never Loads

Authentication may fail before users can even access the dashboard.

Common symptoms include:

  • Endless loading spinner
  • Blank login screen
  • Session initialization failures
  • Authentication requests timing out
  • Browser eventually displaying a timeout page

These issues often occur when the dashboard cannot communicate with the Wazuh API or the Wazuh Indexer quickly enough.

WebSocket Disconnects

Recent versions of the Wazuh Dashboard use persistent connections for various interactive features.

When upstream communication becomes unstable, users may experience:

  • Frequent reconnect attempts
  • Live updates stopping
  • Notifications disappearing
  • Unexpected session interruptions

Because WebSockets remain open longer than traditional HTTP requests, improperly configured proxy timeout values can terminate otherwise healthy connections.

Browser Timeout Errors

End users may see browser-specific errors such as:

  • ERR_CONNECTION_TIMED_OUT
  • ERR_EMPTY_RESPONSE
  • ERR_CONNECTION_RESET
  • The site took too long to respond
  • Network timeout

While these messages originate in the browser, they are often the visible result of upstream timeout failures occurring between Nginx and the Wazuh Dashboard rather than a client-side networking problem.

Common Causes of Upstream Timeout Errors

Upstream timeout errors almost always indicate that Nginx cannot communicate with the Wazuh Dashboard quickly enough to satisfy its configured timeout values.

While increasing the timeout settings may temporarily mask the problem, the real solution is identifying why the upstream server is slow or unreachable.

The following are the most common root causes in Wazuh deployments.

Wazuh Dashboard Service Is Not Running

One of the simplest explanations is that the Wazuh Dashboard service has stopped unexpectedly or failed during startup.

When this happens, Nginx attempts to forward requests to the configured upstream server but receives no response.

Depending on the failure, users may see:

  • 502 Bad Gateway
  • 504 Gateway Timeout
  • Connection refused
  • Upstream connection errors

Common reasons the dashboard service stops include:

  • Failed upgrades
  • Invalid configuration files
  • Plugin initialization failures
  • Out-of-memory conditions
  • Service crashes
  • System reboots where the service did not automatically restart

The first troubleshooting step should always be confirming that the dashboard service is healthy before investigating proxy settings.

Related Guide: How to Fix “Wazuh Dashboard Server Is Not Ready Yet” (Step-by-Step)

Incorrect Proxy Pass Configuration

Misconfigured proxy_pass directives are another frequent cause of timeout errors.

Examples include:

  • Wrong IP address
  • Incorrect port
  • Typographical errors
  • Missing protocol (http:// or https://)
  • Pointing Nginx to an obsolete server after migration

For example:

location / {
    proxy_pass http://127.0.0.1:5601;
}

If the dashboard actually listens on another address or port, Nginx continually waits for responses that never arrive.

The official Nginx documentation recommends carefully validating every upstream server definition and proxy directive whenever backend infrastructure changes.

Firewall Blocking Internal Communication

Even when both Nginx and the Wazuh Dashboard are running, firewall rules may silently block communication.

Potential sources include:

  • firewalld
  • ufw
  • iptables
  • nftables
  • Cloud security groups
  • Host-based endpoint protection

Symptoms often include:

  • Connection timed out
  • No route to host
  • Connection refused
  • Random intermittent failures

Remember that firewalls between virtual machines or Kubernetes nodes can introduce communication failures even though both applications appear healthy.

Slow Wazuh Indexer Responses

The dashboard depends heavily on the Wazuh Indexer.

When users open dashboards or perform searches, the dashboard sends multiple requests to retrieve indexed security events.

If the indexer becomes overloaded because of:

  • High CPU utilization
  • Excessive heap usage
  • Slow disks
  • Large shard recoveries
  • Cluster health problems
  • Massive search queries

the dashboard cannot generate responses quickly enough for Nginx.

This often results in intermittent timeout errors during periods of heavy activity.

Elastic, whose search engine architecture underpins OpenSearch, recommends monitoring search latency, heap usage, thread pools, and cluster health when diagnosing slow query performance.

Related Guides:

Insufficient Proxy Timeout Values

Nginx uses several timeout directives that determine how long it waits for upstream servers.

Common examples include:

  • proxy_connect_timeout
  • proxy_send_timeout
  • proxy_read_timeout
  • send_timeout

If these values are configured too aggressively, legitimate requests may be terminated before the dashboard finishes processing them.

This is particularly common after:

  • Enabling complex visualizations
  • Large threat hunting queries
  • Cluster upgrades
  • Increased log ingestion rates

Increasing timeout values may be appropriate, but only after confirming that backend performance is acceptable.

DNS Resolution Problems

Some deployments configure upstream servers using hostnames instead of IP addresses.

For example:

proxy_pass http://wazuh-dashboard.internal:5601;

If DNS resolution fails, Nginx cannot locate the upstream server.

Possible causes include:

  • Incorrect /etc/resolv.conf
  • Missing DNS records
  • Broken internal DNS servers
  • Kubernetes DNS failures
  • Container networking issues

DNS problems may produce intermittent failures that are difficult to reproduce.

SSL/TLS Handshake Issues

When Nginx communicates with the dashboard over HTTPS, SSL negotiation becomes another potential failure point.

Problems may include:

  • Expired certificates
  • Self-signed certificates
  • Missing intermediate certificates
  • TLS version mismatches
  • Incorrect cipher suites

Handshake failures often appear as upstream connection failures even though the dashboard itself is functioning correctly.

The official OpenSSL project recommends validating certificate chains and ensuring both endpoints support compatible TLS versions during troubleshooting.

Resource Exhaustion on the Server

Servers experiencing resource pressure frequently exhibit timeout behavior before complete failure.

Important resources to monitor include:

  • CPU utilization
  • RAM usage
  • Swap usage
  • Disk I/O
  • File descriptors
  • Network bandwidth

A heavily loaded server may respond eventually, but not before Nginx reaches its timeout limit.

Administrators should correlate timeout events with system monitoring data to determine whether hardware constraints contribute to the issue.

Reverse Proxy Routing Loops

Configuration mistakes can accidentally create request loops.

For example:

Browser
    ↓
Nginx
    ↓
Nginx
    ↓
Nginx

or

Nginx
    ↓
Load Balancer
    ↓
Nginx

Each loop increases latency until requests ultimately time out.

Routing loops commonly occur after:

  • Reverse proxy migrations
  • Load balancer changes
  • Kubernetes ingress modifications
  • Incorrect proxy headers

Large Dashboard Queries Timing Out

Threat hunting and forensic investigations frequently generate complex searches.

Examples include:

  • Large historical searches
  • Multi-index aggregations
  • Long time ranges
  • Complex filters
  • High-cardinality visualizations

These requests can legitimately require significantly longer execution times than standard dashboard operations.

Rather than immediately increasing proxy timeout values, consider optimizing the underlying queries or narrowing search windows to reduce backend processing time.

Verify That the Wazuh Dashboard Service Is Running

Before modifying Nginx configuration, confirm that the upstream service itself is operational.

Many proxy timeout errors ultimately trace back to a dashboard service that has stopped, failed during startup, or is listening on a different interface than expected.

Check Service Status

On most Linux installations, verify the service status with:

sudo systemctl status wazuh-dashboard

A healthy service should report a status similar to:

Active: active (running)

If the service is inactive, failed, or repeatedly restarting, resolve that issue before continuing with Nginx troubleshooting.

Also look for recent restart attempts or crash messages that may indicate a deeper application problem.

Restart the Service

If the dashboard is unresponsive, restarting the service may restore normal operation.

sudo systemctl restart wazuh-dashboard

Then verify that it started successfully:

sudo systemctl status wazuh-dashboard

If the service immediately exits again, avoid repeatedly restarting it. Instead, investigate the startup logs to identify the underlying failure.

Verify Listening Ports

Next, ensure the dashboard is actually listening on its configured port.

On most systems:

sudo ss -tulpn | grep 5601

or

sudo netstat -tulpn | grep 5601

You should see the dashboard listening on the configured interface.

Typical output resembles:

LISTEN 0 511 127.0.0.1:5601

or

LISTEN 0 511 0.0.0.0:5601

If no process is listening, Nginx has nothing to proxy requests to.

Confirm the Dashboard Is Accessible Locally

Before involving Nginx, verify that the dashboard responds directly.

For example:

curl http://localhost:5601

or

curl -k https://localhost:5601

If HTML or HTTP headers are returned, the dashboard is functioning locally.

If the request hangs or times out, the problem lies with the dashboard rather than Nginx.

Review Startup Logs

The dashboard logs often contain the exact reason startup failed.

Useful messages include:

  • Plugin initialization failures
  • Configuration syntax errors
  • OpenSearch connection failures
  • Authentication issues
  • Memory allocation failures
  • Port binding conflicts

On most systems, recent logs can be viewed with:

sudo journalctl -u wazuh-dashboard -n 100 --no-pager

You should also review the dashboard’s own log files if available, especially after upgrades or configuration changes.

Related Guides: 

Test Connectivity Between Nginx and Wazuh Dashboard

After confirming that the dashboard service is running, verify that Nginx can actually reach it.

Successful communication between these two components is essential for proxy requests to complete without timing out.

Testing connectivity from the Nginx host helps isolate networking issues before making configuration changes.

Using curl

The simplest test is sending an HTTP request directly to the dashboard.

For example:

curl http://localhost:5601

or, if HTTPS is used:

curl -k https://localhost:5601

A successful response confirms that:

  • The dashboard is reachable.
  • The listening port is correct.
  • Basic HTTP communication is functioning.

If the request hangs, returns Connection refused, or times out, investigate the dashboard service and network configuration before modifying Nginx.

Using nc (netcat)

Netcat is useful for verifying that the TCP port is reachable without making an HTTP request.

For example:

nc -vz localhost 5601

Expected output resembles:

Connection to localhost 5601 port [tcp/*] succeeded!

A timeout or refused connection indicates that the service is either unavailable or inaccessible from the Nginx host.

Using telnet

Although less common today, Telnet can also verify TCP connectivity.

Example:

telnet localhost 5601

A successful connection confirms that the port accepts incoming TCP sessions.

If the connection fails immediately, verify:

  • Service status
  • Listening interface
  • Firewall configuration
  • Correct port number

Checking Local Firewall Rules

Local firewall policies may prevent Nginx from communicating with the dashboard even when both services reside on the same server.

Depending on your distribution, inspect the active rules using tools such as:

sudo ufw status
sudo firewall-cmd --list-all
sudo iptables -L -n

Look for rules that block traffic to the dashboard’s listening port or restrict communication between local interfaces.

Verifying localhost vs Private IP Connectivity

Many proxy issues stem from mismatched listening addresses.

For example:

  • The dashboard listens only on 127.0.0.1, while Nginx proxies to a private IP address.
  • The dashboard listens on a private IP, while Nginx is configured to use localhost.
  • IPv4 and IPv6 addresses are mixed unintentionally.

Test connectivity using the exact address specified in the proxy_pass directive. For example:

curl http://127.0.0.1:5601
curl http://192.168.1.20:5601

If one succeeds and the other fails, the issue is likely an interface binding or routing mismatch rather than an Nginx timeout problem.

Matching the dashboard’s listening address with the proxy_pass target is essential for reliable reverse proxy communication.

Review Your Nginx Reverse Proxy Configuration

Even if the Wazuh Dashboard is healthy, an incorrect Nginx configuration can prevent requests from reaching it successfully.

A single misconfigured directive may lead to intermittent timeouts, broken WebSocket connections, authentication failures, or HTTP 502 and 504 errors.

Before changing timeout values, carefully review your reverse proxy configuration.

Verify proxy_pass

The proxy_pass directive tells Nginx where to forward incoming requests.

A typical configuration looks like:

location / {
    proxy_pass http://127.0.0.1:5601;
}

Verify that:

  • The IP address is correct.
  • The hostname resolves properly.
  • The port matches the Wazuh Dashboard configuration.
  • The correct protocol (http:// or https://) is used.
  • There are no typographical errors.

Even a minor mistake can cause Nginx to wait for a backend response that never arrives.

The official Nginx documentation recommends verifying upstream server definitions whenever backend infrastructure changes.

Check Upstream Definitions

Many production deployments define upstream servers separately.

Example:

upstream wazuh_dashboard {
    server 127.0.0.1:5601;
}

server {
    location / {
        proxy_pass http://wazuh_dashboard;
    }
}

Review each upstream block to ensure:

  • Every backend server is reachable.
  • Hostnames resolve correctly.
  • Ports are accurate.
  • Removed servers are no longer referenced.
  • Load-balanced servers are healthy.

If one backend server is unavailable, users may experience intermittent timeout errors as Nginx cycles through upstream servers.

Confirm Host Headers

Many web applications, including the Wazuh Dashboard, expect the original Host header to be preserved.

A common configuration includes:

proxy_set_header Host $host;

Without the correct host header, the dashboard may:

  • Generate incorrect redirects.
  • Reject requests.
  • Produce authentication issues.
  • Fail to build URLs correctly.

Preserving the original host information also simplifies troubleshooting and logging.

Preserve Forwarded Headers

Forwarded headers allow the dashboard to identify the original client connection.

Common directives include:

proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Host $host;

Missing or incorrect forwarded headers can lead to:

  • Authentication problems
  • Invalid redirects
  • Session issues
  • Incorrect client IP logging
  • SSL redirect loops

These issues are especially common when Nginx sits behind an external load balancer.

Enable WebSocket Support

The Wazuh Dashboard uses WebSockets for several interactive features.

Without explicit WebSocket support, users may experience:

  • Live updates stopping
  • Session disconnects
  • Dashboard widgets failing
  • Endless loading indicators

A typical configuration includes:

proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";

These directives allow Nginx to properly proxy upgraded HTTP connections used by WebSockets.

Verify HTTP Version

By default, Nginx may proxy requests using HTTP/1.0.

Many modern applications, including the Wazuh Dashboard, expect HTTP/1.1 for persistent connections and WebSocket upgrades.

Verify the configuration includes:

proxy_http_version 1.1;

Without this directive, certain requests may terminate unexpectedly or behave inconsistently.

Validate SSL Configuration

If Nginx communicates with the dashboard over HTTPS, verify the SSL configuration on both sides.

Review:

  • Certificate validity
  • Certificate chain
  • TLS protocol versions
  • Cipher suites
  • Certificate file paths
  • Private key permissions

Handshake failures may appear as generic upstream timeout errors even though the actual issue occurs during TLS negotiation.

The official OpenSSL documentation recommends validating certificate chains whenever secure upstream connections fail.

Increase Nginx Proxy Timeout Settings

After confirming that the Wazuh Dashboard and reverse proxy are correctly configured, you may determine that the existing timeout values are too short for your workload.

Long-running dashboard searches, large visualizations, and high-volume log environments can legitimately require additional processing time.

In these cases, increasing Nginx timeout settings may prevent premature connection termination.

However, timeout adjustments should only be made after ruling out service failures, networking issues, and backend performance bottlenecks.

proxy_connect_timeout

This directive controls how long Nginx waits while establishing a connection to the upstream server.

Example:

proxy_connect_timeout 60s;

If the dashboard is slow to accept new connections because of heavy system load, increasing this value may prevent unnecessary connection failures.

proxy_read_timeout

proxy_read_timeout determines how long Nginx waits for data after successfully connecting to the dashboard.

Example:

proxy_read_timeout 300s;

This is one of the most important settings for Wazuh deployments because complex searches against the Wazuh Indexer can take significantly longer than ordinary page requests.

When this timeout expires, users typically receive:

  • 504 Gateway Timeout
  • upstream timed out
  • connection timeout

proxy_send_timeout

This directive specifies how long Nginx waits while sending requests to the upstream server.

Example:

proxy_send_timeout 300s;

Although dashboard requests are usually small, this setting becomes more important when large payloads or uploads are involved.

send_timeout

send_timeout controls how long Nginx waits while transmitting the response back to the client.

Example:

send_timeout 300s;

Slow client connections or network interruptions can trigger this timeout even when the dashboard responds normally.

keepalive_timeout

Persistent HTTP connections reduce connection overhead by allowing multiple requests to reuse the same TCP session.

Example:

keepalive_timeout 65s;

Proper keepalive values can improve overall dashboard responsiveness while reducing connection setup time.

Avoid setting extremely long values unless they are required for your environment.

When Increasing Timeout Values Is Appropriate

Increasing timeout settings is reasonable when:

  • Dashboards execute legitimately long searches.
  • Users analyze large historical datasets.
  • Security events span multiple indices.
  • Infrastructure latency is expected.
  • Hardware resources are temporarily constrained.
  • High-volume ingestion causes occasional processing delays.

Organizations with large Wazuh deployments often increase proxy_read_timeout after validating that backend services remain healthy and responsive.

Avoid Masking Underlying Performance Issues

Increasing timeout values should not become the default solution.

If the Wazuh Dashboard consistently requires several minutes to respond, investigate the underlying cause instead.

Potential root causes include:

  • Slow Wazuh Indexer queries
  • Excessive JVM heap pressure
  • CPU saturation
  • Disk bottlenecks
  • Memory exhaustion
  • Network latency
  • Oversized dashboards
  • Cluster health issues

Simply allowing Nginx to wait longer may hide these problems while overall system performance continues to degrade.

The Nginx engineering team recommends treating repeated timeout errors as indicators of backend performance issues rather than relying solely on larger timeout values.

Related Guides:

Inspect Nginx Error Logs

Nginx error logs are one of the most valuable resources for diagnosing upstream timeout problems.

They often identify the exact stage at which communication with the Wazuh Dashboard failed, making it much easier to distinguish between networking issues, configuration mistakes, and backend performance problems.

Whenever possible, review the error logs before making configuration changes.

Location of Nginx Logs

The log location depends on your Linux distribution and installation method.

Common locations include:

/var/log/nginx/error.log

and

/var/log/nginx/access.log

Some systems managed by systemd may also write messages to the system journal:

sudo journalctl -u nginx

Always ensure logging is enabled before beginning troubleshooting.

Reading Upstream Timeout Messages

The most recognizable indicator is an upstream timeout message similar to:

upstream timed out (110: Connection timed out)
while reading response header from upstream

or

upstream timed out

These entries indicate that Nginx successfully contacted the dashboard but did not receive a response before the configured timeout expired.

Pay attention to:

  • The requested URL
  • The upstream server address
  • The client IP
  • The timestamp
  • The HTTP status code

Together, these details help identify which requests consistently fail.

Identifying SSL Errors

TLS negotiation failures often generate log entries such as:

SSL_do_handshake() failed

or

SSL handshake failed

These errors may result from:

  • Expired certificates
  • Invalid certificate chains
  • Unsupported TLS versions
  • Cipher mismatches
  • Incorrect certificate configuration

Although users may only see a generic gateway error, the underlying issue is frequently an unsuccessful SSL handshake.

Detecting Connection Resets

Connection reset errors typically resemble:

recv() failed (104: Connection reset by peer)

or

Connection reset by peer

These messages indicate that the upstream server unexpectedly terminated the TCP connection.

Possible causes include:

  • Dashboard crashes
  • Process restarts
  • Memory exhaustion
  • Operating system resource limits
  • Application exceptions

Recognizing DNS Resolution Failures

If Nginx cannot resolve the configured upstream hostname, error logs often contain entries similar to:

host not found in upstream

or

no resolver defined

These messages point toward:

  • Missing DNS records
  • Incorrect resolver configuration
  • Internal DNS outages
  • Typographical errors in hostnames

Resolving DNS problems often restores proxy functionality immediately.

Correlating Timestamps with Dashboard Logs

One of the most effective troubleshooting techniques is comparing Nginx log timestamps with Wazuh Dashboard logs.

For example:

  1. Find the exact time a timeout occurred in error.log.
  2. Locate the corresponding entries in the dashboard logs.
  3. Check whether the dashboard:
    • Received the request.
    • Began processing it.
    • Encountered an exception.
    • Timed out while querying the Wazuh Indexer.
  4. Compare the same timestamp with Indexer logs and system resource metrics.

Correlating logs across multiple services provides a complete picture of the request lifecycle and helps pinpoint whether the failure originated in Nginx, the Wazuh Dashboard, the Wazuh Indexer, or the underlying operating system.

Related Guides:

DevOps

Wazuh

Be First to Comment

    Leave a Reply

    Your email address will not be published. Required fields are marked *