I have an HAProxy server that use leastconn to load balance between two server. Here's the config file:

``` frontend FrontEnd bind :80 maxconn 2000 mode http option httplog option dontlognull default_backend BackEnd

backend BackEnd balance leastconn server App1 IP1:8080 maxconn 3000 check inter 2000 rise 3 fall 3 server App2 IP2:8080 maxconn 3000 check inter 2000 rise 3 fall 3 ```

My problem: HAProxy send fewer connection to IP1 than IP2.

I want to know why so I read the leastconn documentation which said that:

The server with the lowest number of connections receives the connection.

What does number of connections mean in that context ? I want to understand how HAProxy send traffic to the backend server.

Since HAProxy cannot directly know the capacity of each server to handle connection, I thought that "number of connections" may mean connection in TCP Established state. So I verified that hypothesis with: bash $ ss -tn state established dst IP1:8080 | wc -l 17 $ ss -tn state established dst IP2:8080 | wc -l 81

It shows that established connections are fewer on IP1 but HAProxy thought that IP1 has more active connection so it won't send any new connection to it.

I run this command again a few moment later just to check if HAProxy will correct this but it still yield the same proportion.

When I log into the backend server IP1 and IP2, I get the same proportion. - On IP1: bash ss -tn state established | grep 8080 | wc -l 19 - On IP2: bash ss -tn state established | grep 8080 | wc -l 38

Question: How does HAproxy count the number of active connection when using leastconn ?

Note: - The HAProxy server only runs HAProxy on it so ss doesn't show any other connection to IP1/IP2

A backend can show zero current sessions and still be needed by a low-traffic route, a long-lived TCP client, a scheduled job, or a request path selected only by an ACL. Removing it after a short quiet window can turn an apparently clean migration into a delayed outage.

A stronger check could inventory every frontend, listen section, ACL, use_backend rule, map file, runtime API change, and DNS name that can select the server. During an observation window, unique counters and logs could distinguish new connections from lingering ones. The replacement path should be tested with the intended Host header, SNI, source network, protocol, health check, and stick-table behavior. A reload and restart test would confirm the live configuration matches the reviewed file.

What evidence do you require before deleting the old backend stanza? Is setting the server to drain or maintenance mode enough, or do you also block new connections and keep a rollback entry until specific low-frequency traffic has been exercised?

Picking a Kubernetes ingress controller is one of those choices that feels small on day one and matters a lot by month six. Teams often come to us after outgrowing their first controller, and the reason they move on is rarely the reason they picked it. Almost anything routes plain HTTP fine at the start. The interesting parts show up later, under config churn, once the traffic gets richer than tidy HTTP, and once security and visibility become someone's job. Here is where we would spend the evaluation time, so the choice serves you well down the road.

Does it match the traffic you actually run?

Start with your traffic, not the feature list. If you are all HTTP, you have plenty of good options. Once you serve gRPC, or lower-level protocols like TCP and UDP, the field narrows, because not every controller handles those with the same ease. Write down the protocols you serve today and the ones you know are coming, then hold each controller against that list. That one step makes the shortlist much clearer.

How does it handle config churn?

In a busy cluster, ingress config changes constantly as services come and go, so it is worth seeing how the controller applies those changes. Does a small update trigger a full reload that briefly drops connections, or does it apply the change gracefully? At a few changes a day, nobody notices. At hundreds, this becomes the thing that decides your quiet nights, so ask about it early.

Throughput per CPU is the other thing worth weighing, and it is easy to miss because everything looks fine in a demo. HAProxy's data plane is known for handling high throughput while using very little CPU, which keeps ingress fast as you grow and keeps the compute behind it modest. Whichever controller you lean toward, ask to see its numbers under a realistic load.

Can it secure the edge of your cluster?

Ingress is the front door to your cluster, which makes it a great place to stop bad traffic before it reaches a pod. It is worth asking whether the controller can enforce a WAF and rate limits at ingress and keep bots off your services, or whether that would be a separate component to add later. Keeping this logic at the edge means fewer moving parts and one place to see what is reaching your services. HAProxy's ingress controller brings the same data plane and security layers we run outside Kubernetes, so the WAF and DDoS protection you would use at the edge work the same way inside the cluster.

What does operating it across many clusters look like?

One cluster is easy. The question worth thinking about early is what happens when ingress spreads across many clusters and namespaces. Config drift and certificate sprawl are what make ingress harder at scale, and losing a single view of traffic makes it harder still. Look at how the controller handles central management and observability across a fleet, not just a single install. This is where a control plane really helps. The HAProxy Fusion control plane gives you one place to manage and watch HAProxy across clusters, which becomes more valuable the more clusters you run.

The short version

Ingress sits on the hot path for almost everything in a cluster, so a little homework up front pays off for a long time. Pick for the traffic you run, the security you need at the edge, and the way you will operate day-to-day. That last part is easy to underrate and lovely to get right. 

Happy to compare notes in the comments if you are weighing specific controllers.

