ERR_CONNECTION_REFUSED: Cómo solucionarlo en tu web

El ERR_CONNECTION_REFUSED es de esos fallos que amargan la mañana a cualquier webmaster: abres tu web y el navegador te suelta un lacónico «conexión rechazada». Sin pistas. Sin nada. Lo curioso es que, aunque el mensaje salte en tu navegador, casi nunca el problema está en tu equipo: la causa suele estar en el servidor, en los DNS o en el firewall. En esta guía te explicamos qué significa exactamente este error, cómo averiguar si el fallo es tuyo o del servidor, y qué soluciones aplicar paso a paso. Y si no quieres pelearte con la tecnología, en RedServicio (redservicio.net) te lo resuelven en minutos.

¿Qué significa el error ERR_CONNECTION_REFUSED y por qué aparece?

Vamos a lo básico. Este mensaje indica que el navegador intentó conectar con el servidor donde vive tu web, pero este rechazó la petición de forma activa. Fíjate en el matiz: no es un tiempo de espera agotado, ni un DNS que no responde. Algo ahí fuera contestó, y contestó con un «no acepto esta conexión». Técnicamente, la solicitud TCP al puerto correspondiente —normalmente el 80 (HTTP) o el 443 (HTTPS)— fue denegada.

¿Y qué provoca ese rechazo? Lo más habitual:

• El servicio web está caído: Apache, Nginx o LiteSpeed se han detenido por un fallo de configuración, falta de memoria o un reinicio que salió mal.
• Puerto bloqueado por el firewall: puede ser el firewall del servidor, o el de tu propio equipo o red, filtrando el tráfico hacia esos puertos.
• DNS mal configurados: los registros A o AAAA del dominio apuntan a una IP equivocada. Suele pasar tras una migración de hosting reciente.
• Servidor saturado o suspendido: un plan de hosting sin recursos, o una cuenta suspendida por impago o abuso, también devuelve este rechazo.
• Software local interferente: antivirus, VPN o un proxy en tu equipo pueden dar el mismo mensaje aunque el servidor esté perfectamente.

Distinguir entre estas causas es el primer paso para acertar con la solución. Para eso sirve el diagnóstico que viene ahora.

Comprobar si el problema es del servidor o de tu conexión

Antes de tocar nada en el servidor, dedica dos minutos a aislar el origen del fallo:

1. Prueba la web desde otro dispositivo y red: ábrela desde el móvil con datos móviles, no con WiFi. Si carga bien, el problema está en tu equipo o en tu red local.
2. Comprueba si está caído para todo el mundo: pide a alguien en otra ubicación que lo visite, o usa un servicio online de verificación de estado de sitios.
3. Reinicia router y equipo: suena a consejo de soporte telefónico, lo sé. Pero muchos casos de ERR_CONNECTION_REFUSED se arreglan así, por cachés DNS corruptas.
4. Revisa el ping y la IP del dominio: ejecuta en tu terminal ping tudominio.com y compara la IP que devuelve con la real de tu servidor, que puedes ver en el panel de tu hosting. Si no coinciden, el problema es de DNS.
5. Comprueba el puerto directamente: con telnet tudominio.com 443 (o nc en Linux) sabrás si el puerto web está abierto y aceptando conexiones.

Con esto ya sabes hacia dónde apuntar. ¿El fallo es solo tuyo? Con las soluciones locales basta. ¿Es general? Toca servidor.

Cómo solucionar el error ERR_CONNECTION_REFUSED paso a paso

Aplica las soluciones en orden: primero las locales, que solo te afectan a ti, y luego las del servidor.

Soluciones en tu equipo local

1. Limpia la caché DNS: en Windows, ipconfig /flushdns en la consola de comandos; en macOS, sudo dscacheutil -flushcache.
2. Cambia temporalmente los DNS: configura 8.8.8.8 y 1.1.1.1 en tu adaptador de red para descartar problemas con tu DNS actual.
3. Desactiva VPN, proxy y antivirus: prueba de nuevo la web con todo eso apagado. Si funciona, añade una excepción para tu dominio y listo.
4. Borra la caché del navegador: pruébalo también en modo incógnito, que descarta extensiones.

Soluciones en el servidor

1. Reinicia el servicio web: desde SSH, sudo systemctl restart apache2 o sudo systemctl restart nginx, según tu stack.
2. Revisa los logs: consulta /var/log/nginx/error.log o /var/log/apache2/error.log buscando el motivo exacto del fallo, y verifica la sintaxis con nginx -t o apachectl configtest.
3. Comprueba el firewall del servidor: asegúrate de que los puertos 80 y 443 están abiertos con sudo ufw status o revisando las reglas de iptables.
4. Verifica los DNS del dominio: confirma en tu gestor de DNS que el registro A apunta a la IP correcta del servidor. Si acabas de cambiarla, toca esperar la propagación.
5. Revisa recursos y estado de la cuenta: entra en el panel de hosting y mira el consumo de RAM y CPU, o si la cuenta está suspendida.

¿Persiste después de todo esto? Entonces lo más eficaz es abrir un ticket con tu proveedor de hosting y adjuntar los resultados del diagnóstico. En RedServicio (redservicio.net) tienes soporte técnico especializado que puede revisar tu servidor y devolverte el acceso a la web.

