VictorPerez.name

Blog de Estrategia y Tecnología para Vender Más

Categoría: Administración de sistemas Linux

Cómo solucionar el error 421 en Apache 2.4.64 paso a paso – 26 julio 2025

por

el julio 26, 2025

en Administración de sistemas Linux

Existen dos soluciones viables: una definitiva (actualizar paquetes corregidos) y una temporal (hacer rollback a la versión anterior). A continuación te presento cada una:

Opción A: Actualizar paquetes a la versión corregida

cPanel y CloudLinux liberaron versiones corregidas que ajustan el comportamiento de Apache y EA-Nginx para manejar correctamente el SNI.

Paso 1: Ejecuta el actualizador principal de cPanel

/scripts/upcp

Paso 2: (Opcional) Asegúrate de actualizar desde el repositorio testing

yum update ea-apache24* ea-nginx --enablerepo=cl-ea4-testing

Esto instalará las versiones corregidas del servidor Apache y Nginx.

Paso 3: Reinicia los servicios web

service httpd restart
service nginx restart

Opción B: Hacer rollback a la versión anterior (temporal)

Si prefieres no usar repositorios testing o tu servidor ya es estable con la versión previa, puedes hacer rollback.

Paso 1: Instala plugin para bloquear versiones

yum install yum-plugin-versionlock

Paso 2: Hacer downgrade de Apache

yum downgrade ea-apache24*

Paso 3: Bloquear actualizaciones automáticas

yum versionlock add ea-apache24*

Paso 4: Reinicia Apache

service httpd restart

Para finalizar

Este error fue consecuencia de una mejora de seguridad en Apache, pero impactó directamente a servidores con proxy reverso sin SNI configurado correctamente. Afortunadamente, cPanel y CloudLinux rapidamente emitieron versiones corregidas.

Te recomiendo mantener siempre tus servidores actualizados y que siempre te apoyes con un experto en estos temas.

💡 ¿Quieres evitar que tu negocio en línea vuelva a caerse sin aviso?

Te ofrezco mis servicios de mantenimiento técnico, monitoreo y prevención de fallos en servidores para sitios de ecommerce, agencias y profesionales independientes.

🔧 Contáctame hoy y mantén tus ventas protegidas.

Error 421 Misdirected Request en servidores cPanel tras actualización de Apache

por

el julio 26, 2025

en Administración de sistemas Linux

Si el día de hoy te llevaste la sorpresa de que tu tienda en línea, sitio comercial o negocio en línea te presentaba el siguiente mensaje, no fuiste el único. Hoy 26 de julio de 2025, miles de sitios en todo el mundo (particularmente aquellos alojados en servidores con cPanel) mostraban este mensaje de error:

Error 421 Misdirected Request

421 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.

Este error detuvo de forma súbita la visibilidad de muchísimos sitios web, incluyendo tiendas online, sitios corporativos, embudos de venta, plataformas de reservas y otros proyectos que dependen de un buen hosting para sus operaciones comerciales.

🔍 ¿Qué pasó exactamente?

Una actualización automática del paquete ea-apache24 a la versión 2.4.64, en servidores con cPanel, introdujo un cambio crítico: ahora Apache exige el uso correcto de SNI (Server Name Indication) para las conexiones HTTPS.

Si este parámetro no se envía correctamente —como ocurre comúnmente en configuraciones que usan Cloudflare, EA-Nginx como proxy reverso o proxies externos— el servidor no sabe qué certificado ni qué VirtualHost debe usar, y simplemente responde con el famoso error 421 que afectó hoy.

Este cambio en el comportamiento rompió muchas configuraciones que funcionaban perfectamente antes de la actualización.

🌐 ¿Fue un problema global?

Sí. administradores de servidores (sysadmins) de todo el mundo reportaron este problema en distintos foros como StackOverflow, Reddit y Discord, los cuales se llenaron rápidamente de quejas y búsquedas de soluciones.

