HAProxy Backend Config Generator

Introduction:

An HAProxy backend is the named pool of upstream servers that receives traffic after a frontend or listener has matched a request. The backend section decides which targets are eligible, how traffic is distributed, how failed servers are removed, and which per-server arguments HAProxy should apply when it opens a connection.

Backend design turns availability policy into concrete configuration. A round-robin pool spreads requests evenly, a least-connection pool favors less busy targets, source hashing can keep a client near the same server, and backup servers stay out of rotation until the active pool cannot serve traffic. The best choice depends on the service's state model, connection length, readiness endpoint, and tolerance for retry or failover behavior.

Health checks deserve the same care as traffic routing. A TCP check proves that a connection can open, while an HTTP check can prove that a specific readiness endpoint returns an acceptable response. The method, URI, HTTP version, Host header, interval, fall count, and rise count all affect how quickly HAProxy removes a server and how confidently it brings that server back.

Most backend mistakes are not syntax mistakes. Common problems include a readiness endpoint that only checks a port, a missing Host header on a virtual-hosted application, cookie persistence applied to a service that should stay stateless, or server TLS set to skip certificate verification because the CA path was not ready.

A backend block is only one part of a working HAProxy file. DNS resolution, certificate files, CA trust, frontend references, inherited defaults, bind settings, logs, and deployment paths still need to be checked on the HAProxy host before the configuration is loaded.

How to Use This Tool:

Start with the routing and health-check basics, then add advanced options only when the backend actually needs them.

1. Set Backend name to the label your frontend will use in a default_backend or use_backend rule. Unsafe label characters are normalized in the generated section name.
2. Choose Proxy mode. HTTP mode creates HTTP health-check lines; TCP mode creates a TCP connection check.
3. Select the Balance algorithm. Use roundrobin for ordinary even rotation, leastconn for connection-heavy services, source for client-address affinity, or another listed algorithm when it matches your HAProxy design.
4. For HTTP mode, enter the check method, URI, optional Host header, and expected response class. Fix any warning about a blank Host header if the application routes by hostname.
5. Set Check interval, Fall count, and Rise count to control check frequency, removal after failures, and recovery after successes.
6. Enter Server rows as name,address:port,weight,maxconn,role. Role may be active or backup. Quoted CSV cells are accepted, and the normalize action rewrites valid rows into the expected shape.
7. Open advanced settings for backend TLS, CA file, SNI host, server timeout, HTTP connection reuse, redispatch, and HTTP cookie persistence. Verification-required TLS needs a CA file path before the config is usable.
8. Review the generated config, Server Ledger, Check Plan, and JSON output. Copy or download the config only after blockers are gone and review warnings make sense for your deployment.

Interpreting Results:

The summary state tells you how the draft should be treated. Ready means no blockers or review warnings were found. Review means output is available, but settings such as disabled TLS verification, missing Host header, duplicate server names, or omitted persistence need a human check. Blocked means the generated text starts with fix notes and should not be copied into a live configuration.

The Server Ledger is the easiest place to catch row-level surprises. It shows the final server name, address, weight, maximum connections, role, and generated arguments for each valid row. Name normalization, duplicate suffixes, clamped numeric values, backup status, TLS arguments, and cookie values are visible there before you copy the backend block.

The Check Plan is a deployment review list, not a formal HAProxy syntax check. Confirm that the backend name matches the frontend reference, the health-check endpoint is the one the application team expects, the CA and timeout paths are valid on the HAProxy host, and the final complete file passes HAProxy's own configuration check.

Exports are meant for handoff and audit. The config tab provides the backend block, the table tabs provide CSV or DOCX-friendly review ledgers, and the JSON output captures the normalized settings, warnings, errors, server list, and check plan.

Technical Details:

The generated backend follows HAProxy's normal structure: a backend line, a proxy mode, a balance directive, optional backend-level directives, health-check directives, a default-server check cadence, and one server line per valid target. Each server line includes check, weight, and maxconn, with optional backup, TLS, SNI, and cookie arguments.

HTTP mode generates option httpchk and an http-check send request using the selected method, URI, HTTP/1.1, and optional Host header. The expected response can be left implicit, constrained to status 200-399, constrained to 200, or expressed as anything except a 5xx response. TCP mode instead generates option tcp-check and tcp-check connect.

Directive Map:

Input Transformation:

Server TLS and health checks deserve extra review. A server-line SNI value is useful for backend TLS connections, but HAProxy also has health-check-specific SNI behavior. If an HTTPS health check must present a specific SNI value, review the final block against your HAProxy version and add check-specific options where needed.

There is no numeric formula behind the output. The useful checks are rule transformation, HAProxy directive compatibility, safe label and value normalization, and final deployment validation with the complete configuration file.

Worked Examples:

HTTP API pool. A backend named be_app_api, HTTP mode, roundrobin balance, GET health check at /health, Host header api.internal.example, and three server rows produces a backend block with HTTP check directives, default-server cadence, and one checked server line per valid target.

Verified backend TLS. Choosing TLS with verification required adds certificate verification arguments to each server line and requires a CA file path. If the CA file is blank or contains whitespace, the Check Plan marks a blocker so the draft should not be copied.

TCP service with persistence requested. TCP mode can generate a checked server pool, but cookie persistence is HTTP-only. The Check Plan reports that the cookie directive was omitted, so use a TCP-appropriate stickiness design if the service needs affinity.

Imported server list. A pasted CSV list with a duplicate name, out-of-range weight, or malformed address still produces useful review feedback. Valid rows are normalized into the ledger, while address and port errors are shown as blockers.

FAQ:

References:

• Backends, HAProxy Technologies.
• Health checks, HAProxy Technologies.
• HAProxy Configuration Manual, HAProxy project.
• How to configure backend health checks in HAProxy, Simplified Guide.
• How to validate an HAProxy configuration file, Simplified Guide.