ERR_CONNECTION_REFUSED: «ha rechazado la conexión», solución

¿Qué es ERR_CONNECTION_REFUSED?

ERR_CONNECTION_REFUSED significa que tu navegador encontró la dirección IP del sitio web, pero la máquina que está en esa dirección rechazó la conexión. Chrome muestra «No se puede acceder a este sitio web» con «La página example.com ha rechazado la conexión.» y el código ERR_CONNECTION_REFUSED, el error -102 de la lista de Chromium (net_error_list.h).

Tu dispositivo envió una solicitud de conexión TCP a la dirección IP y al puerto del servidor (443 para HTTPS, 80 para HTTP) y recibió un rechazo al instante, ya sea un TCP reset o un mensaje de «puerto inalcanzable» de un firewall: ningún programa aceptaba conexiones en ese puerto, o un firewall rechazó la solicitud. El DNS funcionó; la conexión no.

Dicho de otro modo, es una respuesta, no silencio. Si no contesta nadie, Chrome espera y muestra ERR_CONNECTION_TIMED_OUT. Si la conexión se abre y luego se corta, es ERR_CONNECTION_RESET; si el servidor cuelga antes de enviar la página, ERR_CONNECTION_CLOSED.

Cómo se ve en otros navegadores y apps

Una conexión rechazada es el mismo suceso en todas partes; solo cambia la redacción. Los navegadores basados en Chromium (Chrome, Edge, Brave, Opera) muestran el código ERR_CONNECTION_REFUSED, y las apps informan del error propio del sistema operativo:

Las soluciones de abajo valen sea cual sea la redacción: algo en esa dirección y ese puerto dijo que no.

Causas comunes de ERR_CONNECTION_REFUSED

Las causas, desde el lado del sitio web hasta el tuyo:

• El servidor del sitio web está caído — el servidor web (nginx, Apache, Node.js) se bloqueó, se está reiniciando o lo han detenido. La máquina está en línea, pero nada responde en el puerto 80 o 443.
• Un firewall configurado para rechazar — un firewall del servidor, de tu red o de tu dispositivo que rechaza (en lugar de descartar sin avisar) las conexiones a ese puerto.
• El sitio bloquea tu red — algunos sitios rechazan rangos enteros de direcciones, como los servidores de salida de una VPN o un país.
• Software de seguridad o una VPN — un escudo web del antivirus o una VPN que enruta tu tráfico a través de sí misma y rechaza la conexión. (Un firewall de tu propio dispositivo que bloquea Chrome muestra otra página, «Tu acceso a Internet está bloqueado», ERR_NETWORK_ACCESS_DENIED.)
• La dirección IP equivocada — una caché DNS obsoleta o una entrada del archivo hosts te envía a un servidor antiguo, o a tu propio ordenador (127.0.0.1), donde no escucha nada.
• Una redirección o regla HTTPS recordada — Chrome guardó una redirección, o la regla HSTS del sitio, y sigue enviándote a un puerto que el sitio ya no atiende.
• Nada escuchando en localhost — para desarrolladores: el servidor local no está en ejecución, se bloqueó o está en un puerto o dirección distintos de los que abriste.

¿Un sitio, todos los sitios o todos los navegadores?

Dónde aparece el error te dice dónde mirar, antes de cambiar nada:

«En todos los navegadores» importa: Edge, Firefox y Safari no comparten la caché ni las extensiones de Chrome, así que un rechazo en todos ellos apunta por debajo del navegador: a tu dispositivo, a tu red o al propio sitio.

Solución 1: comprueba si el sitio está caído para todos

Antes de cambiar nada en tu dispositivo, averigua si el sitio rechaza a todo el mundo. Si es así, ninguna solución de tu lado servirá.

La prueba más rápida es otro camino de red: abre el sitio en el teléfono con datos móviles (Wi-Fi apagado). Después prueba el servidor desde fuera con estas herramientas de DNS Robot:

• Verificador de páginas caídas — abre el sitio desde 11 lugares y desde tu propio navegador. Si está caído en todas partes, es el sitio; si funciona en todas partes menos para ti, el problema está de tu lado.
• Verificador de puertos — introduce el sitio con el puerto 443 (o example.com:443). Cerrado significa que el servidor también rechazó nuestra conexión; abierto, que acepta conexiones y el rechazo es solo tuyo.
• Test de Ping — se conecta al sitio por el puerto 443 desde 11 ciudades, además de un ping clásico desde una. Si lo rechazan desde todas las ciudades, la máquina está encendida pero nada escucha en ese puerto; que el ping clásico no responda no demuestra nada, porque muchos servidores lo ignoran.

Solución 2: reinicia tu router y tu dispositivo

La primera sugerencia de Chrome, «Comprobar la conexión», dice que reinicies «los routers, módems u otros dispositivos de red» que uses. Así se borra todo el estado acumulado en el router, incluida su caché DNS.

Desenchufa tu router (y el módem, si es aparte), espera 30 segundos, vuelve a enchufarlo y dale 2–3 minutos para que se reconecte del todo. Reinicia también el ordenador o el teléfono para restablecer su pila de red y prueba el sitio de nuevo.

Solución 3: borra las redirecciones y reglas HTTPS que Chrome recuerda

Chrome recuerda las redirecciones permanentes y la regla HSTS de cada sitio («usar siempre HTTPS»). Si el sitio se ha mudado, o dejó de servir HTTPS en el puerto 443, Chrome sigue enviándote a una dirección o puerto donde no escucha nada.

• Abre Chrome → menú de tres puntos → Borrar datos de navegación
• Intervalo de tiempo → Desde siempre, marca Archivos e imágenes en caché (las cookies pueden quedarse)
• Haz clic en Eliminar datos (o en Eliminar de este dispositivo si no has iniciado sesión en Chrome) y prueba el sitio de nuevo
• ¿Sigue rechazado? Abre chrome://net-internals/#hsts, escribe el dominio en Delete domain security policies y haz clic en Delete. Solo sirve para reglas que el propio sitio estableció, no para dominios incluidos en la lista de precarga HSTS de Chrome.

Un cambio de 2026: Chrome 154 (octubre de 2026) activa por defecto «Usar siempre conexiones seguras», de modo que Chrome te pide permiso antes de la primera visita a un sitio público sin HTTPS en lugar de probarlo en silencio (Google Security Blog).

Solución 4: revisa tu configuración de proxy

La página de error de Chrome menciona el proxy, así que revísalo, pero sabiendo qué esperar. Cuando Chrome no puede alcanzar un servidor proxy, muestra una página con el título «Sin conexión a Internet» y ERR_PROXY_CONNECTION_FAILED («Se ha producido un error con el servidor proxy o la dirección es incorrecta») en lugar de ERR_CONNECTION_REFUSED. Si ves esa página, esta es tu solución.

Windows: Configuración → Red e Internet → Proxy. En Configuración manual del proxy, haz clic en Editar junto a «Usar un servidor proxy», desactívalo y haz clic en Guardar. Desactiva también «Usar script de configuración» si no reconoces la dirección. Deja activado «Detectar automáticamente la configuración», salvo que sepas que tu red no lo usa.

macOS: Ajustes del Sistema → Red → Wi-Fi → Detalles → Proxies. Desactiva todos los proxies que no haya configurado tu organización y haz clic en OK.

Chrome usa la configuración de proxy del sistema, y Firefox también por defecto («Usar la configuración del proxy del sistema»), así que un solo proxy obsoleto estropea todos los navegadores a la vez. En un dispositivo de la escuela o del trabajo, el proxy lo fija el administrador y no puedes cambiarlo.

Solución 5: vacía tu caché DNS

Si el sitio se mudó a un servidor nuevo, una respuesta DNS en caché puede seguir apuntando a la IP antigua, donde ya no escucha nada. Al vaciar la caché, tu dispositivo busca la dirección actual.