Así que si pensabas que era problema de tu Internet o de tu proveedor de Hosting, la verdad es que no fue así, fue un problema global y tu proveedor de hosting fue uno más de los afectados.

Aunque no se ha publicado una cifra oficial, es obvio que decenas de miles de sitios web sufrieron caídas —y entre ellos, tiendas online que perdieron visitas, ventas y campañas activas en Google Ads o redes sociales. De hecho, todos los servidores que usan EasyApache 4 (sea de América, Europa, Asia, etc.) recibieron esa actualización si no tenían actualizaciones manuales desactivadas.

📉 Impacto directo en ventas: ¿cuánto puedes perder en pocas horas?

Imagina una tienda en línea que factura $2000 USD al día y que por este problema estuvo caída 12 horas. Su pérdida directa en ese tiempo fue de $1000 USD. Además, si tenía campañas de ADS activas, esa inversión se perdió ya que tuvo gasto en tráfico pagado sin retorno.

🧠 ¿Qué es el SNI y por qué importa ahora?

El SNI (Server Name Indication) no es un parámetro que haya surgido el día de hoy. Existe desde el año 2003, pero Apache hasta hoy lo hizo obligatorio para servir contenido HTTPS en todas las configuraciones.

Con la versión 2.4.64, Apache ahora requiere forzosamente este dato en cada conexión HTTPS para saber a qué dominio se refiere la petición, especialmente en servidores con múltiples sitios (VirtualHosts).

Cuando el SNI no llega correctamente (por un proxy, un CDN mal configurado o un cliente HTTP desactualizado), Apache no puede continuar la conexión y responde con el error 421.

🧯 ¿Cuál es la solución al error 421?

He compartido un manual paso a paso para solucionar este problema inmediatamente. Este manual te será útil ya sea que:

  • Seas un proveedor de hosting o reseller.
  • Seas un emprendedor que tiene su propio servidor VPS o dedicado.
  • Estés en una empresa de ecommerce afectada.
  • Seas webmaster o freelancer que administra sitios de clientes.

📎 Da clic aquí para [Ir al manual: Cómo solucionar el error 421 en Apache 2.4.64 paso a paso]

✅ ¿Qué aprendemos de este incidente?

  1. No dependas únicamente de actualizaciones automáticas sin supervisión técnica.
  2. Monitorea tus sitios con herramientas como UptimeRobot, BetterUptime o StatusCake.
  3. Si usas servidores propios o semi-administrados, asegúrate de entender las dependencias críticas como SNI, certificados SSL, proxies y versiones de Apache/Nginx.
  4. Tus ventas dependen del uptime. Cada minuto caído cuesta. Sino entiendes nada técnico o no te gusta enredarte con estos asuntos, contrata a un experto en estos temas.

📌 Fuentes de este artículo:

💡 ¿Quieres evitar que tu negocio en línea vuelva a caerse sin aviso?

Te ofrezco mis servicios de mantenimiento técnico, monitoreo y prevención de fallos en servidores para sitios de ecommerce, agencias y profesionales independientes.

🔧 Contáctame hoy y mantén tus ventas protegidas.

Cómo medir la velocidad de Internet de tu servidor vía SSH

por

el marzo 11, 2020

en Administración de sistemas Linux

$ sudo yum install python

Para servidores CentOS/RHEL 8:

$ sudo yum install python3

$ sudo yum install python2

Para Fedora Linux V22+:

$ sudo dnf install python

$ sudo dnf install pytho3

Paso 2: Descargar speedtest_cli.py

El segundo paso es instalar la herramienta te permitirá usar speedtest.net para medir la velocidad de Internet de tu servidor:

$ wget -O speedtest-cli https://raw.githubusercontent.com/sivel/speedtest-cli/master/speedtest.py
$ chmod +x speedtest-cli

Paso 3: Mide tu velocidad

