HAProxy Backend Config Generator

Backend name:

Name the backend section that frontends will reference.

Proxy mode:

Choose the HAProxy backend mode.

Balance algorithm:

Pick the backend load-balancing behavior.

Health check method:

Set the HTTP method used for active checks.

Health check URI:

Use a path such as /health, /ready, or /status.

Health Host header:

Set the Host header sent with the health-check request.

Healthy response:

Choose how strict the HTTP health-check response should be.

Check interval:

Seconds between active health checks.

Fall count:

Consecutive failed checks required before removal.

Rise count:

Consecutive successful checks required before recovery.

Server rows:

Enter one backend server per line: name,address:port,weight,maxconn,role.

Quoted CSV cells are accepted.

Backend server TLS:

Leave plain when HAProxy talks cleartext to the backend servers.

CA file:

Use an absolute path on the HAProxy host.

SNI host:

Leave blank when backend certificates do not require SNI.

Server timeout:

Leave blank to inherit timeout server from defaults.

Add http-reuse safe

Reuse idle backend HTTP connections when it is appropriate for the application.

Add option redispatch

Allow retrying a different server when the selected server is unavailable.

Add cookie persistence

Cookie name:

{{ result.errors.length ? 'Fix before using this config' : 'Review before using this config' }}

{{ item }}
{{ item }}

{{ result.config }}

Server	Address	Weight	Maxconn	Role	Generated arguments	Copy
{{ row.name }}	{{ row.address }}	{{ row.weight }}	{{ row.maxconn }}	{{ row.role }}	`{{ row.arguments }}`
No valid server rows yet.

Severity	Check item	Value	Config effect	Copy
{{ row.severity }}	{{ row.item }}	{{ row.value }}	{{ row.effect }}

Export to PDF Fullscreen

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

An HAProxy backend is the configuration block that names a server pool and tells HAProxy how to send traffic to it. The backend holds the proxy mode, balancing rule, health-check behavior, server list, and per-server options that decide whether a target is eligible for requests. A frontend can route traffic to the backend, but the backend is where most pool behavior becomes concrete.

Small backend changes can have large operational effects. A different balance algorithm can shift traffic away from equal rotation. A missing Host header can make an HTTP health endpoint fail even though the application is healthy. A backend TLS setting can protect traffic between HAProxy and the servers, or it can leave certificate verification intentionally disabled for a short-lived exception.

Frontend route

use_backend

Backend

mode, balance, checks

Server lines

check, weight, maxconn

Review cues

ready, review, blocked

A backend draft joins routing intent, pool selection, active checks, and per-server arguments into one HAProxy configuration block.

A generated backend should be treated as a deployment draft, not as a live HAProxy validation. It can format the backend block, normalize unsafe labels, and point out known input problems. It cannot prove that the servers are reachable, the certificate chain is trusted on the HAProxy host, the health endpoint returns the intended status, or the frontend routes to this backend.

The practical review is therefore two-part. First, make the generated backend read correctly in the page. Then test the complete HAProxy configuration with the target host, defaults, frontend rules, DNS, certificates, and application health behavior.

Technical Details:

HAProxy backend selection begins with a named backend section. Inside that section, mode http enables HTTP-aware health-check and connection behavior, while mode tcp keeps the backend at a raw stream check shape. The balancing algorithm then decides which eligible server receives a new request or connection.

The active check is the main eligibility signal in this generated shape. HTTP mode emits option httpchk plus an http-check send line with method, URI, HTTP version, and optional Host header. TCP mode emits option tcp-check and tcp-check connect. Each server line includes check, so HAProxy can remove a failing server after the configured fall count and return it after the configured rise count.

Rule Core

backend name -> mode -> balance -> active health check -> default-server cadence

server row -> safe name + address:port + check + weight + maxconn + role

TLS and persistence choices -> added server arguments or backend directives

