How is TCP mode different from HTTP mode here?

TCP mode load-balances at the connection level without inspecting HTTP semantics, using Nginx's stream{} module or HAProxy's tcp mode; it works for any protocol (databases, raw sockets) but can't route on paths or headers. HTTP mode understands the request line and headers, so Nginx's http{} upstream and HAProxy's http mode can do things like health-check a specific path.

Why does open-source Nginx only get passive health checks?

Nginx's active health_check directive, which proactively polls backends on a schedule, is an Nginx Plus (commercial) feature. Open-source Nginx only supports passive checks via max_fails/fail_timeout, which mark a backend down after it fails live requests, not before. The generated config uses passive checks and notes the Plus-only alternative.

Does the Kubernetes output actually perform health checks?

Not by itself. A Kubernetes Service just routes to Pods matching its selector; whether a Pod receives traffic depends on that Pod's readinessProbe, which lives on the Deployment/Pod spec, not the Service. The generated output includes a commented readinessProbe snippet using your health check path/interval as a reminder to add it there.

Which HAProxy balance algorithm should I pick?

roundrobin distributes requests evenly and is a reasonable default; leastconn sends new connections to whichever backend currently has the fewest active connections, better for long-lived or uneven-duration requests; source hashes the client IP to consistently route the same client to the same backend, useful for simple session affinity without cookies.

Load Balancer Config Generator - Nginx, HAProxy, Kubernetes

Overview

Introduction

Load balancer configuration syntax differs enough between Nginx, HAProxy, and Kubernetes that switching between them, or evaluating which one fits a given deployment, usually means re-deriving each one's shape from scratch.

This tool generates a working TCP or HTTP load balancer config for all three from the same backend list, port, and health check settings, so comparing them is a toggle instead of a rewrite.

What Is Load Balancer Config Generator?

A generator covering three load balancer targets: an Nginx stream{} block (TCP) or http upstream (HTTP), an HAProxy frontend/backend pair with a selectable balance algorithm, and a Kubernetes Service of type LoadBalancer.

Health checks are handled the way each platform actually supports them: passive max_fails/fail_timeout for open-source Nginx, active httpchk/tcp-check for HAProxy, and a readinessProbe reminder for Kubernetes.

How Load Balancer Config Generator Works

You list backend servers (host:port), pick TCP or HTTP mode, set a listen port (and a target port for Kubernetes), and set a health check path and interval. HAProxy mode also lets you pick a balance algorithm.

The generator validates all the backend addresses and ports, then emits the chosen provider's real config shape: Nginx's stream or http block, HAProxy's global/defaults/frontend/backend, or a Kubernetes Service manifest with a commented readinessProbe example.

When To Use Load Balancer Config Generator

Use it when distributing traffic across multiple backend instances of an app or database and you need a starting config for Nginx, HAProxy, or Kubernetes.

It's also useful for comparing how the same load-balancing intent (backends, port, health check) looks across these three tools before committing to one.

Often used alongside Nginx Reverse Proxy Generator, HAProxy Config Generator and Rate Limiting Config Generator.

Features

Advantages

Generates the correct config shape for each platform's real load-balancing mechanism, not a generic template stretched across all three.
Handles health checks per-platform's actual capability instead of pretending all three work the same way.
Covers both TCP and HTTP modes, since not every load-balanced service is HTTP.

Limitations

The Kubernetes output is a single Service manifest; it assumes a Deployment with matching Pod labels and a readinessProbe already exists or will be added separately.
HAProxy's stats page, ACL-based routing, and SSL termination aren't included here, see the dedicated HAProxy config generator for those.

Examples

HTTP mode on HAProxy with leastconn

Input

provider: haproxy, protocol: http, backends: [10.0.0.1:8080, 10.0.0.2:8080], listenPort: 80, balanceAlgorithm: leastconn, healthCheckPath: /healthz, healthCheckIntervalSeconds: 5

Output

frontend fe_main
    bind *:80
    mode http
    default_backend be_pool

backend be_pool
    mode http
    balance leastconn
    option httpchk GET /healthz
    server web1 10.0.0.1:8080 check inter 5s
    server web2 10.0.0.2:8080 check inter 5s

Each backend gets an auto-numbered server name (web1, web2, ...) and the same health-check interval applied via `check inter`.

Best Practices & Notes

Best Practices

Pick leastconn instead of roundrobin for backends handling long-lived or highly variable-duration requests (websockets, streaming, slow queries).
Always add a real readinessProbe to the Kubernetes Deployment when using a LoadBalancer Service, an empty probe means Kubernetes routes traffic to Pods before they're actually ready.
Keep the health check path lightweight (no database calls) so it reflects process liveness quickly without adding load under a traffic spike.

Developer Notes

Nginx's stream module load-balances at Layer 4 (TCP) with no visibility into HTTP semantics, hence the separate http-mode branch using a regular upstream block for path/header-aware behavior. HAProxy's `option httpchk` combined with `check inter Ns` on each server line implements active health checking natively in open-source HAProxy, unlike Nginx OSS. The Kubernetes output deliberately keeps the Service and Pod-level health check concerns separate, since a Service's `type: LoadBalancer` only provisions an external IP/load balancer via the cloud provider's controller, it has no health-check configuration of its own.

Load Balancer Config Generator Use Cases

Load-balancing a TCP service like a database or message broker across replicas
Setting up HTTP load balancing with active health checks in HAProxy
Exposing a Kubernetes Deployment externally via a LoadBalancer Service with correct probe guidance

Common Mistakes

Assuming a Kubernetes LoadBalancer Service health-checks Pods on its own, without adding a readinessProbe to the Deployment.
Expecting Nginx open-source to actively poll backend health like HAProxy does, when it only reacts passively to failed live requests.

Tips

If you're not sure which platform to standardize on, generate all three for the same backend list, comparing the health-check story side by side often makes the right choice for your ops team obvious.

Load Balancer Config Generator