Ahora ya podrás medir la velocidad de Internet de tu servidor a través de la consola de comandos. Para hacerlo teclea:

$ ./speedtest-cli

O si no funciona el anterior comando prueba con:

$ python speedtest-cli

Por último mira el resultado:

Si esta información te ha sido útil te invito a dejarme un comentario o bien compartelo en tus redes favoritas.

 


Solución a error: Exim Binary not found! – CentOS

por

el marzo 7, 2020

en Administración de sistemas Linux

Solución a error: «Exim Binary not found! at /usr/local/cpanel/Cpanel/**» en servidores Cent OS 6 y 7.

Esta mañana, uno de los servidores que administró tenía problemas en el servicio de envío de correo (exim), al revisar el estado en «Estado del servidor / Estado del servicio» en el WHM (Web Host Manager de cPanel), el servicio de exim aparecía caído:

Al ver lo anterior dije «Bien, bastará con que reinicié exim«, y al ir a la sección de reinicio de servicios, me llevé la sorpresa de que no aparecía el «Servidor de correo exim», ahí noté que algo andaba mal.

Para acelerar las cosas, fui inmediatamente al «Administrador de configuración de exim» y traté de resetear la configuración del exim y ahí fue cuando me apareció el mensaje:

Doing Dry Run
Exim Binary not found! at /usr/local/cpanel/Cpanel/Exim.pm line 99.

Es la primera vez que me aparecía ese mensaje, así que revisé más a fondo y analicé los registros de error (logs) del exim de las horas en que el servicio había empezado a fallar y ahí encontré que el error se generó a raíz de una actualización automática de cPanel que no concluyó con éxito.

¿Cómo se solucionó?

Como el Exim se había dañado se ejecutó el siguiente comando vía SSH para repararlo:

/scripts/check_cpanel_rpms –fix

Por último ejecuté el siguiente comando para comprobar y no dio ningún error:

/scripts/restartsrv_exim –check

Como mencioné, es la primera vez en muchos años que me aparece este error y al no encontrar en Internet alguna referencia sobre ese mismo error, decidí publicarlo ahora en mi blog. Espero que te sea útil, si es así deja tu comentario.

 

 

Cómo cambiar el puerto 22 de SSH a otro

por

el marzo 1, 2020

en Administración de sistemas Linux

Para mayor seguridad es recomendado cambiar el puerto 22 de SSH a otro que tú elijas, para hacerlo sigue los siguientes pasos:

1.- Inicia sesión vía SSH como root y edita el archivo sshd_config que se encuentra en:

etc/ssh/sshd_config

2.- Busca la línea «#Port 22», quita el símbolo «#» y cambia el «22» por otro puerto superior a 1024, por ejemplo: «3625»

3.- Guarda el archivo y ciérralo

4.- Reinicia el servicio sshd ejecutando el comando:

/etc/init.sshd restart en CentOS

/etc/init.ssh restart en Debian

/etc/rc.d/sshd stop ; /etc/rc.dsshd start en Freebsd

Listo, ahora cada que te conectes usarás el nuevo puerto en vez del puerto default.

 

 

Solución a error: Update Failed for EUR USD en WHMCS

por

el septiembre 23, 2018

en Administración de sistemas Linux

Hace un par de días atrás traté de actualizar el tipo de cambio de las monedas Euro y Dólar americano que uso en el sistema WHMCS de Chiapashosting y me marcó dos errores:

Update Failed for EUR
Update Failed for EUR

Supuse que era un problema de incompatibilidad o alguna restricción del firewall del servidor (ya que recientemente mude el sistema de Chiapashosting a un nuevo servidor) así que no le tomé importancia.

Sin embargo el día de hoy intenté de nuevo y noté que el error continuaba así que decidí investigar y encontré la solución brindada por WHMCS.com

Solución:  Update Failed for EUR USD

Whmcs ha indicado que la solución estará en la nueva actualización y que por lo pronto tendrías que hacer la actualización manual, pero para los usuarios exigentes como yo, ha brindado un «Parche de arreglo urgente» que te dejo en el siguiente enlace:

Descarga el parche aquí: https://whmcs.community/files/file/96-core-12694-update-ecb-exchange-rates-url/

Una vez que has descargado el parche, descomprímelo y subes los archivos al directorio en donde tienes instalado WHMCS y reemplaza los archivos actuales vía FTP y con eso quedará solucionado:

Después de realizar lo anterior el resultado será:

Bien este es mi aporte del día de hoy, si te ha servido agrega mi sitio web a tus favoritos o bien agrégame a tus redes sociales.

Escaneo a Profundidad vía SSH de SERVIDORES WEB con Clamav Antivirus

por

el noviembre 30, 2017

en Administración de sistemas Linux

 

 

Uno de los antivirus que la mayoría de proveedores de alojamiento web usan es sin duda Clamav, el cual es gratuito y muy poderoso. En el artículo de hoy te presento algunos comandos que te permitirán realizar un escaneo a profundidad a través de la terminal SSH y además te enviará el resultado a tu correo electrónico:

 

clamscan -r -i --exclude-dir=^/sys\|^/proc\|^/dev / | mail -s "Resultados del Escaneo del `date +%D`" email@email

 

NOTA: Debes reemplazar email@email por tu dirección de correo.

 

Para eliminar automáticamente los archivos infectados, usa el siguiente comando:
 

clamscan -r -i --remove --exclude-dir=^/sys\|^/proc\|^/dev / | mail -s "Resultados del Escaneo del `date +%D`" email@email

 

Para mover los arhivos infectados a un directorio en especial escribe:

 

clamscan -r -i --move=/root/virus/ --exclude-dir=^/sys\|^/proc\|^/dev / | mail -s "Resultados del Escaneo del `date +%D`" email@email

NOTA: /root/virus/ debes reemplazar esto por la ruta en donde se moverán los archivos infectados.

 

Espero que estos comandos te sean útiles y de esta manera mantengas tus servidores libres de malware, virus, troyanos y demás.

 

 

Cómo conocer los Intentos Fallidos de conexión SSH vía putty

por

el octubre 6, 2016

en Administración de sistemas Linux

El servicio de SSH es de los más atacados, debido a que si un pirata lograra acceder por esta vía, tendría control total de tu servidor dedicado y pondría en peligro la información de tu servidor. Hoy te enseñaré Cómo listar los intentos fallidos de conexión SSH que tu servidor recibe, toma nota.

[Tweet «Cómo conocer los Intentos Fallidos de conexión SSH»]

Lo primero que debes realizar es conectarte como root vía SSH a tu servidor dedicado, usando la herramienta Putty

Posteriormente teclea el siguiente comando en la consola:

cat /var/log/secure* | grep ‘Failed password’ | awk ‘{print $9 » » $11 }’ | sort | uniq -c | sort -rn | head -7

El resultado será, que verás una lista de las últimas 7 direcciones IP’s que han tratado de conectarse a tu servidor vía SSH.

Ejemplo:

6597 root 62.152.34.74
2351 root 122.49.119.206
1725 root 61.55.135.59
1074 root 221.181.42.1
926 root 190.24.10.11
675 root 112.216.82.130
565 root 69.64.57.155

El número de resultados se define en el comando por -7, podrás cambiarlo por -10 o el número de IP’s que decidas conocer.

Como puedes notar, este comando es muy útil, te permitirá conocer la lista de IP’s de piratas que tratan de conectarse a tu servidor como root ya sea de forma manual o a través de un Brutal force.

Para finalizar, deberás agregar las IP’s a la lista negra de tu Firewall, de esta forma estas IP’s ya no podrán seguir intentando conectarse a tu servidor.

 

Cómo deshabilitar la alerta LFD «Excessive resource usage»

por

el mayo 3, 2016

en Administración de sistemas Linux

 

Si administras un servidor dedicado, cuentas con cPanel/WHM y el firewall CSF, es posible que estés recibiendo constantemente esta alerta: «Excessive resource usage» en tu buzón de correo. En este artículo te explico cómo disminuir esta alerta o definitivamente dejar de recibirla.

 

Excessive resource usage

 

LFD: es la abreviación de «Login Failure Daemon«. Esto es un proceso que se ejecuta en el servidor que tiene CSF como firewall para la seguridad del servidor.

LFD escanea los registros del servidor de forma periódica, cada «x» segundos. LFD envía una alerta para intentos de inicio de sesión fallidas, los detecta como «ataques de fuerza bruta» y bloquea la IP o bloques de IP’s que son registradas.

En otras ocasiones LFD le enviará una alerta por «uso excesivo de recursos» de un usuario en particular, es en ese momento que recibirá un mensaje similar al siguiente:

Subjet: LFD… Excessive resource usage:

Time:         Tue May  3 08:32:20 2016 -0500
Account:      promoseg
Resource:     Virtual Memory Size
Exceeded:     254 > 200 (MB)
Executable:   /usr/local/cpanel/3rdparty/perl/522/bin/perl
Command Line: spamd child
PID:          19089 (Parent PID:27588)
Killed:       No

Con este ejemplo puedes notar que LFD te está informando que cierto usuario está haciendo un uso excesivo de memoria del servidor. Este mensaje de alerta se puede evitar de 3 formas diferentes, toma nota:

 

Método I: Desactivar la alerta (no recomendado)

 

Puedes desactivar la alerta desde la configuración de CSF. Esta no es una buena medida ya que esta alerta es muy útil para detectar a aquellos usuarios que hacen uso excesivo de recursos y poder controlarlos.

Para desactivar la alerta realiza lo siguiente:

  • Accede como root a tu servidor vía SSH
  • Abre el archivo «CSF configuration» que se encuentra en: /etc/csf/csf.conf con tu editor favorito y busca la directiva «PT_USERMEM«’.
  • Por defecto tendrá el valor de «200» o «256», cámbialo a «0» y de esta manera quedará deshabilitada.

Excessive-resource-usage

 

Método II: Incrementar el PT_USERMEM

 

Esta opción es la que yo te recomiendo, esto disminuirá la cantidad de alertas que recibirás.
 
LFD pasará por alto a los usuarios que usen menos del límite de memoria que establezcas y te informará cuando un usuario específico exceda ese límite.

Para incrementar el PT_USERMEM, realiza lo indicado en el Método I, pero en vez de «0» escribe un valor superior de 256. Lo máximo que podrás incrementar es a «1024» pero de momento no es recomendado.

 

Excessive-resource-usage-2

 

Método III: Excluir el proceso o usuario en csf.pignore

Si la alerta que recibes es sobre un mismo proceso (El servicio de correo Roundcube por ejemplo), o bien sin es de un mismo usuario, puedes editar el archivo «csf.pignore» y añadir el proceso o usuario que deseas Ignorar de las alertas.

Para ello vía SSH, editas el archivo «csf.pignore» y añades la excepción tal y como se muestra en la imagen de abajo:

[root@server #] vim /etc/csf/csf.pignore

Excessive-resource-usage-3

Y por último reinicia el CSF tecleando el comando:

[root@server #] csf -r

 

Estos son los 3 métodos para disminuir la alerta «Excessive resource usage» o para dejar de recibirlas. Considera mis recomendaciones, no la desactives, lo mejor es incrementar la memoria o excluir a determinados procesos o usuarios.

 

Espero que este pequeño tutorial te sea de utilidad y si así fue, no olvides regalarme un «like», «compartir» o mucho mejor dejar tu comentario.

 
 
 

Funciona con WordPress & Tema de Anders Norén