Balanceador de Carga con HAProxy: Guía de Alta Disponibilidad

📅 Publicado el 8 de octubre, 2026 · Por Equipo RedServicio

Si necesitas repartir el tráfico de tu web entre varios servidores, tarde o temprano acabarás hablando de HAProxy. Es un software libre y de código abierto que actúa como intermediario entre tus usuarios y los servidores backend: recibe las peticiones HTTP, HTTPS o TCP y las distribuye para que ningún servidor acabe saturado. ¿Te suena haber visto la web lenta en horas punta? ¿O ese miedo a que una caída de servidor te deje fuera de línea? Pues ahí es donde entra esto. En RedServicio.net lo usamos a diario en nuestras propias infraestructuras, así que lo que sigue viene de la práctica, no del manual.

¿Qué es un balanceador de carga HAProxy y por qué necesitas uno?

Piensa en una tienda con una sola caja. Da igual que entren cincuenta clientes: todos hacen fila en el mismo punto. Un balanceador de carga abre más cajas y reparte a la gente entre ellas automáticamente. HAProxy hace exactamente eso con el tráfico de tu sitio.

¿Qué ganas con ello? Básicamente esto:

• Alta disponibilidad: si un servidor falla, HAProxy lo detecta mediante health checks y manda el tráfico a los demás. El usuario ni se entera.
• Escalabilidad horizontal: puedes añadir servidores backend según crezca el tráfico, sin tocar la aplicación.
• Rendimiento: está escrito en C y optimizado a nivel de kernel; hablamos de decenas de miles de conexiones simultáneas con una latencia mínima.

Hay un detalle que muchos olvidan: HAProxy también funciona como proxy inverso con terminación SSL. Es decir, puede encargarse del cifrado TLS de forma centralizada y quitarles esa carga a tus servidores. Nginx también sabe hacer de balanceador, y bien, pero cuando la prioridad es la alta disponibilidad pura y el enrutado avanzado con ACLs, HAProxy sigue siendo el estándar. No lo digo yo solo; lo dice el mercado.

Requisitos previos y arquitectura recomendada

Antes de instalar nada, preparemos el terreno. Para un escenario de producción, esto es lo mínimo:

• 1 servidor para HAProxy (el balanceador), con acceso a internet y puertos 80 y 443 abiertos.
• 2 o más servidores backend con tu aplicación web idéntica en cada uno (por ejemplo, dos instancias con Nginx + PHP).
• Acceso SSH a todos los servidores y privilegios de root o sudo.
• Un dominio o subdominio (por ejemplo, app.tudominio.com) apuntando mediante registro DNS A a la IP pública del balanceador.

¿Y el hardware? Cuando montamos estos entornos recomendamos, como mínimo, 2 GB de RAM y 1 vCPU para el servidor HAProxy. Para la mayoría de sitios de tamaño medio, sobra. Eso sí, hay algo que la gente pasa por alto: los backends deben servir exactamente el mismo contenido y compartir base de datos o almacenamiento (NFS, base de datos replicada…). El balanceador no sincroniza datos por sí mismo. Repito: no lo hace.

¿Quieres que el propio balanceador no sea un punto único de fallo? El siguiente nivel son dos instancias HAProxy con Keepalived y una IP flotante. Pero vayamos por partes: en esta primera nos quedamos con un solo nodo, que ya elimina el punto único de fallo de tus backends.

Instalación de HAProxy paso a paso

La instalación es sencilla en cualquier distribución Linux moderna. Aquí usaremos Ubuntu 22.04 o Debian 12.

Paso 1: actualizar el sistema

Conéctate por SSH a tu servidor balanceador y ejecuta:

1. sudo apt update && sudo apt upgrade -y (Debian/Ubuntu)
2. sudo dnf update -y (Rocky Linux / AlmaLinux)

Paso 2: instalar el paquete

En sistemas Debian/Ubuntu:

1. sudo apt install haproxy -y

Comprueba la versión con haproxy -v. Si tu repositorio te ofrece la 2.4 o superior, va bien; para funciones modernas como HTTP/2 en el frontend conviene la 2.6 en adelante.

