Solucionando errores de 'Conexión rechazada' en Nginx: Una guía práctica de solución de problemas

Encontrar un error de 'Conexión rechazada' al intentar acceder a un servicio que se ejecuta detrás de Nginx es una experiencia común, aunque frustrante. A diferencia de un error de 'Tiempo de espera', que sugiere retraso en la red o pérdida de paquetes, un error de 'Conexión rechazada' es definitivo: el sistema operativo rechazó inmediatamente el intento de conexión porque ninguna aplicación estaba escuchando activamente en el puerto y la dirección IP especificados.

Este rechazo inmediato señala el problema a unas pocas áreas críticas: el servicio está caído, el cortafuegos está bloqueando el tráfico localmente, o la configuración dirige el tráfico a un puerto inexistente. Esta guía proporciona un enfoque sistemático de cuatro fases para diagnosticar y resolver errores de 'Conexión rechazada', asegurando que puedas restaurar rápidamente la conectividad del servicio.

Fase 1: Verificar el estado del servidor Nginx (El oyente principal)

La causa más básica de un rechazo de conexión es que el propio servicio de Nginx no se está ejecutando o está configurado incorrectamente.

1. Verificar el estado del servicio Nginx

Usa el administrador de servicios de tu sistema (generalmente systemd) para confirmar que Nginx está activo y en ejecución. Un fallo aquí es la causa directa del rechazo en el puerto de escucha principal (generalmente 80 o 443).

sudo systemctl status nginx

Salida esperada (Éxito): Busca Active: active (running).

Solución procesable: Si el estado muestra inactive o failed, intenta iniciar el servicio y verifica los registros para obtener detalles del fallo.

sudo systemctl start nginx
sudo journalctl -xe | grep nginx

2. Confirmar los puertos de escucha activos

Usa la herramienta ss (estadísticas de socket) o netstat para verificar que Nginx realmente se está vinculando a la dirección IP y puerto esperados (por ejemplo, 0.0.0.0:80 o 127.0.0.1:8080).

# Usando ss (preferido en distribuciones Linux modernas)
sudo ss -tuln | grep 80

# Usando netstat
sudo netstat -tuln | grep 80

Si no ves el puerto esperado (por ejemplo, :80 o :443) listado bajo un proceso (PID) asociado con Nginx, significa que Nginx falló al vincularse, probablemente debido a un error de configuración o a que otro servicio ya está ocupando ese puerto.

Consejo: Si otro servicio está ocupando el puerto, debes detener ese servicio o modificar la configuración de Nginx para que escuche en un puerto diferente y disponible.

Fase 2: Cortafuegos y configuración de red

Si Nginx se está ejecutando y escuchando localmente, el rechazo de conexión podría estar ocurriendo externamente al servicio, típicamente debido a reglas de cortafuegos que bloquean el tráfico entrante.

1. Verificar los cortafuegos del servidor local

Asegúrate de que los puertos en los que Nginx está escuchando (por ejemplo, 80, 443) estén explícitamente permitidos a través del cortafuegos del host (UFW, firewalld o iptables).

Ejemplo con UFW (Ubuntu/Debian)

sudo ufw status verbose
# Si está cerrado, permite los puertos:
sudo ufw allow 'Nginx Full'
# O específicamente:
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

Ejemplo con Firewalld (CentOS/RHEL)

sudo firewall-cmd --list-all
# Si está cerrado, agrega los servicios:
sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reload

2. Verificar los grupos de seguridad del proveedor de la nube

Si tu servidor está alojado en un entorno de nube (AWS EC2, Azure VM, GCP Compute Engine), el rechazo de conexión podría originarse en la capa de seguridad de la red virtual.

Grupos de seguridad de AWS (SG): Verifica el SG asociado y asegúrate de que las reglas de entrada permitan tráfico en los puertos 80 y 443 desde las direcciones IP de origen (generalmente 0.0.0.0/0 para acceso público).
Grupos de seguridad de red de Azure (NSG): Verifica las reglas de puerto de entrada.

Fase 3: Validación de la configuración de Nginx

Directivas de configuración incorrectas pueden llevar a que Nginx intente escuchar en un puerto o IP no disponible, resultando en un fallo de inicio y posterior rechazo de conexión.

1. Revisar las directivas `listen`

