ERR_CONNECTION_REFUSED: qué significa y cómo solucionarlo

Qué significa ERR_CONNECTION_REFUSED

Una conexión TCP empieza con un handshake: el cliente envía un paquete SYN, y el servidor responde con SYN-ACK si hay un proceso enlazado a ese puerto. Cuando no hay ningún proceso escuchando, la pila de red del sistema operativo devuelve en su lugar un paquete RST, cerrando el intento en el acto. Ese RST es lo que produce ERR_CONNECTION_REFUSED en Chrome y sus equivalentes en otros navegadores. La conexión llegó hasta la máquina de destino y recibió un no claro, lo que distingue este error de un tiempo de espera agotado, donde nada responde en absoluto.

La respuesta RST viene de la pila TCP del kernel, no de ningún código de aplicación, por eso llega en pocos milisegundos en lugar de después de varios segundos de espera. Esto también significa que la propia máquina está activa y respondiendo tráfico de red; simplemente no tiene nada enlazado al puerto concreto al que apuntaba la petición. Esa distinción importa a la hora de decidir por dónde empezar a mirar: una conexión rechazada apunta al puerto y al proceso que hay detrás, no a la alimentación del servidor ni a su enlace de red.

Cómo aparece el error

Chrome muestra una página sencilla "This site can't be reached ... ERR_CONNECTION_REFUSED" sin más detalle. Firefox reporta "Unable to connect" y nombra el host y el puerto que probó. La línea de comandos da una imagen más exacta:

curl -v https://example.com:8443/
* Trying 203.0.113.10:8443...
* connect to 203.0.113.10 port 8443 failed: Connection refused
* Failed to connect to example.com port 8443 after 2 ms: Connection refused

El mensaje nombra el puerto exacto que probó curl y reporta el rechazo en un par de milisegundos, lo bastante rápido como para descartar un tiempo de espera agotado. telnet host port o nc -zv host port devuelven la misma línea "Connection refused".

Qué causa ERR_CONNECTION_REFUSED

• No hay nada escuchando en ese puerto. El servidor web, la aplicación o el proxy que debería estar enlazado al puerto no se está ejecutando.
• El servicio se detuvo o se cayó. Un proceso que terminó, que fue matado por consumir demasiada memoria, o que se detuvo por mantenimiento deja el puerto sin enlazar.
• Una regla de firewall rechaza la conexión directamente. Una regla REJECT devuelve el mismo RST que devolvería un puerto cerrado, así que desde fuera parece idéntico a que no haya nada ahí.
• Hay un puerto equivocado en la URL. Una errata, un marcador antiguo de antes de un cambio de puerto, o un servicio que se movió a otro puerto, todos producen este error contra el puerto antiguo.
• Un servidor de desarrollo local no se está ejecutando. Un localhost:3000 rechazado casi siempre significa que el servidor de desarrollo se detuvo o nunca se inició en esta sesión de terminal.
• Un proxy o una VPN están mal configurados. Un proxy que apunta a un backend caído, o un cliente VPN que reescribe peticiones hacia un puerto que nada atiende, rechaza la conexión por su propia cuenta.
• El mapeo de puerto de un contenedor no coincide con la aplicación que hay dentro. Un servicio de Docker o Kubernetes cuyo puerto publicado difiere del puerto al que realmente se enlaza la aplicación produce este error aunque el proceso en sí se esté ejecutando y esté sano.

Cómo saber de quién es la culpa

Si el sitio carga ahora mismo para otras personas, o cargó para ti hace un minuto, el problema es más probablemente local: una VPN, un ajuste de proxy, o una regla de firewall en tu propia máquina o red. Si falla igual desde un teléfono con datos móviles, el lado del servidor está rechazando conexiones para todo el mundo. Ejecutar una comprobación de HTTP o de puerto desde varias ubicaciones a la vez resuelve esto en una sola petición; si los puntos de control en varios países reportan todos la conexión rechazada, la causa es el servidor o su firewall, no tu red.

Cómo corregir ERR_CONNECTION_REFUSED

Si eres el visitante

