ERR_CONNECTION_REFUSED: Qué significa y cómo solucionarlo completamente
El error ERR_CONNECTION_REFUSED significa que tu navegador envió una solicitud de conexión a un servidor web, y ese servidor la rechazó activamente — no la ignoró, sino que se negó explícitamente al protocolo de enlace TCP. Este es un modo de fallo fundamentalmente diferente al de un tiempo de espera agotado (ERR_CONNECTION_TIMED_OUT) o un fallo de DNS (ERR_NAME_NOT_RESOLVED), y esa distinción es enormemente importante al diagnosticar la causa raíz.
En términos prácticos, cuando Chrome muestra "No se puede acceder a este sitio. ERR_CONNECTION_REFUSED," significa una de tres cosas: el servidor de destino no está escuchando en el puerto solicitado, un firewall o capa de seguridad está enviando un paquete TCP RST (reset) de vuelta a tu cliente, o la pila de red local está mal configurada y enruta la solicitud incorrectamente antes de que llegue al servidor. Identificar cuál de estas tres categorías aplica a tu situación es el camino más rápido hacia una solución.
Comprendiendo la Mecánica a Nivel TCP
La mayoría de las guías de solución de problemas del navegador tratan ERR_CONNECTION_REFUSED como un vago "problema de red". No lo es. En la capa TCP, una conexión rechazada significa que el servidor (o un intermediario) envió de vuelta un paquete RST/ACK en respuesta al paquete SYN de tu navegador. Esto es un rechazo explícito, no una eliminación silenciosa.
Esta distinción tiene una implicación diagnóstica práctica: si la conexión estuviera siendo eliminada silenciosamente por un firewall, verías ERR_CONNECTION_TIMED_OUT. Una conexión rechazada significa que algo está respondiendo activamente — lo que significa que el host es accesible a nivel de red, pero el servicio en el puerto de destino no está disponible o está bloqueado.
Las causas comunes a nivel de puerto incluyen:
- El proceso del servidor web (Apache, Nginx, Node.js) se ha bloqueado o detenido
- El servidor está escuchando en un puerto no estándar y la URL no lo especifica
- Un firewall basado en el host (iptables, ufw, Windows Defender Firewall) está rechazando conexiones en el puerto 80 o 443
- Un proxy inverso (HAProxy, Nginx, Cloudflare) está configurado incorrectamente y devuelve paquetes RST al upstream
- La aplicación detrás del proxy se ha bloqueado, dejando al proxy sin backend al que reenviar
Causas Raíz: Un Desglose Estructurado
Causas del Lado del Cliente
| Causa | Mecanismo | Señal Diagnóstica |
|---|
| — | — | — |
|---|
| Caché del navegador corrupta | Redirección en caché obsoleta o datos de conexión | El error aparece solo en un navegador |
|---|
| Configuración de proxy incorrecta | El navegador enruta el tráfico a través de un proxy inactivo | Error en todos los sitios o dominios específicos |
|---|
| Caché DNS obsoleta | La IP en caché apunta a un servidor que ya no aloja el sitio | `nslookup` devuelve una IP diferente a la almacenada en caché |
|---|
| Navegador desactualizado | Fallo en la negociación TLS reportado incorrectamente como rechazo de conexión | El error desaparece en un navegador actualizado |
|---|
| Configuración incorrecta de VPN o túnel | El tráfico se enruta a través de un nodo de salida no funcional | El error se resuelve cuando se deshabilita la VPN |
|---|
| Bloqueo por antivirus/firewall | El software de seguridad envía RST en nombre del sistema operativo | El error desaparece cuando se deshabilita el software |
|---|
Causas del Lado del Servidor
| Causa | Mecanismo | Señal Diagnóstica |
|---|
| — | — | — |
|---|
| Proceso del servidor web caído | Sin listener en el puerto 80/443 | `curl -v` muestra "Connection refused" |
|---|
| Configuración incorrecta del puerto | Servidor vinculado a una interfaz o puerto incorrecto | `netstat -tlnp` no muestra listener en el puerto esperado |
|---|
| Error de certificado SSL que causa bloqueo | TLS mal configurado hace que el servidor rechace HTTPS | Error solo en HTTPS, no en HTTP |
|---|
| Agotamiento de recursos | Servidor sin descriptores de archivo o memoria | Error intermitente, frecuentemente bajo carga |
|---|
| Cambio de dirección IP sin propagación DNS | DNS aún resuelve a la IP antigua, desmantelada | `dig` muestra la IP antigua, el nuevo servidor está en otro lugar |
|---|
| Regla de firewall en el servidor | Regla DROP o REJECT de iptables para el rango de IP del cliente | Error solo para usuarios/regiones específicas |
|---|
Guía de Diagnóstico y Solución Paso a Paso
Paso 1: Determinar si el Problema es Global o Local
Antes de modificar cualquier configuración local, establece si el sitio está caído para todos o solo para ti. Usa estas herramientas:
- downforeveryoneorjustme.com — verificación simple de activo/caído
- isitdownrightnow.com — incluye historial de tiempos de respuesta
- ping.pe — hace ping al destino desde múltiples ubicaciones globales simultáneamente
Si el sitio es accesible desde nodos externos pero no desde tu máquina, el problema es local. Si es inaccesible globalmente, el problema está en el servidor y está fuera de tu control — contacta al administrador del sitio o espera.
Para los administradores de servidores que gestionan su propia infraestructura, un sitio globalmente inaccesible justifica una investigación inmediata del proceso del servidor web, las reglas del firewall y la red upstream. Si estás ejecutando un entorno de VPS Hosting, verifica primero la lista de procesos de tu servidor y la configuración del firewall.
Paso 2: Verificar que el Servidor Está Escuchando (Para Administradores de Servidores)
Si administras el servidor en cuestión, conéctate por SSH y ejecuta lo siguiente para confirmar qué está escuchando en qué puertos:
sudo ss -tlnp | grep -E ':80|:443'Si la salida está vacía para el puerto 80 o 443, el proceso de tu servidor web no está en ejecución. Reinícialo:
# For Nginx
sudo systemctl restart nginx
# For Apache
sudo systemctl restart apache2
# Check status
sudo systemctl status nginxTambién verifica que tu firewall no esté bloqueando las conexiones entrantes:
# Check iptables rules
sudo iptables -L INPUT -n -v
# If using ufw
sudo ufw status verboseSi el puerto 443 está bloqueado, permítelo:
sudo ufw allow 443/tcp
sudo ufw allow 80/tcp
sudo ufw reloadPara los administradores que ejecutan Servidores Dedicados, también verifica si el firewall upstream de tu proveedor de hosting o las reglas del grupo de seguridad están bloqueando el puerto en el perímetro de la red — esto es independiente del firewall a nivel del sistema operativo.
Paso 3: Reiniciar el Router y Limpiar el Estado de la Red Local
Para problemas del lado del cliente, reiniciar el router limpia las tablas NAT, los arrendamientos DHCP y cualquier fallo de enrutamiento transitorio. Desenchufa el router durante 30 segundos y vuelve a conectarlo. Esto es especialmente efectivo cuando el error apareció repentinamente sin ningún cambio de configuración.
Paso 4: Vaciar la Caché DNS
Una entrada de caché DNS obsoleta que apunta a una dirección IP antigua o desmantelada es una de las causas más comunes de ERR_CONNECTION_REFUSED en el lado del cliente. Es posible que el servidor en la IP almacenada en caché ya no esté ejecutando el sitio de destino.
En Windows:
ipconfig /flushdnsEn macOS (Ventura, Sonoma y la mayoría de versiones modernas):
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponderEn Linux (systemd-resolved):
sudo systemd-resolve --flush-cachesDespués de vaciar la caché, verifica a qué IP se resuelve ahora el dominio:
nslookup example.com
# or
dig +short example.comCompara esto con la IP conocida del sitio. Si difieren, es posible que la propagación DNS aún esté en curso.
Paso 5: Limpiar la Caché y las Cookies del Navegador
En Google Chrome, navega a chrome://settings/clearBrowserData o usa el atajo de teclado:
- Windows/Linux:
Ctrl + Shift + Delete - macOS:
Cmd + Shift + Delete
Establece el intervalo de tiempo en Todo el tiempo, marca Imágenes y archivos en caché y Cookies y otros datos de sitios, luego haz clic en Borrar datos. Reinicia Chrome completamente (no solo la pestaña) antes de volver a probar.
Para una prueba más rápida sin borrar datos, abre una ventana de Incógnito (Ctrl + Shift + N). Si el sitio carga en modo Incógnito pero no en una ventana normal, el culpable es un recurso en caché o una extensión del navegador.
Paso 6: Auditar y Deshabilitar la Configuración del Proxy
Un servidor proxy mal configurado o inactivo es una causa frecuente de ERR_CONNECTION_REFUSED en todos los sitios web simultáneamente. Chrome usa la configuración del proxy del sistema de forma predeterminada.
En Windows:
Navega a Configuración > Sistema > Proxy y deshabilita "Usar un servidor proxy" si está habilitado sin tu conocimiento. Alternativamente, ejecuta esto desde un Símbolo del sistema elevado:
netsh winhttp reset proxyEn macOS:
Ve a Configuración del Sistema > Red, selecciona tu interfaz activa, haz clic en Detalles, luego en la pestaña Proxies, y desmarca todos los protocolos de proxy activos.
Después de deshabilitar el proxy, prueba el sitio. Si carga, la configuración del proxy era la causa. Reconfigúralo correctamente o elimínalo por completo.
Paso 7: Cambiar tu Resolvedor DNS
El resolvedor DNS predeterminado de tu ISP puede estar devolviendo resultados incorrectos, experimentando una interrupción o bloqueando activamente ciertos dominios. Cambiar a un resolvedor público elimina esta variable.
Resolvedores DNS públicos recomendados:
| Proveedor | DNS Primario | DNS Secundario | Característica |
|---|
| — | — | — | — |
|---|
| Google Public DNS | `8.8.8.8` | `8.8.4.4` | Alta disponibilidad, anycast global |
|---|
| Cloudflare | `1.1.1.1` | `1.0.0.1` | Tiempo de respuesta promedio más rápido, enfocado en privacidad |
|---|
| OpenDNS | `208.67.222.222` | `208.67.220.220` | Opciones de filtrado de contenido |
|---|
| Quad9 | `9.9.9.9` | `149.112.112.112` | Bloqueo de malware, respetuoso con la privacidad |
|---|
En Windows (mediante PowerShell):
Set-DnsClientServerAddress -InterfaceAlias "Wi-Fi" -ServerAddresses ("1.1.1.1","1.0.0.1")En macOS:
Ve a Configuración del Sistema > Red > [Tu Interfaz] > Detalles > DNS, elimina las entradas existentes y añade 1.1.1.1 y 1.0.0.1.
En Linux (systemd-resolved):
Edita /etc/systemd/resolved.conf:
[Resolve]
DNS=1.1.1.1 1.0.0.1
FallbackDNS=8.8.8.8 8.8.4.4Luego reinicia el resolvedor:
sudo systemctl restart systemd-resolvedPaso 8: Deshabilitar Temporalmente el Firewall y el Antivirus
Algunos productos antivirus y firewalls basados en el host interceptan el tráfico HTTPS a través de un proxy local y pueden emitir paquetes RST cuando su motor de inspección falla o cuando el dominio de destino está en una lista de bloqueo. Deshabilitarlos temporalmente (solo con fines de diagnóstico) confirma si son la causa.
Si deshabilitar el software de seguridad resuelve el error, añade una excepción específica para el dominio de destino en lugar de dejar el software deshabilitado. Vuelve a habilitarlo inmediatamente después de las pruebas.
Paso 9: Probar con un Navegador y una Red Diferentes
Prueba la URL en Firefox, Edge o Safari. Si carga en otro navegador, el problema es específico de Chrome — probablemente un perfil corrupto, una extensión que no funciona correctamente o una configuración de proxy específica de Chrome. Intenta crear un nuevo perfil de Chrome para aislar el problema.
Si el sitio falla en todos los navegadores, cambia a un punto de acceso móvil. Si carga con datos móviles, tu ISP o router doméstico es la fuente del problema.
Paso 10: Verificar Problemas de Configuración SSL/TLS (Administradores de Servidores)
Un certificado SSL mal configurado puede hacer que el servidor se bloquee o rechace las conexiones TLS, lo que Chrome reporta como ERR_CONNECTION_REFUSED en lugar de un error de certificado en algunos casos extremos. Usa lo siguiente para probar desde la línea de comandos:
curl -vI https://yourdomain.comBusca la etapa del protocolo de enlace TLS en la salida detallada. Un fallo aquí indica un problema con el certificado o el conjunto de cifrado. También puedes probar con:
openssl s_client -connect yourdomain.com:443 -servername yourdomain.comSi tu certificado SSL ha expirado o está mal configurado, renovarlo o reemplazarlo resuelve el problema. Asegúrate de que tus Certificados SSL sean válidos, estén correctamente encadenados e instalados en la interfaz de servidor correcta.
ERR_CONNECTION_REFUSED vs. Errores de Navegador Similares
Comprender cómo este error difiere de los errores relacionados previene diagnósticos incorrectos:
| Código de Error | Comportamiento TCP | Causa Más Probable |
|---|
| — | — | — |
|---|
| `ERR_CONNECTION_REFUSED` | El servidor envía un paquete RST | Servicio no en ejecución, regla REJECT del firewall, proxy inactivo |
|---|
| `ERR_CONNECTION_TIMED_OUT` | Sin respuesta (paquete descartado) | Regla DROP del firewall, fallo de enrutamiento, servidor sobrecargado |
|---|
| `ERR_NAME_NOT_RESOLVED` | La consulta DNS falla | Configuración DNS incorrecta, el dominio no existe |
|---|
| `ERR_SSL_PROTOCOL_ERROR` | El protocolo de enlace TLS falla | Versiones TLS incompatibles, certificado incorrecto |
|---|
| `ERR_EMPTY_RESPONSE` | La conexión se abre, no se envían datos | El servidor acepta la conexión pero la aplicación se bloquea inmediatamente |
|---|
| `ERR_ADDRESS_UNREACHABLE` | Sin ruta al host | Problema en la tabla de enrutamiento, interfaz caída |
|---|
Casos Extremos Avanzados y Errores Comunes
Conflictos de resolución IPv6 vs. IPv4: Si un dominio se resuelve a una dirección IPv6 pero tu red no admite IPv6 correctamente, Chrome puede intentar una conexión IPv6 que sea rechazada y luego no lograr revertir a IPv4 rápidamente. Deshabilitar temporalmente IPv6 en el adaptador de red puede confirmar esto. En Linux, puedes forzar IPv4 con curl -4 https://example.com.
Errores de origen obsoleto en caché de Cloudflare o CDN: Si un sitio usa Cloudflare y el servidor de origen cae, Cloudflare puede servir una versión en caché durante un tiempo y luego comenzar a devolver errores 521 (origen rechazó la conexión) o 522, que Chrome puede mostrar como ERR_CONNECTION_REFUSED dependiendo de cómo se procese el error.
Entornos de desarrollo local: Los desarrolladores frecuentemente ven ERR_CONNECTION_REFUSED al acceder a localhost:3000 o similares. La causa casi siempre es que el proceso del servidor de desarrollo no está en ejecución, se ha bloqueado o está vinculado a 127.0.0.1 en un puerto diferente al esperado. Ejecuta ss -tlnp | grep node (o el proceso relevante) para confirmar qué está escuchando realmente.
Conflictos de puertos del servidor de correo: Si estás ejecutando Hosting de Correo Electrónico en el mismo servidor que tu aplicación web, asegúrate de que los conflictos de puertos entre SMTP (25, 587), IMAP (993) y HTTP/HTTPS (80, 443) no estén causando que el servidor web no pueda vincularse.
Limitaciones del hosting compartido: En entornos de Hosting Web Compartido, un rechazo de conexión puede indicar que el servidor del proveedor de hosting está sobrecargado, la cuenta ha sido suspendida o el DNS del dominio aún no apunta a la IP compartida correcta. Verifica el estado de tu cuenta y la configuración DNS en el panel de control de tu hosting.
Matriz de Decisión Práctica: Qué Solución Aplicar Primero
Usa esta lista de verificación para clasificar eficientemente:
- El error aparece en todos los sitios web simultáneamente — Verifica primero la configuración del proxy y la configuración de VPN/firewall
- El error aparece solo en un dominio específico — Verifica si el sitio está caído globalmente; luego vacía la caché DNS
- El error aparece solo en Chrome, no en otros navegadores — Limpia la caché de Chrome, deshabilita las extensiones o crea un nuevo perfil de Chrome
- El error aparece solo en tu red, no con datos móviles — Reinicia el router; verifica el DNS a nivel del ISP o el firewall
- El error aparece después de un cambio en la configuración del servidor — Verifica el estado del proceso del servidor web, los enlaces de puertos y las reglas del firewall en el servidor
- El error aparece intermitentemente bajo carga — Investiga el agotamiento de recursos (descriptores de archivo, memoria, límites de conexión) en el servidor
- El error aparece solo en HTTPS, no en HTTP — Investiga la validez del certificado SSL y la configuración TLS
- El error apareció después de cambiar la configuración DNS — Revierte los cambios DNS y vacía la caché; verifica que el nuevo resolvedor sea accesible
Preguntas Frecuentes
¿Cuál es la diferencia entre ERR_CONNECTION_REFUSED y ERR_CONNECTION_TIMED_OUT?
ERR_CONNECTION_REFUSED significa que el servidor (o un firewall) envió activamente un paquete de reset TCP, rechazando la conexión de inmediato. ERR_CONNECTION_TIMED_OUT significa que no se recibió respuesta dentro del período de tiempo de espera — los paquetes fueron descartados silenciosamente. Una conexión rechazada aparece más rápido e indica un rechazo activo, mientras que un tiempo de espera agotado sugiere una regla DROP de enrutamiento o firewall.
¿Puede ERR_CONNECTION_REFUSED ser causado por un certificado SSL expirado?
Indirectamente, sí. En algunas configuraciones de servidor, un certificado SSL expirado o mal configurado hace que el proceso del servidor web falle al iniciarse o se bloquee al manejar conexiones TLS, resultando en ningún listener en el puerto 443. Chrome entonces reporta ERR_CONNECTION_REFUSED porque nada está escuchando, aunque la causa subyacente sea un problema de certificado.
¿Por qué ERR_CONNECTION_REFUSED aparece solo en un sitio web específico?
Si el error está aislado a un solo dominio, las causas más probables son: el servicio web del servidor de destino se ha bloqueado, el firewall del servidor está bloqueando tu rango de IP, los registros DNS del dominio apuntan a una dirección IP antigua donde no hay ningún servicio en ejecución, o el sitio ha sido dado de baja. Usa curl -v https://thatdomain.com desde una red o servidor diferente para aislar la causa.
¿Cómo soluciono ERR_CONNECTION_REFUSED en localhost?
El servidor de aplicaciones no está en ejecución o está vinculado a un puerto diferente al que estás solicitando. Confirma qué está escuchando con ss -tlnp en Linux/macOS o netstat -ano | findstr :PORT en Windows. Inicia el proceso del servidor de aplicaciones y asegúrate de que esté vinculado a 0.0.0.0 o 127.0.0.1 en el puerto esperado.
¿Vaciar la caché DNS siempre soluciona ERR_CONNECTION_REFUSED?
Solo cuando la causa raíz es una entrada de caché DNS obsoleta que apunta a una dirección IP donde el servicio ya no está en ejecución. Si el servidor está caído, el firewall está bloqueando la conexión o el proxy está mal configurado, vaciar la caché DNS no tendrá ningún efecto. Usa dig o nslookup para verificar la resolución DNS antes y después de vaciar la caché para confirmar si DNS era realmente el problema.