# Windows (Command Prompt as Administrator)
ipconfig /flushdns

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Linux (systemd-resolved)
sudo resolvectl flush-caches

# Also clear Chrome's internal DNS cache:
# chrome://net-internals/#dns → Clear host cache

Después de vaciarla, borra también la caché DNS propia de Chrome en chrome://net-internals/#dns y vacía los grupos de sockets en chrome://net-internals/#sockets: Chrome mantiene ambos por separado del sistema operativo. Para el tutorial completo, consulta nuestra guía sobre cómo vaciar la caché DNS en cada sistema operativo.

Para ver la dirección que tu ordenador usa de verdad (con el archivo hosts y la caché incluidos), ejecuta ping example.com, o Resolve-DnsName example.com en PowerShell, y compárala con la Consulta DNS. No uses nslookup para esto: pregunta directamente al servidor DNS y se salta ambos.

Solución 6: cambia a un servidor DNS público

Si el resolver de tu proveedor sigue dando una dirección antigua después de vaciar la caché, cambia a un resolver público para obtener una respuesta nueva.

Windows: Configuración → Red e Internet → Wi-Fi → «Administrar redes conocidas» → tu red (Ethernet → tu red) → Editar junto a «Asignación de servidor DNS» → Manual → IPv4 activado → DNS preferido 1.1.1.1, DNS alternativo 1.0.0.1 → Guardar.

macOS: Ajustes del Sistema → Red → Wi-Fi → Detalles → DNS → añade 1.1.1.1 y 1.0.0.1 y elimina las entradas antiguas → OK.

¿No sabes qué resolver es el más rápido desde tu ubicación? Ejecuta el Test de velocidad de DNS de DNS Robot: compara Cloudflare, Google, Quad9 y otros desde tu propia conexión en segundos.

Solución 7: desactiva temporalmente VPN, antivirus y firewall

Las VPN, los escudos web del antivirus y los firewalls se sitúan entre tu navegador e internet, y cada uno puede rechazar una conexión. Los escudos que analizan HTTPS pasan tu tráfico por un servicio local; si ese servicio se rompe, los sitios HTTPS pueden fallar en todos los navegadores a la vez. Y algunos sitios rechazan directamente las direcciones de VPN.

Pruébalos uno por uno: desconecta la VPN y recarga. Luego pausa la protección web del antivirus durante un minuto y recarga. Por último, pausa cualquier firewall de terceros, que suele formar parte de una suite antivirus. (El firewall de macOS solo filtra las conexiones entrantes, y el Firewall de Windows Defender permite el tráfico saliente salvo que alguien haya añadido una regla. Si Chrome dice «Tu acceso a Internet está bloqueado», la causa es un firewall de tu dispositivo.)

Si el sitio carga con uno de ellos desactivado, vuelve a activarlo y añade una excepción para el sitio, o elige otro servidor de VPN, en lugar de dejar la protección desactivada.

Solución 8: prueba las extensiones en modo incógnito

Las extensiones rara vez causan este código: una que bloquee un sitio muestra ERR_BLOCKED_BY_CLIENT. Pero una ventana de incógnito (Ctrl+Shift+N, o Cmd+Shift+N en Mac) es una prueba de diez segundos que descarta a la vez las extensiones y los datos en caché, porque allí las extensiones están desactivadas salvo que las hayas permitido.

Si el sitio carga en incógnito, ve a chrome://extensions, desactívalas todas y vuelve a activarlas una a una hasta que reaparezca el error. Si sigue fallando en incógnito, la causa está fuera de Chrome.

Solución 9: revisa tu archivo hosts

Tu archivo hosts anula el DNS para los nombres que contiene. Si el sitio está asignado a 127.0.0.1 o a la IP de un servidor antiguo, tu navegador se conecta ahí y lo rechazan. Las entradas de desarrollo olvidadas y las listas hosts de bloqueo de anuncios son los culpables habituales, y el archivo afecta a todos los navegadores.

# Windows — open as Administrator:
notepad C:\Windows\System32\drivers\etc\hosts

