Column 1
Skip to content
Column 1

HAProxy 3.4 LTS: Upgrade Checklist for Load Balancers

HAProxy 3.4 was released on June 3, 2026 and is now listed by HAProxy.org as an LTS branch. HAProxy.org lists version 3.4.0 with an end-of-life target of 2031-Q2, which makes this more than a feature release for web hosts, SaaS teams, agencies, and infrastructure admins. It is a good moment to plan the next load-balancer maintenance path.

The release adds dynamic backend management, performance and memory improvements, native cryptographic operations at the proxy layer, ACME and TLS updates, broader glitch detection, stream elasticity, and OpenTelemetry support as the forward path for tracing. HAProxy also notes that OpenTracing is deprecated in 3.4 and planned for removal in 3.5.

This is an operations guide. It is not telling every production site to jump immediately. The right path is to inventory the current branch, test the configuration, confirm package support, drain traffic carefully, and verify real application behavior after the change.

What changed in HAProxy 3.4

  • Dynamic backends: operators can add, publish, and delete backend sections at runtime without a full reload when the deployment is designed for that model.
  • HTTP/3 and QUIC experiments: QMux support is available for environments where carrying QUIC over TCP is useful, but it should be treated as a lab or controlled rollout feature.
  • Performance: HAProxy reports smarter buffer allocation and efficiency improvements on large-core-count systems.
  • TLS and API security: HAProxy 3.4 adds native cryptographic building blocks and enhanced ACME handling for certificate workflows.
  • Reliability: glitch detection now covers HTTP/1 as well as HTTP/2 and QUIC, and stream elasticity helps moderate concurrent H2/H3 streams under load.
  • Observability: OpenTelemetry support arrives as an add-on, while OpenTracing is deprecated and should be migrated before HAProxy 3.5.

Who should plan this upgrade

HAProxy 3.4 is most interesting for teams running their own edge, reverse proxy, API gateway, high-traffic WordPress or WooCommerce stack, SaaS ingress tier, Kubernetes ingress layer, or CDN/origin routing system. It is also relevant if you depend on HAProxy for TLS termination, ACME automation, HTTP/2 or HTTP/3 behavior, health checks, backend draining, or detailed request logging.

If your server gets HAProxy from an operating-system vendor, cPanel/WHM extension, Plesk extension, appliance vendor, or managed hosting image, do not replace it blindly. Vendor packages may lag or backport fixes. Confirm the supported path before changing a production package source.

Pre-upgrade checklist

  1. Record the current branch and package source. Note whether you are on HAProxy 2.8, 3.0, 3.2, 3.3, a distro build, a container image, or a vendor appliance package.
  2. Back up configuration and maps. Include HAProxy config files, map files, certificate paths, systemd overrides, runtime API socket permissions, WAF/rate-limit files, and deployment manifests.
  3. Check deprecated features. Look for OpenTracing usage and older compression-direction settings before testing 3.4.
  4. Validate the configuration in staging. Run HAProxy's built-in configuration check against the exact files you plan to ship.
  5. Test TLS and ACME behavior. Confirm certificates, chains, OCSP behavior, ALPN, HTTP/2, HTTP/3, and automated renewal paths before production reloads.
  6. Plan backend draining. Keep health checks green, drain one load balancer or node at a time, and verify that sticky sessions, WebSockets, long polling, and uploads survive the maintenance plan.
  7. Confirm observability changes. If you use OpenTracing, plan the OpenTelemetry migration now instead of waiting for the 3.5 removal window.

Production rollout notes

For a pair of load balancers, update the standby node first, validate config, start HAProxy, confirm health checks, then move a small slice of traffic before making it primary. For containerized or Kubernetes deployments, pin the intended image tag or digest, roll a small replica set first, and watch both application metrics and HAProxy logs.

Dynamic backends are powerful, but they also change the operational model. If a control plane can create or publish backends at runtime, review who can access that control plane, how changes are audited, and what happens when a backend is unpublished or removed during live traffic.

Post-upgrade verification

  • HAProxy reports the intended 3.4 build and package source.
  • Configuration validation passes for every frontend, backend, map, certificate, and include file.
  • Health checks show expected backend status before and after traffic is restored.
  • HTTP, HTTPS, HTTP/2, HTTP/3, WebSocket, upload, and long-running request paths behave normally.
  • TLS certificates, ACME automation, redirects, HSTS, and CDN/proxy-chain headers still match policy.
  • Rate limits, WAF rules, bot controls, stick tables, and failover behavior still work.
  • Logs, metrics, alerting, and tracing are visible in the expected monitoring stack.
  • OpenTracing users have a migration plan toward OpenTelemetry before HAProxy 3.5.