Generated HAProxy backend directives and review meaning
Generated area	Directive or argument	Review meaning
Backend identity	`backend NAME`	The label must match the frontend `use_backend` or `default_backend` reference.
Proxy mode	`mode http` or `mode tcp`	HTTP mode supports URI and Host health checks; TCP mode checks connection establishment.
Load distribution	`balance roundrobin`, `leastconn`, `source`, `random`, `static-rr`, or `first`	The choice changes how eligible servers are selected after health checks have kept them in rotation.
HTTP health check	`option httpchk`, `http-check send`, optional `http-check expect`	The check can accept the implicit 2xx or 3xx behavior, require `200`, require `200-399`, or reject 5xx responses.
TCP health check	`option tcp-check` and `tcp-check connect`	The backend checks whether HAProxy can establish a TCP connection to the target address and port.
Check cadence	`default-server inter Ns fall N rise N`	The interval controls check frequency, fall controls removal after failures, and rise controls return after successes.
Server pool	`server NAME ADDRESS check weight N maxconn N`	Each valid CSV row becomes one checked server line, with optional `backup`, TLS, SNI, and cookie arguments.
Persistence and retry	`cookie NAME insert indirect nocache`, `option redispatch`, `http-reuse safe`	These optional lines affect session stickiness, retry behavior, and backend HTTP connection reuse.

Input validation is deliberately narrow and configuration-focused. It makes labels safer for HAProxy syntax, keeps numeric limits in the supported ranges used by the page, and blocks the most obvious missing pieces before the config is copied. It does not parse a complete HAProxy file or check whether surrounding defaults contain compatible timeouts, logging, resolvers, or frontend rules.

HAProxy backend generator validation boundaries
Field or choice	Accepted or normalized behavior	What to check next
Backend and server names	Characters outside letters, digits, underscore, period, colon, and hyphen are replaced with underscores.	Confirm the final label still matches naming standards and frontend references.
Server address	Requires `host:port` or bracketed IPv6 such as `[2001:db8::10]:443`, with ports from `1` to `65535`.	Confirm HAProxy can resolve or reach the target from the load balancer host.
Weight and maxconn	Weight is clamped to `1` through `256`; maxconn is clamped to `1` through `1000000`.	Match these values to backend capacity and any existing HAProxy connection limits.
HTTP health URI and Host	The URI is prefixed with `/` when missing and spaces are encoded as `%20`; Host and SNI values with whitespace are omitted.	Test the same method, URI, and Host header against the application readiness endpoint.
Backend TLS	`verify required` needs a CA file path without whitespace; `verify none` remains a review warning.	Prefer certificate verification with a CA file whenever the backend certificate chain supports it.
Timeout and checks	Check interval is `1` to `300` seconds, fall and rise are `1` to `20`, and server timeout accepts digits or HAProxy suffixes such as `ms`, `s`, `m`, `h`, or `d`.	Keep the generated backend consistent with global and defaults timeouts in the full HAProxy file.

Backup servers are emitted with the backup argument when a CSV role is backup or standby. Other role text is treated as active and creates a review warning. That behavior keeps malformed role entries visible without silently dropping a server from the draft.

Everyday Use & Decision Guide:

Start with Backend name, Proxy mode, and Balance algorithm. Use HTTP mode for web or API pools that have a URI health endpoint and need an explicit Host header. Use TCP mode for raw services where a successful connection is the check that matters. Keep roundrobin for equal ordinary servers, use leastconn for longer-lived connections, and use source only when client affinity by source hash is intentional.

The server CSV should be one row per target using name,address:port,weight,maxconn,role. Put the production address and port in the second column, keep weights proportional to the intended share, and use backup only for targets that should wait behind active servers. Normalize rows is useful after the page has accepted the pool because it rewrites the textarea from the parsed server ledger.