Revisar DNS, firewall y puertos del servidor

Servidor encendido, y aun así el navegador sigue devolviendo ERR_CONNECTION_REFUSED. Pues entonces el problema casi seguro anda en la capa de red. Los culpables, en mi experiencia, suelen ser siempre los mismos tres: un DNS que resuelve mal, reglas de firewall bloqueando el tráfico o un servicio web escuchando en un puerto equivocado (o en ninguno).

Comprobar los registros DNS

Pasa más de lo que parece: un registro A que sigue apuntando a una IP vieja, típico tras una migración de hosting. El navegador intenta conectar con un servidor que, sencillamente, ya no aloja tu web. Comprueba la propagación con dig tudominio.com +short o, si prefieres algo visual, whatsmydns.net. ¿La IP devuelta no coincide con la de tu servidor actual? Corrige el registro en el panel de tu gestor de DNS. Un truco: baja el TTL a 300 segundos antes del cambio, así la propagación va mucho más rápida.

Firewall y puertos 80 y 443

Este error aparece de forma bastante característica cuando el puerto 80 (HTTP) o el 443 (HTTPS) están cerrados o filtrados. Revisa esto:

• UFW (Ubuntu/Debian): ejecuta sudo ufw status y mira que existan reglas para «80/tcp» y «443/tcp». Si no están, sudo ufw allow 80,443/tcp y listo.
• firewalld (CentOS/AlmaLinux): con sudo firewall-cmd –list-all ves lo que hay. Añade el servicio con sudo firewall-cmd –permanent –add-service=https y recarga después.
• Seguridad a nivel de nube: ojo con esto, porque en AWS, Google Cloud o Azure los security groups y firewalls de red son independientes del firewall del sistema operativo. Muchos revisan el sistema y olvidan la nube. Comprueba que las reglas de entrada permitan tráfico web desde 0.0.0.0/0.

Verificar que el servicio escucha

Ejecuta sudo ss -tlnp | grep -E ‘:80|:443’. Si no sale nada, mal asunto: Nginx o Apache no están activos. Arráncalos con sudo systemctl restart nginx o sudo systemctl restart apache2 y bucea en los logs de /var/log/nginx/error.log o /var/log/apache2/error.log para encontrar qué los tumbó.

Soluciones específicas para WordPress y plugins de caché

En WordPress este error a veces se comporta de forma rara: solo afecta a ciertas URLs, o aparece justo después de instalar un componente concreto. Si es tu caso, estos pasos resuelven la mayoría de los escenarios:

1. Desactiva plugins vía FTP o gestión de archivos. Renombra la carpeta wp-content/plugins a «plugins_off». ¿La web vuelve a cargar? Restaura el nombre y desactiva los plugins uno a uno hasta dar con el responsable.
2. Revisa plugins de caché y optimización. W3 Total Cache, WP Super Cache o LiteSpeed Cache pueden escribir configuraciones de servidor (reglas .htaccess o archivos de Nginx) que acaban rompiendo el servicio. Vacía la caché desde el panel y, si no tienes acceso, borra a mano el contenido de wp-content/cache.
3. Comprueba el archivo .htaccess. Renómbralo a «.htaccess_backup» e intenta cargar la web. Si funciona, genera uno nuevo desde Ajustes > Enlaces permanentes en el escritorio de WordPress.
4. Aumenta los recursos PHP. Un límite de memoria agotado puede tirar el proceso PHP-FPM sin mucha ceremonia. Define en wp-config.php: define(‘WP_MEMORY_LIMIT’, ‘256M’);
5. Verifica la URL del sitio. Un cambio incorrecto en siteurl u home al migrar a HTTPS puede redirigir a un puerto que no está disponible. Se corrige desde phpMyAdmin en la tabla wp_options, o con WP_CLI: wp option update siteurl https://tudominio.com.

Conclusión: cómo prevenir el error ERR_CONNECTION_REFUSED en el futuro

Al final, este error casi siempre significa lo mismo: algo, en el servidor o en el camino hasta él, está rechazando la conexión de forma activa. Un servicio caído, un puerto cerrado, un firewall mal configurado o un DNS desactualizado. Lo bueno es que sigue un patrón bastante predecible y, con un diagnóstico ordenado, la mayoría de casos se resuelven en menos de una hora.

¿Y para que no vuelva? Pues rutina de mantenimiento. Concretamente:

• Monitoriza la disponibilidad con UptimeRobot o Pingdom, para enterarte de la caída antes que tus visitantes (que siempre son los primeros en avisar, y no precisamente con amabilidad).
• Mantén copias de seguridad automáticas y diarias, guardadas fuera del servidor.
• Documenta cada cambio en DNS, firewall o configuración del servidor. Cuando algo se rompe, saber qué tocaste ayer te ahorra horas.
• Actualiza WordPress, plugins y el sistema operativo con regularidad, probando antes en staging.
• Revisa los logs del servidor una vez por semana; estos errores casi nunca llegan sin previo aviso.

Y si todo esto de puertos, firewalls y logs no va contigo, en RedServicio (redservicio.net) lo llevamos de serie: diagnosticamos la causa exacta del error ERR_CONNECTION_REFUSED, restauramos el acceso a tu web y dejamos el servidor configurado para que el problema no se repita.