Si administras servidores, sabes que no hay nada como despertarse y ver que los sitios que alojas están caídos. Hace poco me enfrenté a un error particularmente frustrante en un servidor con cPanel y CloudLinux: todas las webs respondían con un críptico ERROR 421 MISDIRECTED REQUEST.
El mensaje completo era aún más específico:
“The client needs a new connection for this request as the requested host name does not match the Server Name Indication (SNI) in use for this connection.”
Este error básicamente significa que el navegador pide ver https://dominio-A.com, pero Apache le está presentando un certificado SSL que pertenece a dominio-B.com o al propio hostname del servidor. Es un fallo en la Indicación del Nombre del Servidor (SNI), crucial para alojar múltiples sitios SSL en una sola IP.
Después de investigar un poco, encontré la causa: un bug en una actualización de software reciente. En este post, te guiaré a través de los pasos que seguí para diagnosticar y solucionar el problema.
El Culpable: Un Bug en una Actualización de Apache
La investigación me llevó a varios foros y, finalmente, a un artículo de soporte de cPanel (Websites experiencing 421 Misdirected requests after upgrading to CloudLinux’s ea-apache24-2.4.64). Resulta que el problema fue introducido en una versión muy específica del paquete de Apache de EasyApache 4:
Paquete problemático: ea-apache24-2.4.64
Este paquete, al ser instalado en servidores con CloudLinux, contiene un bug que rompe la lógica de SNI para los VirtualHosts. Esto confirma que el problema no era una mala configuración de mi parte, sino un fallo en el propio software distribuido.
La Solución: Guía Paso a Paso
Aquí está el procedimiento exacto que seguí para restaurar el servicio. Te recomiendo seguirlo en este orden.
Paso 1: Confirmar el Diagnóstico
Antes de cambiar nada, siempre es bueno confirmar que tienes el problema exacto. Conéctate a tu servidor por SSH como root y verifica la versión de Apache instalada con el siguiente comando:
rpm -q ea-apache24
Si la salida muestra la versión ...2.4.64..., has encontrado al culpable.
Paso 2: La Estrategia (Update vs. Downgrade)
Aquí hay dos caminos, y es importante entender cuándo usar cada uno:
- Actualizar (Update): Es la solución definitiva y recomendada. Los desarrolladores lanzan una nueva versión (ej. 2.4.65 o superior) que corrige el bug. Si esta versión ya está disponible en los repositorios, este es el camino a seguir.
- Revertir (Downgrade): Es la solución de emergencia. Si una versión corregida aún no está disponible, puedes volver a la última versión que funcionaba correctamente. Esta fue la solución que apliqué para restaurar el servicio de inmediato.
Paso 3: Ejecutando la Solución
Basado en la estrategia anterior, aquí están los comandos.
Opción A (Recomendada): Intentar la Actualización
Primero, intenta actualizar el paquete. Es la solución más limpia. Ejecuta este comando:
yum update ea-apache24
Si yum encuentra una versión más nueva, ¡perfecto! Instálala y salta al paso 4. Si dice “No packages marked for update”, pasa a la Opción B.
Opción B (Plan de Respaldo): Hacer un Downgrade
Si no hay una actualización disponible, el downgrade es tu mejor opción para poner los sitios en línea de inmediato. Ejecuta este comando:
yum downgrade ea-apache24
El gestor de paquetes yum te pedirá confirmación para instalar la versión anterior. Acepta y deja que termine el proceso.
Paso 4: Reiniciar y Verificar
Independientemente de si actualizaste o revertiste, el último paso es reiniciar Apache para que los cambios surtan efecto. Ejecuta este comando:
/scripts/restartsrv_httpd
Una vez reiniciado, prueba los sitios web en tu navegador (usa una ventana de incógnito para evitar la caché). También puedes usar curl desde la terminal para una verificación rápida:
curl -Ivs https://uno-de-tus-dominios.com 2>&1 | grep "HTTP/"
Deberías ver una respuesta HTTP/2 200 OK o similar, confirmando que el error 421 ha desaparecido.
Conclusión
Este tipo de problemas nos recuerda lo crítico que es el software que corre en nuestros servidores. Un simple yum update puede ser la causa de una caída masiva. Afortunadamente, en este caso, la comunidad y el soporte de cPanel identificaron el problema rápidamente.
Al final, un yum downgrade ea-apache24 fue la solución que me permitió restaurar el servicio en minutos. Espero que esta guía detallada te ahorre tiempo y estrés si alguna vez te encuentras con este “Misdirected Request”.
¡Feliz administración de sistemas!