Make Your Logs Work for You

The days of logging in to servers and manually viewing log files are over. SolarWinds® Papertrail™ aggregates logs from applications, devices, and platforms to a central location.

View Technology Info

FEATURED TECHNOLOGY

Troubleshoot Fast and Enjoy It

SolarWinds® Papertrail™ provides cloud-based log management that seamlessly aggregates logs from applications, servers, network devices, services, platforms, and much more.

View Capabilities Info

FEATURED CAPABILITIES

Aggregate and Search Any Log

SolarWinds® Papertrail™ provides lightning-fast search, live tail, flexible system groups, team-wide access, and integration with popular communications platforms like PagerDuty and Slack to help you quickly track down customer problems, debug app requests, or troubleshoot slow database queries.

View Languages Info

FEATURED LANGUAGES

TBD - APM Integration Title

TBD - APM Integration Description

TBD Link

APM Integration Feature List

TBD - Built for Collaboration Title

TBD - Built for Collaboration Description

TBD Link

Built for Collaboration Feature List

Tips from the Team

HAProxy Logging – How to Tune Timeouts for Performance

START FREE TRIAL

Fully Functional for 30 Days

Last updated: October 2025

HAProxy (high availability proxy) is a critical part of modern systems infrastructure. It’s ideally the first point of contact for users who access your application. When configured correctly, HAProxy significantly improves your app’s performance. Through load balancing, HAProxy ensures that each service your application depends on remains accessible to users, particularly under load conditions that would otherwise impact application performance. 

I’m going to take you through the process of tuning timeouts with the goal of boosting application performance. You’ll see how robust HAProxy logging can help you troubleshoot timeout issues and improve the performance of your application. I’ll quickly go through some of the HAProxy timeout configurations to lay a foundation.  

Before we dive into the overview, let’s go over a few reasons why we need HAProxy and the logic behind it. This should help us visualize the “how” part later and understand why it’s worth going through the tuning processes.  

Why You’ll Need HAProxy 

Let’s think about how users might access your web application. In a basic setup, users connect directly to a single server that hosts your application. When someone visits your website, their browser sends a request to your server, which processes the request and sends back the response. This straightforward client-server architecture works perfectly fine when you have a small number of users accessing your application.

However, once the application gains traction and the number of users increases, you might observe a decline in application performance. When numerous users access the application simultaneously, requests can back up and even overwhelm the application.

A good analogy is a single-lane road going from point A to point B, which becomes congested when there are too many cars. Adding HAProxy as a load balancer is like adding lanes to the road. More lanes mean more vehicles can now travel the road.  

Additional lanes won’t increase speed, but one car can travel down the road without waiting for the car in front of it to move forward. However, if you add enough vehicles, even these additional lanes will become congested. This is where the concept of timeouts is crucial in avoiding jams.

Timeouts terminate connections after a client waits for a predetermined amount of time to access the server. This frees up connections, allowing active users to access the application. It’s as if the stalled cars are taken off the road so that other vehicles can move freely. Let’s quickly cover the various types of timeouts before we get to the tuning part.   

The Three Basic HAProxy Timeouts 

To illustrate what timeout configurations look like, here’s a sample that includes the three basic timeouts.

##based on Mesosphere Marathon's servicerouter.py haproxy config

global
daemon
log 127.0.0.1 local0
log 127.0.0.1 local1 notice
maxconn 4096
tune.ssl.default-dh-param 2048

defaults
log global
retries 3
maxconn 2000
timeout connect 5s
timeout client 50s
timeout server 50s

Source: GitHub

1. Timeout client 

The timeout client setting defines the maximum time a client can be inactive when connected to the server. A standard value for this timeout is five minutes. You can opt for shorter timeouts—even as short as 30 seconds—if you’re trying to maximize security or the total number of active connections. As the name suggests, this timeout is handled on the client side.

2. Timeout connect 

The timeout connect setting works like a grace period. It sets the maximum time the client has to connect to a server. The time it takes a client to connect to a server can vary significantly, depending on the complexity of the network. The more complex a topology, the longer it can take the client to connect.

This setting allows the client to try to connect again if the initial attempt fails. In addition to the connection time, you’ll need to set the number of retries. The default for the number of retries is three, but you can adjust it to fit your environment.

3. Timeout Server 

When a client sends a request to the server, it expects a response. If the server doesn’t respond within the configured time duration, a timeout server is invoked. This is akin to the timeout client—only in reverse. If a timeout server is invoked, you’ll get a 504 Gateway Timeout response from HAProxy.  

HAProxy Timeout Tuning for Good Performance 