1. Confirma la URL y el puerto. Revisa si hay una errata, un marcador antiguo, o un enlace que todavía apunta a un puerto dado de baja.
2. Desactiva tu VPN o proxy y recarga. Si el sitio carga después, la configuración de la VPN o del proxy es la causa; revisa sus ajustes o contacta con quien la administre.
3. Prueba con otra red, como datos móviles en lugar de wifi, para descartar una regla de firewall o de router local.
4. Espera y vuelve a intentarlo. Si el propietario del sitio está en medio de un despliegue o reiniciando un servicio, el puerto puede quedar sin enlazar solo durante unos segundos.

Si administras el sitio

1. Confirma que el proceso se está ejecutando y está enlazado al puerto esperado:

   ss -ltnp | grep :443
   netstat -tlnp | grep :443

   Un resultado vacío significa que nada está escuchando; inicia el servicio o corrige su puerto configurado.
2. Revisa el estado del servicio y sus registros:

   systemctl status nginx
   journalctl -u nginx -n 50

   Aquí aparece una unidad caída o fallida, a menudo con el motivo por el que salió.
3. Revisa el firewall en busca de una regla REJECT en el puerto:

   iptables -L -n | grep REJECT
   ufw status verbose

   Una regla REJECT parece idéntica desde fuera a un puerto cerrado, así que este paso es fácil de pasar por alto.
4. Confirma que el servicio escucha en la interfaz correcta. Un servidor enlazado a 127.0.0.1 en lugar de 0.0.0.0 rechaza cualquier conexión que llegue desde fuera de la máquina, aunque funcione bien desde una shell local.
5. Reinicia el servicio una vez corregida la configuración, y confirma que el puerto vuelve a estar enlazado con el mismo comando ss antes de dar el problema por resuelto.

Cómo prevenir ERR_CONNECTION_REFUSED

Un servicio caído o una regla de firewall accidental suelen manifestarse primero como conexiones rechazadas y no como una alerta del propio servidor, ya que un proceso que no se está ejecutando no puede reportar su propio fallo. La monitorización de puertos continua detecta esto en minutos conectando desde fuera de la red del mismo modo que lo haría un visitante, y envía una alerta por correo, SMS, llamada de voz, Slack, Telegram y otros canales en cuanto falla una comprobación.

Errores relacionados

• ERR_CONNECTION_TIMED_OUT ocurre cuando nada responde en absoluto al intento de conexión, en lugar de rechazarlo activamente.
• ERR_CONNECTION_RESET ocurre cuando una conexión fue aceptada y luego se cortó a mitad de camino.
• This site can't be reached cubre todo el conjunto de errores de conexión que Chrome agrupa bajo un único título.

Preguntas frecuentes

¿ERR_CONNECTION_REFUSED es lo mismo que un firewall bloqueándome?

Puede serlo. Una regla REJECT de firewall produce la misma respuesta RST que un puerto cerrado, así que ambos parecen idénticos vistos desde el navegador. Una regla DROP se comporta de forma distinta y produce en su lugar un tiempo de espera agotado.

¿Por qué ocurre esto solo en localhost?

Casi siempre porque el servidor de desarrollo local no se está ejecutando en esa terminal, se detuvo, o se cayó al arrancar por un error de código o de configuración. Revisa la terminal donde normalmente lo inicias en busca de un mensaje de error.

¿Puede una VPN causar ERR_CONNECTION_REFUSED?

Sí. Una VPN que enruta el tráfico a través de un proxy o una puerta de enlace puede rechazar conexiones en nombre de esa puerta de enlace si su propio backend está caído, aunque el servidor de destino real esté sano.

¿ERR_CONNECTION_REFUSED significa que el sitio web está caído para todo el mundo?

No necesariamente. Prueba desde una segunda red o ejecuta una comprobación desde varias ubicaciones antes de concluir eso. Una única regla de firewall mal configurada o una VPN local pueden producir el mismo error mientras el sitio funciona bien para todos los demás.

¿Cuál es la diferencia entre rechazado y reseteado?

Rechazado significa que el intento de conexión nunca se completó; el destino lo rechazó de inmediato. Reseteado significa que la conexión se estableció y estaba funcionando, y luego se cortó a mitad de camino, normalmente por algo más adelante en la ruta.

¿Cómo averiguo qué proceso debería estar escuchando?

Revisa los propios registros de arranque de la aplicación y su configuración para ver qué puerto espera enlazar. Si el proceso se está ejecutando pero enlazado a un puerto distinto del que usa la URL, actualiza la URL o la configuración para que ambos coincidan, y luego confirma con ss -ltnp que el puerto está ahora enlazado como se esperaba.