For HTTP checks, set Health check method, Health check URI, Health Host header, and Healthy response to match the readiness endpoint the app actually serves.
For backend TLS, choose TLS, verify required with a CA file when HAProxy should validate the server certificate.
Use SNI host when backend certificates or virtual hosts require a specific TLS server name.
Set Server timeout only when this backend should override the surrounding defaults.
Add option redispatch when retrying another server is acceptable for the workload.
Add cookie persistence only in HTTP mode and only when the application expects session stickiness from HAProxy.

Stop when the alert says Fix before using this config. The generated text starts with comments explaining the blocker, but those comments are not a safe config review. Clear missing address ports, invalid port ranges, missing CA file paths, or empty server pools before copying the backend block.

Treat Review before using this config as a real pause. Warnings such as disabled backend TLS verification, no HTTP Host header, normalized labels, clamped weight or maxconn, omitted SNI, or unsupported role text can still produce a backend block, but they point at choices that need human approval before deployment.

Step-by-Step Guide:

Use the page to draft one backend pool, review the generated rows, then validate the complete HAProxy file on the target host.

Enter Backend name. The summary should show the normalized backend label; if a warning says the name was normalized, check that the final label still matches the frontend route you plan to use.
Choose Proxy mode. HTTP mode should show HTTP health-check controls and produce option httpchk; TCP mode should produce option tcp-check and tcp-check connect.
Set Balance algorithm. Confirm the generated Backend Config contains the intended balance directive before reviewing servers.
In HTTP mode, set Health check method, Health check URI, Health Host header, and Healthy response. The Check Plan should describe the active health check and any response expectation.
Set Check interval, Fall count, and Rise count. The Check Plan should show the cadence as seconds, fall count, and rise count.
Paste Server rows in CSV form. Open Server Ledger and confirm each parsed server name, address, weight, maxconn, role, and generated argument list.
Open Advanced only when needed. Review backend TLS, CA file, SNI host, server timeout, HTTP reuse, redispatch, and cookie persistence against the service requirements.
Clear every blocker in the alert area before copying Backend Config. Use Check Plan for warnings that need approval even when the summary says the backend is ready.
After copying the backend block, place it in the full HAProxy file and run a configuration syntax test on the target HAProxy host before reload.

Interpreting Results:

Backend Config is the draft configuration text. Server Ledger explains how each CSV row became a server line. Check Plan is the review view for blockers, warnings, health-check cadence, TLS mode, session persistence, and server count. The JSON view mirrors the same generated config, server rows, warnings, and errors in structured form.

The ready badge means the page did not find blockers and did not raise review warnings for the current inputs. It does not mean HAProxy has loaded the config, the backend servers are up, certificate verification will pass, or the application health endpoint returns the expected status from the HAProxy host.

HAProxy backend generator output cues and follow-up checks
Output cue	Meaning	Follow-up
Check input	At least one blocker exists, such as no valid server row or missing CA file for required TLS verification.	Fix the alert items before copying Backend Config.
Review	The backend block was generated, but one or more warnings deserve a decision.	Read the Check Plan review rows and approve or change the affected settings.
Ready	Inputs passed the page checks and the backend block can be copied as a draft.	Run the full HAProxy syntax test, then test health checks and routing from the load balancer environment.
Server Ledger	Shows the exact per-server arguments emitted from the CSV rows and advanced settings.	Compare each generated argument with the intended backend role, TLS policy, weight, and connection cap.

Do not overread a clean generated block as a complete production change. Frontend routing, defaults, timeout inheritance, stick-table policy, logging, resolvers, operating-system trust stores, and application behavior all sit outside this backend draft.

Worked Examples:

HTTP API pool with a backup server

A backend named be_app_api uses HTTP mode, roundrobin, GET to /health, Host api.internal.example, implicit healthy response handling, a 3s interval, fall 3, and rise 2. Three rows such as app01,10.44.30.11:8080,100,800,active, app02,10.44.30.12:8080,100,800,active, and app03,10.44.30.13:8080,100,800,backup should produce a Backend Config with option httpchk, http-check send meth GET uri /health ver HTTP/1.1 hdr Host api.internal.example, one default-server line, and three checked server lines. Server Ledger should show the backup argument only for app03.