# macOS / Linux:
sudo nano /etc/hosts

# Look for lines containing the domain, e.g.:
# 127.0.0.1   example.com   ← forces the connection to your own PC
# 203.0.113.7 example.com   ← forces an old server IP

# Delete the offending line, save, then flush DNS.

Solución 10: en Android o iPhone

Los teléfonos rechazan conexiones por las mismas razones, con otros interruptores:

• Cambia de red: carga el sitio con datos móviles y luego con Wi-Fi. Si solo una de las dos lo rechaza, el problema es esa red, no el teléfono.
• Desactiva las apps de VPN, incluidos los bloqueadores de anuncios y firewalls que funcionan como VPN (muestran una llave o un icono de VPN en la barra de estado).
• Quita el proxy de la red Wi-Fi: en Android, abre los ajustes de la red Wi-Fi → icono del lápiz (Modificar) → Opciones avanzadas → Proxy → Ninguno (el texto varía según el fabricante). En iPhone: Ajustes → Wi-Fi → ⓘ junto a la red → Configurar proxy → «Off» (desactivado).
• Borra los datos de Chrome: Chrome → Configuración → Privacidad y seguridad → Borrar datos de navegación → Archivos e imágenes en caché.
• ¿Pruebas tu propio servidor? En un teléfono, localhost es el propio teléfono. Usa la dirección IP local de tu ordenador (mira la sección siguiente).

Localhost rechazó la conexión (para desarrolladores)

Ver localhost rechazó la conexión o ERR_CONNECTION_REFUSED en 127.0.0.1 significa que nada de tu máquina acepta conexiones en la dirección y el puerto que abriste. Las razones habituales:

