Cómo solucionar el error «Misdirected Request» en HestiaCP (VPS): NGINX + Apache

Contenido:
El error 421 Misdirected Request aparece cuando un cliente (por ejemplo un navegador) realiza una conexión HTTPS en la que el nombre de host solicitado no coincide con el nombre de host que el servidor presenta en la negociación TLS (con SNI). En entornos donde NGINX actúa como proxy frente a Apache (como en HestiaCP + NGINX + Apache), este problema puede emerger tras actualizaciones de Apache u otros componentes. cPanel Support+3Hestia Control Panel – Discourse+3Hestia Control Panel – Discourse+3

1. ¿Qué está ocurriendo?

• En la negociación TLS, el cliente envía la extensión Server Name Indication (SNI) con el nombre de host que desea alcanzar. El servidor debe presentar el certificado adecuado para ese hostname. Medium+1
• Si NGINX actúa como proxy hacia Apache sin reenviar correctamente ese SNI, o si Apache detecta que la conexión TLS no coincide con el virtual-host que el cliente quería, entonces Apache puede responder con HTTP 421 indicando “Misdirected Request: 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.” Hestia Control Panel – Discourse+1
• En el foro de HestiaCP esto ha sido reportado luego de una actualización de Apache: “After an apt update & apt upgrade … websites now display an error 421: Misdirected Request …” Hestia Control Panel – Discourse+1

2. Diagnóstico específico en HestiaCP

• Verifica en los registros de Apache del dominio afectado, se puede ver un log similar a:
  AH02032: Hostname 10.0.0.120 (default host as no SNI was provided) and hostname example.com provided via HTTP have no compatible SSL setup Hestia Control Panel – Discourse+1
• Esto indica que Apache recibió una conexión en la que el hostname indicado por el cliente (example.com) no coincide con el hostname que se negoció en TLS (o no se negoció SNI), y por tanto se considera “misdirected”.
• En el entorno HestiaCP + NGINX + Apache, NGINX normalmente actúa como frontend y pasa la conexión (proxy_pass) hacia Apache. Si NGINX no pasa el SNI correctamente al backend, el problema se manifiesta.

3. Solución manual recomendada

Uno de los trabajos más citados en los foros de HestiaCP es añadir las directivas correctas en la configuración de NGINX para habilitar el paso del SNI al backend Apache. Ejemplo de solución:

for file in $(grep -l proxy_pass /usr/local/hestia/data/templates/web/nginx/*.stpl); do
  if ! grep -q proxy_ssl_server_name "$file"; then
    sed -i '/proxy_pass/ i\
        proxy_ssl_server_name on;\
        proxy_ssl_name $host;' "$file"
  fi
done

# Luego reconstruir todos los dominios de los usuarios
for i in $(v-list-users plain | cut -f1); do
  echo "Rebuilding web domains for user $i"
  v-rebuild-web-domains $i yes
done

4. Pasos concretos para HestiaCP

1. Conéctate por SSH al servidor.
2. Crea un fichero de configuración global de NGINX que incluya:

proxy_ssl_server_name on;
proxy_ssl_name $host;
proxy_ssl_session_reuse off;

Guarda este fichero, por ejemplo como /etc/nginx/conf.d/fixssl.conf. (La directiva proxy_ssl_session_reuse off; también aparece en soluciones para entornos similares. support.plesk.com+1 )

3. Reinicia o recarga NGINX:

systemctl reload nginx

4. Si utilizas plantillas de Hestia para NGINX, edita los archivos .stpl en /usr/local/hestia/data/templates/web/nginx/ añadiendo las líneas anteriores antes de proxy_pass.

5. Reconstuye las configuraciones de los dominios usando el comando de Hestia:

v-rebuild-web-domains <usuario> yes

Repítelo para todos los usuarios o usa un bucle automatizado como se mostró arriba.

6. Una vez hecho, prueba acceder al dominio por HTTPS, limpia el caché del navegador o utiliza un modo “incógnito” para asegurar que no se esté reutilizando una conexión anterior.

7. Verifica los logs de Apache del dominio para confirmar que el error AH02032 no aparece más.

8. Opcional: considera deshabilitar HTTP/2 temporalmente para ese dominio si el problema persiste, ya que la reutilización de conexiones TLS en HTTP/2 es parte de la causa de este error.

5. Consideraciones adicionales

• Este problema parece haberse disparado después de una actualización de Apache (o de componentes relacionados) que cambió la forma en que Apache maneja SNI para conexiones proxied via NGINX. community.enhance.com+1
• Asegúrate de que todos tus virtual hosts (dominios) usan configuración de SSL/TLS homogénea (mismos protocolos, parámetros de cifrado, etc.). Según la documentación de Apache, la mezcla de configuraciones en hosts que comparten certificado o conexión puede provocar el 421. cPanel Support+1
• Verifica que no estés utilizando un certificado compartido mal configurado (por ejemplo un certificado SAN que cubre múltiples dominios) sin que cada dominio tenga exactamente la misma configuración TLS, lo cual es factor común en este error. Webidextrous LLC+1
• Tras aplicar la solución, algunos usuarios en los foros reportaron que tuvieron problemas con correo electrónico o servicios adicionales; aunque la comunidad aclara que los servicios de correo no deberían verse afectados directamente por este cambio de NGINX/SSL. Hestia Control Panel – Discourse

6. Conclusión

En resumen: si en tu servidor HestiaCP + NGINX + Apache aparece el error 421 Misdirected Request, lo más probable es que sea un problema de SNI/proxy entre NGINX y Apache. La solución consiste en asegurar que NGINX pase correctamente el nombre de host al backend (Apache) mediante proxy_ssl_server_name on; y proxy_ssl_name $host;, así como reconstruir los dominios para que las configuraciones se actualicen. Aplicar este remedio suele resolver el problema de inmediato.