Paso 3: habilitar el arranque automático

Asegúrate de que el servicio arranque con el sistema:

1. sudo systemctl enable haproxy
2. sudo systemctl start haproxy
3. sudo systemctl status haproxy

Con el servicio activo, HAProxy está listo para configurarse. En la segunda parte de la guía editaremos el archivo /etc/haproxy/haproxy.cfg: definiremos el frontend, los backends, los algoritmos de balanceo y los health checks, y lo verificaremos todo con estadísticas en tiempo real.

Configuración del frontend, backend y health checks

Edita el archivo /etc/haproxy/haproxy.cfg con el editor que uses de siempre. Un ejemplo que funciona para balancear dos servidores web:

frontend http_front
    bind *:80
    default_backend web_servers

backend web_servers
    balance roundrobin
    option httpchk GET /health
    server web1 192.168.1.10:80 check inter 2000 fall 3 rise 2
    server web2 192.168.1.11:80 check inter 2000 fall 3 rise 2

Vamos por partes. La directiva bind fija el puerto de escucha. balance roundrobin reparte las peticiones de forma circular entre los servidores. Si necesitas sesiones persistentes, tienes dos caminos: balance source o la directiva cookie para sticky sessions.

Y los health checks. No los pases por alto, porque aquí se juega buena parte de la fiabilidad del conjunto. inter 2000 comprueba cada 2 segundos; fall 3 marca el servidor como caído tras 3 fallos consecutivos, y rise 2 lo reincorpora cuando lleva 2 comprobaciones exitosas seguidas. ¿Por qué estos valores y no otros? Depende de tu carga. Pero como punto de partida, funcionan bien.

El panel de estadísticas merece la pena. Añade este bloque al final del archivo:

listen stats
    bind *:8404
    stats enable
    stats uri /stats
    stats auth admin:TuClaveSegura

Reinicia con sudo systemctl restart haproxy y entra en http://tu-ip:8404/stats. Verás ahí el estado de los backends en tiempo real. Útil. Más de lo que parece hasta que un servidor empieza a dar guerra.

Alta disponibilidad del propio balanceador con Keepalived

Pensemos en lo evidente: si HAProxy se cae, toda la infraestructura queda inaccesible. Un solo balanceador es un punto único de fallo, por bien configurado que esté. La solución habitual es montar dos balanceadores en activo/pasivo con Keepalived y una IP virtual flotante. Instálalo en ambos nodos:

sudo apt install keepalived -y

En el nodo maestro, edita /etc/keepalived/keepalived.conf:

vrrp_script chk_haproxy {
    script "killall -0 haproxy"
    interval 2
}

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 100
    advert_int 1
    virtual_ipaddress {
        192.168.1.100
    }
    track_script {
        chk_haproxy
    }
}

En el secundario cambia state a BACKUP y baja la priority a 90. La IP virtual (192.168.1.100) es la que deben apuntar tus registros DNS. Si el maestro falla, el backup la asume en segundos. Los usuarios, si acaso, notarán un parpadeo. Nada más.

Buenas prácticas y conclusión: lleva tu infraestructura al siguiente nivel

Para que tu balanceador de carga HAProxy rinda al máximo, apunta estas recomendaciones:

• Seguridad: restringe el puerto de estadísticas a IPs internas y habilita ssl en los bind con certificados Let’s Encrypt.
• Monitoreo: integra HAProxy con Prometheus o Grafana. Detectar una degradación antes de que la noten los usuarios ahorra muchos dolores de cabeza.
• Logs: configura log /dev/log local0 y revisa los códigos 5xx de vez en cuando. Suelen contar una historia.
• Documentación: versiona tu haproxy.cfg en Git. Poder revertir un cambio en segundos vale oro a las tres de la mañana.

Con HAProxy y Keepalived tienes redundancia de principio a fin: ni los servidores web ni el propio balanceador son un punto único de fallo. Ahora bien, por mucho que cuides la configuración, la calidad del hosting subyacente se nota. En RedServicio encontrarás planes de hosting robustos con soporte 24/7 que encajan bien con este tipo de despliegues, y te pueden acompañar durante toda la implementación.