A load balancer does more than round-robin. Active health checks, timeouts, retries, TLS termination and backend-state management protect users from unhealthy nodes. HAProxy can operate at HTTP and TCP levels depending on protocol needs.
When HAProxy active health checks fail for the configured threshold, the backend server is removed from load-balancing rotation. Checks continue and the server can return after enough successful responses. Checks can operate at TCP or HTTP level.
The frontend accepts client connections, ACL/routing rules select a backend pool and health checks keep only healthy servers in rotation.
HTTP mode can inspect L7 data such as headers and paths; TCP mode proxies connections without interpreting application messages.
For HTTP apps, a `/health` endpoint can reflect controlled dependency/database state. Overly expensive deep checks can add load.
Validate configuration syntax before reload.
haproxy -c -f /etc/haproxy/haproxy.cfgsystemctl status haproxy --no-pagerss -lntp | grep haproxyjournalctl -u haproxy --since '-15 min' --no-pagerCritical systems can use two load balancers with VIP/VRRP or an upstream DNS/anycast design.
For some reverse-proxy/load-balancing roles yes, but web serving and ecosystem needs should guide the choice.
They can use TCP connection checks or HTTP requests, among other modes.
It can be for small non-critical systems; critical production should make the load-balancer layer highly available too.
Share protocol, backend count, peak RPS, TLS and health endpoints; we can choose L4/L7 and single/dual LB topology.