# Advanced Features

> Runtime management, operating-system capabilities, Lua scripting, and live tracing

---

LLMS index: [llms.txt](/llms.txt)

---

<!-- Generated by scripts/generate-haproxy-docs.py from pinned upstream text. -->

## 3.5.1. Advanced features : Management {#section-3-5-1}

HAProxy is designed to remain extremely stable and safe to manage in a regular production
environment. It is provided as a single executable file which doesn't require any installation
process. Multiple versions can easily coexist, meaning that it's possible (and recommended) to
upgrade instances progressively by order of importance instead of migrating all of them at once.
Configuration files are easily versioned. Configuration checking is done off-line so it doesn't
require to restart a service that will possibly fail. During configuration checks, a number of
advanced mistakes may be detected (e.g. a rule hiding another one, or stickiness that will not work)
and detailed warnings and configuration hints are proposed to fix them. Backwards configuration file
compatibility goes very far away in time, with version 1.5 still fully supporting configurations for
versions 1.1 written 13 years before, and 1.6 only dropping support for almost unused, obsolete
keywords that can be done differently. The configuration and software upgrade mechanism is smooth
and non disruptive in that it allows old and new processes to coexist on the system, each handling
its own connections. System status, build options, and library compatibility are reported on
startup.

Some advanced features allow an application administrator to smoothly stop a server, detect when
there's no activity on it anymore, then take it off-line, stop it, upgrade it and ensure it doesn't
take any traffic while being upgraded, then test it again through the normal path without opening it
to the public, and all of this without touching HAProxy at all. This ensures that even complicated
production operations may be done during opening hours with all technical resources available.

The process tries to save resources as much as possible, uses memory pools to save on allocation
time and limit memory fragmentation, releases payload buffers as soon as their contents are sent,
and supports enforcing strong memory limits above which connections have to wait for a buffer to
become available instead of allocating more memory. This system helps guarantee memory usage in
certain strict environments.

A command line interface (CLI) is available as a UNIX or TCP socket, to perform a number of
operations and to retrieve troubleshooting information. Everything done on this socket doesn't
require a configuration change, so it is mostly used for temporary changes. Using this interface it
is possible to change a server's address, weight and status, to consult statistics and clear
counters, dump and clear stickiness tables, possibly selectively by key criteria, dump and kill
client-side and server-side connections, dump captured errors with a detailed analysis of the exact
cause and location of the error, dump, add and remove entries from ACLs and maps, update TLS shared
secrets, apply connection limits and rate limits on the fly to arbitrary frontends (useful in shared
hosting environments), and disable a specific frontend to release a listening port (useful when
daytime operations are forbidden and a fix is needed nonetheless). Updating certificates and their
configuration on the fly is permitted, as well as enabling and consulting traces of every processing
step of the traffic.

For environments where SNMP is mandatory, at least two agents exist, one is provided with the
HAProxy sources and relies on the Net-SNMP Perl module. Another one is provided with the commercial
packages and doesn't require Perl. Both are roughly equivalent in terms of coverage.

It is often recommended to install 4 utilities on the machine where HAProxy is deployed:

- socat (in order to connect to the CLI, though certain forks of netcat can also do it to some
  extents);

- halog from the latest HAProxy version: this is the log analysis tool, it parses native TCP and
  HTTP logs extremely fast (1 to 2 GB per second) and extracts useful information and statistics
  such as requests per URL, per source address, URLs sorted by response time or error rate,
  termination codes etc. It was designed to be deployed on the production servers to help
  troubleshoot live issues so it has to be there ready to be used;

- tcpdump: this is highly recommended to take the network traces needed to troubleshoot an issue
  that was made visible in the logs. There is a moment where application and haproxy's analysis will
  diverge and the network traces are the only way to say who's right and who's wrong. It's also
  fairly common to detect bugs in network stacks and hypervisors thanks to tcpdump;

- strace: it is tcpdump's companion. It will report what HAProxy really sees and will help sort out
  the issues the operating system is responsible for from the ones HAProxy is responsible for.
  Strace is often requested when a bug in HAProxy is suspected;

## 3.5.2. Advanced features : System-specific capabilities {#section-3-5-2}

Depending on the operating system HAProxy is deployed on, certain extra features may be available or
needed. While it is supported on a number of platforms, HAProxy is primarily developed on Linux,
which explains why some features are only available on this platform.

The transparent bind and connect features, the support for binding connections to a specific network
interface, as well as the ability to bind multiple processes to the same IP address and ports are
only available on Linux and BSD systems, though only Linux performs a kernel-side load balancing of
the incoming requests between the available processes.

On Linux, there are also a number of extra features and optimizations including support for network
namespaces (also known as "containers") allowing HAProxy to be a gateway between all containers, the
ability to set the MSS, Netfilter marks and IP TOS field on the client side connection, support for
TCP FastOpen on the listening side, TCP user timeouts to let the kernel quickly kill connections
when it detects the client has disappeared before the configured timeouts, TCP splicing to let the
kernel forward data between the two sides of a connections thus avoiding multiple memory copies, the
ability to enable the "defer-accept" bind option to only get notified of an incoming connection once
data become available in the kernel buffers, and the ability to send the request with the ACK
confirming a connect (sometimes called "piggy-back") which is enabled with the "tcp-smart-connect"
option. On Linux, HAProxy also takes great care of manipulating the TCP delayed ACKs to save as many
packets as possible on the network.

Some systems have an unreliable clock which jumps back and forth in the past and in the future. This
used to happen with some NUMA systems where multiple processors didn't see the exact same time of
day, and recently it became more common in virtualized environments where the virtual clock has no
relation with the real clock, resulting in huge time jumps (sometimes up to 30 seconds have been
observed). This causes a lot of trouble with respect to timeout enforcement in general. Due to this
flaw of these systems, HAProxy maintains its own monotonic clock which is based on the system's
clock but where drift is measured and compensated for. This ensures that even with a very bad system
clock, timers remain reasonably accurate and timeouts continue to work. Note that this problem
affects all the software running on such systems and is not specific to HAProxy. The common effects
are spurious timeouts or application freezes. Thus if this behavior is detected on a system, it must
be fixed, regardless of the fact that HAProxy protects itself against it.

On Linux, a new starting process may communicate with the previous one to reuse its listening file
descriptors so that the listening sockets are never interrupted during the process's replacement.

## 3.5.3. Advanced features : Scripting {#section-3-5-3}

HAProxy can be built with support for the Lua embedded language, which opens a wide area of new
possibilities related to complex manipulation of requests or responses, routing decisions,
statistics processing and so on. Using Lua it is even possible to establish parallel connections to
other servers to exchange information. This way it becomes possible (though complex) to develop an
authentication system for example. Please refer to the documentation in the file
"doc/lua-api/index.rst" for more information on how to use Lua.

## 3.5.4. Advanced features: Tracing {#section-3-5-4}

At any moment an administrator may connect over the CLI and enable tracing in various internal
subsystems. Various levels of details are provided by default so that in practice anything between
one line per request to 500 lines per request can be retrieved. Filters as well as an automatic
capture on/off/pause mechanism are available so that it really is possible to wait for a certain
event and watch it in detail. This is extremely convenient to diagnose protocol violations from
faulty servers and clients, or denial of service attacks.