Just by configuring these three timeout values in your haproxy.cfg file, you can achieve a basic level of performance. If you want to enhance performance even further, you can adjust other timeout settings. While the values you set will vary depending on your traffic load and environment, I’ve listed the most common configurations below. To use these, append them to your configuration file.   

timeout http-request 10s
timeout http-keep-alive 2s
timeout queue 5s
timeout tunnel 2m
timeout client-fin 1s
timeout server-fin 1s

Timeout HTTP-Request 

The timeout http-request variable limits the total time each request can persist. Aside from optimizing request performance, it can also defend against denial-of-service (DoS) attacks by limiting the duration of a single request. Usually, 10 seconds is a reasonable limit.  

Some php.ini files may also have this setting, but since the proxy server is the first point of contact with an application, php.ini settings are overridden. This is true unless the application server level (php.ini) setting is shorter than the proxy-determined variable.  

Timeout HTTP-Keep-Alive 

As the name suggests, this is a timeout designed to keep a single connection between the client and the server “alive” for a desired amount of time. While the connection is active, all data packets can pass without needing to reestablish the connection. This essentially enables the server to respond more quickly to the client.  

Keep in mind that the timeout http-request regulates how long a single request can persist, so these two settings work hand in hand. If the timeout http-keep-alive isn’t set or has a value less than the timeout http-request, the latter determines the connection status.  

Timeout Queue

The timeout queue defines how long a request can wait in HAPoxy’s queue when all the servers are busy, which can also impact performance. Setting the queue timeout to a short duration shortens wait times by failing queued requests sooner and allowing clients to attempt reconnection if the queue is full. This is similar to timeout connect, except that the timeout queue limits the number of connections.

If you don’t set the timeout queue, HAProxy will default to the timeout connect settings to manage the queue.  

Timeout Tunnel 

The timeout tunnel variable only applies when you’re working with WebSockets. Essentially, it’s timeout http-keep-alive on steroids, often with durations exceeding minutes. It may seem counterproductive and a potential security risk to keep a connection open for that long. However, when used with other timeout configurations, it’s possible to maintain a safe yet high-performing connection.  

For instance, the timeout http-request variable would prevent an attack even if the timeout tunnel is set at several minutes. Remember, though, that the virtual tunnel you create by implementing this timeout requires you to terminate it at some point using the timeout client-fin parameter.  

Timeout Client-Fin 

Say a connection drops in the middle of a client request; if you look at the HAProxy logs, you’re likely to see that the lost connection is a result of client-side network issues. To handle these types of situations, HAProxy creates a list of dropped client-side connections. The timeout client-fin limits the amount of time a client request will be maintained on this list.    

This parameter starts ticking when a connection is added to the list. Without it, the server will maintain a “maybe they’ll return” sort of connection while others are denied service. To optimize performance, the values set for this timeout are usually short.  

Timeout Server-Fin 

Much like the timeout client-fin concept, abrupt disconnections can also occur on the server side of the application. An optimal setup would include redundant servers for load balancing. When a server has too many requests, redundancy will allow you to reroute overflow requests to less busy servers and speed up response times.  

The timeout server-fin limits the time the client waits for a server response before an alternate server is queried.

HAProxy Logging: How to Determine Perfect Timeouts

By now, you can see how environment variables and traffic can help you determine the time allocations for the timeouts above. Finding the perfect balance between peak performance and optimal security is a matter of trial and error. Keeping a close eye on HAProxy logs can help you see the interactions between these different configurations and find the “sweet spot” for your application and environment. You can use HAProxy logs to understand:  

  • Timestamped metrics about traffic (timing data, connection counters, traffic size) 
  • Detailed event logs of HAProxy operations (content switching, filtering, persistence) 
  • Request and responses (headers, status codes, payloads) 
  • Session terminations and tracking where failures are occurring

Knowing when a timeout event occurs and monitoring the events preceding it are the first steps in successfully troubleshooting and tuning timeout settings. If you’re looking for an easy-to-use cloud-based log management tool, consider SolarWinds Papertrail. Built by engineers for engineers, SolarWinds Papertrail can automatically parse HAProxy logs and help you quickly troubleshoot timeout issues.

It offers a simple search syntax, allowing you to search all your logs from a central interface, view events in context, and pinpoint issues. The live tail feature is invaluable for real-time troubleshooting. If you want to start HAProxy logging with better results, sign up for a free trial.  

Aggregate, organize, and manage your logs

  • Collect real-time log data from your applications, servers, cloud services, and more
  • Search log messages to analyze and troubleshoot incidents, identify trends, and set alerts
  • Create automated backups, and archives of up to a year of historical data
Start Free Trial

Fully Functional for 30 Days

Let's talk it over

Contact our team, anytime.