Hosting and site-owner notes

Business site owners may never log into HAProxy directly, but they can still feel a bad load-balancer upgrade as checkout failures, login loops, broken uploads, missing WebSocket connections, certificate warnings, or random 502/503 errors. If HAProxy sits in front of WordPress, WooCommerce, WHMCS, cPanel, Plesk, or a customer portal, test those flows instead of checking only the home page.

For providers, tell customers when a maintenance window may affect edge routing, TLS, redirects, or portal sessions. Keep rollback simple: known-good package, known-good config, and a cache/CDN purge plan if headers or redirects changed.

Related Fix I.T. Phill reading

Sources

Need help planning a load-balancer upgrade window? Fix I.T. Phill can help inventory the current HAProxy branch, test the config, stage a safe reload, verify TLS and health checks, and document the rollback path.

Related load and DDoS readiness background

Related HTTP and bot-traffic background

June 2026 HPACK update: CVE-2026-55204

June 27, 2026 update: HAProxy Technologies published guidance for CVE-2026-55204, a high-scored availability issue in HAProxy's HTTP/2 HPACK header handling. The public CVE record lists HAProxy through 3.4.0 as affected and points to an upstream fix commit. HAProxy's own advisory says the practical attack risk is low, no exploitation is known, and the issue was not reproduced on a standard HAProxy build.

For hosting teams, the safe response is measured patch planning rather than panic. Treat HAProxy Community, HAProxy Enterprise, and HAProxy ALOHA systems that terminate or proxy HTTP/2 traffic as in scope. Track the fixed package or tagged release for your branch, then schedule the update with the same controls used for normal HAProxy maintenance: config validation, backend drain, health-check review, certificate/TLS check, safe reload, and post-change log review.

At the time HAProxy published its June 26 advisory, the fix had been committed upstream but had not yet landed in a tagged HAProxy Community release. HAProxy Enterprise and ALOHA customers should follow their supported release track and customer portal guidance. Community users should watch for a fixed tagged release or their distribution's backport before treating the update as complete.

While waiting for packaged fixes, keep HAProxy instances within healthy memory limits, review monitoring for low-memory conditions, and avoid combining this change with unrelated CDN, TLS, or backend migrations unless the maintenance window is intentionally broader. If your HAProxy layer sits behind Cloudflare or another CDN, verify both the CDN-to-origin path and the direct admin path after reloading.

Sources: HAProxy Technologies advisory for CVE-2026-55204, CVE.org CVE-2026-55204 record, and NVD API record for CVE-2026-55204.

June 2026 HTTP/2 Bomb update: CVE-2026-49975

HAProxy has published guidance for the HTTP/2 Bomb resource-exhaustion issue tracked as CVE-2026-49975. Treat this as a load-balancer and backend-web-server review item: confirm where HTTP/2 terminates, which systems are directly exposed, and whether vulnerable backends are protected by HAProxy, a CDN, or another trusted edge layer.

For HAProxy Community and HAProxy Enterprise users, the vendor says HAProxy is designed with strict per-connection and per-stream memory controls that prevent this class from overwhelming HAProxy itself. That does not remove the need to patch backend Apache, Nginx, IIS, Envoy, Pingora, or application stacks where HTTP/2 is exposed directly or where traffic can bypass the proxy.

Safe admin checklist

  • Inventory public HTTP/2 termination points: CDN, HAProxy, Nginx, Apache, IIS, Envoy, cloud load balancers, and direct origin listeners.
  • Patch backend web servers through the normal vendor or control-panel channel before relying on configuration workarounds.
  • For Apache/cPanel environments, check EasyApache and Apache HTTP Server package status, then restart or reload during a planned maintenance window.
  • For HAProxy, validate configuration before reload, drain backends where needed, preserve active sessions, and watch health checks after the change.
  • Review memory, worker, 5xx, reset, and backend saturation graphs after patching or policy changes.
  • Confirm public pages, login, APIs, checkout, uploads, and monitoring probes still work from outside the server network.

This update intentionally does not repeat attack strings, packet details, scanner-ready signatures, or vendor configuration snippets. Use the official vendor documentation for your exact platform and test changes in staging where possible.

Sources and related Fix I.T. Phill reading