ERR_CONNECTION_REFUSED

Qué significa este error y cómo reconocerlo

• Chrome, Edge u otro navegador basado en Chromium muestra «No se puede acceder a este sitio — ERR_CONNECTION_REFUSED».
• El error aparece rápidamente en lugar de producirse después de una espera prolongada. Un retraso largo es más coherente con un tiempo de espera agotado, como ERR_CONNECTION_TIMED_OUT.
• Un sitio que funcionaba anteriormente deja de funcionar después de reiniciar el servidor, realizar un despliegue, cambiar el DNS, actualizar la configuración o modificar el firewall.
• SSH u otro puerto de aplicación de la misma máquina puede seguir siendo accesible mientras el puerto web rechaza las conexiones.
• Las solicitudes realizadas en el servidor pueden tener éxito mientras que las solicitudes externas fallan cuando el servicio escucha únicamente en localhost o un firewall externo bloquea el puerto.

Causas principales, ordenadas por probabilidad

1. El servidor web o el proceso de la aplicación está detenido — Nginx, Apache o el servidor de aplicaciones puede haberse bloqueado, detenido o haber fallado durante el inicio.
2. No hay nada escuchando en el puerto solicitado — el servicio puede utilizar otro puerto, mientras que la solicitud se dirige al 80 o al 443.
3. El servicio está vinculado a la interfaz incorrecta — un proceso en escucha en 127.0.0.1 acepta solicitudes locales, pero no conexiones externas directas.
4. Un firewall del host o de la nube rechaza el tráfico — es posible que haya cambiado un firewall del sistema operativo, un grupo de seguridad, una ACL de red o el firewall del proveedor.
5. El DNS apunta al destino incorrecto — el dominio puede resolver a un servidor antiguo, reconstruido o no configurado. Un registro AAAA también puede dirigir a algunos visitantes a una dirección IPv6 sin un proceso web en escucha operativo.

Cómo solucionarlo

1. Confirma la dirección de destino

Comprueba los registros A y AAAA del dominio y compara las direcciones resueltas con el servidor que debería recibir la solicitud. Si el dominio apunta a un servidor antiguo, retirado o recién reconstruido, corrige el DNS antes de cambiar la configuración del servicio web. Si existen registros IPv4 e IPv6, verifica que el servicio y el firewall admitan ambas rutas.

2. Comprueba si el servicio está en ejecución

Mediante un método de administración autorizado, como SSH, comprueba el servicio correspondiente. Por ejemplo, inspecciona Nginx con systemctl status nginx; utiliza el nombre de servicio equivalente para Apache o el servidor de aplicaciones.

Si el servicio está detenido o ha fallado, revisa su estado y sus registros antes de iniciarlo. Un error de configuración introducido por un cambio reciente es una causa habitual de fallos durante el inicio. Valida la configuración con nginx -t para Nginx o apachectl configtest para Apache. Solo después de que la prueba sea correcta y si tienes autorización para cambiar el servicio, debes reiniciarlo o recargarlo. Un reinicio puede interrumpir solicitudes activas y quizá no sea apropiado durante un pico de producción.

3. Verifica el puerto y la interfaz en escucha

En el servidor, inspecciona los procesos en escucha con ss -tlnp o el equivalente de la plataforma. Confirma que el proceso esperado está escuchando en el puerto solicitado, normalmente :80 o :443.

Comprueba también la dirección de vinculación, no solo el puerto:

• 0.0.0.0:80 o 0.0.0.0:443 normalmente escucha en las interfaces IPv4 disponibles.
• Una dirección específica del servidor indica que el servicio está vinculado a esa interfaz.
• 127.0.0.1:80 o 127.0.0.1:443 acepta únicamente solicitudes locales.

Si la aplicación es intencionadamente privada en localhost, confirma que el reverse proxy público está en ejecución y redirige las solicitudes hacia ella. De lo contrario, ajusta la configuración del servicio para que escuche en la interfaz prevista durante un cambio de mantenimiento o despliegue aprobado.

4. Comprueba las reglas del firewall del host y de la nube

Revisa el firewall del servidor con ufw status, iptables -L o el comando equivalente del sistema operativo. Después, inspecciona el grupo de seguridad de la nube, la ACL de red o el firewall del proveedor asociado al servidor esperado.

Confirma que el tráfico entrante está permitido en el puerto requerido desde las fuentes correspondientes. Un sitio web público puede necesitar acceso desde Internet, mientras que un servicio interno debería utilizar un rango aprobado más limitado. Comprueba por separado las reglas IPv4 e IPv6 cuando se publiquen ambos tipos de registro. No amplíes el acceso más de lo necesario y realiza cambios en el firewall únicamente con autorización.

5. Realiza pruebas locales y externas

Desde el servidor, prueba por separado el proceso local en escucha y el nombre de host configurado. El éxito local solo confirma que algo responde en la máquina; no demuestra que los clientes externos puedan acceder al puerto.

Después de corregir el DNS, el servicio, la vinculación o el firewall, ejecuta una solicitud detallada con curl -v contra el nombre de host afectado desde otra red o una máquina externa. Confirma que la solicitud llega a la dirección y el puerto esperados y que el rechazo ha desaparecido.

6. Compara los cambios recientes

Si el fallo comenzó después de un despliegue, reinicio, reconstrucción del servidor, actualización del DNS o cambio del firewall, compara la configuración actual con la última versión conocida que funcionaba. Busca específicamente un puerto cambiado, un inicio fallido del servicio, una vinculación limitada a localhost, una regla asociada al servidor incorrecto o una configuración IPv6 incompleta.

Prevención y cómo verificar la solución

• Utiliza un gestor de servicios o un supervisor de procesos para que el servicio web pueda recuperarse de un fallo inesperado.
• Convierte la validación de la configuración, como nginx -t o apachectl configtest, en una comprobación obligatoria del despliegue antes de recargar o reiniciar.
• Documenta los puertos, las direcciones de vinculación, las reglas del firewall, los grupos de seguridad y los registros DNS previstos como referencia de una configuración conocida y correcta.
• Supervisa el servicio desde fuera del servidor en lugar de depender únicamente de las comprobaciones de estado locales.
• Revisa los procesos en escucha y las reglas del firewall de IPv4 e IPv6 siempre que un dominio tenga registros A y AAAA.
• Registra los cambios de infraestructura para poder relacionar un nuevo rechazo con un despliegue, una reconstrucción, una actualización del DNS o un cambio del firewall.

Preguntas frecuentes