HAProxy Backend Config Generator

Traffic topology visual unavailable.

Backend name:

Use the exact backend label referenced by the frontend.

Proxy mode:

Choose the protocol behavior the backend should enforce.

Balance algorithm:

The selected algorithm changes the emitted balance directive and review notes.

Server rows:

CSV order: name, address:port, weight (1–256), maxconn, active or backup.

Quoted CSV cells are accepted.

Fix backend inputs

{{ issue.message }}

Check interval:

Seconds between active checks, from 1 to 300.

Fall count:

Whole failures from 1 to 20.

Rise count:

Whole successes from 1 to 20.

Backend server TLS:

Prefer certificate verification for TLS backends.

CA file:

Example: /etc/ssl/certs/ca-certificates.crt.

SNI host:

Leave blank when certificate selection does not require SNI.

Server timeout:

Blank inherits timeout server from defaults.

HTTP connection reuse:

Ignored in TCP mode.

{{ params.enable_http_reuse ? 'Emit http-reuse safe' : 'Disabled' }}

Redispatch:

Use when retrying a different server matches the application policy.

{{ params.enable_redispatch ? 'Emit option redispatch' : 'Disabled' }}

Cookie persistence:

Ignored in TCP mode.

{{ params.enable_cookie ? 'Emit persistence cookie' : 'Disabled' }}

Cookie name:

Letters, digits, underscores, and hyphens are preserved.

{{ values.config_text }}

The capacity chart renderer is unavailable. The same values remain in the server ledger.

State	Check	Current value	Operational note	Copy
{{ row.state }}	{{ row.item }}	{{ row.value }}	{{ row.note }}

A load balancer can only make a sound routing decision when its backend pool describes three things accurately: which servers are eligible, how a request should be assigned, and what evidence makes a server healthy. A syntactically valid backend that gets any of those wrong can concentrate traffic on the wrong host, send clients to an unready instance, or remove every server from rotation.

HAProxy backends operate in HTTP or TCP mode. HTTP mode understands requests and responses, so health checks can send a method, URI, HTTP version, and Host header before judging a status code. TCP mode treats successful connection establishment as the health signal. A TCP check can prove that a port accepts connections, but it cannot prove that an application endpoint is ready to serve correct responses.

Balance algorithm: The rule that selects an eligible server, such as weighted round-robin, least connections, source hashing, random selection, static round-robin, or the first server with capacity.
Health cadence: The interval between checks plus the consecutive failure and success counts required to mark a server down or bring it back.
Backend TLS: Encryption from HAProxy to the application server, with certificate verification, CA trust, and Server Name Indication chosen independently from client-facing TLS.
Persistence: A rule that tries to return related HTTP requests to the same server, commonly through a cookie. Persistence changes distribution and should match the application's session design.

Health timing creates a deliberate tradeoff. Short intervals and low failure counts remove a bad server quickly but can react to brief network loss or a slow readiness endpoint. Longer intervals and higher counts resist noise but continue sending traffic to a failing instance for longer. Recovery counts matter too; an instance should not rejoin while it is still warming caches, opening database pools, or replaying state.

TLS verification is another trust boundary, not a cosmetic switch. Encrypting the connection while accepting any certificate protects against casual observation but does not authenticate the backend. Verification requires a CA file that the HAProxy process can read and a certificate identity that matches the connection policy. Server Name Indication may also be required when several certificates share one backend address.

Capacity numbers need careful interpretation. Per-server maxconn values cap concurrent connections at each server line, and weights influence eligible-server selection. Adding those values produces a useful configuration summary, not a throughput forecast. Backup servers, health state, queueing, response time, global limits, and application bottlenecks all change real capacity.

The safest deployment path treats a backend block as one part of a complete HAProxy configuration. Validate the same file set and HAProxy release used by the service, confirm referenced certificates and CA files are readable, observe live backend state, and test traffic through the frontend before considering the change complete.

How to Use This Tool:

Describe one backend pool as it should run on the target HAProxy host, including the application protocol, readiness contract, server limits, and transport trust.

Enter the Backend name referenced by the frontend, then choose Proxy mode and Balance algorithm. Use HTTP mode only when HAProxy should apply HTTP-aware checks and options.
Add Server rows as name, address and port, weight, maxconn, and active or backup role. Put IPv6 addresses in brackets, such as [2001:db8::10]:8080.
For HTTP mode, set the health-check method, URI, optional Host header, and accepted response policy. For TCP mode, confirm that successful connection establishment is sufficient evidence of readiness.
Choose the check interval and the consecutive Fall count and Rise count. Keep the interval between 1 and 300 seconds and each count between 1 and 20.
Set Backend server TLS. Verification-required mode needs a readable CA file; add an SNI host when the backend certificate selection depends on it. Treat verification-disabled output as a warning, not a default.
Enable cookie persistence, HTTP reuse, redispatch, or a server timeout only when the surrounding proxy and application behavior support them. Cookie persistence and HTTP reuse are omitted outside HTTP mode.
Resolve every blocking input message, then review Backend config and the warning rows. Validate the complete target configuration with haproxy -c -V -f <config> before any reload.