Inspecciona tu archivo de configuración principal (a menudo /etc/nginx/nginx.conf) y cualquier bloque de servidor relevante (generalmente en /etc/nginx/conf.d/ o /etc/nginx/sites-enabled/). Asegúrate de que las directivas listen sean correctas.

Ejemplo de un bloque listen configurado correctamente:

server {
    listen 80;
    listen [::]:80;
    server_name example.com;
    # ... otras directivas
}

Si Nginx está configurado para escuchar solo en 127.0.0.1 (localhost) pero intentas acceder usando la IP pública, la conexión será rechazada.

2. Ejecutar verificación de sintaxis de configuración

Antes de reiniciar Nginx, siempre valida la sintaxis de configuración. Un error de análisis impedirá que el servicio se inicie, causando el rechazo.

sudo nginx -t

Si la prueba falla, corrige el error identificado, vuelve a ejecutar la prueba y luego recarga o reinicia Nginx.

sudo systemctl reload nginx

Fase 4: Solución de problemas del proxy inverso (Upstream)

Si Nginx se está ejecutando correctamente en los puertos 80/443, pero acceder a una ruta específica (/api/) resulta en 'Conexión rechazada', el problema está entre Nginx y el servicio backend (el upstream).

En este escenario, Nginx aceptó la conexión inicial, pero cuando intentó proxy la solicitud, la conexión al backend fue rechazada. Los registros de errores lo confirmarán.

1. Verificar los registros de errores de Nginx

Examina los registros de errores de Nginx (generalmente /var/log/nginx/error.log) inmediatamente después de intentar la conexión fallida. Busca mensajes relacionados con la directiva proxy_pass, mencionando específicamente errores de conexión.

tail -f /var/log/nginx/error.log

Podrías ver una entrada como:

[error] connect() failed (111: Connection refused) while connecting to upstream

2. Verificar el estado del servicio backend

Esta es la solución más común en escenarios de proxy: la aplicación backend (por ejemplo, Node.js, Python Gunicorn, Apache) está caída o no está escuchando donde Nginx la espera.

Pasos procesables:

a. Verificar el estado del servicio backend: Confirma que la aplicación backend se está ejecutando.

b. Verificar el puerto de escucha del backend: Usa ss -tuln en el servidor que aloja el backend para confirmar que la aplicación está escuchando en la IP/Puerto especificados en la directiva proxy_pass de Nginx.

3. Probar la conectividad del backend directamente

Prueba la conexión desde el servidor Nginx al backend usando curl o telnet para aislar el problema de Nginx.

Supón que tu proxy_pass está configurado como http://127.0.0.1:8080:

# Probar conexión desde el servidor Nginx al puerto del backend
curl -v http://127.0.0.1:8080

# O usando telnet
telnet 127.0.0.1 8080

Si curl o telnet falla: El servicio backend es definitivamente el problema (no está escuchando o su cortafuegos interno está bloqueando el acceso a 127.0.0.1).
Si curl o telnet tiene éxito: El problema podría ser un error sutil en tu directiva proxy_pass (por ejemplo, punto y coma faltante, resolución de nombre de host incorrecta o una discrepancia en el protocolo—HTTP vs. HTTPS).

Error común en `proxy_pass`

Asegúrate de que la dirección IP en tu proxy_pass coincida con donde el backend está realmente vinculado. Si el backend se vincula a una IP específica (por ejemplo, 192.168.1.10:8080) pero Nginx usa localhost:8080, la conexión fallará si el enlace es restrictivo.

Verificaciones finales de los pasos clave de solución de problemas

Verificación del sistema: ¿Está Nginx en ejecución (systemctl status nginx)?
Verificación del puerto: ¿Está Nginx escuchando en la IP/Puerto correctos (ss -tuln)?
Verificación del cortafuegos: ¿Está abierto el puerto entrante en el cortafuegos del host (UFW, iptables)?
Verificación de la configuración: ¿Pasa nginx -t y son correctas las directivas listen?
Verificación del proxy (si aplica): ¿Está el servicio upstream en ejecución y escuchando en la IP/Puerto exactos definidos en proxy_pass? Prueba la conectividad directamente usando curl.

Trabaja a través de las verificaciones en orden: oyente, puerto, cortafuegos, configuración, luego upstream. Ese camino te mantiene enfocado en el lugar exacto donde se está rechazando la conexión.