TCP service with HTTP-only persistence requested

A raw TCP service uses TCP mode, leastconn, two active server rows, and someone turns on cookie persistence by mistake. Backend Config should use option tcp-check and tcp-check connect instead of HTTP health-check lines. Check Plan should include a review note that cookie persistence is HTTP-mode only and was omitted for TCP mode, so the copied config will not contain a backend cookie directive.

Backend TLS with certificate verification

A HTTPS upstream pool uses HTTP mode, server addresses ending in :443, Backend server TLS set to TLS, verify required, CA file set to /etc/ssl/certs/backend-ca.pem, and SNI host set to api.internal.example. Each server row should include ssl verify required ca-file /etc/ssl/certs/backend-ca.pem sni str(api.internal.example) in Server Ledger. If the CA file is blank, Fix before using this config should block the result until the path is entered or the TLS mode is changed.

Troubleshooting an invalid address row

A server row such as app04,2001:db8::44:8080,100,800,active is ambiguous because IPv6 targets need bracketed address syntax. The alert should point to that row and say IPv6 must use [addr]:port syntax. Change the row to app04,[2001:db8::44]:8080,100,800,active, then recheck Server Ledger before copying the backend block.

Security and Privacy Notes:

Generation happens in the browser after the page loads. The page has no separate remote service for building the HAProxy backend, so pasted server rows and generated config are handled locally by the page logic.

Treat the output as infrastructure-sensitive text. It may include internal hostnames, private IP addresses, CA paths, SNI names, service labels, and operational limits. Review the config in the same change-control path used for other load balancer configuration before pasting it into production.

FAQ:

Can I deploy the generated backend as-is?

Only after host-level checks pass. The generated backend can be a useful draft, but the full HAProxy file still needs a syntax test, matching frontend rules, reachable servers, correct certificates, and health-check proof from the load balancer host.

What server row format is accepted?

Use one CSV row per server: name,address:port,weight,maxconn,role. Quoted CSV cells are accepted, IPv6 needs bracketed [addr]:port syntax, and role should be active or backup.

Why does the HTTP Host header matter?

Many application health endpoints depend on virtual hosting. In HTTP mode, the generated http-check send line can include hdr Host; if it is blank, the page warns that no Host header will be sent with the health check.

Why is verify none marked for review?

verify none still enables TLS to the backend server, but it does not verify that the certificate is trusted. Use TLS, verify required with a CA file when the backend certificate chain supports verification.

Why did the config start with comments instead of a clean backend?

That happens when blockers exist. Common causes are no valid server rows, a missing address port, an out-of-range port, a blank CA file when TLS verification is required, or a CA path with whitespace.

Does this check my live HAProxy server?

No. It builds a backend draft from the fields in the page. Use HAProxy's syntax check, health-check logs, stats, and real traffic tests to confirm live behavior.

Glossary:

Backend: An HAProxy configuration section that defines a named pool of servers and the rules used to send traffic to that pool.
Balance algorithm: The HAProxy rule that chooses an eligible server for a new request or connection.
Active health check: A periodic HTTP or TCP check HAProxy sends to decide whether a server should stay in rotation.
Default-server: A directive that applies shared server options, such as check interval, fall count, and rise count, to server lines in the backend.
Backup server: A server marked with the backup argument so it is held behind active servers unless backup behavior is needed.
SNI: Server Name Indication, the TLS name sent to a backend server when certificate or virtual-host selection depends on it.
CA file: A certificate authority file HAProxy can use to verify a backend server certificate when TLS verification is required.
Cookie persistence: An HTTP-mode HAProxy feature that can keep a client associated with the same backend server by inserting a persistence cookie.

References:

HAProxy 3.2 Configuration Manual, HAProxy Documentation.
Health checks, HAProxy Documentation.
Basics of enabling TLS, HAProxy Documentation.