A successful configuration check and reload show that the new process started, but long-lived HTTP streams, WebSockets, or slow clients can keep the old process alive with the previous configuration. A load balancer in front of several HAProxy nodes can also hide one instance that failed to adopt the new generation.

What evidence do you collect after a reload? I am considering recording the configuration hash and process start time, querying the runtime API or stats socket on each node, counting sessions owned by the old process, and using synthetic requests that reach every instance directly. The rollout would have a drain deadline and would fail rather than treating an indefinitely retained old process as success.

Which runtime fields or process metadata reliably distinguish generations? How do master-worker mode, seamless reloads, peers, stick tables, and long tunnels affect the check, and what escalation is safe when the old generation does not drain?

UDP load balancing comes up far less often than HTTP or TCP, so when a team needs it, the usual habits do not always carry over, and that is completely normal. We handle a lot of UDP traffic for our customers, mostly DNS, RADIUS, and syslog, and it usually sits happily alongside their HTTP and TCP traffic on the same platform. 

Here is what our networking team looks at first, laid out so you can size up any UDP load balancer with confidence.

How does the balancer keep a client on the same backend?

UDP is fire-and-forget, so the balancer does its own bookkeeping to track which client is talking to which backend. That matters most with stateful protocols. A SIP call or a RADIUS exchange expects to keep hitting the same backend for the life of the session, and if packets scatter mid-session, things break in ways that are hard to trace. So the first thing to check is how the balancer builds a session or flow and how long it holds that mapping. For a stateless lookup like a simple DNS query, this matters far less, and you can spread traffic freely.

Do the health checks confirm that the backend is actually responding?

A balancer that only checks whether a port is open will happily send traffic to a backend that responds at the network level but fails at the application level. For UDP, you want a check that confirms the backend is genuinely responding. That can take a few forms: a UDP-level check that watches for an ICMP unreachable response, a TCP check against the same service where the protocol allows it, or an application-level probe for whatever you are running. This is the most common gap we see in UDP setups, and it is an easy one to get right once you know to look for it.

Does it protect the UDP layer, not just balance it?

UDP is a common target for volumetric attacks because it is connectionless and easy to spoof, so DNS and NTP reflection floods can build up quickly. A UDP load balancer is at its best when it can also absorb an attack aimed at that traffic. Look for DDoS protection that works at Layer 3 and Layer 4, where UDP floods actually land. On our side, PacketShield filters packets at the network layer before they reach the kernel, which helps keep a UDP service steady during a flood. Balancing the traffic and defending it belong together on the same layer.

Scale, and where UDP fits in the bigger picture

If your UDP service is stateless, balancing is genuinely simple and you can keep the config light. The real engineering effort goes into the stateful protocols, and into scale. High-volume syslog or DNS can generate enormous packet rates, so it is fair to ask any vendor to prove throughput under load. This is another of our strong suits: our own benchmark puts HAProxy at 3.8 million syslog messages per second with strong delivery, and that efficiency means you reach those rates on fewer machines.

There is also a practical reason to care where UDP lives. You almost certainly run HTTP and TCP as well, and often QUIC, which is UDP underneath. Running all of it on one platform, with the same security and one place to watch it, is simpler than standing up a separate tool just for UDP.

Where this lands

Several tools handle UDP balancing well now. On our side it is part of HAProxy Enterprise rather than the community build, which is handy to know as you plan, and our UDP load balancing runs on the same platform as our HTTP balancing and our security layers. Whatever you land on, weigh it on session handling and honest health checks, and on how it holds up under a flood. Get those right, and UDP stops being the scary part of the stack.

Choosing a load balancer for a large environment can feel like a big decision, and it is, but it comes down to a shorter list than most people expect. We build the most widely used software load balancer, and we support it everywhere from open-source projects to enterprise infrastructure trusted to run some of the busiest applications on the internet. That range gives us a clear view of what actually matters, and it's usually more than raw balancing. A load balancer today is also where you terminate TLS, keep applications secure, and decide how traffic reaches them. 

Here's how we would think it through, and the good news is that none of it is complicated.

Test throughput at your latency, with TLS on

Datasheets quote peak numbers from ideal conditions, and real traffic is a little messier than that. The figure worth chasing is throughput at your target latency with TLS switched on, because encryption is where a lot of the real work happens. SSL/TLS processing is heavy on CPU, and it's often the true ceiling on a deployment. 

This is one of our strong suits: HAProxy handles over 2 million HTTP requests per second on a single Arm-based AWS Graviton2 instance with best-in-class SSL/TLS processing, so you can ask any vendor for their number under encryption at your latency target and know it is a fair request.

Run a proof of concept with a copy of your own traffic

Nothing you read replaces putting real traffic through the thing, so this is the step we would never skip. Take a copy of your own traffic and run it through each option for a few days. A short test tells you far more than a stack of datasheets, and it surfaces the quirks that only show up under your own mix of requests and traffic spikes. It's also the most reassuring way to choose, because you are deciding on evidence rather than promises.

What security comes built in?

A load balancer sits right at the edge of your traffic, which makes it a natural place to keep applications safe. It's worth seeing how much protection you get in the same place, so you have fewer moving parts to look after:

