¿Cómo diagnostica errores 502 y 504 en Nginx?

Question

IT Interview Practice · Accepted Answer

Averigüe dónde falló la solicitud antes de aumentar los tiempos de espera. Un 502 suele señalar un fallo de comunicación con el upstream; un 504 suele indicar que expiró una espera del upstream. Los registros distinguen el fallo real.

## Ejemplo: la aplicación no está escuchando

Suponga que un fragmento del registro de errores dice:

```text
connect() failed (111: Connection refused) while connecting to upstream
upstream: "http://127.0.0.1:3000/products"
```

Nginx intentó conectarse al puerto 3000 y la conexión fue rechazada. Compruebe que la aplicación esté ejecutándose y escuchando en esa dirección. Desde la propia máquina o contenedor de Nginx, pruebe `curl -i http://127.0.0.1:3000/products`. Dentro de un contenedor, esa dirección se refiere al propio contenedor, no automáticamente al de otra aplicación.

## Ejemplo: conectado, pero sin cabeceras de respuesta a tiempo

```text
upstream timed out while reading response header from upstream
```

Esto indica una espera de cabeceras de respuesta. Correlacione la solicitud con los registros de la aplicación y las consultas lentas de la base de datos. Compruebe el tiempo de conexión y de respuesta upstream para separar el establecimiento de red del trabajo de aplicación.

## Confirme la solución

Corrija la dirección o restablezca la aplicación fallida en el primer caso; investigue el trabajo lento en el segundo. Reintente la ruta afectada y supervise la tasa de errores y la latencia. Un `proxy_read_timeout` mayor permite una pausa más larga entre lecturas; no crea capacidad en el backend. Compruebe también los registros del CDN y de la aplicación si alguno produjo el error.

[Documentación oficial](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout).

Ejemplo: la aplicación no está escuchando

Ejemplo: conectado, pero sin cabeceras de respuesta a tiempo

Confirme la solución

Preguntas relacionadas