No hay nada que te prepare para el momento en que todos tus sitios alojados en Plesk colapsan de un segundo a otro y te reciben con un escueto, absurdo e irritante mensaje:
“Error 421 Misdirected Request”.
El sudor frío comienza a escurrirte por la espalda. Lo primero que haces es culpar al DNS. Luego al firewall. Después crees que los certificados SSL están caducados, mal instalados, duplicados, poseídos por algún demonio apacheano del siglo XXI. Reinstalas, reinicias, reconfiguras, lloras. Pero nada funciona.
La trampa está ahí: no hay forma humana de imaginar que todo se debe a una actualización silenciosa de Apache. Un parche de seguridad bienintencionado que termina convirtiendo al servidor en un portero de discoteca enloquecido, rechazando a cada cliente HTTPS que no le susurre dulcemente su nombre.
El mensaje que nos volvió locos
En los registros aparece esto:
pgsql Copiar Editar AH02032: Hostname default-203_0_113_2 (default host as no SNI was provided) and hostname www.example.com provided via HTTP have no compatible SSL setup
Traducción: Apache ahora exige que cada petición HTTPS venga acompañada de la identificación del servidor (mediante SNI, Server Name Indication). Y nginx —ese viejo compañero de batalla— no la está enviando por defecto cuando actúa como proxy inverso.
Resultado: todos tus sitios explotan sin previo aviso y tú, como un idiota, probando cada tutorial, cada truco de ChatGPT, cada video de YouTube con títulos estilo “¡Arregla el error 421 en 3 minutos!”. Cinco horas. Eso fue lo que duró mi calvario.
La solución (gracias, soporte de Plesk)
Finalmente, después de raspar la web como quien busca oro en las cloacas, encontramos un artículo del soporte oficial de Plesk. Dos líneas de configuración. Solo eso.
Conéctate por SSH y ejecuta esto:
bash Copiar Editar echo -e "proxy_ssl_server_name on;\nproxy_ssl_name \$host;" > /etc/nginx/conf.d/fixssl.conf && service nginx restart
¿Resultado? Magia. Los sitios volvieron como si nunca se hubieran ido. Como si las cinco horas anteriores fueran un mal sueño. Apache dejó de hacer berrinche. nginx empezó a comportarse. Y el mundo volvió a su equilibrio.
¿Qué aprendimos?
- Apache ya no acepta conexiones sin SNI por cuestiones de seguridad.
- nginx necesita que le recuerdes pasar el nombre del servidor cuando actúa como proxy HTTPS.
- Plesk aún no ha lanzado la solución oficial, pero lo está preparando para las versiones 18.0.70 y 18.0.71.
- A veces, el problema no está en ti, sino en una actualización que nadie te advirtió.
Y sobre todo: que cuando un error te diga «Misdirected Request», el que está desorientado probablemente eres tú, no la máquina.
Hola Iván, muchísimas gracias por compartir la solución. Me has salvado la vida porque llevaba horas peleándome con las directivas de SNI en un servidor de producción y no entendía por qué Nginx ignoraba el host. Al aplicar tu fix de `proxy_ssl_server_name`, todo ha vuelto a la normalidad al instante.
Aprovechando tu experiencia con el mantenimiento web y la seguridad en 2026, quería consultarte algo técnico. Estoy configurando una plataforma de gestión para un cliente del sector legal/fintech y me preocupa la nueva normativa de cumplimiento. He estado revisando la estructura técnica y de licencias en sitios que ya operan bajo el nuevo marco legal de la SPA/MF, como se detalla en https://guiadebetnacionalbrasil.com , y me pregunto: ¿crees que este tipo de validaciones de certificados y SNI que comentas en Apache se volverán un estándar obligatorio para cualquier sitio que maneje transacciones bajo estas nuevas regulaciones estatales, o seguirá siendo algo opcional según el nivel de endurecimiento del servidor? ¡Un saludo y gran post!
¡Increíble aporte, Iván! Me has ahorrado el mismo calvario porque justo estaba lidiando con fallos de configuración tras la actualización. Por cierto, aprovechando que dominas el tema de las cabeceras y bloqueos de Apache/Nginx, ¿sabes si el error 451 tiene algo que ver con la directiva SNI que mencionas o es puramente un bloqueo geográfico por IP? Te lo pregunto porque intentando acceder a una documentación en guiadebetnacionalbrasil.com me salta ese código de estado legal y no sé si es algo que pueda parchear desde el archivo fixssl.conf o si es un tema externo al servidor. ¡Gracias de antemano!