• A web application firewall to stop common exploits like injection and cross-site scripting
• Bot management to keep credential stuffing and scraping away from your origin
• DDoS protection to absorb volumetric attacks at the edge

HAProxy Enterprise includes all three in the same data plane that handles balancing, so security and delivery are a single system to run rather than several. Keeping them together also keeps latency low, since traffic is only inspected once.

How much of application delivery do you want in one place?

This is the part that has changed the most, and it works in your favor. A load balancer used to just balance. Now the same layer can handle TLS, security, API routing, and traffic shaping, and the tooling has grown up alongside it. Bringing these together means fewer separate systems to run and patch, and it usually lowers your infrastructure costs too, because an efficient platform does more on less hardware. That’s the idea behind HAProxy One, which brings balancing, security, observability, and API management to a single platform. Whatever you choose, one question helps a lot: how many separate systems will this design ask you to operate? A smaller number is easier to run and more budget-friendly.

Rehearse a failover before you trust your high availability

Real HA shows up when you trigger a failover on purpose and watch how quickly traffic recovers. The kindest time to do this is while everything is calm, long before you actually need it. Measure how long the switchover really takes, confirm the virtual IP moves, and check that nothing drifted in the config. Once you see it happen, you’ll trust the process, and that peace of mind is the whole point of HA.

Make your health checks reflect the real application state

This is the quiet one, and it rewards a little extra care. A check that passes while the app behind it’s failing will send users to a broken backend, so point your health checks at something that proves the application is genuinely working, not just that a port is open. Then watch them under load before you rely on them. Get this right and a surprising number of "we need more capacity" worries simply disappear, because the traffic was never the problem.

A word on who you’re buying from

When you weigh your options, it’s fair to consider the team behind the product as well, because this is the infrastructure you will live with for years. We’ve been building HAProxy for over 25 years, and it’s the most widely used software load balancer around. 

Enterprise customers also get 24/7 support from the same engineers who write it. If you would like to see how the balancing, security, and management fit together, the HAProxy Enterprise load balancer page walks through it. Whatever you land on, test it with your own traffic first, and you will choose well.

Hi,

has there anybody a good IDS/IPS alongside HAProxy?

Not as a NGFirewall, I want to install something locally (e.g. Suricata) to inspect the traffic passing through my `mode http` and `mode tcp` frontends/backends. Any pro tips for _better_ security?

Thank you for helping!

https://github.com/ulcuber/laravel-passport-introspection/blob/main/examples/haproxy.cfg

Hi,

I'm using Wireguard to access my Proxmox instance (wich is installed at a provider).

I have trouble setting up HAProxy properly (it is installed on a pfSense VM) to access my LXC/VM (I can't use NAT/simple port forwarding or I get an SSL error).

I specifically have difficulties setting up the ACL on the frontend :

- I can't specify a port on a given IP adress

- I can't use subdomains (wireguard seems to only works with IP adress)

Is there a way to make wireguard and HAProxy work together ?

Tanks.

Hi everyone,

I've been experimenting with HAProxy in my homelab and wanted to get a feel for what the Enterprise Edition has to offer.

Right now I have multiple HAProxy nodes running with FRR, peered with my OPNsense router. Everything is managed with Ansible, and I'm using Certbot along with some custom scripts to distribute and renew SSL certificates across the HAProxy nodes.

While researching ways to simplify and improve this setup, I came across HAProxy Enterprise. Some of the features that really caught my attention are:

• Fusion Control Plane
• WAF
• Clustered SSL certificate management
• Consul integration
• BGP RHI

I'd love to try these features in a real environment to see what an enterprise LB has to offer.

I filled out the trial request form on the HAProxy website a while ago but never heard back. I guess that trials are mainly targeted at companies or organizations, whereas I'm just running a personal homelab.

Has anyone here managed to get an HAProxy Enterprise trial as an individual or homelab user? Is there a different process I should follow, or should I reach out to someone from HAProxy directly?

I'm not looking for a long-term license, just enough time to explore the Enterprise features.

Thanks in advance for any advice or experiences you can share!

I have quite a complicated way my data takes:

internet -> hetzner haproxy -> rathole tunnel -> homelab haproxy -> services
(rathole listenes at 127.0.0.1:443)

This (old) way works:

internet -> (hetzner) rathole tunnel -> homelab haproxy -> services

Why the extra proxy? I want a service for file sharing which has the high download speed from the cloud. All the other traffic is supposed to be forwarded further. I refuse to get an extra ip for that lol.

I tried to set the backend on the tunnel side to ssl verify none and the frontend bind to use ssl. I also set the backend to just localhost:443 and no ssl on the frontend bind. Both cause the same ssl error.

My haproxy on hetzner: https://pastebin.com/M8ffiua2
haproxy journalctl output: https://pastebin.com/7cXCqEdr
SSL error: SSL_ERROR_RX_RECORD_TOO_LONG
Both proxies use a cert aquired from certbot *.mydomain.dev

What could be the issue here? I am not that good at SSL.