ERR_CONNECTION_REFUSED: el servidor rechaza la conexión

Qué significa el error

El navegador encontró la dirección del servidor, pidió una conexión en el puerto 443 (o 80) y el servidor respondió « no »: un paquete TCP de reinicio, que se envía cuando ningún programa escucha en ese puerto. Chrome muestra ERR_CONNECTION_REFUSED (« No se puede acceder a este sitio web »), Firefox « No se ha podido conectar », Safari « Safari no puede conectarse al servidor ».

No es un ERR_CONNECTION_TIMED_OUT (ninguna respuesta: un firewall que descarta los paquetes o un servidor apagado), ni un DNS_PROBE_FINISHED_NXDOMAIN (el nombre no se resuelve). Una conexión rechazada significa: la máquina funciona, pero el servidor web está detenido, escucha en otro puerto o en otra dirección, o un firewall rechaza en lugar de ignorar.

Causas frecuentes

1. El servidor web está detenido. nginx o Apache se cayó, no volvió a arrancar tras un cambio de configuración o lo detuvo una actualización. El caso más frecuente.
2. Dirección o puerto equivocado. Tras un cambio en las líneas listen, nginx solo escucha en 127.0.0.1 o solo en IPv4, mientras el DNS apunta también a una dirección IPv6.
3. Un firewall rechaza el puerto. ufw, firewalld o un grupo de seguridad cloud con una regla reject para el 80 y el 443.
4. Un servidor nuevo sin servidor web. El DNS ya apunta a la IP nueva, pero nginx todavía no está en marcha ahí.
5. HTTPS sin configurar. El puerto 80 responde, nada escucha en el 443 y el navegador (o una entrada HSTS) exige HTTPS.
6. Causas locales en el visitante. Un proxy muerto, una VPN, la « protección web » de un antivirus, una línea en el archivo hosts, una extensión del navegador.

Si eres visitante

1. Prueba el sitio en una ventana privada y en otro navegador, para descartar extensiones y caché.
2. Desactiva un proxy manual que no uses, y apaga un momento la VPN y la protección web del antivirus.
3. Vacía la caché DNS (sudo dscacheutil -flushcache en macOS, sudo resolvectl flush-caches en Linux): quizá conserva la dirección antigua de un sitio que se mudó.
4. Prueba http:// en lugar de https://; si así entra, el HTTPS del sitio está roto y el propietario tiene que repararlo.

Si es tu sitio: comprobar primero

Abre el Website down checker. « Conexión rechazada » desde fuera confirma que el propio servidor rechaza. Entra después por SSH; que SSH responda mientras el sitio rechaza ya es una pista: el servidor funciona, el servidor web no.

# ¿está en marcha el servidor web?
systemctl status nginx
systemctl status apache2

# ¿qué escucha en el 80 y el 443?
sudo ss -tlnp | grep -E ':80 |:443 '

# reglas del firewall
sudo ufw status verbose
sudo firewall-cmd --list-all

Si ss no muestra nada en el 443, el servidor web está detenido o no usa ese puerto. Si muestra 127.0.0.1:443 en lugar de 0.0.0.0:443, solo escucha en local.

Soluciones en tu propio servidor

1. Arrancar el servidor web y leer por qué estaba detenido

sudo systemctl start nginx
systemctl status nginx
sudo journalctl -u nginx -n 50

Si no arranca, casi siempre es:

• bind() to 0.0.0.0:80 failed (98: Address already in use): otro programa ocupa el puerto (Apache y nginx instalados a la vez, o un proceso antiguo). sudo ss -tlnp | grep ':80 ' lo nombra.
• [emerg] unknown directive o unexpected "}": un error de sintaxis. sudo nginx -t indica el archivo y la línea.
• cannot load certificate: un certificado eliminado o renovado en otra ruta. Compara las líneas ssl_certificate con el disco.
• Un disco lleno: df -h, df -i.

Apache: sudo apachectl configtest, luego sudo journalctl -u apache2 -n 50. AH00558 es solo un aviso, no la causa.

Prueba siempre antes de recargar, y recarga en lugar de reiniciar:

sudo nginx -t && sudo systemctl reload nginx
sudo apachectl configtest && sudo systemctl reload apache2

2. Escuchar en la dirección correcta

El bloque server de nginx debe escuchar en IPv4 y en IPv6:

listen 80;
listen [::]:80;
listen 443 ssl;
listen [::]:443 ssl;

Si el DNS tiene un registro AAAA pero el servidor no escucha en IPv6, los visitantes con IPv6 son rechazados y los demás entran. Escucha en IPv6 o elimina el AAAA.

3. Abrir el firewall

# ufw
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# firewalld
sudo firewall-cmd --permanent --add-service=http --add-service=https
sudo firewall-cmd --reload

En un servidor cloud, revisa también el grupo de seguridad del proveedor; una regla ahí es invisible desde el servidor.

4. Configurar HTTPS si solo responde el puerto 80

sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d example.com -d www.example.com

Certbot crea el bloque 443 y la redirección. Comprueba después la cadena con el SSL Checker.

5. Tras una mudanza de servidor

Instala, configura y arranca el servidor web en la máquina nueva antes de cambiar el DNS. Si no, vuelve a apuntar el DNS al servidor antiguo hasta que el nuevo esté listo.

Si el problema está en tu proveedor de hosting

En un hosting compartido, una conexión rechazada significa: el servidor web del proveedor se cayó, o te movió a una IP nueva sin actualizar el DNS. Envía esto:

Hola, mi sitio example.com devuelve « conexión rechazada » en los puertos 80 y 443 desde las 20:15 (UTC) aproximadamente. El dominio se resuelve a 203.0.113.10. No cambié nada por mi parte. ¿Está caído el servidor web de esa máquina, o mi sitio se movió a otra dirección?

Para que no vuelva a pasar

Una conexión rechazada es casi siempre un servidor web detenido, justo lo que una comprobación del sitio desde fuera nota de inmediato. En tu propio servidor, el agente de servidor te avisa cuando nginx o Apache se detiene.

¿Caído? Intervenimos. En tu propio servidor o en un hosting compartido con acceso SSH, la intervención rápida reinicia el servidor web si su prueba de configuración es correcta, a precio fijo, las 24 horas, todos los días. ¿Configuración rota? La intervención a fondo la repara, en bloques de 15 minutos; la estimación es el precio máximo.