Cómo publicar WordPress en el dominio root y Moodle en el path /escuela usando HAProxy sobre el mismo dominio

Feb 20, 2026 · Daniel Cepeda

haproxy wordpress moodle reverse proxy devops infraestructura

Cómo publicar WordPress en el dominio root y Moodle en el path /escuela usando HAProxy sobre el mismo dominio

Escenario

Una institucion educativa necesita:

  • www.mi-escuela.com - Sitio institucional en WordPress
  • www.mi-escuela.com/escuela - Plataforma educativa Moodle
  • Un solo dominio, un solo certificado SSL, sin subdominios

El objetivo es enmascarar ambas aplicaciones detras de un proxy reverso usando HAProxy.


Arquitectura

HAProxy actua como punto de entrada unico, distribuyendo el trafico hacia WordPress o Moodle segun el path de la URL:

  • WordPress: 10.0.0.10:80
  • Moodle: 10.0.0.20:80
  • Dominio: www.mi-escuela.com
Diagrama Reverse Proxy HAProxy
Diagrama de un Reverse Proxy: HAProxy actua como intermediario entre Internet y los servidores backend. (Fuente: Wikimedia Commons, CC BY-SA)

El problema tecnico con Moodle

Moodle esta disenado para vivir en un dominio propio o con un $CFG->wwwroot especifico. Si no reescribimos correctamente el path, ocurren estos problemas:

  • CSS y JS no cargan
  • Redirecciones se rompen o entran en bucle
  • Login falla de forma intermitente
  • Cookies quedan mal configuradas

La solucion requiere: ACL por path, reescritura del path, headers correctos y configuracion adecuada en Moodle.


Configuracion en HAProxy

1. ACL para detectar el path

acl host_miescuela hdr(host) -i www.mi-escuela.com
acl is_moodle_path path_beg -i /escuela

2. Redireccion al backend correspondiente

use_backend backend_moodle if host_miescuela is_moodle_path
use_backend backend_wordpress if host_miescuela

Backend WordPress (root /)

backend backend_wordpress
    mode http
    option forwardfor
    http-request set-header X-Forwarded-Proto https
    http-request set-header X-Forwarded-Host www.mi-escuela.com
    server wp1 10.0.0.10:80 check

Backend Moodle (/escuela)

Lo clave es eliminar el prefijo /escuela antes de enviarlo al backend usando set-path con regsub:

backend backend_moodle
    mode http
    option forwardfor
    http-request set-path con regsub para remover /escuela
    http-request set-header X-Forwarded-Proto https
    http-request set-header X-Forwarded-Host www.mi-escuela.com
    server moodle1 10.0.0.20:80 check

Cuando el usuario entra a www.mi-escuela.com/escuela/login/index.php, HAProxy reescribe el path a /login/index.php antes de enviarlo a Moodle.


Configuracion necesaria en Moodle

En el archivo config.php de Moodle:

$CFG->wwwroot = 'https://www.mi-escuela.com/escuela';
$CFG->reverseproxy = true;
$CFG->sslproxy = true;

Esto asegura que Moodle genere URLs absolutas correctas y maneje bien las cookies y redirecciones.


Configuracion SSL en el frontend HAProxy

frontend https_front
    bind *:443 ssl crt /etc/ssl/mi-escuela.pem
    mode http
    acl host_miescuela hdr(host) -i www.mi-escuela.com
    acl is_moodle_path path_beg -i /escuela
    use_backend backend_moodle if host_miescuela is_moodle_path
    use_backend backend_wordpress if host_miescuela
Infraestructura de servidores en datacenter
Una arquitectura de servidor bien planificada permite consolidar multiples servicios bajo un solo dominio. (Foto: Unsplash)

Buenas practicas

  • Siempre definir explicitamente el host en las ACL
  • No mezclar multiples dominios sin ACL
  • Usar check en los servidores backend
  • Configurar timeouts adecuados
  • Activar logs para debugging

Problemas comunes y soluciones

  • CSS roto: Revisar que $CFG->wwwroot incluya el path /escuela
  • Redireccion infinita: Verificar X-Forwarded-Proto y $CFG->sslproxy
  • Moodle redirige al root: Validar que la reescritura del path funciona correctamente

Ventajas de esta arquitectura

  • Un solo certificado SSL gestionado en HAProxy
  • Mejor branding: todo bajo www.mi-escuela.com
  • Infraestructura limpia y escalable
  • Separacion logica de aplicaciones en servidores distintos
  • Facil de extender con nuevos paths: /intranet, /soporte, /api

Conclusion

Enmascarar aplicaciones por path es una solucion profesional cuando se requiere un solo dominio, se quiere evitar subdominios y simplificar la experiencia del usuario. Sin embargo, no todas las aplicaciones soportan este modelo correctamente. Antes de produccion, validar compatibilidad con reverse proxy y subpath deployment.