• El servidor de desarrollo no está en ejecución — nunca lo iniciaste, o se bloqueó. Revisa la terminal donde deberían estar corriendo npm run dev, rails s o python manage.py runserver.
• Puerto equivocado — el servidor arrancó en otro puerto (3001 porque el 3000 estaba ocupado, por ejemplo). Copia la dirección de su línea de arranque.
• Sin puerto en la dirección — http://localhost va al puerto 80, mientras que los servidores de desarrollo usan el suyo (3000, 5173, 8000, 8080).
• 127.0.0.1 frente a [::1] — los navegadores prueban ambas direcciones para localhost, pero un servidor puede escuchar solo en una. Si abres directamente la otra dirección (http://127.0.0.1:3000 o http://[::1]:3000), o te conectas desde una herramienta que prueba solo una, te rechazan.
• Dentro de Docker — la app debe escuchar en 0.0.0.0 dentro del contenedor y el puerto debe estar publicado (-p 3000:3000). Una app ligada a 127.0.0.1 en un contenedor no es accesible desde tu máquina (puede que veas ERR_EMPTY_RESPONSE).
• Desde un teléfono o un emulador — allí, localhost es el propio dispositivo. Usa la IP de LAN de tu ordenador y arranca el servidor de desarrollo en todas las interfaces (Vite: --host), o 10.0.2.2 desde el emulador de Android, su alias para el localhost de tu ordenador.

# What is listening on port 3000?
# macOS / Linux:
lsof -nP -iTCP:3000 -sTCP:LISTEN

# Windows (PowerShell):
netstat -ano | findstr :3000 | findstr LISTENING

# No output = nothing is listening = connection refused.
# 127.0.0.1:3000 in the output = IPv4 only; [::1]:3000 = IPv6 only.

Si necesitas comprobar si un puerto de tu servidor público es alcanzable desde internet (y no solo desde la propia máquina), usa el Verificador de puertos de DNS Robot: prueba la conexión desde fuera de tu red, que es lo que experimentan tus visitantes.

«Ha rechazado la conexión» dentro de una página incrustada

Si «La página example.com ha rechazado la conexión.» aparece dentro de un recuadro de otra página (un formulario, un informe, un mapa o un inicio de sesión incrustados), normalmente no es un problema de red. Chrome muestra la misma frase cuando el sitio incrustado prohíbe que lo muestren dentro de páginas de otros sitios mediante una cabecera X-Frame-Options o Content-Security-Policy: frame-ancestors. Internamente es ERR_BLOCKED_BY_RESPONSE, error -27 (net_error_list.h).

Como visitante, abre el enlace incrustado en su propia pestaña; allí cargará. Como propietario del sitio, permite la página que te incrusta con Content-Security-Policy: frame-ancestors 'self' https://parent.example. X-Frame-Options solo puede decir DENY o SAMEORIGIN, y los navegadores actuales siguen frame-ancestors cuando una página envía ambas. Mira qué envía tu sitio con el Verificador de encabezados HTTP, y nuestra guía de X-Frame-Options tiene las cabeceras exactas.

Para propietarios de sitios web: tu sitio rechaza conexiones

Si los visitantes informan de ERR_CONNECTION_REFUSED en tu sitio, sus paquetes llegan a una máquina de tu IP, pero nada ahí acepta la conexión. Repasa esta lista:

• ¿Está en marcha el servidor web? Entra por SSH y comprueba systemctl status nginx (o apache2, caddy). Un servidor que no arrancó tras un reinicio por una configuración rota, o que mató el sistema al quedarse sin memoria, deja la máquina sin nada escuchando. Reinícialo con sudo systemctl restart nginx.
• ¿Escucha en los puertos y direcciones correctos? Ejecuta ss -tlnp | grep -E ':(80|443) '. Un servidor que escucha solo en 127.0.0.1 rechaza a todos los de fuera; si no hay nada en el 443, ningún bloque de servidor escucha ahí (nunca se configuró HTTPS, o el archivo del sitio no está habilitado). nginx -T muestra la configuración que está cargada de verdad.
• ¿Hay un firewall rechazando? Una regla configurada para rechazar (iptables REJECT, ufw reject) envía rechazos. El deny por defecto de ufw y los firewalls en la nube, como los grupos de seguridad de AWS, descartan los paquetes sin avisar, y los visitantes ven ERR_CONNECTION_TIMED_OUT.
• ¿Ha baneado fail2ban a alguien? Su ban por defecto rechaza la dirección bloqueada, así que ese visitante (o tú, tras unos inicios de sesión SSH fallidos) recibe ERR_CONNECTION_REFUSED mientras los demás entran. Comprueba sudo fail2ban-client status.
• ¿Cambió la IP de tu servidor? Compara tu registro A con la IP real del servidor usando la Consulta DNS. Tras una migración, un registro A antiguo envía a los visitantes a la máquina anterior.
• ¿Detrás de Cloudflare? Con registros en modo proxy (nube naranja), los visitantes se conectan a Cloudflare, no a ti, y no verán este código. Cuando tu origen rechaza las conexiones de Cloudflare, Cloudflare muestra su propio Error 521: Web server is down.
• Prueba desde fuera: el Verificador de puertos en los puertos 80 y 443, y el Verificador de encabezados HTTP para una petición real desde internet.

Cómo verificar que la solución funcionó

Después de cada solución, comprueba la conexión a nivel de red en lugar de limitarte a recargar la página: así sabrás si el puerto se abrió de verdad.

# Test the TCP connection directly (Mac/Linux):
nc -zv -w 5 example.com 443
# "succeeded" = port open, "refused" = still rejected

# Windows (PowerShell):
Test-NetConnection example.com -Port 443
# TcpTestSucceeded : True = fixed

# Then confirm the address your computer actually uses:
ping -c 1 example.com          # Mac/Linux
Resolve-DnsName example.com    # Windows PowerShell

O sáltate la terminal: pasa el dominio y el puerto por el Verificador de puertos de DNS Robot para obtener una respuesta de abierto/cerrado desde fuera de tu red. Si el puerto está abierto desde fuera pero tu navegador sigue mostrando ERR_CONNECTION_REFUSED, el bloqueo está en tu dispositivo o en tu red: vuelve a las soluciones de VPN, software de seguridad y archivo hosts.