Interpreting Results:

Ready means the inputs produced a backend block without a local normalization warning. Review needed means the block is still available, but an assumption such as disabled certificate verification, a missing health Host header, or a normalized value needs attention. Neither status proves that the target HAProxy process will accept the full configuration or reach the servers.

Compare active and backup counts with the intended failure plan. A backup is eligible according to HAProxy's backup-server behavior, not part of normal active rotation.
Treat total weight as a distribution input and total maxconn as a configured connection ceiling. They do not measure requests per second or available application capacity.
Review every normalized server name, path, timeout, role, weight, and connection cap. A corrected string may parse while still naming the wrong operational object.
After validation and reload, inspect runtime or statistics state and exercise the frontend. A parse-only check does not contact a backend or prove that health transitions behave as intended.

Technical Details:

A backend section first establishes the processing mode and server-selection algorithm. Shared health timing then applies to server lines that explicitly enable checks. HTTP health checks build a request and optionally test the returned status; TCP checks stop at successful connection establishment.

Each server line combines an address with eligibility and capacity arguments. Weight affects selection among eligible servers, maxconn limits concurrent connections to that server, backup changes its normal role, and check opts the server into active checks. Backend-side TLS arguments are attached per server because they govern the connection from HAProxy to that target.

Rule Core:

HAProxy backend generation rules and boundaries
Decision	Generated behavior	Boundary to verify
HTTP mode	Emits HTTP mode, an HTTP health-check request, optional response expectation, and optional safe connection reuse.	The readiness URI, Host header, and accepted status must match the application contract.
TCP mode	Emits a TCP connection check and omits HTTP-only cookie and reuse settings.	A successful connection does not prove application-level readiness.
Health transitions	`inter` accepts 1 to 300 seconds; `fall` and `rise` accept whole counts from 1 to 20.	Down and recovery delay depend on consecutive outcomes, check duration, scheduling, and the chosen values.
Server rows	Requires address and port; bounds weight to 1–256 and `maxconn` to 1–1,000,000; accepts active or backup roles.	Clamped or normalized values require review because the generated value may differ from the source row.
TLS verification	Adds `ssl verify required ca-file` for verified TLS or `ssl verify none` for unverified TLS.	Verified mode requires a nonblank CA path without whitespace; certificate identity and file readability remain host checks.
Persistence	HTTP mode can emit an inserted, indirect, non-cacheable persistence cookie and a cookie value on each server line.	Cookie persistence is omitted in TCP mode and should agree with application session behavior.

Transformation Core:

Server rows pass through a deterministic normalization path before the backend text is assembled. This catches bounded syntax problems while keeping operational decisions visible for review.

Parse each non-empty CSV row, normalize the server label, and give repeated labels numeric suffixes.
Require an address and port, enforce port 1–65535, and require bracket notation for IPv6 literals.
Round and bound weight and maxconn, then map primary to active and standby to backup.
Build the mode-specific health directives, shared check cadence, optional timeout, redispatch, persistence, and reuse directives.
Append one checked server line per valid row with weight, maxconn, role, and any selected TLS or cookie arguments.

HTTP response policies are explicit when selected. The generated expectation can require exactly 200, allow 200–399, or reject responses matching the 5xx range. With the implicit policy, no custom expectation line is emitted, so the HAProxy release's default HTTP-check success behavior applies.

A plain numeric server timeout is interpreted as seconds. Values ending in ms, s, m, h, or d are retained; other timeout strings are omitted with a warning. Health URIs gain a leading slash when missing, and whitespace is encoded as %20.

Limitations and Deployment Safety:

A generated backend block is a bounded configuration draft. It does not inspect the active frontend, inherited defaults, HAProxy build options, certificate files, runtime socket, server reachability, application responses, or deployment manager.

Validate the complete loaded configuration with the target HAProxy binary. A standalone backend snippet may fail when combined with other sections or referenced files.
Keep a rollback path and use a controlled reload. Do not intentionally fail a production backend merely to test health transitions without an approved maintenance plan.
Verify TLS trust, runtime health state, session behavior, and real traffic after reload. A clean parser result is necessary but not sufficient.

Worked Examples:

HTTP pool with one standby server

Three rows define two active application servers and one backup, each with weight 100 and maxconn 800. HTTP mode sends GET /health with the configured Host header every 3 seconds, marks a server down after 3 consecutive failures, and restores it after 2 consecutive successes. The output reports 2 active servers, 1 backup, total weight 300, and total maxconn 2,400; those totals summarize the declarations and should not be read as 2,400 active sessions guaranteed under failure.

References:

HAProxy 3.4 Configuration Manual, HAProxy Technologies.
How to configure backend health checks in HAProxy, Simplified Guide.
How to validate an HAProxy configuration file, Simplified Guide.